January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > I dislike the idea of our packages avoiding using our new features > because of compatibility with old XEmacsen that need to be run with > these very same packages. Note that "old" here means "the latest released version". The packages need to target at the latest released, IMO. > If the package system can't new packages > requiring new features, Not without including a special "packages-for-beta" directory. That would in itself be a good thing. However it would require more management manpower to do that and we are critically short on that. > then the package system needs fixing. How true. The package system needs dependencies so one can have a "depends on XEmacs 21.2.26 and up". Jan

1 participants
0 comments

--pdump on HP-UX 11.0 24 years, 3 months

Marcus Thiessel

I remember a post from Hrvoje mentioning the same behaviour. When I use --pdump the build process aborts leaving a xemacs.dmp file and a runnable temacs behind (which seems most like xemacs). I thought this have been fixed. My question is what should be the expected behaviour (I am going to fix it for HP-UX 11.0). thiessel-:src > make cc -Ae -O -L/usr/contrib/lib -L/usr/local/lib -L/usr/ccs/lib -L/usr/dt/lib -L/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6 -L/usr/contrib/X11R6/lib -Wl,-E -o temacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o debug.o unexhp9k800.o tooltalk.o dragdrop.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-motif.o mule-canna.o getloadavg.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgpr! oc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o lastfile.o gmalloc.o vm-limit.o ralloc.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lXm -lcanna -lRKC -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lDtSvc -ltt -lXmu -lXt -lXext -lX11 -lSM -lICE -ldld -ltermcap -lm EMACSBOOTSTRAPLOADPATH="/ux/xemacs-21.2.26/src/../lisp/:/ux/xemacs-21.2.26" EMACSBOOTSTRAPMODULEPATH="/ux/xemacs-21.2.26/src/../modules/:/ux/xemacs-21.2.26" ./temacs -batch -l /ux/xemacs-21.2.26/src/../lisp/update-elc.el Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /ux/xemacs-21.2.26/lisp/dumped-lisp.el... Loading /ux/packages/lisp/ediff/dumped-lisp.el... Loading /ux/packages/lisp/efs/dumped-lisp.el... Loading /ux/packages/lisp/vc/dumped-lisp.el... Loading /ux/packages/lisp/vm/dumped-lisp.el... rm -f ../lib-src/DOC; \ EMACSBOOTSTRAPLOADPATH="/ux/xemacs-21.2.26/src/../lisp/:/ux/xemacs-21.2.26" EMACSBOOTSTRAPMODULEPATH="/ux/xemacs-21.2.26/src/../modules/:/ux/xemacs-21.2.26" ./temacs -batch -l /ux/xemacs-21.2.26/src/../lisp/make-docfile.el -- \ -o ../lib-src/DOC -d /ux/xemacs-21.2.26/src -i ../lib-src/../site-packages \ abbrev.c alloc.c blocktype.c buffer.c bytecode.c callint.c callproc.c casefiddle.c casetab.c chartab.c cmdloop.c cmds.c console.c console-stream.c data.c device.c dired.c doc.c doprnt.c dynarr.c editfns.c elhash.c emacs.c eval.c events.c debug.c unexhp9k800.c tooltalk.c dragdrop.c dgif_lib.c gif_io.c menubar.c scrollbar.c dialog.c toolbar.c menubar-x.c scrollbar-x.c dialog-x.c toolbar-x.c gui-x.c mule.c mule-ccl.c mule-charset.c file-coding.c input-method-motif.c mule-canna.c getloadavg.c console-tty.c device-tty.c event-tty.c frame-tty.c objects-tty.c redisplay-tty.c cm.c terminfo.c event-unixoid.c database.c sysdll.c emodules.c process-unix.c event-stream.c extents.c faces.c fileio.c filemode.c floatfns.c fns.c font-lock.c frame.c general.c glyphs.c glyphs-eimage.c glyphs-widget.c gui.c gutter.c hash.c imgproc.c indent.c insdel.c intl.c keymap.c line-number.c lread.c lstream.c macros.c marker.c md5.c minibuf.c objects.c opaque.c print.c process.c profile.c! rangetab.c redisplay.c redisplay-output.c regex.c search.c select.c signal.c sound.c specifier.c strftime.c symbols.c syntax.c sysdep.c undo.c balloon_help.c balloon-x.c console-x.c device-x.c event-Xt.c frame-x.c glyphs-x.c objects-x.c redisplay-x.c select-x.c xgccache.c widget.c window.c ralloc.c Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /ux/xemacs-21.2.26/lisp/dumped-lisp.el... Loading /ux/packages/lisp/ediff/dumped-lisp.el... Loading /ux/packages/lisp/efs/dumped-lisp.el... Loading /ux/packages/lisp/vc/dumped-lisp.el... Loading /ux/packages/lisp/vm/dumped-lisp.el... Spawning make-docfile ...Spawning make-docfile ...done EMACSBOOTSTRAPLOADPATH="/ux/xemacs-21.2.26/src/../lisp/:/ux/xemacs-21.2.26" EMACSBOOTSTRAPMODULEPATH="/ux/xemacs-21.2.26/src/../modules/:/ux/xemacs-21.2.26" ./temacs -batch -l /ux/xemacs-21.2.26/src/../lisp/loadup.el dump loadup.el already loaded! xemacs exiting. *** Error exit code 255 (ignored) Testing for Lisp shadows ... Make: Cannot load ./xemacs. Stop. *** Error exit code 1 Stop.

2 participants
1 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > >> before Yoshiki's patch. The new feature of > >> `completing-read', the DEFAULT argument, cannot be relied > >> upon (because XEmacs-21.1.8 does not have it). > > Hrvoje> Sorry, I don't agree with "cannot be relied upon" part. > Hrvoje> Backward compatibility is a nice thing, but can't we > Hrvoje> just have the new version of the package support the new > Hrvoje> XEmacs? > > Forcing people who have and latest released and the latest beta > XEmacs installed to maintain two separate XEmacs packages trees > manually? Shudder! Why the shudder? It used to be normal that a novel API caused update of the actively maintained packages. The people with older Emacsen just used the older versions of packages. The package system apparently made this harder, not easier. > I agree. Packages were separates from XEmacs to ease their > evolution, right? Having them tied to a particular XEmacs is bad. > Tying them to an API version (of core lisp functionality) might be > feasible. > > Is the standards-version field of the `package-get-base''s plist > intended to be used to track API changes? I don't know. :-( Does our package system really have an active maintainer at this point? Michael, come to the rescue!

1 participants
0 comments

Re: [PATCH] Portable dumper fixes for NT 24 years, 3 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Just brought the PD up to life under NT. I see a strange glitch > though. When I dump XEmacs traditional way, zmacs-regions is set to > t. When I do it portable, it is set to nil, both when I run it > vanilla. Is this the way it works on other platforms? I've now tried it on Linux, and you're right: zmacs-region is nil with TPD.

3 participants
2 comments

Re: edit-utils 1.44 released 24 years, 3 months

Andreas Jaeger

>>>>> Martin Buchholz writes: >>>>> "AJ" == Andreas Jaeger <aj(a)suse.de> writes: AJ> I've uploaded edit-utils 1.44 to AJ> ftp.xemacs.org/pub/xemacs/beta/incoming. AJ> The file bookmarks was not usable with XEmacs 21.1.x, I've applied a AJ> quick fix from Adrian. I'd like to see a real fix soon. mb> The current situation with our stable/unstable branches is mb> problematic. XEmacs 21.1 itself may be stable, but the packages used mb> with it are in flux. As a result, nobody is even able to reproduce an mb> install of earlier releases of 21.1, because the packages have mb> changed. mb> It might be considered a matter of philosophy whether the packages are mb> separate from the XEmacs `kernel'. This is similar to the situation mb> with the Linux kernel. My feeling is that the users don't care about mb> this distinction, and would like a stable XEmacs and a development mb> XEmacs. mb> Unfortunately, the development XEmacs keeps making random changes to mb> the packages, which break the stable XEmacs. This is especially easy mb> to do, since the developers typically never run 21.1, and so might mb> write to a new API. mb> If we're serious about having a stable and unstable XEmacs series, mb> that needs to extend to the packages as well. I fear a maintenance nightmare. I would prefer to have packages that work with all versions of XEmacs. mb> In particular, this is a strong argument in favor of at moving at mb> least the core packages currently maintained by the XEmacs development mb> team back into the XEmacs tree, or some other measure to ensure true mb> stability of future stable releases. But adding packages like xemacs-base and mule-base back to the core would get my vote. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Portable dumper with union type 24 years, 3 months

Olivier Galibert

On Sun, Jan 16, 2000 at 12:22:34AM +0100, Hrvoje Niksic wrote: > This patch makes XEmacs compile with portable dumper support using > union type. Olivier, please review this -- I don't really understand > the code, I've just made the compiler happy. I hate this patch. Not because of what you wrote actually, but because it shows how sloppy I have been between void *, Lisp_Object and EMACS_INT. Ick. For now I'd say let's put it on hold, and I am going to review my code for this problem. Most of the (macro-hidden) casts are unnecessay. OG.

1 participants
0 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Adrian Aichner

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> Doing it right (following Kyle's suggestion) would in this >> particular case lead to awkward code bloat compared to the version >> before Yoshiki's patch. The new feature of `completing-read', the >> DEFAULT argument, cannot be relied upon (because XEmacs-21.1.8 does >> not have it). Hrvoje> Sorry, I don't agree with "cannot be relied upon" part. Hrvoje> Backward compatibility is a nice thing, but can't we just Hrvoje> have the new version of the package support the new Hrvoje> XEmacs? Forcing people who have and latest released and the latest beta XEmacs installed to maintain two separate XEmacs packages trees manually? Shudder! Hrvoje> I dislike the idea of our packages avoiding using our new Hrvoje> features because of compatibility with old XEmacsen that Hrvoje> need to be run with these very same packages. If the Hrvoje> package system can't new packages requiring new features, Hrvoje> then the package system needs fixing. I agree. Packages were separates from XEmacs to ease their evolution, right? Having them tied to a particular XEmacs is bad. Tying them to an API version (of core lisp functionality) might be feasible. Is the standards-version field of the `package-get-base''s plist intended to be used to track API changes? Using it one could implement functionality which allows to "download latest package of API standards-version 1.1" or "download latest package of API standards-version 1.2" What if the standards-version where to track the XEmacs release version? Like so "download latest package of XEmacs standards-version 21.1" or "download latest package of XEmacs standards-version 21.2" We would still need two separate package trees, but at least maintaining them would be easy. Actually we would need a package tree per standards-version, not necessarily per XEmacs. What do you think? Adrian

1 participants
0 comments

Re: [PATCH] Use system underline and struck thru fonts 24 years, 3 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > Not only the division line between font and face properties is > > random, it is different in Windows and in > > X. Faces should be -- eh -- homogenized? > > It isn't random, it is just not the same under X and under Windows > and under ttys. When designing an application whose API is supposed to work across window systems, I don't really see the difference between "random" and "closely modeled after X". > The differences are due to difference in these environments. That's > exactly why we should not add a bunch of face properties for fonts. Actually, the proposal goes the other way around: to add a bunch of what are now font properties to faces. One reason why we'd want to do that is for more logical support of face merging. You probably disagree, but I liked the new FSF model a lot. Another reason we might want to do that is the fact that there are few "obvious" font properties. > Let the differences be encoded in the instantiators for the face's > font specifier. This way when the next operating system comes > along, with yet another font model, we won't have to change the low > level API once again to try to make everything look the same. But the same goes the other way around, doesn't it? If we just use the face properties to construct the full outlook of a face, the code that does the construction will be window-system-specific and (mostly) invisible from the outside. So when another system comes by, we just add new device methods in C and stuff. > > Is it possible to kick fonts away form the lisp level at all? > > Fonts are not abstract enough, faces are. > > I really don't want to do this. I do, and not only for ease of use. This kind of thing is really needed for proper merging of faces. As someone who has tried to support the `:bold' property in Customize, I find the lack of existence of a font model awful. > I don't want so much abstraction that it is hard to specify a single > font, simply and exactly. Noone said this would be impossible. The way I see it, if you wanted, you could always specify a single font and leave it at that. > I don't want code that uses the existing API to be broken. Neither do I. But backward compatibility should not be hard to achieve if we have a sane low-level API to build upon.

2 participants
1 comments

vote early, vote often! (was: Slashdot Beanie Awards) 24 years, 3 months

John S. J. Anderson

>>>>> "Darryl" == Darryl Okahata <darrylo(a)sr.hp.com> writes: Darryl> Slashdot (http://slashdot.org) is taking nominations (and, Darryl> later, a vote) for various awards; one of these awards is Darryl> "Best Open Source Text Editor", and the prize is US$10,000. Darryl> I think we should nominate XEmacs. ;-) For those of you who don't religiously follow /., the voting started today, and XEmacs is indeed up for Best Open Source Text Editor. See <URL:http://slashdot.org/vote.pl>, and vote your heart. ;^)= (Also noted on xemacs.org; one of the Review Team might wish to relay this on xemacs-announce as well). john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ <URL:http://www.xemacs.org> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

1 participants
0 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 3 months

Adrian Aichner

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> I'm not sure that patch is right. The DEFAULT argument Hrvoje> didn't exist in pre-21.2 XEmacs, and this patch leaves it Hrvoje> in. That looks wrong. Hi Hrvoje, Andreas, Yoshiki! upon further examination I agree with Hrvoje. My quick patch is wrong. Doing it right (following Kyle's suggestion) would in this particular case lead to awkward code bloat compared to the version before Yoshiki's patch. The new feature of `completing-read', the DEFAULT argument, cannot be relied upon (because XEmacs-21.1.8 does not have it). Consequently the defaulting of an empty completion has to be done just as before. Only, handling a possible wrong-number-of-arguments makes the code unnecessarily hard to read and understand. I vote for reverting to the `bookmark-completing-read' version of bookmark.el revision 1.2. Please advise, Adrian Possible new version (bad, bad, bad): (defun bookmark-completing-read (prompt &optional default) "Prompting with PROMPT, read a bookmark name in completion. PROMPT will get a \": \" stuck on the end no matter what, so you probably don't want to include one yourself. Optional second arg DEFAULT is a string to return if the user enters the empty string." (bookmark-maybe-load-default-file) ; paranoia (let* ((completion-ignore-case bookmark-completion-ignore-case) (default default) (prompt (if default (concat prompt (format " (%s): " default)) (concat prompt ": "))) (str (condition-case nil (completing-read prompt bookmark-alist nil 0 nil 'bookmark-history default) (wrong-number-of-arguments (completing-read prompt bookmark-alist nil 0 nil 'bookmark-history))))) (if (string-equal "" str) (list default) (list str)))) `bookmark-completing-read' of version 1.2 of bookmark.el: (defun bookmark-completing-read (prompt &optional default) "Prompting with PROMPT, read a bookmark name in completion. PROMPT will get a \": \" stuck on the end no matter what, so you probably don't want to include one yourself. Optional second arg DEFAULT is a string to return if the user enters the empty string." (bookmark-maybe-load-default-file) ; paranoia (let* ((completion-ignore-case bookmark-completion-ignore-case) (default default) (prompt (if default (concat prompt (format " (%s): " default)) (concat prompt ": "))) (str (completing-read prompt bookmark-alist nil 0 nil 'bookmark-history))) (if (string-equal "" str) (list default) (list str)))) -- Adrian Aichner <adrian(a)xemacs.org>

4 participants
3 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 2000