January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 21.0-b60 Bug in tm 25 years, 4 months

Oscar Figueiredo

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Raymond> A colleague of mine noticed that in the latest versions of tm (1.15) Raymond> and vm (1.14), there's a small bug. tm-vm uses vm-sprintf, but that Raymond> no longer exists in vm. Can vm-summary-sprintf be used instead? TM is dead, VM has its own MIME support. I have dropped support of tm-vm for a long time. This was only a dirty hack created when VM had no native MIME. Further usage should be discouraged and we should even consider removing that file from the distribution. Oscar

2 participants
1 comments

Re: Steve's tty problem -- attention Linux testers building with gpm 25 years, 4 months

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > The crash I'm getting is occurring in a call to Gpm_Open, but only > when XEmacs is run inside an xterm. When run on the Linux console the > splash screen comes up. When I build without GPM everything is fine. ... and went away when I rebuilt libgpm.so. A version incompatibility against an unreleased libc isn't even close to being a showstopper so the countdown resumes.

1 participants
0 comments

Re: XEmacs 21 /vs./ my keyboard: I want my DEL back 25 years, 4 months

Gary D. Foster

>>>>> "Rick" == Rick Campbell <rick(a)campbellcentral.org> writes: Rick> If you have developed a desire to have DEL key change Rick> directions, I can take a good guess as to where you might Rick> have picked that up. While it puts you in a majority of Rick> sorts, you could also join a majority by adopting the notion Rick> that surfing the web and sending mail Actually, you need to back up just a step there. Martin is not responsible for the change. If you want to bitch at someone, bitch at me. I ramrodded this through (against some very serious protest) a couple of releases ago... and once I convinced Hrvoje and Glynn and a couple of other people they all jumped in and helped to make it work correctly from my first rudimentary fumblings. Even Kyle pitched in with a few judicious kicks in the hindquarters from time to time... I even worked with a few people who then tuned their major modes to take advantage of the new behavior. Those older modes that weren't as sophisticated as python-mode or cc-mode got a makeover by yours truly... Now, after it was out for a while and everyone was (pretty much) satisfied with it, Martin chose to make a single change... to change the _default_ behavior and not the underlying code. Now, if you want to yell, do it in my general direction because Martin has a lot better things to do than defend design decisions that he wasn't to blame for. -- Gary F. -- "Could a greater miracle take place than for us to look through each other's eyes for an instant?" -- Henry David Thoreau

2 participants
1 comments

Re: 21.0 TTY show-stopper 25 years, 4 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: ... > It is much worse when run on an actual terminal. That's why I called > it a show-stopper. > Not that I care myself -- I use X now. But as someone who used XEmacs > (not FSF Emacs) on terminals for some time, I know I'd be monstrously > annoyed by such a "feature". In applications like Gnus and VM your > frame is split most of the time, making every minibuffer operation > imply screen repaint. In an emulator, this is acceptable. On a > terminal... hardly. I don't believe any one is arguing against the fact you have identified a most undesirable feature. I'm certainly not. I can hold back naming a 21.0 release if you really wish it, but if it doesn't core dump, what real difference does it make if the patch to fix it comes in 21.0.63 or 21.1.1?

1 participants
0 comments

Re: 21.0 TTY show-stopper 25 years, 4 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Hrvoje Niksic writes: > > Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > > > > I don't see this under cygwin. I see the redisplay thing but I > > > > hardly think its a showstopper. > > > > > > Me either. I had to work pretty hard to notice the bug. > > > > Are you sure you were running XEmacs on a terminal? Not a terminal > > emulator, but the real thing? > > Emulator, usually running over a 28.8Kbps link. The redisplay > seems to be doing a screen repaint without a full-screen clear. > So I see the cursor dancing around but that's about it. It is much worse when run on an actual terminal. That's why I called it a show-stopper. Not that I care myself -- I use X now. But as someone who used XEmacs (not FSF Emacs) on terminals for some time, I know I'd be monstrously annoyed by such a "feature". In applications like Gnus and VM your frame is split most of the time, making every minibuffer operation imply screen repaint. In an emulator, this is acceptable. On a terminal... hardly.

1 participants
0 comments

Re: 21.0 TTY show-stopper 25 years, 4 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > I don't see this under cygwin. I see the redisplay thing but I > > hardly think its a showstopper. > > Me either. I had to work pretty hard to notice the bug. Are you sure you were running XEmacs on a terminal? Not a terminal emulator, but the real thing?

2 participants
1 comments

Re: 21.0 TTY [not a] show-stopper 25 years, 4 months

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: > Andy Piper writes: >> At 22:50 06/01/99 -0800, SL Baur wrote: >> >I can't duplicate this because I get something far, far worse. :-( >> > >> >$ src/xemacs -vanilla -nw >> > >> >Fatal error (11). >> >Your files have been auto-saved. >> >Use `M-x recover-session' to recover them. >> >> I don't see this under cygwin. I see the redisplay thing but I >> hardly think its a showstopper. > Me either. I had to work pretty hard to notice the bug. So you > get a full screen refresh when you hit RET in the minibuffer--- > it needs to be fixed certainly, but it doesn't need to be fixed > today. Add it to the pile for 21.1. I agree. The slowness should be fixed in 21.1.1. `xemacs -nw == memory fault, core dumped' is a showstopper unless it is only happening to me. Have you tried it with a Mule build? Is it O.K. for anyone else running Linux kernel revision 2.2.0-preX (and glibc 2.0-pre)?

1 participants
0 comments

21.0-b60 Bug in tm 25 years, 4 months

Raymond Toy

A colleague of mine noticed that in the latest versions of tm (1.15) and vm (1.14), there's a small bug. tm-vm uses vm-sprintf, but that no longer exists in vm. Can vm-summary-sprintf be used instead? Ray

2 participants
1 comments

Re: Feedback on pui-list-packages 25 years, 4 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > > Sure, but adapting `wid-edit.el' to that might be a lot of work. > > > I don't see anyone rushing to do it. > > > > I nominate andy. :) It already does a lot of this type of thing when > > determining whether to use glyphs or not, right? > > Wrong. Glyphs work just fine under TTY's. The only place where it > does anything like that is when it decides whether to use images. Well close enough for government work (especially in the US), it could decide whether to use images or the new glyph type for native widgets. Note that I haven't looked at the implementation of those native widgets much. :) -bp

2 participants
1 comments

Re: Feedback on pui-list-packages 25 years, 4 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > > And it won't work on TTY's. > > > > No reason it couldn't. Would just have to implement them ourselves, like > > any other `widgets' on a TTY. widget.el should provide the > > abstraction we need on whether to use 'native' widgets (when in X or > > Windows or whatever), and a text-only representation (like it uses > > now) on a TTY. > > Sure, but adapting `wid-edit.el' to that might be a lot of work. I > don't see anyone rushing to do it. I nominate andy. :) It already does a lot of this type of thing when determining whether to use glyphs or not, right? -Bill P.

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 1999