From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 4 19:50:27 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA16390; Thu, 4 Jun 92 19:50:27 PDT Received: by heavens-gate.lucid.com id AA03195g; Thu, 4 Jun 92 19:39:53 PDT Received: from alpha.xerox.com by heavens-gate.lucid.com id AA03191g; Thu, 4 Jun 92 19:39:48 PDT Received: from BoonesFarm.wbst129.xerox.xns by alpha.xerox.com via XNS id <11693>; Thu, 4 Jun 1992 19:47:40 PDT X-Ns-Transport-Id: 0000AA00978F450E2DEE Date: Thu, 4 Jun 1992 19:47:28 PDT From: Marc_Rocas.WBST129@xerox.com Subject: please add me to mailing list To: bug-lucid-emacs@lucid.com Message-Id: <" 4-Jun-92 22:47:28 EDT".*.Marc_Rocas.WBST129@Xerox.com> From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 04:46:55 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA16880; Fri, 5 Jun 92 04:46:55 PDT Received: by heavens-gate.lucid.com id AA04248g; Fri, 5 Jun 92 04:29:52 PDT Received: from newton.ncsa.uiuc.edu by heavens-gate.lucid.com id AA04244g; Fri, 5 Jun 92 04:29:45 PDT Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12120 (5.65a/IDA-1.4.2 for bug-lucid-emacs@lucid.com); Fri, 5 Jun 92 06:37:50 -0500 Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI) for @newton.ncsa.uiuc.edu:jwz@lucid.com id AA03345; Fri, 5 Jun 92 06:39:02 -0700 Date: Fri, 5 Jun 92 06:39:02 -0700 From: marca@wintermute.ncsa.uiuc.edu (Marc Andreessen) Message-Id: <9206051339.AA03345@wintermute.ncsa.uiuc.edu> To: bug-lucid-emacs@lucid.com Cc: jwz@lucid.com Subject: v19 on IRIX 4.0.2 Here are some random notes after several hours of trying to port Lucid v19 to IRIX 4.0.2. These notes don't concern the IRIX config files per se; for the most part, I hacked together an s-irix4-0.h from the Epoch sources. o xfns.c (maybe_set_screen_title_format): results[] and resources[] should be static, not automatic. o sysdep.c (setpriority on line 2232): shouldn't return a value. o search.c #error is not an acceptable cpp directive; IRIX's cpp will not process the file even though that directive is never actually hit. o floatfns.c (float_error) float_error must be defined for IRIX as well as BSD. o lread.c (read_escape) '\a' is not a valid escape sequence. o ymakefile The dependencies are not reset for non-Sun platforms; this keeps unexmips.c (presumably among other files) from compiling due to dependencies on nonexistent include files. o process.c The big about 'mis;tak-+;;:' was hit. What's the deal? o data.c (%) 'remainder' should apparently be fmod. o fileio.c #include should go outside #ifdef HAVE_REALPATH/#endif because systems without realpath still need to have a value for MAXPATHLEN, at least. o buffer.c emacs.c fileio.c These three files reference Freal_path_name even when HAVE_REALPATH isn't defined. o The bit with the 'invisible' termtype (installed by putenv'ing TERM and TERMCAP) doesn't work as-is under IRIX, as apparently the TERMCAP env variable isn't recognized. I had to actually install a dummy invisible entry into /usr/lib/terminfo to get past that. o The IRIX C compiler flagged several instances of redundant '&'s in the code; I can make a list of them if someone's particularly interested. (The IRIX compiler just ignores 'em.) I don't have it working yet; temacs loads up and produces xemacs just fine, but when xemacs is run it sits and spins for a while, uses up over 12 megs of phsical memory in the process, and then dies. I did run lemacs (from the binary distribution) on a Sun4, and it looked pretty good (although there was one coredump which I didn't pursue, and then after deiconifying an edit screen at one point the X window became infinitely wide, so between those two problems I probably won't start using it regularly quite yet :-). Thanks, Marc -- Marc Andreessen Software Development Group National Center for Supercomputing Applications marca@ncsa.uiuc.edu From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 10:41:30 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17208; Fri, 5 Jun 92 10:41:30 PDT Received: by heavens-gate.lucid.com id AA05152g; Fri, 5 Jun 92 10:26:36 PDT Received: from ti.com by heavens-gate.lucid.com id AA05148g; Fri, 5 Jun 92 10:26:30 PDT Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.59/LAI-3.2) id AA19457; Fri, 5 Jun 92 12:34:47 CDT Received: from hc.ti.com (sunspot) by tilde.csc.ti.com id AA09522; Fri, 5 Jun 1992 12:34:00 -0500 Received: from ninja.hc.ti.com by hc.ti.com (4.1/SMI-4.1) id AA18510; Fri, 5 Jun 92 12:34:38 CDT Received: by ninja.hc.ti.com (4.1/SMI-4.1) id AA19412; Fri, 5 Jun 92 12:34:37 CDT Date: Fri, 5 Jun 92 12:34:37 CDT Message-Id: <9206051734.AA19412@ninja.hc.ti.com> From: Paul Fuqua Sender: pf@hc.ti.com To: bug-lucid-emacs@lucid.com Subject: Can't Build with OLIT These are not real important problems, since I have a Sun and the precompiled binary version works, but the summary is that I can't build lemacs-19.1 using OLIT. 1. It isn't clear enough that one *must* choose OLIT, Motif, and/or Lucid. Since I don't care about any of them (I generally use bare X11R5, sometimes InterViews), I tried doing without. No go. I don't have Motif or Lucid, so I'm stuck with using OLIT. 2. src/ymakefile, and thus src/makefile, doesn't have an all: target, so when "make all" causes "make -f xmakefile all", it fails. 3. gcc -traditional is really required when compiling lwlib.c, but it's tough to make that happen -- I ended up editing the Imakefile well below the "you shouldn't need to edit below here" point, because my X11R5 was built with cc. 4. src/lwlib/lwlib-Xol.c wants to include xt_extension.h, which doesn't exist. 5. The OL include files are in /usr/openwin/include, which isn't in the default include path, and the configuration files don't have a place to add it. Another edit to src/lwlib/Imakefile. 6. After all that, the link of temacs failed with ld: Undefined symbol ___main _resource_string _XtQString _XtQFontStruct _XtQFont _XtQInt _XtQBoolean _XrmCompileResourceList At this point I gave up and FTPed the precompiled version, which actually works pretty well. Paul Fuqua pf@hc.ti.com, ti-csl!pf Texas Instruments, Dallas, Texas "You get what you settle for." -- Thelma & Louise From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 12:06:28 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17331; Fri, 5 Jun 92 12:06:28 PDT Received: by heavens-gate.lucid.com id AA05501g; Fri, 5 Jun 92 11:58:16 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA05497g; Fri, 5 Jun 92 11:58:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA14870; Fri, 5 Jun 92 12:06:22 PDT Date: Fri, 5 Jun 92 12:06:22 PDT Message-Id: <9206051906.AA14870@thalidomide.lucid> From: Jamie Zawinski Sender: jwz@thalidomide To: skip@eco.twg.com Cc: bug-lucid-emacs@lucid.com Subject: Re: Sign me up! In-Reply-To: Skip Koppenhaver's message of Fri 5-Jun-92 15:03:34 EDT <9206051903.AA07591@eco.twg.com> References: <9206051903.AA07591@eco.twg.com> skip@eco.twg.com has been added to bug-lucid-emacs@lucid.com. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 12:15:12 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17355; Fri, 5 Jun 92 12:15:12 PDT Received: by heavens-gate.lucid.com id AA05471g; Fri, 5 Jun 92 11:53:58 PDT Received: from eco.twg.com by heavens-gate.lucid.com id AA05464g; Fri, 5 Jun 92 11:53:47 PDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.15 $) id AA01607; Fri, 5 Jun 92 15:01:46 -0400 Organization: The Wollongong Group, Inc., East Coast Operations Address: 2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102 Phone: 703-847-4500 (Voice); 703-847-4520 (Fax) Received: by .eco.twg.com (4.1/ECO.s-$Revision: 1.6 $) id AA07591; Fri, 5 Jun 92 15:03:34 EDT Date: Fri, 5 Jun 92 15:03:34 EDT From: skip@eco.twg.com (Skip Koppenhaver) Message-Id: <9206051903.AA07591@eco.twg.com> To: bug-lucid-emacs@lucid.com Subject: Sign me up! Reply-To: skip@eco.twg.com Please add skip@eco.twg.com to the mailing list. Thanks. From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 12:35:25 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17373; Fri, 5 Jun 92 12:35:25 PDT Received: by heavens-gate.lucid.com id AA05587g; Fri, 5 Jun 92 12:15:59 PDT Received: from eco.twg.com by heavens-gate.lucid.com id AA05583g; Fri, 5 Jun 92 12:15:50 PDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.15 $) id AA01810; Fri, 5 Jun 92 15:23:48 -0400 Organization: The Wollongong Group, Inc., East Coast Operations Address: 2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102 Phone: 703-847-4500 (Voice); 703-847-4520 (Fax) Received: by .eco.twg.com (4.1/ECO.s-$Revision: 1.6 $) id AA07664; Fri, 5 Jun 92 15:25:33 EDT Date: Fri, 5 Jun 92 15:25:33 EDT From: skip@eco.twg.com (Skip Koppenhaver) Message-Id: <9206051925.AA07664@eco.twg.com> To: bug-lucid-emacs@lucid.com Subject: Build problems Reply-To: skip@eco.twg.com I'm having problems building lemacs-19.1. I'm using SunOs 4.1.1 on a IPC with X11R5. My first problem was that src/ymakefile didn't have an "all" target so I added one, like so: all: xemacs OTHER_FILES That got me through compilation but when linking temacs I get an unresolved reference: ___main Any help would be appreciated. -- Skip Koppenhaver skip@eco.twg.com From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 12:42:34 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17386; Fri, 5 Jun 92 12:42:34 PDT Received: by heavens-gate.lucid.com id AA05607g; Fri, 5 Jun 92 12:18:21 PDT Received: from foobar.cs.Colorado.EDU by heavens-gate.lucid.com id AA05601g; Fri, 5 Jun 92 12:18:10 PDT Received: by foobar.cs.Colorado.EDU id AA17011 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Fri, 5 Jun 1992 13:26:15 -0600 Date: Fri, 5 Jun 1992 13:26:15 -0600 From: Dirk Grunwald Message-Id: <199206051926.AA17011@foobar.cs.Colorado.EDU> To: bug-lucid-emacs@lucid.com Subject: bug in modifiers On my DECstation (& most other workstations), I make CapsLock be an alias for Cntrl because I find it irritating & positioned too close to Cntrl. with the lemacs 19.1 binary, I get... emacs: Caps_Lock generates ModControl, which is nonsensical. which isn't helpful. I was using... ! remove Lock = Caps_Lock ! add Control = Caps_Lock (as documented in the xmodmap man page) but have switched it to ! Make caps lock look like control... keycode 176 = Control_L which gets past the previous message, but now dies in next_screen(). I don't know if it's releated. From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 13:02:30 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17414; Fri, 5 Jun 92 13:02:30 PDT Received: by heavens-gate.lucid.com id AA05709g; Fri, 5 Jun 92 12:44:56 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA05705g; Fri, 5 Jun 92 12:44:50 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA15002; Fri, 5 Jun 92 12:53:02 PDT Date: Fri, 5 Jun 92 12:53:02 PDT Message-Id: <9206051953.AA15002@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz@thalidomide To: Dirk Grunwald Cc: bug-lucid-emacs@lucid.com Subject: Re: bug in modifiers In-Reply-To: Dirk Grunwald's message of Fri 5-Jun-92 13:26:15 -0600 <199206051926.AA17011@foobar.cs.Colorado.EDU> References: <199206051926.AA17011@foobar.cs.Colorado.EDU> In message <199206051926.AA17011@foobar.cs.Colorado.EDU> Dirk Grunwald wrote: > > On my DECstation (& most other workstations), I make CapsLock be an > alias for Cntrl because I find it irritating & positioned too close to > Cntrl. > > with the lemacs 19.1 binary, I get... > > emacs: Caps_Lock generates ModControl, which is nonsensical. > > which isn't helpful. I was using... > > ! remove Lock = Caps_Lock > ! add Control = Caps_Lock It is a common mistake to assume that all that matters in your keyboard configuration is what modifier bits are attached to which keycodes (physical keys). In fact, the keysym attached to that code is important as well. "Mod1" does not mean "Meta" unless it is attached to a keycode whose keysym is Meta_L or Meta_R. If "Mod1" is attached to Super_L, then it means Super, not Meta. Old versions of emacs, and all versions of twm, are buggy in that they assume Mod1 always means Meta. There are 8 bits: ModShift always means shift; ModControl always means control; ModLock means Caps-Lock or Shift-Lock *depending on which keysym the ModLock bit is attached to*; and the meanings of Mod1 through Mod5 are determined solely by what keysyms generate them. If Meta_L generates Mod3, then Mod3 is the bit meaning "meta". Mod1-Mod5 have no predefined semantics. There is no reasonable interpretation of a keysym with a predefined behavior (such as Caps_Lock and the ModLock bit, or Control_L and the ModControl bit) having a different modifier bit associated with it. Likewise, it is nonsensical for two keysyms with different semantics (such as Meta_L and Super_L) to generate the same modifier bit. What does that bit mean, Meta or Super? The only thing that's different about emacs and the Xt text widget's interpretation of modifier bits is that emacs checks for and prints warning messages about inconsistencies. When there are inconsistencies, emacs ignores the subsequent, conflicting bindings. I believe Xt simply does something arbitrarily wrong. (Well, there is one more difference: if you have only Alt keys instead of Meta keys, then emacs treats Alt as Meta. But if you have both Alt and Meta keys (generating different modifier bits, of course), then emacs interprets Alt as meaning the "symbol" modifier, which is the next bit in the progression Shift/Control/Meta/Super/Hyper, and gives you just one more possible bit to bind commands to.) I'll include a file explaining this stuff in more detail with the next release. > (as documented in the xmodmap man page) but have switched it to > > ! Make caps lock look like control... > keycode 176 = Control_L This is the right fix. I would do it like this: keycode 176 = Control_L clear Lock add Control = Control_L You might want to check out my XKeyCaps program on export.lcs.mit.edu in contrib/xkeycaps.tar.Z, which makes messing around with your keyboard mapping easier. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 13:49:16 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17451; Fri, 5 Jun 92 13:49:16 PDT Received: by heavens-gate.lucid.com id AA05944g; Fri, 5 Jun 92 13:32:44 PDT Received: from dido.caltech.edu by heavens-gate.lucid.com id AA05940g; Fri, 5 Jun 92 13:32:38 PDT Received: by dido.caltech.edu (4.1/1.2) id AA11668; Fri, 5 Jun 92 13:39:51 PDT Date: Fri, 5 Jun 92 13:39:51 PDT From: gwp@dido.caltech.edu (G. W. Pigman III) Message-Id: <9206052039.AA11668@dido.caltech.edu> To: bug-lucid-emacs@lucid.com Subject: screen-default-alist I'm not sure whether this is a bug or my incomprehension, but I'm having a problem creating a new screen. I like a large font so I've added to ~/.Xresources Emacs*default.attributeFont: -sony-fixed*24* I fire up lemacs -geometry 80x36-0+0 (this puts as many lines as will fit onto the monitor of my Sun ELC). So far so good, but when I create a new screen, it's too large (about 39 lines, as far as I can tell). I tried placing (setq screen-default-alist '((width . 80) (height . 30))) in my .emacs, but to no avail. Shouldn't screen-default-alist restrict the height of new screens to 30 lines? From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 15:34:42 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17527; Fri, 5 Jun 92 15:34:42 PDT Received: by heavens-gate.lucid.com id AA06292g; Fri, 5 Jun 92 15:17:35 PDT Received: from mda.ca (mdavcr.mda.ca) by heavens-gate.lucid.com id AA06288g; Fri, 5 Jun 92 15:17:27 PDT Received: from mowgli.mda.ca by mda.ca (4.1/SMI-4.1-DNI) id AA17434; Fri, 5 Jun 92 15:24:37 PDT Date: Fri, 5 Jun 92 15:24:37 PDT From: rdr@mda.ca (Randolph Roesler) Message-Id: <9206052224.AA17434@ mda.ca> To: bug-lucid-emacs@lucid.com Subject: Problems building lemacs I saw Emacs 19 at oopsla last year, it that alone almost convinced me to but the Energize product. So, I have rushed out to build lemacs, and these are to problems I have encountered so far. 1) paths.el ... the auto path finding code in startup.el assumes that emacs is installed in /usr/local/emacs/{lock,lisp,etc} At our site, and many other sites, a path of /usr/local/lib/emacs (or gemacs, since we run multiple emacs) is used. 2) target all missing from ymakefile in src. Quickest fix is to change src/Makefile default target to xemacs 3) our site does not have /usr/demo/SOUND 4) most sites don't have cadillac directories, of any type 5) I think most people put header files for X in /usr/include/X11.R5 /usr/include/X11 or /usr/X11/include That is all for now Randy Roesler MacDonald Dettwiler & Assc. Ph. 604-278-3411 Fax. 604-278-2936 13800 Commerce Parkway, email ...!uunet!van-bc!mdavcr!rdr Richmond BC Canada rdr%mda.ca@wimsey.bc.ca or rdr@mda.ca V6V 2J3 From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 15:36:48 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17543; Fri, 5 Jun 92 15:36:48 PDT Received: by heavens-gate.lucid.com id AA06319g; Fri, 5 Jun 92 15:19:46 PDT Received: from dido.caltech.edu by heavens-gate.lucid.com id AA06314g; Fri, 5 Jun 92 15:19:36 PDT Received: by dido.caltech.edu (4.1/1.2) id AA11657; Fri, 5 Jun 92 13:26:53 PDT Date: Fri, 5 Jun 92 13:26:53 PDT From: gwp@dido.caltech.edu (G. W. Pigman III) Message-Id: <9206052026.AA11657@dido.caltech.edu> To: bug-lucid-emacs@lucid.com Subject: xmakefile I hit the following snag when trying to recompile lemacs: make -f xmakefile all make[1]: *** No way to make target `all'. Stop. make: *** [doall] Error 1 In fact, there aren't any targets in xmakefile. From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 15:47:54 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17605; Fri, 5 Jun 92 15:47:54 PDT Received: by heavens-gate.lucid.com id AA06353g; Fri, 5 Jun 92 15:26:19 PDT Received: from mda.ca (mdavcr.mda.ca) by heavens-gate.lucid.com id AA06348g; Fri, 5 Jun 92 15:26:08 PDT Received: from mowgli.mda.ca by mda.ca (4.1/SMI-4.1-DNI) id AA17612; Fri, 5 Jun 92 15:33:23 PDT Date: Fri, 5 Jun 92 15:33:23 PDT From: rdr@mda.ca (Randolph Roesler) Message-Id: <9206052233.AA17612@ mda.ca> To: bug-lucid-emacs@lucid.com Subject: Another problem .... Our compiler (gcc 2.1 no kidding) does not understand #error From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 16:37:15 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17651; Fri, 5 Jun 92 16:37:15 PDT Received: by heavens-gate.lucid.com id AA06559g; Fri, 5 Jun 92 16:10:26 PDT Received: from mda.ca (mdavcr.mda.ca) by heavens-gate.lucid.com id AA06555g; Fri, 5 Jun 92 16:10:19 PDT Received: from mowgli.mda.ca by mda.ca (4.1/SMI-4.1-DNI) id AA18484; Fri, 5 Jun 92 16:17:31 PDT Date: Fri, 5 Jun 92 16:17:31 PDT From: rdr@mda.ca (Randolph Roesler) Message-Id: <9206052317.AA18484@ mda.ca> To: bug-lucid-emacs@lucid.com Subject: More bugs (solved, thanks) In order to compile the lwlib, I had to manually perform imake -DHasGcc because we did not build out X11.R5 with Gcc. There is probably a better way to do this, but this was the first fix I found. Randy From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 16:53:47 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17656; Fri, 5 Jun 92 16:53:47 PDT Received: by heavens-gate.lucid.com id AA06654g; Fri, 5 Jun 92 16:34:51 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA06650g; Fri, 5 Jun 92 16:34:45 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA15339; Fri, 5 Jun 92 16:42:59 PDT Date: Fri, 5 Jun 92 16:42:59 PDT Message-Id: <9206052342.AA15339@thalidomide.lucid> X-Windows: A terminal disease. From: Jamie Zawinski Sender: jwz@thalidomide To: berry@athos.pei.com (Berry Kercheval) Cc: help-lucid-emacs@lucid.com Cc: bug-lucid-emacs@lucid.com Reply-To: jwz@heavens-gate.lucid.com Subject: Re: VM problem In-Reply-To: Berry Kercheval's message of Fri 5-Jun-92 15:27:37 PDT <9206052227.AA08500@athos> References: <9206052227.AA08500@athos> In message <9206052227.AA08500@athos> Berry Kercheval wrote: > > Well when I used the vm provided with lemacs, doing vm-reply got me a > bad number of arguments error on a byte-compiled function deep inside > vm-delete-duplicates. That's very strange. Can you reproduce it? If so, I'd like to see the backtrace. (uuencode it before you mail it to me.) It would also help if you could try to reproduce it in an emacs started with -q, to see if the problem is a bad interaction with some code you have loaded. By the way, messages like this should go to bug-lucid-emacs, not help-lucid-emacs. I think that, at least for the next few days, help-lucid-emacs should be a pretty low volume list. It should be for discussing the use of lemacs, not bugs in it, or in its installation procedures. If this high volume of bug reports keeps up, people are going to unsubscribe from the help list, which would be bad. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 17:01:22 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17664; Fri, 5 Jun 92 17:01:22 PDT Received: by heavens-gate.lucid.com id AA06684g; Fri, 5 Jun 92 16:43:22 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA06680g; Fri, 5 Jun 92 16:43:15 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA15354; Fri, 5 Jun 92 16:51:29 PDT Date: Fri, 5 Jun 92 16:51:29 PDT Message-Id: <9206052351.AA15354@thalidomide.lucid> X-Windows: Live the nightmare. From: Jamie Zawinski Sender: jwz@thalidomide To: rdr%mda.ca@lucid.com (Randolph Roesler) Cc: bug-lucid-emacs@lucid.com Subject: Re: Problems building lemacs In-Reply-To: Randolph Roesler's message of Fri 5-Jun-92 15:24:37 PDT <9206052224.AA17434@ mda.ca> References: <9206052224.AA17434@ mda.ca> In message <9206052224.AA17434@ mda.ca> Randolph Roesler wrote: > > 1) paths.el ... the auto path finding code in startup.el > assumes that emacs is installed in /usr/local/emacs/{lock,lisp,etc} > > At our site, and many other sites, a path of > /usr/local/lib/emacs (or gemacs, since we run multiple emacs) > is used. If there are directories (or links) to the appropriate lisp and etc directories in the same directory in which you placed the emacs executable, it won't use /usr/local/lib/emacs. > 3) our site does not have /usr/demo/SOUND That's unfortunate. You probably have it on tape somewhere, but you can just remove USE_SPARC_SOUND from config.h. > 4) most sites don't have cadillac directories, > of any type Where are you seeing that? -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 19:07:45 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17724; Fri, 5 Jun 92 19:07:45 PDT Received: by heavens-gate.lucid.com id AA07047g; Fri, 5 Jun 92 18:51:28 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA07043g; Fri, 5 Jun 92 18:51:22 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA15556; Fri, 5 Jun 92 18:59:37 PDT Date: Fri, 5 Jun 92 18:59:37 PDT Message-Id: <9206060159.AA15556@thalidomide.lucid> X-Windows: Flakey and built to stay that way. From: Jamie Zawinski Sender: jwz@thalidomide To: bug-lucid-emacs@lucid.com Subject: "Check that your $DISPLAY environment variable is properly set" If you get this error when starting up emacs, it is almost always because emacs is finding the wrong lisp directory, or none at all. Replace the function `normal-top-level' in startup.el with the following definition, and byte-compile the file. startup.el is loaded before emacs is dumped, so you can't install this fix without re-dumping. The best way to make emacs find the correct lisp and etc direcories is to keep those direcories in the same directory as the emacs executable. That is, if the lemacs executable in in /usr/foobar/bin/lemacs, then /usr/foobar/bin/lisp/ and /usr/foobar/bin/etc/ should exist as well. They may be symbolic links to directories, too. If these don't exist, then emacs will try to use /usr/local/lib/emacs/lisp/ or /usr/local/emacs/lisp/ instead. If these directories exist, but are for version 18 instead of Lucid GNU Emacs, then emacs will be unable to run. Another solution is to put the right directories in paths.h before building emacs, but that's not as good a solution because it means that if you want to move the emacs executable to another directory later, you have to recompile. -- Jamie (defun normal-top-level () (if command-line-processed (message "Back to top level.") (setq command-line-processed t) ;; In presence of symlinks, switch to cleaner form of default directory. (if (and (not (eq system-type 'vax-vms)) (getenv "PWD")) (setq default-directory (file-name-as-directory (getenv "PWD")) cdlist (initialize-cdlist))) (let ((tail directory-abbrev-alist)) (while tail (if (string-match (car (car tail)) default-directory) (setq default-directory (concat (cdr (car tail)) (substring default-directory (match-end 0))))) (setq tail (cdr tail)))) (condition-case error (command-line) ;; ;; If we get an error here, it's almost always because emacs couldn't ;; find lisp/term/x-win.el, or it's loading the v18 lisp/term/x-win.el. ;; If emacs supported ttys, then we could concievably continue here, ;; and simply run in tty mode, but right now, that just causes the ;; bogus "only runs under X" error to be printed. Even when ttys work, ;; there's not much point in trying to run if we know we're going to ;; be so completely crippled. It probably just won't work. ;; ;; If we call message here, it clears the screen in an unattractive ;; way, so just blast the bits to stdout. ;; (error (send-string-to-terminal (format "\nInitialization error: %S\n" error)) (send-string-to-terminal (format "\nload-path is %S" load-path)) (send-string-to-terminal (format "\nexec-directory is %S\n" exec-directory)) (kill-emacs 1))))) From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 19:17:28 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA17748; Fri, 5 Jun 92 19:17:28 PDT Received: by heavens-gate.lucid.com id AA07065g; Fri, 5 Jun 92 18:58:07 PDT Received: from watergate.lucid ([192.31.212.117]) by heavens-gate.lucid.com id AA07060g; Fri, 5 Jun 92 18:57:59 PDT Received: by watergate.lucid (4.1/SMI-4.1) id AA12173; Fri, 5 Jun 92 19:06:14 PDT Date: Fri, 5 Jun 92 19:06:14 PDT From: eb@watergate (Eric Benson) Message-Id: <9206060206.AA12173@watergate.lucid> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: Re: "Check that your $DISPLAY environment variable is properly set" In-Reply-To: Jamie Zawinski's message of Fri 5-Jun-92 18:59:37 PDT <9206060159.AA15556@thalidomide.lucid> References: <9206060159.AA15556@thalidomide.lucid> One common way to lose in this manner is by setting the environment variable EMACSLOADPATH. If it is set to the name of an Emacs 18 lisp directory, you will lose. From bug-lucid-emacs-request@heavens-gate.lucid.com Sun Jun 7 14:13:36 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19039; Sun, 7 Jun 92 14:13:36 PDT Received: by heavens-gate.lucid.com id AA10435g; Sun, 7 Jun 92 13:57:16 PDT Received: from att.att.com (att-out.att.com) by heavens-gate.lucid.com id AA10431g; Sun, 7 Jun 92 13:57:10 PDT From: gah@alux5.att.com Received: from me by grenache.sultan (4.1/SMI-4.1) id AA03827; Sun, 7 Jun 92 17:03:42 EDT Message-Id: <9206072103.AA03827@grenache.sultan> To: att!bug-lucid-emacs%lucid.com@alux5 Subject: Small problems with lemacs 19.1. Date: Sun, 07 Jun 92 17:03:42 -0400 Original-From: George A. Howlett (52864 ALC 2A-211 215-770-3351) 1 - If the X resource geometry is not specified completely such as *geometry: 80x55 The geometry request is not fulfilled and the program aborts because it is smaller than the minimum window width. However a specification of Emacs*geometry: 80x55+0+0 does indeed work. 2 - If you immediately hit the exit button from the file menu, the program does not exit until you click in the main window. This version appears very nice. The cleanup of X selections alone is worth using it. Do you intend to add scroll bars (ala GNU version 19)? Thank you for your time and efforts. --gah George Howlett AT&T Bell Laboratories 1247 S. Cedar Crest Blvd. Allentown, PA 18103 (215) 770-3351 From bug-lucid-emacs-request@heavens-gate.lucid.com Sun Jun 7 16:52:49 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19102; Sun, 7 Jun 92 16:52:49 PDT Received: by heavens-gate.lucid.com id AA10620g; Sun, 7 Jun 92 16:39:02 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA10616g; Sun, 7 Jun 92 16:38:55 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA18348; Sun, 7 Jun 92 16:47:13 PDT Date: Sun, 7 Jun 92 16:47:13 PDT Message-Id: <9206072347.AA18348@thalidomide.lucid> From: Jamie Zawinski Sender: jwz@thalidomide To: gah@alux5.att.com Cc: bug-lucid-emacs@lucid.com Subject: Re: Small problems with lemacs 19.1. In-Reply-To: gah@alux5.att.com's message of Sun 7-Jun-92 17:03:42 -0400 <9206072103.AA03827@grenache.sultan> References: <9206072103.AA03827@grenache.sultan> In message <9206072103.AA03827@grenache.sultan> gah@alux5.att.com wrote: > > 1 - If the X resource geometry is not specified completely > such as > > *geometry: 80x55 > > The geometry request is not fulfilled and the program aborts > because it is smaller than the minimum window width. That does not say "make emacs be 80 columns by 55 lines." It says "make emacs and all subwindows thereof be 80x35 in whatever units they care to measure in." In particular, that is both telling the emacs text pane to be 80x55 in characters, and telling the menubar pane to be 80x55 pixels, which is surely not what you want. It's actually worse than that, because there is a RowColumn widget which groups the menubar and the text area together, and it measures geometry in pixels. So you won't get anything that's 80 characters wide anyway. When I do this, I just get a very small emacs window (about 10x1 characters, plus the height of menubar). I can't make it abort(). If you can make this happen reliably, please send me all of your resource settings. The right way to specify geometry in the resource database is with Emacs*EmacsScreen.geometry: 80x55 to make the geometry of all screens be 80x55. As a special-case hack, the geometry of the toplevel shell is checked as well, so that Emacs.geometry: 80x55 works, since that's the way one sets geometry for most other programs (since most other programs have only one toplevel window, unlike emacs, which has many.) To set the geometry for individual screens, use the syntax Emacs*FOO.geometry: 80x55 where FOO is the name of the screen you want to set. (The default name for new screens is "emacs".) > However a specification of > > Emacs*geometry: 80x55+0+0 > > does indeed work. That's very strange. I have no idea why that works. Maybe it's because the RowColumn widget is seeing that X and Y were specified, and deciding to ignore the geometry? That doesn't make much sense. Geometry resources are surely one of the most broken parts of X. > Do you intend to add scroll bars (ala GNU version 19)? Yes, the NEWS file talks about this. By the way, the CC line on the message I recieved contained "att!bug-lucid-emacs%lucid.com@alux5". Your site shouldn't be letting non-fully-qualified addresses like that escape. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 05:38:43 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19627; Mon, 8 Jun 92 05:38:43 PDT Received: by heavens-gate.lucid.com id AA11646g; Mon, 8 Jun 92 05:23:37 PDT Received: from lamont.ldgo.columbia.edu (ldgo.columbia.edu) by heavens-gate.lucid.com id AA11638g; Mon, 8 Jun 92 05:22:38 PDT Received: from (ko.ldgo.columbia.edu) by lamont.ldgo.columbia.edu (4.1/SMI-3.2) id AA12045; Mon, 8 Jun 92 08:30:41 EDT Message-Id: <9206081230.AA12045@lamont.ldgo.columbia.edu> Date: Mon, 8 Jun 92 08:30:32 EDT From: fritzz@lamont.ldgo.columbia.edu (Fritz Zaucker) To: help-lucid-emacs@lucid.com Cc: bug-lucid-emacs@lucid.com Reply-To: fritzz@lamont.ldgo.columbia.edu Us-Snail: Lamont-Doherty Geological Observatory, Palisades, NY 10964 First: thanks for making this available. Some comments: 1) Will you later on merge with GNU EMACS 19? I'd think it would be too bad, if there were several new flavors of Emacs around. 2) Is there any hope that GNUS 3.14 will be adapted to lemacs? 3.13 seems to have some problems. 3) latex.el from Nelson Beebe doesn't work with lemacs. It complains about TeX-mode-map being undefined. Neither epoch nor GNU Emacs 18.58 have a problem there. 4) Running the labrea-binaries on a Sun Sparc 2, SunOS 4.1.1 and displaying to an IBM RISC/6000, lemacs dies with the following error message: Error during initialization: (error unrecognised color paleturquoise) Problems 2 and 3 are right now sufficiently serious me switching back to epoch. I'd rather not if somebody can tell me a fix. Fritz From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 07:03:53 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19660; Mon, 8 Jun 92 07:03:53 PDT Received: by heavens-gate.lucid.com id AA11758g; Mon, 8 Jun 92 06:47:18 PDT Received: from att.att.com (att-out.att.com) by heavens-gate.lucid.com id AA11754g; Mon, 8 Jun 92 06:47:11 PDT From: gah@alux5.att.com Received: from me by grenache.sultan (4.1/SMI-4.1) id AA00370; Mon, 8 Jun 92 09:51:49 EDT Message-Id: <9206081351.AA00370@grenache.sultan> To: att!bug-lucid-emacs%lucid.com@alux5 Subject: Re: Small problems with lemacs 19.1. In-Reply-To: Your message of "Sun, 07 Jun 92 16:47:13 PDT." <9206072347.AA18348@thalidomide.lucid> Date: Mon, 08 Jun 92 09:51:48 -0400 Original-From: George A. Howlett (52864 ALC 2A-211 215-770-3351) Your message dated: Sun, 07 Jun 92 16:47:13 PDT | In message <9206072103.AA03827@grenache.sultan> gah@alux5.att.com wrote: | > | > 1 - If the X resource geometry is not specified completely | > such as | > | > *geometry: 80x55 | > | > The geometry request is not fulfilled and the program aborts | > because it is smaller than the minimum window width. | | That does not say "make emacs be 80 columns by 55 lines." It says "make emac | s | and all subwindows thereof be 80x35 in whatever units they care to measure | in." In particular, that is both telling the emacs text pane to be 80x55 in | characters, and telling the menubar pane to be 80x55 pixels, which is surely | not what you want. | Agreed. I guess I showed that example so there would be no question whether the EmacsShell widget is getting the right specification. A move of desperation I suppose. BTW: The specification supposed to be was Emacs*geometry, but the behavior of kill-word has changed. Is that documented somewhere? For example, it previously would not kill a word past the end of the line if there was intervening blank spaces. I do like the fact it kills only up to the end of the word (and not the following blanks). | It's actually worse than that, because there is a RowColumn widget which | groups the menubar and the text area together, and it measures geometry in | pixels. So you won't get anything that's 80 characters wide anyway. | | When I do this, I just get a very small emacs window (about 10x1 characters, | plus the height of menubar). I can't make it abort(). If you can make this | happen reliably, please send me all of your resource settings. | Emacs*mouseColor: red Emacs*background: AliceBlue Emacs*foreground: purple3 Emacs*cursorColor: red Emacs*borderColor: yellow Emacs*Font: -b&h-lucidatypewriter-bold-r-*-*-14-*-*-*-*-*-*-* Emacs*Geometry: 80x55 Emacs*BoldFont: *cour*14* Emacs*BodyFont: *cour*14* Emacs*reverseVideo: off Emacs*BitMapIcon: on EmacsScreen*borderWidth: 6 The information I forgot add is: SS2 SunOS4.1.1 X11R5 patch level 12 using tvtwm patchlevel 7 (No RandomPlacement, UsePPosition "non-zero") | | > However a specification of | > | > Emacs*geometry: 80x55+0+0 | > | > does indeed work. | | That's very strange. I have no idea why that works. Maybe it's because | the RowColumn widget is seeing that X and Y were specified, and deciding | to ignore the geometry? That doesn't make much sense. Geometry resources | are surely one of the most broken parts of X. | The difference is that in function set_screen_size (ScreenWidget.c) if a position was set, you then go an set the geometry specification in the shell. /* If a position was specified, assign it to the shell widget. */ if (parse_result & (XValue | YValue)) { /* the tricky things with the sign is to make sure that -0 is printed -0. */ sprintf (shell_position, "=%c%d%c%d", parse_result & XNegative ? '-' : '+', x < 0 ? -x : x, parse_result & YNegative ? '-' : '+', y < 0 ? -y : y); XtVaSetValues (wmshell, XtNgeometry, strdup (shell_position), 0); } As a workaround, I added this fragment. else if (parse_result & (WidthValue | HeightValue)) { sprintf (shell_position, "=%dx%d", pixel_width, pixel_height); XtVaSetValues (wmshell, XtNgeometry, strdup (shell_position), 0); } It still isn't right. The 80x55 translates into 80x53 (that's because of the menubar I suppose) but I can live with that. | By the way, the CC line on the message I recieved contained | "att!bug-lucid-emacs%lucid.com@alux5". Your site shouldn't be letting | non-fully-qualified addresses like that escape. | | -- Jamie The combination of the att gateway and our mailer(s) (upas, sendmail, etc), make these things hard to get rid of (e.g. it will accept an address with multiple @ signs). Sorry. --gah From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 08:02:50 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19701; Mon, 8 Jun 92 08:02:50 PDT Received: by heavens-gate.lucid.com id AA11893g; Mon, 8 Jun 92 07:47:09 PDT Received: from dido.caltech.edu by heavens-gate.lucid.com id AA11889g; Mon, 8 Jun 92 07:47:02 PDT Received: by dido.caltech.edu (4.1/1.2) id AA08148; Mon, 8 Jun 92 07:40:55 PDT Date: Mon, 8 Jun 92 07:40:55 PDT From: gwp@dido.caltech.edu (G. W. Pigman III) Message-Id: <9206081440.AA08148@dido.caltech.edu> To: bug-lucid-emacs@lucid.com Subject: problem compiling On a Sun ELC running 4.1.1 using gcc 2.1 I added all: xemacs and changed C_DEBUG_SWITCH to C_OPTIMIZE_SWITCH in ymakefile---no other changes---and tried a make. I had to specify CC=gcc to make lwlib and received various warning messages, but everything compiled. ld complained that ___main was undefined. I tried remaking with make LD=gcc LDFLAGS='-e __start -static -L. -L./lwlib' and got an executable xemacs---which gives a segmentation fault. What do I need to do? From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 09:16:08 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA19746; Mon, 8 Jun 92 09:16:08 PDT Received: by heavens-gate.lucid.com id AA12073g; Mon, 8 Jun 92 08:53:32 PDT Received: from uswat.advtech.uswest.com by heavens-gate.lucid.com id AA12069g; Mon, 8 Jun 92 08:53:20 PDT Received: from alder.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA12229 (5.65c/IDA-1.4.4 for ); Mon, 8 Jun 1992 10:01:32 -0600 Received: by alder.advtech.uswest.com (advtech.uswest.com) id AA13399 (4.1/at-generic.11Feb92); Mon, 8 Jun 92 09:58:37 MDT Date: Mon, 8 Jun 92 09:58:37 MDT From: Chris McClenaghan Message-Id: <9206081558.AA13399@alder.advtech.uswest.com> To: bug-lucid-emacs@lucid.com Subject: minor problems with lemacs 19.1 I believe I have successfully installed on Sun 4 (IPC) Sun OS 4.1.2 with X11R4 and Motif 1.0(?), we don't have an R5 compatible Motif yet. Had some problem with the build environment, never really liked FSF's build strategy, but this one needs cleaning up/documentation. The top level README and INSTALL lead one to believe that make at the top level will do it all. I had to compile each directory separately. I get a ``Symbol's value as a variable void: mouse-map'' when i select info from the help menu, same with key board access. Again, I'm using Motif menu bar, inserting an entirely new pull down shifts Help to the left. I think help should stay full right, and any added pull down inserted after the last (Buffer in default) pull down added. Actually, adding new pull downs and creating new menubars could use some utility routines. For example, if I wanted to remove help, add a new menu and then add help to get around the problem mentioned above, I'd use find-menu-item, followed by delete and add-menu items. However, there isn't a utility function to add/insert the result from find-menu-item. My lisp programming is not to hot, but I could hack something together, is there any further development to be expected here? Finally, not really a bug, but is hyperbole supported yet? Chris McClenaghan mcclen@uswest.com From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 11:47:08 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20027; Mon, 8 Jun 92 11:47:08 PDT Received: by heavens-gate.lucid.com id AA12602g; Mon, 8 Jun 92 11:27:04 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12598g; Mon, 8 Jun 92 11:26:56 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20008; Mon, 8 Jun 92 11:35:13 PDT Date: Mon, 8 Jun 92 11:35:13 PDT Message-Id: <9206081835.AA20008@thalidomide.lucid> X-Windows: No hardware is safe. From: Jamie Zawinski Sender: jwz@thalidomide To: kenb@dadd.ti.com (Ken Butler) Cc: help-lucid-emacs@lucid.com Cc: bug-lucid-emacs@lucid.com Subject: Re: Trouble compiling ScreenWidget.c In-Reply-To: Ken Butler's message of Mon 8-Jun-92 09:04:55 CDT <9206081404.AA11504@atg2.dadd.ti.com> References: <9206081404.AA11504@atg2.dadd.ti.com> Please send messages like this to bug-lucid-emacs, not help-lucid-emacs. People who aren't on the bug list aren't interested in hearing about these problems. In message <9206081404.AA11504@atg2.dadd.ti.com> Ken Butler wrote: > > ScreenWidget.c: In function get_wm_shell: > ScreenWidget.c:201: dereferencing pointer to incomplete type > *** Error code 1 > make: Fatal error: Command failed for target `ScreenWidget.o' I haven't seen this before. Line 201 is "wmshell && !XtIsWMShell (wmshell);". XtIsWMShell is defined in X11/Intrinsic.h in both R4 and R5. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 11:50:33 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20031; Mon, 8 Jun 92 11:50:33 PDT Received: by heavens-gate.lucid.com id AA12628g; Mon, 8 Jun 92 11:30:39 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12624g; Mon, 8 Jun 92 11:30:33 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20023; Mon, 8 Jun 92 11:38:49 PDT Date: Mon, 8 Jun 92 11:38:49 PDT Message-Id: <9206081838.AA20023@thalidomide.lucid> X-Windows: Japan's secret weapon. From: Jamie Zawinski Sender: jwz@thalidomide To: Chris McClenaghan Cc: bug-lucid-emacs@lucid.com Subject: Re: minor problems with lemacs 19.1 In-Reply-To: Chris McClenaghan's message of Mon 8-Jun-92 09:58:37 MDT <9206081558.AA13399@alder.advtech.uswest.com> References: <9206081558.AA13399@alder.advtech.uswest.com> In message <9206081558.AA13399@alder.advtech.uswest.com> Chris McClenaghan wrote: > > I get a ``Symbol's value as a variable void: mouse-map'' when i > select info from the help menu, same with key board access. This means you are loading an Emacs 18 lisp file. Mouse-map no longer exists. > Finally, not really a bug, but is hyperbole supported yet? Nope. Hopefully someone will write an Epoch-compatibility package soon. Also, last time I checked, there was a bug in Hyperbole that prevented it from being compiled with the new byte compiler. I sent a fix to the author. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 11:54:16 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20039; Mon, 8 Jun 92 11:54:16 PDT Received: by heavens-gate.lucid.com id AA12641g; Mon, 8 Jun 92 11:32:16 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12637g; Mon, 8 Jun 92 11:32:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20038; Mon, 8 Jun 92 11:40:27 PDT Date: Mon, 8 Jun 92 11:40:27 PDT Message-Id: <9206081840.AA20038@thalidomide.lucid> X-Windows: The joke that kills. From: Jamie Zawinski Sender: jwz@thalidomide To: gwp@dido.caltech.edu (G. W. Pigman III) Cc: bug-lucid-emacs@lucid.com Subject: Re: problem compiling In-Reply-To: G. W. Pigman III's message of Mon 8-Jun-92 07:40:55 PDT <9206081440.AA08148@dido.caltech.edu> References: <9206081440.AA08148@dido.caltech.edu> In message <9206081440.AA08148@dido.caltech.edu> G. W. Pigman III wrote: > > ld complained that ___main was undefined. This seems to mean that you need to link with the GCC library. Set LIB_GCC to something in config.h. From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 12:05:51 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20068; Mon, 8 Jun 92 12:05:51 PDT Received: by heavens-gate.lucid.com id AA12719g; Mon, 8 Jun 92 11:48:10 PDT Received: from Sunburn.Stanford.EDU by heavens-gate.lucid.com id AA12715g; Mon, 8 Jun 92 11:48:04 PDT Received: by Sunburn.Stanford.EDU (5.61+IDA/25-eef) id AA12107; Mon, 8 Jun 92 11:55:34 -0700 Date: Mon, 8 Jun 92 11:55:34 -0700 From: Martin Frost Message-Id: <9206081855.AA12107@Sunburn.Stanford.EDU> To: bug-lucid-emacs@lucid.com Subject: lemacs screen redrawing Reply-To: me@CS.Stanford.EDU A minor but quite annoying misfeature of lemacs is that it redraws the entire buffer when it doesn't need to, as for instance when I type ^U^V to make the text shift up by four lines. On a local X terminal, this doesn't take more than a second or two, but it makes it hard to keep one's eye on a piece of code that is moving, since the whole screen gets redrawn. And over a 9600-baud line running Xremote on an NCD, it take longer and is very sad to see. I hope and assume this will be fixed in some upcoming revision. Interestingly, lemacs doesn't redraw if I add a line in the middle -- the text below gets shifted down correctly. But even ^U1^V redraws the whole screen. From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 13:18:09 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20149; Mon, 8 Jun 92 13:18:09 PDT Received: by heavens-gate.lucid.com id AA12996g; Mon, 8 Jun 92 13:00:44 PDT Received: from alpha.xerox.com by heavens-gate.lucid.com id AA12992g; Mon, 8 Jun 92 13:00:38 PDT Received: from NightTrain.wbst129.xerox.xns by alpha.xerox.com via XNS id <11569>; Mon, 8 Jun 1992 13:08:14 PDT X-Ns-Transport-Id: 0000AA0081442DB72DDD Date: Mon, 8 Jun 1992 13:07:20 PDT From: Marc_Rocas.Wbst129@xerox.com Subject: Re: Trouble compiling ScreenWidget.c In-Reply-To: <9206081835.AA20008@thalidomide.lucid> To: "kenb@dadd.ti".com@unspecified.xerox.com Cc: "bug-lucid-emacs@lucid".com@unspecified.xerox.com Reply-To: Marc_Rocas.Wbst129@xerox.com Message-Id: <"8-Jun-92 16:07:08".*.Marc_Rocas.WBST129@Xerox.com> Importance: Normal :Please send messages like this to bug-lucid-emacs, not help-lucid-emacs. :people who aren't on the bug list aren't interested in hearing about these :problems. : :In message <9206081404.AA11504@atg2.dadd.ti.com> Ken Butler wrote: :> :> ScreenWidget.c: In function get_wm_shell: :> ScreenWidget.c:201: dereferencing pointer to incomplete type :> *** Error code 1 :> make: Fatal error: Command failed for target `ScreenWidget.o' : :I haven't seen this before. Line 201 is "wmshell && !XtIsWMShell (wmshell);". :XtIsWMShell is defined in X11/Intrinsic.h in both R4 and R5. : : -- Jamie I had a similar problem which was due to the fact that when I built gcc2.1 and performed fixincludes I was still in X11R4. During compilation, gcc-lib/../include/X11 headers were being fetched instead of /usr/include/X11R5. As soon as I realized this, I simply deleted all the modified X11 headers under gcc, and simply allowed X11R5 headers to be used instead and everything compiled with no problems. Hope this helps. BTW, configuration: SunOS4.1.1, gcc2.1, no patches. --Marc. From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 13:56:38 1992 Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20226; Mon, 8 Jun 92 13:56:38 PDT Received: by heavens-gate.lucid.com id AA13132g; Mon, 8 Jun 92 13:37:53 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA13128g; Mon, 8 Jun 92 13:37:44 PDT Return-Path: Received: from turing.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA12911; Mon, 8 Jun 92 16:43:50 -0400 Message-Id: <9206082043.AA12911@mwunix.mitre.org> Received: by turing.mitre.org (15.11/16.2) id AA06114; Mon, 8 Jun 92 16:50:25 edt From: Shawn Smith Subject: Make errors on Sun, HP To: bug-lucid-emacs@lucid.com Date: Mon, 8 Jun 92 16:50:22 EDT Mailer: Elm [revision: 64.9] Has anyone seen this error, or does anyone know where ___fixunsdfsi comes from? I'm runnig SunOS 4.1 and GCC 1.36. Would it help to install GCC 2.1? --------------- Make from the $BUILD/src directory % make make -f xmakefile ld -e __start -Bstatic -L. -L./lwlib -y___fixunsdfsi -o temacs [rest deleted] Undefined ___fixunsdfsi event-stream.o: reference to external undefined ___fixunsdfsi *** Error code 2 make: Fatal error: Command failed for target `temacs' I'm also trying to compile this on an HP 9000/730 (HPUX 8.05/GCC 2.1). I'm stuck at the same point, but with different errors. Anyone had success on an HP? -------------- Make from the $BUILD/src directory % make make -f xmakefile ld -L/usr/lib/Motif1.1 -L/usr/lib/X11R4 -L. -L./lwlib [rest deleted] ld: Duplicate symbol "print_help" in keyboard.o ld: Unsatisfied symbols: __main (code) realpath (code) ld: Found 1 duplicate symbol(s) ld: R_DATA_ONE_SYMBOL fixup in file ScreenWidget.o for code unsat symbol "_XtInherit" - use P' fixup *** Error code 1 Stop. *** Error code 1 Stop. From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 14:13:11 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20238; Mon, 8 Jun 92 14:13:11 PDT Received: by heavens-gate.lucid.com id AA13191g; Mon, 8 Jun 92 13:51:02 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA13187g; Mon, 8 Jun 92 13:50:53 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20359; Mon, 8 Jun 92 13:59:11 PDT Date: Mon, 8 Jun 92 13:59:11 PDT Message-Id: <9206082059.AA20359@thalidomide.lucid> X-Windows: Power tools for power fools. From: Jamie Zawinski Sender: jwz@thalidomide To: Shawn Smith Cc: bug-lucid-emacs@lucid.com Subject: Re: Make errors on Sun, HP In-Reply-To: Shawn Smith's message of Mon 8-Jun-92 16:50:22 EDT <9206082043.AA12911@mwunix.mitre.org> References: <9206082043.AA12911@mwunix.mitre.org> In message <9206082043.AA12911@mwunix.mitre.org> Shawn Smith wrote: > > Has anyone seen this error, or does anyone know where ___fixunsdfsi > comes from? From the PROBLEMS file: * When using gcc, you get the error message "undefined symbol __fixunsdfsi". * When using gcc, you get the error message "undefined symbol __main". This means that you need to link with the gcc library. It may be called "gcc-gnulib" or "libgcc.a"; figure out where it is, and define LIB_GCC in config.h to point to it. > ld: Duplicate symbol "print_help" in keyboard.o That doesn't make sense. The code looks correct to me. > ld: Unsatisfied symbols: > realpath (code) Apparently you can't define HAVE_REALPATH on HPs. But 19.1 can't be compiled without HAVE_REALPATH. I've fixed this, it will be in the next release. > ld: R_DATA_ONE_SYMBOL fixup in file ScreenWidget.o for code unsat symbol "_XtInherit" - use P' fixup I don't know what that means either. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 14:16:04 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20254; Mon, 8 Jun 92 14:16:04 PDT Received: by heavens-gate.lucid.com id AA13229g; Mon, 8 Jun 92 13:57:23 PDT Message-Id: <9206082057.AA13229@lucid.com> Received: from research.att.com by heavens-gate.lucid.com id AA13225g; Mon, 8 Jun 92 13:57:15 PDT Received: by research.att.com; Mon Jun 8 17:04 EDT 1992 Received: by king; Mon Jun 8 16:04:22 CDT 1992 From: ladd@graceland.ih.att.com Date: Mon, 8 Jun 92 16:04:20 CDT To: ssmith@turing.mitre.org Cc: bug-lucid-emacs@lucid.com Subject: Re: Make errors on Sun, HP References: <9206082043.AA12911@mwunix.mitre.org> Shawn Smith writes: > Has anyone seen this error, or does anyone know where ___fixunsdfsi > comes from? I'm runnig SunOS 4.1 and GCC 1.36. Would it help to > install GCC 2.1? > set LIB_GCC in config.h to /usr/local/gcc-gnulib or whatever is appropriate. Now for my question... Why do the sparc binaries and the version I build both complain that they run only under X windows and that I should set $DISPLAY? I'm on a Sparc 1+ running SunOS 4.1.1. I'm also running the MIT X server, if that matters. -Dave Ladd (708)979-8474 ladd@research.att.com From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 15:03:31 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20351; Mon, 8 Jun 92 15:03:31 PDT Received: by heavens-gate.lucid.com id AA13458g; Mon, 8 Jun 92 14:45:42 PDT Received: from erewhon.CS.Berkeley.EDU by heavens-gate.lucid.com id AA13454g; Mon, 8 Jun 92 14:45:35 PDT Received: by erewhon.CS.Berkeley.EDU (5.57/Ultrix3.0-C) id AA05847; Mon, 8 Jun 92 14:55:46 -0700 Message-Id: <9206082155.AA05847@erewhon.CS.Berkeley.EDU> From: Adam Glass To: bug-lucid-emacs@lucid.com Subject: Was Re: Make errors on Sun, HP Now: ultrix problems In-Reply-To: Your message of Mon, 08 Jun 92 13:59:11 PST. <9206082059.AA20359@thalidomide.lucid> Date: Mon, 08 Jun 92 14:55:44 PDT Sender: glass@postgres.Berkeley.EDU > > > ld: Unsatisfied symbols: > > realpath (code) > > Apparently you can't define HAVE_REALPATH... Jamie, FYI: ultrix 4.2a (the current release) doesn't have it either. It also doesn't have strdup(), tparm sortof (it appears as part of the cursesX library), and remainder(). The '-traditional' comment in the INSTALL file just doesn't apply on ultrix. Using gcc-2.1's -traditional results in failures from system include files which have 'volatile' in them. The xmakefile had a recursive macro in it involving 'foo' and 'mallocobj' that had to be undone. also my 'xmakefile' didn't have an 'all' rule which seemed strange. Otherwise the compile was noisy but sucessfull. I'm stuck at the temacs link waiting for solutions to the above stuff. btw: i'd be happy to help you test any ultrix/decstation changes later, Adam Glass ps. this is on a decstation 5k/200 From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 17:14:44 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20566; Mon, 8 Jun 92 17:14:44 PDT Received: by heavens-gate.lucid.com id AA14018g; Mon, 8 Jun 92 16:55:02 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA14013g; Mon, 8 Jun 92 16:54:56 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20685; Mon, 8 Jun 92 17:03:15 PDT Date: Mon, 8 Jun 92 17:03:15 PDT Message-Id: <9206090003.AA20685@thalidomide.lucid> From: Jamie Zawinski Sender: jwz@thalidomide To: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com Subject: "Composed" characters If you understand how Multi_key is supposed to work, or if you have a working Multi_key or "Compose" key on your keyboard, please send me mail. I don't really understand what the right way to make Emacs recognize multi-key characters is. In particular, I'm confused about the suggestion in the xmodmap man page to make Multi_key and Meta_L (with a modifier bit) be the same key. I can't see how, in such a setup, emacs could be made to understand that key as both a "meta" key and as a "compose" key. I'm interested in how other applications deal with this, and how exactly different X servers and libraries deal with the XComposeStatus structure. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 17:50:29 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20624; Mon, 8 Jun 92 17:50:29 PDT Received: by heavens-gate.lucid.com id AA14175g; Mon, 8 Jun 92 17:32:46 PDT Received: from gatech.edu by heavens-gate.lucid.com id AA14171g; Mon, 8 Jun 92 17:32:40 PDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA06009 for bug-lucid-emacs@lucid.com; Mon, 8 Jun 92 20:40:52 EDT Received: from haring.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA20943; Mon, 8 Jun 92 20:40:39 EDT Received: by haring.cc.gatech.edu (4.1/SMI-4.1) id AA03065; Mon, 8 Jun 92 20:38:00 EDT Date: Mon, 8 Jun 92 20:38:00 EDT From: iansmith@cc.gatech.edu (Ian Smith) Message-Id: <9206090038.AA03065@haring.cc.gatech.edu> To: bug-lucid-emacs@lucid.com Subject: vm 5.32L Reply-To: Ian Smith X-Vi: NOT! X-Mailer: VM 5.32L [Lucid Emacs 19.1] VM 5.32L (shipped with 19.1) is not laying down a mark for the supercite package to find and use to cite a reply buffer. It breaks both versions 2.1 and 2.2 of supercite. It is breaking in sc-cite() which is called from mail-yank-hooks (which should be 'sc-cite-original for supercite to work right). VM 5.31 works fine in this respect... Before I go to the trouble of fixing it ... has anyone else fixed this to work right ? ian ----- I guess nobody will ever have as much slack as that big fat Quaker Oatmeal guy. ian smith, multimedia computing group, georgia tech, iansmith@cc.gatech.edu From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 17:52:22 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20628; Mon, 8 Jun 92 17:52:22 PDT Received: by heavens-gate.lucid.com id AA14182g; Mon, 8 Jun 92 17:35:19 PDT Received: from clouso.crim.ca by heavens-gate.lucid.com id AA14178g; Mon, 8 Jun 92 17:35:11 PDT Received: from bond.crim.ca by clouso.crim.ca (4.1/SMI-4.1) id AA21356; Mon, 8 Jun 92 20:43:20 EDT Received: by bond.crim.ca (4.1/SMI-4.0) id AA22421; Mon, 8 Jun 92 20:43:21 EDT Date: Mon, 8 Jun 92 20:43:21 EDT From: paquette@bond.crim.ca (Marc Paquette) Message-Id: <9206090043.AA22421@bond.crim.ca> To: bug-lucid-emacs@lucid.com Subject: Compiling lemacs with OLIT (OpenWindows V3) Comments: Hyperbole mail buttons accepted, v3.04. Hello, Since I'm new on this list, maybe my questions have been answered, but here it goes: I'm trying to compile lemacs with OPEN LOOK support, e.g. by using OLIT. However, there seems to be some bits missing. In file "lemacs-19.1/src/lwlib/lwlib-Xol.c" an include of "xt_extension.h" is made. This file is non existent on my system. Is it suppose to be part of OLIT or part of lwlib ? On another topic, that I suspect is related to the one above, in the function `make_menu_in_widget' ("lemacs-19.1/src/lwlib/lwlib-Xol.c"), there is a call to the function `resource_string', which is also inexistent on my system. Since a function named `resource_motif_string' exists for the Motif support part of lwlib, I suspect that this `resource_string' function is simply missing. Is that the case ? Any help is greatly apreciated. Marc Paquette Conseiller Technique, UNIX Centre de recherche informatique de Montreal (CRIM) Tel : (514) 340-5758 Fax : (514) 340-5777 email : paquette@crim.ca From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 17:53:35 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20632; Mon, 8 Jun 92 17:53:35 PDT Received: by heavens-gate.lucid.com id AA14189g; Mon, 8 Jun 92 17:37:07 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA14185g; Mon, 8 Jun 92 17:37:00 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20842; Mon, 8 Jun 92 17:45:20 PDT Date: Mon, 8 Jun 92 17:45:20 PDT Message-Id: <9206090045.AA20842@thalidomide.lucid> X-Windows: Flawed beyond belief. From: Jamie Zawinski Sender: jwz@thalidomide To: Ian Smith Cc: bug-lucid-emacs@lucid.com Subject: Re: vm 5.32L In-Reply-To: Ian Smith's message of Mon 8-Jun-92 20:38:00 EDT <9206090038.AA03065@haring.cc.gatech.edu> References: <9206090038.AA03065@haring.cc.gatech.edu> Change the calls to (mark) or (mark-marker) in supercite to be (let ((zmacs-regions nil)) (mark)) or (let ((zmacs-regions nil)) (mark-marker)) This is mentioned in the NEWS file: > *** Compatibility note: if you have code which uses (mark) or (mark-marker), > then you need to either: change those calls to (mark t) or (mark-marker t); > or simply bind `zmacs-regions' to nil around the call to mark or mark-marker. > This is probably the best solution, since it will work in Emacs18 as well. This change was made in an effort to enforce the behavior that, when zmacs-regions is on, commands do not operate on the mark unless the region is active. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Mon Jun 8 17:57:52 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA20636; Mon, 8 Jun 92 17:57:52 PDT Received: by heavens-gate.lucid.com id AA14208g; Mon, 8 Jun 92 17:40:59 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA14204g; Mon, 8 Jun 92 17:40:48 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA20858; Mon, 8 Jun 92 17:49:07 PDT Date: Mon, 8 Jun 92 17:49:07 PDT Message-Id: <9206090049.AA20858@thalidomide.lucid> X-Windows: A terminal disease. From: Jamie Zawinski Sender: jwz@thalidomide To: paquette%bond.crim.ca@lucid.com (Marc Paquette) Cc: bug-lucid-emacs@lucid.com Subject: Re: Compiling lemacs with OLIT (OpenWindows V3) In-Reply-To: Marc Paquette's message of Mon 8-Jun-92 20:43:21 EDT <9206090043.AA22421@bond.crim.ca> References: <9206090043.AA22421@bond.crim.ca> In message <9206090043.AA22421@bond.crim.ca> Marc Paquette wrote: > > In file "lemacs-19.1/src/lwlib/lwlib-Xol.c" an include of > "xt_extension.h" is made. Just remove the include of xt_extension.h, it's dead code. > On another topic, that I suspect is related to the one above, in the > function `make_menu_in_widget' > ("lemacs-19.1/src/lwlib/lwlib-Xol.c"), there is a call to the > function `resource_string', which is also inexistent on my > system. Since a function named `resource_motif_string' exists > for the Motif support part of lwlib, I suspect that this > `resource_string' function is simply missing. Is that the case ? I'm not sure. The fellow who wrote the OLIT support is on vacation right now. however, I have seen a running emacs with an OLIT menubar, so it used to work, at least. I'd recommend against trying to use the OLIT menubar just yet. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 05:28:14 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA21134; Tue, 9 Jun 92 05:28:14 PDT Received: by heavens-gate.lucid.com id AA15507g; Tue, 9 Jun 92 05:08:47 PDT Received: from noc.msc.edu by heavens-gate.lucid.com id AA15503g; Tue, 9 Jun 92 05:08:41 PDT Received: from kl.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA08556; Tue, 9 Jun 92 07:16:45 -0500 Received: by kl.msc.edu (5.65/MSC/v3.1r(920220)) id AA07571; Tue, 9 Jun 92 07:16:44 -0500 Date: Tue, 9 Jun 92 07:16:44 -0500 From: olstad@msc.edu (Ken Olstad) Message-Id: <9206091216.AA07571@kl.msc.edu> To: ladd@graceland.ih.att.com Cc: bug-lucid-emacs@lucid.com, ssmith@turing.mitre.org, danw@msc.edu, ken@msc.edu, saroff@msc.edu, andy@msc.edu Subject: Re: Make errors on Sun, HP References: <9206082043.AA12911@mwunix.mitre.org> <9206082057.AA13229@lucid.com> >>>>> On Mon, 8 Jun 92 16:04:20 CDT, ladd@graceland.ih.att.com said: Dave> Now for my question... Why do the sparc binaries ... complain Dave> ... that I should set $DISPLAY? Try setting your DISPLAY to the numeric IP address. All I know is that it seems to work for us. -- Ken Olstad Minnesota Supercomputer Center, Inc. olstad@msc.edu 1200 Washington Avenue South 612 626-1895 Minneapolis, MN 55415 From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 09:49:02 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA21315; Tue, 9 Jun 92 09:49:02 PDT Received: by heavens-gate.lucid.com id AA16147g; Tue, 9 Jun 92 09:27:37 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA16142g; Tue, 9 Jun 92 09:27:25 PDT Received: by moebius.loria.fr id AA02349 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Tue, 9 Jun 92 18:33:53 +0200 Date: Tue, 9 Jun 92 18:33:53 +0200 From: Guido Bosch Message-Id: <9206091633.AA02349@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: diff / diff-mode Reply-To: Guido BOSCH The autoloads for the functions `diff' and `diff-mode' are wrong: (symbol-function 'diff-mode) -> (autoload "Diff Mode is used by diff for perusing the output from the diff program" t nil nil) (symbol-function 'diff) -> (autoload "diff-mode" "Find and display the differences between OLD and NEW file." t nil) (the file that defines them is "diff.el") -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 14:02:34 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA21713; Tue, 9 Jun 92 14:02:34 PDT Received: by heavens-gate.lucid.com id AA17089g; Tue, 9 Jun 92 13:41:53 PDT Received: from gatech.edu by heavens-gate.lucid.com id AA17085g; Tue, 9 Jun 92 13:41:46 PDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA21021 for bug-lucid-emacs@lucid.com; Tue, 9 Jun 92 16:50:00 EDT Received: from haring.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA01185; Tue, 9 Jun 92 16:49:51 EDT Received: by haring.cc.gatech.edu (4.1/SMI-4.1) id AA04042; Tue, 9 Jun 92 16:47:10 EDT Date: Tue, 9 Jun 92 16:47:10 EDT From: iansmith@cc.gatech.edu (Ian Smith) Message-Id: <9206092047.AA04042@haring.cc.gatech.edu> To: bug-lucid-emacs@lucid.com Subject: debugger problem Reply-To: Ian Smith X-Vi: NOT! X-Mailer: VM 5.32L [Lucid Emacs 19.1] Eval this region: (defun f () (print 'foo)) (defun g () (f) (print 'bar)) (debug-on-entry 'f) (debug-on-entry 'g) (g) At least on the binary I am using stepping into g far enough causes problems eventually resulting in some type of error like: Search Failed : "\n Debug" And you never get into f... ian ----- I guess nobody will ever have as much slack as that big fat Quaker Oatmeal guy. ian smith, multimedia computing group, georgia tech, iansmith@cc.gatech.edu From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 17:26:20 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22078; Tue, 9 Jun 92 17:26:20 PDT Received: by heavens-gate.lucid.com id AA17835g; Tue, 9 Jun 92 17:08:38 PDT Received: from uu2.psi.com by heavens-gate.lucid.com id AA17831g; Tue, 9 Jun 92 17:08:29 PDT Received: from rutherford.stsi.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25710; Tue, 9 Jun 92 20:16:40 -0400 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA02867; Tue, 9 Jun 92 20:16:34 EDT Received: from hurricane.sbi.com by sbi.sbi.com (4.1/SMI-4.1) id AA15377; Tue, 9 Jun 92 20:16:33 EDT Received: from scirocco.sbi.com by hurricane.sbi.com (4.1/SMI-4.1) id AA22794; Tue, 9 Jun 92 20:16:31 EDT Date: Tue, 9 Jun 92 20:16:30 EDT From: jbm@internet.sbi.com (Jeffrey B. Moore) Message-Id: <9206100016.AA22794@hurricane.sbi.com> Received: by scirocco.sbi.com (4.1/SMI-4.1) id AA02700; Tue, 9 Jun 92 20:16:28 EDT To: bug-lucid-emacs@lucid.com Subject: `all' target in ymakefile? Umm, this may have already been covered (I just subscribed), or I may be betraying my stoopidness, but... in lemacs-19.1/src, shouldn't ymakefile (and thus xmakefile) have an `all' target? I mean, `Makefile' seems to expect it... Of course, `make xemacs' makes stuff happen. -Jeff Moore (jbm@sbi.com) From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 19:40:37 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22177; Tue, 9 Jun 92 19:40:37 PDT Received: by heavens-gate.lucid.com id AA18257g; Tue, 9 Jun 92 19:24:45 PDT Received: from netcom.netcom.com by heavens-gate.lucid.com id AA18253g; Tue, 9 Jun 92 19:24:40 PDT Received: by netcom.netcom.com (4.1/SMI-4.1) id AA09038; Tue, 9 Jun 92 19:32:07 PDT From: ltd@netcom.com (Larry Drebes) Message-Id: <9206100232.AA09038@netcom.netcom.com> Subject: compiling emacs 19.1 To: bug-lucid-emacs@lucid.com Date: Tue, 9 Jun 92 19:32:06 PDT X-Mailer: ELM [version 2.3 PL11] When I attempt to compile lemacs 19.1 on both a sun4 & sun3 I get an unresolved ___main while linking temacs. Using nm, the reference to ___main is made in emacs.o. Where should this be defined? thanks larry- -- From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 19:46:30 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22181; Tue, 9 Jun 92 19:46:30 PDT Received: by heavens-gate.lucid.com id AA18276g; Tue, 9 Jun 92 19:29:59 PDT Received: from wotan.compaq.com (compaq.com) by heavens-gate.lucid.com id AA18272g; Tue, 9 Jun 92 19:29:52 PDT Received: by wotan.compaq.com (/\==/\ Smail3.1.21.1 #21.34) id ; Tue, 9 Jun 92 21:37 CDT Received: by twisto.eng.hou.compaq.com (Smail3.1.21) id ; Tue, 9 Jun 92 21:36 CDT Received: from localhost.eng.hou.compaq.com by akasha.eng.hou.compaq.com (4.1/1.36(MFA-SUN)) id AA00769; Tue, 9 Jun 92 21:36:47 CDT Message-Id: <9206100236.AA00769@akasha.eng.hou.compaq.com> To: bug-lucid-emacs%lucid.com@twisto.eng.hou.compaq.com ( Lucid Emacs Bugs Mailing List ) Subject: Re: Cannot perform malloc error... In-Reply-To: Your message of "Tue, 09 Jun 92 18:24:25 PDT." <9206100124.AA25214@thalidomide.lucid> Date: Tue, 09 Jun 92 21:36:46 -0500 From: ( Colin :) After compiling lemacs with the following environment: GCC-2.2, X11R5 with Motif, on a Sun Sparc 2 running SunOS 4.1.1 I got "Error: cannot perform malloc." when trying to run and test the xemacs. The malloc error does not manifest itself when I compile liblw with only USE_LUCID, but it does manifest itself when I compile liblw with USE_LUCID and USE_MOTIF. Hmmm... Do you need the Xt extentions to compile liblw with Motif? Here is what I was able to find out about the malloc error through GDB traces...(I am not going to dump the whole backtrace on you guys, I'll be nice :-) ). The error happened in the call to lw_create_widget from Fset_screen_menubar. After tracing a little furthur, I discovered that audio_enc_to_str() was calling the gmalloc() and it was bailing out there, but only after the 3rd or 4th call to audio_enc_to_str(). Wierdness. I am going to compile this with liblw as object files so I can get better debug info later... Well, if anyone has any thought on why this is happening, please tell me... Colin ------------------------------------------------------------------------- Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000 e-mail: smiley@compaq.com Phone: (713) 378-8426 ------------------------------------------------------------------------- Disclaimer: Any opinons expressed here do not reflect the opinions of Compaq Computer Corp. They make computers. I make noise. From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 22:16:17 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22239; Tue, 9 Jun 92 22:16:17 PDT Received: by heavens-gate.lucid.com id AA18573g; Tue, 9 Jun 92 22:00:17 PDT Received: from clouso.crim.ca by heavens-gate.lucid.com id AA18569g; Tue, 9 Jun 92 22:00:09 PDT Received: from bond.crim.ca by clouso.crim.ca (4.1/SMI-4.1) id AA23872; Wed, 10 Jun 92 01:08:20 EDT Received: from hammer.crim.ca.crim.ca by bond.crim.ca (4.1/SMI-4.0) id AA17926; Wed, 10 Jun 92 01:08:22 EDT Date: Wed, 10 Jun 92 01:08:22 EDT From: paquette@bond.crim.ca (Marc Paquette) Message-Id: <9206100508.AA17926@bond.crim.ca> Received: by hammer.crim.ca.crim.ca (4.1/SMI-4.1) id AA19555; Wed, 10 Jun 92 01:10:56 EDT To: bug-lucid-emacs@lucid.com In-Reply-To: bug-lucid-emacs-request@lucid.com's message of Tue, 9 Jun 92 22:34:31 EST Subject: compiling emacs 19.1 Larry said: When I attempt to compile lemacs 19.1 on both a sun4 & sun3 I get an unresolved ___main while linking temacs. Using nm, the reference to ___main is made in emacs.o. Where should this be defined? thanks larry- From what I experienced, linking with the GCC gnulib (either libgcc.a or gnu-lib.a, depending on your installation of GCC) fixes this. Is that correct ? Marc Paquette Conseiller Technique, UNIX Centre de recherche informatique de Montreal (CRIM) Tel : (514) 340-5758 Fax : (514) 340-5777 email : paquette@crim.ca From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 22:27:07 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22252; Tue, 9 Jun 92 22:27:07 PDT Received: by heavens-gate.lucid.com id AA18586g; Tue, 9 Jun 92 22:05:54 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA18580g; Tue, 9 Jun 92 22:05:45 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA25279; Tue, 9 Jun 92 22:14:09 PDT Date: Tue, 9 Jun 92 22:14:09 PDT Message-Id: <9206100514.AA25279@thalidomide.lucid> X-Windows: Power tools for power losers. From: Jamie Zawinski Sender: jwz@thalidomide To: paquette%bond.crim.ca@lucid.com (Marc Paquette) Cc: bug-lucid-emacs@lucid.com Subject: Re: compiling emacs 19.1 In-Reply-To: Marc Paquette's message of Wed 10-Jun-92 01:08:22 EDT <9206100508.AA17926@bond.crim.ca> References: <9206100508.AA17926@bond.crim.ca> In message <9206100508.AA17926@bond.crim.ca> Marc Paquette wrote: > > From what I experienced, linking with the GCC gnulib (either libgcc.a > or gnu-lib.a, depending on your installation of GCC) fixes this. > > Is that correct ? From all reports so far, this has been the case. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 22:43:21 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22276; Tue, 9 Jun 92 22:43:21 PDT Received: by heavens-gate.lucid.com id AA18665g; Tue, 9 Jun 92 22:25:44 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA18661g; Tue, 9 Jun 92 22:25:36 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA25327; Tue, 9 Jun 92 22:34:01 PDT Date: Tue, 9 Jun 92 22:34:01 PDT Message-Id: <9206100534.AA25327@thalidomide.lucid> X-Windows: Don't get frustrated without it. From: Jamie Zawinski Sender: jwz@thalidomide To: ( Colin :) Cc: bug-lucid-emacs@lucid.com Subject: Re: Cannot perform malloc error... In-Reply-To: Colin's message of Tue 9-Jun-92 21:36:46 -0500 <9206100236.AA00769@akasha.eng.hou.compaq.com> References: <9206100124.AA25214@thalidomide.lucid> <9206100236.AA00769@akasha.eng.hou.compaq.com> In message <9206100236.AA00769@akasha.eng.hou.compaq.com> Colin wrote: > > The malloc error does not manifest itself when I compile liblw with > only USE_LUCID, but it does manifest itself when I compile liblw with > USE_LUCID and USE_MOTIF. Hmmm... Do you need the Xt extentions to > compile liblw with Motif? You don't need Xt extensions to use USE_MOTIF. Though I don't see why it wouldn't work, there is currently no reason to define both USE_LUCID and USE_MOTIF, since the only thing that lwlib provides right now is the menubar and the popup menus. If you define USE_LUCID, then the Motif code won't be used (or possibly the other way around.) In the future there may be a reason to define both, but there isn't right now. > The error happened in the call to lw_create_widget from > Fset_screen_menubar. After tracing a little furthur, I discovered > that audio_enc_to_str() was calling the gmalloc() and it was bailing > out there, but only after the 3rd or 4th call to audio_enc_to_str(). > Wierdness. I am going to compile this with liblw as object files so I > can get better debug info later... What's audio_enc_to_str? I don't see that anywhere. What system are you compiling on? Perhaps this is a bug in gmalloc. Try using the system malloc instead. Is malloc() being called with reasonable values? -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Tue Jun 9 23:24:18 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22285; Tue, 9 Jun 92 23:24:18 PDT Received: by heavens-gate.lucid.com id AA18769g; Tue, 9 Jun 92 23:09:01 PDT Received: from clouso.crim.ca by heavens-gate.lucid.com id AA18765g; Tue, 9 Jun 92 23:08:54 PDT Received: from bond.crim.ca by clouso.crim.ca (4.1/SMI-4.1) id AA25715; Wed, 10 Jun 92 01:24:33 EDT Received: from hammer.crim.ca.crim.ca by bond.crim.ca (4.1/SMI-4.0) id AA17985; Wed, 10 Jun 92 01:24:36 EDT Date: Wed, 10 Jun 92 01:24:36 EDT From: paquette@bond.crim.ca (Marc Paquette) Message-Id: <9206100524.AA17985@bond.crim.ca> Received: by hammer.crim.ca.crim.ca (4.1/SMI-4.1) id AA19563; Wed, 10 Jun 92 01:27:10 EDT To: bug-lucid-emacs@lucid.com Subject: RE: Help building/using LEMACS ... Charlie S. Lindahl, lindahl@sparki.uta.edu, said: | I'm running under SUNOS 4.1.1 on a Sparcstation 370. I've built EMACS | from source before, so I'm not a "babe in the woods" -- but I don't | get past the first step (make at top level, when it gets to the | "src" directory). Shell transcript appears below. The makefile (more precisely, the file "ymakefile") in $BUILD/src does not contain a target named all. Probably the best thing is to make one like that: all: xemacs Probably it would also be a good idea to put there dependencies for the makefile in $BUILD/src/lwlib and for the library liblw.a. The targets for these two exist, but are not used as dependencies anywhere. I ended up building the things under $BUILD/src/lwlib first, do a "make xemacs" in $BUILD/src and finally do a "make all" under $BUILD. Finally, the instructions in $BUILD/INSTALL should be updated and merged with the instructions in $BUILD/src/README. Note that the latter refers to "../lisp/NEWS" which does not exist: the "NEWS" file is under $BUILD/etc, so from $BUILD/src it is "../etc/NEWS". Marc Paquette Conseiller Technique, UNIX Centre de recherche informatique de Montreal (CRIM) Tel : (514) 340-5758 Fax : (514) 340-5777 email : paquette@crim.ca From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 09:02:06 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22783; Wed, 10 Jun 92 09:02:06 PDT Received: by heavens-gate.lucid.com id AA19790g; Wed, 10 Jun 92 08:38:58 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA19786g; Wed, 10 Jun 92 08:38:48 PDT Received: by moebius.loria.fr id AA04166 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Wed, 10 Jun 92 17:45:19 +0200 Date: Wed, 10 Jun 92 17:45:19 +0200 From: Guido Bosch Message-Id: <9206101545.AA04166@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: substitute-command-keys Maybe this bug has already been reported: The function `substitute-command-keys' doesn't replace correctly \\{mapvar} stings. This is particular anoying for the `describe-mode' command. Take this example (after loading webster.el): webster-mode-map # (map-keymap '(lambda (key cmd) (princ (format "\nKey: %s\tCommand: %s" key cmd))) webster-mode-map) Key: ? Command: describe-mode Key: d Command: webster Key: e Command: webster-endings Key: button2 Command: webster-xref-word Key: q Command: webster-quit Key: s Command: webster-spell nil (substitute-command-keys "\\{webster-mode-map}") "\nbutton2 webster-xref-word\n" -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 09:50:17 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22850; Wed, 10 Jun 92 09:50:17 PDT Received: by heavens-gate.lucid.com id AA19967g; Wed, 10 Jun 92 09:28:53 PDT Received: from wotan.compaq.com (compaq.com) by heavens-gate.lucid.com id AA19963g; Wed, 10 Jun 92 09:28:47 PDT Received: by wotan.compaq.com (/\==/\ Smail3.1.21.1 #21.34) id ; Wed, 10 Jun 92 11:34 CDT Received: by twisto.eng.hou.compaq.com (Smail3.1.21) id ; Wed, 10 Jun 92 11:33 CDT Received: from localhost.eng.hou.compaq.com by akasha.eng.hou.compaq.com (4.1/1.36(MFA-SUN)) id AA02343; Wed, 10 Jun 92 11:33:19 CDT Message-Id: <9206101633.AA02343@akasha.eng.hou.compaq.com> To: bug-lucid-emacs%lucid.com@twisto.eng.hou.compaq.com ( Lucid Emacs Bugs Mailing List ) Subject: what's in a name... Date: Wed, 10 Jun 92 11:33:18 -0500 From: ( Colin :) For as much as I have been able to intuit, lemacs will only come up correctly when named 'xemacs'. Apparently there is some checking to see what lemacs was called when it was invoked. My biggest beef with this is that lemacs gets installed (via 'make install' in $build) as emacs, thus guaranteeing that it will come up and tell you your DISPLAY variable is not set. hmmpf. As for the name, I would rather have it stay xemacs or lemacs, so I can still use the regular emacs and epoch. Now all I have to do is wade through my .emacs stuff and hope I can get things working the same way... Colin ------------------------------------------------------------------------- Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000 e-mail: smiley@compaq.com Phone: (713) 378-8426 ------------------------------------------------------------------------- Disclaimer: Any opinons expressed here do not reflect the opinions of Compaq Computer Corp. They make computers. I make noise. From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 09:59:51 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA22874; Wed, 10 Jun 92 09:59:51 PDT Received: by heavens-gate.lucid.com id AA20008g; Wed, 10 Jun 92 09:32:54 PDT Received: from wotan.compaq.com (compaq.com) by heavens-gate.lucid.com id AA20004g; Wed, 10 Jun 92 09:32:47 PDT Received: by wotan.compaq.com (/\==/\ Smail3.1.21.1 #21.34) id ; Wed, 10 Jun 92 11:38 CDT Received: by twisto.eng.hou.compaq.com (Smail3.1.21) id ; Wed, 10 Jun 92 11:37 CDT Received: from localhost.eng.hou.compaq.com by akasha.eng.hou.compaq.com (4.1/1.36(MFA-SUN)) id AA02381; Wed, 10 Jun 92 11:37:11 CDT Message-Id: <9206101637.AA02381@akasha.eng.hou.compaq.com> To: bug-lucid-emacs%lucid.com@twisto.eng.hou.compaq.com ( Lucid Emacs Bugs Mailing List ) Subject: Oops, I take that back. Date: Wed, 10 Jun 92 11:37:11 -0500 From: ( Colin :) Disregard my last message... My mistake... :-) ------------------------------------------------------------------------- Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000 e-mail: smiley@compaq.com Phone: (713) 378-8426 ------------------------------------------------------------------------- Disclaimer: Any opinons expressed here do not reflect the opinions of Compaq Computer Corp. They make computers. I make noise. From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 12:13:42 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23128; Wed, 10 Jun 92 12:13:42 PDT Received: by heavens-gate.lucid.com id AA20731g; Wed, 10 Jun 92 11:55:38 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA20727g; Wed, 10 Jun 92 11:55:29 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA09926 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Wed, 10 Jun 1992 11:57:55 -0700 Received: by wsrcc.com id AA17548 (5.65c/IDA-1.4.4-WSR-02/03/92 for bug-lucid-emacs@lucid.com); Wed, 10 Jun 1992 11:55:34 -0700 Date: Wed, 10 Jun 1992 11:55:34 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206101855.AA17548@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: sst error msgs Organization: W S Rupprecht Computer Consulting, Fremont CA Sparc / Sunos 4.1 / gcc 2.2 -O2 -fpcc-struct-return / X11R5p12 emacs sounds return a low-level error: audio: sst_open: SETQSIZE" Invalid argument audio: sst_close: SETREG MMR2, Ivalid argument At first I thought this was a structure packing problem with gcc padding the following: struct audio_ioctl { short control; unsigned char data[46]; }; That does not appear to be the case. Element "data" is indeed 2 bytes above element "control" with both gcc and cc. -wolfgang PS. Please cc me in any followups - I may not be on the mailing list yet. --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 12:28:53 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23145; Wed, 10 Jun 92 12:28:53 PDT Received: by heavens-gate.lucid.com id AA20760g; Wed, 10 Jun 92 12:02:04 PDT Received: from math.mit.edu (WEYL.MIT.EDU) by heavens-gate.lucid.com id AA20753g; Wed, 10 Jun 92 12:01:47 PDT Received: from euler (EULER.MIT.EDU) by math.mit.edu (4.1/Math-2.0) id AA27229; Wed, 10 Jun 92 15:01:41 EDT Received: by euler; Wed, 10 Jun 92 15:09:23 EDT Date: Wed, 10 Jun 92 15:09:23 EDT From: richard@math.mit.edu Message-Id: <9206101909.AA02244@euler> To: bug-lucid-emacs@lucid.com Subject: the function `read' does not skip trailing white spaces I use Lucid emacs 19.1. I noticed that the function `read' does not advance the buffer pointer after reading from a buffer, i.e., after (read (current-buffer)) is evaluated. It is easy to show this. Simply select a buffer with either symbols or numbers. Then type `ESC ESC (read (current-buffer)) RET'. You'll notice that the cursor does not go past the white spaces following the expression just read. According to elisp manual version 1.03 under the node "Input Streams", several examples are given which show that `read' moves past the trailing white spaces. ;; ----------------------------------------------- ;; Richard Y. Kim richard@ear.mit.edu ;; (617) 253-8142 (W), (617) 449-7347 (H) From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 13:15:14 1992 Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23206; Wed, 10 Jun 92 13:15:14 PDT Received: by heavens-gate.lucid.com id AA20987g; Wed, 10 Jun 92 12:52:48 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA20983g; Wed, 10 Jun 92 12:52:38 PDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA07577; Wed, 10 Jun 92 15:58:48 -0400 Received: from gagarin.mitre.org by starbase.mitre.org (4.1/SMI-4.1) id AA13253; Wed, 10 Jun 92 15:58:05 EDT Date: Wed, 10 Jun 92 15:58:05 EDT From: duff@starbase.MITRE.ORG (David A. Duff) Message-Id: <9206101958.AA13253@starbase.mitre.org> Received: by gagarin.mitre.org (4.1/SMI-4.1) id AA01256; Wed, 10 Jun 92 16:03:56 EDT To: bug-lucid-emacs@lucid.com Subject: appending ~/.signature to outgoing mail when i didn't ask for it Reply-To: duff@mitre.org i get a .signature file appended to all of my outgoing mail now and i'm not sure why. with essentially the same .emacs file, this did not happen in version 18.57. is there a varaible that controls this? thanks. -- dave duff mitre corporation 703-883-7731 duff@mitre.org ai technical center mclean, va usa From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 13:37:41 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23258; Wed, 10 Jun 92 13:37:41 PDT Received: by heavens-gate.lucid.com id AA21103g; Wed, 10 Jun 92 13:13:55 PDT Received: from physics.wm.edu by heavens-gate.lucid.com id AA21099g; Wed, 10 Jun 92 13:13:45 PDT Received: by physics.wm.edu (4.1/SMI-4.0) id AA00853; Wed, 10 Jun 92 16:19:00 EDT From: ajn@physics.wm.edu (Touch Not The Cat With The Glove) Message-Id: <9206102019.AA00853@physics.wm.edu> Subject: Word wrap problems To: bug-lucid-emacs@lucid.com Date: Wed, 10 Jun 92 16:18:58 EDT X-Mailer: ELM [version 2.3 PL0] we have noticed problems with word wrap when using proportionally spaced fonts. The text that is bumped to the next line is printed over the end of the line above thus garbling the end of the line. Re-drawing the screen has no effect. included are my Xresources for Emacs: Emacs.geometry: 80x40+0-25 Emacs*font:-*-lucida-medium-r-*-*-18-*-*-*-*-*-*-* Emacs*Foreground: SeaGreen1 Emacs*Background: SkyBlue4 Emacs*default.attributeForeground: yellow Emacs*BitMapIcon: on Emacs*default.attributeBackground: dark slate gray Emacs*cursorColor: orange Emacs*pointerColor: deep pink Emacs*default.attributeFont: -*-lucida-medium-r-*-*-18-*-*-*-*-*-*-* Emacs*isearch.attributeForeground: midnight blue Emacs*isearch.attributeBackground: hot pink Emacs*primary-selection.attributeForeground: cyan Emacs*primary-selection.attributeBackground: dark green Emacs*primary-selection.attributeFont: -*-new century schoolbook-*-r-*-*-18-*-*-*-*-*-*-* Emacs*bold.attributeFont: -*-lucida-*-r-*-*-18-*-*-*-*-*-*-* Emacs*italic.attributeFont: -*-lucida-medium-*-*-*-18-*-*-*-*-*-*-* Emacs*bold-italic.attributeFont: -*-lucida-*-*-*-*-18-*-*-*-*-*-*-* Emacs*info-node.attributeForeground: dark slate gray Emacs*info-node.attributeBackground: bisque Emacs*info-node.attributeFont:-*-lucida-medium-r-*-*-18-*-*-*-*-*-*-* Emacs*info-xref.attributeForeground: dark slate gray Emacs*info-xref.attributeBackground: bisque -- +-----------------------------------------------------------------------------+ |..Alastair Neil................................| | |..(804)-221-3533..[ajn@physics.wm.edu].........| None Shall Sleep | +-----------------------------------------------------------------------------+ From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 13:44:42 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23266; Wed, 10 Jun 92 13:44:42 PDT Received: by heavens-gate.lucid.com id AA21139g; Wed, 10 Jun 92 13:20:39 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA21135g; Wed, 10 Jun 92 13:20:33 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA26098; Wed, 10 Jun 92 13:28:54 PDT Date: Wed, 10 Jun 92 13:28:54 PDT Message-Id: <9206102028.AA26098@thalidomide.lucid> From: Jamie Zawinski Sender: jwz@thalidomide To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: sst error msgs In-Reply-To: Wolfgang S. Rupprecht's message of Wed 10-Jun-92 11:55:34 -0700 <199206101855.AA17548@wsrcc.com> References: <199206101855.AA17548@wsrcc.com> In message <199206101855.AA17548@wsrcc.com> Wolfgang S. Rupprecht wrote: > > Sparc / Sunos 4.1 / gcc 2.2 -O2 -fpcc-struct-return / X11R5p12 > > emacs sounds return a low-level error: > audio: sst_open: SETQSIZE" Invalid argument > audio: sst_close: SETREG MMR2, Ivalid argument Try compiling the files libsst.c and play.c with an older gcc, or with Sun's cc, and see if that makes the problem go away. That will tell you whether it's a compiler bug. This could also be a header-file bug. I vaguely remember something like that happening before. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 14:38:02 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23355; Wed, 10 Jun 92 14:38:02 PDT Received: by heavens-gate.lucid.com id AA21405g; Wed, 10 Jun 92 14:13:31 PDT Received: from uu2.psi.com by heavens-gate.lucid.com id AA21401g; Wed, 10 Jun 92 14:12:42 PDT Received: from rutherford.stsi.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA19545; Wed, 10 Jun 92 17:18:43 -0400 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA12519; Wed, 10 Jun 92 17:18:17 EDT Received: from hurricane.sbi.com by sbi.sbi.com (4.1/SMI-4.1) id AA02096; Wed, 10 Jun 92 17:18:17 EDT Received: from scirocco.sbi.com by hurricane.sbi.com (4.1/SMI-4.1) id AA23760; Wed, 10 Jun 92 17:18:14 EDT Date: Wed, 10 Jun 92 17:18:14 EDT From: jbm@internet.sbi.com (Jeffrey B. Moore) Message-Id: <9206102118.AA23760@hurricane.sbi.com> Received: by scirocco.sbi.com (4.1/SMI-4.1) id AA04161; Wed, 10 Jun 92 17:18:13 EDT To: bug-lucid-emacs@lucid.com Subject: xt_extension.h? When I try to compile against olit, src/lwlib/lwlib-Xol.c wants to include "xt_extension.h". I see no such header. In its absence (posibly even because of its absence :)) some symbols are undefined: Undefined _resource_string _XtQString _XtQFontStruct _XtQFont _XtQInt _XtQBoolean _XrmCompileResourceList Hints? -Jeff Moore (jbm@sbi.com) From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 16:08:58 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23487; Wed, 10 Jun 92 16:08:58 PDT Received: by heavens-gate.lucid.com id AA21773g; Wed, 10 Jun 92 15:45:17 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA21763g; Wed, 10 Jun 92 15:44:58 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA02107; Wed, 10 Jun 92 18:53:14 -0400 Received: from edsr.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 185237.14984; Wed, 10 Jun 1992 18:52:37 EDT Received: from tantalum.eds.com (abqtoalh) by edsr.eds.com id AA15606; Wed, 10 Jun 92 16:05:21 CDT Received: from arsenic.eds.com by tantalum.eds.com (4.1/ALBUQUERQUE-1.1) id AA25512; Wed, 10 Jun 92 15:05:28 MDT Received: by arsenic.eds.com (4.1/ALBSUB-1.3) id AA04898; Wed, 10 Jun 92 15:05:26 MDT Date: Wed, 10 Jun 92 15:05:26 MDT From: edsr!tantalum!cheeks@uunet.UU.NET (Mark Costlow) Message-Id: <9206102105.AA04898@arsenic.eds.com> To: bug-lucid-emacs@lucid.com Subject: add Please add lemacs-bugs@edsr.eds.com to this list. Thanks, Mark -- cheeks@edsr.eds.com or ...uunet!edsr!cheeks From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 17:50:03 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23599; Wed, 10 Jun 92 17:50:03 PDT Received: by heavens-gate.lucid.com id AA22282g; Wed, 10 Jun 92 17:30:04 PDT Received: from watergate.lucid ([192.31.212.117]) by heavens-gate.lucid.com id AA22278g; Wed, 10 Jun 92 17:29:54 PDT Received: by watergate.lucid (4.1/SMI-4.1) id AA24020; Wed, 10 Jun 92 17:38:18 PDT Date: Wed, 10 Jun 92 17:38:18 PDT From: eb@watergate (Eric Benson) Message-Id: <9206110038.AA24020@watergate.lucid> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: sst error msgs In-Reply-To: Jamie Zawinski's message of Wed 10-Jun-92 13:28:54 PDT <9206102028.AA26098@thalidomide.lucid> References: <199206101855.AA17548@wsrcc.com> <9206102028.AA26098@thalidomide.lucid> In message <9206102028.AA26098@thalidomide.lucid> Jamie Zawinski wrote: > > In message <199206101855.AA17548@wsrcc.com> Wolfgang S. Rupprecht > wrote: >> >> Sparc / Sunos 4.1 / gcc 2.2 -O2 -fpcc-struct-return / X11R5p12 >> >> emacs sounds return a low-level error: >> audio: sst_open: SETQSIZE" Invalid argument >> audio: sst_close: SETREG MMR2, Ivalid argument > > Try compiling the files libsst.c and play.c with an older gcc, or > with Sun's cc, and see if that makes the problem go away. That will > tell you whether it's a compiler bug. > > This could also be a header-file bug. I vaguely remember something > like that happening before. > > -- Jamie I recognize this problem. It's due to AUDIOSETQSIZE in /usr/include/sun/audioio.h using _IOW, which in turn is defined using an ANSI-incompatible preprocessor feature (substitution into a character constant). The installation guide for gcc has information about converting system include files for ANSI preprocessing. From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 18:30:47 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23616; Wed, 10 Jun 92 18:30:47 PDT Received: by heavens-gate.lucid.com id AA22417g; Wed, 10 Jun 92 18:10:59 PDT Received: from romulus.reed.edu (reed.edu) by heavens-gate.lucid.com id AA22413g; Wed, 10 Jun 92 18:10:51 PDT Received: from local by romulus.reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 10 Jun 92 18:19 PDT Message-Id: Date: Wed, 10 Jun 92 18:19 PDT From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: building lucid emacs on Ultrix 4.2 Has anyone successfully built lemacs on DECstations running Ultrix 4.2? I'm using gcc, and have had some troubles, some trivial, some not so trivial: several buglets in the make distribution, especially convincing all the various directories to use gcc for their compiler. there needs to be a global configure. one ultrix-specific problem in src/faces.c - you have to include sys/types.h before including sys/stat.h. This is because Ultrix sucks. link trouble with temacs. I haven't successfully made it link, yet, though I'm close. I'm using "ld" to link and am explicity linking libgcc.a to provide an __main (and hoping that I don't collide with precrt0.c). I'm also linking against libcursesX.a and libtermcap.a, and doing that, I've got all the functions but strdup, realpath, and remainder. I can write strdup, I can fake remainder from fmod, and realpath, well, I'm just going to stub it. If anyone has gotten lemacs to work under Ultrix, I'd love to hear how. If anyone knows where I can find free copies of strdup, realpath, and remainder, I could use them. I seem to remember that some gnu tool provided realpath, but I can't find it now.. how did emacs 18 do canonical path resolution? Bleah. From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 18:38:51 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23634; Wed, 10 Jun 92 18:38:51 PDT Received: by heavens-gate.lucid.com id AA22443g; Wed, 10 Jun 92 18:19:49 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA22439g; Wed, 10 Jun 92 18:19:41 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA26913; Wed, 10 Jun 92 18:28:06 PDT Date: Wed, 10 Jun 92 18:28:06 PDT Message-Id: <9206110128.AA26913@thalidomide.lucid> X-Windows: Complex nonsolutions to simple nonproblems. From: Jamie Zawinski Sender: jwz@thalidomide To: nelson@reed.edu (Nelson Minar) Cc: bug-lucid-emacs@lucid.com Subject: Re: building lucid emacs on Ultrix 4.2 In-Reply-To: Nelson Minar's message of Wed 10-Jun-92 18:19 PDT References: In message Nelson Minar wrote: > > I'm also linking against libcursesX.a and libtermcap.a, and doing that, I've > got all the functions but strdup, realpath, and remainder. I can write > strdup, I can fake remainder from fmod, and realpath, well, I'm just going > to stub it. > > If anyone has gotten lemacs to work under Ultrix, I'd love to hear how. > If anyone knows where I can find free copies of strdup, realpath, and > remainder, I could use them. I seem to remember that some gnu tool provided > realpath, but I can't find it now.. For the next release, I've included a definition of strdup(), and have gotten a version of realpath() with the UCB copyright. But if there is a GNU version of strdup, that would be better; if anyone knows for sure, let me know. > how did emacs 18 do canonical path resolution? Bleah. It didn't. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 18:55:08 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23650; Wed, 10 Jun 92 18:55:08 PDT Received: by heavens-gate.lucid.com id AA22524g; Wed, 10 Jun 92 18:35:17 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA22520g; Wed, 10 Jun 92 18:35:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA27047; Wed, 10 Jun 92 18:43:37 PDT Date: Wed, 10 Jun 92 18:43:37 PDT Message-Id: <9206110143.AA27047@thalidomide.lucid> X-Windows: Even your dog won't like it. From: Jamie Zawinski Sender: jwz@thalidomide To: bug-lucid-emacs@lucid.com Subject: volunteer sought... One of the things that would help a lot would be if someone would go over the 18.55->18.58 diffs, and see where our s/s-* and m/m-* files differ. (And process.c too, I guess.) Because of the co-development that has been going on with the v18 and v19 branches of emacs, there are no doubt places where FSF's v18 is "ahead" of our v19. I don't have time to do this myself, but it would be of great value to all those poor souls trying to compile this emacs on non-SparcStations. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 19:56:06 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23679; Wed, 10 Jun 92 19:56:06 PDT Received: by heavens-gate.lucid.com id AA22662g; Wed, 10 Jun 92 19:33:11 PDT Received: from vishnu.reed.edu by heavens-gate.lucid.com id AA22658g; Wed, 10 Jun 92 19:33:03 PDT Received: from local by vishnu.reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 10 Jun 92 19:41 PDT Message-Id: Date: Wed, 10 Jun 92 19:41 PDT From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: lucid emacs and Ultrix 4.2 - links, doesn't run Well, I coerced lucid emacs into linking under Ultrix 4.2. The actual things I did to make it link I'll mention below. Basically what I did was provide my own strdup(), realpath(), and remainder(), and then link against cursesX and the emacs version of termcap.o. It linked! But it doesn't run. I run it, and I get some ugly sort-of emacs buffer on the xterm I'm running it under and the message: This version of emacs only runs under X Windows (for now). Check that your $DISPLAY environment variable is properly set. but my DISPLAY environment is set properly and the machine I'm running it from has permission to open my display. emacs 18.58 has no trouble starting up as an X client, lemacs does. We're running vanilla MIT X11r5 (at a fairly low patch level), not DECwindows. I tried to figure out where in the code the error was coming from, but it looks like that requires more knowledge of the lemacs internals than I have time for. Basically, the "event_stream" variable isn't getting set correctly, but finding where it is supposed to be set is too frightening. Here's the command I used to make it link. First I had to use libgcc.a to get __main (because I was building with gcc). I had to use termcap.o from emacs and link against cursesX, not curses (for the tparm() function, I think). I also tried linking it with Ultrix's libtermcap.a instead of termcap.o, and while it linked it didn't work. Finally, nelsonHack.o are 3 functions missing from the Ultrix libraries. ld -L. -L./lwlib -o temacs pre-crt0.o /lib/crt0.o dispnew.o screen.o scroll.o xdisp.o window.o events.o event-alloc.o event-stream.o term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexmips.o mocklisp.o bytecode.o process.o callproc.o environ.o doprnt.o extents.o faces.o elhash.o hash.o terminfo.o lastfile.o gmalloc.o vm-limit.o alloca.o ScreenWidget.o ColumnWidget.o EmacsShell.o nelsonHack.o termcap.o /local/lib/gcc-lib/mips-dec-ultrix/2.2/libgcc.a -llw -lXaw -lXext -lXt -lXmu -lX11 -lcursesX -lm -lc here's nelsonHack.c... strdup() comes from libiberty that comes with gdb 4.5. remainder() and realpath() are my own (broken) things. Could someone send me a working free realpath()? How about remainder()? The sun man pages make it sound like the difference between fmod() and remainder() is fairly subtle, but it concerns me. char * strdup(); double remainder(); char * realpath(); /* this is from libiberty */ char * strdup(s) char *s; { char *result = (char*)malloc(strlen(s) + 1); if (result == (char*)0) return (char*)0; strcpy(result, s); return result; } /* nelson hack. This is wrong, but close */ double remainder(x, y) double x; double y; { return fmod(x, y); } /* nelson hack. This is more wrong, but who gives a fish? */ char * realpath(path, resolved_path) char * path; char * resolved_path; { strcpy(path, resolved_path); return resolved_path; } From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 19:57:36 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23683; Wed, 10 Jun 92 19:57:36 PDT Received: by heavens-gate.lucid.com id AA22671g; Wed, 10 Jun 92 19:37:08 PDT Received: from vishnu.reed.edu by heavens-gate.lucid.com id AA22667g; Wed, 10 Jun 92 19:36:59 PDT Received: from local by vishnu.reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Wed, 10 Jun 92 19:45 PDT Message-Id: Date: Wed, 10 Jun 92 19:45 PDT From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: addendum to lucid emacs / ultrix 4.2 runtime trouble Oh, I should mention that I've built the lwlib with the following options in the Imakefile: #define USE_LUCID /* #define USE_MOTIF */ /* #define USE_OLIT */ /* #define INCLUDE_EXTENSIONS */ ie: none of the Xt enhancements, and use the Lucid-provided widgets. From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 22:56:11 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23730; Wed, 10 Jun 92 22:56:11 PDT Received: by heavens-gate.lucid.com id AA22947g; Wed, 10 Jun 92 22:33:30 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA22943g; Wed, 10 Jun 92 22:33:21 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA19059 (5.65c/IDA-1.4.4); Wed, 10 Jun 1992 22:35:48 -0700 Received: by wsrcc.com id AA24719 (5.65c/IDA-1.4.4-WSR-02/03/92); Wed, 10 Jun 1992 22:33:38 -0700 Date: Wed, 10 Jun 1992 22:33:38 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206110533.AA24719@wsrcc.com> To: eb%watergate@lucid.com (Eric Benson) Cc: bug-lucid-emacs@lucid.com Subject: Re: sst error msgs In-Reply-To: <9206110038.AA24020@watergate.lucid> References: <199206101855.AA17548@wsrcc.com> <9206102028.AA26098@thalidomide.lucid> <9206110038.AA24020@watergate.lucid> Organization: W S Rupprecht Computer Consulting, Fremont CA Eric Benson writes: > I recognize this problem. It's due to AUDIOSETQSIZE in > /usr/include/sun/audioio.h using _IOW, which in turn is defined using > an ANSI-incompatible preprocessor feature (substitution into a > character constant). The installation guide for gcc has information > about converting system include files for ANSI preprocessing. Bingo! (notice the 'x') sys/ioccom.h:28:#define _IOW(x,y,t) (_IOC_IN|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y) sys/ioccom.h:29:#define _IOWN(x,y,t) (_IOC_IN|(((t)&_IOCPARM_MASK)<<16)|('x'<<8)|y) sys/ioccom.h:31:#define _IOWR(x,y,t) (_IOC_INOUT|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y) sys/ioccom.h:32:#define _IOWRN(x,y,t) (_IOC_INOUT|(((t)&_IOCPARM_MASK)<<16)|('x'<<8)|y) -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Wed Jun 10 23:29:19 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA23755; Wed, 10 Jun 92 23:29:19 PDT Received: by heavens-gate.lucid.com id AA22994g; Wed, 10 Jun 92 23:09:37 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA22990g; Wed, 10 Jun 92 23:09:28 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA19546 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Wed, 10 Jun 1992 23:11:57 -0700 Received: by wsrcc.com id AA24935 (5.65c/IDA-1.4.4-WSR-02/03/92 for list-lucid-emacs-bug@wsrcc.com); Wed, 10 Jun 1992 23:08:53 -0700 Newsgroups: list.lucid-emacs.bug Path: wolfgang From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: building lucid emacs on Ultrix 4.2 Message-Id: Organization: W S Rupprecht Computer Consulting, Fremont CA References: <9206110128.AA26913@thalidomide.lucid> Distribution: wsrcc-net Date: Thu, 11 Jun 1992 06:08:48 GMT Apparently-To: list-lucid-emacs-bug@wsrcc.com In message Nelson Minar wrote: >I can fake remainder from fmod, I think 4.2 called "remainder" "drem". You might want to do a quick check under that name. Just for grins, here is the original code: DEFUN ("%", Frem, Srem, 2, 2, 0, "Returns remainder of first arg divided by second.") (num1, num2) register Lisp_Object num1, num2; { Lisp_Object val; #ifdef LISP_FLOAT_TYPE CHECK_NUMBER_OR_FLOAT (num1, 0); CHECK_NUMBER_OR_FLOAT (num2, 0); if ((XTYPE(num1) == Lisp_Float) || (XTYPE(num2) == Lisp_Float)) { double f1, f2; f1 = (XTYPE(num1) == Lisp_Float) ? XFLOAT(num1)->data : XINT(num1); f2 = (XTYPE(num2) == Lisp_Float) ? XFLOAT(num2)->data : XINT(num2); return (make_float(drem(f1,f2))); } #else CHECK_NUMBER (num1, 0); CHECK_NUMBER (num2, 1); #endif LISP_FLOAT_TYPE XSET (val, Lisp_Int, XINT (num1) % XINT (num2)); return val; } -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 01:19:10 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24055; Thu, 11 Jun 92 01:19:10 PDT Received: by heavens-gate.lucid.com id AA23151g; Thu, 11 Jun 92 00:44:40 PDT Received: from chx400.switch.ch by heavens-gate.lucid.com id AA23147g; Thu, 11 Jun 92 00:44:31 PDT X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Thu, 11 Jun 1992 09:52:30 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Thu, 11 Jun 1992 10:52:09 +0200 Date: Thu, 11 Jun 1992 10:52:09 +0200 X400-Originator: warkent@ltisun9.epfl.ch X400-Recipients: bug-lucid-emacs@lucid.com X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9206110752.AA10727] X400-Content-Type: P2-1984 (2) From: "(Ken Warkentyne)" Message-Id: <9206110752.AA10727@ltisun9.epfl.ch> To: bug-lucid-emacs@lucid.com Subject: problem linking gcc compiled files Received: from ltisun9.epfl.ch by SIC.Epfl.CH via INTERNET ; Thu, 11 Jun 92 09:51:08 N Received: by ltisun9.epfl.ch (4.1/Epfl-3.1/MX) id AA10727; Thu, 11 Jun 92 09:52:09 +0200 System: Sparc 2 running SunOS4.1.1 Compiler: gcc-2.2.1 First of all, entering "make" in the main directory does not work. It seems that one has to go into the directory src and enter "make xemacs". After doing this, all the .c files compile, but the linking stage fails with an undefined symbol. The messages at the end of the make are as follows: > ld -e __start -Bstatic -L. -L./lwlib -o temacs crt0.o ... > Undefined > ___main > *** Error code 2 > make: Fatal error: Command failed for target `temacs' > Current working directory /usr/public/src/editors/lucid_emacs/lemacs-19.1/src > *** Error code 1 > make: Fatal error: Command failed for target `doxemacs' The ld is the standard one that is supplied by the Sun OS. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 01:46:39 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24084; Thu, 11 Jun 92 01:46:39 PDT Received: by heavens-gate.lucid.com id AA23250g; Thu, 11 Jun 92 01:26:35 PDT Received: from vishnu.reed.edu by heavens-gate.lucid.com id AA23246g; Thu, 11 Jun 92 01:26:28 PDT Received: from local by vishnu.reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Thu, 11 Jun 92 01:34 PDT Message-Id: Date: Thu, 11 Jun 92 01:34 PDT From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: Re: problem linking gcc compiled files I'm not sure this is correct, but it's worth a shot: >First of all, entering "make" in the main directory does not work. >It seems that one has to go into the directory src and enter "make xemacs". is this the "nothing to do for target all:" message? The xmakefile I was generating didn't have an all: entry in it - I added "all: xemacs" to mine. doing a "make -f xmakefile xemacs" is equivalent. >ld -e __start -Bstatic -L. -L./lwlib -o temacs crt0.o ... >Undefined >___main I'd guess this is because you were compiling with gcc, which uses a weird __main function, but linking with ld, which knows nothing about it. A quick hack to try to fix this is to add "libgcc.a" (or the complete path to it - somewhere down in the gcc libaries) near the end of the line to "ld" - it should pick up __main from there. Another thing to try is to link using "gcc" instead of "ld" - I'd be wary of that, though, as emacs links funny. but who am I to talk? I can't even make the blasted thing work under Ultrix.. never manages to open a window. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 01:53:29 1992 Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24092; Thu, 11 Jun 92 01:53:29 PDT Received: by heavens-gate.lucid.com id AA23273g; Thu, 11 Jun 92 01:31:53 PDT Received: from srawgw.sra.co.jp by heavens-gate.lucid.com id AA23269g; Thu, 11 Jun 92 01:31:40 PDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA02818; Thu, 11 Jun 92 17:39:20 +0900 Received: from srarc2.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA04179; Thu, 11 Jun 92 17:39:13 +0900 Received: by srarc2.sra.co.jp (5.61/6.4J.6-SJ) id AA19326; Thu, 11 Jun 92 17:39:28 +0900 Date: Thu, 11 Jun 92 17:39:28 +0900 From: hikichi@srarc2.sra.co.jp (Nobuyuki Hikichi) Return-Path: Message-Id: <9206110839.AA19326@srarc2.sra.co.jp> To: bug-lucid-emacs@lucid.com Subject: report to try to port Sony NEWS(MIPS based) Reply-To: hikichi@sra.co.jp I tried to port lemacs 19.1 to Sony News(MIPS) version 4.1(I attached the machine file in the end of this mail). I can compile without error bug it did not startup. I cannot find why not. Anyway I need following change to compile. So I report it. * data.c: For machine without remainder. I use fmod instead of it. * faces.c: To avoid the error message(undefined symbol for xxx_t). * ymakefile: Source code directory has not these files(filehdr.h, aouthdr.h, scnhdr.h and sym.h). Does anyone try to port other BSD based machine? Name: Nobuyuki Hikichi Office: Software Research Associates, Inc. Japan. gnu@srarc2 $ diff -u3 data.c~ data.c --- data.c~ Wed Apr 29 13:31:44 1992 +++ data.c Wed Jun 10 14:00:56 1992 @@ -1512,7 +1512,11 @@ f1 = XTYPE (num1) == Lisp_Float ? XFLOAT (num1)->data : XINT (num1); f2 = XTYPE (num2) == Lisp_Float ? XFLOAT (num2)->data : XINT (num2); +#ifdef NO_REMAINDER + return (make_float (fmod (f1,f2))); +#else return (make_float (remainder (f1,f2))); +#endif } #else /* not LISP_FLOAT_TYPE */ CHECK_NUMBER_COERCE_MARKER (num1, 0); gnu@srarc2 $ diff -u3 faces.c~ faces.c --- faces.c~ Sun May 24 16:20:09 1992 +++ faces.c Wed Jun 10 11:50:35 1992 @@ -15,6 +15,7 @@ along with GNU Emacs; see the file COPYING. If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include #include #include "config.h" gnu@srarc2 $ diff -u3 ymakefile~ yamakefile diff: yamkefile: No such file or directory gnu@srarc2 $ diff -u3 ymakefile~ ymakefile diff: yamakefile: No such file or directory gnu@srarc2 $ diff -u3 ymakefile~ ymakefile --- ymakefile~ Wed Jun 10 11:21:46 1992 +++ ymakefile Wed Jun 10 11:38:41 1992 @@ -714,8 +714,7 @@ unexconvex.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h getpagesize.h unexec.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h getpagesize.h unexenix.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h -unexmips.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h filehdr.h -unexmips.o: aouthdr.h scnhdr.h sym.h +unexmips.o: config.h unexsunos4.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h vm-limit.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h mem_limits.h vm-limit.o: #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 06/11/1992 08:30 UTC by gnu@srarc2 # Source directory /a/ext12/fs/local2/gnu/src/lemacs-19.1/src # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 639 -rw-r--r-- m/m-risc-news.h # # ============= m/m-risc-news.h ============== if test ! -d 'm'; then echo 'x - creating directory m' mkdir 'm' fi if test -f 'm/m-risc-news.h' -a X"$1" != X"-c"; then echo 'x - skipping m/m-risc-news.h (File already exists)' else echo 'x - extracting m/m-risc-news.h (Text)' sed 's/^X//' << 'SHAR_EOF' > 'm/m-risc-news.h' && #include "m-mips.h" #undef LIBS_MACHINE X #define LIBS_MACHINE -lmld X #define COFF #undef LD_SWITCH_MACHINE #define LD_SWITCH_MACHINE -x -D 800000 X /* more pure Lisp code area when risc machine. */ #define RISC X #if 0 #define PURESIZE 142000 /* (122000 + MORE) MORE=20000 */ #endif /* 0 */ X /* #define C_OPTIMIZE_SWITCH -O2 */ #define C_OPTIMIZE_SWITCH -O X #define C_DEBUG_SWITCH -g3 X /* Define BIG_ENDIAN iff lowest-numbered byte in a word X is the most significant byte. */ X /* done in endian.h: #define BIG_ENDIAN */ /* so need to undef to avoid the confilict in wait.h */ #undef BIG_ENDIAN */ X #undef TERMINFO X #define NO_REMAINDER SHAR_EOF chmod 0644 m/m-risc-news.h || echo 'restore of m/m-risc-news.h failed' Wc_c="`wc -c < 'm/m-risc-news.h'`" test 639 -eq "$Wc_c" || echo 'm/m-risc-news.h: original size 639, current size' "$Wc_c" fi exit 0 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 02:09:50 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24106; Thu, 11 Jun 92 02:09:50 PDT Received: by heavens-gate.lucid.com id AA23308g; Thu, 11 Jun 92 01:49:50 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA23304g; Thu, 11 Jun 92 01:49:32 PDT Received: by moebius.loria.fr id AA05410 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 92 10:55:38 +0200 Date: Thu, 11 Jun 92 10:55:38 +0200 From: Guido Bosch Message-Id: <9206110855.AA05410@moebius.loria.fr> To: duff@mitre.org Cc: bug-lucid-emacs@lucid.com Subject: appending ~/.signature to outgoing mail when i didn't ask for it In-Reply-To: <9206101958.AA13253@starbase.mitre.org> References: <9206101958.AA13253@starbase.mitre.org> Reply-To: Guido BOSCH David A. Duff writes: > i get a .signature file appended to all of my outgoing mail now and i'm > not sure why. > > with essentially the same .emacs file, this did not happen in version > 18.57. > > is there a varaible that controls this? > There is, but is has to be placed in the mail-setup-hook, and it should be considered rather a as a hack than a custommization. (add-hook 'mail-setup-hook '(lambda () (setq mail-signature-inserted t))) -- Guido From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 07:17:29 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24217; Thu, 11 Jun 92 07:17:29 PDT Received: by heavens-gate.lucid.com id AA23720g; Thu, 11 Jun 92 06:52:45 PDT Received: from sapir.cog.jhu.edu by heavens-gate.lucid.com id AA23716g; Thu, 11 Jun 92 06:52:34 PDT Received: from localhost by sapir.cog.jhu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA05880; Thu, 11 Jun 92 10:00:21 EDT Message-Id: <9206111400.AA05880@sapir.cog.jhu.edu> To: bug-lucid-emacs@lucid.com Subject: Help building lemacs on NeXT Date: Thu, 11 Jun 92 10:00:20 -0400 From: anderson@sapir.cog.jhu.edu I'm trying to bring up lemacs-19.1 on my NeXT (with PenCom's co-Xist X11R4 environment: I'm not quite ready to port it to NeXTstep yet....). I took the emacs-18.57 sources for NeXT and changed all of the files in the lemacs-19.1/src directory that had been modified in the 18.57 sources; added s/s-mach.h and m/m-NeXT.h, and unexNeXT.c. After setting up the config files, I built liblw.a (had to remove the #include statement from lwlib.c for NeXT-specific reasons, but that didn't seem to cause any problem). Then I went to the src directory to make xemacs. Things go along fine for a while, but I get an error I can't figure out when it gets to the point of making the target "$(environobj)". Can anyone help me? I've included the output from make below. --Steve Anderson sapir:/LocalSrc/lemacs-19.1/src zsh [182]% make xemacs rm -f xmakefile cp ymakefile junk.c cc -E junk.c | sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > xmakefile rm -f junk.c make -f xmakefile xemacs cc -g -Demacs -I./lwlib -c pre-crt0.c cc -g -Demacs -I./lwlib -c dispnew.c cc -g -Demacs -I./lwlib -c screen.c cc -g -Demacs -I./lwlib -c scroll.c cc -g -Demacs -I./lwlib -c xdisp.c xdisp.c: In function get_glyph_dimensions: xdisp.c:3728: warning: assignment of pointer from integer lacks a cast cc -g -Demacs -I./lwlib -c window.c cc -g -Demacs -I./lwlib -c events.c cc -g -Demacs -I./lwlib -c event-alloc.c cc -g -Demacs -I./lwlib -c event-stream.c cc -g -Demacs -I./lwlib -c term.c cc -g -Demacs -I./lwlib -c cm.c cc -g -Demacs -I./lwlib -c xterm.c /usr/include/sys/param.h:41: warning: BSD redefined /usr/include/sys/param.h:42: warning: BSD4_3 redefined /usr/include/sys/param.h:280: warning: FSCALE redefined xterm.c: In function x_write_glyphs: xterm.c:435: warning: assignment of pointer from integer lacks a cast cc -g -Demacs -I./lwlib -c xfns.c xfns.c: In function Fx_get_resource: xfns.c:1528: warning: assignment of pointer from integer lacks a cast xfns.c:1530: warning: assignment of pointer from integer lacks a cast cc -g -Demacs -I./lwlib -c xselect.c cc -g -Demacs -I./lwlib -c xutils.c cc -g -Demacs -I./lwlib -c event-Xt.c cc -g -Demacs -I./lwlib -c menubar.c /usr/include/sys/signal.h:140: warning: sigmask redefined cc -g -Demacs -I./lwlib -c emacs.c emacs.c: In function find_executable_name: emacs.c:403: warning: assignment of pointer from integer lacks a cast cc -g -Demacs -I./lwlib -c keyboard.c cc -g -Demacs -I./lwlib -c macros.c cc -g -Demacs -I./lwlib -c keymap.c cc -g -Demacs -I./lwlib -c sysdep.c cc -g -Demacs -I./lwlib -c buffer.c cc -g -Demacs -I./lwlib -c filelock.c cc -g -Demacs -I./lwlib -c insdel.c cc -g -Demacs -I./lwlib -c marker.c cc -g -Demacs -I./lwlib -c minibuf.c cc -g -Demacs -I./lwlib -c fileio.c /usr/include/sys/param.h:41: warning: BSD redefined print.c:425: warning: assignment of pointer from integer lacks a cast print.c: In function Fprin1_to_string: print.c:449: warning: assignment of pointer from integer lacks a cast print.c: In function Fprinc: print.c:482: warning: assignment of pointer from integer lacks a cast print.c: In function Fprint: print.c:508: warning: assignment of pointer from integer lacks a cast cc -g -Demacs -I./lwlib -c lread.c cc -g -Demacs -I./lwlib -c abbrev.c cc -g -Demacs -I./lwlib -c syntax.c cc -g -Demacs -I./lwlib -c unexNeXT.c cc -g -Demacs -I./lwlib -c mocklisp.c cc -g -Demacs -I./lwlib -c bytecode.c cc -g -Demacs -I./lwlib -c process.c cc -g -Demacs -I./lwlib -c callproc.c pswrap -o m .pswm pswrap: can't open .pswm for input *** Exit 1 Stop. *** Exit 1 Stop. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 08:00:49 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24242; Thu, 11 Jun 92 08:00:49 PDT Received: by heavens-gate.lucid.com id AA23809g; Thu, 11 Jun 92 07:32:10 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA23805g; Thu, 11 Jun 92 07:31:59 PDT Received: from ingr.ingr.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05357; Thu, 11 Jun 92 10:40:09 -0400 Received: by ingr.ingr.com (5.61/INGR-1.1) id AA03854; Thu, 11 Jun 92 09:44:45 -0500 Received: from simpson.turtles by turtles (4.1/SMI-4.1) id AA14375; Thu, 11 Jun 92 17:25:29 IDT Received: by simpson.turtles (4.1/SMI-4.1) id AA11445; Thu, 11 Jun 92 17:25:43 IDT From: matis!amir@uunet.UU.NET (Amir Katz) Message-Id: <9206111425.AA11445@simpson.turtles> Subject: Can't load a file To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Thu, 11 Jun 92 17:25:41 EET DST Organization: SEE Technologies Ltd. Reply-To: matis!ingr.COM!amir%matis.UUCP@uunet.UU.NET X-Mailer: ELM [version 2.3 PL11] Lucid Emacs Gurus, I'm running the pre-cooked emacs for Sun-4. I have the following lines in my .emacs: (setq my-home-dir (getenv "HOME")) (setq my-own-prog-dir (concat my-home-dir "/emacs-progs/")) (setq load-path (cons my-own-prog-dir load-path)) ... (defvar is-lucid-emacs (string-match "Lucid" emacs-version) "*Set to t if it is Lucid/GNU Emacs.") ... (if is-lucid-emacs (load "lucid-sun-kdb.elc")) but Lucid-Emacs gives me an error when loading this file (message split for clarity): Error in init file: File error: "Cannot open load file" \ "lucid-sun-kdb.elc" All other files that are loaded earlier or later in .emacs do not cause any problems. They are all in the same directory. I byte-compiled it both under GNU emacs 18.58 and under Lucid-Emacs 19.1, but it didn't make a difference. The file contains function keys programming. e.g.: (define-key global-map [(f21)] 'repeat-complex-command) Manually loading the file (M-x load-file ...) works just fine. Any hints? Thanks & please respond to the address below. -- /* Amir J. Katz | UUCP: uunet!ingr!matis!amir */ /* System Specialist | Internet: amir%matis.UUCP@ingr.COM */ /* SEE Technologies Ltd. | Voice: +972 52-584684, Fax: +972 52-543917 */ From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 08:51:34 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24299; Thu, 11 Jun 92 08:51:34 PDT Received: by heavens-gate.lucid.com id AA23914g; Thu, 11 Jun 92 08:25:06 PDT Received: from CAMIS.Stanford.EDU by heavens-gate.lucid.com id AA23910g; Thu, 11 Jun 92 08:24:59 PDT Received: from mcs-ipc-3.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA01681; Thu, 11 Jun 92 08:33:14 PDT Date: Thu, 11 Jun 1992 08:22:27 -0700 (PDT) From: Kevin Brock Reply-To: Brock@sumex-aim.stanford.edu Subject: RE: Building Emacs with Sun 'acc' To: matis!ingr.COM!amir%matis.UUCP@uunet.UU.NET Cc: bug-lucid-emacs@lucid.com, simpson!amir@uunet.UU.NET In-Reply-To: matis!amir@uunet.UU.NET's message of Thu, 11 Jun 92 14:58:15 EET DST: <9206111158.AA10136@simpson.turtles> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >My setup is: >- Sun SparcStation 1+, GX frame buffer (cg6) >- SunOS 4.1.2 (no patches) >- MIT X11R5, patch level 12 >- ICS Motif/mwm >- Sun's unbundled ANSI C compiler (version SC1.0). That's essentially what I tried it with the first time that I attempted the build. Different Motif, but otherwise the same. [ build probs deleted ] >(gdb) run >Starting program: /files/lemacs-19.1/src/emacs-19.1-Lucid > >Program received signal 11, Segmentation fault >0x7e5f0 in Fmake_marker () at alloc.c:801 >801 string_free_list = (struct Lisp_String *)string_free_list->dup_list; >(gdb) bt >#0 0x7e5f0 in Fmake_marker () at alloc.c:801 >#1 0x7e914 in Fmake_marker () at alloc.c:884 >#2 0x7ec54 in make_string () at alloc.c:942 >#3 0xb2524 in set_environment_alist () at environ.c:66 >#4 0xb2d10 in init_environ () at environ.c:313 >#5 0x4f460 in main () at emacs.c:706 > >(gdb) p *string_free_list >$1 = {size = 0, dup_list = 2801096, data = 0x0} I looked into this a little more, and found lots of symtoms, but no final solution. The global variable 'initialized' in emacs.c gets initialized to 1, not 0 for some reason. Even when I explicitly try to set it this happens. Thus the init_alloc_once() doesn't get called, and init_strings() doesn't get called. I believe this is the source of *your* error. If I forced initialized to 0 before it was checked I got a bus error down in init_strings(). At that point I gave up and used gcc. lemacs clearly isn't strict ANSI C, and from the number of warnings I got, it doesn't look like I'll have time to make the port. Kevin Brock brock@sumex-aim.stanford.edu From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 10:00:15 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24387; Thu, 11 Jun 92 10:00:15 PDT Received: by heavens-gate.lucid.com id AA24100g; Thu, 11 Jun 92 09:26:54 PDT Received: from sapir.cog.jhu.edu by heavens-gate.lucid.com id AA24093g; Thu, 11 Jun 92 09:26:38 PDT Received: from localhost by sapir.cog.jhu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA07443; Thu, 11 Jun 92 12:34:29 EDT Message-Id: <9206111634.AA07443@sapir.cog.jhu.edu> To: bug-lucid-emacs@lucid.com Subject: More on bringing lemacs to NeXT Date: Thu, 11 Jun 92 12:34:29 -0400 From: anderson@sapir.cog.jhu.edu To fix (or at least avoid) the problem I reported earlier with the target $(environobj) while making xemacs, I tried undefining MAINTAIN_ENVIRONMENT. This time I got everything to compile, but now get errors from ld. Can someone point me to the nature of this problem (and ideally its solution)? Thanks for any help, --Steve Anderson ld: multiple definitions of symbol _realloc gmalloc.o definition of _realloc in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _realloc (value 0x5002d7a) ld: multiple definitions of symbol _malloc gmalloc.o definition of _malloc in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _malloc (value 0x50028fa) ld: multiple definitions of symbol _free gmalloc.o definition of _free in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _free (value 0x5002546) *** Exit 1 Stop. *** Exit 1 Stop. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 11:37:12 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24522; Thu, 11 Jun 92 11:37:12 PDT Received: by heavens-gate.lucid.com id AA24531g; Thu, 11 Jun 92 11:11:43 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA24527g; Thu, 11 Jun 92 11:11:37 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA29164; Thu, 11 Jun 92 11:19:58 PDT Date: Thu, 11 Jun 92 11:19:58 PDT Message-Id: <9206111819.AA29164@thalidomide.lucid> X-Windows: Complex nonsolutions to simple nonproblems. From: Jamie Zawinski Sender: jwz@thalidomide To: anderson@sapir.cog.jhu.edu Cc: bug-lucid-emacs@lucid.com Subject: Re: More on bringing lemacs to NeXT In-Reply-To: anderson@sapir.cog.jhu.edu's message of Thu 11-Jun-92 12:34:29 -0400 <9206111634.AA07443@sapir.cog.jhu.edu> References: <9206111634.AA07443@sapir.cog.jhu.edu> GNU Malloc doesn't seem to be terribly portable, I'd suggest trying it with the system malloc. It also could be that the version of GNU Malloc we have is too old. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 12:40:28 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24617; Thu, 11 Jun 92 12:40:28 PDT Received: by heavens-gate.lucid.com id AA24736g; Thu, 11 Jun 92 12:05:48 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA24730g; Thu, 11 Jun 92 12:05:40 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA00720 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 12:08:06 -0700 Received: by wsrcc.com id AA01300 (5.65c/IDA-1.4.4-WSR-02/03/92 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 11:49:43 -0700 Date: Thu, 11 Jun 1992 11:49:43 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206111849.AA01300@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: Re: appending ~/.signature to outgoing mail when i didn't ask for it References: <9206101958.AA13253@starbase.mitre.org> Organization: W S Rupprecht Computer Consulting, Fremont CA duff@starbase.MITRE.ORG (David A. Duff) writes: >i get a .signature file appended to all of my outgoing mail now and i'm >not sure why. I'm not sure why either. I see that somebody (no doubt an inews fan) took the worst feature of inews and foisted it upon emacs's sendmail.el. Why should the *transport* layer add data to the message without notifying the user? Whatever happened to WYSIWYG? If someone wants to auto-add their .signature why not do that in the "mail" function and let the user see it and edit it if he wants? eg. (setq mail-setup-hook '(lambda () (if (file-exists-p "~/.signature")) (progn (goto-char (point-max)) (insert "\n\n---\n") (insert-file "~/.signature")))) -wolfgang (hoping I'll only get one signature this time) --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 12:40:34 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24621; Thu, 11 Jun 92 12:40:34 PDT Received: by heavens-gate.lucid.com id AA24741g; Thu, 11 Jun 92 12:06:19 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA24737g; Thu, 11 Jun 92 12:06:11 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA00725 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 12:08:08 -0700 Received: by wsrcc.com id AA01700 (5.65c/IDA-1.4.4-WSR-02/03/92 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 12:12:05 -0700 Date: Thu, 11 Jun 1992 12:12:05 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206111912.AA01700@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: geometry spec problems Organization: W S Rupprecht Computer Consulting, Fremont CA Sparc / Sunos 4.1 / gcc 2.2 -O2 -fpcc-struct-return / X11R5p12 BUG1: My lemacs has problems with an initial command-line goemetry spec. lucid-emacs -geometry 81x42-2+2 produces an emacs of char size 81x30. BUG2: Adding an .Xdefaults line of: Emacs*geometry: 81x24 Causes my lemacs to terminate with the bash reporting "Abort". Observations: The geometry spec bugs appear related to the fact that during startup the following routine calls a pixel_to_char_size() for a widget that already has a char-size spec. Its not clear to me if all other calls to this routine are with a char-sized widget - so I'm reluctant to mess with it. void EmacsScreenResize (Widget widget) { EmacsScreenWidget ew = (EmacsScreenWidget)widget; struct screen *s = ew->emacs_screen.screen; int columns; int rows; >>>> pixel_to_char_size (ew, ew->core.width, ew->core.height, &columns, &rows); change_screen_size (s, rows, columns, 0); update_wm_hints (ew); update_various_screen_slots (ew); } -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 12:42:24 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24627; Thu, 11 Jun 92 12:42:24 PDT Received: by heavens-gate.lucid.com id AA24778g; Thu, 11 Jun 92 12:10:41 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA24774g; Thu, 11 Jun 92 12:10:34 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA29411; Thu, 11 Jun 92 12:18:57 PDT Date: Thu, 11 Jun 92 12:18:57 PDT Message-Id: <9206111918.AA29411@thalidomide.lucid> X-Windows: Dissatisfaction guaranteed. From: Jamie Zawinski Sender: jwz@thalidomide To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: appending ~/.signature to outgoing mail when i didn't ask for it In-Reply-To: Wolfgang S. Rupprecht's message of Thu 11-Jun-92 11:49:43 -0700 <199206111849.AA01300@wsrcc.com> References: <199206111849.AA01300@wsrcc.com> <9206101958.AA13253@starbase.mitre.org> In message <199206111849.AA01300@wsrcc.com> Wolfgang S. Rupprecht wrote: > > > duff@starbase.MITRE.ORG (David A. Duff) writes: >>i get a .signature file appended to all of my outgoing mail now and i'm >>not sure why. > > I'm not sure why either. > > I see that somebody (no doubt an inews fan) took the worst feature of > inews and foisted it upon emacs's sendmail.el. Why should the > *transport* layer add data to the message without notifying the user? > Whatever happened to WYSIWYG? I disavow any responsibility for introducing this lossage, but someone has just sent me a patch that makes this behavior be controlled by a variable. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 12:45:41 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24651; Thu, 11 Jun 92 12:45:41 PDT Received: by heavens-gate.lucid.com id AA24824g; Thu, 11 Jun 92 12:18:54 PDT Received: from sapir.cog.jhu.edu by heavens-gate.lucid.com id AA24820g; Thu, 11 Jun 92 12:18:44 PDT Received: from localhost by sapir.cog.jhu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA08899; Thu, 11 Jun 92 15:26:33 EDT Message-Id: <9206111926.AA08899@sapir.cog.jhu.edu> To: bug-lucid-emacs@lucid.com Subject: Ongoing NeXT problem Date: Thu, 11 Jun 92 15:26:33 -0400 From: anderson@sapir.cog.jhu.edu Sorry to keep "bugging" you, but I'm sure someone out there can solve this for me. I've gotten eveything in lemacs-19.1 to compile on the NeXT, but I can't get it to load. The problem has to do with malloc routines. (a) if I define GNU_MALLOC (and #undef SYSTEM_MALLOC) in config.h, as in the distributed version, I get a conflict of definition for three symbols: ld: multiple definitions of symbol _realloc gmalloc.o definition of _realloc in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _realloc (value 0x5002d7a) ld: multiple definitions of symbol _malloc gmalloc.o definition of _malloc in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _malloc (value 0x50028fa) ld: multiple definitions of symbol _free gmalloc.o definition of _free in section (__TEXT,__text) /lib/libsys_s.a(malloc.o) definition of absolute _free (value 0x5002546) (b) If I leave the #undef SYSTEM_MALLOC, but comment out the #define GNU_MALLOC, it compiles malloc.c instead of gmalloc.c and I get essentially the same conflicts as in case a. (c) If I comment out the whole block of conditionals, including both the #undef SYSTEM_MALLOC statement and the #define GNU_MALLOC statement, this gives rise to several undefined symbols instead of the previous multiple definitions: _putenv _strdup _S_ISDIR __start _remainder I'm sure there's some straightforward way to avoid loading both the system definitions of _realloc, _malloc and _free and the gmalloc.o definitions, but I'm not enough of a C programmer to know what it is. In fact, I'm not a programmer at all, but a Professor of Linguistics.... But I'd really like to get lemacs-19 to run on my NeXT. Any suggestions? Thanks in advance, --Steve Anderson From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 13:11:01 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24671; Thu, 11 Jun 92 13:11:01 PDT Received: by heavens-gate.lucid.com id AA24877g; Thu, 11 Jun 92 12:39:30 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA24873g; Thu, 11 Jun 92 12:39:24 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA29476; Thu, 11 Jun 92 12:47:48 PDT Date: Thu, 11 Jun 92 12:47:48 PDT Message-Id: <9206111947.AA29476@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz@thalidomide To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: geometry spec problems In-Reply-To: Wolfgang S. Rupprecht's message of Thu 11-Jun-92 12:12:05 -0700 <199206111912.AA01700@wsrcc.com> References: <199206111912.AA01700@wsrcc.com> In message <199206111912.AA01700@wsrcc.com> Wolfgang S. Rupprecht wrote: > > My lemacs has problems with an initial command-line goemetry spec. > > lucid-emacs -geometry 81x42-2+2 > > produces an emacs of char size 81x30. This is probably because of the menubar, which is added after the windows are created, but I'm surprised you're seeing a twelve line difference. I get one that's 81x40, because the menubar is about two "lines" high. > Adding an .Xdefaults line of: > > Emacs*geometry: 81x24 > > Causes my lemacs to terminate with the bash reporting "Abort". Never, never do this. I've added the following to the NEWS file. (but of course, it shouldn't dump core anyway...) ----- To make the default size of all emacs be 80 columns by 55 lines, do this: Emacs*EmacsScreen.geometry: 80x55 As a special case, this geometry specification also works: Emacs.geometry: 80x55 since that is the syntax used with most other applications (since most other applications, unlike emacs, have only one top-level window.) In general, however, the top-level shell doesn't have any interesting resources on it, and you should set the resources on the screens instead. To set the geometry of a particular screen named, "foo", do this: Emacs*foo.geometry: 80x55 In particular, do --NOT-- use this syntax: Emacs*geometry: 80x55 One should never use "*geometry" with any X application. It does not say "make the geometry of emacs be 80 columns by 55 lines." It really says, "make emacs and all subwindows thereof be 80x35 in whatever units they care to measure in." In particular, that is both telling the emacs text pane to be 80x55 in characters, and telling the menubar pane to be 80x55 pixels, which is surely not what you want. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 13:57:51 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24728; Thu, 11 Jun 92 13:57:51 PDT Received: by heavens-gate.lucid.com id AA25100g; Thu, 11 Jun 92 13:25:11 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA25096g; Thu, 11 Jun 92 13:25:03 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA29676; Thu, 11 Jun 92 13:33:27 PDT Date: Thu, 11 Jun 92 13:33:27 PDT Message-Id: <9206112033.AA29676@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz@thalidomide To: me@CS.Stanford.EDU Cc: bug-lucid-emacs@lucid.com Subject: Re: strange lemacs problem In-Reply-To: Martin Frost's message of Thu 11-Jun-92 13:23:20 -0700 <9206112023.AA19273@Sunburn.Stanford.EDU> References: <9206112023.AA19273@Sunburn.Stanford.EDU> Perhaps it's an NFS or automounter problem of some kind? My only suggestion would be to step through the calls to Fdirectory_files() and Ffile_directory_p(), and see what stat() is being called with, and whether it is lying. > One thing: When lemacs does work for me, it reports an error in my .emacs > file (unlike 18.58), about halfway through (fairly big .emacs): "Error in > init file: Wrong type argument: sequencep, #" . This is because keymaps are no longer vectors or lists, they are a new primary data type, and some of the ways you used to be able to manipulate them don't work any more. > Below is the code that causes the error. (I'm not even sure what the point > of this code is or where I got it.) > > ;;; If mail-mode-map is a sparse-keymap, convert it to a non-sparse one. This code is from an old version of mail-abbrevs.el, a working version of which is included with lemacs. Just delete (or conditionalize) the code in your .emacs file, you don't need it. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 13:58:10 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24732; Thu, 11 Jun 92 13:58:10 PDT Received: by heavens-gate.lucid.com id AA25063g; Thu, 11 Jun 92 13:16:14 PDT Received: from Sunburn.Stanford.EDU by heavens-gate.lucid.com id AA25056g; Thu, 11 Jun 92 13:15:59 PDT Received: by Sunburn.Stanford.EDU (5.61+IDA/25-eef) id AA19273; Thu, 11 Jun 92 13:23:20 -0700 Date: Thu, 11 Jun 92 13:23:20 -0700 From: Martin Frost Message-Id: <9206112023.AA19273@Sunburn.Stanford.EDU> To: bug-lucid-emacs@lucid.com Subject: strange lemacs problem Reply-To: me@CS.Stanford.EDU I'm running the pre-compiled lemacs binary from labrea. The weird thing is that sometimes it starts up OK and sometimes it says "Error: Can't Open Display". The only difference is the command I use to start it. If I say just lemacs it starts fine. But if I say /usr/local/bin/lemacs it give the above error. But 'which lemacs' says /usr/local/bin/lemacs. These also fail the same way: cd /usr/local/lemacs/src ; ./lemacs cd /usr/local/lemacs ; src/lemacs Here's my setup: /usr/local/bin/lemacs --> /usr/local/lemacs/src/lemacs (the binary) /usr/local/lemacs/{etc,lisp,info} hold the lemacs stuff from labrea This is a Sun 4/490, SunOS 4.1.2, display is an NCD 16 X terminal. When it does start up, it has the right lisp directory. More strangeness: For other users, we get the same failure mode but not for the same commands. For some users on other NCDs and for one trying to display on a SparcStation (but run on the 4/490), even 'lemacs' doesn't work (usual error message). For one user running lemacs on the 4/490 but displaying on a DECstation, nothing works except 'cd /usr/local/bin ; lemacs' (. must be in his path). Everyone has their DISPLAY variable set properly (emacs 18.58 works under X). And for me running lemacs on an NCD at home under Xremote, all commands to start up lemacs work! I suppose the differences between different people might be X resources, but that difference doesn't apply between me and myself (for the 'lemacs' and '/usr/local/bin/lemacs' commands, only the first of which works from my office). I haven't been able to spot anything unusual in the different X resources that should do this. Geometry? Font? ReverseVideo? One thing: When lemacs does work for me, it reports an error in my .emacs file (unlike 18.58), about halfway through (fairly big .emacs): "Error in init file: Wrong type argument: sequencep, #" . I'm not particularly concerned about that, but thought I would mention it. Below is the code that causes the error. (I'm not even sure what the point of this code is or where I got it.) ;;; If mail-mode-map is a sparse-keymap, convert it to a non-sparse one. ;;; If a given key would be bound to self-insert-command in mail-mode (that ;;; is, it is bound to it in mail-mode-map or in global-map) then bind it ;;; to sendmail-self-insert-command in mail-mode-map. ;;; (let* ((sparse-p (consp mail-mode-map)) (map (make-keymap)) (L (length map)) (i 0)) (while (< i L) (let ((old (or (if sparse-p (cdr (assq i mail-mode-map)) (aref mail-mode-map i)) (aref global-map i)))) (aset map i (if (eq old 'self-insert-command) 'sendmail-self-insert-command old))) (setq i (1+ i))) (setq mail-mode-map map)) From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 14:32:16 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24766; Thu, 11 Jun 92 14:32:16 PDT Received: by heavens-gate.lucid.com id AA25252g; Thu, 11 Jun 92 13:57:19 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA25244g; Thu, 11 Jun 92 13:56:59 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.20-cs) id AA09319; Thu, 11 Jun 92 15:05:08 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.14-leaf) id AA21866; Thu, 11 Jun 92 15:05:06 -0600 Date: Thu, 11 Jun 92 15:05:06 -0600 From: eeide%asylum.cs@cs.utah.edu (Eric Eide) Message-Id: <9206112105.AA21866@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Cc: eeide%asylum.cs@cs.utah.edu Subject: Compiling Lucid GNU Emacs on HP9000/425 BSD Yesterday I compiled Lucid GNU Emacs on a Hewlett-Packard 9000/425 running BSD. Since the announcement said that Lucid was interested in learning about portability problems, I thought that I should relay my experiences. I am not an experienced systems administrator, nor have I ever had to maintain or install GNU Emacs at my site (the University of Utah Department of Computer Science). I am, however, very familiar with GNU Emacs and Epoch. On with my story... I used the following configuration ("config.h"): System file: "s/s-bsd4-3.h" Machine file: "m/m-hp300bsd.h" Defined: AMPERSAND_FULL_NAME MAINTAIN_ENVIRONMENT Undefined: HAVE_REALPATH I don't have a real ANSI C environment available to me, but I do have gcc. ------------------------------------------------------------------------------- Below I have listed the errors I encountered building Lucid GNU Emacs. + For some reason, my "make" could not figure out how to build "etc/b2m", even though the file "etc/b2m.c" was right where it was supposed to be. I compiled it by hand without problems. + The file "src/ymakefile" doesn't include the target "all". I added the following rule and continued: all: xemacs OTHER_FILES + The build died at "src/dispnew.c" because was being included twice -- first by "dispnew.c" itself, and then later through "xterm.h" ("dispnew.c" includes "xterm.h", which includes , which includes , which includes ). My fix was to remove the inclusion of from "dispnew.c" itself: /* ENE: Don't include this here -- it's included via "xterm.h". */ #if 0 #ifdef NEED_TIME_H #include #else /* not NEED_TIME_H */ #ifdef HAVE_TIMEVAL #include #endif /* HAVE_TIMEVAL */ #endif /* not NEED_TIME_H */ #endif + The build then died at "src/xterm.c" for the same reason that "src/dispnew.c" died. I removed the inclusion of from "xterm.c" (as described above) and proceeded. + The build then died at "src/keyboard.c" because was being included twice -- first directly by "keyboard.c" and then later via "backtrace.h". My fix was to comment out the direct inclusion of by "keyboard.c". /* #include ENE: Included below by "backtrace.h". */ + The build then died at "src/fileio.c" because was not being included. The #include is wrapped inside a #ifdef HAVE_REALPATH ... #endif, but the function Fmake_directory also requires that be loaded. So I made the obvious fix: put "#include " at the top of "src/fileio.c" and comment out the #include later on in the file. + The build then died at "src/eval.c" for the same reason that "src/keyboard.c" died. Again, I simply removed the "#include " from "src/eval.c". + The build died at "src/extents.c" because was being included twice (once directly and then again through "xterm.h"). I commented out the direct inclusion of by "src/extents.c". + The build died at "src/faces.c". On my system, one must include before including . So I added the appropriate line and proceeded. + The build died at "src/lwlib/xlwmenu.c" because was being included twice (again!). So I commented out the "#include " line and pressed on... + Finally, I made it to the linker! But the link failed because the following symbols were undefined: S_ISDIR ("src/emacs.c") My system doesn't provide this macro, so I wrote the obvious equivalent and added it to "src/emacs.c": #define S_ISDIR(mode) ((mode & S_IFDIR)) putenv ("src/emacs.c" and "src/term.c") Again, my system doesn't provide this. I tried to add an equivalent function using setenv(3), but that caused linkage problems later on (getenv became multiply defined -- once by "sys/environ.c" because I'm compiling with MAINTAIN_ENVIRONMENT, and then once by the C library. Currently I have a non-functional version of "putenv" added to "src/emacs.c". I think that this is the source of my terminal problems (see below). remainder ("src/data.c") I wrote my own version of this function (using modf(3) and added it to "src/data.c". Freal_path_name ("src/buffer.c" and "src/emacs.c") Since I am compiling without HAVE_REALPATH defined, this function was not defined by "src/fileio.c" and now I'm having problems. I added an appropriate stub to "src/fileio.c", below the real definition: [...] #else /* HAVE_REALPATH */ /* ENE: Need a stub version for "buffer.c" and "emacs.c". */ Lisp_Object Freal_path_name(name, defalt) Lisp_Object name, defalt; { return Qnil; } #endif /* HAVE_REALPATH */ + And finally, success! ------------------------------------------------------------------------------- The dumped Emacs seems to run fine, for the most part. I have noticed the following peculiarities: + When I started Lucid Emacs from my "$BUILD/src" directory, it was unable to find the "../lisp" and "../etc" directories and immediately exited. It exited so quickly that I didn't even get to see the error message. Perhaps this is related to the problems with the terminal (see below). When I made a symbolic link "$BUILD/emacs" to "$BUILD/src/xemacs" and then executed the symbolic link, Lucid Emacs initialized load-path et al. correctly. + When I (accidentally) start Lucid Emacs in the foreground, the (X) terminal that I invoke Emacs from becomes goofed. The control keys all become NUL. This doesn't seem to happen if I start Lucid Emacs in the background. I haven't looked into this problem at all. But I did notice the "invisible terminal kludge" in the source code, and I'm wondering if my non-functional version of "putenv" is related to this problem. + If one starts Lucid Emacs and then immediately selects "Open File..." from the menu, the find-file prompt is not displayed until the initial banner has gone away (or one hits a key). Perhaps sit-for doesn't exit when mouse input is available? It should, it seems. + Although the mouse cursor changes to a bidirectional vertical arrow when it is over a mode line, I cannot seem to move the mode line with the mouse. The bidirectional arrow implies that I should be able to click-and-drag the mode line. Again, I haven't looked into this at all. ------------------------------------------------------------------------------- So, in the end I had very minor problems building Lucid GNU Emacs 19.1, and it seems to be working well. It looks very impressive and I'm excited to dig into it! Eric. ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 14:42:57 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24788; Thu, 11 Jun 92 14:42:57 PDT Received: by heavens-gate.lucid.com id AA25305g; Thu, 11 Jun 92 14:14:20 PDT Received: from watergate.lucid ([192.31.212.117]) by heavens-gate.lucid.com id AA25301g; Thu, 11 Jun 92 14:14:10 PDT Received: by watergate.lucid (4.1/SMI-4.1) id AA24658; Thu, 11 Jun 92 14:22:28 PDT Date: Thu, 11 Jun 92 14:22:28 PDT From: eb@watergate (Eric Benson) Message-Id: <9206112122.AA24658@watergate.lucid> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com, eeide%asylum.cs@cs.utah.edu (Eric Eide) Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD In-Reply-To: Jamie Zawinski's message of Thu 11-Jun-92 14:18:24 PDT <9206112118.AA29754@thalidomide.lucid> References: <9206112105.AA21866@asylum.cs.utah.edu> <9206112118.AA29754@thalidomide.lucid> I think the BSD equivalent of "remainder" is "drem". From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 14:48:17 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24796; Thu, 11 Jun 92 14:48:17 PDT Received: by heavens-gate.lucid.com id AA25336g; Thu, 11 Jun 92 14:20:40 PDT Received: from vishnu.reed.edu by heavens-gate.lucid.com id AA25332g; Thu, 11 Jun 92 14:20:32 PDT Received: from local by vishnu.reed.edu (/\==/\ Smail3.1.25.1 #25.21) id ; Thu, 11 Jun 92 14:28 PDT Message-Id: Date: Thu, 11 Jun 92 14:28 PDT From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: lemacs on a NeXT in response to anderson@sapir.cog.jhu.edu's problems compiling lemacs on a NeXT. >(a) if I define GNU_MALLOC (and #undef SYSTEM_MALLOC) in config.h, as >in the distributed version, I get a conflict of definition for three >symbols: this is because it's a lot harder to override NeXT's version of malloc with your own. Basically, you shouldn't - do not try to build any malloc(), free(), realloc(), or valloc() yourself, just use the ones in the NeXT libraries. Mach is weird about it's memory. among other things, you don't use sbrk()... >(c) If I comment out the whole block of conditionals, including both >the #undef SYSTEM_MALLOC statement and the #define GNU_MALLOC >statement, this gives rise to several undefined symbols instead of the >previous multiple definitions: > _putenv > _strdup > _S_ISDIR > __start > _remainder strdup and remainder are also missing from Ultrix libraries. Here's strdup from the GNU libiberty (from gdb) char * strdup(s) char *s; { char *result = (char*)malloc(strlen(s) + 1); if (result == (char*)0) return (char*)0; strcpy(result, s); return result; } remainder is a slightly different version of fmod, which your NeXT will almost definitely have. It looks to be present under Ultrix as drem. putenv should be there - that's really strange. I couldn't imagine having getenv and not putenv. I don't know anything about _S_ISDIR and __start. S_ISDIR sounds like it should be a constant in one of the files in /usr/include.. Which X are you building it under? I haven't found an X robust enough on NeXTs to build anything.. From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 14:48:49 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24800; Thu, 11 Jun 92 14:48:49 PDT Received: by heavens-gate.lucid.com id AA25287g; Thu, 11 Jun 92 14:10:07 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA25283g; Thu, 11 Jun 92 14:10:01 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA29754; Thu, 11 Jun 92 14:18:24 PDT Date: Thu, 11 Jun 92 14:18:24 PDT Message-Id: <9206112118.AA29754@thalidomide.lucid> X-Windows: Dissatisfaction guaranteed. From: Jamie Zawinski Sender: jwz@thalidomide To: eeide%asylum.cs@cs.utah.edu (Eric Eide) Cc: bug-lucid-emacs@lucid.com Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD In-Reply-To: Eric Eide's message of Thu 11-Jun-92 15:05:06 -0600 <9206112105.AA21866@asylum.cs.utah.edu> References: <9206112105.AA21866@asylum.cs.utah.edu> What kind of tragically losing system doesn't protect its standard include files from double-inclusion??? That's just absurd! We really have no way of knowing which system include files are going to include each other on different systems, how are we supposed to protect against that in any kind of portable way? In message <9206112105.AA21866@asylum.cs.utah.edu> Eric Eide wrote: > > remainder ("src/data.c") I wrote my own version of this function (using > modf(3) and added it to "src/data.c". If anyone is really sure what the functionally equivalent replacement is for remainder() is on systems that don't have it, please send me the code. Someone said that they didn't think that fmod() and remainder() were exactly the same. > + If one starts Lucid Emacs and then immediately selects "Open File..." from > the menu, the find-file prompt is not displayed until the initial banner > has gone away (or one hits a key). Perhaps sit-for doesn't exit when > mouse input is available? It should, it seems. Sit-for terminates on mouse-input, but not on menu selections, which is kind of bad, but also pretty hard to fix. > + Although the mouse cursor changes to a bidirectional vertical arrow when > it is over a mode line, I cannot seem to move the mode line with the mouse. > The bidirectional arrow implies that I should be able to click-and-drag the > mode line. Again, I haven't looked into this at all. No, that cursor is just there to tease you. :-) You can't actually drag the modelines. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 15:46:35 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24878; Thu, 11 Jun 92 15:46:35 PDT Received: by heavens-gate.lucid.com id AA25593g; Thu, 11 Jun 92 15:24:52 PDT Received: from erewhon.CS.Berkeley.EDU by heavens-gate.lucid.com id AA25589g; Thu, 11 Jun 92 15:24:41 PDT Received: by erewhon.CS.Berkeley.EDU (5.57/Ultrix3.0-C) id AA21130; Thu, 11 Jun 92 15:34:48 -0700 From: Message-Id: <9206112234.AA21130@erewhon.CS.Berkeley.EDU> To: Lucid Emacs 19 Bugs Subject: signal handling bug? Date: Thu, 11 Jun 92 15:34:48 PDT (global-set-key "\M-\C-g" 'goto-line) has the desired effect in emacs 18.57 but not in lemacs. configuration: ultrix4.2a, decstation 5k/200, with BROKEN_O_NONBLOCK fix. later, Adam Glass From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 16:15:21 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24911; Thu, 11 Jun 92 16:15:21 PDT Received: by heavens-gate.lucid.com id AA25676g; Thu, 11 Jun 92 15:53:37 PDT Received: from portal.bcm.tmc.edu by heavens-gate.lucid.com id AA25672g; Thu, 11 Jun 92 15:53:26 PDT Received: from shell.shell.com by shell.com SHELL-X1.3 id AA04124; Thu, 11 Jun 92 15:41:14 -0500 Received: from colorado by shell.shell.com SHELL-I1.3 id AA04004; Thu, 11 Jun 92 15:39:26 -0500 Received: by colorado.agr.shell.com (4.1/AGR-2.0) id AA24148; Thu, 11 Jun 92 15:45:46 CDT Date: Thu, 11 Jun 92 15:45:46 CDT From: jody@shell.com Message-Id: <9206112045.AA24148@colorado.agr.shell.com> To: bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Thu, 11 Jun 92 11:19:58 PDT <9206111819.AA29164@thalidomide.lucid> Subject: More on bringing lemacs to NeXT Sender: jody@shell.com Source-Info: From (or Sender) name not authenticated. The gnu-malloc failed on a Sun 4.1.1 and gcc 2.2. When I switched to the system malloc everything worked. Another not is that since you are using ld to link and gcc to compile on the sun you must link with gcc libraries else you'll get an undefined reference to ___main. Jody Winston jody@shell.com ..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody Consultant to: Shell Development Company, Bellaire Research Center P.O. Box 481, Room 4205, Houston, TX 77001 (Voice: 713 245-7574) From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 16:45:04 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA24960; Thu, 11 Jun 92 16:45:04 PDT Received: by heavens-gate.lucid.com id AA25772g; Thu, 11 Jun 92 16:22:46 PDT Received: from uswat.advtech.uswest.com by heavens-gate.lucid.com id AA25768g; Thu, 11 Jun 92 16:22:39 PDT Received: from alder.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA05963 (5.65c/IDA-1.4.4 for ); Thu, 11 Jun 1992 17:30:58 -0600 Received: by alder.advtech.uswest.com (advtech.uswest.com) id AA15204 (4.1/at-generic.11Feb92); Thu, 11 Jun 92 17:30:58 MDT Date: Thu, 11 Jun 92 17:30:58 MDT From: Chris McClenaghan Message-Id: <9206112330.AA15204@alder.advtech.uswest.com> To: Lucid Emacs 19 Bugs Subject: core dumps I thought this might be my problem, but the binary from labrea does it also. I've gotten two types of core dumps, bus and segmentation errors. Mostly this occurs in loading my .emacs, in one of two places according to the mode line. The initialization justs halts, the cursor may go to the clock face, and a few seconds later the process disappears. One other occurence of this hasn't plagued me since yesterday, which envolved the menubar, clicking on any menu item caused a core dump also. Unfortunately, I can't get gdb to read the reslutant core file without terminating itself. I type "gdb core", get the message about reading symbols and the what looks like a core dump error message. I'll try running this under gdb directly to see if it happens, but it is very intermittent. Chris McClenaghan mcclen@uswest.com From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 17:47:32 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25022; Thu, 11 Jun 92 17:47:32 PDT Received: by heavens-gate.lucid.com id AA25928g; Thu, 11 Jun 92 17:18:10 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA25924g; Thu, 11 Jun 92 17:18:02 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00140; Thu, 11 Jun 92 17:26:27 PDT Date: Thu, 11 Jun 92 17:26:27 PDT Message-Id: <9206120026.AA00140@thalidomide.lucid> X-Windows: A terminal disease. From: Jamie Zawinski Sender: jwz@thalidomide To: Cc: Lucid Emacs 19 Bugs Subject: Re: signal handling bug? In-Reply-To: glass@postgres.berkeley.edu's message of Thu 11-Jun-92 15:34:48 PDT <9206112234.AA21130@erewhon.CS.Berkeley.EDU> References: <9206112234.AA21130@erewhon.CS.Berkeley.EDU> In message <9206112234.AA21130@erewhon.CS.Berkeley.EDU> glass@postgres.berkeley.edu wrote: > > (global-set-key "\M-\C-g" 'goto-line) has the desired effect in emacs > 18.57 but not in lemacs. When I type M-C-g (that is, by holding down both the meta and control keys and typing g) it works. It doesn't work if you type "ESC C-g", and this is indeed a difference between v18 and LEmacs. However, it was very deceptive of "ESC C-g" to ever work in v18, because it *only* works when emacs is waiting for keyboard input. It does *not* work as typeahead! Try this in emacs 18: (defun takes-a-long-time () (interactive) (let ((i 100000)) (while (> i 0) (setq i (1- i))))) (global-set-key "\M-\C-g" 'goto-line) (global-set-key "\M-2" 'takes-a-long-time) Now, you'll notice that the sequence "ESC C-g" executes the goto-line command. But the sequence "ESC 2 ESC C-g" does not: C-g is interpreted as the interrupt character. This behavior seems very confusing and broken to me, so I didn't bother to try to emulate it. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 18:10:01 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25055; Thu, 11 Jun 92 18:10:01 PDT Received: by heavens-gate.lucid.com id AA26010g; Thu, 11 Jun 92 17:42:18 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA26006g; Thu, 11 Jun 92 17:42:13 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00179; Thu, 11 Jun 92 17:50:39 PDT Date: Thu, 11 Jun 92 17:50:39 PDT Message-Id: <9206120050.AA00179@thalidomide.lucid> X-Windows: The problem for your problem. From: Jamie Zawinski Sender: jwz@thalidomide To: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com Reply-To: jwz@heavens-gate.lucid.com Subject: another volunteer sought David Zuhn has done most of the work needed to make Lucid GNU Emacs able to be compiled with the GNU "configure" program, but now he's busy and won't have time to finish it any time soon. If you would like to help out with this, please send me mail. He thinks it's probably not that much work, and it will earn you the beer/pop/beverage-of-choice if you live anywhere where he or I'll will be going anytime soon. Making lemacs able to be compiled with configure will make a huge number of compilation/porting problems go away. You will be the idol of millions if you do this. Fame, fortune, fans, gold records, your name in lights... -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 20:02:21 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25140; Thu, 11 Jun 92 20:02:21 PDT Received: by heavens-gate.lucid.com id AA26328g; Thu, 11 Jun 92 19:37:29 PDT Received: from uswat.advtech.uswest.com by heavens-gate.lucid.com id AA26324g; Thu, 11 Jun 92 19:37:23 PDT Received: from teton.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA07241 (5.65c/IDA-1.4.4 for ); Thu, 11 Jun 1992 20:45:41 -0600 Received: by teton.advtech.uswest.com (advtech.uswest.com) id AA26826 (4.1/at-generic.11Feb92); Thu, 11 Jun 92 20:45:33 MDT Date: Thu, 11 Jun 92 20:45:33 MDT From: Chris McClenaghan Message-Id: <9206120245.AA26826@teton.advtech.uswest.com> To: Lucid Emacs 19 Bugs Subject: It's back, autosave files for mail buffers not removed I had this problem with the Energize beta, autosaves for mail are not removed when mail is sent. I think I can distinguish the case where it fails, I'll have to wait and test in the office. I'm not using vm-5.32.L, still like vm-5.31. Its either that difference or has to do with sendmail and not vm. Chris McClenaghan mcclen@uswest.com From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 20:11:26 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25156; Thu, 11 Jun 92 20:11:26 PDT Received: by heavens-gate.lucid.com id AA26339g; Thu, 11 Jun 92 19:46:21 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA26335g; Thu, 11 Jun 92 19:46:13 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00745; Thu, 11 Jun 92 19:54:39 PDT Date: Thu, 11 Jun 92 19:54:39 PDT Message-Id: <9206120254.AA00745@thalidomide.lucid> X-Windows: Japan's secret weapon. From: Jamie Zawinski Sender: jwz@thalidomide To: Chris McClenaghan Cc: Lucid Emacs 19 Bugs Subject: Re: It's back, autosave files for mail buffers not removed In-Reply-To: Chris McClenaghan's message of Thu 11-Jun-92 20:45:33 MDT <9206120245.AA26826@teton.advtech.uswest.com> References: <9206120245.AA26826@teton.advtech.uswest.com> Are you sure you're not just getting confused by the fact that if you execute M-x mail multiple times, it creates a new buffer instead of reusing the old one? I have never seen autosave files fail to get deleted when they should, and there's certainly nothing magic about mail buffers. > I'm not using vm-5.32.L, still like vm-5.31. Well 5.32L does have the benefit that it works... -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 21:13:57 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25186; Thu, 11 Jun 92 21:13:57 PDT Received: by heavens-gate.lucid.com id AA26459g; Thu, 11 Jun 92 20:47:32 PDT Received: from apple.com by heavens-gate.lucid.com id AA26455g; Thu, 11 Jun 92 20:47:23 PDT Received: by apple.com (5.61/10-Dec-1991-eef) id AA28159; Thu, 11 Jun 92 20:51:08 -0700 for Received: from wetware.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.7]) id AA28179; Thu, 11 Jun 92 20:29:16 PDT Received: by wetware.com (/\==/\ Smail3.1.25.1 #25.1) id ; Thu, 11 Jun 92 20:10 PDT Received: by wsrcc.com id AA07263 (5.65c/IDA-1.4.4-WSR-06/11/92 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 20:00:39 -0700 Date: Thu, 11 Jun 1992 20:00:39 -0700 Message-Id: <199206120300.AA07263@wsrcc.com> From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) To: bug-lucid-emacs@lucid.com Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD Organization: W S Rupprecht Computer Consulting, Fremont CA References: <9206112105.AA21866@asylum.cs.utah.edu> <9206112118.AA29754@thalidomide.lucid> jwz@lucid.COM (Jamie Zawinski) writes: >If anyone is really sure what the functionally equivalent replacement is >for remainder() is on systems that don't have it, please send me the code. >Someone said that they didn't think that fmod() and remainder() were >exactly the same. from the SunOS man pages: remainder(x, y) and fmod(x, y) return a remainder of x with respect to y; that is, the result r is one of the numbers that differ from x by an integral multiple of y. Thus (x - r)/y is an integral value, even though it might exceed MAX- INT if it were explicitly computed as an int. Both func- tions return one of the two such r smallest in magnitude. remainder(x, y) is the operation specified in ANSI/IEEE Std 754-1985; the result of fmod(x, y) may differ from remainder()'s result by +-y. The magnitude of remainder's result can not exceed half that of y; its sign might not agree with either x or y. The magnitude of fmod()'s result is less than that of y; its sign agrees with that of x. Neither function can generate an exception as long as both arguments are normal or subnormal. remainder(x, 0), fmod(x, 0), remainder(oo, y), and fmod(oo, y) are invalid operations that produce a NaN. >From this description it sounds like -y/2 < remainder(x,y) <= y/2 or: remainder(double x, double y) { double tmp; tmp = fmod(x,y); if (tmp > (y/2)) return(tmp - y); else if (tmp <= (-y/2)) /* or perhaps < ??? */ return(tmp + y); else return(tmp); } -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 21:14:05 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25190; Thu, 11 Jun 92 21:14:05 PDT Received: by heavens-gate.lucid.com id AA26454g; Thu, 11 Jun 92 20:47:14 PDT Received: from apple.com by heavens-gate.lucid.com id AA26450g; Thu, 11 Jun 92 20:47:08 PDT Received: by apple.com (5.61/10-Dec-1991-eef) id AA28138; Thu, 11 Jun 92 20:50:51 -0700 for Received: from wetware.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.7]) id AA28171; Thu, 11 Jun 92 20:29:14 PDT Received: by wetware.com (/\==/\ Smail3.1.25.1 #25.1) id ; Thu, 11 Jun 92 20:10 PDT Received: by wsrcc.com id AA07223 (5.65c/IDA-1.4.4-WSR-06/11/92 for bug-lucid-emacs@lucid.com); Thu, 11 Jun 1992 19:59:40 -0700 Date: Thu, 11 Jun 1992 19:59:40 -0700 Message-Id: <199206120259.AA07223@wsrcc.com> From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: strange lemacs problem Organization: W S Rupprecht Computer Consulting, Fremont CA References: <9206112023.AA19273@Sunburn.Stanford.EDU> <9206112033.AA29676@thalidomide.lucid> To: bug-lucid-emacs@lucid.com jwz@lucid.COM (Jamie Zawinski) writes: >Perhaps it's an NFS or automounter problem of some kind? My only >suggestion would be to step through the calls to Fdirectory_files() and >Ffile_directory_p(), and see what stat() is being called with, and >whether it is lying. I see the same strangeness here. It appears to be relates to the empty paths.h and the run-time paths configuring. If I start lemacs from a copy in /usr/local/bin it dies. If I start it via a symlink in /usr/local/bin (pointing to the xemacs in the compilation directory) it works. The following comments buried in startup.el:set-default-load-path apply: ;; These heuristics fail if the emacs binary was copied from the main emacs ;; tree to some other directory, and links for the lisp directory were not ;; put in, but I can't think of a way around that. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 21:24:25 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25199; Thu, 11 Jun 92 21:24:25 PDT Received: by heavens-gate.lucid.com id AA26478g; Thu, 11 Jun 92 20:59:37 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA26474g; Thu, 11 Jun 92 20:59:30 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01146; Thu, 11 Jun 92 21:07:57 PDT Date: Thu, 11 Jun 92 21:07:57 PDT Message-Id: <9206120407.AA01146@thalidomide.lucid> X-Windows: Putting new limits on productivity. From: Jamie Zawinski Sender: jwz@thalidomide To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD In-Reply-To: Wolfgang S. Rupprecht's message of Thu 11-Jun-92 20:00:39 -0700 <199206120300.AA07263@wsrcc.com> References: <199206120300.AA07263@wsrcc.com> <9206112105.AA21866@asylum.cs.utah.edu> <9206112118.AA29754@thalidomide.lucid> It has been claimed that drem and remainder are the same, does anyone disagree? I was going to use #ifdef BSD return (make_float (drem (f1,f2))); #else return (make_float (remainder (f1,f2))); #endif From bug-lucid-emacs-request@heavens-gate.lucid.com Thu Jun 11 21:37:16 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25211; Thu, 11 Jun 92 21:37:16 PDT Received: by heavens-gate.lucid.com id AA26508g; Thu, 11 Jun 92 21:12:38 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA26504g; Thu, 11 Jun 92 21:12:32 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01200; Thu, 11 Jun 92 21:21:00 PDT Date: Thu, 11 Jun 92 21:21:00 PDT Message-Id: <9206120421.AA01200@thalidomide.lucid> X-Windows: The art of incompetence. From: Jamie Zawinski Sender: jwz@thalidomide To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: strange lemacs problem In-Reply-To: Wolfgang S. Rupprecht's message of Thu 11-Jun-92 19:59:40 -0700 <199206120259.AA07223@wsrcc.com> References: <199206120259.AA07223@wsrcc.com> <9206112023.AA19273@Sunburn.Stanford.EDU> <9206112033.AA29676@thalidomide.lucid> In message <199206120259.AA07223@wsrcc.com> Wolfgang S. Rupprecht wrote: > > I see the same strangeness here. It appears to be relates to the > empty paths.h and the run-time paths configuring. > > If I start lemacs from a copy in /usr/local/bin it dies. If I start > it via a symlink in /usr/local/bin (pointing to the xemacs in the > compilation directory) it works. I think that if you create the links /usr/local/bin/lisp and /usr/local/bin/etc, and /usr/local/bin/lemacs is the actual executable, not a link, it will work. For the next version, I've changed `execution-path' to not be canonicalized; it may be a symlink. Now emacs will look for lisp and etc directories at every stop along the link chain, so this set of directories and links will work: /usr/local/bin/lemacs@ -> /some/where/else/xemacs* /usr/local/bin/etc@ -> /yet/another/directory/etc/ /usr/local/bin/lisp@ -> /yet/another/directory/lisp/ As well as /usr/local/bin/lemacs@ -> /some/where/else/xemacs* /some/where/else/etc/ /some/where/else/lisp/ and /usr/local/bin/lemacs* /usr/local/bin/etc@ -> /some/where/else/etc/ /usr/local/bin/lisp@ -> /some/where/else/lisp/ both of which should work in 19.1. I think that some of the other problems related to this that have been reported were not just a problem of missing links; I think that file-directory-p lies sometimes, doubtless because of some "feature" of the Nightmare File System. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 00:31:46 1992 Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25512; Fri, 12 Jun 92 00:31:46 PDT Received: by heavens-gate.lucid.com id AA26815g; Fri, 12 Jun 92 00:04:20 PDT Received: from srawgw.sra.co.jp by heavens-gate.lucid.com id AA26811g; Fri, 12 Jun 92 00:03:58 PDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA07853; Fri, 12 Jun 92 16:11:36 +0900 Received: from srarc2.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA04590; Fri, 12 Jun 92 16:11:10 +0900 Received: by srarc2.sra.co.jp (5.61/6.4J.6-SJ) id AA28455; Fri, 12 Jun 92 16:11:24 +0900 Date: Fri, 12 Jun 92 16:11:24 +0900 From: hikichi@srarc2.sra.co.jp (Nobuyuki Hikichi) Return-Path: Message-Id: <9206120711.AA28455@srarc2.sra.co.jp> To: bug-lucid-emacs@lucid.com In-Reply-To: <9206110839.AA19326@srarc2.sra.co.jp> Subject: Re: report to try to port Sony NEWS(MIPS based) Reply-To: hikichi@sra.co.jp On Thu, 11 Jun 92 17:39:28 +0900, hikichi%srarc2.sra.co.jp@lucid.com (Nobuyuki Hikichi) said: Nob> I tried to port lemacs 19.1 to Sony News(MIPS) version 4.1(I attached Nob> the machine file in the end of this mail). I can compile without Nob> error bug it did not startup. I cannot find why not. I can run well with following patch. I must use system malloc instead of gnu in it. By the way this patch is incorporated with following info. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD Date: Thu, 11 Jun 92 21:07:57 PDT It has been claimed that drem and remainder are the same, does anyone disagree? I was going to use #ifdef BSD return (make_float (drem (f1,f2))); #else return (make_float (remainder (f1,f2))); #endif Name: Nobuyuki Hikichi Office: Software Research Associates, Inc. Japan. #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 06/12/1992 07:04 UTC by hikichi@srarc2 # Source directory /tmp # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 4607 -rw-r--r-- risc-news.diff # # ============= risc-news.diff ============== if test -f 'risc-news.diff' -a X"$1" != X"-c"; then echo 'x - skipping risc-news.diff (File already exists)' else echo 'x - extracting risc-news.diff (Text)' sed 's/^X//' << 'SHAR_EOF' > 'risc-news.diff' && diff -rNu3 lemacs-19.1.org/src/config.h lemacs-19.1/src/config.h --- lemacs-19.1.org/src/config.h Wed Jun 3 16:57:22 1992 +++ lemacs-19.1/src/config.h Fri Jun 12 12:08:24 1992 @@ -30,7 +30,7 @@ X the s- files to use for them. See s-template.h for documentation on X writing s- files. X */ -#include "s/s-sunos4.h" +#include "s/s-bsd4-3.h" X X /* Include here a m- file that describes the machine and system you use. X See the file ../etc/MACHINES for a list of machines and the names of @@ -37,7 +37,7 @@ X the m- files to use for them. See m-template.h for info on what m- X files should define. X */ -#include "m/m-sparc.h" +#include "m/m-risc-news.h" X X /* Load in the conversion definitions if this system X needs them and the source file being compiled has not @@ -106,7 +106,8 @@ X #ifdef SYSTEM_MALLOC X #undef SYSTEM_MALLOC X #endif -#define GNU_MALLOC +/* #define GNU_MALLOC */ +#define SYSTEM_MALLOC X X /* Define REL_ALLOC if you want to use the relocating allocator for X buffer space. (There are too many problems with this right now.) */ @@ -157,6 +158,7 @@ X */ X #define USE_GCC X /* #define USE_LCC */ +#define LIB_GCC /usr/local/gnu/lib/gcc-lib/libgcc.a X X /* If you have defined USE_MOTIF in the lwlib Imakefile, then you must define X LWLIB_USES_MOTIF here. Similarly, if you have defined USE_OLIT in the diff -rNu3 lemacs-19.1.org/src/data.c lemacs-19.1/src/data.c --- lemacs-19.1.org/src/data.c Wed Apr 29 13:31:44 1992 +++ lemacs-19.1/src/data.c Fri Jun 12 13:37:14 1992 @@ -1512,7 +1512,11 @@ X X f1 = XTYPE (num1) == Lisp_Float ? XFLOAT (num1)->data : XINT (num1); X f2 = XTYPE (num2) == Lisp_Float ? XFLOAT (num2)->data : XINT (num2); +#ifdef BSD + return (make_float (drem (f1,f2))); +#else X return (make_float (remainder (f1,f2))); +#endif X } X #else /* not LISP_FLOAT_TYPE */ X CHECK_NUMBER_COERCE_MARKER (num1, 0); diff -rNu3 lemacs-19.1.org/src/faces.c lemacs-19.1/src/faces.c --- lemacs-19.1.org/src/faces.c Sun May 24 16:20:09 1992 +++ lemacs-19.1/src/faces.c Fri Jun 12 11:55:05 1992 @@ -15,6 +15,7 @@ X along with GNU Emacs; see the file COPYING. If not, write to X the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ X +#include X #include X X #include "config.h" diff -rNu3 lemacs-19.1.org/src/m/m-mips.h lemacs-19.1/src/m/m-mips.h --- lemacs-19.1.org/src/m/m-mips.h Thu Mar 21 16:47:31 1991 +++ lemacs-19.1/src/m/m-mips.h Fri Jun 12 11:36:50 1992 @@ -125,7 +125,9 @@ X /* Supposedly the dec machine doesn't have this library. X #define LIBS_MACHINE -lmld */ X +#ifndef LD_SWITCH_MACHINE X #define LD_SWITCH_MACHINE -D 800000 +#endif X #define LIBS_DEBUG X X #else diff -rNu3 lemacs-19.1.org/src/m/m-risc-news.h lemacs-19.1/src/m/m-risc-news.h --- lemacs-19.1.org/src/m/m-risc-news.h +++ lemacs-19.1/src/m/m-risc-news.h Fri Jun 12 11:34:50 1992 @@ -0,0 +1,38 @@ +#include "m-mips.h" +#undef LIBS_MACHINE + +#define LIBS_MACHINE -lmld + +#define COFF +#ifdef LD_SWITCH_MACHINE +/* define already define LD_SWITCH_MACHINE */ +/* undefining LD_SWITCH_MACHINE */ +#undef LD_SWITCH_MACHINE +#endif +#ifdef LD_SWITCH_MACHINE +/* funny define LD_SWITCH_MACHINE */ +#endif +#define LD_SWITCH_MACHINE -x -D 800000 + +/* more pure Lisp code area when risc machine. */ +#define RISC + +#if 0 +#define PURESIZE 142000 /* (122000 + MORE) MORE=20000 */ +#endif /* 0 */ + +/* #define C_OPTIMIZE_SWITCH -O2 */ +#define C_OPTIMIZE_SWITCH -O + +#define C_DEBUG_SWITCH -g3 + +/* Define BIG_ENDIAN iff lowest-numbered byte in a word + is the most significant byte. */ + +/* done in endian.h: #define BIG_ENDIAN */ +/* so need to undef to avoid the confilict in wait.h */ +#undef BIG_ENDIAN */ + +#undef TERMINFO + +#define NO_REMAINDER diff -rNu3 lemacs-19.1.org/src/ymakefile lemacs-19.1/src/ymakefile --- lemacs-19.1.org/src/ymakefile Thu Jun 4 05:41:24 1992 +++ lemacs-19.1/src/ymakefile Fri Jun 12 11:01:40 1992 @@ -342,7 +342,7 @@ X X #ifndef HAVE_ALLOCA X foo = $(mallocobj) -mallocobj = $(foo) alloca.o +mallocobj := $(foo) alloca.o X #endif /* No ALLOCA */ X X #ifdef HAVE_X_WINDOWS @@ -714,8 +714,7 @@ X unexconvex.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h getpagesize.h X unexec.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h getpagesize.h X unexenix.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h -unexmips.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h filehdr.h -unexmips.o: aouthdr.h scnhdr.h sym.h +unexmips.o: config.h X unexsunos4.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h X vm-limit.o: config.h s/s-sunos4.h s/s-bsd4-2.h m/m-sparc.h mem_limits.h X vm-limit.o: SHAR_EOF chmod 0644 risc-news.diff || echo 'restore of risc-news.diff failed' Wc_c="`wc -c < 'risc-news.diff'`" test 4607 -eq "$Wc_c" || echo 'risc-news.diff: original size 4607, current size' "$Wc_c" fi exit 0 From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 09:02:02 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25713; Fri, 12 Jun 92 09:02:02 PDT Received: by heavens-gate.lucid.com id AA27477g; Fri, 12 Jun 92 08:19:30 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA27471g; Fri, 12 Jun 92 08:19:12 PDT Received: by moebius.loria.fr id AA11091 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Fri, 12 Jun 92 17:25:24 +0200 Date: Fri, 12 Jun 92 17:25:24 +0200 From: Guido Bosch Message-Id: <9206121525.AA11091@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: illegal menu callback Reply-To: Guido BOSCH Using the popup menu of the info mode (button 3), I noticed the following behavior: When popping up a menu, dragging the mouse into a non-sensitive title field and releasing the mouse button there, Emacs signals the error "illegal menu callback: 0". Looks like a bug, doesn't it? Guido From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 09:27:58 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25768; Fri, 12 Jun 92 09:27:58 PDT Received: by heavens-gate.lucid.com id AA27556g; Fri, 12 Jun 92 08:54:25 PDT Received: from banzai.cc.columbia.edu by heavens-gate.lucid.com id AA27552g; Fri, 12 Jun 92 08:54:17 PDT Received: by banzai.cc.columbia.edu (5.59/FCB) id AA29143; Fri, 12 Jun 92 12:02:15 EDT Date: Fri, 12 Jun 92 12:02:14 EDT From: Ben Fried To: bug-lucid-emacs@lucid.com Subject: Popup menus can't GrabPointer? Message-Id: When I try using popup menus (e.g. using button3 in info) I get the following message on my console: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 26 (X_GrabPointer) Minor opcode of failed request: 0 Resource id in failed request: 0xc Serial number of failed request: 1140 Current serial number in output stream: 1140 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 26 (X_GrabPointer) Minor opcode of failed request: 0 Resource id in failed request: 0xc Serial number of failed request: 1499 Current serial number in output stream: 1499 This happens using OpenWindows 3 or using MIT's X11R5, using Motif or olvwm3. What am I doing wrong? Ben From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 10:32:28 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25870; Fri, 12 Jun 92 10:32:28 PDT Received: by heavens-gate.lucid.com id AA27417g; Fri, 12 Jun 92 07:58:49 PDT Received: from mailgate.ericsson.se by heavens-gate.lucid.com id AA27413g; Fri, 12 Jun 92 07:58:41 PDT Received: from edsvhs1 (edsvhs1.ericsson.se) by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.10) id AA25151; Fri, 12 Jun 92 17:06:57 +0200 Received: from vhs1c8.edsvh ([136.225.132.9]) by edsvhs1 (4.1/SMI-4.1) id AA15218; Fri, 12 Jun 92 17:02:58 +0200 Date: Fri, 12 Jun 92 17:02:58 +0200 From: edsrik@edsvhs1.ericsson.se (Rikard Ambric) Message-Id: <9206121502.AA15218@edsvhs1> To: bug-lucid-emacs@lucid.com Subject: Trying to compile lemacs19.1, on a Sun with OpenLook Cc: edsrik@edsvhs1.ericsson.se Hello! While trying to compile lemacs19.1 for OpenLook , OpenWindows 2 X Windows version 11R4, SunOs4.1.1, Sparc, with gcc2.2.1, I get the following problem: ****************** PROBLEM 1 ********************************** gcc -O2 -I/usr/local/lib/gcc-include -I/usr/openwin/include -Demacs -I./lwlib -c ScreenWidget.c ScreenWidget.c: In function `get_wm_shell': ScreenWidget.c:201: dereferencing pointer to incomplete type *** Error code 1 ****************** PROBLEM 2 ************************************** gcc -O2 -I/usr/local/lib/gcc-include -I/usr/openwin/include -Demacs -I./lwlib -c EmacsShell.c EmacsShell.c: In function `GetGeometry': EmacsShell.c:157: dereferencing pointer to incomplete type EmacsShell.c: In function `emacsShellRealize': EmacsShell.c:274: dereferencing pointer to incomplete type EmacsShell.c: In function `EvaluateWMHints': EmacsShell.c:332: dereferencing pointer to incomplete type EmacsShell.c: In function `_popup_set_prop': EmacsShell.c:381: dereferencing pointer to incomplete type EmacsShell.c:391: dereferencing pointer to incomplete type EmacsShell.c:431: dereferencing pointer to incomplete type *** Error code 1 ****************** PROBLEM 3 ************************************** gcc -c -O -I/usr/include -I/usr/openwin/include lwlib-Xol.c lwlib-Xol.c:2: xt_extension.h: No such file or directory *** Error code 1 ****************** PROBLEM 4 ************************************** gcc -c -O -I/usr/include -I/usr/openwin/include lwlib-utils.c lwlib-utils.c: In function `XtApplyToWidgets': lwlib-utils.c:53: dereferencing pointer to incomplete type lwlib-utils.c: In function `XtApplyUntilToWidgets': lwlib-utils.c:84: dereferencing pointer to incomplete type lwlib-utils.c:89: dereferencing pointer to incomplete type lwlib-utils.c: In function `XtCompositeChildren': lwlib-utils.c:114: dereferencing pointer to incomplete type *** Error code 1 Maybe somebody can tell me what's wrong? /Rikard Ambric! From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 11:18:30 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25922; Fri, 12 Jun 92 11:18:30 PDT Received: by heavens-gate.lucid.com id AA27979g; Fri, 12 Jun 92 10:41:47 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA27975g; Fri, 12 Jun 92 10:41:32 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01881; Fri, 12 Jun 92 10:49:55 PDT Date: Fri, 12 Jun 92 10:49:55 PDT Message-Id: <9206121749.AA01881@thalidomide.lucid> X-Windows: It could be worse, but it'll take time. From: Jamie Zawinski Sender: jwz@thalidomide To: edsrik%edsvhs1.ericsson.se@lucid.com (Rikard Ambric) Cc: bug-lucid-emacs@lucid.com Subject: Re: Trying to compile lemacs19.1, on a Sun with OpenLook In-Reply-To: Rikard Ambric's message of Fri 12-Jun-92 17:02:58 +0200 <9206121502.AA15218@edsvhs1> References: <9206121502.AA15218@edsvhs1> In message <9206121502.AA15218@edsvhs1> Rikard Ambric wrote: > > ScreenWidget.c ScreenWidget.c: In function `get_wm_shell': > ScreenWidget.c:201: dereferencing pointer to incomplete type *** Error code > 1 Marc_Rocas.Wbst129@xerox.com said this: > > I had a similar problem which was due to the fact that when I built gcc2.1 > and performed fixincludes I was still in X11R4. During compilation, > gcc-lib/../include/X11 headers were being fetched instead of > /usr/include/X11R5. As soon as I realized this, I simply deleted all the > modified X11 headers under gcc, and simply allowed X11R5 headers to be used > instead and everything compiled with no problems. Hope this helps. > gcc -c -O -I/usr/include -I/usr/openwin/include lwlib-Xol.c > lwlib-Xol.c:2: xt_extension.h: No such file or directory Don't bother trying to compile with USE_OLIT yet, it's broken in the released version. -- Jamie From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 11:24:14 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25931; Fri, 12 Jun 92 11:24:14 PDT Received: by heavens-gate.lucid.com id AA27523g; Fri, 12 Jun 92 08:39:24 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA27519g; Fri, 12 Jun 92 08:39:06 PDT Received: by moebius.loria.fr id AA11216 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Fri, 12 Jun 92 17:45:19 +0200 Date: Fri, 12 Jun 92 17:45:19 +0200 From: Guido Bosch Message-Id: <9206121545.AA11216@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: Lucid Emacs crashing down calling popup-menu Reply-To: Guido BOSCH Try this: (popup-menu ["test" nil nil]) Typing C-x C-e after this expression makes crash down immediatly my Lucid Emacs 19 (the binary version from labrea.Stanford.EDU). BTW, is there a documentation of the menu specification format that `popup-menu' accepts? Especially, I'm interested on how to specify recursive submenus in a popup menu. (This should be documented in the function `popup-menu', after my opinion) Guido From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 11:44:48 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA25965; Fri, 12 Jun 92 11:44:48 PDT Received: by heavens-gate.lucid.com id AA28081g; Fri, 12 Jun 92 11:08:21 PDT Received: from sapir.cog.jhu.edu by heavens-gate.lucid.com id AA28077g; Fri, 12 Jun 92 11:08:12 PDT Received: from localhost by sapir.cog.jhu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA11257; Fri, 12 Jun 92 14:16:11 EDT Message-Id: <9206121816.AA11257@sapir.cog.jhu.edu> To: bug-lucid-emacs@lucid.com Subject: Re: Ongoing NeXT problem In-Reply-To: My message of "Thu, 11 Jun 92 15:26:33 EDT." <9206111926.AA08899@sapir.cog.jhu.edu> Date: Fri, 12 Jun 92 14:16:11 -0400 From: anderson@sapir.cog.jhu.edu Eureka! I got lemacs to run on my NeXT. After posting yesterday about problems getting GNU-malloc to work, I got a couple of notes telling me not to bother, but to use the system malloc. That left me with five undefined symbols: one (__start) which turned out to be the result of a miplaced patch of my own; one (S_ISDIR) which is a Sun-specific definition in that I was able to replace in the same way a previous poster did when building on an H-P; one (remainder) a math function that I replaced with the apparently equivalent drem; one (putenv) that a helpful message told me I could find in the essentially undocumented library libcs.a; and one (strdup) that a couple of people sent me replacement code for. After making these changes (in addition to the NeXT-specific patches I made yesterday on the basis of NeXT-ified sources for emacs-18.57) xemacs built without further problem and appears to run. I'm using the co-Xist development environment from PenCom. As soon as I'm sure this is reasonably stable, I'll send a set of patches to Lucid for potential inclusion in future releases. Thanks to those who generously offered their help. --Steve Anderson From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 12:35:52 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA26043; Fri, 12 Jun 92 12:35:52 PDT Received: by heavens-gate.lucid.com id AA28279g; Fri, 12 Jun 92 12:02:16 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA28275g; Fri, 12 Jun 92 12:02:07 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA19065; Fri, 12 Jun 92 12:10:23 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA23087; Fri, 12 Jun 92 12:02:32 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA12964; Fri, 12 Jun 92 12:02:32 PDT Date: Fri, 12 Jun 92 12:02:32 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206121902.AA12964@farside.twinsun.com> To: anderson@sapir.cog.jhu.edu Cc: bug-lucid-emacs@lucid.com In-Reply-To: <9206121816.AA11257@sapir.cog.jhu.edu> (anderson@sapir.cog.jhu.edu) Subject: Ongoing NeXT problem Date: Fri, 12 Jun 92 14:16:11 -0400 From: anderson@sapir.cog.jhu.edu (S_ISDIR) which is a Sun-specific definition in that I was able to replace in the same way a previous poster did when building on an H-P Actually, S_ISDIR is the standard way to do things -- see Posix 1003.1-1990 section 5.6.1.1. For maximum portability, you should use S_IFMT and S_IFDIR only on old-fashioned hosts that don't define S_ISDIR. From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 12 15:06:24 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA26366; Fri, 12 Jun 92 15:06:24 PDT Received: by heavens-gate.lucid.com id AA28967g; Fri, 12 Jun 92 14:39:52 PDT Received: from uswat.advtech.uswest.com by heavens-gate.lucid.com id AA28963g; Fri, 12 Jun 92 14:39:42 PDT Received: from alder.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA18706 (5.65c/IDA-1.4.4 for ); Fri, 12 Jun 1992 15:48:01 -0600 Received: by alder.advtech.uswest.com (advtech.uswest.com) id AA15563 (4.1/at-generic.11Feb92); Fri, 12 Jun 92 15:48:02 MDT Date: Fri, 12 Jun 92 15:48:02 MDT From: Chris McClenaghan Message-Id: <9206122148.AA15563@alder.advtech.uswest.com> To: Lucid Emacs 19 Bugs Subject: Re: mail autosave file Seem to be withdrawing from alot of complaints from yesterday. I reported mail autosave files were not being deleted. This still happens, but the problem must be in my .emacs. If I start lemacs with -q, these files are removed on sending the message. Sorry, Chris McClenaghan mcclen@uswest.com PS Jamie, in case there is an open problem report from the beta, could you pass a note on? Thanks. From bug-lucid-emacs-request@heavens-gate.lucid.com Sat Jun 13 03:13:21 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA26995; Sat, 13 Jun 92 03:13:21 PDT Received: by heavens-gate.lucid.com id AA00363g; Sat, 13 Jun 92 02:49:01 PDT Received: from chx400.switch.ch by heavens-gate.lucid.com id AA00359g; Sat, 13 Jun 92 02:48:32 PDT X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Sat, 13 Jun 1992 11:56:17 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Sat, 13 Jun 1992 12:54:55 +0200 Date: Sat, 13 Jun 1992 12:54:55 +0200 X400-Originator: brossard@sasun1.epfl.ch X400-Recipients: bug-lucid-emacs@lucid.com X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9206130954.AA16610] X400-Content-Type: P2-1984 (2) From: "(Alain Brossard EPFL-SIC/SII)" Message-Id: <9206130954.AA16610@sasun1.epfl.ch> To: bug-lucid-emacs@lucid.com Subject: bug in key definitions Received: from sasun1.epfl.ch by SIC.Epfl.CH via INTERNET ; Sat, 13 Jun 92 11:54:57 N Received: by sasun1.epfl.ch (4.1/Epfl-3.1/MX) id AA16610; Sat, 13 Jun 92 11:54:55 +0200 This works: (global-set-key '(meta up) 'scroll-down-one) But this doesn't: (global-set-key '(shift meta up) 'scroll-up-five) However going back to using the "f" key symbol makes it work (global-set-key '(shift meta f34) 'scroll-up-five) Either "down/up/right/left" should always work or they should never work. Alain From bug-lucid-emacs-request@heavens-gate.lucid.com Sat Jun 13 08:25:40 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA27082; Sat, 13 Jun 92 08:25:40 PDT Received: by heavens-gate.lucid.com id AA00635g; Sat, 13 Jun 92 08:00:19 PDT Received: from chx400.switch.ch by heavens-gate.lucid.com id AA00631g; Sat, 13 Jun 92 08:00:12 PDT X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Sat, 13 Jun 1992 17:08:19 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Sat, 13 Jun 1992 18:06:59 +0200 Date: Sat, 13 Jun 1992 18:06:59 +0200 X400-Originator: brossard@sasun1.epfl.ch X400-Recipients: bug-lucid-emacs@lucid.com X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9206131506.AA17042] X400-Content-Type: P2-1984 (2) From: "(Alain Brossard EPFL-SIC/SII)" Message-Id: <9206131506.AA17042@sasun1.epfl.ch> To: bug-lucid-emacs@lucid.com Subject: Search mode and keyboard redefinition Received: from sasun1.epfl.ch by SIC.Epfl.CH via INTERNET ; Sat, 13 Jun 92 17:07:01 N Received: by sasun1.epfl.ch (4.1/Epfl-3.1/MX) id AA17042; Sat, 13 Jun 92 17:06:59 +0200 When in search mode, the documentation clearly specifies which keys have special meanings and then says that all the others just execute the command that is bound to them. However, none of the key bindings I added to DEL (meta +, ctrl +...) have their command executed when in search mode, instead a regular DEL seems to be issued. Here's an example of a keybinding I use: (global-set-key '(shift meta delete) 'backward-kill-word) It works normaly, but in search mode, it is ignored. Alain From bug-lucid-emacs-request@heavens-gate.lucid.com Sat Jun 13 09:06:26 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA27090; Sat, 13 Jun 92 09:06:26 PDT Received: by heavens-gate.lucid.com id AA00686g; Sat, 13 Jun 92 08:43:34 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA00682g; Sat, 13 Jun 92 08:43:27 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA04012; Sat, 13 Jun 92 08:51:52 PDT Date: Sat, 13 Jun 92 08:51:52 PDT Message-Id: <9206131551.AA04012@thalidomide.lucid> X-Windows: No hardware is safe. From: Jamie Zawinski Sender: jwz@thalidomide To: "(Alain Brossard EPFL-SIC/SII)" Cc: bug-lucid-emacs@lucid.com Subject: Re: bug in key definitions In-Reply-To: Alain Brossard EPFL-SIC/SII's message of Sat 13-Jun-92 12:54:55 +0200 <9206130954.AA16610@sasun1.epfl.ch> References: <9206130954.AA16610@sasun1.epfl.ch> In message <9206130954.AA16610@sasun1.epfl.ch> Alain Brossard EPFL-SIC/SII wrote: > > Either "down/up/right/left" should always work or they should > never work. This is not something emacs has control over. On Sun keyboards, some of the keys on the keypad generate "function key" keysyms and some generate "arrow key" keysyms. In fact, it's even sillier than that: most of the keypad generates "F" keys, except for 8, 4, 6, and 2, which generate arrow keys, and 1, which generates r13! Emacs just uses the name (downcased) that X knows the key by. I think that to do otherwise would be more confusing. You can change the keysyms that the keyboard generates with `xmodmap'. > This works: > > (global-set-key '(meta up) 'scroll-down-one) > > But this doesn't: > > (global-set-key '(shift meta up) 'scroll-up-five) I presume you're running the OpenWindows server. Under OpenWindows, holding down the shift key and typing the up-arrow key generates the keysym "f28" instead of "up". Since the keyboard map contains an explicit binding for the shifted version of that key, emacs uses that instead of the `shift' modifier. This means that `shift up' is not considered to exist, any more than `shift 5' and `%' are the same, from Emacs' point of view. (This isn't true in the default configuration of the MIT sun4 server: shift-up has no special meaning.) Actually, I've noticed that emacs interprets `up' as `up' and `shift-up' as `shift-f28' instead of just `f28', which is wrong. I'm going to fix this. -- Jamie From bug-lucid-emacs-request@lucid.com Sat Jun 13 12:55:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07854; Sat, 13 Jun 92 12:55:48 PDT Received: by heavens-gate.lucid.com id AA01095g; Sat, 13 Jun 92 12:47:03 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA01087g; Sat, 13 Jun 92 12:45:17 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA04431; Sat, 13 Jun 92 12:53:45 PDT Date: Sat, 13 Jun 92 12:53:45 PDT Message-Id: <9206131953.AA04431@thalidomide.lucid> X-Windows: The problem for your problem. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: help-lucid-emacs@lucid.com, bug-lucid-emacs@lucid.com Subject: these mailing lists are now archived These mailing lists are now being archived on labrea.Stanford.EDU (36.8.0.47) in the files pub/gnu/lucid/help-lucid-emacs and pub/gnu/lucid/bug-lucid-emacs. All messages that have been sent to these lists so far are there now. Enjoy... -- Jamie From bug-lucid-emacs-request@lucid.com Sat Jun 13 20:00:31 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08374; Sat, 13 Jun 92 20:00:31 PDT Received: by heavens-gate.lucid.com id AA01552g; Sat, 13 Jun 92 19:51:48 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA01548g; Sat, 13 Jun 92 19:51:41 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA04867; Sat, 13 Jun 92 20:00:12 PDT Date: Sat, 13 Jun 92 20:00:12 PDT Message-Id: <9206140300.AA04867@thalidomide.lucid> X-Windows: Garbage at your fingertips. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bug-lucid-emacs@lucid.com Subject: X KeySym capitalization I'd like some input about how emacs deals with X keysyms. Basically, emacs thinks that a key is a symbol, and a set of modifier bits (though it also accepts ASCII codes and does the appropriate translation.) X keysyms are roughly analogous to symbols, so the transformation from one to the other would seem to be pretty straightforward. However, X keysyms contain mixed case, and are case sensitive. Since there are an unlimited number of potential keysyms, especially since it's possible for users to define new ones simply by adding them to the XKeysymDB file, it's not possible (well, it's really hard) for emacs to flag uses of keysyms that don't exist. And even if it wasn't that hard, it wouldn't be a good idea, because it would mean that your .emacs file could stop working just because someone changed something about the X configuration. A result of this is that if you get the case wrong when making a key binding, it fails silently. This can be confusing. So, to make it easier to get right, emacs downcases all X keysyms that it reads from the server before turning them into symbols: you merely have to remember never to type keysyms in upper case (except for A-Z). I was going to make this more automatic by having emacs downcase the input to define-key, global-set-key, etc as well. But then I realized that global case-folding is completely wrong in this case, because it would lose the distinction between characters like aacute and Aacute: the "don't frob the case if the keysym name is only one character long" trick doesn't work in general. However, I think that it's unreasonable to make people type (global-set-key 'Delete ...) to the exclusion of (global-set-key 'delete ...) especially since this is purely an artifact of X that other window systems (and the tty interface, once it exists) won't have (one hopes). It looks to me like the case of the keysyms is "correct" with these character sets: Latin1, Latin2, Latin3, Latin4, Kana, Technical, Special, Publishing, APL, and Hebrew. Arabic, Cyrillic, and Greek seem ok, except that the keysym names all begin with "Arabic_" instead of "arabic_" (etc). But I could live with that I guess. The real problem is the Keyboard and vendor-specific character sets. They really played fast-and-loose with the capitalization on these. Imagine the confusion that would be caused by the case-sensitivity of "BackSpace". And just when you think you've gotten it figured out with keys like "KP_Equal" and "Scroll_Lock", they throw "Mode_switch" and "Multi_key" at you. The vendor-specific keysyms are just as outlandish, with names like "SunSys_Req", "WYSetup", and "osfBackTab". I think perhaps the right thing to do is to only downcase the keysyms from the Keyboard character set, and leave the rest alone. Another possibility would be to maintain a table associating the downcased version of all of the X keysyms with their "canonical" case, and have define-key consult that. That would be a big table, however. Remember, one of the goals is portability. If some random package binds a function to f1, one shouldn't have to change anything to make that command be executed when some user hits their f1 key on a tty, or under emacs running under some hypothetical other window system. I'd like to do this by using the rule that, for the keysyms that are likely to be common among window systems (i.e., who cares about osfBackTab) keysym names are lower case unless there's a good reason to do otherwise (as with eacute and Eacute.) Pleasantly enough, appendix E of the X Protocol reference, which lists all the predefined keysyms, lists them all in upper case with long descriptive names like "LESS THAN SIGN" and "LATIN CAPITAL LETTER I WITH GRAVE ACCENT". So this probably means that, on some random implementation of X somewhere, the capitalization of the keysyms in the Latin* character sets is just as messed up as in the Keyboard character sets of the MIT and Sun distributions, since it's not really standardized. Any comments on this? (On a related note, I think that perhaps it would make more sense for the "keypadness" of a key to be a bit, rather than being a part of the keysym name. So instead of binding something to KP_Enter, you'd bind it to '(keypad enter). Just a thought.) -- Jamie From bug-lucid-emacs-request@lucid.com Sun Jun 14 07:56:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10178; Sun, 14 Jun 92 07:56:02 PDT Received: by heavens-gate.lucid.com id AA02436g; Sun, 14 Jun 92 07:47:13 PDT Received: from clouso.crim.ca by heavens-gate.lucid.com id AA02432g; Sun, 14 Jun 92 07:47:05 PDT Received: from ireq-robot.hydro.qc.ca by clouso.crim.ca (4.1/SMI-4.1) id AA16885; Sun, 14 Jun 92 10:55:13 EDT Received: by ireq-robot.hydro.qc.ca (4.1/IRBT-2.4) id AA20141; Sun, 14 Jun 92 10:58:05 EDT Date: Sun, 14 Jun 92 10:58:05 EDT From: Martin Boyer Message-Id: <9206141458.AA20141@ireq-robot.hydro.qc.ca> To: bug-lucid-emacs@lucid.com Subject: Re: X KeySym capitalization References: <9206140300.AA04867@thalidomide.lucid> >>>>> Jamie Zawinski writes: 1 ------------------- >X keysyms contain mixed case, and are case sensitive. [...] >A result of this is that if you get the case wrong when making a key binding, >it fails silently. This can be confusing. No different from the way emacs 18 works; if you enter the wrong string, an "unreachable" string will be bound to some function, silently. I detect those immediately; after binding a key, I'm so eager to try it... 2 ------------------- >[One should never] type keysyms in upper case (except for A-Z). Is that really necessary? Why can't I type '(Shift a) instead of '(A)? 3 ------------------- >maintain a table associating the downcased version of all of the X >keysyms with their "canonical" case, and have define-key consult >that. That would be a big table, however. Given that emacs reads keys from the server much more often than from define-key, it seems more efficient to "normalize" keystrokes at binding time rather than at typing time (don't bother to downcase what is read from the server). That said, if emacs is to impose a standard on keysym-to-symbol mapping, a translation table could take care of *exceptions* (instead of *all* keysyms). 4 ------------------- >Remember, one of the goals is portability. [...] I'd like to do this >by using the rule that, for the keysyms that are likely to be common among >window systems (i.e., who cares about osfBackTab) keysym names are lower >case unless there's a good reason to do otherwise (as with eacute and >Eacute.) I'd rather "keysym names are case insensitive unless..."; if all my X documentation talks about BackSpace, I don't want to do a mental translation every time I bind keys in emacs. And I certainly don't want to tell Joe User "if you use emacs, it's 'backspace', but otherwise it's 'BackSpace'". But I don't mind reminding everybody that 'BackwardSpace' isn't the same keysym as 'BackSpace'. And If some other window system uses 'Backspace', there will not be any portability problem. If error checking is the issue, then keysyms should be case insensitive as much as possible (reduce complexity to prevent errors). Specially since it appears that there is no hope to flag unexistant keysyms. 5 ------------------- >on some random implementation of X somewhere, the capitalization of >the keysyms in the Latin* character sets is just as messed up as in >the Keyboard character sets of the MIT and Sun distributions, since >it's not really standardized. If define-key doesn't discard information, and the emacs way of doing things is documented (i.e. "Whatever the implementation says, and since there is no formal standard, the emacs de-facto standard is to use Aacute and aacute."), an implementation-specific elisp file can define keysym translations to please any server. 6 ------------------- >(On a related note, I think that perhaps it would make more sense for the >"keypadness" of a key to be a bit, rather than being a part of the keysym >name. So instead of binding something to KP_Enter, you'd bind it to >'(keypad enter). Just a thought.) Since the "keypadness" is not orthogonal (it can't be applied to letters, for instance), it should remain part of the keysym. Just a thought. Martin From bug-lucid-emacs-request@lucid.com Sun Jun 14 09:41:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10405; Sun, 14 Jun 92 09:41:58 PDT Received: by heavens-gate.lucid.com id AA02512g; Sun, 14 Jun 92 09:33:15 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA02508g; Sun, 14 Jun 92 09:32:50 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA27069; Sun, 14 Jun 1992 18:40:19 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01150; Sun, 14 Jun 92 18:43:13 +0200 Received: from tonus.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA05937; Sun, 14 Jun 92 18:37:05 +0200 Date: Sun, 14 Jun 92 18:37:05 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206141637.AA05937@geant.cenatls.cena.dgac.fr> Received: by tonus.cenatls (4.1/SMI-4.1) id AA00779; Sun, 14 Jun 92 18:37:15 +0200 To: Bug Lucid Emacs Subject: define-key using a (KEYMAP . CHAR) definition fails. If I do (I know, it's stupid, see explications below): (define-key text-mode-map ?a '(lambda () (interactive) (insert "A"))) (define-key c-mode-map ?a '(text-mode-map . ?a)) Then when I type `a' in a C buffer, I got: Signalling: (wrong-type-argument commandp (text-mode-map . 97)) call-interactively((text-mode-map . 97)) Quoting the doc for define-key: "define-key: (keymap keys def) DEF is anything that can be a key's definition: ... or a cons (KEYMAP . CHAR), meaning use definition of CHAR in map KEYMAP." I need such a thing to port calc 2.02 to lucid-emacs. Calc initialises part of its keymaps with aset/aref, especially to define upper case version of keys. Note: I just try it with gnu emacs 18.57, and I got the same error. I should probably send it also to gnu.emacs.bug. Phil From bug-lucid-emacs-request@lucid.com Sun Jun 14 09:48:07 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10423; Sun, 14 Jun 92 09:48:07 PDT Received: by heavens-gate.lucid.com id AA02524g; Sun, 14 Jun 92 09:39:19 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA02520g; Sun, 14 Jun 92 09:39:06 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA27146; Sun, 14 Jun 1992 18:46:45 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01170; Sun, 14 Jun 92 18:48:43 +0200 Received: from tonus.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA06122; Sun, 14 Jun 92 18:42:37 +0200 Date: Sun, 14 Jun 92 18:42:37 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206141642.AA06122@geant.cenatls.cena.dgac.fr> Received: by tonus.cenatls (4.1/SMI-4.1) id AA00826; Sun, 14 Jun 92 18:42:49 +0200 To: Bug Lucid Emacs Subject: vm-reply needs (require 'vm) The subject says it: vm-reply.el needs a (require 'vm), else vm-mail fails if vm is not already loaded. In "standard" vm 5.31, almost every file begins with (require 'vm). Why has it been removed ? BTW, in the lemacs-19.1 distribution I got from ftp.inria.fr (same size as the one on labrea.stanford.edu), vm.el is missing, there is only vm.elc. Phil From bug-lucid-emacs-request@lucid.com Sun Jun 14 09:55:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10437; Sun, 14 Jun 92 09:55:03 PDT Received: by heavens-gate.lucid.com id AA02534g; Sun, 14 Jun 92 09:46:24 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA02530g; Sun, 14 Jun 92 09:46:14 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA27200; Sun, 14 Jun 1992 18:53:27 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01179; Sun, 14 Jun 92 18:56:17 +0200 Received: from tonus.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA06182; Sun, 14 Jun 92 18:50:11 +0200 Date: Sun, 14 Jun 92 18:50:11 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206141650.AA06182@geant.cenatls.cena.dgac.fr> Received: by tonus.cenatls (4.1/SMI-4.1) id AA00892; Sun, 14 Jun 92 18:50:22 +0200 To: Bug Lucid Emacs Subject: undo don't reset the modified flag after capitalization functions Load a standard text file, do a M-c (M-x capitalize-word), then C-x u. The capitalization is undone, but the modified flag stays. The same thing happens with upcase-word, downcase-word, upcase-region and friends. Phil From bug-lucid-emacs-request@lucid.com Sun Jun 14 15:17:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11013; Sun, 14 Jun 92 15:17:17 PDT Received: by heavens-gate.lucid.com id AA02873g; Sun, 14 Jun 92 15:08:33 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA02869g; Sun, 14 Jun 92 15:08:27 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA05300; Sun, 14 Jun 92 15:16:58 PDT Date: Sun, 14 Jun 92 15:16:58 PDT Message-Id: <9206142216.AA05300@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Cc: Bug Lucid Emacs Subject: Re: vm-reply needs (require 'vm) In-Reply-To: Philippe Queinnec's message of Sun 14-Jun-92 18:42:37 +0200 <9206141642.AA06122@geant.cenatls.cena.dgac.fr> References: <9206141642.AA06122@geant.cenatls.cena.dgac.fr> In message <9206141642.AA06122@geant.cenatls.cena.dgac.fr> Philippe Queinnec wrote: > > The subject says it: vm-reply.el needs a (require 'vm), else vm-mail fails > if vm is not already loaded. In "standard" vm 5.31, almost every file begins > with (require 'vm). Why has it been removed ? Our hacked copy of VM 5.32 has had only pretty minor changes from the official VM 5.32; this change in particular is one that Kyle made. > BTW, in the lemacs-19.1 distribution I got from ftp.inria.fr (same size as > the one on labrea.stanford.edu), vm.el is missing, there is only vm.elc. There is no longer a vm.el: vm.elc is constructed by concatenating all the other .elc files together. There are no `require' statements because you're intended to load/autoload everything from vm.elc instead of from the individual files, the idea being that just about everything ends up getting loaded anyway, so why not load it all at once. -- Jamie From bug-lucid-emacs-request@lucid.com Sun Jun 14 15:35:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11024; Sun, 14 Jun 92 15:35:45 PDT Received: by heavens-gate.lucid.com id AA02892g; Sun, 14 Jun 92 15:27:10 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA02888g; Sun, 14 Jun 92 15:27:01 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA05339; Sun, 14 Jun 92 15:35:32 PDT Date: Sun, 14 Jun 92 15:35:32 PDT Message-Id: <9206142235.AA05339@thalidomide.lucid> X-Windows: The defacto substandard. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Cc: Bug Lucid Emacs Subject: Re: define-key using a (KEYMAP . CHAR) definition fails. In-Reply-To: Philippe Queinnec's message of Sun 14-Jun-92 18:37:05 +0200 <9206141637.AA05937@geant.cenatls.cena.dgac.fr> References: <9206141637.AA05937@geant.cenatls.cena.dgac.fr> In message <9206141637.AA05937@geant.cenatls.cena.dgac.fr> Philippe Queinnec wrote: > > If I do (I know, it's stupid, see explications below): > > (define-key text-mode-map ?a '(lambda () (interactive) (insert "A"))) > (define-key c-mode-map ?a '(text-mode-map . ?a)) > > Then when I type `a' in a C buffer, I got: > Signalling: (wrong-type-argument commandp (text-mode-map . 97)) > call-interactively((text-mode-map . 97)) > > Quoting the doc for define-key: > "define-key: (keymap keys def) > DEF is anything that can be a key's definition: > ... > or a cons (KEYMAP . CHAR), meaning use definition of CHAR in map KEYMAP." The symbol `text-mode-map' is not a keymap: that is, (keymapp 'text-mode-map) returns false. Something is keymapp if it is a keymap object, or if it is a symbol whose -function- cell is keymapp. Both of these work: (define-key c-mode-map ?a (cons text-mode-map ?a)) and (fset 'foo text-mode-map) (define-key c-mode-map ?a '(foo . ?a)) > I need such a thing to port calc 2.02 to lucid-emacs. Calc initialises part > of its keymaps with aset/aref, especially to define upper case version of > keys. It should be a pretty mechanical transformation: just replace aref with lookup-key, and aset with define-key. This has the advantage of working in v18 as well. (However, unless something pretty funny is going on, I don't think calc should need to define upper-case synonyms. If there is no upper case binding of something, emacs uses the lower case binding automatically.) -- Jamie From bug-lucid-emacs-request@lucid.com Sun Jun 14 15:45:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11040; Sun, 14 Jun 92 15:45:25 PDT Received: by heavens-gate.lucid.com id AA02912g; Sun, 14 Jun 92 15:36:38 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA02908g; Sun, 14 Jun 92 15:36:29 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA05347; Sun, 14 Jun 92 15:44:59 PDT Date: Sun, 14 Jun 92 15:44:59 PDT Message-Id: <9206142244.AA05347@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Martin Boyer Cc: bug-lucid-emacs@lucid.com Subject: Re: X KeySym capitalization In-Reply-To: Martin Boyer's message of Sun 14-Jun-92 10:58:05 EDT <9206141458.AA20141@ireq-robot.hydro.qc.ca> References: <9206140300.AA04867@thalidomide.lucid> <9206141458.AA20141@ireq-robot.hydro.qc.ca> In message <9206141458.AA20141@ireq-robot.hydro.qc.ca> Martin Boyer wrote: > >>[One should never] type keysyms in upper case (except for A-Z). > > Is that really necessary? Why can't I type '(Shift a) instead of '(A)? `A' and `a' are distinct keysyms; I don't think it would be a good idea for both `%' and `(shift \5)' to work, because that can vary from keyboard to keyboard. `A' and `a' seem analagous, even though they are less likely to vary. >>maintain a table associating the downcased version of all of the X >>keysyms with their "canonical" case, and have define-key consult >>that. That would be a big table, however. > > Given that emacs reads keys from the server much more often than from > define-key, it seems more efficient to "normalize" keystrokes at > binding time rather than at typing time (don't bother to downcase what > is read from the server). Right, that's what I meant. > That said, if emacs is to impose a standard on keysym-to-symbol mapping, > a translation table could take care of *exceptions* (instead of *all* > keysyms). True. This has the disadvantage that this canonicalization won't happen for pre-dumped packages, since X is not yet initialized when the calls to define-key are made (and presumably the X-specific translation table has not yet been installed, under the assumption that some other window system might need a different translation table.) >>Remember, one of the goals is portability. [...] I'd like to do this >>by using the rule that, for the keysyms that are likely to be common among >>window systems (i.e., who cares about osfBackTab) keysym names are lower >>case unless there's a good reason to do otherwise (as with eacute and >>Eacute.) > > I'd rather "keysym names are case insensitive unless..."; I guess I would, too. I'm just not yet sure how to implement that. >>(On a related note, I think that perhaps it would make more sense for the >>"keypadness" of a key to be a bit, rather than being a part of the keysym >>name. So instead of binding something to KP_Enter, you'd bind it to >>'(keypad enter). Just a thought.) > > Since the "keypadness" is not orthogonal (it can't be applied to > letters, for instance), it should remain part of the keysym. Just a > thought. Well, my thought was that some keypads have keys on them that most don't; like keypad-F1. Some have keypad-equal, some don't. But it's probably just a silly idea. Forget it. -- Jamie From bug-lucid-emacs-request@lucid.com Sun Jun 14 22:27:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11578; Sun, 14 Jun 92 22:27:36 PDT Received: by heavens-gate.lucid.com id AA03342g; Sun, 14 Jun 92 22:18:45 PDT Received: from uhunix.uhcc.Hawaii.Edu by heavens-gate.lucid.com id AA03338g; Sun, 14 Jun 92 22:18:38 PDT Received: from (zero.ics.Hawaii.Edu) by uhunix.uhcc.Hawaii.Edu (4.1/Sun690) id AA21044; Sun, 14 Jun 92 19:27:02 HST Received: by (4.1/mail-client) id AA10383; Sun, 14 Jun 92 19:27:01 HST Date: Sun, 14 Jun 92 19:27:01 HST From: dxw@uhunix.uhcc.Hawaii.Edu Message-Id: <9206150527.AA10383@> To: bug-lucid-emacs@lucid.com Subject: please add me to your list thanks, -Dadong From bug-lucid-emacs-request@lucid.com Mon Jun 15 01:06:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12108; Mon, 15 Jun 92 01:06:54 PDT Received: by heavens-gate.lucid.com id AA03589g; Mon, 15 Jun 92 00:58:04 PDT Received: from srawgw.sra.co.jp by heavens-gate.lucid.com id AA03585g; Mon, 15 Jun 92 00:57:48 PDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA08457; Mon, 15 Jun 92 17:05:54 +0859 Received: from srarc2.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA01828; Mon, 15 Jun 92 17:05:28 +0900 Received: by srarc2.sra.co.jp (5.61/6.4J.6-SJ) id AA23276; Mon, 15 Jun 92 17:05:42 +0900 Date: Mon, 15 Jun 92 17:05:42 +0900 From: hikichi%srarc2.sra.co.jp@lucid.com (Nobuyuki Hikichi) Return-Path: Message-Id: <9206150805.AA23276@srarc2.sra.co.jp> To: bug-lucid-emacs@lucid.com Subject: report to try to port MIPS RISC os Reply-To: hikichi%sra.co.jp@lucid.com I try to port lemacs 19.1 to RISC os 4.51. I can do startup with following diff. Almost these files are compiled with mips C compiler except extents.c and faces.c. The last files need to be compiled with gcc in my machine. I could not compile all files with gcc(2.2.2) and could not compile them with mipc C Compiler. I guess both of them compile has a bug. By the way this patch is incorporated with following informations too. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: Compiling Lucid GNU Emacs on HP9000/425 BSD Date: Thu, 11 Jun 92 21:07:57 PDT It has been claimed that drem and remainder are the same, does anyone disagree? I was going to use #ifdef BSD return (make_float (drem (f1,f2))); #else return (make_float (remainder (f1,f2))); #endif From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: lemacs on a NeXT Date: Thu, 11 Jun 92 14:28 PDT : : strdup and remainder are also missing from Ultrix libraries. Here's strdup from the GNU libiberty (from gdb) char * strdup(s) char *s; { char *result = (char*)malloc(strlen(s) + 1); if (result == (char*)0) return (char*)0; strcpy(result, s); return result; } : Name: Nobuyuki Hikichi Office: Software Research Associates, Inc. Japan. #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 06/15/1992 08:01 UTC by gnu@srarc2 # Source directory /tmp # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 12237 -rw-r--r-- risc-os.diff # # ============= risc-os.diff ============== if test -f 'risc-os.diff' -a X"$1" != X"-c"; then echo 'x - skipping risc-os.diff (File already exists)' else echo 'x - extracting risc-os.diff (Compressed)' sed 's/^X//' << 'SHAR_EOF' | uudecode && begin 600 _shar_cmp_.tmp M'YV,9-*8,0.BA1PG=6:`8%.F39@QAX!"F2I,DS":B@J0-" M21TW($#0``&CAHX:,73,4#@QAPP%*\+F7,G39="A,HV>3-#D#52G4&/4`!$# MAM:L-6#0S>%5`1`@!6&PT+LB!HL9<_^";?OV*=VY,6SHJ'H5,E\948^X89IF M#@@W;^B`J.(F#9ZH*,YL!A%&-,#,N3B\#)PR;HB[&9/'1>T$"4#4F8/<.1PV:<:D$1UF MSIPTJMM@%TWG#6L[;]*0`5%&CAR,WJU0VVVYO8"'&6Y,-P8*#N4A1AE?D$=' MA&/(409V7]"Q'D-?F(&10W2D(-QXY>%Q7GKKU99&:1J&@9X>K:7A%@@>RO'9 MC"*]!\(0`0Z(&TQMO-!&"]#!08,+:`CG1AEW@*`3&BLB1]QO+,H(U6\,T8@1 M"$TD`<44($B1Q!1#@/#&'+79T=][,QZ)18\KV/:C1T$.6>1T2=Z7WW[*(7<' M;*6-Q)H8;]0A&A-$?#'%%4E0,0027S01Q*-).%$$G'(6R,8=Z(GQPJ:=NC"& M<&.\T89\;HA6J&@C]/>?C37>"%6.:>P88'A1Y4H>;&.@(:IPNQ$=K2'I`Z;(>H2= M'6G\YX:HJ06U[A>2!\H2@51`RA[[<@E)H@';?FFFMO#KX!&QGP6A@& M&5\P.T88U]E+8K[[]OMOK"=P$<8)!1N\$*=I>`IJR;_>BYR^4_#K[Q<`ST%' M0&\@R5IVN,TUP;`8]1.DQB/+0& M'7(LJSH(ST8[K5MC(!>KA&K443F28-5==QEVN)ARL,.V%[+!"!.Z\/;"(N>] ML7*>]4(38?2&91G"$6<<8@G<",I""'"0A8]E) M2WR2D:L)97WM\PUPZ(]-*5K_RE(#5@P0U` ML((D+E$Q7`J"I;!`A1[$0`$@P.(([+:?%A"A"E,X`L"F<"TK..D-:G((<&[& M)\KUQR;]^U\`>U`0E+1`"#*+$>A:D(073"P@;&##0U13AQ><80QC:$'RI%4& ML(P@C@"<`AU;8$<\DDM#>^SC'X$CR#$0TI"(5.1VE-=($&S1"%O"`G9,XX*H M..%"Q-E/K-J`1I4`1XM1J5T0B,"$)`BA")(L"!OP@$4%$)`@!D&(0FRHP)Z, M4",%"MX8AE>\YMF,F2&,P4L\(DUJ&@\-'6Q!`K/YS&V^H)O$^V92ZH"<(,#! M1C&8"@QRH`,92$:(>^E+6%8PSK)H,YK"2Z:SH#`0I:3PW&XUAH0%(X.34/) M'$R%G#<0I$]M?I MX(.D!%RA#/LY*`BX(ID:W*">F"DB#?GY6,3"9+*I(V@/#RH7NC!TH5JQ3%^. MV((9"&:)*["M1:&8JS[A1ISO\TQ]5`:P/K6AE1Z]T&]W=Y[6E,%FL2*#_:0W MGQC-:$8[C8!.-CI*1(!`!MB(RAZ>K/@5!$LX[K>4<-0Q.`NX$DQ,2T1!G#A4J&;,8C)PG MR11WUI)90T"0AT*IS#L&FX)R??L^$+C`!3F4%*4L!:98(1@],A.;DQX"I25Y M!G>^=4/Y/&/7+-)V!C>P:&Z#_$0@9)?""?XN0X1KGXO%RKC(36Z%6\!<01X' MNEM:D8?,!)6UM75(6\U5<'&#AD*Q83\Q71*(03#>\M(WO75JP1S@P"O_SI?` M]8WSG>#[WY[>QB0/0QY4?"LP-ULI\6GU+IUKXN=I'8]!"WF5"#E33-RCN"$*NBZ=L5>08!'H&P0,-O9PX8V MF\F;T6H#&]?"GAVTBPF"`!-AJ,B10A&8\`5QVPYY!.DP4_Z4JN0T&5^^M5#] MF`9J%^V[-5NJT9'%4(>!](=SQD,-4`]\U/K8QR%N>.H[WR"&#WKF#NO1FW+, M"K4SH$$TH+F#"U*P[5071"Y.9*)<6%WD(S^A3W+`.'G$*@)$BD!MG`3!@Y"Z MYJADP<-$&@\=Q'DQD8!`BE-(PHY"#8<)RF'-;6X!M=$]FH]^X0A#B/:TJPW& M(EP]ZR4O]VVF3B7D=/T+3`![FP%\FR3$V\-P$VK9]W/V)CR!"DDP@J"1?#(Q M")@W)RR#6/'*80^W0>CY:^0Q#:C,?BY0L#!A'+FT6MH+%DCRCAM#.!WOS,A> MOG&BLBQFC_Y.$,@@!W29P5UT0(.IB':?G'?)YR<_AH(VYH<)K:?J[?E0DTL$ M*S)H-?!9$(,8Q)KE(Q2Q`H0@@0,%FVE`O$/2`CDSH#!R^8(3ZM?4' M(,""_YX0!"I$?_KU:H$/,`\"X6"A4N:7OO3JM8,CBQDSS*>"\Z$O_S;(QOK8 MIWW;!A4, M$D$=0H#11P:1$WW*QP)F(!LID`(3V"IL0![V%Q4;V('1!W@AJ#"B@0*1$P8K M0APV@@(GF((KR(*.=&QF8']]8&POB!P!=FH@T$M30%+C5WY?H'_/%W91\2A% M,`1+\`7-U@2_)`5?,`1/4`12,`1>)RE2L`1F"('4)U8P0(2+ETP(5'DBY'DP M44&4=UB6EX<@)"J;9X<,!$U^N!*A=UG[P3Y/)0-Z`0,XH`,Q\(@T0$0S!'N" M:$YZ6'NKY1BM57P-I16N-T.T10,YP`(.M0*D2'QZ`47F!2WH)0(P!@=V-FMX MEEZE539&<#92 ML()%F!W()B"SUHL=]01?(`5$<`52H$75QHW>"(ZF9VS6>(2T57Q5<1@J5Q>E M>'K'ERM$4`1&8`5!((9"\`1/P`31)P*@$2C'44T:HB8B(%8F$)`K,I`/49!E M8!CV)P).X!8M4!KX(Q\Y`@)%`$+(XQER\!2!@A(8IQRK(F@,.08.F1S]`1TZ MQ@8N(`)$"`))2#4:90:U=H%@T2NPP69@\31]`PSP4\&HY,VH@)S,(%[ MD(%1891L9B'MQ0:B043F8%_0T<]Z!Q!*58GT`,G0(1$ MN9E4T8*-!@,9*"&'(WWE(U9_$Y9B)98XE8ZK&101XP;LXBZH,B$NTADY:)F" MYU:%09HSV2JV.8=^%7N#B(FZV2ZD`SJ76"#K`IWOHGF-Q9R0IR[/Z2ZA-P6. MX4[PA'HP(`/U1$\U$%J56$-\*'MYV)W1:7L^A%">2(JLMT2BM8XP<%LJMY_$ M9WQ0!!Z-A@(A(`9C4#G1]S1BI0+#V94D9P+.J`(HP*!,E!)N0'+7!P*A.9I8 M!!Y1L90@X*&Z8GULAARDA1T5&@.H:9,==30:\P4=BBM1,:!!-)0N"(-Q(J-D&93$TY7+N*,]^J,+P09":H0QZC,!5@7D82.E MY@8G(!IED'$'EZ5;ZB1/01)5I2I8VAZX$11D%:/A,5QS)1\;YS1EIE8'AQ-W M("5N$:9Q9V^`4U1K)Z(&379XY+2V9[_E(>-"HC9 MJ:AXJ"Z36GM3T%:*&!6AA1>/"&2]9XF0BHF9*I^L!1D*)1G%UWL_-@-"MA6J M.(]D)U/P9X:3@G=6`'U79$I2FD6\R%%C0U,C55(G58LJ100NJC*TCP*PISF-*[,0JD>%*Z7^@+H MJB`)`)Y0T:DRX'J2P8B3@7JOQYX@Y$_GNBSPNHFXYXF>6`.R!5$GET2G*!>[ M)6LNXA8BF7'6UFP:"4([D*;(06(+1H90D`65<@3(Y79R(U;;M1X9^P98Y%N0 MHUQ38%=T\"='A4J^9EUN(%8V<`-SP3[N<71J(E9#("QB`#5D0!)B)2E4(0,Q M,`.E6'5!@%QK=V>NF%(9EBW;DJ[-2HM1BQSALEZ79"[D=JVOB%IV]JU_U:^/ MUZY>-3Z/:K9]Z!%I"U;8N:YL>X<-5"!ORS"UIQ1,T:GQ1!>200.?%1FCRJ\W MU+8O<+>A)[#TJ5`,Y5FN&E$S0`.Q*KDQ@!FL^&8U9RH01P:Z>*Q9FUX!,6?D M(@:S"+;3(@+8,Q^=2Y,;]6O$:E.>BZW)NJQ>VVW#^+K&6ILZA8VFJ[6N`AI> MNU7.,9!0\31U@)+\H2:I$B'$4P;"4J+*.R%/X[QM<*A\Q7C@.K?-J2G:9UC: M:TZQ2#V5RJYU"Q/A2U!ZRR5AL(BP5A>3D14TX%#[>J+?R[US5EF*VXGP:YX+ M];@G%XE)I!"%`<"F2*O%`8.F5&UE0!+'H9L@P,#K@HZ["Q9;1W6*ZP08.@[?FJBDMK*Z.1;XJ_"DQG+%9!08,=\S$M>,"-1)1ON<9Q MJ:%<<`,G\,:V*3(3@R\G(`8G,,9U,YAV#,CUQ\=?K*%E$,A[54`FK)WMVG>? M0C*DN[9##+Z4/,FA$KN?'N+"XE6(0,R-%N0 M*QBHEUM4K!!0A$5YA$D!$Q(V@D6&W02`307%DR!69B6>L05=0*)D',X9@\;I MQ0-"0`=N0`1O<`=NX`,ZD`!YI%8CS`5N\%\B`-S"W18:XA;(G0`D&`9GT-S/ MC471'=QN4`5P<-WDP1`HR=WRA5-+"!;?+=S$;=SD32[,G0+.+=UN0-U6&S\=4Z)@=B#5Z#C;D=8XL]:5W=J3"="0B0_+KYR.\2+ZN/245F*O9-(Z[?W>1?Y=$6D MNM=";B=%KEJO/+!!A)X'ZWN5FW*%(0-)A'I0%&#@"0>60Q[G_%2^11R@8V$O M+5W,HJ6BL:<;YQF=4CPHWG,)3'6]E#FRLV+0UP)LT`9GALW%%*RUABB*PBB. M`BDJA@254@0+_JR.OBB-\BB#3NF64A";@P/[.>K56*VU^M*!3C;U*`15<`1? M"\>-W%>)2L/FI.1S`%]!+B1#OF=&WLE(WJZV#E^CE>O!CK];3I]!]+?J"=J! M,1@J=QBF;632=AM@5F*QT@0_?E8@"6IB0B9/`":&AFA2X;3NK( M\?$A/_*/4O*Z<_+YM5\KW_(L__)N(_,T3TDKK_,\[_-`OY^E?HT';BS@W%&X M)@5=X@1&8/$9Y6MB;X9E?_9=?X0TZ6U4D(]4P'U)P`3`Y%86T@(50@TO?O@K)44_@O389&8`2.I/8$ MD>F0SNF37NE@7X%F?'7-MO!$_X2)HNF1WNF5#NH@(.JCKII"'\>K#_H2#_N? M+F=+?QTH[_0U+_NT'_1?+]<\;DZ[TA&^8LF33<0;X;S,+\,K7B#+WRO?&9ZE M-Q%'JQ5!M.P<+]G9I/S2C_V9/9_Z6T]60?/Y";F&@5M"U+"XE'@@(`0%9P;] ML:GX/P1=BAXC(7TDQ^J;;X9C6`1W_[%?\`1&('U;O$7T;_\&)P?Z7P;=]P88 M(7TDQ^J;;X;<5SM/((9/8`32M\5;!.M2%Q5#G5[S7C_DD=[3%A5#G5[S7C_D M<7-:S1][_/59A/RT7B`'DB!Z?[&_:GK_#C7#<5+@7,4BB%#0`4;,IP5+@7U##4C\9=IH`=E8%%2 M4,]0,Q)P*),LT*%[$'YTX`3IX19.\)KA1P<<+3!.\)KA1P=24,]0,Q)_F09Z M4`9VA0+U##4CD0(LT*%VF09Z4`8]5I6LS68I(%85+@7U##4C`84GI$7YT(`7,4BB<=E;+5QM[$'YTX`0: M0@<,(585/@14L"'#6>%24,]0,Q)_F09Z4`9VA0+U##4CD0)P*%85+@7U##4C M`84GI$7YT(`7,4BB<=E;X5QM[$'YTX`3IX19.\)KA1P<<+3!.\)KA M1P=24,]0,Q)_F09Z4`9VA0+U##4CD0(LT#.ZD@9Z4`8]5I6LS68I(%85+@7U M##4C`8%T M``7YD2K]D0*%20=S\)?+$4CJ5RH6X@+"R0)L2F;%P0;J5RH6X@(8-[2X"2WM M$1$^4"H6\@70TAX*(DCN\07"R0*QCKTG_/R+NAL15&(R_@*[$4'O$XBT7B"[ M$4'ODT),H5GR9!4TX,.A&-E"_/SFM!L1]#Y'/+`*]5DS0,O,7ELT$'SP3P/! MA]`++:P@@`1!L*OM1FQ!@$4>8A]T1`(?J)44IP:S023^9C\4IP8D2@)`^`9O M0'+^9C^.8_E9N6\4IP;M1TLVLU[XE?(M(`,V$V=S5F=ZP\!T1A+OH0?LVLU[XE?(M(`,V$V=S5F=ZP\!T1A+OH0?KA`<702J$ M15EZLUYRYEZW;C/KA5\IWP(R8#-Q-F=UQEC-\1Q%_@:D0EB4I3?K)6?N=>LV MLU[XE?(M(`,V$V=S5F=Z\SYH0(+BVQS/4>1O(!QAL"IH0((V`V%N@`8D:#/6 ML702J$15EZLUYRYEZW;C/KA5\I MWP(R8#-Q-F=U!DX@8`=#(O4$\P:D0EB4I3?K)6?N=>LVLU[XE?(M(`,V$V=S 95F=Z(Q]M\`523P=X@D5V,"123S!O(!P*`#?K ` end SHAR_EOF echo 'uncompressing file risc-os.diff' && compress -d < _shar_cmp_.tmp > 'risc-os.diff' && rm -f _shar_cmp_.tmp && chmod 0644 risc-os.diff || echo 'restore of risc-os.diff failed' Wc_c="`wc -c < 'risc-os.diff'`" test 12237 -eq "$Wc_c" || echo 'risc-os.diff: original size 12237, current size' "$Wc_c" fi exit 0 From bug-lucid-emacs-request@lucid.com Mon Jun 15 01:50:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12180; Mon, 15 Jun 92 01:50:50 PDT Received: by heavens-gate.lucid.com id AA03653g; Mon, 15 Jun 92 01:42:05 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA03633g; Mon, 15 Jun 92 01:39:40 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA12976; Mon, 15 Jun 1992 10:43:09 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA09131; Mon, 15 Jun 92 10:46:29 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA06894; Mon, 15 Jun 92 10:40:16 +0200 Date: Mon, 15 Jun 92 10:40:16 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206150840.AA06894@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA00789; Mon, 15 Jun 92 10:40:17 +0200 To: Bug Lucid Emacs Subject: stange focus problem I have a strange problem with lemacs "stealing" the mouse focus. It's very hard to trace, but here is a case where it seems to happen every time: First, create /tmp/long.el with: (defun takes-a-long-time () (interactive) (let ((i 100000)) (while (> i 0) (setq i (1- i)))) (message "Coucou")) Then, run a first lemacs -q &, and place it anywhere on your screen. Run lemacs -q -l /tmp/long.el -f takes-a-long-time &, and place the new window anywhere such that it does not overlay the first lemacs (it's very important). Start to type in the first lemacs, and when takes-a-long-time finished, the focus is magically transfered to the second lemacs ! Some observations: - if the second lemacs overlays the first, it works as it should (the focus is not transfered). - if the first lemacs overlays the second, the focus is transfered. - if you replace the first lemacs by a xterm, nothing special happens. - it sometimes happens when creating a new screen, but it's more rare. Configuration: lucid emacs 19.1 compiled with gcc 2.2.1 -O2 and lwlib compiled with USE_LUCID and without INCLUDE_EXTENSIONS. X11R5, MIT standard server up to fix #12 vtwm or twm, *without* RandomPlacement Other information is available on request, but as I said, it's rather strange and difficult to trace. Phil From bug-lucid-emacs-request@lucid.com Mon Jun 15 02:09:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12205; Mon, 15 Jun 92 02:09:22 PDT Received: by heavens-gate.lucid.com id AA03683g; Mon, 15 Jun 92 02:00:28 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA03679g; Mon, 15 Jun 92 02:00:15 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA06025; Mon, 15 Jun 92 02:08:52 PDT Date: Mon, 15 Jun 92 02:08:52 PDT Message-Id: <9206150908.AA06025@thalidomide.lucid> X-Windows: Japan's secret weapon. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Cc: Bug Lucid Emacs Subject: Re: stange focus problem In-Reply-To: Philippe Queinnec's message of Mon 15-Jun-92 10:40:16 +0200 <9206150840.AA06894@geant.cenatls.cena.dgac.fr> References: <9206150840.AA06894@geant.cenatls.cena.dgac.fr> Though I'm not completely sure, there's a very good chance that this is a window manager bug. We've uncovered quite a few of them, because lemacs is apparently exercising parts of the ICCCM that nobody has ever exercised before. When the focus is "stolen," does the title bar indicate that the stealing window has the focus, or is the titlebar indication of focus out of sync with reality? See if you can make the same sort of bad things happen with the following test program. There's a similar bug in the R5 version of tvtwm that goes away when you don't specify NoTitleFocus. -- Jamie ---------- slice 'n' dice --------------------------------- file: take-focus.c /* Test program for WM_TAKE_FOCUS protocol (ICCCM section 4.1.7) ** Matthieu Devin (devin@lucid.com) ** ** This is how we compile this program: ** cc -g -I/x11r4/usr.sun4/include -L/x11r4/usr.sun4/lib take-focus.c -o take-focus -lXaw -lXt -lXmu -lX11 -lm -lc ** ** The program creates 2 windows, "shell1" and "shell2". These ** windows use the locally active input model. With NCDwm in ** click-to-type mode there is no way to give the keyboard focus to ** "shell2" by clicking on it. NCDwm correctly send the WM_TAKE_FOCUS ** message to "shell2" but the ICCCM compliant reply, which it to call ** XSetInputFocus for "shell2" is ignored. ** ** The program prints messages when the WM_TAKE_FOCUS message is sent ** or when a Key event happens in a window. ** ** The program works fine with mwm, tvtwm or twm. ** ** This test program can also be passed a -global argument. It will ** then use the globally active input model which also does not work ** with NCDwm. */ #include #include #include #include #include #include Atom WM_PROTOCOLS; Atom WM_TAKE_FOCUS; static void init_atoms (display) Display* display; { WM_PROTOCOLS = XInternAtom (display, "WM_PROTOCOLS", False); WM_TAKE_FOCUS = XInternAtom (display, "WM_TAKE_FOCUS", False); } static void handle_message (widget, closure, event, continue_to_dispatch) Widget widget; XtPointer closure; XEvent* event; Boolean* continue_to_dispatch; { switch (event->xany.type) { case ClientMessage: if (event->xclient.message_type == WM_PROTOCOLS && event->xclient.data.l [0] == WM_TAKE_FOCUS) { printf ("Received WM_TAKE_FOCUS for %s\n", XtName (widget)); XSetInputFocus (XtDisplay (widget), event->xclient.window, RevertToParent, event->xclient.data.l [1]); *continue_to_dispatch = False; } else *continue_to_dispatch = True; break; default: *continue_to_dispatch = True; } } static void handle_key_press (widget, closure, event, continue_to_dispatch) Widget widget; XtPointer closure; XEvent* event; Boolean* continue_to_dispatch; { printf ("Received KeyPress for %s\n", XtName (widget)); } static Widget make_popup_shell (toplevel, name, localy_active_p) Widget toplevel; char* name; Boolean localy_active_p; { Atom properties [1]; Widget popup; popup = XtVaCreatePopupShell (name, shellWidgetClass, toplevel, XtNinput, localy_active_p, XtNtitle, name, 0); XtVaCreateManagedWidget ("label", labelWidgetClass, popup, XtNlabel, name, 0); XtRealizeWidget (popup); XtAddEventHandler (popup, 0, True, handle_message, NULL); XtAddEventHandler (popup, KeyPressMask, False, handle_key_press, NULL); properties [0] = WM_TAKE_FOCUS; XChangeProperty (XtDisplay (popup), XtWindow (popup), WM_PROTOCOLS, XA_ATOM, 32, PropModeAppend, (unsigned char*)properties, 1); XtPopup (popup, XtGrabNone); return popup; } main (argc, argv) Cardinal argc; String* argv; { Widget toplevel; XtAppContext app_con; Boolean localy_active_p; toplevel = XtAppInitialize (&app_con, "Take-Focus", NULL, 0, &argc, argv, NULL, NULL, 0); if (argc == 2) { if (!strcmp (argv [1], "-global")) localy_active_p = False; else if (!strcmp (argv [1], "-local")) localy_active_p = True; else { fprintf (stderr, "Argument must be -global or -local\n"); exit (1); } } else localy_active_p = True; printf ("Using the %s model.\n", localy_active_p ? "\"Locally active\"" : "\"Globally active\""); init_atoms (XtDisplay (toplevel)); make_popup_shell (toplevel, "shell1", localy_active_p); make_popup_shell (toplevel, "shell2", localy_active_p); XtAppMainLoop (app_con); } From bug-lucid-emacs-request@lucid.com Mon Jun 15 02:20:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12229; Mon, 15 Jun 92 02:20:00 PDT Received: by heavens-gate.lucid.com id AA03714g; Mon, 15 Jun 92 02:10:41 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA03710g; Mon, 15 Jun 92 02:10:19 PDT Received: from ingr.ingr.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17557; Mon, 15 Jun 92 05:18:41 -0400 Received: by ingr.ingr.com (5.61/INGR-1.1) id AA29845; Mon, 15 Jun 92 04:23:41 -0500 Received: from simpson.turtles by turtles (4.1/SMI-4.1) id AA20497; Mon, 15 Jun 92 12:13:58 IDT Received: by simpson.turtles (4.1/SMI-4.1) id AA19679; Mon, 15 Jun 92 12:14:11 IDT Date: Mon, 15 Jun 92 12:14:11 IDT From: matis!amir@uunet.UU.NET (Amir Katz) Message-Id: <9206150914.AA19679@simpson.turtles> To: bug-lucid-emacs@lucid.com Subject: Building Emacs with Sun ANSI-C Reply-To: matis!ingr.COM!amir%matis.UUCP@uunet.UU.NET [I posted this last week, but I'm not sure it has arrived, so here it is again] Guys, My setup is: - Sun SparcStation 1+, GX frame buffer (cg6) - SunOS 4.1.2 (no patches) - MIT X11R5, patch level 12 - ICS Motif/mwm - Sun's unbundled ANSI C compiler (version SC1.0). I had hard time building Lucid-Emacs 19.1, but I finally succeeded. Seems like Sun's ANSI-C compiler is sometimes very picky. I can describe the problems if anyone cares. Anyway, after overcoming all the build problems, when I run emacs, it dumps core. Can anyone help? I'm enclosing the debugger trace below. BTW, running the pre-built Emacs for Sun4 is fine. Please email to the address(es) below, as mailers regularly munge my mail headers. ----------- cut here ------------ GDB 4.5, Copyright 1992 Free Software Foundation, Inc... (gdb) run Starting program: /files/lemacs-19.1/src/emacs-19.1-Lucid Program received signal 11, Segmentation fault 0x7e5f0 in Fmake_marker () at alloc.c:801 801 string_free_list = (struct Lisp_String *)string_free_list->dup_list; (gdb) bt #0 0x7e5f0 in Fmake_marker () at alloc.c:801 #1 0x7e914 in Fmake_marker () at alloc.c:884 #2 0x7ec54 in make_string () at alloc.c:942 #3 0xb2524 in set_environment_alist () at environ.c:66 #4 0xb2d10 in init_environ () at environ.c:313 #5 0x4f460 in main () at emacs.c:706 (gdb) p *string_free_list $1 = {size = 0, dup_list = 2801096, data = 0x0} ----------- cut here ------------ -- /* Amir J. Katz | UUCP: uunet!ingr!matis!amir */ /* System Specialist | Internet: amir%matis.UUCP@ingr.COM */ /* SEE Technologies Ltd. | Voice: +972 52-584684, Fax: +972 52-543917 */ From bug-lucid-emacs-request@lucid.com Mon Jun 15 05:28:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13007; Mon, 15 Jun 92 05:28:24 PDT Received: by heavens-gate.lucid.com id AA03987g; Mon, 15 Jun 92 05:19:42 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA03983g; Mon, 15 Jun 92 05:19:27 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA21913; Mon, 15 Jun 1992 14:27:29 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01375; Mon, 15 Jun 92 14:28:42 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA10769; Mon, 15 Jun 92 14:22:30 +0200 Date: Mon, 15 Jun 92 14:22:30 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206151222.AA10769@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02490; Mon, 15 Jun 92 14:22:31 +0200 To: Jamie Zawinski Cc: Bug Lucid Emacs Subject: Re: stange focus problem In-Reply-To: Your message of Mon 15 June 92, 02:08:52 PDT References: <9206150840.AA06894@geant.cenatls.cena.dgac.fr> <9206150908.AA06025@thalidomide.lucid> On 15 June 92, the keyboard of Jamie Zawinski wrote: > When the focus is "stolen," does the title bar indicate that the stealing > window has the focus, or is the titlebar indication of focus out of sync > with reality? The titlebar indication of focus is out of sync. > See if you can make the same sort of bad things happen with the following > test program. If my cursor is in shell1 or shell2, it is stolen by lemacs. However, was it really the test you wanted ? > There's a similar bug in the R5 version of tvtwm that goes away when you > don't specify NoTitleFocus. Yeah, same thing here with vtwm. Well, I have to assume it's a bug in the window manager. Phil From bug-lucid-emacs-request@lucid.com Mon Jun 15 05:45:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13140; Mon, 15 Jun 92 05:45:46 PDT Received: by heavens-gate.lucid.com id AA04023g; Mon, 15 Jun 92 05:36:53 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA04017g; Mon, 15 Jun 92 05:36:27 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA22582; Mon, 15 Jun 1992 14:43:13 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01446; Mon, 15 Jun 92 14:46:06 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA10992; Mon, 15 Jun 92 14:39:49 +0200 Date: Mon, 15 Jun 92 14:39:49 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206151239.AA10992@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02735; Mon, 15 Jun 92 14:39:50 +0200 To: Jamie Zawinski Cc: Bug Lucid Emacs Subject: Re: define-key using a (KEYMAP . CHAR) definition fails. In-Reply-To: Your message of Sun 14 June 92, 15:35:32 PDT References: <9206141637.AA05937@geant.cenatls.cena.dgac.fr> <9206142235.AA05339@thalidomide.lucid> > The symbol `text-mode-map' is not a keymap: that is, (keymapp > 'text-mode-map) returns false. Something is keymapp if it is a keymap > object, or if it is a symbol whose -function- cell is keymapp. What is the reason for stocking the keymap value in the function cell of a symbol, and not in the value cell? And why when I evaluate (symbol-value 'text-mode-map) I get the keymap, but (symbol-function 'text-mode-map) returns an error? Well, the reason must be deep inside emacs, and I am certainly too curious and not wise enough to learn such knowledge... > It should be a pretty mechanical transformation: just replace aref with > lookup-key, and aset with define-key. This has the advantage of working > in v18 as well. I started like this, but it's far more complicated than I thought it would be: parcouring a keymap using (let ((i 0)) .... (setq i (1+ i))), which needs rewriting using map-keymap (not portable in v18); inserting a (keymap (key . def) ...) in another keymap vector... It will need some time to be ready :-(. Phil From bug-lucid-emacs-request@lucid.com Mon Jun 15 05:50:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13152; Mon, 15 Jun 92 05:50:19 PDT Received: by heavens-gate.lucid.com id AA04033g; Mon, 15 Jun 92 05:41:18 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA04029g; Mon, 15 Jun 92 05:41:11 PDT Received: from ingr.ingr.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10567; Mon, 15 Jun 92 08:49:31 -0400 Received: by ingr.ingr.com (5.61/INGR-1.1) id AA11968; Mon, 15 Jun 92 07:54:21 -0500 Received: from simpson.turtles by turtles (4.1/SMI-4.1) id AA20965; Mon, 15 Jun 92 15:45:45 IDT Received: by simpson.turtles (4.1/SMI-4.1) id AA21643; Mon, 15 Jun 92 15:45:58 IDT From: matis!amir@uunet.UU.NET (Amir Katz) Message-Id: <9206151245.AA21643@simpson.turtles> Subject: Non-incremental Search To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Mon, 15 Jun 92 15:45:57 EET DST Organization: SEE Technologies Ltd. Reply-To: matis!ingr.COM!amir%matis.UUCP@uunet.UU.NET X-Mailer: ELM [version 2.3 PL11] Guys, I'm running the pre-cooked lucid-emacs for Sun-4. I don't care much for the incremental search, so, under Emacs 18.58, to do a search I would type: C-s [ESC] ABCD [RET] And it finds the first occurance of ABCD. Hitting C-s again would find the next occurance, and so on. In Lemacs, the second C-s invokes the last isearch expression. Is this a feature or a bug? I fuzzily recall reading in the FM that something has changed in Lucid Emacs regarding the search, so can someone enlighten me? Pls respond to the addresses below. -- /* Amir J. Katz | UUCP: uunet!ingr!matis!amir */ /* System Specialist | Internet: amir%matis.UUCP@ingr.COM */ /* SEE Technologies Ltd. | Voice: +972 52-584684, Fax: +972 52-543917 */ From bug-lucid-emacs-request@lucid.com Mon Jun 15 06:03:27 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13210; Mon, 15 Jun 92 06:03:27 PDT Received: by heavens-gate.lucid.com id AA04065g; Mon, 15 Jun 92 05:54:31 PDT Received: from sapir.cog.jhu.edu by heavens-gate.lucid.com id AA04061g; Mon, 15 Jun 92 05:54:16 PDT Received: from localhost by sapir.cog.jhu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA12966; Mon, 15 Jun 92 09:02:26 EDT Message-Id: <9206151302.AA12966@sapir.cog.jhu.edu> To: bug-lucid-emacs@lucid.com Subject: patches to build lemacs-19.1 for NeXT Date: Mon, 15 Jun 92 09:02:26 -0400 From: anderson@sapir.cog.jhu.edu Here's what you need to get a working version of lemacs-19.1 for a NeXT, assuming the X11R4 development environment of PenCom's co-Xist product for NeXT. The attached uu-encoded compressed tarfile includes a small set of context diffs against files in the src directory; an unexNeXT.c file (from the NeXT-ified sources for emacs-18.57: I see that this doesn't explicitly include a statement of availability under GPL), m/m-NeXT.h and s/s-mach.h. Unpack the files into the src directory, feed the diffs to patch, and you should be able to make a working xemacs. Note that you should use the system malloc, rather than trying to use the GNU malloc. --Steve Anderson begin 644 NeXT-lemacs-19.1-patches.tar.Z M'YV0+EZ026/&S!P`"!,J7,BPH<.'$"-*G(@0A$4;-&B``HHP:&SN"B#$C MI,B+-&Z`!%%#1HP;,6+`B%$C1L>6-&!PI,BSI\^?0(,*'4JTJ-&C2),JE:BB M*8@R;<*,F>-B3`(C.F M#(@G7Z00N2(%Q-K+9=P,-&,9!%L0(PBJU@QBRI/$:LV;.GFWCUBT%19L4O5%HOVY"NI$F5+#WZ%'[MA'J*9JG7OVZ M_>7,FSN#@"(E"6CZ3X84F3(%!(S6K?T&PA!OM!&5:B"P`1T(8BRM$A'5MT8:1(GX8ZJAUOI*%7E6Q<^<4=#;K!V1EWIC"K M:TH2U*294*KH&W!TH)$&A!:R`0>$;]0Q95>?,EL5FLY:-"8*G*5!1QIA**A' M7NF%V]&XO/JJ1AUM7$M'@W18EVZO6&K)I9?8A4`>#.T2"@(<)-)A!@HBQ#L& M"//66Q>^P861!AMYA<"%&R(8JYYJ8Y;Y)+BN7:8L;44X402;26A11*=D`C?& MOB*&<>[#Y9Z;;AKKR@&A<,0IZ,8:>0VXP@JDOI'9G,^"L`8;=9!QAF1IIQ\`"S!:)X$39+0C+=1M7NP%A$7!!."T(M"Q\H% M)DR."$5#FIJ0E-Z0-#R1;TK**@)PO M+&%E*F/"%XR0!":\#((6F>0>`XE)01+2,X=,Y"*GT,A'QO`DDZPD+]T02$T" MTS_U\R0;0,FZCNC2DK[<)`@0J4A&.K)RD41F'I69R5\:$IH?6TW,0##*XK"2 M"JZ$91%D24M;,LV3(`N1*-]`RK*=\IX\7*<3F(`;>&I/"E480G*6DR385,^= MK7RE%&(YRUK>\HZONI/*(BI/>EI40WA\X`ZG689JYC*C*)`H1>M9!)"R0:3X M5.=)RO3.>$YTGA6U)T,MTAI5TH:66.B>32E*S&_*,@A$(((43`H"H`I5I3@M MZB._@%2EWBFDBE)1'(-(DQC8H&\Q$ER'X.`"-%PE*T_\2EAT,`,T?I6-/AQK M6;]8E[L4K0EAR(-I$N<2'PH36J^YSGR*$;IG$0'!!SIZL1-4I-)%DH5O5/J;WXC4 MQ[[8PC"=!&&+6V*"6"$>MHB2$ERJYI`9LEH%*UHAHUIA4)89B.6P(Q&L;L^G MJN+*A2YVP8M>E"N3OP0F!GX%"QL)6QDXYB0R,:!!>A77%)B]=GQSD$.^/"9# M#WI%.['%SE3D2]^1@G*=[3S"$ZJ`R%0^E%D;["`-[P3"\F706.N\@X1*I`,0 MB$%;['R#&)2FUSJ`4G=3"H,;\@`LO3(T3"1U+ZC$5ZC2@>`+$Y-OL<*IX`\V M6'[8@?&]^!O-@(KL3#O=83[7*6`"RRG(,0T9<*A04^VM::',L8CT=GM>(:K7 M+T8D;^"$I`JE7]-AAH4)USLJP*%:A0`--/EI16*X9M")^B:#KT>,B] M$1">]?P%IEE$S0S.+PA,4&@ZR%FS4I[N2&Z4HRZ[*,M:?B.7KXBI.&ZJO2:S M,P@2284@?.',:9ZAC47-:U_'N9..IIZN-_VD/8>KSVG`F8OS8K,P##I450V7;VK@-D<'6W31FM[+30?ZTL-1 M5)W>,%L9!QHQXE(&3O""&_S@`>$6'KPUAH,[W"<=L0$,_,*1CGS$)!8A"<8M M#H.,@(4E+K'!X6YP@Z]>A'`QV,G#5\[REKO\Y3"/^>T5<5`@AGOE0>I`\-80GM`$ M["3="&400^\:I%<98"JZFJHY]1\PS@Z=#T-(B!\(9'_-\#GR?(Q^;P?E<\7-!@>;YG M'@2`5]4+>A6&S,BA\YA//.B'^X+-8`SUDE<\Z_L,^\_S0$%B\"(:"O_V]XJH M=V.8$BB#SS:OJ&"RPZ>#&/+@3#:K0$/Y-9(":*X<$"S![U.KL-=`0(:RG0#0 M>(`#SD,\XH-)Z`S':P/WJVWA,N2A;'JQ0A.^@(0D'`$)Q4[Z%4Q5/`C]:%]Z MU1EY432[$P9=DU?*\P;!P1EZ03P1,B$&A!UW("VEDG1P$`93`V)HTP9?L"]7 M8C-%(V)Z(6'FXAEEPP9Z%2UO\%\.*"4*"#?KIVV@=`9%1P='IQQ)QT2[\S11 M,S54@H!B=S5KT#46XA7;5Q=O``<@X&'#LH!X4#1V,'1!DBX,0@9DP#]SD'05 MTB!%@WO'DQ4LY`(@$`3!5P<`^">YTS47PS4(HV%A4#=Z54KGX@9UX!EW,!Q= M4B(:D71M4`=`QP9Y(BH?XA5T,831(F*%,B4"2`800@<*Z(=WXH,3HMX#!%%,W&\*'UTD`?BUR3H(XA3\B-G4'Q?,"7WDP!VP(&E=X4LM"HA M9H58:"3,R(%KLR[)2"$\\R4*<(U?T(9TL(WB.'[%9XW-&(X2,HY3$A5XH([\ M9(YE@XXF``;]@88(V+;N(4_0@;6"`?#D8\:I@;C METW_F(X@8A#<-B43"4J6I@!]P#N2A8P9^7:KB#:Y0@8*@'YO<`4X&E(UE`"(H M<)59290IX#$)L)&.9C_?F`!I&99#"8E;F1HI<#1?J99"Z93G]']6,@9UR91_ MB9,:,I<)L)B%B96'291Y:7R*N9C2]^ABNZH@!S M$`9ILY9DD)()XYDA*9HD:0;5Q@9_U!E/2)BQ!31100<:X@(6FIS,&`9;"48, M`@?0:0<:&F/Y$@;]&1S#,:%N:08((R4+$WBMHB$B<'-C4&'0\XUVH*()TZ*, M]Z(F*@<3RB>"8HTXRJ('9'IR`*,;4Z,9RBJJ@2=!JI&?:3/1]F<*\'^PN7EO MH)KOXF),4IL=@9N;]P464GJ&J)9C:GI>:D(C0HRY"9N[29.&^9\Y^9L6P9.P M*(O*<9V12:<@@*'+Z9)N^I]C(Y/6^*>Z*:@J<&%F8(V&D@:,ZF)F"9WC8J4H MT*4[AY5G*BHOU(V769.9*@=M"0("4YEGN3!F>C6F%ZI5J:#WPJ`RRC`SXP;M M9*4_6"H*^*E*F@"@A@($8XU(D@`Z1RZXN`.%`GJ7*J:H*BKP>7CS23^%3BJJ52INCII^DBI:&&JAW&:JC.I>WR:DZ"GRN":BHJ:K@"@+`NJ`-^BDX M!ZLB-JNH6JO#TZ:#*H(@@*MNN9B[VJMS^:L)8);G-)M5T:S=>)YFJ:UKRI+, M.9O[.BX"RP/^$:V4J:ZLFB[M^J`,LV%GX&'VNIMFF:NZ.F]WXJ^+";"*2I8> M"*'_6;`#>HI?J:@!.I\#V[("&K-U8`8S^[(U>Y*++] MNJ\`6YJG.9M4E[/6&:=WF9/'.IO8Z0:<^8V[ZD!&8J"@.:52H@"NQP:>>`8D MJJ4=D8[/B(4%N6/CF+C1F*86D8YFN8WSTXV0NX$=2(W1N(WKD;G0.`=9>)Q] MJ@#+B+B:"[K;Z+B@2X\PUHW;2+C7THW0J;I/>2YZT:XV\ZQDK0!Z_*[O?."Z(.Y@@B`+W,@=K`&,7LC`I$#JTJR'+NRZU MN9A&$`1,`"=6:WVPE#T)I1_\0;%;B[&O^K7QRD^8N[(@J*0&<[:^BK^`7&6'RJ"8ZT2[G;.Y>2Z[I3'AE\+U< M?,,&F1=K?,,-^9#.E,=7S$P7"20/*[1`(JKDH5+H.P3JVQ]\P`<;R!^<=9S+Q3NY'_.I?QI0!MD`=?8$!T^L#:*'S=2*<8:KK=G+JJ+*D2]+S\$KW3J\37 MRVC:J\J;ZKT@L#U54`3EB\ANHLC[,05#O+].()5W.[+V%6I&FP*T"\__*Z4/ M@Z#T;,]F\"-EH)JQI:BUJ<]8R<_K\HW_S(&90;^A@L34:[U,S-!W`M"*:VHR M3:HF'9)_*Z-?T'WF8KCBXF*J2C=IVAHZ<)!,P@O6"\>K=OEP#+Z"F15FXNYC`P^2__2"#L.9'`3B,3#9#*QZS;CGE.-T`)^F.)%?.;5]/;T'6\TT M:.),?C$L1,Y47-<2<@?1K)@9[AD;[DV])@0C3L7:(=AYT`9TP^*3 MJ=9Q&^,IL..-/I&Z2QY MC@9K_N>!/K6#ODT<7E0NG.A3^^E>'>HS2.I3:^HX2>GPV=^9'AQV#>M^WLE/ M#A]A4$&ZOIBR_N0`"[#WW1B4"1Q7@(]Q<]K_S1PTC@(DV-/$0]JF3::HK;39 MNC#GGJKER[01CJFG[=KMZZH.ZK5@*[_C;H+:`@<89HIFN[\F^Y9S>>W_#0+; M7H+W2I3?/I?!.N#05.#"7IX9_*PKL,GCLN\H4.[6"N,5/L86X?$6'I\&2Z"& M;,PB(?(["\OJ7N]=2YCP*ZOZSNU730?^3M=8+K*O_4$#3_`G6_"+B=_5E_"A M\B%9<8R#Q#65UO#A3E)EL`:B;:GM+BKC;)EF(*`0@C3P/O6@NL46(4MP$A[& M2LI5:1$N_[[Y/L)/WV(WOX`8$_#7/?!I.^5Y[==(KB+M(Z[QCJSHSD#&++IQ M?=I57ZI8OZ\IVY[V7);U^9736GI1;ZU'C;6CRO)36\]?0-PO'?F+GZYG?^\P MG_8<*;:R<:S_%[Z+9(??*4OYB6C_EM:P8/#;.*>;'V[JZ?'[]3 MLN\U3_HY/^/"_/.PS](N/?NUOZ]`GP!"K^TTWQEW`-E,'\T2E/I8;:W.EP+1 MW'^>23QY[?HK0C/LO#Z\RW_LT3SS`__;"+_"FOYC?Z)G,C^W5]P1+$`19 M$-'?/=[E?=[I[01/X`K0-^;PC;;;T*-Y_,,BA0A3-`"_D4$`38\O=-0%MS0N MG![4FVK6*LIA#4O8&4&DH`L042FB))E0C/21)* M#5$/$'Z&T.#=!DH6T!`F:UQ@P+%'L&M1]:U!^?4+&K]R^=]HTI(2*17O3B#P[!>F*+`Q(`^A3&,A*SO!+R`$T`!)8@F MQ'*&A#R0M:E4RJZAW2`/D%!1^2IG]E^JDC?@$06`0R&2I4"36@&MX)=C@"V5??64$O#0-&01.H!F-> M.YF%RH,[+<-;F`MWX3GTA7@`&"JW6<;4G%J^0((UCTFXMH,(2A[?OB*)+XWC M[:NN(#2@WD7\2K\P7P3#7X4236)AZQ4E424R*D+6?.!A2,1R(G!BE3*6R!E< MHC($BFB0(<)"ARB_?H0SL86X\`0D(*A8$:W34<08&N(/8@R,J!'S%Y)(,JQ! M`CL\1T"B,,/4XK*@-QH`[),6P1(IA0B6A$"N"'Z9P)!"3N42.J;'(@;4`( M$:-7?N/-\!^GPM_)`87$@HC#'9(#:V!$AA@,L3I88C3*5YZA-*D*"J&`[,2X M&Q;Q40IH!D,DB2Z5<"2.QG$J",?4P#FX!A2H`W4CVB@`)A!M4L-_T3G>43MF MAGMQ,:C"VRD":4,.O!_YL#O0CX@)%7I!_/BH:;$VVD:1U!(I1$.T`:5!$/0* MOCI(8.0Y:HN2DAR7(VM9?18)CW28V4`<8%`I&0CGHFQ`B,PP!\;`?@A\W2,TH9T5$#OQXFDB[(!/(3'D52.E))'@H!2'[B(:/%L)!;AA(_,IG.(3YXAO5F,W$F")@!,F!G%@>? M:8B"H]#4'=T2MT4P`I@T%P1Z]%V#!`^@-?#Q#11%3#&-3Q00#%T MV@:3BD(3IH?,>#_1^LI(B<#84CK=X`XC3>?Z4*3`$Q-?+>*!& M@(R:4=-0`VP`W`DH[,9@(,[Y^4.%@&TP;T.@_J@,(ZHD2PMP>$1%0^?)2.!/EG)`N1Y#^%`D+(!+^@&I';J/IA1_R#14`8=9VDO)1%-1 MH[8D/?C/XIF"8"D,JC25KBW?$(%A322X%3)=0I\M3NTA-:`E&C@"N&P9%0K,.D< MI9Z^YLVT3R.01HO`,<4_(7#=W0F,JDT=*!VU7G1`#7`GC"12E=!F!`X/="OQ MRI(Z2L\`2P6A($![>@8RL`;*"DB17S25]J`!#6$G7I,,]"(*,Y-23R*P!.A/ M/VP<%)2E;%.\0KUZ5!7J9A;&7*!.X4$TJ014&`YZ1 MW2-\M`BO@T%HB^%A'XD#?N1#^[$_EH'_Z'^>I:)T/`;R%UU6!2D?&J1G>)`1 M,C7XHW]J(8F%N8!NMA&0)@#+V`.;"+0 M5E86(\&).!-G+H($O*AQ\"+'D0$:`>3X19G@<6Y"R9$!A='$ZM@=RV-[K(XU MI)#%7!0?WF@W=(Z`92V\PWO6\-;4=,E"7!(X9QK>31/(ZAV;H>I4![/*NW53[J MUOJH7G^K?I0#_'&>#E<`R3^@)7*=E@A2O"Y(IQHO/V5TG9"ELKIB2`WYPS@D M=_V0WU5$BED5 M:J5Y*I*YTKWR2C7TY9[M?1V6V:)8,J(U@"Q1KI#@';`H-([(>&M<"61R19CQ M\5I2B&PIN+8CT?R6=B-<0E!R:2[1I;HD%NSRE;[+M]5O/V/,=43\I$KR1P1Q M//6E/R*A_M+\!$SP2C#=*]SR,"1*P8("XTH`7,@+(B`J2H?-@H M\`2J>!1[(@+4(FAKNW%G-H0(N9M3^N<#1239`]'F44:R5YO`B\`"+R)SS*"6 MF!>NJP+`%7Y$#$B%-;`^%H(?```4```H@!K*X9)`5,A`"F$.'`',"P`6`.?M MJTK#?[`0A?`'2"\"J`K1YIY!A880"```!```!P#V8@DR(`84@B```!@``#`` MW0MC'&4:(*X,H1)(`0#``0#`!""^`O?XJK#+)Y!,3T+0`P-@```"S`B0A2A`-]L`@56?P8$F8`+NQ#MQ`T&B M!M1E._`#9M2"Z`25HL9BBFIO"*U`G`<'T9D<5((V^Q8BUYJ"8()] M7L;S@JK/PK"^[]?ZAG#FLX-)\0@W1-#7!OO=&\R"^VH+TD$BC`QWWGW)@V]G M#ZK!/FBTM.(<8\/E@Q!B#$-(NA:A*F42>*T1?B/]$0YSUB1,1O7"$CK"\G$. M.2&3:(>@4`Y#4M`@&N@A$SB%$VL"/SY6F+5MOA' M#CV#.;R*Z'`%S$%V2!YFX2P6A?)0"CCB+*`/\>$0T(?\T!_Z!X`HBPFB4*Q* M-5$A9F'WM84SL3N,B$IH(D9%BPB,N2(IGH/+K2/FBH^8"+/B]1N).#$A)L*3 M&(^_H,(@`RL1CQ3%8QR*YU),Y%\?+1O/XYN($.VQ2)3$3O&7\&-(ZH:#(@E< M3$1Q:"QD(\R-ER+H2\B%A")*Q2*ID2(TQK*Q&3K6\4B47H$R_C#+.#),9V?0C,R!,UI9>?ET[P1I1(U!!#5^ M6=889LW`:^1"LE'NU,8TNV9UH[0@LF_61)9*.XL<[2V2;8YY%CH2W#Y;'5/I MAP1%7(,2$=KOJ`#"(Z*%K;)5/=962!L?TKL*S/!*(FGMB;RUZ!4AJM<7&2-[ MK=>MD<%6O@[;^BHL?:1^3;;\==E6S@!KEY7DP36PTW936EM/>24UI+;UK%PR MPG[),%EA8ZEE(;=[=L.RR>(S%>$DNZ42[A;>Z@5Y.R+HK:0LSG(K/)Z@06EZ MC.2A_+>V(^`:7S^TERW$>0:6`_922EL$RRD9+JCL"`_7.T?#0P*_TDTKRY!)+8\ER*:>RA+EG0.:"SO%\ MF3^MD`V[.M=H:DN?VRV!;B;Z)>+R"1!=L&ET1V[2+932HD3`2P?)E4,TU*V7 M4S?C$FBK^S7ZY79$GZNYZ](,L.LR%V;#))X0TT19"8I)+"PF:PQU&O/"=DQ> M"#*ALL@TDB4S1)Q,MN&Q/)'R2*1-6JCF59K9-,?F7S";>U-M2E6V631YZ^%T MNTOSK(I-LADUY]_41)M5,VC.::*I-;>J#_V:8=-IEDT_?3;3IM4 MSP(D.VEG4`VL,A.'OI/>F4>!YQ@0GM>:>$X!XTF@K?*;-4"5NGDBD>=I/?%T M]9R;TA-[;E.9>J:KHZ%XRN"3$1F@KH!FS>=PY1\F;N&R3_<)/^_T`ZV?A94> M@E+^J:T#J(@9H+[/@`8:%V-`%RB$.*FP@8YNG28@06T)!:VB1^""4E`AH$$Y MJ(#PH(4TA([00%1"PP\*I0,J='-VSIFDIA>$#*6A-M2K#L<<"FS,-4$)HDYF MAZX).=$"CNBJ@!#FFHE.F!;?+V$=PH6(RC4FW#/4OE+76D4X-/%%>QY8""8R6%"@[59@=3T#),!S9YD]2EU)^("E0* M2S]GK\ZP4P-'7T=9FF)KJ;W"I<=#EX8(7NI+3ZO7'-R=E)@:TVAZ)Y8I@PES MV:)N0--D:EK[`@RHIB_@FF[MCOH_N775^*:U(IS6H%)93L]I[(E$/&>=OKC@ M[4X[AQG"$'KE2M!3.&!/2]'0\1#^E9_ZS?`:''&WH1&H'8&@0@B#6F[99D(] M/1JJT@3N!QI1:\H3H*AA#P5P5(VJOI4*[8[8U!.DLE22RIT@=DJ5U"P5?]=O M`B@@V#5-M:GTDOO$2-`$P'LJH/JIXYN.$E6CBE0PJ%(5$$QU"-525195`62% 4KJJ6%*OJ[GSMN66FA_.J6@"L%@ZI ` end From bug-lucid-emacs-request@lucid.com Mon Jun 15 09:48:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14046; Mon, 15 Jun 92 09:48:58 PDT Received: by heavens-gate.lucid.com id AA04569g; Mon, 15 Jun 92 09:39:31 PDT Received: from hp.com by heavens-gate.lucid.com id AA04565g; Mon, 15 Jun 92 09:39:24 PDT Received: from gourmet.ch.apollo.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA27888; Mon, 15 Jun 92 09:46:54 -0700 Message-Id: <9206151646.AA27888@hp.com> Received: by gourmet.ch.apollo.hp.com id ; Mon, 15 Jun 92 12:47:49 -0400 Date: Mon, 15 Jun 92 12:47:49 -0400 From: sommerfeld@apollo.hp.com To: bug-lucid-emacs@lucid.com Subject: please add me. Thanks.. - Bill From bug-lucid-emacs-request@lucid.com Mon Jun 15 10:26:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14265; Mon, 15 Jun 92 10:26:50 PDT Received: by heavens-gate.lucid.com id AA04719g; Mon, 15 Jun 92 10:17:32 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA04715g; Mon, 15 Jun 92 10:17:26 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA06671; Mon, 15 Jun 92 10:25:57 PDT Date: Mon, 15 Jun 92 10:25:57 PDT Message-Id: <9206151725.AA06671@thalidomide.lucid> X-Windows: Flawed beyond belief. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Cc: Bug Lucid Emacs Subject: Re: stange focus problem In-Reply-To: Philippe Queinnec's message of Mon 15-Jun-92 14:22:30 +0200 <9206151222.AA10769@geant.cenatls.cena.dgac.fr> References: <9206150840.AA06894@geant.cenatls.cena.dgac.fr> <9206150908.AA06025@thalidomide.lucid> <9206151222.AA10769@geant.cenatls.cena.dgac.fr> In message <9206151222.AA10769@geant.cenatls.cena.dgac.fr> Philippe Queinnec wrote: > >> When the focus is "stolen," does the title bar indicate that the stealing >> window has the focus, or is the titlebar indication of focus out of sync >> with reality? > > The titlebar indication of focus is out of sync. Ok, well I think that definitely means that this is a window manager bug; that symptom has to mean that the internal state of the WM is inconsistent. -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jun 15 15:34:15 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15661; Mon, 15 Jun 92 15:34:15 PDT Received: by heavens-gate.lucid.com id AA05949g; Mon, 15 Jun 92 15:25:07 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA05943g; Mon, 15 Jun 92 15:24:55 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18653; Mon, 15 Jun 92 18:33:20 -0400 Received: from lupine.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 183242.1936; Mon, 15 Jun 1992 18:32:42 EDT Received: from hansen1.ncd.com (hansen2) by lupine.ncd.com (4.1/SMI-4.1) id AA26400; Mon, 15 Jun 92 15:05:04 PDT Received: from local by hansen1.ncd.com (4.1/SMI-4.1) id AA18891; Mon, 15 Jun 92 15:08:39 PDT Message-Id: <9206152208.AA18891@hansen1.ncd.com> To: bug-lucid-emacs@lucid.com Subject: Having massive trouble building lemacs-19.1 on a Sun4 running 4.1A.1 Date: Mon, 15 Jun 92 15:08:38 PDT From: Ted Lemon (Before you read this, I suppose I should warn you that I'm using gcc version 2 - I wouldn't be surprised if that's why I'm losing.) I suppose I'll just grab the binaries for now, but I'd like to be able to build it. First, the make fails in .../src: hansen% make make -f xmakefile all make: Fatal error: Don't know how to make target `all' Current working directory /u6/mellon/src/emacs19/lemacs-19.1/src *** Error code 1 make: Fatal error: Command failed for target `doall' hansen% Typing ``make -f xmakefile'' seems to get around this, but later on, I get an undefined __main when it tries to link temacs. I worked around this by adding a reference to libgcc.a, but now after temacs has dumped itself, xemacs comes back with the following: hansen% xemacs emacs: Alt_L (0x14) generates ModLock, which is nonsensical. Fatal error (6).IOT trap (core dumped) hansen% I tried running temacs, but it prints this: ------------------------------------------------------------------------------- This version of emacs only runs under X Windows (for now). Check that your $DISPLAY environment variable is properly set. hansen% echo $DISPLAY ncdu301:0.0 hansen% If anybody has any suggestions as to why this might be happening, I'd love to hear them. Thanks! _MelloN_ From bug-lucid-emacs-request@lucid.com Mon Jun 15 18:39:40 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16213; Mon, 15 Jun 92 18:39:40 PDT Received: by heavens-gate.lucid.com id AA06487g; Mon, 15 Jun 92 18:30:50 PDT Received: from cns.caltech.edu (acquine.cns.caltech.edu) by heavens-gate.lucid.com id AA06483g; Mon, 15 Jun 92 18:30:44 PDT Received: from bradbury.cns.caltech.edu by cns.caltech.edu (4.1/1.34) id AA16324; Mon, 15 Jun 92 18:34:43 PDT Date: Mon, 15 Jun 92 18:34:43 PDT From: tromey@cns.caltech.edu (Tom Tromey) Message-Id: <9206160134.AA16324@cns.caltech.edu> Received: by bradbury.cns.caltech.edu (4.1/SMI-4.0) id AA00550; Mon, 15 Jun 92 18:43:34 PDT To: bug-lucid-emacs@lucid.com Subject: Bad GNUS / Lucid interaction X-Zippy: My haircut is totally traditional! Occasionally when trying to enter a new newsgroup, GNUS will print a "wrong type: syntax-table-p, nil" (I forget the exact text) error. I traced it to the function mail-strip-quoted-names in mail-utils.el, which tries to do a (set-syntax-table lisp-mode-syntax-table). However, lisp-mode-syntax-table is nil under certain circumstances (I think if lisp mode has never been entered; I didn't really investigate this). I don't have a fix. I suspect that the best thing to do is just always create lisp-mode-syntax-table in lisp-mode.el. It doesn't seem like the overhead of one more syntax table is enormous. Tom --- This reporter is tromey@cns.caltech.edu "Totally Objective" "`Nova heat moving in,' dig?" -- Robert Anton Wilson From bug-lucid-emacs-request@lucid.com Tue Jun 16 01:00:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17219; Tue, 16 Jun 92 01:00:28 PDT Received: by heavens-gate.lucid.com id AA07238g; Tue, 16 Jun 92 00:51:26 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA07234g; Tue, 16 Jun 92 00:51:15 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA21945; Tue, 16 Jun 1992 09:58:09 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA13542; Tue, 16 Jun 92 10:00:52 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA03952; Tue, 16 Jun 92 09:54:33 +0200 Date: Tue, 16 Jun 92 09:54:33 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206160754.AA03952@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA00577; Tue, 16 Jun 92 09:54:30 +0200 To: Ted Lemon Cc: bug-lucid-emacs@lucid.com Subject: Re: Having massive trouble building lemacs-19.1 on a Sun4 running 4.1A.1 In-Reply-To: Your message of Mon 15 June 92, 15:08:38 PDT References: <9206152208.AA18891@hansen1.ncd.com> > (Before you read this, I suppose I should warn you that I'm using gcc > version 2 - I wouldn't be surprised if that's why I'm losing.) No, my lemacs is build is built with gcc 2.2.1 -O2 without major problem. > hansen% make > make -f xmakefile all > make: Fatal error: Don't know how to make target `all' > Current working directory /u6/mellon/src/emacs19/lemacs-19.1/src There is a missing all: xemacs dependency in src/ymakefile > Typing ``make -f xmakefile'' seems to get around this, but later on, I > get an undefined __main when it tries to link temacs. I worked > around this by adding a reference to libgcc.a, but now after temacs > has dumped itself, xemacs comes back with the following: > > hansen% xemacs > emacs: Alt_L (0x14) generates ModLock, which is nonsensical. > Fatal error (6).IOT trap (core dumped) My own ugly solution was to compile all the files with gcc, then compile emacs.c (which contains main()) with cc, and not link with libgcc.a. This way everything is fine, and lemacs works. Note: I am on Sun4 running sunos 4.1.1, not 4.1A.1 (what's the difference ?) Phil From bug-lucid-emacs-request@lucid.com Wed Jun 17 08:39:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23648; Wed, 17 Jun 92 08:39:08 PDT Received: by heavens-gate.lucid.com id AA10918g; Wed, 17 Jun 92 08:29:51 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA10914g; Wed, 17 Jun 92 08:29:43 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06481; Wed, 17 Jun 92 11:38:18 -0400 Received: from meaddata.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 113706.26009; Wed, 17 Jun 1992 11:37:06 EDT Received: from pepperoni.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA05940; Wed, 17 Jun 92 10:31:17 EDT Received: by pepperoni.meaddata.com (4.1/SMI-4.1) id AA12383; Wed, 17 Jun 92 10:31:15 EDT Date: Wed, 17 Jun 92 10:31:15 EDT From: marko@meaddata.com (Mark Osbourne) Message-Id: <9206171431.AA12383@pepperoni.meaddata.com> To: tromey@cns.caltech.edu (Tom Tromey) Cc: bug-lucid-emacs@lucid.com Subject: Re: Bad GNUS / Lucid interaction In-Reply-To: Tom Tromey's message of Mon June 15, at 18:34:43 PDT References: <9206160134.AA16324@cns.caltech.edu> In-Reply-To: Tom Tromey's message of Mon June 15, at 18:34:43 PDT tromey> Occasionally when trying to enter a new newsgroup, GNUS will print a tromey> "wrong type: syntax-table-p, nil" (I forget the exact text) error. tromey> tromey> I traced it to the function mail-strip-quoted-names in mail-utils.el, tromey> which tries to do a (set-syntax-table lisp-mode-syntax-table). tromey> However, lisp-mode-syntax-table is nil under certain circumstances (I tromey> think if lisp mode has never been entered; I didn't really investigate tromey> this). A temporary fix would be to use the gnus-Startup-hook like so: (setq gnus-Startup-hook '(lambda () (lisp-mode-variables t))) which will create the lisp-mode-syntax-table as one of its side effects. The prefered fix would be to make mail-strip-quoted-names in mail-utils.el check the existance of the lisp-mode-syntax-table and create it before using it. The emacs-lisp-mode-syntax-table seems to exist at all times, maybe that would be good enough for the mail-strip-quoted-names function to use. Since I'm not enough of a Elisp expert to know exactly why/how the lisp-mode-syntax-table is used in mail-strip-quoted-names, I will leave the official fix to someone else. -- --- Mark Osbourne (marko@meaddata.com) (...!uunet!meaddata!marko) -- From bug-lucid-emacs-request@lucid.com Wed Jun 17 12:20:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24398; Wed, 17 Jun 92 12:20:37 PDT Received: by heavens-gate.lucid.com id AA11694g; Wed, 17 Jun 92 12:11:40 PDT Received: from lysator.liu.se by heavens-gate.lucid.com id AA11690g; Wed, 17 Jun 92 12:11:32 PDT Received: by lysator.liu.se (5.65c8/1.34/Lysator-3.1) id AA04844; Wed, 17 Jun 1992 21:19:56 +0200 (rfc931-sender: linus@lysator.liu.se) Date: Wed, 17 Jun 1992 21:19:56 +0200 From: linus%lysator.liu.se@lucid.com (Linus Tolke Y) Message-Id: <199206171919.AA04844@lysator.liu.se> To: bug-lucid-emacs@lucid.com Subject: Incorrect documentation of interactive interactive: (args) ... k -- Key sequence (string). ... This is obviously not a string anymore. -- /Linus ***** Wherever I exec my `which emacs`, is my $HOME. ***** Linus Tolke SM7OUU, linus@lysator.liu.se Student at the member of SK5EU LiTHSA Link|ping institute of technology, LiTH LiTH S{ndare Amat|rer (Ham-club) From bug-lucid-emacs-request@lucid.com Wed Jun 17 13:37:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24629; Wed, 17 Jun 92 13:37:17 PDT Received: by heavens-gate.lucid.com id AA11941g; Wed, 17 Jun 92 13:28:01 PDT Received: from postman.osf.org by heavens-gate.lucid.com id AA11936g; Wed, 17 Jun 92 13:27:50 PDT Received: from spinner.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA18511; Wed, 17 Jun 92 16:36:04 -0400 Received: by uec_hp.osf.org.osf.org (16.7/4.7) id AA09673; Wed, 17 Jun 92 16:37:49 -0400 Subject: Trying to get it running under Motif on a HP Snak box To: bug-lucid-emacs@lucid.com X-Mailer: Poste 2.0 From: Douglas Rand Date: Wed, 17 Jun 92 16:37:44 -0400 Message-Id: <920617163744.6435@spinner.osf.org> Encoding: 31 TEXT, 4 TEXT SIGNATURE Ah sweet mysteries of life! OK. I'm running with the latest version of Motif 1.2, X11R5 on a HP700 running HPUX. I finally got everything to compile. I cannot get it to link yet. Some comments: 1) For a Motif based application, there should be no Athena widgets included. While it's true it ought to work, it may not. Anyway a consideration. 2) You have a few things that may pass gcc but the HP ansi cc is very picky. 3) Do you want diffs? I tried patching in Motif widgets for the paned windows you use. I made some other changes you might want. 4) Libraries. Xext doesn't exist in R5 I needed to change the following files: floatfns.c.~1~ sysdep.c.~1~ xmakefile.~1~ data.c.~1~ menubar.c.~1~ unexhp9k800.c.~1~ xterm.c.~1~ fileio.c.~1~ xfns.c.~1~ Let me know if others have gotten this going on the HP. Thanks, Doug Douglas S. Rand OSF/Motif Dev. Snail: 11 Cambridge Center, Cambridge, MA 02142 Disclaimer: I don't know if OSF agrees with me... let's vote on it. Amateur Radio: KC1KJ From bug-lucid-emacs-request@lucid.com Wed Jun 17 13:44:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24656; Wed, 17 Jun 92 13:44:17 PDT Received: by heavens-gate.lucid.com id AA11977g; Wed, 17 Jun 92 13:34:48 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA11973g; Wed, 17 Jun 92 13:34:37 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA14043; Wed, 17 Jun 92 13:43:12 PDT Date: Wed, 17 Jun 92 13:43:12 PDT Message-Id: <9206172043.AA14043@thalidomide.lucid> X-Windows: Form follows malfunction. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Douglas Rand Cc: bug-lucid-emacs@lucid.com Subject: Re: Trying to get it running under Motif on a HP Snak box In-Reply-To: Douglas Rand's message of Wed 17-Jun-92 16:37:44 -0400 <920617163744.6435@spinner.osf.org> References: <920617163744.6435@spinner.osf.org> In message <920617163744.6435@spinner.osf.org> Douglas Rand wrote: > > 1) For a Motif based application, there should be no Athena widgets > included. While it's true it ought to work, it may not. Anyway > a consideration. I think we used the Athena widgets because the Motif widgets were buggy. Surprise surprise. > 3) Do you want diffs? I tried patching in Motif widgets for the > paned windows you use. I made some other changes you might > want. Yes, I'd like to see whatever changes you need to make. > 4) Libraries. Xext doesn't exist in R5 It does in the MIT distribution, and -lXmu and -lXt require it (for shaped buttons.) -- Jamie From bug-lucid-emacs-request@lucid.com Wed Jun 17 13:45:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24660; Wed, 17 Jun 92 13:45:25 PDT Received: by heavens-gate.lucid.com id AA11985g; Wed, 17 Jun 92 13:35:54 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA11981g; Wed, 17 Jun 92 13:35:45 PDT Received: from ingr.ingr.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00675; Wed, 17 Jun 92 16:43:55 -0400 Received: by ingr.ingr.com (5.61/INGR-1.1) id AA10459; Wed, 17 Jun 92 15:48:39 -0500 Received: from simpson.turtles by turtles (4.1/SMI-4.1) id AA27088; Wed, 17 Jun 92 17:56:51 IDT Received: by simpson.turtles (4.1/SMI-4.1) id AA13253; Wed, 17 Jun 92 17:57:03 IDT From: matis!amir@uunet.UU.NET (Amir Katz) Message-Id: <9206171457.AA13253@simpson.turtles> Subject: Lemacs & Gnu CC 2.0 woes To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Wed, 17 Jun 92 17:57:02 EET DST Organization: SEE Technologies Ltd. Reply-To: matis!ingr.COM!amir%matis.UUCP@uunet.UU.NET Followup-To: amir%matis.UUCP@ingr.COM X-Mailer: ELM [version 2.3 PL11] Lucid Magicians, After giving up on building lemacs with Sun's ANSI-C compiler, I tried with GNU cc 2.0. As per a previous post and the INSTALL file, I compiled all the files in the src dir with gcc -traditional -g -c -I./lwlib -Demacs except emacs.c (which was compiled with Sun's unbundled C compiler), and environ.c (which needed the '-ansi' flag for gcc). Still, the executable dumps core: Program received signal 11, Segmentation fault 0x466c8 in main (argc=1, argv=0xf7fffa84, envp=0xf7fffa8c) at emacs.c:855 855 initialized = 1; (gdb) p &initialized $1 = (int *) 0x1cb2d8 (gdb) set initialized=2 Seems like the variable 'initialized' is read-only (??), but the debugger does let me modify it, so what's the deal here? Please respond to the address below. -- /* Amir J. Katz | UUCP: uunet!ingr!matis!amir */ /* System Specialist | Internet: amir%matis.UUCP@ingr.COM */ /* SEE Technologies Ltd. | Voice: +972 52-584684, Fax: +972 52-543917 */ From bug-lucid-emacs-request@lucid.com Wed Jun 17 14:57:27 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24855; Wed, 17 Jun 92 14:57:27 PDT Received: by heavens-gate.lucid.com id AA12225g; Wed, 17 Jun 92 14:48:23 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA12221g; Wed, 17 Jun 92 14:48:15 PDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA16825; Wed, 17 Jun 92 17:54:31 -0400 Received: by starbase.mitre.org (4.1/SMI-4.1) id AA13520; Wed, 17 Jun 92 17:53:18 EDT Date: Wed, 17 Jun 92 17:53:18 EDT From: duff@starbase.MITRE.ORG (David A. Duff) Message-Id: <9206172153.AA13520@starbase.mitre.org> To: bug-lucid-emacs@lucid.com Subject: behaviour of modification flag for rmail buffers? Reply-To: duff@mitre.org i've noticed that in version 19, when i do c-x s (save some buffers), my modified mail buffers are not saved. in version 18.57, this command offered to save all my modified buffers, including rmail buffers. is there some reason for this change? dave duff mitre corporation 703-883-7731 duff@mitre.org ai technical center mclean, va usa From bug-lucid-emacs-request@lucid.com Thu Jun 18 03:33:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26956; Thu, 18 Jun 92 03:33:00 PDT Received: by heavens-gate.lucid.com id AA13819g; Thu, 18 Jun 92 03:22:12 PDT Received: from trout.nosc.mil by heavens-gate.lucid.com id AA13815g; Thu, 18 Jun 92 03:22:04 PDT Received: from popeye.nosc.mil by trout.nosc.mil (5.59/1.27) id AA03830; Wed, 17 Jun 92 23:30:00 PDT Received: by popeye.nosc.mil.four.four.four (4.0/SMI-4.0) id AA14771; Wed, 17 Jun 92 23:29:45 PDT Date: Wed, 17 Jun 92 23:29:45 PDT From: glasgow%popeye.nosc.mil@nosc.mil (Michael Glasgow) Message-Id: <9206180629.AA14771@popeye.nosc.mil.four.four.four> To: bug-lucid-emacs@lucid.com Subject: Problems building emacs. I am having several problems with Lucid Emas. First of all, I like so many others can not get it to compile and run. More on this in a minute. I downloaded the executable, and this runs okay, but when I type Meta-X, all I get is the following message. Symbol's value as variable is void: meta-flag I am compiling with gcc-2.2.1. I followed some of the hints posted, and got it to compile, but when it runs, it immediately dumps core. I tried compiling emacs.c with Sun's compiler, and then linking. This worked, but lemacs still dumped core. I have included a stack trace from gdb. I don't know where to start to try and find the problem. The line numbers may be a bit skewed. I started to un-ansi-fy the code, then gcc 2.2 was released, and decided to try that. #0 0x12f2e4 in _XtCompileResourceList () #1 0x130508 in XtGetSubresources () #2 0x2e408 in maybe_set_screen_title_format (shell=0x2dfd30) at xfns.c:709 #3 0x2e5b4 in x_create_widgets (s=0x2dfb18, parms=338185052, lisp_window_id=69672188) at xfns.c:752 #4 0x2eac8 in Fx_create_screen (parms=338185052, lisp_window_id=69672188) at xfns.c:878 #5 0x7ab28 in Ffuncall (nargs=2, args=0xf7ffd284) at eval.c:1809 #6 0x8fa54 in Fbyte_code (bytestr=204261888, vector=271371856, maxdepth=4) at bytecode.c:428 #7 0x7b3d0 in funcall_lambda (fun=405589624, nargs=1, arg_vector=0xf7ffd4ec) at eval.c:1970 #8 0x7ac50 in Ffuncall (nargs=2, args=0xf7ffd4e8) at eval.c:1837 #9 0x8fa54 in Fbyte_code (bytestr=204261936, vector=271372952, maxdepth=2) at bytecode.c:428 #10 0x79ad0 in Feval (form=338227356) at eval.c:1419 #11 0x78658 in Fcondition_case (args=338184820) at eval.c:969 #12 0x90324 in Fbyte_code (bytestr=204261924, vector=271373000, maxdepth=3) at bytecode.c:582 #13 0x7b3d0 in funcall_lambda (fun=405590768, nargs=1, arg_vector=0xf7ffda3c) at eval.c:1970 #14 0x7ac50 in Ffuncall (nargs=2, args=0xf7ffda38) at eval.c:1837 #15 0x8fa54 in Fbyte_code (bytestr=204038408, vector=271073648, maxdepth=4) at bytecode.c:428 #16 0x7b3d0 in funcall_lambda (fun=405291440, nargs=0, arg_vector=0xf7ffdd58) at eval.c:1970 #17 0x7ac50 in Ffuncall (nargs=1, args=0xf7ffdd54) at eval.c:1837 #18 0x7a95c in Ffuncall (nargs=2, args=0xf7ffdd50) at eval.c:1787 #19 0x7a3d8 in call1 (fn=69700120, arg=69862044) at eval.c:1615 #20 0x80534 in mapcar1 (leni=1, vals=0xf7ffde98, fn=69700120, seq=338223156) at fns.c:1262 #21 0x8074c in Fmapcar (fn=69700120, seq=338223156) at fns.c:1319 #22 0x7ab28 in Ffuncall (nargs=3, args=0xf7ffe020) at eval.c:1809 #23 0x8fa54 in Fbyte_code (bytestr=203214596, vector=270323524, maxdepth=4) at bytecode.c:428 #24 0x7b3d0 in funcall_lambda (fun=404541144, nargs=1, arg_vector=0xf7ffe28c) at eval.c:1970 #25 0x7ac50 in Ffuncall (nargs=2, args=0xf7ffe288) at eval.c:1837 #26 0x8fa54 in Fbyte_code (bytestr=203292056, vector=270400948, maxdepth=2) at bytecode.c:428 #27 0x79ad0 in Feval (form=337509768) at eval.c:1419 #28 0x78658 in Fcondition_case (args=338552956) at eval.c:969 #29 0x90324 in Fbyte_code (bytestr=203291804, vector=270400760, maxdepth=5) at bytecode.c:582 #30 0x7b3d0 in funcall_lambda (fun=404618372, nargs=0, arg_vector=0xf7ffe7e4) at eval.c:1970 #31 0x7ac50 in Ffuncall (nargs=1, args=0xf7ffe7e0) at eval.c:1837 #32 0x8fa54 in Fbyte_code (bytestr=203290576, vector=270399656, maxdepth=3) at bytecode.c:428 #33 0x7b3d0 in funcall_lambda (fun=404617144, nargs=0, arg_vector=0xf7ffe990) at eval.c:1970 #34 0x7afec in apply_lambda (fun=404617144, args=69672188, eval_flag=1) at eval.c:1901 #35 0x79bc8 in Feval (form=337507984) at eval.c:1442 #36 0x78658 in Fcondition_case (args=338213124) at eval.c:969 #37 0x90324 in Fbyte_code (bytestr=203290032, vector=270398984, maxdepth=5) at bytecode.c:582 #38 0x7b3d0 in funcall_lambda (fun=404616600, nargs=0, arg_vector=0xf7ffee20) at eval.c:1970 #39 0x7afec in apply_lambda (fun=404616600, args=69672188, eval_flag=1) at eval.c:1901 #40 0x79bc8 in Feval (form=338184796) at eval.c:1442 #41 0x42058 in top_level_2 () at keyboard.c:395 #42 0x78788 in internal_condition_case (bfun=0x42044 , handlers=69672468, hfun=0x41bb4 ) at eval.c:1003 #43 0x420ac in top_level_1 (dummy=69672188) at keyboard.c:404 #44 0x7818c in internal_catch (tag=69672448, func=0x42068 , arg=69672188) at eval.c:815 #45 0x41f9c in command_loop () at keyboard.c:364 #46 0x41a24 in recursive_edit_1 () at keyboard.c:222 #47 0x41b34 in Frecursive_edit () at keyboard.c:251 #48 0x41394 in main (argc=1, argv=0xf7fff45c, envp=0xf7fff464) at emacs.c:881 Michael Glasgow glasgow@popeye.nosc.mil From bug-lucid-emacs-request@lucid.com Thu Jun 18 03:43:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26986; Thu, 18 Jun 92 03:43:08 PDT Received: by heavens-gate.lucid.com id AA13845g; Thu, 18 Jun 92 03:32:34 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA13841g; Thu, 18 Jun 92 03:32:27 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00833; Thu, 18 Jun 92 03:40:59 PDT Date: Thu, 18 Jun 92 03:40:59 PDT Message-Id: <9206181040.AA00833@thalidomide.lucid> X-Windows: Complex nonsolutions to simple nonproblems. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: glasgow%popeye.nosc.mil@nosc.mil (Michael Glasgow) Cc: bug-lucid-emacs@lucid.com Subject: Re: Problems building emacs. In-Reply-To: Michael Glasgow's message of Wed 17-Jun-92 23:29:45 PDT <9206180629.AA14771@popeye.nosc.mil.four.four.four> References: <9206180629.AA14771@popeye.nosc.mil.four.four.four> In message <9206180629.AA14771@popeye.nosc.mil.four.four.four> Michael Glasgow wrote: > > Symbol's value as variable is void: meta-flag Run with -q. This is almost certainly something you're loading. > #0 0x12f2e4 in _XtCompileResourceList () > #1 0x130508 in XtGetSubresources () > #2 0x2e408 in maybe_set_screen_title_format (shell=0x2dfd30) at xfns.c:709 Well, I don't recognise this. My only suggestion would be to link with a debugging version of Xt and figure out what it's blowing up on. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Jun 18 04:17:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27057; Thu, 18 Jun 92 04:17:17 PDT Received: by heavens-gate.lucid.com id AA13897g; Thu, 18 Jun 92 04:06:36 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA13893g; Thu, 18 Jun 92 04:06:23 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA16805; Thu, 18 Jun 1992 13:14:45 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA12418; Thu, 18 Jun 92 13:18:21 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA28455; Thu, 18 Jun 92 13:11:49 +0200 Date: Thu, 18 Jun 92 13:11:49 +0200 From: queinnec%mailhost.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206181111.AA28455@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA01593; Thu, 18 Jun 92 13:11:50 +0200 To: Bug Lucid Emacs Subject: underscores badly displayed with times font Not important at all, and I suppose it's covered by the phrase in NEWS: "There may be some display glitches if all the fonts of a screen are not the same height in pixels." When using the fonts "-*-times-medium-r-*-*-14-*-*-*-*-*-*-*" and "-*-clean-medium-r-*-*-14-*-*-*-*-70-*-*", underscores _ in a buffer displayed using the times font produce problems: sometimes they are not displayed at all (but there is room for them), sometimes they are displayed but will not disappeared when the window is scrolled. This problem always disappears when I hit C-l (recenter) Phil From bug-lucid-emacs-request@lucid.com Thu Jun 18 19:03:47 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00361; Thu, 18 Jun 92 19:03:47 PDT Received: by heavens-gate.lucid.com id AA16063g; Thu, 18 Jun 92 18:53:52 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA16059g; Thu, 18 Jun 92 18:53:43 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA00614 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Thu, 18 Jun 1992 18:56:14 -0700 Received: by wsrcc.com id AA29583 (5.65c/IDA-1.4.4-WSR-06/16/92 for bug-lucid-emacs@lucid.com); Thu, 18 Jun 1992 18:33:24 -0700 Date: Thu, 18 Jun 1992 18:33:24 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206190133.AA29583@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: Is deiconify-emacs broken? Organization: W S Rupprecht Computer Consulting, Fremont CA I can't get deiconify-emacs to work. The following function iconifies emacs but doesn't de-iconify it again. (Single stepping this code is is somewhat problematic ;-)). (defun wink () (interactive) (iconify-emacs) (sit-for 1) (deiconify-emacs)) -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Fri Jun 19 14:37:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04642; Fri, 19 Jun 92 14:37:59 PDT Received: by heavens-gate.lucid.com id AA19006g; Fri, 19 Jun 92 14:28:48 PDT Received: from Princeton.EDU by heavens-gate.lucid.com id AA19002g; Fri, 19 Jun 92 14:28:40 PDT Received: from hhb.UUCP by Princeton.EDU (5.65b/2.90/princeton) id AA04905; Fri, 19 Jun 92 17:37:04 -0400 Received: from brett.master by master (4.1/Redac_Mahwah-v1.0) id AA10773; Fri, 19 Jun 92 16:17:24 EDT Received: by brett.master (4.1/SMI-4.1) id AA05474; Fri, 19 Jun 92 16:17:28 EDT Date: Fri, 19 Jun 92 16:17:28 EDT From: bvk%hhb@Princeton.EDU (Brett Kuehner) Message-Id: <9206192017.AA05474@brett.master> To: lucid.com!bug-lucid-emacs@Princeton.EDU Subject: Subscription request Cc: lucid.com!help-lucid-emacs@Princeton.EDU Please add me to the mailing list. Brett -- Brett Kuehner, Racal-Redac, Mahwah, NJ ...!princeton!hhb!bvk bvk%hhb@princeton.EDU From bug-lucid-emacs-request@lucid.com Fri Jun 19 16:07:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04921; Fri, 19 Jun 92 16:07:26 PDT Received: by heavens-gate.lucid.com id AA19302g; Fri, 19 Jun 92 15:57:43 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA19291g; Fri, 19 Jun 92 15:55:39 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA05950; Fri, 19 Jun 92 16:04:19 PDT Date: Fri, 19 Jun 92 16:04:19 PDT Message-Id: <9206192304.AA05950@thalidomide.lucid> From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: help-lucid-emacs@lucid.com, bug-lucid-emacs@lucid.com Subject: Lucid GNU Emacs 19.2 released It is on labrea.Stanford.EDU (36.8.0.47) in pub/gnu/lucid/. What's new: - I've rearranged the lisp directory so that there are only a handful of files at top-level; everything has been moved to subdirectories. This should speed up the automatic generation of load-path, since it will have to stat() 10x fewer files. - You can now input and display all iso8859-1 characters. If you set the variable ctl-arrow to something that is non-nil and non-t then high-bit characters will be displayed in the current font instead of in octal. - If you load x-compose.el, you can do Sun/DEC-like compose processing. See the comment in that file. - Random bug fixes, installation problem fixes, some portability #ifdefs. - The pre-built sun4 binaries are compiled with optimization now. What's old: - It doesn't use "configure" yet. - The OLIT menubar still doesn't work. Next release for sure... Enjoy... -- Jamie From bug-lucid-emacs-request@lucid.com Fri Jun 19 17:59:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05127; Fri, 19 Jun 92 17:59:29 PDT Received: by heavens-gate.lucid.com id AA19581g; Fri, 19 Jun 92 17:50:14 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA19577g; Fri, 19 Jun 92 17:50:06 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA06194; Fri, 19 Jun 92 17:58:49 PDT Date: Fri, 19 Jun 92 17:58:49 PDT Message-Id: <9206200058.AA06194@thalidomide.lucid> From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: Is deiconify-emacs broken? In-Reply-To: Wolfgang S. Rupprecht's message of Thu 18-Jun-92 18:33:24 -0700 <199206190133.AA29583@wsrcc.com> References: <199206190133.AA29583@wsrcc.com> The reason for this problem is quite complicated, and I don't know how to fix it. This message is rather long, but I hope some of you will have some ideas. There are two styles of events that Emacs (all emacses) know about. Keypresses and mouse-clicks are of the first type, which, for lack of a better name, I'll call "synchronous". Subprocess output is of the second type, which I'll call "asynchronous". Asynchronous isn't really the best name, however, because these aren't asynchronous in the interrupt sense. Neither type of event is "processed" unless emacs is waiting for input (by calling functions like read-char, sit-for, sleep-for, or accept-process-output.) The difference is that the sequences in which these two kinds of events are processed may be interleaved. Given this series of events: KeyPress A; Process output B; KeyPress C; Process output D the order in which the events are actually executed by emacs varies, depending on what emacs is doing. Suppose emacs was busy executing some random elisp code when these events became available. If emacs were to call sit-for or sleep-for, then events B and D would be executed, and removed from the queue, leaving events A and C behind. But if emacs returned to the top-level command loop before going into a wait-state, then events would be executed in the order in which they arrived. Now the dividing line between those two kinds of events gets fuzzy when it comes to X events. For things like Expose and SelectionRequest, it's appropriate for the X events (which lemacs sees as opaque "magic" events) to be treated in the same way as sub-process events. But really, there are some other kinds of X events which, although it's hard to describe them as "user input", do need to be executed in sequence with the rest of the user input. Focus change events fall into this category, because otherwise, moving the mouse into another screen while emacs was waiting for output from a process (GNUS, say) would cause the current buffer to change out from under the executing code, and everything would break. (The last time I checked, Epoch had this problem, but perhaps it has been fixed by now.) So we worked around this by adding a new type of event, an "eval" event, which, when executed, simply executes some code. Then we modified the X-specific "magic" event handler to enqueue "eval" events when certain "magic" events are processed. This is not necessarily the best way to go about it, but the upshot is that there are two kinds of "magic" events, one which is synchronous and one which is asynchronous. FocusIn and FocusOut must be like user input, because of the switching screens problem above. They are usually a result of user action, and should be treated synchronously with other user input. We applied the same logic to MapNotify, UnmapNotify, EnterNotify, and LeaveNotify: those events are treated as user input. This means that if you execute some code that causes an UnmapNotify event to be generated, as in Wolfgang's code: (iconify-screen screen) then, even if you call accept-process-ouput after that, the UnmapNotify event will not have been executed by the time you execute your next bit of code: (screen-visible-p screen) and the screen's visible-p slot will not have been updated (nor will the map-screen-hook have been run.) Because of this, calling make-screen-visible or uniconify-emacs will do nothing, because emacs thinks the screen is already visible. (And emacs can't just unconditionally map the window without consulting the visible_p slot, or it would do an unacceptable amount of auto- raising, which is something no client should do; that's in the domain of the window manager.) The reason that iconify-emacs works, and clicking on the resulting icon restores things is that emacs has returned to the top-level loop between when iconify-emacs and uniconify-emacs have been called. (iconify-emacs arranges for uniconify-emacs to be called from the map-screen-hook.) I'm not entirely sure what to do about this, and am open to suggestions. -- Jamie From bug-lucid-emacs-request@lucid.com Fri Jun 19 18:02:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05137; Fri, 19 Jun 92 18:02:39 PDT Received: by heavens-gate.lucid.com id AA19594g; Fri, 19 Jun 92 17:53:23 PDT Received: from dido.caltech.edu by heavens-gate.lucid.com id AA19590g; Fri, 19 Jun 92 17:53:11 PDT Received: by dido.caltech.edu (4.1/1.2) id AA02450; Fri, 19 Jun 92 18:00:29 PDT Date: Fri, 19 Jun 92 18:00:29 PDT From: gwp@dido.caltech.edu (G. W. Pigman III) Message-Id: <9206200100.AA02450@dido.caltech.edu> To: bug-lucid-emacs@lucid.com Subject: unread-command-char In vm 5.32.l vm-isearch-forward complains Wrong type argument: integer-or-float-or-marker-p, nil until unread-command-char is set to something. From bug-lucid-emacs-request@lucid.com Sat Jun 20 12:31:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07563; Sat, 20 Jun 92 12:31:03 PDT Received: by heavens-gate.lucid.com id AA21097g; Sat, 20 Jun 92 10:20:52 PDT Received: from nestroy.wu-wien.ac.at ([137.208.3.4]) by heavens-gate.lucid.com id AA21093g; Sat, 20 Jun 92 10:20:43 PDT Received: from dec4.wu-wien.ac.at by nestroy.wu-wien.ac.at with SMTP (16.6/15.6) id AA02890; Sat, 20 Jun 92 19:29:14 +0200 Received: by dec4.wu-wien.ac.at (5.57/Ultrix3.0-C) id AA27461; Sat, 20 Jun 92 19:30:11 +0200 From: neumann%dec4.wu-wien.ac.at@lucid.com (Gustaf Neumann) Message-Id: <9206201730.AA27461@dec4.wu-wien.ac.at> Subject: tex-mode.el needs oshell.el To: bug-lucid-emacs@lucid.com Date: Sat, 20 Jun 92 19:27:34 MET In your message from [Sat, 20 Jun 92 01:07:33 +0200] you wrote: |> - I've rearranged the lisp directory so that there are only a handful |> of files at top-level; everything has been moved to subdirectories. |> This should speed up the automatic generation of load-path, since it |> will have to stat() 10x fewer files. tex-mode.el of lemacs 19.2 requires oshell.el which does not come with lemacs 19.2, but which was available with lemacs 19.1. if I copy oshell.el from lemacs 19.1 into the new lisp tree, tex-mode.el starts nicely and dies on c-c c-b (where it tries to run tex as a shell command) with Wrong type argument: processp, "tex-shell" when i replace oshell by shell in tex-mode.el i get similar results. |> - You can now input and display all iso8859-1 characters. If you set |> the variable ctl-arrow to something that is non-nil and non-t then |> high-bit characters will be displayed in the current font instead of |> in octal. great, works perfectly. -- Gustaf Neumann neumann@dec4.wu-wien.ac.at, neumann@awiwuw11.bitnet Vienna University of Economics and Business Administration Augasse 2-6, A-1090 Vienna, Austria Tel: +43 (222) 31-336 x4533 Fax 347-555 From bug-lucid-emacs-request@lucid.com Sun Jun 21 11:16:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10279; Sun, 21 Jun 92 11:16:08 PDT Received: by heavens-gate.lucid.com id AA22309g; Sun, 21 Jun 92 11:06:57 PDT Received: from apple.com by heavens-gate.lucid.com id AA22305g; Sun, 21 Jun 92 11:06:50 PDT Received: by apple.com (5.61/10-Dec-1991-eef) id AA27135; Sun, 21 Jun 92 11:11:30 -0700 for Received: from wetware.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.7]) id AA00573; Sun, 21 Jun 92 10:44:13 PDT Received: by wetware.com (/\==/\ Smail3.1.25.1 #25.1) id ; Sat, 20 Jun 92 13:20 PDT Received: by wsrcc.com id AA18712 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Sat, 20 Jun 1992 13:17:36 -0700 Date: Sat, 20 Jun 1992 13:17:36 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206202017.AA18712@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: \C-z -> eventual core dump Organization: W S Rupprecht Computer Consulting, Fremont CA Sparc / SunOS 4.2 / X11R5p12 / gcc 2.2 Using \C-z (iconify-emacs) leave me with a broken emacs. If I uniconify emacs fairly soon (via twm) all is well. If I let it sit for a while the icon-name will change from to "emacs@". If I wait a minute or two and then uniconify via twm, I eventually get an emacs that either is 80x3010 chars (!!!!) and takes 20 megs, or one that dumps core immidiately upon being un-iconified. If I iconify emacs via twm I don't have any such problems. -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Sun Jun 21 14:20:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10660; Sun, 21 Jun 92 14:20:34 PDT Received: by heavens-gate.lucid.com id AA22492g; Sun, 21 Jun 92 14:11:21 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA22488g; Sun, 21 Jun 92 14:11:16 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA07029; Sun, 21 Jun 92 14:20:00 PDT Date: Sun, 21 Jun 92 14:20:00 PDT Message-Id: <9206212120.AA07029@thalidomide.lucid> X-Windows: The first fully modular software disaster. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com Subject: Re: \C-z -> eventual core dump In-Reply-To: Wolfgang S. Rupprecht's message of Sat 20-Jun-92 13:17:36 -0700 <199206202017.AA18712@wsrcc.com> References: <199206202017.AA18712@wsrcc.com> I'm afraid I can't reproduce this with the R5 twm. From bug-lucid-emacs-request@lucid.com Sun Jun 21 15:24:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10725; Sun, 21 Jun 92 15:24:29 PDT Received: by heavens-gate.lucid.com id AA22564g; Sun, 21 Jun 92 15:15:10 PDT Received: from life.ai.mit.edu by heavens-gate.lucid.com id AA22560g; Sun, 21 Jun 92 15:15:04 PDT Received: from espresso (espresso.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AB22096; Sun, 21 Jun 92 18:23:35 EDT From: misha@ai.mit.edu (Mike Bolotski) Received: by espresso (4.1/AI-4.10) id AA05841; Sun, 21 Jun 92 18:21:56 EDT Date: Sun, 21 Jun 92 18:21:56 EDT Message-Id: <9206212221.AA05841@espresso> To: bug-lucid-emacs@lucid.com Subject: hack-local-variables During the course of ensuring that auc-tex was supported by lemacs, I discovered that some local variables were getting clobbered by a call to "hack-local-variables". If anyone is interested in duplicating this occurence, load auc-tex 2.2, latex a buffer and look at the value of TeX-zap-file (the base name of the tex file). Then eval hack-local-variables and observe that TeX-zap-file gets set to nil. As a result, the preview and print commands don't pick up the base name of the file. My quick hack was to remove the calls to hack-local-variables, but I'd like to find the real root of the bug. Also in the same package, LaTeX-format-paragraph chokes on a type check (integerp) during a call to re-search-forward. The C source code for search_command appears the same in both 18-58 and L19, I'm confused. I haven't hacked elisp much, so I'd welcome anyone else taking a stab at the problem. -- Mike From bug-lucid-emacs-request@lucid.com Mon Jun 22 13:02:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14453; Mon, 22 Jun 92 13:02:24 PDT Received: by heavens-gate.lucid.com id AA24599g; Mon, 22 Jun 92 12:49:32 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA24593g; Mon, 22 Jun 92 12:49:14 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA19128 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Mon, 22 Jun 1992 12:51:40 -0700 Received: by wsrcc.com id AA09496 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Mon, 22 Jun 1992 12:42:22 -0700 Date: Mon, 22 Jun 1992 12:42:22 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206221942.AA09496@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: minor 19.2 install bugs. Organization: W S Rupprecht Computer Consulting, Fremont CA Sparc/SunOS 4.1/Gcc 2.2 This installation went much smoother than the 19.1. There are still a few very minor snags for me: 1) for gcc on SunOS 4.1 ymakefile:SOUND_CFLAGS needs "-traditional" added. This is a bug w. a non-ansi ioctl macro in /usr/include. This should probably be conditional on (SUNOS <= 4.1) and an ansi compiler. 2) gcc 2.2 doesn't seem to like "-Btatic" it prefers "-static". Change required to s/s-sun4.h. This should probably be conditional on: "#if defined(__GNUC__) && __GNUC__ >= 2" 3) Unless gcc is installed as cc or CC=gcc is set in the src/Makefile the ymakefile is processed with cc. This causes the "#if __GNUC__" sections to not be processed. This problem probably just needs documentation. -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Mon Jun 22 14:04:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14663; Mon, 22 Jun 92 14:04:12 PDT Received: by heavens-gate.lucid.com id AA24774g; Mon, 22 Jun 92 13:51:16 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA24770g; Mon, 22 Jun 92 13:51:05 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07792; Mon, 22 Jun 92 16:59:48 -0400 Received: from edsr.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 165810.4537; Mon, 22 Jun 1992 16:58:10 EDT Received: from tantalum.eds.com (abqtoalh) by edsr.eds.com id AA06124; Mon, 22 Jun 92 14:55:36 CDT Received: from arsenic.eds.com by tantalum.eds.com (4.1/ALBUQUERQUE-1.1) id AA14792; Mon, 22 Jun 92 13:55:48 MDT Received: by arsenic.eds.com (4.1/ALBSUB-1.3) id AA13784; Mon, 22 Jun 92 13:55:45 MDT Date: Mon, 22 Jun 92 13:55:45 MDT From: edsr!tantalum!cheeks@uunet.UU.NET (Mark Costlow) Message-Id: <9206221955.AA13784@arsenic.eds.com> To: bug-lucid-emacs@lucid.com Subject: insert-buffer not setting mark hard enough? In lemacs-19.1 (haven't had a chance to get 19.2 yet), if I do insert-buffer, the minibuffer says "Mark set", but if I immediately eval (mark), I get nil. Is this fixed in 19.2? Or is it perhaps another artifact of the zmacs stuff? Thanks, Mark -- cheeks@edsr.eds.com or ...uunet!edsr!cheeks From bug-lucid-emacs-request@lucid.com Mon Jun 22 14:16:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14691; Mon, 22 Jun 92 14:16:03 PDT Received: by heavens-gate.lucid.com id AA24839g; Mon, 22 Jun 92 14:03:21 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA24835g; Mon, 22 Jun 92 14:03:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00474; Mon, 22 Jun 92 14:12:09 PDT Date: Mon, 22 Jun 92 14:12:09 PDT Message-Id: <9206222112.AA00474@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: edsr!tantalum!cheeks@uunet.UU.NET (Mark Costlow) Cc: bug-lucid-emacs@lucid.com Subject: Re: insert-buffer not setting mark hard enough? In-Reply-To: Mark Costlow's message of Mon 22-Jun-92 13:55:45 MDT <9206221955.AA13784@arsenic.eds.com> References: <9206221955.AA13784@arsenic.eds.com> In message <9206221955.AA13784@arsenic.eds.com> Mark Costlow wrote: > > In lemacs-19.1 (haven't had a chance to get 19.2 yet), if I do > insert-buffer, the minibuffer says "Mark set", but if I immediately eval > (mark), I get nil. Is this fixed in 19.2? Or is it perhaps another > artifact of the zmacs stuff? Bingo. (mark t) will return the mark unconditionally; if zmacs-regions is true, then (mark) only returns the mark when the region is in the active (highlighted) state. This prevents commands from working on the region when it's inactive, unless they go out of their way to do so. The simple/portable fix for this, when some package is calling (mark) and doesn't really care whether the region is active or not is to replace (mark) with (let ((zmacs-regions nil)) (mark)). -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jun 22 14:22:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14724; Mon, 22 Jun 92 14:22:37 PDT Received: by heavens-gate.lucid.com id AA24868g; Mon, 22 Jun 92 14:09:28 PDT Received: from darwin.bu.edu by heavens-gate.lucid.com id AA24864g; Mon, 22 Jun 92 14:09:17 PDT Received: from HALDANE.BU.EDU by darwin.bu.edu (5.61+++/Spike-2.1) id AA20532; Mon, 22 Jun 92 17:18:15 -0400 From: ivan@darwin.bu.edu (Ivan Vazquez) Received: by haldane (4.1/Spike-2.0) id AA16014; Mon, 22 Jun 92 17:15:16 EDT Date: Mon, 22 Jun 92 17:15:16 EDT Message-Id: <9206222115.AA16014@haldane> To: bug-lucid-emacs@lucid.com Subject: Compilation problem on Sparc ELC running 4.1.1 X11R4 Hi, this compilation problem has been seen before (it's in the archived list) but I couldn't find a specific fix for it. Problem follows: gcc -g -Demacs -I./lwlib -c EmacsShell.c -o EmacsShell.o EmacsShell.c: In function `GetGeometry': EmacsShell.c:157: dereferencing pointer to incomplete type EmacsShell.c: In function `emacsShellRealize': EmacsShell.c:274: dereferencing pointer to incomplete type EmacsShell.c: In function `EvaluateWMHints': EmacsShell.c:332: dereferencing pointer to incomplete type EmacsShell.c: In function `_popup_set_prop': EmacsShell.c:381: dereferencing pointer to incomplete type EmacsShell.c:391: dereferencing pointer to incomplete type EmacsShell.c:431: dereferencing pointer to incomplete type make[1]: *** [EmacsShell.o] Error 1 make: *** [doall] Error 1 exit 1 I have already removed all the /usr/local/include/lib/gcc/.../include/X* away. thanks, Ivan From bug-lucid-emacs-request@lucid.com Mon Jun 22 14:27:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14735; Mon, 22 Jun 92 14:27:35 PDT Received: by heavens-gate.lucid.com id AA24893g; Mon, 22 Jun 92 14:15:43 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA24887g; Mon, 22 Jun 92 14:15:28 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA20724 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Mon, 22 Jun 1992 14:18:07 -0700 Received: by wsrcc.com id AA10990 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Mon, 22 Jun 1992 14:17:13 -0700 Date: Mon, 22 Jun 1992 14:17:13 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206222117.AA10990@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: process-connection-type t and ^M Organization: W S Rupprecht Computer Consulting, Fremont CA Sparc / SunOS 4.1 / (HAVE_TERMIO is undefined) With process-connection-type set to t, I get a ^M terminating each line of process-output. With process-connection-type set to nil this doesn't happen. I wonder if the TIOCSETN ioctl() in sysdep.c:child_setup_tty() is failing. (In theory the sun has termio and termios structs so one can use that instead of the old sgtty compatablility package. I'll play with this and see if the native termio calls work any better.) -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Mon Jun 22 16:38:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15131; Mon, 22 Jun 92 16:38:06 PDT Received: by heavens-gate.lucid.com id AA25321g; Mon, 22 Jun 92 16:25:37 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA25317g; Mon, 22 Jun 92 16:25:31 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09884; Mon, 22 Jun 92 19:34:10 -0400 Received: from edsr.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 193355.13422; Mon, 22 Jun 1992 19:33:55 EDT Received: from tantalum.eds.com (abqtoalh) by edsr.eds.com id AA12317; Mon, 22 Jun 92 17:42:25 CDT Received: from arsenic.eds.com by tantalum.eds.com (4.1/ALBUQUERQUE-1.1) id AA18002; Mon, 22 Jun 92 16:42:35 MDT Received: by arsenic.eds.com (4.1/ALBSUB-1.3) id AA14175; Mon, 22 Jun 92 16:42:34 MDT Date: Mon, 22 Jun 92 16:42:34 MDT From: edsr!tantalum!cheeks@uunet.UU.NET (Mark Costlow) Message-Id: <9206222242.AA14175@arsenic.eds.com> To: uunet!lucid.com!jwz@uunet.UU.NET Cc: bug-lucid-emacs@lucid.com In-Reply-To: <9206222112.AA00474@thalidomide.lucid> (uunet!lucid.com!jwz) Subject: insert-buffer not setting mark hard enough? On Mon, 22 Jun 92 14:12:09 PDT, Jamie Zawinski said: Jamie> X-Windows: It could happen to you. Jamie> Bingo. (mark t) will return the mark unconditionally; [...] Great, that does the trick. Thanks. Jamie> The simple/portable fix for this, when some package is calling Jamie> (mark) and doesn't really care whether the region is active or not Jamie> is to replace (mark) with (let ((zmacs-regions nil)) (mark)). Is that better or equivalent to (mark t)? >>Chx -- cheeks@edsr.eds.com or ...uunet!edsr!cheeks From bug-lucid-emacs-request@lucid.com Mon Jun 22 17:23:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15227; Mon, 22 Jun 92 17:23:26 PDT Received: by heavens-gate.lucid.com id AA25469g; Mon, 22 Jun 92 17:12:31 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA25465g; Mon, 22 Jun 92 17:12:22 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA19688; Mon, 22 Jun 92 17:19:44 -0700 Received: from bi.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA02033; Mon, 22 Jun 92 12:17:13 PDT Received: by bi.twinsun.com (4.1/SMI-4.1) id AA25763; Mon, 22 Jun 92 12:17:12 PDT Date: Mon, 22 Jun 92 12:17:12 PDT From: eggert@bi.twinsun.com (Paul Eggert) Message-Id: <9206221917.AA25763@bi.twinsun.com> To: bug-lucid-emacs@lucid.com Subject: epoch-pop can't be compiled lemacs 19.2 comes with a file lisp/ilisp/epoch-pop.elc that is out-of-date with respect to the corresponding .el file, but which can't be made because the .el file requires epoch-util, which isn't delivered with lemacs. From bug-lucid-emacs-request@lucid.com Mon Jun 22 17:42:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15255; Mon, 22 Jun 92 17:42:19 PDT Received: by heavens-gate.lucid.com id AA25527g; Mon, 22 Jun 92 17:31:31 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA25523g; Mon, 22 Jun 92 17:31:25 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA00718; Mon, 22 Jun 92 17:40:24 PDT Date: Mon, 22 Jun 92 17:40:24 PDT Message-Id: <9206230040.AA00718@thalidomide.lucid> X-Windows: Let it get in YOUR way. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: edsr!tantalum!cheeks@uunet.UU.NET (Mark Costlow) Cc: bug-lucid-emacs@lucid.com Subject: Re: insert-buffer not setting mark hard enough? In-Reply-To: Mark Costlow's message of Mon 22-Jun-92 16:42:34 MDT <9206222242.AA14175@arsenic.eds.com> References: <9206222112.AA00474@thalidomide.lucid> <9206222242.AA14175@arsenic.eds.com> In message <9206222242.AA14175@arsenic.eds.com> Mark Costlow wrote: > > Jamie> The simple/portable fix for this, when some package is calling > Jamie> (mark) and doesn't really care whether the region is active or not > Jamie> is to replace (mark) with (let ((zmacs-regions nil)) (mark)). > > Is that better or equivalent to (mark t)? They accomplish the same thing, but the (let ...) version is better in that it is backward compatible with v18. (mark) takes no args in v18. But if you're writing lemacs-specific code anyway (fonts, menus, etc), you might as well use the (mark t) form. -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 10:37:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18655; Tue, 23 Jun 92 10:37:36 PDT Received: by heavens-gate.lucid.com id AA27738g; Tue, 23 Jun 92 10:28:13 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA27734g; Tue, 23 Jun 92 10:28:04 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA07365 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Tue, 23 Jun 1992 10:30:46 -0700 Received: by wsrcc.com id AA29784 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Tue, 23 Jun 1992 10:28:51 -0700 Newsgroups: list.lucid-emacs.bug Path: wolfgang From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: process-connection-type t and ^M Message-Id: Organization: W S Rupprecht Computer Consulting, Fremont CA References: <199206222117.AA10990@wsrcc.com> Distribution: wsrcc-net Date: Tue, 23 Jun 1992 17:28:48 GMT Apparently-To: bug-lucid-emacs@lucid.com >Sparc / SunOS 4.1 / (HAVE_TERMIO is undefined) >With process-connection-type set to t, I get a ^M terminating each >line of process-output. >With process-connection-type set to nil this doesn't happen. Problem solved. The above failures seemed to be related to an incomplete installation of gcc 2.2 which allowed some non-ANSI compatible include files into the compilation. In particular this effects virtually all ioctl() calls. -wolfgang (Now to go back over my bugs and see which others went away.) -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Tue Jun 23 12:05:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19116; Tue, 23 Jun 92 12:05:23 PDT Received: by heavens-gate.lucid.com id AA28036g; Tue, 23 Jun 92 11:55:57 PDT Received: from ti.com by heavens-gate.lucid.com id AA28032g; Tue, 23 Jun 92 11:55:51 PDT Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.59/LAI-3.2) id AA24707; Tue, 23 Jun 92 14:04:59 CDT Received: from crowtrobot.csc.ti.com (crowtrobot) by tilde.csc.ti.com id AA09092; Tue, 23 Jun 1992 14:03:38 -0500 Received: by crowtrobot.csc.ti.com (4.1/SMI-4.1) id AA00984; Tue, 23 Jun 92 14:03:36 CDT Date: Tue, 23 Jun 92 14:03:36 CDT From: wall@crowtrobot.csc.ti.com (Raj Wall) Message-Id: <9206231903.AA00984@crowtrobot.csc.ti.com> To: bug-lucid-emacs@lucid.com Subject: ispell I have had trouble getting ispell started. It goes into auto-save and never comes out. I end up (a half-hour later) ^G-ing out. Or is my machine just r e a l s l o w (I'm running a SPARC 2). Regards, Raj Wall wall@csc.ti.com From bug-lucid-emacs-request@lucid.com Tue Jun 23 12:09:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19141; Tue, 23 Jun 92 12:09:46 PDT Received: by heavens-gate.lucid.com id AA28052g; Tue, 23 Jun 92 12:00:11 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA28042g; Tue, 23 Jun 92 12:00:00 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02270; Tue, 23 Jun 92 12:08:45 PDT Date: Tue, 23 Jun 92 12:08:45 PDT Message-Id: <9206231908.AA02270@thalidomide.lucid> X-Windows: The problem for your problem. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: wall@crowtrobot.csc.ti.com (Raj Wall) Cc: bug-lucid-emacs@lucid.com Subject: Re: ispell In-Reply-To: Raj Wall's message of Tue 23-Jun-92 14:03:36 CDT <9206231903.AA00984@crowtrobot.csc.ti.com> References: <9206231903.AA00984@crowtrobot.csc.ti.com> Some times the "Auto saving..." message isn't cleared when it should be. So probably emacs wasn't really stuck inside of auto-save, but somewhere else. Possibly you're loading a version of ispell.el that is incompatible with the ispell executable that you have. "Sitting there and doing nothing" is a common symptom of that. -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 12:40:47 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19243; Tue, 23 Jun 92 12:40:47 PDT Received: by heavens-gate.lucid.com id AA28147g; Tue, 23 Jun 92 12:29:13 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA28143g; Tue, 23 Jun 92 12:29:06 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA05383; Tue, 23 Jun 92 12:37:46 -0700 Received: from shadow.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA09188; Tue, 23 Jun 92 12:22:19 PDT Received: by shadow.twinsun.com (4.1/SMI-4.1) id AA18713; Tue, 23 Jun 92 12:22:18 PDT Date: Tue, 23 Jun 92 12:22:18 PDT From: eggert@shadow.twinsun.com (Paul Eggert) Message-Id: <9206231922.AA18713@shadow.twinsun.com> To: bug-lucid-emacs@lucid.com Subject: 19.2 broke PATH_LOADSEARCH; startup.el improvement We install lemacs into /local/bin/lemacs and the lemacs libraries into /local/lib/lemacs/lisp and /local/lib/lemacs/etc. This isn't that weird a configuration, but startup.el can't figure it out. In 19.1, we worked around this by defining PATH_LOADSEARCH in paths.h, but this no longer works in 19.2 given the lisp/ reorganization, because subdirectories of PATH_LOADSEARCH are not examined. The PATH_LOADSEARCH bug should probably be fixed, since other people probably have ``weird'' configurations too. However, we used a different workaround: we hacked lisp/prim/startup.el so that it recognizes the D/bin/lemacs -> D/lib/lemacs installation template. Here is our patch: =================================================================== RCS file: lisp/prim/startup.el,v retrieving revision 19.2 diff -c -r19.2 lisp/prim/startup.el *** lisp/prim/startup.el 1992/06/15 09:56:54 19.2 --- lisp/prim/startup.el 1992/06/23 18:52:10 *************** *** 391,405 **** ;; ;; Make sure there is a reasonable elisp library directory on the load path, ;; and a reasonable emacs utility directory on the exec-path, even if this ! ;; emacs was dumped with now-inappropriate defaults. Look at the directory ! ;; from which this emacs image was run: ;; ! ;; o If it ends in .../src/, and ../lisp/ exists, then use that for the ;; lisp library (likewise for /etc/ and /lock/). ! ;; o If there is a subdirectory of that dir called lisp/ (or etc/ or ! ;; lock/), then use that. ;; o If the emacs program that was run is itself a symlink, then chase ;; the link and try again on the resultant directory. ;; ;; These heuristics fail if the emacs binary was copied from the main emacs ;; tree to some other directory, and links for the lisp directory were not --- 391,408 ---- ;; ;; Make sure there is a reasonable elisp library directory on the load path, ;; and a reasonable emacs utility directory on the exec-path, even if this ! ;; emacs was dumped with now-inappropriate defaults. Look at the name ! ;; of this emacs image was run: ;; ! ;; o If the emacs image is named D/bin/P, and if D/P/lisp/ exists, ! ;; then use that for the lisp library (likewise for /etc/ and /lock/). ! ;; o If it is named D/src/P, and D/lisp/ exists, then use that for the ;; lisp library (likewise for /etc/ and /lock/). ! ;; o If it is named D/P, and D/lisp/ (or etc/ or lock/) exists, ! ;; then use that. ;; o If the emacs program that was run is itself a symlink, then chase ;; the link and try again on the resultant directory. + ;; o If all else fails, look in a couple of obvious places. ;; ;; These heuristics fail if the emacs binary was copied from the main emacs ;; tree to some other directory, and links for the lisp directory were not *************** *** 509,514 **** --- 512,527 ---- (let ((invocation-directory (file-name-directory execution-path)) tmp) (cond ;; + ;; If in .../bin/lemacs, look for .../lib/lemacs/lisp/ + ;; + ((and (string-match "\\(^\\|/\\)bin/$" invocation-directory) + (file-directory-p + (setq tmp (concat (substring invocation-directory 0 + (match-end 1)) + "lib/" + (file-name-nondirectory execution-path) + "/" dir "/")))) + tmp) ;; If in .../src/, look for subdirs of this directory's parent. ;; ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\)/$" From bug-lucid-emacs-request@lucid.com Tue Jun 23 12:40:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19248; Tue, 23 Jun 92 12:40:58 PDT Received: by heavens-gate.lucid.com id AA28152g; Tue, 23 Jun 92 12:29:26 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA28148g; Tue, 23 Jun 92 12:29:16 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA05395; Tue, 23 Jun 92 12:37:51 -0700 Received: from shadow.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA09207; Tue, 23 Jun 92 12:26:49 PDT Received: by shadow.twinsun.com (4.1/SMI-4.1) id AA18722; Tue, 23 Jun 92 12:26:47 PDT Date: Tue, 23 Jun 92 12:26:47 PDT From: eggert@shadow.twinsun.com (Paul Eggert) Message-Id: <9206231926.AA18722@shadow.twinsun.com> To: bug-lucid-emacs@lucid.com Subject: too many stat()s Lucid GNU Emacs 19.2 stat()s way too many files when it tries to load a file. For example, as it starts up and is loading "screen", it stats the following 37 file names. The first 36 names don't exist. This excessive statting slows things down, especially over NFS. .../lisp/screen.elc .../lisp/screen.el .../lisp/screen .../lisp/bytecomp/screen.elc .../lisp/bytecomp/screen.el .../lisp/bytecomp/screen .../lisp/calendar/screen.elc .../lisp/calendar/screen.el .../lisp/calendar/screen .../lisp/comint/screen.elc .../lisp/comint/screen.el .../lisp/comint/screen .../lisp/dired/screen.elc .../lisp/dired/screen.el .../lisp/dired/screen .../lisp/electric/screen.elc .../lisp/electric/screen.el .../lisp/electric/screen .../lisp/emulators/screen.elc .../lisp/emulators/screen.el .../lisp/emulators/screen .../lisp/energize/screen.elc .../lisp/energize/screen.el .../lisp/energize/screen .../lisp/gnus/screen.elc .../lisp/gnus/screen.el .../lisp/gnus/screen .../lisp/ilisp/screen.elc .../lisp/ilisp/screen.el .../lisp/ilisp/screen .../lisp/modes/screen.elc .../lisp/modes/screen.el .../lisp/modes/screen .../lisp/packages/screen.elc .../lisp/packages/screen.el .../lisp/packages/screen .../lisp/prim/screen.elc From bug-lucid-emacs-request@lucid.com Tue Jun 23 12:51:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19322; Tue, 23 Jun 92 12:51:33 PDT Received: by heavens-gate.lucid.com id AA28210g; Tue, 23 Jun 92 12:41:23 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA28206g; Tue, 23 Jun 92 12:41:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02341; Tue, 23 Jun 92 12:49:57 PDT Date: Tue, 23 Jun 92 12:49:57 PDT Message-Id: <9206231949.AA02341@thalidomide.lucid> X-Windows: The art of incompetence. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: eggert@shadow.twinsun.com (Paul Eggert) Cc: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: Paul Eggert's message of Tue 23-Jun-92 12:26:47 PDT <9206231926.AA18722@shadow.twinsun.com> References: <9206231926.AA18722@shadow.twinsun.com> In message <9206231926.AA18722@shadow.twinsun.com> Paul Eggert wrote: > > Lucid GNU Emacs 19.2 stat()s way too many files when it tries to load a > file. For example, as it starts up and is loading "screen", it stats the > following 37 file names. The first 36 names don't exist. This excessive > statting slows things down, especially over NFS. That -should- be fast. After all, when a shell launches a program, it has to do the same thing (until that program is in the cache, anyway.) If anyone can think of a way to have emacs cache the contents of the directories on the load-path WITHOUT forcing the user to ever need to use some analog of the "rehash" shell command, please speak up. -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 13:00:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19332; Tue, 23 Jun 92 13:00:59 PDT Received: by heavens-gate.lucid.com id AA28240g; Tue, 23 Jun 92 12:49:08 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA28233g; Tue, 23 Jun 92 12:48:49 PDT Received: from wendy-fate.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10720; Tue, 23 Jun 92 15:57:32 -0400 From: kyle@wendy-fate.uu.net Received: by wendy-fate.UU.NET (5.61/UUNET-mail-leaf) id AA03974; Tue, 23 Jun 92 15:57:14 -0400 Date: Tue, 23 Jun 92 15:57:14 -0400 Message-Id: <9206231957.AA03974@wendy-fate.UU.NET> To: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: <9206231949.AA02341@thalidomide.lucid> References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> Jamie Zawinski writes: > In message <9206231926.AA18722@shadow.twinsun.com> Paul Eggert wrote: > > > > Lucid GNU Emacs 19.2 stat()s way too many files when it tries to load a > > file. For example, as it starts up and is loading "screen", it stats the > > following 37 file names. The first 36 names don't exist. This excessive > > statting slows things down, especially over NFS. > > That -should- be fast. After all, when a shell launches a program, it has > to do the same thing (until that program is in the cache, anyway.) > > If anyone can think of a way to have emacs cache the contents of the > directories on the load-path WITHOUT forcing the user to ever need to use > some analog of the "rehash" shell command, please speak up. Well, if you kept track of the modify times of the directories in the load path, you could rehash automatically as needed. You would only have to stat the directories, which would cut the number of stat()s needed by 2/3rds. From bug-lucid-emacs-request@lucid.com Tue Jun 23 13:03:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19338; Tue, 23 Jun 92 13:03:57 PDT Received: by heavens-gate.lucid.com id AA28275g; Tue, 23 Jun 92 12:53:15 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA28269g; Tue, 23 Jun 92 12:52:46 PDT Received: from wendy-fate.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11708; Tue, 23 Jun 92 16:01:20 -0400 From: kyle@wendy-fate.uu.net Received: by wendy-fate.UU.NET (5.61/UUNET-mail-leaf) id AA04189; Tue, 23 Jun 92 16:01:04 -0400 Date: Tue, 23 Jun 92 16:01:04 -0400 Message-Id: <9206232001.AA04189@wendy-fate.UU.NET> To: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: <9206231949.AA02341@thalidomide.lucid> References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> Has anyone considered using ar and ranlib for Lisp libraries? You could have one big library containing all the commonly used Lisp libraries, all indexed in the usual way with ranlib. From bug-lucid-emacs-request@lucid.com Tue Jun 23 13:21:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19447; Tue, 23 Jun 92 13:21:14 PDT Received: by heavens-gate.lucid.com id AA28340g; Tue, 23 Jun 92 13:11:26 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA28334g; Tue, 23 Jun 92 13:11:08 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA06859; Tue, 23 Jun 1992 22:19:34 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA15382; Tue, 23 Jun 92 22:23:06 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA29428; Tue, 23 Jun 92 22:15:58 +0200 Date: Tue, 23 Jun 92 22:15:58 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206232015.AA29428@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA03548; Tue, 23 Jun 92 22:16:00 +0200 To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com, eggert@shadow.twinsun.com (Paul Eggert) Subject: Re: too many stat()s In-Reply-To: Your message of Tue 23 June 92, 12:49:57 PDT References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> > If anyone can think of a way to have emacs cache the contents of the > directories on the load-path WITHOUT forcing the user to ever need to use > some analog of the "rehash" shell command, please speak up. Why not build the cache, and before effectively using it, you just have to validate it by stating the directories in the load-path to see if any new file has been added ? If one stat() says that a directory has been modified since the last building of the cache, you need to rebuild it. If not, your cache is fine. This will divide by 3/2 the number of required stat() (why 1.5 and not 3? Here it is: in the current scheme, emacs tries to stat the file with .elc, with .el and without extension. On the average, it finds its file after 3 * n/2, where n is the number of directories in the load-path. If emacs stats all the directories, that makes n stats, hence the 1.5 factor. Note also, that you can reach a factor 3, if emacs stats only the relevant directories, that is the directories which are before (in the load-path) the directory containing the sought file, but that's becoming complicated). Phil PS: I hope I am clear, and not too much wrong, but it's 22:15 in France, and I have been working for more than 14 hours... From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:02:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19540; Tue, 23 Jun 92 14:02:41 PDT Received: by heavens-gate.lucid.com id AA28449g; Tue, 23 Jun 92 13:53:18 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA28444g; Tue, 23 Jun 92 13:53:10 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02474; Tue, 23 Jun 92 14:01:57 PDT Date: Tue, 23 Jun 92 14:01:57 PDT Message-Id: <9206232101.AA02474@thalidomide.lucid> X-Windows: The joke that kills. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: kyle@wendy-fate.uu.net Cc: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: kyle@wendy-fate.uu.net's message of Tue 23-Jun-92 15:57:14 -0400 <9206231957.AA03974@wendy-fate.UU.NET> References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> <9206231957.AA03974@wendy-fate.UU.NET> Does 1/3 as many stat()s necessarily mean 1/3 the time? That's not clear to me. Is 1/3 the time a big enough improvement, given the amount of work that implementing this kind of cache would be? Though it would be nice for emacs to start up fast, my opinion is that it's not really that important. If you're restarting emacs all the time, you're not using it very effectively. Ten or twenty seconds is no big deal if you only do it once a day. (On my system, xman takes a little more than three times as long as emacs to start up.) -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:18:18 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19586; Tue, 23 Jun 92 14:18:18 PDT Received: by heavens-gate.lucid.com id AA28488g; Tue, 23 Jun 92 14:08:53 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA28484g; Tue, 23 Jun 92 14:08:42 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA11029 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Tue, 23 Jun 1992 14:11:24 -0700 Received: by wsrcc.com id AA11369 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Tue, 23 Jun 1992 13:58:01 -0700 Newsgroups: list.lucid-emacs.bug Path: wolfgang From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: too many stat()s Message-Id: Organization: W S Rupprecht Computer Consulting, Fremont CA References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> Distribution: wsrcc-net Date: Tue, 23 Jun 1992 20:57:55 GMT Apparently-To: bug-lucid-emacs@lucid.com jwz@lucid.com (Jamie Zawinski) writes: >If anyone can think of a way to have emacs cache the contents of the >directories on the load-path WITHOUT forcing the user to ever need to use >some analog of the "rehash" shell command, please speak up. Well, I admit this answer is far from bullet-proof, but how about an auto rehash on failure? Eg. if the requested file isn't in the hash table the whole table gets rehashed. Clearly the above method fails if someone adds something upstream from the previous hashed hit. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:38:53 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19646; Tue, 23 Jun 92 14:38:53 PDT Received: by heavens-gate.lucid.com id AA28558g; Tue, 23 Jun 92 14:29:12 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA28554g; Tue, 23 Jun 92 14:29:01 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA09565; Tue, 23 Jun 92 14:37:43 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA09703; Tue, 23 Jun 92 14:31:42 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA14313; Tue, 23 Jun 92 14:31:40 PDT Date: Tue, 23 Jun 92 14:31:40 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206232131.AA14313@farside.twinsun.com> To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Tue, 23 Jun 92 12:49:57 PDT <9206231949.AA02341@thalidomide.lucid> Subject: too many stat()s Date: Tue, 23 Jun 92 12:49:57 PDT X-Windows: The art of incompetence. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com References: <9206231926.AA18722@shadow.twinsun.com> In message <9206231926.AA18722@shadow.twinsun.com> Paul Eggert wrote: > > Lucid GNU Emacs 19.2 stat()s way too many files when it tries to load a > file. For example, as it starts up and is loading "screen", it stats the > following 37 file names. The first 36 names don't exist. That -should- be fast. After all, when a shell launches a program, it has to do the same thing (until that program is in the cache, anyway.) People rarely have 37 directories in their Unix PATH. The problem is worse with lemacs than with sh, partly because of the large number of directories lemacs automatically slurps into the load path, and partly because lemacs always looks for "file.elc", "file.el", and "file" when you say (load "file"). If anyone can think of a way to have emacs cache the contents of the directories on the load-path WITHOUT forcing the user to ever need to use some analog of the "rehash" shell command, please speak up. Go back to the traditional PATH_LOADSEARCH approach; it's not incompatible with subdirectories. If someone wants to reload .../lisp/electric/ebuff-menu.el, what's wrong with making them say (load "electric/ebuff-menu")? If you don't like PATH_LOADSEARCH, then you can try more complicated solutions. For example, you can stat the directories and look at their last-changed times. You should never have to stat a Lisp file -- just open it. Better yet, add a flag to turn off directory statting after initial startup, because in practice it's unnecessary. The flag can be off by default for naive users' sake. But I would like to turn it on -- my NFS servers are a tad slow, and I don't think I'm alone in having this problem. But really, the simple PATH_LOADSEARCH approach is better than all that complexity. From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:45:04 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19661; Tue, 23 Jun 92 14:45:04 PDT Received: by heavens-gate.lucid.com id AA28580g; Tue, 23 Jun 92 14:35:22 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA28576g; Tue, 23 Jun 92 14:35:15 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02760; Tue, 23 Jun 92 14:44:03 PDT Date: Tue, 23 Jun 92 14:44:03 PDT Message-Id: <9206232144.AA02760@thalidomide.lucid> X-Windows: graphics hacking :: roman numerals : sqrt(pi) From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: eggert@twinsun.com (Paul Eggert) Cc: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: Paul Eggert's message of Tue 23-Jun-92 14:31:40 PDT <9206232131.AA14313@farside.twinsun.com> References: <9206231949.AA02341@thalidomide.lucid> <9206232131.AA14313@farside.twinsun.com> In message <9206232131.AA14313@farside.twinsun.com> Paul Eggert wrote: > > People rarely have 37 directories in their Unix PATH. Well I've got 25... > Go back to the traditional PATH_LOADSEARCH approach; it's not incompatible > with subdirectories. If someone wants to > reload .../lisp/electric/ebuff-menu.el, what's wrong with making > them say (load "electric/ebuff-menu")? Lots of code has to be updated, and people need to know what directory the things are in. In particular, every call to `require' would need to be modified; I don't think that will be acceptable. Would you like to hack up some code to try and improve this? -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:50:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19681; Tue, 23 Jun 92 14:50:28 PDT Received: by heavens-gate.lucid.com id AA28595g; Tue, 23 Jun 92 14:39:29 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA28590g; Tue, 23 Jun 92 14:39:11 PDT Received: from wendy-fate.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09371; Tue, 23 Jun 92 17:47:58 -0400 From: kyle@wendy-fate.uu.net Received: by wendy-fate.UU.NET (5.61/UUNET-mail-leaf) id AA14862; Tue, 23 Jun 92 17:33:35 -0400 Date: Tue, 23 Jun 92 17:33:35 -0400 Message-Id: <9206232133.AA14862@wendy-fate.UU.NET> To: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: <9206232101.AA02474@thalidomide.lucid> References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> <9206231957.AA03974@wendy-fate.UU.NET> <9206232101.AA02474@thalidomide.lucid> Jamie Zawinski writes: > Does 1/3 as many stat()s necessarily mean 1/3 the time? > That's not clear to me. It _might_ mean an even greater time savings. In the case where you're stat'ing file.elc, file.el and file you're usually doing linear searches in medium to large directories. In the case where you're stat'ing directories, the parent directories would typically would be small. THe assumes maximal file fanout in the leaf directories. If the Lisp files and directories are carefully organized with this in mind you can assure yourself these speed improvement. NAMEI caches complicate this simplistic analysis, of course. > Is 1/3 the time a big enough improvement, given the amount of > work that implementing this kind of cache would be? You're beginning to take the choice out of whether a user lives inside of Emacs or not. Currently I can still say "emacs file" anytime and be editing a few seconds later. I don't _have_ to be running emacsclient and a window system to get decent response time. > Though it would be nice for emacs to start up fast, my opinion > is that it's not really that important. If you're restarting > emacs all the time, you're not using it very effectively. Ten > or twenty seconds is no big deal if you only do it once a day. > (On my system, xman takes a little more than three times as > long as emacs to start up.) I don't see Emacs as a power-user only tool. But if it takes twenty seconds to start up, not many people other than power-users are going to bother to wait that long. From bug-lucid-emacs-request@lucid.com Tue Jun 23 14:50:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19685; Tue, 23 Jun 92 14:50:37 PDT Received: by heavens-gate.lucid.com id AA28599g; Tue, 23 Jun 92 14:39:44 PDT Received: from JUNIN.MT.CS.CMU.EDU by heavens-gate.lucid.com id AA28591g; Tue, 23 Jun 92 14:39:31 PDT Received: from junin.mt.cs.cmu.edu by JUNIN.MT.CS.CMU.EDU id aa00459; 23 Jun 92 17:47:25 EDT To: Paul Eggert Cc: bug-lucid-emacs@lucid.com Subject: Re: epoch-pop can't be compiled In-Reply-To: Your message of Mon, 22 Jun 92 12:17:12 -0800. <9206221917.AA25763@bi.twinsun.com> Date: Tue, 23 Jun 92 17:47:12 -0400 Message-Id: <457.709336032@JUNIN.MT.CS.CMU.EDU> From: Todd_Kaufmann@JUNIN.MT.CS.CMU.EDU Are you trying to do byte-recompile-directory on the ilisp directory? This bombs out on epoch-pop for normal (ie, non-epoch) emacs as well, and epoch-pop is only loadable in epoch (it's still out of date, but..). You should just ignore it. There should probably be a popper rewritten for v19.x (is there any demand?). I've been too busy lately to play much with 19.x, but eventually I might get around to doing this.. (contributions always welcome, of course). -todd From bug-lucid-emacs-request@lucid.com Tue Jun 23 15:08:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19760; Tue, 23 Jun 92 15:08:48 PDT Received: by heavens-gate.lucid.com id AA28647g; Tue, 23 Jun 92 14:58:58 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA28643g; Tue, 23 Jun 92 14:58:46 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA10532; Tue, 23 Jun 92 15:07:25 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA09817; Tue, 23 Jun 92 14:56:26 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA14364; Tue, 23 Jun 92 14:56:24 PDT Date: Tue, 23 Jun 92 14:56:24 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206232156.AA14364@farside.twinsun.com> To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com Subject: too many stat()s Date: Tue, 23 Jun 92 14:01:57 PDT From: Jamie Zawinski Though it would be nice for emacs to start up fast, my opinion is that it's not really that important. lemacs currently takes about 15 real-time seconds for a cold start on my poor overworked old Sparcstation 1 which is running it off an overworked NFS server. This compares to about 3 seconds for GNU Emacs 18.58. A warm start (assuming lemacs is already paged in, etc.) is 5 seconds, versus 1 second for GNU Emacs 18.58. If you're restarting emacs all the time, you're not using it very effectively. No doubt, no doubt. Still, first impressions are important. The first thing the folks here noticed was how big and slow lemacs is, compared to Emacs. It can't hurt to tune lemacs to fix this. Ten or twenty seconds is no big deal if you only do it once a day. Huh? That's three hours per year wasted. I'm not convinced. (On my system, xman takes a little more than three times as long as emacs to start up.) That's odd -- on my system, xman takes about 10 seconds for a cold start, and 5 for a warm start, so it's a tad faster than lemacs. Perhaps your xman is slow? Or you have a big MANPATH? Is 1/3 the time a big enough improvement, given the amount of work that implementing this kind of cache would be? You can do much better than a factor of 0.33. If you went back to PATH_LOADSEARCH, you'd improve the stat() time by a factor of 10. More, if you used open() instead of stat()+open(). From bug-lucid-emacs-request@lucid.com Tue Jun 23 16:13:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19933; Tue, 23 Jun 92 16:13:54 PDT Received: by heavens-gate.lucid.com id AA28817g; Tue, 23 Jun 92 16:04:31 PDT Received: from dido.caltech.edu by heavens-gate.lucid.com id AA28813g; Tue, 23 Jun 92 16:04:22 PDT Received: by dido.caltech.edu (4.1/1.2) id AA06795; Tue, 23 Jun 92 16:11:40 PDT Date: Tue, 23 Jun 92 16:11:40 PDT From: gwp@dido.caltech.edu (G. W. Pigman III) Message-Id: <9206232311.AA06795@dido.caltech.edu> To: bug-lucid-emacs@lucid.com Subject: isearch & iso8859-1 Latin1 characters are a wonderful addition to lemacs. If I load x-iso8859 and x-compose and set ctl-arrow to non-nil, I can insert and display them without difficulty, but isearch will insert a composed character instead of finding it. If I run quoted-insert and give the octal value, isearch is happy, but this not terribly convenient. From bug-lucid-emacs-request@lucid.com Tue Jun 23 18:08:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20449; Tue, 23 Jun 92 18:08:19 PDT Received: by heavens-gate.lucid.com id AA29071g; Tue, 23 Jun 92 17:58:53 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA29067g; Tue, 23 Jun 92 17:58:47 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA16869; Tue, 23 Jun 92 18:07:28 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA13653; Tue, 23 Jun 92 18:03:08 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA14806; Tue, 23 Jun 92 18:03:07 PDT Date: Tue, 23 Jun 92 18:03:07 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206240103.AA14806@farside.twinsun.com> To: bug-lucid-emacs@lucid.com Subject: too many stat()s It's not just efficiency (though that bugs me too), it's also a matter of clarity. What's the point of organizing the Lisp files in subdirectories if you're not making the organization visible to the user? If we just want to organize those files in the source code for our own benefit, that's fine, but with the current setup we might as well install just a flat hierarchy, since functions like `load' don't see the hierarchy. I say that it's better to tell users about the hierarchy and encourage them to switch from (require 'FILE) to (require 'SUBDIR/FILE). It's not hard to fix all the (require 'FILE) calls in the existing Lucid GNU Emacs library. For backwards compatibility we may want to support (require 'FILE) for certain well-known instances of FILE. That's easy to do: just install a link for those well-known instances. This could be a symlink, hard link, or short .el file saying (require 'SUBDIR/FILE) -- it doesn't really matter. Doing this will simplify the Emacs source code, since it will remove the kludgy subdirectory snarfing in prim/startup's set-default-load-path. The old PATH_LOADSEARCH method is much easier to understand and configure, as well as being more efficient. Going back to PATH_LOADSEARCH will also fix a few other bugs. (Ever try to run lemacs's `yow' program outside of lemacs? :-) From bug-lucid-emacs-request@lucid.com Tue Jun 23 18:57:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20680; Tue, 23 Jun 92 18:57:57 PDT Received: by heavens-gate.lucid.com id AA29153g; Tue, 23 Jun 92 18:48:16 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA29149g; Tue, 23 Jun 92 18:48:08 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA03076; Tue, 23 Jun 92 18:56:59 PDT Date: Tue, 23 Jun 92 18:56:59 PDT Message-Id: <9206240156.AA03076@thalidomide.lucid> X-Windows: The Cutting Edge of Obsolescence. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: eggert@twinsun.com (Paul Eggert) Cc: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: Paul Eggert's message of Tue 23-Jun-92 18:03:07 PDT <9206240103.AA14806@farside.twinsun.com> References: <9206240103.AA14806@farside.twinsun.com> In message <9206240103.AA14806@farside.twinsun.com> Paul Eggert wrote: > > It's not just efficiency (though that bugs me too), it's also a matter of > clarity. What's the point of organizing the Lisp files in subdirectories if > you're not making the organization visible to the user? If we just want to > organize those files in the source code for our own benefit, that's fine, but > with the current setup we might as well install just a flat hierarchy, since > functions like `load' don't see the hierarchy. There are two reasons to subdivide things: first, to make it easy to tell which files belong to which packages. Second, to make it easy for someone who is just browsing around the lisp directory to realize what's there, and what relationships exist. There are two reasons for load to not force users to type the name of the subdirectory when loading a file: first, because it's more work for the user. If the user knows that nntp.el exists, but doesn't know that it's a part of GNUS, they should be able to just do (require 'nntp) without worrying about it. This is exactly the same reason that $PATH exists in shells. (They also shouldn't have to guess whether something is a "mode" or a "package"; the distinction tends to get kind of fuzzy...) Second, because changing all calls to require, load-library, and autoload is an enormous change. We do not have access to every lisp package in the world. There are thousands out there. > For backwards compatibility we may want to support (require 'FILE) for > certain well-known instances of FILE. That's easy to do: just install a > link for those well-known instances. This could be a symlink, hard link, > or short .el file saying (require 'SUBDIR/FILE) -- it doesn't really matter. This would end up being almost every file in the distribution. It would make the lisp directory disappear in a morass of links: instead of lisp/ being a small directory of subdirs, the subdirs would be lost in the noise, making browsing difficult. I think that putting the links off in another directory, like ../lisp-flat/, would be a horrible hack. > Doing this will simplify the Emacs source code, since it will remove the > kludgy subdirectory snarfing in prim/startup's set-default-load-path. I don't think it's kludgy at all. I think it's an adequate, if slow, solution to a non-imagined problem. > The old PATH_LOADSEARCH method is much easier to understand and configure, For you maybe. For people who don't mind compiling emacs. Those people are most definitely in the minority. Hardcoding pathnames into executables is always, without fail, a bad idea. People want to be able to rearrange their system configuration without having to recompile anything. People want to be able to run executables built at other sites. Neither of these is possible with the v18 method. There are a few possible solutions to this (in my opinion, minor) problem: 1: Completely flatten out the lisp directory; no subdirs. I think this is bad from an organizational and maintenance standpoint. 2: Make there be fewer subdirectories. I doubt this would win much. 3: Add a cache for the load-path by looking at the directory write-dates. This might not win much more than 30%, but it could. 4: Don't snarf subdirs, but change every call to `require' and `autoload'. See above. 5: Throw away the existing code and just do it the way v18 did. See above. 6: Use ar and ranlib to put all the .elc files into a .a file. This will make the lisp library take up twice as much space, (well, more like 1.4x I guess) and is a pretty weird idea besides... It also makes it harder to add or modify files; but maybe that's ok, since casual users shouldn't be modifying the standard library anyway. 7: Leave it the way it is now. Other suggestions are welcome. I'm going to go with number 7. I think that numbers 1, 4 and 5 are the wrong solution. If someone implements number 3, and it makes a difference, I'll put it in. But, in the absense of ideas better than the ones above, I think we should stick with the status quo. I realize that some folks are unhappy with the startup speed, and I'm willing to make changes to make it start up faster, as long as that doesn't mean sacrificing the new functionality. But so far #3 is the only one that I think is a good solution. The next release will start up a little faster anyway, because it turns out that there are still a few files which are being loaded at runtime which really should have been dumped with emacs. The speed of loading things from your .emacs file won't improve, but the delay will be after the window has been mapped rather that before, and I strongly suspect that that will make you not notice. (Isn't psychology neat?) Look at it this way; lemacs takes about ten seconds longer to start than v18. But the byte-compiler that comes with lemacs makes GNUS start up and fetch newsgroups much faster. So it's a net gain... -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 20:13:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20823; Tue, 23 Jun 92 20:13:34 PDT Received: by heavens-gate.lucid.com id AA29280g; Tue, 23 Jun 92 20:03:27 PDT Received: from cs-mail.bu.edu by heavens-gate.lucid.com id AA29276g; Tue, 23 Jun 92 20:03:21 PDT Received: from CSD.BU.EDU by cs-mail.bu.edu (5.61+++/SMI-4.0.3) id AA23737; Tue, 23 Jun 92 23:11:50 -0400 From: jbw@cs.bu.edu (Joe Wells) Received: by csd.bu.edu (5.61+++/Spike-2.0) id AA01251; Tue, 23 Jun 92 23:11:51 -0400 Date: Tue, 23 Jun 92 23:11:51 -0400 Message-Id: <9206240311.AA01251@csd.bu.edu> To: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: <9206240156.AA03076@thalidomide.lucid> References: <9206240103.AA14806@farside.twinsun.com> <9206240156.AA03076@thalidomide.lucid> Sent-Via: bug-lucid-emacs@lucid.com >>>>> "Jamie" == Jamie Zawinski writes: Jamie> I think that putting the links off in another directory, like Jamie> ../lisp-flat/, would be a horrible hack. I think it would be a wonderful hack. Do it! -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details From bug-lucid-emacs-request@lucid.com Tue Jun 23 20:17:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20834; Tue, 23 Jun 92 20:17:14 PDT Received: by heavens-gate.lucid.com id AA29296g; Tue, 23 Jun 92 20:07:49 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA29292g; Tue, 23 Jun 92 20:07:41 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.17) id AA20230; Tue, 23 Jun 92 20:16:23 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA14028; Tue, 23 Jun 92 20:06:11 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA15046; Tue, 23 Jun 92 20:06:10 PDT Date: Tue, 23 Jun 92 20:06:10 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206240306.AA15046@farside.twinsun.com> To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com Subject: too many stat()s Date: Tue, 23 Jun 92 18:56:59 PDT From: Jamie Zawinski > The old PATH_LOADSEARCH method is much easier to understand and configure, For you maybe. For people who don't mind compiling emacs. Those people are most definitely in the minority. Hardcoding pathnames into executables is always, without fail, a bad idea. Come now, that's a red herring. You can deduce the name of the /lisp/ directory at runtime without affecting the rest of my proposal. As far as the rest of the discussion goes, clearly you're willing to trade performance for what you perceive to be convenience and clarity. I don't object to this trade in general, but I think 19.2's changes are neither convenient nor clear. If your goal was to make it work conveniently ``out of the box'', you failed in my case, because the ``out of the box'' method didn't work for me, and fixing it required elisp hacking beyond what one should expect of a novice. I'm not sold on the new scheme's ``clarity'' either. There's no documentation about it in the manual; this doesn't help matters. Perhaps if you document the new scheme -- e.g. with an explanation to ordinary users of what happens when two different packages contain .el files with the same name -- you'll see more of its problems. From bug-lucid-emacs-request@lucid.com Tue Jun 23 20:34:38 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20860; Tue, 23 Jun 92 20:34:38 PDT Received: by heavens-gate.lucid.com id AA29333g; Tue, 23 Jun 92 20:25:19 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA29329g; Tue, 23 Jun 92 20:25:12 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA03252; Tue, 23 Jun 92 20:34:03 PDT Date: Tue, 23 Jun 92 20:34:03 PDT Message-Id: <9206240334.AA03252@thalidomide.lucid> X-Windows: Warn your friends about it. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: eggert@twinsun.com (Paul Eggert) Cc: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: Paul Eggert's message of Tue 23-Jun-92 20:06:10 PDT <9206240306.AA15046@farside.twinsun.com> References: <9206240306.AA15046@farside.twinsun.com> In message <9206240306.AA15046@farside.twinsun.com> Paul Eggert wrote: > > > The old PATH_LOADSEARCH method is much easier to understand and > > configure, > > For you maybe. For people who don't mind compiling emacs. Those people > are most definitely in the minority. Hardcoding pathnames into > executables is always, without fail, a bad idea. > > Come now, that's a red herring. You can deduce the name of the /lisp/ > directory at runtime without affecting the rest of my proposal. I thought you were objecting to automatically deducing the name of the lisp directory as well. Sorry. > If your goal was to make it work conveniently ``out of the box'', you > failed in my case, because the ``out of the box'' method didn't work for > me, and fixing it required elisp hacking beyond what one should expect of > a novice. True. But if I include your fix to startup.el (guessing at a slightly different set of possibilities) then that problem goes away, no? It's my intent that putting stuff in paths.h should never be necessary. > I'm not sold on the new scheme's ``clarity'' either. There's no > documentation about it in the manual; this doesn't help matters. The documentation on our version of emacs clearly isn't finished. You can help out if you like. The heuristics are described in the NEWS file, where most of the new doc for this version of emacs is right now. > Perhaps if you document the new scheme -- e.g. with an explanation to > ordinary users of what happens when two different packages contain .el > files with the same name -- you'll see more of its problems. We do not distribute multiple packages which contain files of the same name. If the user installs their own package with conflicting file names, then they're going to have -exactly- the same problem under v18 as under lemacs. Right? -- Jamie From bug-lucid-emacs-request@lucid.com Tue Jun 23 21:06:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20892; Tue, 23 Jun 92 21:06:02 PDT Received: by heavens-gate.lucid.com id AA29409g; Tue, 23 Jun 92 20:56:43 PDT Received: from cs-mail.bu.edu by heavens-gate.lucid.com id AA29405g; Tue, 23 Jun 92 20:56:36 PDT Received: from CSD.BU.EDU by cs-mail.bu.edu (5.61+++/SMI-4.0.3) id AA24124; Wed, 24 Jun 92 00:05:15 -0400 From: jbw@cs.bu.edu (Joe Wells) Received: by csd.bu.edu (5.61+++/Spike-2.0) id AA01736; Wed, 24 Jun 92 00:05:15 -0400 Date: Wed, 24 Jun 92 00:05:15 -0400 Message-Id: <9206240405.AA01736@csd.bu.edu> To: bug-lucid-emacs@lucid.com Subject: Re: too many stat()s In-Reply-To: <9206232001.AA04189@wendy-fate.UU.NET> References: <9206231926.AA18722@shadow.twinsun.com> <9206231949.AA02341@thalidomide.lucid> <9206232001.AA04189@wendy-fate.UU.NET> Sent-Via: bug-lucid-emacs@lucid.com Kyle> Has anyone considered using ar and ranlib for Lisp libraries? Kyle> You could have one big library containing all the commonly used Kyle> Lisp libraries, all indexed in the usual way with ranlib. One of two cases would then hold: 1. Emacs would have to be linked with the necessary routines to extract modules from ar-style archives. Ugh. 2. Emacs would have to run a subprocess each time it wanted to extract a module. Quadruple UGH! -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details From bug-lucid-emacs-request@lucid.com Wed Jun 24 08:17:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23047; Wed, 24 Jun 92 08:17:48 PDT Received: by heavens-gate.lucid.com id AA00621g; Wed, 24 Jun 92 08:06:44 PDT Received: from gateway.bnr.ca by heavens-gate.lucid.com id AA00617g; Wed, 24 Jun 92 08:06:29 PDT Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA09519; Wed, 24 Jun 92 11:15:03 -0400 Message-Id: <9206241515.AA09519@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 1408; Wed, 24 Jun 92 11:13:14 EDT Date: 24 Jun 92 11:14:00 EDT To: bug-lucid-emacs@lucid.com From: Jeffrey (J.D.) Sparkes Subject: the (l)emacs info file has problems and there is no source f Sender: Jeffrey (J.D.) Sparkes I can't seem to read the section on pull-down menus, and there seem to be a lot of problems with links. This could (probably) be easily solved by updating the menus using the appropriate texinfo2 command, *but* the emacs.tex in the lemacs-19.2/man directory isn't the source for the info file, and is dated Dec 6, 1991, which is probably far out of date. -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Wed Jun 24 08:57:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23175; Wed, 24 Jun 92 08:57:33 PDT Received: by heavens-gate.lucid.com id AA00732g; Wed, 24 Jun 92 08:44:54 PDT Received: from sun2.nsfnet-relay.ac.uk by heavens-gate.lucid.com id AA00728g; Wed, 24 Jun 92 08:44:44 PDT Via: cs.city.ac.uk; Wed, 24 Jun 1992 16:52:52 +0100 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.barney.cs.city.ac.uk.sun4.40 via MS.5.6.barney.cs.city.ac.uk.sun4_40; Wed, 24 Jun 1992 16:55:27 +0100 (BST) Message-Id: <4eG9fja__5g80b6lB4@cs.city.ac.uk> Date: Wed, 24 Jun 1992 16:55:27 +0100 (BST) From: Andy Whitcroft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bug-lucid-emacs@lucid.com Subject: Subscribe Please subscribe `lucid-bug-users@cs.city.ac.uk' to the bug-lucid-emacs list. Thanks. Andy. From bug-lucid-emacs-request@lucid.com Wed Jun 24 09:12:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23253; Wed, 24 Jun 92 09:12:28 PDT Received: by heavens-gate.lucid.com id AA00767g; Wed, 24 Jun 92 08:58:39 PDT Received: from ti.com by heavens-gate.lucid.com id AA00763g; Wed, 24 Jun 92 08:58:26 PDT Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.59/LAI-3.2) id AA19234; Wed, 24 Jun 92 11:07:11 CDT Received: from hc.ti.com (sunspot) by tilde.csc.ti.com id AA19938; Wed, 24 Jun 1992 11:05:49 -0500 Received: from mycroft.csc.ti.com by hc.ti.com (4.1/SMI-4.1) id AA05423; Wed, 24 Jun 92 11:06:45 CDT Date: Wed, 24 Jun 92 11:06:45 CDT From: djohnson@hc.ti.com (Doug Johnson) Message-Id: <9206241606.AA05423@hc.ti.com> Received: by mycroft.csc.ti.com (4.1/SMI-4.1) id AA09555; Wed, 24 Jun 92 11:06:44 CDT To: andy@cs.city.ac.uk Cc: bug-lucid-emacs@lucid.com In-Reply-To: <4eFONK6__5g80MuUVT@cs.city.ac.uk> (message from Andy Whitcroft on Mon, 22 Jun 1992 11:07:18 +0100 (BST)) Subject: Re: GNUS 1.13 Reply-To: johnson@ti.com Sender: johnson@ti.com >Date: Mon, 22 Jun 1992 11:07:18 +0100 (BST) >From: Andy Whitcroft >Mime-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII > >As an Emacs Fan (ermmm shhh don't tell anyone) I am just getting into >Lucid. I notice that you ship the GNUS 1.13 rather than GNUS 1.14.1 >which we use with Emacs. I seem to be having some trouble with this >version (or the lucid port of it?). For some groups currently >news.software.nntp I get "Wrong type argument: syntax-table-p, nil" when >I attempt to select it to read. Anyone else seen this/fixed it? I've run down what seems to be happening and hacked a fix. I don't think it's a "real" fix, but it works. mail-strip-quoted-names in mail-utils.el was changed to do a better job of parsing names. It does a (set-syntax-table lisp-mode-syntax-table). lisp-mode-syntax-table is not routinely bound. The hacked fix is to put the following in your .emacs file. A better fix might be to change mail-strip-quoted-names to use emacs-lisp-mode-syntax-table instead. (if (string-match "Lucid" emacs-version) (setq lisp-mode-syntax-table emacs-lisp-mode-syntax-table)) -- Doug From bug-lucid-emacs-request@lucid.com Wed Jun 24 09:13:32 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23259; Wed, 24 Jun 92 09:13:32 PDT Received: by heavens-gate.lucid.com id AA00781g; Wed, 24 Jun 92 09:00:37 PDT Received: from hp.com by heavens-gate.lucid.com id AA00776g; Wed, 24 Jun 92 09:00:19 PDT Received: from gourmet.ch.apollo.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA20131; Wed, 24 Jun 92 09:07:53 -0700 Message-Id: <9206241607.AA20131@hp.com> Received: by gourmet.ch.apollo.hp.com id ; Wed, 24 Jun 92 12:08:47 -0400 Date: Wed, 24 Jun 92 12:08:47 -0400 From: sommerfeld@apollo.hp.com To: Jamie Zawinski Cc: eggert@twinsun.com, bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Tue, 23 Jun 92 18:56:59 PDT, <9206240156.AA03076@thalidomide.lucid> Subject: Re: too many stat()s 6: Use ar and ranlib to put all the .elc files into a .a file. This will make the lisp library take up twice as much space, (well, more like 1.4x I guess) .. not if you don't keep the .elc's around as separate files. and is a pretty weird idea besides... It also makes it harder to add or modify files; .. not if you tweak byte-compile-file to invoke "ar" if "elc.a" exists in the directory. but maybe that's ok, since casual users shouldn't be modifying the standard library anyway. Actually, not necessarily, since you don't have the "breakage" problem (unused allocated space at the end of file blocks). Unlike tar, which puts new files on a new block, ar starts the next file right after the previous one. Back of the envelope calculations: For a full (non-emacs-19) directory on a filesystem with a 512 byte fragment size, all the .elc files took up 2730 512-byte blocks; an "elisp.a" file containing all the .elc's took up 2592 blocks, for a savings of about 5%. On an AIX system (which uses a 4K fragment size), the savings was more like 16% (1424 vs. 1188 1 kilobyte blocks), even though the aix version of ar seems to have more overhead per file (which points out an alternate problem with this proposal: some vendors have changed the format of .a files from the "original" format found in V7). - Bill From bug-lucid-emacs-request@lucid.com Wed Jun 24 15:21:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24292; Wed, 24 Jun 92 15:21:00 PDT Received: by heavens-gate.lucid.com id AA02006g; Wed, 24 Jun 92 15:11:00 PDT Received: from lamont.ldgo.columbia.edu (ldgo.columbia.edu) by heavens-gate.lucid.com id AA01997g; Wed, 24 Jun 92 15:10:41 PDT Received: from (ko.ldgo.columbia.edu) by lamont.ldgo.columbia.edu (4.1/SMI-3.2) id AA13056; Wed, 24 Jun 92 18:19:02 EDT Message-Id: <9206242219.AA13056@lamont.ldgo.columbia.edu> Date: Wed, 24 Jun 92 18:18:48 EDT From: fritzz@lamont.ldgo.columbia.edu To: jwz@lucid.com Cc: eggert@twinsun.com, bug-lucid-emacs@lucid.com In-Reply-To: <9206240156.AA03076@thalidomide.lucid> (message from Jamie Zawinski on Tue, 23 Jun 92 18:56:59 PDT) Subject: too many stat()s How about having an environment variable that specifies which directories to look into? This would be 1) Fast, as every user can just put into that variable whatever (s)he wants to have searched and even the order. 2) Flexible, as it would allow the more advanced user or the installer/maintainer of EMACS to change configurations, add additional packages and only have to change this variable to become effective. Depending on the installation it could even be changed in a "global" .cshrc file 3) Easy to implement, two or three lines of lisp code would do it. 4) Easy to use, as almost every user should be able to set his/her PATH, so why not set EMACSPATH. Fritz From bug-lucid-emacs-request@lucid.com Wed Jun 24 15:23:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24298; Wed, 24 Jun 92 15:23:12 PDT Received: by heavens-gate.lucid.com id AA02013g; Wed, 24 Jun 92 15:13:34 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA02009g; Wed, 24 Jun 92 15:13:27 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA04319; Wed, 24 Jun 92 15:22:14 PDT Date: Wed, 24 Jun 92 15:22:14 PDT Message-Id: <9206242222.AA04319@thalidomide.lucid> X-Windows: Garbage at your fingertips. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: fritzz@lamont.ldgo.columbia.edu Cc: bug-lucid-emacs@lucid.com, eggert@twinsun.com Subject: Re: too many stat()s In-Reply-To: fritzz@lamont.ldgo.columbia.edu's message of Wed 24-Jun-92 18:18:48 EDT <9206242219.AA13056@lamont.ldgo.columbia.edu> References: <9206240156.AA03076@thalidomide.lucid> <9206242219.AA13056@lamont.ldgo.columbia.edu> It's already there, $EMACSLOADPATH. But that's related to the "automatically figuring out the load path" issue, not to the "emacs is slow to start up because there are too many directories on the load path" issue. -- Jamie From bug-lucid-emacs-request@lucid.com Wed Jun 24 23:34:49 1992 Received: from lucid.com ([192.31.212.72]) by labrea.Stanford.EDU (4.1/1.34) id AA25328; Wed, 24 Jun 92 23:34:49 PDT Received: by heavens-gate.lucid.com id AA02994g; Wed, 24 Jun 92 23:23:34 PDT Received: from srawgw.sra.co.jp by heavens-gate.lucid.com id AA02990g; Wed, 24 Jun 92 23:23:22 PDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA18038; Thu, 25 Jun 92 15:31:43 +0900 Received: from srarc2.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA17517; Thu, 25 Jun 92 15:31:18 +0900 Received: by srarc2.sra.co.jp (5.61/6.4J.6-SJ) id AA11646; Thu, 25 Jun 92 15:31:32 +0900 Date: Thu, 25 Jun 92 15:31:32 +0900 From: hikichi%srarc2.sra.co.jp@lucid.com (Nobuyuki Hikichi) Return-Path: Message-Id: <9206250631.AA11646@srarc2.sra.co.jp> To: bug-lucid-emacs@lucid.com Subject: lemacs 19.2 for MIPS RISC os Reply-To: hikichi%sra.co.jp@lucid.com I try to port lemacs 19.2 to RISC os 4.52. I modify some files a little as following. I can do startup with following diff. Almost all files are compiled with gcc 2.2.2 -O. Only ``xdisp.c'' cannot be compiled with -O. So I compile it without -O. Also by the way this patch is incorporated with following information too. From: nelson@reed.edu (Nelson Minar) To: bug-lucid-emacs@lucid.com Subject: lemacs on a NeXT Date: Thu, 11 Jun 92 14:28 PDT : : strdup and remainder are also missing from Ultrix libraries. Here's strdup from the GNU libiberty (from gdb) Name: Nobuyuki Hikichi Office: Software Research Associates, Inc. Japan. Thu Jun 25 14:20:18 1992 Gnu is not Unix (gnu at srarc2) * config.h: add the local define for compiling gcc. * ymakefile: delete dependency list in mips. * emacs.c(strdup, putenv): add for pure BSD. #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 06/25/1992 06:22 UTC by gnu@srarc2 # Source directory /tmp # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 2562 -rw-r--r-- RISCos.diff # # ============= RISCos.diff ============== if test -f 'RISCos.diff' -a X"$1" != X"-c"; then echo 'x - skipping RISCos.diff (File already exists)' else echo 'x - extracting RISCos.diff (Text)' sed 's/^X//' << 'SHAR_EOF' > 'RISCos.diff' && diff -rNu3 lemacs-19.2.org/src/config.h lemacs-19.2/src/config.h --- lemacs-19.2.org/src/config.h Fri Jun 19 08:17:19 1992 +++ lemacs-19.2/src/config.h Mon Jun 22 16:25:06 1992 @@ -30,7 +30,7 @@ X the s- files to use for them. See s-template.h for documentation on X writing s- files. X */ -#include "s/s-sunos4.h" +#include "s/s-bsd4-3.h" X X /* Include here a m- file that describes the machine and system you use. X See the file ../etc/MACHINES for a list of machines and the names of @@ -37,7 +37,7 @@ X the m- files to use for them. See m-template.h for info on what m- X files should define. X */ -#include "m/m-sparc.h" +#include "m/m-mips4.h" X X /* Load in the conversion definitions if this system X needs them and the source file being compiled has not @@ -189,6 +189,21 @@ X /* #define C_SWITCH_SITE -I/cadillacgnu/gcc-include -I/x11r4/usr/include */ X X #ifdef USE_GCC + +#ifdef C_DEBUG_SWITCH +#undef C_DEBUG_SWITCH +#endif +#define C_DEBUG_SWITCH -g -O + +#ifdef LIB_STANDARD +#undef LIB_STANDARD +#endif + +#define LIB_STANDARD -lm -lmld \ + '/usr/local/gnu/lib/gcc-lib/mips-mips-bsd/2.2.2/libgcc.a' \ + -lc /lib/crtn.o + + X /* Depending on how GCC is installed, you may need to add the gcc library X here. This could also go in LD_SWITCH_SITE. If you get errors about X __fixunsdfsi or__main being undefined, you probably need to do this. */ diff -rNu3 lemacs-19.2.org/src/emacs.c lemacs-19.2/src/emacs.c --- lemacs-19.2.org/src/emacs.c Tue Jun 16 17:34:58 1992 +++ lemacs-19.2/src/emacs.c Mon Jun 22 15:13:28 1992 @@ -1124,3 +1124,29 @@ X DEFVAR_BOOL ("noninteractive", &noninteractive1, X "Non-nil means Emacs is running without interactive terminal."); X } + +#ifdef BSD +char * +strdup(s) + char *s; +{ + char *result = (char*)malloc(strlen(s) + 1); + if (result == (char*)0) + return (char*)0; + strcpy(result, s); + return result; +} + +putenv(s) + char *s; +{ + char *p; + char name = p; + p = index(s, '='); + p = 0; +#if 0 + setenv (name, p + 1, 1); +#endif + set_environment_alist (name, p+1); +} +#endif diff -rNu3 lemacs-19.2.org/src/ymakefile lemacs-19.2/src/ymakefile --- lemacs-19.2.org/src/ymakefile Fri Jun 19 19:31:43 1992 +++ lemacs-19.2/src/ymakefile Mon Jun 22 15:14:45 1992 @@ -731,8 +731,7 @@ X unexconvex.o: config.h getpagesize.h X unexec.o: config.h getpagesize.h X unexenix.o: config.h -unexmips.o: config.h filehdr.h -unexmips.o: aouthdr.h scnhdr.h sym.h +unexmips.o: config.h X unexsunos4.o: config.h X vm-limit.o: config.h mem_limits.h X vm-limit.o: SHAR_EOF chmod 0644 RISCos.diff || echo 'restore of RISCos.diff failed' Wc_c="`wc -c < 'RISCos.diff'`" test 2562 -eq "$Wc_c" || echo 'RISCos.diff: original size 2562, current size' "$Wc_c" fi exit 0 From bug-lucid-emacs-request@lucid.com Thu Jun 25 02:50:31 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26321; Thu, 25 Jun 92 02:50:31 PDT Received: by heavens-gate.lucid.com id AA03350g; Thu, 25 Jun 92 02:40:55 PDT Received: from cns.caltech.edu (acquine.cns.caltech.edu) by heavens-gate.lucid.com id AA03346g; Thu, 25 Jun 92 02:40:47 PDT Received: from bradbury.cns.caltech.edu by cns.caltech.edu (4.1/1.34) id AA29787; Thu, 25 Jun 92 02:44:52 PDT Date: Thu, 25 Jun 92 02:44:52 PDT From: tromey@cns.caltech.edu (Tom Tromey) Message-Id: <9206250944.AA29787@cns.caltech.edu> Received: by bradbury.cns.caltech.edu (4.1/SMI-4.0) id AA02483; Thu, 25 Jun 92 02:54:01 PDT To: bug-lucid-emacs@lucid.com Subject: Unbalanced parens while reading news X-Zippy: If a person is FAMOUS in this country, they have to go on the ROAD for MONTHS at a time and have their name misspelled on the SIDE of a GREYHOUND SCENICRUISER!! I just tried to read the newsgroup comp.std.c with GNUS in Lucid Emacs. I got an "unbalanced parentheses" error. Here is the backtrace: Signalling: (error "Unbalanced parentheses") scan-sexps(19 1) forward-sexp(1) mail-strip-quoted-names("kanze@us-es.sel.de (James Kanze (R.30)") gnus-optional-lines-and-from([8188 "Re: What C can't do - but I need it to!" "kanze@us-es.sel.de (James Kanze (R.30)" nil 33 "Wed, 24 Jun 92 12:45:22 GMT" "<1992Jun24.124522.25610@us-es.sel.de>" " <11740@inews.intel.com>"]) gnus-Subject-prepare-threads((([8187 "Question about ANSI C function declaration" "anthony@cs.uq.oz.au (Anthony Lee)" nil 51 "24 Jun 92 11:55:58 GMT" "<9100@uqcspe.cs.uq.oz.au>" nil]) ([8188 "Re: What C can't do - but I need it to!" "kanze@us-es.sel.de (James Kanze (R.30)" nil 33 "Wed, 24 Jun 92 12:45:22 GMT" "<1992Jun24.124522.25610@us-es.sel.de>" " <11740@inews.intel.com>"]) ([8189 "Re: ANSI C history.." "ed@pa.dec.com (Ed Gould)" nil 13 "Wed, 24 Jun 92 16:07:12 GMT" "<1992Jun24.160712.3028@PA.dec.com>" " <1992Jun24.060619.20017@PA.dec.com> <1992Jun24.064729.3475@kithrup.COM>"] ([8192 "Re: ANSI C history.." "sef@kithrup.COM (Sean Eric Fagan)" nil 22 "24 Jun 92 20:42:16 GMT" "<1992Jun24.204216.7009@kithrup.COM>" "<1992Jun24.060619.20017@PA.dec.com> <1992Jun24.064729.3475@kithrup.COM> <1992Jun24.160712.3028@PA.dec.com>"])) ([8190 "strong enums (was: What C can't do - but I need it to!)" "karl@ima.isc.com (Karl Heuer! )" nil 46 "24 Jun 92 17:03:32 GMT" "<1992Jun24.170332.16152@ima.isc.com>" " <11740@inews.intel.com> <1992Jun24.124522.25610@us-es.sel.de>"]) ([8191 "Looking for C tutor text files" "herzog@ux6.lbl.gov (Hanan Herzog)" "nntp-server.caltech.edu comp.lang.c:54511 comp.std.c:8191" 19 "24 Jun 92 21:56:44 GMT" "<1992Jun24.215644.24345@overload.lbl.gov>" nil]) ([8193 "Re: ANSI C history.." "dmm@vnet.ibm.com (dave)" nil 35 "Wed, 24 Jun 92 20:36:56 EDT" "<19920624.174232.639@almaden.ibm.com>" " <1992Jun24.060619.20017@PA.dec.com>"])) 0) gnus-Subject-prepare() gnus-Subject-read-group("comp.std.c" nil nil) gnus-Group-read-group(nil) * call-interactively(gnus-Group-read-group) Sorry about the long lines. I guess the guy (James Kanze) does have an bad quoting in his address. But I don't think mail-strip-quoted-names should die if the name is improperly quoted. Tom --- This reporter is tromey@cns.caltech.edu "Totally Objective" "`Nova heat moving in,' dig?" -- Robert Anton Wilson From bug-lucid-emacs-request@lucid.com Thu Jun 25 06:57:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26840; Thu, 25 Jun 92 06:57:35 PDT Received: by heavens-gate.lucid.com id AA03655g; Thu, 25 Jun 92 06:48:01 PDT Received: from bcars520 (x400gate.bnr.ca) by heavens-gate.lucid.com id AA03651g; Thu, 25 Jun 92 06:47:54 PDT X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Jun 1992 09:55:26 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Jun 1992 09:54:35 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Jun 1992 05:54:00 -0400 Date: Thu, 25 Jun 1992 09:54:00 +0000 X400-Originator: /DD.ID=1581776/G=Jeffrey/I=JD/S=Sparkes/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.245:25.05.92.13.54.35] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Re: the (l)em... From: "Jeffrey (J.D.) Sparkes" Message-Id: <"6271 Thu Jun 25 09:55:26 1992"@bnr.ca> To: jwz@thalidomide Cc: bug-lucid-emacs@lucid.com Subject: Re: the (l)emacs info file has problems and there is no source f In message "Re: the (l)emacs info file has problems and there is no source f", '' writes: > >The info node titled "Pull-down Menus" works fine for me in 19.2, what problem >are you seeing? Oops. Appears to be yet another "I accidentally loaded an emacs18 file.." It works fine if I do "lemacs -q". Sorry about that chief. -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Fri Jun 26 04:25:43 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01252; Fri, 26 Jun 92 04:25:43 PDT Received: by heavens-gate.lucid.com id AA06808g; Fri, 26 Jun 92 04:16:03 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA06804g; Fri, 26 Jun 92 04:15:56 PDT Received: by liasg2.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Fri, 26 Jun 92 13:24 MDT Message-Id: Date: Fri, 26 Jun 92 13:24 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Lemacs 19.2: startup.el breaks without CLASH_DETECTION For systems without CLASH_DETECTION defined in the config files, the variable "lock-directory" is unbound in temacs. lisp/prims/startup.el wants to read it and falls over. -- Simon. *** 1.1 1992/06/26 11:20:59 --- lisp/prim/startup.el 1992/06/26 11:23:05 *************** *** 407,413 **** ;; (let ((lisp (find-default-load-path-internal "lisp")) (etc (find-default-load-path-internal "etc")) ! (lock (or lock-directory (find-default-load-path-internal "lock")))) ;;(send-string-to-terminal (concat "lisp: " lisp "\n")) ;;(send-string-to-terminal (concat "etc: " etc "\n")) ;;(send-string-to-terminal (concat "lock: " lock "\n")) --- 407,414 ---- ;; (let ((lisp (find-default-load-path-internal "lisp")) (etc (find-default-load-path-internal "etc")) ! (lock (and (boundp 'lock-directory) ! (or lock-directory (find-default-load-path-internal "lock"))))) ;;(send-string-to-terminal (concat "lisp: " lisp "\n")) ;;(send-string-to-terminal (concat "etc: " etc "\n")) ;;(send-string-to-terminal (concat "lock: " lock "\n")) *************** *** 442,450 **** (if (and (boundp 'Info-directory-list) (null Info-directory-list)) (setq Info-directory-list (list (expand-file-name "../info/" exec-directory)))) ! (setq lock-directory lock) ! (if (and lock-directory (null superlock-path)) ! (setq superlock-path (concat lock-directory "!!!SuperLock!!!"))) (set-default-load-path-warning))) --- 443,453 ---- (if (and (boundp 'Info-directory-list) (null Info-directory-list)) (setq Info-directory-list (list (expand-file-name "../info/" exec-directory)))) ! (if (boundp 'lock-directory) ! (progn ! (setq lock-directory lock) ! (if (and lock-directory (null superlock-path)) ! (setq superlock-path (concat lock-directory "!!!SuperLock!!!"))))) (set-default-load-path-warning))) From bug-lucid-emacs-request@lucid.com Fri Jun 26 04:32:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01266; Fri, 26 Jun 92 04:32:59 PDT Received: by heavens-gate.lucid.com id AA06815g; Fri, 26 Jun 92 04:21:54 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA06811g; Fri, 26 Jun 92 04:21:47 PDT Received: by liasg2.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Fri, 26 Jun 92 13:30 MDT Message-Id: Date: Fri, 26 Jun 92 13:30 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Success! Lemacs 19.2 running on IRIX 4.0.4 8-) 8-) 8-) Hehe, this message has been posted from an SGI Indigo running Lemacs. I had to modify a couple of files, but this gave me the opportunity to integrate some Gnumacs 18.58 improvements, which I will wrap up after Lunch. See you, -- Simon. From bug-lucid-emacs-request@lucid.com Fri Jun 26 07:01:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01670; Fri, 26 Jun 92 07:01:01 PDT Received: by heavens-gate.lucid.com id AA07026g; Fri, 26 Jun 92 06:51:19 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA07022g; Fri, 26 Jun 92 06:51:09 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Fri, 26 Jun 92 15:59 MDT Message-Id: Date: Fri, 26 Jun 92 15:59 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Lemacs 19.2: src/ymakefile There are too many dependencies for unexmips.o -- filehdr.h and friends are (MIPS/USG specific) header files in /usr/include. -- Simon. *** 1.1 1992/06/26 13:36:00 --- src/ymakefile 1992/06/26 13:36:12 *************** *** 731,738 **** unexconvex.o: config.h getpagesize.h unexec.o: config.h getpagesize.h unexenix.o: config.h ! unexmips.o: config.h filehdr.h ! unexmips.o: aouthdr.h scnhdr.h sym.h unexsunos4.o: config.h vm-limit.o: config.h mem_limits.h vm-limit.o: --- 731,737 ---- unexconvex.o: config.h getpagesize.h unexec.o: config.h getpagesize.h unexenix.o: config.h ! unexmips.o: config.h unexsunos4.o: config.h vm-limit.o: config.h mem_limits.h vm-limit.o: From bug-lucid-emacs-request@lucid.com Fri Jun 26 08:52:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01966; Fri, 26 Jun 92 08:52:12 PDT Received: by heavens-gate.lucid.com id AA07361g; Fri, 26 Jun 92 08:42:30 PDT Received: from srv01s4.cas.org by heavens-gate.lucid.com id AA07355g; Fri, 26 Jun 92 08:42:20 PDT Date: Fri, 26 Jun 92 11:51:05 EDT From: wxj23@cas.org Message-Id: <9206261551.AA13163@cas.org> To: bug-lucid-emacs@lucid.com Subject: Failing to make 'temacs' executable I'm trying to make emacs on a Sun 4/690 running SUNOS 4.1.2. I'm having the following difficulty with the load: make -f xmakefile ld -e __start -Bstatic -L/usr1/gnu/lib -L/usr3/x11r5/install/lib -L. -L./lwlib -o temacs crt0.o dispnew.o screen.o scroll.o xdisp.o window.o events.o event-alloc.o event-stream.o term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexec.o mocklisp.o bytecode.o process.o callproc.o environ.o doprnt.o extents.o faces.o elhash.o hash.o tparam.o lastfile.o gmalloc.o vm-limit.o ScreenWidget.o ColumnWidget.o EmacsShell.o sunOS-fix.o -llw -lXaw -lXext -lXt -lXmu -lX11 -ltermcap -lg -lm -lc ld: Undefined symbol *** Error code 2 make: Fatal error: Command failed for target `temacs' Current working directory /usr1/emacs-19.1/lemacs-19.1/src *** Error code 1 make: Fatal error: Command failed for target `doall' res04s4: Wayne Johnson Chemical Abstracts Service From bug-lucid-emacs-request@lucid.com Sat Jun 27 05:46:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06303; Sat, 27 Jun 92 05:46:50 PDT Received: by heavens-gate.lucid.com id AA10046g; Sat, 27 Jun 92 05:34:30 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA10042g; Sat, 27 Jun 92 05:34:22 PDT Received: by liasg2.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Sat, 27 Jun 92 14:43 MDT Message-Id: Date: Sat, 27 Jun 92 14:43 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Proposal for additional default keybindings (Meta-) Under previous versions of Emacs I could exploit the fact that Meta-Right was equivalent to C-M-f and so on, and always used the arrow keys with Meta to navigate in terms of sexps. In order to restore this functionality in Lemacs 19, I've put (define-key global-map '(meta right) 'forward-sexp) (define-key global-map '(meta left) 'backward-sexp) (define-key global-map '(meta up) 'backward-up-list) (define-key global-map '(meta down) 'down-list) in my .emacs file. Maybe this should be done by default? -- Simon. From bug-lucid-emacs-request@lucid.com Mon Jun 29 10:46:47 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00456; Mon, 29 Jun 92 10:46:47 PDT Received: by heavens-gate.lucid.com id AA12639g; Mon, 29 Jun 92 06:13:46 PDT Received: from srv01s4.cas.org by heavens-gate.lucid.com id AA12635g; Mon, 29 Jun 92 06:13:40 PDT Date: Mon, 29 Jun 92 09:21:47 EDT From: wxj23@cas.org Message-Id: <9206291321.AA18043@cas.org> To: bug-lucid-emacs@lucid.com Subject: Incorrect documentation in Ilisp One of the files which ilisp expects is completion.el. This file is missing from my ilisp directory and I presume the command (initialize-completions) which won't load is in it. The documentation in ilisp.el and ilisp.emacs should be updated if these are no longer used. Thanks, Wayne Johnson From bug-lucid-emacs-request@lucid.com Mon Jun 29 10:47:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00460; Mon, 29 Jun 92 10:47:14 PDT Received: by heavens-gate.lucid.com id AA12623g; Mon, 29 Jun 92 05:58:00 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA12619g; Mon, 29 Jun 92 05:57:47 PDT Received: by moebius.loria.fr id AA03564 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Mon, 29 Jun 92 15:05:08 +0200 Date: Mon, 29 Jun 92 15:05:08 +0200 From: Guido Bosch Message-Id: <9206291305.AA03564@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: incompatibility with new popup menu format Reply-To: Guido BOSCH In Lucid Emacs 19.2 you altered the data format for popup-menus. They now only accept strings as the first item in the menu description. The popup-menu of info.el must be fixed up for this: *** lisp/packages/info.el~ Tue May 19 22:03:10 1992 --- lisp/packages/info.el Mon Jun 29 14:47:54 1992 *************** *** 902,908 **** (if (looking-at ".*\\bNext:") (setq next-p t)) (if (looking-at ".*\\bPrev:") (setq prev-p t)) (if (looking-at ".*Up:") (setq up-p t)) ! (setq menu (nconc (list nil "Info Commands:" "----") (if (setq in (Info-indicated-node event)) (list (vector (car (cdr in)) in t))) (list --- 902,908 ---- (if (looking-at ".*\\bNext:") (setq next-p t)) (if (looking-at ".*\\bPrev:") (setq prev-p t)) (if (looking-at ".*Up:") (setq up-p t)) ! (setq menu (nconc (list "Info" "Info Commands:" "----") (if (setq in (Info-indicated-node event)) (list (vector (car (cdr in)) in t))) (list From bug-lucid-emacs-request@lucid.com Mon Jun 29 10:47:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00464; Mon, 29 Jun 92 10:47:30 PDT Received: by heavens-gate.lucid.com id AA12401g; Mon, 29 Jun 92 02:18:58 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA12397g; Mon, 29 Jun 92 02:18:34 PDT Received: by moebius.loria.fr id AA02069 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Mon, 29 Jun 92 11:26:01 +0200 Date: Mon, 29 Jun 92 11:26:01 +0200 From: Guido Bosch Message-Id: <9206290926.AA02069@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: multimedia include files missing Reply-To: Guido BOSCH While compiling Lucid Emacs 19.2 using make from the lemacs-19.2 main directory on a Sparc station 2, with SUN OS 4.1.1: % make cd etc; make all cd src; make all make -f xmakefile all gcc -c -g -Demacs -I./lwlib -I/usr/demo/SOUND play.c In file included from play.c:19: libsst.h:18: multimedia/libaudio.h: No such file or directory libsst.h:19: multimedia/audio_device.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `play.o' Current working directory /local/moebius1/gnu/lemacs-19.2/src *** Error code 1 make: Fatal error: Command failed for target `doall' Current working directory /local/moebius1/gnu/lemacs-19.2/src *** Error code 1 make: Fatal error: Command failed for target `src' Seems that there are some include files missing in my UNIX environment. Where should be the "multimedia" directory and what should be in it? Guido From bug-lucid-emacs-request@lucid.com Mon Jun 29 10:47:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00469; Mon, 29 Jun 92 10:47:41 PDT Received: by heavens-gate.lucid.com id AA12417g; Mon, 29 Jun 92 02:29:21 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12413g; Mon, 29 Jun 92 02:29:15 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA07769; Mon, 29 Jun 92 02:38:19 PDT Date: Mon, 29 Jun 92 02:38:19 PDT Message-Id: <9206290938.AA07769@thalidomide.lucid> X-Windows: A moment of convenience, a lifetime of regret. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Guido BOSCH Cc: bug-lucid-emacs@lucid.com Subject: Re: multimedia include files missing In-Reply-To: Guido Bosch's message of Mon 29-Jun-92 11:26:01 +0200 <9206290926.AA02069@moebius.loria.fr> References: <9206290926.AA02069@moebius.loria.fr> I think it should be /usr/demo/SOUND/multimedia/, if you have the "sound" option installed. If there's a more definitive place for this, someone let me know. You can get around this by removing the define of USE_SPARC_SOUND in config.h, but then you won't be able to use sound files as beeps. -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jun 29 10:56:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00503; Mon, 29 Jun 92 10:56:57 PDT Received: by heavens-gate.lucid.com id AA13285g; Mon, 29 Jun 92 10:48:31 PDT Received: from uucp-gw-1.pa.dec.com by heavens-gate.lucid.com id AA13275g; Mon, 29 Jun 92 10:47:40 PDT Received: by uucp-gw-1.pa.dec.com; id AA00277; Mon, 29 Jun 92 10:50:07 -0700 Received: by wsrcc.com id AA09352 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Mon, 29 Jun 1992 10:38:51 -0700 Message-Id: <199206291738.AA09352@wsrcc.com> Received: from USENET by wsrcc.com with netnewsfor bug-lucid-emacs@lucid.com (bug-lucid-emacs@lucid.com);contact usenet@wsrcc.com if you have questions. To: bug-lucid-emacs@lucid.com Date: Mon, 29 Jun 1992 17:38:44 GMT From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Organization: W S Rupprecht Computer Consulting, Fremont CA References: , <9206290926.AA02069@moebius.loria.fr> Subject: Re: multimedia include files missing Guido.Bosch@loria.fr (Guido Bosch) writes: >While compiling Lucid Emacs 19.2 using make from the lemacs-19.2 main >directory on a Sparc station 2, with SUN OS 4.1.1: > gcc -c -g -Demacs -I./lwlib -I/usr/demo/SOUND play.c > libsst.h:18: multimedia/libaudio.h: No such file or directory > libsst.h:19: multimedia/audio_device.h: No such file or directory This is a bug in gcc's fixincludes. You have to go into the gcc include directory (probably /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia) and make a symlink from libaudio.h and audio_device.h to /usr/include/multimedia. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Mon Jun 29 15:34:51 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02191; Mon, 29 Jun 92 15:34:51 PDT Received: by heavens-gate.lucid.com id AA14267g; Mon, 29 Jun 92 15:26:11 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA14263g; Mon, 29 Jun 92 15:26:04 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22663; Mon, 29 Jun 92 18:34:48 -0400 Received: from cirdan.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA12649; Mon, 29 Jun 92 15:34:48 PDT Date: Mon, 29 Jun 92 15:34:47 PDT Message-Id: <9206292234.AA12649@cygnus.com> Received: by cirdan.cygnus.com (4.1/SMI-4.1) id AA22432; Mon, 29 Jun 92 15:34:47 PDT From: david d `zoo' zuhn Sender: zoo@cygnus.com Organization: Cygnus Support -- +1 415 322 3811 To: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Cc: bug-lucid-emacs@lucid.com In-Reply-To: wolfgang@wsrcc.com's message of Mon, 29 Jun 1992 17:38:44 GMT Subject: Re: multimedia include files missing X-Windows: Warn your friends about it. This is a bug in gcc's fixincludes. Huh? I doubt it. You have to go into the gcc include directory (probably /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia) and make a symlink from libaudio.h and audio_device.h to /usr/include/multimedia. This is redundant. GCC searches /usr/include after it searches its own private include directory. The only files in gcc-lib/.../include are either GCC specific (varargs.h etc) or 'fixed' versions of /usr/include. There should never be a symlink in gcc-lib/.../include. The problem is much more likely that the optional sound software isn't installed. david d 'zoo' zuhn | cygnus support | "Man made it, man can fix it." zoo@cygnus.com | -- anonymous biker in South Dakota From bug-lucid-emacs-request@lucid.com Mon Jun 29 16:37:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02295; Mon, 29 Jun 92 16:37:54 PDT Received: by heavens-gate.lucid.com id AA14436g; Mon, 29 Jun 92 16:29:00 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA14432g; Mon, 29 Jun 92 16:28:54 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.19) id AA00555; Mon, 29 Jun 92 16:37:46 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA22033; Mon, 29 Jun 92 16:36:18 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA25571; Mon, 29 Jun 92 16:36:16 PDT Date: Mon, 29 Jun 92 16:36:16 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9206292336.AA25571@farside.twinsun.com> To: zoo@cygnus.com Cc: bug-lucid-emacs@lucid.com In-Reply-To: david d `zoo' zuhn's message of Mon, 29 Jun 92 15:34:47 PDT <9206292234.AA12649@cygnus.com> Subject: multimedia include files missing Date: Mon, 29 Jun 92 15:34:47 PDT From: david d `zoo' zuhn The only files in gcc-lib/.../include are either GCC specific (varargs.h etc) or 'fixed' versions of /usr/include. There should never be a symlink in gcc-lib/.../include. No, fixincludes creates creates symbolic links, because sometimes it must fix linked-to files. Look in fixincludes, under ``Making internal symbolic directory links'' and ``Making internal symbolic non-directory links''. From bug-lucid-emacs-request@lucid.com Mon Jun 29 18:21:56 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02493; Mon, 29 Jun 92 18:21:56 PDT Received: by heavens-gate.lucid.com id AA14770g; Mon, 29 Jun 92 18:12:23 PDT Received: from uucp-gw-1.pa.dec.com by heavens-gate.lucid.com id AA14762g; Mon, 29 Jun 92 18:11:27 PDT Received: by uucp-gw-1.pa.dec.com; id AA14170; Mon, 29 Jun 92 18:13:25 -0700 Received: by wsrcc.com id AA10919 (5.65c/IDA-1.4.4-WSR-06/19/92); Mon, 29 Jun 1992 17:20:12 -0700 Date: Mon, 29 Jun 1992 17:20:12 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199206300020.AA10919@wsrcc.com> To: david d `zoo' zuhn Cc: bug-lucid-emacs@lucid.com, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Subject: Re: multimedia include files missing In-Reply-To: <9206292234.AA12649@cygnus.com> References: <9206292234.AA12649@cygnus.com> Organization: W S Rupprecht Computer Consulting, Fremont CA > Huh? I doubt it. > > You have to go into the gcc include directory (probably > /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia) and make a > symlink from libaudio.h and audio_device.h to /usr/include/multimedia. > > This is redundant. GCC searches /usr/include after it searches its > own private include directory. The only files in gcc-lib/.../include > are either GCC specific (varargs.h etc) or 'fixed' versions of > /usr/include. There should never be a symlink in gcc-lib/.../include. > > The problem is much more likely that the optional sound software isn't > installed. Sigh, I just double checked my notes and the missing symlinks are for audio_errno.h and audio_hdr.h in the multimedia include directory. The files libaudio.h and audio_device.h should be found normally. Perhaps things are changed under SunOS > 4.1 but under 4.1 the multimedia/libaudio.h include file tries to include two other include files in the current directory with the "file.h" directive. Since the multimedia directory is off the beaten include path those two other files won't be found without the symlinks in place. From /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia/libaudio.h: /* @(#)libaudio.h 1.2 90/01/03 SMI */ /* Copyright (c) 1989 by Sun Microsystems, Inc. */ #ifndef _multimedia_libaudio_h #define _multimedia_libaudio_h #include "audio_errno.h" #include "audio_hdr.h" [...] There is no include file audio_errno.h in the current gcc include directory or on the include path. One must symlink /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia/audio_errno.h from /usr/include/multimedia/audio_errno.h. Ditto for "audio_hdr.h". Alternately fixincludes could change: #incldue "audio_errno.h" -> #include #include "audio_audio.h" -> #include -wolfgang --- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Tue Jun 30 00:08:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03264; Tue, 30 Jun 92 00:08:46 PDT Received: by heavens-gate.lucid.com id AA15498g; Mon, 29 Jun 92 23:58:55 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA15494g; Mon, 29 Jun 92 23:58:43 PDT Received: by moebius.loria.fr id AA04754 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Tue, 30 Jun 92 09:06:16 +0200 Date: Tue, 30 Jun 92 09:06:16 +0200 From: Guido Bosch Message-Id: <9206300706.AA04754@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: Re: multimedia include files missing In-Reply-To: <9206292234.AA12649@cygnus.com> References: <9206292234.AA12649@cygnus.com> Reply-To: Guido BOSCH david d `zoo' zuhn writes: > Huh? I doubt it. > > You have to go into the gcc include directory (probably > /usr/local/lib/gcc-lib/sun4/2.2.2/include/multimedia) and make a > symlink from libaudio.h and audio_device.h to /usr/include/multimedia. > > This is redundant. GCC searches /usr/include after it searches its > own private include directory. The only files in gcc-lib/.../include > are either GCC specific (varargs.h etc) or 'fixed' versions of > /usr/include. There should never be a symlink in gcc-lib/.../include. > > The problem is much more likely that the optional sound software isn't > installed. > Bingo, that was it. My system engeneer told me that the multimedia files are not installed on every station of our network. He put it on my sun (/usr/demo/SOUND/multimedia/) and compiling works fine now. Thanks for the hint. Guido From bug-lucid-emacs-request@lucid.com Tue Jun 30 06:17:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04713; Tue, 30 Jun 92 06:17:12 PDT Received: by heavens-gate.lucid.com id AA15994g; Tue, 30 Jun 92 06:08:40 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA15990g; Tue, 30 Jun 92 06:08:26 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA03535; Tue, 30 Jun 1992 15:16:58 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA01273; Tue, 30 Jun 92 15:20:41 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA01910; Tue, 30 Jun 92 15:12:56 +0200 Date: Tue, 30 Jun 92 15:12:56 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9206301312.AA01910@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02034; Tue, 30 Jun 92 15:12:57 +0200 To: Bug Lucid Emacs Subject: endless loop with debugger The following sequence of actions causes emacs to enter an endless loop: shell> xemacs -q ;; In the *scratch* buffer, set debug-on-error: (setq debug-on-error t) C-x C-e ;; Create a new screen: C-x 5 ;; In this screen, starts a command which uses the minibuffer, for instance, ;; find-file: C-x f ;; With the mouse pointer, choose delete-screen in the file menu: ;; In the first screen, the minibuffer displays 'find file: ~/', and the ;; point is in the scratch buffer. Move it in the minibuffer: C-x o ;; Cancel the find-file command: C-g Emacs then displays 'Entering debugger...' and eats cpu doing nothing. There is no way to stop it except to send it a SIGKILL. A SIGQUIT (3) is acknowledge (emacs prints 'Fatal error (3).') but don't stop. If debug-on-error is nil, xemacs displays instead: Cannot set-window-configuration for a deleted screen Configuration: - lucid emacs 19.2 - compiled with gcc 2.2.1 -O2 - on a SPARCstation 2, sunos 4.1.1 (using s/s-sunos4.h) Phil From bug-lucid-emacs-request@lucid.com Wed Jul 1 18:37:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12065; Wed, 1 Jul 92 18:37:22 PDT Received: by heavens-gate.lucid.com id AA21593g; Wed, 1 Jul 92 18:27:51 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA21589g; Wed, 1 Jul 92 18:27:43 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA16655; Wed, 1 Jul 92 18:36:48 PDT Date: Wed, 1 Jul 92 18:36:48 PDT Message-Id: <9207020136.AA16655@thalidomide.lucid> X-Windows: A moment of convenience, a lifetime of regret. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bug-lucid-emacs@lucid.com Subject: Lucid Emacs newsgroups Thanks to Kyle Jones, we now have a pair of newsgroups bidirectionally gatewayed into the bug-lucid-emacs and help-lucid-emacs newsgroups. They are alt.lucid-emacs.bug and alt.lucid-emacs.help. I expect that many of you will want to unsubscribe from the mailing lists, and read the messages in newsgroup form instead. However, I would advise you to wait a few weeks before unsubscribing, so that we know that the gateway is functioning properly. We wanted the newsgroups to be gnu.lucid-emacs.bug and gnu.lucid-emacs.help, but the FSF folks are not willing to allow the creation of those groups. In fact, it would appear that they are unwilling even to allow us to announce the existence of our version of emacs on their newsgroups. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Jul 2 09:12:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15413; Thu, 2 Jul 92 09:12:41 PDT Received: by heavens-gate.lucid.com id AA23172g; Thu, 2 Jul 92 09:03:54 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA23168g; Thu, 2 Jul 92 09:03:34 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA01901; Thu, 2 Jul 1992 18:12:19 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA04964; Thu, 2 Jul 92 18:16:07 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA05499; Thu, 2 Jul 92 18:08:09 +0200 Date: Thu, 2 Jul 92 18:08:09 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9207021608.AA05499@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02500; Thu, 2 Jul 92 18:08:10 +0200 To: Bug Lucid Emacs Subject: A few bugs in diff-mode This patch corrects the following bugs in the diff-mode: - add a binding for bury-buffer on `q' (I think all temporary buffers as *completion*, *Help*... should have this binding). - diff was erroneously setting the buffer-read-only to nil. I really don't understand why it was doing such a thing... - if there was only one difference, an error regarding a not-found regexp was generated (diff tried to find the next difference boundary to narrow the visible region). Phil PS: is this file maintained by Lucid, or by someone else who should receive this patch? The only information is: "Written sunpitt!wpmstr!fbresz@Sun.COM 1/27/89", which is both 1/ old, and 2/ a funny address (I thought Sun had a better mailing configuration :-)). --- packages/diff.el.old Sat Apr 25 01:36:50 1992 +++ packages/diff.el Thu Jul 2 17:55:54 1992 @@ -48,4 +48,5 @@ (define-key diff-mode-map "n" 'diff-next-difference) (define-key diff-mode-map "p" 'diff-previous-difference) + (define-key diff-mode-map "q" 'bury-buffer) (define-key diff-mode-map "j" 'diff-show-difference)) @@ -76,6 +77,5 @@ (setq new (expand-file-name new) old (expand-file-name old)) - (let ((buffer-read-only nil) - (sw diff-switches)) + (let ((sw diff-switches)) (with-output-to-temp-buffer "*Diff Output*" (buffer-disable-undo standard-output) @@ -95,8 +95,9 @@ (if (string= "0" diff-total-differences) (insert (message "There are no differences.")) - (narrow-to-region (point) (progn - (forward-line 1) - (re-search-forward diff-search-pattern nil) - (goto-char (match-beginning 0)))) + (or (string= "1" diff-total-differences) + (narrow-to-region (point) (progn + (forward-line 1) + (re-search-forward diff-search-pattern nil) + (goto-char (match-beginning 0))))) (setq diff-current-difference "1"))) @@ -163,8 +164,9 @@ (message "No previous differences.") (setq diff-current-difference "1")) - (narrow-to-region (point) (progn - (forward-line 1) - (re-search-forward diff-search-pattern nil) - (goto-char (match-beginning 0)))) + (or (string= "1" diff-total-differences) + (narrow-to-region (point) (progn + (forward-line 1) + (re-search-forward diff-search-pattern nil) + (goto-char (match-beginning 0))))) (goto-char (point-min))))) From bug-lucid-emacs-request@lucid.com Thu Jul 2 13:19:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16335; Thu, 2 Jul 92 13:19:28 PDT Received: by heavens-gate.lucid.com id AA23868g; Thu, 2 Jul 92 13:10:36 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA23861g; Thu, 2 Jul 92 13:09:54 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA17179; Thu, 2 Jul 92 13:18:58 PDT Date: Thu, 2 Jul 92 13:18:58 PDT Message-Id: <9207022018.AA17179@thalidomide.lucid> X-Windows: No hardware is safe. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Cc: Bug Lucid Emacs Subject: Re: A few bugs in diff-mode In-Reply-To: Philippe Queinnec's message of Thu 2-Jul-92 18:08:09 +0200 <9207021608.AA05499@geant.cenatls.cena.dgac.fr> References: <9207021608.AA05499@geant.cenatls.cena.dgac.fr> In message <9207021608.AA05499@geant.cenatls.cena.dgac.fr> Philippe Queinnec wrote: > > PS: is this file maintained by Lucid, or by someone else who should > receive this patch? That file is in the FSF's v19 sources; other than that, I don't know its geneology. But we're interested in getting bug fixes to all of the code that we distribute, regardless of the original author. -- Jamie From bug-lucid-emacs-request@lucid.com Fri Jul 3 04:53:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19407; Fri, 3 Jul 92 04:53:37 PDT Received: by heavens-gate.lucid.com id AA25964g; Fri, 3 Jul 92 04:43:21 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA25960g; Fri, 3 Jul 92 04:43:06 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05020; Fri, 3 Jul 92 07:52:08 -0400 Received: from jclark.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 075156.24723; Fri, 3 Jul 1992 07:51:56 EDT Received: by jclark.com (4.1/SMI-4.1) id AA12521; Fri, 3 Jul 92 12:41:18 BST Date: Fri, 3 Jul 92 12:41:18 BST From: jjc@jclark.com (James Clark) Message-Id: <9207031141.AA12521@jclark.com> To: bug-lucid-emacs@lucid.com Subject: Info-select-node-menu When I press the right mouse button in Info mode, I get the following error: Signalling: (wrong-type-argument stringp nil) popup-menu((nil "Info Commands:" "----" ["Goto Info Top-level" Info-directory t] ["Next Node" Info-next nil] ["Previous Node" Info-prev nil] ["Parent Node (Up)" Info-up nil] ["Goto Node..." Info-goto-node t] ["Goto Last Visited Node" Info-last t] "----" "Sub-Nodes:" "----" ["Info" (Info-menu "Info") t] ["Emacs" (Info-menu "Emacs") t] ["Dired" (Info-menu "Dired") t] ["Ange-FTP" (Info-menu "Ange-FTP") t] ["GNUS" (Info-menu "GNUS") t] ["View Mail" (Info-menu "View Mail") t] ["Calendar" (Info-menu "Calendar") t] ["Edebug" (Info-menu "Edebug") t] ["Lispref" (Info-menu "Lispref") t] ["ILISP" (Info-menu "ILISP") t] ["GDB" (Info-menu "GDB") t] ["Texinfo" (Info-menu "Texinfo") t] ["Tar" (Info-menu "Tar") t] ["Finger" (Info-menu "Finger") t] ["Regex" (Info-menu "Regex") t] ["Termcap" (Info-menu "Termcap") t])) Info-select-node-menu(#) * call-interactively(Info-select-node-menu) This seems to cure it: *** info.el.~1~ Tue May 19 21:03:10 1992 --- info.el Fri Jul 3 12:36:53 1992 *************** *** 902,908 **** (if (looking-at ".*\\bNext:") (setq next-p t)) (if (looking-at ".*\\bPrev:") (setq prev-p t)) (if (looking-at ".*Up:") (setq up-p t)) ! (setq menu (nconc (list nil "Info Commands:" "----") (if (setq in (Info-indicated-node event)) (list (vector (car (cdr in)) in t))) (list --- 902,908 ---- (if (looking-at ".*\\bNext:") (setq next-p t)) (if (looking-at ".*\\bPrev:") (setq prev-p t)) (if (looking-at ".*Up:") (setq up-p t)) ! (setq menu (nconc (list "Info" "Info Commands:" "----") (if (setq in (Info-indicated-node event)) (list (vector (car (cdr in)) in t))) (list James Clark jjc@jclark.com From bug-lucid-emacs-request@lucid.com Fri Jul 3 05:31:40 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19525; Fri, 3 Jul 92 05:31:40 PDT Received: by heavens-gate.lucid.com id AA26002g; Fri, 3 Jul 92 05:23:01 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA25998g; Fri, 3 Jul 92 05:22:43 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA25049; Fri, 3 Jul 1992 14:31:07 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA23727; Fri, 3 Jul 92 14:34:34 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA10283; Fri, 3 Jul 92 14:26:31 +0200 Date: Fri, 3 Jul 92 14:26:31 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9207031226.AA10283@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA01389; Fri, 3 Jul 92 14:26:33 +0200 To: Bug Lucid Emacs Subject: undo don't reset the modified flag after capitalization functions [ I resubmit it, as it still happens with 19.2. ] Load a standard text file, do a M-c (M-x capitalize-word), then C-x u. The capitalization is undone, but the modified flag stays. The same thing happens with upcase-word, downcase-word, upcase-region and friends. Phil From bug-lucid-emacs-request@lucid.com Fri Jul 3 05:43:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19572; Fri, 3 Jul 92 05:43:19 PDT Received: by heavens-gate.lucid.com id AA26029g; Fri, 3 Jul 92 05:34:36 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA26025g; Fri, 3 Jul 92 05:34:16 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Fri, 3 Jul 92 14:43 MDT Message-Id: Date: Fri, 3 Jul 92 14:43 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Lemacs 19.2 audio support for SGI machines Hi, here is an implementation of sound using IRIX' audio library. It should even handle interrupts that occur while a sound is played, and tries to be a good citizen by reverting the audio port's volume etc. after it's done. Now someone should write a VM extension that recognizes the MIME format and presents rich-text bodyparts using faces and audio insets using `play-sound'... And what's sorely missing in Lemacs is the capability to make noises at a particular place on the screen, which could be implemented using stereophonic sound. :-) To enable it on the SGI after applying the patch to the src/ subdirectory of the Lemacs sources, simply define USE_SPARC_SOUND in the config file. The ymakefile part of the patch may be rejected because I had to change the ymakefile a bit to work under IRIX. Have fun, -- Simon. *** /dev/null Fri Jul 3 14:32:15 1992 --- sgiplay.c Fri Jul 3 14:28:15 1992 *************** *** 0 **** --- 1,237 ---- + /* Play ULAW sound using the SGI audio library + Copyright (C) 1992 Free Software Foundation, Inc. + + This file is part of GNU Emacs. + + GNU Emacs is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GNU Emacs is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU Emacs; see the file COPYING. If not, write to + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ + + #include "config.h" + #include "lisp.h" + + #include + #include + #include + #include + #include + #include "libst.h" + #include + + /* Exports + + all compilers on machines that have the SGI audio library + understand prototypes, right? */ + + extern void play_sound_file (const char *, int); + extern void play_sound_data (const unsigned char *, int, int); + + /* Forward declarations */ + + static int initialize_audio_port (int); + static void close_sound_file (Lisp_Object); + static void restore_audio_port (Lisp_Object); + static int open_audio_port (int); + static int adjust_audio_volume (int, int); + static void get_current_volumes (int *, int *); + + /* Imports */ + + extern void report_file_error (char *, Lisp_Object); + + static ALport audio_output = (ALport) 0; + + /* the play routine can be interrupted between chunks, so we choose a + small chunksize to keep the system responsive (2000 samples + correspond to a quarter of a second */ + #define CHUNKSIZE 2000 + + /* the sampling rate should really be read from the header portion of + the audio file. For now we fix it at 8000/s because that's the + most common format. */ + #define OUTPUT_SAMPLING_RATE AL_RATE_8000 + + /* are we looking at an "audio data" header? */ + #define LOOKING_AT_HEADER_P(address) \ + (!strncmp(".snd", (char *)(address), 4)) + + /* size of the header to skip in this case */ + #define HEADERSIZE 32 + + static void + close_sound_file (closure) + Lisp_Object closure; + { + close (XFASTINT (closure)); + } + + void + play_sound_file (sound_file, volume) + const char * sound_file; + int volume; + { + int count = specpdl_ptr - specpdl; + int input_fd; + unsigned char buffer[CHUNKSIZE]; + int bytes_read; + + input_fd = open (sound_file, O_RDONLY); + if (input_fd == -1) + /* no error message -- this can't happen + because Fplay_sound_file has checked the + file for us. */ + return; + + record_unwind_protect (close_sound_file, make_number (input_fd)); + + while ((bytes_read = read (input_fd, buffer, CHUNKSIZE)) > 0) + play_sound_data (buffer, bytes_read, volume); + unbind_to (count); + } + + static long + savestate[] = { + AL_OUTPUT_RATE, 0, + AL_LEFT_SPEAKER_GAIN, 0, + AL_RIGHT_SPEAKER_GAIN, 0, + }; + + static void + restore_audio_port (closure) + Lisp_Object closure; + { + Lisp_Object * contents = (XVECTOR (closure))->contents; + savestate[1] = XFASTINT (contents[0]); + savestate[3] = XFASTINT (contents[1]); + savestate[5] = XFASTINT (contents[2]); + ALsetparams (AL_DEFAULT_DEVICE, savestate, 6); + } + + void + play_sound_data (data, length, volume) + const unsigned char * data; + int length; + int volume; + { + short obuf[CHUNKSIZE], *bufp; + int count = specpdl_ptr - specpdl; + int i; + Lisp_Object audio_port_state[3]; + + /* Make sure that the audio port is reset to + its initial characteristics after exit */ + ALgetparams (AL_DEFAULT_DEVICE, savestate, + sizeof (savestate) / sizeof (long)); + audio_port_state[0] = make_number (savestate[1]); + audio_port_state[1] = make_number (savestate[3]); + audio_port_state[2] = make_number (savestate[5]); + record_unwind_protect (restore_audio_port, Fvector (3, &audio_port_state[0])); + + initialize_audio_port (volume); + + if (LOOKING_AT_HEADER_P (data)) + { + data += HEADERSIZE; + length -= HEADERSIZE; + } + while (length > 0) + { + QUIT; + for (i = HEADERSIZE, bufp = &obuf[0]; i < CHUNKSIZE && i < length; ++i) + *bufp++ = st_ulaw_to_linear (*data++); + while (ALgetfilled (audio_output) > 0) + { + sginap (1); + QUIT; + } + ALwritesamps (audio_output, obuf, (long) i-32); + length -= i; + } + unbind_to (count); + } + + static int + initialize_audio_port (volume) + int volume; + { + int current_vol_left, current_vol_right; + + volume = volume * 256 / 100; + if (audio_output==(ALport) 0) + { + if (open_audio_port (volume)==-1) + { + report_file_error ("Open audio port", Qnil); + return -1; + } + } + get_current_volumes (& current_vol_left, & current_vol_right); + if (current_vol_left != volume || current_vol_right != volume) + { + if (adjust_audio_volume (volume, volume)==-1) + { + report_file_error ("Adjust volume", + Fcons (make_number (volume), Qnil)); + return -1; + } + } + return 0; + } + + static int + open_audio_port (volume) + int volume; + { + ALconfig config = ALnewconfig(); + long params[2]; + + adjust_audio_volume (volume, volume); + params[0] = AL_OUTPUT_RATE; params[1] = OUTPUT_SAMPLING_RATE; + ALsetparams (AL_DEFAULT_DEVICE, params, 2); + + ALsetchannels (config, AL_MONO); + ALsetwidth (config, AL_SAMPLE_16); + ALsetqueuesize (config, (long) CHUNKSIZE); + audio_output = ALopenport("Lemacs audio output", "w", config); + ALfreeconfig (config); + if (audio_output==0) + { + report_file_error ("Opening audio output port", Qnil); + return -1; + } + return 0; + } + + static int + adjust_audio_volume (left, right) + int left, right; + { + long params[4] = { + AL_LEFT_SPEAKER_GAIN, 0, + AL_RIGHT_SPEAKER_GAIN, 0 + }; + params[1] = left; + params[3] = right; + ALsetparams (AL_DEFAULT_DEVICE, params, 4); + return 0; + } + + static void + get_current_volumes (int * left, int * right) + { + long params[4] = { AL_LEFT_SPEAKER_GAIN, 0, + AL_RIGHT_SPEAKER_GAIN, 0 }; + ALgetparams (AL_DEFAULT_DEVICE, params, 4); + * left = params[1]; + * right = params[3]; + } *** 1.1 1992/06/26 13:36:00 --- ymakefile 1992/07/03 10:41:41 *************** *** 192,201 **** --- 192,209 ---- correct version for use in Emacs. */ #ifdef USE_SPARC_SOUND + #ifdef sparc # define SOUND_LIBS -L/usr/demo/SOUND -laudio # define SOUND_CFLAGS -I/usr/demo/SOUND # define SOUND_OBJS play.o libsst.o #else + #ifdef sgi + # define SOUND_LIBS -laudio + # define SOUND_CFLAGS + # define SOUND_OBJS sgiplay.o + #endif + #endif + #else # define SOUND_LIBS # define SOUND_CFLAGS # define SOUND_OBJS *************** *** 754,756 **** --- 761,764 ---- xterm.o: window.h bitmaps.h events.h xutils.o: config.h xterm.h xutils.o: blockio.h dispextern.h screen.h + sgiplay.o: config.h lisp.h libst.h From bug-lucid-emacs-request@lucid.com Fri Jul 3 12:26:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20440; Fri, 3 Jul 92 12:26:33 PDT Received: by heavens-gate.lucid.com id AA26636g; Fri, 3 Jul 92 12:17:48 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA26632g; Fri, 3 Jul 92 12:17:38 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Fri, 3 Jul 92 21:26 MDT Message-Id: Date: Fri, 3 Jul 92 21:26 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: SGI audio patch for Lemacs 19.2 -- missing file The sgiplay.c that came to you with my last message references a file called "libst.h" which is part of Jef Poskanzer's SPARC sound tools. I forgot to include it in the patch, so here it is. Put it into the src/ subdirectory if you want the SGI sound support. -- Simon. ---------------------------------- libst.h ---------------------------------- /* libst.h - include file for portable sound tools library ** ** Copyright (C) 1989 by Jef Poskanzer. ** ** Permission to use, copy, modify, and distribute this software and its ** documentation for any purpose and without fee is hereby granted, provided ** that the above copyright notice appear in all copies and that both that ** copyright notice and this permission notice appear in supporting ** documentation. This software is provided "as is" without express or ** implied warranty. */ #define SAMPLES_PER_SECOND 8192 #define MINLIN -32768 #define MAXLIN 32767 #define LINCLIP(x) do { if ( x < MINLIN ) x = MINLIN ; else if ( x > MAXLIN ) x = MAXLIN; } while ( 0 ) unsigned char st_linear_to_ulaw( /* int sample */ ); int st_ulaw_to_linear_slow( /* unsigned char ulawbyte */ ); /* ** This macro converts from ulaw to 16 bit linear, faster. ** ** Jef Poskanzer ** 23 October 1989 ** ** Input: 8 bit ulaw sample ** Output: signed 16 bit linear sample */ #define st_ulaw_to_linear(ulawbyte) ulaw_table[ulawbyte] static int ulaw_table[256] = { -32124, -31100, -30076, -29052, -28028, -27004, -25980, -24956, -23932, -22908, -21884, -20860, -19836, -18812, -17788, -16764, -15996, -15484, -14972, -14460, -13948, -13436, -12924, -12412, -11900, -11388, -10876, -10364, -9852, -9340, -8828, -8316, -7932, -7676, -7420, -7164, -6908, -6652, -6396, -6140, -5884, -5628, -5372, -5116, -4860, -4604, -4348, -4092, -3900, -3772, -3644, -3516, -3388, -3260, -3132, -3004, -2876, -2748, -2620, -2492, -2364, -2236, -2108, -1980, -1884, -1820, -1756, -1692, -1628, -1564, -1500, -1436, -1372, -1308, -1244, -1180, -1116, -1052, -988, -924, -876, -844, -812, -780, -748, -716, -684, -652, -620, -588, -556, -524, -492, -460, -428, -396, -372, -356, -340, -324, -308, -292, -276, -260, -244, -228, -212, -196, -180, -164, -148, -132, -120, -112, -104, -96, -88, -80, -72, -64, -56, -48, -40, -32, -24, -16, -8, 0, 32124, 31100, 30076, 29052, 28028, 27004, 25980, 24956, 23932, 22908, 21884, 20860, 19836, 18812, 17788, 16764, 15996, 15484, 14972, 14460, 13948, 13436, 12924, 12412, 11900, 11388, 10876, 10364, 9852, 9340, 8828, 8316, 7932, 7676, 7420, 7164, 6908, 6652, 6396, 6140, 5884, 5628, 5372, 5116, 4860, 4604, 4348, 4092, 3900, 3772, 3644, 3516, 3388, 3260, 3132, 3004, 2876, 2748, 2620, 2492, 2364, 2236, 2108, 1980, 1884, 1820, 1756, 1692, 1628, 1564, 1500, 1436, 1372, 1308, 1244, 1180, 1116, 1052, 988, 924, 876, 844, 812, 780, 748, 716, 684, 652, 620, 588, 556, 524, 492, 460, 428, 396, 372, 356, 340, 324, 308, 292, 276, 260, 244, 228, 212, 196, 180, 164, 148, 132, 120, 112, 104, 96, 88, 80, 72, 64, 56, 48, 40, 32, 24, 16, 8, 0 }; From bug-lucid-emacs-request@lucid.com Sun Jul 5 23:36:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27072; Sun, 5 Jul 92 23:36:45 PDT Received: by heavens-gate.lucid.com id AA29929g; Sun, 5 Jul 92 23:28:05 PDT Received: from alpha.xerox.com by heavens-gate.lucid.com id AA29925g; Sun, 5 Jul 92 23:27:50 PDT Received: from archer.parc.xerox.com ([13.1.100.94]) by alpha.xerox.com with SMTP id <11954>; Sun, 5 Jul 1992 23:36:44 PDT Received: by archer.parc.xerox.com id <21546>; Sun, 5 Jul 1992 23:36:32 -0700 To: bug-lucid-emacs@lucid.com Subject: sundry bugs and misfeatures From: Richard Mlynarik Sender: Richard Mlynarik Fake-Sender: mlynarik@parc.xerox.com Reply-To: Mly@lcs.mit.edu Message-Id: <92Jul5.233632pdt.21546@archer.parc.xerox.com> Date: Sun, 5 Jul 1992 23:36:24 PDT (documentation 'read-key-sequence) "... A C-g typed while in this function is treated like any other character, and `quit-flag' is not set. ..." (condition-case c (read-key-sequence "Type Control-G") (quit c)) => (quit), not [#] There's a bunch of moaning about this in command_loop_1. I don't understand what the deal is, but it sure would be nice if it worked. IWBNI c-g read "synchronously" (ie by command_loop_1) should just look-up the key in the keymaps as usual instead of having the quit hard-wired into the command-loop. ---------------------------------------------------------------------- The (sit-for 1) in kill-ring-save is one of the more hateful things you've done. ---------------------------------------------------------------------- The spelling is "highlight". No cretinous "hi" or "lite" or any combination thereof. Global search and replace is in order. ---------------------------------------------------------------------- interrupt-char's symbol documentation claims: Do not setq this variable: use the function `set-interrupt-character' instead. There is no such function (though there should be.) ---------------------------------------------------------------------- "force-mode-line-update" in subr.el is inconsistent with other names in Emacs ("redraw-display" "redraw-screen") and with the C code (redraw_mode_line). Rename as "redraw-mode-line" ---------------------------------------------------------------------- In command_loop_1, local variables cmd, nonundocount, lose, i, no_direct and no_redisplay are set but never used. What sort of losing compilers are you guys using? ---------------------------------------------------------------------- The "backup_n" arg to completing-read isn't documented. This function is yet another argument for why &keyword args win and why &optionals are evil. ---------------------------------------------------------------------- num_input_keys (in keyboard.c) is never used. Nuke it! If somebody really truly needs it, put a (setq num-input-keys 0) into a emacs-compatibility-crocks.el file. ---------------------------------------------------------------------- "saved_keys" in command_execute is set but not used. It seems that it isn't set because somebody (accidentally?) diked out all the code which was supposed to keep "this-command-keys" current. Compare the behaviour of (defun foo () (interactive) (message "Foo: %s" (let ((print-escape-newlines t)) (prin1-to-string (this-command-keys))))) in Lucid and 18.58. Of course, the usefulness of (this-command-keys) in this case is extremely dubious -- perhaps it -should- just return nil? ---------------------------------------------------------------------- m-x point-to-register w (or c-x / w) doesn't clear the echo area and leaves the cursor in the echo are. Moreover, after one does type the next command (say, c-p) a turd is left in the echo area where the cursor was drawn. ---------------------------------------------------------------------- You should add a variable which controls the bizarre buffer-modifying behaviour of c-n. People ask for it on bug-gnu-emacs all the time. (I've been using a personal non-losing version of next-line for years.) Just pick a name and add it finally! ---------------------------------------------------------------------- There should be a "current-message" procedure (there's probably a better name) which returns the string which is being displayed in the echo area. That way one can write things which temporarily "overwrite" the old message (in much the same way as the GC messages do, for example.) Better yet, implement the echo area as a buffer and I can just use buffer-string to snag it. ---------------------------------------------------------------------- buffer-string should take an optional argument (default current-buffer) buffer-substring should work if the one or both of its args are markers pointing into a buffer other than (current-buffer) ---------------------------------------------------------------------- mark-bob and mark-eob are horrible names (and are inconsistent with the user-programming names of Emacs) mark-beginning-of-buffer and mark-end-of-buffer, please! ---------------------------------------------------------------------- From bug-lucid-emacs-request@lucid.com Sun Jul 5 23:46:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27229; Sun, 5 Jul 92 23:46:37 PDT Received: by heavens-gate.lucid.com id AA29942g; Sun, 5 Jul 92 23:37:59 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA29938g; Sun, 5 Jul 92 23:37:48 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA22659; Sun, 5 Jul 92 23:47:02 PDT Date: Sun, 5 Jul 92 23:47:02 PDT Message-Id: <9207060647.AA22659@thalidomide.lucid> From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Mly@lcs.mit.edu Cc: bug-lucid-emacs@lucid.com Subject: Re: sundry bugs and misfeatures In-Reply-To: Richard Mlynarik's message of Sun 5-Jul-19 23:36:24 PDT <92Jul5.233632pdt.21546@archer.parc.xerox.com> References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> In message <92Jul5.233632pdt.21546@archer.parc.xerox.com> Richard Mlynarik wrote: > > IWBNI c-g read "synchronously" (ie by command_loop_1) should just > look-up the key in the keymaps as usual instead of having the quit > hard-wired into the command-loop. Emacs 18 did this but it is not reasonable. It leads people to believe that you can bind commands to ^G while it is the interrupt character; in fact, you can only execute those commands when emacs is waiting for input. They don't work as typeahead. I see no justification for such a bogus losing feature. > mark-bob and mark-eob are horrible names (and are inconsistent with > the user-programming names of Emacs) > > mark-beginning-of-buffer and mark-end-of-buffer, please! Not mark-\"Bob\" ? -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jul 6 10:01:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29619; Mon, 6 Jul 92 10:01:03 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA00880g; Mon, 6 Jul 92 09:51:47 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA03006; Mon, 6 Jul 92 13:00:51 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA02999; Mon, 6 Jul 92 13:00:48 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA13842; Mon, 6 Jul 92 13:00:59 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!walter!geoff From: geoff@flash.bellcore.com (Geoffrey Clemm) Subject: Re: sundry bugs and misfeatures In-Reply-To: Richard Mlynarik's message of Sun, 5 Jul 1992 23:36:24 PDT Message-Id: Organization: Bellcore References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> Date: 6 Jul 92 12:44:57 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <92Jul5.233632pdt.21546@archer.parc.xerox.com> Richard Mlynarik writes: > There's a bunch of moaning ... > ... is one of the more hateful things you've done. > ... No cretinous "hi" or "lite" or any ... > ... What sort of losing compilers are you guys using? > ... isn't set because somebody (accidentally?) diked out all the code ... > ... the next command (say, c-p) a turd is left in the echo area where ... > ... mark-bob and mark-eob are horrible names ... Just to make sure anyone new to this newsgroup is not misled by the above "posting" from Mr. Mlynarik, This is *not* the way one communicates on a technical newsgroup. Politeness and good humor are expected, even if you are squirreled away in some dark cubicle, resenting the world because no one can stand your repulsive personality (:-). Cheers, Geoff -- geoff@bellcore.com From bug-lucid-emacs-request@lucid.com Mon Jul 6 11:02:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29954; Mon, 6 Jul 92 11:02:34 PDT Received: by heavens-gate.lucid.com id AA01133g; Mon, 6 Jul 92 10:53:29 PDT Received: from watergate.lucid ([192.31.212.117]) by heavens-gate.lucid.com id AA01126g; Mon, 6 Jul 92 10:50:21 PDT Received: by watergate.lucid (4.1/SMI-4.1) id AA09837; Mon, 6 Jul 92 10:59:28 PDT Date: Mon, 6 Jul 92 10:59:28 PDT From: eb%watergate@lucid.com (Eric Benson) Message-Id: <9207061759.AA09837@watergate.lucid> To: geoff@flash.bellcore.com, Mly@lcs.mit.edu Cc: bug-lucid-emacs@lucid.com Subject: Re: sundry bugs and misfeatures Newsgroups: alt.lucid-emacs.bug In-Reply-To: Geoffrey Clemm's message of nil 92-Jul-12 :44:57 References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> Reply-To: eb@lucid.com In message Geoffrey Clemm wrote: > > In article <92Jul5.233632pdt.21546@archer.parc.xerox.com> Richard > Mlynarik writes: >> There's a bunch of moaning ... ... is one of the more hateful >> things you've done. ... No cretinous "hi" or "lite" or any ... >> ... What sort of losing compilers are you guys using? ... isn't >> set because somebody (accidentally?) diked out all the code ... >> ... the next command (say, c-p) a turd is left in the echo area >> where ... ... mark-bob and mark-eob are horrible names ... > > Just to make sure anyone new to this newsgroup is not misled by the > above "posting" from Mr. Mlynarik, > > This is *not* the way one communicates on a technical newsgroup. > > Politeness and good humor are expected, even if you are squirreled > away in some dark cubicle, resenting the world because no one can > stand your repulsive personality (:-). We aren't offended by Mr. Mlynarik's vitriolic correspondence. We know he's just trying to keep us entertained, and besides, if he vents his spleen on us he's less likely to get in real trouble by venting it on someone who could really damage his career! If you want to see a real flame, look at terminal.el. Richard, I think you`re losing your edge. From bug-lucid-emacs-request@lucid.com Mon Jul 6 12:23:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00422; Mon, 6 Jul 92 12:23:58 PDT Received: by heavens-gate.lucid.com id AA01447g; Mon, 6 Jul 92 12:13:02 PDT Received: from mda.ca (mdavcr.mda.ca) by heavens-gate.lucid.com id AA01441g; Mon, 6 Jul 92 12:12:50 PDT Received: from sparky.mda.ca by mda.ca (4.1/SMI-4.1-DNI) id AA01683; Mon, 6 Jul 92 12:20:55 PDT Date: Mon, 6 Jul 92 12:20:55 PDT From: rdr%mda.ca@lucid.com (Randolph Roesler) Message-Id: <9207061920.AA01683@ mda.ca> To: bug-lucid-emacs@lucid.com Subject: emacs.1 and xemacs.Geometry 1) Can not find emacs.1 2) setting resource xemacs.Geometry (or xemacs*Geometry) causes lemacs to abort. dbx'ing the core tells me that emacs could not find some (unknown which) window 3) You really do need to set all of PATH_LOADSEARCH, PATH_EXEC, and PATH_LOCK is your LIBDIR is anything other than BINDIR/../lib (mine is BINDIR/../lib/emacs) Randy Roesler From bug-lucid-emacs-request@lucid.com Mon Jul 6 12:33:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00445; Mon, 6 Jul 92 12:33:30 PDT Received: by heavens-gate.lucid.com id AA01493g; Mon, 6 Jul 92 12:25:01 PDT Received: from linus.mitre.org by heavens-gate.lucid.com id AA01486g; Mon, 6 Jul 92 12:21:51 PDT Return-Path: Received: from circe.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA09833; Mon, 6 Jul 92 15:30:37 -0400 Posted-Date: Mon, 06 Jul 92 15:31:57 -0400 Received: by circe.mitre.org (5.61/RCF-4C) id AA03183; Mon, 6 Jul 92 15:31:57 -0400 Message-Id: <9207061931.AA03183@circe.mitre.org> To: bug-lucid-emacs@lucid.com Cc: guttman@linus.mitre.org Subject: Tex-mode.el error: (require 'oshell) X-Postal-Address: MITRE, Mail Stop A156 \\ 202 Burlington Rd. \\ Bedford, MA 01730 Date: Mon, 06 Jul 92 15:31:57 -0400 From: guttman@linus.mitre.org At the top of lemacs-19.2/lisp/modes/tex-mode.el is the form: (require 'oshell) I get an error when I try to edit files in tex-mode "Cannot open load file." And sure enough: circe-32 ls */oshell.el */oshell.el not found circe-33 pwd /tmp_mnt/usr/src/local2/imps/lemacs-19.2/lisp circe-34 ls x11/ term/ modes/ electric/ site-init.el version.el rmail/ ilisp/ dired/ site-load.el vms/ sunview/ gnus/ comint/ README vm/ prim/ energize/ calendar/ COPYING utils/ packages/ emulators/ bytecomp/ paths.el circe-35 I don't need any very fancy functionality in tex-mode: is there some simple version that will work? Josh From bug-lucid-emacs-request@lucid.com Mon Jul 6 12:50:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00507; Mon, 6 Jul 92 12:50:39 PDT Received: by heavens-gate.lucid.com id AA01562g; Mon, 6 Jul 92 12:41:18 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA01542g; Mon, 6 Jul 92 12:38:08 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA23345; Mon, 6 Jul 92 12:47:18 PDT Date: Mon, 6 Jul 92 12:47:18 PDT Message-Id: <9207061947.AA23345@thalidomide.lucid> X-Windows: Garbage at your fingertips. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: rdr%mda.ca@lucid.com (Randolph Roesler) Cc: bug-lucid-emacs@lucid.com Subject: Re: emacs.1 and xemacs.Geometry In-Reply-To: Randolph Roesler's message of Mon 6-Jul-92 12:20:55 PDT <9207061920.AA01683@ mda.ca> References: <9207061920.AA01683@ mda.ca> In message <9207061920.AA01683@ mda.ca> Randolph Roesler wrote: > > 2) setting resource xemacs.Geometry (or xemacs*Geometry) > causes lemacs to abort. dbx'ing the core tells me > that emacs could not find some (unknown which) window It shouldn't abort, but setting *Geometry on any X application with a window hierarchy deeper than one is always the wrong thing. See the mailing list archive. I'm not sure why xemacs.Geometry would fail, I'll look into it. > 3) You really do need to set all of PATH_LOADSEARCH, PATH_EXEC, > and PATH_LOCK is your LIBDIR is anything other than > BINDIR/../lib (mine is BINDIR/../lib/emacs) It is my opinion that, instead of using paths.h, you should arrange your directory hierarchy so that it works. Using paths.h hardcodes way too much information into the executable. Simply make links called "lisp" and "etc" in the directory where the emacs executable is. Or in some directory along the link chain. Why not just make /usr/local/bin/lemacs (or whatever) be a link to an executable in the src/ directory of the lemacs distribution? -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jul 6 12:54:16 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00530; Mon, 6 Jul 92 12:54:16 PDT Received: by heavens-gate.lucid.com id AA01567g; Mon, 6 Jul 92 12:42:46 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA01545g; Mon, 6 Jul 92 12:38:59 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Mon, 6 Jul 92 21:48 MDT Message-Id: Date: Mon, 6 Jul 92 21:48 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: CD-quality(!), stereo(!!) sound for Lemacs (on SGI machines only)-; The `sgiplay.c' I had sent out a couple of days ago has been rewritten to recognise more audio formats possible in NeXT/Sun sound files. Files in other formats are not supported, but can usually convert them to .snd format using sfconvert or sox without any loss of quality. The new version of sgiplay.c is also better organised and documented, so adapting the code to other systems (NeXT comes to mind) is feasible. -- Simon. ----------------------- src/sgiplay.c for Lemacs 19.2 ----------------------- /* Play sound using the SGI audio library written by Simon Leinen Copyright (C) 1992 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Emacs; see the file COPYING. If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ #include "config.h" #include "lisp.h" #include #include #include #include #include #include #include /* for ntohl() etc. */ /* Configuration options */ /* ability to parse Sun/NeXT (.au or .snd) audio file headers. The .snd format supports all sampling rates and sample widths that are commonly used, as well as stereo. It is also easy to parse. */ #ifndef HAVE_SND_FILES #define HAVE_SND_FILES 1 #endif /* support for eight-but mu-law encoding. This is a useful compaction technique, and most sounds from the Sun universe are in this format. */ #ifndef HAVE_MULAW_8 #define HAVE_MULAW_8 1 #endif /* if your machine is very slow, you have to use a table lookup to convert mulaw samples to linear. This makes Emacs bigger so try to avoid it. */ #ifndef USE_MULAW_DECODE_TABLE #define USE_MULAW_DECODE_TABLE 0 #endif /* support for linear encoding -- useful if you want better quality. This enables 8, 16 and 24 bit wide samples. */ #ifndef HAVE_LINEAR #define HAVE_LINEAR 1 #endif /* support for 32 bit wide samples. If you notice the difference between 32 and 24 bit samples, you must have very good ears. Since the SGI audio library only supports 24 bit samples, each sample has to be shifted right by 8 bits anyway. So you should probably just convert all your 32 bit audio files to 24 bit. */ #ifndef HAVE_LINEAR_32 #define HAVE_LINEAR_32 0 #endif /* support for stereo sound. Imagine the cool applications of this: finally you don't just hear a beep -- you also know immediately *where* something went wrong! Unfortunately the programming interface only takes a single volume argument so far. */ #ifndef HAVE_STEREO #define HAVE_STEREO 1 #endif /* the play routine can be interrupted between chunks, so we choose a small chunksize to keep the system responsive (2000 samples correspond to a quarter of a second for .au files. If you HAVE_STEREO, the chunksize should probably be even. */ #define CHUNKSIZE 8000 /* the format assumed for header-less audio data. The following assumes ".au" format (8000 samples/sec mono 8-bit mulaw). */ #define DEFAULT_SAMPLING_RATE 8000 #define DEFAULT_CHANNEL_COUNT 1 #define DEFAULT_FORMAT AFmulaw8 /* Exports */ /* all compilers on machines that have the SGI audio library understand prototypes, right? */ extern void play_sound_file (char *, int); extern void play_sound_data (unsigned char *, int, int); /* Imports */ extern void report_file_error (char *, Lisp_Object); /* Data structures */ /* an AudioContext describes everything we want to know about how a particular sound snippet should be played. It is split into three parts (device, port and buffer) for implementation reasons. The device part corresponds to the state of the output device and must be reverted after playing the samples. The port part corresponds to an ALport; we want to allocate a minimal number of these since there are only four of them system-wide, but on the other hand we can't use the same port for mono and stereo. The buffer part corresponds to the sound data itself. */ typedef struct _AudioContextRec * AudioContext; typedef struct { long device; int left_speaker_gain; int right_speaker_gain; long output_rate; } AudioDeviceRec, * AudioDevice; /* supported sound data formats */ typedef enum { AFunknown, #if HAVE_MULAW_8 AFmulaw8, #endif #if HAVE_LINEAR AFlinear8, AFlinear16, AFlinear24, #if HAVE_LINEAR_32 AFlinear32, #endif #endif AFillegal } AudioFormat; typedef struct { ALport port; AudioFormat format; unsigned nchan; unsigned queue_size; } AudioPortRec, * AudioPort; typedef struct { void * data; unsigned long size; void (* write_chunk_function) (void *, void *, AudioContext); } AudioBufferRec, * AudioBuffer; typedef struct _AudioContextRec { AudioDeviceRec device; AudioPortRec port; AudioBufferRec buffer; } AudioContextRec; #define ac_device device.device #define ac_left_speaker_gain device.left_speaker_gain #define ac_right_speaker_gain device.right_speaker_gain #define ac_output_rate device.output_rate #define ac_port port.port #define ac_format port.format #define ac_nchan port.nchan #define ac_queue_size port.queue_size #define ac_data buffer.data #define ac_size buffer.size #define ac_write_chunk_function buffer.write_chunk_function /* Forward declarations */ static void close_sound_file (Lisp_Object); static AudioContext audio_initialize (unsigned char *, int, int); static void play_internal (unsigned char *, int, AudioContext); static void drain_audio_port (AudioContext); static void write_mulaw_8_chunk (void *, void *, AudioContext); static void write_linear_chunk (void *, void *, AudioContext); static void write_linear_32_chunk (void *, void *, AudioContext); static void restore_audio_port (Lisp_Object); static AudioContext initialize_audio_port (AudioContext); static int open_audio_port (AudioContext, AudioContext); static void adjust_audio_volume (AudioDevice); static void get_current_volumes (AudioDevice); static int set_channels (ALconfig, unsigned); static int set_output_format (ALconfig, AudioFormat); static int parse_snd_header (void*, long, AudioContext); /* are we looking at an NeXT/Sun audio header? */ #define LOOKING_AT_SND_HEADER_P(address) \ (!strncmp(".snd", (char *)(address), 4)) static void close_sound_file (closure) Lisp_Object closure; { close (XFASTINT (closure)); } void play_sound_file (sound_file, volume) char * sound_file; int volume; { int count = specpdl_ptr - specpdl; int input_fd; unsigned char buffer[CHUNKSIZE]; int bytes_read; AudioContext ac = (AudioContext) 0; input_fd = open (sound_file, O_RDONLY); if (input_fd == -1) /* no error message -- this can't happen because Fplay_sound_file has checked the file for us. */ return; record_unwind_protect (close_sound_file, make_number (input_fd)); while ((bytes_read = read (input_fd, buffer, CHUNKSIZE)) > 0) { if (ac == (AudioContext) 0) { ac = audio_initialize (buffer, bytes_read, volume); if (ac == 0) return; } else { ac->ac_data = buffer; ac->ac_size = bytes_read; } play_internal (buffer, bytes_read, ac); } drain_audio_port (ac); unbind_to (count); } static long saved_device_state[] = { AL_OUTPUT_RATE, 0, AL_LEFT_SPEAKER_GAIN, 0, AL_RIGHT_SPEAKER_GAIN, 0, }; static void restore_audio_port (closure) Lisp_Object closure; { Lisp_Object * contents = (XVECTOR (closure))->contents; saved_device_state[1] = XFASTINT (contents[0]); saved_device_state[3] = XFASTINT (contents[1]); saved_device_state[5] = XFASTINT (contents[2]); ALsetparams (AL_DEFAULT_DEVICE, saved_device_state, 6); } void play_sound_data (data, length, volume) unsigned char * data; int length; int volume; { int count = specpdl_ptr - specpdl; AudioContext ac; ac = audio_initialize (data, length, volume); if (ac == (AudioContext) 0) return; play_internal (data, length, ac); drain_audio_port (ac); unbind_to (count); } static AudioContext audio_initialize (data, length, volume) unsigned char * data; int length; int volume; { Lisp_Object audio_port_state[3]; static AudioContextRec desc; AudioContext ac; desc.ac_right_speaker_gain = desc.ac_left_speaker_gain = volume * 256 / 100; desc.ac_device = AL_DEFAULT_DEVICE; #if HAVE_SND_FILES if (LOOKING_AT_SND_HEADER_P (data)) { if (parse_snd_header (data, length, & desc)==-1) report_file_error ("decoding .snd header", Qnil); } else #endif { desc.ac_data = data; desc.ac_size = length; desc.ac_output_rate = DEFAULT_SAMPLING_RATE; desc.ac_nchan = DEFAULT_CHANNEL_COUNT; desc.ac_format = DEFAULT_FORMAT; desc.ac_write_chunk_function = write_mulaw_8_chunk; } /* Make sure that the audio port is reset to its initial characteristics after exit */ ALgetparams (desc.ac_device, saved_device_state, sizeof (saved_device_state) / sizeof (long)); audio_port_state[0] = make_number (saved_device_state[1]); audio_port_state[1] = make_number (saved_device_state[3]); audio_port_state[2] = make_number (saved_device_state[5]); record_unwind_protect (restore_audio_port, Fvector (3, &audio_port_state[0])); ac = initialize_audio_port (& desc); desc = * ac; return ac; } static void play_internal (data, length, ac) unsigned char * data; int length; AudioContext ac; { unsigned char * limit; if (ac == (AudioContext) 0) return; data = ac->ac_data; limit = data + ac->ac_size; while (data < limit) { unsigned char * chunklimit = data + CHUNKSIZE; if (chunklimit > limit) chunklimit = limit; QUIT; (* ac->ac_write_chunk_function) (data, chunklimit, ac); data = chunklimit; } } static void drain_audio_port (ac) AudioContext ac; { while (ALgetfilled (ac->ac_port) > 0) sginap(1); } /* Methods to write a "chunk" from a buffer containing audio data to an audio port. This may involve some conversion if the output device doesn't directly support the format the audio data is in. */ #if HAVE_MULAW_8 #if USE_MULAW_DECODE_TABLE #include "libst.h" #else /* not USE_MULAW_DECODE_TABLE */ static int st_ulaw_to_linear (u) int u; { static const short table[] = {0,132,396,924,1980,4092,8316,16764}; int u1 = ~u; short exponent = (u1 >> 4) & 0x07; int mantissa = u1 & 0x0f; int unsigned_result = table[exponent]+(mantissa << (exponent+3)); return u1 & 0x80 ? -unsigned_result : unsigned_result; } #endif /* not USE_MULAW_DECODE_TABLE */ static void write_mulaw_8_chunk (buffer, chunklimit, ac) void * buffer; void * chunklimit; AudioContext ac; { unsigned char * data = (unsigned char *) buffer; unsigned char * limit = (unsigned char *) chunklimit; short * obuf, * bufp; long n_samples = limit - data; obuf = alloca (n_samples * sizeof (short)); bufp = &obuf[0]; while (data < limit) *bufp++ = st_ulaw_to_linear (*data++); ALwritesamps (ac->ac_port, obuf, n_samples); } #endif /* HAVE_MULAW_8 */ #if HAVE_LINEAR static void write_linear_chunk (data, limit, ac) void * data; void * limit; AudioContext ac; { unsigned n_samples; switch (ac->ac_format) { case AFlinear16: n_samples = (short *) limit - (short *) data; break; case AFlinear8: n_samples = (char *) limit - (char *) data; break; default: n_samples = (long *) limit - (long *) data; break; } ALwritesamps (ac->ac_port, data, (long) n_samples); } #if HAVE_LINEAR_32 static void write_linear_32_chunk (buffer, chunklimit, ac) void * buffer; void * chunklimit; AudioContext ac; { long * data = (long *) buffer; long * limit = (long *) chunklimit; long * obuf, * bufp; long n_samples = limit-data; obuf = alloca (n_samples * sizeof (long)); bufp = &obuf[0]; while (data < limit) *bufp++ = *data++ >> 8; ALwritesamps (ac->ac_port, obuf, n_samples); } #endif /* HAVE_LINEAR_32 */ #endif /* HAVE_LINEAR */ static AudioContext initialize_audio_port (desc) AudioContext desc; { /* we can't use the same port for mono and stereo */ static AudioContextRec mono_port_state = { { 0, 0, 0, 0 }, { (ALport) 0, AFunknown, 1, 0 }, { (void *) 0, (unsigned long) 0 } }; #if HAVE_STEREO static AudioContextRec stereo_port_state = { { 0, 0, 0, 0 }, { (ALport) 0, AFunknown, 2, 0 }, { (void *) 0, (unsigned long) 0 } }; static AudioContext return_ac; switch (desc->ac_nchan) { case 1: return_ac = & mono_port_state; break; case 2: return_ac = & stereo_port_state; break; default: return (AudioContext) 0; } #else /* not HAVE_STEREO */ static AudioContext return_ac = & mono_port_state; #endif /* not HAVE_STEREO */ return_ac->device = desc->device; return_ac->buffer = desc->buffer; return_ac->ac_format = desc->ac_format; return_ac->ac_queue_size = desc->ac_queue_size; if (return_ac->ac_port==(ALport) 0) { if ((open_audio_port (return_ac, desc))==-1) { report_file_error ("Open audio port", Qnil); return (AudioContext) 0; } } else { ALconfig config = ALgetconfig (return_ac->ac_port); int changed = 0; long params[2]; params[0] = AL_OUTPUT_RATE; ALgetparams (return_ac->ac_device, params, 2); return_ac->ac_output_rate = params[1]; if (return_ac->ac_output_rate != desc->ac_output_rate) { return_ac->ac_output_rate = params[1] = desc->ac_output_rate; ALsetparams (return_ac->ac_device, params, 2); } if ((changed = set_output_format (config, return_ac->ac_format))==-1) return (AudioContext) 0; return_ac->ac_format = desc->ac_format; if (changed) ALsetconfig (return_ac->ac_port, config); } return_ac->ac_write_chunk_function = desc->ac_write_chunk_function; get_current_volumes (& return_ac->device); if (return_ac->ac_left_speaker_gain != desc->ac_left_speaker_gain || return_ac->ac_right_speaker_gain != desc->ac_right_speaker_gain) adjust_audio_volume (& desc->device); return return_ac; } static int open_audio_port (return_ac, desc) AudioContext return_ac; AudioContext desc; { ALconfig config = ALnewconfig(); long params[2]; adjust_audio_volume (& desc->device); return_ac->ac_left_speaker_gain = desc->ac_left_speaker_gain; return_ac->ac_right_speaker_gain = desc->ac_right_speaker_gain; params[0] = AL_OUTPUT_RATE; params[1] = desc->ac_output_rate; ALsetparams (desc->ac_device, params, 2); return_ac->ac_output_rate = desc->ac_output_rate; if (set_channels (config, desc->ac_nchan)==-1) return -1; return_ac->ac_nchan = desc->ac_nchan; if (set_output_format (config, desc->ac_format)==-1) return -1; return_ac->ac_format = desc->ac_format; ALsetqueuesize (config, (long) CHUNKSIZE); return_ac->ac_port = ALopenport("Lemacs audio output", "w", config); ALfreeconfig (config); if (return_ac->ac_port==0) { report_file_error ("Opening audio output port", Qnil); return -1; } return 0; } static int set_channels (config, nchan) ALconfig config; unsigned nchan; { switch (nchan) { case 1: ALsetchannels (config, AL_MONO); break; #if HAVE_STEREO case 2: ALsetchannels (config, AL_STEREO); break; #endif /* HAVE_STEREO */ default: report_file_error ("Unsupported channel count", Fcons (make_number (nchan), Qnil)); return -1; } return 0; } static int set_output_format (config, format) ALconfig config; AudioFormat format; { long samplesize; long old_samplesize; switch (format) { #if HAVE_MULAW_8 case AFmulaw8: #endif #if HAVE_LINEAR case AFlinear16: #endif #if HAVE_MULAW_8 || HAVE_LINEAR samplesize = AL_SAMPLE_16; break; #endif #if HAVE_LINEAR case AFlinear8: samplesize = AL_SAMPLE_8; break; case AFlinear24: #if HAVE_LINEAR_32 case AFlinear32: samplesize = AL_SAMPLE_24; break; #endif #endif default: report_file_error ("Unsupported audio format", Fcons (make_number (format), Qnil)); return -1; } old_samplesize = ALgetwidth (config); if (old_samplesize==samplesize) return 0; ALsetwidth (config, samplesize); return 1; } static void adjust_audio_volume (device) AudioDevice device; { long params[4] = {AL_LEFT_SPEAKER_GAIN, 0, AL_RIGHT_SPEAKER_GAIN, 0}; params[1] = device->left_speaker_gain; params[3] = device->right_speaker_gain; ALsetparams (device->device, params, 4); } static void get_current_volumes (device) AudioDevice device; { long params[4] = { AL_LEFT_SPEAKER_GAIN, 0, AL_RIGHT_SPEAKER_GAIN, 0 }; ALgetparams (device->device, params, 4); device->left_speaker_gain = params[1]; device->right_speaker_gain = params[3]; } #if HAVE_SND_FILES /* Parsing .snd (NeXT/Sun) headers */ typedef struct { int magic; int dataLocation; int dataSize; int dataFormat; int samplingRate; int channelCount; char info[4]; } SNDSoundStruct; #define SOUND_TO_HOST_INT(x) ntohl(x) typedef enum { SND_FORMAT_FORMAT_UNSPECIFIED, SND_FORMAT_MULAW_8, SND_FORMAT_LINEAR_8, SND_FORMAT_LINEAR_16, SND_FORMAT_LINEAR_24, SND_FORMAT_LINEAR_32, SND_FORMAT_FLOAT, SND_FORMAT_DOUBLE, SND_FORMAT_INDIRECT, SND_FORMAT_NESTED, SND_FORMAT_DSP_CODE, SND_FORMAT_DSP_DATA_8, SND_FORMAT_DSP_DATA_16, SND_FORMAT_DSP_DATA_24, SND_FORMAT_DSP_DATA_32, SND_FORMAT_DSP_unknown_15, SND_FORMAT_DISPLAY, SND_FORMAT_MULAW_SQUELCH, SND_FORMAT_EMPHASIZED, SND_FORMAT_COMPRESSED, SND_FORMAT_COMPRESSED_EMPHASIZED, SND_FORMAT_DSP_COMMANDS, SND_FORMAT_DSP_COMMANDS_SAMPLES } SNDFormatCode; static int parse_snd_header (header, length, desc) void * header; long length; AudioContext desc; { #define hp ((SNDSoundStruct *) (header)) long limit; #if HAVE_LINEAR desc->ac_write_chunk_function = write_linear_chunk; #endif switch ((SNDFormatCode) SOUND_TO_HOST_INT (hp->dataFormat)) { #if HAVE_MULAW_8 case SND_FORMAT_MULAW_8: desc->ac_format = AFmulaw8; desc->ac_write_chunk_function = write_mulaw_8_chunk; break; #endif #if HAVE_LINEAR case SND_FORMAT_LINEAR_8: desc->ac_format = AFlinear8; break; case SND_FORMAT_LINEAR_16: desc->ac_format = AFlinear16; break; case SND_FORMAT_LINEAR_24: desc->ac_format = AFlinear24; break; #endif #if HAVE_LINEAR_32 case SND_FORMAT_LINEAR_32: desc->ac_format = AFlinear32; desc->ac_write_chunk_function = write_linear_32_chunk; break; #endif default: desc->ac_format = AFunknown; } desc->ac_output_rate = SOUND_TO_HOST_INT (hp->samplingRate); desc->ac_nchan = SOUND_TO_HOST_INT (hp->channelCount); desc->ac_data = (char *) header + SOUND_TO_HOST_INT (hp->dataLocation); limit = (char *) header + length - (char *) desc->ac_data; desc->ac_size = SOUND_TO_HOST_INT (hp->dataSize); if (desc->ac_size > limit) desc->ac_size = limit; return 0; #undef hp } #endif /* HAVE_SND_FILES */ From bug-lucid-emacs-request@lucid.com Mon Jul 6 13:18:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00606; Mon, 6 Jul 92 13:18:23 PDT Received: by heavens-gate.lucid.com id AA01664g; Mon, 6 Jul 92 13:09:04 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA01651g; Mon, 6 Jul 92 13:07:20 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Mon, 6 Jul 92 22:16 MDT Message-Id: Date: Mon, 6 Jul 92 22:16 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: rdr@mda.ca (Randolph Roesler) Cc: bug-lucid-emacs@lucid.com Subject: emacs.1 and xemacs.Geometry In-Reply-To: <9207061920.AA01683@ mda.ca> References: <9207061920.AA01683@ mda.ca> > 2) setting resource xemacs.Geometry (or xemacs*Geometry) > causes lemacs to abort. ...works for me (Lemacs 19.2). > 3) You really do need to set all of PATH_LOADSEARCH, PATH_EXEC, > and PATH_LOCK is your LIBDIR is anything other than > BINDIR/../lib (mine is BINDIR/../lib/emacs) I also had difficulties with the dynamic configuration at first, but my current installation works nicely -- probably you can adapt it to your setup: * Lemacs libraries reside under /usr/local/lemacs/{lisp,etc,info}. * The Lemacs binary is physically stored as /usr/local/lemacs/lemacs. * /usr/local/bin/lemacs is a symlink -> /usr/local/lemacs/lemacs. -- Simon. From bug-lucid-emacs-request@lucid.com Mon Jul 6 13:40:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00673; Mon, 6 Jul 92 13:40:26 PDT Received: by heavens-gate.lucid.com id AA01775g; Mon, 6 Jul 92 13:31:48 PDT Received: from kona.cs.ucla.edu by heavens-gate.lucid.com id AA01753g; Mon, 6 Jul 92 13:28:40 PDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61c+YP/3.19) id AA24670; Mon, 6 Jul 92 13:37:43 -0700 Received: from farside.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA07049; Mon, 6 Jul 92 13:30:54 PDT Received: by farside.twinsun.com (4.1/SMI-4.1) id AA08105; Mon, 6 Jul 92 13:30:53 PDT Date: Mon, 6 Jul 92 13:30:53 PDT From: eggert@twinsun.com (Paul Eggert) Message-Id: <9207062030.AA08105@farside.twinsun.com> To: bug-lucid-emacs@lucid.com Subject: lemacs installation Date: Mon, 6 Jul 92 12:47:18 PDT From: Jamie Zawinski Why not just make /usr/local/bin/lemacs (or whatever) be a link to an executable in the src/ directory of the lemacs distribution? That isn't possible in many environments, where there has to be a sharp distinction between source directories and installed directories, either because of cross-compilation issues, or lack of disk space, or local politics. From bug-lucid-emacs-request@lucid.com Mon Jul 6 14:18:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00783; Mon, 6 Jul 92 14:18:00 PDT Received: by heavens-gate.lucid.com id AA01909g; Mon, 6 Jul 92 14:09:19 PDT Received: from research.nj.nec.com by heavens-gate.lucid.com id AA01898g; Mon, 6 Jul 92 14:07:58 PDT Received: by research.nj.nec.com (4.0/YDL1.8-920115.13) id AA09731(research.nj.nec.com); Mon, 6 Jul 92 17:17:00 EDT Received: by overdrive.NJ.NEC.COM (4.1/EMS1.6-920330.08) id AA10532(overdrive.NJ.NEC.COM); Mon, 6 Jul 92 17:16:51 EDT Date: Mon, 6 Jul 92 17:16:51 EDT From: max@ccrl.nj.nec.com (Maximilian Ott) Message-Id: <9207062116.AA10532@overdrive.NJ.NEC.COM> To: bug-lucid-emacs@lucid.com Subject: tex-mode: missing oshell I'm sure this has been dealt with before, but I just tuned in. The tex-mode.el file requires an 'oshell' which I can't find anywhere. Are there actually FTP sites carrying elisp code. Looked at my faviorite ones but no luck. Thanks, max p.s Please send me mail directly as I just sent off my request for joining and I don't know how long it will take for my name to be included. From bug-lucid-emacs-request@lucid.com Mon Jul 6 14:31:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00808; Mon, 6 Jul 92 14:31:54 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01954g; Mon, 6 Jul 92 14:23:08 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA22371; Mon, 6 Jul 92 17:32:13 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA22365; Mon, 6 Jul 92 17:32:11 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA16180; Mon, 6 Jul 92 17:32:17 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!walter!geoff From: geoff@flash.bellcore.com (Geoffrey Clemm) Subject: Re: sundry bugs and misfeatures In-Reply-To: eb%watergate@lucid.com's message of Mon, 6 Jul 92 10:59:28 PDT Message-Id: Organization: Bellcore References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> <9207061759.AA09837@watergate.lucid> Date: 6 Jul 92 17:28:30 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9207061759.AA09837@watergate.lucid> eb%watergate@lucid.com (Eric Benson) writes: We aren't offended by Mr. Mlynarik's vitriolic correspondence. We know he's just trying to keep us entertained, and besides, if he vents his spleen on us he's less likely to get in real trouble by venting it on someone who could really damage his career! If you want to see a real flame, look at terminal.el. Richard, I think you`re losing your edge. I appreciate the spirit in which this was posted -- as the recipient of the rudeness, it is appropriate for the folks at Lucid to be magnanimous and shrug it off as a minor irritation. On the other hand, it is important not to minimize the damage done to a technical newsgroup by impolite and ill-natured postings. There are a sizeable percentage of potentially valuable contributors (both of software as well as news articles) who have no interest in reading or being the target of abuse. Cheers, Geoff -- geoff@bellcore.com From bug-lucid-emacs-request@lucid.com Mon Jul 6 15:19:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00981; Mon, 6 Jul 92 15:19:45 PDT Received: by heavens-gate.lucid.com id AA02146g; Mon, 6 Jul 92 15:10:40 PDT Received: from linus.mitre.org by heavens-gate.lucid.com id AA02136g; Mon, 6 Jul 92 15:08:15 PDT Return-Path: Received: from circe.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA13901; Mon, 6 Jul 92 18:17:22 -0400 Posted-Date: Mon, 06 Jul 92 18:18:43 -0400 Received: by circe.mitre.org (5.61/RCF-4C) id AA03607; Mon, 6 Jul 92 18:18:43 -0400 Message-Id: <9207062218.AA03607@circe.mitre.org> To: max@ccrl.nj.nec.com (Maximilian Ott) Cc: bug-lucid-emacs@lucid.com, guttman@linus.mitre.org Subject: Re: tex-mode: missing oshell In-Reply-To: Your message of "Mon, 06 Jul 92 17:16:51 EDT." <9207062116.AA10532@overdrive.NJ.NEC.COM> X-Postal-Address: MITRE, Mail Stop A156 \\ 202 Burlington Rd. \\ Bedford, MA 01730 Date: Mon, 06 Jul 92 18:18:43 -0400 From: guttman@linus.mitre.org I asked the same question about 3 hours ago, and lo and behold, they sent me the enclosed replacement. Josh ~~~~~~~~~~~~~~~~ ;;; tex-mode.el --- TeX, LaTeX, and SliTeX mode commands. ;; Copyright (C) 1985-1992 Free Software Foundation, Inc. ;; Contributions over the years by William F. Schelter, Dick King, ;; Stephen Gildea, Michael Prange, and Edward M. Reingold. ;; Latest revision (1992) by Edward M. Reingold . ;; This file is part of GNU Emacs. ;; GNU Emacs is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 1, or (at your option) ;; any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs; see the file COPYING. If not, write to ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. (require 'comint) (defvar tex-shell-file-name nil "*If non-nil, is file name to use for the subshell in which TeX is run.") (defvar tex-directory "." "*Directory in which temporary files are left. You can make this /tmp if your TEXINPUTS has no relative directories in it and you don't try to apply \\[tex-region] or \\[tex-buffer] when there are \\input commands with relative directories.") (defvar tex-offer-save t "*If non-nil, ask about saving modified buffers before \\[tex-file] is run.") (defvar tex-run-command "tex" "*Command used to run TeX subjob. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string.") (defvar latex-run-command "latex" "*Command used to run LaTeX subjob. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string.") (defvar standard-latex-block-names '("abstract" "array" "center" "description" "displaymath" "document" "enumerate" "eqnarray" "eqnarray*" "equation" "figure" "figure*" "flushleft" "flushright" "itemize" "letter" "list" "minipage" "picture" "quotation" "quote" "slide" "sloppypar" "tabbing" "table" "table*" "tabular" "tabular*" "thebibliography" "theindex*" "titlepage" "trivlist" "verbatim" "verbatim*" "verse") "Standard LaTeX block names.") (defvar latex-block-names nil "*User defined LaTeX block names. Combined with `standard-latex-block-names' for minibuffer completion.") (defvar slitex-run-command "slitex" "*Command used to run SliTeX subjob. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string.") (defvar tex-bibtex-command "bibtex" "*Command used by `tex-bibtex-file' to gather bibliographic data. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string.") (defvar tex-dvi-print-command "lpr -d" "*Command used by \\[tex-print] to print a .dvi file. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string.") (defvar tex-alt-dvi-print-command "lpr -d" "*Command used by \\[tex-print] with a prefix arg to print a .dvi file. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string. If two printers are not enough of a choice, you can define the value of tex-alt-dvi-print-command to be an expression that asks what you want; for example, (setq tex-alt-dvi-print-command '(format \"lpr -P%s\" (read-string \"Use printer: \"))) would tell \\[tex-print] with a prefix argument to ask you which printer to use.") (defvar tex-dvi-view-command nil "*Command used by \\[tex-view] to display a .dvi file. If this string contains an asterisk (*), it will be replaced by the filename; if not, the name of the file, preceded by blank, will be added to this string. This can be set conditionally so that the previewer used is suitable for the window system being used. For example, (setq tex-dvi-view-command (if (eq window-system 'x) \"xdvi\" \"dvi2tty * | cat -s\")) would tell \\[tex-view] use xdvi under X windows and to use dvi2tty otherwise.") (defvar tex-show-queue-command "lpq" "*Command used by \\[tex-show-print-queue] to show the print queue. Should show the queue(s) that \\[tex-print] puts jobs on.") (defvar tex-default-mode 'plain-tex-mode "*Mode to enter for a new file that might be either TeX or LaTeX. This variable is used when it can't be determined whether the file is plain TeX or LaTeX or what because the file contains no commands. Normally set to either 'plain-tex-mode or 'latex-mode.") (defvar tex-open-quote "``" "*String inserted by typing \\[tex-insert-quote] to open a quotation.") (defvar tex-close-quote "''" "*String inserted by typing \\[tex-insert-quote] to close a quotation.") (defvar tex-last-temp-file nil "Latest temporary file generated by \\[tex-region] and \\[tex-buffer]. Deleted when the \\[tex-region] or \\[tex-buffer] is next run, or when the tex-shell goes away.") (defvar tex-command nil "Command to run TeX. The name of the file, preceded by a blank, will be added to this string.") (defvar tex-trailer nil "String appended after the end of a region sent to TeX by \\[tex-region].") (defvar tex-start-of-header nil "String used by \\[tex-region] to delimit the start of the file's header.") (defvar tex-end-of-header nil "String used by \\[tex-region] to delimit the end of the file's header.") (defvar tex-shell-cd-command "cd" "Command to give to shell running TeX to change directory. The value of tex-directory will be appended to this, separated by a space.") (defvar tex-zap-file nil "Temporary file name used for text being sent as input to TeX. Should be a simple file name with no extension or directory specification.") (defvar tex-last-buffer-texed nil "Buffer which was last TeXed.") (defvar tex-print-file nil "File name that \\[tex-print] prints. Set by \\[tex-region], \\[tex-buffer], and \\[tex-file].") (defvar tex-mode-syntax-table nil "Syntax table used while in TeX mode.") (defun tex-define-common-keys (keymap) "Define the keys that we want defined both in TeX mode and in the tex-shell." (define-key keymap "\C-c\C-k" 'tex-kill-job) (define-key keymap "\C-c\C-l" 'tex-recenter-output-buffer) (define-key keymap "\C-c\C-q" 'tex-show-print-queue) (define-key keymap "\C-c\C-p" 'tex-print) (define-key keymap "\C-c\C-v" 'tex-view) ) (defvar tex-mode-map nil "Keymap for TeX mode.") (if tex-mode-map nil (setq tex-mode-map (make-sparse-keymap)) (tex-define-common-keys tex-mode-map) (define-key tex-mode-map "\"" 'tex-insert-quote) (define-key tex-mode-map "\n" 'tex-terminate-paragraph) (define-key tex-mode-map "\C-c}" 'up-list) (define-key tex-mode-map "\C-c{" 'tex-insert-braces) (define-key tex-mode-map "\C-c\C-r" 'tex-region) (define-key tex-mode-map "\C-c\C-b" 'tex-buffer) (define-key tex-mode-map "\C-c\C-f" 'tex-file) (define-key tex-mode-map "\C-c\C-i" 'tex-bibtex-file) (define-key tex-mode-map "\C-c\C-o" 'tex-latex-block) (define-key tex-mode-map "\C-c\C-e" 'tex-close-latex-block)) (defvar tex-shell-map nil "Keymap for the tex-shell. A comint-mode-map with a few additions.") ;(fset 'TeX-mode 'tex-mode) ;in loaddefs. ;;; This would be a lot simpler if we just used a regexp search, ;;; but then it would be too slow. ;;;###autoload (defun tex-mode () "Major mode for editing files of input for TeX, LaTeX, or SliTeX. Tries to determine (by looking at the beginning of the file) whether this file is for plain TeX, LaTeX, or SliTeX and calls plain-tex-mode, latex-mode, or slitex-mode, respectively. If it cannot be determined, such as if there are no commands in the file, the value of tex-default-mode is used." (interactive) (let (mode slash comment) (save-excursion (goto-char (point-min)) (while (and (setq slash (search-forward "\\" nil t)) (setq comment (let ((search-end (point))) (save-excursion (beginning-of-line) (search-forward "%" search-end t)))))) (if (and slash (not comment)) (setq mode (if (looking-at "documentstyle") (if (looking-at "documentstyle{slides}") 'slitex-mode 'latex-mode) 'plain-tex-mode)))) (if mode (funcall mode) (funcall tex-default-mode)))) ;;;###autoload (fset 'TeX-mode 'tex-mode) ;;;###autoload (fset 'LaTeX-mode 'latex-mode) ;;;###autoload (defun plain-tex-mode () "Major mode for editing files of input for plain TeX. Makes $ and } display the characters they match. Makes \" insert `` when it seems to be the beginning of a quotation, and '' when it appears to be the end; it inserts \" only after a \\. Use \\[tex-region] to run TeX on the current region, plus a \"header\" copied from the top of the file (containing macro definitions, etc.), running TeX under a special subshell. \\[tex-buffer] does the whole buffer. \\[tex-file] saves the buffer and then processes the file. \\[tex-print] prints the .dvi file made by any of these. \\[tex-view] previews the .dvi file made by any of these. \\[tex-bibtex-file] runs bibtex on the file of the current buffer. Use \\[validate-tex-buffer] to check buffer for paragraphs containing mismatched $'s or braces. Special commands: \\{tex-mode-map} Mode variables: tex-run-command Command string used by \\[tex-region] or \\[tex-buffer]. tex-directory Directory in which to create temporary files for TeX jobs run by \\[tex-region] or \\[tex-buffer]. tex-dvi-print-command Command string used by \\[tex-print] to print a .dvi file. tex-alt-dvi-print-command Alternative command string used by \\[tex-print] (when given a prefix argument) to print a .dvi file. tex-dvi-view-command Command string used by \\[tex-view] to preview a .dvi file. tex-show-queue-command Command string used by \\[tex-show-print-queue] to show the print queue that \\[tex-print] put your job on. Entering Plain-tex mode calls the value of text-mode-hook, then the value of tex-mode-hook, and then the value of plain-tex-mode-hook. When the special subshell is initiated, the value of tex-shell-hook is called." (interactive) (tex-common-initialization) (setq mode-name "TeX") (setq major-mode 'plain-tex-mode) (setq tex-command tex-run-command) (setq tex-start-of-header "%**start of header") (setq tex-end-of-header "%**end of header") (setq tex-trailer "\\bye\n") (run-hooks 'text-mode-hook 'tex-mode-hook 'plain-tex-mode-hook)) ;;;###autoload (fset 'plain-TeX-mode 'plain-tex-mode) ;;;###autoload (defun latex-mode () "Major mode for editing files of input for LaTeX. Makes $ and } display the characters they match. Makes \" insert `` when it seems to be the beginning of a quotation, and '' when it appears to be the end; it inserts \" only after a \\. Use \\[tex-region] to run LaTeX on the current region, plus the preamble copied from the top of the file (containing \\documentstyle, etc.), running LaTeX under a special subshell. \\[tex-buffer] does the whole buffer. \\[tex-file] saves the buffer and then processes the file. \\[tex-print] prints the .dvi file made by any of these. \\[tex-view] previews the .dvi file made by any of these. \\[tex-bibtex-file] runs bibtex on the file of the current buffer. Use \\[validate-tex-buffer] to check buffer for paragraphs containing mismatched $'s or braces. Special commands: \\{tex-mode-map} Mode variables: latex-run-command Command string used by \\[tex-region] or \\[tex-buffer]. tex-directory Directory in which to create temporary files for LaTeX jobs run by \\[tex-region] or \\[tex-buffer]. tex-dvi-print-command Command string used by \\[tex-print] to print a .dvi file. tex-alt-dvi-print-command Alternative command string used by \\[tex-print] (when given a prefix argument) to print a .dvi file. tex-dvi-view-command Command string used by \\[tex-view] to preview a .dvi file. tex-show-queue-command Command string used by \\[tex-show-print-queue] to show the print queue that \\[tex-print] put your job on. Entering Latex mode calls the value of text-mode-hook, then the value of tex-mode-hook, and then the value of latex-mode-hook. When the special subshell is initiated, the value of tex-shell-hook is called." (interactive) (tex-common-initialization) (setq mode-name "LaTeX") (setq major-mode 'latex-mode) (setq tex-command latex-run-command) (setq tex-start-of-header "\\documentstyle") (setq tex-end-of-header "\\begin{document}") (setq tex-trailer "\\end{document}\n") (run-hooks 'text-mode-hook 'tex-mode-hook 'latex-mode-hook)) (defun slitex-mode () "Major mode for editing files of input for SliTeX. Makes $ and } display the characters they match. Makes \" insert `` when it seems to be the beginning of a quotation, and '' when it appears to be the end; it inserts \" only after a \\. Use \\[tex-region] to run SliTeX on the current region, plus the preamble copied from the top of the file (containing \\documentstyle, etc.), running SliTeX under a special subshell. \\[tex-buffer] does the whole buffer. \\[tex-file] saves the buffer and then processes the file. \\[tex-print] prints the .dvi file made by any of these. \\[tex-view] previews the .dvi file made by any of these. \\[tex-bibtex-file] runs bibtex on the file of the current buffer. Use \\[validate-tex-buffer] to check buffer for paragraphs containing mismatched $'s or braces. Special commands: \\{tex-mode-map} Mode variables: slitex-run-command Command string used by \\[tex-region] or \\[tex-buffer]. tex-directory Directory in which to create temporary files for SliTeX jobs run by \\[tex-region] or \\[tex-buffer]. tex-dvi-print-command Command string used by \\[tex-print] to print a .dvi file. tex-alt-dvi-print-command Alternative command string used by \\[tex-print] (when given a prefix argument) to print a .dvi file. tex-dvi-view-command Command string used by \\[tex-view] to preview a .dvi file. tex-show-queue-command Command string used by \\[tex-show-print-queue] to show the print queue that \\[tex-print] put your job on. Entering SliTeX mode calls the value of text-mode-hook, then the value of tex-mode-hook, then the value of latex-mode-hook, and then the value of slitex-mode-hook. When the special subshell is initiated, the value of tex-shell-hook is called." (interactive) (tex-common-initialization) (setq mode-name "SliTeX") (setq major-mode 'slitex-mode) (setq tex-command slitex-run-command) (setq tex-start-of-header "\\documentstyle{slides}") (setq tex-end-of-header "\\begin{document}") (setq tex-trailer "\\end{document}\n") (run-hooks 'text-mode-hook 'tex-mode-hook 'latex-mode-hook 'slitex-mode-hook)) (defun tex-common-initialization () (kill-all-local-variables) (use-local-map tex-mode-map) (setq local-abbrev-table text-mode-abbrev-table) (if (null tex-mode-syntax-table) (let ((char 0)) (setq tex-mode-syntax-table (make-syntax-table)) (set-syntax-table tex-mode-syntax-table) (while (< char ? ) (modify-syntax-entry char ".") (setq char (1+ char))) (modify-syntax-entry ?\C-@ "w") (modify-syntax-entry ?\t " ") (modify-syntax-entry ?\n ">") (modify-syntax-entry ?\f ">") (modify-syntax-entry ?$ "$$") (modify-syntax-entry ?% "<") (modify-syntax-entry ?\\ "/") (modify-syntax-entry ?\" ".") (modify-syntax-entry ?& ".") (modify-syntax-entry ?_ ".") (modify-syntax-entry ?@ "_") (modify-syntax-entry ?~ " ") (modify-syntax-entry ?' "w")) (set-syntax-table tex-mode-syntax-table)) (make-local-variable 'paragraph-start) (setq paragraph-start "^[ \t]*$\\|^[\f\\\\%]") (make-local-variable 'paragraph-separate) (setq paragraph-separate paragraph-start) (make-local-variable 'comment-start) (setq comment-start "%") (make-local-variable 'comment-start-skip) (setq comment-start-skip "\\(\\(^\\|[^\\]\\)\\(\\\\\\\\\\)*\\)\\(%+ *\\)") (make-local-variable 'comment-indent-hook) (setq comment-indent-hook 'tex-comment-indent) (make-local-variable 'compare-windows-whitespace) (setq compare-windows-whitespace 'tex-categorize-whitespace) (make-local-variable 'tex-command) (make-local-variable 'tex-start-of-header) (make-local-variable 'tex-end-of-header) (make-local-variable 'tex-trailer)) (defun tex-comment-indent () (if (looking-at "%%%") (current-column) (skip-chars-backward " \t") (max (if (bolp) 0 (1+ (current-column))) comment-column))) (defun tex-categorize-whitespace (backward-limit) ;; compare-windows-whitespace is set to this. ;; This is basically a finite-state machine. ;; Returns a symbol telling how TeX would treat ;; the whitespace we are looking at: null, space, or par. (let ((category 'null) (not-finished t)) (skip-chars-backward " \t\n\f" backward-limit) (while not-finished (cond ((looking-at "[ \t]+") (goto-char (match-end 0)) (if (eql category 'null) (setq category 'space))) ((looking-at "\n") (cond ((eql category 'newline) (setq category 'par) (setq not-finished nil)) (t (setq category 'newline) ;a strictly internal state (goto-char (match-end 0))))) ((looking-at "\f+") (setq category 'par) (setq not-finished nil)) (t (setq not-finished nil)))) (skip-chars-forward " \t\n\f") (if (eql category 'newline) 'space ;TeX doesn't distinguish category))) (defun tex-insert-quote (arg) "Insert the appropriate quote marks for TeX. Inserts the value of tex-open-quote (normally ``) or tex-close-quote (normally '') depending on the context. With prefix argument, always inserts \" characters." (interactive "*P") (if arg (self-insert-command (prefix-numeric-value arg)) (insert (cond ((or (bobp) (save-excursion (forward-char -1) (looking-at "\\s(\\|\\s \\|\\s>"))) tex-open-quote) ((= (preceding-char) ?\\) ?\") (t tex-close-quote))))) (defun validate-tex-buffer () "Check current buffer for paragraphs containing mismatched $'s. As each such paragraph is found, a mark is pushed at its beginning, and the location is displayed for a few seconds." (interactive) (let ((opoint (point))) (goto-char (point-max)) ;; Does not use save-excursion ;; because we do not want to save the mark. (unwind-protect (while (and (not (input-pending-p)) (not (bobp))) (let ((end (point))) (search-backward "\n\n" nil 'move) (or (tex-validate-region (point) end) (progn (push-mark (point)) (message "Mismatch found in pararaph starting here") (sit-for 4))))) (goto-char opoint)))) (defun tex-validate-region (start end) "Check for mismatched braces or $'s in region. Returns t if no mismatches. Returns nil and moves point to suspect area if a mismatch is found." (interactive "r") (let ((failure-point nil) (max-possible-sexps (- end start))) (save-excursion (condition-case () (save-restriction (narrow-to-region start end) (goto-char start) (while (< 0 (setq max-possible-sexps (1- max-possible-sexps))) (forward-sexp 1))) (error (setq failure-point (point))))) (if failure-point (progn (goto-char failure-point) nil) t))) (defun tex-terminate-paragraph (inhibit-validation) "Insert two newlines, breaking a paragraph for TeX. Check for mismatched braces/$'s in paragraph being terminated. A prefix arg inhibits the checking." (interactive "*P") (or inhibit-validation (save-excursion (tex-validate-region (save-excursion (search-backward "\n\n" nil 'move) (point)) (point))) (message "Paragraph being closed appears to contain a mismatch")) (insert "\n\n")) (defun tex-insert-braces () "Make a pair of braces and be poised to type inside of them." (interactive "*") (insert ?\{) (save-excursion (insert ?\}))) ;;; Like tex-insert-braces, but for LaTeX. (defun tex-latex-block (name) "Creates a matching pair of lines \\begin{NAME} and \\end{NAME} at point. Puts point on a blank line between them." (interactive (prog2 (barf-if-buffer-read-only) (list (completing-read "LaTeX block name: " (mapcar 'list (append standard-latex-block-names latex-block-names)))))) (let ((col (current-column))) (insert (format "\\begin{%s}\n" name)) (indent-to col) (save-excursion (insert ?\n) (indent-to col) (insert-string (format "\\end{%s}" name)) (if (eobp) (insert ?\n))))) (defun tex-last-unended-begin () "Leave point at the beginning of the last \\begin{...} that is unended." (while (and (re-search-backward "\\(\\\\begin\\s *{\\)\\|\\(\\\\end\\s *{\\)") (looking-at "\\\\end{")) (tex-last-unended-begin))) (defun tex-close-latex-block () "Creates an \\end{...} to match the last unclosed \\begin{...}." (interactive "*") (let ((new-line-needed (bolp)) text indentation) (save-excursion (condition-case nil (tex-last-unended-begin) (error (error "Couldn't find unended \\begin"))) (setq indentation (current-column)) (re-search-forward "\\\\begin\\(\\s *{[^}\n]*}\\)") (setq text (buffer-substring (match-beginning 1) (match-end 1)))) (indent-to indentation) (insert "\\end" text) (if new-line-needed (insert ?\n)))) ;;; Invoking TeX in an inferior shell. ;;; Why use a shell instead of running TeX directly? Because if TeX ;;; gets stuck, the user can switch to the shell window and type at it. ;;; The utility functions: (defun tex-start-shell () (save-excursion (set-buffer (make-comint "tex-shell" (or tex-shell-file-name (getenv "ESHELL") (getenv "SHELL") "/bin/sh") nil "-v")) (let ((proc (get-process "tex-shell"))) (set-process-sentinel proc 'tex-shell-sentinel) (process-kill-without-query proc) (setq tex-shell-map (copy-keymap comint-mode-map)) (tex-define-common-keys tex-shell-map) (use-local-map tex-shell-map) (run-hooks 'tex-shell-hook) (while (zerop (buffer-size)) (sleep-for 1))))) (defun tex-shell-sentinel (proc msg) (cond ((null (buffer-name (process-buffer proc))) ;; buffer killed (set-process-buffer proc nil) (tex-delete-last-temp-files)) ((memq (process-status proc) '(signal exit)) (tex-delete-last-temp-files)))) (defun tex-set-buffer-directory (buffer directory) "Set BUFFER's default directory to be DIRECTORY." (setq directory (file-name-as-directory (expand-file-name directory))) (if (not (file-directory-p directory)) (error "%s is not a directory" directory) (save-excursion (set-buffer buffer) (setq default-directory directory)))) (defun tex-send-command (command &optional file background) "Send COMMAND to tex-shell, substituting optional FILE for *; in background if optional BACKGROUND is t. If COMMAND has no *, FILE will be appended, preceded by a blank, to COMMAND. If FILE is nil, no substitution will be made in COMMAND. COMMAND can be any expression that evaluates to a command string." (save-excursion (let* ((cmd (eval command)) (star (string-match "\\*" cmd))) (comint-proc-query (get-process "tex-shell") (concat (substring cmd 0 star) (if file (concat " " file) "") (if star (substring cmd (1+ star) nil) "") (if background "&\n" "\n")))))) (defun tex-delete-last-temp-files () "Delete any junk files from last temp file." (if tex-last-temp-file (let* ((dir (file-name-directory tex-last-temp-file)) (list (file-name-all-completions (file-name-nondirectory tex-last-temp-file) dir))) (while list (delete-file (concat dir (car list))) (setq list (cdr list)))))) (setq kill-emacs-hook 'tex-delete-last-temp-files) ;;; The commands: (defun tex-region (beg end) "Run TeX on the current region, via a temporary file. The file's name comes from the variable `tex-zap-file' and the variable `tex-directory' says where to put it. If the buffer has a header, the header is given to TeX before the region itself. The buffer's header is all lines between the strings defined by `tex-start-of-header' and `tex-end-of-header' inclusive. The header must start in the first 100 lines of the buffer. The value of `tex-trailer' is given to TeX as input after the region. The value of `tex-command' specifies the command to use to run TeX." (interactive "r") (if (tex-shell-running) (tex-kill-job) (tex-start-shell)) (or tex-zap-file (setq tex-zap-file (tex-generate-zap-file-name))) (let* ((temp-buffer (get-buffer-create " TeX-Output-Buffer")) ; Temp file will be written and TeX will be run in zap-directory. ; If the TEXINPUTS file has relative directories or if the region has ; \input of files, this must be the same directory as the file for ; TeX to access the correct inputs. That's why it's safest if ; tex-directory is ".". (zap-directory (file-name-as-directory (expand-file-name tex-directory))) (tex-out-file (concat zap-directory tex-zap-file))) (tex-delete-last-temp-files) ;; Write the new temp file. (save-excursion (save-restriction (widen) (goto-char (point-min)) (forward-line 100) (let ((search-end (point)) (hbeg (point-min)) (hend (point-min)) (default-directory zap-directory)) (goto-char (point-min)) ;; Initialize the temp file with either the header or nothing (if (search-forward tex-start-of-header search-end t) (progn (beginning-of-line) (setq hbeg (point)) ;mark beginning of header (if (search-forward tex-end-of-header nil t) (progn (forward-line 1) (setq hend (point))) ;mark end of header (setq hbeg (point-min))))) ;no header (write-region (min hbeg beg) hend (concat tex-out-file ".tex") nil nil) (write-region (max beg hend) end (concat tex-out-file ".tex") t nil)) (let ((local-tex-trailer tex-trailer)) (set-buffer temp-buffer) (erase-buffer) ;; make sure trailer isn't hidden by a comment (insert-string "\n") (if local-tex-trailer (insert-string local-tex-trailer)) (tex-set-buffer-directory temp-buffer zap-directory) (write-region (point-min) (point-max) (concat tex-out-file ".tex") t nil)))) ;; Record the file name to be deleted afterward. (setq tex-last-temp-file tex-out-file) (tex-send-command tex-shell-cd-command zap-directory) (tex-send-command tex-command tex-out-file) (setq tex-print-file tex-out-file) (setq tex-last-buffer-texed (current-buffer)))) (defun tex-buffer () "Run TeX on current buffer. See \\[tex-region] for more information. Does not save the buffer, so it's useful for trying experimental versions. See \\[tex-file] for an alternative." (interactive) (tex-region (point-min) (point-max))) (defun tex-file () "Prompt to save all buffers and run TeX (or LaTeX) on current buffer's file. This function is more useful than \\[tex-buffer] when you need the `.aux' file of LaTeX to have the correct name." (interactive) (let ((tex-out-file (if (buffer-file-name) (file-name-nondirectory (buffer-file-name)) (error "Buffer does not seem to be associated with any file"))) (file-dir (file-name-directory (buffer-file-name)))) (save-some-buffers) (if (tex-shell-running) (tex-kill-job) (tex-start-shell)) (tex-send-command tex-shell-cd-command file-dir) (tex-send-command tex-command tex-out-file)) (setq tex-last-buffer-texed (current-buffer)) (setq tex-print-file (buffer-file-name))) (defun tex-generate-zap-file-name () "Generate a unique name suitable for use as a file name." ;; Include the shell process number and host name ;; in case there are multiple shells (for same or different user). (format "#tz%d%s" (process-id (get-buffer-process "*tex-shell*")) (tex-strip-dots (system-name)))) (defun tex-strip-dots (s) (setq s (copy-sequence s)) (while (string-match "\\." s) (aset s (match-beginning 0) ?-)) s) ;; This will perhaps be useful for modifying TEXINPUTS. ;; Expand each file name, separated by colons, in the string S. (defun tex-expand-files (s) (let (elts (start 0)) (while (string-match ":" s start) (setq elts (cons (substring s start (match-beginning 0)) elts)) (setq start (match-end 0))) (or (= start 0) (setq elts (cons (substring s start) elts))) (mapconcat 'expand-file-name (nreverse elts) ":"))) (defun tex-shell-running () (and (get-process "tex-shell") (eq (process-status (get-process "tex-shell")) 'run))) (defun tex-kill-job () "Kill the currently running TeX job." (interactive) (quit-process (get-process "tex-shell") t)) (defun tex-recenter-output-buffer (linenum) "Redisplay buffer of TeX job output so that most recent output can be seen. The last line of the buffer is displayed on line LINE of the window, or centered if LINE is nil." (interactive "P") (let ((tex-shell (get-buffer "*tex-shell*")) (old-buffer (current-buffer))) (if (null tex-shell) (message "No TeX output buffer") (pop-to-buffer tex-shell) (bury-buffer tex-shell) (goto-char (point-max)) (recenter (if linenum (prefix-numeric-value linenum) (/ (window-height) 2))) (pop-to-buffer old-buffer)))) (defun tex-print (&optional alt) "Print the .dvi file made by \\[tex-region], \\[tex-buffer] or \\[tex-file]. Runs the shell command defined by tex-dvi-print-command. If prefix argument is provided, use the alternative command, tex-alt-dvi-print-command." (interactive "P") (let ((print-file-name-dvi (tex-append tex-print-file ".dvi")) test-name) (if (and (not (equal (current-buffer) tex-last-buffer-texed)) (file-newer-than-file-p (setq test-name (tex-append (buffer-file-name) ".dvi")) print-file-name-dvi)) (setq print-file-name-dvi test-name)) (if (not (file-exists-p print-file-name-dvi)) (error "No appropriate `.dvi' file could be found") (tex-send-command (if alt tex-alt-dvi-print-command tex-dvi-print-command) print-file-name-dvi t)))) (defun tex-view () "Preview the last `.dvi' file made by running TeX under Emacs. This means, made using \\[tex-region], \\[tex-buffer] or \\[tex-file]. The variable `tex-dvi-view-command' specifies the shell command for preview." (interactive) (let ((tex-dvi-print-command tex-dvi-view-command)) (tex-print))) (defun tex-append (file-name suffix) "Append to FILENAME the suffix SUFFIX, using same algorithm TeX uses. Scans for the first (not last) period. No period is retained immediately before SUFFIX, so normally SUFFIX starts with one." (if (stringp file-name) (let ((file (file-name-nondirectory file-name))) (concat (file-name-directory file-name) (substring file 0 (string-match "\\." file)) suffix)) " ")) (defun tex-show-print-queue () "Show the print queue that \\[tex-print] put your job on. Runs the shell command defined by tex-show-queue-command." (interactive) (if (tex-shell-running) (tex-kill-job) (tex-start-shell)) (tex-send-command tex-show-queue-command)) (defun tex-bibtex-file () "Run BibTeX on the current buffer's file." (interactive) (if (tex-shell-running) (tex-kill-job) (tex-start-shell)) (let ((tex-out-file (tex-append (file-name-nondirectory (buffer-file-name)) "")) (file-dir (file-name-directory (buffer-file-name)))) (tex-send-command tex-shell-cd-command file-dir) (tex-send-command bibtex-command tex-out-file))) (run-hooks 'tex-mode-load-hook) (provide 'tex-mode) From bug-lucid-emacs-request@lucid.com Mon Jul 6 17:51:16 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01327; Mon, 6 Jul 92 17:51:16 PDT Received: by heavens-gate.lucid.com id AA02604g; Mon, 6 Jul 92 17:41:20 PDT Received: from fernwood.mpk.ca.us by heavens-gate.lucid.com id AA02591g; Mon, 6 Jul 92 17:40:45 PDT Received: by fernwood.mpk.ca.us; id AA08867; Mon, 6 Jul 92 16:46:00 -0700 Received: from alba.YP.acad by autodesk.com (4.1/MADMAX-RED-CUCCIA) id AA14046; Mon, 6 Jul 92 16:35:26 PDT Received: by alba.YP.acad (4.1/SMI-4.1) id AA05759; Mon, 6 Jul 92 16:35:26 PDT Date: Mon, 6 Jul 92 16:35:26 PDT From: larsn@autodesk.com (Lars Nyman) Message-Id: <9207062335.AA05759@alba.YP.acad> To: bug-lucid-emacs@lucid.com Subject: remove from mailing list Can you please remove me from the mailing list. Thanks. From bug-lucid-emacs-request@lucid.com Tue Jul 7 08:38:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04286; Tue, 7 Jul 92 08:38:12 PDT Received: by heavens-gate.lucid.com id AA04109g; Tue, 7 Jul 92 08:29:03 PDT Received: from dmi.ens.fr by heavens-gate.lucid.com id AA04102g; Tue, 7 Jul 92 08:28:12 PDT Received: from ella.ens.fr (ella-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0) Date: Tue, 7 Jul 92 17:25:48 +0200 From: polcher%lmd.ens.fr@lucid.com (POLCHER Jan) Message-Id: <9207071525.AA12404@ella.ens.fr> To: bug-lucid-emacs@lucid.com Subject: problems compiling lemacs19.2 on a Sun4 Hello I have problems compiling the lemacs.19.2 on a Sun 4/470. We are running the MIT version of X11R4.18, and we are using the gcc version 2.2.1. After executing build-install I get the following message. gcc -g -Demacs -I./lwlib -c ScreenWidget.c ScreenWidget.c: In function `get_wm_shell': ScreenWidget.c:201: dereferencing pointer to incomplete type *** Error code 1 make: Fatal error: Command failed for target `ScreenWidget.o' I feel a little stupid because I know it should compile on Sparc as the ready-to-run executables are available. They dont work at our site because they dont recognize the DISPLAY ( = hostname:0) variable, problem mentioned in the PROBLEMS file. I hope you can suggest a solution to my problem Thanks Jan Polcher Laboratoire de meteorologie Dynamique 24 rue Lhomond 75231 Paris cedex 05, France polcher@lmd.ens.fr From bug-lucid-emacs-request@lucid.com Tue Jul 7 09:03:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04350; Tue, 7 Jul 92 09:03:26 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA04195g; Tue, 7 Jul 92 08:54:20 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18218; Tue, 7 Jul 92 12:03:24 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18212; Tue, 7 Jul 92 12:03:21 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA26599; Tue, 7 Jul 92 12:03:41 -0400 Path: uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!rutgers!micro-heart-of-gold.mit.edu!bloom-beacon!bloom-picayune.mit.edu!news.mit.edu!eliz From: eliz@ai.mit.edu (Elizabeth Willey) Newsgroups: alt.lucid-emacs.bug Subject: Re: sundry bugs and misfeatures Message-Id: Date: 7 Jul 92 16:45:32 GMT References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> <9207061759.AA09837@watergate.lucid> Organization: MIT Artificial Intelligence Laboratory In-Reply-To: eb%watergate@lucid.com's message of 6 Jul 92 17:59:28 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com eb%watergate@lucid.com (Eric Benson) writes: We aren't offended by Mr. Mlynarik's vitriolic correspondence. We know he's just trying to keep us entertained, and besides, if he vents his spleen on us he's less likely to get in real trouble by venting it on someone who could really damage his career! If you want to see a real flame, look at terminal.el. Richard, I think you`re losing your edge. Mr Benson, you neglected to point out whether or not your opinion represented that of Lucid, Inc. Presumably it does. We'll let it go this time, but don't let it happen again. Disclaimers are a vital part of all usenet correspondence and are there for a reason! You also neglected to include smiley faces, contrary to generally-accepted Internet social protocol. If Mr Mlynarik is indeed losing his edge (and longtime mly-watchers will agree that the message which prompted this thread was uncharacteristically mild), it is certainly due to excessive proximity to Lucid, which is in California, which is where Mr Mlynarik has been for the past few months. Too much perfection in weather and Lifestyle will take its toll on even the finest-honed critical mind and blunt its insight, inducing a laid-back, mushy, sensitive attitude concerned less with substance than with style. Whether this phenomenon, often noted before, has overall applications to the US economy in general (in light of the high rate of internal migration to California) and Lucid's products in particular is a topic which ought to be addressed elsewhere, and in depth---perhaps as the subject of a special meeting. From bug-lucid-emacs-request@lucid.com Tue Jul 7 12:27:10 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05094; Tue, 7 Jul 92 12:27:10 PDT Received: by heavens-gate.lucid.com id AA04845g; Tue, 7 Jul 92 12:16:49 PDT Received: from mda.ca (mdavcr.mda.ca) by heavens-gate.lucid.com id AA04841g; Tue, 7 Jul 92 12:16:29 PDT Received: from jeff.mda.ca by mda.ca (4.1/SMI-4.1-DNI) id AA23706; Tue, 7 Jul 92 12:24:13 PDT Date: Tue, 7 Jul 92 12:24:13 PDT From: rdr%mda.ca@lucid.com (Randolph Roesler) Message-Id: <9207071924.AA23706@ mda.ca> To: bug-gnu-emacs@prep.ai.mit.edu, bug-lucid-emacs@lucid.com Subject: Beef about the way keys are bound in emacs I am always frustrated by the way in which keys are bound inside emacs. Here is an example .... On my xterm, I have both a Del(ete) Key and a Backspace Key. I happen to like having backspace delete the character before the cursor (usually, the character I just typed), and Delete deleting the character the cursor is on (the character after the point, in emacs terms). So, I put this in my .emacs file. (global-set-key 'delete 'delete-char) (global-set-key 'backspace 'delete-backward-char) Now this works fine, except in c-mode, c++-mode, lisp-mode ..... because all these modes bind actions directly to keys, i.e. (define-key c-mode-map "\177" 'backward-delete-char-untabify) So now I need to rebind delete and backspace in very mode map, but, most of these modes are auto-load'ed .... A better system would be for people to define things arround a action type system .... (define-action c-mode-map 'backspace-action 'backward-delete-char-untabify) (define-action global-map 'delete-action 'delete-char) and standard emacs would define (define-key "\177" 'backspace-action) And then every body who wants can rebind keys only once .... (define-key `backspace `backspace-action) (define-key `delete `delete-action) PS. How I got around my problem of having to redefine keys in many modes was to write the following into my .emacs file (defun catch-auto-load ( file forms ) (setq after-load-alist (append after-load-alist (list (cons file forms))))) (catch-auto-load "c++-mode" (list '(define-key c++-mode-map 'backspace 'backward-delete-char-untabify) '(define-key c++-mode-map 'delete 'delete-char))) Randy Roesler MacDonald Dettwiler & Assc. Ph. 604-278-3411 Fax. 604-278-2936 13800 Commerce Parkway, email ...!uunet!van-bc!mdavcr!rdr Richmond BC Canada rdr%mda.ca@wimsey.bc.ca or rdr@mda.ca V6V 2J3 From bug-lucid-emacs-request@lucid.com Tue Jul 7 19:11:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06244; Tue, 7 Jul 92 19:11:02 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA06335g; Tue, 7 Jul 92 19:02:20 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20280; Tue, 7 Jul 92 22:11:29 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA20274; Tue, 7 Jul 92 22:11:28 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA04030; Tue, 7 Jul 92 22:11:52 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!darwin.sura.net!udel!louie!hercules.cis.udel.edu!carroll From: carroll@hercules.cis.udel.edu (Mark C. Carroll) Subject: Window Shrinkage bug Message-Id: <1992Jul8.020525.18484@udel.edu> Organization: University of Delaware, Newark Date: Wed, 8 Jul 1992 02:05:25 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I've got 19.2 installed on our system with a _very_ small number of users. One of the few people using it has on three occasions had very strange window behavior, which I've managed to witness. At random times, without any provocation, the lemacs window shrinks to one pixel wide or one pixel high, and the emacs process within it seems to die. (We can't see what's going on inside of it, but it doesn't respond to any kind of emacs command.) No clue of what could be causing it... -- || Mark Craig Carroll: ||"Don't try to tell me there's no reason || Univ of Delaware, Dept of CIS|| for any moment in time, for every memory || Grad Student/Labstaff Hacker || of mine. Those years are lines of color on || carroll@udel.edu || my face, the past is warpaint"-Happy Rhodes From bug-lucid-emacs-request@lucid.com Wed Jul 8 01:18:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07293; Wed, 8 Jul 92 01:18:25 PDT Received: by heavens-gate.lucid.com id AA06864g; Wed, 8 Jul 92 01:09:55 PDT Received: from mescal.NOC.Vitalink.COM by heavens-gate.lucid.com id AA06860g; Wed, 8 Jul 92 01:09:43 PDT Received: by mescal.NOC.Vitalink.COM with UUCP id AA06717 (5.65c/IDA-1.4.4 for bug-lucid-emacs@lucid.com); Wed, 8 Jul 1992 01:12:32 -0700 Received: by wsrcc.com id AA15250 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Wed, 8 Jul 1992 01:13:09 -0700 Date: Wed, 8 Jul 1992 01:13:09 -0700 From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Message-Id: <199207080813.AA15250@wsrcc.com> To: bug-lucid-emacs@lucid.com Subject: Re: Window Shrinkage bug Newsgroups: list.lucid-emacs.bug References: <1992Jul8.020525.18484@udel.edu> Organization: W S Rupprecht Computer Consulting, Fremont CA >At random times, without any provocation, the lemacs window shrinks to >one pixel wide or one pixel high, and the emacs process within it >seems to die. (We can't see what's going on inside of it, but it doesn't >respond to any kind of emacs command.) I can get lemacs to *expand* and die a horrible death. (Sparc SLC/SunOS 4.1/gcc 2.2.2/X11R5p12/twm) To recreate: 1) hack the time-filter to do a gc. (not a requirement, just speeds the process up). 2) start the modeline time running with this hacked filter. 3) control-Z emacs, iconifying it. 4) at some point the icon name will change from *scratch* (or whatever buffer you were in) to emacs@machine.domain). 5) wait for the next couple of gcs. 6) open up the emacs icon 7) push the twm resize button but don't drag. Read the size from the top left. The size will often be 80x3000. Emacs is effectively bloated and dead at this point with ~20megs under its belt. It may still respond to the commands but the system will soon run out of memory. (I never did figure out how to do a ulimit from inside gdb.) Note this only happens on a \C-Z iconification, never on a twm iconification. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Wed Jul 8 04:13:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08202; Wed, 8 Jul 92 04:13:39 PDT Received: by heavens-gate.lucid.com id AA07069g; Wed, 8 Jul 92 04:04:55 PDT Received: from sun2.nsfnet-relay.ac.uk by heavens-gate.lucid.com id AA07065g; Wed, 8 Jul 92 04:04:42 PDT Via: uk.ac.city.cs; Wed, 8 Jul 1992 12:13:47 +0100 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.barney.cs.city.ac.uk.sun4.40 via MS.5.6.barney.cs.city.ac.uk.sun4_40; Wed, 8 Jul 1992 12:16:39 +0100 (BST) Message-Id: Date: Wed, 8 Jul 1992 12:16:39 +0100 (BST) From: Andy Whitcroft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bug-lucid-emacs@lucid.com Subject: Lemacs 19.1 We have a number of users here that use the EVI mode as a VI emulation. With this emulation loaded and attempting to use an ANGE-FTP style file name with ange-ftp loaded the lemacs session imediatly dumps core as below. Has anyone seen this behaviour? #0 0x4b84 in pixel_to_glyph_translation () #1 0x15c58 in event_pixel_translation () #2 0x15cc4 in Fevent_window () #3 0x5f700 in Ffuncall () #4 0x71378 in Fbyte_code () #5 0x5fcb8 in funcall_lambda () #6 0x5f850 in Ffuncall () #7 0x5f258 in call1 () #8 0x1832c in wait_delaying_user_input () #9 0x19534 in Fdispatch_event () #10 0x31dec in command_loop_1 () #11 0x5dda0 in internal_condition_case () #12 0x31a44 in command_loop_2 () #13 0x5d8f4 in internal_catch () #14 0x319bc in command_loop () #15 0x31598 in recursive_edit_1 () #16 0x411f8 in read_minibuf () #17 0x415b0 in Fread_from_minibuffer () #18 0x416a0 in Fread_string () #19 0x5f724 in Ffuncall () #20 0x71378 in Fbyte_code () #21 0x5fcb8 in funcall_lambda () #22 0x5f850 in Ffuncall () #23 0x71378 in Fbyte_code () #24 0x5fcb8 in funcall_lambda () #25 0x5f850 in Ffuncall () #26 0x5f1e8 in apply1 () #27 0x5b670 in Fcall_interactively () #28 0x32004 in Fcommand_execute () #29 0x19374 in cancel_echoing () #30 0x1901c in cancel_echoing () #31 0x182c0 in wait_delaying_user_input () #32 0x19534 in Fdispatch_event () #33 0x31dec in command_loop_1 () #34 0x5dda0 in internal_condition_case () #35 0x31a44 in command_loop_2 () #36 0x5d8f4 in internal_catch () #37 0x319f0 in command_loop () #38 0x31598 in recursive_edit_1 () #39 0x31688 in Frecursive_edit () #40 0x30dcc in main () Andy. Andy Whitcroft E-mail: andy@cs.city.ac.uk (MIME & ATK) Systems Architecture Research Centre, Tel: +44 71 477 8000 x8551 City University, London, UK. Fax: +44 71 477 8587 From bug-lucid-emacs-request@lucid.com Wed Jul 8 05:54:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08476; Wed, 8 Jul 92 05:54:59 PDT Received: by heavens-gate.lucid.com id AA07223g; Wed, 8 Jul 92 05:45:26 PDT Received: from dmi.ens.fr by heavens-gate.lucid.com id AA07219g; Wed, 8 Jul 92 05:45:11 PDT Received: from ella.ens.fr (ella-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0) Date: Wed, 8 Jul 92 14:43:33 +0200 From: polcher%lmd.ens.fr@lucid.com (POLCHER Jan) Message-Id: <9207081243.AA24997@ella.ens.fr> To: bug-lucid-emacs@lucid.com Subject: adding me to you mailing list Could you please add me to your mailing lists add subscribe Jan Polcher Laboratoire de meteorologie Dynamique 24 rue Lhomond 75231 Paris cedex 05 FRANCE From bug-lucid-emacs-request@lucid.com Wed Jul 8 09:06:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09085; Wed, 8 Jul 92 09:06:39 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA07635g; Wed, 8 Jul 92 08:56:10 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA16361; Wed, 8 Jul 92 12:05:20 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA16355; Wed, 8 Jul 92 12:05:10 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA11998; Wed, 8 Jul 92 12:05:41 -0400 Path: uunet!spool.mu.edu!agate!stanford.edu!rutgers!micro-heart-of-gold.mit.edu!xn.ll.mit.edu!xn!haydens From: haydens@bullwinkle.juliet.ll.mit.edu (Hayden Schultz x3685 g42) Newsgroups: alt.lucid-emacs.bug Subject: unexec problem bulding lemacs Message-Id: Date: 8 Jul 92 15:41:24 GMT Reply-To: haydens@juliet.ll.mit.edu Distribution: alt.lucid-emacs.bug Organization: M.I.T. Lincoln Lab - Group 42 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com After quite a bit of messing around I *finally* got a version of lemacs for the SGI to compile, link, and almost dump. I seem to be having a problem in unexecmips. The following happens: ... Loading site-load... Loading version.el... Loading bytecomp-runtime... Finding pointers to doc strings... Finding pointers to doc strings...done Loading site-init... Dumping under names xemacs and emacs-19.2.2-Lucid unexec: 9 sections found instead of 10. Then when I try to run xemacs, I get the following (possibly unrelated) error message: emacs: Terminal type invisible is not defined. After browsing through unexecmips.c, I can't see how it could ever find 10 sections. I've clipped out the appropriate section of the code. Note that i is set to 0, and then since CHECK_SCNHDR is called 9 times, i can't get bigger than 9. Anyone know what to do about that? #define CHECK_SCNHDR(ptr, name, flags) \ if (strcmp (hdr.section[i].s_name, name) == 0) \ { \ if (hdr.section[i].s_flags != flags) \ fprintf (stderr, "unexec: %x flags (%x expected) in %s section.\n", \ hdr.section[i].s_flags, flags, name); \ ptr = hdr.section + i; \ i += 1; \ } \ else \ ptr = NULL; i = 0; CHECK_SCNHDR (text_section, _TEXT, STYP_TEXT); CHECK_SCNHDR (init_section, _INIT, STYP_INIT); CHECK_SCNHDR (rdata_section, _RDATA, STYP_RDATA); CHECK_SCNHDR (data_section, _DATA, STYP_DATA); #ifdef _LIT8 CHECK_SCNHDR (lit8_section, _LIT8, STYP_LIT8); CHECK_SCNHDR (lit4_section, _LIT4, STYP_LIT4); #endif /* _LIT8 */ CHECK_SCNHDR (sdata_section, _SDATA, STYP_SDATA); CHECK_SCNHDR (sbss_section, _SBSS, STYP_SBSS); CHECK_SCNHDR (bss_section, _BSS, STYP_BSS); if (i != hdr.fhdr.f_nscns) fprintf (stderr, "unexec: %d sections found instead of %d.\n", i, hdr.fhdr.f_nscns); thanks, Hayden Schultz haydens@juliet.ll.mit.edu haydens@atc.ll.mit.edu MIT Lincoln Lab From bug-lucid-emacs-request@lucid.com Wed Jul 8 09:47:53 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09225; Wed, 8 Jul 92 09:47:53 PDT Received: by heavens-gate.lucid.com id AA07791g; Wed, 8 Jul 92 09:39:18 PDT Received: from liasun6.epfl.ch by heavens-gate.lucid.com id AA07786g; Wed, 8 Jul 92 09:38:24 PDT Received: by liasun6.epfl.ch (/\==/\ Smail3.1.25.1 #25.42) id ; Wed, 8 Jul 92 18:47 MET DST Message-Id: Date: Wed, 8 Jul 92 18:47 MET DST From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: haydens@juliet.ll.mit.edu Cc: bug-lucid-emacs@lucid.com Subject: unexec problem bulding lemacs Newsgroups: alt.lucid-emacs.bug In-Reply-To: References: Hayden Schultz x3685 g writes: > > Dumping under names xemacs and emacs-19.2.2-Lucid > unexec: 9 sections found instead of 10. This is in fact a (harmless?) problem in unexmips.c. Use the one from GNU Emacs 18.58 instead. If you want to strip xemacs, you also have to apply a small patch which has appeared in the News a couple times (see the included message at the end). > Then when I try to run xemacs, I get the following (possibly > unrelated) error message: > > emacs: Terminal type invisible is not defined. This is indeed unrelated. Adding "termcap.o" to the #ifdef TERMINFO variant of the definition of termcapobj in [xy]makefile solves the problem. -- Simon. -------------- From: scotth@hoshi.corp.sgi.com (Scott Henry) Subject: Patch to Gnu Emacs 18.58 to run stripped under Irix 4.0.1 Message-ID: Nntp-Posting-Host: hoshi.corp.sgi.com Organization: Silicon Graphics Inc, Mountain View, CA Date: Tue, 3 Mar 1992 21:11:27 GMT I can't find the message to followup to, but here is a little patch that allows emacs to exec when stripped. Funny, I thought I remember posting this patch back when Irix 3.3 hit the streets. Same fix, anyway. It's an unexec error that the loader is now intolerant of. *** src/unexmips.c.~1~ Fri Oct 25 11:55:27 1991 --- src/unexmips.c Tue Mar 3 10:16:20 1992 *************** *** 190,196 **** rdata_section->s_size = data_start - DATA_START; data_section->s_vaddr = data_start; data_section->s_paddr = data_start; ! data_section->s_size = brk - DATA_START; data_section->s_scnptr = rdata_section->s_scnptr + rdata_section->s_size; vaddr = data_section->s_vaddr + data_section->s_size; scnptr = data_section->s_scnptr + data_section->s_size; --- 190,196 ---- rdata_section->s_size = data_start - DATA_START; data_section->s_vaddr = data_start; data_section->s_paddr = data_start; ! data_section->s_size = brk - data_start; data_section->s_scnptr = rdata_section->s_scnptr + rdata_section->s_size; vaddr = data_section->s_vaddr + data_section->s_size; scnptr = data_section->s_scnptr + data_section->s_size; This is unsupported software, Silicon Graphics doesn't make any warrantly, etc, etc. I've only tested this patch under (what is supposed to be) the released Irix version 4.0.2. =-=-= -- Scott Henry / Traveller on Dragon Wings Networking Services, / Help! My disclaimer is missing! Silicon Graphics, Inc / Bureaucracy is the enemy of success. From bug-lucid-emacs-request@lucid.com Wed Jul 8 10:44:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09374; Wed, 8 Jul 92 10:44:36 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08005g; Wed, 8 Jul 92 10:35:14 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA23787; Wed, 8 Jul 92 13:44:17 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA23781; Wed, 8 Jul 92 13:44:16 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA12969; Wed, 8 Jul 92 13:44:48 -0400 Path: uunet!dtix!darwin.sura.net!udel!louie!hercules.cis.udel.edu!carroll From: carroll@hercules.cis.udel.edu (Mark C. Carroll) Newsgroups: alt.lucid-emacs.bug Subject: Re: Window Shrinkage bug Message-Id: <1992Jul8.173424.22467@udel.edu> Date: 8 Jul 92 17:34:24 GMT References: <1992Jul8.020525.18484@udel.edu> Organization: University of Delaware, Newark Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <1992Jul8.020525.18484@udel.edu> carroll@hercules.cis.udel.edu (Mark C. Carroll) writes: >I've got 19.2 installed on our system with a _very_ small number of >users. One of the few people using it has on three occasions had very >strange window behavior, which I've managed to witness. > >At random times, without any provocation, the lemacs window shrinks to >one pixel wide or one pixel high, and the emacs process within it >seems to die. (We can't see what's going on inside of it, but it doesn't >respond to any kind of emacs command.) > >No clue of what could be causing it... Sorry, forgot to include system configuration: System: Sun Sparcstation. The bug has shown up on an SLC, an ILC, and a Sparc2. OS Version: Sunos 4.0.1. XWindows version: X11R5. I compiled it with -O2. -- || Mark Craig Carroll: || "Only love || Univ of Delaware, Dept of CIS|| can make love" || Grad Student/Labstaff Hacker || -Peter Gabriel || carroll@udel.edu || From bug-lucid-emacs-request@lucid.com Thu Jul 9 00:22:15 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11384; Thu, 9 Jul 92 00:22:15 PDT Received: by heavens-gate.lucid.com id AA02066g; Thu, 9 Jul 92 00:09:25 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA02062g; Thu, 9 Jul 92 00:09:12 PDT Received: by moebius.loria.fr id AA17745 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Thu, 9 Jul 92 09:16:58 +0200 Date: Thu, 9 Jul 92 09:16:58 +0200 From: Guido Bosch Message-Id: <9207090716.AA17745@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: problems with popper.el and `enlarge-window' Reply-To: Guido BOSCH It seems that in Lucid Emacs the functions `{enlarge|shrink}-window' produce the error "Won't change only window" if the current screen is not split up in at least two windows. This could be considered as a feature (even if it is not documented in the functions docstrings). But how about this? M-0 C-x ^ (enlarge-window 0) This occurs often when using popper.el from the ILISP package. ------------------------- *Backtrace* ----------------------- Signalling: (error "Won't change only window") enlarge-window(0) popper-bury-output(t) popper-show-output(#) popper-show(#) minibuffer-complete-word() * call-interactively(minibuffer-complete-word) call-interactively(find-file) ------------------------------------------------------------- Where's the bug? In popper.el or in `enlarge-window'? Guido From bug-lucid-emacs-request@lucid.com Thu Jul 9 10:23:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13275; Thu, 9 Jul 92 10:23:45 PDT Received: by heavens-gate.lucid.com id AA04267g; Thu, 9 Jul 92 10:15:32 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA04229g; Thu, 9 Jul 92 10:04:28 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11044; Thu, 9 Jul 92 13:11:47 -0400 Received: from jclark.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 123422.15862; Thu, 9 Jul 1992 12:34:22 EDT Received: by jclark.com (4.1/SMI-4.1) id AA00406; Thu, 9 Jul 92 17:29:25 BST Date: Thu, 9 Jul 92 17:29:25 BST From: jjc@jclark.com (James Clark) Message-Id: <9207091629.AA00406@jclark.com> To: bug-lucid-emacs@lucid.com Subject: mail-strip-quoted-names Using lemacs 19.2, I get the following error when I type SPC in gnus Newsgroup mode: Signalling: (wrong-type-argument syntax-table-p nil) set-syntax-table(nil) mail-strip-quoted-names("staffan@ca.serum.kodak.com (Kenneth Staffan (x37507))") gnus-optional-lines-and-from([25962 "Re: Cool Whip [tm]" "staffan@ca.serum.kodak.com (Kenneth Staffan (x37507))" nil 14 "7 Jul 92 14:22:14 GMT" "<1992Jul7.142214.1571@clpd.kodak.com>" "<1992Jul4.162113.718@ads.com> <9146@emory.mathcs.emory.edu> <1149@stake.DaytonOH.NCR.COM>"]) gnus-Subject-prepare-threads() gnus-Subject-prepare() gnus-Subject-read-group("rec.food.cooking" nil nil) gnus-Group-read-group(nil) call-interactively(gnus-Group-read-group) The problem is that mail-strip-quoted-names assumes that lisp-mode-syntax-table has been initialized. A workaround is to evaluate (lisp-mode). James Clark jjc@jclark.com From bug-lucid-emacs-request@lucid.com Fri Jul 10 03:40:16 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16216; Fri, 10 Jul 92 03:40:16 PDT Received: by heavens-gate.lucid.com id AA06809g; Fri, 10 Jul 92 03:29:49 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA06805g; Fri, 10 Jul 92 03:29:04 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29263; Fri, 10 Jul 92 06:38:12 -0400 Received: from jclark.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 063632.11134; Fri, 10 Jul 1992 06:36:32 EDT Received: by jclark.com (4.1/SMI-4.1) id AA06374; Fri, 10 Jul 92 11:26:43 BST Date: Fri, 10 Jul 92 11:26:43 BST From: jjc@jclark.com (James Clark) Message-Id: <9207101026.AA06374@jclark.com> To: bug-lucid-emacs@lucid.com Subject: mail-yank-original With lemacs 19.2, when I do C-c C-y in mail mode, the yanked message is active (I have zmacs-regions t). This seems undesirable to me: a normal yank doesn't make the yanked text active. James Clark jjc@jclark.com From bug-lucid-emacs-request@lucid.com Fri Jul 10 06:32:09 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16788; Fri, 10 Jul 92 06:32:09 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA07106g; Fri, 10 Jul 92 06:21:36 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA22796; Fri, 10 Jul 92 09:30:50 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA22790; Fri, 10 Jul 92 09:30:48 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA01939; Fri, 10 Jul 92 09:31:40 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!darwin.sura.net!udel!louie!udel.edu!neal From: neal@neal.ctd.comsat.com (Neal Becker) Subject: lemacs1.2 on HP Message-Id: Organization: COMSAT Labs Distribution: alt Date: Fri, 10 Jul 1992 14:24:51 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com After #undef'ing LISP_FLOAT_TYPE (reluctantly) only one more problem needed to be solved to get lemacs to pass the linker. gmalloc.o still referred to getpagesize(). It seems that getpagesize.h is supposed to take care of this, but it looks like gmalloc.c doesn't include it? I added the #include, but still no luck. Because gmalloc.c has a declaration of __getpagesize() I needed to make a static function (not a macro) in getpagesize.h to get this to compile. Now it links! But what does this mean? ---------------------------------- gnumake -f xmakefile all ./temacs -batch -l inc-vers Loading inc-vers... Loading startup... Symbol's value as variable is void: lock-directorygnumake: *** [release] Error 255 *** Error code 1 Stop. ----------------------------------- Is this a simple config problem or is the code completely broken? From bug-lucid-emacs-request@lucid.com Fri Jul 10 07:48:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16986; Fri, 10 Jul 92 07:48:37 PDT Received: by heavens-gate.lucid.com id AA07249g; Fri, 10 Jul 92 07:37:52 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA07245g; Fri, 10 Jul 92 07:37:39 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02402; Fri, 10 Jul 92 07:46:56 PDT Date: Fri, 10 Jul 92 07:46:56 PDT Message-Id: <9207101446.AA02402@thalidomide.lucid> X-Windows: Flakey and built to stay that way. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: neal@neal.ctd.comsat.com (Neal Becker) Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs1.2 on HP In-Reply-To: Neal Becker's message of Fri 10-Jul-92 14:24:51 GMT References: GNU malloc doesn't seem to be very portable. If you have trouble with it, give up and use the system malloc instead. The lock-directory error means that there is lisp code which can't cope with emacs being compiled without #define CLASH_DETECTION. -- Jamie From bug-lucid-emacs-request@lucid.com Fri Jul 10 07:54:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16999; Fri, 10 Jul 92 07:54:35 PDT Received: by heavens-gate.lucid.com id AA07278g; Fri, 10 Jul 92 07:47:04 PDT Received: from neal.ctd.comsat.com by heavens-gate.lucid.com id AA07274g; Fri, 10 Jul 92 07:45:56 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Fri, 10 Jul 92 10:55 EDT Message-Id: Date: Fri, 10 Jul 92 10:55 EDT From: neal@ctd.comsat.com (Neal Becker) To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Fri, 10 Jul 92 07:46:56 PDT <9207101446.AA02402@thalidomide.lucid> Subject: lemacs1.2 on HP >>>>> On Fri, 10 Jul 92 07:46:56 PDT, Jamie Zawinski said: Jamie> GNU malloc doesn't seem to be very portable. If you have trouble with it, Jamie> give up and use the system malloc instead. I guess this refers to problems with getpagesize()? I finally got this fixed, although I doubt it was worth the effort to use gmalloc. Jamie> The lock-directory error means that there is lisp code which can't cope Jamie> with emacs being compiled without #define CLASH_DETECTION. I'll try this. But this was never needed for emacs-18.58, so what's different? From bug-lucid-emacs-request@lucid.com Fri Jul 10 08:06:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17066; Fri, 10 Jul 92 08:06:41 PDT Received: by heavens-gate.lucid.com id AA07305g; Fri, 10 Jul 92 07:57:39 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA07293g; Fri, 10 Jul 92 07:53:40 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02425; Fri, 10 Jul 92 08:02:57 PDT Date: Fri, 10 Jul 92 08:02:57 PDT Message-Id: <9207101502.AA02425@thalidomide.lucid> X-Windows: There's got to be a better way. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: neal@ctd.comsat.com (Neal Becker) Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs1.2 on HP In-Reply-To: Neal Becker's message of Fri 10-Jul-92 10:55 EDT References: <9207101446.AA02402@thalidomide.lucid> In message Neal Becker wrote: > >>>>>> On Fri, 10 Jul 92 07:46:56 PDT, Jamie Zawinski said: > > Jamie> GNU malloc doesn't seem to be very portable. If you have > Jamie> trouble with it, give up and use the system malloc instead. > > I guess this refers to problems with getpagesize()? I finally got > this fixed, although I doubt it was worth the effort to use gmalloc. Other people have had trouble with gmalloc, but perhaps it was just the getpagesize problem. I don't think anyone else tracked it as far as you did. > Jamie> The lock-directory error means that there is lisp code which > Jamie> can't cope with emacs being compiled without #define > CLASH_DETECTION. > > I'll try this. But this was never needed for emacs-18.58, so what's > different? It shouldn't be necessary, it's a bug. The problem was in the new dynamically-generating-load-path code we added to startup.el. It's fixed in 19.3 (not released yet.) (BTW, many of the emacs 18.57 -> 18.58 improvements are not in lemacs 19.1, because the emacs 18 and emacs 19 development has been going on in parallel, and we diverged from the main emacs source tree at around the time 18.58 was being readied for release.) -- Jamie From bug-lucid-emacs-request@lucid.com Fri Jul 10 08:17:43 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17103; Fri, 10 Jul 92 08:17:43 PDT Received: by heavens-gate.lucid.com id AA07357g; Fri, 10 Jul 92 08:09:59 PDT Received: from neal.ctd.comsat.com by heavens-gate.lucid.com id AA07347g; Fri, 10 Jul 92 08:07:18 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Fri, 10 Jul 92 11:16 EDT Message-Id: Date: Fri, 10 Jul 92 11:16 EDT From: neal@ctd.comsat.com (Neal Becker) To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Fri, 10 Jul 92 08:02:57 PDT <9207101502.AA02425@thalidomide.lucid> Subject: lemacs1.2 on HP Well things are looking up! Just one more problem. Can you help me with this? (I don't understand it): -------------------------------- gnumake -f xmakefile all rm -f ../etc/DOC ../etc/make-docfile dispnew.o screen.o scroll.o xdisp.o window.o events.o event-alloc.o event-stream.o term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexhp9k800.o mocklisp.o bytecode.o process.o callproc.o environ.o doprnt.o extents.o faces.o elhash.o hash.o realpath.o ../lisp/prim/simple.elc ../lisp/prim/help.elc ../lisp/prim/files.elc ../lisp/prim/window.elc ../lisp/prim/indent.elc ../lisp/prim/loaddefs.el ../lisp/paths.el ../lisp/prim/startup.elc ../lisp/prim/lisp.elc ../lisp/prim/page.elc ../lisp/prim/register.elc ../lisp/prim/paragraphs.elc ../lisp/modes/lisp-mode.elc ../lisp/modes/text-mode.elc ../lisp/prim/fill.elc ../lisp/modes/c-mode.elc ../lisp/prim/isearch.elc ../l! isp/prim/replace.elc ../lisp/modes /abbrev.elc ../lisp/prim/faces.elc ../lisp/packages/buff-menu.elc ../lisp/prim/subr.elc ../lisp/bytecomp/bytecomp-runtime.elc ../lisp/packages/lpr.elc ../lisp/packages/compare-w.elc ../lisp/prim/novice.elc ../lisp/x11/x-faces.elc ../lisp/x11/x-iso8859-1.elc ../lisp/x11/x-mouse.elc ../lisp/x11/xselect.elc ../lisp/version.el > ../etc/DOC ./temacs -batch -l inc-vers Loading inc-vers... Loading startup... New Emacs version will be 19.2.1 ./temacs -batch -l loadup.el dump Loading loadup.el... Loading subr... Loading faces... Loading loaddefs.el... Loading simple... Loading help... Loading files... Loading indent... Loading window... Loading paths.el... Loading startup... Loading lisp... Loading page... Loading register... Loading paragraphs... Loading lisp-mode... Loading text-mode... Loading fill... Loading c-mode... Loading isearch... Loading replace... Loading abbrev... Loading buff-menu... Loading x-faces... Loading x-iso8859-1... Loading x-mouse... Loading xselect... Loading site-load... Loading version.el... Loading bytecomp-runtime... Finding pointers to doc strings... Finding pointers to doc strings...done Loading site-init... Dumping under names xemacs and emacs-19.2.1-Lucid /a/data/src/gnu/lemacs-19.2/src% xemacs & [1] 21921 /a/data/src/gnu/lemacs-19.2/src% emacs: Terminal type invisible is not defined. ------------------------------------------ This was started up under an emacs shell (term=emacs). From bug-lucid-emacs-request@lucid.com Fri Jul 10 08:53:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17273; Fri, 10 Jul 92 08:53:03 PDT Received: by heavens-gate.lucid.com id AA07417g; Fri, 10 Jul 92 08:42:38 PDT Received: from neal.ctd.comsat.com by heavens-gate.lucid.com id AA07410g; Fri, 10 Jul 92 08:38:52 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Fri, 10 Jul 92 11:48 EDT Message-Id: Date: Fri, 10 Jul 92 11:48 EDT From: neal@ctd.comsat.com (Neal Becker) To: jwz@lucid.com, bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Fri, 10 Jul 92 08:18:53 PDT <9207101518.AA02480@thalidomide.lucid> Subject: lemacs1.2 on HP -- invisible term problem I looked through the archives as you suggested. I saw something about using terminfo.c, but this doesn't look like it will solve my problem. I'm not familiar with this termcap/termlib schism, but it looks to me that some systems have -ltermcap and some have -lterminfo. Actually, HP has both!?! I tried both. No good. Looks to me like the problem is like this one: --------------------------------- From bug-lucid-emacs-request@heavens-gate.lucid.com Fri Jun 5 04:46:55 1992 Return-Path: Received: from lucid.com (heavens-gate.lucid.com) by love-canal. (4.0/SMI-4.0) id AA16880; Fri, 5 Jun 92 04:46:55 PDT Received: by heavens-gate.lucid.com id AA04248g; Fri, 5 Jun 92 04:29:52 PDT Received: from newton.ncsa.uiuc.edu by heavens-gate.lucid.com id AA04244g; Fri, 5 Jun 92 04:29:45 PDT Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA12120 (5.65a/IDA-1.4.2 for bug-lucid-emacs@lucid.com); Fri, 5 Jun 92 06:37:50 -0500 Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI) for @newton.ncsa.uiuc.edu:jwz@lucid.com id AA03345; Fri, 5 Jun 92 06:39:02 -0700 Date: Fri, 5 Jun 92 06:39:02 -0700 From: marca@wintermute.ncsa.uiuc.edu (Marc Andreessen) Message-Id: <9206051339.AA03345@wintermute.ncsa.uiuc.edu> To: bug-lucid-emacs@lucid.com Cc: jwz@lucid.com Subject: v19 on IRIX 4.0.2 Here are some random notes after several hours of trying to port Lucid v19 to IRIX 4.0.2. These notes don't concern the IRIX config files per se; for the most part, I hacked together an s-irix4-0.h from the Epoch sources. [...deleted...] o The bit with the 'invisible' termtype (installed by putenv'ing TERM and TERMCAP) doesn't work as-is under IRIX, as apparently the TERMCAP env variable isn't recognized. I had to actually install a dummy invisible entry into /usr/lib/terminfo to get past that. ------------------------------------------------ This sounds like the same problem on HP. Just one stupid question, what should a dummy invisible entry look like? From bug-lucid-emacs-request@lucid.com Fri Jul 10 10:34:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17582; Fri, 10 Jul 92 10:34:59 PDT Received: by heavens-gate.lucid.com id AA07705g; Fri, 10 Jul 92 10:24:13 PDT Received: from neal.ctd.comsat.com by heavens-gate.lucid.com id AA07691g; Fri, 10 Jul 92 10:21:58 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Fri, 10 Jul 92 13:31 EDT Message-Id: Date: Fri, 10 Jul 92 13:31 EDT From: neal@ctd.comsat.com (Neal Becker) To: bug-lucid-emacs@lucid.com Subject: lemacs1.2 on HP - SUCCESS?? Finally, after disabling code for INVISIBLE_TERMINAL_KLUDGE in emacs.c we compile, link and actually run! Details on request... Looks like we still have some problems though. Seems like messing with the menus makes emacs loose the key focus, and I can't seem to get it back either. From bug-lucid-emacs-request@lucid.com Fri Jul 10 10:46:05 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17646; Fri, 10 Jul 92 10:46:05 PDT Received: by heavens-gate.lucid.com id AA07755g; Fri, 10 Jul 92 10:38:17 PDT Received: from bellcore.bellcore.com by heavens-gate.lucid.com id AA07748g; Fri, 10 Jul 92 10:36:28 PDT Received: from monolith.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA10393; Fri, 10 Jul 92 13:45:41 -0400 Received: from reggae.cam by monolith.bellcore.com (4.0/SMI-4.1) id AA13585; Fri, 10 Jul 92 13:45:39 EDT Date: Fri, 10 Jul 92 13:45:39 EDT From: plm@monolith.bellcore.com (Paul Mowatt) Message-Id: <9207101745.AA13585@monolith.bellcore.com> To: bug-lucid-emacs@lucid.com Subject: Compiling under OSF/1 I am trying to compile lemacs on a mips based DEC workstation running OSF/1. When it gets to "make -f xmakefile", make core dumps (Segment Violation). Does anyone have a solution to this problem? Paul plm@reggae.cam.bellcore.com From bug-lucid-emacs-request@lucid.com Fri Jul 10 14:08:20 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18264; Fri, 10 Jul 92 14:08:20 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08270g; Fri, 10 Jul 92 13:57:25 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02722; Fri, 10 Jul 92 16:58:17 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA02716; Fri, 10 Jul 92 16:58:15 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA12310; Fri, 10 Jul 92 16:59:10 -0400 Path: uunet!spool.mu.edu!uwm.edu!caen!destroyer!gumby!yale!yale.edu!jvnc.net!darwin.sura.net!udel!louie!udel.edu!neal From: neal@neal.ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs1.2 on HP - SUCCESS?? Message-Id: Date: 10 Jul 92 21:32:36 GMT References: Organization: COMSAT Labs In-Reply-To: neal@ctd.comsat.com's message of Fri, 10 Jul 92 13:31 EDT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com It looks like loosing key focus is only a problem with Motif. I built with USE_LUCID with both X11R4 and X11R5 without this problem. You can compile everything with gcc-2.2.2 and use X11R4 without major difficulties. But if you compile with gcc you won't be able to link against X11R5! Seems to be some disagreement about whether const char[] are code or data. Alternatively, anybody got lemacs-1.2 to compile with cc? From bug-lucid-emacs-request@lucid.com Fri Jul 10 19:35:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18941; Fri, 10 Jul 92 19:35:48 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA09331g; Fri, 10 Jul 92 19:25:09 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA17587; Fri, 10 Jul 92 22:34:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA17581; Fri, 10 Jul 92 22:34:18 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA16158; Fri, 10 Jul 92 22:35:16 -0400 Path: uunet!zaphod.mps.ohio-state.edu!rpi!bu.edu!nntp-read!jbw From: jbw@bigbird.bu.edu (Joe Wells) Newsgroups: alt.lucid-emacs.bug Subject: Re: sundry bugs and misfeatures Message-Id: Date: 11 Jul 92 03:26:05 GMT References: <92Jul5.233632pdt.21546@archer.parc.xerox.com> Followup-To: alt.flame Organization: Boston University Computer Science Department In-Reply-To: geoff@flash.bellcore.com's message of 6 Jul 92 17:44:57 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article geoff@flash.bellcore.com (Geoffrey Clemm) writes: Just to make sure anyone new to this newsgroup is not misled by the above "posting" from Mr. Mlynarik, This is *not* the way one communicates on a technical newsgroup. Perhaps a word analogy will make the situation clear. In terms of how welcome they are, "Mr. Mlynarik's complaints" are to "Mr. Clemm's complaints about Mr. Mlynarik's complaints" as "a small bug, eg. a cockroach" is to "one of the monsters from the movie Aliens that plants its larvae inside live humans which then grow and eat their way out". Yours for better Emacsing, Joe Wells "I seem to have run into a novel problem with the electronic mail. My computer's demanding an electronic female. Preferably brunette." -- Bart Schaefer From bug-lucid-emacs-request@lucid.com Sat Jul 11 16:33:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA21685; Sat, 11 Jul 92 16:33:12 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10702g; Sat, 11 Jul 92 16:21:42 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02703; Sat, 11 Jul 92 19:30:58 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA02697; Sat, 11 Jul 92 19:30:56 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA25394; Sat, 11 Jul 92 19:32:04 -0400 Path: uunet!decwrl!infopiz!lupine!mellon Newsgroups: alt.lucid-emacs.bug Subject: Re: mail-strip-quoted-names Message-Id: From: mellon@ncd.com (Ted Lemon) Date: 11 Jul 92 20:25:42 GMT References: <9207091629.AA00406@jclark.com> Organization: Network Computing Devices, Inc. In-Reply-To: jjc@jclark.com's message of 9 Jul 92 16:29:25 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Actually, it seems like quite a few things assume that lisp-mode-syntax-table will be initialized - I've noticed this problem too. It might be a win to just initialize that table to begin with, as I think was the case in version 18. _MelloN_ -- mellon@ncd.com Member, League for Programming Freedom | To learn how software patents could cost you your right to program, contact the LPF - league@prep.ai.mit.edu From bug-lucid-emacs-request@lucid.com Mon Jul 13 11:23:11 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27351; Mon, 13 Jul 92 11:23:11 PDT Received: by heavens-gate.lucid.com id AA14063g; Mon, 13 Jul 92 11:12:47 PDT Received: from neal.ctd.comsat.com by heavens-gate.lucid.com id AA14026g; Mon, 13 Jul 92 11:04:50 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Mon, 13 Jul 92 14:13 EDT Message-Id: Date: Mon, 13 Jul 92 14:13 EDT From: neal@ctd.comsat.com (Neal Becker) To: ange@hplb.hpl.hp.com, bug-lucid-emacs@lucid.com In-Reply-To: Andy Norman's message of Fri, 10 Jul 92 23:18:06 BST <9207102218.AA07309@anorman.hpl.hp.com> Subject: Diffs for lemacs-19.2 for HP9000/7xx HPUX 8.07 I'm better at fixing code than at documenting what I did, but I hope this will do it: ------------------------------------------------------------- *** lemacs-19.2/src/config.h Thu Jun 18 19:17:19 1992 --- lemacs-19.2-hp/src/config.h Mon Jul 13 09:27:47 1992 *************** *** 30,36 **** the s- files to use for them. See s-template.h for documentation on writing s- files. */ ! #include "s/s-sunos4.h" /* Include here a m- file that describes the machine and system you use. See the file ../etc/MACHINES for a list of machines and the names of --- 30,36 ---- the s- files to use for them. See s-template.h for documentation on writing s- files. */ ! #include "s/s-hpux8.h" /* Include here a m- file that describes the machine and system you use. See the file ../etc/MACHINES for a list of machines and the names of *************** *** 37,43 **** the m- files to use for them. See m-template.h for info on what m- files should define. */ ! #include "m/m-sparc.h" /* Load in the conversion definitions if this system needs them and the source file being compiled has not --- 37,43 ---- the m- files to use for them. See m-template.h for info on what m- files should define. */ ! #include "m/m-hp9000s800.h" /* Load in the conversion definitions if this system needs them and the source file being compiled has not *************** *** 99,114 **** /* Define LISP_FLOAT_TYPE if you want emacs to support floating-point numbers. */ ! #define LISP_FLOAT_TYPE /* Define GNU_MALLOC if you want to use the *new* GNU memory allocator. If you have trouble with _malloc being multiply-defined, or if you're on a NeXT (or possibly MACH in general) comment out the next four lines. */ ! #ifdef SYSTEM_MALLOC #undef SYSTEM_MALLOC #endif #define GNU_MALLOC /* define NEED_STRDUP if your system doesn't have the strdup() function. */ --- 99,115 ---- /* Define LISP_FLOAT_TYPE if you want emacs to support floating-point numbers. */ ! /* #define LISP_FLOAT_TYPE */ /* Define GNU_MALLOC if you want to use the *new* GNU memory allocator. If you have trouble with _malloc being multiply-defined, or if you're on a NeXT (or possibly MACH in general) comment out the next four lines. */ ! /* #ifdef SYSTEM_MALLOC #undef SYSTEM_MALLOC #endif #define GNU_MALLOC + */ /* define NEED_STRDUP if your system doesn't have the strdup() function. */ *************** *** 152,158 **** /* Define this if your system does not include the realpath() system call. */ ! /* #define NEED_REALPATH */ #ifdef THIS_IS_YMAKEFILE --- 153,159 ---- /* Define this if your system does not include the realpath() system call. */ ! #define NEED_REALPATH #ifdef THIS_IS_YMAKEFILE *************** *** 161,167 **** Otherwise, "cc" will be used. You -must- use an ANSI C compiler. */ ! #define USE_GCC /* #define USE_LCC */ /* If you have defined USE_MOTIF in the lwlib Imakefile, then you must define --- 162,168 ---- Otherwise, "cc" will be used. You -must- use an ANSI C compiler. */ ! /* #define USE_GCC */ /* #define USE_LCC */ /* If you have defined USE_MOTIF in the lwlib Imakefile, then you must define *************** *** 179,185 **** X libraries aren't in a place that your loader can find on its own, you might want to add "-L/..." or something similar. */ ! /* #define LD_SWITCH_SITE -L/x11r4/usr.`arch`/lib */ /* Define C_SWITCH_SITE to contain any special flags your compiler may need. For instance, if you've defined HAVE_X_WINDOWS above and your --- 180,186 ---- X libraries aren't in a place that your loader can find on its own, you might want to add "-L/..." or something similar. */ ! #define LD_SWITCH_SITE -a archive -L/usr/lib/X11R4 /* Define C_SWITCH_SITE to contain any special flags your compiler may need. For instance, if you've defined HAVE_X_WINDOWS above and your *************** *** 186,192 **** X include files aren't in a place that your compiler can find on its own, you might want to add "-I/..." or something similar. */ ! /* #define C_SWITCH_SITE -I/cadillacgnu/gcc-include -I/x11r4/usr/include */ #ifdef USE_GCC /* Depending on how GCC is installed, you may need to add the gcc library --- 187,193 ---- X include files aren't in a place that your compiler can find on its own, you might want to add "-I/..." or something similar. */ ! #define C_SWITCH_SITE -Aa -D_HPUX_SOURCE -Dunix -I/usr/include/X11R4 #ifdef USE_GCC /* Depending on how GCC is installed, you may need to add the gcc library *************** *** 193,199 **** here. This could also go in LD_SWITCH_SITE. If you get errors about __fixunsdfsi or__main being undefined, you probably need to do this. */ ! /* #define LIB_GCC /cadillacgnu/lib/sun4/gcc-gnulib */ #endif /* USE_GCC */ --- 194,200 ---- here. This could also go in LD_SWITCH_SITE. If you get errors about __fixunsdfsi or__main being undefined, you probably need to do this. */ ! #define LIB_GCC -lgcc #endif /* USE_GCC */ diff -r -c lemacs-19.2/src/config.h lemacs-19.2-hp/src/config.hlemacs-19.2/src/data.c lemacs-19.2-hp/src/data.c *** lemacs-19.2/src/data.c Thu Jun 11 22:22:03 1992 --- lemacs-19.2-hp/src/data.c Thu Jul 9 12:53:10 1992 *************** *** 21,26 **** --- 21,27 ---- #include /* For sprintf */ #include + #include "puresize.h" #include "config.h" #include "lisp.h" diff -r -c lemacs-19.2/src/data.c lemacs-19.2-hp/src/data.clemacs-19.2/src/dispnew.c lemacs-19.2-hp/src/dispnew.c *** lemacs-19.2/src/dispnew.c Mon Jun 15 04:31:06 1992 --- lemacs-19.2-hp/src/dispnew.c Fri Jul 10 15:28:09 1992 *************** *** 67,74 **** --- 67,76 ---- #endif + #ifndef __hpux void bzero (); void bcopy (); + #endif #include "termchar.h" #include "termopts.h" *************** *** 1525,1531 **** int detect_input_pending (); int scrolling (); ! int ioctl (); unsigned sleep (); /* int clashes with */ /* At the time this function is called, no line is common --- 1527,1533 ---- int detect_input_pending (); int scrolling (); ! /* int ioctl (); */ unsigned sleep (); /* int clashes with */ /* At the time this function is called, no line is common diff -r -c lemacs-19.2/src/dispnew.c lemacs-19.2-hp/src/dispnew.clemacs-19.2/src/emacs.c lemacs-19.2-hp/src/emacs.c *** lemacs-19.2/src/emacs.c Tue Jun 16 04:34:58 1992 --- lemacs-19.2-hp/src/emacs.c Fri Jul 10 12:31:59 1992 *************** *** 629,636 **** { /* Need to use fresh strings here and not strings from * read-only space */ ! putenv(strdup ("TERM=invisible")); ! putenv(strdup ("TERMCAP=invisible:cm=:co#80:li#24:")); } else { --- 629,636 ---- { /* Need to use fresh strings here and not strings from * read-only space */ ! /* putenv(strdup ("TERM=invisible")); ! putenv(strdup ("TERMCAP=invisible:cm=:co#80:li#24:")); */ } else { diff -r -c lemacs-19.2/src/emacs.c lemacs-19.2-hp/src/emacs.clemacs-19.2/src/events.c lemacs-19.2-hp/src/events.c *** lemacs-19.2/src/events.c Mon Jun 15 04:29:49 1992 --- lemacs-19.2-hp/src/events.c Thu Jul 9 12:35:27 1992 *************** *** 680,686 **** return Qnil; return Qt; case magic_event: ! return (bcmp (XEVENT (o1)->event.magic, XEVENT (o2)->event.magic, sizeof (struct magic_data)) ? Qnil : Qt); --- 680,686 ---- return Qnil; return Qt; case magic_event: ! return (bcmp ((char*)&(XEVENT (o1)->event.magic), (char*)&(XEVENT (o2)->event.magic), sizeof (struct magic_data)) ? Qnil : Qt); diff -r -c lemacs-19.2/src/events.c lemacs-19.2-hp/src/events.clemacs-19.2/src/events.h lemacs-19.2-hp/src/events.h *** lemacs-19.2/src/events.h Mon Jun 15 04:34:33 1992 --- lemacs-19.2-hp/src/events.h Mon Jul 13 09:17:00 1992 *************** *** 216,222 **** struct Lisp_Event; /* assert that these are global... */ ! struct Lisp_Process; struct event_stream { int (*event_pending_p) (int); --- 216,222 ---- struct Lisp_Event; /* assert that these are global... */ ! /* struct Lisp_Process; */ struct event_stream { int (*event_pending_p) (int); diff -r -c lemacs-19.2/src/events.h lemacs-19.2-hp/src/events.hlemacs-19.2/src/fileio.c lemacs-19.2-hp/src/fileio.c *** lemacs-19.2/src/fileio.c Tue Jun 9 00:24:56 1992 --- lemacs-19.2-hp/src/fileio.c Thu Jul 9 12:47:00 1992 *************** *** 57,63 **** #endif /* HAVE_TIMEVAL */ #endif /* not NEED_TIME_H */ ! #ifdef HPUX #include #include #endif --- 57,63 ---- #endif /* HAVE_TIMEVAL */ #endif /* not NEED_TIME_H */ ! #ifdef HPUX_NET #include #include #endif diff -r -c lemacs-19.2/src/fileio.c lemacs-19.2-hp/src/fileio.clemacs-19.2/src/floatfns.c lemacs-19.2-hp/src/floatfns.c *** lemacs-19.2/src/floatfns.c Mon Jun 15 00:35:46 1992 --- lemacs-19.2-hp/src/floatfns.c Thu Jul 9 12:55:21 1992 *************** *** 469,475 **** return num; } ! #if defined (BSD) || defined (IRIX) static void float_error (signo) int signo; --- 469,475 ---- return num; } ! #if defined (BSD) || defined (IRIX) || defined (__hpux) static void float_error (signo) int signo; diff -r -c lemacs-19.2/src/floatfns.c lemacs-19.2-hp/src/floatfns.clemacs-19.2/src/getpagesize.h lemacs-19.2-hp/src/getpagesize.h *** lemacs-19.2/src/getpagesize.h Mon Apr 13 20:22:59 1992 --- lemacs-19.2-hp/src/getpagesize.h Fri Jul 10 09:03:31 1992 *************** *** 4,11 **** #endif #endif ! #ifndef HAVE_GETPAGESIZE #include #ifdef EXEC_PAGESIZE --- 4,16 ---- #endif #endif ! #ifdef __hpux ! #include ! static size_t getpagesize() { return( 4096 ); } ! #define HAVE_GETPAGESIZE ! #endif + #ifndef HAVE_GETPAGESIZE #include #ifdef EXEC_PAGESIZE *************** *** 22,25 **** #endif /* no EXEC_PAGESIZE */ #endif /* not HAVE_GETPAGESIZE */ - --- 27,29 ---- diff -r -c lemacs-19.2/src/getpagesize.h lemacs-19.2-hp/src/getpagesize.hlemacs-19.2/src/gmalloc.c lemacs-19.2-hp/src/gmalloc.c *** lemacs-19.2/src/gmalloc.c Wed Apr 29 00:31:12 1992 --- lemacs-19.2-hp/src/gmalloc.c Fri Jul 10 08:56:32 1992 *************** *** 1,4 **** ! /* gmalloc.c - THIS FILE IS AUTOMAGICALLY GENERATED SO DON'T EDIT IT. */ /* Single-file skeleton for GNU malloc. --- 1,4 ---- ! #include "getpagesize.h" /* gmalloc.c - THIS FILE IS AUTOMAGICALLY GENERATED SO DON'T EDIT IT. */ /* Single-file skeleton for GNU malloc. Common subdirectories: lemacs-19.2/src/lwlib and lemacs-19.2-hp/src/lwlib Common subdirectories: lemacs-19.2/src/m and lemacs-19.2-hp/src/m diff -r -c lemacs-19.2/src/gmalloc.c lemacs-19.2-hp/src/gmalloc.clemacs-19.2/src/malloc.c lemacs-19.2-hp/src/malloc.c *** lemacs-19.2/src/malloc.c Mon Apr 13 20:20:24 1992 --- lemacs-19.2-hp/src/malloc.c Thu Jul 9 14:19:42 1992 *************** *** 685,691 **** return aligned; } ! #ifndef hpux /* This runs into trouble with getpagesize on HPUX. Patching out seems cleaner than the ugly fix needed. */ char * --- 685,691 ---- return aligned; } ! #ifndef __hpux /* This runs into trouble with getpagesize on HPUX. Patching out seems cleaner than the ugly fix needed. */ char * diff -r -c lemacs-19.2/src/malloc.c lemacs-19.2-hp/src/malloc.clemacs-19.2/src/menubar.c lemacs-19.2-hp/src/menubar.c *** lemacs-19.2/src/menubar.c Fri Jun 12 23:20:17 1992 --- lemacs-19.2-hp/src/menubar.c Thu Jul 9 12:44:10 1992 *************** *** 579,585 **** (menu_desc) Lisp_Object menu_desc; { ! static menu_id; struct screen *s = selected_screen; char *name = " unnamed popup "; --- 579,585 ---- (menu_desc) Lisp_Object menu_desc; { ! static int menu_id; struct screen *s = selected_screen; char *name = " unnamed popup "; Common subdirectories: lemacs-19.2/src/s and lemacs-19.2-hp/src/s diff -r -c lemacs-19.2/src/menubar.c lemacs-19.2-hp/src/menubar.clemacs-19.2/src/sysdep.c lemacs-19.2-hp/src/sysdep.c *** lemacs-19.2/src/sysdep.c Tue Jun 16 04:34:35 1992 --- lemacs-19.2-hp/src/sysdep.c Thu Jul 9 13:53:32 1992 *************** *** 1908,1913 **** --- 1908,1914 ---- #ifndef NCR486 /* OBE -- defined in libX11.a */ + #ifndef __hpux /* * The BSD random(3) returns numbers in the range of * 0 to 2e31 - 1. The USG rand(3C) returns numbers in the *************** *** 1928,1933 **** --- 1929,1936 ---- srand (arg); } + #endif /* __hpux */ + #endif /* ! NCR486 */ #endif /* USG */ *************** *** 2226,2233 **** */ rename (from, to) ! char *from; ! char *to; { if (access (from, 0) == 0) { --- 2229,2236 ---- */ rename (from, to) ! const char *from; ! const char *to; { if (access (from, 0) == 0) { diff -r -c lemacs-19.2/src/sysdep.c lemacs-19.2-hp/src/sysdep.clemacs-19.2/src/unexhp9k800.c lemacs-19.2-hp/src/unexhp9k800.c *** lemacs-19.2/src/unexhp9k800.c Mon Apr 13 20:21:37 1992 --- lemacs-19.2-hp/src/unexhp9k800.c Mon Jul 13 09:43:29 1992 *************** *** 60,66 **** int old_size, new_size; struct header hdr; struct som_exec_auxhdr auxhdr; ! /* For the greatest flexibility, should create a temporary file in the same directory as the new file. When everything is complete, rename the temp file to the new name. --- 60,67 ---- int old_size, new_size; struct header hdr; struct som_exec_auxhdr auxhdr; ! long i; ! /* For the greatest flexibility, should create a temporary file in the same directory as the new file. When everything is complete, rename the temp file to the new name. *************** *** 81,87 **** /* Decide how large the new and old data areas are */ old_size = auxhdr.exec_dsize; ! new_size = sbrk(0) - auxhdr.exec_dmem; /* Copy the old file to the new, up to the data space */ lseek(old, 0, 0); --- 82,89 ---- /* Decide how large the new and old data areas are */ old_size = auxhdr.exec_dsize; ! i = sbrk(0); ! new_size = i - auxhdr.exec_dmem; /* Copy the old file to the new, up to the data space */ lseek(old, 0, 0); diff -r -c lemacs-19.2/src/unexhp9k800.c lemacs-19.2-hp/src/unexhp9k800.clemacs-19.2/src/ymakefile lemacs-19.2-hp/src/ymakefile *** lemacs-19.2/src/ymakefile Fri Jun 19 06:31:43 1992 --- lemacs-19.2-hp/src/ymakefile Mon Jul 13 09:15:43 1992 *************** *** 20,25 **** --- 20,27 ---- COMPILE.c=$(CC) $(CFLAGS) $(CPPFLAGS) -c + MAKE=gnumake + dot = . /* on Xenix, replace double-dot below with $(dot)$(dot) */ lispdir = ../lisp/ *************** *** 477,483 **** cd $(LWLIBDIR); if [ -f Makefile ]; then make Makefile; else xmkmf;fi $(LWLIBDIR)/liblw.a: $(LWLIBDIR)/Makefile ! cd $(LWLIBDIR) ; make ${MFLAGS} liblw.a #endif /* These are needed for C compilation, on the systems that need them */ --- 479,485 ---- cd $(LWLIBDIR); if [ -f Makefile ]; then make Makefile; else xmkmf;fi $(LWLIBDIR)/liblw.a: $(LWLIBDIR)/Makefile ! cd $(LWLIBDIR) ; $(MAKE) ${MFLAGS} liblw.a #endif /* These are needed for C compilation, on the systems that need them */ diff -r -c lemacs-19.2/src/lwlib/Imakefile lemacs-19.2-hp/src/lwlib/Imakefile *** lemacs-19.2/src/lwlib/Imakefile Fri Jun 19 06:34:38 1992 --- lemacs-19.2-hp/src/lwlib/Imakefile Fri Jul 10 14:55:19 1992 *************** *** 27,32 **** --- 27,33 ---- */ #define USE_LUCID + #define USE_GCC /* #define USE_MOTIF */ /* #define USE_OLIT */ diff -r -c lemacs-19.2/src/s/s-hpux.h lemacs-19.2-hp/src/s/s-hpux.h *** lemacs-19.2/src/s/s-hpux.h Thu Mar 21 02:47:18 1991 --- lemacs-19.2-hp/src/s/s-hpux.h Thu Jul 9 13:01:43 1992 *************** *** 253,260 **** /* This is how to get the device name of the tty end of a pty. */ #define PTY_TTY_NAME_SPRINTF \ ! sprintf (ptyname, "/dev/pty/tty%c%x", c, i); /* This is how to get the device name of the control end of a pty. */ #define PTY_NAME_SPRINTF \ ! sprintf (ptyname, "/dev/ptym/pty%c%x", c, i); --- 253,260 ---- /* This is how to get the device name of the tty end of a pty. */ #define PTY_TTY_NAME_SPRINTF \ ! sprintf (pty_name, "/dev/pty/tty%c%x", c, i); /* This is how to get the device name of the control end of a pty. */ #define PTY_NAME_SPRINTF \ ! sprintf (pty_name, "/dev/ptym/pty%c%x", c, i); diff +new -c -r lemacs-19.2/src/s/s-hpux8.h lemacs-19.2-hp/src/s/s-hpux8.h *** lemacs-19.2/src/s/s-hpux8.h --- lemacs-19.2-hp/src/s/s-hpux8.h Fri Jul 10 14:26:01 1992 *************** *** 0 **** --- 1,279 ---- + /* s- file for hpux version 8. + This contains changes that were suggested "for the hp700". + They were not needed for the 800. + Our conjecture that they are needed for hpux version 8, + which is what runs on the 700. */ + + /* #include "s/s-hpux7.h" */ + /* Definitions file for GNU Emacs running on HPUX release 7.0. + Based on AT&T System V.2. + Copyright (C) 1985, 1986 Free Software Foundation, Inc. + + This file is part of GNU Emacs. + + GNU Emacs is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 1, or (at your option) + any later version. + + GNU Emacs is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU Emacs; see the file COPYING. If not, write to + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ + + + /* + * Define symbols to identify the version of Unix this is. + * Define all the symbols that apply correctly. + */ + + #define USG /* System III, System V, etc */ + + #define USG5 + + #define HPUX + + /* SYSTEM_TYPE should indicate the kind of system you are using. + It sets the Lisp variable system-type. */ + + #define SYSTEM_TYPE "hpux" + + /* `nomultiplejobs' should be defined if your system's shell + does not have "job control" (the ability to stop a program, + run some other program, then continue the first one). + + On hpux this depends on the precise kind of machine in use, + so the m- file defines this symbol if appropriate. */ + + /* Default is to set interrupt_input to 0: don't do input buffering within Emacs */ + + /* #define INTERRUPT_INPUT */ + + /* Letter to use in finding device name of first pty, + if system supports pty's. 'p' means it is /dev/ptym/ptyp0 */ + + #define FIRST_PTY_LETTER 'p' + + /* + * Define HAVE_TERMIO if the system provides sysV-style ioctls + * for terminal control. + */ + + #define HAVE_TERMIO + + /* Says to include time.h, and not include sys/time.h. */ + + #define NEED_TIME_H + + /* + * Define HAVE_TIMEVAL if the system supports the BSD style clock values. + * Look in for a timeval structure. + */ + + #define HAVE_TIMEVAL + + /* With HAVE_TIMEVAL define, Emacs expects to use `utimes'. + But HPUX does not have one. */ + + #define MISSING_UTIMES + + /* + * Define HAVE_SELECT if the system supports the `select' system call. + */ + + #define HAVE_SELECT + + /* + * Define HAVE_PTYS if the system supports pty devices. + */ + + #define HAVE_PTYS + + /* Define HAVE_SOCKETS if system supports 4.2-compatible sockets. */ + + #define HAVE_SOCKETS + + /* + * Define NONSYSTEM_DIR_LIBRARY to make Emacs emulate + * The 4.2 opendir, etc., library functions. + */ + + /* #define NONSYSTEM_DIR_LIBRARY */ + + /* Define this symbol if your system has the functions bcopy, etc. + * s800 and later versions of s300 (s200) kernels have equivilents + * of the BSTRING functions of BSD. If your s200 kernel doesn't have + * em comment out this section. + */ + + #define BSTRING + + /* subprocesses should be defined if you want to + have code for asynchronous subprocesses + (as used in M-x compile and M-x shell). + This is generally OS dependent, and not supported + under most USG systems. */ + + #define subprocesses + + /* If your system uses COFF (Common Object File Format) then define the + preprocessor symbol "COFF". */ + + /* #define COFF */ + + /* define MAIL_USE_FLOCK if the mailer uses flock + to interlock access to /usr/spool/mail/$USER. + The alternative is that a lock file named + /usr/spool/mail/$USER.lock. */ + + /* #define MAIL_USE_FLOCK */ + + /* Say we have the SYSV style of interprocess communication. */ + + #define HAVE_SYSVIPC + + /* Define CLASH_DETECTION if you want lock files to be written + so that Emacs can tell instantly when you try to modify + a file that someone else has modified in his Emacs. */ + + #define CLASH_DETECTION + + /* Define SHORTNAMES if the C compiler can distinguish only + short names. It means that the stuff in ../shortnames + must be run to convert the long names to short ones. + + Some USG systems support long names. + If yours is one, DO NOT change this file! + Do #undef SHORTNAMES in the m- file or in config.h. */ + + /* #define SHORTNAMES */ + + /* We use the Berkeley (and usg5.2.2) interface to nlist. */ + + #define NLIST_STRUCT + + /* The file containing the kernel's symbol table is called /hp-ux. */ + + #define KERNEL_FILE "/hp-ux" + + /* The symbol in the kernel where the load average is found + depends on the cpu type, so we let the m- files define LDAV_SYMBOL. */ + + /* Special hacks needed to make Emacs run on this system. */ + + /* + * Make the sigsetmask function go away. Don't know what the + * ramifications of this are, but doesn't seem possible to + * emulate it properly anyway at this point. + */ + + /* HPUX has sigsetmask */ + /* #define sigsetmask(mask) / * Null expansion * / */ + + /* setjmp and longjmp can safely replace _setjmp and _longjmp, + but they will run slower. */ + + /* HP-UX has _setjmp and _longjmp */ + /* + #define _setjmp setjmp + #define _longjmp longjmp + */ + + /* On USG systems the system calls are interruptable by signals + that the user program has elected to catch. Thus the system call + must be retried in these cases. To handle this without massive + changes in the source code, we remap the standard system call names + to names for our own functions in sysdep.c that do the system call + with retries. */ + + #define read sys_read + #define open sys_open + #define write sys_write + + #define INTERRUPTABLE_OPEN + #define INTERRUPTABLE_IO + + /* Use the system provided termcap(3) library */ + #define TERMINFO + + /* The 48-bit versions are more winning for Emacs. */ + + #define rand lrand48 + #define srand srand48 + + /* In hpux, the symbol SIGIO is defined, but the feature + does not really exist. + + Here we assume that signal.h is included before config.h + so that we can override it here. */ + + #undef SIGIO + + /* USG systems tend to put everything declared static + into the initialized data area, which becomes pure after dumping Emacs. + Foil this. Emacs carefully avoids static vars inside functions. */ + + #define static + + /* Define extra libraries to load. + This should have -lBSD, but that library is said to make + `signal' fail to work. */ + + #ifdef HPUX_NET + #define LIBS_SYSTEM -ln + #else + #define LIBS_SYSTEM + #endif + + /* Some additional system facilities exist. */ + + #define HAVE_DUP2 + #define HAVE_GETTIMEOFDAY + #define HAVE_VFORK + #define HAVE_PERROR /* Delete this line for version 6. */ + + /* The following maps shared exec file to demand loaded exec. + Don't do this as demand loaded exec is broken in hpux. */ + + #if 0 + + /* Adjust a header field for the executable file about to be dumped. */ + + #define ADJUST_EXEC_HEADER \ + hdr.a_magic = ((ohdr.a_magic.file_type == OLDMAGIC.file_type) ? \ + NEWMAGIC : ohdr.a_magic); + + #endif + + /* Baud-rate values in tty status have nonstandard meanings. */ + + #define BAUD_CONVERT \ + { 0, 50, 75, 110, 135, 150, 200, 300, 600, 900, 1200, \ + 1800, 2400, 3600, 4800, 7200, 9600, 19200, 38400 } + + /* This is needed for HPUX version 6.2; it may not be needed for 6.2.1. */ + #define SHORT_CAST_BUG + + /* This is how to get the device name of the tty end of a pty. */ + #define PTY_TTY_NAME_SPRINTF \ + sprintf (pty_name, "/dev/pty/tty%c%x", c, i); + + /* This is how to get the device name of the control end of a pty. */ + #define PTY_NAME_SPRINTF \ + sprintf (pty_name, "/dev/ptym/pty%c%x", c, i); + + /* #define C_SWITCH_SYSTEM -I/usr/include/X11R4 */ + + /* Don't use shared libraries. unexec doesn't handle them. */ + /* #define LD_SWITCH_SYSTEM -a archive -L/usr/lib/X11R4 */ + + /* Some hpux 8 machines seem to have TIOCGWINSZ, + and none have sioctl.h, so might as well define this. */ + #define NO_SIOCTL_H + + /* Specify compiler options for compiling oldXMenu. */ + #define OLDXMENU_OPTIONS CFLAGS=-I/usr/include/X11R4 From bug-lucid-emacs-request@lucid.com Wed Jul 15 08:50:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04877; Wed, 15 Jul 92 08:50:26 PDT Received: by heavens-gate.lucid.com id AA20518g; Wed, 15 Jul 92 08:41:54 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA20514g; Wed, 15 Jul 92 08:41:10 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA22680; Wed, 15 Jul 1992 17:49:54 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr (geant-gw) by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA27328; Wed, 15 Jul 92 17:53:50 +0200 Received: from caval.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA23600; Wed, 15 Jul 92 17:44:31 +0200 Date: Wed, 15 Jul 92 17:44:31 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9207151544.AA23600@geant.cenatls.cena.dgac.fr> Received: by caval.cenatls (4.1/SMI-4.1) id AA00603; Wed, 15 Jul 92 17:44:34 +0200 To: Bug Lucid Emacs Subject: bad gc when switching font - save the following elisp code in /tmp/toto.el - run xemacs -q -l /tmp/toto.el - execute C-x 5 (*not* M-x x-new-screen) - this leads to bus error due to bad gc. Configuration: lucid emacs 19.2 SPARCstation 2, sunos4.1.1, standard MIT X11R5 upto fix #12 Compiled with gcc -O ;--- code lisp --- (defvar the-proportional-font "-*-lucida-medium-r-*-*-12-*-*-*-*-*-*-*" "*The name of the proportional font.") (defvar the-extent nil "Per buffer extent.") (defun use-proportional () (interactive) (make-local-variable 'the-extent) (or the-extent (setq the-extent (make-extent (point-min) (point-max)))) (or (find-face 'proportional) (set-face-font (copy-face (get-face 'default) 'proportional) the-proportional-font)) (set-extent-attribute the-extent 'writable) (set-extent-attribute the-extent 'unhighlight) (set-extent-attribute the-extent 'visible) (set-extent-face the-extent 'proportional) (make-local-variable 'after-change-function) (setq after-change-function 'resize-extent) (resize-extent 0 0 0)) (defun resize-extent (beg end size) (and the-extent (set-extent-endpoints the-extent (point-min) (point-max)))) (insert "Hello world") ; Important, no bug without. (use-proportional) ; --end of code lisp-- X11 says: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 56 (X_ChangeGC) Resource id in failed request: 0x0 Serial number of failed request: 554 Current serial number in output stream: 567 X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 76 (X_ImageText8) Resource id in failed request: 0x0 Serial number of failed request: 555 Current serial number in output stream: 567 X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 76 (X_ImageText8) Resource id in failed request: 0x0 Serial number of failed request: 561 Current serial number in output stream: 567 Backtrace: #0 0xb96c in glyphs_from_bufpos (screen=0x26d000, buffer=0x1d1f00, pos=1, dp=0x0, hscroll=0, columns=0, tab_offset=0, direction=0, only_nonchars=0) at xdisp.c:1717 #1 0x4cd38 in compute_motion (window=1, from=1, fromvpos=0, fromhpos=0, to=12, tovpos=1376256, tohpos=0, width=79, hscroll=0, tab_offset=0, hpos_pix_width=0, column=0) at indent.c:500 #2 0x9e2c in redisplay_window (window=1344498688, just_this_one=0) at xdisp.c:916 #3 0x9888 in redisplay_windows (window=1344498688) at xdisp.c:753 #4 0x93ac in redisplay () at xdisp.c:564 #5 0x17018 in Fnext_event (event=1747416960) at event-stream.c:279 #6 0x33c5c in command_loop_1 (dummy=1844224) at keyboard.c:510 #7 0x5ff18 in internal_condition_case (bfun=0x33b70 , handlers=68991260, hfun=0x335ec ) at eval.c:1001 #8 0x33914 in command_loop_2 (dummy=1841152) at keyboard.c:385 #9 0x5fa68 in internal_catch (tag=68991240, func=0x338f0 , arg=68990980) at eval.c:813 #10 0x338c0 in command_loop () at keyboard.c:364 #11 0x33468 in recursive_edit_1 () at keyboard.c:221 #12 0x3355c in Frecursive_edit () at keyboard.c:250 #13 0x32c9c in main (argc=1918592, argv=0xf7fff804, envp=0xf7fff818) at emacs.c:899 Phil From bug-lucid-emacs-request@lucid.com Wed Jul 15 14:07:49 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06363; Wed, 15 Jul 92 14:07:49 PDT Received: by heavens-gate.lucid.com id AA21777g; Wed, 15 Jul 92 13:59:29 PDT Received: from cmcl2.NYU.EDU (NYU.EDU) by heavens-gate.lucid.com id AA21757g; Wed, 15 Jul 92 13:57:42 PDT Received: from WOTAN.CNS.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34) id AA29667; Wed, 15 Jul 92 17:06:45 -0400 Received: from hagen.cns.nyu.edu by wotan.cns.nyu.edu (4.1/SMI-4.0) id AA18263; Wed, 15 Jul 92 17:05:19 EDT Date: Wed, 15 Jul 92 17:05:19 EDT From: okeefe@cns.nyu.edu (Larry O'Keefe) Message-Id: <9207152105.AA18263@wotan.cns.nyu.edu> To: help-lucid-emacs@lucid.com Subject: remove me Cc: bug-lucid-emacs@lucid.com Please remove me from the mailing list. I am now able to get the lucid groups on internet. Thanks, Lawrence P. O'Keefe, Ph.D. Center for Neural Science New York University 6 Washington Place, 8th Floor New York, NY 10003 okeefe@cns.nyu.edu (212) 998-7898 From bug-lucid-emacs-request@lucid.com Wed Jul 15 15:57:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06721; Wed, 15 Jul 92 15:57:26 PDT Received: by heavens-gate.lucid.com id AA22176g; Wed, 15 Jul 92 15:49:41 PDT Received: from bcars520 (x400gate.bnr.ca) by heavens-gate.lucid.com id AA22172g; Wed, 15 Jul 92 15:49:31 PDT X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Jul 1992 18:57:17 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Jul 1992 18:58:49 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Jul 1992 14:57:00 -0400 Date: Wed, 15 Jul 1992 18:57:00 +0000 X400-Originator: /DD.ID=1581776/G=Jeffrey/I=JD/S=Sparkes/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.145:15.06.92.22.58.49] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: find-tag-othe... From: "Jeffrey (J.D.w\Nw\H) Sparkes" Message-Id: <"28152 Wed Jul 15 18:58:54 1992"@bnr.ca> To: bug-lucid-emacs@lucid.com Subject: find-tag-other-window now takes only one argument I've almost got Hyperbole ported to Lucid emacs. One problem I've run into is that the find-tag-other-window in etags.el does not take the second argument, even though it is mentioned in the documentation. BTW: highlighting extents is cool! -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Wed Jul 15 21:25:43 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07456; Wed, 15 Jul 92 21:25:43 PDT Received: by heavens-gate.lucid.com id AA22923g; Wed, 15 Jul 92 21:14:26 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA22919g; Wed, 15 Jul 92 21:14:18 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA07777; Wed, 15 Jul 92 21:20:52 PDT Date: Wed, 15 Jul 92 21:20:52 PDT Message-Id: <9207160420.AA07777@thalidomide.lucid> From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: okeefe@cns.nyu.edu (Larry O'Keefe) Cc: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com Subject: Re: remove me In-Reply-To: Larry O'Keefe's message of Wed 15-Jul-92 17:05:19 EDT <9207152105.AA18263@wotan.cns.nyu.edu> References: <9207152105.AA18263@wotan.cns.nyu.edu> okeefe@cns.nyu.edu has been removed from help-lucid-emacs@lucid.com and bug-lucid-emacs@lucid.com. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Jul 16 07:57:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09511; Thu, 16 Jul 92 07:57:57 PDT Received: by heavens-gate.lucid.com id AA23768g; Thu, 16 Jul 92 07:48:40 PDT Received: from alpha.xerox.com by heavens-gate.lucid.com id AA23764g; Thu, 16 Jul 92 07:48:32 PDT Received: from ColdDuck.wbst129ul.xerox.xns by alpha.xerox.com via XNS id <11559>; Thu, 16 Jul 1992 07:57:39 PDT X-Ns-Transport-Id: 08003701035C37892E25 Date: Thu, 16 Jul 1992 07:57:28 PDT From: Marc_Rocas.Wbst129@xerox.com Subject: Remove me To: "bug-lucid-emacs@lucid".com@unspecified.xerox.com Reply-To: Marc_Rocas.Wbst129@xerox.com Message-Id: <"16-Jul-92 10:57:25".*.Marc_Rocas.WBST129@Xerox.com> Please remove me from the mailing list. Thanks in advance. --Marc. From bug-lucid-emacs-request@lucid.com Fri Jul 17 04:26:44 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12973; Fri, 17 Jul 92 04:26:44 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA26746g; Fri, 17 Jul 92 04:15:20 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA03244; Fri, 17 Jul 92 07:24:47 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA03238; Fri, 17 Jul 92 07:24:45 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA16111; Fri, 17 Jul 92 07:25:01 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Subject: elisp reference info file in lemacs 19.2 Message-Id: <1992Jul16.162005.13393@cs.sfu.ca> Summary: seems corrupted Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Date: Thu, 16 Jul 1992 16:20:05 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Now I realize this is the version 18 manual, but when you know as little elisp as I do, it's way better than nothing. Unfortunately the version that that ships with lemacs 19.2 seems to be corrupted: When I select e.g, "Control structures::", info blanks the window, the mode line still says (elisp)Top, and the echo area reads 'Search failed: "\n^_"'. Is this a problem with info, the elisp info file, or me? David -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Fri Jul 17 04:26:43 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12972; Fri, 17 Jul 92 04:26:43 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA26747g; Fri, 17 Jul 92 04:15:23 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA03254; Fri, 17 Jul 92 07:24:49 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA03248; Fri, 17 Jul 92 07:24:48 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA16120; Fri, 17 Jul 92 07:25:04 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Subject: more problems with info Message-Id: <1992Jul16.164641.13497@cs.sfu.ca> Summary: popup menus don't Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Date: Thu, 16 Jul 1992 16:46:41 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Pressing the right button in info rings the bell and prints the error message "Wrong type of argument: stringp,nil" Both this and the previous problems occur whether or not I have a .emacs file David P.S. Once info is working for me, I'm thinking of adding support for compressed info files, like Dave Gillespie's version of info. Is anybody else working on this? -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Fri Jul 17 07:40:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13578; Fri, 17 Jul 92 07:40:02 PDT Received: by heavens-gate.lucid.com id AA26993g; Fri, 17 Jul 92 07:29:16 PDT Received: from CAMIS.Stanford.EDU by heavens-gate.lucid.com id AA26989g; Fri, 17 Jul 92 07:29:07 PDT Received: from mcs-ipc-3.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA23161; Fri, 17 Jul 92 07:38:35 PDT Date: Fri, 17 Jul 1992 07:33:43 -0700 (PDT) From: Kevin Brock Reply-To: Brock@sumex-aim.stanford.edu Subject: RE: elisp reference info file in lemacs 19.2 To: bug-lucid-emacs@lucid.com In-Reply-To: bremner%cs.sfu.ca@lucid.com's message of Thu, 16 Jul 1992 16:20:05 GMT: <1992Jul16.162005.13393@cs.sfu.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >When I select e.g, "Control structures::", info blanks the window, the >mode line still says (elisp)Top, and the echo area reads >'Search failed: "\n^_"'. I believe it's because the elisp indirection table is pointing into a file you don't have. Check the numbers on the elisp files in your info directory -- you're probably missing some. I was too, but I thought I had just lost the files at some point. Maybe they just aren't in the distribution. Since it *is* just the version 18 manual you should be able to replace the missing pieces pretty easily. ----------- Kevin Brock brock@sumex-aim.stanford.edu From bug-lucid-emacs-request@lucid.com Fri Jul 17 08:56:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13796; Fri, 17 Jul 92 08:56:13 PDT Received: by heavens-gate.lucid.com id AA27161g; Fri, 17 Jul 92 08:45:24 PDT Received: from andrew.cmu.edu by heavens-gate.lucid.com id AA27150g; Fri, 17 Jul 92 08:43:43 PDT Received: by andrew.cmu.edu (5.54/3.15) id for bug-lucid-emacs@lucid.com; Fri, 17 Jul 92 11:53:08 EDT Received: via switchmail; Fri, 17 Jul 1992 11:53:08 -0400 (EDT) Received: from sinope.esl.acs.cmu.edu via qmail ID ; Fri, 17 Jul 1992 11:52:11 -0400 (EDT) Received: from sinope.esl.acs.cmu.edu via qmail ID ; Fri, 17 Jul 1992 11:52:04 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.sinope.esl.acs.cmu.edu.pmax.ul4 via MS.5.6.sinope.esl.acs.cmu.edu.pmax_ul4; Fri, 17 Jul 1992 11:52:04 -0400 (EDT) Message-Id: Date: Fri, 17 Jul 1992 11:52:04 -0400 (EDT) From: "Eric A. Anderson" To: bug-lucid-emacs@lucid.com Subject: Changes neccesary to get lemacs to compile on a sparc system *** src/lwlib/Imakefile.~1~ Wed Jun 3 17:06:37 1992 --- src/lwlib/Imakefile Fri Jun 5 11:44:59 1992 *************** *** 25,35 **** /* #define USE_MOTIF */ /* #define USE_OLIT */ ! /* #define INCLUDE_EXTENSIONS */ #ifdef INCLUDE_EXTENSIONS /* this is where it is at our site */ ! TOP = /$(WHICH_X)/mit #endif /* --- 25,37 ---- /* #define USE_MOTIF */ /* #define USE_OLIT */ ! /*#define INCLUDE_EXTENSIONS*/ + /* Gotta use gcc, cc doesn't like prototypes */ + CC = gcc #ifdef INCLUDE_EXTENSIONS /* this is where it is at our site */ ! TOP = /src/X11/x11r5/mit #endif /* *** src/lwlib/lwlib.c.~1~ Tue May 12 23:08:04 1992 --- src/lwlib/lwlib.c Fri Jun 5 11:41:14 1992 *************** *** 36,42 **** #endif #if (!defined(USE_MOTIF) && !defined(USE_LUCID) && !defined(USE_OLIT)) ! #error at least one of USE_MOTIF, USE_LUCID or USE_OLIT must be defined #endif --- 36,42 ---- #endif #if (!defined(USE_MOTIF) && !defined(USE_LUCID) && !defined(USE_OLIT)) ! diedieideiidididididie #endif *** src/ymakefile.~1~ Wed Jun 3 16:41:24 1992 --- src/ymakefile Fri Jun 5 11:36:19 1992 *************** *** 409,414 **** --- 410,417 ---- #ifndef OBJECTS_MACHINE #define OBJECTS_MACHINE #endif + + all: xemacs xemacs: temacs ${lisp} ${etcdir}DOC OTHER_FILES ./temacs -batch -l loadup.el dump -Eric ********************************************************* "Overhead, without any fuss, the stars were going out." -The Nine Billion Names of God "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From bug-lucid-emacs-request@lucid.com Fri Jul 17 09:51:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14052; Fri, 17 Jul 92 09:51:33 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA27337g; Fri, 17 Jul 92 09:43:54 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00153; Fri, 17 Jul 92 12:53:08 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00147; Fri, 17 Jul 92 12:53:06 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA17588; Fri, 17 Jul 92 12:53:25 -0400 Path: uunet!stanford.edu!rutgers!rochester!cornell!murthy From: murthy@cs.cornell.edu (Chet Murthy) Newsgroups: alt.lucid-emacs.bug Subject: Install still failing Message-Id: <1992Jul17.115547.16841@cs.cornell.edu> Date: 17 Jul 92 11:55:47 GMT Organization: Cornell Univ. CS Dept, Ithaca NY 14853 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have ftp'd a copy of lucid-emacs, version 19.2, and succeeded in compiling it with gcc-1.40. However, the same set of files, under gcc-2.1, fails to compile. I have tried it with every combination of the options -traditional and -ansi, without success. Has anybody succeeded in compiling lemacs 19.2 with gcc 2.1? It's nice that the binary is provided, and I can use it, though. --chet-- From bug-lucid-emacs-request@lucid.com Fri Jul 17 10:50:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14265; Fri, 17 Jul 92 10:50:30 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA27547g; Fri, 17 Jul 92 10:42:49 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04997; Fri, 17 Jul 92 13:52:17 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA04977; Fri, 17 Jul 92 13:52:13 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA17943; Fri, 17 Jul 92 13:52:32 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!stanford.edu!EE.Stanford.EDU!sierra!mcgrant From: mcgrant@rascals.stanford.edu (Michael C. Grant) Subject: Re: elisp reference info file in lemacs 19.2 In-Reply-To: bremner@cs.sfu.ca's message of Thu, 16 Jul 1992 16:20:05 GMT Message-Id: Organization: Information Systems Laboratory, Stanford University References: <1992Jul16.162005.13393@cs.sfu.ca> Date: 17 Jul 92 10:51:06 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <1992Jul16.162005.13393@cs.sfu.ca> bremner@cs.sfu.ca (David Bremner) writes: Now I realize this is the version 18 manual, but when you know as little elisp as I do, it's way better than nothing. Unfortunately the version that that ships with lemacs 19.2 seems to be corrupted: When I select e.g, "Control structures::", info blanks the window, the mode line still says (elisp)Top, and the echo area reads 'Search failed: "\n^_"'. Is this a problem with info, the elisp info file, or me? David I have this problem as well. Can't explain it! Michael C. Grant From bug-lucid-emacs-request@lucid.com Mon Jul 20 05:05:31 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22261; Mon, 20 Jul 92 05:05:31 PDT Received: by heavens-gate.lucid.com id AA01919g; Mon, 20 Jul 92 04:54:42 PDT Received: from CCVCOM.AUKUNI.AC.NZ by heavens-gate.lucid.com id AA01915g; Mon, 20 Jul 92 04:54:25 PDT Received: from ccu1.aukuni.ac.nz by aukuni.ac.nz (PMDF #2864 ) id <01GMMCGUO36894E0HJ@aukuni.ac.nz>; Tue, 21 Jul 1992 00:06:41 +1200 Received: from mercury.gen.nz by ccu1.aukuni.ac.nz with 920110.SGI/920109.2 id ; Tue, 21 Jul 92 00:03:31 +1200 Received: by mercury.gen.nz (smail2.5); 20 Jul 92 22:13:44 NZST (Mon) Received: from ibm3270.manasys.co.nz by atlas.manasys.co.nz (4.1/SMI-4.1) id AA12351; Mon, 20 Jul 92 14:21:09 NZS Received: by ibm3270.manasys.co.nz (4.1/SMI-4.1) id AA00519; Mon, 20 Jul 92 14:21:07 NZS Date: Mon, 20 Jul 92 14:21:07 NZS From: paulr%manasys.co.nz@lucid.com (Paul Reddy) Subject: various Lucid emacs problems - mainly lisp. To: bug-lucid-emacs@lucid.com Message-Id: <9207200221.AA00519@ibm3270.manasys.co.nz> X-Envelope-To: bug-lucid-emacs@lucid.com Content-Transfer-Encoding: 7BIT In GNU Emacs 19.2.6 Lucid of Wed Jul 8 1992 on noddy (berkeley-unix) MACHINE: SPARCstation SLC and SPARC2 OS: SUNOS 4.1.1 WINDOWING: X11R5 EMACS: 19.2.6 Received your version of emacs last week, and I have spent the last couple of days playing around with it. Lots of mucho cool stuff. I have found a couple of funnies, I presume with the lisp code but you will be better qualified to judge that. The problems: (Note that these have all been tried with no .emacs file and a vanilla build, i.e. no local modifications). 1) gnus (supplied version = 3.13) Loads and starts ok. Enter a group (into subject list). Can read items fine. Quit the group - back to *Newsgroup* buffer. Now cannot read anymore groups. Just get the message "Wrong type argument: syntax-table-p, nil" Note that this only happens with some groups, but it is always the same ones. 2) evi (supplied version = 0.93) This will compile, but wont load. Get the following message: "can't bind 27: this map contains meta-bindings: #" Doesn't seem to like remapping esc (e.g. evi-insert-map, and numerous other places). 3) vip (supplied version = 4.3) This just goes wierd. Get lots of errors. For example: 'i' gets same message as above (can't bind 27) dd gets "Wrong type argument: integer-or-float-or-marker-p, nil" the list goes on... 4) vi (supplied version = ?) This is pretty limited. [can you tell yet that I am a 'vi' weenie.... I need my ex commands]. 5) dmacros (this was not supplied, but *almost* works. version = 1.5) We use this a lot, an I am therefore keen to get it to go. Suppose you had a dmacro called first-second that put the following text into your buffer: hello there then running it will give the following output under emacsV19 hello there -second Once again, please feel free to ignore this one, but if you have any ideas you can give me then I would be greatful. 6) sound I can attach a sound to an event using: (load-sound-file "blah/blah/moo.au", 'undefined-key) and the sound does play for an undefined key event. However an error message appears even though everything went fine, i.e. "audio: sst_close: SETREG MMR2, invalid argument" 7) completions (not a supplied package => cannot expect it to work I guess) Similar problem to the dmacros above. Would be nice if you have heard of any patches, otherwise ignore. 8) Shell mode (supplied version = ?) (control c)(control c) does nothing to the process in the shell, but since emacs puts "Quit" in the minibuf I suspect that emacs is recieving the signal. Help on a key reveals that it is mapped to "comint-interrupt-subjob" in the shell buffer (control c)(control z) kills emacs (doesn't stop, but actually kills it). This is mapped to "comint-stop-subjob" in the shell buffer. That's it so far. Any hints on the above would be most welcome, especially the vi hassles. Thanks. Paul p.s. Are there any mail lists that I could be added to? thanks. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Phone: +64 9 419 0046 (in a rush) | "Organising Email: paulr@manasys.co.nz (if you're patient) | programmers is like Snail: Mana Systems (if you're *really* patient)| trying to herd cats" P.O. Box 34137, Auckland 10, NZ | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From bug-lucid-emacs-request@lucid.com Mon Jul 20 05:46:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22442; Mon, 20 Jul 92 05:46:29 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01961g; Mon, 20 Jul 92 05:34:26 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA13016; Mon, 20 Jul 92 08:43:58 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA13010; Mon, 20 Jul 92 08:43:55 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA10353; Mon, 20 Jul 92 08:44:03 -0400 Path: uunet!mcsun!corton!loria!news.loria.fr!bosch From: bosch%loria.fr@lucid.com (Guido Bosch) Newsgroups: alt.lucid-emacs.bug Subject: Re: more problems with info Message-Id: Date: 20 Jul 92 12:22:59 GMT References: <1992Jul16.164641.13497@cs.sfu.ca> Reply-To: Guido BOSCH Organization: INRIA-Lorraine / CRIN, Nancy, France In-Reply-To: bremner@cs.sfu.ca's message of 16 Jul 92 16:46:41 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com > > P.S. Once info is working for me, I'm thinking of adding support for > compressed info files, like Dave Gillespie's version of info. Is anybody > else working on this? > There are more interesting features in Dave's info.el, e.g., local info directories, and a lot of new commands. Maybe you should consider to bring up his version to Lucid Emacs 19 rather than add some of its features to the current version. Ask Jamie for the Lucid specific patches of info.el and try to apply them to Dave Gillespie's info.el. Guido -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@lucid.com Mon Jul 20 06:35:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22653; Mon, 20 Jul 92 06:35:01 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02032g; Mon, 20 Jul 92 06:27:03 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA14657; Mon, 20 Jul 92 09:36:28 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA14640; Mon, 20 Jul 92 09:36:25 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA10684; Mon, 20 Jul 92 09:36:33 -0400 Path: uunet!think.com!zaphod.mps.ohio-state.edu!mips!mips!decwrl!deccrl!bloom-beacon!eru.mt.luth.se!lunic!sunic!ugle.unit.no!nuug!nntp.nta.no!nntp.nta.no!kjellm From: kjellm%hydra.unik.no@lucid.com (Kjell M. Myksvoll) Newsgroups: alt.lucid-emacs.bug Subject: Re: various Lucid emacs problems - mainly lisp. Message-Id: Date: 20 Jul 92 13:14:35 GMT References: <9207200221.AA00519@ibm3270.manasys.co.nz> Organization: Universitetsstudiene paa Kjeller (UNIK), University of Oslo, Norway In-Reply-To: paulr%manasys.co.nz@lucid.com's message of Mon, 20 Jul 92 14:21:07 NZS Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9207200221.AA00519@ibm3270.manasys.co.nz> paulr%manasys.co.nz@lucid.com (Paul Reddy) writes: In GNU Emacs 19.2.6 Lucid of Wed Jul 8 1992 on noddy (berkeley-unix) I have found a couple of funnies, I presume with the lisp code but you will be better qualified to judge that. 1) gnus (supplied version = 3.13) Loads and starts ok. Enter a group (into subject list). Can read items fine. Quit the group - back to *Newsgroup* buffer. Now cannot read anymore groups. Just get the message "Wrong type argument: syntax-table-p, nil" Note that this only happens with some groups, but it is always the same ones. This one seem to be due to an error in the "mail-strip-quoted-names" function defined in .../lisp/util/mail-utils.el. It does not seem to be able to handle strings containing nested parenthesis (one pair of parenthesis goes fine, two (or more?) nested inside each other make it choke). This is why it chokes only on some newsgroups - namely on those where the posters like to have nested parenthesis in their "From:" field. Same groups every time :-) The mail-strip-quoted-names function from emacs-18.58 works fine so I use that one now (inside gnus). Paul kjell From bug-lucid-emacs-request@lucid.com Mon Jul 20 11:04:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23331; Mon, 20 Jul 92 11:04:37 PDT Received: by heavens-gate.lucid.com id AA02653g; Mon, 20 Jul 92 10:56:05 PDT Received: from gateway.bnr.ca by heavens-gate.lucid.com id AA02649g; Mon, 20 Jul 92 10:55:54 PDT Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA28125; Mon, 20 Jul 92 14:05:21 -0400 Message-Id: <9207201805.AA28125@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 1034; Mon, 20 Jul 92 14:03:30 EDT Date: 20 Jul 92 14:05:00 EDT To: bug-lucid-emacs@lucid.com From: Jeffrey (J.D.) Sparkes Subject: problem with condition-case and keyboad-quit Sender: Jeffrey (J.D.) Sparkes The following code demonstrates a problem with Lucid emacs 19.2 (sunos4.1.1). Under emacs 18.58 (and the lastest epoch), running this function and hitting C-G at the prompt causes the "qot quit" message to appear. Under lemacs19.2, I get a "Quit" message instead. (defun test-quit() (interactive) (condition-case () (read-from-minibuffer "Volume: " "11") (quit (message "got quit")) (error (message "got error")))) (test-quit) (BTW: this is the last thing left in getting Hyperbole to work; expect patches in a day or two for brave testers...) -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Tue Jul 21 05:14:07 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25569; Tue, 21 Jul 92 05:14:07 PDT Received: by heavens-gate.lucid.com id AA05294g; Tue, 21 Jul 92 05:03:22 PDT Received: from sun2.nsfnet-relay.ac.uk by heavens-gate.lucid.com id AA05290g; Tue, 21 Jul 92 05:03:10 PDT Via: uk.ac.city.cs; Tue, 21 Jul 1992 13:11:34 +0100 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.barney.cs.city.ac.uk.sun4.40 via MS.5.6.barney.cs.city.ac.uk.sun4_40; Tue, 21 Jul 1992 13:14:32 +0100 (BST) Message-Id: Date: Tue, 21 Jul 1992 13:14:32 +0100 (BST) From: Andy Whitcroft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bug-lucid-emacs@lucid.com Subject: Zmacs Regions. In some popup-menu code I wish to know if the zmacs region is active in order to allow or disallow a memu entry. There seems to be no sensible variable/function to provide this information. The info.el menu uses the x-selection-owner-p function, which seesm incorrect. Looking at the code for marker etc they use zmacs_active_region_p, should this not be bound up as zmacs-regions is, or perhaps made available as a function zmacs-active-region-p? Comments? Andy. Andy Whitcroft Email: andy@cs.city.ac.uk (MIME & ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 City University, London, UK. Fax: +44 71 477 8587 From bug-lucid-emacs-request@lucid.com Wed Jul 22 13:38:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01794; Wed, 22 Jul 92 13:38:33 PDT Received: by heavens-gate.lucid.com id AA09481g; Wed, 22 Jul 92 13:29:51 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA09474g; Wed, 22 Jul 92 13:28:01 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA12133; Wed, 22 Jul 92 13:36:07 PDT Date: Wed, 22 Jul 92 13:36:07 PDT Message-Id: <9207222036.AA12133@thalidomide.lucid> X-Windows: The joke that kills. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Andy Whitcroft Cc: bug-lucid-emacs@lucid.com Subject: Re: Zmacs Regions. In-Reply-To: Andy Whitcroft's message of Tue 21-Jul-92 13:14:32 +0100 References: In message Andy Whitcroft wrote: > > In some popup-menu code I wish to know if the zmacs region is active in > order to allow or disallow a memu entry. There seems to be no sensible > variable/function to provide this information. The info.el menu uses > the x-selection-owner-p function, which seesm incorrect. Looking at the > code for marker etc they use zmacs_active_region_p, should this not be > bound up as zmacs-regions is, or perhaps made available as a function > zmacs-active-region-p? You're probably right that there should be a cleaner way of determining this. x-selection-owner-p is correct when running under X, since when the Zmacs region is active, it is also the X selection. x-selection-owner-p will also be true if zmacs-regions is nil, but the user has highlighted some text with the mouse. (and zmacs-regions (mark)) should also do what you want. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Jul 23 01:31:23 1992 Received: from lucid.com ([192.31.212.72]) by labrea.Stanford.EDU (4.1/1.34) id AA03253; Thu, 23 Jul 92 01:31:23 PDT Received: by heavens-gate.lucid.com id AA11135g; Thu, 23 Jul 92 01:18:40 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA11131g; Thu, 23 Jul 92 01:18:25 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA10158; Thu, 23 Jul 1992 10:27:54 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA14516; Thu, 23 Jul 92 10:31:58 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA23462; Thu, 23 Jul 92 10:21:53 +0200 Date: Thu, 23 Jul 92 10:21:53 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9207230821.AA23462@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA00585; Thu, 23 Jul 92 10:21:54 +0200 To: Bug Lucid Emacs Subject: vm-isearch bug with corrections Here is a correction for the bug in vm-isearch-{forward,backward} (reference to void-variable unread-command-char). It simply consists in using unread-command-event instead, plus adding some conversion between char and event. This enables vm-isearch to work. However, to be complete, it should use events in the same way as isearch, and not converting them immediately to characters (it loses with function keys or keypad keys). Phil --- vm-search.el.orig Thu Jul 23 10:05:11 1992 +++ vm-search.el Thu Jul 23 10:06:24 1992 @@ -58,5 +58,5 @@ (catch 'search-done (while t - (or (>= unread-command-char 0) + (or unread-command-event (progn (or (input-pending-p) @@ -88,5 +88,5 @@ (cond ((and (>= char 128) search-exit-option) - (setq unread-command-char char) + (setq unread-command-event (character-to-event char)) (throw 'search-done t)) ((eq char search-exit-char) @@ -164,5 +164,5 @@ (or (= char ?\177) (and (< char ? ) (/= char ?\t) (/= char ?\r)))) - (setq unread-command-char char) + (setq unread-command-event (character-to-event char)) (throw 'search-done t)) (t @@ -305,5 +305,5 @@ (setq other-end (if forward (match-beginning 0) (match-end 0))))) - (quit (setq unread-command-char ?\C-g) + (quit (setq unread-command-event (character-to-event ?\C-g)) (setq success nil)) (invalid-regexp (setq invalid-regexp (car (cdr lossage))) @@ -341,5 +341,5 @@ (setq message (if forward "VM Word search: " "VM Word search backward: ")) ;; Otherwise let that 1 char be part of the search string. - (setq unread-command-char char)) + (setq unread-command-event (character-to-event char))) (setq function (if (eq char search-yank-word-char) From bug-lucid-emacs-request@lucid.com Fri Jul 24 20:53:09 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05972; Fri, 24 Jul 92 20:53:09 PDT Received: by heavens-gate.lucid.com id AA17514g; Fri, 24 Jul 92 20:41:00 PDT Received: from eas.gatech.edu by heavens-gate.lucid.com id AA17510g; Fri, 24 Jul 92 20:40:51 PDT Received: by eas.gatech.edu (AIX 3.1/UCB 5.61/3.1) id AA38990; Fri, 24 Jul 92 23:50:32 -0400 Date: Fri, 24 Jul 92 23:50:32 -0400 From: Ryan Mulderig Message-Id: <9207250350.AA38990@eas.gatech.edu> To: bug-lucid-emacs@lucid.com Subject: AIX 3.2 installation I have fought further along than anyone who has sent me mail, and actually gotten it to dump. However there is a bit of strangeness in term.c. First at the top of term_init I had to comment out the lines if (status == 0) fatal(... I could not figure out what tgetent was being called, as it was not the one in termcap.c (since I deleted termcap.o, recompiled and it did not recompile and no unfound symbol erros were generated). Then I realized that near the end, it call itself as term_init("invisible"), so we recursed forever. I commented out this as well, and compiled yet again. When I ran it, it started to load, but then failed on an IOT trap. I would love any ideas anyone may have. Signature Under Construction From bug-lucid-emacs-request@lucid.com Sun Jul 26 11:53:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10291; Sun, 26 Jul 92 11:53:08 PDT Received: by heavens-gate.lucid.com id AA19340g; Sun, 26 Jul 92 11:40:27 PDT Received: from cs.widener.edu by heavens-gate.lucid.com id AA19336g; Sun, 26 Jul 92 11:37:19 PDT Received: by cs.widener.edu id AA22029 (5.65c/Widener-4.2 for bug-lucid-emacs@lucid.com); Sun, 26 Jul 1992 14:47:00 -0400 Date: Sun, 26 Jul 1992 14:47:00 -0400 From: Brendan Kehoe Message-Id: <199207261847.AA22029@cs.widener.edu> To: bug-lucid-emacs@lucid.com Subject: Using -static vs -Bstatic with gcc Reply-To: brendan@cs.widener.edu A small tweak's necessary if you've got CC set to gcc: *** s-sunos4.h.~1~ Wed Apr 29 00:33:15 1992 --- s-sunos4.h Sun Jul 26 14:27:48 1992 *************** *** 6,10 **** --- 6,14 ---- #endif + #ifdef __GNUC__ + #define LD_SWITCH_SYSTEM -e __start -static + #else #define LD_SWITCH_SYSTEM -e __start -Bstatic + #endif /* In SunOS 4.1, a static function called by tzsetwall reportedly -- Brendan Kehoe, Sun Network Manager brendan@cs.widener.edu Widener University Chester, PA "Life is a process, and it shouldn't matter what the hardware is." -- Chris Langton From bug-lucid-emacs-request@lucid.com Sun Jul 26 19:05:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11019; Sun, 26 Jul 92 19:05:17 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA19740g; Sun, 26 Jul 92 18:51:37 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA08307; Sun, 26 Jul 92 22:01:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA08301; Sun, 26 Jul 92 22:01:22 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA03754; Sun, 26 Jul 92 22:02:18 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!decwrl!adobe!jfinger From: jfinger@adobe.com (Jeff Finger) Subject: Ultrix 4.2/lemacs 19.2 temacs problem Message-Id: <1992Jul27.015750.22024@adobe.com> Organization: Adobe Systems, Inc., Mountain View, CA Distribution: net Date: Mon, 27 Jul 1992 01:57:50 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com My temacs crashes under Ultrix almost immediately. Help? This report consists of: 1. Configuration 2. Description of Problem: 3. How I built temacs 4. Local Changes to Distribution 5. Log of Build of temacs Thanks, -- Jeff Finger -- ================================================================ 1. Configuration: Decstation 5000/120 ULTRIX V4.2 ( Rev. 96 ) System #1: Thu Jun 13 16:41:48 PDT 1991 UWS V4.2 (Rev.272) X11 R4 XT_VERSION 11 XT_REVISION 4 GCC 2.2.2 lemacs-19.2 2. Description of Problem: lemacs-19.2/src/temacs gives a segmentation fault in make_pure_string() init_obarray() main() The problem happens regardless of whether I use SYSTEM_MALLOC or GNU_MALLOC in building the system. % gdb temacs ... GDB 4.6, Copyright 1992 Free Software Foundation, Inc... (gdb) run -batch -l inc-vers Starting program: .../lemacs-19.2/src/temacs -batch -l inc-vers Program received signal 11, Segmentation fault 0x474678 in make_pure_string (data=0x100a5dd4 "nil", length=3) at alloc.c:976 976 XSTRING (new)->size = length; (gdb) bt #0 0x474678 in make_pure_string (data=0x100a5dd4 "nil", length=3) at alloc.c:976 #1 0x4957cc in init_obarray () at lread.c:1330 #2 0x4474d8 in main (argc=4, argv=0x7fffb3d4, envp=0x7fffb3e8) at emacs.c:704 (gdb) p/x new $1 = 0xc016d60 (gdb) p/x *new Cannot access memory at address 0xc016d60. (gdb) 3. How I built temacs: 1. Changed src/config.h (See below) 2. Changed src/ymakefile (See below) 3. build-install 4. Local Changes to Distribution % diff src/config.h src/config.h-dist 33,34c33 < /* #include "s/s-sunos4.h" */ < #include "s/s-bsd4-3.h" --- > #include "s/s-sunos4.h" 41,42c40 < /* #include "m/m-sparc.h" */ < #include "m/m-mips.h" --- > #include "m/m-sparc.h" 117c115 < #define NEED_STRDUP --- > /* #define NEED_STRDUP */ 157c155 < #define NEED_REALPATH --- > /* #define NEED_REALPATH */ 184c182 < #define LD_SWITCH_SITE -L/usr/local/X11R4/lib -L/user/jfinger/public-software/usr/local/lib --- > /* #define LD_SWITCH_SITE -L/x11r4/usr.`arch`/lib */ 192d189 < #define C_SWITCH_SITE -I/usr/local/X11R4/include % diff src/ymakefile src/ymakefile.ORIG 326c326 < #define LIBS_TERMCAP -lcurses -lcursesX -ltermcap --- > #define LIBS_TERMCAP -lcurses 480c480 < cd $(LWLIBDIR) ; make ${MFLAGS} CC=gcc CCOPTIONS= liblw.a --- > cd $(LWLIBDIR) ; make ${MFLAGS} liblw.a 734,735c734,735 < unexmips.o: config.h # filehdr.h < unexmips.o: # aouthdr.h scnhdr.h sym.h --- > unexmips.o: config.h filehdr.h > unexmips.o: aouthdr.h scnhdr.h sym.h 5. Log of Build of temacs % build-install set EMACS=/usr/local/emacs set BIN=/usr/local/bin /bin/sed s;/usr/local/emacs;/usr/local/emacs; cd etc make cc -o test-distrib test-distrib.c ./test-distrib cc -o etags -g -DETAGS etags.c cc -o ctags -g -DCTAGS etags.c cc -o wakeup -g wakeup.c cc -o make-docfile -g make-docfile.c cc -o digest-doc -g digest-doc.c cc -o sorted-doc -g sorted-doc.c cc -o movemail -g movemail.c cc -o cvtmail -g cvtmail.c cc -o fakemail -g fakemail.c cc -o yow -g yow.c cc -o env -DEMACS -g env.c cc -o emacsserver -g emacsserver.c cc -o emacsclient -g emacsclient.c cc -g b2m.c -o b2m cc -o hexl -g hexl.c cd src make rm -f xmakefile cp ymakefile junk.c gcc -E junk.c | sed -e 's/^#.*//' -e 's/^[ \f\t][ \f\t]*$//' -e 's/^ / /' | sed -n -e '/^..*$/p' > xmakefile rm -f junk.c make -f xmakefile all gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c pre-crt0.c -o pre-crt0.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c dispnew.c -o dispnew.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c screen.c -o screen.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c scroll.c -o scroll.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c xdisp.c -o xdisp.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c window.c -o window.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c events.c -o events.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c event-alloc.c -o event-alloc.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c event-stream.c -o event-stream.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c term.c -o term.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c cm.c -o cm.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c xterm.c -o xterm.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c xfns.c -o xfns.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c xselect.c -o xselect.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c xutils.c -o xutils.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c event-Xt.c -o event-Xt.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c menubar.c -o menubar.o In file included from events.h:185, from menubar.c:29: /usr/include/signal.h:350: warning: `sigmask' redefined xterm.h:113: warning: this is the location of the previous definition gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c emacs.c -o emacs.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c keyboard.c -o keyboard.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c macros.c -o macros.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c keymap.c -o keymap.o keymap.c:481: warning: static declaration for `access_keymap' follows non-static gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c sysdep.c -o sysdep.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c buffer.c -o buffer.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c filelock.c -o filelock.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c insdel.c -o insdel.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c marker.c -o marker.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c minibuf.c -o minibuf.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c fileio.c -o fileio.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c dired.c -o dired.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c filemode.c -o filemode.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c cmds.c -o cmds.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c casetab.c -o casetab.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c casefiddle.c -o casefiddle.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c indent.c -o indent.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c search.c -o search.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c regex.c -o regex.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c undo.c -o undo.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c alloc.c -o alloc.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c data.c -o data.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c doc.c -o doc.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c editfns.c -o editfns.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c callint.c -o callint.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c eval.c -o eval.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c floatfns.c -o floatfns.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c fns.c -o fns.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c print.c -o print.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c lread.c -o lread.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c abbrev.c -o abbrev.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c syntax.c -o syntax.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c unexmips.c -o unexmips.o unexmips.c:263: warning: `mark_x' was declared implicitly `extern' and later `static' gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c mocklisp.c -o mocklisp.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c bytecode.c -o bytecode.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c process.c -o process.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c callproc.c -o callproc.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c environ.c -o environ.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c doprnt.c -o doprnt.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c extents.c -o extents.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c faces.c -o faces.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c elhash.c -o elhash.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c hash.c -o hash.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c realpath.c -o realpath.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c terminfo.c -o terminfo.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c lastfile.c -o lastfile.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c gmalloc.c -o gmalloc.o gmalloc.c:219: warning: conflicting types for built-in function `memcpy' gmalloc.c: In function `__free': gmalloc.c:435: warning: comparison of distinct pointer types lacks a cast gmalloc.c: In function `realloc': gmalloc.c:965: warning: comparison of distinct pointer types lacks a cast gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c vm-limit.c -o vm-limit.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c alloca.c -o alloca.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c ScreenWidget.c -o ScreenWidget.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c ColumnWidget.c -o ColumnWidget.o gcc -g -I/usr/local/X11R4/include -Demacs -I./lwlib -c EmacsShell.c -o EmacsShell.o gcc -nostdlib -D 800000 -L/usr/local/X11R4/lib -L/user/jfinger/public-software/usr/local/lib -L. -L./lwlib -o temacs pre-crt0.o /lib/crt0.o dispnew.o screen.o scroll.o xdisp.o window.o events.o event-alloc.o event-stream.o term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o do c.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexmips.o mocklisp.o bytecode.o process.o callproc.o environ.o doprnt.o extents.o faces.o elhash.o hash.o realpath.o terminfo.o lastfile.o gmalloc.o vm-limit.o alloca.o ScreenWidget.o ColumnWidget.o EmacsShell.o -llw -lXaw -lXext -lXt -lXmu -lX11 -lcurses -lcursesX -ltermcap -lgcc -lm -lc rm -f ../etc/DOC ../etc/make-docfile dispnew.o screen.o scroll.o xdisp.o window.o events.o event-alloc.o event-stream.o term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexmips.o mocklisp.o bytecode.o process.o c allproc.o environ.o doprnt.o extents.o faces.o elhash.o hash.o realpath.o ../lisp/prim/simple.elc ../lisp/prim/help.elc ../lisp/prim/files.elc ../lisp/prim/window.elc ../lisp/prim/indent.elc ../lisp/prim/loaddefs.el ../lisp/paths.el ../lisp/prim/startup.elc ../lisp/prim/lisp.elc ../lisp/prim/page.elc ../lisp/prim/register.elc ../lisp/prim/paragraphs.elc ../lisp/modes/lisp-mode.elc ../lisp/modes/text-mode.elc ../lisp/prim/fill.elc ../lisp/modes/c-mode.elc ../lisp/prim/isearch.elc ../lisp/pri m/replace.elc ../lisp/modes/abbrev.elc ../lisp/prim/faces.elc ../lisp/packages/buff-menu.elc ../lisp/prim/subr.elc ../lisp/bytecomp/bytecomp-runtime.elc ../lisp/packages/lpr.elc ../lisp/packages/compare-w.elc ../lisp/prim/novice.elc ../lisp/prim/float-sup.elc ../lisp/x11/x-faces.elc ../lisp/x11/x-iso8859-1.elc ../lisp/x11/x-mouse.elc ../lisp/x11/xselect.elc ../lisp/version.el > ../etc/DOC ./temacs -batch -l inc-vers make[1]: *** [release] Segmentation fault (core dumped) make: *** [doall] Error 1 exit 1 From bug-lucid-emacs-request@lucid.com Sun Jul 26 19:15:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11044; Sun, 26 Jul 92 19:15:30 PDT Received: by heavens-gate.lucid.com id AA19768g; Sun, 26 Jul 92 19:06:15 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA19764g; Sun, 26 Jul 92 19:06:04 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA16069; Sun, 26 Jul 92 19:14:29 PDT Date: Sun, 26 Jul 92 19:14:29 PDT Message-Id: <9207270214.AA16069@thalidomide.lucid> X-Windows: Don't get frustrated without it. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: jfinger@adobe.com (Jeff Finger) Cc: bug-lucid-emacs@lucid.com Subject: Re: Ultrix 4.2/lemacs 19.2 temacs problem Newsgroups: alt.lucid-emacs.bug In-Reply-To: Jeff Finger's message of Mon 27-Jul-92 01:57:50 GMT <1992Jul27.015750.22024@adobe.com> References: <1992Jul27.015750.22024@adobe.com> It looks to me like the `pure' array is on a readonly page. See if you can explicitly write into it after the segv, and see if 0xc016d60 is actually inside of it. I'm not really sure why pure would be readonly, however. -- Jamie From bug-lucid-emacs-request@lucid.com Mon Jul 27 00:56:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11518; Mon, 27 Jul 92 00:56:14 PDT Received: by heavens-gate.lucid.com id AA20099g; Mon, 27 Jul 92 00:43:59 PDT Received: from lulea.trab.se (miramon.lulea.trab.se) by heavens-gate.lucid.com id AA20095g; Mon, 27 Jul 92 00:43:48 PDT Received: from holmendis.lulea.trab.se by lulea.trab.se; Mon, 27 Jul 92 09:54:59 +0200 Received: by holmendis.lulea.trab.se; Mon, 27 Jul 92 09:54:57 +0200 Message-Id: <9207270754.AA03360@holmendis.lulea.trab.se> To: bug-lucid-emacs@lucid.com Cc: petter@lulea.trab.se Subject: Please remove me! Date: Mon, 27 Jul 92 09:54:57 +0200 From: Petter Bengtsson Please remove me from this mailing list. ------------------------------------------------------------------------------- | Petter Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden | | Email: petter@lulea.trab.se Voice: (+46) 920 75476 Fax: (+46) 920 75490 | ------------------------------------------------------------------------------- From bug-lucid-emacs-request@lucid.com Mon Jul 27 13:00:10 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13778; Mon, 27 Jul 92 13:00:10 PDT Received: by heavens-gate.lucid.com id AA21475g; Mon, 27 Jul 92 12:50:51 PDT Received: from bcars520 (x400gate.bnr.ca) by heavens-gate.lucid.com id AA21471g; Mon, 27 Jul 92 12:49:59 PDT X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 27 Jul 1992 15:58:25 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 27 Jul 1992 15:59:09 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 27 Jul 1992 11:58:00 -0400 Date: Mon, 27 Jul 1992 15:58:00 +0000 X400-Originator: /DD.ID=1581776/G=Jeffrey/I=JD/S=Sparkes/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.147:27.06.92.19.59.09] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: raised/sunken... From: "Jeffrey (J.D.) Sparkes" Message-Id: <"18154 Mon Jul 27 15:59:13 1992"@bnr.ca> To: bug-lucid-emacs@lucid.com Subject: raised/sunken extents? Wouldn't it be neat if you could surround extents with raised or sunken borders so that they look kinda like motif buttons? Since it's already done for the menus, it shouldn't be *too* hard, right? :-) -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Mon Jul 27 13:23:15 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13821; Mon, 27 Jul 92 13:23:15 PDT Received: by heavens-gate.lucid.com id AA21576g; Mon, 27 Jul 92 13:13:48 PDT Received: from uu2.psi.com by heavens-gate.lucid.com id AA21572g; Mon, 27 Jul 92 13:13:24 PDT Received: from rutherford.stsi.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25476; Mon, 27 Jul 92 16:22:51 -0400 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA00558; Mon, 27 Jul 92 16:22:54 EDT Received: from cyclone.sbi.com by sbi.sbi.com (4.1/SMI-4.1) id AA09668; Mon, 27 Jul 92 16:22:54 EDT Received: from scirocco.sbi.com by cyclone.sbi.com (4.1/SMI-4.1) id AA21792; Mon, 27 Jul 92 16:22:52 EDT Date: Mon, 27 Jul 92 16:22:52 EDT From: jbm@cyclone.sbi.com (Jeffrey B. Moore) Message-Id: <9207272022.AA21792@cyclone.sbi.com> Received: by scirocco.sbi.com (4.1/SMI-4.1) id AA02746; Mon, 27 Jul 92 16:22:51 EDT To: jsparkes%x400gate.bnr.ca@lucid.com Cc: bug-lucid-emacs@lucid.com In-Reply-To: <"18154 Mon Jul 27 15:59:13 1992"@bnr.ca> (jsparkes%x400gate.bnr.ca@lucid.com) Subject: raised/sunken extents? > From: "Jeffrey (J.D.) Sparkes" > > Wouldn't it be neat if you could surround extents with raised or > sunken borders so that they look kinda like motif buttons? Since it's > already done for the menus, it shouldn't be *too* hard, right? :-) > -- > Jeff Sparkes > jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada No, it wouldn't be "neat" for *anything* to look, feel or smell more like drainbrammaged mo-effing-tif or anything else from IBM's captive Open Sore Fundament in any way. Yuck. ------ Thanks, I feel better now. If you feel a strong need to flame me, try to exercise better self control than I and avoid burning everybody's bandwidth... * All imaginable disclaimers go here; nobody is responsible for or agrees with anything * -Jeff Moore (jbm@sbi.com) From devin%scylla@lucid.com Tue Jul 28 11:08:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17074; Tue, 28 Jul 92 11:08:08 PDT Received: from scylla.lucid (scylla.lucid.com) by heavens-gate.lucid.com id AA24749g; Tue, 28 Jul 92 10:51:21 PDT Received: by scylla.lucid (4.1/SMI-4.1) id AA06388; Tue, 28 Jul 92 09:07:03 PDT Return-Path: Received: by scylla.lucid (4.1/SMI-4.1) id AA06384; Tue, 28 Jul 92 09:06:59 PDT Date: Tue, 28 Jul 92 09:06:59 PDT From: devin%scylla@lucid.com (Matthieu Devin) Message-Id: <9207281606.AA06384@scylla.lucid> To: bug-lucid-emacs@scylla Cc: devin@scylla Subject: Re: lemacs is grabbing window focus when it isn't supposed to In-Reply-To: Colas Nahaboo's message of Tue 28-Jul-92 10:32:50 +0200 <199207280832.AA14324@bagheera.inria.fr> References: <199207280832.AA14324@bagheera.inria.fr> Colas is wondering why Emacs takes the focus. This is necessary to implement select-screen: a lisp function that makes another Emacs screen be selected meaning that the typed characters go to this screen. The semantic of select-screen is really to move the keyboard focus from one Emacs screen to the other. The advantage of setting the focus is that the WM can show you with some kind of highlight where is the focus. Otherwise you end-up with one Emacs screen highlighted and the characters going into and other screen. Confusion! Explicitely taking the focus is the ICCCCCCCCCM way to do this. It does not work with bogus window managers, but it is supposed to work. (At least in our understanding of the ICCCM, if WM persons like Colas have a better understanding please, please correct me). By "does not work" I mean that Emacs sometimes steals the focus after the user thought it moved it to another window, like an xterm. We beleive we are having all those problems because Lucid Emacs seems to be the first large client to use WM_TAKE_FOCUS. First, what the ICCCM says (in my own words): When a client as WM_TAKE_FOCUS set the WM has to send a WM_TAKE_FOCUS message to ask the client if it wants the keyboard. This message has a timestamp in arg[1] (or 0?) which is most likely to be the timestamp of the XEvent that caused the WM to decide that Emacs could take the focus (an EnterWindow event, an explicit click in a title bar, etc.). The client has to answer by explicitely setting the focus to one of its windows, i.e. by calling XSetInputFocus with the timestamp passed in the event. The timestamp is the key here, it is used to solve race conditions when the WM_TAKE_FOCUS client is too slow to answer, like Emacs can be when swapped out, garbage collecting, etc. XSetInputFocus is defined as a noop if the timestamp is earlier than the timestamp of the last call to XSetInputFocus. For the timestamp to correctly solve the race condition problems a real estate driven WM has to explicitely set the Focus back to PointerRoot when the focus has to move from a WM_TAKE_FOCUS client to a non WM_TAKE_FOCUS client. Example: in a real estate driven WM, the mouse goes from an xterm to Emacs to an xterm again. The WM sends WM_TAKE_FOCUS with time t1 to Emacs and then do XSetInputFocus (t2, PointerRoot) for the xterm. When Emacs wakes up and answers the TAKE_FOCUS its call to XSetInputFocus is ignored because t1 is less than t2. So Emacs does not steal the focus. Now, the benefits: As Emacs is a WM_TAKE_FOCUS client it can explicitely switch the focus to any of its windows as long as it already has the focus when it does it and use valid timestamps in the call to XSetInputFocus (using CurrentTime here would clearly lose). The WM can track the focus changes and correctly highlight the focus window. Some WM could even decide to raise the window if the user had said that the focus window should always be on top. So unless I'm totally confused (which is extremely possible as ICCCM stuff is really hard) Emacs is doing the right thing. I know that most WM do not do the right thing yet but my guess is that it's because they did not have test cases for the full WM_TAKE_FOCUS stuff. If we disable this feature the WM will never be fixed. Colas what do you think? Can gwm do the right thing? Matthieu From bug-lucid-emacs-request@lucid.com Tue Jul 28 13:22:47 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17586; Tue, 28 Jul 92 13:22:47 PDT Received: by heavens-gate.lucid.com id AA25579g; Tue, 28 Jul 92 13:13:21 PDT Received: from mail-relay-2.mv.us.adobe.com by heavens-gate.lucid.com id AA25559g; Tue, 28 Jul 92 13:09:23 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA07233; Tue, 28 Jul 92 13:19:13 -0700 Received: by firenze.mv.us.adobe.com; id AA02767; Tue, 28 Jul 92 13:19:11 -0700 From: jfinger@mv.us.adobe.com (Jeff Finger) Message-Id: <9207282019.AA02767@firenze.mv.us.adobe.com> To: bug-lucid-emacs@lucid.com Subject: set-mouse-position Phone: (415) 962-2047 Fax: (415) 961-3769 Date: Tue, 28 Jul 92 13:19:08 MDT Sender: jfinger@mv.us.adobe.com Configuration: Decstation 5000/120 Ultrix 4.2 X11R4 twm lemacs-19.2 gcc-2.2.2 Problem: I believe set-mouse-position() breaks lemacs. I want to "warpto" (twm jargon for moving keyboard focus and pointer to an X window) various known screen, for example, left-screen. If I just do select-screen, keyboard focus is in the correct X window, but the pointer stays where it was, and X highlighting is not done correctly. (defvar left-screen (x-create-screen nil) "Smaller l-emacs Screen on my left") (defun select-left-screen () (interactive) (select-screen left-screen) (set-mouse-position left-screen 1 1)) Adding set-mouse-position() moves the pointer and gets X highlighting correct, but the next command causes lemacs to crash. Questions: 1. Is there a bug in set-mouse-position or related code. 2. Is there a better way to do a "warpto"? 3. (set-mouse-position WINDOW 0 0) causes an immediate crash. There should be code to check for this. Thanks, -- Jeff Finger -- From bug-lucid-emacs-request@lucid.com Tue Jul 28 13:37:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17647; Tue, 28 Jul 92 13:37:01 PDT Received: by heavens-gate.lucid.com id AA25672g; Tue, 28 Jul 92 13:27:31 PDT Received: from watergate.lucid ([192.31.212.117]) by heavens-gate.lucid.com id AA25657g; Tue, 28 Jul 92 13:25:07 PDT Received: by watergate.lucid (4.1/SMI-4.1) id AA24956; Tue, 28 Jul 92 13:35:03 PDT Date: Tue, 28 Jul 92 13:35:03 PDT From: eb%watergate@lucid.com (Eric Benson) Message-Id: <9207282035.AA24956@watergate.lucid> To: jfinger@mv.us.adobe.com (Jeff Finger) Cc: bug-lucid-emacs@lucid.com Subject: Re: set-mouse-position In-Reply-To: Jeff Finger's message of Tue 28-Jul-92 13:19:08 MDT <9207282019.AA02767@firenze.mv.us.adobe.com> References: <9207282019.AA02767@firenze.mv.us.adobe.com> Reply-To: eb@lucid.com I can't reproduce any of these problems in our latest development lemacs on a Sun-4. That doesn't mean there might not be a bug in there somewhere, but it's going to make it difficult to find... From bug-lucid-emacs-request@lucid.com Tue Jul 28 20:25:52 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18526; Tue, 28 Jul 92 20:25:52 PDT Received: by heavens-gate.lucid.com id AA27623g; Tue, 28 Jul 92 20:15:59 PDT Received: from lysator.liu.se by heavens-gate.lucid.com id AA27619g; Tue, 28 Jul 92 20:15:44 PDT Received: by lysator.liu.se (5.65c8/1.34/Lysator-3.1) id AA08078; Wed, 29 Jul 1992 05:25:24 +0200 (rfc931-sender: linus@lysator.liu.se) Date: Wed, 29 Jul 1992 05:25:24 +0200 From: linus%lysator.liu.se@lucid.com (Linus Tolke Y) Message-Id: <199207290325.AA08078@lysator.liu.se> To: bug-lucid-emacs@lucid.com Subject: info.el (Info-select-node-menu): popup-menu Keywords: popup-menu Summary: noticed and fixed bug introduced in 19.2 in info.el From lucid-emacs-19.1 to lucid-emacs-19.2 popup-menu was rewritten. The doc-string was improved but backward compatibility was not provided and since the info.el was not updated it was not longer possible to use the popup-menu (on the right button). Another thing: In the info-page: * Menu: The list of major topics begins on the next line. * Info: (info). Documentation browsing system. * Emacs-info: (emacs). The extensible self-documenting text editor. * Elisp: (elisp). Gnu Emacs Lisp Reference Manual. * Emacs:: Documentation for Emacs utilities. It was not possible to select the node * Emacs:: since the search was just done on "* Emacs". Not first on "* Emacs:". I have fixed these problems and also rewritten the popup-menu function as to make sub-menus instead of concatenating everything in one menu. A bug I have not fixed is that the info-mode highlighting/italic and bold info is connected to one screen only, the screen that was current when loading the file. This should of course follow the buffer on any screen. Here is my patch. If you don't want the submenus thing then just don't use the third (last and longest) part of the patch. -- /Linus ***** Wherever I exec my `which emacs`, is my $HOME. ***** Linus Tolke SM7OUU, linus@lysator.liu.se Student at the member of SK5EU LiTHSA Link|ping institute of technology, LiTH LiTH S{ndare Amat|rer (Ham-club) ================================================================ diff -u info.el.19.1 info.el --- info.el.19.1 Tue May 19 22:03:10 1992 +++ info.el Tue Jul 28 23:50:29 1992 @@ -518,7 +518,8 @@ (goto-char (point-min)) (or (search-forward "\n* menu:" nil t) (error "No menu in this node")) - (or (search-forward (concat "\n* " menu-item) nil t) + (or (search-forward (concat "\n* " menu-item ":") nil t) + (search-forward (concat "\n* " menu-item) nil t) (error "No such item in menu")) (beginning-of-line) (forward-char 2) @@ -902,7 +903,7 @@ (if (looking-at ".*\\bNext:") (setq next-p t)) (if (looking-at ".*\\bPrev:") (setq prev-p t)) (if (looking-at ".*Up:") (setq up-p t)) - (setq menu (nconc (list nil "Info Commands:" "----") + (setq menu (nconc (list "Info Commands:" "----") (if (setq in (Info-indicated-node event)) (list (vector (car (cdr in)) in t))) (list @@ -930,20 +931,25 @@ (if (> (length subnodes) 21) (setcdr (nthcdr 20 subnodes) '(more))) ) (if xrefs - (nconc menu (list "----" "Cross-References:" "----") - (mapcar (function (lambda (xref) - (if (eq xref 'more) - "...more..." - (vector xref - (list 'Info-follow-reference xref) - t)))) - xrefs))) + (nconc menu + (list + (apply 'list "Cross-References:" "----" + (mapcar (function + (lambda (xref) + (if (eq xref 'more) + "...more..." + (vector xref + (list 'Info-follow-reference xref) + t)))) + xrefs))))) (if subnodes - (nconc menu (list "----" "Sub-Nodes:" "----") - (mapcar (function (lambda (node) - (if (eq node 'more) - "...more..." - (vector node (list 'Info-menu node) - t)))) - subnodes))) + (nconc menu + (list + (apply 'list "Sub-Nodes:" "----" + (mapcar (function (lambda (node) + (if (eq node 'more) + "...more..." + (vector node (list 'Info-menu node) + t)))) + subnodes))))) (popup-menu menu))) From bug-lucid-emacs-request@lucid.com Wed Jul 29 15:10:16 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22020; Wed, 29 Jul 92 15:10:16 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01415g; Wed, 29 Jul 92 14:59:52 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18296; Wed, 29 Jul 92 18:09:42 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18289; Wed, 29 Jul 92 18:09:41 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA04373; Wed, 29 Jul 92 18:11:09 -0400 Path: uunet!cs.utexas.edu!news From: cmkuo@cs.utexas.edu (Chin-Ming Kuo) Newsgroups: alt.lucid-emacs.bug Subject: lhilit.el, ifdef VMS Date: 29 Jul 1992 17:09:22 -0500 Organization: CS Dept, University of Texas at Austin Message-Id: Keywords: masking off ifdef Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I just tried the lhilit.el, and IT'S GREAT!!!! While experimenting with different color combination, I thought of would it be nice to have the hilit mode automatically mask off (by setting the forground color to background) ifdef pair. Specifically, make >>>>>>>>>> diskname = malloc(...); #ifdef VMS /* initialize descriptor */ PACK_DESCRIP(dsp, diskname, strlen(diskname)); PACK_LIST(mylist, 4, avail, r_length); #endif .... >>>>>>>>>> into >>>>>>>>>> diskname = malloc(...); .... >>>>>>>>>> if on non-VMS machine. Any clue as to how to do it? This will be a good exercise for me to use elisp. Thanks. -- Chin-Ming Kuo cmkuo@cs.utexas.edu {uunet,rutgers,ti-csl}!cs.utexas.edu!cmkuo From bug-lucid-emacs-request@lucid.com Wed Jul 29 15:40:52 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22084; Wed, 29 Jul 92 15:40:52 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01597g; Wed, 29 Jul 92 15:31:10 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA19356; Wed, 29 Jul 92 18:40:52 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA19350; Wed, 29 Jul 92 18:40:49 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA04509; Wed, 29 Jul 92 18:42:14 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs is grabbing window focus when it isn't supposed to Message-Id: Date: 29 Jul 92 13:06:32 GMT References: <199207280832.AA14324@bagheera.inria.fr> <9207281606.AA06384@scylla.lucid> Organization: Human Communication Research Center In-Reply-To: devin%scylla@lucid.com's message of 28 Jul 92 16:06:59 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com If one was being argumentitive it is possible to interpret the ICCCM as meaning that a `locally active focus model' client is only supposed to throw the focus around between windows within one top level shell. On the other hand the lemacs behaviour seems reasonable since it allows the focus to be thrown around in a controled way from the keyboard. Sometimes the details are a little odd -- the focus shouldn't shift as a side effect of anything and the minibuffer handling can really screw things up. Twm-based window managers can't cope with lemacs since they don't pay attension to focus changes by other clients. I changed tvtwm to do the Right Thing and it isn't hideously difficult. I'm not sure if the patches would qapply to a straight twm. No matter what, though, it breaks the rule that the mouse and the keyboard focus move together. This could be fixed if there was some way of warping the mouse to follow the focus which didn't cause half a million enter and leave events on the way. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Wed Jul 29 15:55:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22098; Wed, 29 Jul 92 15:55:42 PDT Received: by heavens-gate.lucid.com id AA01692g; Wed, 29 Jul 92 15:46:19 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA01674g; Wed, 29 Jul 92 15:44:04 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA23407; Wed, 29 Jul 92 15:52:32 PDT Date: Wed, 29 Jul 92 15:52:32 PDT Message-Id: <9207292252.AA23407@thalidomide.lucid> X-Windows: The Cutting Edge of Obsolescence. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: rjc@cogsci.ed.ac.uk (Richard Caley) Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs is grabbing window focus when it isn't supposed to Newsgroups: alt.lucid-emacs.bug In-Reply-To: Richard Caley's message of 29-Jul-92 13:06:32 GMT References: <199207280832.AA14324@bagheera.inria.fr> <9207281606.AA06384@scylla.lucid> In message Richard Caley wrote: > > Sometimes the details are a little odd -- the focus shouldn't shift as a > side effect of anything I agree. > and the minibuffer handling can really screw things up. I think the way the minibuffer deals with multiple screens is generally broken. If something is being displayed in the minibuffer or echo area, it should be displayed simultaniously on all screens, just like a normal buffer that was visible in multiple windows. > No matter what, though, it breaks the rule that the mouse and the > keyboard focus move together. This could be fixed if there was some > way of warping the mouse to follow the focus which didn't cause half a > million enter and leave events on the way. If any warping was to be done, it should be in the window manager, not emacs. It would be reasonable for a window manager to warp the mouse as a result of a client taking the focus. (I wouldn't use that wm, though :-)) -- Jamie From bug-lucid-emacs-request@lucid.com Wed Jul 29 17:41:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22347; Wed, 29 Jul 92 17:41:06 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02283g; Wed, 29 Jul 92 17:31:31 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA08166; Wed, 29 Jul 92 20:41:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA08158; Wed, 29 Jul 92 20:41:22 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA04984; Wed, 29 Jul 92 20:42:53 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!zaphod.mps.ohio-state.edu!wupost!gumby!destroyer!ais.org!umeecs!news-server.eecs.umich.edu!garath From: garath@engin.umich.edu (morris) Subject: Re: lhilit.el, ifdef VMS In-Reply-To: cmkuo@cs.utexas.edu's message of 29 Jul 1992 17:09:22 -0500 Message-Id: Organization: University of Michigan References: Date: Thu, 30 Jul 1992 01:22:04 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article cmkuo@cs.utexas.edu (Chin-Ming Kuo) writes: Any clue as to how to do it? This will be a good exercise for me to use elisp. Thanks. You could just use the hideif.el file already provided in the standard distribution. Just (load "hideif" nil t) and then when editing a C file do M-x hide-ifdef-mode....there's lots of settings to make things totally disappear like you want, you just gotta figure out which ones you like. -- Scott Grosch Internet: garath@engin.umich.edu Programmer Bitnet: user7a4b@umichu Computer Aided Engineering Network University of Michigan From bug-lucid-emacs-request@lucid.com Thu Jul 30 05:49:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24282; Thu, 30 Jul 92 05:49:57 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA04578g; Thu, 30 Jul 92 05:37:44 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA08267; Thu, 30 Jul 92 08:47:30 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA08259; Thu, 30 Jul 92 08:47:27 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA07766; Thu, 30 Jul 92 08:49:05 -0400 Path: uunet!mcsun!corton!sophia!bagheera.inria.fr!colas From: colas%bagheera.inria.fr@lucid.com (Colas Nahaboo) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs is grabbing window focus when it isn't supposed to Message-Id: <25931@sophia.inria.fr> Date: 30 Jul 92 12:40:55 GMT References: <199207280832.AA14324@bagheera.inria.fr> <9207281606.AA06384@scylla.lucid> Organization: Koala Project, Bull Research France Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9207281606.AA06384@scylla.lucid>, devin%scylla@lucid.com (Matthieu Devin) writes: |> Colas is wondering why Emacs takes the focus. This is necessary to |> implement |> First, what the ICCCM says (in my own words): ... |> Colas what do you think? I just checked, you are right, I was wrong. (technical details: I was thinking that a WM_TAKE_FOCUS from wm->client with timestamp being CurrentTime (0), which IS NOT allowed in the ICCCM) |> Can gwm do the right thing? Of course, no question about it. I was just fooled because other WMs exhibited the same behavior... -- Colas Nahaboo, colas@sa.inria.fr, Bull Research Koala proj. Wool&Gwm Architect Pho:(33) 93.65.77.70(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE. From bug-lucid-emacs-request@lucid.com Thu Jul 30 12:12:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25398; Thu, 30 Jul 92 12:12:22 PDT Received: by heavens-gate.lucid.com id AA06071g; Thu, 30 Jul 92 12:02:28 PDT Received: from canopus.cis.ksu.edu by heavens-gate.lucid.com id AA06062g; Thu, 30 Jul 92 12:01:46 PDT Return-Path: Received: by canopus.cis.ksu.edu (5.65a) id AA14321; Thu, 30 Jul 92 14:11:36 -0500 Date: Thu, 30 Jul 92 14:11:36 -0500 From: frain@cis.ksu.edu (Jerry Frain) Message-Id: <9207301911.AA14321@canopus.cis.ksu.edu> To: bug-lucid-emacs@lucid.com Subject: Permission denied when running compile Reply-To: frain@cis.ksu.edu X-Organization: KSU Dept. of Computing and Information Sciences X-Office: Nichols 117 X-Phone: (913) 532-6350 - ext. 45 X-Fax: (913) 532-7353 When I try to compile --Jerry Frain, frain@cis.ksu.edu From bug-lucid-emacs-request@lucid.com Thu Jul 30 12:13:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25404; Thu, 30 Jul 92 12:13:25 PDT Received: by heavens-gate.lucid.com id AA06082g; Thu, 30 Jul 92 12:04:03 PDT Received: from canopus.cis.ksu.edu by heavens-gate.lucid.com id AA06076g; Thu, 30 Jul 92 12:03:29 PDT Return-Path: Received: by canopus.cis.ksu.edu (5.65a) id AA14326; Thu, 30 Jul 92 14:13:22 -0500 Date: Thu, 30 Jul 92 14:13:22 -0500 From: frain@cis.ksu.edu (Jerry Frain) Message-Id: <9207301913.AA14326@canopus.cis.ksu.edu> To: bug-lucid-emacs@lucid.com Subject: Permission denied when running compile. Reply-To: frain@cis.ksu.edu X-Organization: KSU Dept. of Computing and Information Sciences X-Office: Nichols 117 X-Phone: (913) 532-6350 - ext. 45 X-Fax: (913) 532-7353 Sorry for the last incomplete message. When I try to run compile, I get the following message: tcsh: Permission denied. Compilation exited abnormally with code 1 at Thu Jul 30 14:12:27 The same commands/shells run fine with GNU Emacs 18. Any clues on how this can be fixed? Thanks in advance, --Jerry Frain, frain@cis.ksu.edu From bug-lucid-emacs-request@lucid.com Thu Jul 30 16:07:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25933; Thu, 30 Jul 92 16:07:24 PDT Received: by heavens-gate.lucid.com id AA07143g; Thu, 30 Jul 92 15:54:50 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA07139g; Thu, 30 Jul 92 15:54:37 PDT Return-Path: Received: from sergei.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA07745; Thu, 30 Jul 92 19:02:16 -0400 Received: by sergei.mitre.org (4.1/SMI-4.1) id AA05713; Thu, 30 Jul 92 19:03:59 EDT Date: Thu, 30 Jul 92 19:03:59 EDT From: bcotton@sergei.mitre.org (Robert T. Cotton) Message-Id: <9207302303.AA05713@sergei.mitre.org> To: bug-lucid-emacs@lucid.com Subject: x-raise-screen Broken (with fix) Beacuse (according to config.h) lemacs cannot be compiled with ENERGIZE defined, rasie-screen fails to set the stack_mode and flags for the XConfigureWindow call.. Here is the fix. Bob Cotton *** /usr2/lemacs-19.2/src/xterm.c Tue Jun 16 04:37:05 1992 --- xterm.c Thu Jul 30 18:58:37 1992 *************** *** 2507,2512 **** --- 2507,2516 ---- xwc.stack_mode = Above; flags = CWStackMode; } + #else + + xwc.stack_mode = Above; + flags = CWStackMode; #endif /* get ready to handle the error generated by XConfigureWindow */ From bug-lucid-emacs-request@lucid.com Fri Jul 31 03:22:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27747; Fri, 31 Jul 92 03:22:26 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA09067g; Fri, 31 Jul 92 03:07:43 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20092; Fri, 31 Jul 92 06:17:32 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA20073; Fri, 31 Jul 92 06:17:25 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA15861; Fri, 31 Jul 92 06:19:12 -0400 Path: uunet!mcsun!corton!sophia!bagheera.inria.fr!colas From: colas%bagheera.inria.fr@lucid.com (Colas Nahaboo) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs is grabbing window focus when it isn't supposed to Message-Id: <26012@sophia.inria.fr> Date: 31 Jul 92 09:47:39 GMT References: <199207280832.AA14324@bagheera.inria.fr> Organization: Koala Project, Bull Research France Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article , rjc@cogsci.ed.ac.uk (Richard Caley) writes: |> No matter what, though, it breaks the rule that the mouse and the |> keyboard focus move together. this is NOT a rule. only one policy, and most windowing systems in the world (Windows, mac, motif) implement the other click-to-type policy (even if you can customize mwm to be real-estate, the Motif styleguide stil mandates click-to-type I think..) |>This could be fixed if there was some |> way of warping the mouse to follow the focus which didn't cause half a |> million enter and leave events on the way. Now, warping the mouse cursor is definitively a bad idea... -- Colas Nahaboo, colas@sa.inria.fr, Bull Research Koala proj. Wool&Gwm Architect Pho:(33) 93.65.77.70(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE. From bug-lucid-emacs-request@lucid.com Fri Jul 31 15:42:53 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29516; Fri, 31 Jul 92 15:42:53 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA00669g; Fri, 31 Jul 92 15:28:28 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA10250; Fri, 31 Jul 92 18:38:22 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA10244; Fri, 31 Jul 92 18:38:20 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA20771; Fri, 31 Jul 92 18:40:13 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs is grabbing window focus when it isn't supposed to Message-Id: Date: 31 Jul 92 18:49:12 GMT References: <199207280832.AA14324@bagheera.inria.fr> <26012@sophia.inria.fr> Organization: Human Communication Research Center In-Reply-To: colas@bagheera.inria.fr's message of 31 Jul 92 09:47:39 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <26012@sophia.inria.fr>, Colas Nahaboo (cn) writes: In article , rjc@cogsci.ed.ac.uk (Richard Caley) writes: rjc> No matter what, though, it breaks the rule that the mouse and the rjc> keyboard focus move together. cn> this is NOT a rule. only one policy, Ah, context is everything. I was just talking about twm and derivatives. cn> and most windowing systems in the world (Windows, mac, motif) cn> implement the other click-to-type policy I can't think of a better argument for focus-follows-mouse than that windows, the mac and motif do it the other way. :-| That is a list of the three worst GUIs it has been my misfortune to have to use. rjc> This could be fixed if there was some way of warping the mouse to rjc> follow the focus which didn't cause half a million enter and rjc> leave events on the way. cn> Now, warping the mouse cursor is definitively a bad idea... In general yes, but if the user specifically asks for the focus to move in a focus follows mouse system, the consistant thing to do is to move the mouse pointer. In this case the focus shift command (e.g. M-o in lemacs) is an accelorater for moving the mouse. Of course, so long as lemacs shifts the focus at unreasonable times (e.g. C-x 5) the warping would be a pain in the backside. I think lemacs has it backwards, select-screen should be tied to focus-in events and then the user could move between screens using whatever focus shifting conventions they usually used. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Fri Jul 31 16:39:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29662; Fri, 31 Jul 92 16:39:34 PDT Received: by heavens-gate.lucid.com id AA00945g; Fri, 31 Jul 92 16:29:52 PDT Received: from scylla.lucid (scylla.lucid.com) by heavens-gate.lucid.com id AA00939g; Fri, 31 Jul 92 16:28:11 PDT Received: by scylla.lucid (4.1/SMI-4.1) id AA20588; Fri, 31 Jul 92 16:35:08 PDT Date: Fri, 31 Jul 92 16:35:08 PDT From: devin%scylla@lucid.com (Matthieu Devin) Message-Id: <9207312335.AA20588@scylla.lucid> To: rjc@cogsci.ed.ac.uk (Richard Caley) Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs is grabbing window focus when it isn't supposed to Newsgroups: alt.lucid-emacs.bug In-Reply-To: Richard Caley's message of 31-Jul-92 18:49:12 GMT References: <199207280832.AA14324@bagheera.inria.fr> <26012@sophia.inria.fr> In message Richard Caley wrote: > > I think lemacs has it backwards, select-screen should be tied to > focus-in events and then the user could move between screens using > whatever focus shifting conventions they usually used. I agree with that, but you know those emacs people, they want to be able to do everything from Emacs Lisp so we had to provide this select-screen function. A focus-in event actually calls select-screen in an indirect way. From bug-lucid-emacs-request@lucid.com Wed Aug 5 02:18:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13664; Wed, 5 Aug 92 02:18:02 PDT Received: by heavens-gate.lucid.com id AA17891g; Wed, 5 Aug 92 02:03:16 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA17886g; Wed, 5 Aug 92 02:02:58 PDT Received: by moebius.loria.fr id AA12004 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Wed, 5 Aug 92 10:16:14 +0200 Date: Wed, 5 Aug 92 10:16:14 +0200 From: Guido Bosch Message-Id: <9208050816.AA12004@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: lisp-indent-function for add-hook Reply-To: Guido BOSCH Hi, `add-hook' is really a big help for dealing with hooks. However, its lisp indentation (the standard function indentation) is rather cumbersome. I suggest the following prog1 like indentation: (add-hook 'hook 'my-hook) (add-hook 'hook 'my-hook) At the moment, it looks like this: (add-hook 'hook 'my-hook) (add-hook 'hook 'my-hook) Here is the patch: --------------------------- cut here ---------------------------- *** subr.el.orig Mon May 11 12:28:05 1992 --- subr.el Wed Aug 5 09:59:16 1992 *************** *** 202,207 **** --- 202,208 ---- "Variable by which C primitives find the function `run-hooks'. Don't change it.") + (put 'add-hook 'lisp-indent-function 1) (defun add-hook (hook-var function) "Add a function to a hook. First argument HOOK-VAR (a symbol) is the name of a hook, second ------------------------------ end ------------------------------ Guido From me@Sunburn.Stanford.EDU Wed Aug 5 17:59:15 1992 Received: from Sunburn.Stanford.EDU by labrea.Stanford.EDU (4.1/1.34) id AA18909; Wed, 5 Aug 92 17:59:15 PDT Received: by Sunburn.Stanford.EDU (5.61+IDA/25-eef) id AA21321; Wed, 5 Aug 92 17:58:16 -0700 Date: Wed, 5 Aug 92 17:58:16 -0700 From: Martin Frost Message-Id: <9208060058.AA21321@Sunburn.Stanford.EDU> To: bug-lucid-emacs-archive@labrea.Stanford.EDU Subject: test Reply-To: me@CS.Stanford.EDU just a test. From me@Sunburn.Stanford.EDU Wed Aug 5 18:14:40 1992 Received: from Sunburn.Stanford.EDU by labrea.Stanford.EDU (4.1/1.34) id AA18967; Wed, 5 Aug 92 18:14:40 PDT Received: by Sunburn.Stanford.EDU (5.61+IDA/25-eef) id AA21543; Wed, 5 Aug 92 18:13:42 -0700 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18639; Wed, 5 Aug 92 16:12:42 PDT Received: by heavens-gate.lucid.com id AA20600g; Wed, 5 Aug 92 16:03:00 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA20575g; Wed, 5 Aug 92 16:00:28 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01500; Wed, 5 Aug 92 16:09:11 PDT Date: Wed, 5 Aug 92 16:09:11 PDT Message-Id: <9208052309.AA01500@thalidomide.lucid> X-Windows: graphics hacking :: roman numerals : sqrt(pi) From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com Xto: rjc@cogsci.ed.ac.uk (Richard Caley) Xcc: bug-lucid-emacs@lucid.com Subject: Re: autoload. Newsgroups: alt.lucid-emacs.bug In-Reply-To: Richard Caley's message of 5-Aug-92 16:14:37 GMT References: Apparently-To: Are you sure the old tex-mode wasn't loaded already? Autoload doesn't do anything if the function is already defined as a non-autoload. Possibly some other function is autoloaded from the old tex-mode and you're calling that before TeX-mode. Look at (symbol-function 'TeX-mode). -- Jamie From bug-lucid-emacs-request@lucid.com Thu Aug 6 15:40:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22187; Thu, 6 Aug 92 15:40:06 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA24866g; Thu, 6 Aug 92 15:28:41 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18525; Thu, 6 Aug 92 18:38:43 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18516; Thu, 6 Aug 92 18:38:41 -0400 Received: from USENET (alt.lucid-emacs.bug) by news.UU.NET with InterNetNews (5.61/UUNET-mail-leaf) id AA14110; Thu, 6 Aug 92 18:39:25 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: Re: autoload. Message-Id: Date: 6 Aug 92 17:29:31 GMT References: <9208052309.AA01500@thalidomide.lucid> Organization: Human Communication Research Center In-Reply-To: jwz@lucid.com's message of 5 Aug 92 23:09:11 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9208052309.AA01500@thalidomide.lucid>, Jamie Zawinski (jz) writes: jz> Look at (symbol-function 'TeX-mode). Aha! TeX-mode is defined to be tex-mode which is an autoload. My attempt to set an autoload for TeX-mode was therefore failing because it had a non-autoload definition. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Fri Aug 7 12:17:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02934; Fri, 7 Aug 92 12:17:02 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA28455g; Fri, 7 Aug 92 12:04:14 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07965; Fri, 7 Aug 92 15:14:19 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07961; Fri, 7 Aug 92 15:14:17 -0400 Path: uunet!mcsun!sunic!dkuug!iesd!iesd.auc.dk!abraham From: abraham%iesd.auc.dk@lucid.com (Per Abrahamsen) Newsgroups: alt.lucid-emacs.bug Subject: Re: autoload. Message-Id: Date: 7 Aug 92 19:28:27 GMT References: Distribution: alt Organization: Mathematics and Computer Science, Aalborg University Lines: 8 In-Reply-To: rjc@cogsci.ed.ac.uk's message of 5 Aug 92 16:14:37 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Sounds like tex-mode is pre-loaded into your copy of Lucid Emacs. In that case, you will have to recompile emacs without the standard tex-mode. If Lucid is distributing the binary version of their emacs variant with tex-mode pre-loaded, then they should stop doing that. tex-mode is the first thing to be replaced when you install emacs. From bug-lucid-emacs-request@lucid.com Sun Aug 9 15:21:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08770; Sun, 9 Aug 92 15:21:01 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA04849g; Sun, 9 Aug 92 14:56:03 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04636; Sun, 9 Aug 92 18:06:10 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA04632; Sun, 9 Aug 92 18:06:09 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: Yet another focus feature. Message-Id: Date: 8 Aug 92 13:26:27 GMT Distribution: alt Organization: Human Communication Research Center Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com [I don't think I've mentioned this one before] I think select-screen should only be possible on mapped screens. More specifically M-o should cycle through only mapped screens. My understanding is that only mapped windows can have keyboard focus and this means that there is no help for lemacs and the WM getting out of phase if lemacs pretends to put the focus to an umapped display. -- rjc@cogsci.ed.ac.uk Just lost my focus by having my hand rest on Meta... From bug-lucid-emacs-request@lucid.com Wed Aug 12 03:31:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17658; Wed, 12 Aug 92 03:31:48 PDT Received: by heavens-gate.lucid.com id AA14647g; Wed, 12 Aug 92 03:18:59 PDT Received: from munnari.oz.au by heavens-gate.lucid.com id AA14643g; Wed, 12 Aug 92 03:18:41 PDT Received: from uniwa.uwa.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09717; Wed, 12 Aug 1992 20:28:37 +1000 (from toivo@sage.ucs.uwa.edu.au) Received: from sage.ucs.uwa.edu.au by uniwa.uwa.edu.au with SMTP (5.65c) id AA07657; Wed, 12 Aug 1992 18:28:33 +0800 Received: by sage.ucs.uwa.edu.au (4.1/SMI-4.1) id AA08259; Wed, 12 Aug 92 18:28:31 WST Date: Wed, 12 Aug 92 18:28:31 WST From: toivo%sage.ucs.uwa.edu.au@lucid.com (Toivo Pedaste) Message-Id: <9208121028.AA08259@sage.ucs.uwa.edu.au> To: bug-lucid-emacs@lucid.com Subject: Ultrix and asycnronous processes problem Has anybody come up with a solution to the problem with Ultrix and async processes, eg hanging when using emacs-client. With a bit af debuging I found that lemacs is doing a 1024 byte read from the process, this is obviously relying on something other that 1024 bytes to terminate it. What mechanism is lemacs using for this. I compiled it using the bsd4.2 config. ------------------------------------------------------------------ Toivo Pedaste Email: toivo@ucs.uwa.edu.au University Computing Services, Phone: +61 9 380 2605 University of Western Australia Fax: +61 9 380 1014 From bug-lucid-emacs-request@lucid.com Wed Aug 12 04:12:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17726; Wed, 12 Aug 92 04:12:03 PDT Received: by heavens-gate.lucid.com id AA14718g; Wed, 12 Aug 92 04:00:25 PDT Received: from gate.demon.co.uk by heavens-gate.lucid.com id AA14706g; Wed, 12 Aug 92 03:58:42 PDT Received: from jclark.com by gate.demon.co.uk id aa14719; 12 Aug 92 12:07 BST Received: by jclark.com (4.1/SMI-4.1) id AA20143; Wed, 12 Aug 92 12:07:27 BST Date: Wed, 12 Aug 92 12:07:27 BST From: James Clark Message-Id: <9208121107.AA20143@jclark.com> To: bug-lucid-emacs@lucid.com Subject: save-some-buffers v rmail Is there some good reason why save-some-buffers skips rmail buffers? I typically have a dozen or so rmail buffers, and I find it annoying to have to save each one manually. James Clark jjc@jclark.com From bug-lucid-emacs-request@lucid.com Wed Aug 12 07:58:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18304; Wed, 12 Aug 92 07:58:39 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA15276g; Wed, 12 Aug 92 07:49:46 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18328; Wed, 12 Aug 92 10:59:57 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18301; Wed, 12 Aug 92 10:59:50 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bwdls61!bwdls138!jsparkes From: jsparkes%bwdls138.bnr.ca@lucid.com (Jeff Sparkes) Subject: no previous-screen function in lemacs 19.2 Message-Id: <1992Aug12.143845.6161@bwdls61.bnr.ca> Nntp-Posting-Host: bwdls138 Organization: Bell-Northern Research Ltd., Ottawa Date: Wed, 12 Aug 1992 14:38:45 GMT Lines: 8 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Probably an oversight. The is a next-screen, and the stub code function prev_screen in screen.c. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Wed Aug 12 08:33:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18402; Wed, 12 Aug 92 08:33:28 PDT Received: by heavens-gate.lucid.com id AA15334g; Wed, 12 Aug 92 08:21:46 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA15330g; Wed, 12 Aug 92 08:21:31 PDT Received: by moebius.loria.fr id AA16751 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Wed, 12 Aug 92 17:31:49 +0200 Date: Wed, 12 Aug 92 17:31:49 +0200 From: Guido Bosch Message-Id: <9208121531.AA16751@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: bogus elisp function `read-no-blanks-input' Reply-To: Guido BOSCH The function `read-no-blanks-input' doesn't work in Lucid Emacs 19.2. It produces the error "Wrong number of arguments" ------------------------------ *Help* ------------------------------ read-no-blanks-input: (prompt init) Args PROMPT and INIT, strings. Read a string from the terminal, not allowing blanks. Prompt with PROMPT, and provide INIT as an initial value of the input string. -------------------------------------------------------------------- (read-no-blanks-input "Prompt: " "init") -> Wrong number of arguments: #, 2 Guido From bug-lucid-emacs-request@lucid.com Wed Aug 12 16:18:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19410; Wed, 12 Aug 92 16:18:23 PDT Received: by heavens-gate.lucid.com id AA17315g; Wed, 12 Aug 92 16:07:30 PDT Received: from sgi.sgi.com (SGI.COM) by heavens-gate.lucid.com id AA17311g; Wed, 12 Aug 92 16:07:19 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for bug-lucid-emacs@lucid.com id AA29390; Wed, 12 Aug 92 16:17:38 -0700 Received: from giraffe.asd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:bug-lucid-emacs@lucid.com id AA20759; Wed, 12 Aug 92 16:04:26 -0700 Received: from powerslide.asd.sgi.com by giraffe.asd.sgi.com via SMTP (911016.SGI/910805.SGI) for @relay.sgi.com:bug-lucid-emacs@lucid.com id AA16136; Wed, 12 Aug 92 16:04:25 -0700 Received: from localhost. by powerslide.asd.sgi.com via SMTP (911016.SGI/911001.SGI) for @giraffe.asd.sgi.com:bug-lucid-emacs@lucid.com id AA28789; Wed, 12 Aug 92 16:04:23 -0700 Message-Id: <9208122304.AA28789@powerslide.asd.sgi.com> To: bug-lucid-emacs@lucid.com Cc: iain@powerslide.asd.sgi.com, rickb@powerslide.asd.sgi.com Subject: lemacs split-window-horizontally fails on SGI Date: Wed, 12 Aug 92 16:04:22 -0700 From: Iain McClatchie I'm running lemacs on an SGI Indigo under IRIX 4.0.5. (emacs-version) -> "GNU Emacs 19.2.81 Lucid of Tue Jul 7 1992 on liasg2 (silicon-graphics-unix)" If I do split-screen-horizontally, the display becomes badly messed up. If I switch to the right hand window, the characters I type show up on the left, and many copies of the cursor show up on the right. I don't mean live, moving cursors, I mean lots of static ghosts. Basically, I don't think the display code is working properly. Unfortunately, I got my executable from Shankar Unni, who got his executable from simon@lia.di.epfl.ch. I can get a tar file for the source-diffs. Would you like me to send you the source diffs? How else can I help you get this bug? -Iain McClatchie iain@asd.sgi.com 415-390-1005 From bug-lucid-emacs-request@lucid.com Thu Aug 13 00:29:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20364; Thu, 13 Aug 92 00:29:02 PDT Received: by heavens-gate.lucid.com id AA18860g; Thu, 13 Aug 92 00:20:11 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA18855g; Thu, 13 Aug 92 00:19:58 PDT Received: by liasg1.epfl.ch (/\==/\ Smail3.1.25.1 #25.7) id ; Thu, 13 Aug 92 09:30 MDT Message-Id: Date: Thu, 13 Aug 92 09:30 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: Iain McClatchie Cc: bug-lucid-emacs@lucid.com, iain@powerslide.asd.sgi.com, rickb@powerslide.asd.sgi.com Subject: lemacs split-window-horizontally fails on SGI In-Reply-To: <9208122304.AA28789@powerslide.asd.sgi.com> References: <9208122304.AA28789@powerslide.asd.sgi.com> The brokenness of horizontally split window display is not SGI-specific - I can reproduce it on the Sun 4 version. (Maybe it's a feature because the documentation says: emacs-6: `C-x 5' (`split-window-horizontally') breaks the selected window :-) Btw. this looks like a documentation bug since C-x 5 is bound to `x-new-screen' (at least for me). > Unfortunately, I got my executable from Shankar Unni, who got his > executable from simon@lia.di.epfl.ch. I can get a tar file for the > source-diffs. The diffs (as well as the SGI binaries) can be FTPed anonymously from liasun3.epfl.ch:/pub/gnu. -rw-r--r-- 1 simon 2656767 Jul 7 17:29 lemacs-19.2-sgi.tar.Z -rw-r--r-- 1 simon 43892 Jul 9 19:10 lemacs-19.2.udiff.sgi.Z > How else can I help you get this bug? You mean get as in catch or as in suffer from it? I think the display code of Lemacs is currently in a state of transition and it is quite natural that there are some bugs in the less-excercised portions. Hope this helps, -- Simon Leinen. Laboratoire d'Intelligence Artificielle Ecole Polytechnique Federale de Lausanne MA-Ecublens CH-1015 Lausanne Tel.: +41-21-693-5277 FAX: +41-21-247071 From bug-lucid-emacs-request@lucid.com Thu Aug 13 03:19:53 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA21208; Thu, 13 Aug 92 03:19:53 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA19196g; Thu, 13 Aug 92 03:07:26 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA27602; Thu, 13 Aug 92 06:17:39 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA27598; Thu, 13 Aug 92 06:17:37 -0400 Path: uunet!mcsun!corton!sophia!almeria.inria.fr!bob From: bob%almeria.inria.fr@lucid.com (Renaud Marlet) Newsgroups: alt.lucid-emacs.bug Subject: 8bits display Message-Id: <26854@sophia.inria.fr> Date: 13 Aug 92 09:59:48 GMT Organization: INRIA, Sophia-Antipolis (Fr) Lines: 10 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Is there a reason why charaters in range [0200,0237] are always displayed \xxx, whatever ctl-arrow evaluates to? > if (((c >= 040 && c < 0177) || /* Normal character. */ > (!EQ (ctl_arrow, Qnil) && /* 8-bit display */ > !EQ (ctl_arrow, Qt) && c >= 0240)) This is really annoying for some real full fonts we use here. Thanks. Renaud. From bug-lucid-emacs-request@lucid.com Thu Aug 13 03:25:51 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA21212; Thu, 13 Aug 92 03:25:51 PDT Received: by heavens-gate.lucid.com id AA19219g; Thu, 13 Aug 92 03:17:03 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA19215g; Thu, 13 Aug 92 03:16:53 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02000; Thu, 13 Aug 92 03:27:13 PDT Date: Thu, 13 Aug 92 03:27:13 PDT Message-Id: <9208131027.AA02000@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bob%almeria.inria.fr@lucid.com (Renaud Marlet) Cc: bug-lucid-emacs@lucid.com Subject: Re: 8bits display Newsgroups: alt.lucid-emacs.bug In-Reply-To: Renaud Marlet's message of 13-Aug-92 09:59:48 GMT <26854@sophia.inria.fr> References: <26854@sophia.inria.fr> In message <26854@sophia.inria.fr> Renaud Marlet wrote: > > Is there a reason why charaters in range [0200,0237] are always displayed > \xxx, whatever ctl-arrow evaluates to? Because (as far as I know) none of the ISO-8859 character sets have characters there, and because I saw some other patches for emacs 18 doing the same thing. What encoding are your fonts in? -- Jamie From bug-lucid-emacs-request@lucid.com Thu Aug 13 06:21:38 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA21581; Thu, 13 Aug 92 06:21:38 PDT Received: by heavens-gate.lucid.com id AA19542g; Thu, 13 Aug 92 06:09:52 PDT Received: from almeria.inria.fr by heavens-gate.lucid.com id AA19537g; Thu, 13 Aug 92 06:09:36 PDT Received: by almeria.inria.fr (5.65c/IDA-1.2.8) id AA00385; Thu, 13 Aug 1992 15:20:19 +0200 From: Renaud Marlet Message-Id: <199208131320.AA00385@almeria.inria.fr> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: Re: 8bits display In-Reply-To: Your message of Thu, 13 Aug 92 03:27:13 -0700. <9208131027.AA02000@thalidomide.lucid> Date: Thu, 13 Aug 92 15:20:17 +0200 The fonts I am talking about are home made fonts used by an emacs TeX pretty printer. The first half (0-127) consits in standard ascii encoding, and the second half (128-255) consist in mathematical and other miscellaneous sym- bols. I had to do that because I couldn't find a way to magage (i.e. display, motion, edition...) in an emacs buffer some kind of atomic data coded on several characters. What a dream! I thus had to code everything (maximum 256 atoms) on a single char and derive new fonts from ISO-8859 and symbolic fonts. We already have had enough astute hypotheses in emacs (7bits display, 7bits keymaps) not to settle a new one. I do believe in homogeneity. Lucid emacs also apparently. BTW, you have done a very good job with lemacs. The only things that keep confusing me are the overlapping attributes of buffers and screens. In particular, I miss a buffer specific face. -- Renaud PS: I was porting this TeX viewer from Epoch to Lucid emacs when I came across this problem. I hope to release it soon though, maybe with a little patch file to xdisp.c for people wanting to use it with Lucid (otherwise, it costs me all the downcase greek letters :-). From bug-lucid-emacs-request@lucid.com Thu Aug 13 06:24:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA21593; Thu, 13 Aug 92 06:24:23 PDT Received: by heavens-gate.lucid.com id AA19564g; Thu, 13 Aug 92 06:15:05 PDT Received: from pat.uio.no by heavens-gate.lucid.com id AA19558g; Thu, 13 Aug 92 06:14:39 PDT Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <06075-0@pat.uio.no>; Thu, 13 Aug 1992 15:24:30 +0200 Date: Thu, 13 Aug 1992 15:24:21 +0200 From: h.b.furuseth%usit.uio.no@lucid.com Message-Id: <9208131324.AAgandalf14877@gandalf.uio.no> To: bug-lucid-emacs@lucid.com Cc: Renaud Marlet , Jamie Zawinski In-Reply-To: jwz@lucid.com's message of Thu, 13 Aug 1992 03:27:13 PDT Subject: Re: 8bits display You could let ctl-arrow say which characters should be considered printable. I did this for emacs-18.58 with the patch below, see its modified doc string. It should be easy to do the same thing to v19; search the code for regexp 'ctl.arrow' to find all places to fix. [I only display char 0241 and up as printable, because 0240 is buggy in some fonts, and little used because it's blank anyway.] Hallvard. diff -c2 emacs-18.58/src/buffer.c~ emacs-18.58/src/buffer.c *** emacs-18.58/src/buffer.c~ Thu Feb 20 10:20:41 1992 --- emacs-18.58/src/buffer.c Thu Feb 20 13:41:11 1992 *************** *** 1267,1273 **** DEFVAR_PER_BUFFER ("ctl-arrow", ¤t_buffer->ctl_arrow, ! "*Non-nil means display control chars with uparrow.\n\ ! Nil means use backslash and octal digits.\n\ ! Automatically becomes local when set in any fashion."); DEFVAR_PER_BUFFER ("truncate-lines", ¤t_buffer->truncate_lines, --- 1267,1275 ---- DEFVAR_PER_BUFFER ("ctl-arrow", ¤t_buffer->ctl_arrow, ! "*t means display control chars with uparrow.\n\ ! Nil or 0 means use backslash and octal digits.\n\ ! Otherwise assume that meta chars > \"\\240\" (M-SPACE) are printable.\n\ ! If it is an integer, meta chars >= ctl-arrow are assumed to be printable.\n\ ! Automatically becomes local when set in any fashion."); DEFVAR_PER_BUFFER ("truncate-lines", ¤t_buffer->truncate_lines, diff -c2 emacs-18.58/src/buffer.h~ emacs-18.58/src/buffer.h *** emacs-18.58/src/buffer.h~ Sat Jan 5 01:12:49 1991 --- emacs-18.58/src/buffer.h Thu Feb 20 13:41:12 1992 *************** *** 269,270 **** --- 269,275 ---- extern void reset_buffer (); + + /* Compute more convenient value from ctl-arrow object. */ + /* Remember to guard against users setting ctl-arrow < 0200. */ + #define CTL_ARROW_CONV(obj) (NULL (obj) ? 0 : EQ (obj, Qt) ? 0400 : \ + XTYPE (obj) == Lisp_Int ? XINT (obj) : 0241) diff -c2 emacs-18.58/src/indent.c~ emacs-18.58/src/indent.c *** emacs-18.58/src/indent.c~ Thu Feb 20 10:20:46 1992 --- emacs-18.58/src/indent.c Thu Feb 20 13:41:12 1992 *************** *** 79,83 **** register int post_tab; register int tab_width = XINT (current_buffer->tab_width); ! int ctl_arrow = !NULL (current_buffer->ctl_arrow); if (point == last_known_column_point --- 79,83 ---- register int post_tab; register int tab_width = XINT (current_buffer->tab_width); ! int ctl_arrow = CTL_ARROW_CONV (current_buffer->ctl_arrow); if (point == last_known_column_point *************** *** 134,138 **** } else ! col += (ctl_arrow && c < 0200) ? 2 : 4; } --- 134,138 ---- } else ! col += ctl_arrow ? (c < 0200 ? 2 : c < ctl_arrow ? 4 : 1) : 4; } *************** *** 298,302 **** register int end = ZV; register int tab_width = XINT (current_buffer->tab_width); ! register int ctl_arrow = !NULL (current_buffer->ctl_arrow); Lisp_Object val; --- 298,302 ---- register int end = ZV; register int tab_width = XINT (current_buffer->tab_width); ! register int ctl_arrow = CTL_ARROW_CONV (current_buffer->ctl_arrow); Lisp_Object val; *************** *** 325,332 **** col = col / tab_width * tab_width; } ! else if (ctl_arrow && (c < 040 || c == 0177)) ! col++; ! else if (c < 040 || c >= 0177) ! col += 3; } --- 325,332 ---- col = col / tab_width * tab_width; } ! else if (c < 040 || c == 0177) ! col += ctl_arrow ? 1 : 3; ! else if (c >= 0200 && !(ctl_arrow && c >= ctl_arrow)) ! col += 3; } *************** *** 355,359 **** register int c; register int tab_width = XFASTINT (current_buffer->tab_width); ! register int ctl_arrow = !NULL (current_buffer->ctl_arrow); int selective = XTYPE (current_buffer->selective_display) == Lisp_Int --- 355,359 ---- register int c; register int tab_width = XFASTINT (current_buffer->tab_width); ! register int ctl_arrow = CTL_ARROW_CONV (current_buffer->ctl_arrow); int selective = XTYPE (current_buffer->selective_display) == Lisp_Int *************** *** 430,434 **** } else ! hpos += (ctl_arrow && c < 0200) ? 2 : 4; /* Handle right margin. */ --- 430,434 ---- } else ! hpos += ctl_arrow ? (c < 0200 ? 2 : c < ctl_arrow ? 4 : 1) : 4; /* Handle right margin. */ diff -c2 emacs-18.58/src/xdisp.c~ emacs-18.58/src/xdisp.c *** emacs-18.58/src/xdisp.c~ Thu Feb 20 10:21:01 1992 --- emacs-18.58/src/xdisp.c Thu Feb 20 13:41:13 1992 *************** *** 1265,1269 **** register unsigned char *p1prev; int tab_width = XINT (current_buffer->tab_width); ! int ctl_arrow = !NULL (current_buffer->ctl_arrow); int width = XFASTINT (w->width) - 1 - (XFASTINT (w->width) + XFASTINT (w->left) != screen_width); --- 1265,1269 ---- register unsigned char *p1prev; int tab_width = XINT (current_buffer->tab_width); ! int ctl_arrow = CTL_ARROW_CONV (current_buffer->ctl_arrow); int width = XFASTINT (w->width) - 1 - (XFASTINT (w->width) + XFASTINT (w->left) != screen_width); *************** *** 1392,1395 **** --- 1392,1401 ---- p1++; } + else if (ctl_arrow && c >= ctl_arrow) + { + if (p1 >= startp) + *p1 = c; + p1++; + } else { *************** *** 1942,1945 **** --- 1948,1952 ---- unsigned char *p1start = new_screen->contents[vpos] + hpos; int window_width = XFASTINT (w->width); + int ctl_arrow = CTL_ARROW_CONV (buffer_defaults.ctl_arrow); if (tab_width <= 0 || tab_width > 20) tab_width = 8; *************** *** 1977,1981 **** while ((p1 - start + hscroll - (hscroll > 0)) % tab_width); } ! else if (c < 0200 && buffer_defaults.ctl_arrow) { if (p1 >= start) --- 1984,1988 ---- while ((p1 - start + hscroll - (hscroll > 0)) % tab_width); } ! else if (c < 0200 && ctl_arrow) { if (p1 >= start) *************** *** 1984,1987 **** --- 1991,2000 ---- if (p1 >= start && p1 < end) *p1 = c ^ 0100; + p1++; + } + else if (ctl_arrow && c >= ctl_arrow) + { + if (p1 >= start) + *p1 = c; p1++; } From bug-lucid-emacs-request@lucid.com Thu Aug 13 12:25:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22560; Thu, 13 Aug 92 12:25:30 PDT Received: by heavens-gate.lucid.com id AA20807g; Thu, 13 Aug 92 12:16:36 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA20792g; Thu, 13 Aug 92 12:14:42 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA03205; Thu, 13 Aug 92 12:23:38 PDT Date: Thu, 13 Aug 92 12:23:38 PDT Message-Id: <9208131923.AA03205@thalidomide.lucid> X-Windows: The art of incompetence. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: h.b.furuseth%usit.uio.no@lucid.com Cc: Renaud Marlet , bug-lucid-emacs@lucid.com Subject: Re: 8bits display In-Reply-To: h b furuseth's message of Thu 13-Aug-92 15:24:21 +0200 <9208131324.AAgandalf14877@gandalf.uio.no> References: <9208131324.AAgandalf14877@gandalf.uio.no> In message <9208131324.AAgandalf14877@gandalf.uio.no> h b furuseth wrote: > > You could let ctl-arrow say which characters should be considered > printable. I did this for emacs-18.58 with the patch below, see its > modified doc string. That's not a bad idea. I'll put it into 19.3. > [I only display char 0241 and up as printable, because 0240 is buggy > in some fonts, and little used because it's blank anyway.] Actually, 0240 is really useful, because it's supposed to display as a space, but emacs doesn't think it is one. So if you use 0240, you can have pairs of words that auto-fill doesn't break. But since it's buggy in many fonts, the lemacs display code always displays 0240 as a normal space. (In our development version, anyway; I may have added this after releasing 19.2.) In message <199208131320.AA00385@almeria.inria.fr> Renaud Marlet wrote: > > The fonts I am talking about are home made fonts used by an emacs TeX pretty > printer. The first half (0-127) consits in standard ascii encoding, and the > second half (128-255) consist in mathematical and other miscellaneous sym- > bols. I see. Making a new font is a pretty drastic thing to have to do to get behavior like this (though I think you're right that it's the only way to do it right now.) Eventually, once display-tables work, you should be able to effectively remap the emacs character set in arbitrary ways, even making certain characters display in different fonts, or display as more than one character. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Aug 13 13:30:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA22733; Thu, 13 Aug 92 13:30:37 PDT Received: by heavens-gate.lucid.com id AA21115g; Thu, 13 Aug 92 13:18:45 PDT Received: from hp.com by heavens-gate.lucid.com id AA21089g; Thu, 13 Aug 92 13:15:15 PDT Received: from gourmet.ch.apollo.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA09415; Thu, 13 Aug 92 13:25:36 -0700 Message-Id: <9208132025.AA09415@hp.com> Received: by gourmet.ch.apollo.hp.com id ; Thu, 13 Aug 92 15:28:56 -0400 Date: Thu, 13 Aug 92 15:28:56 -0400 From: sommerfeld@apollo.hp.com To: Jamie Zawinski Cc: bob%almeria.inria.fr@lucid.com, bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Thu, 13 Aug 92 03:27:13 PDT, <9208131027.AA02000@thalidomide.lucid> Subject: Re: 8bits display I have no idea which fonts Renaud is using, but the encoding used by the HP48SX calculator uses ISO latin 1 (or something very close to it) for character positions 040-0177 and 0240-0377, and fills the space between 0200 and 0237 with calculator-specific symbols and greek latters not in Latin-1. Now, I haven't constructed such a font for X, but if I had one, it would be very useful for editing 48SX programs.. - Bill From bug-lucid-emacs-request@lucid.com Sun Aug 16 10:48:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01710; Sun, 16 Aug 92 10:48:59 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01844g; Sun, 16 Aug 92 10:39:25 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00671; Sun, 16 Aug 92 13:49:43 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00667; Sun, 16 Aug 92 13:49:42 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!Germany.EU.net!gmd.de!jvnc.net!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!usenet.coe.montana.edu!news.u.washington.edu!uw-beaver!cornell!murthy From: murthy@cs.cornell.edu (Chet Murthy) Subject: Bug report on narrow-to-region Message-Id: <1992Aug16.155146.8687@cs.cornell.edu> Organization: Cornell Univ. CS Dept, Ithaca NY 14853 Date: Sun, 16 Aug 1992 15:51:46 GMT Lines: 27 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Synopsis: narrow-to-region does not work as in v18. To repeat: (1) fire up lemacs -q (for a fresh, clean boot. (2) type in 20 letters (e.g. the digits twice) (3) run M-ESC ( n a r r o w - t o - r e g i o n SPC 4 spc 8 ) RET (e.g. the command (narrow-to-region 4 8)) (4) observe that the digits "3456" are visible. (5) run M-x w i d RET (6) observe that the digits "34567890..." are visible, but NOT "012". (7) hit C-l, and it fixes tiself. I verified that ths behaviour wasn't happening in v18.57. --chet-- From bug-lucid-emacs-request@lucid.com Mon Aug 17 08:50:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04331; Mon, 17 Aug 92 08:50:41 PDT Received: by heavens-gate.lucid.com id AA04512g; Mon, 17 Aug 92 08:40:59 PDT Received: from srv01s4.cas.org by heavens-gate.lucid.com id AA04505g; Mon, 17 Aug 92 08:40:43 PDT Date: Mon, 17 Aug 92 11:51:10 EDT From: rls26@cas.org Message-Id: <9208171551.AA10909@cas.org> To: bug-lucid-emacs@lucid.com Subject: Backups of linked files within lemacs Cc: rscott@csa.org There appears to have been a change in the method that lemacs uses to identify the directory for a backup file when the file in a buffer is a symbolic link. In the past (epoch and emacs 18) the backup files for a symbolic link were placed in the directory containing the symbolic link. It appears that lemacs attempts to place those backups into the directory where the actual file resides. We are running with the following settings for the variables that control backups: (setq backup-by-copying t) (setq make-backup-files t) In many cases this is change is desirable, but in others, it will be a headache. The situation that we have is that authority files reside in a protected directory where users can not create or delete files. Write permission is granted to a user for specific files they have checked out and a symbolic link to the authority file is created in a user directory. In the past, backup files where created in the users directory, where they could be created. With lemacs, the backup is attempted into the protected directory so we do not get a file specific backup (other than teh generic fallback ~/%backup%~). I think that one of two changes should be made: 1) Add a new variable to control the selection of the directory when creating backups of linked files, or 2) If the directory containing the actual file is not writable, then attempt to create the backup in the directory in which the link resides. Any thought? Richard Scott Chemical Abstracts Service rscott@cas.org From bug-lucid-emacs-request@lucid.com Tue Aug 18 18:16:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10336; Tue, 18 Aug 92 18:16:26 PDT Received: by heavens-gate.lucid.com id AA08983g; Tue, 18 Aug 92 18:06:38 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA08978g; Tue, 18 Aug 92 18:05:37 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01787; Tue, 18 Aug 92 18:13:16 PDT Date: Tue, 18 Aug 92 18:13:16 PDT Message-Id: <9208190113.AA01787@thalidomide.lucid> X-Windows: Warn your friends about it. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: rls26@cas.org Cc: bug-lucid-emacs@lucid.com, rscott@csa.org Subject: Re: Backups of linked files within lemacs In-Reply-To: rls26@cas.org's message of Mon 17-Aug-92 11:51:10 EDT <9208171551.AA10909@cas.org> In message <9208171551.AA10909@cas.org> rls26@cas.org wrote: > > I think that one of two changes should be made: > > 1) Add a new variable to control the selection of the directory > when creating backups of linked files, or I think this is a good idea; probably it should be called something like backup-using-truenames to be consistent with backup-by-copying and find-file-use-truenames. This shouldn't be hard to implement; I encourage someone to contribute the code! -- Jamie From bug-lucid-emacs-request@lucid.com Wed Aug 19 09:23:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12803; Wed, 19 Aug 92 09:23:30 PDT Received: by heavens-gate.lucid.com id AA10508g; Wed, 19 Aug 92 09:11:07 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA10504g; Wed, 19 Aug 92 09:10:48 PDT Return-Path: Received: from sergei.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA07452; Wed, 19 Aug 92 12:19:04 -0400 Received: by sergei.mitre.org (4.1/SMI-4.1) id AA02121; Wed, 19 Aug 92 12:20:51 EDT Date: Wed, 19 Aug 92 12:20:51 EDT From: bcotton@sergei.mitre.org (Robert T. Cotton) Message-Id: <9208191620.AA02121@sergei.mitre.org> To: bug-lucid-emacs@lucid.com Subject: Make errors on HP Good day, I am trying to compile lemacs 19.2 on an HP-720 HPUX 8.07. I have the patches posted to this group, and installed them. I compiled the main code with cc (We bought it) and the lwlib with gcc (2.2.2). I also have X11R5 installed, and am using it. (Both includes and lib's). The problem is that ld cant fine XtStrings (code). I looked in the PROBLEMS file and it said that this is a result of using the R5 includes and the R4 libs. But this is not the case (unless the linker is doing something I'm not telling it to) I have these defined in config.h: /* Define LD_SWITCH_SITE to contain any special flags your loader may need. For instance, if you've defined HAVE_X_WINDOWS above and your X libraries aren't in a place that your loader can find on its own, you might want to add "-L/..." or something similar. */ #define LD_SWITCH_SITE -a archive -L/usr/contrib/mitX11R5/lib /* Define C_SWITCH_SITE to contain any special flags your compiler may need. For instance, if you've defined HAVE_X_WINDOWS above and your X include files aren't in a place that your compiler can find on its own, you might want to add "-I/..." or something similar. */ #define C_SWITCH_SITE -Aa -D_HPUX_SOURCE -Dunix -I/usr/contrib/mitX11R5/include and I'm not using INCLUDE_EXTENSIONS in lwlib. Any clues? Bob From bug-lucid-emacs-request@lucid.com Wed Aug 19 15:59:40 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13825; Wed, 19 Aug 92 15:59:40 PDT Received: by heavens-gate.lucid.com id AA11978g; Wed, 19 Aug 92 15:46:58 PDT Received: from humpty.edb.tih.no by heavens-gate.lucid.com id AA11965g; Wed, 19 Aug 92 15:44:54 PDT Received: by humpty.edb.tih.no (/\==/\ Smail3.1.22.1 #22.3) id ; Thu, 20 Aug 92 00:36 MDT Received: by viper.edb.tih.no. (5.64/tih-k1.01) id AA22751; Thu, 20 Aug 92 00:58:11 GMT From: oddbjorn%edb.tih.no@lucid.com Message-Id: <9208200058.AA22751@viper.edb.tih.no.> Subject: Compiling Lucid Emacs 19.2 under ISC 2.2.1 To: bug-lucid-emacs@lucid.com Date: Thu, 20 Aug 92 0:58:10 MET X-Mailer: ELM [version 2.3 PL11] Hi! I'm trying to install Lucid Emacs 19.2 under Interactive 2.2.1 (SysV3.2). With a little tweaking, I managed to compile everything, but now, during the linking I have some problems : undefined first referenced symbol in file realpath fileio.o remainder data.o acosh floatfns.o asinh floatfns.o atanh floatfns.o cbrt floatfns.o expm1 floatfns.o lgamma floatfns.o log1p floatfns.o logb floatfns.o rint floatfns.o [there are others as well, but I think I'll manage to resolve them... :)] These functions is not available in any library, as far as I can see. (I'm using gcc 2.2.2). My question is: Are these functions available somewhere ? Since I don't have man pages for them, it's rather hard for me to write them from scratch... /oddbjorn [oddbjorn@edb.tih.no] From bug-lucid-emacs-request@lucid.com Wed Aug 19 17:55:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14014; Wed, 19 Aug 92 17:55:26 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA12451g; Wed, 19 Aug 92 17:43:40 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18770; Wed, 19 Aug 92 20:54:13 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18766; Wed, 19 Aug 92 20:54:12 -0400 Path: uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!tulane!wupost!gumby!yale!yale.edu!jvnc.net!netnews.upenn.edu!catone From: catone@dmark.wharton.upenn.edu (Tony Catone) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs& on HP 9000/720 Message-Id: Date: 19 Aug 92 22:15:40 GMT References: <92230.11:37:35.140387.L58@vm.urz.uni-heidelberg.de> Organization: University of Pennsylvania Lines: 22 Nntp-Posting-Host: sovereign.wharton.upenn.edu In-Reply-To: L58@vm.urz.uni-heidelberg.de's message of 17 Aug 92 10:48:49 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <92230.11:37:35.140387.L58@vm.urz.uni-heidelberg.de> L58@vm.urz.uni-heidelberg.de (Dieter Menszner) writes: Trying to start Lucid Emacs in the background on a HP 9000/720 HP-UX 8.07 I get (in hpterm and xterm and /bin/ksh): lemacs& + Stopped(tty output) lemacs& Does anybody know of a cure? It would be nice to free the terminal window. I get the same message on a HP 9000/730 running HP/UX 8.05, in csh. Doing an fg reveals a message as to one of the Classes having been compiled for R3. We're still running X11R4 and got the Athena widget stuff from one of the HP anon ftp sites, so I assume the solution is to go to X11R5. In the meantime, you can play shell script wrapper games with redirection to force lemacs into the background and the message to /dev/null. - Tony catone@dmark.wharton.upenn.edu From bug-lucid-emacs-request@lucid.com Thu Aug 20 19:08:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17561; Thu, 20 Aug 92 19:08:45 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA15572g; Thu, 20 Aug 92 18:56:39 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA24159; Thu, 20 Aug 92 22:07:14 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA24155; Thu, 20 Aug 92 22:07:13 -0400 Path: uunet!haven.umd.edu!darwin.sura.net!wupost!cs.utexas.edu!asuvax!asuacad!azpxe Organization: Arizona State University Date: Thursday, 20 Aug 1992 17:41:19 MST From: Message-Id: <92233.174119AZPXE@ASUACAD.BITNET> Newsgroups: alt.lucid-emacs.bug Subject: Re: Bug report on narrow-to-region References: <1992Aug16.155146.8687@cs.cornell.edu> Lines: 2 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com qquit From bug-lucid-emacs-request@lucid.com Fri Aug 21 00:41:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18226; Fri, 21 Aug 92 00:41:06 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA16009g; Fri, 21 Aug 92 00:28:03 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00619; Fri, 21 Aug 92 03:38:39 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00615; Fri, 21 Aug 92 03:38:36 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!aun.uninett.no!alf.uib.no!alf.uib.no!s082 From: s082%flue.ii.uib.no@lucid.com (Ketil Malde) Subject: Re: 8bits display In-Reply-To: sommerfeld@apollo.hp.com's message of Thu, 13 Aug 1992 15:28:56 -0400 Message-Id: Reply-To: s082%brems.ii.uib.no@lucid.com Organization: student of computer science at the University of Bergen, Norway References: <9208132025.AA09415@hp.com> Date: 21 Aug 92 09:01:20 Lines: 20 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9208132025.AA09415@hp.com> sommerfeld@apollo.hp.com writes: Date: Thu, 13 Aug 1992 15:28:56 -0400 From: sommerfeld@apollo.hp.com I have no idea which fonts Renaud is using, but the encoding used by the HP48SX calculator uses ISO latin 1 (or something very close to it) for character positions 040-0177 and 0240-0377, and fills the space between 0200 and 0237 with calculator-specific symbols and greek latters not in Latin-1. And, of course, the reason that the characteres between 0177 and 240 is concidered unprintables, is that if you happen to strip the eight bit (as many anglo-american nationalist programs tend to do, and for no apparent reason) you end up with control characters that may prove hazardous to you and your computer....just for the record. -- ; Ketil Malde, In real life: s082@ii.uib.no + From bug-lucid-emacs-request@lucid.com Fri Aug 21 04:12:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19115; Fri, 21 Aug 92 04:12:36 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA16215g; Fri, 21 Aug 92 03:59:29 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00776; Fri, 21 Aug 92 07:10:05 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00770; Fri, 21 Aug 92 07:10:02 -0400 Path: uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Newsgroups: alt.lucid-emacs.bug Subject: SunOS kernel panic Summary: Yeah, I know its really a SunOS bug, but I don't have SunOS source Message-Id: <1992Aug20.174216.14385@cs.sfu.ca> Date: 20 Aug 92 17:42:16 GMT Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Lines: 21 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com running lemacs 19-2 on a Sparcstation IPX, a user either 1) Typing, or 2) During a redraw, got the following kernel panic Aug 20 09:40:34 botein vmunix: BAD TRAP Aug 20 09:40:34 botein vmunix: pid 2356, `lemacs': Illegal instruction Aug 20 09:40:34 botein vmunix: pc=0xf80be478, sp=0xf82e7e10, psr=0x904010c1, context=0x4 Aug 20 09:40:34 botein vmunix: g1-g7: f812d000, 8000000, ffffffff, 207f60, f8133c00, 0, 0 Aug 20 09:40:34 botein vmunix: Begin traceback... sp = f82e7e10 Aug 20 09:40:34 botein vmunix: Called from f810c840, fp=f82e7e70, args=1ce000 ff0ec498 0 0 2 1cf000 Aug 20 09:40:34 botein vmunix: Called from f810a65c, fp=f82e7ee0, args=1ce478 0 2 0 f81d3aa8 f8164400 Aug 20 09:40:34 botein vmunix: Called from f8005b4c, fp=f82e7f58, args=10009 f82e7fb4 1ce478 80 2 0 Aug 20 09:40:34 botein vmunix: Called from f8005b4c, fp=f7ffe9e8, args=1ce470 41cb804 1ce470 80 3 0 Aug 20 09:40:34 botein vmunix: End traceback... -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Fri Aug 21 04:43:10 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19189; Fri, 21 Aug 92 04:43:10 PDT Received: by heavens-gate.lucid.com id AA16296g; Fri, 21 Aug 92 04:31:20 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA16292g; Fri, 21 Aug 92 04:31:08 PDT Received: by moebius.loria.fr id AA00725 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Fri, 21 Aug 92 12:52:20 +0200 Date: Fri, 21 Aug 92 12:52:20 +0200 From: Guido Bosch Message-Id: <9208211052.AA00725@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: Keybindings of comint.el Reply-To: Guido BOSCH Somebody seems to have hacked the keybindings of the comint mode. I'd preferr the documented behavior. from comint.el: ;;; Brief Command Documentation: ;;;============================================================================ ;;; Comint Mode Commands: (common to all derived modes, like cmushell & cmulisp ;;; mode) ;;; ;;; m-p comint-previous-input Cycle backwards in input history ;;; m-n comint-next-input Cycle forwards ;;; m-s comint-previous-similar-input Previous similar input . . . (if comint-mode-map nil (setq comint-mode-map (make-sparse-keymap)) ;;(define-key comint-mode-map "\ep" 'comint-previous-input) ;;(define-key comint-mode-map "\en" 'comint-next-input) (define-key comint-mode-map "\ep" 'comint-previous-similar-input) (define-key comint-mode-map "\en" 'comint-next-similar-input) (define-key comint-mode-map "\es" 'comint-previous-similar-input) Guido From bug-lucid-emacs-request@lucid.com Fri Aug 21 04:47:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19199; Fri, 21 Aug 92 04:47:01 PDT Received: by heavens-gate.lucid.com id AA16304g; Fri, 21 Aug 92 04:37:56 PDT Received: from ingr.ingr.com by heavens-gate.lucid.com id AA16300g; Fri, 21 Aug 92 04:37:43 PDT Received: from lucid.com by ingr.ingr.com (5.65c/1.920611) id AA08513; Fri, 21 Aug 1992 06:52:35 -0500 Received: from rodan.UU.NET by heavens-gate.lucid.com id AA16215g; Fri, 21 Aug 92 03:59:29 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00776; Fri, 21 Aug 92 07:10:05 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00770; Fri, 21 Aug 92 07:10:02 -0400 Path: uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Newsgroups: alt.lucid-emacs.bug Subject: SunOS kernel panic Summary: Yeah, I know its really a SunOS bug, but I don't have SunOS source Message-Id: <1992Aug20.174216.14385@cs.sfu.ca> Date: 20 Aug 92 17:42:16 GMT Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Lines: 21 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com running lemacs 19-2 on a Sparcstation IPX, a user either 1) Typing, or 2) During a redraw, got the following kernel panic Aug 20 09:40:34 botein vmunix: BAD TRAP Aug 20 09:40:34 botein vmunix: pid 2356, `lemacs': Illegal instruction Aug 20 09:40:34 botein vmunix: pc=0xf80be478, sp=0xf82e7e10, psr=0x904010c1, context=0x4 Aug 20 09:40:34 botein vmunix: g1-g7: f812d000, 8000000, ffffffff, 207f60, f8133c00, 0, 0 Aug 20 09:40:34 botein vmunix: Begin traceback... sp = f82e7e10 Aug 20 09:40:34 botein vmunix: Called from f810c840, fp=f82e7e70, args=1ce000 ff0ec498 0 0 2 1cf000 Aug 20 09:40:34 botein vmunix: Called from f810a65c, fp=f82e7ee0, args=1ce478 0 2 0 f81d3aa8 f8164400 Aug 20 09:40:34 botein vmunix: Called from f8005b4c, fp=f82e7f58, args=10009 f82e7fb4 1ce478 80 2 0 Aug 20 09:40:34 botein vmunix: Called from f8005b4c, fp=f7ffe9e8, args=1ce470 41cb804 1ce470 80 3 0 Aug 20 09:40:34 botein vmunix: End traceback... -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Fri Aug 21 05:10:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19240; Fri, 21 Aug 92 05:10:36 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA16345g; Fri, 21 Aug 92 05:01:32 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07853; Fri, 21 Aug 92 08:12:08 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07848; Fri, 21 Aug 92 08:12:02 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!corax.udac.uu.se!woody.csd.uu.se!hb From: hb%woody.csd.uu.se@lucid.com (Henrik B}kman CSD) Subject: Problem with lemacs 19.2 on HPUX 8.07 Message-Id: <1992Aug21.120141.18987@corax.udac.uu.se> Organization: UDAC, Uppsala, Sweden Date: Fri, 21 Aug 1992 12:01:41 GMT Lines: 19 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have problems with makeing lemacs 19.2 on my HP 9000/730 with HPUX 8.07. The dokumentation says that you should use a ANSI-compiler so I am using cc with '-Aa -D_HPUX_SOURCE'. With that I get compiler-errors in several files, most of the times because om constructions which I believe isn't ANSI-compatible. (old "prototypes", implicitly uses of 'int' in variable-definitions etc). The strange thing is that there seems to be quite a lot of people out there using lemacs on HP computers so what do I do wrong??? -- ---------------------------------------------------------------------- Henrik Bakman Adress: Box 520 Tel: +46 18 181044 System Manager 751 20 UPPSALA Fax: +46 18 521270 Computing Science Dep. SWEDEN Email: hb@csd.uu.se Uppsala University From bug-lucid-emacs-request@lucid.com Fri Aug 21 10:40:51 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20248; Fri, 21 Aug 92 10:40:51 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA17006g; Fri, 21 Aug 92 10:26:32 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA28960; Fri, 21 Aug 92 13:37:09 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA28956; Fri, 21 Aug 92 13:37:07 -0400 Path: uunet!haven.umd.edu!mimsy!lhc!lhc!warsaw From: warsaw@nlm.nih.gov (Barry A. Warsaw) Newsgroups: alt.lucid-emacs.bug Subject: Re: Keybindings of comint.el Message-Id: Date: 21 Aug 92 15:59:58 GMT References: <9208211052.AA00725@moebius.loria.fr> Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw) Organization: Century Computing, Inc. Lines: 10 In-Reply-To: Guido.Bosch%loria.fr@lucid.com's message of 21 Aug 92 10:52:20 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> "Guido" == Guido Bosch writes: Guido> Somebody seems to have hacked the keybindings of the comint Guido> mode. Guido> (define-key comint-mode-map "\en" 'comint-next-similar-input) Is there a more recent version of comint that has this function defined? My 2.03 only has comint-previous-similar-input. From bug-lucid-emacs-request@lucid.com Fri Aug 21 13:21:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20682; Fri, 21 Aug 92 13:21:24 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA17522g; Fri, 21 Aug 92 13:12:23 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA11420; Fri, 21 Aug 92 16:22:54 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA11407; Fri, 21 Aug 92 16:22:50 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!Germany.EU.net!ira.uka.de!uni-heidelberg!vm.urz.uni-heidelberg.de!L58 From: L58%vm.urz.uni-heidelberg.de@lucid.com (Dieter Menszner) Subject: Cannot read Lisp manual info Message-Id: <1684A13335.L58@vm.urz.uni-heidelberg.de> Organization: University of Heidelberg, Germany Date: Fri, 21 Aug 92 21:50:45 CET Lines: 10 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In Lucid-Emacs 19.2 I cannot read the info nodes for the Lisp manual after the first 3 or 4 entries. Error code is: Search failed: "n^_" ( this is a 3270 terminal) Other info items like the Emacs manual work. The system is Apollo DomainOS SR 10.3. Dieter From bug-lucid-emacs-request@lucid.com Sat Aug 22 10:37:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23337; Sat, 22 Aug 92 10:37:48 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA19492g; Sat, 22 Aug 92 10:24:07 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29506; Sat, 22 Aug 92 13:34:46 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA29502; Sat, 22 Aug 92 13:34:45 -0400 Path: uunet!mcsun!uknet!edcastle!aifh!aifh!tfb From: tfb@aisb.ed.ac.uk (Tim Bradshaw) Newsgroups: alt.lucid-emacs.bug Subject: Re: Cannot read Lisp manual info Message-Id: Date: 22 Aug 92 17:21:05 GMT References: <1684A13335.L58@vm.urz.uni-heidelberg.de> Organization: Not Lines: 18 In-Reply-To: L58@vm.urz.uni-heidelberg.de's message of 21 Aug 92 21:11:41 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On 21 Aug 92 21:11:41 GMT, L58@vm.urz.uni-heidelberg.de (Dieter Menszner) said: > In Lucid-Emacs 19.2 I cannot read the info nodes for the Lisp manual > > after the first 3 or 4 entries. Error code is: > > Search failed: "n^_" ( this is a 3270 terminal) > > Other info items like the Emacs manual work. The system is > Apollo DomainOS SR 10.3. > Unless there are several 19.2 distributions lying around, probably you'll find that most of the files of the elisp info are missing. I just fetched the standard elisp documentation & installed it in place of the supplied one. --tim Tim Bradshaw: tim.bradshaw@ed.ac.uk From bug-lucid-emacs-request@lucid.com Sun Aug 23 06:18:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25415; Sun, 23 Aug 92 06:18:25 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA20680g; Sun, 23 Aug 92 06:05:04 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09999; Sun, 23 Aug 92 09:15:44 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09995; Sun, 23 Aug 92 09:15:43 -0400 Path: uunet!mcsun!corton!laas!matthieu From: matthieu%laas.fr@lucid.com (Matthieu Herrb) Newsgroups: alt.lucid-emacs.bug Subject: bug in mail-strip-quoted-names Message-Id: Date: 23 Aug 92 13:05:14 GMT Distribution: alt Organization: LAAS-CNRS France Lines: 18 Nntp-Posting-Host: monk Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com the lucid emacs version of mail-strip-quoted-names uses lisp-mode-syntax-table to parse nested comments. But this syntax table is nil unless you've called lisp-mode. As I don't use it, I have an error everytime Emacs parses a mail adress with nested parenthesis. A simple fix could be to use emacs-lisp-mode-syntax-table which is (I think) allways defined (for lisp-interaction). Matthieu -- Matthieu Herrb CNRS - LAAS Matthieu.Herrb@laas.fr 7, avenue du Colonel Roche 31077 Toulouse Cedex - France "War -- What is it good for ? -- Absolutely nothing !" From bug-lucid-emacs-request@lucid.com Mon Aug 24 01:17:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26930; Mon, 24 Aug 92 01:17:46 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA21515g; Mon, 24 Aug 92 01:03:04 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04803; Mon, 24 Aug 92 04:13:40 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA04799; Mon, 24 Aug 92 04:13:38 -0400 Path: uunet!mcsun!corton!loria!news.loria.fr!bosch From: bosch%loria.fr@lucid.com (Guido Bosch) Newsgroups: alt.lucid-emacs.bug Subject: Re: Keybindings of comint.el Message-Id: Date: 24 Aug 92 08:09:33 GMT References: <9208211052.AA00725@moebius.loria.fr> Reply-To: Guido BOSCH Organization: INRIA-Lorraine / CRIN, Nancy, France Lines: 29 In-Reply-To: warsaw@nlm.nih.gov's message of 21 Aug 92 15:59:58 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article warsaw@nlm.nih.gov (Barry A. Warsaw) writes: > Guido> Somebody seems to have hacked the keybindings of the comint > Guido> mode. > > Guido> (define-key comint-mode-map "\en" 'comint-next-similar-input) > > Is there a more recent version of comint that has this function > defined? My 2.03 only has comint-previous-similar-input. > Well, my version (the one with `comint-next-similar-input') is even older (2.02). It's the one I got with the Lemacs 19.2 distribution (lisp/comint/comint.el). My guess is that the version distributed with Lucid Emacs is a "non-officialy" patched-up one. Hopefully this will be corrected for the next release. Guido -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@lucid.com Mon Aug 24 15:19:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00133; Mon, 24 Aug 92 15:19:22 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA23394g; Mon, 24 Aug 92 15:06:54 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA28028; Mon, 24 Aug 92 18:17:36 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA28024; Mon, 24 Aug 92 18:17:34 -0400 Path: uunet!olivea!decwrl!mips!swrinde!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!lystad From: lystad@m2.dseg.ti.com (Garr Lystad) Newsgroups: alt.lucid-emacs.bug Subject: various bugs Message-Id: Date: 24 Aug 92 22:36:24 GMT Reply-To: Garr Lystad Distribution: alt Organization: TI DSEG, Spring Creek, Plano, Tx. Lines: 64 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com During the last week I've noticed a variety of bugs, some big, some small. Here they are, in no particular order. 1. Serious evaluating "\t", as with C-x C-e, crashes lemacs. I've done NO investigation. 2. Serious (if anyone has a workaround for this one *PLEASE* let me know.) Symptom: Insert some text in a non-empty buffer line. Move the cursor to a subsequent non-mepty line. Click button1 and don't move the mouse. You will notice that the cursor appears at a position to the left of the mouse 1 more character left than the number of characters you inserted. The same sort of thing works with deleted characters, the cursor appears to the right the number of characters deleted. What I have found: It appears to me that pixel_to_glyph_translation works with outdated information after inserts and deletes. After inserts, at least, both event-x and event-point return incorrect values. The event input to mouse-track-select is fine, but is interpreted incorrectly by pixel_to_glyph_translation until next-event is called. After that call, a copy of the original event when passed to event-x or event-point returns the correct value. Only slightly related to the foregoing, is the fact that a function called direct_output_for_insert exists in the source but is never called. 3. Annoying, is it a feature? I redefined member to take an optional test argument. The byte-compiler ignores my redefinition and complains about the extra argument. 4. Inconvenient. The command tags-apropos appears to be broken. It tells me that the command visit-tags-table-buffer is undefined. A tags-search, based on the src and lisp directories and their subdirectories does not find visit-tags-table-buffer. 5. Inconvenient. Eval-defun has no sense that it is entering another definition, though it encounters a ( in col 0, and can wind up compiling things way down in the buffer when the current defun lacks a closing paren. 6. Inconsequential The source to list-buffers calls buffer-flush-undo which is obsolete. 7. Possibly inconvenient. Numeric arguments prevent mouse buttons from being interpreted as commands. 8. Very Inconvenient. Very frequently C-x /, point-to-register, doesn't return from the minibuffer. It does store point, but it looks like something breaks after that. I haven't investigated. Also, note that sometimes it works just fine, though not often for me. 9. Inconsequential. Mouse button-1 in the minibuffer produces an error. Hold the button down there to see it. I'm not sure that it matters for these sorts of bugs, but in case it does, I'm using Lucid Emacs on a Sparc station from an NCD X-terminal. -- Garr From bug-lucid-emacs-request@lucid.com Tue Aug 25 07:52:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02522; Tue, 25 Aug 92 07:52:37 PDT Received: by heavens-gate.lucid.com id AA24975g; Tue, 25 Aug 92 07:43:20 PDT Received: from jpmorgan.jpmorgan.com by heavens-gate.lucid.com id AA24971g; Tue, 25 Aug 92 07:43:09 PDT Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA00152; Tue, 25 Aug 92 10:53:52 -0400 Received: from hawking.ny.jpmorgan.com by newton.ny.jpmorgan.com (4.1/SMI-4.0) id AA07929; Tue, 25 Aug 92 10:53:51 EDT From: chan@jpmorgan.com (Milo A. Chan) Message-Id: <9208251453.AA07929@newton.ny.jpmorgan.com> Subject: Re: Need help using purify to link Lucid Emacs To: bug-lucid-emacs@lucid.com Date: Tue, 25 Aug 92 10:53:50 EDT X-Mailer: ELM [version 2.3(JPM) PL11] For those who would like to use 'purify' on Lucid Emacs, here's what I did to make it work: * $EMACSLOADPATH - set to ../lisp/prim, when running temacs from src directory. * src/config.h - define the following macros: #define LD_CMD purify acc /* or gcc, as the case may be */ #define START_FILES /* to omit crt0.o */ #define LD_SWITCH_SYSTEM /* to suppress '-e __start' */ #define CANNOT_DUMP /* omits unexec code */ #define CANNOT_UNEXEC /* omits ref to _start in sysdep.c */ /* DATA_START makes start_of_data() return the right thing */ /* DATA_START_DECL declares etext, I added it to sysdep.c, below */ #define DATA_START &etext #define DATA_START_DECL extern char etext; * src/sysdep.c - in fcn: void* start_of_data(), line 1448, add: DATA_START_DECL right before "return ((char *) DATA_START);". * lisp/prim/loadup.el - for some reason, I had to add: (load "x-faces") before (load "faces") because "faces" needs x-resource-face. Since purify won't work with unexec, these changes should build a runnable temacs which looks in $EMACSLOADPATH for loadup.el. (Thanks to help from Barry Warsaw, Reed Hastings and Eric Benson.) P.S. -- If there is a simpler way, I'd like to hear about it. -- Milo Chan, Fixed Income Market Strategies, J.P. Morgan Securities, Inc. email: chan_milo@jpmorgan.com ...or... chan@fractl.tn.cornell.edu phone: 212.648.4483 ...or... 212.648.4486 (sec'y) From bug-lucid-emacs-request@lucid.com Tue Aug 25 09:11:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02850; Tue, 25 Aug 92 09:11:37 PDT Received: by heavens-gate.lucid.com id AA25130g; Tue, 25 Aug 92 09:02:32 PDT Received: from jpmorgan.jpmorgan.com by heavens-gate.lucid.com id AA25114g; Tue, 25 Aug 92 09:00:34 PDT Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA00575; Tue, 25 Aug 92 12:10:33 -0400 Received: from hawking.ny.jpmorgan.com by newton.ny.jpmorgan.com (4.1/SMI-4.0) id AA08170; Tue, 25 Aug 92 12:10:30 EDT From: chan@jpmorgan.com (Milo A. Chan) Message-Id: <9208251610.AA08170@newton.ny.jpmorgan.com> Subject: purify & lemacs To: warsaw@nlm.NIH.GOV (Barry A. Warsaw) Date: Tue, 25 Aug 92 12:04:05 EDT X-Mailer: ELM [version 2.3(JPM) PL11] Sender: chan@jpmorgan.com Barry, I tried to run a purify'd version of Lucid temacs. But I appear to core dump while garbage collecting after loading "lisp-mode". Running temacs without purify seems OK. Is this the behavior you were getting? ------------------------------begin core trace 0xe980 p129_static+0x104() p3.o 0xea30 p204_static+0x1c() p3.o 0x3218 _sbrk+0x70() p3.o 0x15aa1c _morecore_with_warning+0x318() vm-limit.c:104 0x158a4c ___free+0x694() gmalloc.c:503 0x15902c _FrEe+0x6c() gmalloc.c:591 0x2e84 p12_static+0x14() p3.o 0x2eec p8_static+0x50() p3.o 0x2988 _free+0x164() p3.o 0xedb04 _gc_sweep+0x11a8() alloc.c:1736 0xeeee0 _Fgarbage_collect+0x9e0() alloc.c:2011 0x107f1c _Feval+0xe70() eval.c:1408 0x11f0a8 _readevalloop+0x334() lread.c:447 0x11e100 _Fload+0x470() lread.c:240 0x108094 _Feval+0xfe8() eval.c:1422 0x9c3e8 _top_level_2+0x24() keyboard.c:394 0x105ae0 _internal_condition_case+0x250() eval.c:1001 0x9c47c _top_level_1+0x78() keyboard.c:403 0x104e9c _internal_catch+0x19c() eval.c:813 0x9c2a4 _command_loop+0xdc() keyboard.c:359 0x9b7b4 _recursive_edit_1+0xcc() keyboard.c:219 0x9b9f0 _Frecursive_edit+0x188() keyboard.c:250 0x9af50 _main+0xde0() emacs.c:895 0x2064 start+0x44() _usr_local_compilers_SunC++_SC1.0_crt0.o ------------------------------end core trace I also occasionally get core dumps at gmalloc.c:784, but this happens regardless of whether I am running temacs or the regular xemacs. Sound familiar? -- Milo Chan, Fixed Income Market Strategies, J.P. Morgan Securities, Inc. email: chan_milo@jpmorgan.com ...or... chan@fractl.tn.cornell.edu phone: 212.648.4483 ...or... 212.648.4486 (sec'y) From bug-lucid-emacs-request@lucid.com Tue Aug 25 13:34:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03709; Tue, 25 Aug 92 13:34:34 PDT Received: by heavens-gate.lucid.com id AA26082g; Tue, 25 Aug 92 13:21:48 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA26075g; Tue, 25 Aug 92 13:21:11 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA26010; Tue, 25 Aug 92 15:30:05 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA05412; Tue, 25 Aug 92 16:20:52 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA07794; Tue, 25 Aug 92 16:32:03 EDT Date: Tue, 25 Aug 92 16:32:03 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9208252032.AA07794@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA00607; Tue, 25 Aug 92 16:32:18 EDT To: bug-lucid-emacs@lucid.com Subject: Bug in 'read-key-sequence', Lucid Emacs V19.2. Doc says: read-key-sequence: (prompt) The sequence read is sufficient to specify a non-prefix command starting from the current local and global keymaps. A C-g typed while in this function is treated like any other character, and `quit-flag' is not set. One arg, PROMPT, is a prompt string, or nil meaning do not prompt specially. but an (eval (read-key-sequence "Key: ")) with an input of C-g does perform a quit, thus no value is returned. Bob From bug-lucid-emacs-request@lucid.com Tue Aug 25 13:35:31 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03713; Tue, 25 Aug 92 13:35:31 PDT Received: by heavens-gate.lucid.com id AA26099g; Tue, 25 Aug 92 13:26:13 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA26083g; Tue, 25 Aug 92 13:22:21 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA26034; Tue, 25 Aug 92 15:31:15 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA05418; Tue, 25 Aug 92 16:22:02 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA07800; Tue, 25 Aug 92 16:33:13 EDT Date: Tue, 25 Aug 92 16:33:13 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9208252033.AA07800@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA00609; Tue, 25 Aug 92 16:33:28 EDT To: bug-lucid-emacs@lucid.com Subject: Bug in 'find-tags-other-window' of "packages/etags.el", Lucid Emacs V19.2. [Note: "etags.el" in Lucid Emacs V19.2 is a slight mod of Joe Wells "tags-fix.el".] As the doc for ''find-tags-other-window' explains, it should take a second argument, however, its signature permits only one argument. From bug-lucid-emacs-request@lucid.com Tue Aug 25 14:03:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03766; Tue, 25 Aug 92 14:03:42 PDT Received: by heavens-gate.lucid.com id AA26179g; Tue, 25 Aug 92 13:51:41 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA26172g; Tue, 25 Aug 92 13:50:20 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA27022; Tue, 25 Aug 92 15:59:06 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA05487; Tue, 25 Aug 92 16:49:52 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA07915; Tue, 25 Aug 92 17:01:04 EDT Date: Tue, 25 Aug 92 17:01:04 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9208252101.AA07915@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA00617; Tue, 25 Aug 92 17:01:19 EDT To: bug-lucid-emacs@lucid.com Cc: jbw@bucsf.bu.edu Subject: Re: Bug in 'find-tags-other-window' of "packages/etags.el", Lucid Emacs V19.2. Here is the diff with the fix I made. diff etags.el~ etags.el 879c879 < (defun find-tag-other-window (tagname) --- > (defun find-tag-other-window (tagname &optional next) 901c901 < '(nil) --- > '(nil t) 903c903,905 < (find-tag tagname t)) --- > (if next > (find-tag nil t) > (find-tag tagname t))) From bug-lucid-emacs-request@lucid.com Tue Aug 25 15:45:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04027; Tue, 25 Aug 92 15:45:21 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA26561g; Tue, 25 Aug 92 15:32:55 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA05139; Tue, 25 Aug 92 18:43:34 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA05135; Tue, 25 Aug 92 18:43:32 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: -iconic Message-Id: Date: 25 Aug 92 11:11:08 GMT Distribution: alt Organization: Human Communication Research Center Lines: 8 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Starting lemacs with the -iconic command line flag causes all later screens to be created iconic too. This is probably not the correct behaviour. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Wed Aug 26 14:04:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07826; Wed, 26 Aug 92 14:04:13 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA29780g; Wed, 26 Aug 92 13:55:04 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA26407; Wed, 26 Aug 92 17:05:51 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA26403; Wed, 26 Aug 92 17:05:49 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!sun-barr!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bwdls61!bwdls138!jsparkes From: jsparkes%bwdls138.bnr.ca@lucid.com (Jeff Sparkes) Subject: bug with point-to-register Message-Id: <1992Aug26.204048.10644@bwdls61.bnr.ca> Nntp-Posting-Host: bwdls138 Organization: Bell-Northern Research Ltd., Ottawa Date: Wed, 26 Aug 1992 20:40:48 GMT Lines: 12 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com It appears that I type to fast for lemacs. (This is version 19.2, sun4). If I type "C-x/a" quickly, the prompt for the register shows up. If I hit a again, the point does indeed go to register a, and an a shows up in the buffer. It does not appear in the buffer until after I type something at the prompt. I guess the (interactive?) argument reader is a little slow. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Wed Aug 26 14:12:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07857; Wed, 26 Aug 92 14:12:22 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA29832g; Wed, 26 Aug 92 14:03:15 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA27079; Wed, 26 Aug 92 17:14:02 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA27074; Wed, 26 Aug 92 17:14:00 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!sun-barr!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bwdls61!bwdls138!jsparkes From: jsparkes%bwdls138.bnr.ca@lucid.com (Jeff Sparkes) Subject: problems with c-style Message-Id: <1992Aug26.205302.11103@bwdls61.bnr.ca> Nntp-Posting-Host: bwdls138 Organization: Bell-Northern Research Ltd., Ottawa References: <1992Aug26.204048.10644@bwdls61.bnr.ca> Date: Wed, 26 Aug 1992 20:53:02 GMT Lines: 17 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com There's a change in the c-style package that drove me nuts until I discovered it. (I had been using version 2.1; there is no version number in one with lemacs). Anyway, the lemacs version requires that the variables be dotted-pairs whereas the "real" one needs lists. It seems my variables get set to lists, i.e. c-argdecl-indent is (4), which makes lemacs unhappy. You get messages like "wrong-type-argument integer-or-float-or-marker-p (4)" when you hit TAB. If this is an lemacs specific bug it should be fixed. If not, then the c-style package should be updated with the one in the elisp archive. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Wed Aug 26 15:52:07 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08136; Wed, 26 Aug 92 15:52:07 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA00227g; Wed, 26 Aug 92 15:42:53 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02982; Wed, 26 Aug 92 18:53:39 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA02978; Wed, 26 Aug 92 18:53:37 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bwdls61!bwdls138!jsparkes From: jsparkes%bwdls138.bnr.ca@lucid.com (Jeff Sparkes) Subject: uncompress leaves point at end of file Message-Id: <1992Aug26.223417.12474@bwdls61.bnr.ca> Nntp-Posting-Host: bwdls138 Organization: Bell-Northern Research Ltd., Ottawa Date: Wed, 26 Aug 1992 22:34:17 GMT Lines: 10 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com (I don't remember if I sent this one in already..) Subject says it all. If you visit a compressed file, point is the end of the buffer. This didn't happen under 18.58, and uncompress.el looks to be the same. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Thu Aug 27 03:14:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10046; Thu, 27 Aug 92 03:14:21 PDT Received: by heavens-gate.lucid.com id AA01388g; Thu, 27 Aug 92 03:01:11 PDT Received: from ntu.ac.sg by heavens-gate.lucid.com id AA01384g; Thu, 27 Aug 92 03:00:54 PDT Received: by ntu.ac.sg (5.57/Ultrix3.0-C) id AA26377; Thu, 27 Aug 92 18:11:23 +0800 Message-Id: <9208271011.AA26377@ntu.ac.sg> Sender: franks%ntu.ac.sg@lucid.com Date: Thu, 27 Aug 1992 18:11:59 +0730 To: bug-lucid-emacs@lucid.com From: franks%ntu.ac.sg@lucid.com (Frank Siebenlist) Subject: please add me to mailing list ________________________________________________________________________ Frank Siebenlist Email: franks@imt.ntu.ac.sg Institute of Manufacturing Technology (IMT) Tel: (65) 799-1336 Nanyang Technological University (NTU) Fax: (65) 791-2927 Nanyang Avenue Singapore 2263 From bug-lucid-emacs-request@lucid.com Thu Aug 27 07:36:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10382; Thu, 27 Aug 92 07:36:21 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01665g; Thu, 27 Aug 92 07:23:50 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA28275; Thu, 27 Aug 92 10:34:38 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA28271; Thu, 27 Aug 92 10:34:36 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!lystad From: lystad@m2.dseg.ti.com (Garr Lystad) Subject: Re: bug with point-to-register Organization: TI DSEG, Spring Creek, Plano, Tx. In-Reply-To: jsparkes@bwdls138.bnr.ca's message of Wed, 26 Aug 1992 20:40:48 GMT References: <1992Aug26.204048.10644@bwdls61.bnr.ca> Message-Id: Reply-To: Garr Lystad Date: Thu, 27 Aug 1992 15:10:47 GMT Lines: 14 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <1992Aug26.204048.10644@bwdls61.bnr.ca> jsparkes@bwdls138.bnr.ca (Jeff Sparkes) writes: > It appears that I type to fast for lemacs. (This is version 19.2, > sun4). If I type "C-x/a" quickly, the prompt for the register shows > up. If I hit a again, the point does indeed go to register a, and an > a shows up in the buffer. It does not appear in the buffer until > after I type something at the prompt. I guess the (interactive?) > argument reader is a little slow. No, you don't type too fast. The command seems to just be broken. This bug has been bugging me for days now, and I hope to be able to look for a workaround today. If I find anything I'll post it. -- Garr From bug-lucid-emacs-request@lucid.com Thu Aug 27 07:43:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10411; Thu, 27 Aug 92 07:43:21 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01701g; Thu, 27 Aug 92 07:34:03 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29034; Thu, 27 Aug 92 10:44:50 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA29030; Thu, 27 Aug 92 10:44:47 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!lystad From: lystad@m2.dseg.ti.com (Garr Lystad) Subject: Ctrl-x Esc bug Organization: TI DSEG, Spring Creek, Plano, Tx. Message-Id: Reply-To: Garr Lystad Distribution: alt Date: Thu, 27 Aug 1992 15:26:45 GMT Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com It seems that I frequently want to repeat a 'complex' command, i.e. a minibuffer command. I press C-x ESC usually to do this and it works just fine for a while. But eventually lemacs gets to be in a funny state where the minibuffer will say C-x ESC - and just wait for another key. Yesterday when that happened I found that repeat-complex-command is also on C-x [. That key sequence had the same problem, I got C-x [ - in the minibuffer. I will try to find out what action causes this problem, but if anyone already knows I'd appreciate the information. If there's a fix I'd appreciate that too. -- Garr From bug-lucid-emacs-request@lucid.com Thu Aug 27 09:33:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10721; Thu, 27 Aug 92 09:33:35 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA01986g; Thu, 27 Aug 92 09:24:07 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09238; Thu, 27 Aug 92 12:34:56 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09233; Thu, 27 Aug 92 12:34:53 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!sun-barr!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!lystad From: lystad@m2.dseg.ti.com (Garr Lystad) Subject: Re: Ctrl-x Esc bug Organization: TI DSEG, Spring Creek, Plano, Tx. In-Reply-To: lystad@m2.dseg.ti.com's message of Thu, 27 Aug 1992 15:26:45 GMT References: Message-Id: Reply-To: Garr Lystad Distribution: alt Date: Thu, 27 Aug 1992 17:14:53 GMT Lines: 12 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I've found what I did, something reasonable I think, with an unreasonable result, or at least so it seems to me. After defining uncomment-out-region I did (define-key global-map [(control x)(meta \;)] 'uncomment-out-region) From that point on it's broken. I guess it must be some holdover from ESC = meta confusion. What really seems strange is that C-x C-[ is broken too. -- Garr From bug-lucid-emacs-request@lucid.com Thu Aug 27 10:51:57 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10942; Thu, 27 Aug 92 10:51:57 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02256g; Thu, 27 Aug 92 10:42:36 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA14203; Thu, 27 Aug 92 13:53:24 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA14197; Thu, 27 Aug 92 13:53:18 -0400 Path: uunet!mcsun!uknet!edcastle!aifh!aifh!tfb From: tfb@aisb.ed.ac.uk (Tim Bradshaw) Newsgroups: alt.lucid-emacs.bug Subject: A diff.el that works, I hope Message-Id: Date: 27 Aug 92 17:43:25 GMT Organization: Not Lines: 275 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Here is a version of the diff.el distributed with lemacs-19.2 which has some bug-fixes and some compatibility stuff for dired and ange-ftp put in. This seems to work for me, if you make changes or find bugs can you let me know? --Cut-- #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh diff.el <<'END_OF_diff.el' X;;;; * Fixed diff with optional switches X;; $Id: diff.el,v 1.3 1992/08/26 21:06:27 tfb Exp $ X;; "DIFF" mode for handling output from unix diff utility. X;; Copyright (C) 1990 Free Software Foundation, Inc. X;; Written sunpitt!wpmstr!fbresz@Sun.COM 1/27/89 X X;; This file is part of GNU Emacs. X X;; GNU Emacs is free software; you can redistribute it and/or modify X;; it under the terms of the GNU General Public License as published by X;; the Free Software Foundation; either version 1, or (at your option) X;; any later version. X X;; GNU Emacs is distributed in the hope that it will be useful, X;; but WITHOUT ANY WARRANTY; without even the implied warranty of X;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the X;; GNU General Public License for more details. X X;; You should have received a copy of the GNU General Public License X;; along with GNU Emacs; see the file COPYING. If not, write to X;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. X X;; todo: diff-switches flexibility: X;; (defconst diff-switches-function X;; '(lambda (file) X;; (if (string-match "\\.el$" file) X;; "-c -F\"^(\"" X;; "-p")) X;; "Function to return switches to pass to the `diff' utility, in \\[diff]. X;; This function is called with one arg, a file name, and returns a string X;; containing 0 or more arguments which are passed on to `diff'. X;; NOTE: This is not an ordinary hook; it may not be a list of functions.") X X;;; moved to loaddefs.el X;(defvar diff-switches nil X; "*A list of switches to pass to the diff program.") X X(defvar diff-search-pattern "^\\([0-9]\\|\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\*\\)" X "Regular expression that delineates difference regions in diffs.") X X;; Initialize the keymap if it isn't already X(if (boundp 'diff-mode-map) X nil X (setq diff-mode-map (make-keymap)) X (suppress-keymap diff-mode-map) X (define-key diff-mode-map "?" 'describe-mode) X (define-key diff-mode-map "." 'diff-beginning-of-diff) X (define-key diff-mode-map " " 'scroll-up) X (define-key diff-mode-map "\177" 'scroll-down) X (define-key diff-mode-map "n" 'diff-next-difference) X (define-key diff-mode-map "p" 'diff-previous-difference) X (define-key diff-mode-map "j" 'diff-show-difference)) X X(defun diff (old new &optional switches) X "Find and display the differences between OLD and NEW files. XInteractively you are prompted with the current buffer's file name for NEW Xand what appears to be its backup for OLD." X (interactive (diff-read-args "Diff original file (%s) " X "Diff new file (%s) " X "Switches for diff (%s) " X (buffer-file-name))) X (setq switches (diff-fix-switches (or switches diff-switches))) X (message "Comparing files %s %s..." new old) X (setq new (expand-file-name new) X old (expand-file-name old)) X (let ((buffer-read-only nil)) X (with-output-to-temp-buffer "*Diff Output*" X (buffer-disable-undo standard-output) X (save-excursion X (set-buffer standard-output) X (erase-buffer) X (apply 'call-process "diff" nil t nil X (append switches (list old new))))) X (set-buffer "*Diff Output*") X (goto-char (point-min)) X (while switches X (if (string= (car switches) "-c") X ;; strip leading filenames from context diffs X (progn (forward-line 2) (delete-region (point-min) (point)))) X (setq switches (cdr switches)))) X (diff-mode) X (if (string= "0" diff-total-differences) X (message "There are no differences.") X (narrow-to-region (point) (progn X (forward-line 1) X (if X (re-search-forward diff-search-pattern nil 'move) X (goto-char (match-beginning 0)) X (point)))) X X (setq diff-current-difference "1"))) X X;;; arg reading from Dired originally X(defun diff-read-args (oldprompt newprompt switchprompt X &optional file-for-backup) X ;; Grab the args for diff. OLDPROMPT and NEWPROMPT are the prompts X ;; for the old & new filenames, SWITCHPROMPT for the list of X ;; switches. If FILE_FOR_BACKUP is provided (it must be a string if X ;; so), then it will be used to try & work out a file & backup to X ;; diff, & in this case the prompting order is backwards. %s in a X ;; prompt has a guess substituted into it. This is nasty. X (let (oldf newf) X (if file-for-backup X (setq newf file-for-backup X newf (if (and newf (file-exists-p newf)) X (read-file-name X (format newprompt (file-name-nondirectory newf)) X nil newf t) X (read-file-name (format newprompt "") nil nil t)) X oldf (file-newest-backup newf) X oldf (if (and oldf (file-exists-p oldf)) X (read-file-name X (format oldprompt (file-name-nondirectory oldf)) X nil oldf t) X (read-file-name (format oldprompt "") X (file-name-directory newf) nil t))) X ;; Else we aren't trying to be bright... X (setq oldf (read-file-name (format oldprompt "") nil nil t) X newf (read-file-name X (format newprompt (file-name-nondirectory oldf)) X nil (file-name-directory oldf) t))) X (list oldf newf (diff-read-switches switchprompt)))) X X(defun diff-read-switches (switchprompt) X ;; Read and return a list of switches X (if current-prefix-arg X (let ((default (mapconcat 'identity diff-switches " "))) X (diff-fix-switches X (read-string (format switchprompt default) default))))) X X(defun diff-fix-switches (switch-spec) X ;; Parse a string into a list of switches or leave it be if it's X ;; not a string X (if (stringp switch-spec) X (let (result (start 0)) X (while (string-match "\\(\\S-+\\)" switch-spec start) X (setq result (cons (substring switch-spec (match-beginning 1) X (match-end 1)) X result) X start (match-end 0))) X (nreverse result)) X switch-spec)) X X X;; Take a buffer full of Unix diff output and go into a mode to easily X;; see the next and previous difference X(defun diff-mode () X "Diff Mode is used by \\[diff] for perusing the output from the diff program. XAll normal editing commands are turned off. Instead, these are available: X\\ X\\[diff-beginning-of-diff] Move point to start of this difference. X\\[scroll-up] Scroll to next screen of this difference. X\\[scroll-down] Scroll to previous screen of this difference. X\\[diff-next-difference] Move to Next Difference. X\\[diff-previous-difference] Move to Previous Difference. X\\[diff-show-difference] Jump to difference specified by numeric position. X" X (interactive) X (use-local-map diff-mode-map) X (setq buffer-read-only t X major-mode 'diff-mode X mode-name "Diff" X mode-line-modified "--- " X mode-line-process X '(" " diff-current-difference "/" diff-total-differences)) X (make-local-variable 'diff-current-difference) X (set (make-local-variable 'diff-total-differences) X (int-to-string (diff-count-differences)))) X X(defun diff-next-difference (n) X "In diff-mode go the the beginning of the next difference as delimited Xby diff-search-pattern." X (interactive "p") X (if (< n 0) (diff-previous-difference (- n)) X (if (zerop n) () X (goto-char (point-min)) X (forward-line 1) ; to get past the match for the start of this diff X (widen) X (if (re-search-forward diff-search-pattern nil 'move n) X (let ((start (goto-char (match-beginning 0)))) X (forward-line 1) X (if (re-search-forward diff-search-pattern nil 'move) X (goto-char (match-beginning 0))) X (narrow-to-region start (point)) X (setq diff-current-difference X (int-to-string (+ n (string-to-int X diff-current-difference))))) X (re-search-backward diff-search-pattern nil) X (narrow-to-region (point) (point-max)) X (message "No following differences.") X (setq diff-current-difference diff-total-differences)) X (goto-char (point-min))))) X X(defun diff-previous-difference (n) X "In diff-mode go the the beginning of the previous difference as delimited Xby diff-search-pattern." X (interactive "p") X (if (< n 0) (diff-next-difference (- n)) X (if (zerop n) () X (goto-char (point-min)) X (widen) X (if (re-search-backward diff-search-pattern nil 'move n) X (setq diff-current-difference X (int-to-string (- (string-to-int diff-current-difference) n))) X (message "No previous differences.") X (setq diff-current-difference "1")) X (narrow-to-region (point) (progn X (forward-line 1) X (if X (re-search-forward diff-search-pattern nil 'move) X (goto-char (match-beginning 0)) X (point)))) X (goto-char (point-min))))) X X(defun diff-show-difference (n) X "Show difference number N (prefix argument)." X (interactive "p") X (let ((cur (string-to-int diff-current-difference))) X (cond ((or (= n cur) X (zerop n) X (not (natnump n))) ; should signal an error perhaps. X ;; just redisplay. X (goto-char (point-min))) X ((< n cur) X (diff-previous-difference (- cur n))) X ((> n cur) X (diff-next-difference (- n cur)))))) X X(defun diff-beginning-of-diff () X "Goto beginning of current difference." X (interactive) X (goto-char (point-min))) X X;; This function counts up the number of differences in the buffer. X(defun diff-count-differences () X "Count number of differences in the current buffer." X (message "Counting differences...") X (save-excursion X (save-restriction X (widen) X (goto-char (point-min)) X (let ((cnt 0)) X (while (re-search-forward diff-search-pattern nil t) X (setq cnt (1+ cnt))) X (message "Counting differences...done (%d)" cnt) X cnt)))) END_OF_diff.el if test 9371 -ne `wc -c Date: 28 Aug 92 06:18:21 GMT Organization: University of Nice Sophia-Antipolis, France Lines: 14 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Has anyone else noticed this? It struck me when I used epoch again lately. It's especially noticeable when lemacs' window has been unmapped (either iconified or hidden) and needs to be mapped again. First it is slow to appear and second, it is slow to process, for example, new mail in RMAIL mode. It's almost immediate with epoch (a 'g' displays the new messages within a second). Any ideas? Will it be speeded up in version 19.3? -- Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE. From bug-lucid-emacs-request@lucid.com Fri Aug 28 04:11:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13798; Fri, 28 Aug 92 04:11:06 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA04650g; Fri, 28 Aug 92 04:01:39 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18716; Fri, 28 Aug 92 07:12:28 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18712; Fri, 28 Aug 92 07:12:27 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Subject: Startup/sit-for buglets Message-Id: <1992Aug27.224738.3500@cs.sfu.ca> Summary: menu events don't count as events in sit-for, plus more Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Date: Thu, 27 Aug 1992 22:47:38 GMT Lines: 19 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Environment: Lemacs 19.2, X11R5, SunOS 4.1.1, sparc The first bug is fairly clear cut: menubar events don't cause sit-for to return. Try (sit-for 30) and then select something from a menu. The second is somehow related, but wierder: if you start lemacs up, and press an undefined mouse button to clear the warranty, then the the next menu item you select is passed an argument. In my case, this causes info-dg.el to prompt for an info file. -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Sun Aug 30 06:48:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19640; Sun, 30 Aug 92 06:48:42 PDT Received: by heavens-gate.lucid.com id AA08655g; Sun, 30 Aug 92 06:33:22 PDT Received: from liasg1.epfl.ch by heavens-gate.lucid.com id AA08651g; Sun, 30 Aug 92 06:33:09 PDT Received: by liasg1.epfl.ch (Smail3.1.26.7 #2) id m0mOpZK-0009eTC; Sun, 30 Aug 92 15:43 MDT Message-Id: Date: Sun, 30 Aug 92 15:43 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com, Joe Wells Subject: etags.el enhancement # 13 All in all I am very happy with the new etags package - tag completion is a big win! But one improvement I would sometimes like to disable is: ;; 13. don't pull all files into memory for tags-search Rationale: I always use "M-x tags-s RET zxc RET" to "page in" all source files of the project I start working on. With the new etags.el, all the buffers get killed immediately :-( The following patch to etags.el from the Lucid Emacs 19.2 distribution adds a switch for the new behavior, so that I can turn it off from my .emacs. It would really be nice if something like this could be added to the distribution. Thanks!! -- Simon. *** 1.1 1992/08/30 13:34:26 --- etags.el 1992/08/30 13:36:56 *************** *** 1015,1020 **** --- 1015,1024 ---- "Form for tags-loop-continue to eval to process one file. If it returns nil, it is through with one file; move on to next.") + (defvar tags-search-nuke-uninteresting-buffers t + "*If t (the default), tags-search and tags-query-replace will only + keep newly-visited buffers if they contain the search target.") + (defun tags-loop-continue (&optional first-time) "Continue last \\[tags-search] or \\[tags-query-replace] command. Used noninteractively with non-nil argument *************** *** 1027,1033 **** (setq message t))) ;; **** (let ((cursor-in-echo-area t))) (while (not (eval tags-loop-form)) ! (if (and buf-is-new (not (buffer-modified-p))) (kill-buffer (current-buffer))) (setq buf-is-new (next-file)) (message "Scanning file %s..." buffer-file-name) --- 1031,1038 ---- (setq message t))) ;; **** (let ((cursor-in-echo-area t))) (while (not (eval tags-loop-form)) ! (if (and buf-is-new (not (buffer-modified-p)) ! tags-search-nuke-uninteresting-buffers) (kill-buffer (current-buffer))) (setq buf-is-new (next-file)) (message "Scanning file %s..." buffer-file-name) From bug-lucid-emacs-request@lucid.com Sun Aug 30 10:48:49 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19952; Sun, 30 Aug 92 10:48:49 PDT Received: by heavens-gate.lucid.com id AA08775g; Sun, 30 Aug 92 10:35:24 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA08771g; Sun, 30 Aug 92 10:33:47 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA03472; Sun, 30 Aug 92 12:42:51 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA05228; Sun, 30 Aug 92 13:33:30 EDT Received: from msn10.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA03402; Sun, 30 Aug 92 13:45:49 EDT Date: Sun, 30 Aug 92 13:45:49 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9208301745.AA03402@pts4.pts.mot.com> Received: by msn10.motorola (4.1/SMI-4.1) id AA01719; Sun, 30 Aug 92 13:45:57 EDT To: bug-lucid-emacs@lucid.com Subject: Simple fix for novice.el bug in Lemacs V19.2. diff ~/lemacs/lisp/prim/novice.el- ~/lemacs/lisp-lemacs/novice.el 30,35c30 < ;; ## Hey, this doesn't work! this-command-keys doesn't include M-x. < (if (eq (event-to-character (aref (this-command-keys) 0)) ?\M-x) < (princ "You have invoked the disabled command ") < (princ "You have typed ") < (princ (key-description (this-command-keys))) < (princ ", invoking disabled command ")) --- > (princ "You have invoked the disabled command ") From bug-lucid-emacs-request@lucid.com Tue Sep 1 02:54:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25589; Tue, 1 Sep 92 02:54:42 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA12817g; Tue, 1 Sep 92 02:42:18 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA16231; Tue, 1 Sep 92 05:53:16 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA16227; Tue, 1 Sep 92 05:53:13 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!aun.uninett.no!nuug!nntp.nta.no!nntp.nta.no!howcome From: howcome%nta.no@lucid.com (Hakon W Lie FDX) Subject: lucid/gnus bug Message-Id: Nntp-Posting-Host: earth.nta.no Organization: Norwegian Telecom Research, Norway Date: 1 Sep 92 11:33:52 Lines: 10 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com When using lucid with gnus (3.13) I sometimes get teh message "wrong type argument: syntax-table-p, nil" when selecting a group. This happens consitentlly with some groups, and not with others. I'm sure this has been discovered/discussed before, but it would be very helpful if someone could point me to a solution: should I upgrade gnus, lemacs or is there a patch? Thanks, -h&kon From bug-lucid-emacs-request@lucid.com Tue Sep 1 06:20:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25901; Tue, 1 Sep 92 06:20:42 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA13030g; Tue, 1 Sep 92 06:11:31 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA08658; Tue, 1 Sep 92 09:22:28 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA08654; Tue, 1 Sep 92 09:22:27 -0400 Path: uunet!mcsun!uknet!edcastle!aifh!aifh!tfb From: tfb@aisb.ed.ac.uk (Tim Bradshaw) Newsgroups: alt.lucid-emacs.bug Subject: Re: lucid/gnus bug Message-Id: Date: 1 Sep 92 12:59:44 GMT References: Organization: Not Lines: 37 In-Reply-To: howcome@nta.no's message of 1 Sep 92 10:33:52 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On 1 Sep 92 10:33:52 GMT, howcome@nta.no (Hakon W Lie FDX) said: > When using lucid with gnus (3.13) I sometimes get teh message "wrong > type argument: syntax-table-p, nil" when selecting a group. This > happens consitentlly with some groups, and not with others. I'm sure > this has been discovered/discussed before, but it would be very > helpful if someone could point me to a solution: should I upgrade > gnus, lemacs or is there a patch? This is likely a problem with nested comments in addresses. Emacs tries to use the lisp-mode syntax table to parse them but this is no longer defaultly in the sysout. Emacs-lisp mode is though so this diff ro utils/mail-utils.el fixes it. --tim --Cut-- *** mail-utils.el-orig Tue Apr 14 01:16:40 1992 --- mail-utils.el Tue Sep 1 13:57:06 1992 *************** *** 55,61 **** (set-buffer (get-buffer-create " *temp*")) (erase-buffer) (insert address) ! (set-syntax-table lisp-mode-syntax-table) (goto-char 1) (while (search-forward "(" nil t) (forward-char -1) --- 55,61 ---- (set-buffer (get-buffer-create " *temp*")) (erase-buffer) (insert address) ! (set-syntax-table emacs-lisp-mode-syntax-table) (goto-char 1) (while (search-forward "(" nil t) (forward-char -1) From bug-lucid-emacs-request@lucid.com Tue Sep 1 06:24:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25908; Tue, 1 Sep 92 06:24:23 PDT Received: by heavens-gate.lucid.com id AA13037g; Tue, 1 Sep 92 06:14:59 PDT Received: from linus.mitre.org by heavens-gate.lucid.com id AA13033g; Tue, 1 Sep 92 06:13:10 PDT Return-Path: Received: from circe.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA20662; Tue, 1 Sep 92 09:24:06 -0400 Posted-Date: Tue, 01 Sep 92 09:24:57 -0400 Received: by circe.mitre.org (5.61/RCF-4C) id AA01838; Tue, 1 Sep 92 09:24:58 -0400 Message-Id: <9209011324.AA01838@circe.mitre.org> To: bug-lucid-emacs@lucid.com Cc: guttman@linus.mitre.org Subject: delete-window X-Postal-Address: MITRE, Mail Stop A156 \\ 202 Burlington Rd. \\ Bedford, MA 01730 X-Telephone-Number: 617 271 2654; Fax 617 271 3816 Date: Tue, 01 Sep 92 09:24:57 -0400 From: guttman@linus.mitre.org Delete-window now destroys the screen if there is only one window on it. This is disconcerting. Since there's also delete-screen, I don't see the purpose of having this curlicue on delete-window. Why be willfully incompatible with behavior familiar from Emacs18 and before? Josh ~~~~~~~~~~~~~~~~ delete-window: Remove WINDOW from the display. Default is selected window. If window is the only one on the screen, the screen is destroyed. arguments:(&optional window) From bug-lucid-emacs-request@lucid.com Tue Sep 1 21:42:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA28244; Tue, 1 Sep 92 21:42:24 PDT Received: by heavens-gate.lucid.com id AA15662g; Tue, 1 Sep 92 21:29:57 PDT Received: from uucp-gw-1.pa.dec.com by heavens-gate.lucid.com id AA15658g; Tue, 1 Sep 92 21:29:46 PDT Received: by uucp-gw-1.pa.dec.com; id AA01056; Tue, 1 Sep 92 21:31:13 -0700 Received: by wsrcc.com id AA13414 (5.65c/IDA-1.4.4-WSR-06/19/92 for bug-lucid-emacs@lucid.com); Tue, 1 Sep 1992 09:53:06 -0700 Message-Id: <199209011653.AA13414@wsrcc.com> Received: from USENET by wsrcc.com with netnewsfor bug-lucid-emacs@lucid.com (bug-lucid-emacs@lucid.com);contact usenet@wsrcc.com if you have questions. To: bug-lucid-emacs@lucid.com Date: Tue, 1 Sep 1992 16:53:00 GMT From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht) Organization: W S Rupprecht Computer Consulting, Fremont CA References: , <9208200058.AA22751@viper.edb.tih.no.> Subject: Re: Compiling Lucid Emacs 19.2 under ISC 2.2.1 oddbjorn@edb.tih.no writes: >I'm trying to install Lucid Emacs 19.2 under Interactive >2.2.1 (SysV3.2). With a little tweaking, I managed to >compile everything, but now, during the linking I have >some problems : >undefined first referenced >symbol in file >remainder data.o >acosh floatfns.o >asinh floatfns.o >atanh floatfns.o >cbrt floatfns.o >expm1 floatfns.o >lgamma floatfns.o >log1p floatfns.o >logb floatfns.o >rint floatfns.o These functions come from the BSD math library of 4.2 and 4.3. Just grab them from some site that has the freed part of the BSD code such as uunet. Alternately you can just write some stubs just to get things to compile. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang Snail Mail: 39469 Gallaudet Drive, Fremont, CA 94538-4511 From bug-lucid-emacs-request@lucid.com Wed Sep 2 07:01:56 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00107; Wed, 2 Sep 92 07:01:56 PDT Received: by heavens-gate.lucid.com id AA16560g; Wed, 2 Sep 92 06:48:59 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA16553g; Wed, 2 Sep 92 06:48:17 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA07467; Wed, 2 Sep 92 08:59:40 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA00331; Wed, 2 Sep 92 09:46:24 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA15184; Tue, 1 Sep 92 19:16:48 EDT Date: Tue, 1 Sep 92 19:16:48 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9209012316.AA15184@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA02498; Tue, 1 Sep 92 19:16:02 EDT To: bug-lucid-emacs@lucid.com Subject: raise-screen does not work under OpenLook WM and Lemacs V19.2. Reply-To: bob_weiner@pts.mot.com Lower screen works fine. Is this a known bug or is it a configuration issue with my window manager? From bug-lucid-emacs-request@lucid.com Sun Sep 6 05:38:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13634; Sun, 6 Sep 92 05:38:58 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA28035g; Sun, 6 Sep 92 05:26:42 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07837; Sun, 6 Sep 92 08:37:50 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07833; Sun, 6 Sep 92 08:37:47 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!corax.udac.uu.se!woody.csd.uu.se!hb From: hb%woody.csd.uu.se@lucid.com (Henrik B}kman CSD) Subject: Re: Compiling Lucid Emacs 19.2 under ISC 2.2.1 Message-Id: <1992Sep6.120311.5306@corax.udac.uu.se> Organization: UDAC, Uppsala, Sweden References: <199209011653.AA13414@wsrcc.com> Date: Sun, 6 Sep 1992 12:03:11 GMT Lines: 34 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <199209011653.AA13414@wsrcc.com>, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes: > oddbjorn@edb.tih.no writes: > >I'm trying to install Lucid Emacs 19.2 under Interactive > >2.2.1 (SysV3.2). With a little tweaking, I managed to > >compile everything, but now, during the linking I have > >some problems : > > >undefined first referenced > >symbol in file > >remainder data.o > >acosh floatfns.o > >asinh floatfns.o > >atanh floatfns.o > >cbrt floatfns.o > >expm1 floatfns.o > >lgamma floatfns.o > >log1p floatfns.o > >logb floatfns.o > >rint floatfns.o > > These functions come from the BSD math library of 4.2 and 4.3. Just > grab them from some site that has the freed part of the BSD code such > as uunet. > > Alternately you can just write some stubs just to get things to > compile. Another way is to comment out '#define LISP_FLOAT_TYPE' in src/config.h -- ---------------------------------------------------------------------- Henrik Bakman Adress: Box 520 Tel: +46 18 181044 System Manager 751 20 UPPSALA Fax: +46 18 521270 Computing Science Dep. SWEDEN Email: hb@csd.uu.se Uppsala University From bug-lucid-emacs-request@lucid.com Tue Sep 8 06:07:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA19145; Tue, 8 Sep 92 06:07:42 PDT Received: by heavens-gate.lucid.com id AA00695g; Tue, 8 Sep 92 05:56:29 PDT Received: from ingr.ingr.com by heavens-gate.lucid.com id AA00691g; Tue, 8 Sep 92 05:56:11 PDT Received: from matis.UUCP by ingr.ingr.com (5.65c/1.920611) id AA02289; Tue, 8 Sep 1992 08:12:47 -0500 Received: from simpson.turtles by turtles (4.1/SMI-4.1) id AA11063; Mon, 7 Sep 92 17:28:19 IDT Received: by simpson.turtles (4.1/SMI-4.1) id AA02077; Mon, 7 Sep 92 16:27:34 IST From: matis!amir@lucid.com (Amir Katz) Message-Id: <9209071427.AA02077@simpson.turtles> Subject: Sound on SunOS 4.1.3 To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Mon, 7 Sep 92 16:27:33 EET Organization: SEE Technologies Ltd. Reply-To: matis!matis.ingr.COM!amir@lucid.com X-Reply-To: amir@matis.ingr.COM X-Mailer: ELM [version 2.3 PL11] Lucidites, take notice. Today I installed SunOs 4.1.3 on my machine (always the pioneer (sucker?) here). The sound stuff stopped working, so I had to tweak the file libsst.c in the 'src' directory and to rebuild. My configuration is: SparcStation 1+ w/GX SunOS 4.1.3 MIT X11R5, patch 17 gcc 2.2.2 Audio Device Changes ==================== In SunOS 4.1.3, the audio device stuff has been changed (in order to support the better audio devices on the SPARC*10 boxes). It seems like the literal AUDIOSETQSIZE does no longer exist and there is no equivalent function to change the audio device queue size, as far as I can tell from the man pages. I'm sure the audio device can be better utilized, but what the hell, it works now, so who cares... *** libsst.c.orig Tue Apr 14 03:25:53 1992 --- libsst.c Mon Sep 7 15:30:44 1992 *************** *** 34,39 **** --- 34,40 ---- return( fd ); } + #ifdef AUDIO_4_1_2 /* AJK */ /* Shrink audio device's queue size, to cut down time delay. */ i = AUDBUF; if ( ioctl( fd, AUDIOSETQSIZE, &i ) < 0 ) *************** *** 41,46 **** --- 42,48 ---- perror( "sst_open: SETQSIZE" ); return( fd ); } + #endif /* AUDIO_4_1_2 */ /* Set gains. -10 <= ger <= 18, -18 <= gr <= 12, -18 <= gx <= 12. */ if (!play_level) -- /* ----------------------------------------------------------- */ /* Amir J. Katz | amir@matis.ingr.COM */ /* System Specialist | Voice: +972 52-584684 */ /* SEE Technologies Ltd. | Fax: +972 52-543917 */ /* ............ Solaris 2.0 - The Final Frontier ? ........... */ From bug-lucid-emacs-request@lucid.com Wed Sep 9 13:38:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24598; Wed, 9 Sep 92 13:38:46 PDT Received: by heavens-gate.lucid.com id AA05280g; Wed, 9 Sep 92 13:28:21 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA05273g; Wed, 9 Sep 92 13:26:28 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA27376; Wed, 9 Sep 92 13:37:49 PDT Date: Wed, 9 Sep 92 13:37:49 PDT Message-Id: <9209092037.AA27376@thalidomide.lucid> From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bug-lucid-emacs@lucid.com Subject: Lucid Emacs 19.3 released Lucid GNU Emacs 19.3 is now available. This is a version of GNU Emacs derived from an early version of Emacs version 19 from the Free Software Foundation. (If you are already a user of version 19.2, you might want to skip ahead to the section labeled "Differences Between 19.2 and 19.3".) You can get it via anonymous FTP from the host labrea.Stanford.EDU (36.8.0.47). It is currently available only by FTP. We don't have the manpower to make tapes right now. Log in with the user "anonymous" and "username@host" as a password (that is, your email address.) Execute the command "cd pub/gnu/lucid/". These are the files you will find there: lemacs-19.3.tar.Z The complete source distribution. This file is about 8 megabytes. When untarred and uncompressed, the source distribution will take up about 20 megs. You will need an additional 12 megs or so to compile it. lemacs-19.3-sun4.tar.Z This is a ready-to-run set of Sun4 executables, and a DOC file. If you want to use these executables, you will still need to get the file lemacs-19.3.tar.Z, because Emacs cannot function very well without the lisp library online. This file is about 1.7 megs, 3.8 megs when unpacked, 3 megs of which is the Emacs executable itself (2.1 megs if stripped.) Don't forget to set "binary" mode when transferring these files. Unpack them with some variation of the command "zcat lemacs-19.3.tar.Z | tar -vxf -". We have created two mailing lists for discussing our Emacs. bug-lucid-emacs@lucid.com For reporting all bugs in Lucid GNU Emacs, including bugs in the compilation and installation procedures. help-lucid-emacs@lucid.com For random questions and conversation about using Lucid GNU Emacs. To be added or removed from these mailing lists, send mail to bug-lucid-emacs-request@lucid.com or help-lucid-emacs-request@lucid.com. The bug-lucid-emacs and help-lucid-emacs mailing lists are archived on labrea, and are bidirectionally gatewayed into the newsgroups alt.lucid-emacs.bug and alt.lucid-emacs.help. The bug-lucid-emacs and help-lucid-emacs mailing lists are archived on labrea. Please do not send messages about problems with Lucid GNU Emacs to the FSF GNU Emacs newsgroups and mailing lists (help-gnu-emacs@prep.ai.mit.edu, bug-gnu-emacs@prep.ai.mit.edu, gnu.emacs.help, gnu.emacs.bug, et cetera) unless you are sure that the problem you are reporting is a problem with both versions of GNU Emacs. People who aren't subscribed to the Lucid GNU Emacs mailing lists most likely are not interested in hearing about problems with it. Why Another Version of Emacs? ============================= Lucid's latest product, Energize, is a C/C++ development environment. Rather than invent (and force our users to learn) a new user-interface, we chose to build part of our environment on top of the world's best editor, GNU Emacs. (Though our product is commercial, the work we did on GNU Emacs is free software, and is useful without having to purchase our product.) We needed a version of Emacs with mouse-sensitive regions, multiple fonts, the ability to mark sections of a buffer as read-only, the ability to detect which parts of a buffer has been modified, and many other features. Why Not Epoch? ============== For our purposes, the existing version of Epoch was not sufficient; it did not allow us to put arbitrary pixmaps/icons in buffers, `undo' did not restore changes to regions, regions did not overlap and merge their attributes in the way we needed, and several other things. We could have devoted our time to making Epoch do what we needed (and, in fact, we spent some time doing that) but, since the FSF planned to include Epoch-like features in their version 19, we decided that our efforts would be better spent improving Emacs19 instead of Epoch. Our original hope was that our changes to Emacs would be incorporated into the "official" v19. However, scheduling conflicts arose, and we found that, given the amount of work still remaining to be done, we didn't have time to merge with the FSF's code. Consequently, we have released our work as a forked branch of Emacs, instead of delaying any longer. It seems likely that a merger of Epoch and Lucid Emacs will occur in the not-too-distant future. No Warranty =========== Lucid GNU Emacs is distributed under exactly the same terms as GNU Emacs, and thus has no warranty of any kind. (However, Energize support contracts include Lucid GNU Emacs support.) We do not currently have plans to sell support for Emacs independent of support for Energize. What's Different? ================= Lucid GNU Emacs *currently* requires X Windows to run, though it will not be much work to make it run on dumb ttys again. We plan to do this soon. We have not personally tried to compile this version of Emacs under anything but SunOS 4.1 on SparcStations, though others have successfully done so. We are very eager to get feedback about portability problems from those who compile it on other systems. We have reimplemented the basic input model in a more general way; instead of X input being a special-case of the normal ASCII input stream, Emacs has a concept of "input events", and ASCII characters are a subset of that. The events that Emacs knows about are not X events, but are a generalization of them, so that Emacs can eventually be ported to different window systems. We have reimplemented keymaps so that sequences of events can be stored into them instead of just ASCII codes; it is possible to, for example, bind different commands to each of the chords Control-h, Control-H, Backspace, Control-Backspace, and Super-Shift-Backspace. Key bindings, function key bindings, and mouse bindings live in the same keymaps. Input and display of all ISO-8859-1 characters is supported. You can have multiple X Windows ("screens" in Emacs terminology). Our Emacs has objects called "extents" and "faces", which are roughly analogous to Epoch's "buttons," "zones," and "styles." An extent is a region of text (a start position and an end position) and a face is a collection of textual attributes like fonts and colors. Every extent is displayed in some "face", so changing the properties of a face immediately updates the display of all associated extents. Faces can be screen-local: you can have a region of text which displays with completely different attributes when its buffer is viewed from a different X window. The display attributes of faces may be specified either in lisp or through the X resource manager. Emacs use the MIT "Xt" toolkit instead of raw Xlib calls, which makes it be a more well-behaved X citizen (and also improves portability). A result of this is that it is possible to include other Xt "Widgets" in the Emacs window. Also, Emacs understands the standard Xt command-line arguments. Emacs understands the X11 "Selection" mechanism; it's possible to define and customize selection converter functions and new selection types from elisp, without having to recompile Emacs. Emacs now supports the Zmacs/Lispm style of region highlighting, where the region between the point and mark is highlighted when in its "active" state. Emacs has a menubar, whose contents are customizable from emacs-lisp. This menubar looks Motif-ish, but does not require Motif. If you already own Motif, however, you can configure Emacs to use a *real* Motif menubar instead. If you have OLIT ("OpenLook Intrinsics"), you can use an OpenWindows-like menubar. The initial load-path is computed at run-time, instead of at compile-time. This means that if you move the Emacs executable and associated directories to somewhere else, you don't have to recompile anything. Emacs now supports floating-point numbers. Emacs now knows about timers directly, instead of them being simulated by a subprocess. Emacs understands truenames, and can be configured to notice when you are visiting two names of the same file. If you're running on a sun SparcStation, you can specify sound files for Emacs to play instead of the default X beep. Much more detail about the differences between Lucid GNU Emacs and Emacs 18 can be found in the file .../etc/NEWS (accessible with ``C-h n''.) Note that building Lucid GNU Emacs requires an ANSI C compiler, such as gcc. Major Differences Between 19.2 and 19.3 ======================================= The ISO characters have correct case and syntax tables now, so the word-motion and case-converting commands work sensibly on them. If you set ctl-arrow to an integer, you can control exactly which characters are printable. (There will be a less crufty way to do this eventually.) Menubars can now be buffer local; the function set-screen-menubar no longer exists. Look at GNUS and VM for examples of how to do this, or read menubar.el. When emacs is reading from the minibuffer with completions, any completions which are visible on the screen will highlight when the mouse moves over them; clicking middle on a completion is the same as typing it at the minibuffer. Some implications of this: The *Completions* buffer is always mousable. If you're using the completion feature of find-tag, your source code will be mousable when you type M-. Dired buffers will be mousable as soon as you type ^X^F. And so on. The old isearch code has been replaced with a descendant of Dan LaLiberte's excellent isearch-mode; it is more customizable, and generally less bogus. You can search for "composed" characters. There are new commands, too; see the doc for ^S, or the NEWS file. Note that ESC no longer terminates an isearch: LFD does instead. This is a change RMS has made in his v19 as well. The old isearch variables (like search-repeat-char) are no longer used; it's all done with keymaps now. Please try to avoid the temptation to bind ESC to its old behavior; it was always a bad idea to overload the meta-prefix-char in this way. If you don't have a LFD key, you can make some other key be the terminator (RET, or F1, or whatever) but using ESC is more complicated because of its goofy equivalence to Meta. A patched GNUS 3.14 is included. The user's manual now documents Lucid Emacs 19.3. A few more modes have mouse and menu support. The startup code should be a little more robust, and give you more reasonable error messages when things aren't installed quite right (instead of the ubiquitous "cannot open DISPLAY"...) Subdirectories of the lisp directory whose names begin with a hyphen or dot are not automatically added to the load-path, so you can use this to avoid accidentally inflicting experimental software on your users. I've tried to incorporate all of the portability patches that were sent to me; I tried to solve some of the problems in different ways than the patches did, so let me know if I missed something. There's no `configure' support yet. I've been sent patches to make 19.1 work with configure, but I haven't had time to integrate them into 19.3. The OLIT menubar probably still doesn't work. Fixes are welcome, as always. Some systems will need to define NEED_STRDUP, NEED_REALPATH, HAVE_DREM, or HAVE_REMAINDER in config.h. Really this should be done in the appropriate s- or m- files, but I don't know which systems need these and which don't. If yours does, let me know which file it should be in. I haven't made diffs, because they would be really huge, and I still don't know a truly painless way to make diffs of an emacs source tree. Check out these new packages: blink-paren.el: causes the matching parenthesis to flash on and off whenever the cursor is sitting on a paren-syntax character. pending-del.el: Certain commands implicitly delete the highlighted region: Typing a character when there is a highlighted region replaces that region with the typed character. lhilit.el: Attaches fonts/colors to patterns matching regular expressions. font-lock.el: Yet Another code-highlighting package, but this one is driven off of syntax tables, so that it understands block comments, strings, etc. The insertion hook is used to fontify text as you type it in. (This is fast now.) shell-font.el: Displays your shell-buffer prompt in boldface. From bug-lucid-emacs-request@lucid.com Wed Sep 9 15:03:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24831; Wed, 9 Sep 92 15:03:59 PDT Received: by heavens-gate.lucid.com id AA05635g; Wed, 9 Sep 92 14:53:19 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA05614g; Wed, 9 Sep 92 14:50:02 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA27686; Wed, 9 Sep 92 15:01:24 PDT Date: Wed, 9 Sep 92 15:01:24 PDT Message-Id: <9209092201.AA27686@thalidomide.lucid> X-Windows: More than enough rope. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bug-lucid-emacs@lucid.com Subject: YP/DNS problem Some of you have encountered the bug that, when running on some machines, lemacs doesn't recognize certain (other) host names. I've isolated this bug a little further, and it confuses me greatly, so I'm going to describe what I know about it in hope that some of you have ideas, because I'm out. If emacs is linked against Sun's libc.a, then the gethostbyname() routine that is linked in is one that knows about YP (Yellow Pages, aka NIS) and not DNS (Domain Name Service, the standard which Sun has reinvented.) If you are running the emacs executable on machine A, with $DISPLAY set to machine B, then the emacs running on machine A needs to resolve the name "B" to an address. It does this by calling gethostbyname(). Normally this consults the YP database. Now here's the problem: if the *logged in user* is present in the local /etc/passwd file on machine A (as opposed to, or in addition to, being in the "passwd" YP database) then gethostbyname() will *not* attempt to use the contents of the YP host database to resolve hostnames to addresses. Suppose "B" is in the YP database and "B.FOO.COM" is registered in DNS. Emacs will work if $DISPLAY points at "B.FOO.COM", but not "B". B.FOO.COM need not be in the local /etc/hosts file. The rule seems to be that, if emacs manages to find the logged-in user information by using the local /etc/passwd file (which I presume it checks first) then it doesn't EVER consult YP for the "/etc/hosts" information. But it will consult DNS. Puzzle out that incestuous relationship, why don't you. Now, one might ask, why is this a problem for emacs and not for anything else? That's a very good question. One of the things that emacs does early in its startup is call tzsetwall(). If this is not done, then the dumped emacs will always think that it is in the timezone in which it was dumped. calling tzsetwall() makes emacs refresh its idea about what the local timezone is. The man page says: tzset() uses the value of the environment variable TZ to set time conversion information used by localtime(). If TZ is absent from the environment, the an available approximation to local wall clock time is used by localtime(). If TZ appears in the environment but its value is a null string, Greenwich Mean Time is used; if TZ appears and begins with a slash, it is used as the absolute pathname of the tzfile- format (see tzfile(5)) file from which to read the time conversion information; if TZ appears and begins with a character other than a slash, it is used as a pathname rela- tive to a system time conversion information directory. tzsetwall() sets things up so that localtime() returns the best available approximation of local wall clock time. I don't know what the difference between tzset() and tzsetwall() is, but they both seem to have the same effect. Which is: if a dumped emacs calls either of these tz functions, then the passwd/hosts problem exhibits itself. If neither of these tz functions is called, then there is no problem. This only happens from dumped emacses, so possibly it has something to do with static data being overwritten, or corrupted malloc lists, or something. In particular, it doesn't happen when one codes up the obvious trivial testcase (linking it either statically or dynamically.) This is baffling not only because I don't have the source to Sun's tz, host, and passwd functions, but because I don't have even a clue what they are actually trying to DO. Why do the tz functions have anything to do with the userid and host routines? Since the man page gives no information on how the tz routines figure out what timezone they are in, perhaps they use YP to figure it out. Who knows. Linking with the GNU libc.a doesn't shed any light on this, because the GNU libc.a doesn't know about YP at all, so it's a non-issue. I don't remember the details any more, but I found that if I caused YP to be consulted before the first call to tzsetwall() (I think by calling getpwuid() or something explicitly) then the problem didn't manifest itself. You won't notice this bug happening if you don't use YP, or if you have exactly the same information in the YP host database as is in the DNS host database; many sites have short local aliases in YP but not DNS, and those aliases will stop working if this problem rears its ugly head. So, to reiterate, my understanding of this bug is: once tzsetwall() is called, *IF* the logged-in user is in the local /etc/passwd file, then the YP host database is not consulted. One could interpret this as meaning that if YP is not consulted to find out the current user name, etc, then it won't be consulted for host names either. I expect that this only a problem (in the current incarnation, anyway) when emacs is running on a Sun; do any non-Sun machines use YP? The output from `trace' is pretty unilluminating. I'm wide open to suggestions. -- Jamie From bug-lucid-emacs-request@lucid.com Wed Sep 9 17:11:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25166; Wed, 9 Sep 92 17:11:45 PDT Received: by heavens-gate.lucid.com id AA06171g; Wed, 9 Sep 92 17:02:12 PDT Received: from research.nj.nec.com by heavens-gate.lucid.com id AA06152g; Wed, 9 Sep 92 16:58:57 PDT Received: by research.nj.nec.com (4.0/YDL1.8-920115.13) id AA26175(research.nj.nec.com); Wed, 9 Sep 92 20:10:06 EDT Received: by overdrive.NJ.NEC.COM (4.1/EMS1.6-920330.08) id AA08776(overdrive.NJ.NEC.COM); Wed, 9 Sep 92 20:10:06 EDT From: max@ccrl.nj.nec.com (Maximilian Ott) Received: by sun006 (4.1/CNC-Client) id AA05753; Wed, 9 Sep 92 20:09:57 EDT Date: Wed, 9 Sep 92 20:09:57 EDT Message-Id: <9209100009.AA05753@sun006> To: bug-lucid-emacs@lucid.com Subject: Two problems with 19.3 1) Missing lib file I just installed 19.3 and tried to run it "out of the box" using the provided binaries. However "emacsserver" is looking for ld.so: liblucidx.so.2: not found which I can't find anywhere. 2) Selecting files with mouse There are also some funny problems with selecting files with the mouse (a great new feature). It occurs when you have have file names selected (those things happen with three button mice. Why can't we stick with select on one and a location sensitive menu on the other. But that would make live too easy :)). I even got lemacs to core dump on one occasion: #0 0x4a14 in pixel_to_glyph_translation () at dispnew.c:1758 #1 0x15f0c in event_pixel_translation () at events.c:488 #2 0x15f80 in Fevent_window () at events.c:549 #3 0x37bf8 in Fkey_binding () at keymap.c:1383 #4 0x189b8 in command_builder_find_leaf () at event-stream.c:1114 #5 0x1905c in compose_command () at event-stream.c:1399 #6 0x18400 in dispatch_event_internal () at event-stream.c:963 #7 0x1981c in Fdispatch_event () at event-stream.c:1710 #8 0x33bbc in command_loop_1 () at keyboard.c:457 #9 0x5c548 in internal_condition_case () at eval.c:979 #10 0x33840 in command_loop_2 () at keyboard.c:384 #11 0x5bfc8 in internal_catch () at eval.c:798 #12 0x337ec in command_loop () at keyboard.c:358 #13 0x33320 in recursive_edit_1 () at keyboard.c:211 #14 0x33428 in Frecursive_edit () at keyboard.c:238 #15 0x32e04 in main () at emacs.c:420 I think I had a whole row selected in the *completion window*. I know you shouldn't do it, but ... Otherwise it looks great. (Will I ever get used to NOT use the Esc key in isearch?) max From bug-lucid-emacs-request@lucid.com Wed Sep 9 17:52:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25220; Wed, 9 Sep 92 17:52:54 PDT Received: by heavens-gate.lucid.com id AA06279g; Wed, 9 Sep 92 17:43:08 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA06266g; Wed, 9 Sep 92 17:41:11 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA28569; Wed, 9 Sep 92 17:49:34 PDT Date: Wed, 9 Sep 92 17:49:34 PDT Message-Id: <9209100049.AA28569@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: max@ccrl.nj.nec.com (Maximilian Ott) Cc: bug-lucid-emacs@lucid.com Subject: Re: Two problems with 19.3 In-Reply-To: Maximilian Ott's message of Wed 9-Sep-92 20:09:57 EDT <9209100009.AA05753@sun006> References: <9209100009.AA05753@sun006> In message <9209100009.AA05753@sun006> Maximilian Ott wrote: > > 1) Missing lib file > > I just installed 19.3 and tried to run it "out of the box" using the > provided binaries. However "emacsserver" is looking for > > ld.so: liblucidx.so.2: not found > > which I can't find anywhere. Sorry about that. I should have known better than to ever compile anything without saying "please link statically so that I don't lose horribly if someone sneezes." I compiled with Lucid C, and it's trying to dynamically link against its runtime library, which exists because Sun's libraries are buggy. I'll make a new set of static binaries this evening. (This should only be a problem for the things in the etc directory, not emacs itself, and those are easy to compile, so you might want to just do that instead of re-FTPing the whole package.) > I even got lemacs to core dump on one occasion: > > #0 0x4a14 in pixel_to_glyph_translation () at dispnew.c:1758 Aaah, redisplay. Bane of the modern world. The binaries I distributed were compiled with optimization, so I can't really do much unless you can come up with a script to reproduce this, or recompile your emacs with debug info and have it happen again. It's related to the position of the mouse, the position of the extents, and timing is probably a factor as well. -- Jamie From bug-lucid-emacs-request@lucid.com Wed Sep 9 21:38:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25602; Wed, 9 Sep 92 21:38:02 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA06714g; Wed, 9 Sep 92 21:24:54 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29057; Thu, 10 Sep 92 00:36:10 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA29053; Thu, 10 Sep 92 00:36:08 -0400 Control: cancel <1992Sep10.041124.19301@bmerh85.bnr.ca> Newsgroups: alt.lucid-emacs.bug Path: uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: cancel <1992Sep10.041124.19301@bmerh85.bnr.ca> Message-Id: <1992Sep10.041217.19357@bmerh85.bnr.ca> Organization: Bell Northern Research Date: Thu, 10 Sep 92 04:12:17 GMT Lines: 0 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com From bug-lucid-emacs-request@lucid.com Wed Sep 9 21:38:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA25603; Wed, 9 Sep 92 21:38:03 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA06715g; Wed, 9 Sep 92 21:24:58 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29065; Thu, 10 Sep 92 00:36:14 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA29061; Thu, 10 Sep 92 00:36:12 -0400 Path: uunet!dtix!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Newsgroups: alt.lucid-emacs.bug Subject: Why does lemacs (currently) care about your terminal type (TERM) Message-Id: <1992Sep10.041315.19413@bmerh85.bnr.ca> Date: 10 Sep 92 04:13:15 GMT Organization: Bell Northern Research Lines: 26 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com This is with Lucid Emacs 19.3. If I startup lemacs from an xterm, it starts up fine. If I start it up from an emacs shell buffer, I get: emacs: Terminal type emacs is not defined. This is under HPUX 7.05 on an HP9000/425. This machine fakes termcap with terminfo, I think, so it doesn't use the fake "TERMCAP=emacs..." that emacs puts into the environment. Since lemacs is using the X-windows interface, it shouldn't care *what* value TERM has. If I unset TERM, It starts up fine. i.e. the code in term_init which does: if (egetenv ("DISPLAY") && !inhibit_window_system) return; could probably be moved a lot nearer the beginning of term_init, no? I've tried moving it to just before the call to "tgetent" in term_init, and it seems to work so far. From bug-lucid-emacs-request@lucid.com Thu Sep 10 03:34:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA26427; Thu, 10 Sep 92 03:34:08 PDT Received: by heavens-gate.lucid.com id AA07357g; Thu, 10 Sep 92 03:21:31 PDT Received: from jclark.com by heavens-gate.lucid.com id AA07353g; Thu, 10 Sep 92 03:21:15 PDT Received: by jclark.com (4.1/SMI-4.1) id AA04264; Thu, 10 Sep 92 11:31:37 BST Date: Thu, 10 Sep 92 11:31:37 BST From: jjc@jclark.com (James Clark) Message-Id: <9209101031.AA04264@jclark.com> To: bug-lucid-emacs@lucid.com Subject: 19.3 find-default-load-path-internal lemacs 19.3 wasn't able to find either the doc file or the emacsserver program on my system. I didn't have this problem with 19.2. I have lemacs in /local/bin; this is a symlink to /local/lemacs-19.3/src/emacs-19.3.1-Lucid. There's also a directory /local/etc. The problem was that (find-default-load-path-internal "etc") returned /local/etc rather than /local/lemacs-19.3/etc. I fixed it like this: *** lisp/prim/startup.el.~1~ Sun Aug 30 03:36:02 1992 --- lisp/prim/startup.el Thu Sep 10 10:42:47 1992 *************** *** 542,548 **** ;; If in .../src/ or ../bin/, look for subdirs of this directory's ;; parent. ;; ! ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\|bin\\)/$" invocation-directory) (file-directory-p (setq tmp (concat (substring invocation-directory 0 --- 542,548 ---- ;; If in .../src/ or ../bin/, look for subdirs of this directory's ;; parent. ;; ! ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\)/$" invocation-directory) (file-directory-p (setq tmp (concat (substring invocation-directory 0 James Clark jjc@jclark.com From bug-lucid-emacs-request@lucid.com Thu Sep 10 07:39:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27785; Thu, 10 Sep 92 07:39:54 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA07737g; Thu, 10 Sep 92 07:27:30 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15561; Thu, 10 Sep 92 10:38:44 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15557; Thu, 10 Sep 92 10:38:42 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bcars6a8!bcars6a8!jsparkes From: jsparkes%bnr.ca@lucid.com (Jeff Sparkes) Subject: Re: Lucid Emacs 19.3 released In-Reply-To: jwz@lucid.com's message of Wed, 9 Sep 1992 13:37:49 PDT Message-Id: Nntp-Posting-Host: bcars68a Organization: Bell-Northern Research, Ottawa References: <9209092037.AA27376@thalidomide.lucid> Date: Thu, 10 Sep 1992 15:25:17 GMT Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com jwz>I haven't made diffs, because they would be really huge, and I still don't jwz>know a truly painless way to make diffs of an emacs source tree. Have you tried gnu diff and "diff -rcN"? The -N flags does a diff of new files as if a zero size old one existed, and patches just fine. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Thu Sep 10 09:57:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00181; Thu, 10 Sep 92 09:57:00 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08031g; Thu, 10 Sep 92 09:42:04 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA23997; Thu, 10 Sep 92 12:53:20 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA23993; Thu, 10 Sep 92 12:53:19 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!eco.twg.com!skip From: skip@eco.twg.com (Skip Koppenhaver) Subject: 19.3 coredump Message-Id: <1992Sep10.165332.13297@eco.twg.com> Keywords: coredump Nntp-Posting-Host: eco.twg.com Organization: The Wollongong Group (East Coast Operations) Date: Thu, 10 Sep 92 16:53:32 GMT Lines: 29 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Environment: ============ SunOs 4.1.1 X11R5, patchlevel 17 xemacs built locally using GCC 2.2.2 Description: ============ If xemacs is started without both the TERM and DISPLAY environment variables set it immediately coredumps. I discovered this when trying to run it remotely. For example, all the following will coredump: rsh -n xemacs -display :0.0 rsh -n 'setenv DISPLAY :0.0; xemacs' rsh -n 'setenv TERM xterm; xemacs -display :0.0' However, the following will work: rsh -n 'setenv TERM xterm; setenv DISPLAY :0.0; xemacs' If you start it with just DISPLAY set, it complains about TERM not being set and then coredumps. In an X environment why is TERM needed at all? -- Skip Koppenhaver skip@eco.twg.com From bug-lucid-emacs-request@lucid.com Thu Sep 10 12:03:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00584; Thu, 10 Sep 92 12:03:33 PDT Received: by heavens-gate.lucid.com id AA08465g; Thu, 10 Sep 92 11:51:26 PDT Received: from research.nj.nec.com by heavens-gate.lucid.com id AA08455g; Thu, 10 Sep 92 11:48:44 PDT Received: by research.nj.nec.com (4.0/YDL1.8-920115.13) id AA06008(research.nj.nec.com); Thu, 10 Sep 92 14:59:52 EDT Received: by overdrive.NJ.NEC.COM (4.1/EMS1.6-920330.08) id AA00695(overdrive.NJ.NEC.COM); Thu, 10 Sep 92 14:59:53 EDT From: max@ccrl.nj.nec.com (Maximilian Ott) Received: by sun006 (4.1/CNC-Client) id AA06023; Thu, 10 Sep 92 14:59:44 EDT Date: Thu, 10 Sep 92 14:59:44 EDT Message-Id: <9209101859.AA06023@sun006> To: bug-lucid-emacs@lucid.com Subject: 19.3: Info-directory-list and .../etc path I experience the problem that lemacs 19.3 doesn't set the Info-directory-list variable correctly. My ../bin/lemacs is a symbolic link to the binary in .../lemacs-19.3/src/lemacs. The load-path is set correctly. An most likely associated problem is that it can't find "emacsserver" in ../etc (Regarding my mail of yesterday, thanks Jamie. I should have thought about recompiling it myself.) Has anyone tried out "font-lock"? Should the colors (faces) change while I type. This was my understanding, but I only see them right after I save the file. (Besides, how do I change the colors - does this tell you that I've no idea?) max From bug-lucid-emacs-request@lucid.com Thu Sep 10 18:24:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01548; Thu, 10 Sep 92 18:24:13 PDT Received: by heavens-gate.lucid.com id AA09609g; Thu, 10 Sep 92 18:10:08 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA09599g; Thu, 10 Sep 92 18:07:45 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02285; Thu, 10 Sep 92 18:17:40 PDT Date: Thu, 10 Sep 92 18:17:40 PDT Message-Id: <9209110117.AA02285@thalidomide.lucid> X-Windows: Sometimes you fill a vacuum and it still sucks. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: jsparkes%bnr.ca@lucid.com (Jeff Sparkes) Cc: bug-lucid-emacs@lucid.com Subject: Re: Lucid Emacs 19.3 released Newsgroups: alt.lucid-emacs.bug In-Reply-To: Jeff Sparkes's message of Thu 10-Sep-92 15:25:17 GMT References: <9209092037.AA27376@thalidomide.lucid> In message Jeff Sparkes wrote: > > jwz> I haven't made diffs, because they would be really huge, and I still > jwz> don't know a truly painless way to make diffs of an emacs source tree. > > Have you tried gnu diff and "diff -rcN"? The -N flags does a diff of > new files as if a zero size old one existed, and patches just fine. But I'll bet it doesn't know to not bother diffing .elc files, and doesn't emit code to delete files that no longer exist. Sure, I could do some sed hacking to accomplish this, but frankly I'd rather eat lint... If someone makes 19.2->19.3 diffs, I'll be happy to distribute them. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Sep 10 19:58:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01752; Thu, 10 Sep 92 19:58:17 PDT Received: by heavens-gate.lucid.com id AA09855g; Thu, 10 Sep 92 19:44:29 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA09844g; Thu, 10 Sep 92 19:40:54 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA02559; Thu, 10 Sep 92 19:50:49 PDT Date: Thu, 10 Sep 92 19:50:49 PDT Message-Id: <9209110250.AA02559@thalidomide.lucid> X-Windows: Flakey and built to stay that way. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: max@ccrl.nj.nec.com (Maximilian Ott) Cc: bug-lucid-emacs@lucid.com Subject: Re: 19.3: Info-directory-list and .../etc path In-Reply-To: Maximilian Ott's message of Thu 10-Sep-92 14:59:44 EDT <9209101859.AA06023@sun006> References: <9209101859.AA06023@sun006> In message <9209101859.AA06023@sun006> Maximilian Ott wrote: > > I experience the problem that lemacs 19.3 doesn't set the > Info-directory-list variable correctly. My ../bin/lemacs is a symbolic > link to the binary in .../lemacs-19.3/src/lemacs. The load-path > is set correctly. Sigh... The heuristics that emacs is using to find the etc and lisp directories seems to have gotten worse, primarily as a result of the fact that it now starts at the name of the emacs program that was run (even if that was a symbolic link) instead of at the `truename' of the emacs executable. If you make symlinks to the etc and lisp dirs in the same directory in which your "frontmost" emacs executable resides, things should work. (I realize that some of you don't want to do this.) > Has anyone tried out "font-lock"? Should the colors (faces) change > while I type. This was my understanding, but I only see them right > after I save the file. Odd; it works for me with the 19.3 started with -q. I visited a new file (foo.el) did M-x font-lock-mode, and typed ; testing (defun foo () The word "testing" was in italic and the word "foo" was in bold-italic. > (Besides, how do I change the colors - does this tell you that I've no > idea?) `C-h a face' -- Jamie From bug-lucid-emacs-request@lucid.com Thu Sep 10 22:51:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02125; Thu, 10 Sep 92 22:51:59 PDT Received: by heavens-gate.lucid.com id AA10135g; Thu, 10 Sep 92 22:35:33 PDT Received: from ntu.ac.sg by heavens-gate.lucid.com id AA10127g; Thu, 10 Sep 92 22:33:09 PDT Received: by ntu.ac.sg (5.57/Ultrix3.0-C) id AA09867; Fri, 11 Sep 92 13:43:52 +0800 Message-Id: <9209110543.AA09867@ntu.ac.sg> Sender: franks%ntu.ac.sg@lucid.com Date: Fri, 11 Sep 1992 13:44:56 +0730 To: bug-lucid-emacs@lucid.com From: franks%ntu.ac.sg@lucid.com (Frank Siebenlist) Subject: mouse completion of "dot"-files The new mouse completion is really nice! There is only a problem with "."-files, just try to complete with ~/. and you will see that the files are not or wrongly recognized. From bug-lucid-emacs-request@lucid.com Fri Sep 11 05:21:11 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03682; Fri, 11 Sep 92 05:21:11 PDT Received: by heavens-gate.lucid.com id AA10745g; Fri, 11 Sep 92 05:06:34 PDT Received: from plg.uwaterloo.ca by heavens-gate.lucid.com id AA10734g; Fri, 11 Sep 92 05:05:18 PDT Received: by plg.uwaterloo.ca id <28714>; Fri, 11 Sep 1992 08:16:31 -0400 From: Dave Mason To: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com Subject: Simple optimization for blink-paren Message-Id: <92Sep11.081631edt.28714@plg.uwaterloo.ca> Date: Fri, 11 Sep 1992 08:16:30 -0400 Every day I uncover more nifty things! blink-paren is pretty neat, but it is a real network hog, so I thought of highlighting the paren rather than having it constantly change, so I tried setting the -on and -off fonts the same: Emacs*default.attributeFont: -*-courier-medium-r-*-*-20-*-*-*-*-*-*-* Emacs*blink-paren-off.attributeFont: -*-courier-medium-r-*-*-20-*-*-*-*-*-*-* Emacs*blink-paren-off.attributeBackgroundPixmap: gray3 Emacs*blink-paren-on.attributeFont: -*-courier-medium-r-*-*-20-*-*-*-*-*-*-* Emacs*blink-paren-on.attributeBackgroundPixmap: gray3 However the set-extent-face code doesn't check to see if the new face is the same as the old face, and you get all the extra timer interrupts anyway, so I made blink-paren-post-command do the check. Here is the diff: *** /usr/local/src/lemacs/lemacs-19.3/lisp/packages/blink-paren.el Fri Sep 4 05:42:38 1992 --- Emacs/blink-paren.el Thu Sep 10 19:07:57 1992 *************** *** 79,84 **** --- 79,88 ---- (defun blink-paren-post-command () (blink-paren-pre-command) (if (and (setq blink-paren-extent (blink-paren-make-extent)) + (not (and (face-equal 'blink-paren-on 'blink-paren-off) + (progn + (set-extent-face blink-paren-extent 'blink-paren-on) + t))) (or (floatp blink-paren-timeout) (integerp blink-paren-timeout))) (setq blink-paren-timeout-id This might be worth putting in the distribution with a comment about the amount of network activity that plain blink-paren produces. A couple of other useful font changes that I've found: This works well for isearch, even when using hilite, etc.: Emacs*isearch.attributeForeground: black Emacs*isearch.attributeBackground: white Emacs*highlight.attributeBackgroundPixmap: dimple3 This makes for quieter modelines: Emacs*modeline.attributeForeground: white Emacs*modeline.attributeBackground: black Emacs*modeline.attributeBackgroundPixmap: dimple3 ../Dave From bug-lucid-emacs-request@lucid.com Fri Sep 11 08:21:51 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04259; Fri, 11 Sep 92 08:21:51 PDT Received: by heavens-gate.lucid.com id AA11093g; Fri, 11 Sep 92 08:06:20 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA11088g; Fri, 11 Sep 92 08:06:00 PDT Received: by liasg2.epfl.ch (Smail3.1.26.7 #2) id m0mTCkG-000HMnC; Fri, 11 Sep 92 17:17 MDT Message-Id: Date: Fri, 11 Sep 92 17:17 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Loss of functionality in 19.3 isearch Newsgroups: alt.lucid-emacs.bug The new isearch-mode doesn't use Lemacs' audio capabilities as the old isearch did. Here's a patch (in Unidiff format). -- Simon. RCS file: /usr/tmp/lemacs-19.3/lisp/prim/RCS/isearch-mode.el,v retrieving revision 1.1 diff -w -u -r1.1 /usr/tmp/lemacs-19.3/lisp/prim/isearch-mode.el --- 1.1 1992/09/11 15:08:10 +++ /usr/tmp/lemacs-19.3/lisp/prim/isearch-mode.el 1992/09/11 15:14:59 @@ -753,7 +753,7 @@ If no previous match was done, just beep." (interactive) (if (null (cdr isearch-cmds)) - (ding) + (ding nil 'isearch-quit) (isearch-pop-state)) (isearch-update)) @@ -1269,7 +1269,7 @@ nil ;; Ding if failed this time after succeeding last time. (and (nth 3 (car isearch-cmds)) - (ding)) + (ding nil 'isearch-failed)) (goto-char (nth 2 (car isearch-cmds))))) ;;;================================================= From bug-lucid-emacs-request@lucid.com Fri Sep 11 09:44:39 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04472; Fri, 11 Sep 92 09:44:39 PDT Received: by heavens-gate.lucid.com id AA11315g; Fri, 11 Sep 92 09:27:17 PDT Received: from scylla.lucid (scylla.lucid.com) by heavens-gate.lucid.com id AA11299g; Fri, 11 Sep 92 09:23:19 PDT Received: by scylla.lucid (4.1/SMI-4.1) id AA18463; Fri, 11 Sep 92 08:41:28 PDT Date: Fri, 11 Sep 92 08:41:28 PDT From: devin%scylla@lucid.com (Matthieu Devin) Message-Id: <9209111541.AA18463@scylla.lucid> To: Dave Mason Cc: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com Subject: Re: Simple optimization for blink-paren In-Reply-To: Dave Mason's message of Fri 11-Sep-19 08:16:30 -0400 <92Sep11.081631edt.28714@plg.uwaterloo.ca> References: <92Sep11.081631edt.28714@plg.uwaterloo.ca> In message <92Sep11.081631edt.28714@plg.uwaterloo.ca> Dave Mason wrote: > blink-paren is pretty neat, but it is a real network hog, so I > thought of highlighting the paren rather than having it constantly > change, so I tried setting the -on and -off fonts the same: If you just want to highlight (and not blink) you can get rid of the timeout. It would put a much lower load on the system running your emacs. From bug-lucid-emacs-request@lucid.com Fri Sep 11 09:44:44 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04476; Fri, 11 Sep 92 09:44:44 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11317g; Fri, 11 Sep 92 09:27:23 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25110; Fri, 11 Sep 92 12:42:22 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25105; Fri, 11 Sep 92 12:42:12 -0400 Path: uunet!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Newsgroups: alt.lucid-emacs.bug Subject: Sun compile configuration bugs (minor stuff) Message-Id: <1992Sep11.161507.12782@daimi.aau.dk> Date: 11 Sep 92 16:15:07 GMT Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Lines: 25 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I thought I would pass the following small stuff along to the rest of the community The following applies using gcc 2 In order to compile on a sparc, I needed to set `-fno-builtin -traditional' and -D"const= " since const declarations don't mix well with -traditional. Many other ways of fixing this is definitely possible. Also I needed to change -fsoft into -msoft-float in m-sun3.h (C_SWITCH_MACHINE) ------------------------------------------------------------------------------ Christian Lynbech DAIMI office: R0.32 phone: 5034 University of Aarhus,DK-Denmark email: lynbech@daimi.aau.dk ------------------------------------------------------------------------------ EMACS, The One True Editor Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From bug-lucid-emacs-request@lucid.com Fri Sep 11 10:44:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04706; Fri, 11 Sep 92 10:44:02 PDT Received: by heavens-gate.lucid.com id AA11538g; Fri, 11 Sep 92 10:30:39 PDT Received: from plg.uwaterloo.ca by heavens-gate.lucid.com id AA11491g; Fri, 11 Sep 92 10:19:28 PDT Received: by plg.uwaterloo.ca id <28714>; Fri, 11 Sep 1992 13:32:38 -0400 From: Dave Mason To: devin%scylla@lucid.com Cc: bug-lucid-emacs@lucid.com, help-lucid-emacs@lucid.com In-Reply-To: Matthieu Devin's message of Fri, 11 Sep 1992 11:41:28 -0400 <9209111541.AA18463@scylla.lucid> Subject: RE: Simple optimization for blink-paren Message-Id: <92Sep11.133238edt.28714@plg.uwaterloo.ca> Date: Fri, 11 Sep 1992 13:32:31 -0400 > From: devin%scylla@lucid.com (Matthieu Devin) > In message <92Sep11.081631edt.28714@plg.uwaterloo.ca> Dave Mason wrote: > > blink-paren is pretty neat, but it is a real network hog, so I > > thought of highlighting the paren rather than having it constantly > > change, so I tried setting the -on and -off fonts the same: > > If you just want to highlight (and not blink) you can get rid of the timeout. > It would put a much lower load on the system running your emacs. Unless I've done something stupid, the code I sent already does that (the ``and'' terminates with a nil value if the two faces are equal). ../Dave From bug-lucid-emacs-request@lucid.com Fri Sep 11 11:22:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04830; Fri, 11 Sep 92 11:22:00 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11699g; Fri, 11 Sep 92 11:09:53 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00444; Fri, 11 Sep 92 14:21:11 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00440; Fri, 11 Sep 92 14:21:09 -0400 Path: uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!olivea!tymix!gabriela!steve From: steve@gabriela.tymnet.com (Steve Sandke) Newsgroups: alt.lucid-emacs.bug Subject: Bug in lhilit Message-Id: <2476@tymix.Tymnet.COM> Date: 11 Sep 92 18:14:42 GMT Organization: BT North America, San Jose, CA Lines: 28 Nntp-Posting-Host: gabriela Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Want to send Lemacs into contortions? Load lihilit, put this code into a buffer in c-mode, then [try to] save it. *************** /* This is a test case */ int main() { } /* This unterminated comment really messes things up... int fn1() { } *************** Apparently, the highlighting code goes into a really tight loop trying to find the other end of the comment. If you hit control-G, you at least get your prompt back, but emacs keeps running at full speed, taking up most of the CPU. I'm not an elisp expert at all, so I have no idea how to fix this. -- ------------------- Steve Sandke steve@orchid.tymnet.com From bug-lucid-emacs-request@lucid.com Fri Sep 11 11:27:52 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04841; Fri, 11 Sep 92 11:27:52 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11717g; Fri, 11 Sep 92 11:15:40 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00820; Fri, 11 Sep 92 14:26:58 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00816; Fri, 11 Sep 92 14:26:52 -0400 Path: uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!cis.ksu.edu!frain From: frain@cis.ksu.edu (Jerry Frain) Newsgroups: alt.lucid-emacs.bug Subject: isearch-mode missing defconsts Date: 11 Sep 92 16:47:39 GMT Organization: Kansas State University Lines: 52 Message-Id: Nntp-Posting-Host: depot.cis.ksu.edu Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com When installing v19.3, I decided to recompile all of the distribution elisp files, because there was a bug with vm (something about byte-code). Anyway, I discovered when using vm's incremental search, that some lisp constants were missing, notably "search-exit-char". Looking through the distribution lisp source, "search-exit-char" was not defined anywhere, nor is it defined when I do a "describe-variable". v19.2 had "search-exit-char" in prim/loaddefs.el, but v19.3 loaddefs.el had a comment explaining that the isearch-mode defvars had been moved back to isearch-mode.el. When I looked at isearch-mode.el, there was a whole section of defconsts missing that used to be in v19.2 loaddefs.el, which I cannot find in any other v19.3 lisp file. To make a long story short, here's a patch to add the missing defconsts to isearch-mode.el. *** isearch-mode.el.~1~ Wed Sep 9 01:25:48 1992 --- isearch-mode.el Fri Sep 11 11:23:31 1992 *************** *** 113,118 **** --- 113,137 ---- This does not include direct calls to the primitive search functions, and does not include searches that are aborted.") + (defconst search-repeat-char ?\C-s "\ + *Character to repeat incremental search forwards.") + (defconst search-reverse-char ?\C-r "\ + *Character to repeat incremental search backwards.") + (defconst search-exit-char ?\e "\ + *Character to exit incremental search.") + (defconst search-delete-char ?\177 "\ + *Character to delete from incremental search string.") + (defconst search-quote-char ?\C-q "\ + *Character to quote special characters for incremental search.") + (defconst search-yank-word-char ?\C-w "\ + *Character to pull next word from buffer into search string.") + (defconst search-yank-line-char ?\C-y "\ + *Character to pull rest of line from buffer into search string.") + (defconst search-ring-advance-char ?\M-n "\ + *Character to pull next (more recent) search string from the ring of same.") + (defconst search-ring-retreat-char ?\M-p "\ + *Character to pull previous (older) search string from the ring of same.") + (defconst search-exit-option t "Non-nil means random control characters terminate incremental search.") ------------------------------------------------------------------------------ Jerry Frain, Systems Programmer | "Back off man, I'm a scientist." Kansas State University | frain@cis.ksu.edu Department of Computer & Info Sciences | ...!rutgers!depot!frain From bug-lucid-emacs-request@lucid.com Fri Sep 11 11:39:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04858; Fri, 11 Sep 92 11:39:03 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11739g; Fri, 11 Sep 92 11:26:53 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA01681; Fri, 11 Sep 92 14:38:10 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA01676; Fri, 11 Sep 92 14:38:09 -0400 Path: uunet!spool.mu.edu!wupost!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!cis.ksu.edu!frain From: frain@cis.ksu.edu (Jerry Frain) Newsgroups: alt.lucid-emacs.bug Subject: patch for vm Makefile Date: 11 Sep 1992 18:37:29 GMT Organization: Kansas State University, Dept. of Computing and Information Sciences Lines: 51 Distribution: world Message-Id: Nntp-Posting-Host: depot.cis.ksu.edu Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com With the addition of vm-lucid.el in the lisp/vm directory, it doesn't look like the Makefile was modified correctly to compile vm from scratch. The vm-lucid.el looks like it is to be loaded separate from vm.el, which is obvious due to the "(require 'vm)" at the top of vm-lucid.el. However, vm-lucid.elc was added to the list of BINS in the Makefile to be cat'd together to make vm.elc. So, vm-lucid.el doesn't byte-compile because vm.elc hasn't been made yet. Here's my patch to the vm Makefile, to make a vm-lucid.elc separate from (and following) vm.elc: *** Makefile.~1~ Mon Aug 3 03:04:56 1992 --- Makefile Thu Sep 10 20:49:47 1992 *************** *** 6,15 **** BINS= vm-delete.elc vm-digest.elc vm-edit.elc vm-folder.elc vm-group.elc \ vm-license.elc vm-mark.elc vm-message.elc vm-misc.elc vm-motion.elc \ vm-page.elc vm-reply.elc vm-save.elc vm-search.elc vm-summary.elc \ ! vm-undo.elc vm-vars.elc vm-version.elc vm-virtual.elc vm-window.elc \ ! vm-lucid.elc ! VM: vm.elc .el.elc: $(EMACS) -batch -q -l ./vm-message.el -l ./vm-misc.el -f batch-byte-compile $(@:.elc=.el) --- 6,14 ---- BINS= vm-delete.elc vm-digest.elc vm-edit.elc vm-folder.elc vm-group.elc \ vm-license.elc vm-mark.elc vm-message.elc vm-misc.elc vm-motion.elc \ vm-page.elc vm-reply.elc vm-save.elc vm-search.elc vm-summary.elc \ ! vm-undo.elc vm-vars.elc vm-version.elc vm-virtual.elc vm-window.elc ! VM: vm.elc vm-lucid.elc .el.elc: $(EMACS) -batch -q -l ./vm-message.el -l ./vm-misc.el -f batch-byte-compile $(@:.elc=.el) *************** *** 16,21 **** --- 15,23 ---- vm.elc: $(BINS) cat $(BINS) > $@ + + vm-lucid.elc: vm-lucid.el + $(EMACS) -batch -q -f batch-byte-compile vm-lucid.el vm: vm.texinfo $(EMACS) -batch -q vm.texinfo -f texinfo-format-buffer -f save-buffer From bug-lucid-emacs-request@lucid.com Fri Sep 11 13:31:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05188; Fri, 11 Sep 92 13:31:45 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA12049g; Fri, 11 Sep 92 13:19:45 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA10042; Fri, 11 Sep 92 16:30:54 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA10036; Fri, 11 Sep 92 16:30:40 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!fstop.csc.ti.com!fstop.csc.ti.com!kenb From: kenb@dadd.ti.com (Ken Butler) Subject: Re: mouse completion of "dot"-files In-Reply-To: franks%ntu.ac.sg@lucid.com's message of Fri, 11 Sep 1992 13:44:56 +0730 Message-Id: Nntp-Posting-Host: bigears.dadd.ti.com Organization: Texas Instruments, Inc., Dallas, TX References: <9209110543.AA09867@ntu.ac.sg> Date: Fri, 11 Sep 1992 21:03:15 GMT Lines: 18 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I agree that the mouse completion is nice. The only thing I'd like to see would be a mouse button bound so that if the "file" is another directory, that directory name would be appended to the current directory name in the minibuffer, and the new set of completions generated. Is that already possible? If so, I can't figure out how to do it. Thanks. Ken -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Kenneth M. Butler (214) 997-6370 (office) Texas Instruments (214) 997-2049 (FAX) P.O. Box 655303 MS 3683 kenb@dadd.ti.com Dallas, TX 75265 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* From bug-lucid-emacs-request@lucid.com Fri Sep 11 13:44:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05256; Fri, 11 Sep 92 13:44:28 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA12089g; Fri, 11 Sep 92 13:32:32 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA10896; Fri, 11 Sep 92 16:43:40 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA10892; Fri, 11 Sep 92 16:43:33 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Re: isearch-mode missing defconsts In-Reply-To: frain@cis.ksu.edu's message of 11 Sep 92 16:47:39 GMT Message-Id: <1992Sep11.201200.25490@bmerh85.bnr.ca> Lines: 30 Organization: Bell Northern Research References: Date: Fri, 11 Sep 92 20:12:00 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On 11 Sep 92 16:47:39 GMT, >>>>> frain@cis.ksu.edu (Jerry Frain) wrote: Jerry> When installing v19.3, I decided to recompile all of the Jerry> distribution elisp files, because there was a bug with vm Jerry> (something about byte-code). Jerry> Anyway, I discovered when using vm's incremental search, that Jerry> some lisp constants were missing, notably "search-exit-char". Jerry> Looking through the distribution lisp source, Jerry> "search-exit-char" was not defined anywhere, nor is it defined Jerry> when I do a "describe-variable". Jerry> v19.2 had "search-exit-char" in prim/loaddefs.el, but v19.3 Jerry> loaddefs.el had a comment explaining that the isearch-mode Jerry> defvars had been moved back to isearch-mode.el. When I looked Jerry> at isearch-mode.el, there was a whole section of defconsts Jerry> missing that used to be in v19.2 loaddefs.el, which I cannot Jerry> find in any other v19.3 lisp file. Jerry> To make a long story short, here's a patch to add the missing Jerry> defconsts to isearch-mode.el. Um, it's all very well to add these constants back in, but they aren't *used* anywhere. The isearch mode in 19.3 is a new one, written by Daniel LaLiberte. In this, isearch is a minor mode, so If you want to change the characters, you change the isearch-mode-map. Check lisp/prim/isearch-mode.el for details. From bug-lucid-emacs-request@lucid.com Fri Sep 11 20:57:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06262; Fri, 11 Sep 92 20:57:45 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA13076g; Fri, 11 Sep 92 20:42:52 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA23254; Fri, 11 Sep 92 23:54:11 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA23250; Fri, 11 Sep 92 23:54:10 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cs.utexas.edu!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: How to crash Lucid emacs 19.3 Message-Id: <1992Sep12.031637.29477@bmerh85.bnr.ca> Lines: 61 Organization: Bell Northern Research Date: Sat, 12 Sep 92 03:16:37 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com This came up while using ange-ftp to copy some files. In the *scratch* buffer, enter the following: (progn (message "%%") (garbage-collect)) Then execute it. emacs should get a fatal error (6). This is due to an abort deep down in the bowels of emacs. The cause is that at some point during the execution of this code, garbage collection takes place. In Fgarbage_collect, there is some code that looks like this: if (!noninteractive) { #ifdef HAVE_X_WINDOWS extern int x_show_normal_cursor (struct screen* s); if (!x_show_normal_cursor (s)) #endif { if (omessage) message (omessage); else message ("Garbage collecting...done"); } } gc_in_progress = 0; omessage has been set to the value of the variable "echo_area_glyphs", which appears to contain the string the echo area was displaying. I guess the intent is to redisplay the string which was being displayed when garbage collecting started. If the message the echo area was displaying ended in %, then a string ending in % is passed to message(). doprnt (called by message) dislikes being given a format indication (%) followed by a null. It signals an error (using Fsignal). Unfortunately, Fsignal calls abort if it is called during garbage collection. Fgarbage_collect needs to be fixed to process the "echo_area_glyph" string so that '%' is converted to '%%' before it passes it to message. Also, it seems that the "gc_in_process = 0;" line could be moved above the message call. This would allow Fsignal to signal without aborting. At this point garbage collection (the meat of it) is effectively over. Comments? Hamish. From bug-lucid-emacs-request@lucid.com Sat Sep 12 16:07:15 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08726; Sat, 12 Sep 92 16:07:15 PDT Received: by heavens-gate.lucid.com id AA14173g; Sat, 12 Sep 92 15:51:58 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA14169g; Sat, 12 Sep 92 15:51:48 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20182; Sat, 12 Sep 92 19:03:10 -0400 Received: from synaptx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 190248.18872; Sat, 12 Sep 1992 19:02:48 EDT Received: from thymus.synaptics by synaptx.synaptics.com (4.1/SMI-4.1) id AA11469; Sat, 12 Sep 92 15:32:26 PDT Received: by thymus.synaptics (4.1/SMI-4.1) id AA19296; Sat, 12 Sep 92 15:39:17 PDT Message-Id: <9209122239.AA19296@thymus.synaptics> To: bug-lucid-emacs@lucid.com Subject: Re: How to crash Lucid emacs 19.3 In-Reply-To: Your message of "Sat, 12 Sep 92 03:16:37 GMT." <1992Sep12.031637.29477@bmerh85.bnr.ca> Reply-To: daveg@synaptics.com Date: Sat, 12 Sep 92 15:39:16 -0700 From: Dave Gillespie Hamish Macdonald writes: > Fgarbage_collect needs to be fixed to process the "echo_area_glyph" > string so that '%' is converted to '%%' before it passes it to > message. The solution is much simpler. Write message ("%s", omessage); instead of message (omessage); This bug does not occur in Emacs 18, since Fgarbage_collect there calls message1 instead (which takes its string argument without any printf processing). The message1 function seems to have been dropped from Lucid Emacs. Are there any other places where message was incorrectly substituted for message1? (BTW, Lisp hackers beware: The same bug can exist in Lisp. If you have a variable string STR, it is always better to write (message "%s" STR) than (message STR), because you never know when a string might contain a percent-sign.) -- Dave From bug-lucid-emacs-request@lucid.com Sun Sep 13 13:17:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10962; Sun, 13 Sep 92 13:17:58 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA15107g; Sun, 13 Sep 92 12:56:12 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04350; Sun, 13 Sep 92 16:07:36 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA04346; Sun, 13 Sep 92 16:07:34 -0400 Path: uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!cis.ksu.edu!frain From: frain@cis.ksu.edu (Jerry Frain) Newsgroups: alt.lucid-emacs.bug Subject: Re: isearch-mode missing defconsts Date: 13 Sep 92 19:58:08 GMT Organization: Kansas State University Lines: 29 Message-Id: References: <1992Sep11.201200.25490@bmerh85.bnr.ca> Nntp-Posting-Host: draconis.cis.ksu.edu Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald) writes: > >>>>> On 11 Sep 92 16:47:39 GMT, > >>>>> frain@cis.ksu.edu (Jerry Frain) wrote: > Jerry> To make a long story short, here's a patch to add the missing > Jerry> defconsts to isearch-mode.el. > Um, it's all very well to add these constants back in, but they aren't > *used* anywhere. Evidently they *are* used somewhere, or vm (the version distributed with Lucid 19.3) would not have barfed on the incremental search (i.e. vm-isearch-forward), complaining that search-exit-char was not defined. Granted, now that I understand the problem, it is not directly a problem with Lucid Emacs, but due to vm not yet being updated to use the new isearch-mode. > The isearch mode in 19.3 is a new one, written by Daniel LaLiberte. > In this, isearch is a minor mode, so If you want to change the > characters, you change the isearch-mode-map. Check > lisp/prim/isearch-mode.el for details. Vm uses the search-exit-char variable explicitly (disbelievers may check the vm-search.el file), changing isearch-mode-map won't help in this instance. --Jerry Frain, frain@cis.ksu.edu From bug-lucid-emacs-request@lucid.com Sun Sep 13 20:19:18 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11572; Sun, 13 Sep 92 20:19:18 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA15426g; Sun, 13 Sep 92 20:04:06 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA11251; Sun, 13 Sep 92 23:15:30 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA11247; Sun, 13 Sep 92 23:15:28 -0400 Path: uunet!munnari.oz.au!uniwa!toivo From: toivo%ucs.uwa.OZ.AU@lucid.com (Toivo Pedaste) Newsgroups: alt.lucid-emacs.bug Subject: Lucid Emacs 19.3 and Ultrix Date: 14 Sep 1992 03:07:50 GMT Organization: The University of Westrn Australia Lines: 9 Message-Id: <190vm6INNkio@uniwa.uwa.edu.au> Nntp-Posting-Host: sage.ucs.uwa.edu.au Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Trying out 19.3 I found that while to problem with async processes (eg the emacs-client stuff) has been fixed, pasting in a X windows selection still hangs it. Is this the general experience or have I done something wrong with my compilation. -- ------------------------------------------------------------------ Toivo Pedaste Email: toivo@ucs.uwa.edu.au University Computing Services, Phone: +61 9 380 2605 University of Western Australia Fax: +61 9 380 1014 From bug-lucid-emacs-request@lucid.com Mon Sep 14 00:27:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12038; Mon, 14 Sep 92 00:27:00 PDT Received: by heavens-gate.lucid.com id AA15618g; Mon, 14 Sep 92 00:11:53 PDT Received: from pat.uio.no by heavens-gate.lucid.com id AA15614g; Mon, 14 Sep 92 00:11:43 PDT Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <18839-0@pat.uio.no>; Mon, 14 Sep 1992 09:22:50 +0200 Received: by durin.uio.no ; Mon, 14 Sep 1992 09:22:45 +0200 Date: Mon, 14 Sep 1992 09:22:45 +0200 From: h.b.furuseth%usit.uio.no@lucid.com Message-Id: <9209140722.AAdurin05786@durin.uio.no> To: bug-lucid-emacs@lucid.com In-Reply-To: simon%lia.di.epfl.ch@lucid.com's message of Fri, 11 Sep 1992 15:17:36 GMT Subject: Re: Loss of functionality in 19.3 isearch References: Right, but please try to make such changes in a way that would work on GNU emacs too: (fset 'isearch-ding (if (boundp 'facep) ; Lucid emacs 'ding) '(lambda (&optional arg ignore) (ding arg))) ... (isearch-ding nil 'isearch-quit) Hallvard From bug-lucid-emacs-request@lucid.com Mon Sep 14 02:30:58 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12215; Mon, 14 Sep 92 02:30:58 PDT Received: by heavens-gate.lucid.com id AA15732g; Mon, 14 Sep 92 02:14:50 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA15728g; Mon, 14 Sep 92 02:14:37 PDT Received: by liasg2.epfl.ch (Smail3.1.26.7 #2) id m0mUCcb-000HMnC; Mon, 14 Sep 92 11:21 MDT Message-Id: Date: Mon, 14 Sep 92 11:26 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: bug-lucid-emacs@lucid.com Subject: Lucid Emacs 19.3 under IRIX 4.0.5 (Silicon Graphics) Basically, Lemacs compiles without much hassle under IRIX 4 (using GCC). The linker that comes with the new (3.10) compilers generates slightly different output files, which causes unexec() to break. The patch below (posted to the Epoch newsgroup by Shankar Unni of SGI) makes unexmips.c cope with the new format. The resulting lemacs works (I am using it now) but has some problems: * if you start it in the background, it stops with [1]+ Stopped (tty output) lemacs * tabs are sometimes displayed incorrectly (as single spaces even at the beginning of a line). The Sun version (compiled by me using GCC) has the same problem. -- Simon. ============================== snip snip ============================== *** unexmips.c.orig Fri Aug 7 14:36:00 1992 --- unexmips.c Thu Aug 27 19:10:46 1992 *************** *** 152,158 **** --- 152,164 ---- exit(1); } + /* + * The headers are no longer in text-init-rdata-data order. Therefore we + * have to do a linear search for each section in the section list. + */ #define CHECK_SCNHDR(ptr, name, flags) \ + i = 0; ptr = NULL; \ + while(i < hdr.fhdr.f_nscns && !ptr) { \ if (strcmp(hdr.section[i].s_name, name) == 0) { \ if (hdr.section[i].s_flags != flags) { \ fprintf(stderr, "unexec: %x flags where %x expected in %s section.\n", \ *************** *** 159,171 **** hdr.section[i].s_flags, flags, name); \ } \ ptr = hdr.section + i; \ - i += 1; \ } \ ! else { \ ! ptr = NULL; \ ! } - i = 0; CHECK_SCNHDR(text_section, _TEXT, STYP_TEXT); CHECK_SCNHDR(init_section, _INIT, STYP_INIT); CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA); --- 165,174 ---- hdr.section[i].s_flags, flags, name); \ } \ ptr = hdr.section + i; \ } \ ! i += 1; \ ! } CHECK_SCNHDR(text_section, _TEXT, STYP_TEXT); CHECK_SCNHDR(init_section, _INIT, STYP_INIT); CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA); *************** *** 198,203 **** --- 201,212 ---- hdr.aout.bss_start = hdr.aout.data_start + hdr.aout.dsize; rdata_section->s_size = data_start - DATA_START; + + /* adjust start and virtual addresses of rdata_section, too */ + rdata_section->s_vaddr = DATA_START; + rdata_section->s_paddr = DATA_START; + rdata_section->s_scnptr = text_section->s_scnptr + hdr.aout.tsize; + data_section->s_vaddr = data_start; data_section->s_paddr = data_start; data_section->s_size = brk - data_start; From bug-lucid-emacs-request@lucid.com Mon Sep 14 07:29:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13648; Mon, 14 Sep 92 07:29:28 PDT Received: by heavens-gate.lucid.com id AA16093g; Mon, 14 Sep 92 07:14:18 PDT Received: from rip.hrb.com by heavens-gate.lucid.com id AA16089g; Mon, 14 Sep 92 07:14:06 PDT Received: from ICF2.HRB.COM by rip.hrb.com (PMDF #2315 ) id <01GORS3U2TUO0009SP@rip.hrb.com>; Mon, 14 Sep 1992 10:25:16 EST Received: from icf.hrb.com by icf.hrb.com (PMDF #2315 ) id <01GORRU390WWLLWLJV@icf.hrb.com>; Mon, 14 Sep 1992 10:24:52 EST Date: 14 Sep 1992 10:24:52 -0500 (EST) From: "Eric L. Schott" Subject: (setq selective-display t) To: bug-lucid-emacs@lucid.com Message-Id: <01GORRU39AK2LLWLJV@icf.hrb.com> X-Vms-To: IN%"bug-lucid-emacs@lucid.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT With both Lemacs 19.2 and 19.3, the dired-hide-... functions did not work correctly: rather than one short line with "...", there was one line with "^M" where every new line should have been. I traced the problem to (setq selective-display t) was not working correctly. It seems the code in xdisp.c for this is commented out with "This doesn't work." Why is this commented out? Is there a fix? --- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" From bug-lucid-emacs-request@lucid.com Mon Sep 14 11:30:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14411; Mon, 14 Sep 92 11:30:35 PDT Received: by heavens-gate.lucid.com id AA16797g; Mon, 14 Sep 92 11:17:49 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA16791g; Mon, 14 Sep 92 11:17:35 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA15202; Mon, 14 Sep 92 11:26:04 PDT Date: Mon, 14 Sep 92 11:26:04 PDT Message-Id: <9209141826.AA15202@thalidomide.lucid> X-Windows: Don't get frustrated without it. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: "Eric L. Schott" Cc: bug-lucid-emacs@lucid.com Subject: Re: (setq selective-display t) In-Reply-To: Eric L. Schott's message of EST 14-Sep-92 10:24:52 -0500 <01GORRU39AK2LLWLJV@icf.hrb.com> References: <01GORRU39AK2LLWLJV@icf.hrb.com> In message <01GORRU39AK2LLWLJV@icf.hrb.com> Eric L. Schott wrote: > > I traced the problem to (setq selective-display t) was not working > correctly. This is mentioned in the NEWS file. > It seems the code in xdisp.c for this is commented out with "This doesn't > work." Why is this commented out? Maybe because it doesn't work? :-) > Is there a fix? As I see it, the fix is to rewrite redisplay. This will take a couple of months, and I don't know when I'm going to have time to start working on it. I spent some time trying to make selective display work with the current redisplay model (that's the code you see that's commented out) but I didn't finish. If someone else would like to take a stab at making that code work, then I'm sure many people would be grateful. -- Jamie From bug-lucid-emacs-request@lucid.com Mon Sep 14 12:44:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14685; Mon, 14 Sep 92 12:44:28 PDT Received: by heavens-gate.lucid.com id AA17106g; Mon, 14 Sep 92 12:32:02 PDT Received: from ingr.ingr.com by heavens-gate.lucid.com id AA17102g; Mon, 14 Sep 92 12:31:45 PDT Received: from matis.UUCP by ingr.ingr.com (5.65c/1.920611) id AA28391; Mon, 14 Sep 1992 14:48:33 -0500 Received: from simpson.ingr.com by turtles (4.1/SMI-4.1) id AA25464; Mon, 14 Sep 92 16:22:30 IST Received: by simpson.ingr.com (4.1/SMI-4.1) id AA21199; Mon, 14 Sep 92 16:21:42 IST From: matis!amir@lucid.com (Amir J Katz) Message-Id: <9209141421.AA21199@simpson.ingr.com> Subject: Lemacs 19.3, Audio and SunOS 4.1.3 To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Mon, 14 Sep 92 16:21:42 EET Cc: help-lucid-emacs@lucid.com (Lucid Emacs help M.L.) Organization: SEE Technologies Ltd. Reply-To: matis!amir@lucid.com X-Reply-To: amir@matis.ingr.COM X-Mailer: ELM [version 2.3 PL11] (If you don't have a Sun SparcStation, please save this message to /dev/null :-) On SunOS 4.1.3, Sun has changed the audio header files (and the audio ioctl commands as well) in order to support the new audio devices on the SparcStation 10 family. Accordingly, in Lucid Emacs 19.3, Jamie (or someone else at Lucid) has surrounded some pre-SunOS 4.1.3 code in src/libsst.c with the appropriate #ifdef. However, I found out that it is not enough, at least not for gcc and Sun's ANSI-C compilers. Here is a patch to libsst.h that fixes the problem: *** libsst.h.orig Wed Sep 2 11:00:23 1992 --- libsst.h Mon Sep 14 14:52:53 1992 *************** *** 14,19 **** --- 14,20 ---- #ifndef SUNOS4_0_3 #define AUDIO_4_0_3_COMPAT #define AUDIO_CHIP + #define AMD_CHIP /* AJK: SparcStation 1, 2, IPC, IPX */ #include #include #include Since I don't have a SparcStation 10, I don't know whether this code will compile correctly there. BTW, does anyone know whether there is a #define on Suns that shows the machine type? Both Sun's cc and GNU gcc define, when on Sun, the symbols 'sun' and 'sparc'. However, in order to determine whether an audio device exists at all, the machine type (as returned by the shell command 'arch -k') must be either 'sun4c' and 'sun4m'. Neither compiler defines such symbols. -- /* ----------------------------------------------------------- */ /* Amir J. Katz | amir@matis.ingr.COM */ /* System Specialist | Voice: +972 52-584684 */ /* SEE Technologies Ltd. | Fax: +972 52-543917 */ /* ............ Solaris 2.0 - The Final Frontier ? ........... */ From bug-lucid-emacs-request@lucid.com Mon Sep 14 13:16:04 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14795; Mon, 14 Sep 92 13:16:04 PDT Received: by heavens-gate.lucid.com id AA17203g; Mon, 14 Sep 92 13:00:10 PDT Received: from rip.hrb.com by heavens-gate.lucid.com id AA17193g; Mon, 14 Sep 92 12:59:52 PDT Received: from ICF2.HRB.COM by rip.hrb.com (PMDF #2315 ) id <01GOS46IM2TC0009NC@rip.hrb.com>; Mon, 14 Sep 1992 16:11:02 EST Received: from icf.hrb.com by icf.hrb.com (PMDF #2315 ) id <01GOS3X53MTSLLWVH2@icf.hrb.com>; Mon, 14 Sep 1992 16:10:25 EST Date: 14 Sep 1992 16:10:25 -0500 (EST) From: "Eric L. Schott" Subject: x-set-point-and-insert-selection To: bug-lucid-emacs@lucid.com Message-Id: <01GOS3X54642LLWVH2@icf.hrb.com> X-Vms-To: IN%"bug-lucid-emacs@lucid.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT x-set-point-and-insert-selection (defaults to button2) seems to have changed from 19.2 to 19.3. With 19.3, use the mouse to select a region, then use the middle button to insert that selection in the same window, but away from the selection. The new behavior seems to extend the selection to the click point, then insert the new, larger selection. Was this change from 19.2 (which did not extend the selection) intentional? --- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" From bug-lucid-emacs-request@lucid.com Mon Sep 14 18:41:03 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15497; Mon, 14 Sep 92 18:41:03 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA18214g; Mon, 14 Sep 92 18:25:57 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09391; Mon, 14 Sep 92 21:37:20 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09387; Mon, 14 Sep 92 21:37:19 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!paladin.american.edu!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!cherokee!mcclen From: mcclen@advtech.uswest.com ( Chris McClenaghan) Subject: lemacs 19.3 and Motif menu bar Message-Id: Nntp-Posting-Host: alder.advtech.uswest.com Organization: US WEST Advanced Technologies, Boulder, Colorado Date: Fri, 11 Sep 1992 20:31:59 GMT Lines: 9 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I previously responded that it was necessary to define ENERGIZE in the lwlib Imakefile to get the Motif menubar option loaded properly. The "Buffers" pulldown does not work. When selected, I get a 4 or 6 pixel square and that's all. This is using the -q option on start up. The Xt version seems to work fine. -- Chris McClenaghan mcclen@advtech.uswest.com From bug-lucid-emacs-request@lucid.com Tue Sep 15 01:51:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00661; Tue, 15 Sep 92 01:51:30 PDT Received: by heavens-gate.lucid.com id AA18749g; Tue, 15 Sep 92 01:39:32 PDT Received: from liasg2.epfl.ch by heavens-gate.lucid.com id AA18745g; Tue, 15 Sep 92 01:38:22 PDT Received: by liasg2.epfl.ch (Smail3.1.26.7 #2) id m0mUYbO-000HMnC; Tue, 15 Sep 92 10:49 MDT Message-Id: Date: Tue, 15 Sep 92 10:49 MDT From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: YP/DNS problem In-Reply-To: <9209092201.AA27686@thalidomide.lucid> References: <9209092201.AA27686@thalidomide.lucid> The gethostbyname() routines in the C run-time libraries distributed with SunOS 4.x *never* consult the DNS directly. They use the NIS hosts map or /etc/hosts if there is no NIS. The recommended (by Sun, not by me) way to use the DNS is to configure the NIS server to do DNS lookup in case it doesn't find a host or IP address in the local NIS map. This can be done by hacking /var/yp/Makefile as documented in Sun's manuals. Now many people want to avoid the overhead of NIS because all host information is in the DNS anyway, so they follow the advice of the Net and replace the gethost...() routines in the dynamic libc by the BIND versions of these routines that use the resolver to query the DNS nameserver directly. These routines are distributed by Sun in /usr/lib/libresolv.a library (but you can also use a newer BIND version). Jamie Zawinski writes: > If emacs is linked against Sun's libc.a, then the gethostbyname() > routine that is linked in is one that knows about YP (Yellow Pages, > aka NIS) and not DNS (Domain Name Service, the standard which Sun > has reinvented.) Hmmm... not here. It is true that most people who want to use DNS for hostname resolution only change their dynamic libc, but I think it is a good idea to keep the dynamic and static versions of the library consistent; so I put the resolver routines into libc.a as well (this is even easier than patching libc.so.x.y). > The rule seems to be that, if emacs manages to find the logged-in > user information by using the local /etc/passwd file (which I > presume it checks first) then it doesn't EVER consult YP for the > "/etc/hosts" information. But it will consult DNS. Puzzle out that > incestuous relationship, why don't you. As I said, Sun's gethostby...() routines don't know how to talk to the DNS directly so this puzzles me. > I don't know what the difference between tzset() and tzsetwall() is, > but they both seem to have the same effect. Which is: if a dumped > emacs calls either of these tz functions, then the passwd/hosts > problem exhibits itself. If neither of these tz functions is > called, then there is no problem. > > This only happens from dumped emacses, so possibly it has something > to do with static data being overwritten, or corrupted malloc lists, > or something. In particular, it doesn't happen when one codes up > the obvious trivial testcase (linking it either statically or > dynamically.) Oh, I see. Very good detective work! There's a known off-by-one error in one of the tzset routines which causes the ninth byte of an eight-byte buffer to be overwritten; maybe you are hitting this bug? It was in SunOS 4.1 and 4.1.1 and fixed by official patch 100267-04 (and probably earlier versions). I don't know whether it has resurfaced in 4.1.2 or 4.1.3. The bug's official name is: 1038500 localtime or tzsetwall corrupts malloc space And it was the reason for USE_SYSTEM_MALLOC in the SunOS 4.1 config files of GNU Emacs. Sun's malloc() rounds up the buffer's size so that the illegal access doesn't cause any harm. It is probably not easy to work around this bug in an elegant way because the buffer is allocated by tzsetwall() rather than Emacs. > I expect that this only a problem (in the current incarnation, anyway) > when emacs is running on a Sun; do any non-Sun machines use YP? Yes! NIS is part of ONC (Open Network Computing) and many vendors other than Sun use it: Hewlett-Packard, Silicon Graphics, and Digital all ship it with their workstation OSes (that's all brands I could check). -- Simon. From bug-lucid-emacs-request@lucid.com Tue Sep 15 05:11:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01166; Tue, 15 Sep 92 05:11:21 PDT Received: by heavens-gate.lucid.com id AA19018g; Tue, 15 Sep 92 04:56:36 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA19014g; Tue, 15 Sep 92 04:56:02 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA14402; Tue, 15 Sep 1992 14:07:08 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA06203; Tue, 15 Sep 92 14:09:07 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA24930; Tue, 15 Sep 92 14:06:33 +0200 Date: Tue, 15 Sep 92 14:06:33 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9209151206.AA24930@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA03691; Tue, 15 Sep 92 14:06:31 +0200 To: Bug Lucid Emacs Subject: Segmentation fault when playing with site-init.el Environment: lemacs 19.3 compiled with gcc 2.2.2 -g (without -O) on SPARCstation 2 (sunos4.1.1) I try to put a lot of thing in the dumped lemacs, and it generally fails, either with the message: "This version of emacs only runs under X Windows (for now). Check that your $DISPLAY environment variable is properly set." or with a segmentation fault. For instance, the following site-init.el leads to the following backtrace: ;; site-init.el file (require 'bbdb-com) ; from bbdb 1.47; 11-sep-92. (require 'vm) ; from lemacs ditribution (load "gnus") ; from lemacs distribution leads to: (gdb) run -batch -l loadup.el dump Starting program: /export/home/gogol/queinnec/FTP/lemacs-19.3/src/temacs -batch -l loadup.el dump Loading loadup.el... [ messages removed ] Loading bytecomp-runtime... Finding pointers to doc strings... Finding pointers to doc strings...done Loading site-init... Loading gnus... Program received signal 11, Segmentation fault 0x13edb0 in strlen () (gdb) bt #0 0x13edb0 in strlen () #1 0x999a0 in print (obj=203911048, printcharfun=69261356, escapeflag=0) at print.c:621 #2 0x98d10 in Fprinc (obj=203911048, printcharfun=69261356) at print.c:489 #3 0x4c320 in cmd_error (data=338148276) at keyboard.c:320 #4 0x8c994 in internal_condition_case (bfun=0x4c5b0 , handlers=69261596, hfun=0x4c0ec ) at eval.c:992 #5 0x4c680 in top_level_1 (dummy=69261316) at keyboard.c:406 #6 0x8c3b0 in internal_catch (tag=69261576, func=0x4c63c , arg=69261316) at eval.c:814 #7 0x4c508 in command_loop () at keyboard.c:366 #8 0x4bf1c in recursive_edit_1 () at keyboard.c:221 #9 0x4c040 in Frecursive_edit () at keyboard.c:250 #10 0x4b5a4 in main (argc=5, argv=0xf7fff70c, envp=0xf7fff724) at emacs.c:817 The following site-init.el: (require 'vm) (load "gnus") generates: (gdb) run -batch -l loadup.el dump Starting program: /export/home/gogol/queinnec/FTP/lemacs-19.3/src/temacs -batch -l loadup.el dump Loading loadup.el... [ a few lines removed ] Finding pointers to doc strings... Finding pointers to doc strings...done Loading site-init... Loading gnus... This version of emacs only runs under X Windows (for now). Check that your $DISPLAY environment variable is properly set. Program received signal 11, Segmentation fault 0x947c0 in Fget (sym=???, prop=0) at fns.c:979 979 { (gdb) bt #0 0x947c0 in Fget (sym=???, prop=0) at fns.c:979 [ ouch, no stack ! ] More information available on request. Phil From bug-lucid-emacs-request@lucid.com Tue Sep 15 06:12:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01335; Tue, 15 Sep 92 06:12:08 PDT Received: by heavens-gate.lucid.com id AA19096g; Tue, 15 Sep 92 06:00:24 PDT Received: from mwunix.mitre.org by heavens-gate.lucid.com id AA19092g; Tue, 15 Sep 92 06:00:13 PDT Return-Path: Received: from maestro.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA15823; Tue, 15 Sep 92 09:09:11 -0400 Received: from gong.mitre.org ([128.29.45.16]) by maestro.mitre.org (4.1/SMI-4.1) id AA17105; Tue, 15 Sep 92 09:10:07 EDT Date: Tue, 15 Sep 92 09:10:07 EDT From: lamour@maestro.mitre.org (Michael Lamoureux) Message-Id: <9209151310.AA17105@maestro.mitre.org> Received: by gong.mitre.org (4.1/SMI-4.1) id AA07377; Tue, 15 Sep 92 09:10:06 EDT To: bug-lucid-emacs@lucid.com Subject: lemacs 19.3 & VM To say the least, VM under 19.3 is quirky. So far, yesterday is the only day I haven't been able to hang emacs in VM (I've already done it this morning!). I think I've finally narrowed down when it happens, but I haven't been able to get any concrete info on it. Basically, every time it has hung has been when I delete the last message in my INBOX. By default, it wraps to the first message. This works most of the time. When it doesn't work, the CPU pegs, and nothing can save emacs at that point. ^G, does nothing. I can get one kill statement in, at which point emacs breaks out of whatever loop it's in, and goes directly into one that will only respond to a kill -9. Is anyone else experiencing anything like this? I'm on a Sparc 1+, SunOS4.1, lucid sun4 binary distribution (with recompiled /etc dir). I guess the next steps are to turn off vm-circular-folders, and to recompile to whole emacs distribution. I haven't really had any trouble with any other part of emacs (but then, I do tend to use VM more than any other mode ;-) Thanks, Michael lamour@mitre.org PS> I just got my Solaris 2.0 CD today, anyone have lemacs running on Solaris 2.0 yet? From bug-lucid-emacs-request@lucid.com Tue Sep 15 09:03:11 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01873; Tue, 15 Sep 92 09:03:11 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA19340g; Tue, 15 Sep 92 08:51:31 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07930; Tue, 15 Sep 92 12:02:58 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07926; Tue, 15 Sep 92 12:02:56 -0400 Path: uunet!news.centerline.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!yale.edu!jvnc.net!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!cis.ksu.edu!frain From: frain@cis.ksu.edu (Jerry Frain) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs 19.3 & VM Date: 15 Sep 92 15:23:55 GMT Organization: Kansas State University Lines: 26 Message-Id: References: <9209151310.AA17105@maestro.mitre.org> Nntp-Posting-Host: depot.cis.ksu.edu Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com lamour@maestro.mitre.org (Michael Lamoureux) writes: > I haven't really had any trouble with any other part of emacs > (but then, I do tend to use VM more than any other mode ;-) I, too, ran into these problems. One of the errors I saw mentioned "byte-code", so I re-compiled vm-mode from the distribution. However, vm-mode uses a several constants (the first one it misses is search-exit-char) previously defined in loaddefs.el, and used for the incremental search, but now removed because they are unnecessary due to the new isearch-mode. If you want to re-compile vm, you'll need to put these constants back in somewhere, I put them in isearch-mode though there is probably a better place for them (see my patch a couple of articles back, or mail me and I'll be glad to ship you a new one). Anyway, after adding that patch and recompiling vm, it works fine for me. ------------------------------------------------------------------------------ Jerry Frain, Systems Programmer | "Back off man, I'm a scientist." Kansas State University | frain@cis.ksu.edu Department of Computer & Info Sciences | ...!rutgers!depot!frain From bug-lucid-emacs-request@lucid.com Tue Sep 15 09:23:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01957; Tue, 15 Sep 92 09:23:36 PDT Received: by heavens-gate.lucid.com id AA19368g; Tue, 15 Sep 92 09:08:40 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA19364g; Tue, 15 Sep 92 09:08:28 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA02818; Tue, 15 Sep 92 10:19:54 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.15-leaf) id AA19391; Tue, 15 Sep 92 10:19:52 -0600 Date: Tue, 15 Sep 92 10:19:52 -0600 From: eeide@asylum.cs.utah.edu (Eric Eide) Message-Id: <9209151619.AA19391@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Subject: Menu Selection Doesn't Exit (sit-for) This is a bug that I reported back in June for 19.1, but it's still present in 19.3. When Lucid GNU Emacs starts up and displays the copyleft, making a menu selction doesn't "wake up" Lucid. (At this point Lucid is doing (sit-for 120), and menu input doesn't cause the sit-for to exit.) This is confusing behavior. As its documentation says, sit-for is supposed to "wait for ARG seconds or until user input is available." I would argue that menu selections definitely qualify as user input. ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." From bug-lucid-emacs-request@lucid.com Tue Sep 15 09:38:42 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02001; Tue, 15 Sep 92 09:38:42 PDT Received: by heavens-gate.lucid.com id AA19409g; Tue, 15 Sep 92 09:26:11 PDT Received: from srv01s4.cas.org by heavens-gate.lucid.com id AA19402g; Tue, 15 Sep 92 09:25:46 PDT Date: Tue, 15 Sep 92 12:36:59 EDT From: rls26@cas.org Message-Id: <9209151636.AA26491@cas.org> To: bug-lucid-emacs@lucid.com Subject: Ange-ftp failures under 19.3 Cc: rscott*cas.org@cas.org I have installed 19.3 and am havingg good luck with most of the facilities. It appears that ange-ftp does not work with 19.3. I have tried both the version that was in the distribution and the version that we have been using with 19.2 getting the same result. The ftp connection is opened and the ls listing is placed into the temp file, however when ange-ftp attempts to parse the data it fails giving the following message instead of the file. /@archive.cis.ohio-state.edu:/pub: ls: /@archive.cis.ohio-state.edu:/pub/.: No such file or directory The content of the temp file created by the ftp ls command is as follows: total 2182 drwxrwsr-x124 root 2560 Sep 15 08:37 . dr-xr-sr-x 10 ftp 512 May 3 15:54 .. -rw-r----- 1 5 0 Dec 18 1991 .hushlogin drwxrwsr-x 2 482 512 Feb 20 1990 CTEXT -rw-rw-r-- 1 2055 32113 Aug 27 16:00 GNU.how-to-get -rw-rw-r-- 1 2055 32109 Aug 26 18:23 GNU.how-to-get~ lrwxrwxrwx 1 root 9 Sep 11 1991 GoodNeWS -> HyperNeWS drwxrwsr-x 2 320 1024 Nov 3 1990 HyperNeWS drwxrwsr-x 3 482 512 Feb 20 1990 ICCCM drwxrwsr-x 2 482 1024 May 22 1990 Interviews drwxrwsr-x 2 13 512 Nov 9 1990 NeWS drwxrwsr-x 4 482 512 Feb 20 1990 PEX drwxr-sr-x 3 216 512 Oct 11 1991 Usenix drwxrwsr-x 9 482 2048 Sep 5 00:17 X-contrib drwxrwsr-x 7 482 512 Feb 20 1990 X.V11R4 drwxrwsr-x 7 2297 512 May 18 19:03 X.V11R5 drwxrwsr-x 2 482 512 Feb 20 1990 XDMCP drwxrwsr-x 2 482 512 Feb 20 1990 XLFD drwxrwsr-x 2 482 1024 Feb 20 1990 XTEST drwxrwsr-x 3 482 512 Feb 20 1990 XView drwxr-sr-x 2 5305 512 Aug 14 16:29 Xo drwxrwsr-x 2 1221 512 Apr 22 1991 algebra drwxrwsr-x 2 482 512 Jun 19 1991 amd drwxrwsr-x 2 320 1024 Sep 12 1991 analyrim drwxrwsr-x 24 5169 512 Feb 26 1992 att7300 drwxrwsr-x 3 216 1024 Sep 12 04:33 backup drwxrwsr-x 3 root 512 Nov 9 1990 bibliographies drwxrwsr-x 2 482 512 Jun 19 1991 byacc drwxrwsr-x 2 258 512 May 30 1991 cast drwxrwsr-x 2 253 512 Jun 18 17:29 chameleon drwxrwsr-x 2 439 512 Oct 24 1991 cleanup drwxrwsr-x 4 5169 512 Jul 16 01:32 comp.sources.3b1 drwxr-sr-x 4 439 512 Feb 7 1992 comp.sources.misc drwxrwsr-x 26 5196 1024 Jul 19 1991 comp.sources.unix drwxrwsr-x 2 320 512 Jun 19 1991 compress drwxrwsr-x 2 511 512 Jun 7 16:44 condela drwxrwsr-x 2 482 512 Jun 19 1991 condor drwxrwsr-x 2 2134 512 Mar 27 19:51 console-server drwxrwsr-x 3 5942 512 May 27 21:17 cops drwxrwsr-x 2 482 512 Jun 19 1991 deliver -rw-rw-r-- 1 439 227839 Aug 27 1991 dotfiles.tar.Z drwxrwsr-x 2 439 10240 Sep 27 1991 drafts drwxrwsr-x 2 3028 512 Jun 19 1991 dspl -rw-rw-r-- 1 273 442159 Nov 16 1989 dvi3ps.tar.Z drwxrwsr-x 2 2055 512 Feb 25 1992 elm-2.3.11 -rw-rw-r-- 1 273 364277 Sep 8 1989 fac-guide.tar.Z -rw-r--r-- 1 439 590 Sep 13 07:01 files-modified-last-week.Z drwxrwsr-x 5 482 2560 Sep 3 13:45 firearms drwxrwsr-x 2 320 512 Dec 22 1991 fsuucp -rw-rw-r-- 1 258 1300 Aug 16 1991 ftpdu lrwxrwxrwx 1 root 26 May 3 15:50 gnu -> /n/archive/0/extra-ftp/gnu drwxrwsr-x 2 258 512 May 14 1991 gnu-mpw -rw-rw-r-- 1 258 854 Aug 16 1991 gnudu drwxr-sr-x 2 3004 512 Aug 26 19:28 hci drwxrwsr-x 2 3004 3072 Sep 12 10:51 hcibib drwxrwsr-x 2 2055 512 Sep 13 1991 i386 drwxrwsr-x 7 482 512 Aug 21 1990 ibm-pc drwxrwsr-x 2 root 1536 Nov 9 1990 idea drwxrwsr-x 2 320 3072 Nov 9 1990 ien drwxrwsr-x 2 320 512 Oct 4 1991 imap drwxrwsr-x 2 258 512 Apr 14 16:01 incoming drwxrwsr-x 2 320 1536 Jun 14 1991 internet-drafts drwxrwsr-x 2 482 512 Jun 19 15:18 isode lrwxrwxrwx 1 root 10 Sep 11 1991 ispell -> gnu/ispell -rw-r--r-- 1 3128 438416 Sep 25 1991 jargon.296.Z drwxr-sr-x 2 3126 512 Jul 27 14:18 kbridge drwxrwsr-x 2 258 512 Jun 19 1991 kgen drwxr-sr-x 3 320 2048 Mar 20 15:14 lpf -rw-r--r-- 1 root 151021 Sep 15 08:40 ls-lR.Z -rw-r--r-- 1 root 151231 Sep 14 08:40 ls-lR.Z-OLD drwxrwsr-x 2 439 1024 Jun 19 1991 m3 drwxrwsr-x 2 320 512 Feb 20 1990 mgr drwxrwsr-x 2 482 4096 Feb 20 1990 mitscheme drwxrwsr-x 5 2055 512 Jun 19 1991 nameserver drwxrwsr-x 4 320 512 Feb 20 1990 ncsa drwxrwsr-x 2 439 2048 Jun 30 18:37 netinfo drwxr-xr-x 6 3169 9728 Sep 14 15:03 neuroprose drwxrwsr-x 4 482 1024 Jun 19 1991 news drwxrwsr-x 2 482 512 Jun 19 1991 newsgate drwxrwsr-x 2 3128 512 Jun 19 1991 next drwxrwsr-x 2 258 512 Jun 19 1991 nfswatch drwxrwsr-x 2 482 512 Jun 19 1991 nnstat drwxrwsr-x 2 482 512 Jun 19 1991 nntp -rw-rw-r-- 1 683 20975 Sep 12 1989 noquotas.tar.Z drwxrwsr-x 2 320 1536 Jun 29 19:35 ntp drwxrwxr-x 2 439 512 Feb 7 1992 oraperl drwxrwsr-x 2 21 512 Jun 19 1991 osu-dissert drwxrwsr-x 3 258 512 Oct 23 1990 oztex drwxr-sr-x 3 root 512 Mar 18 1992 papers drwxrwsr-x 2 320 512 Jun 19 1991 paranoia drwxrwsr-x 2 482 512 Jun 19 1991 patch drwxrwsr-x 3 482 512 Jun 19 1991 pathalias drwxrwsr-x 2 482 512 Jun 19 1991 pbmplus drwxrwsr-x 2 482 512 Jun 19 1991 pcomm drwxrwsr-x 4 320 512 Aug 8 1991 pcroute drwxrwsr-x 2 482 512 Jun 19 1991 pcrrn drwxrwsr-x 8 3128 512 Dec 18 1991 perl drwxrwsr-x 2 258 1536 Aug 18 14:20 picasso drwxrwsr-x 2 439 512 Jul 24 1991 plan9 drwxrwsr-x 2 320 512 Jun 19 1991 plot2ps drwxrwsr-x 2 482 512 Jun 3 1991 policy-docs lrwxrwxrwx 1 320 4 Oct 4 1991 popl -> imap drwxrwsr-x 2 258 1024 Aug 14 13:20 postgres-v4r0 drwxr-sr-x 3 3128 512 Feb 15 1992 postscript drwxrwsr-x 2 320 512 Mar 30 21:37 ppp drwxrwsr-x 2 439 512 Jun 19 1991 proxyarp drwxrwsr-x 2 320 512 Jun 19 1991 rastps drwxrwsr-x 2 482 512 Jun 19 1991 rcs drwxrwsr-x 2 320 512 Apr 2 1991 regionals drwxrwsr-x 2 482 15360 Aug 19 14:54 rfc drwxrwsr-x 5 482 512 Jun 19 1991 rn drwxrwsr-x 2 320 1024 Jun 19 1991 rpc4.0 drwxr-sr-x 2 2055 512 Mar 3 1992 sac2 drwxrwsr-x 4 320 512 Jun 19 1991 sbprolog drwxrwsr-x 2 root 512 Jun 19 1991 sdbm drwxrwsr-x 2 482 512 Jun 19 1991 security drwxrwsr-x 3 482 1024 Jun 19 1991 sendmail drwxrwsr-x 2 1217 512 Sep 8 22:11 siggraph92 drwxrwsr-x 2 482 512 Apr 16 1991 slipware drwxrwsr-x 2 root 512 Jan 28 1992 smail drwxr-sr-x 2 3004 512 Aug 22 19:28 stat drwxrwsr-x 2 320 512 Jun 19 1991 stdwin drwxrwsr-x 2 683 3584 Jun 19 1991 style-files drwxrwsr-x 2 482 512 Sep 12 1991 style-guide drwxr-sr-x 2 3128 512 Jun 16 18:10 sun-src drwxrwsr-x 4 3070 512 Sep 21 1990 sysgen drwxrwsr-x 2 320 512 Apr 8 04:12 taylor-uucp drwxrwsr-x 3 2134 1024 Apr 14 15:55 tcl drwxrwsr-x 2 258 512 Jan 14 1992 tcsh drwxr-sr-x 2 2112 512 Sep 10 14:43 tech-report drwxrwsr-x 4 2126 512 Nov 15 1991 tex drwxrwsr-x 2 482 512 Nov 26 1990 tiff drwxr-sr-x 2 root 512 Jul 24 18:59 tmp drwxrwsr-x 2 482 512 Jun 19 1991 tn3270 drwxrwsr-x 2 511 512 Jun 19 1991 toolset drwxrwsr-x 2 2055 512 Nov 18 1991 top drwxrwsr-x 2 2055 512 Nov 1 1991 traceroute drwxrwsr-x 4 439 512 Sep 16 1991 uemacs drwxrwsr-x 2 2270 512 Sep 21 1990 volumeimage drwxrwsr-x 3 482 512 Jun 19 1991 xcomm -rw-rw-r-- 1 273 100431 Feb 2 1989 xscheme.tar.Z -rw-r----- 1 439 0 Feb 7 1992 ziggy drwxrwsr-x 2 320 512 Jan 14 1992 zoo Can anyone offer any suggestions on this problem? Thanks in advance Richard Scott Senior Scientist Chemical Abstracts Service rscott@cas.org From bug-lucid-emacs-request@lucid.com Tue Sep 15 09:38:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02007; Tue, 15 Sep 92 09:38:50 PDT Received: by heavens-gate.lucid.com id AA19414g; Tue, 15 Sep 92 09:26:36 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA19410g; Tue, 15 Sep 92 09:26:12 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA03228; Tue, 15 Sep 92 10:37:37 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.15-leaf) id AA19934; Tue, 15 Sep 92 10:37:36 -0600 Date: Tue, 15 Sep 92 10:37:36 -0600 From: eeide@asylum.cs.utah.edu (Eric Eide) Message-Id: <9209151637.AA19934@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Subject: Non-robust X Processing I erroneously added the following line to my ".Xresources" file: ! 68 is the glyph for the left pointer. Emacs*XlwMenu.cursor: 68 Lucid GNU Emacs couldn't turn "68" into a Cursor, and this resulted in a long line of X errors. I could no longer pull down any of the menus, and when I exited Emacs it dumped core. Changing the resource specification to: Emacs*XlwMenu.curosr: left_ptr cleared up all of the problems. It appears that Lucid GNU Emacs doesn't handle some X errors very well. It wouldn't take much for Lucid to provide its own default cursor in the case above, for example. I guess this falls into the category of "robust" behavior, and perhaps Lucid GNU Emacs is too young to be expected to be wholly robust. I am, however, pleased to report that this is the only crash I've experienced with Lucid GNU Emacs. And 19.3 was easy to install on my system -- much easier than 19.1! Thank you, Lucid, for your excellent work! PS -- I love "blink-paren". One of my coworkers said that "blink-paren" alone is reason enough to switch to Lucid. ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." From bug-lucid-emacs-request@lucid.com Tue Sep 15 13:40:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02837; Tue, 15 Sep 92 13:40:45 PDT Received: by heavens-gate.lucid.com id AA20309g; Tue, 15 Sep 92 13:25:26 PDT Received: from Princeton.EDU by heavens-gate.lucid.com id AA20305g; Tue, 15 Sep 92 13:25:10 PDT Received: from hhb.UUCP by Princeton.EDU (5.65b/2.93/princeton) id AA29359; Tue, 15 Sep 92 16:36:23 -0400 Received: from brett.master by master (4.1/Redac_Mahwah-v1.0) id AA03352; Tue, 15 Sep 92 15:44:03 EDT Received: by brett.master (4.1/SMI-4.1) id AA12862; Tue, 15 Sep 92 15:44:06 EDT Date: Tue, 15 Sep 92 15:44:06 EDT From: bvk%hhb@Princeton.EDU (Brett Kuehner) Message-Id: <9209151944.AA12862@brett.master> To: bug-lucid-emacs@lucid.com, cas.org!rls26@Princeton.EDU Subject: Re: Ange-ftp failures under 19.3 I've noticed that the ftp log buffer seems to have ^M (control-m) characters at the end of every line. Shell mode has this problem as well, which makes some sense as ange-ftp seems to be somewhat built on top of shell-mode. Perhaps this is what is screwing up ange-ftp? Doing a "stty -echo nl" in a shell-mode buffer fixes the problem for a shell, but I can't figure out how to add this to ange-ftp's startup for local ftp. I've tried mucking around with setting the ange-ftp gateway to be my machine, just so that it would do call the setup-term-command, but it doesn't seem to work (or, more likely, I've set thing up incorrectly). Does anyone have a fix to set the terminal mode of shell subprocesses to be equivalent to "stty -echo nl"? Brett -- Brett Kuehner, Racal-Redac, Mahwah, NJ ...!princeton!hhb!bvk bvk%hhb@princeton.EDU From bug-lucid-emacs-request@lucid.com Tue Sep 15 14:17:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02970; Tue, 15 Sep 92 14:17:48 PDT Received: by heavens-gate.lucid.com id AA20464g; Tue, 15 Sep 92 14:05:38 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA20460g; Tue, 15 Sep 92 14:05:27 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA17583; Tue, 15 Sep 92 16:17:12 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA05738; Tue, 15 Sep 92 17:05:08 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA22661; Tue, 15 Sep 92 17:17:31 EDT Date: Tue, 15 Sep 92 17:17:31 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9209152117.AA22661@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA09591; Tue, 15 Sep 92 17:16:57 EDT To: bug-lucid-emacs@lucid.com Cc: bug-gnu-emacs@prep.ai.mit.edu Subject: SUGGESTION: Permit help strings in menu items. Reply-To: bob_weiner@pts.mot.com I'd like to suggest that an optional 4th field be permitted in Lucid Emacs menu items (or GNU Emacs V19 menus if it has them) which would be a one line description providing help on the menu item. The string would be appropriate for display in the echo area and could be accessed by a user prior to selecting a menu item, for those cases where the item name is not descriptive enough. When the item is selected via some mouse button 'help' binding, the help string would be shown. I've designed menu-based frontends to systems for a number of years now and this is one feature which most menu systems lack that I find indispensible. If it were implemented, I could convert a series of menus I have under another system I designed for use as Lucid Emacs menus. They provide logical, structured access to Emacs buffers, screens, documentation, major and minor modes, subsystems and so on, so that mere mortals can effectively browse and operate many Emacs facilities. A release could then most likely be made ready for the end of the year. Bob From bug-lucid-emacs-request@lucid.com Tue Sep 15 14:49:59 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03055; Tue, 15 Sep 92 14:49:59 PDT Received: by heavens-gate.lucid.com id AA20630g; Tue, 15 Sep 92 14:37:33 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA20626g; Tue, 15 Sep 92 14:37:18 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA19317; Tue, 15 Sep 92 14:47:21 PDT Date: Tue, 15 Sep 92 14:47:21 PDT Message-Id: <9209152147.AA19317@thalidomide.lucid> X-Windows: It could be worse, but it'll take time. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bob_weiner@pts.mot.com Cc: bug-lucid-emacs@lucid.com Subject: Re: SUGGESTION: Permit help strings in menu items. In-Reply-To: Bob Weiner's message of Tue 15-Sep-92 17:17:31 EDT <9209152117.AA22661@pts4.pts.mot.com> References: <9209152117.AA22661@pts4.pts.mot.com> > I'd like to suggest that an optional 4th field be permitted in Lucid Emacs > menu items (or GNU Emacs V19 menus if it has them) which would be a one line > description providing help on the menu item. The string would be > appropriate for display in the echo area and could be accessed by a user > prior to selecting a menu item, for those cases where the item name is not > descriptive enough. I thought about implementing it as an additional slot in the menu description, but I think it might be better to have the modeline simply display the first line of the documentation string of the command which they invoke, as the mouse moves over the menu items. It is already customary that the first line be a single sentence which summarizes the command's behavior for the benefit of apropos. > I've designed menu-based frontends to systems for a number of years now > and this is one feature which most menu systems lack that I find > indispensible. Needless to say, the lispms had it fifteen years ago. -- Jamie From bug-lucid-emacs-request@lucid.com Tue Sep 15 16:19:04 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03269; Tue, 15 Sep 92 16:19:04 PDT Received: by heavens-gate.lucid.com id AA20952g; Tue, 15 Sep 92 16:04:08 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA20948g; Tue, 15 Sep 92 16:03:40 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA22015; Tue, 15 Sep 92 18:15:28 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA06396; Tue, 15 Sep 92 19:03:24 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA22975; Tue, 15 Sep 92 19:15:47 EDT Date: Tue, 15 Sep 92 19:15:47 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9209152315.AA22975@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA09607; Tue, 15 Sep 92 19:15:13 EDT To: bug-lucid-emacs@lucid.com In-Reply-To: Jamie Zawinski's message of Tue, 15 Sep 92 14:47:21 PDT <9209152147.AA19317@thalidomide.lucid> Subject: Re: SUGGESTION: Permit help strings in menu items. Reply-To: bob_weiner@pts.mot.com >> I'd like to suggest that an optional 4th field be permitted in Lucid Emacs >> menu items (or GNU Emacs V19 menus if it has them) which would be a one line >> description providing help on the menu item. The string would be >> appropriate for display in the echo area and could be accessed by a user >> prior to selecting a menu item, for those cases where the item name is not >> descriptive enough. JWZ wrote: > I thought about implementing it as an additional slot in the menu > description, but I think it might be better to have the modeline simply > display the first line of the documentation string of the command which > they invoke, as the mouse moves over the menu items. A couple problems. Visually, this would be distracting as you are walking down a list of items from which you are trying to choose, your attention is continually drawn to the part of the view that is changing, namely the doc strings that are rolling by. Although one could turn it off most likely with a variable, people generally want to say when they want help rather than being continually offered it. > It is already > customary that the first line be a single sentence which summarizes the > command's behavior for the benefit of apropos. True and this could be the default. But if sexpressions are allowed as menu item actions, one would still need an additional doc string. > >> I've designed menu-based frontends to systems for a number of years now >> and this is one feature which most menu systems lack that I find >> indispensible. > > Needless to say, the lispms had it fifteen years ago. Yes, the world is very slow to recognize that which is right rather than that which just is, especially when it comes to technology and organizational processes. Maybe we learn the expression `reinventing the wheel' early in life so that many of us can become good at doing it. Bob From bug-lucid-emacs-request@lucid.com Tue Sep 15 16:35:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03283; Tue, 15 Sep 92 16:35:01 PDT Received: by heavens-gate.lucid.com id AA21019g; Tue, 15 Sep 92 16:23:11 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA21015g; Tue, 15 Sep 92 16:23:00 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA19538; Tue, 15 Sep 92 16:33:04 PDT Date: Tue, 15 Sep 92 16:33:04 PDT Message-Id: <9209152333.AA19538@thalidomide.lucid> X-Windows: You'll envy the dead. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: bob_weiner@pts.mot.com Cc: bug-lucid-emacs@lucid.com Subject: Re: SUGGESTION: Permit help strings in menu items. In-Reply-To: Bob Weiner's message of Tue 15-Sep-92 19:15:47 EDT <9209152315.AA22975@pts4.pts.mot.com> References: <9209152147.AA19317@thalidomide.lucid> <9209152315.AA22975@pts4.pts.mot.com> It's not distracting. Trust me. From bug-lucid-emacs-request@lucid.com Tue Sep 15 17:51:09 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03467; Tue, 15 Sep 92 17:51:09 PDT Received: by heavens-gate.lucid.com id AA21254g; Tue, 15 Sep 92 17:36:09 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA21250g; Tue, 15 Sep 92 17:35:59 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA20339; Tue, 15 Sep 92 18:47:25 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.15-leaf) id AA29742; Tue, 15 Sep 92 18:47:24 -0600 Date: Tue, 15 Sep 92 18:47:24 -0600 From: eeide@asylum.cs.utah.edu (Eric Eide) Message-Id: <9209160047.AA29742@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Subject: blink-paren Blinks Quote The "blink-paren" package that comes with Lucid GNU Emacs 19.3 does not always blink the matching paren. For an expression like this: '(foo) when point is after the closing parenthesis, "blink-paren" blinks the quote, not the opening parenthesis. Also, I dislike the fact that "blink-paren" sets blink-matching-paren to nil. The usual paren-bouncing is still useful, especially when the opening parenthesis is not in the window. ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." From bug-lucid-emacs-request@lucid.com Tue Sep 15 17:54:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03473; Tue, 15 Sep 92 17:54:23 PDT Received: by heavens-gate.lucid.com id AA21277g; Tue, 15 Sep 92 17:42:22 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA21273g; Tue, 15 Sep 92 17:42:09 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA20399; Tue, 15 Sep 92 18:53:35 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.15-leaf) id AA29823; Tue, 15 Sep 92 18:53:34 -0600 Date: Tue, 15 Sep 92 18:53:34 -0600 From: eeide@asylum.cs.utah.edu (Eric Eide) Message-Id: <9209160053.AA29823@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Subject: Some Floats Aren't Readable When I eval 0.4, Lucid GNU Emacs 19.3 prints .4 -- but .4 isn't a readable float. Either .4 should be readable or Lucid should print the float 0.4 as 0.4. ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." From bug-lucid-emacs-request@lucid.com Wed Sep 16 08:29:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05928; Wed, 16 Sep 92 08:29:14 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA22585g; Wed, 16 Sep 92 08:17:10 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25966; Wed, 16 Sep 92 11:28:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25958; Wed, 16 Sep 92 11:28:19 -0400 Path: uunet!olivea!spool.mu.edu!yale.edu!ira.uka.de!chx400!sicsun!disuns2!disuns2.epfl.ch!simon From: simon%lia.di.epfl.ch@lucid.com (Simon Leinen) Newsgroups: alt.lucid-emacs.bug Subject: Problem with TABs under Lucid Emacs 19.3 Message-Id: Date: 16 Sep 92 14:18:28 GMT References: Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne Lines: 12 Nntp-Posting-Host: liasg2.epfl.ch In-Reply-To: simon%lia.di.epfl.ch@lucid.com's message of 14 Sep 92 09:26:12 GMT X-Md4-Signature: d659830e1ab061f6db00f4e7c976aa5d Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article I wrote: * tabs are sometimes displayed incorrectly (as single spaces even at the beginning of a line). The Sun version (compiled by me using GCC) has the same problem. This was actually a problem with my setup - I had set the variable `ctl-arrow' to 1, but this variable is now interpreted in a different way (see C-h v ctl-arrow). If you experience this problem, you should set `ctl-arrow' to e.g. 160. -- Simon. From bug-lucid-emacs-request@lucid.com Wed Sep 16 10:05:27 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06258; Wed, 16 Sep 92 10:05:27 PDT Received: by heavens-gate.lucid.com id AA22943g; Wed, 16 Sep 92 09:50:04 PDT Received: from cs.utah.edu by heavens-gate.lucid.com id AA22938g; Wed, 16 Sep 92 09:49:31 PDT Received: from asylum.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA17826; Wed, 16 Sep 92 11:00:59 -0600 Received: by asylum.cs.utah.edu (5.65/utah-2.15-leaf) id AA12448; Wed, 16 Sep 92 11:00:57 -0600 Date: Wed, 16 Sep 92 11:00:57 -0600 From: eeide@asylum.cs.utah.edu (Eric Eide) Message-Id: <9209161700.AA12448@asylum.cs.utah.edu> To: bug-lucid-emacs@lucid.com Subject: Compiling Lucid GNU Emacs 19.3 on HP9000/400 running BSD 4.3 Last week I compiled Lucid GNU Emacs 19.3 on a Hewlett-Packard 9000/433 running BSD 4.3. This message describes the changes I had to make in order to compile 19.3. (By the way, I had a much easier time compiling 19.3 than I had compiling 19.1. At this rate, 19.4 will be a simple installation indeed!) I used the following configuration files: System file: "s/s-bsd4-3.h" Machine file: "m/m-hp9000s300.h" Defined in "config.h": AMPERSAND_FULL_NAME NEED_REALPATH HAVE_DREM I had the following problems compiling Lucid GNU Emacs 19.3: + My "make" is stupid, as it couldn't figure out to to make "etc/b2m" from "etc/b2m.c". (I had this problem with 19.1, too, of course.) If stupid "make" programs are commonplace, one might want to consider remaining this program. (I hate pandering to stupid systems as much as anybody. But one sometimes has to make a choice between "right" for you and "convenient" for everybody else.) + The C-l's in "src/m/m-hp9000s300.h" found their way into "src/xmakefile", and my "make" barfed on the C-l's. I simply removed the C-l's from the machine description file. + The compilation died compiling "src/events.c" because "union wait" was redefined. This is because my machine description file includes ; "config.h" includes the machine description file; "events.h" includes "config.h"; and finally, "events.c" includes both "config.h" and "events.h". Now I realize that this problem is essentially my system's fault (i.e., it doesn't guard against multiple inclusion of ). However, it doesn't seem like a good idea for Lucid GNU Emacs' code to multiply include "config.h" without protecting "config.h" against multiple inclusion. In any case, I solved this problem by protecting "src/config.h" against multiple inclusion with the usual #ifndef CONFIG_H ... #endif technique. + BIG_ENDIAN is defined by "m/m-hp9000s300.h", but it is later redefined by on my system ( is included by , which is included by "m-hp9000s300.h"). I don't know if this is typical of BSD systems or not. Although the two definitions are different, they are equivalent as far as Lucid GNU Emacs is concerned, so I simply removed the definition of BIG_ENDIAN from "m-hp9000s300.h". + The compilation died compiling "src/sysdep.c" because the include file does not exist on my system. The symbol NEED_BSDTTY is defined in "m/m-hp9000s300.h" but is only needed on HPUX systems (I think). So I moved the directives that define NEED_BSDTTY into the #ifndef BSD4_3 ... #endif part of "m-hp9000s300.h". + Again the compilation died at "src/sysdep.c" because was multiply included (once via my "m-hp9000s300.h" and once directly by "sysdep.c"). I solved this problem by protecting the inclusion of by "sysdep.c" with #ifndef WSTOPPED ... #endif. I made the same change to "src/process.c". Again I realize that this problem is essentially my system's fault because it doesn't guard against multiple inclusion of . But I'm not really sure why "m/m-hp9000s300.h" has to include at all. The other machine description files don't do this; why does mine? If somebody could explain the reason to me, I'd be grateful. + The compilation died compiling "src/process.c" because WAITTYPE was defined incorrectly. "m/m-hp9000s300.h" defined WAITTYPE to b "int" which is not correct for my BSD system. To solve this problem I wrapped the definition of WAITTYPE in "m-hp9000s300.h" within #ifndef BSD4_3 ... #endif. I don't know that BSD4_3 is really the right condition for this; could somebody who really knows tell me what the appropriate condition is? In summary, I was able to solve most of my problems by editing the machine description file "m/m-hp9000s300.h". I also had to guard the "config.h" file against multiple inclusion. I've included my new machine description file at the end of this message. If sombody who really knows the differences between BSD and HPUX could incorporate my changes into the distributed description file, that would be groovy :-). Again, my appreciation to Lucid for a fine product! ------------------------------------------------------------------------------- Eric Eide | University of Utah Department of Computer Science eeide@cs.utah.edu | Buddhist to hot dog vendor: "Make me one with everything." ------------------------------------------------------------------------------- /* m- file for hp9000 series 200 or 300 on either HPUX or BSD. Copyright (C) 1985 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Emacs; see the file COPYING. If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ /* Define this symbol if you are running a version of HP-UX which predates version 6.5 */ /* #define NOMULTIPLEJOBS */ /* Define this symbol if you are running a version of HP-UX which predates version 6.01 */ /* #define HPUX_5 */ /* The following three symbols give information on the size of various data types. */ #define SHORTBITS 16 /* Number of bits in a short */ #define INTBITS 32 /* Number of bits in an int */ #define LONGBITS 32 /* Number of bits in a long */ /* Define BIG_ENDIAN iff lowest-numbered byte in a word is the most significant byte. */ /* ENE: BIG_ENDIAN defined by including , which includes . */ #ifndef UTAH #define BIG_ENDIAN #endif /* Define NO_ARG_ARRAY if you cannot take the address of the first of a * group of arguments and treat it as an array of the arguments. */ /* #define NO_ARG_ARRAY */ /* Define WORD_MACHINE if addresses and such have * to be corrected before they can be used as byte counts. */ /* #define WORD_MACHINE */ /* Define how to take a char and sign-extend into an int. On machines where char is signed, this is a no-op. */ #define SIGN_EXTEND_CHAR(c) (c) /* Now define a symbol for the cpu type, if your compiler does not define it automatically. */ #ifndef hp9000s300 #define hp9000s300 #endif /* Use type int rather than a union, to represent Lisp_Object */ /* This is desirable for most machines. */ #define NO_UNION_TYPE /* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend the 24-bit bit field into an int. In other words, if bit fields are always unsigned. If you use NO_UNION_TYPE, this flag does not matter. */ #define EXPLICIT_SIGN_EXTEND /* Data type of load average, as read out of kmem. */ #define LOAD_AVE_TYPE double /* Convert that into an integer that is 100 for a load average of 1.0 */ #define LOAD_AVE_CVT(x) ((int) ((x) * 100.0)) /* Define CANNOT_DUMP on machines where unexec does not work. Then the function dump-emacs will not be defined and temacs will do (load "loadup") automatically unless told otherwise. */ /* #define CANNOT_DUMP */ /* Define VIRT_ADDR_VARIES if the virtual addresses of pure and impure space as loaded can vary, and even their relative order cannot be relied on. Otherwise Emacs assumes that text space precedes data space, numerically. */ /* #define VIRT_ADDR_VARIES */ /* For University of Utah 4.3bsd implemetation on HP300s. The #ifndef __GNUC__ definitions are required for the "standard" cc, a very old, brain-dead version of PCC. */ #ifdef BSD4_3 /* Tell crt0.c that this is an ordinary 68020. */ #undef hp9000s300 #define CRT0_DUMMIES bogus_a6, #define HAVE_ALLOCA #ifndef __GNUC__ #define LIBS_DEBUG /* don't have -lg that works */ #define C_DEBUG_SWITCH /* don't support -g */ #endif #endif /* BSD4_3 */ #ifndef BSD4_3 /* The following definitions are for HPUX only. */ /* The symbol in the kernel where the load average is found is named _avenrun on this machine. */ #define LDAV_SYMBOL "_avenrun" /* This library is needed with -g, on the 200/300 only. */ #if !defined(__GNUC__) || defined(__HPUX_ASM__) #define LIBS_DEBUG /usr/lib/end.o #endif /* The symbol FIONREAD is defined, but the feature does not work on the 200/300. */ #define BROKEN_FIONREAD /* In older versions of hpux, for unknown reasons, S_IFLNK is defined even though symbolic links do not exist. Make sure our conditionals based on S_IFLNK are not confused. Here we assume that stat.h is included before config.h so that we can override it here. Version 6 of HP-UX has symbolic links. */ #ifdef HPUX_5 #undef S_IFLNK #endif /* Define the BSTRING functions in terms of the sysV functions. Version 6 of HP-UX supplies these in the BSD library. */ /* #ifdef HPUX_5 */ #define bcopy(a,b,s) memcpy (b,a,s) #define bzero(a,s) memset (a,0,s) #define bcmp memcmp /* #endif */ /* On USG systems these have different names. Version 6 of HP-UX supplies these in the BSD library. */ /* #ifdef HPUX_5 */ #define index strchr #define rindex strrchr /* #endif */ /* Define C_SWITCH_MACHINE to be +X if you want the s200/300 * Emacs to run on both 68010 and 68020 based hp-ux's. * * Define OLD_HP_ASSEMBLER if you have an ancient assembler * * Define HPUX_68010 if you are using the new assembler but * compiling for a s200 (upgraded) or s310. 68010 based * processor without 68881. */ /* These switches increase the size of some internal C compiler tables. They are required for compiling the X11 interface files. */ #ifndef HPUX_5 #ifndef __GNUC__ #define C_SWITCH_MACHINE -Wc,-Nd4000,-Ns3000 #endif #endif /* Define NEED_BSDTTY if you have such. */ #ifndef NOMULTIPLEJOBS #define NEED_BSDTTY #endif #endif /* not BSD4_3 */ #ifndef NOT_C_CODE #ifndef NO_SHORTNAMES #include #ifndef BSD4_3 #define WAITTYPE int #endif /* not BSD4_3 */ #endif #define WRETCODE(w) (((w) >> 8) & 0377) #endif From bug-lucid-emacs-request@lucid.com Wed Sep 16 14:04:27 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06887; Wed, 16 Sep 92 14:04:27 PDT Received: by heavens-gate.lucid.com id AA23799g; Wed, 16 Sep 92 13:52:21 PDT Message-Id: <9209162052.AA23799@lucid.com> Received: from vnet.ibm.com by heavens-gate.lucid.com id AA23795g; Wed, 16 Sep 92 13:52:02 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2587; Wed, 16 Sep 92 17:05:39 EDT Date: Wed, 16 Sep 92 13:55:58 PDT From: "Mickey Ferguson" To: BUG-LUCID-EMACS@lucid.com Subject: installation problem OK, this may not be a bug, but something I've missed, but I can't get some things to compile. When I run build-install, I get the following output (this is the second time I tried it, so much of the first time compilations and makes aren't there now because they already worked...) build-install set EMACS=/demo/gnu-emacs/lemacs-19.3 set BIN=/demo/gnu-emacs/lemacs-19.3/bin /bin/sed s;/usr/local/emacs;/demo/gnu-emacs/lemacs-19.3; cd etc make cc -o yow -g yow.c cd src make make -f xmakefile all gcc -O -I/opt1/openwin3/include -Demacs -I./lwlib -c dispnew.c In file included from dispnew.c:72: lisp.h:1213: conflicting types for `malloc' /usr/include/stdlib.h:29: previous declaration of `malloc' lisp.h:1213: conflicting types for `realloc' /usr/include/stdlib.h:33: previous declaration of `realloc' lisp.h:1214: conflicting types for `free' /usr/include/stdlib.h:27: previous declaration of `free' dispnew.c:1745: conflicting types for `abort' /usr/include/stdlib.h:18: previous declaration of `abort' *** Error code 1 make: Fatal error: Command failed for target `dispnew.o' Current working directory /demo/gnu-emacs/lemacs-19.3/src *** Error code 1 make: Fatal error: Command failed for target `doall' exit 1 Can you tell what might be the problem which is causing these procedures to be multiply, and differently, defined? What should I do to fix this? Do you need any other information, such as how I modified my config.h? Thanks for any help you can give me. Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Wed Sep 16 16:37:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07433; Wed, 16 Sep 92 16:37:36 PDT Received: by heavens-gate.lucid.com id AA24125g; Wed, 16 Sep 92 16:25:46 PDT Received: from Princeton.EDU by heavens-gate.lucid.com id AA24121g; Wed, 16 Sep 92 16:25:34 PDT Received: from hhb.UUCP by Princeton.EDU (5.65b/2.93/princeton) id AA14642; Wed, 16 Sep 92 19:36:58 -0400 Received: from brett.master by master (4.1/Redac_Mahwah-v1.0) id AA07891; Wed, 16 Sep 92 17:36:22 EDT Received: by brett.master (4.1/SMI-4.1) id AA14356; Wed, 16 Sep 92 17:36:26 EDT Date: Wed, 16 Sep 92 17:36:26 EDT From: bvk%hhb@Princeton.EDU (Brett Kuehner) Message-Id: <9209162136.AA14356@brett.master> To: lucid.com!bug-lucid-emacs@Princeton.EDU Subject: extra ^M from subprocesses Has anyone gotten shell mode, ange-ftp, or gnuserv to work correctly on a Sparc 2, OS 4.1.1? They all seem to have a problem with spurious ^M (returns) at the end of lines produced by subprocesses. I noticed code in sysdep.c that should set the terminal mode to not do NL to NLCR mapping, and also turn off echoing, but even after I recompiled with this code enabled (by defining HAVE_TERMIO), I still have the same problem. Does anyone have any ideas? Thanks, Brett -- Brett Kuehner, Racal-Redac, Mahwah, NJ ...!princeton!hhb!bvk bvk%hhb@princeton.EDU From bug-lucid-emacs-request@lucid.com Wed Sep 16 18:26:10 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07692; Wed, 16 Sep 92 18:26:10 PDT Received: by heavens-gate.lucid.com id AA24449g; Wed, 16 Sep 92 18:11:10 PDT Received: from bond.crim.ca by heavens-gate.lucid.com id AA24445g; Wed, 16 Sep 92 18:10:56 PDT Received: by bond.crim.ca (4.1/SMI-4.1) id AA08975; Wed, 16 Sep 92 21:22:10 EDT Date: Wed, 16 Sep 92 21:22:10 EDT From: paquette%crim.ca@lucid.com (Marc Paquette) Message-Id: <9209170122.AA08975@bond.crim.ca> To: mickeyf@vnet.ibm.com Cc: BUG-LUCID-EMACS@lucid.com In-Reply-To: "Mickey Ferguson"'s message of Wed, 16 Sep 92 13:55:58 PDT <9209162052.AA23799@lucid.com> Subject: RE: installation problem Mickey Ferguson said : > OK, this may not be a bug, but something I've missed, but I can't get some > things to compile. ( stuff deleted ) > make -f xmakefile all > gcc -O -I/opt1/openwin3/include -Demacs -I./lwlib -c dispnew.c > In file included from dispnew.c:72: > lisp.h:1213: conflicting types for `malloc' > /usr/include/stdlib.h:29: previous declaration of `malloc' > lisp.h:1213: conflicting types for `realloc' I had this also. In a previous message (11 Sep 92 16:15:07 GMT), Christian Lynbech said (refering to using gcc 2): > In order to compile on a sparc, I needed to set `-fno-builtin -traditional' > and -D"const= " since const declarations don't mix well with -traditional. My problems went away by using these flags to gcc. Just put the following line in your src/config.h (near line 196) and you should be fine (regarding this particuliar problem): #define C_SWITCH_SITE -fno-builtin -traditional -D"const= " -I/usr/local/X11/include Note that the "-I/usr/local/X11/include" is for our site, it might be different for you. Hope this helps. Marc Paquette |Centre de recherche informatique de Montreal (CRIM) Conseiller Technique, UN*X | 3744 rue Jean-Brillant, bureau 500 paquette@crim.ca | Montreal (Quebec) Canada H3T 1P1 Tel : (514) 340-5758 | Fax : (514) 340-5777 From bug-lucid-emacs-request@lucid.com Thu Sep 17 06:46:55 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09586; Thu, 17 Sep 92 06:46:55 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA25320g; Thu, 17 Sep 92 06:31:22 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21403; Thu, 17 Sep 92 09:42:51 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA21399; Thu, 17 Sep 92 09:42:50 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!dxcern!dxcern!defert From: defert%gnuisance.cern.ch@lucid.com (Philippe Defert) Subject: beginner's question on lhilit.el Message-Id: Organization: CERN, European Laboratory for Particle Physics Distribution: alt Date: Thu, 17 Sep 1992 14:40:19 GMT Lines: 50 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I am trying to understand the way to make region bold, italic or change colour but have not found the documentation. So this is what is happening in VM mode: - there is the vm-lucid.el as from the distribution - I added the following in my .emacs file: (setq vm-mode-hilit '( ("^From:.*" nil hilit0) ("^Subject:.*" nil hilit2))) (hilit::mode-list-update "VM" vm-mode-hilit) (add-hook 'vm-mode-hooks 'hilit::hilit-buffer) stolen from Michael Lamoureux - when I enter VM the things are happening like decided by vm-lucid.el as from the distribution with bold and italics but everything is black. - when I type "S" to save the folder then the from begins to be red and the subject is blue, but they are not bold or italics any longer... Can somebody explain me ? Thanks. Philippe. -- ************************************************************************ * Philippe Defert: Computing and Networks Division * * CERN, European Laboratory for Particle Physics * ************************************************************************ * Earth mail: | E*mail: * * CERN / CN / CO | defert@dxcern.cern.ch * * CH*1211 Geneve 23. Switzerland. | defert@dxcern.UUCP * * Voice: | defert@dxcern.bitnet * * + 41 22 7673923 | psi%02284681140551::defert * ************************************************************************ * | \ * * D`es que le vent soufflera, | \ * * Je repartira. /| \ * * D`es que les vents tourneront, / | \ * * Nous nous en allerons. /__|_________\ * * \____________/ * ************************************************************************ rom bug-lucid-emacs-request@lucid.com Thu Sep 17 06:46:55 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09588; Thu, 17 Sep 92 06:46:55 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA25319g; Thu, 17 Sep 92 06:31:21 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21393; Thu, 17 Sep 92 09:42:49 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA21384; Thu, 17 Sep 92 09:42:46 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!dxcern!dxcern!defert From: defert%gnuisance.cern.ch@lucid.com (Philippe Defert) Subject: VM hangs all the time Message-Id: Organization: CERN, European Laboratory for Particle Physics Distribution: alt Date: Thu, 17 Sep 1992 14:31:11 GMT Lines: 28 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I saw some days ago people complaining that their mail reader (VM) hung LUCID emacs. I am experimenting the problem. Anybody fixed this problem ? SUN IPX / SunOS 4.1.2 / gcc 2.2.2 / lemacs 19.3 Thanks. Philippe. -- ************************************************************************ * Philippe Defert: Computing and Networks Division * * CERN, European Laboratory for Particle Physics * ************************************************************************ * Earth mail: | E*mail: * * CERN / CN / CO | defert@dxcern.cern.ch * * CH*1211 Geneve 23. Switzerland. | defert@dxcern.UUCP * * Voice: | defert@dxcern.bitnet * * + 41 22 7673923 | psi%02284681140551::defert * ************************************************************************ * | \ * * D`es que le vent soufflera, | \ * * Je repartira. /| \ * * D`es que les vents tourneront, / | \ * * Nous nous en allerons. /__|_________\ * * \____________/ * ************************************************************************ From bug-lucid-emacs-request@lucid.com Thu Sep 17 09:12:04 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10154; Thu, 17 Sep 92 09:12:04 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA25634g; Thu, 17 Sep 92 09:00:15 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA01348; Thu, 17 Sep 92 12:11:42 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA01340; Thu, 17 Sep 92 12:11:10 -0400 Path: uunet!pipex!warwick!uknet!mcsun!sun4nl!tuegate.tue.nl!wim From: wim%boa.es.ele.tue.nl@lucid.com (Wim Philipsen) Newsgroups: alt.lucid-emacs.bug Subject: 19.3 bugs Message-Id: Date: 17 Sep 92 13:54:00 GMT Distribution: alt Organization: /mnt/boa/users/wim/.organization Lines: 20 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have got a problem with the popup menu's. After I had one menu, i always get the same menu. Even when another menu is supposed to popup. The x-set-point-and-insert-selection does not behave as it should. It insert at the click-point the region between the selection beginning and the point. It looks like the set-point is not performed. If I first set the point with the left button it works correctly. system : hp720, hpux 8.07 compiler: hp cc against the X11R5 includes and libraries Any fixes? -- Wim Philipsen wim@es.ele.tue.nl From bug-lucid-emacs-request@lucid.com Thu Sep 17 09:45:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10285; Thu, 17 Sep 92 09:45:21 PDT Received: by heavens-gate.lucid.com id AA25745g; Thu, 17 Sep 92 09:33:18 PDT Received: from bond.crim.ca by heavens-gate.lucid.com id AA25730g; Thu, 17 Sep 92 09:32:24 PDT Received: from fatman.crim.ca by bond.crim.ca (4.1/SMI-4.1) id AA01964; Thu, 17 Sep 92 12:43:49 EDT Received: by fatman.crim.ca (4.1/SMI-4.1) id AA14271; Thu, 17 Sep 92 12:42:37 EDT Date: Thu, 17 Sep 92 12:42:37 EDT From: paquette%fatman.crim.ca@lucid.com (Marc Paquette) Message-Id: <9209171642.AA14271@fatman.crim.ca> To: bug-lucid-emacs@lucid.com Subject: set-screen-menubar missing OR News file out of date ? Comments: Hyperbole mail buttons accepted, v3.05P. In 19.2, there was a function called `set-screen-menubar' which was a subr (defined in src/menubar.c) wich is now extinct as a lisp-callable function. It seems that `set-menubar' is it's new name and it is now a elisp function (defined in lisp/menubar.el). However, the News file still refers to `set-screen-menubar'. Is the oversight in src/menubar.c or in the News file ? Marc Paquette |Centre de recherche informatique de Montreal (CRIM) Conseiller Technique, UN*X | 3744 rue Jean-Brillant, bureau 500 paquette@crim.ca | Montreal (Quebec) Canada H3T 1P1 Tel : (514) 340-5758 | Fax : (514) 340-5777 From bug-lucid-emacs-request@lucid.com Thu Sep 17 11:42:38 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00537; Thu, 17 Sep 92 11:42:38 PDT Received: by heavens-gate.lucid.com id AA26223g; Thu, 17 Sep 92 11:29:36 PDT Received: from lupulus.ssc.gov by heavens-gate.lucid.com id AA26216g; Thu, 17 Sep 92 11:27:50 PDT Received: by lupulus.ssc.gov (5.65c/IDA-1.4.4); Thu, 17 Sep 1992 13:39:19 -0500 Date: Thu, 17 Sep 1992 13:39:19 -0500 From: John Palkovic Message-Id: <199209171839.AA07365@lupulus.ssc.gov> To: bug-lucid-emacs@lucid.com Subject: Supercite 2.2 doesn't work w/ lemacs-19.3 lemacs-19.3 on a Sun IPC running 4.1.1 SunOS. The binaries came from labrea.stanford.edu:/pub/gnu/lucid/lemacs-19.3-sun4.tar.Z. Anyone have this fixed? When replying to a mail message, if I do a mail-yank-original I see: Please designate a region to cite (i.e. set the mark). In the minibuffer. Setting the mark does not help much, I just get Wrong type argument: listp, # Received: from vnet.ibm.com by heavens-gate.lucid.com id AA26300g; Thu, 17 Sep 92 11:51:09 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0804; Thu, 17 Sep 92 15:04:57 EDT Date: Thu, 17 Sep 92 11:48:50 PDT From: "Mickey Ferguson" To: ANDY@CS.CITY.AC.UK, JWZ@lucid.com, PAQUETTE@CRIM.CA, BUG-LUCID-EMACS@lucid.com Subject: Next installation problem (Was: Re: installation problem) First, the winner to the problem I had previously with respect to conflicting types for `malloc' etc. is... Andy Whitcroft. He told me that I have to change the definitions of the functions in stdlib.h to match src/lisp.h. That cleared up that problem. I found a few more which were similar and fixed them, also. Now the problem is with Widget. It's trying to rebuild lwlib.c, and runs into a problem. First, I had to add into the Imakefile the ability to use '.' as another include directory path, since /usr/include/X11 doesn't exist. It's located in another place, so I created a link to it in the lwlib (and also src) directory) and it can now find the X11 include files. But when it's compiling lwlib.c, I get the error "./lwlib.h", line 63: syntax error at or near type word "Widget". The way I see it, it couldn't find the definition for Widget, which then traces back to not knowing the definition for _WidgetRec, which is defined in Core.h and CoreP.h. I just don't know what is the link of include files to add (and for that matter, where to add them - lwlib.h? lwlib.c? some- where else?) to get this stuff to compile. For further info, I am trying to compile this for OLIT since we are running SunOS 4.1.2 and OpenLook 3.0. Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Thu Sep 17 12:18:56 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00684; Thu, 17 Sep 92 12:18:56 PDT Received: by heavens-gate.lucid.com id AA26369g; Thu, 17 Sep 92 12:07:07 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA26359g; Thu, 17 Sep 92 12:04:39 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA01584; Thu, 17 Sep 92 12:13:16 PDT Date: Thu, 17 Sep 92 12:13:16 PDT Message-Id: <9209171913.AA01584@thalidomide.lucid> X-Windows: Don't get frustrated without it. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: "Mickey Ferguson" Cc: ANDY@CS.CITY.AC.UK, BUG-LUCID-EMACS@lucid.com, PAQUETTE@CRIM.CA Subject: Re: Next installation problem (Was: Re: installation problem) In-Reply-To: Mickey Ferguson's message of Thu 17-Sep-92 11:48:50 PDT <9209171851.AA26300@lucid.com> References: <9209171851.AA26300@lucid.com> In message <9209171851.AA26300@lucid.com> Mickey Ferguson wrote: > > Now the problem is with Widget. It's trying to rebuild lwlib.c, and runs > into a problem. First, I had to add into the Imakefile the ability to use > '.' as another include directory path, since /usr/include/X11 doesn't exist. > It's located in another place, so I created a link to it in the lwlib (and > also src) directory) and it can now find the X11 include files. Sounds like you don't have Imake installed correctly. > For further info, I am trying to compile this for OLIT since we are running > SunOS 4.1.2 and OpenLook 3.0. The README says > The OLIT menubar probably still doesn't work. Fixes are welcome, as always. and the src/lwlib/Imakefile says > * The OLIT menubar is not as good as the Motif and Lucid menubars yet. > * It's slow, and possibly buggy. I'd recommend against using it unless > * you'd like to hack on it. -- Jamie From bug-lucid-emacs-request@lucid.com Thu Sep 17 18:17:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01811; Thu, 17 Sep 92 18:17:46 PDT Received: by heavens-gate.lucid.com id AA26223g; Thu, 17 Sep 92 11:29:36 PDT Site: Received: from lupulus.ssc.gov by heavens-gate.lucid.com id AA26216g; Thu, 17 Sep 92 11:27:50 PDT Received: by lupulus.ssc.gov (5.65c/IDA-1.4.4); Thu, 17 Sep 1992 13:39:19 -0500 Date: Thu, 17 Sep 1992 13:39:19 -0500 From: John Palkovic Message-Id: <199209171839.AA07365@lupulus.ssc.gov> To: bug-lucid-emacs@lucid.com Subject: Supercite 2.2 doesn't work w/ lemacs-19.3 lemacs-19.3 on a Sun IPC running 4.1.1 SunOS. The binaries came from labrea.stanford.edu:/pub/gnu/lucid/lemacs-19.3-sun4.tar.Z. Anyone have this fixed? When replying to a mail message, if I do a mail-yank-original I see: Please designate a region to cite (i.e. set the mark). In the minibuffer. Setting the mark does not help much, I just get Wrong type argument: listp, # Received: from vnet.ibm.com by heavens-gate.lucid.com id AA00408g; Thu, 17 Sep 92 18:20:28 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2989; Thu, 17 Sep 92 16:53:22 EDT Date: Thu, 17 Sep 92 13:45:12 PDT From: "Mickey Ferguson" To: PAQUETTE@CRIM.CA, BUG-LUCID-EMACS@lucid.com, ANDY@CS.CITY.AC.UK, JWZ@lucid.com Subject: Re: Next installation problem I can't control how Imake is installed... Our support group is a misnomer. They were a bunch of DOS sysadmins, and now they're trying to run their unix world in the same way. They have moved everything around, and some things aren't where they should be, links are sometimes missing, etc. I have figured out ways to get everything to work, but just haven't figured out the tangled web of the X11 include files for widgets. Yes, I know that the README says that the OLIT menubar probably still doesn't work, and is not as good as the Motif and Lucid menubars, and buggy, etc. I read that to mean that there are some bugs, but not that recompilation wouldn't even work. I figured I could deal with a few bugs, but not in the make stage. Believe it or not, I actually read the notes in both the README and the lwlib/Imakefile! :) Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Thu Sep 17 19:02:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01929; Thu, 17 Sep 92 19:02:29 PDT Received: by heavens-gate.lucid.com id AA26314g; Thu, 17 Sep 92 11:53:21 PDT Site: Message-Id: <9209171853.AA26314@lucid.com> Received: from vnet.ibm.com by heavens-gate.lucid.com id AA26300g; Thu, 17 Sep 92 11:51:09 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0804; Thu, 17 Sep 92 15:04:57 EDT Date: Thu, 17 Sep 92 11:48:50 PDT From: "Mickey Ferguson" To: ANDY@CS.CITY.AC.UK, JWZ@lucid.com, PAQUETTE@CRIM.CA, BUG-LUCID-EMACS@lucid.com Subject: Next installation problem (Was: Re: installation problem) First, the winner to the problem I had previously with respect to conflicting types for `malloc' etc. is... Andy Whitcroft. He told me that I have to change the definitions of the functions in stdlib.h to match src/lisp.h. That cleared up that problem. I found a few more which were similar and fixed them, also. Now the problem is with Widget. It's trying to rebuild lwlib.c, and runs into a problem. First, I had to add into the Imakefile the ability to use '.' as another include directory path, since /usr/include/X11 doesn't exist. It's located in another place, so I created a link to it in the lwlib (and also src) directory) and it can now find the X11 include files. But when it's compiling lwlib.c, I get the error "./lwlib.h", line 63: syntax error at or near type word "Widget". The way I see it, it couldn't find the definition for Widget, which then traces back to not knowing the definition for _WidgetRec, which is defined in Core.h and CoreP.h. I just don't know what is the link of include files to add (and for that matter, where to add them - lwlib.h? lwlib.c? some- where else?) to get this stuff to compile. For further info, I am trying to compile this for OLIT since we are running SunOS 4.1.2 and OpenLook 3.0. Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Thu Sep 17 19:40:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01991; Thu, 17 Sep 92 19:40:23 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA00839g; Thu, 17 Sep 92 19:28:49 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA06627; Thu, 17 Sep 92 22:40:19 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA06623; Thu, 17 Sep 92 22:40:18 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!UB.com!daver!qedinc!rac From: rac@qedinc.com (Robert Clark) Subject: FCC output file format Message-Id: <1992Sep17.230121.26019@qedinc.com> Organization: Quantum Effect Design Date: Thu, 17 Sep 1992 23:01:21 GMT Lines: 13 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Files created by lemacs19.2 when requesting a 'FCC' are not in the proper format to ne read by rmail. FCC: Files created by emacs18.58 are read without a problem in lemacs19.2 I'm not an elisp hacker, but I think the problem is in rmail.el. Bob Clark; (408) 456-2382 Quantum Effect Design, Inc. 2670 Seeley Avenue, San Jose, CA 95134 Internet: rac@qedinc.com UUCP: decwrl.dec.com!daver!qedinc!rac From bug-lucid-emacs-request@lucid.com Fri Sep 18 06:28:20 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03827; Fri, 18 Sep 92 06:28:20 PDT Received: by heavens-gate.lucid.com id AA01650g; Fri, 18 Sep 92 06:16:52 PDT Received: from rip.hrb.com by heavens-gate.lucid.com id AA01644g; Fri, 18 Sep 92 06:15:03 PDT Received: from ICF2.HRB.COM by rip.hrb.com (PMDF #2315 ) id <01GOXB78C68G000FIA@rip.hrb.com>; Fri, 18 Sep 1992 09:26:24 EST Received: from icf.hrb.com by icf.hrb.com (PMDF #2315 ) id <01GOXAQITB3KLLX2T4@icf.hrb.com>; Fri, 18 Sep 1992 09:25:57 EST Date: 18 Sep 1992 09:25:56 -0500 (EST) From: "Eric L. Schott" Subject: Lemacs 19.3 Crashes DEC Window Manager To: bug-lucid-emacs@lucid.com Message-Id: <01GOXAQITKQQLLX2T4@icf.hrb.com> X-Vms-To: IN%"bug-lucid-emacs@lucid.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Lemacs 19.3 crashes DECwindows windows manager with relative consistancy. CONFIGURATION: Lemacs 19.3 compiled with gcc2.2.2 on and running on a SPARCstation (SunOS 4.1.1) as an X client (using Openwindows 3 for X). FAILURE MODE: When using either a VAXstation (DECwindows) or a VXT-2000 as the X server, the server crashes approximately 60% of the time when Lemacs exits. NOTES: 1. This admittedly seems to be a problem with DECwindows (not lemacs). 2. Lemacs 19.2 did not cause such crashes. 3. I will attempt to report problem to DEC. --- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" From bug-lucid-emacs-request@lucid.com Fri Sep 18 06:54:05 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03903; Fri, 18 Sep 92 06:54:05 PDT Received: by heavens-gate.lucid.com id AA01694g; Fri, 18 Sep 92 06:42:30 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA01687g; Fri, 18 Sep 92 06:39:48 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA29691; Fri, 18 Sep 1992 15:51:04 +0200 (MET) Received: from geant.cenatls.cena.dgac.fr by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA28077; Fri, 18 Sep 92 15:53:04 +0200 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA28031; Fri, 18 Sep 92 15:50:28 +0200 Date: Fri, 18 Sep 92 15:50:28 +0200 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9209181350.AA28031@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02238; Fri, 18 Sep 92 15:50:27 +0200 To: Bug Lucid Emacs Subject: The Ever Lasting Bug: undo capitalization and the modified flag. [ I resubmit it, as it still happens in 19.3 as in 19.2 and 19.1. I am longing for 19.4 to see if it's still there :-) ] Undo doesn't reset the modified flag after capitalization functions. Load a standard text file, do a M-c (M-x capitalize-word), then C-x u. The capitalization is undone, but the modified flag stays. The same thing happens with upcase-word, downcase-word, upcase-region and friends. Configuration: lemacs 19.3 compiled with gcc 2.2.2 on SS2 sunos4.1.1. Phil PS: I know it's a tiny bug, but I like it because it allows me to report at least one bug with each new version of Lucid Emacs. From bug-lucid-emacs-request@lucid.com Fri Sep 18 09:44:09 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04333; Fri, 18 Sep 92 09:44:09 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02124g; Fri, 18 Sep 92 09:32:30 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25526; Fri, 18 Sep 92 12:44:03 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25522; Fri, 18 Sep 92 12:43:58 -0400 Path: uunet!mcsun!sun4nl!tuegate.tue.nl!wim From: wim%boa.ele.tue.nl@lucid.com (Wim Philipsen) Newsgroups: alt.lucid-emacs.bug Subject: popup-menu in 19.3 Message-Id: Date: 18 Sep 92 14:13:04 GMT Distribution: alt Organization: /mnt/boa/users/wim/.organization Lines: 24 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com system hp 720 with hpux 8.07 I have the following problem with popup-menus: eval: (popup-menu '("Info" "first" "----")) (popup-menu '("Info" "second" "----")) the first gives a correct menu but the second call produces the same menu as the first one. The argument is neglected after the first call. But: (setq m '("Info" "second" "----")) (popup-menu 'm) will produce a correct menu. Is this aknown problem and are there fixes avaiable? -- Wim Philipsen wim@es.ele.tue.nl From bug-lucid-emacs-request@lucid.com Fri Sep 18 15:54:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA05677; Fri, 18 Sep 92 15:54:00 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA03383g; Fri, 18 Sep 92 15:42:30 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15710; Fri, 18 Sep 92 18:54:03 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15706; Fri, 18 Sep 92 18:54:02 -0400 Path: uunet!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: ^X-5, focus and screen selection. Message-Id: Date: 18 Sep 92 11:13:47 GMT Distribution: alt Organization: Human Communication Research Center Lines: 20 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com (This is 19.2) When I ^X-5 lemacs creates a new screen and directs my input to it. This is incredably irritating, but that is a missfeature, not a bug. However, it seems to do this in some way which does not get the focus over there properly. lemacs's cursor does not highlight and tvtwm doesn't get focus events to shift the focus decoration over. In fact, no screen has lemacs's cursor highlighted and the screen I was in when I typed ^X-5 seems to still have the focus. If I click on the old window I get an out of range error. I think lucid emacs thinks I am in the new window and does an XQueryPointer and gets an out of range coordinate. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Mon Sep 21 08:21:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00891; Mon, 21 Sep 92 08:21:34 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA05011g; Sat, 19 Sep 92 09:05:52 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25296; Sat, 19 Sep 92 12:06:27 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25292; Sat, 19 Sep 92 12:06:26 -0400 Path: uunet!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Newsgroups: alt.lucid-emacs.bug Subject: Re: Supercite 2.2 doesn't work w/ lemacs-19.3 Message-Id: <1992Sep19.152058.16014@daimi.aau.dk> Date: 19 Sep 92 15:20:58 GMT References: <199209171839.AA07365@lupulus.ssc.gov> Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Lines: 60 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com john_palkovic@ssc.gov (John Palkovic) writes: >lemacs-19.3 on a Sun IPC running 4.1.1 SunOS. The binaries came from >labrea.stanford.edu:/pub/gnu/lucid/lemacs-19.3-sun4.tar.Z. >Anyone have this fixed? When replying to a mail message, if I do a >mail-yank-original I see: > Please designate a region to cite (i.e. set the mark). >In the minibuffer. Setting the mark does not help much, I just get > Wrong type argument: listp, #-John > Why wouldn't an enhanced deterrent, a more stable peace, a better > prospect to denying the ones who enter conflict in the first place > to have a reduction of offensive systems and an introduction to > defensive capability. I believe that is the route this country > will eventually go. > -- Vice President Dan Quayle As V19 is a major upgrade, incompabilities must be expected. First of all, it is necessary to recompile all lisp-files. Using V18 .elc in V19 can lead to obscure bugs, that will go away when recompiling. If this does not solve it, you must prepare yourself that the code is broken. Pull out your friendly debugger (set debug-on-error to something other than nil), load the .el files (makes the backtrace more readable) and start over. If it is as simple as the following suggestion to your problem, the old debugger should be sufficient, but remember that Lucid comes with an advanced source-level debugger. Chack the info system under edebug. In the above mentioned problem, the cause can the changes to the handling of marks. Another package I was using, had a call to the mark function in order to retrieve the mark. But this will return nil when zmacs-regions is t (the default). Being new to Lucid, I won't make any predictions on what happens by setting this to nil. The alternative is (assuming that this really is the problem) to hunt down the `(mark)' calls and replace them with `(mark t)' As I have supercite myself, I may look into this, but other things are higher on my agenda for the time being. ------------------------------------------------------------------------------ Christian Lynbech DAIMI office: R0.32 phone: 5034 University of Aarhus,DK-Denmark email: lynbech@daimi.aau.dk ------------------------------------------------------------------------------ EMACS, The One True Editor Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From bug-lucid-emacs-request@lucid.com Mon Sep 21 09:39:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01308; Mon, 21 Sep 92 09:39:36 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA07644g; Mon, 21 Sep 92 09:38:39 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA16962; Mon, 21 Sep 92 12:39:08 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA16958; Mon, 21 Sep 92 12:39:06 -0400 Path: uunet!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Newsgroups: alt.lucid-emacs.bug Subject: floatingpoints on HP's (sort of SOLVED) Message-Id: <1992Sep21.123359.23682@daimi.aau.dk> Date: 21 Sep 92 12:33:59 GMT Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Lines: 151 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have the made a little fix to enable floatingpoints on hp's. I have succesfully compiled it for hp9000s700 and hp9000s300 and have tested it on the 700 with the blink-paren package. It should however be general enough to run elsewhere. The patch fixes floatfns.c and adds a new file, floathp.h One must make sure that LISP_FLOAT_TYPE is defined in config.h Also, one could change the ymakefile to include floathp.h in the dependency list for floatfns.c ------------------------------------------------------------------------------ Christian Lynbech DAIMI office: R0.32 phone: 5034 University of Aarhus,DK-Denmark email: lynbech@daimi.aau.dk ------------------------------------------------------------------------------ EMACS, The One True Editor Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) -----------8<--------------8<---------------8<--------------------------- diff -c -r lemacs-19.3/src/floatfns.c lemacs-19.3.new/src/floatfns.c *** lemacs-19.3/src/floatfns.c Sun Aug 30 04:09:00 1992 --- lemacs-19.3.new/src/floatfns.c Sat Sep 19 15:25:05 1992 *************** *** 28,33 **** --- 28,40 ---- #ifdef LISP_FLOAT_TYPE #include + #if defined(__hpux) + /* HP seems to be missing a number fancy float funcs. + * floathp.h defines aliases for those missing. + */ + #include "floathp.h" + #endif + /* Nonzero while executing in floating point. This tells float_error what to do. */ diff -c -r lemacs-19.3/src/floathp.h lemacs-19.3.new/src/floathp.h *** lemacs-19.3/src/floathp.h Mon Sep 21 12:33:17 1992 --- lemacs-19.3.new/src/floathp.h Mon Sep 21 12:40:04 1992 *************** *** 0 **** --- 1,93 ---- + /* lynbech@daimi.aau.dk + * This file is hereby placed in the public domain + */ + + /*** + NAME + floathp + PURPOSE + Adding emulation for missing floating point functions + NOTES + This is a very basic and simple implementation. Somebody probably + could do this better. + Lookout for the definition of rint(). This is not exactly correct. + Also note that I'm not experienced in floating-point C, so I + will NOT guarantee that none of the following expressions + never will fail due to rounding quirks. Nor do I use a lot of + floating-point emacs lisp, so any bugs may not surface for me + for a long time. + HISTORY + lynbech - Sep 19, 1992: Created. + ***/ + + #ifndef FLOATHP + #define FLOATHP + + + double + acosh (d) + double d; + { + return log(d + sqrt(d*d - 1.0)); + } + + double + asinh (d) + double d; + { + return log(d + sqrt(d*d + 1.0)); + } + + double + atanh (d) + double d; + { + return 0.5 * log((1.0+d) / (1.0-d)); + } + + double + cbrt (d) + double d; + { + return pow(d,-3); + } + + double + expm1 (d) + double d; + { + return exp(d)-1.0; + } + + double + log1p (d) + double d; + { + return log(1.0 + d); + } + + double + logb (d) + double d; + { + return log(d) / log(2.0); + } + + double + rint (d) + double d; + { + /* + * fix rounding direction, which is not quite what rint() seems to be + * about, but in order to get this up and running, this should be OK. + * According to the SUN manpages rint() is supposed to find the closest + * integral according to the current IEEE rounding direction. This + * always rounds downwards. + */ + + return floor(d); + } + + + + #endif /* FLOATHP */ From bug-lucid-emacs-request@lucid.com Tue Sep 22 11:28:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07632; Tue, 22 Sep 92 11:28:29 PDT Received: by heavens-gate.lucid.com id AA02126g; Tue, 22 Sep 92 11:27:55 PDT Received: from ingr.ingr.com by heavens-gate.lucid.com id AA02106g; Tue, 22 Sep 92 11:25:31 PDT Received: from matis.UUCP by ingr.ingr.com (5.65c/1.920611) id AA08292; Tue, 22 Sep 1992 13:25:36 -0500 Received: from simpson.ingr.com by turtles (4.1/SMI-4.1) id AA12627; Tue, 22 Sep 92 19:18:50 IST Received: by simpson.ingr.com (4.1/SMI-4.1) id AA16303; Tue, 22 Sep 92 19:17:58 IST From: matis!amir@lucid.com (Amir J Katz) Message-Id: <9209221717.AA16303@simpson.ingr.com> Subject: 19.3 hangs when creating new screens? To: help-lucid-emacs@lucid.com (Lucid Emacs help M.L.) Date: Tue, 22 Sep 92 19:17:56 EET Cc: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.), jwz@lucid.com (Jamie Zawinski) Organization: SEE Technologies Ltd. Reply-To: matis!amir@lucid.com X-Reply-To: amir@matis.ingr.COM X-Mailer: ELM [version 2.3 PL11] [This is a repost - I have not received anything] Guys, I've built Lucid Emacs 19.3, and the following functions (suggested recently by someone on the list) hang lemacs. A new screen is opened, but then lemacs goes to sleep and never comes back. Any idea? Thanks in advance. BTW, sometimes even 'C-x 5' (x-new-screen) hangs lemacs. My configuration is: SparcStation 1+ w/SunOS 4.1.3 gcc 2.2.2 MIT X11R5, patch 17 --------------------------------------- (defun x-find-file (filename) "Does find file in new X Window" (interactive "Ffind file new screen: ") (select-screen (x-create-screen nil)) (switch-to-buffer (find-file-noselect filename))) (defun y-find-file (filename) "Does find file in new X Window" (interactive) (select-screen (x-create-screen nil)) (switch-to-buffer (find-file-noselect filename))) (defun find-dot-emacs () (interactive) (y-find-file "~/.emacs") ) ;; add new item to existing menu (add-menu-item '("File") "Find File New Screen" 'x-find-file t) ;; add a new menu (add-menu-item '("--Dot Files--") ".emacs" 'find-dot-emacs t) --------------------------------------- -- /* ----------------------------------------------------------- */ /* Amir J. Katz | amir@matis.ingr.COM */ /* System Specialist | Voice: +972 52-584684 */ /* SEE Technologies Ltd. | Fax: +972 52-543917 */ /* ............ Solaris 2.0 - The Final Frontier ? ........... */ From bug-lucid-emacs-request@lucid.com Tue Sep 22 12:25:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07826; Tue, 22 Sep 92 12:25:35 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02328g; Tue, 22 Sep 92 12:25:18 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA05710; Tue, 22 Sep 92 15:25:59 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA05704; Tue, 22 Sep 92 15:25:56 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!utcsri!torn!cunews!nrcnet0!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Specifying sizes for screens doesn't appear to work. Message-Id: <1992Sep22.185623.1903@bmerh85.bnr.ca> Lines: 51 Organization: Bell Northern Research Date: Tue, 22 Sep 92 18:56:23 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have been trying to create a screen with a specific number of rows and columns using lucid emacs version 19.3 compiled on an HP9000s425 running H-pukes 7.05. None of the following have worked properly: (x-create-screen '((width . 80) (height . 10))) (x-create-screen '((geometry . "80x10"))) (x-create-screen '(("width" . 80) ("height" . 10))) ;; *NOTE below (x-create-screen '(("geometry" . "80x10"))) Note: Specifying "width" and "height" in the alist creates a screen which tries to be 80 pixels wide and 10 pixels high. This is not what is desired. I want it to be 80 *characters* wide and 10 *characters* high. I think that this may be due to the fact that in ScreenWidget.c, set_screen_size is called from EmacsScreenInitialize, but is not called in EmacsScreenRealize. I'm no X Intrinsics/Toolkit expert, but the I believe that the following is what happens. In xfns.c, in function x_create_widgets, EmacsScreenInitialize gets called indirectly due to the XtCreateWidget call to create an instance of the emacsScreenWidgetClass class. This causes set_screen_size to be called. Then in x_create_widgets, x_set_screen_values is called to transfer any of the good stuff in the alist passed to x-create-screen from the alist to the instance of the emacs widget. Then XtRealizeWidget is called to realize the widget. At this point, the size of the emacs widget has already been set to a default value when set_screen_size was called in EmacsScreenInitialize. Unfortunately, since set_screen_size is not called again after setting the parameters (such as geometry), the default size is used when the widget is realized. Perhaps the call to set_screen_size should be delayed until after the screen values have been set. This would involve moving it from EmacsScreenInitialize to EmacsScreenRealize. Comments? From bug-lucid-emacs-request@lucid.com Wed Sep 23 01:10:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09642; Wed, 23 Sep 92 01:10:30 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA03843g; Wed, 23 Sep 92 01:09:28 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA22995; Wed, 23 Sep 92 04:10:11 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA22991; Wed, 23 Sep 92 04:10:09 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Subject: Anybody else working on selective displays ? Message-Id: <1992Sep23.075918.29522@daimi.aau.dk> Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Date: Wed, 23 Sep 92 07:59:18 GMT Lines: 33 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I have looked at little into the missing selective display feature, trying the obvious of un-un-def'fing (nice word, eh) the relevant part (ignoring the integer case). It seemed to work, for a brief moment. But as soon as I tried to move the cursor, it became apparent that something in cursor-motion is not correct. The cursor jumps to far. I couldn't find no apparent correlation for the extra skip, but it seemed that the cursor-position is in fact correct, because redisplaying with ^L would place the cursor correctly. All this only applies when the motions did not cause the screen to scroll. I have tried debugging the stuff, but the display code is pretty complex for a newcomer like me. Is anybody else working on this, or has any ideas/observations to share ? ------------------------------------------------------------------------------ Christian Lynbech DAIMI office: R0.32 phone: 5034 University of Aarhus,DK-Denmark email: lynbech@daimi.aau.dk ------------------------------------------------------------------------------ EMACS, The One True Editor Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From bug-lucid-emacs-request@lucid.com Wed Sep 23 04:23:01 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10599; Wed, 23 Sep 92 04:23:01 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA04001g; Wed, 23 Sep 92 04:22:35 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA06758; Wed, 23 Sep 92 07:23:17 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA06754; Wed, 23 Sep 92 07:23:15 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ubc-cs!fornax!bremner From: bremner%cs.sfu.ca@lucid.com (David Bremner) Subject: infinite-loop in splice_extant_into_buffer? Message-Id: <1992Sep22.235734.8372@cs.sfu.ca> Reply-To: bremner%cs.sfu.ca@lucid.com (David Bremner) Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada Date: Tue, 22 Sep 1992 23:57:34 GMT Lines: 44 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com lemacs-19.3 seemed to have gone comatose on me, so I killed it with a SEGV and started poking around with GDB. (gdb) bt #0 0xb2648 in splice_extent_into_buffer (extent=0x210d1c, buffer=473649152) at extents.c:540 #1 0xb2a20 in make_extent_internal (from=750, to=766, buffer=473649152, ext=0x0) at extents.c:610 #2 0xb40e8 in Fmake_extent (from=750, to=766, buffer=473649152) at extents.c:1414 ... (gdb) list 535 { 536 prev = tmp; 537 while (prev && !EXTENT_E_LESS_VALS (prev, start, end)) 538 { 539 tmp = prev; 540 prev = tmp->e_previous; 541 } 542 } 543 544 if (!tmp && !prev) (gdb) print tmp $1 = (struct extent *) 0x210d44 (gdb) print *tmp $2 = {flags = 0, secondary_type = 0, start = 128427, end = 128466, next = 0x210d44, previous = 0x210d44, e_next = 0x210d1c, e_previous = 0x210d6c, attr_index = 9, buffer = 473649152, user_data = 69587828} It seems to me that this loop is going to run a looong time. Anybody have any clever ideas on how to pursue this? David -- bremner@cs.sfu.ca ubc-cs!fornax!bremner From bug-lucid-emacs-request@lucid.com Wed Sep 23 08:37:33 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11382; Wed, 23 Sep 92 08:37:33 PDT Received: by heavens-gate.lucid.com id AA04492g; Wed, 23 Sep 92 08:37:10 PDT Received: from lupulus.ssc.gov by heavens-gate.lucid.com id AA04488g; Wed, 23 Sep 92 08:36:58 PDT Received: by lupulus.ssc.gov (5.65c/IDA-1.4.4); Wed, 23 Sep 1992 10:37:37 -0500 Date: Wed, 23 Sep 1992 10:37:37 -0500 From: John Palkovic Message-Id: <199209231537.AA22828@lupulus.ssc.gov> To: bug-lucid-emacs@lucid.com Subject: vm-visit-folder hangs xemacs 19.3 SunOS 4.1.1 IPC, xemacs 19.3 built with gcc 2.2.2. Xemacs hangs when I do a vm-visit-folder on a folder containing a mail digest *and* the messages which result when I 'burst' the digest with '*' in vm. The From lines in the folder are like so: lupulus% grep '^From ' ysn.in From ysn-adm@zoyd.ee.washington.edu Wed Sep 23 05:59:13 1992 From Wed Sep 23 09:10:26 1992 From Wed Sep 23 09:10:26 1992 From Wed Sep 23 09:10:26 1992 From Wed Sep 23 09:10:26 1992 When I vm-visit-folder the same folder from an instance of emacs 18.58 using vm 5.31beta, it works swimmingly. Running edebug, I see that it is hanging when vm-bobble-bookmark calles vm-goto-message. Here is a backtrace: (gdb) bt #0 re_match_2 (pbufp=(struct re_pattern_buffer *) 0x201960, string1=(unsigned char *) 0x47184c "From Wed Sep 23 09:10:26 1992\nStatus: O\nX-VM-v5-Data: ([nil t nil nil nil nil nil nil nil]\n\t[nil nil nil nil nil nil nil nil nil nil nil nil \"^From:\" nil nil nil])\nFrom: au195@cleveland.Freenet.Edu ("..., size1=0, string2=(unsigned char *) 0x47184c "From Wed Sep 23 09:10:26 1992\nStatus: O\nX-VM-v5-Data: ([nil t nil nil nil nil nil nil nil]\n\t[nil nil nil nil nil nil nil nil nil nil nil nil \"^From:\" nil nil nil])\nFrom: au195@cleveland.Freenet.Edu ("..., size2=3262, pos=3262, regs=(struct re_registers *) 0x202cd8, mstop=3262) (regex.c line 1379) 1379 goto nofinalize; #1 0x71fb4 in Flooking_at (string=204505536) (search.c line 152) #2 0x8ee3c in Ffuncall (nargs=2, args=(int *) 0xf7ffd730) (eval.c line 1805) #3 0xa8f64 in Fbyte_code (...) (...) #4 0x8f710 in funcall_lambda (fun=405857312, nargs=2, arg_vector=(int *) 0xf7ffd9a4) (eval.c line 1969) #5 0x8ef90 in Ffuncall (nargs=3, args=(int *) 0xf7ffd9a0) (eval.c line 1836) #6 0xa8f64 in Fbyte_code (...) (...) #7 0x8f710 in funcall_lambda (fun=405680512, nargs=0, arg_vector=(int *) 0xf7ffdc0c) (eval.c line 1969) #8 0x8ef90 in Ffuncall (nargs=1, args=(int *) 0xf7ffdc08) (eval.c line 1836) #9 0xa8f64 in Fbyte_code (...) (...) #10 0x8f710 in funcall_lambda (fun=405681472, nargs=1, arg_vector=(int *) 0xf7ffddc0) (eval.c line 1969) #11 0x8f32c in apply_lambda (fun=405681472, args=338335436, eval_flag=1) (eval.c line 1900) #12 0x8decc in Feval (form=338335308) (eval.c line 1441) #13 0x8c894 in Fcondition_case (args=340180548) (eval.c line 968) #14 0xa9828 in Fbyte_code (...) (...) #15 0x8f710 in funcall_lambda (fun=405486176, nargs=0, arg_vector=(int *) 0xf7ffe30c) (eval.c line 1969) #16 0x8ef90 in Ffuncall (nargs=1, args=(int *) 0xf7ffe308) (eval.c line 1836) #17 0xa8f64 in Fbyte_code (...) (...) #18 0x8ddd4 in Feval (form=338526508) (eval.c line 1418) #19 0x8afa0 in Fprogn (args=338526620) (eval.c line 291) #20 0x1cc80 in Fsave_window_excursion (...) (...) #21 0xa9764 in Fbyte_code (...) (...) #22 0x8f710 in funcall_lambda (fun=405484224, nargs=2, arg_vector=(int *) 0xf7ffe89c) (eval.c line 1969) #23 0x8ef90 in Ffuncall (nargs=3, args=(int *) 0xf7ffe898) (eval.c line 1836) #24 0xa8f64 in Fbyte_code (...) (...) #25 0x8f710 in funcall_lambda (fun=405484960, nargs=2, arg_vector=(int *) 0xf7ffeafc) (eval.c line 1969) #26 0x8ef90 in Ffuncall (nargs=3, args=(int *) 0xf7ffeaf8) (eval.c line 1836) #27 0x8e584 in Fapply (nargs=2, args=(int *) 0xf7ffebf0) (eval.c line 1552) #28 0x8e638 in apply1 (fn=69408328, arg=340183164) (eval.c line 1578) #29 0x89108 in Fcall_interactively (...) (...) #30 0x4cd38 in Fcommand_execute (...) (...) #31 0x4d080 in Fexecute_extended_command (...) (...) #32 0x8ee3c in Ffuncall (nargs=2, args=(int *) 0xf7fff188) (eval.c line 1805) #33 0x8a130 in Fcall_interactively (...) (...) #34 0x4cd38 in Fcommand_execute (...) (...) #35 0x24d34 in dispatch_command_event_internal (...) (...) #36 0x249a0 in compose_command (...) (...) #37 0x234e0 in dispatch_event_internal (...) (...) #38 0x2512c in Fdispatch_event (...) (...) #39 0x4ca58 in command_loop_1 (...) (...) #40 0x8c9c4 in internal_condition_case (bfun=(int (*)()) 0x4c814 , handlers=69245212, hfun=(int (*)()) 0x4c0bc ) (eval.c line 1002) #41 0x4c550 in command_loop_2 (...) (...) #42 0x8c380 in internal_catch (tag=69245192, func=(int (*)()) 0x4c528 , arg=69244932) (eval.c line 814) #43 0x4c4f8 in command_loop (...) (...) #44 0x4beec in recursive_edit_1 (...) (...) #45 0x4c010 in Frecursive_edit (...) (...) #46 0x4b574 in main (...) (...) (gdb) quit The program is running. Quit anyway? (y or n) y -John I should have caught the mistake on that spelling bee card. But as Mark Twain once said, 'You should never trust a man who has only one way to spell a word.' -- Vice President Dan Quayle, actually quoting from President Andrew Jackson. From bug-lucid-emacs-request@lucid.com Wed Sep 23 16:23:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA12849; Wed, 23 Sep 92 16:23:25 PDT Received: by heavens-gate.lucid.com id AA05927g; Wed, 23 Sep 92 16:22:09 PDT Message-Id: <9209232322.AA05927@lucid.com> Received: from vnet.ibm.com by heavens-gate.lucid.com id AA05923g; Wed, 23 Sep 92 16:21:59 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2755; Wed, 23 Sep 92 19:25:03 EDT Date: Wed, 23 Sep 92 16:15:23 PDT From: "Mickey Ferguson" To: BUG-LUCID-EMACS@lucid.com, JWZ@lucid.com Subject: Using OLIT for Lucid I've fixed any number of problems, mostly due to our funny configuration, to get everything to compile for the OLIT setup. My only remaining problem in getting it up (aside from bugs which I may run into later) is that I'm getting an undefined symbol when it tries to link the lwlib.a. Actually, I was getting two of them until I looked in lwlib-Xol.c and found it was trying to reference a procedure called xol_pop_instance, but in the code it was defined as xlw_pop_instance. I fixed that, and it got rid of that error, but I don't know where resource_string should be. Maybe it's another name error? Maybe it should be pre-defined in a library (which one)? Any other ideas where I might look? Thanks in advance. Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Thu Sep 24 04:23:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14800; Thu, 24 Sep 92 04:23:41 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA06835g; Thu, 24 Sep 92 04:23:20 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA01978; Thu, 24 Sep 92 07:24:03 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA01969; Thu, 24 Sep 92 07:24:01 -0400 Path: uunet!mcsun!sun4nl!tuegate.tue.nl!wim From: wim%boa.es.ele.tue.nl@lucid.com (Wim Philipsen) Newsgroups: alt.lucid-emacs.bug Subject: selecting deleted buffer Message-Id: Date: 24 Sep 92 10:50:26 GMT Distribution: alt Organization: /mnt/boa/users/wim/.organization Lines: 17 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com If I do this: get a fresh emacs, and make a new screen. Visit the same file in both buffers. Now iconize one screen, and kill the buffer in the other screen. lemacs will start beeping with the message: selecting deleted buffer I haven't found a way out of it. Is this a common problem and/or fixes? -- Wim Philipsen wim@es.ele.tue.nl From bug-lucid-emacs-request@lucid.com Thu Sep 24 05:55:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14948; Thu, 24 Sep 92 05:55:21 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA06912g; Thu, 24 Sep 92 05:55:02 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07278; Thu, 24 Sep 92 08:55:47 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07274; Thu, 24 Sep 92 08:55:46 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Subject: lisp distribution bug Message-Id: <1992Sep24.123635.5470@daimi.aau.dk> Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Date: Thu, 24 Sep 92 12:36:35 GMT Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com There is a little silly bug in the lisp/calendar directory. The file holiday.el should be named holidays.el ^ One could of course change the two autoloads in diary.el but that would be out of sync with the V18 distribution (at least the one I have) of the calendar package. Christian Lynbech From bug-lucid-emacs-request@lucid.com Thu Sep 24 13:59:35 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA16725; Thu, 24 Sep 92 13:59:35 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08018g; Thu, 24 Sep 92 13:59:14 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA07503; Thu, 24 Sep 92 16:59:59 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA07499; Thu, 24 Sep 92 16:59:58 -0400 Path: uunet!utcsri!torn!cunews!dgbt!netfs!ub!zaphod.mps.ohio-state.edu!darwin.sura.net!dtix!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Help build 19.3 on hpux Message-Id: Date: 24 Sep 92 18:26:51 GMT Organization: COMSAT Labs Lines: 22 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: 94b67ea5de8d82e90bce133850c85ef6 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I am trying to build lemacs-19.3 on hpux8.07/hp9000s700. I have only had minor problems until I came to environ.c. Since including declares extern char *getenv(const char *); There is a conflict with emacs's own version of getenv which is defined: char * getenv (str) register unsigned char *str; Has anyone fixed this (without breaking other things)??? The same kind of nastiness occurs because in s-hpux8.h we had #define rand lrand48 #define srand srand48 Defining the 4-byte sequence "rand" causes trouble when #including . For now I just removed these #defines. Anyone else gotten any farther? From bug-lucid-emacs-request@lucid.com Thu Sep 24 16:43:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17249; Thu, 24 Sep 92 16:43:17 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08757g; Thu, 24 Sep 92 16:42:13 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15360; Thu, 24 Sep 92 19:42:52 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15355; Thu, 24 Sep 92 19:42:44 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!utcsri!torn!cunews!nrcnet0!bnrgate!bcars6a8!bcars68a!jsparkes From: jsparkes%bcars68a.bnr.ca@lucid.com (Jeff Sparkes) Subject: default-menubar vs. current-menubar and local menus Message-Id: <1992Sep24.230902.27047@bcars6a8.bnr.ca> Nntp-Posting-Host: bcars68a Organization: Bell-Northern Research Ltd., Ottawa References: <7173485518-317828@dec4.wu-wien.ac.at> Date: Thu, 24 Sep 1992 23:09:02 GMT Lines: 14 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com With the advent of buffer-local menus, a number of packages now use default-menubar instead of current-menubar to construct their buffer local menus. I consider this a bug since my personalized additions to the menus then disappear. I can mess around with the default-menubar variable, but that could be dangerous in terms of upward compatibility. Perhaps there should be an add-default-menu-item which also alters the default-menubar variable. It seems that the whole menu interface is a little clunky right now that local menus have been added. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 "For better gas mileage, do not drive with the parking brake on." - paraphrased from the owners manual of my Integra. From bug-lucid-emacs-request@lucid.com Thu Sep 24 17:46:36 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17517; Thu, 24 Sep 92 17:46:36 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA08940g; Thu, 24 Sep 92 17:46:13 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA17541; Thu, 24 Sep 92 20:46:59 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA17528; Thu, 24 Sep 92 20:46:57 -0400 Path: uunet!charon.amdahl.com!pacbell.com!decwrl!stanford.edu!ames!bionet!raven.alaska.edu!news.u.washington.edu!uw-beaver!june.cs.washington.edu!klaiber From: klaiber@june.cs.washington.edu (Alexander Klaiber) Newsgroups: alt.lucid-emacs.bug Subject: Problem building on DECstation (PMAX) Message-Id: <1992Sep24.230254.8082@beaver.cs.washington.edu> Date: 24 Sep 92 23:02:54 GMT References: Organization: Computer Science & Engineering, U. of Washington, Seattle Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I am trying to build 19.3 on a DECstation 5000/200, running Ultrix 4.2. I selected s/s-bsd4.2 and m/m-pmax.h and tried both the DEC-supplied compiler and gcc-2.2.2. In either case, when I run xemacs, I get this message ad nauseam: xdr_bytes: out of memory Anyone else got this? A workaround? Help much appreciated, Alexander Klaiber klaiber@cs.washington.edu From bug-lucid-emacs-request@lucid.com Thu Sep 24 22:46:46 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18104; Thu, 24 Sep 92 22:46:46 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA09424g; Thu, 24 Sep 92 22:46:23 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25357; Fri, 25 Sep 92 01:47:10 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25353; Fri, 25 Sep 92 01:47:08 -0400 Path: uunet!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!tuegate.tue.nl!wim From: wim%boa.es.ele.tue.nl@lucid.com (Wim Philipsen) Newsgroups: alt.lucid-emacs.bug Subject: selecting deleted buffer Message-Id: Date: 24 Sep 92 10:50:26 GMT Distribution: alt Organization: /mnt/boa/users/wim/.organization Lines: 17 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com If I do this: get a fresh emacs, and make a new screen. Visit the same file in both buffers. Now iconize one screen, and kill the buffer in the other screen. lemacs will start beeping with the message: selecting deleted buffer I haven't found a way out of it. Is this a common problem and/or fixes? -- Wim Philipsen wim@es.ele.tue.nl From bug-lucid-emacs-request@lucid.com Thu Sep 24 22:58:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18120; Thu, 24 Sep 92 22:58:13 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA09437g; Thu, 24 Sep 92 22:57:48 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA25490; Fri, 25 Sep 92 01:58:34 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA25486; Fri, 25 Sep 92 01:58:32 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!math.fu-berlin.de!zrz.tu-berlin.de!cs.tu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!dkuug!daimi!lynbech From: lynbech%daimi.aau.dk@lucid.com (Christian Lynbech) Subject: lisp distribution bug Message-Id: <1992Sep24.123635.5470@daimi.aau.dk> Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Date: Thu, 24 Sep 92 12:36:35 GMT Lines: 11 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com There is a little silly bug in the lisp/calendar directory. The file holiday.el should be named holidays.el ^ One could of course change the two autoloads in diary.el but that would be out of sync with the V18 distribution (at least the one I have) of the calendar package. Christian Lynbech From bug-lucid-emacs-request@lucid.com Fri Sep 25 10:35:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20367; Fri, 25 Sep 92 10:35:13 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10581g; Fri, 25 Sep 92 10:34:39 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09015; Fri, 25 Sep 92 13:35:25 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09011; Fri, 25 Sep 92 13:35:24 -0400 Path: uunet!europa.asd.contel.com!darwin.sura.net!mojo.eng.umd.edu!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Re: DEL key on HPUX Message-Id: Date: 25 Sep 92 15:46:04 GMT References: Organization: COMSAT Labs Lines: 5 Nntp-Posting-Host: neal.ctd.comsat.com In-Reply-To: neal@ctd.comsat.com's message of 25 Sep 92 09:46:34 X-Md4-Signature: f508a933124dd4bc4e5770ff9cb816ed Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com This seems to work. I don't see why this is better than x-rebind-key, though. (global-unset-key 'backspace) (define-key global-map 'backspace [(delete)]) From bug-lucid-emacs-request@lucid.com Fri Sep 25 10:37:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20379; Fri, 25 Sep 92 10:37:48 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10592g; Fri, 25 Sep 92 10:37:09 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09073; Fri, 25 Sep 92 13:37:48 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09069; Fri, 25 Sep 92 13:37:47 -0400 Path: uunet!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!darwin.sura.net!mojo.eng.umd.edu!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: DEL key on HPUX Message-Id: Date: 25 Sep 92 13:32:37 GMT Organization: COMSAT Labs Lines: 14 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: 7abb7a878fa7e1b36088aea8e737a9ca Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I hope this isn't a FAQ, but I have an HP keyboard. For all intents and purposes, you could say it doesn't have a DEL key. It has a BackSpace key. I know, I've heard it before. Use xmodmap -e "keycode 0x65 = Delete". Well I did this. It breaks so much other software I had to remove this little goodie. Is there another way? Right now, this is a major annoyance if I want to use lemacs. As shipped, an HP9000/7xx doesn't have a usable DEL key at all! It's being used by the window manager. IMHO: ALL software should accept BS or DEL interchangably. If I want to hack lemacs to do this, where should I hack? Thanks. From bug-lucid-emacs-request@lucid.com Fri Sep 25 10:39:09 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20386; Fri, 25 Sep 92 10:39:09 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10598g; Fri, 25 Sep 92 10:38:33 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA09135; Fri, 25 Sep 92 13:39:20 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA09131; Fri, 25 Sep 92 13:39:18 -0400 Path: uunet!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!darwin.sura.net!mojo.eng.umd.edu!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Re: DEL key on HPUX Message-Id: Date: 25 Sep 92 13:46:34 GMT References: Organization: COMSAT Labs Lines: 3 Nntp-Posting-Host: neal.ctd.comsat.com In-Reply-To: neal@ctd.comsat.com's message of 25 Sep 92 09:32:37 X-Md4-Signature: 92ca7d37e0dd9013833158e519e68c5c Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com That reminds me. What every happened to (x-rebind-key)? This works by doing exactly the equivalent of xmodmap, but just for the current program. This is just what I need. (I think) From bug-lucid-emacs-request@lucid.com Sat Sep 26 06:16:41 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23317; Sat, 26 Sep 92 06:16:41 PDT Received: by heavens-gate.lucid.com id AA12493g; Sat, 26 Sep 92 06:16:03 PDT Received: from Relay.Prime.COM by heavens-gate.lucid.com id AA12489g; Sat, 26 Sep 92 06:15:52 PDT Received: from APOLLO.Prime.COM by Relay.Prime.COM; 26 Sep 92 09:15:46 EST Received: from CIS.Prime.COM [130.21.130.10] by APOLLO.CIS.Prime.COM ; 26 Sep 92 14:12:07 UT Received: from mira.CIS.Prime.COM by CIS.Prime.COM (4.1/SMI-4.1.1/CIS) id AA02613; Sat, 26 Sep 92 14:09:04 BST Date: Sat, 26 Sep 92 14:09:04 BST From: David Hughes Message-Id: <9209261309.AA02613@CIS.Prime.COM> Received: by mira.CIS.Prime.COM (4.1/SMI-4.1) id AA01609; Sat, 26 Sep 92 14:08:49 BST To: bug-lucid-emacs@lucid.com Subject: Sign me up! + Bugs in lemacs19.3 Return-Receipt-To: djh@cis.Prime.COM Please add djh@cis.prime.com to bug-lucid-emacs & help-lucid-emacs. Thanx. Problems with lemacs-19.3 1. I first spotted this in 19.1 & 19.2 and thought it had been fixed for 19.3, but it hasn't. If I insert or delete several charcters and then try to move somewhere straight away with mouse button1, it puts the cursor in the wrong place. This seems to happen mostly with larger buffers for some reason. It looks like event-x is not being updated properly. 2. The new font/highlighting for VM header fields is very nice, making it much easier to distinguish header from body. However, if you have a long list of names (for example) on the To: field such that it wraps, then the last few names appear mangled!! What is going on? 3. It is annoying when the Autosaving... message does not go away when it has finished. Is this a permanent mis-feature? -- Regards, David From bug-lucid-emacs-request@lucid.com Mon Sep 28 06:13:55 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA28931; Mon, 28 Sep 92 06:13:55 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA14648g; Mon, 28 Sep 92 06:13:19 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00477; Mon, 28 Sep 92 09:14:12 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00473; Mon, 28 Sep 92 09:14:09 -0400 Path: uunet!mcsun!uknet!edcastle!aisb!aisb!tfb From: tfb@aisb.ed.ac.uk (Tim Bradshaw) Newsgroups: alt.lucid-emacs.bug Subject: map-extents documention bug (19.2) Message-Id: Date: 28 Sep 92 12:56:12 GMT Organization: Not Lines: 7 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Perhaps this is fixed in 19.3. map-extents will stop prematurely if the function called ever returns non-NIL. This is a useful feature but it should be documented somewhere other than the source code... --tim From bug-lucid-emacs-request@lucid.com Mon Sep 28 06:34:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA28968; Mon, 28 Sep 92 06:34:30 PDT Received: by heavens-gate.lucid.com id AA14679g; Mon, 28 Sep 92 06:34:02 PDT Received: from Relay.Prime.COM by heavens-gate.lucid.com id AA14674g; Mon, 28 Sep 92 06:33:43 PDT Received: from APOLLO.Prime.COM by Relay.Prime.COM; 28 Sep 92 09:39:32 EST Received: from CIS.Prime.COM [130.21.130.10] by APOLLO.CIS.Prime.COM ; 28 Sep 92 14:35:19 UT Received: from mira.CIS.Prime.COM by CIS.Prime.COM (4.1/SMI-4.1.1/CIS) id AA07879; Mon, 28 Sep 92 14:32:12 BST Date: Mon, 28 Sep 92 14:32:12 BST From: David Hughes Message-Id: <9209281332.AA07879@CIS.Prime.COM> Received: by mira.CIS.Prime.COM (4.1/SMI-4.1) id AA03385; Mon, 28 Sep 92 14:31:55 BST To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: lemacs19.3 Segmentation fault Return-Receipt-To: djh@cis.Prime.COM Jamie, With lemacs19.2, we were able to use a neat trick to allow sun3's etc to access a sparc version of Lucid Emacs using the following alias: alias emacs19 'rsh \!* "setenv DISPLAY {$HOST}:0.0; setenv PATH /flint/tool/bin:/bin:/usr/bin:/usr/ucb; emacs &"' However, with Lucid Emacs 19.3, this alias results in a Segmentation fault. It still works if you rlogin to the appropriate Sparcstation and do it all by hand, but it would be better if the rsh command was accepted. Any ideas? -- Regards, David From bug-lucid-emacs-request@lucid.com Mon Sep 28 06:51:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29031; Mon, 28 Sep 92 06:51:19 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA14705g; Mon, 28 Sep 92 06:50:43 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02777; Mon, 28 Sep 92 09:51:35 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA02773; Mon, 28 Sep 92 09:51:34 -0400 Path: uunet!dtix!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Keyboard Macros no substitute for xmodmap Message-Id: Date: 28 Sep 92 13:11:34 GMT Organization: COMSAT Labs Lines: 12 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: 1260acd23afba3b7320882cc068d63f2 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com After running for a couple of days with: (global-unset-key 'backspace) (define-key global-map 'backspace [(delete)]) everything seemed OK till I went into i-search mode. Then pressing the backspace key did *not* do the same as delete. I found the (removed) x-rebind-key code in xfns.c, where it is claimed that it is no longer needed since keyboard macros work as well. The above example sure didn't work as well. Did I do something wrong? Thanks. From bug-lucid-emacs-request@lucid.com Mon Sep 28 09:14:18 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29528; Mon, 28 Sep 92 09:14:18 PDT Received: by heavens-gate.lucid.com id AA14923g; Mon, 28 Sep 92 09:13:42 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA14918g; Mon, 28 Sep 92 09:11:55 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11197; Mon, 28 Sep 92 12:12:40 -0400 Received: from synaptx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 121131.14178; Mon, 28 Sep 1992 12:11:31 EDT Received: from thymus.synaptics by synaptx.synaptics.com (4.1/SMI-4.1) id AA29833; Sun, 27 Sep 92 18:50:41 PDT Received: by thymus.synaptics (4.1/SMI-4.1) id AA00544; Sun, 27 Sep 92 18:58:31 PDT Message-Id: <9209280158.AA00544@thymus.synaptics> To: bug-lucid-emacs@lucid.com Subject: remainder vs. fmod Reply-To: daveg@synaptics.com Date: Sun, 27 Sep 92 18:58:29 -0700 From: Dave Gillespie I just ran across the long discussion of remainder() and fmod() in the archives of this list. I note that 19.3 is designed to use drem(), remainder(), or fmod() depending on which is available, with fmod() being least favored. This is a bug; fmod() is always the right choice. Briefly, fmod(x,y) gives the remainder based on a quotient which rounds *down* to the next lower integer, but remainder(x,y) on the Sun gives the remainder for a quotient rounded to the *nearest* integer. The C standard doesn't say what x%y ought to do for negative arguments, but for positive arguments, at least, the standard requires fmod-like behavior. Therefore, to be consistent, lemacs ought to use fmod(x,y) for float arguments if it is using x%y for integer arguments. Also, fmod() is a required part of the C standard; remainder(), as we've all found out the hard way, is defined only on Suns. As for drem(), I don't know how it works but it's not defined on Suns. Anyway, fmod() is the obvious right choice on all machines. Here's a test program that shows what I mean. -------- foo.c: #include int main() { double a = 1234.0; double b = 5678.0; double c = 100.0; printf("%g vs. %g vs. %d\n", fmod(a, c), remainder(a, c), (int)a % (int)c); printf("%g vs. %g vs. %d\n", fmod(b, c), remainder(b, c), (int)b % (int)c); } -------- foo.out: 34 vs. 34 vs. 34 78 vs. -22 vs. 78 -------- As you can see, remainder(5678,100) rounds the quotient up to 57, giving a remainder of -22. This is not a very useful sort of remainder in most cases, but the IEEE standard provides it anyhow. In a similar vein, there have been a lot of problems with missing asinh() along with few other library functions. The ANSI standard requires only these functions (from page 251 of K&R II): sin, cos, tan, asin, acos, atan, atan2, sinh, cosh, tanh, exp, log, log10, pow, sqrt, ceil, floor, fabs, fmod, ldexp, frexp, modf Lucid Emacs also refers to asinh, acosh, atanh, j0, j1, jn, y0, y1, yn, cbrt, erf, erfc, expm1, log1p, logb, lgamma, and rint, which are available on Suns but are not standard. I'd strongly recommend either taking them out, or #ifdef'ing them out on everything but Suns. With the possible exception of rint, no one is likely to miss any of these functions, and rint(x) can be simulated by floor(x+0.5) (not exactly IEEE rounding but close enough to match the doc string). All the other functions are available in Emacs Calc; the next version of Calc will make it easy to apply these functions to Lucid Emacs floats. It's too bad ANSI C provides inverse and hyperbolic trig functions without providing the inverse-hyperbolic ones as well. If this seems too asymmetrical, I'd recommend either dropping the hyperbolics from Lisp, or defining them in terms of logs rather than expecting them to be in the library. On the other hand, atan2, floor, and ceil are not available from Emacs Lisp. The current floor and ceiling functions return integers, not floats, so they don't work for arguments larger than 2^23. Common Lisp provides ffloor, fceiling, fround, and ftruncate alternatives which return integer-valued floats, and it also provides an atan which accepts an optional second argument. I remember seeing a version of floatfns.c from long ago which included ffloor, etc.---I wonder how they managed to get dropped from the version Lucid Emacs uses. (The ldexp, frexp, and modf functions are probably too arcane to worry about for Lisp.) -- Dave From bug-lucid-emacs-request@lucid.com Mon Sep 28 09:51:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29668; Mon, 28 Sep 92 09:51:26 PDT Received: by heavens-gate.lucid.com id AA15016g; Mon, 28 Sep 92 09:50:51 PDT Received: from portal.bcm.tmc.edu by heavens-gate.lucid.com id AA15010g; Mon, 28 Sep 92 09:50:35 PDT Received: by portal.bcm.tmc.edu (AA28352); Mon, 28 Sep 92 11:50:02 -0500 Received: from shell.shell.com by shell.com SHELL-X1.3 id AA29517; Mon, 28 Sep 92 10:57:39 -0500 Received: from patriot by shell.shell.com SHELL-I1.3 id AA28958; Mon, 28 Sep 92 09:59:40 -0500 Received: from colorado.AGR by patriot.brc.shell.com (4.1/AGR-2.0) id AA02682; Mon, 28 Sep 92 09:59:04 CDT Date: Mon, 28 Sep 92 09:59:04 CDT From: jody@shell.com (Jody Winston) Message-Id: <9209281459.AA02682@patriot.brc.shell.com> Received: by colorado.AGR (4.1/SMI-4.1) id AA26397; Mon, 28 Sep 92 09:59:08 CDT To: bug-lucid-emacs@lucid.com Subject: lemacs 19.3 On the following setup: Sun 4 OS 4.1.1 gcc 2.2.2 lemacs 19.3, SYSTEM_MALLOC, lucid menus tvtwm X11R5 patch level 17 with or without an ~/.emacs I have the following problem in event-Xt.c, look_for_key_or_mouse_event; the event structure is garbage. Here's the traceback from gcc (As soon as I get a version of purify that can handle gcc, I'll try purify on it.) Program received signal 10, Bus error 0x45510 in look_for_key_or_mouse_event (display=0x2526c8, event=0xe, arg=0xf7ffe7e4) at event-Xt.c:1475 (gdb) print *event $1 = Cannot access memory at address 0xe. (gdb) where #0 0x45510 in look_for_key_or_mouse_event (display=0x2526c8, event=0xe, arg=0xf7ffe7e4) at event-Xt.c:1475 #1 0xfb33c in XCheckIfEvent () #2 0x454c0 in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:1456 #3 0x22dc8 in Fsit_for (n=120, nodisp=69265580) at event-stream.c:752 #4 0x8eec8 in Ffuncall (nargs=2, args=0xf7ffea10) at eval.c:1808 #5 0xa8fc4 in Fbyte_code (bytestr=202923100, vector=270032160, maxdepth=5) at bytecode.c:428 #6 0x8f770 in funcall_lambda (fun=404249668, nargs=0, arg_vector=0xf7ffec7c) at eval.c:1969 #7 0x8eff0 in Ffuncall (nargs=1, args=0xf7ffec78) at eval.c:1836 #8 0xa8fc4 in Fbyte_code (bytestr=202921096, vector=270030028, maxdepth=3) at bytecode.c:428 #9 0x8f770 in funcall_lambda (fun=404247664, nargs=0, arg_vector=0xf7ffeedc) at eval.c:1969 #10 0x8eff0 in Ffuncall (nargs=1, args=0xf7ffeed8) at eval.c:1836 #11 0xa8fc4 in Fbyte_code (bytestr=202920096, vector=270029036, maxdepth=5) at bytecode.c:428 #12 0x8f770 in funcall_lambda (fun=404246664, nargs=0, arg_vector=0xf7fff090) at eval.c:1969 #13 0x8f38c in apply_lambda (fun=404246664, args=69265580, eval_flag=1) at eval.c:1900 #14 0x8df2c in Feval (form=337779588) at eval.c:1441 #15 0x4c5f4 in top_level_2 () at keyboard.c:397 #16 0x8ca24 in internal_condition_case (bfun=0x4c5e0 , handlers=69265860, hfun=0x4c11c ) at eval.c:1002 #17 0x4c6b0 in top_level_1 (dummy=69265580) at keyboard.c:406 #18 0x8c3e0 in internal_catch (tag=69265840, func=0x4c66c , arg=69265580) at eval.c:814 #19 0x4c538 in command_loop () at keyboard.c:366 #20 0x4bf4c in recursive_edit_1 () at keyboard.c:221 #21 0x4c070 in Frecursive_edit () at keyboard.c:250 #22 0x4b5ec in main (argc=1, argv=0xf7fff6fc, envp=0xf7fff704) at emacs.c:817 (gdb) quit Jody Winston jody@shell.com ..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody Consultant to: Shell Development Company, Bellaire Research Center P.O. Box 481, Room 4205, Houston, TX 77001 (Voice: 713 245-7574) From bug-lucid-emacs-request@lucid.com Mon Sep 28 10:19:54 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29787; Mon, 28 Sep 92 10:19:54 PDT Received: by heavens-gate.lucid.com id AA15098g; Mon, 28 Sep 92 10:19:14 PDT Received: from banzai.cc.columbia.edu by heavens-gate.lucid.com id AA15094g; Mon, 28 Sep 92 10:18:42 PDT Received: by banzai.cc.columbia.edu (5.59/FCB) id AA01841; Mon, 28 Sep 92 13:19:29 EDT Date: Mon, 28 Sep 92 13:19:28 EDT From: Ben Fried To: bug-lucid-emacs@lucid.com Subject: Problem with gnus/nntp.el? Message-Id: I was having big problems with gnus: I could get the newsgroups buffer up, but when I tried to enter a newsgroup, I would almost always get an "out of range" message on the list of article headers. It turns out that many articles on our news server do not have a "References:" line, and that nntp-retrieve-headers was creating header vectors that were only 7 elements long as a result (the 8th element of the header vector is supposed to be the contents of the References: header). So I made a simple modification to nntp.el: banzai$ diff nntp.el nntp.el.~1~ 289,290d288 < (if (null references) < (setq references "")) However, in retrospect, the cleverer change is to set the default value of references to be "": banzai$ diff nntp.el nntp.el.~2~ 261c261 < (setq references "") --- > (setq references nil) Now everything works fine. Is the lack of References: lines (and the vanilla gnus response) a common problem? Kudos to the people at lucid, on lucid's emacs, and on the edebug package, which made nailing down this bug a breeze. Lucid emacs is a life saver. Ben From bug-lucid-emacs-request@lucid.com Mon Sep 28 11:20:21 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA29935; Mon, 28 Sep 92 11:20:21 PDT Received: by heavens-gate.lucid.com id AA15350g; Mon, 28 Sep 92 11:19:50 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA15346g; Mon, 28 Sep 92 11:19:42 PDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA13231; Mon, 28 Sep 92 13:20:55 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA22564; Mon, 28 Sep 92 14:20:18 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA24937; Mon, 28 Sep 92 14:19:26 EDT Date: Mon, 28 Sep 92 14:19:26 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9209281819.AA24937@pts4.pts.mot.com> To: ben@banzai.cc.columbia.edu, bug-lucid-emacs@lucid.com Subject: Re: Problem with gnus/nntp.el? WE have the same problems with References: here. It is not specific to Lucid Emacs. Bob From bug-lucid-emacs-request@lucid.com Mon Sep 28 13:07:56 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00321; Mon, 28 Sep 92 13:07:56 PDT Received: by heavens-gate.lucid.com id AA15621g; Mon, 28 Sep 92 13:05:18 PDT Received: from sgi.sgi.com (SGI.COM) by heavens-gate.lucid.com id AA15611g; Mon, 28 Sep 92 13:03:53 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for bug-lucid-emacs@lucid.com id AA12312; Mon, 28 Sep 92 13:04:45 -0700 Received: from mti.mti.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:jzw@lucid.com id AA01406; Mon, 28 Sep 92 13:04:43 -0700 Received: from farfle.mti.sgi.com by mti.mti.sgi.com via SMTP (920110.SGI/911001.SGI) for @sgi.com:bug-lucid-emacs@lucid.com id AA13112; Mon, 28 Sep 92 13:04:51 -0700 Received: from localhost. mti.sgi.com by farfle.mti.sgi.com via SMTP (920330.SGI/911001.SGI) for @mti.mti.sgi.com:jzw@lucid.com id AA16008; Mon, 28 Sep 92 13:04:33 -0700 Message-Id: <9209282004.AA16008@farfle.mti.sgi.com> To: bug-lucid-emacs@lucid.com Cc: jzw@lucid.com Subject: Emacs bug with font-lock-fontify-buffer Date: Mon, 28 Sep 92 13:04:32 -0700 From: Rick Braumoeller While using font-lock-fontify-buffer, I received an error and this message in the minibuffer: Wrong type argument: number-or-marker-p, # Fortunately, my lemacs didn't crash (19.3) and I'm still using it, fool though I may be. Can anyone tell me what this means? I'd be glad to provide the file and whatever configuration information would be useful (Irix 4.0.5, etc..) Thanks! ----- Rick Braumoeller rickb@mti.sgi.com Silicon Graphics, Inc. (415) 390-4506 From bug-lucid-emacs-request@lucid.com Tue Sep 29 08:48:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03765; Tue, 29 Sep 92 08:48:34 PDT Received: by heavens-gate.lucid.com id AA17512g; Tue, 29 Sep 92 08:46:40 PDT Received: from corton.inria.fr by heavens-gate.lucid.com id AA17506g; Tue, 29 Sep 92 08:45:30 PDT Received: from esemetz.ese-metz.fr by corton.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA17633; Tue, 29 Sep 1992 16:45:36 +0100 (MET) Received: from tintin.ese-metz.fr by esemetz.ese-metz.fr, Tue, 29 Sep 92 15:44:21 GMT Received: by tintin.ese-metz.fr, Tue, 29 Sep 92 16:44:28 +0100 Date: Tue, 29 Sep 92 16:44:28 +0100 From: popineau%ese-metz.fr@lucid.com Message-Id: <9209291544.AA00523@tintin.ese-metz.fr> To: bug-lucid-emacs@lucid.com Subject: Documentation string It seems to me that there is a bug linked to the documentation string of a function. This function : | (defun latex-mode () | "Major mode for editing files of input for LaTeX. | | Makes $ and } display the characters they match. | Makes \" insert `` when it seems to be the beginning of a quotation, | and '' when it appears to be the end; it inserts \" only after a \\. | LFD and TAB indent lines as with programming modes. | | Use \\[TeX-region] to run LaTeX on the current region, plus the | preamble copied from the top of the file (containing \\documentstyle, | etc.). \\[TeX-buffer] does the whole buffer. Use \\[TeX-preview] to | preview the .dvi file made by either of these. | | Use \\[TeX-next-error] to trace through the errors. | | See LaTeX-section and LaTeX-environment for a description of customization. | | Use \\[TeX-validate-buffer] to check buffer for paragraphs containing | mismatched $'s or braces. | | TAB is forced to insert spaces, as TeX ignores ordinary tab's. | | Special commands: | \\{LaTeX-mode-map} | | Mode variables: | | Refer to `tex-site.el' for customization | | Entering LaTeX mode calls the value of text-mode-hook, | then the value of TeX-mode-hook, and then the value | of LaTeX-mode-hook." | (interactive) | (TeX-common-initialization) | (setq LaTeX-optop "[") | (setq LaTeX-optcl "]") | (modify-syntax-entry (string-to-char LaTeX-optop) (concat "(" LaTeX-optcl)) | (modify-syntax-entry (string-to-char LaTeX-optcl) (concat ")" LaTeX-optop)) | (make-local-variable 'indent-line-function) | (setq indent-line-function 'LaTeX-indent-line) | (use-local-map LaTeX-mode-map) | (setq mode-name "LaTeX") | (setq major-mode 'LaTeX-mode) | ... | ) makes lemacs crashing when I ask (documentation "LaTeX-mode"). If I remove 99% of the text, it works fine. This function comes from AUC-TeX mode for emacs. It works fine under Emacs v18.58, but neither under lemacs 19.2 nor lemacs 19.3 . F. Popineau ----------- e-mail: popineau@loria.loria.fr popineau@ese-metz.fr voice-mail: (+33) 87-74-99-38 surface-mail: Ecole Superieure d'Electricite 2 rue Edouard Belin F-57078 Metz Cedex 3 FRANCE From bug-lucid-emacs-request@lucid.com Tue Sep 29 09:20:27 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03902; Tue, 29 Sep 92 09:20:27 PDT Received: by heavens-gate.lucid.com id AA17612g; Tue, 29 Sep 92 09:20:00 PDT Received: from chenas.inria.fr by heavens-gate.lucid.com id AA17608g; Tue, 29 Sep 92 09:19:27 PDT Received: from sid1.cenaath.cena.dgac.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA10737; Tue, 29 Sep 1992 17:20:10 +0100 (MET) Received: from geant.cenatls.cena.dgac.fr by sid1.cenaath.cena.dgac.fr (4.1/SMI-4.1) id AA14477; Tue, 29 Sep 92 17:22:17 +0100 Received: from gogol.cenatls by geant.cenatls.cena.dgac.fr (4.1/SMI-4.1) id AA11503; Tue, 29 Sep 92 17:19:32 +0100 Date: Tue, 29 Sep 92 17:19:31 +0100 From: queinnec%geant.cenatls.cena.dgac.fr@lucid.com (Philippe Queinnec) Message-Id: <9209291619.AA11503@geant.cenatls.cena.dgac.fr> Received: by gogol.cenatls (4.1/SMI-4.1) id AA02992; Tue, 29 Sep 92 17:19:30 +0100 To: bug-lucid-emacs@lucid.com Subject: Re: Documentation string In-Reply-To: Your message of Tue 29 September 92, 16:44:28 +0100 References: <9209291544.AA00523@tintin.ese-metz.fr> In <9209291544.AA00523@tintin.ese-metz.fr>, popineau@ese-metz.fr explained a problem with a documentation string. I noticed also some strange things with the documentation strings: Define the following variable and function: (defvar truc t "This fails: \\=\\[ and this too \\=\\]: same result as \\[ and \\].") (defun toto () "This doesn't fail: \\=\\[ and this neither: \\=\\]. Not the same result as \\[ and \\]." nil) And then: C-h d toto RET => the documentation string is ok. C-h v truc RET => the documentation string is NOT ok (contains: This fails: M-x and this too \: same result as M-x and \. (same results with M-x describe-function and M-x describe-variable) It works fine with emacs 18.57. Phil From bug-lucid-emacs-request@lucid.com Wed Sep 30 07:50:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08023; Wed, 30 Sep 92 07:50:23 PDT Received: by heavens-gate.lucid.com id AA20382g; Wed, 30 Sep 92 07:48:13 PDT Message-Id: <9209301448.AA20382@lucid.com> Received: from gourde.bbn.com by heavens-gate.lucid.com id AA20377g; Wed, 30 Sep 92 07:48:04 PDT Received: by gourde.bbn.com id AA20411g; Wed, 30 Sep 92 10:47:46 EDT To: bug-lucid-emacs@lucid.com Cc: fwhite@bbn.com Subject: font-lock mode breaks query-replace Date: Wed, 30 Sep 92 10:47:45 -0400 From: Fredric M White This must have already been reported, but anyways: "GNU Emacs 19.3 Lucid of Wed Sep 9 1992 on watergate (berkeley-unix)" lemacs -no-init-file m-x load-library font-lock c-x c-f something.el m-x font-lock-mode m-$ defun defoo And the buffer is trashed. Sometimes I later get a minibuffer message like "# encountered, save your buffers!" --Fred From bug-lucid-emacs-request@lucid.com Wed Sep 30 11:06:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08592; Wed, 30 Sep 92 11:06:50 PDT Received: by heavens-gate.lucid.com id AA21060g; Wed, 30 Sep 92 11:04:14 PDT Message-Id: <9209301804.AA21060@lucid.com> Received: from vnet.ibm.com by heavens-gate.lucid.com id AA21053g; Wed, 30 Sep 92 11:03:50 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7301; Wed, 30 Sep 92 14:06:34 EDT Date: Wed, 30 Sep 92 09:31:59 PDT From: "Mickey Ferguson" To: JWZ%THALIDOMIDE@lucid.com, BUG-LUCID-EMACS@lucid.com Subject: Linking Lucid 19.3 for OLIT I hadn't heard anything from my previous note reporting my linking problem, so I thought I would send again in case it was never received. My problem is that when I try to build lucid (with USE_OLIT), I end up with an undefined symbol which causes the link to fail. The name of the symbol is resource_string, which is defined in the file src/lwlib/lwlib-Xol.c. Is this supposed to be something in the standard X11 library? Maybe it is the name of a procedure which should be in one of the other files, but that file isn't being linked in? Maybe it's mis-named? (I found one other typo in procedure name, but fixed that.) Please help me so I can build the system. Yes, I know you've said that the system is mainly set up for the Lucid and / or Motif widgets, and that OLIT may be buggy, but I would have thought that it would at least link. Any suggestions (other than not using OLIT? :) Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Wed Sep 30 20:23:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10224; Wed, 30 Sep 92 20:23:08 PDT Received: by heavens-gate.lucid.com id AA22580g; Wed, 30 Sep 92 20:22:09 PDT Message-Id: <9210010322.AA22580@lucid.com> Received: from vnet.ibm.com by heavens-gate.lucid.com id AA22576g; Wed, 30 Sep 92 20:21:52 PDT Received: from SCRVM2 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3040; Wed, 30 Sep 92 23:25:07 EDT Date: Wed, 30 Sep 92 13:35:38 PDT From: "Mickey Ferguson" To: DEVIN%SCYLLA@lucid.com, BUG-LUCID-EMACS@lucid.com Subject: Lucid link error Can you ask the person who wrote the procedure make_menu_in_widget in the file lwlib-Xol.c, what the call label = (char *) resource_string (widget, cur->name); is doing, and where they expect the call to find this procedure? If we can change it to something else, the linking will be done, and maybe I can even debug it for you. :) Mickey Ferguson -- Rolm -- FergusoM at scrvm2 -- mickeyf@vnet.ibm.com From bug-lucid-emacs-request@lucid.com Wed Sep 30 21:30:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10317; Wed, 30 Sep 92 21:30:13 PDT Received: by heavens-gate.lucid.com id AA22771g; Wed, 30 Sep 92 21:29:36 PDT Received: from scylla.lucid (scylla.lucid.com) by heavens-gate.lucid.com id AA22767g; Wed, 30 Sep 92 21:29:28 PDT Received: by scylla.lucid (4.1/SMI-4.1) id AA09621; Wed, 30 Sep 92 21:30:57 PDT Date: Wed, 30 Sep 92 21:30:57 PDT From: devin%scylla@lucid.com (Matthieu Devin) Message-Id: <9210010430.AA09621@scylla.lucid> To: "Mickey Ferguson" Cc: BUG-LUCID-EMACS@lucid.com Subject: Re: Lucid link error In-Reply-To: "Mickey Ferguson"'s message of Wed 30-Sep-92 13:35:38 PDT <9210010321.AA22576@lucid.com> References: <9210010321.AA22576@lucid.com> In message <9210010321.AA22576@lucid.com> "Mickey Ferguson" wrote: > > Can you ask the person who wrote the procedure make_menu_in_widget in the > file lwlib-Xol.c, what the call > > label = (char *) resource_string (widget, cur->name); > > is doing, and where they expect the call to find this procedure? If we > can change it to something else, the linking will be done, and maybe I can > even debug it for you. :) You can change it to a no-op, i.e.: label = cur->name; The resource_string routine was supposed to look in the resource database for the value of the string in cur->name, but most likely the OLIT toolkit does the resourcing automatically when the oblongButtonWidget is created, so it must not be useful. From bug-lucid-emacs-request@lucid.com Fri Oct 2 11:18:13 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA17002; Fri, 2 Oct 92 11:18:13 PDT Received: by heavens-gate.lucid.com id AA26917g; Fri, 2 Oct 92 11:15:12 PDT Received: from relay1.UU.NET by heavens-gate.lucid.com id AA26907g; Fri, 2 Oct 92 11:14:49 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27949; Fri, 2 Oct 92 14:15:45 -0400 Received: from localhost.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA28252; Fri, 2 Oct 92 11:15:33 PDT Message-Id: <9210021815.AA28252@cygnus.com> To: bug-lucid-emacs@lucid.com Subject: lemacs-19.2.18 porting notes to NewsOS-3.2 Date: Fri, 02 Oct 92 11:15:32 -0700 From: bothner@cygnus.com Ported lemacs-19.2.18 to NewsOS 3.2 (old BSD-4.3 derivative from Sony, running on 68020, using X11R4 libraries and an X11R2 server). Uncommented #include from src/lisp.h. (Testing for __STDC__ isn't good enough, given that gcc normally defines __STDC__.) Uncommented #include and #include from src/lwlib/lwlib.c. Again, these are not universally available. src/lwlib/Makefile: CFLAGS uses ALLDEFINES, which uses ALLINCLUDES, which includes TOP_INCLUDES, which is -I$(INCROOT), which is /usr/include, hence the wrong directory is searched. I don't know enough about Imakefiles to suggest a clean fix. xrdb-cpp.c: Added #include and #include . Also added #include (for isspace). xrdb-r4.c: XtCXtToolkitError is not defined. Replace by "XtCXtToolkitError" src/lwlib/dispatch.c: #include , for XtPerDisplayInput src/lwlib/dispatch.c: Add cast (two places in XtWidgetToDispatchTo): grabList = *(XtGrabList*)_XtGetGrabList(pdi); Edited src/config.h: #define NEED_STRDUP #define NEED_REALPATH #define HAVE_DREM /* #define HAVE_REMAINDER */ strcasecmp is needed, but is not a commonly available function. (It isn't ANSI or Posix.) I grabbed a version. On startup, I get the following annoying warning: emacs: Meta_L (0xca) generates Mod1, which is generated by Alt. Two distinct modifier keys (such as Meta and Hyper) cannot generate the same modifier bit, because Emacs won't be able to tell which modifier was actually held down when some other key is pressed. It won't be able to tell Meta-x and Hyper-x apart, for example. Change one of these keys to use some other modifier bit. The meanings of the modifier bits Mod1 through Mod5 are determined by the keysyms used to control those bits. Mod1 does NOT always mean Meta, although some non-ICCCM-compliant programs assume that. There are bugs in the re-display of menus. I assume you're aware of them. If gcc is used, -O should probably be the default. I have old R4 (beta?) libraries, where InstrinsicP.h does not include ObjectP.h. Fixed by hacking InstrinsicP.h. --Per Bothner Cygnus Support bothner@cygnus.com From bug-lucid-emacs-request@lucid.com Mon Oct 5 17:38:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA27806; Mon, 5 Oct 92 17:38:45 PDT Received: by heavens-gate.lucid.com id AA04189g; Mon, 5 Oct 92 17:36:49 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA04184g; Mon, 5 Oct 92 17:36:39 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA11244; Mon, 5 Oct 92 17:37:55 PDT Date: Mon, 5 Oct 92 17:37:55 PDT Message-Id: <9210060037.AA11244@thalidomide.lucid> X-Windows: Power tools for power fools. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: neal@ctd.comsat.com (Neal Becker) Cc: bug-lucid-emacs@lucid.com Subject: Re: DEL key on HPUX Newsgroups: alt.lucid-emacs.bug In-Reply-To: Neal Becker's message of 25-Sep-92 15:46:04 GMT References: In message Neal Becker wrote: > > This seems to work. I don't see why this is better than x-rebind-key, > though. > > (global-unset-key 'backspace) > (define-key global-map 'backspace [(delete)]) This is better than x-rebind-key because it's one interface instead of two, and not X specific. You need to also do the same binding in the isearch-mode-map, and any local map which contains a binding of Delete or Backspace, instead of just inheriting the global bindings (there aren't many of these.) -- Jamie From bug-lucid-emacs-request@lucid.com Mon Oct 5 19:22:22 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA28010; Mon, 5 Oct 92 19:22:22 PDT Received: by heavens-gate.lucid.com id AA04509g; Mon, 5 Oct 92 19:20:10 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA04505g; Mon, 5 Oct 92 19:20:00 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11194; Mon, 5 Oct 92 22:21:16 -0400 Received: from synaptx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 222040.24275; Mon, 5 Oct 1992 22:20:40 EDT Received: from thymus.synaptics by synaptx.synaptics.com (4.1/SMI-4.1) id AA23457; Mon, 5 Oct 92 18:39:51 PDT Received: by thymus.synaptics (4.1/SMI-4.1) id AA02450; Mon, 5 Oct 92 18:48:11 PDT Message-Id: <9210060148.AA02450@thymus.synaptics> To: bug-lucid-emacs@lucid.com Subject: Re: DEL key on HPUX In-Reply-To: Your message of "Mon, 05 Oct 92 17:37:55 PDT." <9210060037.AA11244@thalidomide.lucid> Reply-To: daveg@synaptics.com Date: Mon, 05 Oct 92 18:48:10 -0700 From: Dave Gillespie Jamie Zawinski writes: > This is better than x-rebind-key because it's one interface instead of two, > and not X specific. > > You need to also do the same binding in the isearch-mode-map, and any local > map which contains a binding of Delete or Backspace, instead of just > inheriting the global bindings (there aren't many of these.) Does Lucid Emacs have an analogue of keyboard-translate-table? Old Emacs provided a two-level translation. Supporting x-rebind-key would be the clean way to carry this two-level mapping over to the new event model. The two levels, conceptually, are from physical keys on your keyboard onto logical keys that Emacs packages like to know about, and from logical keys onto functions in those packages. It seems like it would be really nice to be able to map Backspace to Delete, and have every package automatically start treating Backspace as Delete as a result. You might also want to use the first level for mapping page-down to C-n; the keyboard macro thing seems like a kludge that attempts to get the same effect. (By the way, the keyboard macro kludge would be a way to accomplish the Backspace->Delete binding for HP users without having to change all the local maps.) One of the reasons I don't like keyboard macros is that they must contain whole commands, including their arguments. I tried getting my numerical keypad to work with Calc once, defining keypad-0 to the macro "0" and so on, but it didn't work because the digit keys in Calc actually start a minibuffer entry of the rest of the digits. If the "0" appeared by itself in a keyboard macro, the digit-entry command terminated at the end of the macro and the result was that each keypad key entered a separate number rather than separate digits of the same number. -- Dave From bug-lucid-emacs-request@lucid.com Mon Oct 5 20:04:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA28094; Mon, 5 Oct 92 20:04:30 PDT Received: by heavens-gate.lucid.com id AA04632g; Mon, 5 Oct 92 20:03:47 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA04628g; Mon, 5 Oct 92 20:03:39 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA11683; Mon, 5 Oct 92 20:04:56 PDT Date: Mon, 5 Oct 92 20:04:56 PDT Message-Id: <9210060304.AA11683@thalidomide.lucid> X-Windows: A moment of convenience, a lifetime of regret. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: daveg@synaptics.com Cc: bug-lucid-emacs@lucid.com Subject: Re: DEL key on HPUX In-Reply-To: Dave Gillespie's message of Mon 5-Oct-92 18:48:10 -0700 <9210060148.AA02450@thymus.synaptics> References: <9210060037.AA11244@thalidomide.lucid> <9210060148.AA02450@thymus.synaptics> In message <9210060148.AA02450@thymus.synaptics> Dave Gillespie wrote: > > The two levels, conceptually, are from physical keys on your keyboard > onto logical keys that Emacs packages like to know about, and from > logical keys onto functions in those packages. It seems like it > would be really nice to be able to map Backspace to Delete, and have > every package automatically start treating Backspace as Delete as a > result. My view is that, under X, the first level of translation is accomplished using "xmodmap" and the second level is accomplished using `define-key'. In a tty universe, there is no equivalent of xmodmap, so emacs simulates it using keyboard-translate-table. Making x-rebind-key work with the new event model is hard, because x-rebind-key is ASCII-centric. and coming up with some lisp-level data structure that can efficiently map arbitrary events to arbitrary other events is also nontrivial. I don't think it's worth the effort. > You might also want to use the first level for mapping page-down to C-n; > the keyboard macro thing seems like a kludge that attempts to get the > same effect. One man's kludge is anothers "elegant solution" :-) > One of the reasons I don't like keyboard macros is that they must > contain whole commands, including their arguments. This is indeed unfortunate. Even more unfortunate is that "fixing" this would probably break the world... -- Jamie From bug-lucid-emacs-request@lucid.com Tue Oct 6 09:15:51 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA00720; Tue, 6 Oct 92 09:15:51 PDT Received: by heavens-gate.lucid.com id AA05928g; Tue, 6 Oct 92 09:15:09 PDT Received: from seismo.CSS.GOV by heavens-gate.lucid.com id AA05919g; Tue, 6 Oct 92 09:14:42 PDT Received: from esosun.CSS.GOV by seismo.CSS.GOV (5.65/1.14) id AA24061; Tue, 6 Oct 92 12:15:46 -0400 Received: from greip.css.gov by esosun.css.gov (3.2/) id AA09287; Tue, 6 Oct 92 09:15:40 PDT Received: by greip.css.gov (4.1/1.14jmj) id AA01229; Tue, 6 Oct 92 09:15:42 PDT Date: Tue, 6 Oct 92 09:15:42 PDT From: yonkman@greip.css.gov (Tom Yonkman) Message-Id: <9210061615.AA01229@greip.css.gov> To: bug-lucid-emacs@lucid.com Subject: delete-other-windows bug Reply-To: yonkman@esosun.css.gov Delete-other-windows does nothing when given an argument and when there are 3 windows on the default screen. It does work properly when given no arguments. The actual call I used was (delete-other-windows (get-largest window)) when there were 3 windows of different vertical sizes on the default screen. Any help is greatly appreciated. -- +---------------------------------------------------------------+ | Tom Yonkman UUCP: seismo!esosun!yonkman | | Open Systems Division Internet: yonkman@esosun.css.gov | | SAIC, Mail Stop A2-F PHONE: (619)458-4949 | | 10260 Campus Point Drive FAX: (619)458-4993 | | San Diego, CA 92121 | +---------------------------------------------------------------+ From bug-lucid-emacs-request@lucid.com Tue Oct 6 14:34:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01887; Tue, 6 Oct 92 14:34:02 PDT Received: by heavens-gate.lucid.com id AA06957g; Tue, 6 Oct 92 14:33:00 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA06953g; Tue, 6 Oct 92 14:32:24 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06900; Tue, 6 Oct 92 17:32:42 -0400 Received: from synaptx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 172849.1507; Tue, 6 Oct 1992 17:28:49 EDT Received: from thymus.synaptics by synaptx.synaptics.com (4.1/SMI-4.1) id AA26307; Tue, 6 Oct 92 13:42:40 PDT Received: by thymus.synaptics (4.1/SMI-4.1) id AA02563; Tue, 6 Oct 92 13:51:03 PDT Message-Id: <9210062051.AA02563@thymus.synaptics> To: bug-lucid-emacs@lucid.com Subject: Re: DEL key on HPUX In-Reply-To: Your message of "Mon, 05 Oct 92 20:04:56 PDT." <9210060304.AA11683@thalidomide.lucid> Reply-To: daveg@synaptics.com Date: Tue, 06 Oct 92 13:51:01 -0700 From: Dave Gillespie > Making x-rebind-key work with the new event model is hard, because > x-rebind-key is ASCII-centric. and coming up with some lisp-level data > structure that can efficiently map arbitrary events to arbitrary other > events is also nontrivial. I don't think it's worth the effort. How about "event-translate-hook", taking an event and returning a translated event; it would be equal to 'identity by default. -- Dave From bug-lucid-emacs-request@lucid.com Tue Oct 6 15:26:34 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02113; Tue, 6 Oct 92 15:26:34 PDT Received: by heavens-gate.lucid.com id AA07148g; Tue, 6 Oct 92 15:25:44 PDT Received: from plg.uwaterloo.ca by heavens-gate.lucid.com id AA07140g; Tue, 6 Oct 92 15:24:02 PDT Received: by plg.uwaterloo.ca id <29115>; Tue, 6 Oct 1992 18:24:37 -0400 From: Dave Mason To: bug-lucid-emacs@lucid.com Subject: pseudo bug in man.el Message-Id: <92Oct6.182437edt.29115@plg.uwaterloo.ca> Date: Tue, 6 Oct 1992 18:24:25 -0400 In our environment, MANPATH components end in /, hence the code in man.el produced things like /usr/man//cat1, /usr/man//cat1, etc. This used to work fine, but it appears that the file open code in lemacs treats the // specially, so it wasn't finding /cat1, /cat2, etc. In any case, this patch makes it only append a / if the component didn't already end in one. ../Dave ; diff -c man.el /u2/dmason/Emacs/man.el *** man.el Wed Aug 26 04:18:20 1992 --- /u2/dmason/Emacs/man.el Tue Oct 6 18:09:43 1992 *************** *** 293,300 **** (defun Manual-select-subdirectories (dirlist subdir) (apply 'append (mapcar '(lambda (dir) (and (file-exists-p dir) ! (mapcar '(lambda (name) (concat dir "/" name)) ! (file-name-all-completions subdir dir)) )) dirlist))) ;; Manual-select-directories --- 293,303 ---- (defun Manual-select-subdirectories (dirlist subdir) (apply 'append (mapcar '(lambda (dir) (and (file-exists-p dir) ! (progn ! (or (string-match "/$" dir) ! (setq dir (concat dir "/"))) ! (mapcar '(lambda (name) (concat dir name)) ! (file-name-all-completions subdir dir) )))) dirlist))) ;; Manual-select-directories From bug-lucid-emacs-request@lucid.com Wed Oct 7 14:25:30 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06515; Wed, 7 Oct 92 14:25:30 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10655g; Wed, 7 Oct 92 14:20:45 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA14947; Wed, 7 Oct 92 17:21:55 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA14939; Wed, 7 Oct 92 17:21:49 -0400 Path: uunet!decwrl!spool.mu.edu!darwin.sura.net!ra!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Minor Installation Bug Message-Id: Date: 29 Sep 92 15:00:22 GMT Organization: COMSAT Labs Lines: 7 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: a1835ad814ae9be5c4de2031c4309dbd Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I just love the new paths setup. I just make /usr/local/bin/lemacs a symlink and everything works fine! Well, not really. This is a great idea, but unfortuntely, if you have a directory called /usr/local/etc you're in for a nasty surprise! Unfortunately, lemacs will think this is it's etc directory and nothing will work. I don't know a good solution for this. Does anyone else? From bug-lucid-emacs-request@lucid.com Wed Oct 7 14:48:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06585; Wed, 7 Oct 92 14:48:48 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10706g; Wed, 7 Oct 92 14:27:22 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15858; Wed, 7 Oct 92 17:27:16 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15849; Wed, 7 Oct 92 17:26:13 -0400 Path: uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!spool.mu.edu!sgiblab!adagio.panasonic.com!chorus.mei!oskgate0.mei!icspub!wnoc-kyo!atrwide!atr-hr!ebg From: ebg%atr-hr.atr.co.jp@lucid.com (Ed Gamble) Newsgroups: alt.lucid-emacs.bug Subject: Bug in Query-Replace with font-lock-mode on. Message-Id: Date: 7 Oct 92 05:41:38 GMT Organization: ATR Auditory and Visual Perception Research Labs., Japan Lines: 29 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Lemacs 19.3, Lisp mode with (font-lock-mode 1) ;; buffer contents, for example (defun foo () ) (defun funny-foo () ) ;; end of buffer contents Try (query-replace "foo" "bar" nil) ;; New buffer contents () ) () ) ;; End of new buffer contents Frequently I also see 'foo' replaced with 'foobar' Try (undo), (font-lock-mode 0), and then query-replace again... Now no problem. - Ed From bug-lucid-emacs-request@lucid.com Wed Oct 7 14:49:11 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06589; Wed, 7 Oct 92 14:49:11 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10705g; Wed, 7 Oct 92 14:26:59 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15754; Wed, 7 Oct 92 17:26:16 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15736; Wed, 7 Oct 92 17:25:51 -0400 Path: uunet!mcsun!sunic!psinntp!psinntp!lupine!pepper!mellon From: mellon@ncd.com (Ted Lemon) Newsgroups: alt.lucid-emacs.bug Subject: Re: lemacs & DECstations Message-Id: Date: 1 Oct 92 19:06:17 GMT References: <1992Sep29.212147.15767@beaver.cs.washington.edu> Lines: 15 Nntp-Posting-Host: pepper Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com klaiber@cs.washington.edu (Alexander Klaiber) writes: >HELP -- did *anyone* get 19.3 to run on a DECstation? Am I just >doing something stupid? Any fixes I ought to apply? Yup. I wound up putting #ifdefs around the contents of config.h so that they would only be scanned once, and put a #undef TERMINFO into m-pmax.h. I think you also need to define LIBS_TERMCAP to include both -lcurses and -ltermcap... It's fundamentally solid, but the configuration stuff isn't really there yet... _MelloN_ -- mellon@ncd.com uunet!lupine!mellon Member, League for Programming Freedom | To learn how software patents could cost you your right to program, contact the LPF - league@prep.ai.mit.edu From bug-lucid-emacs-request@lucid.com Wed Oct 7 14:50:50 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06593; Wed, 7 Oct 92 14:50:50 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10714g; Wed, 7 Oct 92 14:30:24 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15709; Wed, 7 Oct 92 17:28:05 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15695; Wed, 7 Oct 92 17:25:42 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!walter!att-out!pacbell.com!decwrl!wupost!zaphod.mps.ohio-state.edu!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Re: window manager "quit" nukes emacs In-Reply-To: alarson@src.honeywell.com's message of 30 Sep 92 15:43:53 GMT Message-Id: <1992Sep30.172836.9885@bmerh85.bnr.ca> Lines: 9 Organization: Bell Northern Research References: <1992Sep30.154353.27792@src.honeywell.com> Date: Wed, 30 Sep 92 17:28:36 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On 30 Sep 92 15:43:53 GMT, >>>>> In message <1992Sep30.154353.27792@src.honeywell.com>, >>>>> alarson@src.honeywell.com (Aaron Larson) wrote: Aaron> The Window manager "quit" button causes emacs to crash. Aaron> Preferred action is to have the screen be removed. In other words, Lucid Emacs should advertise and honour the WM_DELETE_WINDOW protocol. From kyle@uunet.uu.net Wed Oct 7 15:05:00 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06652; Wed, 7 Oct 92 15:05:00 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10781g; Wed, 7 Oct 92 14:48:44 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18342; Wed, 7 Oct 92 17:45:25 -0400 Received: from wendy-fate.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18336; Wed, 7 Oct 92 17:45:22 -0400 Path: uunet!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!bu.edu!nntp-read!jbw From: jbw@bigbird.bu.edu (Joe Wells) Newsgroups: alt.lucid-emacs.bug Subject: event-translate-hook (was: DEL key on HPUX) Message-Id: Date: 7 Oct 92 02:28:25 GMT References: <9210062051.AA02563@thymus.synaptics> Organization: Boston University Computer Science Department Lines: 15 In-Reply-To: daveg@thymus.synaptics.com's message of 6 Oct 92 20:51:01 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9210062051.AA02563@thymus.synaptics> daveg@thymus.synaptics.com (Dave Gillespie) writes: > Making x-rebind-key work with the new event model is hard, because > x-rebind-key is ASCII-centric. and coming up with some lisp-level data > structure that can efficiently map arbitrary events to arbitrary other > events is also nontrivial. I don't think it's worth the effort. How about "event-translate-hook", taking an event and returning a translated event; it would be equal to 'identity by default. Yeah! Great idea! -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details From bug-lucid-emacs-request@lucid.com Wed Oct 7 15:56:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06767; Wed, 7 Oct 92 15:56:29 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10994g; Wed, 7 Oct 92 15:49:56 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15729; Wed, 7 Oct 92 17:27:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15720; Wed, 7 Oct 92 17:25:47 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!charon.amdahl.com!pacbell.com!sgiblab!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Re: window manager "quit" nukes emacs In-Reply-To: barmar@think.com's message of 1 Oct 1992 10:19:49 GMT Message-Id: <1992Oct01.193501.6425@bmerh85.bnr.ca> Lines: 21 Organization: Bell Northern Research References: <1992Sep30.154353.27792@src.honeywell.com> <1992Sep30.172836.9885@bmerh85.bnr.ca> <1aejc5INNicj@early-bird.think.com> Date: Thu, 01 Oct 92 19:35:01 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On 1 Oct 1992 10:19:49 GMT, >>>>> In message <1aejc5INNicj@early-bird.think.com>, >>>>> barmar@think.com (Barry Margolin) wrote: Barry> Unfortunately, the original poster didn't say what window Barry> manager he's referring to. But in most window managers, Barry> WM_DELETE_WINDOW is invoked by the "close" button (it's the Barry> f.delete function in twm). The "quit" button (f.kill in twm) Barry> is used to forcibly kill the entire application, and works by Barry> closing the connection to the client, resulting in an error the Barry> next time the client tries to talk to the server. In Mwm, the "close" action sends a WM_DELETE_WINDOW message if the client is participating in that protocol, otherwise, it shuts down the connection. I actually prefer this method to having two separate methods, like twm. Of course, this can be a problem if the client says it is participating, but ignores the message. From bug-lucid-emacs-request@lucid.com Wed Oct 7 16:08:10 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06807; Wed, 7 Oct 92 16:08:10 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11053g; Wed, 7 Oct 92 15:56:30 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15717; Wed, 7 Oct 92 17:26:36 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15697; Wed, 7 Oct 92 17:25:43 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!sun-barr!cs.utexas.edu!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!alarson From: alarson@src.honeywell.com (Aaron Larson) Subject: Re: window manager "quit" nukes emacs In-Reply-To: barmar@think.com's message of 1 Oct 1992 10: 19:49 GMT Message-Id: <1992Oct1.162519.9442@src.honeywell.com> Nntp-Posting-Host: gendibal.src.honeywell.com Organization: Honeywell Systems & Research Center References: <1992Sep30.154353.27792@src.honeywell.com> <1992Sep30.172836.9885@bmerh85.bnr.ca> <1aejc5INNicj@early-bird.think.com> Date: Thu, 1 Oct 1992 16:25:19 GMT Lines: 24 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <1aejc5INNicj@early-bird.think.com> barmar@think.com (Barry Margolin) writes: barmar> In article <1992Sep30.172836.9885@bmerh85.bnr.ca> Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald) writes: >Aaron> The Window manager "quit" button causes emacs to crash. >Aaron> Preferred action is to have the screen be removed. >In other words, Lucid Emacs should advertise and honour the >WM_DELETE_WINDOW protocol. barmar> Unfortunately, the original poster didn't say what window manager he's barmar> referring to. Actually, I did, although it may not have been obvious at the end of the line there; Aaron> lemacs 19.3, distributed sparc binary, Sun's News server, SunOS 4.1, olwm. barmar> But in most window managers, WM_DELETE_WINDOW is invoked by barmar> the "close" button (it's the f.delete function in twm). The "quit" button barmar> (f.kill in twm) is used to forcibly kill the entire application, and ... In olwm, quit is delete. Aaron. From bug-lucid-emacs-request@lucid.com Wed Oct 7 16:31:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06887; Wed, 7 Oct 92 16:31:08 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA10690g; Wed, 7 Oct 92 14:25:21 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15567; Wed, 7 Oct 92 17:25:30 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15554; Wed, 7 Oct 92 17:25:13 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!caen!sol.ctr.columbia.edu!src.honeywell.com!alarson From: alarson@src.honeywell.com (Aaron Larson) Subject: window manager "quit" nukes emacs Message-Id: <1992Sep30.154353.27792@src.honeywell.com> Nntp-Posting-Host: gendibal.src.honeywell.com Organization: Honeywell Systems & Research Center Date: Wed, 30 Sep 1992 15:43:53 GMT Lines: 12 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com The Window manager "quit" button causes emacs to crash. Preferred action is to have the screen be removed. lemacs 19.3, distributed sparc binary, Sun's News server, SunOS 4.1, olwm. Fatal I/O Error 32 (Broken pipe) on display connection "gendibal:0.0" after 787 requests (787 known processed) with 0 events remaining. Autosaving and exiting... Sorry if this has been reported already. Patches aren't necessary, I'll wait 'till the next version. From bug-lucid-emacs-request@lucid.com Wed Oct 7 17:05:40 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06975; Wed, 7 Oct 92 17:05:40 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11296g; Wed, 7 Oct 92 16:57:29 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15643; Wed, 7 Oct 92 17:26:12 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15630; Wed, 7 Oct 92 17:25:27 -0400 Path: uunet!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!think.com!wupost!darwin.sura.net!mojo.eng.umd.edu!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Re: Minor Installation Bug Message-Id: Date: 29 Sep 92 18:01:32 GMT References: Organization: COMSAT Labs Lines: 29 Nntp-Posting-Host: neal.ctd.comsat.com In-Reply-To: neal@ctd.comsat.com's message of 29 Sep 92 11:00:22 X-Md4-Signature: 64d389a1b3c67f5adaebb50618d9c8ef Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I've got to stop following up my own stuff. Anyway, here's a simple (not particularly good) fix to keep lemacs from getting fooled into thinking that /usr/local/etc is it's etc dir when invoked as /usr/local/bin/lemacs. This may sound silly to you, but /usr/local/bin/lemacs is the most obvious place to put lemacs, and many pieces of software are wanting /usr/local/etc these days, so actual this problem is probably very common. *** startup.el~ Sat Aug 29 22:36:02 1992 --- startup.el Tue Sep 29 13:55:15 1992 *************** *** 542,548 **** ;; If in .../src/ or ../bin/, look for subdirs of this directory's ;; parent. ;; ! ((and (string-match "/\\(src\\|etc\\|lisp\\|lock\\|bin\\)/$" invocation-directory) (file-directory-p (setq tmp (concat (substring invocation-directory 0 --- 542,550 ---- ;; If in .../src/ or ../bin/, look for subdirs of this directory's ;; parent. ;; ! ((and ! (not (string-match "/usr/local/bin" invocation-directory)) ! (string-match "/\\(src\\|etc\\|lisp\\|lock\\|bin\\)/$" invocation-directory) (file-directory-p (setq tmp (concat (substring invocation-directory 0 From bug-lucid-emacs-request@lucid.com Wed Oct 7 17:07:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA06981; Wed, 7 Oct 92 17:07:25 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11294g; Wed, 7 Oct 92 16:59:24 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15613; Wed, 7 Oct 92 17:25:36 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15605; Wed, 7 Oct 92 17:25:23 -0400 Path: uunet!cs.utexas.edu!uwm.edu!rpi!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: alt.lucid-emacs.bug Subject: Re: window manager "quit" nukes emacs Date: 1 Oct 1992 10:19:49 GMT Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 23 Message-Id: <1aejc5INNicj@early-bird.think.com> References: <1992Sep30.154353.27792@src.honeywell.com> <1992Sep30.172836.9885@bmerh85.bnr.ca> Nntp-Posting-Host: gandalf.think.com Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <1992Sep30.172836.9885@bmerh85.bnr.ca> Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald) writes: >Aaron> The Window manager "quit" button causes emacs to crash. >Aaron> Preferred action is to have the screen be removed. >In other words, Lucid Emacs should advertise and honour the >WM_DELETE_WINDOW protocol. Unfortunately, the original poster didn't say what window manager he's referring to. But in most window managers, WM_DELETE_WINDOW is invoked by the "close" button (it's the f.delete function in twm). The "quit" button (f.kill in twm) is used to forcibly kill the entire application, and works by closing the connection to the client, resulting in an error the next time the client tries to talk to the server. Clients can set up custom handlers for this error, but they generally can't interact with the user in any useful way (i.e. it's not a good place to put a "do you really want to quit" prompt); in Emacs's case, it should probably be treated equivalently to receiving a SIGHUP on a normal tty, which I think should force an autosave and then exit (I don't know whether it already does this). -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar From bug-lucid-emacs-request@lucid.com Wed Oct 7 17:24:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07033; Wed, 7 Oct 92 17:24:48 PDT Received: by heavens-gate.lucid.com id AA11407g; Wed, 7 Oct 92 17:18:09 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA11368g; Wed, 7 Oct 92 17:12:49 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03637; Wed, 7 Oct 92 19:13:19 -0400 Received: from richter.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 191250.8357; Wed, 7 Oct 1992 19:12:50 EDT Received: from screamer.UUCP by richter.slc.com (4.1/SMI-4.1) id AA23885; Wed, 7 Oct 92 15:56:10 PDT Organization: Servio Corporation Received: by screamer.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA08634; Wed, 7 Oct 1992 18:52:40 -0400 Message-Id: <9210072252.AA08634@screamer.torolab.ibm.com> To: @richter.uucp:bug-lucid-emacs@lucid.com Subject: Changes made to Lucid Emacs for AIX 3.2.1. Cc: @screamer@uunet.UU.NET, @richter.UUCP:harry@richter.slc.com Date: Wed, 07 Oct 92 18:52:39 -0500 From: Harry Weeks In case someone is interested, here are changes I had to make to the Lucid Emacs 19.2 distribution from `labrea.stanford.edu' to run under AIX 3.2.1. Cheers! . . . . Harry -------- #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # CHANGES # config.h.diff # data.c.diff # editfns.c.diff # emacs.c.diff # filelock.c.diff # floatfns.c.diff # process.c.diff # ymakefile.diff # This archive created: Wed Oct 7 18:41:09 1992 export PATH; PATH=/bin:$PATH if test -f 'CHANGES' then echo shar: will not over-write existing file "'CHANGES'" else sed 's/^_//' << \SHAR_EOF > 'CHANGES' _Files `hftctl.c', `m-ibmrs6000.h', `s-aix-3-?.h', and `unexaix.c' were _added from the Epoch 4.2 distribution. _ _File `ymakefile' was changed to include new files and add special binder _directives for AIX 3.2, following Epoch. _ _Files `config.h', `data.c', `editfns.c', `emacs.c', `filelock.c', _`floatfns.c', and `process.c' were changed. _ _These changes allow Lucid Emacs to run under AIX 3.2.1. The changes made _were `quick and dirty,' e.g. `emacs.c' defines an external `__iconv_open' _that was left unresolved from `/lib/libX11.a' for undetermined reasons, _and the `INVISIBLE_TERMINAL_KLUDGE' was removed. SHAR_EOF if test 606 -ne "`wc -c < 'CHANGES'`" then echo shar: error transmitting "'CHANGES'" '(should have been 606 characters)' fi fi # end of overwriting check if test -f 'config.h.diff' then echo shar: will not over-write existing file "'config.h.diff'" else sed 's/^_//' << \SHAR_EOF > 'config.h.diff' _33c33 _< #include "s/s-sunos4.h" _--- _> #include "s/s-aix3-2.h" _40c40 _< #include "m/m-sparc.h" _--- _> #include "m/m-ibmrs6000.h" _139c139 _< #define INVISIBLE_TERMINAL_KLUDGE _--- _> /* #define INVISIBLE_TERMINAL_KLUDGE */ _155c155 _< /* #define NEED_REALPATH */ _--- _> #define NEED_REALPATH _164c164 _< #define USE_GCC _--- _> /* #define USE_GCC */ _173c173 _< /* #define LWLIB_USES_MOTIF */ _--- _> #define LWLIB_USES_MOTIF SHAR_EOF if test 408 -ne "`wc -c < 'config.h.diff'`" then echo shar: error transmitting "'config.h.diff'" '(should have been 408 characters)' fi fi # end of overwriting check if test -f 'data.c.diff' then echo shar: will not over-write existing file "'data.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'data.c.diff' _1519c1519 _< return (make_float (remainder (f1,f2))); _--- _> return (make_float (drem (f1,f2))); SHAR_EOF if test 107 -ne "`wc -c < 'data.c.diff'`" then echo shar: error transmitting "'data.c.diff'" '(should have been 107 characters)' fi fi # end of overwriting check if test -f 'editfns.c.diff' then echo shar: will not over-write existing file "'editfns.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'editfns.c.diff' _1345,1346c1345,1346 _< defsubr (&Sset_default_file_mode); _< defsubr (&Sunix_sync); _--- _> /* defsubr (&Sset_default_file_mode); */ _> /* defsubr (&Sunix_sync); */ SHAR_EOF if test 166 -ne "`wc -c < 'editfns.c.diff'`" then echo shar: error transmitting "'editfns.c.diff'" '(should have been 166 characters)' fi fi # end of overwriting check if test -f 'emacs.c.diff' then echo shar: will not over-write existing file "'emacs.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'emacs.c.diff' _57a58,59 _> int __iconv_open = 0; _> _620a623 _> #if 0 _647a651 _> #endif _789d792 _< #ifdef CLASH_DETECTION _791d793 _< #endif /* CLASH_DETECTION */ SHAR_EOF if test 141 -ne "`wc -c < 'emacs.c.diff'`" then echo shar: error transmitting "'emacs.c.diff'" '(should have been 141 characters)' fi fi # end of overwriting check if test -f 'filelock.c.diff' then echo shar: will not over-write existing file "'filelock.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'filelock.c.diff' _37,38d36 _< #ifdef CLASH_DETECTION _< _41a40,41 _> #ifdef CLASH_DETECTION _> _388a389 _> _399a401 _> #else /* CLASH_DETECTION */ _401c403,419 _< #endif /* CLASH_DETECTION */ _--- _> syms_of_filelock () _> { _> DEFVAR_LISP ("lock-directory", &Vlock_directory, "Don't change this"); _> DEFVAR_LISP ("superlock-path", &Vsuperlock_path, "Don't change this"); _> _> #ifdef PATH_LOCK _> Vlock_directory = build_string (PATH_LOCK); _> #else _> Vlock_directory = Qnil; _> #endif _> #ifdef PATH_SUPERLOCK _> Vsuperlock_path = build_string (PATH_SUPERLOCK); _> #else _> Vsuperlock_path = Qnil; _> #endif _> } _> #endif /* not CLASH_DETECTION */ SHAR_EOF if test 627 -ne "`wc -c < 'filelock.c.diff'`" then echo shar: error transmitting "'filelock.c.diff'" '(should have been 627 characters)' fi fi # end of overwriting check if test -f 'floatfns.c.diff' then echo shar: will not over-write existing file "'floatfns.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'floatfns.c.diff' _472c472 _< #if defined (BSD) || defined (IRIX) _--- _> #if defined (BSD) || defined (IRIX) || defined (AIX) SHAR_EOF if test 105 -ne "`wc -c < 'floatfns.c.diff'`" then echo shar: error transmitting "'floatfns.c.diff'" '(should have been 105 characters)' fi fi # end of overwriting check if test -f 'process.c.diff' then echo shar: will not over-write existing file "'process.c.diff'" else sed 's/^_//' << \SHAR_EOF > 'process.c.diff' _153c153 _< #if !defined (BSD) && !defined (UNIPLUS) && !defined (STRIDE) && !(defined (HPUX) && !defined (NOMULTIPLEJOBS)) && !defined (HAVE_WAIT_HEADER) _--- _> #if !defined (BSD) && !defined (UNIPLUS) && !defined (STRIDE) && !(defined (HPUX) && !defined (NOMULTIPLEJOBS)) && !defined (HAVE_WAIT_HEADER) && !defined (AIX) SHAR_EOF if test 320 -ne "`wc -c < 'process.c.diff'`" then echo shar: error transmitting "'process.c.diff'" '(should have been 320 characters)' fi fi # end of overwriting check if test -f 'ymakefile.diff' then echo shar: will not over-write existing file "'ymakefile.diff'" else sed 's/^_//' << \SHAR_EOF > 'ymakefile.diff' _155c155 _< LD=ld _--- _> LD=cc -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp _739a740 _> UNEXEC : config.h SHAR_EOF if test 101 -ne "`wc -c < 'ymakefile.diff'`" then echo shar: error transmitting "'ymakefile.diff'" '(should have been 101 characters)' fi fi # end of overwriting check # End of shell archive exit 0 From bug-lucid-emacs-request@lucid.com Wed Oct 7 17:25:19 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07037; Wed, 7 Oct 92 17:25:19 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11392g; Wed, 7 Oct 92 17:19:02 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15592; Wed, 7 Oct 92 17:25:42 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15583; Wed, 7 Oct 92 17:25:18 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!charon.amdahl.com!pacbell.com!decwrl!wupost!udel!rochester!cornell!uw-beaver!klaiber From: klaiber@cs.washington.edu (Alexander Klaiber) Subject: lemacs & DECstations Message-Id: <1992Sep29.212147.15767@beaver.cs.washington.edu> Organization: Computer Science & Engineering, U. of Washington, Seattle Date: Tue, 29 Sep 92 21:21:47 GMT Lines: 8 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com HELP -- did *anyone* get 19.3 to run on a DECstation? Am I just doing something stupid? Any fixes I ought to apply? Perplexed, Alexander Klaiber klaiber@cs.washington.edu From bug-lucid-emacs-request@lucid.com Wed Oct 7 17:33:26 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07061; Wed, 7 Oct 92 17:33:26 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11447g; Wed, 7 Oct 92 17:25:20 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15567; Wed, 7 Oct 92 17:25:30 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15554; Wed, 7 Oct 92 17:25:13 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!caen!sol.ctr.columbia.edu!src.honeywell.com!alarson From: alarson@src.honeywell.com (Aaron Larson) Subject: window manager "quit" nukes emacs Message-Id: <1992Sep30.154353.27792@src.honeywell.com> Nntp-Posting-Host: gendibal.src.honeywell.com Organization: Honeywell Systems & Research Center Date: Wed, 30 Sep 1992 15:43:53 GMT Lines: 12 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com The Window manager "quit" button causes emacs to crash. Preferred action is to have the screen be removed. lemacs 19.3, distributed sparc binary, Sun's News server, SunOS 4.1, olwm. Fatal I/O Error 32 (Broken pipe) on display connection "gendibal:0.0" after 787 requests (787 known processed) with 0 events remaining. Autosaving and exiting... Sorry if this has been reported already. Patches aren't necessary, I'll wait 'till the next version. From bug-lucid-emacs-request@lucid.com Wed Oct 7 18:04:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07107; Wed, 7 Oct 92 18:04:25 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11603g; Wed, 7 Oct 92 17:58:07 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15762; Wed, 7 Oct 92 17:26:42 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15755; Wed, 7 Oct 92 17:25:54 -0400 Path: uunet!dtix!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: Help make lemacs with CANNOT_DUMP Message-Id: Date: 5 Oct 92 13:32:59 GMT Organization: COMSAT Labs Lines: 15 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: fd59e9753df8088ca1e74b6fc4a4c39f Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I am trying to make lemacs using shared libs on hp9000/7xx. To do this, you need to avoid the unexec code by defining CANNOT_DUMP and CANNOT_UNEXEC (I have done this with emacs-18.58). But this doesn't work for lemacs-19.3. This is part of the problem: make -f xmakefile release ./temacs -batch -l inc-vers Cannot open load file: loadup.el*** Error code 255 This is cause in emacs.c defining CANNOT_DUMP causes loadup.el to be loaded right away. So where does the initial load-path come from in lemacs? (I am not setting this stuff in paths.h). Also, attempting to ignore this problem but just executing temacs causes a core dump. I haven't investigated this yet. From bug-lucid-emacs-request@lucid.com Wed Oct 7 18:05:44 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07111; Wed, 7 Oct 92 18:05:44 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11615g; Wed, 7 Oct 92 17:59:51 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA15828; Wed, 7 Oct 92 17:27:34 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA15809; Wed, 7 Oct 92 17:26:06 -0400 Path: uunet!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!bu.edu!nntp-read!jbw From: jbw@bigbird.bu.edu (Joe Wells) Newsgroups: alt.lucid-emacs.bug Subject: Re: pseudo bug in man.el Message-Id: Date: 7 Oct 92 02:31:49 GMT References: <92Oct6.182437edt.29115@plg.uwaterloo.ca> Organization: Boston University Computer Science Department Lines: 24 In-Reply-To: dmason%plg.uwaterloo.ca@lucid.com's message of 6 Oct 92 22:24:25 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <92Oct6.182437edt.29115@plg.uwaterloo.ca> dmason%plg.uwaterloo.ca@lucid.com (Dave Mason) writes: In our environment, MANPATH components end in /, hence the code in man.el produced things like /usr/man//cat1, /usr/man//cat1, etc. This is a sign that there is some Emacs Lisp code that is combining directories with filenames the wrong way. This particular case probably came from GNU Emacs. The wrong way: (concat directory name-within-directory) The right way: (expand-file-name name-within-directory directory) The wrong way is guaranteed to fail on VMS. Please folks, handle this right. Never ever use `concat' to combine a directory name with the name of a file in that directory. -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details From bug-lucid-emacs-request@lucid.com Wed Oct 7 19:05:38 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07191; Wed, 7 Oct 92 19:05:38 PDT Received: by heavens-gate.lucid.com id AA12004g; Wed, 7 Oct 92 19:04:46 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA11999g; Wed, 7 Oct 92 19:04:23 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA19305; Wed, 7 Oct 92 19:05:44 PDT Date: Wed, 7 Oct 92 19:05:44 PDT Message-Id: <9210080205.AA19305@thalidomide.lucid> X-Windows: A moment of convenience, a lifetime of regret. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: alarson@src.honeywell.com (Aaron Larson) Cc: bug-lucid-emacs@lucid.com Subject: Re: window manager "quit" nukes emacs Newsgroups: alt.lucid-emacs.bug In-Reply-To: Aaron Larson's message of Wed 30-Sep-92 15:43:53 GMT <1992Sep30.154353.27792@src.honeywell.com> References: <1992Sep30.154353.27792@src.honeywell.com> Oops, this used to work. Here's a fix. If there is more than one screen, then WM_DELETE_WINDOW deletes the screen. Otherwise, it exits emacs. -- Jamie =================================================================== RCS file: /cadillac-inferno-5/cvs-master/lemacs/src/event-Xt.c,v retrieving revision 1.7 diff -c -r1.7 event-Xt.c *** 1.7 1992/09/18 19:47:33 --- event-Xt.c 1992/10/08 01:34:22 *************** *** 879,885 **** RevertToParent, event->xclient.data.l[1]); UNBLOCK_INPUT; } ! goto OTHER; break; case MappingNotify: /* The user has run xmodmap */ --- 879,886 ---- RevertToParent, event->xclient.data.l[1]); UNBLOCK_INPUT; } ! else ! goto OTHER; break; case MappingNotify: /* The user has run xmodmap */ From bug-lucid-emacs-request@lucid.com Wed Oct 7 20:44:38 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07411; Wed, 7 Oct 92 20:44:38 PDT Received: by heavens-gate.lucid.com id AA12258g; Wed, 7 Oct 92 20:43:40 PDT Received: from plg.uwaterloo.ca by heavens-gate.lucid.com id AA12254g; Wed, 7 Oct 92 20:43:28 PDT Received: by plg.uwaterloo.ca id <29116>; Wed, 7 Oct 1992 23:44:35 -0400 From: Dave Mason To: jbw@bigbird.bu.edu Cc: bug-lucid-emacs@lucid.com In-Reply-To: Subject: pseudo bug in man.el Message-Id: <92Oct7.234435edt.29116@plg.uwaterloo.ca> Date: Wed, 7 Oct 1992 23:44:31 -0400 > From: jbw@bigbird.bu.edu (Joe Wells) > In article <92Oct6.182437edt.29115@plg.uwaterloo.ca> dmason%plg.uwaterloo.ca@lucid.com (Dave Mason) writes: > > In our environment, MANPATH components end in /, hence the code in > man.el produced things like /usr/man//cat1, /usr/man//cat1, etc. > > This is a sign that there is some Emacs Lisp code that is combining > directories with filenames the wrong way. This particular case probably > came from GNU Emacs. Much better solution. Here's the corrected (and tested) patch. ../Dave ; diff -bc man.elO man.el *** man.elO Wed Aug 26 04:18:20 1992 --- man.el Wed Oct 7 23:38:16 1992 *************** *** 293,299 **** (defun Manual-select-subdirectories (dirlist subdir) (apply 'append (mapcar '(lambda (dir) (and (file-exists-p dir) ! (mapcar '(lambda (name) (concat dir "/" name)) (file-name-all-completions subdir dir)) )) dirlist))) --- 293,299 ---- (defun Manual-select-subdirectories (dirlist subdir) (apply 'append (mapcar '(lambda (dir) (and (file-exists-p dir) ! (mapcar '(lambda (name) (expand-file-name name d ir)) (file-name-all-completions subdir dir)) )) dirlist))) From bug-lucid-emacs-request@lucid.com Wed Oct 7 21:06:05 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07459; Wed, 7 Oct 92 21:06:05 PDT Received: by heavens-gate.lucid.com id AA12310g; Wed, 7 Oct 92 21:05:17 PDT Received: from ntu.ac.sg by heavens-gate.lucid.com id AA12305g; Wed, 7 Oct 92 21:04:58 PDT Received: by ntu.ac.sg (5.57/Ultrix3.0-C) id AA13197; Thu, 8 Oct 92 11:47:58 +0800 Message-Id: <9210080347.AA13197@ntu.ac.sg> Sender: franks%ntu.ac.sg@lucid.com Date: Thu, 8 Oct 1992 11:49:53 +0730 To: bug-lucid-emacs@lucid.com From: franks%ntu.ac.sg@lucid.com (Frank Siebenlist) Subject: copy&paste behaviour When I select some text, choose copy from the edit menu, then select some other text, and subsequently choose paste from the edit menu, the last selected text is pasted in (duplicated) at the cursor, instead of being replaced by the previous one. Not sure what the Gospel of the Lispm has to say about this behaviour. Regards, Frank. PS. using the pending-del package From bug-lucid-emacs-request@lucid.com Wed Oct 7 21:38:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA07501; Wed, 7 Oct 92 21:38:06 PDT Received: by heavens-gate.lucid.com id AA12371g; Wed, 7 Oct 92 21:37:17 PDT Received: from scylla.lucid (scylla.lucid.com) by heavens-gate.lucid.com id AA12367g; Wed, 7 Oct 92 21:37:09 PDT Received: by scylla.lucid (4.1/SMI-4.1) id AA25811; Wed, 7 Oct 92 21:38:59 PDT Date: Wed, 7 Oct 92 21:38:59 PDT From: devin%scylla@lucid.com (Matthieu Devin) Message-Id: <9210080438.AA25811@scylla.lucid> To: franks%ntu.ac.sg@lucid.com (Frank Siebenlist) Cc: bug-lucid-emacs@lucid.com Subject: Re: copy&paste behaviour In-Reply-To: Frank Siebenlist's message of Thu 8-Oct-19 11:49:53 +0730 <9210080347.AA13197@ntu.ac.sg> References: <9210080347.AA13197@ntu.ac.sg> I think there was a bug in 19.3 related to PASTE not being pending delete. Make sure that the following is in your copy of pending-del.el: (put 'x-yank-clipboard-selection 'pending-delete t) From bug-lucid-emacs-request@lucid.com Thu Oct 8 04:48:14 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08657; Thu, 8 Oct 92 04:48:14 PDT Received: by heavens-gate.lucid.com id AA13147g; Thu, 8 Oct 92 04:47:22 PDT Received: from Relay.Prime.COM by heavens-gate.lucid.com id AA13143g; Thu, 8 Oct 92 04:47:06 PDT Received: from 31107711123637 (caller not authenticated) by Relay.Prime.COM; 08 Oct 92 07:41:15 EST Received: from CIS.Prime.COM [130.21.130.10] by APOLLO.CIS.Prime.COM ; 08 Oct 92 12:34:54 N Received: from mira.CIS.Prime.COM by CIS.Prime.COM (4.1/SMI-4.1.1/CIS) id AA26083; Thu, 8 Oct 92 12:31:22 BST Date: Thu, 8 Oct 92 12:31:22 BST From: David Hughes Message-Id: <9210081131.AA26083@CIS.Prime.COM> Received: by mira.CIS.Prime.COM (4.1/SMI-4.1) id AA02067; Thu, 8 Oct 92 12:31:08 BST To: bug-lucid-emacs@lucid.com Subject: Function Keys unmapped by VM and dired There is a problem in lemacs 19.3 running on a Sparc which I *know* did not exists in lemacs 19.2 : I use global-set-key to set (amongst others) the keys kp_subtract, kp_add, kp_enter, kp_decimal and insert to various functions. However, when I enter VM or dired these keys become 'undefined' although the other globally defined function keys retain their global settings. This does not happen with lemacs 19.2. As a workaround, I have had to add the following lines in my .emacs (define-key vm-mode-map 'kp_subtract 'recenter) (define-key vm-mode-map 'kp_add 'drag-up-display) (define-key vm-mode-map 'kp_enter 'drag-down-display) (define-key vm-mode-map 'kp_decimal 'forward-word) (define-key vm-mode-map 'insert 'backward-word) (define-key dired-mode-map 'kp_subtract 'recenter) (define-key dired-mode-map 'kp_add 'drag-up-display) (define-key dired-mode-map 'kp_enter 'drag-down-display) (define-key dired-mode-map 'kp_decimal 'forward-word) (define-key dired-mode-map 'insert 'backward-word) This horrible! Why are kp_subtract, kp_add, kp_enter, kp_decimal and insert getting zapped anyway? -- Regards, David From bug-lucid-emacs-request@lucid.com Thu Oct 8 07:40:49 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09737; Thu, 8 Oct 92 07:40:49 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA13490g; Thu, 8 Oct 92 07:39:57 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18299; Thu, 8 Oct 92 10:41:09 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA18287; Thu, 8 Oct 92 10:41:07 -0400 From: kingsley@hpwrce.mayfield.hp.com (Kingsley Morse) Date: Wed, 7 Oct 1992 23:35:46 GMT Subject: Please Help Message-Id: <56370001@hpwrce.mayfield.hp.com> Organization: HP Western Response Center Path: uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sdd.hp.com!scd.hp.com!hplextra!hpcc05!hpwrce!kingsley Newsgroups: alt.lucid-emacs.bug Lines: 56 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Please answer these 9 questions and return. 1.) Do you think equal rights for men and women is generally a good idea? Yes [ ] Sometimes [ ] No [ ] Haven't heard enough [ ] Other [ ] 2.) Are you pro choice? Yes [ ] Sometimes [ ] No [ ] Haven't heard enough [ ] Other [ ] 3.) Are you in favor of adoption? Yes [ ] Sometimes [ ] No [ ] Haven't heard enough [ ] Other [ ] 4.) Do you think men should be allowed to legally terminate their parental rights and responsibilities before fetal viability? Yes [ ] Sometimes [ ] No [ ] Haven't heard enough [ ] Other [ ] 5.) What sex are you? Male [ ] Female [ ] 6.) How old are you? Under 18 [ ] 19 to 65 [ ] Over 65 [ ] 7.) What religion are you? Protestant [ ] Catholic [ ] Jewish [ ] Other [ ] 8.) What political party are you affiliated with? Democratic [ ] Republican [ ] Other [ ] 9.) How many years of education have you completed? Grade School [ ] High School [ ] College [ ] More [ ] From bug-lucid-emacs-request@lucid.com Thu Oct 8 08:15:45 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09844; Thu, 8 Oct 92 08:15:45 PDT Received: by heavens-gate.lucid.com id AA13594g; Thu, 8 Oct 92 08:14:24 PDT Received: from plg.uwaterloo.ca by heavens-gate.lucid.com id AA13587g; Thu, 8 Oct 92 08:13:52 PDT Received: by plg.uwaterloo.ca id <29117>; Thu, 8 Oct 1992 11:14:57 -0400 From: Glen Ditchfield To: bug-lucid-emacs@lucid.com Subject: super-kill kills Message-Id: <92Oct8.111457edt.29117@plg.uwaterloo.ca> Date: Thu, 8 Oct 1992 11:14:47 -0400 My Emacs initialization code contains (autoload 'super-kill "super-kill" t) (global-set-key "\C-k" 'super-kill) super-kill.el and the uuencoded .elc follow. When I type C-k, I get a segmentation fault and core dump out of lemacs version 19.3 on a Sun 4. GDB 4.6 says (gdb) where #0 0xd6998 in strlen () #1 0x18748 in echo_prompt () at event-stream.c:1058 #2 0x198ec in Fread_key_sequence () at event-stream.c:1735 #3 0x5df30 in Ffuncall () at eval.c:1708 #4 0x6e350 in Fbyte_code () at bytecode.c:263 #5 0x5d3fc in Feval () at eval.c:1276 #6 0x5b07c in Fprogn () at eval.c:266 #7 0x5e5b0 in funcall_lambda () at eval.c:1919 #8 0x5e0b8 in Ffuncall () at eval.c:1708 #9 0x5a930 in Fcall_interactively () at callint.c:162 #10 0x33e24 in Fcommand_execute () at keyboard.c:654 #11 0x19558 in dispatch_command_event_internal () at event-stream.c:1527 #12 0x19298 in compose_command () at event-stream.c:1399 #13 0x18400 in dispatch_event_internal () at event-stream.c:963 #14 0x1981c in Fdispatch_event () at event-stream.c:1710 #15 0x33bbc in command_loop_1 () at keyboard.c:457 #16 0x5c548 in internal_condition_case () at eval.c:979 #17 0x33840 in command_loop_2 () at keyboard.c:384 #18 0x5bfc8 in internal_catch () at eval.c:798 #19 0x337ec in command_loop () at keyboard.c:358 #20 0x33320 in recursive_edit_1 () at keyboard.c:211 #21 0x33428 in Frecursive_edit () at keyboard.c:238 #22 0x32e04 in main () at emacs.c:420 ---------------------------------------- ;;; Super-kill acts as a kill prefix. You type C-k (or whatever ;;; super-kill is bound to) followed by a command key sequence, ;;; and super-kill kills some text depending on the command. If ;;; the key sequence is a printing character, this function acts ;;; much like 'zap-to-char. If the key sequence represents a ;;; movement command, the text between the starting and ending ;;; points is deleted. There are also a number of special ;;; commands. Unfortunately, there is no way to change the ;;; "bindings" of these keys short of editing the super-kill ;;; function. ;;; Hints: ;;; Bind 'recursive-edit to some control key such as C-\. Then ;;; you can move to the start of an arbitrary block of text, type ;;; C-k C-\, then move to the end of the text, hit ESC C-c, and ;;; the block of text will be deleted. ;;; Bind 'forward-sexp and 'backward-sexp to some control keys, ;;; you will be amazed at how often you want to delete the ;;; previous or following sexp. If you use arrow keys for ;;; 'forward-char and 'backward-char, bind the sexp commands to ;;; C-f and C-b. ;;; The effects of 'kill-line can be simulated (more or less) ;;; by C-k C-e and C-k C-l (where C-e is bound to 'end-of-line). ;;; Written by David Gudeman (gudeman@arizona.edu) April 1987 (defun super-kill (arg) "Kill text between current point and point after the next command. If the prefix-arg is ARG, and the following key stroke is: C-w delete-horizontal-space (as the command) C-o delete-blank-lines (as the command) C-l kill whole line and the ARG - 1 following lines C-j join lines current line to arg following lines, delete any fill prefix, and fixup whitespace printing char kill upto and including the ARGth occurrence of the character (which can be quoted). C-q char as above, except that char is quoted if it is not C-g. DEL kill back to the ARGth occurrence of the next char which is quoted if it is not C-g. movement command kill the buffer section between starting point and point after the command is executed with ARG as its prefix-arg C-k Read another character and interpret as above, but copy the indicated text to the kill-ring instead of killing it. More C-k's toggle from kill to copy. C-y Read another character and interpret as above, but toggle whether the text will be appended to the kill-ring or put in a new slot. otherwise no affect Called from an elisp function, takes one argument, the prefix arg." (interactive "P") (let* ((key (read-key-sequence nil)) (c (string-to-char key)) (n (prefix-numeric-value arg)) (buf (current-buffer)) (p1 (point)) p2 copy-only) (while (memq c '(?\C-k ?\C-y)) (if (= c ?\C-y) (setq last-command (if (equal 'kill-region last-command) nil 'kill-region)) (setq copy-only (not copy-only))) (setq key (read-key-sequence nil)) (setq c (string-to-char key))) (cond ((or (and (>= c ? ) (<= c ?~)) (= c ?\t)) (search-forward key nil nil n)) ((= c ?\C-m) (search-forward ?\n nil nil n)) ((= c ?\C-q) (search-forward (char-to-string (read-char)) nil nil n)) ((= c ?\C-?) (search-forward (char-to-string (read-char)) nil nil (- n))) ((= c ?\C-w) (delete-horizontal-space) (setq buf nil)) ;prevent deletion later ((= c ?\C-o) (delete-blank-lines) (setq buf nil)) ;ditto above ((= c ?\C-l) (beginning-of-line 1) (setq p1 (point)) (beginning-of-line (1+ n))) ((= c ?\C-j) (if (< n 0) ; p2 is used as an increment, (setq p2 1 c 0) ; and c is a direction (setq p2 -1 c 1)) (while (/= n 0) (end-of-line c) (setq p1 (point)) (forward-char 1) (and fill-prefix (looking-at fill-prefix) (forward-char (length fill-prefix))) (delete-region p1 (point)) (fixup-whitespace) (setq n (+ n p2))) (setq buf nil)) ;ditto above (t ;(let ((current-prefix-arg arg)) (call-interactively (key-binding key))));) (setq p2 (point)) (if (and (/= p1 p2) (eql buf (current-buffer))) (if copy-only (copy-region-as-kill p1 p2) (kill-region p1 p2)))) (sit-for 0)) ---------------------------------------- begin 644 super-kill.elc M"BAD969U;B!S=7!EF]N=&%L M+7-P86-E("AA2!F:6QL('!R969I>"P@86YD(&9I>'5P('=H M:71E&-E<'0@=&AA="!C:&%R(&ES('%U;W1E9"!I9B!I="!I'0@8VAA<@H)"0EW:&EC:"!I&5C=71E9"!W:71H($%21PH)"0EA M71E+6-O M9&4@(L&(S,$A&,T((1K.#"$;<."DT.!@X'7"*"6@'2#@8.!UPB+@>( M[N,AAR(@6VME>2!N:6P@8R!N(&%R9R!B=68@<#$@<#(@8V]P>2UO;FQY(&QA M"!T(')E860M:V5Y+7-E<75E;F-E('-T M"UN=6UE (global-set-key "\C-k" 'super-kill) Glen> super-kill.el and the uuencoded .elc follow. When I type C-k, I get a Glen> segmentation fault and core dump out of lemacs version 19.3 on a Sun 4. Glen> GDB 4.6 says Glen> (gdb) where Glen> #0 0xd6998 in strlen () Glen> #1 0x18748 in echo_prompt () at event-stream.c:1058 Glen> #2 0x198ec in Fread_key_sequence () at event-stream.c:1735 Glen> [...] Glen> (let* ((key (read-key-sequence nil)) Glen> (c (string-to-char key)) Glen> (n (prefix-numeric-value arg)) Glen> (buf (current-buffer)) Glen> (p1 (point)) Glen> p2 copy-only) According to the documentation of read-key-sequence: One arg, PROMPT, is a prompt string, or nil meaning do not prompt specially. Here is the function. It looks like it is assuming that the passed prompt is a valid string, and passing it to echo_prompt. It should check if the prompt is Qnil, and pass "" to echo_prompt if it is. If it is not Qnil, it should check if propmt is STRINGP, and if not, it should signal an error. This is what I will change my copy to do. Does this sound correct? DEFUN ("read-key-sequence", Fread_key_sequence, Sread_key_sequence, 1, 1, 0, "Read a [...]") (prompt) Lisp_Object prompt; { Lisp_Object result = Qnil; Lisp_Object event = Fallocate_event (); int count = specpdl_ptr - specpdl; struct gcpro gcpro1; GCPRO1 (event); QUIT; echo_prompt ((char *) XSTRING (prompt)->data); [...] From bug-lucid-emacs-request@lucid.com Thu Oct 8 10:45:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA10502; Thu, 8 Oct 92 10:45:12 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA14018g; Thu, 8 Oct 92 10:44:14 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00512; Thu, 8 Oct 92 13:45:18 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00504; Thu, 8 Oct 92 13:45:15 -0400 Path: uunet!mcsun!corton!loria!news.loria.fr!bosch From: bosch%loria.fr@lucid.com (Guido Bosch) Newsgroups: alt.lucid-emacs.bug Subject: Re: `x-set-point-and-insert-selection' bug Message-Id: Date: 8 Oct 92 16:23:58 GMT References: Distribution: alt Organization: INRIA-Lorraine / CRIN, Nancy, France Lines: 40 In-Reply-To: bosch@loria.fr's message of 8 Oct 92 15:14:08 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article bosch@loria.fr (Guido Bosch) writes: > Since version 19.3, the function `x-set-point-and-insert-selection' > (middle mouse click) has a strange behavior: I grabs all the text from > the beginning of the current selection up to te cursor position and > copies it to point. This happens only for copy actions within the same > buffer. > Is there a bug fix available? If there wasn't so far, here is one: The problem was that `x-set-point-and-insert-selection' (in x-mouse.el) sets the point to the mouse position *before* `x-get-selection' was called, but moving point also changes the selection. So `x-get-selection' finally grabed all text between the beginning of the primary selection and the new point. Here is a fix for `x-set-point-and-insert-selection': (defun x-set-point-and-insert-selection (event) "Sets point where clicked and insert the primary selection or the cut buffer" (interactive "e") (let ((text (or (condition-case () (x-get-selection) (error ())) (x-get-cutbuffer) (error "No selection or cut buffer available")))) (mouse-set-point event) (push-mark (point)) (insert text) ;; (if zmacs-regions (zmacs-activate-region)) )) -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@lucid.com Thu Oct 8 16:35:52 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11627; Thu, 8 Oct 92 16:35:52 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA14974g; Thu, 8 Oct 92 16:34:47 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA24942; Thu, 8 Oct 92 19:35:50 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA24938; Thu, 8 Oct 92 19:35:42 -0400 Control: cancel <56370001@hpwrce.mayfield.hp.com> Newsgroups: alt.lucid-emacs.bug Path: uunet!utcsri!torn!cunews!revcan!geovision!news From: news@geovision.gvc.com (News Administrator) Subject: cancel <56370001@hpwrce.mayfield.hp.com> Message-Id: <1992Oct8.183040.8155@geovision.gvc.com> Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario, Canada Date: Thu, 8 Oct 1992 18:30:40 GMT Lines: 4 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com cancel <56370001@hpwrce.mayfield.hp.com> in newsgroup alt.lucid-emacs.bug -- Paul Tomblin, News Administrator Extraordinaire. (pt@geovision.gvc.com) I just administer the news, I don't make or state policy. From bug-lucid-emacs-request@lucid.com Thu Oct 8 18:06:56 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11875; Thu, 8 Oct 92 18:06:56 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA15185g; Thu, 8 Oct 92 18:05:52 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA26283; Thu, 8 Oct 92 21:06:54 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA26279; Thu, 8 Oct 92 21:06:49 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!stanford.edu!ames!news.hawaii.edu!news.Hawaii.Edu!johnson From: johnson@natasha.ics.Hawaii.Edu (Philip Johnson) Subject: Probable bug in SORT Message-Id: Nntp-Posting-Host: natasha.ics.hawaii.edu Organization: University of Hawaii, Department of Computer Science Distribution: alt Date: Fri, 9 Oct 1992 00:54:57 GMT Lines: 37 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com The following code works fine under Epoch and Emacs, but breaks horribly under Lucid: (defun cached-attribute-sort (attribute node-ID-list lessp-fn) "Returns the list NODE-ID-LIST sorted by key ATTRIBUTE with comparison function LESSP-FN." (let ((pair-list (mapcar (function (lambda (node-ID) (cons (funcall attribute node-ID) node-ID))) node-ID-list))) (setq pair-list (sort pair-list (function (lambda (pair1 pair2) (funcall lessp-fn (car pair1) (car pair2)))))) (mapcar 'cdr pair-list))) The basic idea is to cons up a list of attribute/ID pairs, sort by attribute, then return the sorted IDs.(This avoids the overhead of calling the attribute function on every comparison.) For some reason, after sorting a list of these pairs, the attribute has been mangled. Straightforward application of this code fragment may not reliably reproduce the error. If more context is required, I can try to supply it. Philip Johnson ----------------------------------------------------------------------- Philip Johnson johnson@hawaii.edu Assistant Professor Collaborative Software Development Laboratory Department of Information and Computer Sciences University of Hawaii 2565 The Mall (808) 956-3489 Honolulu, HI 96822 Fax: (808) 956-3548 From bug-lucid-emacs-request@lucid.com Fri Oct 9 07:42:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA14421; Fri, 9 Oct 92 07:42:37 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA16613g; Fri, 9 Oct 92 07:35:59 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21457; Fri, 9 Oct 92 10:37:14 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA21453; Fri, 9 Oct 92 10:37:11 -0400 Path: uunet!paladin.american.edu!darwin.sura.net!jvnc.net!rutgers!sun-barr!sh.wide!wnoc-kyo!atrwide!atr-hr!ebg From: ebg%atr-hr.atr.co.jp@lucid.com (Ed Gamble) Newsgroups: alt.lucid-emacs.bug Subject: A Few Things Message-Id: Date: 9 Oct 92 00:25:22 GMT Organization: ATR Auditory and Visual Perception Research Labs., Japan Lines: 45 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Lucid-Emacs 19.3, Sparc, Sunos 4.1.2 1 ) ilisp.el references 'common-lisp-indent-hook, should read 'common-lisp-indent-function (Fixed below.) ;;;%%Common LISP (defdialect clisp "Common LISP" ilisp (if (not (fboundp 'common-lisp-indent-function)) ;; <<== Fixed (load "cl-indent")) (setq lisp-indent-hook 'common-lisp-indent-function) ;; <<== Fixed ....) 2) ilisp-menu.el can't find (require 'simple-menu). Neither can I. 3) Sound. Having bound some sounds with, for example, (load-sound-file "..../drip.au" 'undefined-key), I now get nice sounds; unfortunately, some error messages are printed as follows: audio: sst_open: SETQSIZE, Invalid argument <<== before the sound audio: sst_close: SETREG MMR2, Invalid argument <<== after the sound. 4) With (setq mode-motion-hook 'mode-motion-highlight-sexp) and font-lock: often an sexp is not highlighted until the mouse is on the second character or on one character beyond the last character in the sexp. 5) Here is a regexp for font-lock mode that will 'properly' highlight (def* (setf foo) (bar baz)) "^(def[-a-z]+\\s +\\(\\s(\\S)*\\s)\\|\\S(\\S *\\)" Although, it won't highlight the setf sexp until the closing paren and still (defun foo) highlights the closing paren. 6) Occasionally in ilisp-mode I have lost the comint connection to my running lisp, been thrown into the lisp debugger or lost lemacs altogether. Seems to happen when hitting the "I (ignore)" option to a failed 'compile-lisp-defun command. Maybe somebody has seen this, otherwise I'll report more fully later Jamie/Lucid -- keep up the good work. - Ed From bug-lucid-emacs-request@lucid.com Fri Oct 9 14:08:15 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15688; Fri, 9 Oct 92 14:08:15 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA17920g; Fri, 9 Oct 92 14:05:46 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20596; Fri, 9 Oct 92 17:07:00 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA20589; Fri, 9 Oct 92 17:06:54 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!hubcap!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: core dump while garbage collecting Message-Id: <1992Oct09.194301.815@bmerh85.bnr.ca> Lines: 137 Organization: Bell Northern Research Date: Fri, 09 Oct 92 19:43:01 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com While running GNUS within Lucid Emacs (GNU Emacs 19.3.1 Lucid of Tue Sep 22 1992 on bmerh166 (hpux)), on an HP9000s425 running HP-UX 7.05, compiled by gcc 2.2.2, with X11R5 libraries, I got a core dump while (I think) advancing to another article. Here is some information from GDB. It looks like the garbage collection may have been corrupted. I'm afraid it would be hard to reproduce this on demand, although it does seem to die like this every so often. I'm no GC expert, so it's hard to determine what is going on. Any hints would be appreciated. I'll keep the (4Meg!) core file around for a while so that it can be poked around in, if anybody can give me any hints about what should be examined. Jamie, please tell me this is fixed in 19.4! :-) Thanks, Hamish. (gdb) core-file ../../core Core was generated by `lemacs'. #0 0xd7400 in _kill () (gdb) where #0 0xd7400 in _kill () #1 0xd2e7e in raise () #2 0x424f2 in compact_string_chars () at alloc.c:1842 #3 0x420aa in gc_sweep () at alloc.c:1516 #4 0x4287a in Fgarbage_collect () at alloc.c:2035 #5 0x4ccd4 in Ffuncall (nargs=2, args=0xffefce24) at eval.c:1724 #6 0x5c9c0 in Fbyte_code (bytestr=-1942618496, vector=-1875454336, maxdepth=7) at bytecode.c:428 #7 0x4d3b8 in funcall_lambda (fun=3617984, nargs=0, arg_vector=0xffefcf3c) at eval.c:1969 #8 0x4d01a in Ffuncall (nargs=406271168, args=0xffefcf38) at eval.c:1845 #9 0x5c9c0 in Fbyte_code (bytestr=-1942628276, vector=-1875454272, maxdepth=2) at bytecode.c:428 #10 0x4d3b8 in funcall_lambda (fun=3618016, nargs=0, arg_vector=0xffefd04c) at eval.c:1969 #11 0x4d01a in Ffuncall (nargs=406271200, args=0xffefd048) at eval.c:1845 #12 0x5c9c0 in Fbyte_code (bytestr=-1942664468, vector=-1875453760, maxdepth=3) at bytecode.c:428 #13 0x4d3b8 in funcall_lambda (fun=3618496, nargs=0, arg_vector=0xffefd160) at eval.c:1969 #14 0x4d01a in Ffuncall (nargs=406271680, args=0xffefd15c) at eval.c:1845 #15 0x5c9c0 in Fbyte_code (bytestr=-1942629868, vector=-1875591104, maxdepth=2) at bytecode.c:428 #16 0x4d3b8 in funcall_lambda (fun=3457056, nargs=0, arg_vector=0xffefd220) at eval.c:1969 #17 0x4d1b4 in apply_lambda (fun=406110240, args=68712452, eval_flag=1) at eval.c:1900 #18 0x4c7a0 in Feval (form=337904732) at eval.c:1441 #19 0x4ba32 in Fcondition_case (args=340319484) at eval.c:968 #20 0x5cd4a in Fbyte_code (bytestr=-1943794856, vector=-1877158176, maxdepth=3) at bytecode.c:582 #21 0x4c6e0 in Feval (form=337904708) at eval.c:1418 #22 0x4aada in Fprogn (args=337904684) at eval.c:291 #23 0x4d372 in funcall_lambda (fun=337904772, nargs=0, arg_vector=0xffefd6ac) at eval.c:1967 #24 0x4d01a in Ffuncall (nargs=337904772, args=0xffefd6a8) at eval.c:1845 #25 0x4cb40 in apply1 (fn=-2078014504, arg=68712452) at eval.c:1566 #26 0x4991c in Fcall_interactively (function=69469144, record=68712452) at callint.c:265 #27 0x26898 in Fcommand_execute (cmd=-2078014504, record=68712452) at keyboard.c:701 #28 0x12b30 in dispatch_command_event_internal (event=0x2302a0, leaf=1) at event-stream.c:1590 #29 0x12966 in compose_command (event=0x2302a0, execute_p=1) at event-stream.c:1501 #30 0x11efe in dispatch_event_internal (event=1747124896, execute_p=1) at event-stream.c:988 #31 0x12da8 in Fdispatch_event (event=1747124896) at event-stream.c:1714 #32 0x266f6 in command_loop_1 (dummy=68712732) at keyboard.c:508 #33 0x4badc in internal_condition_case (bfun=0x2659c , handlers=68712732, hfun=0x260e0 ) at eval.c:1002 #34 0x263d6 in command_loop_2 (dummy=68712452) at keyboard.c:388 #35 0x4b6e2 in internal_catch (tag=37, func=0x263bc , arg=68712452) at eval.c:814 #36 0x26398 in command_loop () at keyboard.c:367 #37 0x25fc8 in recursive_edit_1 () at keyboard.c:221 #38 0x26078 in Frecursive_edit () at keyboard.c:250 #39 0x258d2 in main (argc=3, argv=0xffefdca4, envp=0xffefdcb4) at emacs.c:817 (gdb) frame 28 #28 0x12b30 in dispatch_command_event_internal (event=0x2302a0, leaf=1) at event-stream.c:1590 Source file is more recent than executable. (gdb) p event $3 = (struct Lisp_Event *) 0x2302a0 (gdb) p *$ $4 = {event_type = -2147483647, channel = 941362176, timestamp = 1398883868, event = {key = {key = 103, modifiers = 0 '\000'}, button = {button = 103, modifiers = 0 '\000', x = -1091576147, y = -1091576147}, motion = { x = 103, y = 11386607}, process = {process = 103}, timeout = { function = 103, object = 11386607, id_number = -559038737}, eval = { function = 103, object = 11386607}, magic = { underlying_event = {"\000\000\000g\000->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o^->o"}}}, next = 0x0} (gdb) frame 2 #2 0x424f2 in compact_string_chars () at alloc.c:1842 (gdb) p size $7 = 1 (gdb) p fullsize $8 = 969894920 (gdb) p string $9 = (struct Lisp_String *) 0x37d461 (gdb) p *$ $10 = {size = 969894912, dup_list = 1540, data = 0x18780400
} (gdb) i locals from_s_chars = (struct string_chars *) 0x39cf68 to_s_chars = (struct string_chars *) 0x4e8ac4 string = (struct Lisp_String *) 0x37d461 size = 1 fullsize = 969894920 from_pos = 3932 to_sb = (struct string_chars_block *) 0x4e8000 to_pos = 2772 from_sb = (struct string_chars_block *) 0x39c000 (gdb) i frame Stack level 2, frame at 0xffefcd4c: pc = 0x424f2 in compact_string_chars (alloc.c:1842); saved pc 0x420aa called by frame at 0xffefcd7c, caller of frame at 0xffefcd28 source language c. Arglist at 0xffefcd4c, args: Locals at 0xffefcd4c, Previous frame's sp is 0xffefcd54 Saved registers: d2 at 0xffefcd30, d3 at 0xffefcd34, d4 at 0xffefcd38, a2 at 0xffefcd3c, a3 at 0xffefcd40, a4 at 0xffefcd44, a5 at 0xffefcd48, fp at 0xffefcd4c, pc at 0xffefcd50 (gdb) p *from_s_chars $11 = {string = 0x37d461, chars = {"0"}} (gdb) p *to_s_chars $12 = {string = 0x7265706c, chars = {"y"}} (gdb) p *string $13 = {size = 969894912, dup_list = 1540, data = 0x18780400
} (gdb) p *to_sb $14 = {next = 0x4ea000, prev = 0x4e6000, pos = 8168, chars = {"\000Hm Date: 11 Oct 92 00:36:29 GMT References: <1992Sep30.154353.27792@src.honeywell.com> <9210080205.AA19305@thalidomide.lucid> Organization: Boston University Computer Science Department Lines: 11 In-Reply-To: jwz@lucid.com's message of 8 Oct 92 02:05:44 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9210080205.AA19305@thalidomide.lucid> jwz@lucid.com (Jamie Zawinski) writes: If there is more than one screen, then WM_DELETE_WINDOW deletes the screen. Otherwise, it exits emacs. Surely there is a way to disable this misfeature so it can't kill your Emacs, right? I mean, really, Emacs should never exit at all. -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details From bug-lucid-emacs-request@lucid.com Mon Oct 12 08:23:05 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA23607; Mon, 12 Oct 92 08:23:05 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA24098g; Mon, 12 Oct 92 08:19:48 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA23443; Mon, 12 Oct 92 11:21:08 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA23436; Mon, 12 Oct 92 11:21:06 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!convex!news.utdallas.edu!corpgate!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Re: window manager "quit" nukes emacs In-Reply-To: jwz@lucid.com's message of Wed, 7 Oct 1992 19:05:44 PDT Message-Id: <1992Oct12.143716.615@bmerh85.bnr.ca> Lines: 12 Organization: Bell Northern Research References: <1992Sep30.154353.27792@src.honeywell.com> <9210080205.AA19305@thalidomide.lucid> Date: Mon, 12 Oct 92 14:37:16 GMT Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com >>>>> On Wed, 7 Oct 1992 19:05:44 PDT, >>>>> In message <9210080205.AA19305@thalidomide.lucid>, >>>>> jwz@lucid.com (Jamie Zawinski) wrote: Jamie> If there is more than one screen, then WM_DELETE_WINDOW deletes Jamie> the screen. Otherwise, it exits emacs. Hmm... Lucid Emacs still doesn't advertise its willingness to accept this message (by including WM_DELETE_WINDOW in WM_PROTOCOLS), so Mwm *won't* send it a WM_DELETE_WINDOW message. It will just break the X connection. If Lucid is willing to accept and process these messages, it should say so, IMHO. From bug-lucid-emacs-request@lucid.com Mon Oct 12 11:25:20 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24099; Mon, 12 Oct 92 11:25:20 PDT Received: by heavens-gate.lucid.com id AA24805g; Mon, 12 Oct 92 11:23:47 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA24800g; Mon, 12 Oct 92 11:23:33 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA06429; Mon, 12 Oct 92 11:25:00 PDT Date: Mon, 12 Oct 92 11:25:00 PDT Message-Id: <9210121825.AA06429@thalidomide.lucid> X-Windows: The problem for your problem. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Cc: bug-lucid-emacs@lucid.com Subject: Re: window manager "quit" nukes emacs Newsgroups: alt.lucid-emacs.bug In-Reply-To: Hamish Macdonald's message of Mon 12-Oct-92 14:37:16 GMT <1992Oct12.143716.615@bmerh85.bnr.ca> References: <1992Oct12.143716.615@bmerh85.bnr.ca> <1992Sep30.154353.27792@src.honeywell.com> <9210080205.AA19305@thalidomide.lucid> In message <1992Oct12.143716.615@bmerh85.bnr.ca> Hamish Macdonald wrote: > > Hmm... Lucid Emacs still doesn't advertise its willingness to accept > this message (by including WM_DELETE_WINDOW in WM_PROTOCOLS), so Mwm > *won't* send it a WM_DELETE_WINDOW message. xprop says: WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW, WM_TAKE_FOCUS -- Jamie From bug-lucid-emacs-request@lucid.com Mon Oct 12 15:30:24 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA24845; Mon, 12 Oct 92 15:30:24 PDT Received: by heavens-gate.lucid.com id AA25654g; Mon, 12 Oct 92 15:29:26 PDT Received: from motgate.mot.com by heavens-gate.lucid.com id AA25650g; Mon, 12 Oct 92 15:29:16 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com (4.1/SMI-4.0) id AA12482; Mon, 12 Oct 92 17:30:53 CDT Received: from pts1.pts.mot.com ([145.4.3.2]) by pobox.mot.com (4.1/SMI-4.0) id AA03707; Mon, 12 Oct 92 17:30:52 CDT Received: from pts4.pts.mot.com by pts1.pts.mot.com (4.1/SMI-4.1) id AA23215; Mon, 12 Oct 92 18:31:24 EDT Received: from msn25.motorola by pts4.pts.mot.com (4.1/SMI-4.1) id AA04732; Mon, 12 Oct 92 18:30:37 EDT Date: Mon, 12 Oct 92 18:30:37 EDT From: ex594bw@pts.mot.com (Bob Weiner) Message-Id: <9210122230.AA04732@pts4.pts.mot.com> Received: by msn25.motorola (4.1/SMI-4.1) id AA20730; Mon, 12 Oct 92 18:30:27 EDT To: bug-lucid-emacs@lucid.com Subject: 'event-window' should consider modeline part of window. Reply-To: bob_weiner@pts.mot.com As its documentation states, it returns nil if an event occurs on a modeline. But if you look at the Emacs window-edges function, it includes the modeline within a window's boundaries, so this behavior seems inconsistent. There are times when one wants to know the window of a modeline clicked upon or that a modeline has been clicked upon, but 'event-window' just returns nil in this case, which I can't see as ever being as helpful. Hyperbole, for example, needs this functionality for some of its mouse handling. One could manually compute the window of the modeline clicked upon from the event-x and event-y coordinates but since 'event-window' exists, I think it should handle it. Thanks, Bob From bug-lucid-emacs-request@lucid.com Wed Oct 14 14:01:02 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA01513; Wed, 14 Oct 92 14:01:02 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02143g; Wed, 14 Oct 92 13:56:54 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA10011; Wed, 14 Oct 92 16:58:09 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA10003; Wed, 14 Oct 92 16:58:03 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!utcsri!torn!cunews!nrcnet0!bnrgate!bmerh85!bmerh85!hamish From: Hamish.Macdonald%x400gate.bnr.ca@lucid.com (Hamish Macdonald) Subject: Lucid Emacs, HPUX, and bcopy/bzero Message-Id: <1992Oct14.180536.7906@bmerh85.bnr.ca> Lines: 110 Organization: Bell Northern Research Date: Wed, 14 Oct 92 18:05:36 GMT Xref: uunet alt.lucid-emacs.bug:274 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Since first building Lucid Emacs, I have been seeing problems with inferior processes. When running programs within cmushell, I could not interrupt the processes. Also, I run gnuserv, and when I quit lemacs, the gnuserv process did not die. I finally got around to trying to debug what is going on. It turns out that the "kill" in process-send-signal was failing, with an ESRCH (no such process found). This is when emacs is trying to kill the entire process group by calling kill with the negated group id. When I first compiled Lucid Emacs, it failed linking with a million unresolved references to bcopy and bzero. I said, "No problem, I'll just link in /usr/lib/libBSD.a", to get the bcopy/bzero from it. Lucid emacs linked ok, and then ran fine other than the problems above. I suspect that my problem is that emacs calls setpgrp expecting the SYSV semantics (since USG is defined in the s-hpux.h config file), but the setpgrp linked in is the one in /usr/lib/libBSD.a which has the BSD semantics. I decided to get rid of /usr/lib/libBSD.a. It was somewhat painful. I managed to get rid of most of the bcopy/bzero references by changing m-hp9000s300.h to include the following lines: /* #ifdef HPUX_5 */ #define bcopy(a,b,s) memcpy (b,a,s) #define bzero(a,s) memset (a,0,s) #define bcmp memcmp /* #endif */ In the lucid m-hp9000s300.h file, the "#ifdef" and "#endif" above are not commented out. In the GNU emacs distribution lying around here (18.56) they are commented out, with the following comment: /* Define the BSTRING functions in terms of the sysV functions. Version 6 of HP-UX supplies these in the BSD library, but that library has reported bugs in `signal'. */ This means that they had a good reason to have these definitions compiled in. I don't know if this was changed in the Lucid Emacs distribution or in an Emacs distribution since 18.56. By making these definitions active, I managed to get rid of most of the problems with compiling Lucid Emacs without bcopy/bzero. Unfortunately, there were a few places which didn't include "config.h", so I had to fix those up by hand. These places were gmalloc.c, and lwlib.c. In gmalloc.c, they use memset, memcpy and memmove. Unfortunately, if neither __GNU_LIBRARY__, STDC_HEADERS nor USG are defined, they #define memset to be bzero etc. Since gmalloc.c didn't include config.h, it didn't get USG defined, so the above definitions were active. The fix in this case was to insert: #ifdef emacs #include "config.h" #endif at the beginning of gmalloc.c. The "EmacsShell.c" source file calls bcopy at one point. I added a #define of bcopy to call memcpy to this file. Unfortunately, lwlib.c calls bzero in a few places. I changed lwlib-internal.h to #define bzero(a,s) as memset(a,0,s) if __hpux was defined. I didn't like to have to do this hack, however. I find it ironic that we are told that we need an ANSI compiler to compile Lucid Emacs, but the source (especially the new source, EmacsShell.c and lwlib.c, which don't come from emacs) uses this non-ANSI bzero and bcopy routines when an ANSI programming environment will have the ANSI routines memcpy and memset available. Perhaps lwlib.c and EmacsShell.c should be changed to use the memset and memcpy routines rather than bzero and bcopy. I would imagine that the number of programming environments without the b* routines greatly outnumbers those without the mem* routines. I recommend that some/all of the changes I've described above be included in the Lucid Emacs source distribution. These are: 1) Change m-hp9000s300.h to #define bcopy/bzero/bcmp as memcpy/memset/memcmp. 2) Change gmalloc.c to include "config.h" if compiling emacs (or find some other solution to having gmalloc.c use memset and memcpy). 3) Modify the EmacsShell.c source to avoid the use of bcopy. 4) Modify the lwlib sources to avoid the use of bzero. You'll be happy to know that after doing all this and compiling/linking/dumping Lucid emacs, I now have a lemacs which properly handles subprocesses. The gnuserv process correctly dies when I quit emacs, and I can interrupt processes running under my shell. From bug-lucid-emacs-request@lucid.com Wed Oct 14 20:26:53 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA02913; Wed, 14 Oct 92 20:26:53 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA03453g; Wed, 14 Oct 92 20:25:19 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA26952; Wed, 14 Oct 92 23:26:44 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA26947; Wed, 14 Oct 92 23:26:40 -0400 From: kingsley@hpwrce.mayfield.hp.com (Kingsley Morse) Date: Fri, 9 Oct 1992 15:33:36 GMT Subject: Re: Please Help Message-Id: <56370002@hpwrce.mayfield.hp.com> Organization: HP Western Response Center Path: uunet!zaphod.mps.ohio-state.edu!swrinde!sdd.hp.com!scd.hp.com!hplextra!hpcc05!hpwrce!kingsley Newsgroups: alt.lucid-emacs.bug References: <56370001@hpwrce.mayfield.hp.com> Lines: 4 Xref: uunet alt.lucid-emacs.bug:276 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com Oops! My apologies for posting my previous "Please Help" survey to this group. It was an honest mistake and won't happen again. Kingsley From bug-lucid-emacs-request@lucid.com Thu Oct 15 10:54:06 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA09796; Thu, 15 Oct 92 10:54:06 PDT Received: by heavens-gate.lucid.com id AA05550g; Thu, 15 Oct 92 10:50:38 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA05537g; Thu, 15 Oct 92 10:49:50 PDT Received: by moebius.loria.fr id AA05721 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Thu, 15 Oct 92 18:50:53 +0100 Date: Thu, 15 Oct 92 18:50:53 +0100 From: Guido Bosch Message-Id: <9210151750.AA05721@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Subject: gnus-lucid.el patch Reply-To: Guido BOSCH Here is a patch for gnus-lucid.el that does the following: - add a "Forward Article" entry to the `gnus-Subject-menu'. - change all `defvar's in `defconst's (they are easily re-evaluable after modifications). - add a `gnus-Article-menu'. - makes `gnus-install-mouse-tracker' more custommizable. Enjoy Guido -------------------------- gnus-lucid-patch -------------------------- *** gnus-lucid.el~ Mon Aug 3 01:37:03 1992 --- gnus-lucid.el Thu Oct 15 17:15:51 1992 *************** *** 21,27 **** ;;; Right button pops up a menu of commands in Newsgroup and Subject buffers. ;;; Middle button selects indicated newsgroup or article. ! (defvar gnus-Subject-menu '("GNUS Subject Commands" ["Select Article / Next Page" gnus-Subject-next-page t] ["Prev Page" gnus-Subject-prev-page t] --- 21,27 ---- ;;; Right button pops up a menu of commands in Newsgroup and Subject buffers. ;;; Middle button selects indicated newsgroup or article. ! (defconst gnus-Subject-menu '("GNUS Subject Commands" ["Select Article / Next Page" gnus-Subject-next-page t] ["Prev Page" gnus-Subject-prev-page t] *************** *** 37,42 **** --- 37,43 ---- ["Mail Reply (Citing Original)" gnus-Subject-mail-reply-with-original t] ["Post Reply" gnus-Subject-post-reply t] ["Post Reply (Citing Original)" gnus-Subject-post-reply-with-original t] + ["Forward Article" gnus-Subject-mail-forward t] "----" ["Mark Article as Read" gnus-Subject-mark-as-read-forward t] ["Mark Article as Unread" gnus-Subject-mark-as-unread-backward t] *************** *** 46,52 **** gnus-Subject-catch-up-and-exit t] )) ! (defvar gnus-Group-menu '("GNUS Group Commands" ["Select Newsgroup" gnus-Group-read-group t] ["Unsubscribe Newsgroup" gnus-Group-unsubscribe-current-group t] --- 47,53 ---- gnus-Subject-catch-up-and-exit t] )) ! (defconst gnus-Group-menu '("GNUS Group Commands" ["Select Newsgroup" gnus-Group-read-group t] ["Unsubscribe Newsgroup" gnus-Group-unsubscribe-current-group t] *************** *** 64,69 **** --- 65,80 ---- ["Quit GNUS" gnus-Group-exit t] )) + (defconst gnus-Article-menu + '("GNUS Article Commands" + ["Next Page" gnus-Article-next-page t] + ["Prev Page" gnus-Article-prev-page t] + ["Pop Article History" gnus-Article-pop-article t] + ["Refer Article" gnus-Article-refer-article t] + ["Show Subjects" gnus-Article-show-subjects t] + ["Gnus Info Find Node" gnus-Info-find-node t] + ["Describe Briefly" gnus-Article-describe-briefly t])) + (defun gnus-Subject-menu (e) (interactive "e") (mouse-set-point e) *************** *** 78,83 **** --- 89,98 ---- (search-forward ":" nil t) (popup-menu gnus-Group-menu)) + (defun gnus-Article-menu (e) + (interactive "@e") + (popup-menu gnus-Article-menu)) + (defun gnus-Group-mouse-read-group (e) (interactive "e") (mouse-set-point e) *************** *** 98,103 **** --- 113,119 ---- (define-key gnus-Subject-mode-map 'button3 'gnus-Subject-menu) (define-key gnus-Group-mode-map 'button3 'gnus-Group-menu) + (define-key gnus-Article-mode-map 'button3 'gnus-Article-menu) ;;; Put message headers in boldface, etc... *************** *** 201,207 **** (defun gnus-install-mouse-tracker () (require 'mode-motion) ! (setq mode-motion-hook 'mode-motion-highlight-line)) (add-hook 'gnus-Subject-mode-hook 'gnus-install-mouse-tracker) (add-hook 'gnus-Group-mode-hook 'gnus-install-mouse-tracker) --- 217,225 ---- (defun gnus-install-mouse-tracker () (require 'mode-motion) ! ;; This allows further mode-motion-hook custommization, e.g., in the .emacs ! (if (eq (default-value 'mode-motion-hook) mode-motion-hook) ! (setq mode-motion-hook 'mode-motion-highlight-line))) (add-hook 'gnus-Subject-mode-hook 'gnus-install-mouse-tracker) (add-hook 'gnus-Group-mode-hook 'gnus-install-mouse-tracker) From bug-lucid-emacs-request@lucid.com Thu Oct 15 17:49:49 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11989; Thu, 15 Oct 92 17:49:49 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA07322g; Thu, 15 Oct 92 17:46:48 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA26294; Thu, 15 Oct 92 20:48:13 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA26287; Thu, 15 Oct 92 20:48:11 -0400 Path: uunet!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ira.uka.de!gmd.de!Germany.EU.net!mcsun!uknet!edcastle!edcogsci!cogsci!rjc From: rjc@cogsci.ed.ac.uk (Richard Caley) Newsgroups: alt.lucid-emacs.bug Subject: Cursor positioning bug? Message-Id: Date: 15 Oct 92 16:16:53 GMT Distribution: alt Organization: Human Communication Research Center Lines: 21 Xref: uunet alt.lucid-emacs.bug:278 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com (19.2, Sun, X11R4) I have some problems with some code which works fine in epoch or emacs-18. This code does some stuff, then goes to the top of the buffer and searches repeatedly for different things to get to where it aught to be. Anyway, after all this lemacs ends up showing me the beginning of the buffer with the cursor at some place which bears no resemblence to any of the patterns. It doesn't happen when I use the debugger. Before I start getting into the details of what is going on, I thought I'd ask if a bug like this is known in 19.2 and if there is a workaround. -- rjc@cogsci.ed.ac.uk _O_ |< From bug-lucid-emacs-request@lucid.com Fri Oct 16 03:44:25 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA13943; Fri, 16 Oct 92 03:44:25 PDT Received: by heavens-gate.lucid.com id AA08517g; Fri, 16 Oct 92 03:42:40 PDT Received: from moebius.loria.fr by heavens-gate.lucid.com id AA08513g; Fri, 16 Oct 92 03:42:15 PDT Received: by moebius.loria.fr id AA07131 (5.65c+/IDA-1.4.3 for bug-lucid-emacs@lucid.com); Fri, 16 Oct 92 11:43:15 +0100 Date: Fri, 16 Oct 92 11:43:15 +0100 From: Guido Bosch Message-Id: <9210161043.AA07131@moebius.loria.fr> To: bug-lucid-emacs@lucid.com Cc: tromey@cns.caltech.edu (Tom Tromey), daveg@thymus.synaptics.com Subject: Re: gnus-lucid.el patch Newsgroups: alt.lucid-emacs.bug In-Reply-To: <9210152307.AA29959@bradbury.cns.caltech.edu> References: <9210152307.AA29959@bradbury.cns.caltech.edu>, <9210152111.AA07442@thymus.synaptics> Reply-To: Guido BOSCH Tom Tromey writes: > Here is an excerpt from the function documentation for "defconst": > > Note: do not use `defconst' for user options in libraries that are not > normally loaded, since it is useful for users to be able to specify > their own values for such variables before loading the library. > Since `defconst' unconditionally assigns the variable, > it would override the user's choice. > > Your other fixes look pretty nice though (haven't tried them). > > Tom > --- > This reporter is tromey@cns.caltech.edu "Totally Objective" > "`Nova heat moving in,' dig?" -- Robert Anton Wilson Dave Gillespie writes: > > - change all `defvar's in `defconst's (they are easily re-evaluable > > after modifications). > > But users will not be able to override them in their .emacs files. > > -- Dave Well, I wasn't sure whether the variables defining menus are user options, i.e., whether they are ment to be custommized in .emacs or elsewhere. What users most probably will want to do is adding or removing some buttons, which can always be done with `add-menu-item' and `delete-menu-item'. I found it a good idea to use defconst instead of defvar because it allows updating of a variable with M-C-x or C-x C-e, just after having done some modifications. But I agree that this is the wrong way to do it. So ignore the `defconst'- parts of my patch. Here is a (hopfully) better solution to my problem: making defvar forms changing the variable value when evaluated with `eval-last-sexp' (C-x C-e) and `eval-defun' (M-C-x). (I think I've seen this on Lispmachine before) Enjoy, Guido -------------------------- lisp-mode-patch -------------------------- *** lisp-mode.el~ Thu Jul 30 01:43:08 1992 --- lisp-mode.el Fri Oct 16 11:28:49 1992 *************** *** 202,208 **** (defun eval-print-last-sexp (arg) "Evaluate sexp before point; print value into current buffer." (interactive "P") ! (eval-region (let ((stab (syntax-table))) (unwind-protect (save-excursion --- 202,208 ---- (defun eval-print-last-sexp (arg) "Evaluate sexp before point; print value into current buffer." (interactive "P") ! (eval-region-hack-defvar (let ((stab (syntax-table))) (unwind-protect (save-excursion *************** *** 217,223 **** "Evaluate sexp before point; print value in minibuffer. With argument, print output into current buffer." (interactive "P") ! (eval-region (let ((stab (syntax-table))) (unwind-protect (save-excursion --- 217,223 ---- "Evaluate sexp before point; print value in minibuffer. With argument, print output into current buffer." (interactive "P") ! (eval-region-hack-defvar (let ((stab (syntax-table))) (unwind-protect (save-excursion *************** *** 237,244 **** (end-of-defun) (let ((end (point))) (beginning-of-defun) ! (eval-region (point) end (if arg (current-buffer) t))))) (defun lisp-comment-indent () (if (looking-at "\\s<\\s<\\s<") --- 237,257 ---- (end-of-defun) (let ((end (point))) (beginning-of-defun) ! (eval-region-hack-defvar (point) end (if arg (current-buffer) t))))) + + (defun eval-region-hack-defvar (b e &optional printflag) + "Same as `eval-region', but treats forms starting with `\(defvar' as + if they would be `defconst's, i.e., change the variable's value (which + is not the case for `defvar')." + (if (save-excursion + (goto-char b) + (looking-at "(defvar")) + (let ((form (car (read-from-string (buffer-substring b e))))) + (rplaca form 'defconst) + (print (eval form) printflag)) + (eval-region b e printflag))) + (defun lisp-comment-indent () (if (looking-at "\\s<\\s<\\s<") From bug-lucid-emacs-request@lucid.com Sat Oct 17 12:14:23 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04319; Sat, 17 Oct 92 12:14:23 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA11982g; Sat, 17 Oct 92 12:11:52 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA00251; Sat, 17 Oct 92 15:13:23 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA00247; Sat, 17 Oct 92 15:13:21 -0400 Newsgroups: alt.lucid-emacs.bug Path: uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bcars6a8!bcars68a!jsparkes From: jsparkes%bcars68a.bnr.ca@lucid.com (Jeff Sparkes) Subject: lemacs 19.3 doesn't seem to work with SYSTEM_MALLOC Message-Id: <1992Oct17.185514.1990@bcars6a8.bnr.ca> Nntp-Posting-Host: bcars68a Organization: Bell-Northern Research Ltd., Ottawa Date: Sat, 17 Oct 1992 18:55:14 GMT Lines: 8 Xref: uunet alt.lucid-emacs.bug:280 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I wanted to try a malloc that will sbrk() memory back to the system. I first tried just using the system malloc, but it seems to cause coredumps in make_float. I'm on a sun4, running sunos 4.1.1. Anybody get the system malloc to work? -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 You know, a muffin can be *very* filling. From bug-lucid-emacs-request@lucid.com Sat Oct 17 13:16:44 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04434; Sat, 17 Oct 92 13:16:44 PDT Received: by heavens-gate.lucid.com id AA12093g; Sat, 17 Oct 92 13:13:05 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12089g; Sat, 17 Oct 92 13:12:52 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA23135; Sat, 17 Oct 92 13:14:29 PDT Date: Sat, 17 Oct 92 13:14:29 PDT Message-Id: <9210172014.AA23135@thalidomide.lucid> X-Windows: Flawed beyond belief. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: jsparkes%bcars68a.bnr.ca@lucid.com (Jeff Sparkes) Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs 19.3 doesn't seem to work with SYSTEM_MALLOC In-Reply-To: Jeff Sparkes's message of Sat 17-Oct-92 18:55:14 GMT <1992Oct17.185514.1990@bcars6a8.bnr.ca> References: <1992Oct17.185514.1990@bcars6a8.bnr.ca> In message <1992Oct17.185514.1990@bcars6a8.bnr.ca> Jeff Sparkes wrote: > > I wanted to try a malloc that will sbrk() memory back to the system. There's no point, because emacs basically never calls free(). All lisp objects are free-listed. > I first tried just using the system malloc, but it seems to cause coredumps > in make_float. I'm on a sun4, running sunos 4.1.1. Anybody get the system > malloc to work? I haven't seen this; I've successfully used the system malloc under SunOS 4.1.1. -- Jamie From bug-lucid-emacs-request@lucid.com Sun Oct 18 20:52:17 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA08390; Sun, 18 Oct 92 20:52:17 PDT Received: by heavens-gate.lucid.com id AA13689g; Sun, 18 Oct 92 20:49:39 PDT Received: from relay2.UU.NET by heavens-gate.lucid.com id AA13685g; Sun, 18 Oct 92 20:49:29 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03749; Sun, 18 Oct 92 23:51:05 -0400 Received: from richter.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 235002.8777; Sun, 18 Oct 1992 23:50:02 EDT Received: from screamer.UUCP by richter.slc.com (4.1/SMI-4.1) id AA05083; Thu, 1 Oct 92 20:41:19 PDT Organization: Servio Corporation Received: by screamer.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13752; Sun, 18 Oct 1992 23:37:24 -0400 Message-Id: <9210190337.AA13752@screamer.torolab.ibm.com> To: @richter.uucp:bug-lucid-emacs@lucid.com Subject: Installation difficulties under AIX 3.2. Cc: @screamer@uunet.UU.NET, @richter.UUCP:harry@richter.slc.com Date: Sun, 18 Oct 92 23:37:24 -0500 From: Harry Weeks In AIX 3.2, the HFT `ioctl(2)' code HFQEIO has been deleted. Use HFQERROR to query terminal for i/o error value. This change is required in file `src/sysdep.c' for functions `hft_init()' and `hft_reset()'. The AIX `make' utility complains of bad syntax when there is a continuation line for a macro that contains only a tab character. This can occur when the `ymakefile' is transformed to the `xmakefile'. In particular, I found this with the definition of `obj'. Really use SYSTEM_MALLOC for AIX, not GNU_MALLOC. Change required in the file `config.h'. The AIX XL C preprocessor does not like lines of the form /**/# found in Imakefiles. It attempts to understand the line as a preprocessor directive, which usually fails. This problem occurs with the file `src/lwlib/Imakefile'. AIX requires the directive #pragma alloca to appear in any source file using the `alloca()' function, which is implemented directly by the XL C compiler. Only `' need be included; there is no include file `' on AIX 3.2. To link `temacs', one must use the XL C command cc -Wl,-bnso,-bnodelcsect,-bI:/lib/syscalls.exp instead of just `ld'. AIX requires that `NEED_REALPATH' be defined in the `config.h' file. The file `src/lwlib/lwlib-Xm.c' contains definitions and declarations that appear to be valid only with the Lucid environment (`Energize?'), viz. extern Widget create_project_p_sheet (Widget parent); extern Widget create_debugger_p_sheet (Widget parent); extern Widget create_breaklist_p_sheet (Widget parent); extern Widget create_le_browser_p_sheet (Widget parent); extern Widget create_class_browser_p_sheet (Widget parent); extern Widget create_call_browser_p_sheet (Widget parent); static Widget make_project_p_sheet (widget_instance* instance); static Widget make_debugger_p_sheet (widget_instance* instance); static Widget make_breaklist_p_sheet (widget_instance* instance); static Widget make_le_browser_p_sheet (widget_instance* instance); static Widget make_class_browser_p_sheet (widget_instance* instance); static Widget make_call_browser_p_sheet (widget_instance* instance); Because of an undetermined linking problem, it's necessary to define an external symbol `__iconv_open', which remains unresolved from the X11 library (`/lib/libX11.a'). It would be very useful were a `Makefile' provided for compiling the `lwlib' library. AIX does not provide `imake' or `xmkmf' as part of its standard X11 distribution. Cheers! . . . . Harry From bug-lucid-emacs-request@lucid.com Mon Oct 19 08:49:12 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA11146; Mon, 19 Oct 92 08:49:12 PDT Received: by heavens-gate.lucid.com id AA14486g; Mon, 19 Oct 92 08:46:57 PDT Received: from bcars520 (x400gate.bnr.ca) by heavens-gate.lucid.com id AA14482g; Mon, 19 Oct 92 08:46:35 PDT X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 19 Oct 1992 11:47:27 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 19 Oct 1992 11:47:12 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 19 Oct 1992 07:46:00 -0400 Date: Mon, 19 Oct 1992 11:46:00 +0000 X400-Originator: /DD.ID=1581776/G=Jeffrey/I=JD/S=Sparkes/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.960:19.09.92.15.47.12] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Re: lemacs 19... From: "Jeffrey (J.D.) Sparkes" Message-Id: <"25977 Mon Oct 19 11:47:19 1992"@bnr.ca> To: jwz@lucid.com Cc: bug-lucid-emacs@lucid.com Subject: Re: lemacs 19.3 doesn't seem to work with SYSTEM_MALLOC In message "Re: lemacs 19.3 doesn't seem to work with SYSTEM_MALLOC", 'jwz@lucid.com' writes: >Sat Oct 17 16:19:00 1992 > To: Jeffrey (J.D.) Sparkes (BNR) Dept 4C23 CAR > Copy to: 'bug-lucid-emacs@lucid.com' (BNR400) > From: 'jwz@lucid.com' (BNR400) > Subject: Re: lemacs 19.3 doesn't seem to work with SYSTEM_MALLOC > Attachment: 1) UNIX File: ORIGINAL.HEADER - 1200 bytes >In message <1992Oct17.185514.1990@bcars6a8.bnr.ca> Jeff Sparkes wrote: >> >> I wanted to try a malloc that will sbrk() memory back to the system. > >There's no point, because emacs basically never calls free(). All lisp >objects are free-listed. That explains a lot. Further investigation shows that the gmalloc.c does seem to have the capability of release memor as well. I thought that the space for buffers was done via malloc/realloc/free. I tried the REL_ALLOC code, and the warning was right, it didn't work. The reason I want this is that I'm running dataless, with only 64M of swap. Right now, emacs has 30M of that used up. >I haven't seen this; I've successfully used the system malloc under >SunOS 4.1.1. I'll see if I can dig up more info. I am using the unbundled C compiler from Sun; maybe it's over optimizing, or just has a bug. -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From bug-lucid-emacs-request@lucid.com Tue Oct 20 10:13:47 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA15498; Tue, 20 Oct 92 10:13:47 PDT Received: by heavens-gate.lucid.com id AA00469g; Tue, 20 Oct 92 09:58:49 PDT Received: from ingr.ingr.com by heavens-gate.lucid.com id AA00465g; Tue, 20 Oct 92 09:58:25 PDT Received: from matis.UUCP by ingr.ingr.com (5.65c/1.920611) id AA29882; Tue, 20 Oct 1992 12:00:11 -0500 Received: from simpson.ingr.com by turtles (4.1/SMI-4.1) id AA18803; Tue, 20 Oct 92 18:54:08 IST Received: by simpson.ingr.com (4.1/SMI-4.1) id AA04882; Tue, 20 Oct 92 18:53:08 IST From: matis!amir@lucid.com (Amir J Katz) Message-Id: <9210201653.AA04882@simpson.ingr.com> Subject: problem with Guido Bosch's mode-motion+ package To: bug-lucid-emacs@lucid.com (Lucid Emacs Bug M.L.) Date: Tue, 20 Oct 92 18:53:06 EET Organization: SEE Technologies Ltd. Reply-To: matis!amir@lucid.com X-Reply-To: amir@matis.ingr.COM X-Mailer: ELM [version 2.3 PL11] Has anyone noticed that the function mouse-track-highlight-whole-line-follow is not defined in mode-motion-handlers.el? As a result, the mode-motion fails in *Buffer List* buffers. -- /* ----------------------------------------------------------- */ /* Amir J. Katz | amir@matis.ingr.COM */ /* System Specialist | Voice: +972 52-584684 */ /* SEE Technologies Ltd. | Fax: +972 52-543917 */ /* ............ Solaris 2.0 - The Final Frontier ? ........... */ From bug-lucid-emacs-request@lucid.com Wed Oct 21 02:03:28 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA18773; Wed, 21 Oct 92 02:03:28 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA02265g; Wed, 21 Oct 92 01:57:50 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA05330; Wed, 21 Oct 92 04:59:29 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA05324; Wed, 21 Oct 92 04:59:25 -0400 Path: uunet!mcsun!corton!loria!news.loria.fr!bosch From: bosch%loria.fr@lucid.com (Guido Bosch) Newsgroups: alt.lucid-emacs.bug Subject: Re: problem with Guido Bosch's mode-motion+ package Message-Id: Date: 21 Oct 92 07:43:09 GMT References: <9210201653.AA04882@simpson.ingr.com> Distribution: alt Organization: INRIA-Lorraine / CRIN, Nancy, France Lines: 106 In-Reply-To: matis!amir@lucid.com's message of 20 Oct 92 17:00:37 GMT Xref: uunet alt.lucid-emacs.bug:284 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com In article <9210201653.AA04882@simpson.ingr.com> matis!amir@lucid.com (Amir J Katz) writes: > Has anyone noticed that the function > mouse-track-highlight-whole-line-follow > is not defined in mode-motion-handlers.el? > As a result, the mode-motion fails in *Buffer List* buffers. Oups, that's right. Here's the patch for the file mode-motion-handlers.el. Being in directory mode-motion+/, apply it with the command patch mode-motion-handlers.el mode-motion-handlers.el-patch-1.5-1.6 --------------- mode-motion-handlers.el-patch-1.5-1.6 --------------- =================================================================== RCS file: /users/prog/bosch/lemacs19.3/lisp/mode-motion+/RCS/mode-motion-handlers.el,v retrieving revision 1.5 retrieving revision 1.6 diff -c -r1.5 -r1.6 *** 1.5 1992/10/19 13:34:35 --- 1.6 1992/10/21 08:21:17 *************** *** 32,37 **** --- 32,40 ---- ; Change History ; ; $Log: mode-motion-handlers.el,v $ + ; Revision 1.6 1992/10/21 08:21:17 bosch + ; Motion handler `mouse-track-highlight-whole-line-follow' added. + ; ; Revision 1.5 1992/10/19 13:34:35 bosch ; Handler `mouse-track-pointer' added. Command ; `try-mode-motion-handlers' added. Comments modified. *************** *** 75,80 **** --- 78,84 ---- ;; symbol | background | stays | m-t-h-symbol ;; filename | background | stays | m-t-h-filename ;; whole line | background | stays | m-t-h-whole-line + ;; whole line | background | follows | m-t-h-whole-line-follow ;; visible line text | background | stays | m-t-h-visible-line ;; visible line text | background | follows | m-t-h-visible-line-follow ;; syntax structure | background | stays | m-t-h-thing *************** *** 103,108 **** --- 107,113 ---- ("mouse-track-highlight-thing") ("mouse-track-highlight-thing-bold") ("mouse-track-highlight-whole-line") + ("mouse-track-highlight-whole-line-follow") ("mouse-track-highlight-visible-line-follow") ("mouse-track-pointer") *************** *** 315,320 **** --- 320,359 ---- (thing-region start end)) 't) (set-buffer-modified-p buffer-modified-flag))) + + (defun mouse-track-highlight-whole-line-follow (event) + "Track the mouse by highlighting the whole window line mouse is over. + The point follows the cursor. For use as the value of `mode-motion-hook'. + BE CAREFUL: in order to highlight the whole line on the screen, + white space characters have to be inserted up to the maximum colon + visible on the screen. They remain after highlighting is done. + Therefore, this kind of highlighting is not suitable for each mode. + \(e.g., gnus-group and dired don't like it\)." + + (let ((buffer-modified-flag (buffer-modified-p)) + (buffer-read-only nil) + start mid end ww) + + (mouse-track-highlight-region + event + (function + (lambda (point) + (goto-char point) + (beginning-of-line) + (setq start (point)) + (end-of-line) + ;; fill up with white space + (if (>= (setq ww (1- (window-width (event-window event)))) + (current-column)) + (progn + ;; (setq mid (point)) + (indent-to-column ww))) + (setq end (point)) + (goto-char start) + (thing-region start end)) + 't) + (set-buffer-modified-p buffer-modified-flag)))) + (defun mouse-track-pointer (event) =================================================================== -- Guido BOSCH, INRIA-Lorraine/CRIN Institut National de Recherche en Informatique et en Automatique (INRIA) Centre de Recherche en Informatique de Nancy (CRIN) Campus scientifique, B.P. 239 54506 Vandoeuvre-les-Nancy CEDEX Tel.: (+33) 83.91.24.24 Fax.: (+33) 83.41.30.79 email: bosch@loria.fr From bug-lucid-emacs-request@lucid.com Wed Oct 21 12:52:04 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA20482; Wed, 21 Oct 92 12:52:04 PDT Received: from rodan.UU.NET by heavens-gate.lucid.com id AA03672g; Wed, 21 Oct 92 12:49:48 PDT Received: from bug-lucid-emacs@lucid.com (list exploder) by rodan.UU.NET (5.61/UUNET-mail-drop) id AA24851; Wed, 21 Oct 92 15:51:27 -0400 Received: from news.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA24846; Wed, 21 Oct 92 15:51:25 -0400 Path: uunet!dtix!mimsy!sdd.comsat.com!neal.ctd.comsat.com!neal!neal From: neal@ctd.comsat.com (Neal Becker) Newsgroups: alt.lucid-emacs.bug Subject: lemacs19.3/hpux coredump on garbage collect Message-Id: Date: 19 Oct 92 13:48:19 GMT Organization: COMSAT Labs Lines: 10 Nntp-Posting-Host: neal.ctd.comsat.com X-Md4-Signature: fd3305a7695f29e6f055e383bfcfae2b Xref: uunet alt.lucid-emacs.bug:285 Sender: bug-lucid-emacs-request@lucid.com To: bug-lucid-emacs@lucid.com I am using lemacs19.3 on hpux 8.07, hp9000/7xx. It is working, but I get random core dumps. Debugging shows this occurred during garbage collection: In routine compact_string_chars () [alloc.c: 1838]. Has anyone else seen this? Should I bother trying to use a debugging malloc? Thanks. From bug-lucid-emacs-request@lucid.com Sat Oct 24 15:08:29 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03949; Sat, 24 Oct 92 15:08:29 PDT Received: by heavens-gate.lucid.com id AA12072g; Sat, 24 Oct 92 15:05:42 PDT Received: from sunscreen.Stanford.EDU by heavens-gate.lucid.com id AA12068g; Sat, 24 Oct 92 15:05:35 PDT Received: from cardinal.Stanford.EDU by sunscreen.Stanford.EDU (4.1/AIR-1.0) id AA11541; Sat, 24 Oct 92 15:07:17 PDT Received: by cardinal.Stanford.EDU (5.57/Ultrix3.0-C) id AA01964; Sat, 24 Oct 92 15:07:21 -0700 Date: Sat, 24 Oct 92 15:07:21 -0700 From: erose@leland.Stanford.EDU Message-Id: <9210242207.AA01964@cardinal.Stanford.EDU> To: bug-lucid-emacs@lucid.com Subject: Case-sensitivity in buffer mode switch headers When I insert // -*- objective-C -*- at the top of an object-C code buffer, the 'C' gets mapped to a 'c', and wont load the mode, which is called "objective-C-mode". I assume this is a feature, because I've seen people write -*- Perl -*-, -*- C++ -*-, etc. I guess I should just re-write the objective-C mode to use all lower case, or put in a function alias. Any comments on why everything gets turned to lower-case when the lisp handles both cases? Or is this an option flag I can set? -Eric From bug-lucid-emacs-request@lucid.com Sat Oct 24 15:18:37 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA03968; Sat, 24 Oct 92 15:18:37 PDT Received: by heavens-gate.lucid.com id AA12085g; Sat, 24 Oct 92 15:16:26 PDT Received: from thalidomide.lucid ([192.31.212.116]) by heavens-gate.lucid.com id AA12081g; Sat, 24 Oct 92 15:16:17 PDT Received: by thalidomide.lucid (4.1/SMI-4.1) id AA23804; Sat, 24 Oct 92 15:18:09 PDT Date: Sat, 24 Oct 92 15:18:09 PDT Message-Id: <9210242218.AA23804@thalidomide.lucid> X-Windows: It could happen to you. From: Jamie Zawinski Sender: jwz%thalidomide@lucid.com To: erose@leland.Stanford.EDU Cc: bug-lucid-emacs@lucid.com Subject: Re: Case-sensitivity in buffer mode switch headers In-Reply-To: erose@leland.Stanford.EDU's message of Sat 24-Oct-92 15:07:21 -0700 <9210242207.AA01964@cardinal.Stanford.EDU> References: <9210242207.AA01964@cardinal.Stanford.EDU> Case sensitivity is the work of the devil. None of the standard emacs modes have upper case names (except TeX-mode, but people are really anal about the capitalization of TeX) so yours shouldn't either. V18 works this way too. -- Jamie From bug-lucid-emacs-request@lucid.com Sat Oct 24 18:00:08 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04298; Sat, 24 Oct 92 18:00:08 PDT Received: by heavens-gate.lucid.com id AA12765g; Sat, 24 Oct 92 17:57:40 PDT Received: from bigbird.bu.edu by heavens-gate.lucid.com id AA12744g; Sat, 24 Oct 92 17:56:59 PDT Received: by bigbird.bu.edu (5.61+++/Spike-2.1) id AA28337; Sat, 24 Oct 92 20:58:36 -0400 Date: Sat, 24 Oct 92 20:58:36 -0400 From: jbw@bigbird.bu.edu (Joe Wells) Message-Id: <9210250058.AA28337@bigbird.bu.edu> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: byte-compiler gives weird message when compiling file with no errors Sent-Via: Jamie Zawinski byte-compile-version's value is "2.05; 9-mar-92." The file yyy.el is an empty file, and hence refers to no unknown functions. However, byte-compile-file has this to say: Sat Oct 24 20:16:43 1992 While compiling the end of the data in file yyy.el: ** The following functions are not known to be defined: second, stack-save-current-pos, third, signum, 2str This happens when a previous byte-compilation attempt ended with an error in the middle. Thus, I presume that the byte-compiler uses a global variable to keep track of referenced-but-unknown functions. It should clear this variable if a compilation is aborted due to an error. I don't know if this is fixed in 2.08, the version in lemacs. -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details "Beware of Mathematicians and other evil-doers. The danger already exists that they have made a pact with the Devil for the corruption of Man and his confinement to Eternal Damnation." -- St. Thomas Aquinas From bug-lucid-emacs-request@lucid.com Sat Oct 24 18:40:48 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04337; Sat, 24 Oct 92 18:40:48 PDT Received: by heavens-gate.lucid.com id AA13205g; Sat, 24 Oct 92 18:38:35 PDT Received: from bigbird.bu.edu by heavens-gate.lucid.com id AA13201g; Sat, 24 Oct 92 18:38:26 PDT Received: by bigbird.bu.edu (5.61+++/Spike-2.1) id AA28383; Sat, 24 Oct 92 21:40:07 -0400 Date: Sat, 24 Oct 92 21:40:07 -0400 From: jbw@bigbird.bu.edu (Joe Wells) Message-Id: <9210250140.AA28383@bigbird.bu.edu> To: Jamie Zawinski Cc: bug-lucid-emacs@lucid.com Subject: byte-compiler assumes fn def of symbol is a function Sent-Via: Jamie Zawinski byte-compile-version's value is "2.05; 9-mar-92." The byte-compiler assumes that the function definition of a symbol is always a function. This is false, since it can also be a string (keyboard macro) or a keymap. To reproduce, place the following in a file: (defvar yyy-map (make-sparse-keymap)) (defun yyy-prefix () (fset 'yyy-prefix yyy-map)) (yyy-prefix) (Code like this is necessary because it is impossible in Emacs to autoload a keymap. Instead, you have to autoload a function that turns itself into a keymap.) Then call byte-compile-and-load-file twice on that file. You will get this error: Wrong type argument: arrayp, (keymap) The evil function that needs to be fixed is byte-compile-arglist-warn. I don't know if this is fixed in 2.08. -- Joe Wells Member of the League for Programming Freedom --- send e-mail for details "Reality is what refuses to go away when I stop believing in it." -- Philip K. Dick From bug-lucid-emacs-request@lucid.com Sun Oct 25 00:24:32 1992 Received: from lucid.com by labrea.Stanford.EDU (4.1/1.34) id AA04793; Sun, 25 Oct 92 00:24:32 PDT Received: by heavens-gate.lucid.com id AA13590g; Sun, 25 Oct 92 00:22:11 PDT Received: from sunlight.Stanford.EDU by heavens-gate.lucid.com id AA13586g; Sun, 25 Oct 92 00:22:03 PDT Received: from elaine37.Stanford.EDU by sunlight.Stanford.EDU (4.1/AIR-1.0) id AA19298; Sun, 25 Oct 92 00:23:51 PDT Date: Sun, 25 Oct 92 00:23:51 PDT From: erose@leland.stanford.edu Message-Id: <9210250723.AA19298@sunlight.Stanford.EDU> Received: by elaine37.Stanford.EDU (4.1/SMI-4.1) id AA03077; Sun, 25 Oct 92 00:23:50 PDT To: bug-lucid-emacs@lucid.com Subject: Lucid Emacs freezes on file save I'm having an intermitant problem where Lucid Emacs will freeze after completing a file write (C-x C-s). It writes that it has saved the file and then freezes, refusing to take any more events, including window update events. My system: DecStation 5000/240 X11R5, Ultrix 4.2A Using the Dec c-compiler with -O2 to compile Lucid Using the Dec-provided libraries to link it (Xlib, Xt, etc) I know its, not much to go on, but if others have been reporting it maybe there is fix. It could easily be a problem with the way I compiled it, or even a compiler-introduced problem. Have others been having any problems with this? -Eric