July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > I've no idea what this patch does, but this sort of thing should go > in the s&m files surely? No, we're trying to get rid of s&m files. getpt() should be detected by configure.

1 participants
0 comments

Re: GNU Emacs new isearch feature 25 years, 4 months

Hrvoje Niksic

Jake Colman <colman(a)ppllc.com> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> 21.1 is deeply frozen, sorry. > > Hrvoje> However, 21.2 happens to be quite stable, so xemacs-beta > Hrvoje> regulars should not hesitate to try it out. > > Is there a tentative release schedule for 21.2? I'm itching to try > it out but only if it is close to suitable for production use. 21.2 works nicely for me, for everyday editing and for news and mail-reading. Steve obviously has different experiences. I recommend you give 21.2 a shot, and if it doesn't work out for you, revert to 21.2.

1 participants
0 comments

Re: Shell trouble - third post (was Shell trouble - second post, please read) 25 years, 4 months

Rodney Stromlund

Yes, it is annoying and I agree that it seems that the shells output takes priority over your input. I made sure that font-lock was not on in case it was a regexp problem (actually I don't use font-lock in shell-mode ever). I looked at the 20.4 shell.el and the new package style shell.el and there isn't that much difference. If, from a shell buffer, I rlogin into another box I can break a program right away. If I exit the rlogin, the bad behaviour returns. I am guessing that since shell is on the same box the pipes are treated different than a pipe to a different machine. This could be a change to the process C code in XEmacs or it can be a un?x issue. ================================ Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu＠wnco.com (214) 792-6484 ================================ >>> Justin Vallon <vallon(a)mindspring.com> 07/29/99 06:50AM >>> On Wed, 28 Jul 1999, Rodney Stromlund wrote: > Surely someone somewhere has had this problem. I am > on a HP-UX 10.20 PA2.0. I have tried switching my > stty settings to just about everything possible and > I always have the same problem. I have not gotten a > single email on this. Please just email me and tell > me to shut up! Please read on : > > ** Previous post ** > > When I enter shell mode (I'm using ksh) if I start a > program that has lots of output, I can't break it > or move my cursor around until the program ends. Its > almost like xemacs is waiting for the shell to take a > breath before it will interrupt it. That happens to me too, and it is really annoying. My guess is that input is arriving too fast for xemacs to process the input, making xemacs the bottleneck. Then, maybe X events are not handled while there is non-X pipe input to process. Maybe include display updates in there somewhere. Maybe non-X input is being considered a higher priority than X input and/or X display refresh has very low priority. I think both may be true. > This problem isn't there in telnet or rsh. It is there in > rlogin and shell. Maybe the process-input path is shorter in those modes? Does telnet do fontification? Maybe it can be turned off in shell modes to at least help with the input flood? -Justin vallon(a)mindspring.com

1 participants
0 comments

Re: [patch] pty98 25 years, 4 months

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > I've no idea what this patch does, but this sort of thing should go in the > s&m files surely? If it will truly work on _any_ glibc based system, and not just a linux glibc based box, then it belongs outside of the s&m directories, because it is really just C library dependent. If it requires linux though, then it can go to hellthe s&m directories. -bp

1 participants
0 comments

Submitting new packages: pg.el & babel.el 25 years, 4 months

Eric Marsden

Hi, This is to suggest inclusion of two elisp modules I have written in XEmacs (presumably as packages). * pg.el is a socket-level interface to the PostgreSQL RDBMS. It is a programmer's API, which allows you to send SQL queries to the backend, and receive the results with appropriate type coercions. It probably needs more testing before bundling. pg.el will eventually be included in Emacs. <URL:http://www.chez.com/emarsden/downloads/pg.el> * babel.el is an interface to different translation engines available on Internet, such as Babelfish and SysTran. It uses w3 to submit requests to their web frontends, and formats the result. It can break large texts into several chunks and submit them sequentially. There are hooks for babel.el in recent versions of Pterodactyl Gnus, so it would be good for it to be easily available. <URL:http://www.chez.com/emarsden/downloads/babel.el> I don't know what the correct procedure for requesting inclusion is (<URL:http://www.xemacs.org/elisp.html> says "please let us know"; I hope this is the right place). I am not able to stay current with development versions of XEmacs, so I can't do the packaging myself. -- Eric Marsden It's elephants all the way down

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 25 years, 4 months

Raymond Toy

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Check the *Message-Log* buffer for messages. If you are running up sb> against the soft font-lock limit, there will be a message telling you sb> about it. What is your value of font-lock-maximum size? Size does sb> matter. I crank the size up in my .emacs, I don't know what the sb> default is. It's small enough to be annoying (IMO). It's set to 256000, the default, I think. However, I've been doing my tests on my 21K .bash_profile, which exhibits the problem. Some tests show that by the time normal-mode is called font-lock isn't turned on. For a different test file, which works as expected, by the time normal-mode is run, the buffer has already been font-locked. I need to trace through this a bit better. Ray

1 participants
0 comments

Re: Merging with GNU Emacs 25 years, 4 months

SL Baur

Gerald Gutierrez <gutier(a)intergate.bc.ca> writes in xemacs-beta(a)xemacs.org: > Hi all. > I've used GNU Emacs practically forever and have only recently tried > Lucid Emacs. I was fairly surprised by the many differences. "Lucid Emacs" died over five year ago. For better or for worse, it is XEmacs now. > Having read the FAQ file regarding the merging of the two projects, > I'd like to know something more about it. I realize that this is a > touchy subject but I would only like to know a few facts. > 1) Is there discussion in place about a possible merge? No. > 2) Is there a possibility of an "XEmacs takeover" like with egcs/gcc? No. > 3) Is there a reason why XEmacs authors haven't signed over the > copyright to the FSF if their code is intended to be under the GPL? The major sticking point that caused separation was the fact that Richard was not satisfied with the way Sun handled the GPL-ization of the code they sponsored in Lucid Emacs and XEmacs. This cannot have been the real reason because the Mule code he has been adding to Emacs 20 isn't FSF copyright assigned and will never be FSF copyright assigned. Since it is entirely owned by a non-US government I sincerely doubt he has any legal recourse whatsoever in a US court should the situation change (unlike with a US corporation like Sun Microsystems) and according to what I've been told here, he doesn't have legal recourse in a Japanese court either. Since when it suits his purposes, he uses non-FSF copyright assigned code, I fail to see why I should care, so long as I am using GPL'ed code. > 4) Is GNU Emacs development still taking place, or is it again more or > less like the egcs/gcc deal where GNU Emacs is just slowing down > more and more? Yes, no. At the moment they are busy reimplementing the XEmacs redisplay engine (incompatibly of course).

2 participants
1 comments

[patch] pty98 25 years, 4 months

Neal D. Becker

I think this is a clean patch. It should work on any glibc2.1 system AFAIK. I can only test it on glibc2.1 w/pty98 support. It seems OK: The conditional code is moved to process.h. I suppose that's where it should go(?) 1. M-x shell 2. tty > /dev/pts/1 (good) 3. C-x k 4. M-x shell 5. tty > /dev/pts/1 (good) 6. M-x rename buffer *shell2* 7. M-x shell 8. tty > /dev/pts/2 (good) Index: process.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process.h,v retrieving revision 1.8 diff -u -r1.8 process.h --- process.h 1998/04/11 05:37:05 1.8 +++ process.h 1999/07/29 02:19:51 ＠＠ -134,4 +134,16 ＠＠ #endif /* emacs */ +#if defined (__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC_MINOR__ >= 1) +# define HAVE_GETPT +#endif + +#ifdef HAVE_GETPT +#define PTY_ITERATION +#define PTY_OPEN \ + if ((fd = getpt()) < 0 || grantpt (fd) < 0 || unlockpt (fd) < 0) \ + return -1; +#define PTY_TTY_NAME_SPRINTF ptsname_r (fd, pty_name, sizeof (pty_name)); +#endif + #endif /* _XEMACS_PROCESS_H_ */ Index: process-unix.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-unix.c,v retrieving revision 1.11.2.5 diff -u -r1.11.2.5 process-unix.c --- process-unix.c 1998/12/29 10:54:27 1.11.2.5 +++ process-unix.c 1999/07/29 02:20:04 ＠＠ -216,6 +216,7 ＠＠ int fd; int c; + #ifdef PTY_ITERATION PTY_ITERATION #else ＠＠ -265,7 +266,7 ＠＠ if (access (pty_name, 6) != 0) { close (fd); -#if !defined(IRIS) && !defined(__sgi) +#if !defined(IRIS) && !defined(__sgi) && !defined (HAVE_GETPT) continue; #else return -1;

2 participants
1 comments

21.1.4 on DU4.0e, wrong exec-directory 25 years, 4 months

Holger Bauer

Bug report: Tried to install Xemacs Version 21.1.4 on our DEC Alpha DU4.0e system. However, all architecture dependent files get installed in the right place but xemacs does not find them because exec-directory points to the ...../lib-src directory and not to the architecture dependent directory. Could not find the bug since all the configuration variables in the corresponding Makefiles are set correctly. (Yes, I could have set the exec-directory myself, but this is just to dirty ...) I am not going back to xemacs-19.16 (which I throwed away since all the available binary packages dump core on VERY large files, always have to compile myself). Holger -- ------------------------------------------------ | Holger Bauer | Univ. of Stuttgart, ITSM | | Dipl.-Ing. | 70550 Stuttgart, Germany | | phone +49.711.685-3543, FAX +49.711.685-3280 | | http://www.itsm.uni-stuttgart.de/staff/bauer/ | ------------------------------------------------ "Experience comes from bad judgment" Mark Twain

1 participants
0 comments

Re: BUG REPORT: BBDB package is outdated :( 25 years, 4 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > Daniel Pittman <daniel(a)danann.net> writes: >> The current maintainer release is 2.00.06 (or possibly higher). This >> release has corrected this problem. >> >> Would it be possible to see the updated release installed as a package? > Bomb Colin's mailbox. I've given up on this issue long ago ;-) No! The blame is solely mine.

1 participants
0 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 July 1999