October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: DLL support, Re: Emacs' Future 26 years, 1 month

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > Hmmm.. Somebody is just contributing a whole new DLL support module to > > XEmacs. It would be a pity that if for once there is effort going on to > > keep the two more or less in line the XEmacs side would screw it up. > > > > IMHO this a major reason to stay with the old method for XEmacs or > > alternatively that the new implementation be sent to RMS for inclusion > > in stead. > > I disagree with this reasoning. With all due respect to Bill's worthy > contribution of cross-platform low-level DLL code, the new elisp-level > code looked better and more polished than anything we had before. > > Perhaps J. Kean Johnston would be prepared to argue with Stallman over > this, but given his bad experiences a few messages before, I doubt it. Once we get everything polished up, I can do the arguing with stallman. -Bill P.

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 26 years, 1 month

SL Baur

Richard Coleman <coleman(a)math.gatech.edu> writes in xemacs-beta(a)xemacs.org: >> > They gained a short-term advantage by not asking contributors for >> > legal papers, the way I do; that endangers the ability to enforce the >> > GPL for XEmacs.[1] >> > >> > Please do not help them win this rivalry. If you don't want to help >> > me, at least please don't urge people to join their camp. > Oh, how the might have fallen! He's sent that message to many people over the time I've been XEmacs maintainer. ... > The whole situation is a damn shame, really. Yes. Sigh. Footnotes: [1] Copyright assignment papers or not, I don't know of anyone "in the XEmacs camp" who has any desire whatsoever to endanger the GPL status of XEmacs. As far as I'm concerned un-GPLing XEmacs would have to occur over my dead body.

2 participants
1 comments

Re: DLL support, Re: Emacs' Future 26 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hmmm.. Somebody is just contributing a whole new DLL support module > to XEmacs. It would be a pity that if for once there is effort going > on to keep the two more or less in line the XEmacs side would screw > it up. > > IMHO this a major reason to stay with the old method for XEmacs or > alternatively that the new implementation be sent to RMS for > inclusion in stead. I disagree with this reasoning. With all due respect to Bill's worthy contribution of cross-platform low-level DLL code, the new elisp-level code looked better and more polished than anything we had before. Perhaps J. Kean Johnston would be prepared to argue with Stallman over this, but given his bad experiences a few messages before, I doubt it. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- I'm a Lisp variable -- bind me!

1 participants
0 comments

Re: DLL support, Re: Emacs' Future 26 years, 1 month

William M. Perry

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Jan Vroonhof writes: > > The following message is a courtesy copy of an article > > that has been posted to comp.emacs as well. > > > > Dave Love <d.love(a)dl.ac.uk> writes: > > > > > -- is still expected to happen at some stage (says Handa). Oh, and > > > 20.5 should support dynamic loading of object files consistently with > > > XEmacs' implementation -- Bill Perry be praised, as always. > > > > Hmmm.. Somebody is just contributing a whole new DLL support module to > > XEmacs. It would be a pity that if for once there is effort going on > > to keep the two more or less in line the XEmacs side would screw it > > up. > > If the new method is code, use it. The DLL code is new enough that > almost nothing is using it. So this is the time to make radical changes, > before historical usage sets everything in stone. RMS would gladly hang > a boat anchor around our necks whenever he can, so ignore him. > Absolutely do not condition acceptance of code on whether RMS accepts it. > XEmacs exists today because people got sick of arguing with him. Forget > compatibility with GNU emacs, make it insanely great. agreed - the only reason RMS is putting dll support into Emacs is because I wheedled him into it and he thinks he must have this feature to 'compete' with XEmacs. So let's make it as good as we can. -Bill P.

1 participants
0 comments

Re: XEmacs 21.0-pre15-pre4/21.2-beta3-pre2 26 years, 1 month

SL Baur

Glynn Clements <glynn(a)sensei.co.uk> writes in xemacs-beta(a)xemacs.org: > SL Baur wrote: >> I've committed new versions of XEmacs to both release trees. > I haven't been able to update via CVS since Poitou. > cvs update -dP -r r21-0b58 > says `no such tag r21-0b58', while just > cvs update -dP > doesn't update anything. > Should this work? No. I haven't made 21.0-b58 AKA 21.0-pre15 AKA "Pyrenean" yet. The `cvs update -dP' should work, I believe.

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 26 years, 1 month

Richard Coleman

> > They gained a short-term advantage by not asking contributors for > > legal papers, the way I do; that endangers the ability to enforce the > > GPL for XEmacs. > > > > Please do not help them win this rivalry. If you don't want to help > > me, at least please don't urge people to join their camp. Oh, how the might have fallen! There was a time when I greatly respected RMS. But with every battle he fights, I lose respect for him. After seeing how he has treated the XEmacs developers, seeing the lignux debacle, seeing the gcc/egcs fight, I must conclude that the FSF and RMS will becoming increasingly irrelevant amoung free software developers. I used to believe that RMS was for free software. Now I believe he is only for free software that he completely controls. The whole situation is a damn shame, really. -- Richard Coleman coleman(a)math.gatech.edu

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Aki Vehtari

"Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> I think the only reason that we don't get more complaints Hrvoje> in c.x.e. is that people don't *notice* this thing. I have noticed this thing, but until now I have thought, that I have made the mistake. I have several times been annoyed by this and couple times I have lost some data. I think that current behaviour is somewhat confusing... Ave

1 participants
0 comments

Re: Package build error in "Pyrenean-pre4" 26 years, 1 month

SL Baur

Paul Bibilo <peb(a)delcam.com> writes in xemacs-beta(a)xemacs.org: > I CVS updated everything, removed all my .elc's, and rebuilt > everything with a non-mule XEmacs. > I had problems building the following package files. > Compiling /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/comm/mew/mew/mew-lang-jp.el... > While compiling toplevel forms in file /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/comm/mew/mew/mew-lang-jp.el: > !! Invalid read syntax (("#")) > Done There be Japanese in that file. > /devdisk/d54man/gnu/xemacs-beta/xemacs-21/i62-r4k/src/xemacs -batch -vanilla \ > -eval "(insert-file-contents \"mew/info/mew.texi\")" \ > -l ./hack-mew-jis.texi.el \ > -l texinfmt -f texinfo-format-buffer \ > -eval '(setq file-coding-system (quote iso-2022-7))' \ > -eval '(save-buffer 0)' > Formatting Info file... > Formatting Info file: mew.jis.info > Converting *scratch* to Info format... > Removing trailing whitespace from Info buffer... > Formatting: Mew $B%^%K%e%"%k ... > ＠b$7$ is not handled by texinfo > xemacs exiting. > make[2]: *** [mew.jis.info] Error 255 > make[2]: Leaving directory `/tmp_mnt/devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/comm/mew' There be Japanese in that file. These should be fixed today. > make[2]: Entering directory `/tmp_mnt/devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/prog/ediff' > /devdisk/d54man/gnu/xemacs-beta/xemacs-21/i62-r4k/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- pcl-cvs dired xemacs-base -- ediff-diff.el ... > While compiling toplevel forms in file /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/prog/ediff/ediff-diff.el: > !! File error (("Cannot open load file" "cookie")) > Done The pcl-cvs dependency needs to be replaced with a dependency on elib. ... > While compiling toplevel forms in file /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/prog/ediff/ediff-merg.el: > !! File error (("Cannot open load file" "cookie")) > Done Same problem. ... > While compiling toplevel forms in file /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/prog/ediff/ediff-mult.el: > !! File error (("Cannot open load file" "cookie")) > Done Same problem. ... > While compiling toplevel forms in file /devdisk/d54man/gnu/xemacs-beta/xemacs-21/xemacs-packages/prog/ediff/ediff-ptch.el: > !! File error (("Cannot open load file" "cookie")) > Done Same problem. ... This should be fixed shortly. > I expect the mew problem is becuase I don't have a mule-aware xemacs, Yup. > but I thought we were supposed to be able to build this stuff anyway > now, or at least not have it try if it can't. Yup. Mule stuffs are supposed to be ignored and are for the most part. Mew packaging is new. > I'm not sure about the second problem though. If I do a (load > "cookie") in a running xemacs it comes back t, but is having problems > building the ediff package. Ideas ? cookie.el and the rest of elib got moved out of pcl-cvs and put in its own package. The dependencies of ediff were not updated. They are now. I'm not making new package kits because these are build fixes. They have been committed to CVS. Please do a cvs update in comm/mew and prog/ediff and things should work a bit better.

1 participants
0 comments

xemacs-21.0-b57 build success on DUNIX 4.0D 26 years, 1 month

Steve Carney

I'm not on xemacs-beta, please include me on replies. Just to ensure that XEmacs is still working on DUNIX, I built xemacs-21.0-b57 on DUNIX 4.0D without any problems. The attached patch cleans up some warning messages that I noticed. What happened to advice, comint, and rsz-minibuf? Steve --- gifrlib.h.dist Tue Aug 11 14:54:06 1998 +++ gifrlib.h Mon Oct 12 15:51:13 1998 ＠＠ -167,15 +167,15 ＠＠ /* This is the in-core version of an extension record */ typedef struct { - int ByteCount; - char *Bytes; /* on malloc(3) heap */ + int ByteCount; + GifByteType *Bytes; /* on malloc(3) heap */ } ExtensionBlock; /* This holds an image header, its unpacked raster bits, and extensions */ typedef struct SavedImage { GifImageDesc ImageDesc; - char *RasterBits; /* on malloc(3) heap */ + GifPixelType *RasterBits; /* on malloc(3) heap */ int Function; int ExtensionBlockCount; --- dgif_lib.c.dist Tue Aug 11 14:54:02 1998 +++ dgif_lib.c Mon Oct 12 15:52:56 1998 ＠＠ -110,7 +110,7 ＠＠ /* The GIF Version number is ignored at this time. Maybe we should do */ /* something more useful with it. */ Buf[GIF_STAMP_LEN] = 0; - if (strncmp(GIF_STAMP, Buf, GIF_VERSION_POS) != 0) { + if (strncmp(GIF_STAMP, (const char *) Buf, GIF_VERSION_POS) != 0) { GifInternError(GifFile, D_GIF_ERR_NOT_GIF_FILE); } ＠＠ -856,7 +856,7 ＠＠ CopyFrom->ImageDesc.ColorMap->Colors); /* next, the raster */ - sp->RasterBits = (char *)malloc(sizeof(GifPixelType) + sp->RasterBits = (GifPixelType*)malloc(sizeof(GifPixelType) * CopyFrom->ImageDesc.Height * CopyFrom->ImageDesc.Width); memcpy(sp->RasterBits, --- emacs.c.dist Sat Sep 5 20:11:26 1998 +++ emacs.c Mon Oct 12 15:37:42 1998 ＠＠ -2520,7 +2520,7 ＠＠ GET_C_CHARPTR_INT_FILENAME_DATA_ALLOCA (path, newpath); - len = strlen (newpath); + len = strlen ((const char *) newpath); /* #### Does this make sense? It certainly does for decode_env_path(), but it looks dubious here. Does any code depend on decode_path("") returning nil instead of an empty

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Didier Verna

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > The behavior is still logical. Maybe it is logical with respect to the knowledge you have of the technical details of the ring implementation. How many users do you think have this knowledge, and how many of them do you think should know the technical details to be "allowed" to use XEmacs ? > What you are describing is user ignorance. So what !? All new users of XEmacs begin with being "ignorant". Now if you have to be an _experimented_ user to begin finding things logical, then I can assure you that the number of new users is not going to increase by a lot in the future. > That doesn't mean Emacs should be tailored to your ignorance. Neither to your ignorance or lack of interest in ergonomics concerns. beginning-of-buffer and end-of-buffer are commands to move in the buffer. The other commands like next-line previous-line and even BEGINNING-OF-line and END-OF-line preserve the mark, but not those 2 ones. I admit that a different behavior might be usefull in the case of long moves, but I don't think this should be the default. If *you* want a different behavior at a certain time, *you* type more stuff to get what you want. Not the other way around. Being experimented means knowing which "more stuff" to type, not the other way around. > Or they would M-< C-x C-x C-u C-SPC which achieves the same result. Ahah !! No, really Kyle, I hardly believe you can seriously raise this argument. You might have forgotten a smiley or something ! I can image the manual or the tutorial about this: | XEmacs provides commands to move in a buffer. The most important ones are: | - C-f (forward-char) | - C-b (backward-char) | - C-n (next-line) | - C-p (previous-line) | - C-a (beginning-of-line) | - C-e (end-of-line) | - M-< (beginning-of-buffer) | - M-> (end-of-buffer) | | [ ... ] | | After you have set the mark with C-SPACE, you can move around in the buffer | with the functions detailed above to select a region. Those functions | preserve the mark. | | Note: M-< and M-> are exceptions. If you want to preserve the mark, please | type M-< C-x C-x C-u C-SPC or M-> C-x C-x C-u C-SPC And then the reader's reaction: "this software is brain damadged". And he will be right. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

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 October 1998