August 2000 - XEmacs-Beta - XEmacs Mailing List Archives

pcl-cvs describe-mode 24 years, 3 months

Charles G Waldman

It sure would be nice if `C-h m' in cvs-mode showed the keymap, especially with some of the rather non-obvious key bindings in that mode (M-DEL for `remove all marks', `O' for `update', etc). Most other `civilized' modes show the key bindings when you do `C-h m'. What's different about PCL-CVS? Is it because we're using that ikky `easy-mmode'? Or maybe it's because pcl-cvs is a derived mode, derived from fundamental-mode. In any case it's not very user-friendly behavior.

1 participants
0 comments

Re: Sourceforge account 24 years, 3 months

Adrian Aichner

>>>>> "Andreas" == Andreas Jaeger <aj(a)suse.de> writes: Andreas> Can you add me also, please? Andreas> I'm ajaeger＠sourceforge... Hi Andreas, you have been added as an xemacs developer with admin rights. cron will have to run before you get all the access. Let me know if you can't get access by same time tomorrow. Enjoy! Adrian Andreas> Andreas Andreas> -- Andreas> Andreas Jaeger Andreas> SuSE Labs aj(a)suse.de Andreas> private aj(a)arthur.inka.de Andreas> http://www.suse.de/~aj

1 participants
0 comments

Re: pcl-cvs requires mule 24 years, 3 months

Andreas Jaeger

>>>>> Martin Buchholz writes: >>>>> "Y" == Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: Y> I think it's fixed in CVS. Y> It seems Andreas is very busy lately so you might need to Y> wait for a while. > Yes. Andreas has announced that he won't have as much time for > maintaining xemacs-packages as we likes, so his job is available for > any interested volunteer. Yes, unfortunatly I'm busy with other stuff. > A smaller (but still big) task would be simply organizing the next > package sumo, to go with xemacs-21.1.12. Volunteers? I'll try to do it this week. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.inka.de http://www.suse.de/~aj

1 participants
0 comments

Re: Running a free software project 24 years, 3 months

Ben Wing

also on xemacs-beta now. Andy Piper wrote: > > At 05:14 AM 8/3/00 -0700, Ben Wing wrote: > >1. it looks like the internal sizing code is good, but what needs to be > >fixed is > >communication between frame and widget. the frame should automatically resize > >to the root widget's size, and when the root widget later on resizes, the > >frame > >should follow. currently in `make-search-dialog' you have a bunch of kludgy > >sizes in because of this problem. > > So we require explicit root sizing right now - XEmacs has a whole bunch of > similar limits for example? xemacs explicit policy is not to have these. > and we are already doing better than default windows layout > IIRC. So I agree this is a feature that should be added at some point but > disagree that this is a 21.2 + dialogs showstopper. this is important to fix because it is hard to create dialogs that are portable on x and windows if you have to put arbitrary sizes in. > > >2. there is no :initial-focus keyword. actually, i added this in my > >about-to-be-integrated changes, but it doesn't do anything. what it should do > >is specify the widget that gets the focus when the dialog first starts > >up. When > >no widget has this keyword, currently none have the focus, and the keys > >actually > >go to the frame below [where they get doubled!]. instead, if no widget has > >:initial-focus, then some widget should get it. what about this? this is the single biggest missing feature making dialogs not usable currently. i do hope you will make it a priority. i tried to look into it myself but i am still extremely unclear on how widget instantiation/layout/property setting works. if you could take a few hours and write some docs on just this section, it would really really help me. > you need to add a "focusable" > >property to each widget class indicating whether it can get the focus. > > Sounds reasonable. Is this the same as :active? no. this is a per-class thing; i guess mostly it just needs to exclude static text/images. btw is :active implemented? > > >3. keyboard accelerator specs don't work quite right. it seems that the X > >version of the widgets does accept %_ and munge in the button strings, but the > >MSW code does nothing -- you have to put &'s in to get anything. I also > >notice > > Surely you mean the other way round, the X code doesn't display > accelerators but rather %_ instead. I thought you were fixing this? i did fix it in x. but the windows code has never handled this properly. > > >you have an `accelerator' keyword, which I'm not sure what it does. This > >needs > >to be cleaned up and made consistent, so that all and anything can get an > > Not my keyword, its inherited from the menubar code. I don't do anything > with it IIRC. But yes this should be fixed. > > >accelerator spec in it [including static text -- frequently, static text > >contains the accelerator that corresponds to the edit field or whatever that's > >next to it]. now, with some recent changes i made [calling > >IsDialogMessage[] in > >strategic places], you CAN traverse between widgets using TAB, up/down, etc. > >[although perhaps not completely correctly according to the way things work > >standardly, because there are GROUP and TABSTOP and such attributes which you > >give no control over] so it's possible that if you just get the accelerator > >munging code consistent so that the > >nice underlines get displayed, accelerators with alt will just work. but > >maybe > >not; it might require more work. > > I thought that the windows implementation of these was pretty primitive - > isn't it just the order they are created. Should tab control be merged with > focus? i don't understand what you mean. > > >4. hitting ESC doesn't kill a dialog box, like it should. > > Ok. > > >By the way, Andy, ultimately I'd like to see us moving towards a new object > >called a glyph-instantiator. i don't know what docs i've written up and > >sent to > >you; you probably haven't gotten them, and i'll try to locate them. but the > > I haven't received anything. > > [glyph-instantiator stuff deleted] > > This sounds reasonable but I strongly recommend that we do not do it for > 21.2. The update stuff you talk about is already implemented hmm, i do see now that you removed set-image-instance-property. that looks good. does it handle progress-glyph update efficiently? > so, as always, > I would like to stabilize the code and do a release rather than a rewrite. > At the very most we [you] should write the external representation > converting to vectors internally. > > andy > -------------------------------------------------------------- > Dr Andy Piper > Principal Consultant, BEA Systems Ltd -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/

2 participants
1 comments

Re: evil hack in buffer.c, and need for internal docs onwidgetcode 24 years, 3 months

Ben Wing

Andy Piper wrote: > > At 01:16 AM 8/8/00 -0700, Ben Wing wrote: > >changing the buffer order is simply an internal state change. the only reason > >it affects redisplay is because of the fact that you choose to make the tab > >widget order dependent on the buffer order. redisplay should be triggered > >*only* as a result of the tab widget instantiator changing. if the tab > >widgets > >are off, or implemented in a different fashion, it no longer makes any > >sense to > >force a frame redisplay just because of the buffer order change. that's why > >your addition doesn't belong. > > Ok. But this still does not fit with your redisplay change - i.e. if you > put anything else on that hook you may get screwed. Nevertheless I will > take it out. > > > > >calling record-buffer has nothing inherently to do with redisplay. by > > adding > > It does when you add a redisplay hook that is based on changes to the > buffer-alist. > > > > >this special kludge for the tab widgets, you are just papering over > > > >another bug > > > >elsewhere, which is that the changes to the tab widgets aren't properly > > > >getting > > > >noticed > > There was no bug, as I say it was an ideological change. > > >btw you commented out my defer-window-pos code; why? > > Because I wasn't sure whether this was obscuring other display-related > problems. IMHO it shouldn't be necessary and is a window-system specific > change. As you can see it left the code in and will re-enable it by default > when things have settled down. > > >please try to document what's currently there and not wait any longer. if you > >could do so, i could help you fix the various widget bugs. as it is, the code > >is impenetrable to me. > > Given time, crashes take priority. But please give me some indication that > you are not simply going to rewrite things yet again. no, i'm planning on doing code review and bug fixing. > > >btw you never responded to my message outlining changes i think necessary for > >dialog boxes to work. what do you think of it? > > Give me a chance, I had 424 mail messages after 3 days holiday and only a > 1.25 hr train journey in which to answer them all. > > andy > -------------------------------------------------------------- > Dr Andy Piper > Principal Consultant, BEA Systems Ltd -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/

1 participants
0 comments

bug in portable dumper with mingw 24 years, 3 months

Andrew Begel

I tried building today (with a newly checked out source tree) for i586-pc-mingw32. I turned on the portable dumper. Instead of temacs.exe being built, the first thing built was xemacs.exe (interesting, but I'll go with the flow). However, when the next step of the compiler tried to run xemacs.exe to load update-elc.el, it died. cd ./src && make all make[1]: Entering directory `/xemacs/xemacs-21.2/src' gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow -Wl,-export-dynamic -I/xemacs/xemacs-21.2/src -o xemacs 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 tests.o filelock.o ntplay.o nt.o ntheap.o ntproc.o dired-msw.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o file-coding.o realpath.o getloadavg.o inline.o sysdll.o emodules.o process-nt.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 imgproc.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 widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o free-hook.o vm-limit.o dump-id.c -ltiff -ljpeg -lz -mno-cygwin -mwindows -lwinmm -lwsock32 -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lwinspool ./xemacs -nd -batch -l /xemacs/xemacs-21.2/src/../lisp/update-elc.el make[1]: *** [update-elc.stamp] Error 3 make[1]: Leaving directory `/xemacs/xemacs-21.2/src' make: *** [src] Error 2 [18:57:19] /xemacs/xemacs-21.2> rm temacs.exe Here's the gdb backtrace. It looks like malloc didn't work: [18:58:20] /xemacs/xemacs-21.2> gdb -nw ./src/xemacs GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r -nd -batch -l /xemacs/xemacs-21.2/lisp/update-elc.el Starting program: /xemacs/xemacs-21.2/./src/xemacs.exe -nd -batch -l /xemacs/xemacs-21.2/lisp/update -elc.el Program received signal SIGTRAP, Trace/breakpoint trap. 0x77f9f9e0 in ?? () (gdb) where #0 0x77f9f9e0 in ?? () #1 0x44ee19 in signal_1 (sig=0, data=52467728) at eval.c:1879 #2 0x457676 in signal_simple_error ( reason=0x548940 "Internal error: lstream has no writer", frob=52457472) at eval.c:2052 #3 0x548a44 in Lstream_flush_out (lstr=0x3207000) at lstream.c:288 #4 0x54a06b in Lstream_flush (lstr=0x3207000) at lstream.c:371 #5 0x43d145 in emacs_doprnt_string_va ( format_nonreloc=0x4030d0 "%s\nKilling some buffers may delay running out of memory.\nHowever, ce rtainly by the time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.", format_reloc=0, format_length=-1, vargs=0x2b0fd78 "E\024\\") at doprnt.c:847 #6 0x456174 in warn_when_safe (class=0, level=0, fmt=0x4030d0 "%s\nKilling some buffers may delay running out of memory.\nHowever, certainly by t he time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.") at eval.c:5305 #7 0x409d65 in malloc_warning ( str=0x5c14c8 "Warning: past 85% of memory limit") at alloc.c:214 #8 0x5c1680 in check_memory_limits () at vm-limit.c:90 #9 0x5bf914 in morecore (size=4096) at gmalloc.c:439 #10 0x5bfd33 in malloc (size=4096) at gmalloc.c:659 #11 0x5bfba9 in malloc (size=2036) at gmalloc.c:603 #12 0x405f2a in make_string_nocopy (contents=0x5a38cc "nil", length=3) ---Type <return> to continue, or q <return> to quit--- at alloc.c:353 #13 0x5a3958 in init_symbols_once_early () at symbols.c:3169 #14 0x447fa7 in xemacs_21_2_b35_i586_pc_mingw32 (argc=5, argv=0x2b19418, envp=0x2b150b0, restart=0) at emacs.c:1146 #15 0x44bd58 in main (argc=5, argv=0x2b19418, envp=0x2b150b0) at emacs.c:2537 (gdb)

1 participants
0 comments

Re: crash in gnus 24 years, 3 months

Michael Harnois

On Mon, 07 Aug 2000 22:26:42 +0100, Andy Piper <andy(a)xemacs.org> said: > I think this has been reported and I am composing a fix. andy > At 11:23 AM 8/5/00 -0500, Michael Harnois wrote: >> Came home from two weeks of vacation, updated 21.2 from CVS and >> get this when reading mail in gnus: So happy you're not decomposing. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.

1 participants
0 comments

bug in loading files from temacs command line 24 years, 3 months

Andrew Begel

Under Win2k, I compiled a just-checked-out Xemacs 21.2 under mingw32 (./configure i586-pc-mingw32). After making a few adjustments to make_arg_list_1 in emacs.c to define Qdll_filename_encoding to be Qnative, and then commenting out the extra definition of getloadavg in nt.c, Xemacs actually compiles. Unfortunately, temacs won't load files with unix-style filenames, so the build process fails. Temacs wants windows-style filenames only. I'm running this all from bash under cygwin 1.1.2. This feels like a bug, somewhere in the code that parses the command line arguments, to me. I added the Qdll_filename_encoding declaration (which wasn't in the code and caused it to fail to compile). Lisp_Object Qdll_filename_encoding; static Lisp_Object make_arg_list_1 (int argc, Extbyte **argv, int skip_args) { Lisp_Object result = Qnil; REGISTER int i; Qdll_filename_encoding = Qnative; for (i = argc - 1; i >= 0; i--) { if (i == 0 || i > skip_args) { #ifdef WIN32_NATIVE if (i == 0) { /* Do not trust to what crt0 has stuffed into argv[0] */ char full_exe_path[MAX_PATH]; Lisp_Object fullpath; GetModuleFileName (NULL, full_exe_path, MAX_PATH); fullpath = build_ext_string (full_exe_path, Qmswindows_tstr); result = Fcons (fullpath, result); #if defined(HAVE_SHLIB) { Extbyte *fullpathext; LISP_STRING_TO_EXTERNAL (fullpath, fullpathext, Qdll_filename_encoding); (void) dll_init (fullpathext); } #endif } else #endif result = Fcons (build_ext_string (argv[i], Qcommand_argument_encoding), result); } } return result; } I think that last build_ext_string perhaps might be converting the pathnames if it see's em, but it's not working... andrew

4 participants
3 comments

AW: XEmacs 21.1 (patch 12) "Channel Islands" Has Been Released 24 years, 3 months

Joachim Orth

hi there, please remove flabes(a)eurem.de from Your mailinglist since he left our company tia Joachim Orth Admin -----Ursprüngliche Nachricht----- Von: owner-xemacs-announce(a)xemacs.org [mailto:owner-xemacs-announce＠xemacs.org]Im Auftrag von Vin Shelton Gesendet: Samstag, 5. August 2000 17:53 An: xemacs-announce(a)xemacs.org Betreff: XEmacs 21.1 (patch 12) "Channel Islands" Has Been Released XEmacs 21.1.12 "Channel Islands" is available from ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.12.tar.gz -or- ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.12.tar.bz2 These are the core distribution without bytecompiled lisp and without processed texinfo manuals. (You only need one of these two files: the .bz2 file has been compressed with bzip2 and is therefore smaller than the .gz file, which has been compressed with gzip.) If you are on a fast machine with a possibly slow connection to the FTP site, one of these tarballs is all you need for the base XEmacs. Untar it, run 'configure', then run `make' and `make install'. Note that you will still need the XEmacs packages. Please see the file README.packages in the root of the source directory. ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.12-elc.tar.gz This tarball is the bytecompiled lisp of all the lisp (.el) files included in the above tarball. Bytecompiling all of XEmacs Lisp included in this tarball takes only a few minutes on a machine with any speed at all, so this file is not strictly necessary. ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.12-info.tar.gz This tarball is the processed texinfo manuals. If you have makeinfo installed and your machine has any kind of decent speed, it is quicker to run `make info' from the toplevel and rebuild it yourself than it is to download and untar it. Note that GNU texinfo-3.12 or later is required. A patch to upgrade from XEmacs 21.1.11 is also available: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.11-21.1.12.patch.gz After applying the patch, please run the command 'touch configure' in order to make sure 'configure' is newer than 'configure.in'. XEmacs-21.1 is the stable branch of XEmacs. As such, only bugfix submissions are allowed into these releases. The major fix in this release allows a user to fetch the package list from xemacs.org or a mirror site (see Adrian Aichner's fix below). Here is the list of the significant bugfixes in this release: From: "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> Subject: Patch: NAS_LITTLE_ENDIAN [was: NAS related source code error?] <URL: http://www.xemacs.org/list-archives/xemacs-patches/200008/msg00016.html> From: Torsten Duwe <duwe(a)caldera.de> Subject: Security patches to 21.1.10 <URL: http://www.xemacs.org/list-archives/xemacs-patches/200007/msg00123.html> From: "Alastair J. Houghton" <ajhoughton(a)lineone.net> Subject: [EXPERIMENTAL PATCH] Make NT heap death more informative. <URL: http://www.xemacs.org/list-archives/xemacs-patches/200007/msg00130.html> From: Adrian Aichner <aichner(a)ecf.teradyne.com> Subject: [PATCH 21.1] fix `insert-file-contents-literally' for `package-get'. <URL: http://www.xemacs.org/list-archives/xemacs-patches/200007/msg00134.html> From: Gunnar Evermann <ge204(a)eng.cam.ac.uk> Subject: [21.1 only] fix gdbinit's pobj <URL: http://www.xemacs.org/list-archives/xemacs-patches/200007/msg00136.html> The 21.1.x series of releases is being named for US National Parks. Channel Islands National Park is located off the southern California coast. For more information see: <URL: http://www.nps.gov/chis/>. Vin Shelton

1 participants
0 comments

Mingw32 build problem with getloadavg 24 years, 3 months

Andrew Begel

I just checked out the latest XEmacs 21.2 from CVS and am trying to compile it for Mingw (./configure i586-pc-mingw32) under Win2k. When I link temacs, I get this error: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow -Wl,-export-dynamic -I/cygdrive/c/xemacs/xemacs-21.2/src -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 tests.o filelock.o ntplay.o nt.o ntheap.o ntproc.o dired-msw.o unexcw.o crollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o file-coding.o realpath.o getloadavg.o inline.o sysdll.o emodules.o process-nt.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o eneral.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.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 sheap.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o free-hook.o vm-limit.o -ltiff -ljpeg -lz -mno-cygwin -mwindows -lwinmm -lwsock32 -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lwinspool getloadavg.o: In function `getloadavg': /cygdrive/c/xemacs/xemacs-21.2/src/getloadavg.c:493: multiple definition of `getloadavg' nt.o:/cygdrive/c/xemacs/xemacs-21.2/src/nt.c:75: first defined here collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make[1]: Leaving directory `/cygdrive/c/xemacs/xemacs-21.2/src' make: *** [src] Error 2 [16:11:42] /xemacs/xemacs-21.2> xe Which definition is better? The one in nt.c is quite small, whereas the one in getloadavg.c seems to be doing quite a bit more. I commented out the small one in nt.c without seemingly ill effects. Andrew

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 August 2000