From owner-xemacs-beta@xemacs.org Sun Oct 31 23:59:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA24508 for xemacs-beta-out; Sun, 31 Oct 1999 23:59:59 -0500 Received: from pc-hrvoje.srce.hr (pc-hrvoje.srce.hr [161.53.2.132]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA24505 for ; Sun, 31 Oct 1999 23:59:56 -0500 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.03 #1 (Debian)) id 11i9ZQ-0006sy-00 for ; Mon, 01 Nov 1999 05:59:52 +0100 To: XEmacs Beta List Subject: Re: Speed of scrolling with a background pixmap References: <87so2rysa8.fsf@pc-hrvoje.srce.hr> <14365.3821.745779.126444@crystal.WonderWorks.COM> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 01 Nov 1999 05:59:42 +0100 In-Reply-To: Kyle Jones's message of "Sun, 31 Oct 1999 19:54:21 -0800 (PST)" Message-ID: <87ln8iyfgh.fsf@pc-hrvoje.srce.hr> Lines: 24 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > Hrvoje Niksic writes: > > [...] > > Whether you use a bg pixmap or not, try comparing scrolling speed with > > and without a bg pixmap. For me, scrolling is much slower without a > > bg pixmap, even though the pixmap itself doesn't scroll. > > I assume you meant that scrolling is slower WITH a background > pixmap. Of course; sorry for the confusion. > Repainting an X window with a pixmap is slower than clearing the > same window to a single color. Repainting a window to a single > color can probably be done with a single instruction sent to the > video card. Repainting a pixmap region is going to require data to > be copied from main memory to VRAM on the card. Would it help if the X server be made to remember the picture? For instance, is it possible to tell X that the letters are a layer over the background image, which will be removed and replaced with new ones? I assume the graphical 2D acceleration hardware has *some* optimizations for these cases? From owner-xemacs-beta@xemacs.org Mon Nov 1 00:09:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA24874 for xemacs-beta-out; Mon, 1 Nov 1999 00:09:58 -0500 Received: from pc-hrvoje.srce.hr (pc-hrvoje.srce.hr [161.53.2.132]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA24870 for ; Mon, 1 Nov 1999 00:09:55 -0500 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.03 #1 (Debian)) id 11i9j5-0006tB-00 for ; Mon, 01 Nov 1999 06:09:52 +0100 To: XEmacs Beta List Subject: Re: --pdump References: <87iu3n158u.fsf@pc-hrvoje.srce.hr> <19991031191021.C16720@nemesis.ncsl.nist.gov> <87ogdfyruh.fsf@pc-hrvoje.srce.hr> <19991031203507.E16720@nemesis.ncsl.nist.gov> <87g0yqzzx8.fsf@pc-hrvoje.srce.hr> <19991031225358.A18296@nemesis.ncsl.nist.gov> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 01 Nov 1999 06:09:42 +0100 In-Reply-To: Olivier Galibert's message of "Sun, 31 Oct 1999 22:53:58 -0500" Message-ID: <87hfj6yezt.fsf@pc-hrvoje.srce.hr> Lines: 59 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Olivier Galibert writes: > On Mon, Nov 01, 1999 at 03:52:19AM +0100, Hrvoje Niksic wrote: > > Have you tried measuring startup speed of XEmacs? > > No. But I'm still in the <1s area for startup. It only shows that you have a fast computer. :-) > > How long does it take to relocate the data? > > Not much, obviously. Why obviously? I think it should be measured, but I don't know what to compare it against. Repeatedly timing `xemacs -batch -f kill-emacs' might be a good measurement, given two XEmacsen with maximum optimization. > Incidentally, a missing feature (which will be easy to implement > once I consider the rest of the system stable enough because it > needs some support in the build process which will have to call > temacs twice, once for dumping , once for relocating) is > pre-relocating the data to the address the initial mmap () puts the > file to. I'll do some tests, but I have no reason to think that it > should change between subsequence invocations of the same xemacs . Are you sure about that? What gives you the guarantee that mmap() will return the same address? I'm curious. (Something that calls itself a "portable dumper" should be portable, after all. OK, I couldn't resist this one.) > > Is the mmap()ed data shared between XEmacs processes? > > Implicitely, which means not at all. [...] Yikes. > None at all because: > - the relocating process writes to most of the pages > - the garbage collector writes to the remaining ones > > So, in order to have sharing we need the pre-relocation and a > smarter gc (which is probably going to come with Jan's allocator > model). I'd *really* like Michael Sperber to comment on our GC discussions. Michael, are you still around? > Ouch, there still are some nasty bugs in the pdump. Active regions > setup is lost . Same for auto delete selection. M-q breaks lines > in all the wrong places . And loses the line length, too, it seems, > while that may only be a side effect of not knowing where to break > the line. > > Isn't that mail cute once filled by a pdumped XEmacs? ;-) Feathers or lead? :-) From owner-xemacs-beta@xemacs.org Mon Nov 1 00:45:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA26345 for xemacs-beta-out; Mon, 1 Nov 1999 00:45:57 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA26341 for ; Mon, 1 Nov 1999 00:45:55 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id AAA18708 for xemacs-beta@xemacs.org; Mon, 1 Nov 1999 00:45:54 -0500 Date: Mon, 1 Nov 1999 00:45:54 -0500 From: Olivier Galibert To: XEmacs Beta List Subject: Re: Speed of scrolling with a background pixmap Message-ID: <19991101004554.C18593@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Beta List References: <87so2rysa8.fsf@pc-hrvoje.srce.hr> <14365.3821.745779.126444@crystal.WonderWorks.COM> <87ln8iyfgh.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <87ln8iyfgh.fsf@pc-hrvoje.srce.hr>; from Hrvoje Niksic on Mon, Nov 01, 1999 at 05:59:42AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, Nov 01, 1999 at 05:59:42AM +0100, Hrvoje Niksic wrote: > Would it help if the X server be made to remember the picture? This is, mostly, what the pixmap does. > For > instance, is it possible to tell X that the letters are a layer over > the background image, which will be removed and replaced with new > ones? I assume the graphical 2D acceleration hardware has *some* > optimizations for these cases? AFAIK, the current X protocol is too dumb for that. The Xv extension may help. Imagine that, a binary editor that uses the video extensions for a faster redisplay, Wow. OG. From owner-xemacs-beta@xemacs.org Mon Nov 1 01:00:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA26619 for xemacs-beta-out; Mon, 1 Nov 1999 01:00:18 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA26615 for ; Mon, 1 Nov 1999 01:00:16 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id BAA18744 for xemacs-beta@xemacs.org; Mon, 1 Nov 1999 01:00:15 -0500 Date: Mon, 1 Nov 1999 01:00:15 -0500 From: Olivier Galibert To: XEmacs Beta List Subject: Re: --pdump Message-ID: <19991101010015.D18593@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Beta List References: <87iu3n158u.fsf@pc-hrvoje.srce.hr> <19991031191021.C16720@nemesis.ncsl.nist.gov> <87ogdfyruh.fsf@pc-hrvoje.srce.hr> <19991031203507.E16720@nemesis.ncsl.nist.gov> <87g0yqzzx8.fsf@pc-hrvoje.srce.hr> <19991031225358.A18296@nemesis.ncsl.nist.gov> <87hfj6yezt.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <87hfj6yezt.fsf@pc-hrvoje.srce.hr>; from Hrvoje Niksic on Mon, Nov 01, 1999 at 06:09:42AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, Nov 01, 1999 at 06:09:42AM +0100, Hrvoje Niksic wrote: > > Not much, obviously. > > Why obviously? I should have written, not _that_ much. > I think it should be measured, but I don't know what > to compare it against. Repeatedly timing `xemacs -batch -f kill-emacs' > might be a good measurement, given two XEmacsen with maximum > optimization. Yes, I agree. > Are you sure about that? What gives you the guarantee that mmap() > will return the same address? I'm curious. Nothing. It's only probable, and due to the identical virtual memory layout. It may change if some other application forced a remapping of the shared libraries or this kind of shit. It will be interesting to see how often it happens. > (Something that calls itself a "portable dumper" should be portable, > after all. OK, I couldn't resist this one.) I will still work no matter what mmap returns, of course :-) > I'd *really* like Michael Sperber to comment on our GC discussions. > Michael, are you still around? So would I. Michaeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeel ! OG. From owner-xemacs-beta@xemacs.org Mon Nov 1 01:21:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA27337 for xemacs-beta-out; Mon, 1 Nov 1999 01:21:46 -0500 Received: from pc-hrvoje.srce.hr (pc-hrvoje.srce.hr [161.53.2.132]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA27333 for ; Mon, 1 Nov 1999 01:21:44 -0500 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.03 #1 (Debian)) id 11iAqb-0006zs-00 for ; Mon, 01 Nov 1999 07:21:41 +0100 To: XEmacs Beta List Subject: Re: --pdump References: <87iu3n158u.fsf@pc-hrvoje.srce.hr> <19991031191021.C16720@nemesis.ncsl.nist.gov> <87ogdfyruh.fsf@pc-hrvoje.srce.hr> <19991031203507.E16720@nemesis.ncsl.nist.gov> <87g0yqzzx8.fsf@pc-hrvoje.srce.hr> <19991031225358.A18296@nemesis.ncsl.nist.gov> <87hfj6yezt.fsf@pc-hrvoje.srce.hr> <19991101010015.D18593@nemesis.ncsl.nist.gov> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 01 Nov 1999 07:21:39 +0100 In-Reply-To: Olivier Galibert's message of "Mon, 1 Nov 1999 01:00:15 -0500" Message-ID: <87904iybnw.fsf@pc-hrvoje.srce.hr> Lines: 18 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Olivier Galibert writes: > > Are you sure about that? What gives you the guarantee that mmap() > > will return the same address? I'm curious. > > Nothing. It's only probable, and due to the identical virtual > memory layout. It may change if some other application forced a > remapping of the shared libraries or this kind of shit. Or if you upgrade to a different OS revision. Or if you take your binary to another system. Or... > > (Something that calls itself a "portable dumper" should be > > portable, after all. OK, I couldn't resist this one.) > > I will still work no matter what mmap returns, of course :-) In that case, I think it should print a really really scary warning. From owner-xemacs-beta@xemacs.org Mon Nov 1 01:54:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA28565 for xemacs-beta-out; Mon, 1 Nov 1999 01:54:08 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA28562 for ; Mon, 1 Nov 1999 01:54:06 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id BAA19018 for xemacs-beta@xemacs.org; Mon, 1 Nov 1999 01:54:02 -0500 Date: Mon, 1 Nov 1999 01:54:02 -0500 From: Olivier Galibert To: XEmacs Beta List Subject: Re: --pdump Message-ID: <19991101015402.A18984@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Beta List References: <87iu3n158u.fsf@pc-hrvoje.srce.hr> <19991031191021.C16720@nemesis.ncsl.nist.gov> <87ogdfyruh.fsf@pc-hrvoje.srce.hr> <19991031203507.E16720@nemesis.ncsl.nist.gov> <87g0yqzzx8.fsf@pc-hrvoje.srce.hr> <19991031225358.A18296@nemesis.ncsl.nist.gov> <87hfj6yezt.fsf@pc-hrvoje.srce.hr> <19991101010015.D18593@nemesis.ncsl.nist.gov> <87904iybnw.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <87904iybnw.fsf@pc-hrvoje.srce.hr>; from Hrvoje Niksic on Mon, Nov 01, 1999 at 07:21:39AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, Nov 01, 1999 at 07:21:39AM +0100, Hrvoje Niksic wrote: > In that case, I think it should print a really really scary warning. I see no particular problem with having a subr returning Qt or Qnil depending on whether relocating have been necessary. OG. From owner-xemacs-beta@xemacs.org Mon Nov 1 02:47:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA29438 for xemacs-beta-out; Mon, 1 Nov 1999 02:47:36 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA29435 for ; Mon, 1 Nov 1999 02:47:34 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id CAA29852 for xemacs-beta@xemacs.org; Mon, 1 Nov 1999 02:47:32 -0500 Date: Mon, 1 Nov 1999 02:47:32 -0500 From: Olivier Galibert To: XEmacs Beta List Subject: Re: --pdump Message-ID: <19991101024732.A29784@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Beta List References: <87iu3n158u.fsf@pc-hrvoje.srce.hr> <19991031191021.C16720@nemesis.ncsl.nist.gov> <87ogdfyruh.fsf@pc-hrvoje.srce.hr> <19991031203507.E16720@nemesis.ncsl.nist.gov> <87g0yqzzx8.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <87g0yqzzx8.fsf@pc-hrvoje.srce.hr>; from Hrvoje Niksic on Mon, Nov 01, 1999 at 03:52:19AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, Nov 01, 1999 at 03:52:19AM +0100, Hrvoje Niksic wrote: > Have you tried measuring startup speed of XEmacs? Here are the result for twenty invocations of: [tx]emacs -batch -vanilla -kill > & /dev/null The /dev/null redirection because the stream console correct initialisation in the pdump case has the side effect of allowing the Loading... messages to show for the auto-autoloads. Or maybe the reason is somewhere else. Anyway. pdump: 9.150u 1.920s 0:11.08 99.9% 0+0k 0+0io 23971pf+0w 9.050u 2.020s 0:11.09 99.8% 0+0k 0+0io 23970pf+0w 8.970u 2.030s 0:11.13 98.8% 0+0k 0+0io 23970pf+0w 9.020u 2.050s 0:11.08 99.9% 0+0k 0+0io 23970pf+0w 8.920u 2.150s 0:11.13 99.4% 0+0k 0+0io 23970pf+0w non-pdump: 8.380u 2.360s 0:10.80 99.4% 0+0k 0+0io 24730pf+0w 8.400u 2.300s 0:10.89 98.2% 0+0k 0+0io 24730pf+0w 8.380u 2.290s 0:10.67 100.0% 0+0k 0+0io 24730pf+0w 8.510u 2.170s 0:10.79 98.9% 0+0k 0+0io 24730pf+0w 8.350u 2.380s 0:10.76 99.7% 0+0k 0+0io 24730pf+0w ../xemacs-wk/configure '--prefix=/sw/xemacs/install' '--with-mule' '--cflags=-g -O9 -Wall -Wno-switch' '--debug=no' '--error-checking=none' I don't really understand what is involved in the somehow lower usage of system resources. End result is a 2% increase of startup time. I wouldn't lose sleep other that (but I don't like the lack of sharing, though). OG. From owner-xemacs-beta@xemacs.org Mon Nov 1 06:14:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA00308 for xemacs-beta-out; Mon, 1 Nov 1999 06:14:01 -0500 Received: from juran.asahi-net.or.jp (juran.asahi-net.or.jp [202.224.39.39]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA00302 for ; Mon, 1 Nov 1999 06:14:00 -0500 Received: from libretto.osaka.or.jp (ppp156109.asahi-net.or.jp [202.213.156.109]) by juran.asahi-net.or.jp (8.8.8/3.7W) with ESMTP id UAA14733; Mon, 1 Nov 1999 20:13:43 +0900 (JST) Date: Mon, 01 Nov 1999 20:08:02 +0900 Message-ID: <14365.29842.49002.8921F@osaka.email.ne.jp> From: Mikio Nakajima To: vroonhof@math.ethz.ch Cc: xemacs-beta@xemacs.org Subject: Re: double negative In-Reply-To: In your message of "Mon, 25 Oct 1999 05:36:24 +0900" <14355.28104.210068.6644X@osaka.email.ne.jp> References: <14354.64356.292001.16795B@osaka.email.ne.jp> <14355.28104.210068.6644X@osaka.email.ne.jp> User-Agent: Wanderlust/2.2.5 (Come Undone) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-pc-linux) X-Face: "p2|01omA&m@t(Sk!=}`N5J2adI\F7W2BO5_:P8vEk.TQgm`sX8U-%AIF~]bI[pQy-<#B+^!6J]xBzNs<^L{|F4#=hc MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Mon_Nov__1_20:08:01_1999-1" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Mon_Nov__1_20:08:01_1999-1 Content-Type: text/plain; charset=US-ASCII At Mon, 25 Oct 1999 05:36:24 +0900, Mikio Nakajima wrote: > At 24 Oct 1999 17:28:35 +0200, > Jan Vroonhof wrote: > > > this is wrong. Although most of the time it won't matter (not (not > > a)) is not equal to a. If you want to do this you must make sure you > > only do it in contexts where we are sure we only want 'non-nil'ness. > > I got it. I will do it in byte-optimize-if or something like that > respectively. I was doing these for byte-opt.el of FSFmacs, and perhaps has finished. Now I apply same thing to byte-optimize.el of XEmacs. I will send diff file xemacs-patches. --Multipart_Mon_Nov__1_20:08:01_1999-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="ChangeLog" Content-Transfer-Encoding: 7bit 1999-11-01 Mikio Nakajima * byte-opt.el: Put byte-optimzier properties of `when' and `unless' to `byte-optimize-when'. (byte-optimize-when): New function. (byte-optimize-form-code-walker): Optimize form of which car is `when' or `unless'. (byte-optimize-cond): Optimize a double negative and side effect free condition Turn (cond (( )) ...) into (cond (( )) ... ) if has not side effect. (byte-optimize-if): Optimize a double negative condition. (byte-optimize-double-negative): New function. (byte-compile-side-effect-sex-p): Ditto. --Multipart_Mon_Nov__1_20:08:01_1999-1 Content-Type: text/plain; charset=US-ASCII -- Mikio Nakajima (in case of emergency) http://www.asahi-net.or.jp/~gy2m-nkjm/ --Multipart_Mon_Nov__1_20:08:01_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 1 06:24:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA00557 for xemacs-beta-out; Mon, 1 Nov 1999 06:24:05 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA00553 for ; Mon, 1 Nov 1999 06:24:03 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id UAA13377; Mon, 1 Nov 1999 20:22:24 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: --pdump -vs- fast-lock/lazy loaded byte code? X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 01 Nov 1999 20:22:23 +0900 Message-ID: Lines: 105 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [This is very exciting to me to see things this close, go go Olivier.] $ ./temacs Fatal error: assertion failed, file /usr/local/devel/xemacs-21.2/src/lread.c, line 487, !purify_flag Fatal error (6). ... Lisp backtrace follows: # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("fast-lock" nil nil nil binary) # bind (path handler filename nosuffix nomessage noerror file) load("fast-lock" nil nil nil) # (unwind-protect ...) turn-on-fast-lock() run-hooks(turn-on-fast-lock) # bind (on-p maximum-size arg) font-lock-mode(1) turn-on-font-lock() run-hooks(turn-on-font-lock) lisp-interaction-mode() # (unwind-protect ...) # bind (command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) zsh: 13346 IOT instruction (core dumped) ./temacs $ gdb ./temacs core GNU gdb 4.18 ... This GDB was configured as "sparc-sun-solaris2.6"... ... (gdb) where #0 0x6f607418 in _libc_kill () from /usr/lib/libc.so.1 #1 0xb6108 in fatal_error_signal (sig=6) at /usr/local/devel/xemacs-21.2/src/emacs.c:276 #2 #3 0x6f607418 in _libc_kill () from /usr/lib/libc.so.1 #4 0x6f5ba52c in abort () from /usr/lib/libc.so.1 #5 0xb6068 in fatal_error_signal (sig=3023096) at /usr/local/devel/xemacs-21.2/src/emacs.c:2796 This crash doesn't happen when I run --vanilla, so I presume it has something to do with either fast-lock or more likely, lazy loaded byte code. uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ../xemacs-21.2/configure '--with-mule' '--debug=yes' '--error-checking=all' '--extra-verbose=no' '--site-prefixes=/usr/local' '--compiler=gcc' '--mail-locking=file' '--srcdir=../xemacs-21.2' '--cflags=-g -O3' '--site-includes=/usr/lib/locale/ja/wnn/demo/include' '--site-libraries=/usr/lib/locale/ja/wnn/lib' '--with-scrollbars=athena3d' '--with-dialogs=athena3d' '--with-xim=none' '--with-widgets=athena3d' '--pdump' XEmacs 21.2-b19 "Shinjuku" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /usr/local/devel/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O3 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/local/X11R6/include Where do we find X Windows libraries? /usr/dt/lib /usr/local/X11R6/lib Additional header files: /usr/lib/locale/ja/wnn/demo/include Additional libraries: /usr/lib/locale/ja/wnn/lib Additional prefixes: /usr/local Runtime library search path: /usr/lib/locale/ja/wnn/lib:/usr/local/lib:/usr/dt/lib:/usr/local/X11R6/lib:/usr/local/qt/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using the new portable dumper (wishful thinking). Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From owner-xemacs-beta@xemacs.org Mon Nov 1 06:37:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA00812 for xemacs-beta-out; Mon, 1 Nov 1999 06:37:36 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA00809 for ; Mon, 1 Nov 1999 06:37:34 -0500 Received: by avon.delcam.com; Mon, 1 Nov 1999 11:36:52 GMT Received: by pat.delcam.com; Mon, 1 Nov 1999 11:37:52 GMT Received: by dr2.delcam.com; Mon, 1 Nov 1999 11:37:54 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14365.31633.712392.633173@pub.news.uk.psi.net> Date: Mon, 1 Nov 1999 11:37:53 +0000 (GMT) To: xemacs-beta@xemacs.org Subject: IRIX6.2 build failure X-Mailer: VM 6.71 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) X-Face: "+N/{>9S5,OIk<0$%[)LGd} I CVS updated my source this morning and the build failed. ../configure '--site-libraries=/usr/local/lib' '--site-includes=/usr/local/include' '--cflags=-g' '--package-path=/devdisk/d54man/gnu/xemacs-beta/packages' '--with-mule=no' XEmacs 21.2-b19 "Shinjuku" configured for `mips-sgi-irix6.2'. Where should the build process find the source code? /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -g Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- A make beta went as usual until this . . . Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... Fatal error: assertion failed, file /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/lisp.h, line 650, RECORD_TYPEP (obj, &lrecord_cons) make[1]: *** [xemacs] Abort make[1]: *** Deleting file `xemacs' make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 Any ideas ? -- Paul Bibilo, Delcam plc, | Tel: +44 121 766 5544 Talbot Way, Small Heath, Birmingham, | Fax: +44 121 766 5511 England, B10 0HJ. | ICBM-mail: 52 17N 1 30W #include | ICQ: 32045109 From owner-xemacs-beta@xemacs.org Mon Nov 1 12:11:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10114 for xemacs-beta-out; Mon, 1 Nov 1999 12:11:44 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA10111 for ; Mon, 1 Nov 1999 12:11:39 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA24251 for ; Mon, 1 Nov 1999 18:11:38 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005us; Mon Nov 1 18:11:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA09927; Mon, 1 Nov 1999 18:11:29 +0100 To: xemacs-beta@xemacs.org Subject: Re: [bug report, 21.2] font-lock face inheritance References: <19991030064630.A10967@nemesis.ncsl.nist.gov> <381B70F6.96659D2F@666.com> <87so2r2s25.fsf@pc-hrvoje.srce.hr> From: Jan Vroonhof Date: 01 Nov 1999 18:11:29 +0100 In-Reply-To: Hrvoje Niksic's message of "31 Oct 1999 21:28:34 +0100" Message-ID: Lines: 27 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Note that it would be possible to compatibly add new specifier tags > for all domains, e.g. by a new DOMAINS optional argument to > `define-specifier-tag', Something like that yes. > > However, the problem is that the current specifier implementation has > to be extended to support such on-the-fly fetching of relevant data. > I believe Kirill did some work on this, but it was never finished. I am not sure it is needed to be that dynamic. I thing adding a hook to each specifier that is called when that specifier is changed would be sufficient. Then you could put a hook on the background color specifier of the default face such that when it gets changed you simply recompute the tags, invalidate all the caches and redisplay the whole shebang. This hook could also be used to do other things. For instance imagine that the fallback value of the font specifier of a face is another specifier "font-model-font". Thus specifier is autoconstructed from the face's family, weight and size specifiers, which have hooks on them so that when they get changed the font-model code recomputes font-model-font. Jan From owner-xemacs-beta@xemacs.org Mon Nov 1 12:34:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA11084 for xemacs-beta-out; Mon, 1 Nov 1999 12:34:45 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA11080 for ; Mon, 1 Nov 1999 12:34:43 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA24553 for ; Mon, 1 Nov 1999 18:34:39 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005zb; Mon Nov 1 18:34:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA10035; Mon, 1 Nov 1999 18:34:30 +0100 To: xemacs-beta@xemacs.org Subject: Re: double negative References: <14354.64356.292001.16795B@osaka.email.ne.jp> <14355.28104.210068.6644X@osaka.email.ne.jp> <14365.29842.49002.8921F@osaka.email.ne.jp> From: Jan Vroonhof Date: 01 Nov 1999 18:34:30 +0100 In-Reply-To: Mikio Nakajima's message of "Mon, 01 Nov 1999 20:08:02 +0900" Message-ID: Lines: 32 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mikio Nakajima writes: > I was doing these for byte-opt.el of FSFmacs, and perhaps has > finished. Now I apply same thing to byte-optimize.el of XEmacs. I > will send diff file xemacs-patches. > > > 1999-11-01 Mikio Nakajima Next time please 1. include the Changelog and the patch in the same message 2. Use 'diff -u' thanks.. > > * byte-opt.el: Put byte-optimzier properties of `when' and > `unless' to `byte-optimize-when'. > (byte-optimize-when): New function. > (byte-optimize-form-code-walker): Optimize form of > which car is `when' or `unless'. Why is this needed? Isn't 'when' a macro that expands to (if (form here) (progn ...)) so that just handling the if case is enough? Jan P.S. I'll look at it in more detail later. From owner-xemacs-beta@xemacs.org Mon Nov 1 15:56:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA19065 for xemacs-beta-out; Mon, 1 Nov 1999 15:56:42 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA19061 for ; Mon, 1 Nov 1999 15:56:38 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA27983 for ; Mon, 1 Nov 1999 21:56:36 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006pD; Mon Nov 1 21:56:36 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA11301; Mon, 1 Nov 1999 21:56:35 +0100 To: xemacs-beta@xemacs.org Subject: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) From: Jan Vroonhof Date: 01 Nov 1999 21:56:35 +0100 Message-ID: Lines: 60 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Any ideas? xpm-button.el is back in the core wasn't it...? Jan --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: "Dave Hall" Newsgroups: comp.emacs.xemacs Subject: Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) Date: Mon, 1 Nov 1999 12:49:29 -0500 Organization: NASA Lewis Research Center Message-ID: <7vkk08$3rb@sulawesi.lerc.nasa.gov> References: <381DB42E.103B7BE2@research.panasonic.com> NNTP-Posting-Host: dghall.lerc.nasa.gov X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Lines: 31 Path: pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!newsfeed.rhein-neckar.de!news.rhein-neckar.de!news-kar1.dfn.de!newsfeed.nacamar.de!dispose.news.demon.net!demon!europa.netcrusader.net!198.138.0.5!newshub.northeast.verio.net!news.idt.net!news.stealth.net!cnn.nas.nasa.gov!news.lerc.nasa.gov!newsread.lerc.nasa.gov!news Xref: pfaff.ethz.ch comp.emacs.xemacs:39500 Luyang Li wrote in message news:381DB42E.103B7BE2@research.panasonic.com... > > Hi, > > I built Xemacs 21.1.7 on RedHat Linux 6.0. When I click on any button, > it says: > "Symbol's function definition is void: ..." > > What's wrong in my configuration? > > I really appreciate if someone can give me some clue. > > Regards, > > Luyang Li > I am having the same trouble with 21.1 patch 7 built for a Sun/Solaris 2.7 system. some buttons seem to work. Most do not. The error message "Symbol's finction definition is void: xpm-button-create" Please e-mail me if you figure it out? --=-=-= -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof @ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085 --=-=-=-- From owner-xemacs-beta@xemacs.org Mon Nov 1 16:54:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA20794 for xemacs-beta-out; Mon, 1 Nov 1999 16:54:51 -0500 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA20791 for ; Mon, 1 Nov 1999 16:54:49 -0500 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.8.8/8.8.8) with ESMTP id NAA01963; Mon, 1 Nov 1999 13:54:40 -0800 (PST) Message-Id: <199911012154.NAA01963@ptavv.es.net> To: Jan Vroonhof cc: xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) In-reply-to: Your message of "01 Nov 1999 21:56:35 +0100." Date: Mon, 01 Nov 1999 13:54:40 -0800 From: "Kevin Oberman" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I don't know if it's in core now, but it was NOT in core for 21.1.7. It is in xemacs-base. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-xemacs-beta@xemacs.org Mon Nov 1 18:35:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA23340 for xemacs-beta-out; Mon, 1 Nov 1999 18:35:27 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA23337 for ; Mon, 1 Nov 1999 18:35:25 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id CB245472F; Mon, 1 Nov 1999 19:41:11 -0500 (EST) To: "Kevin Oberman" Cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) References: <199911012154.NAA01963@ptavv.es.net> From: Vin Shelton Organization: The XEmacs Development Team Date: 01 Nov 1999 19:41:11 -0500 In-Reply-To: "Kevin Oberman"'s message of "Mon, 01 Nov 1999 13:54:40 -0800" Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I just downloaded the official 21.1.7 tarball from xemacs.org and xpm-button.el is in the lisp directory. Is there something else I needed to do? It seems to get byte-compiled just fine for me. And in fact, list-load-path shadows tells me: /usr/local/xemacs-packages/lisp/xemacs-base/xpm-button hides /usr/local/xemacs/lib/xemacs-21.1.7/lisp/xpm-button Am I missing something? - vin >>>>> On Mon, 01 Nov 1999, "Kevin Oberman" said: Kevin> I don't know if it's in core now, but it was NOT in core for Kevin> 21.1.7. It is in xemacs-base. From owner-xemacs-beta@xemacs.org Mon Nov 1 20:42:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA26535 for xemacs-beta-out; Mon, 1 Nov 1999 20:42:15 -0500 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA26532 for ; Mon, 1 Nov 1999 20:42:13 -0500 Received: from bodhi.mastaler.com (pool-207-205-181-79.phnx.grid.net [207.205.181.79]) by smtp10.atl.mindspring.net (8.8.5/8.8.5) with SMTP id UAA20750 for ; Mon, 1 Nov 1999 20:42:08 -0500 (EST) Received: (qmail 27161 invoked by uid 500); 2 Nov 1999 01:41:53 -0000 Received: from dres.lewismoss.org (ppp214.arden.dialup.ioa.com [205.138.38.223]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA17223 for ; Mon, 1 Nov 1999 14:52:21 -0500 Received: from dres by dres.lewismoss.org with local (Exim 3.03 #1 (Debian)) for xemacs-beta@xemacs.org id 11iNV4-0004DQ-00; Mon, 01 Nov 1999 14:52:18 -0500 To: xemacs-beta@xemacs.org Subject: Question about mule compiled elisp files From: James LewisMoss X-Url: http://www.ioa.com/~dres X-Organization: Debian/Software in the Public Interest X-We-Love-Spooks: Delta Force Mossad Bosnia Albania Ft. Knox Ron Brown SDI clones spy BATF Legion of Doom Uzi cypherpunk Vickie Weaver Kibo X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 01 Nov 1999 14:52:16 -0500 Message-ID: Lines: 47 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Is it safe to use mule compiled elisp files with a non-mule binary? I've hit a couple of things that make me think it's not quite right (but close). First is that trying to use jka-compr gives an error like coding-system-for-read undefined. If I set that to nil then I get file-coding-system-alist undefined, but the following bit of code lets jka-compr work just fine. (as far as I can tell) (defvar file-coding-system-alist nil) (defvar coding-system-for-read nil) (require 'jka-compr) (jka-compr-install) The other is that when starting a non-mule binary the warnings (1) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/skk/auto-autoloads: Cannot open load file: mule (2) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/lookup/auto-autoloads: Cannot open load file: mule (This is actually from a report from a debian user, but I think I've seen this before. (just tested it and I do see this at startup.)) Again it looks like it is causing no problems, but I wanted to ask in case there were things I should watch out for. Oh and just so you understand how things are compiled: 1) configure for a mule, canna, wnn setup. 2) compile the binary. 3) compile the elisp 4) configure for a mule (no input methods but xim) 5) compile the binary 6) configure for a non-mule 7) compile the binary These are then installed together (with each binary being xemacs-21.1.7-{mule,mule-canna-wnn,nomule} and doc files in /usr/lib/xemacs-21.1.7/i386-debian-linux/{mule,mule-canna-wnn,nomule}/DOC). Thanks Jim -- @James LewisMoss | Blessed Be! @ http://www.ioa.com/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From owner-xemacs-beta@xemacs.org Mon Nov 1 22:09:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA28619 for xemacs-beta-out; Mon, 1 Nov 1999 22:09:15 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA28611; Mon, 1 Nov 1999 22:09:13 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id WAA07201; Mon, 1 Nov 1999 22:09:07 -0500 Date: Mon, 1 Nov 1999 22:09:07 -0500 From: Olivier Galibert To: xemacs-beta@xemacs.org, XEmacs patches Subject: Re: --pdump -vs- fast-lock/lazy loaded byte code? Message-ID: <19991101220907.A7152@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org, XEmacs patches References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=2oS5YaxWCcQjTEyO X-Mailer: Mutt 0.95.4us In-Reply-To: ; from SL Baur on Mon, Nov 01, 1999 at 08:22:23PM +0900 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii On Mon, Nov 01, 1999 at 08:22:23PM +0900, SL Baur wrote: > Fatal error: assertion failed, file /usr/local/devel/xemacs-21.2/src/lread.c, line 487, !purify_flag Try that. If it fixes the problem, please apply it. If it doesn't, please show me the relevant part of your .emacs so that I can reproduce the crash. OG. 1999-11-01 Olivier Galibert * alloc.c (reinit_alloc_once_early): Move purify_flag init... * emacs.c (main_1): ...here, to get the correct value even with the portable dumper. --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="d1.txt" Index: src/alloc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/alloc.c,v retrieving revision 1.42.2.30 diff -u -r1.42.2.30 alloc.c --- alloc.c 1999/10/30 04:47:04 1.42.2.30 +++ alloc.c 1999/11/02 03:00:41 @@ -3922,9 +3922,6 @@ reinit_alloc_once_early (void) { gc_generation_number[0] = 0; - /* purify_flag 1 is correct even if CANNOT_DUMP. - * loadup.el will set to nil at end. */ - purify_flag = 1; breathing_space = 0; XSETINT (all_bit_vectors, 0); /* Qzero may not be set yet. */ XSETINT (Vgc_message, 0); Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/02 03:00:44 @@ -856,8 +856,20 @@ We try to do things in an order that minimizes the non-obvious dependencies between functions. */ + /* purify_flag 1 is correct even if CANNOT_DUMP. + * loadup.el will set to nil at end. */ + + purify_flag = 0; #ifdef PDUMP - initialized = restart || pdump_load (); + if (restart) + initialized = 1; + else { + initialized = pdump_load (); + purify_flag = !initialized; + } +#else + if (!initialized) + purify_flag = 1; #endif if (!initialized) --2oS5YaxWCcQjTEyO-- From owner-xemacs-beta@xemacs.org Mon Nov 1 22:45:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA29713 for xemacs-beta-out; Mon, 1 Nov 1999 22:45:58 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA29708; Mon, 1 Nov 1999 22:45:53 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 14963472F; Mon, 1 Nov 1999 23:51:39 -0500 (EST) To: Andy Piper , Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: Patches Applied for 21.1.8 References: <3.0.5.32.19991021090515.00a79490@london.beasys.com> <3.0.6.32.19991021202349.007b17e0@mail.dycon.com> <3.0.6.32.19991023120038.007e1120@mail.dycon.com> <3.0.6.32.19991023205932.007c9580@mail.dycon.com> <3.0.6.32.19991024232207.007c95a0@mail.dycon.com> <3.0.5.32.19991026220534.009b8b80@london.beasys.com> From: Vin Shelton Organization: The XEmacs Development Team Date: 01 Nov 1999 23:51:39 -0500 In-Reply-To: Andy Piper's message of "Tue, 26 Oct 1999 22:05:34 +0100" Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm a little confused; do I need to apply this patch to 21.1.8 in addition to Adrian's patch for call process cleanup? --- nt.c~ Thu Jul 15 09:58:41 1999 +++ nt.c Tue Oct 26 16:45:40 1999 @@ -608,7 +608,9 @@ "EMACSLOCKDIR", "INFOPATH" }; - +#ifdef HEAP_IN_DATA + cache_system_info (); +#endif for (i = 0; i < countof (env_vars); i++) { if (!getenv (env_vars[i]) && From owner-xemacs-beta@xemacs.org Mon Nov 1 23:16:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA30637 for xemacs-beta-out; Mon, 1 Nov 1999 23:16:46 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA30634 for ; Mon, 1 Nov 1999 23:16:44 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 8CED9472F; Tue, 2 Nov 1999 00:22:30 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Status of 21.1.8 From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 00:22:30 -0500 Message-ID: Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Here is the list of patches I've already commited to 21.1.8. I hope to turn the crank and release 21.1.8 tomorrow, but if I miss that date, it won't happen until Sunday at the earliest, as I must go out of town. http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00023.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00025.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00028.html http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00065.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00016.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00030.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00007.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00033.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00034.html http://www.xemacs.org/list-archives/xemacs-patches/9904/msg00039.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00080.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00046.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00043.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00054.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00056.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00055.html * http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00002.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00096.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00100.html http://www.xemacs.org/list-archives/xemacs-patches/9906/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00015.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00017.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00020.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00019.html * I actually applied Hrvoje's version of this patch, but that one went to xemacs-review, and hence is not in the mailinglist archive. - vin From owner-xemacs-beta@xemacs.org Tue Nov 2 00:11:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA32190 for xemacs-beta-out; Tue, 2 Nov 1999 00:11:28 -0500 Received: from max3p121.smart.net (max3p121.smart.net [216.84.81.121]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA32187 for ; Tue, 2 Nov 1999 00:11:23 -0500 Received: (from jmiller@localhost) by max3p121.smart.net (8.9.3/8.9.3) id BAA11172; Tue, 2 Nov 1999 01:22:47 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14366.33591.347462.767925@max3p121.smart.net.> Date: Tue, 2 Nov 1999 01:22:47 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Re: --pdump -vs- fast-lock/lazy loaded byte code? In-Reply-To: <19991101220907.A7152@nemesis.ncsl.nist.gov> References: <19991101220907.A7152@nemesis.ncsl.nist.gov> X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "OG" == Olivier Galibert writes: OG> On Mon, Nov 01, 1999 at 08:22:23PM +0900, SL Baur wrote: --snip-- OG> Try that. If it fixes the problem, please apply it. If it OG> doesn't, please show me the relevant part of your .emacs so that I OG> can reproduce the crash. it seems to fix it for me. I essentially had the same problem as Steve. ./temacs would coredump, ./temacs -vanilla would start. With your patch, now ./temacs starts up fine. Jeff From owner-xemacs-beta@xemacs.org Tue Nov 2 04:58:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA05569 for xemacs-beta-out; Tue, 2 Nov 1999 04:58:58 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA05558; Tue, 2 Nov 1999 04:58:33 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA28373; Tue, 2 Nov 1999 01:57:55 -0800 (PST) Received: from andyppc (london-shiva-2-2.beasys.com [10.5.1.22]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id JAA13531; Tue, 2 Nov 1999 09:58:29 GMT Message-Id: <3.0.5.32.19991102095912.00ad2b50@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Nov 1999 09:59:12 +0000 To: Vin Shelton , Andy Piper , Adrian Aichner From: Andy Piper Subject: Re: Patches Applied for 21.1.8 Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3.0.5.32.19991021090515.00a79490@london.beasys.com> <3.0.6.32.19991021202349.007b17e0@mail.dycon.com> <3.0.6.32.19991023120038.007e1120@mail.dycon.com> <3.0.6.32.19991023205932.007c9580@mail.dycon.com> <3.0.6.32.19991024232207.007c95a0@mail.dycon.com> <3.0.5.32.19991026220534.009b8b80@london.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 11:51 PM 11/1/99 -0500, Vin Shelton wrote: > >I'm a little confused; do I need to apply this patch to 21.1.8 in >addition to Adrian's patch for call process cleanup? No. It has no relevance for 21.1.x - I will apply it for 21.2.x andy > >--- nt.c~ Thu Jul 15 09:58:41 1999 >+++ nt.c Tue Oct 26 16:45:40 1999 >@@ -608,7 +608,9 @@ > "EMACSLOCKDIR", > "INFOPATH" > }; >- >+#ifdef HEAP_IN_DATA >+ cache_system_info (); >+#endif > for (i = 0; i < countof (env_vars); i++) > { > if (!getenv (env_vars[i]) && > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 2 05:11:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05809 for xemacs-beta-out; Tue, 2 Nov 1999 05:11:01 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05755; Tue, 2 Nov 1999 05:08:54 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA28749; Tue, 2 Nov 1999 02:07:03 -0800 (PST) Received: from andyppc (london-shiva-2-2.beasys.com [10.5.1.22]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id KAA13775; Tue, 2 Nov 1999 10:07:09 GMT Message-Id: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Nov 1999 10:07:51 +0000 To: acs@xemacs.org, aichner@ecf.teradyne.com From: Andy Piper Subject: Re: "Forked child base mismatch" using MKS Toolkit shell Cc: Mike Alexander , XEmacs NT List , xemacs-beta@xemacs.org In-Reply-To: <4.2.0.58.19991020002354.00a65960@pophost.arbortext.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin, I think this one should go in although it hasn't been sent to xemacs-patches. However, there maybe some wierd interaction with Adrian's process patch that should be checked. Adrian, does your patch include this? Have you tried this patch with yours? andy At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >A few weeks ago I sent a message to the list asking if anyone knew what was >causing the MKS Toolkit Korn shell to fail when used with the XEmacs shell >command. If you recall any attempt to invoke a sub shell produced the >message "Forked child base mismatch" and pipes didn't work (they appeared >to cause the shell to hang). I think I've fixed both problems and the >shell seems to be working ok now. > >The first problem was happening because nt-create-process creates the >process suspended and then uses run-in-other-process to issue a call to >SetConsoleCtrlHandler in the new process before it lets it run. Apparently >this call is doing something (probably allocating memory) which confuses >the MKS shell. I fixed this by deferring the call to SetConsoleCtrlHandler >until after the shell has had a chance to initialize. The only way I could >figure out to do this without changing core XEmacs was to use the >update_status_if_terminated call back which is a bit of a kludge. If >someone knows a better way, let me know. > >The other problem turned out to be caused by the fact that XEmacs was >passing the same handle for both StdOutput and StdError. When the shell >created the pipe between the two commands for something like "ps | sort" it >got confused because it wasn't expecting two copies of the same >handle. The net result was that it lost it's connection to StdError so no >further prompts appeared and I thought the shell had hung. This was easy >to fix by simply making StdError a copy of the StdOutput handle instead of >passing the same handle for both. > >Here is the patch that fixes both problems I'd appreciate it if someone >would give it a try and see if it breaks anything. I've tried this with >the current CVS source as of last night. > > >Mike Alexander Arbortext, Inc. >mta@arbortext.com +1-734-327-6803 > >--- process-nt.c 1999/09/11 08:57:25 1.11.2.5 >+++ process-nt.c 1999/10/19 08:24:07 >@@ -53,6 +53,7 @@ > struct nt_process_data > { > HANDLE h_process; >+ int need_enable_child_signals; > }; > > #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) >@@ -421,7 +422,7 @@ > Lisp_Object *argv, int nargv, > Lisp_Object program, Lisp_Object cur_dir) > { >- HANDLE hmyshove, hmyslurp, hprocin, hprocout; >+ HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; > LPTSTR command_line; > BOOL do_io, windowed; > char *proc_env; >@@ -472,6 +473,10 @@ > CreatePipe (&hprocin, &hmyshove, &sa, 0); > CreatePipe (&hmyslurp, &hprocout, &sa, 0); > >+ /* Duplicate the stdout handle for use as stderr */ >+ DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), >&hprocerr, >+ 0, TRUE, DUPLICATE_SAME_ACCESS); >+ > /* Stupid Win32 allows to create a pipe with *both* ends either > inheritable or not. We need process ends inheritable, and local > ends not inheritable. */ >@@ -599,7 +604,7 @@ > { > si.hStdInput = hprocin; > si.hStdOutput = hprocout; >- si.hStdError = hprocout; >+ si.hStdError = hprocerr; > si.dwFlags |= STARTF_USESTDHANDLES; > } > >@@ -614,6 +619,7 @@ > /* These just have been inherited; we do not need a copy */ > CloseHandle (hprocin); > CloseHandle (hprocout); >+ CloseHandle (hprocerr); > } > > /* Handle process creation failure */ >@@ -640,12 +646,18 @@ > CloseHandle (pi.hProcess); > } > >- if (!windowed) >- enable_child_signals (pi.hProcess); >- > ResumeThread (pi.hThread); > CloseHandle (pi.hThread); > >+ /* Remember to enable child signals later if this is not a windowed >+ app. Can't do it right now because that screws up the MKS Toolkit >+ shell. */ >+ if (!windowed) >+ { >+ NT_DATA(p)->need_enable_child_signals = 10; >+ kick_status_notify (); >+ } >+ > /* Hack to support Windows 95 negative pids */ > return ((int)pi.dwProcessId < 0 > ? -(int)pi.dwProcessId : (int)pi.dwProcessId); >@@ -664,6 +676,18 @@ > nt_update_status_if_terminated (struct Lisp_Process* p) > { > DWORD exit_code; >+ >+ if (NT_DATA(p)->need_enable_child_signals > 1) >+ { >+ NT_DATA(p)->need_enable_child_signals -= 1; >+ kick_status_notify (); >+ } >+ else if (NT_DATA(p)->need_enable_child_signals == 1) >+ { >+ enable_child_signals(NT_DATA(p)->h_process); >+ NT_DATA(p)->need_enable_child_signals = 0; >+ } >+ > if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) > && exit_code != STILL_ACTIVE) > { >@@ -764,6 +788,14 @@ > int current_group, int nomsg) > { > struct Lisp_Process *p = XPROCESS (proc); >+ >+ /* Enable child signals if necessary. This may lose the first >+ but it's better than nothing. */ >+ if (NT_DATA(p)->need_enable_child_signals > 0) >+ { >+ enable_child_signals(NT_DATA(p)->h_process); >+ NT_DATA(p)->need_enable_child_signals = 0; >+ } > > /* Signal error if SIGNO cannot be sent */ > validate_signal_number (signo); > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 2 06:42:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA07954 for xemacs-beta-out; Tue, 2 Nov 1999 06:42:32 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA07951 for ; Tue, 2 Nov 1999 06:42:30 -0500 Received: (qmail 28457 invoked by alias); 2 Nov 1999 11:42:23 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 28436 invoked by uid 0); 2 Nov 1999 11:42:21 -0000 Received: from dialupe151.tcsn.uswest.net (HELO 666.com) (209.180.112.151) by tcsnpop1.tcsn.uswest.net with SMTP; 2 Nov 1999 11:42:21 -0000 Message-ID: <381ECE04.B423D895@666.com> Date: Tue, 02 Nov 1999 04:41:57 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs beta list , XEmacs Patches List , XEmacs Reviews Subject: Correct format for patch attachments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: PLEASE PLEASE PLEASE make sure that, whenever you send a patch as an attachment, the type of the patch is "text/plain". I have seen patches in "application/octet-stream", "application/x-patch", "application/x-diff", "text/x-patch", etc. etc. These weird MIME types screw up my mail reader (and I imagine many other people's, too), so that I have to save the patch out to another directory, go find it again, and open it up in some random Windows text editor crap. If the type is "text/plain", it comes up nicely right in my mail reader, and makes it much more likely that I will carefully go over the patch. So can we agree upon a standard, i.e. all patch attachments are MIME type "text/plain"? Thank you. Ben From owner-xemacs-beta@xemacs.org Tue Nov 2 06:52:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08216 for xemacs-beta-out; Tue, 2 Nov 1999 06:52:21 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA08209; Tue, 2 Nov 1999 06:52:15 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id GAA29923; Tue, 2 Nov 1999 06:59:12 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id MAA01529; Tue, 2 Nov 1999 12:52:01 +0100 (MET) To: Andy Piper Cc: acs@xemacs.org, aichner@ecf.teradyne.com, Mike Alexander , XEmacs NT List , xemacs-beta@xemacs.org Subject: Re: "Forked child base mismatch" using MKS Toolkit shell References: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 02 Nov 1999 12:49:45 +0100 In-Reply-To: Andy Piper's message of "Tue, 02 Nov 1999 10:07:51 +0000" Message-ID: Lines: 165 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> Vin, I think this one should go in although it hasn't been Andy> sent to xemacs-patches. However, there maybe some wierd Andy> interaction with Adrian's process patch that should be Andy> checked. Adrian, does your patch include this? Have you No Andy> tried this patch with yours? No I'll try to take a lok at this this evening. Adrian Andy> andy Andy> At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >> A few weeks ago I sent a message to the list asking if anyone knew what was >> causing the MKS Toolkit Korn shell to fail when used with the XEmacs shell >> command. If you recall any attempt to invoke a sub shell produced the >> message "Forked child base mismatch" and pipes didn't work (they appeared >> to cause the shell to hang). I think I've fixed both problems and the >> shell seems to be working ok now. >> >> The first problem was happening because nt-create-process creates the >> process suspended and then uses run-in-other-process to issue a call to >> SetConsoleCtrlHandler in the new process before it lets it run. Apparently >> this call is doing something (probably allocating memory) which confuses >> the MKS shell. I fixed this by deferring the call to SetConsoleCtrlHandler >> until after the shell has had a chance to initialize. The only way I could >> figure out to do this without changing core XEmacs was to use the >> update_status_if_terminated call back which is a bit of a kludge. If >> someone knows a better way, let me know. >> >> The other problem turned out to be caused by the fact that XEmacs was >> passing the same handle for both StdOutput and StdError. When the shell >> created the pipe between the two commands for something like "ps | sort" it >> got confused because it wasn't expecting two copies of the same >> handle. The net result was that it lost it's connection to StdError so no >> further prompts appeared and I thought the shell had hung. This was easy >> to fix by simply making StdError a copy of the StdOutput handle instead of >> passing the same handle for both. >> >> Here is the patch that fixes both problems I'd appreciate it if someone >> would give it a try and see if it breaks anything. I've tried this with >> the current CVS source as of last night. >> >> >> Mike Alexander Arbortext, Inc. >> mta@arbortext.com +1-734-327-6803 >> >> --- process-nt.c 1999/09/11 08:57:25 1.11.2.5 >> +++ process-nt.c 1999/10/19 08:24:07 >> @@ -53,6 +53,7 @@ >> struct nt_process_data >> { >> HANDLE h_process; >> + int need_enable_child_signals; >> }; >> >> #define NT_DATA(p) ((struct nt_process_data*)((p)->process_data)) >> @@ -421,7 +422,7 @@ >> Lisp_Object *argv, int nargv, >> Lisp_Object program, Lisp_Object cur_dir) >> { >> - HANDLE hmyshove, hmyslurp, hprocin, hprocout; >> + HANDLE hmyshove, hmyslurp, hprocin, hprocout, hprocerr; >> LPTSTR command_line; >> BOOL do_io, windowed; >> char *proc_env; >> @@ -472,6 +473,10 @@ >> CreatePipe (&hprocin, &hmyshove, &sa, 0); >> CreatePipe (&hmyslurp, &hprocout, &sa, 0); >> >> + /* Duplicate the stdout handle for use as stderr */ >> + DuplicateHandle(GetCurrentProcess(), hprocout, GetCurrentProcess(), >> &hprocerr, >> + 0, TRUE, DUPLICATE_SAME_ACCESS); >> + >> /* Stupid Win32 allows to create a pipe with *both* ends either >> inheritable or not. We need process ends inheritable, and local >> ends not inheritable. */ >> @@ -599,7 +604,7 @@ >> { >> si.hStdInput = hprocin; >> si.hStdOutput = hprocout; >> - si.hStdError = hprocout; >> + si.hStdError = hprocerr; >> si.dwFlags |= STARTF_USESTDHANDLES; >> } >> >> @@ -614,6 +619,7 @@ >> /* These just have been inherited; we do not need a copy */ >> CloseHandle (hprocin); >> CloseHandle (hprocout); >> + CloseHandle (hprocerr); >> } >> >> /* Handle process creation failure */ >> @@ -640,12 +646,18 @@ >> CloseHandle (pi.hProcess); >> } >> >> - if (!windowed) >> - enable_child_signals (pi.hProcess); >> - >> ResumeThread (pi.hThread); >> CloseHandle (pi.hThread); >> >> + /* Remember to enable child signals later if this is not a windowed >> + app. Can't do it right now because that screws up the MKS Toolkit >> + shell. */ >> + if (!windowed) >> + { >> + NT_DATA(p)->need_enable_child_signals = 10; >> + kick_status_notify (); >> + } >> + >> /* Hack to support Windows 95 negative pids */ >> return ((int)pi.dwProcessId < 0 >> ? -(int)pi.dwProcessId : (int)pi.dwProcessId); >> @@ -664,6 +676,18 @@ >> nt_update_status_if_terminated (struct Lisp_Process* p) >> { >> DWORD exit_code; >> + >> + if (NT_DATA(p)->need_enable_child_signals > 1) >> + { >> + NT_DATA(p)->need_enable_child_signals -= 1; >> + kick_status_notify (); >> + } >> + else if (NT_DATA(p)->need_enable_child_signals == 1) >> + { >> + enable_child_signals(NT_DATA(p)->h_process); >> + NT_DATA(p)->need_enable_child_signals = 0; >> + } >> + >> if (GetExitCodeProcess (NT_DATA(p)->h_process, &exit_code) >> && exit_code != STILL_ACTIVE) >> { >> @@ -764,6 +788,14 @@ >> int current_group, int nomsg) >> { >> struct Lisp_Process *p = XPROCESS (proc); >> + >> + /* Enable child signals if necessary. This may lose the first >> + but it's better than nothing. */ >> + if (NT_DATA(p)->need_enable_child_signals > 0) >> + { >> + enable_child_signals(NT_DATA(p)->h_process); >> + NT_DATA(p)->need_enable_child_signals = 0; >> + } >> >> /* Signal error if SIGNO cannot be sent */ >> validate_signal_number (signo); >> >> >> Andy> -------------------------------------------------------------- Andy> Dr Andy Piper Andy> Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 2 07:23:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA09325 for xemacs-beta-out; Tue, 2 Nov 1999 07:23:31 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA09320; Tue, 2 Nov 1999 07:23:29 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 7DD54472F; Tue, 2 Nov 1999 08:29:20 -0500 (EST) To: xemacs-mule@xemacs.org, xemacs-beta@xemacs.org Subject: Ethiopic in 21.1.7++ From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 08:29:20 -0500 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm working on the candidate for 21.1.8 (everything checked in to CVS), and when I try to: Mule -> Set Language Environment -> Ethiopic I get the following error and backtrace: Symbol's function definition is void: setup-ethiopic-environment-internal Signaling: (void-function setup-ethiopic-environment-internal) setup-ethiopic-environment-internal() set-language-environment("Ethiopic") eval((set-language-environment "Ethiopic")) I'd like to get this working before I release 21.1.8 (tonight, I hope). Can anyone offer a patch? - vin From owner-xemacs-beta@xemacs.org Tue Nov 2 07:24:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA09362 for xemacs-beta-out; Tue, 2 Nov 1999 07:24:08 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA09355; Tue, 2 Nov 1999 07:24:06 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA25929; Tue, 2 Nov 1999 13:24:04 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006L7; Tue Nov 2 13:24:01 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id NAA12140; Tue, 2 Nov 1999 13:24:01 +0100 To: Ben Wing Cc: XEmacs beta list , XEmacs Patches List Subject: Re: Correct format for patch attachments References: <381ECE04.B423D895@666.com> From: Jan Vroonhof Date: 02 Nov 1999 13:24:00 +0100 In-Reply-To: Ben Wing's message of "Tue, 02 Nov 1999 04:41:57 -0700" Message-ID: Lines: 19 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > So can we agree upon a standard, i.e. all patch attachments are MIME > type "text/plain"? We already agreed on that. However it doesn't really help. A lot of patches are submitted by "first time patchers" and those won't know that. The problem here is that the TM uses that type as a device for patches. So we cannot do much more than repeat this plea every now and again. The best solution would be to migrate you away from such a broken platform. IBM has released its viavoice dev kit for linux as beta, have you tried using something like kvoice? If it is anything close to sufficient would create XEmacs support for this. (Unfortunately it is unlikely that we will be able to release it to the general public). Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 07:30:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA09685 for xemacs-beta-out; Tue, 2 Nov 1999 07:30:10 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA09682 for ; Tue, 2 Nov 1999 07:30:07 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA26056 for ; Tue, 2 Nov 1999 13:30:05 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006N5; Tue Nov 2 13:29:58 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id NAA12144; Tue, 2 Nov 1999 13:29:57 +0100 To: xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) References: <199911012154.NAA01963@ptavv.es.net> From: Jan Vroonhof Date: 02 Nov 1999 13:29:57 +0100 In-Reply-To: Vin Shelton's message of "01 Nov 1999 19:41:11 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin Shelton writes: > /usr/local/xemacs-packages/lisp/xemacs-base/xpm-button hides > /usr/local/xemacs/lib/xemacs-21.1.7/lisp/xpm-button > > Am I missing something? Did you rebuild the autoloads? Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 07:40:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA10183 for xemacs-beta-out; Tue, 2 Nov 1999 07:40:32 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA10179 for ; Tue, 2 Nov 1999 07:40:29 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id HAA02859 for ; Tue, 2 Nov 1999 07:47:11 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id NAA01699; Tue, 2 Nov 1999 13:39:58 +0100 (MET) To: XEmacs Beta List Subject: Q: warn_when_safe vs. stderr_out X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 02 Nov 1999 13:37:43 +0100 Message-ID: Lines: 14 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello All! Can someone here give me a hint where to start looking for documentation on usage of warn_when_safe vs. stderr_out in XEmacs source? I wasn't able to find anything on either of them in 21.1 or 21.2 CVS xemacs/man sources. Regards, Adrian From owner-xemacs-beta@xemacs.org Tue Nov 2 07:51:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA10626 for xemacs-beta-out; Tue, 2 Nov 1999 07:51:46 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA10622 for ; Tue, 2 Nov 1999 07:51:42 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA26495; Tue, 2 Nov 1999 13:51:37 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006Tv; Tue Nov 2 13:51:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id NAA12418; Tue, 2 Nov 1999 13:51:30 +0100 To: xemacs-beta@xemacs.org, James LewisMoss Subject: Re: Question about mule compiled elisp files References: From: Jan Vroonhof Date: 02 Nov 1999 13:51:29 +0100 In-Reply-To: James LewisMoss's message of "01 Nov 1999 14:52:16 -0500" Message-ID: Lines: 41 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: James LewisMoss writes: > Is it safe to use mule compiled elisp files with a non-mule binary? Yes, if the source was plain ascii. No, otherwise. > First is that trying to use jka-compr gives an error like > coding-system-for-read undefined. This is a bug in the jka-compr package. There is patch around for ages, but for some reason we haven't had a package release release for some months. These are really urgent patches that are prime candidates for your .diff section This fixes the jka-compr bug http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00013.html This fixes a similar problem in calendar.el http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00063.html This fixes an equally stupid bug with ps-print http://www.xemacs.org/list-archives/xemacs-patches/9907/msg00053.html > The other is that when starting a non-mule binary the warnings > > (1) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/skk/auto-autoloads: > Cannot open load file: mule > (2) (warning/warning) Autoload error in: /usr/share/xemacs21/mule-packages/lisp/lookup/auto-autoloads: > Cannot open load file: mule This is wrong. The package-path should NOT contain mule-packages for a non-mule build. Are you setting the package-path explicitly? Jan P.S. I suggest you either use the mainline CVS or weight for .8 as those contain some patches tailor made for you (the Linux dumping architecture problems that I sent you a patch for and a fix work around a bug in the recent glibc version that potato uses) From owner-xemacs-beta@xemacs.org Tue Nov 2 08:03:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11055 for xemacs-beta-out; Tue, 2 Nov 1999 08:03:07 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11046 for ; Tue, 2 Nov 1999 08:02:56 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11idaQ-0008H4-00 for ; Tue, 02 Nov 1999 14:02:54 +0100 To: XEmacs Beta List Subject: Re: Q: warn_when_safe vs. stderr_out References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 02 Nov 1999 14:02:54 +0100 In-Reply-To: Adrian Aichner's message of "02 Nov 1999 13:37:43 +0100" Message-ID: <9t9n1sx82rl.fsf@mraz.iskon.hr> Lines: 15 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > Can someone here give me a hint where to start looking for > documentation on usage of warn_when_safe vs. stderr_out in XEmacs > source? Use warn_when_safe() as you would use the Lisp function `display-warning', except that warn_when_safe() accepts format parameters a la `message'. > I wasn't able to find anything on either of them in 21.1 or 21.2 CVS > xemacs/man sources. Huh? `grep warn_when_safe *.c' will give you tens of examples of usage. From owner-xemacs-beta@xemacs.org Tue Nov 2 08:07:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11154 for xemacs-beta-out; Tue, 2 Nov 1999 08:07:49 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id IAA11148 for ; Tue, 2 Nov 1999 08:07:47 -0500 Received: (qmail 18377 invoked from network); 2 Nov 1999 13:06:28 -0000 Received: from usrpri2-35.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.100) by biff.kiva.net with SMTP; 2 Nov 1999 13:06:28 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id IAA24674; Tue, 2 Nov 1999 08:09:14 -0500 To: Jan Vroonhof Cc: Ben Wing , XEmacs beta list , XEmacs Patches List Subject: Re: Correct format for patch attachments X-Now-Listening-To: Commitments, - Fa-fa-fa-fa (Sad Song) References: <381ECE04.B423D895@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 60 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Ben Wing writes: > > > So can we agree upon a standard, i.e. all patch attachments are MIME > > type "text/plain"? > > We already agreed on that. However it doesn't really help. A lot of > patches are submitted by "first time patchers" and those won't know > that. The problem here is that the TM uses that type as a device for > patches. So we cannot do much more than repeat this plea every now and > again. > > The best solution would be to migrate you away from such a broken > platform. IBM has released its viavoice dev kit for linux as beta, have > you tried using something like kvoice? If it is anything close to > sufficient would create XEmacs support for this. (Unfortunately it is > unlikely that we will be able to release it to the general public). I actually did a bit of hacking with ViaVoice to get XEmacs to recognize it. It wouldn't be that hard to do. I was debating whether to put it in as part of the main XEmacs executable, or just write a generic program that would run in a subprocess and have a process-filter on it that just inserted the text. I didn't actually get any of it working before work starting beckoning again (ah, to have more than a weekend to hack on things). My goal was going to be something like: (defun viavoice-mode (&optional arg) "Toggle ViaVoice mode. With arg, turn ViaVoice mode on if and only if arg is positive. When ViaVoice mode is enabled, voice recognition is performed. All voice data is analyzed and put into the current buffer as keystrokes." ...) (defun viavoice-vocabulary-define-word () "Define a word in the XEmacs vocabulary for voice recognition. You will be prompted to say the word clearly, as well as type the textual equivalent." ...) (defun viavoice-vocabulary-remove-word () "Remove a word from the XEmacs vocabulary for voice recognition." ...) (defun viavoice-vocabulary-save () "Save the currently loaded vocabulary" ...) ViaVoice mode would basically boil down to turning the mic on and off by the appropriate ViaVoice SDK functions. If anybody wants to hack on this, I'd love to help as much as I can. I need to just take a month off from work. :( -Bill P. From owner-xemacs-beta@xemacs.org Tue Nov 2 08:08:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11170 for xemacs-beta-out; Tue, 2 Nov 1999 08:08:26 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11167 for ; Tue, 2 Nov 1999 08:08:25 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id IAA04319 for ; Tue, 2 Nov 1999 08:15:27 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id OAA02316; Tue, 2 Nov 1999 14:08:16 +0100 (MET) To: xemacs-beta@xemacs.org Subject: .el reported newer for xemacs-packages after DaylightSavingTime ends X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 02 Nov 1999 14:05:58 +0100 Message-ID: Lines: 39 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i586-pc-win32) of Sun Oct 24 1999 on ZJ75T configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: All packages were installed when DST was on. Now that DST went off automatically in Europe last sunday morning, I get tons of these messages when any lisp packages are loaded. This happens both in post 21.1.7 and post 21.2-b19 XEmacsen. Any ideas? Adrian Recent keystrokes: C-x m M-x s h - m e s SPC RET C-x 0 x e m a c s - n BS b e t a C-x k RET y misc-user Recent messages (most recent first): Loading c:\XEmacs\xemacs-packages\lisp\mail-lib\mail-extr.elc...done (file mail-extr.el is newer) Loading c:\XEmacs\xemacs-packages\lisp\mail-lib\mail-extr.elc... (file mail-extr.el is newer) Loading mail-extr... Loading emacsbug...done Loading c:\XEmacs\xemacs-packages\lisp\net-utils\emacsbug.elc...done (file emacsbug.el is newer) Loading c:\XEmacs\xemacs-packages\lisp\net-utils\emacsbug.elc... (file emacsbug.el is newer) Loading emacsbug... Buffer *mail* modified; kill anyway? (y or n) Yes Buffer *mail* modified; kill anyway? (y or n) Loading lazy-lock...done From owner-xemacs-beta@xemacs.org Tue Nov 2 08:28:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA12063 for xemacs-beta-out; Tue, 2 Nov 1999 08:28:24 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA12059 for ; Tue, 2 Nov 1999 08:28:19 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11idyz-0008Rj-00 for ; Tue, 02 Nov 1999 14:28:17 +0100 To: XEmacs Beta List Subject: Support for /usr/share/info X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 02 Nov 1999 14:28:16 +0100 Message-ID: <9t9aeox81lb.fsf@mraz.iskon.hr> Lines: 6 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Lateish Debian systems enforce placing Info pages to /usr/share/info rather than /usr/info. XEmacs doesn't seem to recognize this. Of course, I can add this to Info-directory-list, but I don't know off-hand how to fix this correctly (in the source). Any ideas? From owner-xemacs-beta@xemacs.org Tue Nov 2 08:36:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA12495 for xemacs-beta-out; Tue, 2 Nov 1999 08:36:13 -0500 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA12492 for ; Tue, 2 Nov 1999 08:36:12 -0500 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ie6d-0001hW-00 for xemacs-beta@xemacs.org; Tue, 02 Nov 1999 08:36:11 -0500 To: xemacs-beta@xemacs.org Subject: verilog-mode.el 3.37 released Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 02 Nov 1999 08:36:11 -0500 Message-ID: Lines: 4 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Note: I have not personally tested this code. ;;; You can get step by step help in installing this file by going to ;;; From owner-xemacs-beta@xemacs.org Tue Nov 2 09:15:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA13710 for xemacs-beta-out; Tue, 2 Nov 1999 09:15:56 -0500 Received: from pm1.contactor.se (gw.contactor.se [193.15.23.130]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA13705 for ; Tue, 2 Nov 1999 09:15:45 -0500 Received: from sid.contactor.se (IDENT:matsl@dhcp118.contactor.se [193.15.23.118]) by pm1.contactor.se (8.9.3/8.9.1) with SMTP id PAA23251 for ; Tue, 2 Nov 1999 15:23:49 +0100 (MET) To: xemacs-beta@xemacs.org Subject: Building xemacs-packages from the top. Possible? From: Mats Lidell Date: 02 Nov 1999 16:20:19 +0100 Message-ID: Lines: 23 User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) XEmacs/21.0 (Irish Goat) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi, I'm trying to catch up on beta testing xemacs by picking the sources from CVS. Works fine. When it comes to the packages I fail to find any decent way to build them all from the top. The best I have found is to go around in leaf directories and "make" like this: "make STAGING=/... bindist" Now this is not what you want to do after a cvs update. I would want to be able to build it all from the top. I have really tried to look for documentation both in xemacs and xemacs-packages module but failed to find anything. Since this is beta test stuff I don't know what to expect either but to be frank I was expecting something a bit more polished and I'm sure there is. So how to do it? Yours -- %% Mats From owner-xemacs-beta@xemacs.org Tue Nov 2 12:06:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA27229 for xemacs-beta-out; Tue, 2 Nov 1999 12:06:57 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA27223 for ; Tue, 2 Nov 1999 12:06:51 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id MAA21439; Tue, 2 Nov 1999 12:13:33 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id SAA04042; Tue, 2 Nov 1999 18:06:21 +0100 (MET) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Q: warn_when_safe vs. stderr_out References: <9t9n1sx82rl.fsf@mraz.iskon.hr> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 02 Nov 1999 18:04:07 +0100 In-Reply-To: Hrvoje Niksic's message of "02 Nov 1999 14:02:54 +0100" Message-ID: Lines: 32 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Adrian Aichner writes: >> Can someone here give me a hint where to start looking for >> documentation on usage of warn_when_safe vs. stderr_out in XEmacs >> source? Hrvoje> Use warn_when_safe() as you would use the Lisp function Hrvoje> `display-warning', except that warn_when_safe() accepts format Hrvoje> parameters a la `message'. Ah, that gets me started. Thanks! >> I wasn't able to find anything on either of them in 21.1 or 21.2 CVS >> xemacs/man sources. Hrvoje> Huh? `grep warn_when_safe *.c' will give you tens of Hrvoje> examples of usage. This is true. I still find it hard though to deduce correct usage from examples. I used stderr_out because I found examples of its usage in the first place :-) Are there any rules how to pick the correct level amongst these: The recognized warning levels, in decreasing order of priority, are 'emergency, 'alert, 'critical, 'error, 'warning, 'notice, 'info, and 'debug. Thanks, Adrian From owner-xemacs-beta@xemacs.org Tue Nov 2 12:39:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA29018 for xemacs-beta-out; Tue, 2 Nov 1999 12:39:23 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA29011 for ; Tue, 2 Nov 1999 12:39:18 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA15503 for ; Tue, 2 Nov 1999 18:39:17 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003mD; Tue Nov 2 18:39:08 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA13244; Tue, 2 Nov 1999 18:39:08 +0100 To: xemacs-beta@xemacs.org Subject: Re: Q: warn_when_safe vs. stderr_out References: <9t9n1sx82rl.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 02 Nov 1999 18:39:08 +0100 In-Reply-To: Adrian Aichner's message of "02 Nov 1999 18:04:07 +0100" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > Are there any rules how to pick the correct level amongst these: > > The recognized warning levels, in decreasing order of priority, are > 'emergency, 'alert, 'critical, 'error, 'warning, 'notice, 'info, and > 'debug. Not really I think. I think the most important would be their value relative to the default display-warning-minimum level (which IMHO is currently too low). From owner-xemacs-beta@xemacs.org Tue Nov 2 13:21:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA30349 for xemacs-beta-out; Tue, 2 Nov 1999 13:21:44 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA30346 for ; Tue, 2 Nov 1999 13:21:42 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id TAA19697 for xemacs-beta@xemacs.org; Tue, 2 Nov 1999 19:21:41 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11iiYH-00038Y-00 for xemacs-beta@xemacs.org; Tue, 02 Nov 1999 19:21:01 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 0) id 48DDE1993; Tue, 2 Nov 1999 19:21:00 +0100 (CET) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: applying patches References: From: Andreas Jaeger Date: 02 Nov 1999 19:20:59 +0100 In-Reply-To: Jan Vroonhof's message of "19 Oct 1999 14:55:06 +0200" Message-ID: Lines: 45 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Jan Vroonhof writes: Jan> Gunnar Evermann writes: >> How are patches sent to xemacs-patches handled at the moment? Jan> Extremely ad-hoc. AFAICS nobody is applying patches to the packages at Jan> the moment. >> Is anyone applying the patches sent there by people without cvs-write >> access? Jan> Andy and Michael have applied most them. Normally Steve applies all Jan> that were left out, just before a new beta releases. >> We should really make sure we do not lose any patches and that >> everything that is applied to 21.1 is also applied to 21.2! Jan> Yes. We need some explicit tracker system (that is what xemacs-review Jan> is meant for but I am not sure it is working properly). There is a Jan> whole lot of patches to the packages that are "in the queue" for two Jan> months now. I would love it if there were some system in there Jan> somewhere. For instance there is a patch from _February_ about esound Jan> support that I still want look at (I didn't have esound at the time). Hi, can I help out? After considering this for some time, I'm volunteering to help. I should have enough time to keep the CVS archive for the packages uptodate. For those who don't know me, let me introduce myself briefly. I'm one of the glibc developers and XEmacs is one of my favorite programs. In mid 1997 I helped to get XEmacs running with glibc2 - and since I'm always using glibc testreleases, XEmacs still works with glibc;-). I'm currently employed by the Linux distributor SuSE and have spent some time during the last weeks to get a mule enabled XEmacs 21.1.7 on our next distribution. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 2 13:30:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA30605 for xemacs-beta-out; Tue, 2 Nov 1999 13:30:55 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA30601 for ; Tue, 2 Nov 1999 13:30:53 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA16881 for ; Tue, 2 Nov 1999 19:30:51 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0047i; Tue Nov 2 19:30:42 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA13253; Tue, 2 Nov 1999 19:30:41 +0100 To: xemacs-beta@xemacs.org Subject: Re: Ethiopic in 21.1.7++ References: From: Jan Vroonhof Date: 02 Nov 1999 19:30:41 +0100 In-Reply-To: Vin Shelton's message of "02 Nov 1999 08:29:20 -0500" Message-ID: Lines: 26 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin Shelton writes: > Symbol's function definition is void: setup-ethiopic-environment-internal > > Signaling: (void-function setup-ethiopic-environment-internal) > setup-ethiopic-environment-internal() > set-language-environment("Ethiopic") > eval((set-language-environment "Ethiopic")) > > I'd like to get this working before I release 21.1.8 (tonight, I > hope). Can anyone offer a patch? I tried making the obvious path (namely copying 'setup-ethiopic-environment-internal from an old mule base into the core), however then I stopped. auto-autoloads.el from mule-base contains (autoload 'setup-ethiopic-environment-internal "ethio-util" nil nil nil) so how could this happen? IMO it would be better to have an 21.1.8 now with broken ethiopic support than on sunday with a fix. Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 13:40:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA30956 for xemacs-beta-out; Tue, 2 Nov 1999 13:40:05 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA30953 for ; Tue, 2 Nov 1999 13:40:03 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA17004 for ; Tue, 2 Nov 1999 19:40:02 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0049c; Tue Nov 2 19:39:59 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA13272; Tue, 2 Nov 1999 19:39:57 +0100 To: xemacs-beta@xemacs.org Subject: Re: Support for /usr/share/info References: <9t9aeox81lb.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 02 Nov 1999 19:39:55 +0100 In-Reply-To: Hrvoje Niksic's message of "02 Nov 1999 14:28:16 +0100" Message-ID: Lines: 17 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Lateish Debian systems enforce placing Info pages to /usr/share/info > rather than /usr/info. XEmacs doesn't seem to recognize this. Of > course, I can add this to Info-directory-list, but I don't know > off-hand how to fix this correctly (in the source). Add it to (defvar paths-default-info-directories (list (paths-construct-path '("usr" "local" "info") (char-to-string directory-sep-char)) (paths-construct-path '("usr" "info") (char-to-string directory-sep-char))) "Directories appended to the end of the info path by default.") Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 13:47:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA31147 for xemacs-beta-out; Tue, 2 Nov 1999 13:47:31 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA31144 for ; Tue, 2 Nov 1999 13:47:29 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA17098 for ; Tue, 2 Nov 1999 19:47:12 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004B8; Tue Nov 2 19:47:10 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA13274; Tue, 2 Nov 1999 19:47:10 +0100 To: xemacs-beta@xemacs.org Subject: Re: Building xemacs-packages from the top. Possible? References: From: Jan Vroonhof Date: 02 Nov 1999 19:47:10 +0100 In-Reply-To: Mats Lidell's message of "02 Nov 1999 16:20:19 +0100" Message-ID: Lines: 24 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mats Lidell writes: > When it comes to the packages I fail to find any decent way to build > them all from the top. The best I have found is to go around in leaf > directories and "make" like this: > > "make STAGING=/... bindist" > > Now this is not what you want to do after a cvs update. I would want > to be able to build it all from the top. You are supposed to be able to just type "make" in the toplevel directory. >From the toplevel Makefile all: for dir in $(SUBDIRS); do \ $(MAKE) $(MFLAGS) -C $${dir} autoloads; \ done for dir in $(SUBDIRS); do \ $(MAKE) $(MFLAGS) -C $${dir} bytecompile; \ done Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 13:59:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA31639 for xemacs-beta-out; Tue, 2 Nov 1999 13:59:30 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA31631; Tue, 2 Nov 1999 13:59:25 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA17282; Tue, 2 Nov 1999 19:59:23 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004Dy; Tue Nov 2 19:59:22 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA13315; Tue, 2 Nov 1999 19:59:22 +0100 To: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: XEmacs 21.2.19 "Sneaky Bastard 19991102" not released From: Jan Vroonhof Date: 02 Nov 1999 19:59:22 +0100 Message-ID: Lines: 27 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: It has been a long time since their has been an 21.2 release. To allow people without CVS access to enjoy the delights of the portable dumper and other goodies added since July, I have made http://www.math.ethz.ch/~vroonhof/emacs/xemacs-sneaky-19991102.tar.gz This a CVS snapshot of the CVS as of to day. The only things I did are - cvs checkout -r release-21-2 - change the code name to "Sneaky Bastard 19991102" to allow identification. - renamed toplevel directory - tar xzf xemacs-sneaky-19991102.tar.gz Nothing else. This is not a real beta release, in particular - It is not test compiled at all. - It is still called 21.1.19 and will overwrite older versions of 21.1.19 on install - CHANGES.beta and other readme's have not been updated. - The codename is not a part of Tokyo. Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 14:23:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32513 for xemacs-beta-out; Tue, 2 Nov 1999 14:23:50 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA32508 for ; Tue, 2 Nov 1999 14:23:46 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11ijJv-0000PS-00; Tue, 02 Nov 1999 20:10:15 +0100 To: Adrian Aichner Cc: XEmacs Beta List Subject: Re: Q: warn_when_safe vs. stderr_out References: <9t9n1sx82rl.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 02 Nov 1999 20:10:15 +0100 In-Reply-To: Adrian Aichner's message of "02 Nov 1999 18:04:07 +0100" Message-ID: <9t9bt9c4smg.fsf@mraz.iskon.hr> Lines: 16 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > Hrvoje> Huh? `grep warn_when_safe *.c' will give you tens of > Hrvoje> examples of usage. > > This is true. I still find it hard though to deduce correct usage > from examples. Yes. Such is the way of hacking XEmacs internals. *Some* things are, of course, explained in the Internals manual, but many more are not. > The recognized warning levels, in decreasing order of priority, > are 'emergency, 'alert, 'critical, 'error, 'warning, 'notice, > 'info, and 'debug. Use common sense. Most code uses 'warning, I think. From owner-xemacs-beta@xemacs.org Tue Nov 2 20:37:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA11169 for xemacs-beta-out; Tue, 2 Nov 1999 20:37:23 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA11158 for ; Tue, 2 Nov 1999 20:37:19 -0500 Received: (qmail 9689 invoked by alias); 3 Nov 1999 01:37:04 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 9611 invoked by uid 0); 3 Nov 1999 01:37:01 -0000 Received: from dialupe250.tcsn.uswest.net (HELO 666.com) (209.180.112.250) by tcsnpop1.tcsn.uswest.net with SMTP; 3 Nov 1999 01:37:01 -0000 Message-ID: <381F9072.2280E2AC@666.com> Date: Tue, 02 Nov 1999 18:31:31 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof CC: XEmacs beta list , XEmacs Patches List Subject: Re: Correct format for patch attachments References: <381ECE04.B423D895@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Why can't we just ask Tomohiko to fix this TM problem? (or even require it, since he will be participating in Mule development?) As for Windows, I'm not using voice recognition, but there are many other reasons I'm on this platform. In addition, isn't it useful to have someone who will be actively fixing the Windows problems? Jan Vroonhof wrote: > Ben Wing writes: > > > So can we agree upon a standard, i.e. all patch attachments are MIME > > type "text/plain"? > > We already agreed on that. However it doesn't really help. A lot > of patches are submitted by "first time patchers" and those won't know > that. The problem here is that the TM uses that type as a device for > patches. So we cannot do much more than repeat this plea every now and > again. > > The best solution would be to migrate you away from such a broken > platform. IBM has released its viavoice dev kit for linux as beta, > have you tried using something like kvoice? If it is anything close to > sufficient would create XEmacs support for this. (Unfortunately it is > unlikely that we will be able to release it to the general public). > > Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 20:47:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA12512 for xemacs-beta-out; Tue, 2 Nov 1999 20:47:14 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA12504 for ; Tue, 2 Nov 1999 20:47:12 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id A81BE472F; Tue, 2 Nov 1999 21:52:54 -0500 (EST) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) References: <199911012154.NAA01963@ptavv.es.net> From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 21:52:54 -0500 In-Reply-To: Jan Vroonhof's message of "02 Nov 1999 13:29:57 +0100" Message-ID: Lines: 33 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I believe the build scripts take care of rebuilding the autoloads. Just now I ran 'make autoloads', but it didn't change anything. ...and there is no mention of the string 'xpm' in any of the lisp/auto* files. OK. I built up a 21.1.7 without any packages, and xpm-button-create does not get defined until I load-library xpm-button. These lines appear in xpm-button.el: ;;;###autoload (defun xpm-button-create (text shadow-thickness fg-color bg-color) Meanwhile, in my package-less XEmacs, I can still use the toolbar (at least to cut text). What was the bug that I was trying to address by copying xpm-button.el to the lisp directory? I don't get it. Help! - vin >>>>> On 02 Nov 1999, Jan Vroonhof said: Jan> Vin Shelton writes: >> /usr/local/xemacs-packages/lisp/xemacs-base/xpm-button hides >> /usr/local/xemacs/lib/xemacs-21.1.7/lisp/xpm-button >> >> Am I missing something? Jan> Did you rebuild the autoloads? Jan> Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 21:24:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA17707 for xemacs-beta-out; Tue, 2 Nov 1999 21:24:43 -0500 Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA17692 for ; Tue, 2 Nov 1999 21:24:38 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id VAA29171 for ; Tue, 2 Nov 1999 21:24:32 -0500 (EST) Date: Tue, 2 Nov 1999 21:24:32 -0500 (EST) Message-Id: <199911030224.VAA29171@chmls05.mediaone.net> Mail-Copies-To: Never From: "XEmacs Build 'Bot" Subject: XEmacs Build Report for XEmacs-21.1.8 To: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello XEmacs beta testers. I am in the process of building XEmacs-21.1.8 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: Linux zion.ne.mediaone.net 2.2.13 #2 SMP Tue Oct 19 22:29:47 EDT 1999 i686 unknown ./configure '--prefix=/home/acs/cvsroot' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.1.8 "Bryce Canyon" configured for `i686-pc-linux'. Where should the build process find the source code? /home/acs/cvsroot/xemacs-21.1 What installation prefix should install use? /home/acs/cvsroot What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. From owner-xemacs-beta@xemacs.org Tue Nov 2 22:05:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA24036 for xemacs-beta-out; Tue, 2 Nov 1999 22:05:02 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA24029 for ; Tue, 2 Nov 1999 22:04:55 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id A4FCC472F; Tue, 2 Nov 1999 23:10:43 -0500 (EST) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) References: <199911012154.NAA01963@ptavv.es.net> From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 23:10:43 -0500 In-Reply-To: Vin Shelton's message of "02 Nov 1999 21:52:54 -0500" Message-ID: Lines: 43 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Well, I don't get it, but I finally managed to build an auto-autoloads.el file which included the autoload from xpm-button.el. I checked in that auto-autoload.el file. As you saw from the build bot message, 21.1.8 is in the process of being released. - vin >>>>> On 02 Nov 19990, Vin Shelton said: Vin> I believe the build scripts take care of rebuilding the autoloads. Vin> Just now I ran 'make autoloads', but it didn't change anything. Vin> ...and there is no mention of the string 'xpm' in any of the Vin> lisp/auto* files. Vin> OK. I built up a 21.1.7 without any packages, and xpm-button-create Vin> does not get defined until I load-library xpm-button. Vin> These lines appear in xpm-button.el: Vin> ;;;###autoload Vin> (defun xpm-button-create (text shadow-thickness fg-color bg-color) Vin> Meanwhile, in my package-less XEmacs, I can still use the toolbar (at Vin> least to cut text). What was the bug that I was trying to address by Vin> copying xpm-button.el to the lisp directory? Vin> I don't get it. Help! Vin> - vin >>>>> On 02 Nov 1999, Jan Vroonhof said: Jan> Vin Shelton writes: >>> /usr/local/xemacs-packages/lisp/xemacs-base/xpm-button hides >>> /usr/local/xemacs/lib/xemacs-21.1.7/lisp/xpm-button >>> >>> Am I missing something? Jan> Did you rebuild the autoloads? Jan> Jan From owner-xemacs-beta@xemacs.org Tue Nov 2 22:53:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA32743 for xemacs-beta-out; Tue, 2 Nov 1999 22:53:51 -0500 Received: from mharnois.workgroup.net (ps07alo.willinet.net [198.49.28.104]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA32712 for ; Tue, 2 Nov 1999 22:53:38 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian 8.9.3-6) id VAA09939; Tue, 2 Nov 1999 21:50:43 -0600 To: xemacs-beta@xemacs.org Subject: Re: menubar.c in current cvs doesn't like me References: <8766znf624.fsf@mharnois.workgroup.net> From: Michael Harnois Date: 02 Nov 1999 21:50:40 -0600 In-Reply-To: Michael Harnois's message of "31 Oct 1999 17:45:23 -0600" Message-ID: <87zowwxmgf.fsf@mharnois.workgroup.net> Lines: 30 User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 31 Oct 1999 17:45:23 -0600, Michael Harnois said: > /usr/src/xemacs-21.2/src/menubar.c:531: macro > `DEFVAR_SYMVAL_FWD_OBJECT' used with too many (55) args make[1]: > *** [menubar.o] Error 1 Am I really the only one seeing this? And if so, can someone please help me figure out why? I configured with "with menubars=none" and got past this error, but then hit this one: /usr/src/xemacs-21.2/src/file-coding.c:694: parse error at null character /usr/src/xemacs-21.2/src/file-coding.c: In function `Fmake_coding_system': /usr/src/xemacs-21.2/src/file-coding.c:866: number of arguments doesn't match prototype /usr/src/xemacs-21.2/src/file-coding.c:694: prototype declaration /usr/src/xemacs-21.2/src/file-coding.c:873: `type' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:873: (Each undeclared identifier is reported only once /usr/src/xemacs-21.2/src/file-coding.c:873: for each function it appears in.) /usr/src/xemacs-21.2/src/file-coding.c:890: `name' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:894: `doc_string' undeclared (first use in this function) /usr/src/xemacs-21.2/src/file-coding.c:900: `props' undeclared (first use in this function) make[1]: *** [file-coding.o] Error 1 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin From owner-xemacs-beta@xemacs.org Wed Nov 3 00:30:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA21212 for xemacs-beta-out; Wed, 3 Nov 1999 00:30:33 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id AAA21180 for ; Wed, 3 Nov 1999 00:30:25 -0500 Received: (qmail 1217 invoked by alias); 3 Nov 1999 05:30:22 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 1166 invoked by uid 0); 3 Nov 1999 05:30:20 -0000 Received: from dialupc94.tcsn.uswest.net (HELO 666.com) (209.180.115.94) by tcsnpop1.tcsn.uswest.net with SMTP; 3 Nov 1999 05:30:20 -0000 Message-ID: <381FC737.BB7C4327@666.com> Date: Tue, 02 Nov 1999 22:25:11 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: Jan Vroonhof , XEmacs beta list , XEmacs Patches List Subject: Re: Correct format for patch attachments References: <381ECE04.B423D895@666.com> <86g0ypnipx.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: A subprocess would be preferred. (Until someone writes a foreign-function interface so you can call arbitrary C functions from Lisp ...) "William M. Perry" wrote: > Jan Vroonhof writes: > > > Ben Wing writes: > > > > > So can we agree upon a standard, i.e. all patch attachments are MIME > > > type "text/plain"? > > > > We already agreed on that. However it doesn't really help. A lot of > > patches are submitted by "first time patchers" and those won't know > > that. The problem here is that the TM uses that type as a device for > > patches. So we cannot do much more than repeat this plea every now and > > again. > > > > The best solution would be to migrate you away from such a broken > > platform. IBM has released its viavoice dev kit for linux as beta, have > > you tried using something like kvoice? If it is anything close to > > sufficient would create XEmacs support for this. (Unfortunately it is > > unlikely that we will be able to release it to the general public). > > I actually did a bit of hacking with ViaVoice to get XEmacs to recognize > it. It wouldn't be that hard to do. I was debating whether to put it in > as part of the main XEmacs executable, or just write a generic program that > would run in a subprocess and have a process-filter on it that just > inserted the text. > > I didn't actually get any of it working before work starting beckoning > again (ah, to have more than a weekend to hack on things). > > My goal was going to be something like: > > (defun viavoice-mode (&optional arg) > "Toggle ViaVoice mode. > With arg, turn ViaVoice mode on if and only if arg is positive. > > When ViaVoice mode is enabled, voice recognition is performed. > All voice data is analyzed and put into the current buffer as > keystrokes." > ...) > > (defun viavoice-vocabulary-define-word () > "Define a word in the XEmacs vocabulary for voice recognition. > You will be prompted to say the word clearly, as well as type the > textual equivalent." > ...) > > (defun viavoice-vocabulary-remove-word () > "Remove a word from the XEmacs vocabulary for voice recognition." > ...) > > (defun viavoice-vocabulary-save () > "Save the currently loaded vocabulary" > ...) > > ViaVoice mode would basically boil down to turning the mic on and off by > the appropriate ViaVoice SDK functions. If anybody wants to hack on this, > I'd love to help as much as I can. > > I need to just take a month off from work. :( > > -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 3 01:15:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA29555 for xemacs-beta-out; Wed, 3 Nov 1999 01:15:37 -0500 Received: from max3p121.smart.net (max3p121.smart.net [216.84.81.121]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA29540 for ; Wed, 3 Nov 1999 01:15:33 -0500 Received: (from jmiller@localhost) by max3p121.smart.net (8.9.3/8.9.3) id CAA19976; Wed, 3 Nov 1999 02:26:36 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14367.58284.392297.791898@max3p121.smart.net.> Date: Wed, 3 Nov 1999 02:26:36 -0500 (EST) To: Michael Harnois Cc: xemacs-beta@xemacs.org Subject: Re: menubar.c in current cvs doesn't like me In-Reply-To: <87zowwxmgf.fsf@mharnois.workgroup.net> References: <8766znf624.fsf@mharnois.workgroup.net> <87zowwxmgf.fsf@mharnois.workgroup.net> X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "MH" == Michael Harnois writes: MH> On 31 Oct 1999 17:45:23 -0600, Michael Harnois said: >> /usr/src/xemacs-21.2/src/menubar.c:531: macro >> `DEFVAR_SYMVAL_FWD_OBJECT' used with too many (55) args make[1]: >> *** [menubar.o] Error 1 MH> Am I really the only one seeing this? And if so, can someone MH> please help me figure out why? MH> I configured with "with menubars=none" and got past this error, MH> but then hit this one: I just did a cvs update, and built a mule XEmacs, so I'm not seeing it. (redhat 6.1) have you applied any patches or anything odd? perhaps one of your .c or .h files was corrupted? a possible suggestion... occaasionally, I remove all the .c & .h files from, say, src or lib-src, so-on, prior to a cvs update, just to make sure everything is clean...... might be worth a shot. oh, have you you installed anything else recently? I vaguely recall that you often try out some of the bleeding edge stuff..... Jeff From owner-xemacs-beta@xemacs.org Wed Nov 3 02:10:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA06233 for xemacs-beta-out; Wed, 3 Nov 1999 02:10:06 -0500 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA17581 for xemacs-announce-out; Wed, 3 Nov 1999 00:08:44 -0500 To: xemacs-announce@xemacs.org Subject: XEmacs 21.1.8 "Bryce Canyon" Released From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 23:30:54 -0500 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: xemacs-beta@xemacs.org X-Mailing-List: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: XEmacs-21.1.8 "Bryce Canyon" is available from ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8-elc.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8-info.tar.gz A patch to upgrade from 21.1.7 is also available: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.7-21.1.8.patch.gz [The patch tarball only includes patches from xemacs-21.1.7.tar.gz to xemacs-21.1.8.tar.gz; you will still need to retrieve the elc and info tarballs.] XEmacs-21.1 is the stable branch of XEmacs. As such, only bugfix submissions are allowed into these releases. This release fixes a fairly large number of bugs; here are the relevant URLS: http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00023.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00025.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00028.html http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00065.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00016.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00030.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00007.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00033.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00034.html http://www.xemacs.org/list-archives/xemacs-patches/9904/msg00039.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00080.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00046.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00043.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00054.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00056.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00055.html http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00002.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00096.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00100.html http://www.xemacs.org/list-archives/xemacs-patches/9906/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00015.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00017.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00020.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00019.html The 21.1.x series of releases is being named for US National Parks. Bryce Canyon is a mind-blowing place located in southern Utah. For more information see: http://www.nps.gov/brca/. Vin Shelton From owner-xemacs-beta@xemacs.org Wed Nov 3 02:22:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA08043 for xemacs-beta-out; Wed, 3 Nov 1999 02:22:29 -0500 Received: from ro.ctd.comsat.com (ro.ctd.comsat.com [134.133.40.45]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA08037 for ; Wed, 3 Nov 1999 02:22:26 -0500 Received: from exim by ro.ctd.comsat.com with local (Exim 2.12 #8) id 11iukT-00005U-00 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 02:22:25 -0500 From: postmaster@ctd.comsat.com To: xemacs-beta@xemacs.org Subject: Invalid Account In-Reply-To: Message-Id: Date: Wed, 3 Nov 1999 02:22:25 -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: neal no longer works at COMSAT. Please remove neal@ctd.comsat.com from your mailing-list. Please contact postmaster@comsat.com if you require more information. ------ This is a copy of the message, including all the headers. ------ Received: from [207.96.122.8] (helo=gwyn.tux.org) by ro.ctd.comsat.com with esmtp (Exim 2.12 #8) id 11iukS-00005R-00 for neal@ctd.comsat.com; Wed, 3 Nov 1999 02:22:24 -0500 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA06233 for xemacs-beta-out; Wed, 3 Nov 1999 02:10:06 -0500 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA17581 for xemacs-announce-out; Wed, 3 Nov 1999 00:08:44 -0500 To: xemacs-announce@xemacs.org Subject: XEmacs 21.1.8 "Bryce Canyon" Released From: Vin Shelton Organization: The XEmacs Development Team Date: 02 Nov 1999 23:30:54 -0500 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: xemacs-beta@xemacs.org X-Mailing-List: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: XEmacs-21.1.8 "Bryce Canyon" is available from ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8-elc.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.8-info.tar.gz A patch to upgrade from 21.1.7 is also available: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.7-21.1.8.patch.gz [The patch tarball only includes patches from xemacs-21.1.7.tar.gz to xemacs-21.1.8.tar.gz; you will still need to retrieve the elc and info tarballs.] XEmacs-21.1 is the stable branch of XEmacs. As such, only bugfix submissions are allowed into these releases. This release fixes a fairly large number of bugs; here are the relevant URLS: http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00023.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00025.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00028.html http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00065.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00016.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00030.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00007.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00033.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00034.html http://www.xemacs.org/list-archives/xemacs-patches/9904/msg00039.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00080.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00046.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00043.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00054.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00056.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00055.html http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00002.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00096.html http://www.xemacs.org/list-archives/xemacs-patches/9909/msg00100.html http://www.xemacs.org/list-archives/xemacs-patches/9906/msg00031.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00015.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00017.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00020.html http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00019.html The 21.1.x series of releases is being named for US National Parks. Bryce Canyon is a mind-blowing place located in southern Utah. For more information see: http://www.nps.gov/brca/. Vin Shelton From owner-xemacs-beta@xemacs.org Wed Nov 3 03:23:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16232 for xemacs-beta-out; Wed, 3 Nov 1999 03:23:16 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA16222 for ; Wed, 3 Nov 1999 03:23:10 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id JAA01636 for ; Wed, 3 Nov 1999 09:23:08 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000PU; Wed Nov 3 09:23:04 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id JAA13518; Wed, 3 Nov 1999 09:23:04 +0100 To: xemacs-beta@xemacs.org Subject: Re: [comp.emacs.xemacs] Solaris 2.7 (was Re: Xemacs 21.1.7 for Linux -- all buttons are not defined!) References: <199911012154.NAA01963@ptavv.es.net> From: Jan Vroonhof Date: 03 Nov 1999 09:23:03 +0100 In-Reply-To: Vin Shelton's message of "02 Nov 1999 23:10:43 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin Shelton writes: > Vin> Meanwhile, in my package-less XEmacs, I can still use the toolbar (at > Vin> least to cut text). What was the bug that I was trying to address by > Vin> copying xpm-button.el to the lisp directory? xpm-button.el is used by gui.el, which is used to make the dialog box you get on the find-file button. Jan From owner-xemacs-beta@xemacs.org Wed Nov 3 04:36:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA18350 for xemacs-beta-out; Wed, 3 Nov 1999 04:36:30 -0500 Received: from rasp.eng.cam.ac.uk (rasp.eng.cam.ac.uk [129.169.8.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA18339 for ; Wed, 3 Nov 1999 04:36:20 -0500 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by rasp.eng.cam.ac.uk with ESMTP id JAA02439 for ; Wed, 3 Nov 1999 09:36:12 GMT Received: from kennet.eng.cam.ac.uk (via kennet [129.169.81.54]) by tigger.eng.cam.ac.uk with ESMTP id JAA08374 for ; Wed, 3 Nov 1999 09:36:09 GMT Received: (via ge204@localhost) by kennet.eng.cam.ac.uk id JAA18098; Wed, 3 Nov 1999 09:36:09 GMT To: XEmacs Developers Subject: Re: menubar.c in current cvs doesn't like me References: <8766znf624.fsf@mharnois.workgroup.net> <87zowwxmgf.fsf@mharnois.workgroup.net> <14367.58284.392297.791898@max3p121.smart.net.> From: Gunnar Evermann In-Reply-To: Jeff Miller's message of "Wed, 3 Nov 1999 02:26:36 -0500 (EST)" Date: 03 Nov 1999 09:36:08 +0000 Message-ID: Lines: 13 User-Agent: Gnus/5.070092 (Pterodactyl Gnus v0.92) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jeff Miller writes: > have you applied any patches or anything odd? perhaps one of your .c > or .h files was corrupted? > > a possible suggestion... occaasionally, I remove all the .c & .h > files from, say, src or lib-src, so-on, prior to a cvs update, just to > make sure everything is clean...... might be worth a shot. you can use 'cvs diff' to achieve the same. I do that quite often just to check that I removed all my old changes. Gunnar From owner-xemacs-beta@xemacs.org Wed Nov 3 06:47:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA20532 for xemacs-beta-out; Wed, 3 Nov 1999 06:47:40 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA20529 for ; Wed, 3 Nov 1999 06:47:39 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id GAA26519 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 06:47:37 -0500 Date: Wed, 3 Nov 1999 06:47:37 -0500 From: Olivier Galibert To: XEmacs beta Subject: fill-region-as-paragraph / mule / pdump / please help Message-ID: <19991103064737.A26428@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs beta Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm stumped. fill-region-as-paragraph works perfectly (afaik) when not using pdump or not using mule. Only pdump+mule is broken. While I can mostly follow the lisp code when featurep 'mule returns nil, I'm overweirded when the kinsoku junk comes into play. Could someone more knowledgeable about lisp point me to the subr/variable/whatever that does not behave the way it should so that I can trace the problem at the C level? OG. From owner-xemacs-beta@xemacs.org Wed Nov 3 06:54:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA20724 for xemacs-beta-out; Wed, 3 Nov 1999 06:54:59 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA20720 for ; Wed, 3 Nov 1999 06:54:58 -0500 Received: (qmail 31220 invoked from network); 3 Nov 1999 11:53:39 -0000 Received: from usrpri2-19.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.84) by biff.kiva.net with SMTP; 3 Nov 1999 11:53:39 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA04216; Wed, 3 Nov 1999 06:56:23 -0500 To: Ben Wing Cc: Jan Vroonhof , XEmacs beta list , XEmacs Patches List Subject: ViaVoice support (was Re: Correct format for patch attachments) X-Now-Listening-To: Metallica - So What References: <381ECE04.B423D895@666.com> <86g0ypnipx.fsf@megalith.bp.aventail.com> <381FC737.BB7C4327@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > A subprocess would be preferred. (Until someone writes a foreign-function > interface so you can call arbitrary C functions from Lisp ...) Well, the reason I didn't start writing it as a module is that it is going to hook into the Xt or unixoid event loops, since you can get a file descriptor that gets tickled whenever new data is available. This is done with the 'SmNexternalNotifier' attribute in the SmArg list sent to SmOpen(). I was planning on just throwing this into the event loop. I'm not sure if we can currently do this from the module API or not. The route I would take with a subprocess is to use (make-event ...) with data from the subprocess. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 3 06:59:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA20851 for xemacs-beta-out; Wed, 3 Nov 1999 06:59:11 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA20844 for ; Wed, 3 Nov 1999 06:59:08 -0500 Received: (qmail 735 invoked from network); 3 Nov 1999 11:57:51 -0000 Received: from usrpri2-19.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.84) by biff.kiva.net with SMTP; 3 Nov 1999 11:57:51 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id HAA04234; Wed, 3 Nov 1999 07:00:35 -0500 To: xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: patch for portable dumper w/o debug X-Now-Listening-To: Metallica - The Prince Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 27 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Since debug.o is not linked unless you compile with debugging info, reinit_vars_of_debug() is undefined. This fixes it for me. I know I know, debug symbols good for portable dumper, but I configured that way by mistake and turned this up. :) -Bill P. Index: emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.31 diff -c -w -r1.82.2.31 emacs.c *** emacs.c 1999/10/30 19:57:32 1.82.2.31 --- emacs.c 1999/11/03 11:56:21 *************** *** 1662,1668 **** --- 1662,1670 ---- reinit_vars_of_buffer (); reinit_vars_of_console (); + #ifdef DEBUG_XEMACS reinit_vars_of_debug (); + #endif reinit_vars_of_device (); reinit_vars_of_eval (); #ifdef HAVE_X_WINDOWS From owner-xemacs-beta@xemacs.org Wed Nov 3 09:11:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA24056 for xemacs-beta-out; Wed, 3 Nov 1999 09:11:12 -0500 Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA24053 for ; Wed, 3 Nov 1999 09:11:10 -0500 Received: from informatik.uni-tuebingen.de (brabantio.Informatik.Uni-Tuebingen.De [134.2.12.25]) by macon.informatik.uni-tuebingen.de (8.9.3/8.9.1) with ESMTP id PAA16146 for ; Wed, 3 Nov 1999 15:11:07 +0100 Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id PAA30936; Wed, 3 Nov 1999 15:11:04 +0100 To: xemacs-beta@xemacs.org Subject: Stupid question: How to get Backspace working in TTY mode? Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 03 Nov 1999 15:11:03 +0100 Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id JAA24054 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I really felt stupid when someone asked me how to make Backspace delete backwards in TTY mode, and I didn't know. This seems to be FAQ material, but isn't in the FAQ. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Nov 3 10:36:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27246 for xemacs-beta-out; Wed, 3 Nov 1999 10:36:22 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27242 for ; Wed, 3 Nov 1999 10:36:19 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id QAA13459; Wed, 3 Nov 1999 16:36:14 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id QAA30733; Wed, 3 Nov 1999 16:36:13 +0100 Date: Wed, 3 Nov 1999 16:36:13 +0100 From: Stef Epardaud To: "Michael Sperber [Mr. Preprocessor]" Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? Message-ID: <19991103163613.A30455@tanglefoot.lunatech.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Michael Sperber [Mr. Preprocessor] on Wed, Nov 03, 1999 at 03:11:03PM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: xemacs -nw -vanilla ? it does it for me without any special config. but all control+arrow key don't work, so i would appreciate also a hint for this :) On Wed, Nov 03, 1999 at 03:11:03PM +0100, Michael Sperber [Mr. Preprocessor] wrote: > > I really felt stupid when someone asked me how to make Backspace > delete backwards in TTY mode, and I didn't know. This seems to be FAQ > material, but isn't in the FAQ. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Wed Nov 3 11:48:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA29835 for xemacs-beta-out; Wed, 3 Nov 1999 11:48:14 -0500 Received: from ns.jsys.co.jp (ns.jsys.co.jp [202.33.240.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA29831 for ; Wed, 3 Nov 1999 11:48:04 -0500 Received: from cosmos.jsys.co.jp (cosmos.jsys.co.jp [172.31.80.5]) by ns.jsys.co.jp (8.9.3/8.9.3) with ESMTP id BAA23247; Thu, 4 Nov 1999 01:47:49 +0900 (JST) Received: from skywalk.jsys.co.jp (skywalk.jsys.co.jp [172.31.49.72]) by cosmos.jsys.co.jp (8.9.3/8.9.3/NOTES) with ESMTP id BAA29622; Thu, 4 Nov 1999 01:47:48 +0900 (JST) Received: (from ienaga@localhost) by skywalk.jsys.co.jp (8.9.3/3.7W) id BAA13009; Thu, 4 Nov 1999 01:48:52 +0900 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: MIME-Version: 1.0 (generated by WEMI 1.13.5 - "Fijieda") Content-Type: text/plain; charset=US-ASCII From: Kazuyuki IENAGA Date: 04 Nov 1999 01:48:52 +0900 In-Reply-To: (Michael Sperber [Mr. Preprocessor]'s message of "03 Nov 1999 15:11:03 +0100") Message-ID: Lines: 20 User-Agent: T-gnus/6.13.1 (based on Pterodactyl Gnus v0.96) (revision 01) X-Face: 8USaCFc~lusX>!w&WSKn|Y>{Xn3WCwoV[9?YtJcat&+&H{7'`-2#q,@WbK$2h?^E~KEcxb2 ccau$twWn%fCVrpm7`eA sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > I really felt stupid when someone asked me how to make Backspace > delete backwards in TTY mode, and I didn't know. This seems to be FAQ > material, but isn't in the FAQ. You could just do "stty erase ^H", instead of using "Delete" for erase. You'd lose Backspace for help-command prefix but you could use f1. You might have to check if f1 was correctly registered in terminfo or termcap database. For terminfo database, you could use infocmp command to show what characters are expected for f1 key. You also could type "C-v f1" on the tty to check that what characters f1 key exactly produces. Make sense? -- kazz From owner-xemacs-beta@xemacs.org Wed Nov 3 11:52:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA30072 for xemacs-beta-out; Wed, 3 Nov 1999 11:52:46 -0500 Received: from faerie.whatever.org (BNice-1-2-91.abo.wanadoo.fr [193.250.211.91]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA30057 for ; Wed, 3 Nov 1999 11:52:38 -0500 Received: (from stephane@localhost) by faerie.whatever.org (8.9.3/8.9.3/Debian/GNU) id RAA04881 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 17:52:35 +0100 Date: Wed, 3 Nov 1999 17:52:34 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Subject: compiler warnings mess Message-ID: <19991103175234.A4872@faerie.whatever.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: hi, i decided to rebuild on cvs today, and although it did build, the compilation gave me loads of warnings, and since i was really bored, i took a look at them. while i fixed (what i call 'fix' ... ;) some of them and produce some patches, the dozens others remain and i cannot fix them because i don;'t understand them, they seem plain wrong. those i could fix were some with unused variables (forgotten somehow) and some with using ints before initialization that i explicitly set to 0, and some chars used as integers casting problem. but sometimes it just complains about ints used before initialization and even setting them to any value does not fix the warning, sometimes the initialization is a macro in the declaration and although it _is_ initialized, it just does not get it. to me it seems broken or i gave it a wrong option (and it is by default because i did not give any option) and in the end i even wondered if my 10-20 warnings fix were valid because the ones remaining seemd unjustified. what should i do, or is it normal to get dozens of : window.c: In function `window_loop': window.c:2409: warning: `w' might be used uninitialized in this function window.c:2411: warning: `next_window' might be used uninitialized in this function window.c:2412: warning: `last_window' might be used uninitialized in this function window.c:2413: warning: `frame' might be used uninitialized in this function window.c:2420: warning: `devcons' might be used uninitialized in this function window.c:2420: warning: `concons' might be used uninitialized in this function window.c:2443: warning: `obj' might be used uninitialized in this function window.c:2445: warning: `obj' might be used uninitialized in this function window.c:2477: warning: `obj' might be used uninitialized in this function window.c:2478: warning: `obj' might be used uninitialized in this function window.c:2551: warning: `obj' might be used uninitialized in this function window.c:2571: warning: `obj' might be used uninitialized in this function window.c:2647: warning: `obj' might be used uninitialized in this function window.c:2688: warning: `obj' might be used uninitialized in this function (example) in a lot of files ? thanx for making me smarter by answering :) -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Rotterdam # Lunatech Research, # NETHERLANDS # soon we will drop the searching for the finding... # # From owner-xemacs-beta@xemacs.org Wed Nov 3 13:10:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA00306 for xemacs-beta-out; Wed, 3 Nov 1999 13:10:57 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA32767; Wed, 3 Nov 1999 13:10:52 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA05341; Wed, 3 Nov 1999 19:10:42 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001JO; Wed Nov 3 19:10:32 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA14859; Wed, 3 Nov 1999 19:10:32 +0100 To: wmperry@aventail.com Cc: Ben Wing , XEmacs beta list , XEmacs Patches List Subject: Re: ViaVoice support (was Re: Correct format for patch attachments) References: <381ECE04.B423D895@666.com> <86g0ypnipx.fsf@megalith.bp.aventail.com> <381FC737.BB7C4327@666.com> <864sf34wm0.fsf_-_@megalith.bp.aventail.com> From: Jan Vroonhof Date: 03 Nov 1999 19:10:31 +0100 In-Reply-To: wmperry@aventail.com's message of "03 Nov 1999 06:56:23 -0500" Message-ID: Lines: 9 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > SmOpen(). I was planning on just throwing this into the event loop. I'm > not sure if we can currently do this from the module API or not. I cannot think why not. Note that the tooltalk stuff which really should be a module already does things on the lines of what you want. Jan From owner-xemacs-beta@xemacs.org Wed Nov 3 13:19:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA00574 for xemacs-beta-out; Wed, 3 Nov 1999 13:19:26 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA00559 for ; Wed, 3 Nov 1999 13:19:15 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA05443 for ; Wed, 3 Nov 1999 19:19:12 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001L1; Wed Nov 3 19:19:10 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA14861; Wed, 3 Nov 1999 19:19:10 +0100 To: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess References: <19991103175234.A4872@faerie.whatever.org> From: Jan Vroonhof Date: 03 Nov 1999 19:19:09 +0100 In-Reply-To: Stef Epardaud's message of "Wed, 3 Nov 1999 17:52:34 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stef Epardaud writes: > and in the end i even wondered if my 10-20 warnings fix were valid > because the ones remaining seemd unjustified. > what should i do, or is it normal to get dozens of : > window.c: In function `window_loop': > window.c:2409: warning: `w' might be used uninitialized in this function > window.c:2411: warning: `next_window' might be used uninitialized in > this function Are you using egcs 1.1 ? It has a known bug that causes it to warn far too much. Jan From owner-xemacs-beta@xemacs.org Wed Nov 3 14:07:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA02598 for xemacs-beta-out; Wed, 3 Nov 1999 14:07:00 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA02595 for ; Wed, 3 Nov 1999 14:06:58 -0500 Received: (qmail 18573 invoked from network); 3 Nov 1999 19:05:41 -0000 Received: from usrpri2-23.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.88) by biff.kiva.net with SMTP; 3 Nov 1999 19:05:41 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA05165; Wed, 3 Nov 1999 14:08:25 -0500 To: Jan Vroonhof Cc: Ben Wing , XEmacs beta list , XEmacs Patches List Subject: Re: ViaVoice support (was Re: Correct format for patch attachments) X-Now-Listening-To: Metallica - Sabbra Cadabra References: <381ECE04.B423D895@666.com> <86g0ypnipx.fsf@megalith.bp.aventail.com> <381FC737.BB7C4327@666.com> <864sf34wm0.fsf_-_@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > SmOpen(). I was planning on just throwing this into the event loop. I'm > > not sure if we can currently do this from the module API or not. > > I cannot think why not. Note that the tooltalk stuff which really > should be a module already does things on the lines of what you want. Hmmm... interesting. So when you connect_to_file_descriptor(), the data doesn't actually get _read_ if you have a process filter set up? Would it make sense to make the GPM code do this as well then? Would definitely make it cleaner, and the GPM code could become a module, as could the speech stuff. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 3 14:09:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA02703 for xemacs-beta-out; Wed, 3 Nov 1999 14:09:22 -0500 Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA02695 for ; Wed, 3 Nov 1999 14:09:18 -0500 Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta4/8.10.0.Beta4) with ESMTP id dA3J8wf25192; Wed, 3 Nov 1999 14:08:58 -0500 Message-Id: <199911031908.dA3J8wf25192@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: Stef Epardaud Cc: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess In-Reply-To: Your message of "Wed, 03 Nov 1999 17:52:34 +0100." <19991103175234.A4872@faerie.whatever.org> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_802952918P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 03 Nov 1999 14:08:57 -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Exmh_802952918P Content-Type: text/plain; charset=us-ascii On Wed, 03 Nov 1999 17:52:34 +0100, Stef Epardaud said: > window.c:2409: warning: `w' might be used uninitialized in this function At least for the IBM xlc compiler, you can get these quite easily. The usual cause is code similar to this: int foo, bar; struct baz *quux; while(frobozz(quux) { if (quux->myflag) bar = quux->value; quux = quux->next; } foo = bar; This will draw a message on 'bar'. Even though *YOU* know that the while loop *will* find a value of quux->myflag that's true and therefor set 'bar' (because frobozz will call assert if it doesn't find one ;), the compiler doesn't know that - it just sees that you CAN drop out of the while without ever setting 'bar'. The compiler can't know what the rest of your program will actually do at run time. It's impossible to 100% fix this and eliminate all erroneous warnings, as that's basically the Turing Halting Problem... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_802952918P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBOCCISdQBOOoptg9JAQE0JAP/Y5kUJuLiVKV0lgHAaebAJdhSKLGj1hw7 K7QjZhF1uLBJelBI2d9uN1zwiwGU2YjMGAJ8H+jjOzQxsZBlpSXBvBkJih4K6Yzs a28+CgokokHntlxOpMTuN6s4H6V4ENKxXLXWOoanx5AqR5TKsk/3AmaM+rSqMAyJ lvOmjOthOXQ= =6Z88 -----END PGP MESSAGE----- --==_Exmh_802952918P-- From owner-xemacs-beta@xemacs.org Wed Nov 3 14:16:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA02976 for xemacs-beta-out; Wed, 3 Nov 1999 14:16:27 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA02973 for ; Wed, 3 Nov 1999 14:16:25 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id LAA08267 for ; Wed, 3 Nov 1999 11:16:01 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-94.beasys.com [192.168.11.94]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id TAA26334 for ; Wed, 3 Nov 1999 19:16:38 GMT Message-Id: <3.0.5.32.19991103191715.009c8d80@london.beasys.com> X-Sender: andyp@london.beasys.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Nov 1999 19:17:15 +0000 To: xemacs-beta@xemacs.org From: Andy Piper Subject: pdump and const Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I notice the pdump stuff uses const static structures a lot. Shouldn't these be CONST? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Wed Nov 3 14:17:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA03056 for xemacs-beta-out; Wed, 3 Nov 1999 14:17:59 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA03048 for ; Wed, 3 Nov 1999 14:17:56 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id UAA15588 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 20:17:54 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11j5sZ-0007gS-00 for xemacs-beta@xemacs.org; Wed, 03 Nov 1999 20:15:31 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 714971871; Wed, 3 Nov 1999 20:15:30 +0100 (CET) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess References: <19991103175234.A4872@faerie.whatever.org> From: Andreas Jaeger Date: 03 Nov 1999 20:15:30 +0100 In-Reply-To: Stef Epardaud's message of "Wed, 3 Nov 1999 17:52:34 +0100" Message-ID: Lines: 21 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Stef Epardaud writes: > hi, > i decided to rebuild on cvs today, and although it did build, the > compilation gave me loads of warnings, and since i was really bored, i > took a look at them. > while i fixed (what i call 'fix' ... ;) some of them and produce some > patches, the dozens others remain and i cannot fix them because i don;'t > understand them, they seem plain wrong. > those i could fix were some with unused variables (forgotten somehow) gcc isn't very good in diagnosing if a variable is really used unitialized or not. Too often the warning is wrong. That's a known 'feature' of gcc:-(. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Wed Nov 3 14:37:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA04002 for xemacs-beta-out; Wed, 3 Nov 1999 14:37:06 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA03995; Wed, 3 Nov 1999 14:37:02 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA07105; Wed, 3 Nov 1999 20:36:56 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001iq; Wed Nov 3 20:36:46 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA14944; Wed, 3 Nov 1999 20:36:46 +0100 To: wmperry@aventail.com Cc: Ben Wing , XEmacs beta list , XEmacs Patches List Subject: Re: ViaVoice support (was Re: Correct format for patch attachments) References: <381ECE04.B423D895@666.com> <86g0ypnipx.fsf@megalith.bp.aventail.com> <381FC737.BB7C4327@666.com> <864sf34wm0.fsf_-_@megalith.bp.aventail.com> <8666zj1jh3.fsf@megalith From: Jan Vroonhof Date: 03 Nov 1999 20:36:45 +0100 In-Reply-To: wmperry@aventail.com's message of "03 Nov 1999 14:08:24 -0500" Message-ID: Lines: 13 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Hmmm... interesting. So when you connect_to_file_descriptor(), the data > doesn't actually get _read_ if you have a process filter set up? Would it > make sense to make the GPM code do this as well then? Maybe. The only thing is that then you don't get the console association. That is probably wrong anyway because the GPM library uses only one file descriptor to catch events for all Linux VT's and these are different consoles (they really shouldn't be but there is no way we can figure that out). Jan From owner-xemacs-beta@xemacs.org Wed Nov 3 15:08:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA04862 for xemacs-beta-out; Wed, 3 Nov 1999 15:08:57 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA04856 for ; Wed, 3 Nov 1999 15:08:48 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id VAA19281 for ; Wed, 3 Nov 1999 21:08:44 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id VAA16953 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 21:08:44 +0100 Date: Wed, 3 Nov 1999 21:08:44 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess Message-ID: <19991103210844.A16879@tanglefoot.lunatech.com> References: <19991103175234.A4872@faerie.whatever.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Jan Vroonhof on Wed, Nov 03, 1999 at 07:19:09PM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 03, 1999 at 07:19:09PM +0100, Jan Vroonhof wrote: > > Are you using egcs 1.1 ? It has a known bug that causes it to warn far > too much. > > Jan labyrinth stephane 18:31 ...src/xemacs > gcc --version egcs-2.91.66 that's not 1.1, right? well it sure does warn for too much. only a few ten are fixable, and i have patches, should i send them to xemacs-patches, or is it my compiler's fault ? -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Wed Nov 3 15:41:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05998 for xemacs-beta-out; Wed, 3 Nov 1999 15:41:13 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA05995 for ; Wed, 3 Nov 1999 15:41:10 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA07773 for ; Wed, 3 Nov 1999 21:41:08 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001tL; Wed Nov 3 21:41:00 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA14963; Wed, 3 Nov 1999 21:41:00 +0100 To: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess References: <19991103175234.A4872@faerie.whatever.org> <19991103210844.A16879@tanglefoot.lunatech.com> From: Jan Vroonhof Date: 03 Nov 1999 21:41:00 +0100 In-Reply-To: Stef Epardaud's message of "Wed, 3 Nov 1999 21:08:44 +0100" Message-ID: Lines: 20 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stef Epardaud writes: > labyrinth stephane 18:31 ...src/xemacs > gcc --version > egcs-2.91.66 > > that's not 1.1, right? I don't know. What I do know is that gcc 2.95 compiles 21.1.7 with almost no warnings at all and so does the Solaris compiler. As to which things to change and what not. Use your own judgement. If you get the feeling that you are only trying to work around the compiler being stupid then don't. If the code wasn't clear and the change has zero or almost no cost then do. However, Martin compiles XEmacs with a C++ compiler from time to time and then fixes all the warnings for that (a C++ compiler is allowed to me much more picky). Jan From owner-xemacs-beta@xemacs.org Wed Nov 3 16:40:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA08845 for xemacs-beta-out; Wed, 3 Nov 1999 16:40:46 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id QAA08839 for ; Wed, 3 Nov 1999 16:40:43 -0500 Received: (qmail 25889 invoked from network); 3 Nov 1999 21:39:27 -0000 Received: from usrpri2-20.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.85) by biff.kiva.net with SMTP; 3 Nov 1999 21:39:27 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id QAA05822; Wed, 3 Nov 1999 16:42:17 -0500 To: xemacs-beta@xemacs.org Subject: Is it ok to call CONSOLE_HAS_METHOD() after initialization? X-Now-Listening-To: Insane Clown Posse - Hokus Pokus Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: If we want to make the GPM code into a module, we'd have to move the following code out of frame-tty.c, and into gpmevent.c #ifdef HAVE_GPM CONSOLE_HAS_METHOD (tty, get_mouse_position); CONSOLE_HAS_METHOD (tty, set_mouse_position); #endif Also, I don't see a clean way to do this from device-tty.c: This is from tty_asynch_device_change(): #ifdef HAVE_GPM /* We need to tell GPM how big our screen is now ** I am pretty sure the GPM library will get incredibly confused ** if you try to connect to more than one mouse-capable device, ** so I don't think it will cause any more damage in that case. */ gpm_mx = width; gpm_my = height; #endif -bp From owner-xemacs-beta@xemacs.org Wed Nov 3 17:14:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA11694 for xemacs-beta-out; Wed, 3 Nov 1999 17:14:18 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA11685; Wed, 3 Nov 1999 17:14:06 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id RAA13348; Wed, 3 Nov 1999 17:21:01 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-3.ecf.teradyne.com [131.101.192.123]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id XAA01481; Wed, 3 Nov 1999 23:13:47 +0100 (MET) To: Andy Piper Cc: acs@xemacs.org, aichner@ecf.teradyne.com, Mike Alexander , XEmacs NT List , xemacs-beta@xemacs.org Subject: Re: "Forked child base mismatch" using MKS Toolkit shell References: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 03 Nov 1999 23:10:59 +0100 In-Reply-To: Andy Piper's message of "Tue, 02 Nov 1999 10:07:51 +0000" Message-ID: Lines: 31 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> Vin, I think this one should go in although it hasn't been Andy> sent to xemacs-patches. However, there maybe some wierd Andy> interaction with Adrian's process patch that should be Andy> checked. Adrian, does your patch include this? Have you Andy> tried this patch with yours? I tried looking at this problem. I have MKS Source Integrity installed but can't find a korn shell in there. Is the MKS Toolkit a separate product? If so, I can't debug this. If it's part of MKS SI, please point me to the executable which I haven't been able to find. Thanks, Adrian Andy> andy Andy> At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >> A few weeks ago I sent a message to the list asking if anyone >> knew what was causing the MKS Toolkit Korn shell to fail when >> used with the XEmacs shell command. If you recall any attempt >> to invoke a sub shell produced the message "Forked child base >> mismatch" and pipes didn't work (they appeared to cause the >> shell to hang). I think I've fixed both problems and the shell >> seems to be working ok now. From owner-xemacs-beta@xemacs.org Wed Nov 3 17:39:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA12759 for xemacs-beta-out; Wed, 3 Nov 1999 17:39:49 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA12756; Wed, 3 Nov 1999 17:39:45 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id XAA22257; Wed, 3 Nov 1999 23:39:41 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id XAA26100; Wed, 3 Nov 1999 23:39:41 +0100 Date: Wed, 3 Nov 1999 23:39:41 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Cc: xemacs-patches@xemacs.org Subject: Re: compiler warnings patch Message-ID: <19991103233941.A25339@tanglefoot.lunatech.com> References: <19991103175234.A4872@faerie.whatever.org> <19991103210844.A16879@tanglefoot.lunatech.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=NzB8fVQJ5HfG6fxh X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Jan Vroonhof on Wed, Nov 03, 1999 at 09:41:00PM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii On Wed, Nov 03, 1999 at 09:41:00PM +0100, Jan Vroonhof wrote: > Stef Epardaud writes: > > > labyrinth stephane 18:31 ...src/xemacs > gcc --version > > egcs-2.91.66 > > > > that's not 1.1, right? > > I don't know. What I do know is that gcc 2.95 compiles 21.1.7 with > almost no warnings at all and so does the Solaris compiler. you are right, i just upgraded to 2.95 and all the weird ones (almost) dissapeared. just the ones i could fix (i think...not sure if it didn't break them instead?) remained and i could still fix them. those are the ones that remain: /opt/src/xemacs/lib-src/hexl.c: In function `main': /opt/src/xemacs/lib-src/hexl.c:150: warning: `c' might be used uninitialized in this function /opt/src/xemacs/lib-src/hexl.c:197: warning: `c' might be used uninitialized in this function eval.c: In function `Feval': eval.c:2850: warning: `val' might be used uninitialized in this function eval.c: In function `Ffuncall': eval.c:3116: warning: `val' might be used uninitialized in this function window.c: In function `Fset_window_configuration': window.c:4952: warning: `previous_minibuf_top' might be used uninitialized in this function and here are my patches, if they are wrong or doing bad things, someone tell me because iam building on it :) thanx for the answers, i am very happy to have a compiler that behaves on warnings now :) (sent this both to answer xemacs-beta and to patches, hope it's alright) :-/ -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patches.warn2" diff -u -r1.22 etags.c --- etags.c 1998/05/24 05:40:19 1.22 +++ etags.c 1999/11/03 17:24:54 @@ -1846,7 +1846,7 @@ 54, 10, 26, 137, 24, 42, 30, 18, 46, 137, 137, 137, 137, 137, 137, 137, 137, 137, }; - return len + asso_values[str[2]] + asso_values[str[0]]; + return len + asso_values[(int)str[2]] + asso_values[(int)str[0]]; } struct C_stab_entry * diff -u -r1.8.2.1 gnuserv.c --- gnuserv.c 1998/12/05 16:54:24 1.8.2.1 +++ gnuserv.c 1999/11/03 17:27:35 @@ -323,7 +323,7 @@ char buf[GSERV_BUFSZ+1]; int offset=0; int s; - int len; + int len=0; int result_len; /* read in "n/m:" (n=client fd, m=message length) */ diff -u -r1.2 ootags.c --- ootags.c 1998/05/18 05:42:06 1.2 +++ ootags.c 1999/11/03 17:20:11 @@ -1909,7 +1909,7 @@ 10, 62, 59, 130, 28, 27, 50, 19, 3, 130, 130, 130, 130, 130, 130, 130, 130, 130, }; - return len + asso_values[str[2]] + asso_values[str[0]]; + return len + asso_values[(int)str[2]] + asso_values[(int)str[0]]; } struct C_stab_entry * diff -u -r1.13.2.6 mule-ccl.c --- mule-ccl.c 1999/09/23 07:40:07 1.13.2.6 +++ mule-ccl.c 1999/11/03 17:05:00 @@ -760,7 +760,7 @@ int i, j, op; int stack_idx = ccl->stack_idx; /* Instruction counter of the current CCL code. */ - int this_ic; + int this_ic = 0; if (ic >= ccl->eof_ic) ic = CCL_HEADER_MAIN; diff -u -r1.1.2.13 xlwtabs.c --- xlwtabs.c 1999/10/21 14:29:47 1.1.2.13 +++ xlwtabs.c 1999/11/03 22:35:36 @@ -645,8 +645,9 @@ */ if( tw->tabs.topWidget != curtw->tabs.topWidget ) + { if( XtIsRealized(tw->tabs.topWidget) ) - { + { Widget w = tw->tabs.topWidget ; TabsConstraints tab = (TabsConstraints) w->core.constraints ; @@ -663,6 +664,7 @@ } else tw->tabs.needs_layout = True ; + } return needRedraw ; } @@ -813,7 +815,7 @@ if (req->request_mode & (CWWidth | CWHeight | CWBorderWidth)) { Dimension rw,rh ; /* child's requested width, height */ - Dimension cw,ch ; /* children's preferred size */ + Dimension cw=0,ch=0 ; /* children's preferred size */ Dimension aw,ah ; /* available size we can give child */ Dimension th ; /* space used by tabs */ Dimension wid,hgt ; /* Tabs widget size */ @@ -1057,10 +1059,10 @@ TabsPage(Widget w, XEvent *event, String *params, Cardinal *num_params) { TabsWidget tw = (TabsWidget) w ; - Widget newtop ; + Widget newtop = NULL ; Widget *childP ; int idx ; - int i ; +/* int i ; */ int nc = tw->composite.num_children ; if( nc <= 0 ) @@ -1121,10 +1123,10 @@ TabsHighlight(Widget w, XEvent *event, String *params, Cardinal *num_params) { TabsWidget tw = (TabsWidget) w ; - Widget newhl ; + Widget newhl = NULL; Widget *childP ; int idx ; - int i ; +/* int i ; */ int nc = tw->composite.num_children ; if( nc <= 0 ) @@ -1271,8 +1273,8 @@ XawTabsSetHighlight(Widget t, Widget w) { TabsWidget tw = (TabsWidget)t ; - TabsConstraints tab ; - Widget oldtop = tw->tabs.topWidget ; +/* TabsConstraints tab ; */ +/* Widget oldtop = tw->tabs.topWidget ; */ if( !XtIsSubclass(t, tabsWidgetClass) ) return ; --NzB8fVQJ5HfG6fxh-- From owner-xemacs-beta@xemacs.org Wed Nov 3 18:40:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA15153 for xemacs-beta-out; Wed, 3 Nov 1999 18:40:47 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA15148 for ; Wed, 3 Nov 1999 18:40:44 -0500 Received: (qmail 23760 invoked from network); 3 Nov 1999 23:39:25 -0000 Received: from usrpri2-16.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.81) by biff.kiva.net with SMTP; 3 Nov 1999 23:39:25 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id SAA12641; Wed, 3 Nov 1999 18:42:15 -0500 To: xemacs-beta@xemacs.org Subject: rewriting GPM support... Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 42 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Well, I have a halfway working version of the GPM code using connect_to_file_descriptor() - it gets and reads events. And you can turn gpm-mode on and off and have it do the right thing. The only problem is that I am using Fdispatch_event() after creating an event and filling in the structures. Like this: ----- fake_event = Fmake_event (Qnil, Qnil); event = XEVENT(fake_event); event->timestamp = 0; event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ if (ev.modifiers & 1) modifiers |= MOD_SHIFT; if (ev.modifiers & 2) modifiers |= MOD_META; if (ev.modifiers & 4) modifiers |= MOD_CONTROL; if (ev.modifiers & 8) modifiers |= MOD_META; [...] /* Handle the event */ Fdispatch_event (fake_event); Fdeallocate_event (fake_event); GPM_DRAWPOINTER(&ev); return (Qzero); ----- For one thing, you never really get to see the GPM pointer except for a lot of flickering, I think because redisplay happens immediately after the 'process output' is handled. Also, I get all sorts of weird errors like: (3) (error/warning) Error in process filter: (error Selection aborted) (4) (error/warning) Error in process filter: (wrong-type-argument integerp #) I think the selection aborted is because of the process events getting there when it thinks a mouse button is depressed, but I don't know for sure. Any ideas? -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 3 19:13:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA16683 for xemacs-beta-out; Wed, 3 Nov 1999 19:13:11 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA16680 for ; Wed, 3 Nov 1999 19:13:09 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id TAA32208 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 19:13:06 -0500 Date: Wed, 3 Nov 1999 19:13:06 -0500 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? Message-ID: <19991103191306.C32122@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <86r9i7w8uf.fsf@megalith.bp.aventail.com>; from William M. Perry on Wed, Nov 03, 1999 at 04:42:16PM -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 03, 1999 at 04:42:16PM -0500, William M. Perry wrote: > If we want to make the GPM code into a module, we'd have to move the > following code out of frame-tty.c, and into gpmevent.c None of the two dumpers care. OG. From owner-xemacs-beta@xemacs.org Wed Nov 3 19:15:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA16843 for xemacs-beta-out; Wed, 3 Nov 1999 19:15:52 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA16837 for ; Wed, 3 Nov 1999 19:15:50 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id TAA32220 for xemacs-beta@xemacs.org; Wed, 3 Nov 1999 19:15:49 -0500 Date: Wed, 3 Nov 1999 19:15:49 -0500 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: pdump and const Message-ID: <19991103191549.D32122@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: <3.0.5.32.19991103191715.009c8d80@london.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <3.0.5.32.19991103191715.009c8d80@london.beasys.com>; from Andy Piper on Wed, Nov 03, 1999 at 07:17:15PM +0000 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 03, 1999 at 07:17:15PM +0000, Andy Piper wrote: > I notice the pdump stuff uses const static structures a lot. Shouldn't > these be CONST? Not sure. "const" is required in ISO C. What does CONST mean? OG. From owner-xemacs-beta@xemacs.org Wed Nov 3 19:57:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA18724 for xemacs-beta-out; Wed, 3 Nov 1999 19:57:03 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA18720 for ; Wed, 3 Nov 1999 19:57:01 -0500 Received: by crystal.WonderWorks.COM id QQhnup07914; Wed, 3 Nov 1999 16:56:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14368.55769.964435.802650@crystal.WonderWorks.COM> Date: Wed, 3 Nov 1999 16:56:57 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: pdump and const In-Reply-To: <19991103191549.D32122@nemesis.ncsl.nist.gov> References: <3.0.5.32.19991103191715.009c8d80@london.beasys.com> <19991103191549.D32122@nemesis.ncsl.nist.gov> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Olivier Galibert writes: > On Wed, Nov 03, 1999 at 07:17:15PM +0000, Andy Piper wrote: > > I notice the pdump stuff uses const static structures a lot. Shouldn't > > these be CONST? > > Not sure. "const" is required in ISO C. What does CONST mean? I think CONST_IS_LOSING was instituted back in the Lucid Emacs days by Jamie, because compiles would fail in unfixable ways if you attempted to use const. I no longer remember the details. We should try turning off CONST_IS_LOSING in the next beta and see if we can make it work. ANSI/ISO C implementations were pretty new back when CONST_IS_LOSING was put in; const may be fit to use across all the major platforms now. From owner-xemacs-beta@xemacs.org Wed Nov 3 20:02:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA19019 for xemacs-beta-out; Wed, 3 Nov 1999 20:02:17 -0500 Received: from pm1.contactor.se (gw.contactor.se [193.15.23.130]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA19011 for ; Wed, 3 Nov 1999 20:02:09 -0500 Received: from sid.contactor.se (IDENT:matsl@dhcp117.contactor.se [193.15.23.117]) by pm1.contactor.se (8.9.3/8.9.1) with SMTP id CAA25832; Thu, 4 Nov 1999 02:10:09 +0100 (MET) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Building xemacs-packages from the top. Possible? References: From: Mats Lidell Date: 04 Nov 1999 02:06:38 +0100 In-Reply-To: Jan Vroonhof's message of "02 Nov 1999 19:47:10 +0100" Message-ID: Lines: 26 User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) XEmacs/21.0 (Irish Goat) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Jan wrote: Jan> You are supposed to be able to just type "make" in the toplevel directory. OK. Maybe it is the fact that I haven't build xemacs with mule support that is the problem. When I do a simple make I get the following problem in mule-base. (And trying to compile things there seems to be a bad idea if no mule support is available. Right!?) make[2]: Entering directory `/usr/local/src/xemacs-packages/mule/mule-base' /usr/local/src/xemacs/src/xemacs -vanilla -batch \ -eval "(setq autoload-package-name \"mule-base\")" \ -l autoload -f batch-update-directory . Updating autoloads in directory /usr/local/src/xemacs-packages/mule/mule-base...Generating autoloads for mule-base/_pkg.el... No autoloads found in mule-base/canna.el Generating autoloads for mule-base/char-table.el... Unbalanced parentheses xemacs exiting. make[2]: *** [auto-autoloads.el] Error 255 Well I removed the mule directory from SUBDIRS in the top Makefile and things started to compile. ;-) I guess I'm on my way. Yours -- %% Mats From owner-xemacs-beta@xemacs.org Wed Nov 3 20:11:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA19453 for xemacs-beta-out; Wed, 3 Nov 1999 20:11:13 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA19449 for ; Wed, 3 Nov 1999 20:11:11 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id RAA16060; Wed, 3 Nov 1999 17:11:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14368.56618.326991.179243@lasker.666.com> Date: Wed, 3 Nov 1999 17:11:06 -0800 (PST) From: Martin Buchholz To: Olivier Galibert Cc: xemacs-beta@xemacs.org Subject: Re: pdump and const In-Reply-To: <19991103191549.D32122@nemesis.ncsl.nist.gov> References: <3.0.5.32.19991103191715.009c8d80@london.beasys.com> <19991103191549.D32122@nemesis.ncsl.nist.gov> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "OG" == Olivier Galibert writes: OG> On Wed, Nov 03, 1999 at 07:17:15PM +0000, Andy Piper wrote: >> I notice the pdump stuff uses const static structures a lot. Shouldn't >> these be CONST? OG> Not sure. "const" is required in ISO C. What does CONST mean? CONST is just a macro for const. It has been a plan of mine for a while to globally replace CONST with const everywhere. For now, consider yourself permitted to write ANSI C code using plain `const'. Martin From owner-xemacs-beta@xemacs.org Wed Nov 3 20:55:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA21392 for xemacs-beta-out; Wed, 3 Nov 1999 20:55:53 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA21388 for ; Wed, 3 Nov 1999 20:55:50 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id KAA13697; Thu, 4 Nov 1999 10:54:06 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Thu_Nov__4_10:54:05_1999-1" Content-Transfer-Encoding: 7bit Date: 04 Nov 1999 10:54:05 +0900 Message-ID: Lines: 120 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Thu_Nov__4_10:54:05_1999-1 Content-Type: text/plain; charset=US-ASCII Does someone want to take a look at this? --Multipart_Thu_Nov__4_10:54:05_1999-1 Content-Type: message/rfc822 X-From-Line: yusufg@outblaze.com Tue Nov 2 19:42:37 1999 Return-Path: Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by mule.m17n.org (8.9.2/3.7W-19990512194415) with ESMTP id TAA15416 for ; Tue, 2 Nov 1999 19:42:37 +0900 (JST) Received: from tsukuba.m17n.org (root@tsukuba.m17n.org [192.47.44.130]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with SMTP id TAA09643 for ; Tue, 2 Nov 1999 19:42:35 +0900 (JST) Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by tsukuba.m17n.org (8.9.3/3.7W-19990729182150) with ESMTP id TAA10695 for ; Tue, 2 Nov 1999 19:42:29 +0900 (JST) Received: from ns1.portal2.com (ns1.portal2.com [203.85.226.193]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id FAA06690 for ; Tue, 2 Nov 1999 05:42:14 -0500 Received: (qmail 35821 invoked from network); 2 Nov 1999 10:40:42 -0000 Received: from yusufg.portal2.com (qmailr@203.85.226.249) by ns1.portal2.com with SMTP; 2 Nov 1999 10:40:42 -0000 Received: (qmail 2607 invoked by uid 500); 2 Nov 1999 10:41:24 -0000 Date: Tue, 2 Nov 1999 18:41:24 +0800 From: Yusuf Goolamabbas To: steve@xemacs.org Subject: [dgaudet@arctic.org: faster malloc for multithreaded programs] Message-ID: <19991102184124.A2602@outblaze.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" X-Mailer: Mutt 1.0pre3i Lines: 80 Xref: miho.m17n.org inbox:1320 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Steve, Would this be useful for XEmacs ? Cheers, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com --opJtzjQTFsWo+cga Content-Type: message/rfc822 Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 4472 invoked by uid 6000); 1 Nov 1999 16:07:04 -0000 Received: (qmail 4445 invoked from network); 1 Nov 1999 16:07:02 -0000 Received: from twinlark.arctic.org (204.107.140.52) by taz.hyperreal.org with SMTP; 1 Nov 1999 16:07:02 -0000 Received: (qmail 4324 invoked by uid 500); 1 Nov 1999 16:06:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Nov 1999 16:06:57 -0000 Date: Mon, 1 Nov 1999 08:06:56 -0800 (PST) From: Dean Gaudet To: new-httpd@apache.org Subject: faster malloc for multithreaded programs Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org ---------- Forwarded message ---------- From: "Emery Berger" Subject: Hoard 1.2 - malloc/free replacement: 30% faster + SPROC support Date: Sun, 31 Oct 1999 08:43:23 GMT =====BEGIN PGP SIGNED MESSAGE===== Hoard is a fast, scalable, and memory-efficient replacement for malloc/free for multiprocessors. The newest release (1.2) incorporates a user-level lock implementation (for x86, SPARC, and SGI's) that improves performance by about 30%. This makes Hoard faster than the Linux allocator in glibc2, even on just one processor (it's always been faster for multiple processors). This version also includes an "sproc" version for SGI's. - -- Emery - -- This article has been digitally signed by the moderator, using PGP. http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature. Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov PLEASE remember a short description of the software and the LOCATION. This group is archived at http://www.iki.fi/mjr/linux/cola.html =====BEGIN PGP SIGNATURE===== Version: 2.6.3i Charset: latin1 iQCVAgUBOBwBK1rUI/eHXJZ5AQEZSwP+NIHRg6rYfV6/cOQINI2XHLaf1OHGkUrD O4G/dLskZE5Lwju3S1n/o9TeMdLq8MdsUj3okzGkfDABTOuQyI6YO5k5pbEzyaEO gdl3PeKGET9wSOEoPPGKJzijWRKGYZp1w1TGvTlLok5UIbTbcz848VRvEf8VY0dK XG0yudOLRJY= =na4D =====END PGP SIGNATURE===== --opJtzjQTFsWo+cga-- --Multipart_Thu_Nov__4_10:54:05_1999-1-- From owner-xemacs-beta@xemacs.org Wed Nov 3 21:05:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA21767 for xemacs-beta-out; Wed, 3 Nov 1999 21:05:42 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id VAA21757 for ; Wed, 3 Nov 1999 21:05:38 -0500 Received: (qmail 25986 invoked by alias); 4 Nov 1999 01:26:58 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 19571 invoked by uid 0); 4 Nov 1999 00:38:30 -0000 Received: from dialupa227.tcsn.uswest.net (HELO 666.com) (209.180.113.227) by tcsnpop1.tcsn.uswest.net with SMTP; 4 Nov 1999 00:38:30 -0000 Message-ID: <3820D56F.F738099B@666.com> Date: Wed, 03 Nov 1999 17:38:08 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs beta list Subject: [Fwd: Xemacs in AIX 4.2 (fwd)] Content-Type: multipart/mixed; boundary="------------13D87591E0CC0CE28813D664" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a multi-part message in MIME format. --------------13D87591E0CC0CE28813D664 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------13D87591E0CC0CE28813D664 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: lhelmbrecht@ifm.uni-kiel.de Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id FAA17130 for <666-ben@pplus.shell5.ba.best.com>; Wed, 3 Nov 1999 05:11:10 -0800 (PST) Received: from nms.rz.uni-kiel.de (nms.rz.uni-kiel.de [134.245.1.2]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with SMTP id FAA28518 for ; Wed, 3 Nov 1999 05:11:03 -0800 (PST) Received: from xerxes.ifm.uni-kiel.de by nms.rz.uni-kiel.de with Local-SMTP (PP); Wed, 3 Nov 1999 14:10:34 +0100 Received: by xerxes.ifm.uni-kiel.de; id AA22037; Wed, 3 Nov 1999 14:10:29 +0100 Date: Wed, 3 Nov 1999 14:10:29 +0100 (MET) From: lutz helmbrecht To: wing@666.com Subject: Xemacs in AIX 4.2 (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mozilla-Status2: 00000000 Tschuess Lutz ---------- Forwarded message ---------- Date: Wed, 3 Nov 1999 14:06:39 +0100 (MET) From: lutz helmbrecht To: arossini@stat.sc.edu Subject: Xemacs in AIX 4.2 Hi ! I'm just trying to run a Xemacs on an IBM RISC 6000. I took the xemacs-21.1.3-rs6000-ibm-aix4.2.1.0.tar.gz archive from the binary_kit FTP site extracted ..... So far everything seems to run - except one thing: If I press the open button in the toolbar I get the error: "Symbol's function definition is void: xpm-button-create" (The error appears whenever Xemacs tries to open the little dialog window) What could be the problem ? Is there a solution ? Tanks, Lutz --------------13D87591E0CC0CE28813D664-- From owner-xemacs-beta@xemacs.org Wed Nov 3 23:44:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA26922 for xemacs-beta-out; Wed, 3 Nov 1999 23:44:38 -0500 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA26863; Wed, 3 Nov 1999 23:42:37 -0500 Message-Id: <4.2.1.19991103233925.00bff280@mailhost.arbortext.com> X-Sender: mta@mailhost.arbortext.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 03 Nov 1999 23:43:56 -0500 To: Adrian Aichner , Andy Piper From: Mike Alexander Subject: Re: "Forked child base mismatch" using MKS Toolkit shell Cc: acs@xemacs.org, aichner@ecf.teradyne.com, XEmacs NT List , xemacs-beta@xemacs.org In-Reply-To: References: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: MKS Toolkit is a separate product. Part of it is also included in Microsoft's poorly named "Services for Unix" which adds some Unix compatibility to NT. See for more information about that. I thought that all or part of SFU was available for free, but I can't find it so perhaps I'm remembering wrong or it has changed. Several people have tried MKS Toolkit shell with this patch and found that it works fine, so I don't think that is the issue right now. A more interesting question is whether the patch interacts badly with your process patch. I looked at what you did and it looks like they should be ok together, and independent of each other, but I haven't actually tried them together. Mike Alexander At 05:10 PM 11/3/99 , Adrian Aichner wrote: > >>>>> "Andy" == Andy Piper writes: > > Andy> Vin, I think this one should go in although it hasn't been > Andy> sent to xemacs-patches. However, there maybe some wierd > Andy> interaction with Adrian's process patch that should be > Andy> checked. Adrian, does your patch include this? Have you > Andy> tried this patch with yours? > >I tried looking at this problem. I have MKS Source Integrity >installed but can't find a korn shell in there. > >Is the MKS Toolkit a separate product? If so, I can't debug this. > >If it's part of MKS SI, please point me to the executable which I >haven't been able to find. > >Thanks, > >Adrian > > Andy> andy > > Andy> At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: > > >> A few weeks ago I sent a message to the list asking if anyone > >> knew what was causing the MKS Toolkit Korn shell to fail when > >> used with the XEmacs shell command. If you recall any attempt > >> to invoke a sub shell produced the message "Forked child base > >> mismatch" and pipes didn't work (they appeared to cause the > >> shell to hang). I think I've fixed both problems and the shell > >> seems to be working ok now. From owner-xemacs-beta@xemacs.org Wed Nov 3 23:44:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA26940 for xemacs-beta-out; Wed, 3 Nov 1999 23:44:51 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id XAA26937 for ; Wed, 3 Nov 1999 23:44:50 -0500 Received: (qmail 23307 invoked from network); 4 Nov 1999 04:43:34 -0000 Received: from usrpri2-27.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.92) by biff.kiva.net with SMTP; 4 Nov 1999 04:43:34 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id XAA15117; Wed, 3 Nov 1999 23:46:24 -0500 To: Olivier Galibert Cc: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 12 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Olivier Galibert writes: > On Wed, Nov 03, 1999 at 04:42:16PM -0500, William M. Perry wrote: > > If we want to make the GPM code into a module, we'd have to move the > > following code out of frame-tty.c, and into gpmevent.c > > None of the two dumpers care. And it actually seems to work. Unfortunately there is no CONSOLE_NO_LONGER_HAS_METHOD(...) macro to go with it. :) -Bill P. From owner-xemacs-beta@xemacs.org Thu Nov 4 00:12:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA28538 for xemacs-beta-out; Thu, 4 Nov 1999 00:12:41 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA28530 for ; Thu, 4 Nov 1999 00:12:37 -0500 Received: by localhost id m11jFCN-00015aC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 4 Nov 1999 14:12:35 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.5571.420089.132460@turnbull.sk.tsukuba.ac.jp> Date: Thu, 4 Nov 1999 14:12:35 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: Ethiopic in 21.1.7++ In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Vin Shelton writes: >> Symbol's function definition is void: >> setup-ethiopic-environment-internal >> >> I'd like to get this working before I release 21.1.8 (tonight, >> I hope). Can anyone offer a patch? This looks like the same thing that was happening with Japanese and some other languages. The FSF changed the language environemnt API, and that got ported to a couple of language environments but not the rest. :-( Jan> I tried making the obvious path (namely copying Jan> 'setup-ethiopic-environment-internal from an old mule base Jan> into the core), however then I stopped. auto-autoloads.el Jan> from mule-base contains Ethiopic is one of the things that got ported from FSF and ignored, I think disabling it is the best route until somebody is willing to take a good look at it. That is my suggestion for any non-ISO-8859, non-Asian-ideographic language that breaks, unfortunately. I think a real solution to this, one that is robust to ++patchlevel, even, will have to wait until we define real APIs for Mule and convince porters from FSF to stick to them. You can always write Tomohiko Morioka , and ask him. He did most or all of those ports. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 4 00:53:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA30622 for xemacs-beta-out; Thu, 4 Nov 1999 00:53:38 -0500 Received: from prosper.leonora.org (leonora.org [24.142.59.46]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA30615; Thu, 4 Nov 1999 00:53:29 -0500 Received: from prosper.leonora.org (IDENT:vladimir@localhost [127.0.0.1]) by prosper.leonora.org (8.9.3/8.9.3) with ESMTP id VAA05209; Wed, 3 Nov 1999 21:58:25 -0800 Message-Id: <199911040558.VAA05209@prosper.leonora.org> To: Mike Alexander cc: Adrian Aichner , Andy Piper , acs@xemacs.org, XEmacs NT List , xemacs-beta@xemacs.org Subject: Re: "Forked child base mismatch" using MKS Toolkit shell In-reply-to: Message from Mike Alexander of "Wed, 03 Nov 1999 23:43:56 EST." <4.2.1.19991103233925.00bff280@mailhost.arbortext.com> Date: Wed, 03 Nov 1999 21:58:25 -0800 From: Vladimir Ivanovic Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: There is a beta available for Services For Unix which is free. Microsoft might have taken it off the site in preparation for FCS. -- Vladimir Vladimir G. Ivanovic http://www.leonora.org/~vladimir 2770 Cowper St. vladimir@acm.org Palo Alto, CA 94306-2447 +1 650 787 2514 "MA" == Mike Alexander writes: MA> MKS Toolkit is a separate product. Part of it is also included in MA> Microsoft's poorly named "Services for Unix" which adds some Unix MA> compatibility to NT. See MA> MA> for more information about that. I thought that all or part of SFU was MA> available for free, but I can't find it so perhaps I'm remembering wrong or MA> it has changed. MA> Several people have tried MKS Toolkit shell with this patch and found that MA> it works fine, so I don't think that is the issue right now. A more MA> interesting question is whether the patch interacts badly with your process MA> patch. I looked at what you did and it looks like they should be ok MA> together, and independent of each other, but I haven't actually tried them MA> together. MA> Mike Alexander MA> At 05:10 PM 11/3/99 , Adrian Aichner wrote: >> >>>>> "Andy" == Andy Piper writes: >> Andy> Vin, I think this one should go in although it hasn't been Andy> sent to xemacs-patches. However, there maybe some wierd Andy> interaction with Adrian's process patch that should be Andy> checked. Adrian, does your patch include this? Have you Andy> tried this patch with yours? >> >> I tried looking at this problem. I have MKS Source Integrity >> installed but can't find a korn shell in there. >> >> Is the MKS Toolkit a separate product? If so, I can't debug this. >> >> If it's part of MKS SI, please point me to the executable which I >> haven't been able to find. >> >> Thanks, >> >> Adrian >> Andy> andy >> Andy> At 12:44 AM 10/20/99 -0400, Mike Alexander wrote: >> >> >> A few weeks ago I sent a message to the list asking if anyone >> >> knew what was causing the MKS Toolkit Korn shell to fail when >> >> used with the XEmacs shell command. If you recall any attempt >> >> to invoke a sub shell produced the message "Forked child base >> >> mismatch" and pipes didn't work (they appeared to cause the >> >> shell to hang). I think I've fixed both problems and the shell >> >> seems to be working ok now. From owner-xemacs-beta@xemacs.org Thu Nov 4 01:07:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA31293 for xemacs-beta-out; Thu, 4 Nov 1999 01:07:53 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA31282 for ; Thu, 4 Nov 1999 01:07:45 -0500 Received: from localhost.localdomain (dialup14ip032.tus.azstarnet.com [169.197.36.160]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id XAA22954; Wed, 3 Nov 1999 23:07:38 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ To: Sean Murphy Cc: xemacs-beta@xemacs.org Subject: Re: Missing hm--html-menus package References: Organization: geneHackCorps X-URL: X-Attribution: jsja From: john s jacobs anderson Date: 03 Nov 1999 23:07:13 -0700 In-Reply-To: Sean Murphy's message of "Wed, 3 Nov 1999 10:56:00 +0000 (GMT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Sean: I'm not sure what the basis of your problem is. I've Cc'd the beta list on this message, and someone there might have a solution. If you don't hear anything from them, I would suggest raising this question in the comp.emacs.xemacs newsgroup. Good luck, john. >>>>> "Sean" == Sean Murphy writes: Sean> Hi, [not sure who to send this to - thought you'd at least know Sean> who could handle it] Sean> I use Xemacs 21.1.4. I wanted to add a html editor to my Sean> installation so I used the (excellent) package management Sean> mode. I obtained the list of current packages from my closest Sean> xemacs mirror (doc.ic.ac.uk) and found that hm--html-menus will Sean> probably do the job. However, when I tried to download this Sean> package, xemacs spewed out an error stating that the package Sean> could not be found. I tried using a couple of other sites for Sean> download, but each of them gave the same response. Sean> So I looked into how this download mechanism works - looked up Sean> /pub/xemacs/packages on the xemacs.org server and found that Sean> there is no hm--html-menus package there. Then I had a look at Sean> the packages-index.LATEST file, and found that the Sean> hm--html-menus package is listed there. So I guess that there's Sean> an inconsistency between the files on the server and the index Sean> file. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ You'll have to pry my Emacs from my cold \ jacobs@xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz From owner-xemacs-beta@xemacs.org Thu Nov 4 02:12:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA01498 for xemacs-beta-out; Thu, 4 Nov 1999 02:12:31 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA01494 for ; Thu, 4 Nov 1999 02:12:28 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id IAA09708 for xemacs-beta@xemacs.org; Thu, 4 Nov 1999 08:12:26 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11jGol-0000Wv-00 for xemacs-beta@xemacs.org; Thu, 04 Nov 1999 07:56:19 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 09B011871; Thu, 4 Nov 1999 07:56:18 +0100 (CET) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] References: From: Andreas Jaeger Date: 04 Nov 1999 07:56:18 +0100 In-Reply-To: SL Baur's message of "04 Nov 1999 10:54:05 +0900" Message-ID: Lines: 27 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> SL Baur writes: sb> Does someone want to take a look at this? sb> From: Yusuf Goolamabbas sb> Subject: [dgaudet@arctic.org: faster malloc for multithreaded programs] sb> To: steve@xemacs.org sb> X-Sent: 1 day, 20 hours, 10 minutes, 2 seconds ago sb> Steve, Would this be useful for XEmacs ? sb> Cheers, Yusuf I've read the paper on Hoard which also compares Doug Lea's malloc implementation as used in glibc with Hoard. Their results indicate that Hoard is faster but also uses more memory. I don't have a comparison of features between Hoard and the glibc implementation. Before switching somebody should run a number of real tests with XEmacs - on different platforms. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Thu Nov 4 03:20:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA04286 for xemacs-beta-out; Thu, 4 Nov 1999 03:20:31 -0500 Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA04281 for ; Thu, 4 Nov 1999 03:20:29 -0500 Received: from informatik.uni-tuebingen.de (brabantio.Informatik.Uni-Tuebingen.De [134.2.12.25]) by macon.informatik.uni-tuebingen.de (8.9.3/8.9.1) with ESMTP id JAA18372 for ; Thu, 4 Nov 1999 09:20:23 +0100 Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA19260; Thu, 4 Nov 1999 09:20:21 +0100 To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 04 Nov 1999 09:20:20 +0100 In-Reply-To: Kazuyuki IENAGA's message of "04 Nov 1999 01:48:52 +0900" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA04282 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "kazz" == Kazuyuki IENAGA writes: kazz> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> I really felt stupid when someone asked me how to make Backspace >> delete backwards in TTY mode, and I didn't know. This seems to be FAQ >> material, but isn't in the FAQ. kazz> You could just do "stty erase ^H", instead of using "Delete" for kazz> erase. kazz> You'd lose Backspace for help-command prefix but you could use f1. Sure, F1 works. But I don't really want to globally use ^H for erase. Why can't I rebind the damn key in XEmacs? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Nov 4 03:21:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA04360 for xemacs-beta-out; Thu, 4 Nov 1999 03:21:55 -0500 Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA04355 for ; Thu, 4 Nov 1999 03:21:53 -0500 Received: from informatik.uni-tuebingen.de (brabantio.Informatik.Uni-Tuebingen.De [134.2.12.25]) by macon.informatik.uni-tuebingen.de (8.9.3/8.9.1) with ESMTP id JAA19404 for ; Thu, 4 Nov 1999 09:21:48 +0100 Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA29036; Thu, 4 Nov 1999 09:21:47 +0100 To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: <19991103163613.A30455@tanglefoot.lunatech.com> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 04 Nov 1999 09:21:46 +0100 In-Reply-To: Stef Epardaud's message of "Wed, 3 Nov 1999 16:36:13 +0100" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA04358 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Stef" == Stef Epardaud writes: Stef> xemacs -nw -vanilla ? Stef> it does it for me without any special config. Not for me, at least not for 21.1.3 inside an XEmacs. I have this vague feeling it used to work, but I don't know when or in what version. Stef> On Wed, Nov 03, 1999 at 03:11:03PM +0100, Michael Sperber [Mr. Preprocessor] wrote: >> >> I really felt stupid when someone asked me how to make Backspace >> delete backwards in TTY mode, and I didn't know. This seems to be FAQ >> material, but isn't in the FAQ. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Nov 4 03:46:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA05699 for xemacs-beta-out; Thu, 4 Nov 1999 03:46:32 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA05694; Thu, 4 Nov 1999 03:46:29 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id AAA16792; Thu, 4 Nov 1999 00:46:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.18398.863185.115614@lasker.666.com> Date: Thu, 4 Nov 1999 00:46:22 -0800 (PST) From: Martin Buchholz To: Stef Epardaud Cc: xemacs-beta@xemacs.org, XEmacs Review Subject: Re: compiler warnings mess In-Reply-To: <19991103175234.A4872@faerie.whatever.org> References: <19991103175234.A4872@faerie.whatever.org> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello, Stef. I am the one who usually does the warning removal in XEmacs. It seems that you have examined the warnings in 21.1.7. I do not think we should try to fix those warnings, UNLESS YOU FIND A GENUINE BUG, but instead concentrate on fixing warnings in 21.2. The reason for this is that: - warning fixes to 21.1 will not make it to 21.2 and so will be dead-end. - we are trying for stability in 21.1, and so only true bug fixes should go into 21.1. - the biggest reason for removing compiler warnings is so that developers will run the compiler with maximal warnings turned on, BUT developers are mostly using 21.2, so warning fixes for 21.1 will be relatively wasted effort. Currently, the warnings we get in the src directory in 21.2 are as follows: (martin@lasker) ~/x/build/mo9/src $ rm *.o; make >/dev/null /hack/import/gcc-2.95.2/inst/linux-libc2/bin/gcc -c -mcpu=pentiumpro -march=pentiumpro -O3 -Wall -Wpointer-arith -Winline -Wmissing-prototypes -Wmissing-declarations -Wunused -Wformat -Wno-switch -Wno-sign-compare -Wshadow ... /home/martin/x/ws/dev/src/eval.c: In function `Feval': /home/martin/x/ws/dev/src/eval.c:2850: warning: `val' might be used uninitialized in this function /home/martin/x/ws/dev/src/eval.c: In function `Ffuncall': /home/martin/x/ws/dev/src/eval.c:3116: warning: `val' might be used uninitialized in this function /home/martin/x/ws/dev/src/mule-ccl.c: In function `ccl_driver': /home/martin/x/ws/dev/src/mule-ccl.c:763: warning: `this_ic' might be used uninitialized in this function In file included from /home/martin/x/ws/dev/src/glyphs-eimage.c:66: /usr/include/png.h:1270: warning: declaration of `error' shadows global declaration /usr/include/png.h:1274: warning: declaration of `error' shadows global declaration /usr/include/png.h:1278: warning: declaration of `message' shadows global declaration /usr/include/png.h:1282: warning: declaration of `message' shadows global declaration /home/martin/x/ws/dev/src/gui.c:254: warning: no previous prototype for `gui_add_item_keywords_to_plist' /home/martin/x/ws/dev/src/redisplay-output.c: In function `redisplay_output_layout': /home/martin/x/ws/dev/src/redisplay-output.c:1205: warning: declaration of `frame_changed' shadows global declaration /home/martin/x/ws/dev/src/window.c: In function `Fset_window_configuration': /home/martin/x/ws/dev/src/window.c:4952: warning: `previous_minibuf_top' might be used uninitialized in this function The ``might be used uninitialized'' warnings are gcc bugs. We could ``fix'' those by initializing automatic variables, and in fact I have done a lot of that in the past. But in the case of Feval and Ffuncall, it might make those very heavily used functions slower, and warning removal is just not worth it. The png.h warnings cannot be removed by us, and they are also gcc bugs. Andy has the job of fixing the gui_add_item_keywords_to_plist warning. The other warnings should be investigated for possible removal. The source code not maintained by us, for example etags.c, generates many warnings, but cannot be fixed without taking on new maintenance burdens. So, I guess I....errr... veto pure warning removal patches for 21.1, but might accept them for 21.2 (but not to eval.c or etags.c). Martin From owner-xemacs-beta@xemacs.org Thu Nov 4 04:57:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA08703 for xemacs-beta-out; Thu, 4 Nov 1999 04:57:57 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA08693; Thu, 4 Nov 1999 04:57:51 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id FAA17214; Thu, 4 Nov 1999 05:04:39 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id KAA26824; Thu, 4 Nov 1999 10:57:26 +0100 (MET) To: Mike Alexander Cc: Adrian Aichner , Andy Piper , acs@xemacs.org, XEmacs NT List , xemacs-beta@xemacs.org Subject: Re: "Forked child base mismatch" using MKS Toolkit shell References: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> <4.2.1.19991103233925.00bff280@mailhost.arbortext.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 04 Nov 1999 10:54:23 +0100 In-Reply-To: Mike Alexander's message of "Wed, 03 Nov 1999 23:43:56 -0500" Message-ID: Lines: 22 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Mike" == Mike Alexander writes: Mike> Several people have tried MKS Toolkit shell with this patch Mike> and found that it works fine, so I don't think that is the Mike> issue right now. A more interesting question is whether the Mike> patch interacts badly with your process patch. I looked at Mike> what you did and it looks like they should be ok together, Mike> and independent of each other, but I haven't actually tried Mike> them together. Hello Mike, please do if you can, now that XEmacs-21.1.8 (including my call-process patch) is available. Let me know if you find problems with my patch. Regards, Adrian Mike> Mike Alexander From owner-xemacs-beta@xemacs.org Thu Nov 4 05:14:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA09549 for xemacs-beta-out; Thu, 4 Nov 1999 05:14:25 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA09540; Thu, 4 Nov 1999 05:14:20 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA29378; Thu, 4 Nov 1999 11:14:12 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa007B0; Thu Nov 4 11:14:03 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15376; Thu, 4 Nov 1999 11:14:02 +0100 To: martin@xemacs.org Cc: Stef Epardaud , xemacs-beta@xemacs.org, XEmacs Review Subject: Re: compiler warnings mess References: <19991103175234.A4872@faerie.whatever.org> <14369.18398.863185.115614@lasker.666.com> From: Jan Vroonhof Date: 04 Nov 1999 11:14:02 +0100 In-Reply-To: Martin Buchholz's message of "Thu, 4 Nov 1999 00:46:22 -0800 (PST)" Message-ID: Lines: 13 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > It seems that you have examined the warnings in 21.1.7. His patch has a xlwtabs in it, seems to be for 21.2. > Currently, the warnings we get in the src directory in 21.2 are as > follows: Yes, but he fixes stuff in the other directories. That is important too. (if you do a full make you see those too). Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 05:23:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA09876 for xemacs-beta-out; Thu, 4 Nov 1999 05:23:17 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA09868; Thu, 4 Nov 1999 05:23:14 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA29532; Thu, 4 Nov 1999 11:23:13 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa007DQ; Thu Nov 4 11:23:09 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15378; Thu, 4 Nov 1999 11:23:09 +0100 To: Stef Epardaud Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: compiler warnings patch References: <19991103175234.A4872@faerie.whatever.org> <19991103210844.A16879@tanglefoot.lunatech.com> <19991103233941.A25339@tanglefoot.lunatech.com> From: Jan Vroonhof Date: 04 Nov 1999 11:23:08 +0100 In-Reply-To: Stef Epardaud's message of "Wed, 3 Nov 1999 23:39:41 +0100" Message-ID: Lines: 21 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stef Epardaud writes: > - return len + asso_values[str[2]] + asso_values[str[0]]; > + return len + asso_values[(int)str[2]] + asso_values[(int)str[0]]; > } This one is correct. > - int len; > + int len=0; > int result_len; > > /* read in "n/m:" (n=client fd, m=message length) */ This is just the compiler being stupid. If you want to fix better it much better to rewrite the read-in loop to be more clear, using a do { } while or a for loop. I didn't look at the rest yet. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 05:27:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA09938 for xemacs-beta-out; Thu, 4 Nov 1999 05:27:04 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA09935 for ; Thu, 4 Nov 1999 05:27:01 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id LAA01604 for ; Thu, 4 Nov 1999 11:26:58 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id LAA22768 for xemacs-beta@xemacs.org; Thu, 4 Nov 1999 11:26:57 +0100 Date: Thu, 4 Nov 1999 11:26:57 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess Message-ID: <19991104112657.A22485@tanglefoot.lunatech.com> References: <19991103175234.A4872@faerie.whatever.org> <14369.18398.863185.115614@lasker.666.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Jan Vroonhof on Thu, Nov 04, 1999 at 11:14:02AM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Thu, Nov 04, 1999 at 11:14:02AM +0100, Jan Vroonhof wrote: > Martin Buchholz writes: > > > It seems that you have examined the warnings in 21.1.7. > > His patch has a xlwtabs in it, seems to be for 21.2. yes, so far i am updating from cvs for 21.2 and i get a 21.2 when i compile :-/ what makes you think it was for 21.1 ? i mean... i am not a guru in C like you guys are, abd yes i do mistakes and i am clumbsy in my mails, ... but i really think it is 21.2 ;) or the world is plotting against me and i am in the matrix, they try to make me think it is the latest, but in fact it is only a version maintained by computers to keep me in line ! ;) > > > Currently, the warnings we get in the src directory in 21.2 are as > > follows: > > Yes, but he fixes stuff in the other directories. That is important > too. (if you do a full make you see those too). > basicly it is very small stuff and some things commented in xlwtabs because probably the code is under devel and some variables are declared but not initialized yet, but it does get rid of ten of the 15 total warnings i get when compiling XEmacs 21.2 from scratch. > Jan -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Thu Nov 4 05:30:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA10096 for xemacs-beta-out; Thu, 4 Nov 1999 05:30:51 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA10090 for ; Thu, 4 Nov 1999 05:30:48 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id LAA01772; Thu, 4 Nov 1999 11:30:44 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id LAA22997; Thu, 4 Nov 1999 11:30:44 +0100 Date: Thu, 4 Nov 1999 11:30:44 +0100 From: Stef Epardaud To: "Michael Sperber [Mr. Preprocessor]" Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? Message-ID: <19991104113044.A22788@tanglefoot.lunatech.com> References: <19991103163613.A30455@tanglefoot.lunatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Michael Sperber [Mr. Preprocessor] on Thu, Nov 04, 1999 at 09:21:46AM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Thu, Nov 04, 1999 at 09:21:46AM +0100, Michael Sperber [Mr. Preprocessor] wrote: > >>>>> "Stef" == Stef Epardaud writes: > > Stef> xemacs -nw -vanilla ? > Stef> it does it for me without any special config. > > Not for me, at least not for 21.1.3 inside an XEmacs. I have this > vague feeling it used to work, but I don't know when or in what > version. > if you want to tracke versions, mine is 21.2.19 . > Stef> On Wed, Nov 03, 1999 at 03:11:03PM +0100, Michael Sperber [Mr. Preprocessor] wrote: > >> > >> I really felt stupid when someone asked me how to make Backspace > >> delete backwards in TTY mode, and I didn't know. This seems to be FAQ > >> material, but isn't in the FAQ. > > > > > -- > Cheers =8-} Chipsy > Friede, Völkerverständigung und überhaupt blabla -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Thu Nov 4 05:37:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA10232 for xemacs-beta-out; Thu, 4 Nov 1999 05:37:58 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA10228 for ; Thu, 4 Nov 1999 05:37:55 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA29792 for ; Thu, 4 Nov 1999 11:37:54 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa007HL; Thu Nov 4 11:37:48 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15383; Thu, 4 Nov 1999 11:37:48 +0100 To: xemacs-beta@xemacs.org Subject: Re: Large lisp chars and big XEmacs buffers References: <19991027162400.B343@nemesis.ncsl.nist.gov> <3817C64A.E78366DF@666.com> <19991028035922.A2136@nemesis.ncsl.nist.gov> <38196718.E875D524@666.com> <19991029182217.B19557@nemesis.ncsl.nist.gov> <14362.37496.905536.411227@turnbull.sk.tsukuba.ac.jp From: Jan Vroonhof Date: 04 Nov 1999 11:37:48 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 4 Nov 1999 18:03:14 +0900 (JST)" Message-ID: Lines: 16 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Jan> But surely diff would have an > Jan> --ignore-unicode-composing-differences and this would default > Jan> to on? > > This is a joke, right? Unicode changes, non-GNU diffs, non-diff > comparison programs, .... No, I am dead serious. Diff compares text files, if your text encoding has various encodings for the same thing it needs to deal with that. I am all for making sure XEmacs not making gratuitous changes, but if the cost is too high, so be it. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 05:39:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA10267 for xemacs-beta-out; Thu, 4 Nov 1999 05:39:14 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA10264 for ; Thu, 4 Nov 1999 05:39:08 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id LAA02132; Thu, 4 Nov 1999 11:39:06 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id LAA23800; Thu, 4 Nov 1999 11:39:05 +0100 Date: Thu, 4 Nov 1999 11:39:05 +0100 From: Stef Epardaud To: "Michael Sperber [Mr. Preprocessor]" Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? Message-ID: <19991104113905.B22788@tanglefoot.lunatech.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Michael Sperber [Mr. Preprocessor] on Thu, Nov 04, 1999 at 09:20:20AM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Thu, Nov 04, 1999 at 09:20:20AM +0100, Michael Sperber [Mr. Preprocessor] wrote: > >>>>> "kazz" == Kazuyuki IENAGA writes: > > kazz> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > >> I really felt stupid when someone asked me how to make Backspace > >> delete backwards in TTY mode, and I didn't know. This seems to be FAQ > >> material, but isn't in the FAQ. > > kazz> You could just do "stty erase ^H", instead of using "Delete" for > kazz> erase. > kazz> You'd lose Backspace for help-command prefix but you could use f1. > > Sure, F1 works. But I don't really want to globally use ^H for > erase. Why can't I rebind the damn key in XEmacs? > vcorrect me if i'm wrong, but i think i remember something about emacs not being able to differenciate BS key and C-h for some old reason. i read that in o'reilly book about writting elisp modules for emacs. and i was surprised because it always worked for me under xemacs. i have emacs installed at university and i just got used to forgetting BS, because it has the same key value than Del (which is even different but still not gutt) what i say is that i _think_ it is not possible to make the difference in tty mode, for the same reason that emacs cannot do it ? please correct me if i'm wrong, because then i might use the trick to make it work at school and save hours of labour :) -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Thu Nov 4 05:47:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA10478 for xemacs-beta-out; Thu, 4 Nov 1999 05:47:28 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA10475 for ; Thu, 4 Nov 1999 05:47:26 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA29972 for ; Thu, 4 Nov 1999 11:47:25 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa007KH; Thu Nov 4 11:47:18 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15385; Thu, 4 Nov 1999 11:47:17 +0100 To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: From: Jan Vroonhof Date: 04 Nov 1999 11:47:17 +0100 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "04 Nov 1999 09:20:20 +0100" Message-ID: Lines: 28 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > kazz> You could just do "stty erase ^H", instead of using "Delete" for > kazz> erase. > kazz> You'd lose Backspace for help-command prefix but you could use f1. > > Sure, F1 works. But I don't really want to globally use ^H for > erase. Then why do you have your backspace generating that code? Note that the problem is that most shell support ^H as erase regardless of the stty setting and thus hide the problem. Try something less intelligent that takes tty input and you'll see that ^h doesn't work there too. > Why can't I rebind the damn key in XEmacs? You can. Just set tty-erase-char explicitly. However you really don't want to do that. What you really want is to make your backspace key generate DEL instead. For instance in xterms you do this XTerm*vt100.translations: #override BackSpace: string(0x7f) \n\ Delete: string(0x1b) string([3~) Every terminal emulator worthy of the name has a similar option. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 05:51:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA10531 for xemacs-beta-out; Thu, 4 Nov 1999 05:51:19 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA10528 for ; Thu, 4 Nov 1999 05:51:17 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA00049 for ; Thu, 4 Nov 1999 11:51:16 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0000j; Thu Nov 4 11:51:15 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15387; Thu, 4 Nov 1999 11:51:14 +0100 To: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 04 Nov 1999 11:51:14 +0100 In-Reply-To: wmperry@aventail.com's message of "03 Nov 1999 20:19:58 -0500" Message-ID: Lines: 8 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > And it actually seems to work. Unfortunately there is no > CONSOLE_NO_LONGER_HAS_METHOD(...) macro to go with it. :) Just call CONSOLE_HAS_METHOD with a NULL method value? JAn From owner-xemacs-beta@xemacs.org Thu Nov 4 06:05:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11043 for xemacs-beta-out; Thu, 4 Nov 1999 06:05:55 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11038; Thu, 4 Nov 1999 06:05:47 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA01046; Thu, 4 Nov 1999 12:05:27 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000GI; Thu Nov 4 12:05:17 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA15389; Thu, 4 Nov 1999 12:05:17 +0100 To: john s jacobs anderson Cc: Sean Murphy , xemacs-beta@xemacs.org Subject: Re: Missing hm--html-menus package References: From: Jan Vroonhof Date: 04 Nov 1999 12:05:17 +0100 In-Reply-To: john s jacobs anderson's message of "03 Nov 1999 23:07:13 -0700" Message-ID: Lines: 17 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: john s jacobs anderson writes: > Sean> So I looked into how this download mechanism works - looked up > Sean> /pub/xemacs/packages on the xemacs.org server and found that > Sean> there is no hm--html-menus package there. Then I had a look at > Sean> the packages-index.LATEST file, and found that the > Sean> hm--html-menus package is listed there. So I guess that there's > Sean> an inconsistency between the files on the server and the index > Sean> file. You are correct. The hm--html-menus is missing from the FTP site. You either need the SUMO tarball or get it from the authors site. A new release of the packages is badly needed, but requires some organisational changes that are currently being worked on. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 06:06:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11051 for xemacs-beta-out; Thu, 4 Nov 1999 06:06:12 -0500 Received: from nirvana.ingames.com (ingames.no [195.159.15.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11044 for ; Thu, 4 Nov 1999 06:06:03 -0500 Received: from glynn.ingames.com ([195.159.15.204]) by nirvana.ingames.com (8.8.7/8.8.7) with SMTP id MAA27193 for ; Thu, 4 Nov 1999 12:10:32 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.26988.399000.984105@glynn.ingames.com> Date: Thu, 4 Nov 1999 12:09:29 +0100 (GMT--1:00) To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? In-Reply-To: References: X-Mailer: VM 6.67 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote: > >> I really felt stupid when someone asked me how to make Backspace > >> delete backwards in TTY mode, and I didn't know. This seems to be FAQ > >> material, but isn't in the FAQ. > > kazz> You could just do "stty erase ^H", instead of using "Delete" for > kazz> erase. > kazz> You'd lose Backspace for help-command prefix but you could use f1. > > Sure, F1 works. But I don't really want to globally use ^H for > erase. Why can't I rebind the damn key in XEmacs? Maybe I'm missing your point, as the following seems too obvious. If your Backspace key generates \010, then XEmacs can't tell the difference between Backspace and C-h. This is the main reason why most of the terminal users which I know configure their terminals so that Backspace generates \177. The only thing that you should really need to do to get the Backspace key to delete backwards is to ensure that the terminal's erase setting is correct (or set tty-erase-char manually). Then character_to_event will convert that character to the 'backspace keysym, which always deletes backwards. It shouldn't even be necessary to tell people that their terminal driver has to be configured correctly. I guess that this is one of the down sides to readline (which usually works OK regardless of whether your terminal driver has a misconfigured erase setting, so a user may not spot the error until trying to run XEmacs). -- Glynn Clements From owner-xemacs-beta@xemacs.org Thu Nov 4 06:11:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11197 for xemacs-beta-out; Thu, 4 Nov 1999 06:11:59 -0500 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11194 for ; Thu, 4 Nov 1999 06:11:49 -0500 From: ALTMARK@de.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA201216 for ; Thu, 4 Nov 1999 12:11:47 +0100 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA58842 for ; Thu, 4 Nov 1999 12:11:46 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C125681F.003D7D7C ; Thu, 4 Nov 1999 12:11:38 +0100 X-Lotus-FromDomain: IBMDE To: xemacs-beta@xemacs.org Message-ID: Date: Thu, 4 Nov 1999 12:11:35 +0100 Subject: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --text follows this line-- This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Sneaky Bastard 19991102" [Lucid] (i686-pc-linux) of Thu Nov 4 1999 on altmark configured using `configure --site-includes=/usr/local/include --site-libraries=/usr/local/lib --cflags=-O3 --debug=no --error-checking=none --prefix /usr/local/test/xemacs' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Actions: 1. Started Xemacs: /usr/local/test/xemacs/bin/xemacs -vanilla & 2. Chose to use a toolbar with Ediff control buffer: Tools -> Ediff Miscellanea -> Use a toolbar with Ediff control buffer 3. Compared two files with Ediff (e.g. ~/.xemacs/lisp/.emacs and ~/.xemacs/lisp/.emacs~): Tools -> Compare -> Two Files... 4. After the Ediff session came up, moved the mouse pointer to the Ediff control buffer. Jumped between some diffs using the corresponding toolbar button and also the keys and

. 5. Moved the mouse pointer out of the Ediff control buffer. Crash ... Notes: 1. This doesn't happen when no toolbar for the Ediff control buffer is used. 2. This doesn't happen with 21.2-b19 built from the latest available tarballs. (Compiled with the same options.) 3. Same crash with built for AIX 4.3.2 (also in line 7517 of redisplay.c). Screen messages (on xterm from which XEmacs was started): root@altmark: /root (2) # Fatal error: assertion failed, file redisplay.c, line 7517, abort() Fatal error (6). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/test/xemacs/bin/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: event-window(#) # bind (frame event) default-mouse-motion-handler(#) # (condition-case ... . error) # (catch top-level ...) [1]+ Aborted (core dumped) /usr/local/test/xemacs/bin/xemacs -vanilla C stack backtrace: (gdb) where #0 0x40303ab1 in __kill () from /lib/libc.so.6 #1 0x807d019 in fatal_error_signal () #2 0x403039b8 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125 #3 0x40304ef3 in abort () at ../sysdeps/generic/abort.c:88 #4 0x807cf7e in assert_failed () #5 0x8112604 in start_end_of_last_line () #6 0x8114f69 in pixel_to_glyph_translation () #7 0x8088763 in event_pixel_translation () #8 0x8089d45 in Fevent_window () #9 0x8080c25 in Ffuncall () #10 0x805c33a in execute_optimized_program () #11 0x805bf56 in funcall_compiled_function () #12 0x8080de2 in Ffuncall () #13 0x8084060 in call1 () #14 0x80a5d78 in execute_internal_event () #15 0x80a8316 in Fdispatch_event () #16 0x8064bcf in Fcommand_loop_1 () #17 0x8064e16 in command_loop_1 () #18 0x8084beb in condition_case_1 () #19 0x8064f0c in command_loop_2 () #20 0x8084ab9 in internal_catch () #21 0x80648e0 in initial_command_loop () #22 0x807b96b in xemacs_21_2_b19_i686_pc_linux () #23 0x807d27d in main () #24 0x402fd213 in __libc_start_main (main=0x807d160

, argc=2, argv=0xbffff844, init=0x804dc50 <_init>, fini=0x817baa0 <_fini>, rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff83c) at ../sysdeps/generic/libc-start.c:90 Output of `M-x describe-installation': uname -a: Linux altmark 2.2.10 #1 Tue Jul 20 16:32:24 MEST 1999 i686 unknown ./configure '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--cflags=-O3' '--debug=no' '--error-checking=none' '--prefix' '/usr/local/test/xemacs' XEmacs 21.2-b19 "Sneaky Bastard 19991102" configured for `i686-pc-linux'. Where should the build process find the source code? /build/xemacs/xemacs-cvs-snapshot-19991102 What installation prefix should install use? /usr/local/test/xemacs What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O3 Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for LDAP. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Recent keystrokes: misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... --- Markus Alt IBM Laboratory Boeblingen, Germany From owner-xemacs-beta@xemacs.org Thu Nov 4 06:12:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11206 for xemacs-beta-out; Thu, 4 Nov 1999 06:12:12 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11192 for ; Thu, 4 Nov 1999 06:11:47 -0500 Received: from hpbbse.bbn.hp.com (hpbbse.bbn.hp.com [15.136.26.26]) by palrel1.hp.com (Postfix) with ESMTP id D6F6C2CE for ; Thu, 4 Nov 1999 03:11:10 -0800 (PST) Received: from bbn.hp.com (tmbbwmt.bbn.hp.com [15.136.25.175]) by hpbbse.bbn.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id MAA15174 for ; Thu, 4 Nov 1999 12:11:09 +0100 (MEZ) Received: (from thiessel@localhost) by bbn.hp.com (8.8.6 (PHNE_17190)/8.8.6) id MAA13158; Thu, 4 Nov 1999 12:11:08 +0100 (MET) From: Marcus Thiessel Message-ID: <14369.27084.315448.131378@gargle.gargle.HOWL> Date: Thu, 4 Nov 1999 12:11:08 +0100 (MET) To: xemacs-beta@xemacs.org Subject: Re: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: $Ni[2@rr#(N|NUCz5KIWbyoZAxlt%A0v\FN^6!ES@.B}HU9e_* 9(ruLWwCx'bZvjoKvMR #;;T1kZYsWEGnbkXl76=Eb%qdUBo7]:[AmX&RqthqAPcqSQ95n{ fJBPEP{fXYYdGezPd7;=(g{*FDUw8!XB*EXNi@@x&Qi>~Ha'$V%` X-Attribution: mt Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > Does someone want to take a look at this? > > ---------- Forwarded message ---------- > From: "Emery Berger" > Subject: Hoard 1.2 - malloc/free replacement: 30% faster + SPROC support > Date: Sun, 31 Oct 1999 08:43:23 GMT > > =====BEGIN PGP SIGNED MESSAGE===== > > > Hoard is a fast, scalable, and memory-efficient replacement > for malloc/free for multiprocessors. The newest release (1.2) > incorporates a user-level lock implementation (for x86, SPARC, > and SGI's) that improves performance by about 30%. This makes > Hoard faster than the Linux allocator in glibc2, even on just > one processor (it's always been faster for multiple processors). > > This version also includes an "sproc" version for SGI's. > > Looks like some work has to be done for AIX, HP-UX and others. Anyway, would be interesting to know how this compares to other implementation on e.g. AIX/HP-UX. From owner-xemacs-beta@xemacs.org Thu Nov 4 06:21:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11365 for xemacs-beta-out; Thu, 4 Nov 1999 06:21:13 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA11362 for ; Thu, 4 Nov 1999 06:21:12 -0500 Received: (qmail 14508 invoked from network); 4 Nov 1999 11:19:56 -0000 Received: from usrpri2-14.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.79) by biff.kiva.net with SMTP; 4 Nov 1999 11:19:56 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA16275; Thu, 4 Nov 1999 06:22:46 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? X-Now-Listening-To: Insane Clown Posse - The Neden Game References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > And it actually seems to work. Unfortunately there is no > > CONSOLE_NO_LONGER_HAS_METHOD(...) macro to go with it. :) > > Just call CONSOLE_HAS_METHOD with a NULL method value? Nope, that's not how it works - you tell it what method and it automatically constructs the function name from the console type (tty) and method name (set_mouse_position). I just cheat a little and set the method slots directly. -Bill P. From owner-xemacs-beta@xemacs.org Thu Nov 4 06:42:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11891 for xemacs-beta-out; Thu, 4 Nov 1999 06:42:14 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11886 for ; Thu, 4 Nov 1999 06:42:12 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA01795 for ; Thu, 4 Nov 1999 12:42:10 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Ry; Thu Nov 4 12:42:07 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA15434; Thu, 4 Nov 1999 12:42:06 +0100 To: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> <86n1su1oxl.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 04 Nov 1999 12:42:06 +0100 In-Reply-To: wmperry@aventail.com's message of "04 Nov 1999 06:22:46 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Nope, that's not how it works - you tell it what method and it > automatically constructs the function name from the console type (tty) and > method name (set_mouse_position). I just cheat a little and set the method > slots directly. Ah you're right of course. Maybe you should just introduce that macro (or change the function to do nothing, that might be cleaner). Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 06:46:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA12015 for xemacs-beta-out; Thu, 4 Nov 1999 06:46:14 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA12012 for ; Thu, 4 Nov 1999 06:46:12 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA01910 for ; Thu, 4 Nov 1999 12:46:10 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000To; Thu Nov 4 12:46:06 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA15493; Thu, 4 Nov 1999 12:46:06 +0100 To: xemacs-beta@xemacs.org Subject: Re: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] References: <14369.27084.315448.131378@gargle.gargle.HOWL> From: Jan Vroonhof Date: 04 Nov 1999 12:46:06 +0100 In-Reply-To: Marcus Thiessel's message of "Thu, 4 Nov 1999 12:11:08 +0100 (MET)" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Marcus Thiessel writes: > > Hoard is a fast, scalable, and memory-efficient replacement > > for malloc/free for multiprocessors. The newest release (1.2) > > incorporates a user-level lock implementation (for x86, SPARC, FWIW? XEmacs cpu usage isn't dominated by time spent in malloc is it? I don't see the point at this moment to change to another allocator if that takes more space and isn't as portable as we use now. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 06:50:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA12098 for xemacs-beta-out; Thu, 4 Nov 1999 06:50:47 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA12094 for ; Thu, 4 Nov 1999 06:50:44 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA02015 for ; Thu, 4 Nov 1999 12:50:31 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000VT; Thu Nov 4 12:50:23 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA15664; Thu, 4 Nov 1999 12:50:23 +0100 To: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer References: From: Jan Vroonhof Date: 04 Nov 1999 12:50:21 +0100 In-Reply-To: ALTMARK@de.ibm.com's message of "Thu, 4 Nov 1999 12:11:35 +0100" Message-ID: Lines: 16 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: ALTMARK@de.ibm.com writes: > In XEmacs 21.2 (beta19) "Sneaky Bastard 19991102" [Lucid] (i686-pc-linux) of Aha.. So there are people using it. > Please describe exactly what actions triggered the bug > and the precise symptoms of the bug: I'll try to reproduce at home this weekend. -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof @ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085 From owner-xemacs-beta@xemacs.org Thu Nov 4 07:27:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA13061 for xemacs-beta-out; Thu, 4 Nov 1999 07:27:03 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id HAA13056 for ; Thu, 4 Nov 1999 07:27:01 -0500 Received: (qmail 14095 invoked from network); 4 Nov 1999 12:25:40 -0000 Received: from usrpri2-4.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.69) by biff.kiva.net with SMTP; 4 Nov 1999 12:25:40 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id HAA16441; Thu, 4 Nov 1999 07:28:31 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> <86n1su1oxl.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > Nope, that's not how it works - you tell it what method and it > > automatically constructs the function name from the console type (tty) and > > method name (set_mouse_position). I just cheat a little and set the method > > slots directly. > > Ah you're right of course. Maybe you should just introduce that macro > (or change the function to do nothing, that might be cleaner). Well, the console code already has a 'dummy' method it uses. I want to avoid duplicating it if I can, just so the two do not get out of synch. This is all kind of moot right now anyway, since the Gpm_GetSnapshot appears to return useless positions (negative, etc). :( -Bill P. From owner-xemacs-beta@xemacs.org Thu Nov 4 07:40:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA13459 for xemacs-beta-out; Thu, 4 Nov 1999 07:40:22 -0500 Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA13418; Thu, 4 Nov 1999 07:40:12 -0500 Received: from cr308749-a.wlfdle1.on.wave.home.com ([24.112.10.88]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991104123816.GIJL24158.mail.rdc3.on.home.com@cr308749-a.wlfdle1.on.wave.home.com>; Thu, 4 Nov 1999 04:38:16 -0800 Received: (from georgn@localhost) by cr308749-a.wlfdle1.on.wave.home.com (8.9.3+Sun/8.9.3) id HAA01409; Thu, 4 Nov 1999 07:40:06 -0500 (EST) From: Georg Nikodym MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.32422.278541.446646@cr308749-a.wlfdle1.on.wave.home.com> Date: Thu, 4 Nov 1999 07:40:06 -0500 (EST) To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Reply-To: georgn@home.com Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Does someone want to take a look at this? Uh, unless somebody made XEmacs multithreaded while I wasn't looking, this sort of technology isn't very interesting... The problem that MT allocators are attempting to solve is concurrent access to the heap management structures internal to the allocator itself. That said, if someone is inclined, experiments with various allocators with an eye to performance will perhaps uncover From owner-xemacs-beta@xemacs.org Thu Nov 4 07:43:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA13602 for xemacs-beta-out; Thu, 4 Nov 1999 07:43:18 -0500 Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA13590; Thu, 4 Nov 1999 07:43:06 -0500 Received: from cr308749-a.wlfdle1.on.wave.home.com ([24.112.10.88]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991104124114.GJJX24158.mail.rdc3.on.home.com@cr308749-a.wlfdle1.on.wave.home.com>; Thu, 4 Nov 1999 04:41:14 -0800 Received: (from georgn@localhost) by cr308749-a.wlfdle1.on.wave.home.com (8.9.3+Sun/8.9.3) id HAA01412; Thu, 4 Nov 1999 07:43:04 -0500 (EST) From: Georg Nikodym MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.32600.725296.409366@cr308749-a.wlfdle1.on.wave.home.com> Date: Thu, 4 Nov 1999 07:43:04 -0500 (EST) To: SL Baur CC: xemacs-beta@xemacs.org Subject: Re: [Yusuf Goolamabbas ] [dgaudet@arctic.org: faster malloc for multithreaded programs] In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Reply-To: georgn@home.com Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Does someone want to take a look at this? In my last posting, I accidentally sent before finishing a thought which I don't really have time to complete right now. So, just ignore that last paragraph (which probably doesn't mean anything anyway). From owner-xemacs-beta@xemacs.org Thu Nov 4 07:56:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA14128 for xemacs-beta-out; Thu, 4 Nov 1999 07:56:40 -0500 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA14119; Thu, 4 Nov 1999 07:56:30 -0500 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11jMRJ-00036V-00; Thu, 04 Nov 1999 07:56:29 -0500 To: martin@xemacs.org Cc: Olivier Galibert , xemacs-beta@xemacs.org Subject: Re: pdump and const References: <3.0.5.32.19991103191715.009c8d80@london.beasys.com> <19991103191549.D32122@nemesis.ncsl.nist.gov> <14368.56618.326991.179243@lasker.666.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 04 Nov 1999 07:56:29 -0500 In-Reply-To: Martin Buchholz's message of "Wed, 3 Nov 1999 17:11:06 -0800 (PST)" Message-ID: Lines: 3 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The problem was not that compilers don't implement const. The problem is inconsistent usage of it in system include file prototypes. If you can actually make this work portably, you're a better man than I. From owner-xemacs-beta@xemacs.org Thu Nov 4 08:55:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA15600 for xemacs-beta-out; Thu, 4 Nov 1999 08:55:30 -0500 Received: from mharnois.workgroup.net (ps04alo.willinet.net [198.49.28.101]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA15596 for ; Thu, 4 Nov 1999 08:55:27 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian 8.9.3-6) id HAA04202; Thu, 4 Nov 1999 07:55:23 -0600 To: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer References: From: Michael Harnois Date: 04 Nov 1999 07:55:23 -0600 In-Reply-To: Jan Vroonhof's message of "04 Nov 1999 12:50:21 +0100" Message-ID: <877ljy5pkk.fsf@mharnois.workgroup.net> Lines: 11 User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 04 Nov 1999 12:50:21 +0100, Jan Vroonhof said: > I'll try to reproduce at home this weekend. Getting rather personal here, aren't we? -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org Most lies succeed because no one goes through the work to figure out how to catch them. -- Paul Ekman From owner-xemacs-beta@xemacs.org Thu Nov 4 09:15:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA16133 for xemacs-beta-out; Thu, 4 Nov 1999 09:15:51 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA16129 for ; Thu, 4 Nov 1999 09:15:49 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id JAA24863; Thu, 4 Nov 1999 09:22:35 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id PAA27610; Thu, 4 Nov 1999 15:15:18 +0100 (MET) To: Michael Harnois Cc: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer References: <877ljy5pkk.fsf@mharnois.workgroup.net> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 04 Nov 1999 15:12:17 +0100 In-Reply-To: Michael Harnois's message of "04 Nov 1999 07:55:23 -0600" Message-ID: Lines: 18 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Harnois writes: Michael> On 04 Nov 1999 12:50:21 +0100, Jan Vroonhof Michael> said: >> I'll try to reproduce at Michael> home this weekend. Michael> Getting rather personal here, aren't we? Wouldn't that sheer attempt be illegal in some of the more fundamentalist of the Unites States, unless one is married? Adrian :-) Michael> -- Michael> Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA Michael> mharnois@willinet.net aa0bt@aa0bt.ampr.org Michael> Most lies succeed because no one goes through the work to Michael> figure out how to catch them. -- Paul Ekman From owner-xemacs-beta@xemacs.org Thu Nov 4 09:18:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA16261 for xemacs-beta-out; Thu, 4 Nov 1999 09:18:38 -0500 Received: from mharnois.workgroup.net (ps04alo.willinet.net [198.49.28.101]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA16256 for ; Thu, 4 Nov 1999 09:18:34 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian 8.9.3-6) id IAA04723; Thu, 4 Nov 1999 08:18:30 -0600 To: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer References: <877ljy5pkk.fsf@mharnois.workgroup.net> From: Michael Harnois Date: 04 Nov 1999 08:18:30 -0600 In-Reply-To: Adrian Aichner's message of "04 Nov 1999 15:12:17 +0100" Message-ID: <87yace49xl.fsf@mharnois.workgroup.net> Lines: 14 User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 04 Nov 1999 15:12:17 +0100, Adrian Aichner said: > Wouldn't that sheer attempt be illegal in some of the more > fundamentalist of the Unites States, unless one is married? I don't know what the state of fornication laws is these days. I believe some states still have laws against sodomy, but, of course, there reproduction is not an issue. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org Most lies succeed because no one goes through the work to figure out how to catch them. -- Paul Ekman From owner-xemacs-beta@xemacs.org Thu Nov 4 09:20:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA16375 for xemacs-beta-out; Thu, 4 Nov 1999 09:20:57 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA16372 for ; Thu, 4 Nov 1999 09:20:55 -0500 Received: by localhost id m11jNkz-00016JC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 4 Nov 1999 23:20:53 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.38469.546674.290980@turnbull.sk.tsukuba.ac.jp> Date: Thu, 4 Nov 1999 23:20:53 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer In-Reply-To: <877ljy5pkk.fsf@mharnois.workgroup.net> References: <877ljy5pkk.fsf@mharnois.workgroup.net> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Harnois writes: Michael> On 04 Nov 1999 12:50:21 +0100, Jan Vroonhof Michael> said: >> I'll try to reproduce at home this weekend. Michael> Getting rather personal here, aren't we? Not really. Isn't that how all great programmers get more work than one human can possibly do done? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 4 10:48:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA19489 for xemacs-beta-out; Thu, 4 Nov 1999 10:48:22 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA19485 for ; Thu, 4 Nov 1999 10:48:19 -0500 Received: (qmail 8342 invoked from network); 4 Nov 1999 15:46:53 -0000 Received: from usrpri2-23.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.88) by biff.kiva.net with SMTP; 4 Nov 1999 15:46:53 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA17634; Thu, 4 Nov 1999 10:49:44 -0500 To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer X-Now-Listening-To: Insane Clown Posse - House Of Horrors References: <877ljy5pkk.fsf@mharnois.workgroup.net> <14369.38469.546674.290980@turnbull.sk.tsukuba.ac.jp> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > >>>>> "Michael" == Michael Harnois writes: > > Michael> On 04 Nov 1999 12:50:21 +0100, Jan Vroonhof > Michael> said: > > >> I'll try to reproduce at home this weekend. > > Michael> Getting rather personal here, aren't we? > > Not really. Isn't that how all great programmers get more work than > one human can possibly do done? I hope liam can start taking some of my workload off soon then. :) -bp From owner-xemacs-beta@xemacs.org Thu Nov 4 11:13:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA20389 for xemacs-beta-out; Thu, 4 Nov 1999 11:13:30 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA20384 for ; Thu, 4 Nov 1999 11:13:27 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA15764 for ; Thu, 4 Nov 1999 17:13:24 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003qF; Thu Nov 4 17:13:15 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA16760; Thu, 4 Nov 1999 17:13:15 +0100 To: xemacs-beta@xemacs.org Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer References: <877ljy5pkk.fsf@mharnois.workgroup.net> From: Jan Vroonhof Date: 04 Nov 1999 17:13:14 +0100 In-Reply-To: Michael Harnois's message of "04 Nov 1999 07:55:23 -0600" Message-ID: Lines: 32 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Harnois writes: > > I'll try to reproduce at home this weekend. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. I will always proof read my messages. .... > > Getting rather personal here, aren't we? He, my Girlfriend is 800km's away. What am I going to do :-) Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 11:59:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA21831 for xemacs-beta-out; Thu, 4 Nov 1999 11:59:42 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA21827 for ; Thu, 4 Nov 1999 11:59:39 -0500 Received: (qmail 20564 invoked from network); 4 Nov 1999 16:58:19 -0000 Received: from usrpri2-42.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.107) by biff.kiva.net with SMTP; 4 Nov 1999 16:58:19 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id MAA17833; Thu, 4 Nov 1999 12:01:09 -0500 To: xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: Reworked GPM support... X-Now-Listening-To: Indigo Girls - It's Alright Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 36 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Here is a reworked version of the GPM support. This is equivalent functionality-wise to the current implementation, but does not sink its teeth into all the console and event loops like the old one. You can also choose whether or not you want GPM to be on by the new function: ----------------- `gpm-mode' is a built-in function (gpm-mode &optional ARG) Documentation: Start accepting GPM mouse events iff ARG is positive. ----------------- This works a lot like the tooltalk support. When gpm-mode is turned on, it calls Gpm_Open to get the file descriptor, sticks it into the lisp-accessible variable 'gpm-fd', connects a process object to the fd, and sets the process filter to read the GPM events, and sticks the button events into the unread-command-events variable, and dispatches movement events via Fdispatch_event. This should make the GPM code much more stable/useful (I like being able to turn it off temporarily if I want to cut/paste something between virtual consoles, not just XEmacs frames). No need to worry about selecting the same FD multiple times if you open multiple TTY devices, etc. The only drawback to doing it this way is that the GPM pointer cannot be seen very well. If anybody has ideas on how to fix that, other than having XEmacs draw it as part of redisplay, please let me know. -Bill P. --=-=-= Content-Disposition: inline; filename=gpm.patch Index: src/console-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.5 diff -u -w -r1.18.2.5 console-tty.c --- console-tty.c 1999/10/24 03:48:31 1.18.2.5 +++ console-tty.c 1999/11/04 16:32:06 @@ -38,9 +38,6 @@ #ifdef FILE_CODING #include "file-coding.h" #endif -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif DEFINE_CONSOLE_TYPE (tty); DECLARE_IMAGE_INSTANTIATOR_FORMAT (nothing); @@ -129,10 +126,6 @@ #endif /* MULE */ tty_con->terminal_type = terminal_type; tty_con->controlling_process = controlling_process; - -#ifdef HAVE_GPM - connect_to_gpm (con); -#endif if (NILP (CONSOLE_NAME (con))) CONSOLE_NAME (con) = Ffile_name_nondirectory (tty); Index: src/console-tty.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.h,v retrieving revision 1.8.2.2 diff -u -w -r1.8.2.2 console-tty.h --- console-tty.h 1999/02/17 20:03:57 1.8.2.2 +++ console-tty.h 1999/11/04 16:32:09 @@ -41,9 +41,6 @@ struct tty_console { int infd, outfd; -#ifdef HAVE_GPM - int mouse_fd; -#endif Lisp_Object instream, outstream; Lisp_Object terminal_type; Lisp_Object controlling_process; @@ -203,9 +200,6 @@ unsigned int is_stdio :1; }; -#ifdef HAVE_GPM -#define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd) -#endif #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty) #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x) #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y) Index: src/device-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-tty.c,v retrieving revision 1.9 diff -u -w -r1.9 device-tty.c --- device-tty.c 1998/05/27 20:42:00 1.9 +++ device-tty.c 1999/11/04 16:32:38 @@ -38,10 +38,6 @@ #include "syssignal.h" /* for SIGWINCH */ -#ifdef HAVE_GPM -#include -#endif - #include Lisp_Object Qinit_pre_tty_win, Qinit_post_tty_win; @@ -155,15 +151,6 @@ CONSOLE_TTY_DATA (con)->width = width; CONSOLE_TTY_DATA (con)->height = height; -#ifdef HAVE_GPM - /* We need to tell GPM how big our screen is now - ** I am pretty sure the GPM library will get incredibly confused - ** if you try to connect to more than one mouse-capable device, - ** so I don't think it will cause any more damage in that case. - */ - gpm_mx = width; - gpm_my = height; -#endif for (tail = DEVICE_FRAME_LIST (d); !NILP (tail); tail = XCDR (tail)) Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -w -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/04 16:32:57 @@ -1088,6 +1088,10 @@ syms_of_eldap (); #endif +#ifdef HAVE_GPM + syms_of_gpmevent (); +#endif + /* Now create the subtypes for the types that have them. We do this before the vars_*() because more symbols may get initialized here. */ @@ -1481,6 +1485,10 @@ #ifdef HAVE_LDAP vars_of_eldap (); +#endif + +#ifdef HAVE_GPM + vars_of_gpmevent (); #endif /* Now initialize any specifier variables. We do this later Index: src/event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.14 diff -u -w -r1.41.2.14 event-Xt.c --- event-Xt.c 1999/10/10 11:45:15 1.41.2.14 +++ event-Xt.c 1999/11/04 16:33:05 @@ -2034,9 +2034,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2044,32 +2041,13 @@ infd = event_stream_unixoid_select_console (con); XSETCONSOLE (console, con); select_filedesc (infd, console); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - /* We check filedesc_to_what_closure[fd] here because if you run - ** XEmacs from a TTY, it will fire up GPM, select the mouse fd, then - ** if you run gnuattach to connect to another TTY, it will fire up - ** GPM again, and try to reselect the mouse fd. GPM uses the same - ** fd for every connection apparently, and select_filedesc will - ** fail its assertion if we try to select it twice. - */ - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { - select_filedesc (mousefd, console); } - } -#endif -} static void emacs_Xt_unselect_console (struct console *con) { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2077,15 +2055,6 @@ infd = event_stream_unixoid_unselect_console (con); XSETCONSOLE (console, con); unselect_filedesc (infd); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - if (mousefd >= 0) { - unselect_filedesc (mousefd); - } - } -#endif } /* read an event from a tty, if one is available. Returns non-zero Index: src/event-unixoid.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-unixoid.c,v retrieving revision 1.9.2.1 diff -u -w -r1.9.2.1 event-unixoid.c --- event-unixoid.c 1999/03/07 15:25:17 1.9.2.1 +++ event-unixoid.c 1999/11/04 16:33:05 @@ -41,10 +41,6 @@ #include "sysproc.h" /* select stuff */ #include "systime.h" -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif - /* Mask of bits indicating the descriptors that we wait for input on. These work as follows: @@ -83,12 +79,6 @@ Lisp_Object console; XSETCONSOLE (console, con); - -#ifdef HAVE_GPM - if (fd == CONSOLE_TTY_MOUSE_FD (con)) { - return handle_gpm_read (event,con,fd); - } -#endif nread = read (fd, &ch, 1); if (nread <= 0) Index: src/frame-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame-tty.c,v retrieving revision 1.8.2.1 diff -u -w -r1.8.2.1 frame-tty.c --- frame-tty.c 1998/12/05 16:55:48 1.8.2.1 +++ frame-tty.c 1999/11/04 16:33:05 @@ -33,11 +33,7 @@ #include "events.h" -#ifdef HAVE_GPM -#include -#endif - /* Default properties to use when creating frames. */ Lisp_Object Vdefault_tty_frame_plist; @@ -86,33 +82,6 @@ call1 (Qinit_post_tty_win, FRAME_CONSOLE (f)); } -#ifdef HAVE_GPM -static int -tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) -{ - Gpm_Event ev; - int num_buttons; - - num_buttons = Gpm_GetSnapshot(&ev); - *x = ev.x; - *y = ev.y; - *frame = DEVICE_SELECTED_FRAME (d); - return (1); -} - -static void -tty_set_mouse_position (struct window *w, int x, int y) -{ - /* XXX - I couldn't find any GPM functions that set the mouse position. - Mr. Perry had left this function empty; that must be why. - karlheg - */ -} - -#endif - - /* Change from withdrawn state to mapped state. */ static void tty_make_frame_visible (struct frame *f) @@ -223,10 +192,6 @@ CONSOLE_HAS_METHOD (tty, init_frame_1); CONSOLE_HAS_METHOD (tty, init_frame_3); CONSOLE_HAS_METHOD (tty, after_init_frame); -#ifdef HAVE_GPM - CONSOLE_HAS_METHOD (tty, get_mouse_position); - CONSOLE_HAS_METHOD (tty, set_mouse_position); -#endif CONSOLE_HAS_METHOD (tty, make_frame_visible); CONSOLE_HAS_METHOD (tty, make_frame_invisible); CONSOLE_HAS_METHOD (tty, frame_visible_p); Index: src/gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5 diff -u -w -r1.5 gpmevent.c --- gpmevent.c 1998/03/31 20:11:47 1.5 +++ gpmevent.c 1999/11/04 16:33:07 @@ -1,5 +1,28 @@ -/* William Perry 1997 */ +/* GPM functions + Copyright (C) 1997 William M. Perry + Copyright (C) 1999 Free Software Foundation, Inc. + +This file is part of XEmacs. + +XEmacs 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. + +XEmacs 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 XEmacs; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* Synched up with: Not in FSF. */ + +/* Authors: William Perry */ + #include #include "lisp.h" #include "console.h" @@ -8,11 +31,16 @@ #include "events.h" #include "events-mod.h" #include "sysdep.h" +#include "commands.h" #ifdef HAVE_GPM #include "gpmevent.h" #include +/* This is commented out in commands.h, I'm not sure why */ +extern Lisp_Object Vunread_command_events; +extern Lisp_Object Vunread_command_event; + #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 @@ -21,19 +49,38 @@ #include #endif -int -handle_gpm_read (struct Lisp_Event *event, struct console *con, int fd) +Lisp_Object Vgpm_fd; + +DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* +Run GPM_GetEvent(). +This function is the process handler for the GPM connection. +*/ + (ignore1, ignore2)) { Gpm_Event ev; int modifiers = 0; int type = -1; int button = 1; + Lisp_Object fake_event; + struct Lisp_Event *event = NULL; + struct gcpro gcpro1; + static int num_events; if (!Gpm_GetEvent(&ev)) - return 0; + { + warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed"); + return(Qzero); + } + + GCPRO1(fake_event); + + num_events++; + fake_event = Fmake_event (Qnil, Qnil); + event = XEVENT(fake_event); + event->timestamp = 0; - event->channel = CONSOLE_SELECTED_FRAME (con); + event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (co n); */ /* Whow, wouldn't named defines be NICE!?!?! */ modifiers = 0; @@ -44,20 +91,30 @@ if (ev.modifiers & 8) modifiers |= MOD_META; if (ev.type & GPM_DOWN) + { type = GPM_DOWN; + } else if (ev.type & GPM_UP) + { type = GPM_UP; - else if (ev.type & GPM_MOVE) { + } + else if (ev.type & GPM_MOVE) + { type = GPM_MOVE; - GPM_DRAWPOINTER(&ev); } if (ev.buttons & GPM_B_LEFT) + { button = 1; + } else if (ev.buttons & GPM_B_MIDDLE) + { button = 2; + } else if (ev.buttons & GPM_B_RIGHT) + { button = 3; + } switch (type) { case GPM_DOWN: @@ -75,21 +132,130 @@ event->event.motion.y = ev.y; event->event.motion.modifiers = modifiers; default: - return 0; + /* This will never happen */ + break; + } + + /* Handle the event */ +#if 0 + /* dispatching it directly doesn't seem to work well */ + Fdispatch_event (fake_event); +#else + /* Let's try sticking it on the unread events queue */ + if (!command_event_p (fake_event)) + { + /* unread_command_events does not like motion events */ + Fdispatch_event (fake_event); + } + else if (NILP (Vunread_command_events)) + { + Vunread_command_events = Fcons (fake_event, Qnil); + } + else + { + Lisp_Object arg[2]; + arg[0] = Vunread_command_events; + arg[1] = fake_event; + + Vunread_command_events = Fappend (2,arg); + } +#endif + GPM_DRAWPOINTER(&ev); + + UNGCPRO; + + return (Qzero); +} + +static void turn_off_gpm (void) +{ + Fdelete_process (build_string ("gpm")); + Gpm_Close(); + Vgpm_fd = Qnil; + + /* Remove the TTY mouse methods */ + /* This is breaking abstraction a bit, but... */ + tty_console_methods->get_mouse_position_method = NULL; + tty_console_methods->set_mouse_position_method = NULL; +} + +/* This function appears to work once in a blue moon. I'm not sure +** exactly why either. *sigh* +** wmperry Nov 4, 1999 +*/ +static int +tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) +{ + Gpm_Event ev; + int num_buttons; + + memset(&ev,'\0',sizeof(ev)); + num_buttons = Gpm_GetSnapshot(&ev); + + if (!num_buttons) + { + /* This means there are events pending... */ + return(-1); } - return 1; + *x = ev.x; + *y = ev.y; + *frame = DEVICE_SELECTED_FRAME (d); + return (1); +} + +static void +tty_set_mouse_position (struct window *w, int x, int y) +{ + /* XXX + I couldn't find any GPM functions that set the mouse position. + Mr. Perry had left this function empty; that must be why. + karlheg + */ } -void -connect_to_gpm (struct console *con) +DEFUN ("gpm-mode", Fgpm_mode, 0, 1, 0, /* +Start accepting GPM mouse events iff ARG is positive. +*/ + (arg)) { - /* Only do this if we are running after dumping and really interactive */ - if (!noninteractive && initialized) { - /* We really only want to do this on a TTY */ - CONSOLE_TTY_MOUSE_FD (con) = -1; - if (EQ (CONSOLE_TYPE (con), Qtty)) { Gpm_Connect conn; int rval; + Lisp_Object gpm_process; + Lisp_Object gpm_filter; + + if (NILP (arg)) + { + /* Toggle current GPM mode */ + if (!NILP (Vgpm_fd)) + { + /* Need to turn it off */ + turn_off_gpm (); + return (Qnil); + } + } + else + { + int i; + + CHECK_INT (arg); + + i = XINT (arg); + + if (i < 0) + { + turn_off_gpm (); + return (Qnil); + } + } + + if (!NILP (Vgpm_fd)) + { + error ("Already connected to GPM"); + } + + /* Install the mouse position methods for the TTY console type */ + CONSOLE_HAS_METHOD (tty, get_mouse_position); + CONSOLE_HAS_METHOD (tty, set_mouse_position); conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; conn.defaultMask = GPM_MOVE; @@ -97,6 +263,7 @@ conn.maxMod = ((1<; Thu, 4 Nov 1999 12:00:21 -0500 Received: from ODIN4.rito.no (odin.rito.no [172.20.4.17]) by vals.intramed.rito.no (8.9.3/8.9.3) with ESMTP id SAA10625; Thu, 4 Nov 1999 18:00:16 +0100 (CET) Received: by odin4.rito.no with Internet Mail Service (5.5.2448.0) id ; Thu, 4 Nov 1999 17:57:55 +0100 Message-ID: <22FD5BD2DBC5D211BE0D0008C7A4E87FD9B318@odin4.rito.no> From: Bless Terje To: "'XEmacs-Beta'" Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer Date: Thu, 4 Nov 1999 17:57:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof wrote: >Michael Harnois wrote: >>Jan Vroonhof wrote: >> >>>I'll try to reproduce at home this weekend. >>Getting rather personal here, aren't we? > >He, my Girlfriend is 800km's away. What am I going to do :-) "If at first you don't succeed..." :-) From owner-xemacs-beta@xemacs.org Thu Nov 4 12:44:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA23931 for xemacs-beta-out; Thu, 4 Nov 1999 12:44:04 -0500 Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA23926 for ; Thu, 4 Nov 1999 12:44:02 -0500 Received: from informatik.uni-tuebingen.de (brabantio.Informatik.Uni-Tuebingen.De [134.2.12.25]) by macon.informatik.uni-tuebingen.de (8.9.3/8.9.1) with ESMTP id SAA19906 for ; Thu, 4 Nov 1999 18:43:54 +0100 Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id SAA23564; Thu, 4 Nov 1999 18:43:52 +0100 To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 04 Nov 1999 18:43:51 +0100 In-Reply-To: Jan Vroonhof's message of "04 Nov 1999 11:47:17 +0100" Message-ID: Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id MAA23929 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: kazz> You could just do "stty erase ^H", instead of using "Delete" for kazz> erase. kazz> You'd lose Backspace for help-command prefix but you could use f1. >> >> Sure, F1 works. But I don't really want to globally use ^H for >> erase. Jan> Then why do you have your backspace generating that code? Note that the Jan> problem is that most shell support ^H as erase regardless of the stty Jan> setting and thus hide the problem. Try something less intelligent that Jan> takes tty input and you'll see that ^h doesn't work there too. >> Why can't I rebind the damn key in XEmacs? Jan> You can. Just set tty-erase-char explicitly. However you really don't Jan> want to do that. What you really want is to make your backspace key Jan> generate DEL instead. Jan> For instance in xterms you do this Jan> XTerm*vt100.translations: #override BackSpace: string(0x7f) \n\ Jan> Delete: string(0x1b) string([3~) Jan> Every terminal emulator worthy of the name has a similar option. All excellent answers. (Thanks, Jan!) They still doesn't answer the basic question why I can't rebind this key inside XEmacs, when I can rebind every other key. Note that I don't care about most of the issues raised by other people. I don't care about Help, specifically. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Nov 4 13:19:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26823 for xemacs-beta-out; Thu, 4 Nov 1999 13:19:45 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA26819 for ; Thu, 4 Nov 1999 13:19:44 -0500 Received: (qmail 1929 invoked from network); 4 Nov 1999 18:18:27 -0000 Received: from usrpri2-2.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.67) by biff.kiva.net with SMTP; 4 Nov 1999 18:18:27 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA01040; Thu, 4 Nov 1999 13:21:18 -0500 To: Bless Terje Cc: "'XEmacs-Beta'" Subject: Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer X-Now-Listening-To: Tom Petty & The Heartbreakers - Swingin' References: <22FD5BD2DBC5D211BE0D0008C7A4E87FD9B318@odin4.rito.no> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Bless Terje writes: > Jan Vroonhof wrote: > > >Michael Harnois wrote: > >>Jan Vroonhof wrote: > >> > >>>I'll try to reproduce at home this weekend. > >>Getting rather personal here, aren't we? > > > >He, my Girlfriend is 800km's away. What am I going to do :-) > > "If at first you don't succeed..." :-) rent a car? :) -bp From owner-xemacs-beta@xemacs.org Thu Nov 4 13:20:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26891 for xemacs-beta-out; Thu, 4 Nov 1999 13:20:48 -0500 Received: from nirvana.ingames.com (nirvana.ingames.no [195.159.15.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26882 for ; Thu, 4 Nov 1999 13:20:44 -0500 Received: from glynn.ingames.com ([195.159.15.204]) by nirvana.ingames.com (8.8.7/8.8.7) with SMTP id TAA29049; Thu, 4 Nov 1999 19:25:26 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.53043.459000.631229@glynn.ingames.com> Date: Thu, 4 Nov 1999 19:23:44 +0100 (GMT--1:00) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? In-Reply-To: References: X-Mailer: VM 6.67 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote: > All excellent answers. (Thanks, Jan!) They still doesn't answer the > basic question why I can't rebind this key inside XEmacs, when I can > rebind every other key. Why you can't rebind what key? 'backspace or [(control ?h)]? You should be able to rebind either. However, there isn't much point rebinding [(control ?h)] in tty mode if your tty's erase character is \010, as you will never get a keypress-event for [(control ?h)], but for 'backspace instead. -- Glynn Clements From owner-xemacs-beta@xemacs.org Thu Nov 4 13:25:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA27281 for xemacs-beta-out; Thu, 4 Nov 1999 13:25:22 -0500 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA27275 for ; Thu, 4 Nov 1999 13:25:20 -0500 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id KAA11937 for ; Thu, 4 Nov 1999 10:25:17 -0800 (PST) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id KAA27441; Thu, 4 Nov 1999 10:25:19 -0800 (PST) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id KAA29328; Thu, 4 Nov 1999 10:25:06 -0800 (PST) Message-Id: <199911041825.KAA29328@mina.sr.hp.com> To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? Reply-To: Darryl Okahata In-reply-to: Your message of "04 Nov 1999 18:43:51 +0100." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Nov 1999 10:25:05 -0800 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) wrote: > All excellent answers. (Thanks, Jan!) They still doesn't answer the > basic question why I can't rebind this key inside XEmacs, when I can > rebind every other key. Note that I don't care about most of the > issues raised by other people. I don't care about Help, specifically. Well, if you're trying to do this from ~/.emacs, you have to do it via "term-setup-hook", as Emacs loads the term setup code *AFTER* reading your ~/.emacs file (which means that any changes made in ~/.emacs get blown away). Here's an example (for someone who recently asked me how to force C-h to be 'delete-backward-char, and not help): =============================================================================== ;; Add this to your ~/.emacs file: (defun munge-keyboard () (let () (cond ( (eq window-system 'x) (progn ;; Setup for X-windows (global-set-key "\C-h" 'delete-backward-char) )) ( (or (string= (getenv "TERM") "vt100") (string= (getenv "TERM") "vt102")) (progn ;; Setup for VT-100 terminals ;; Do other stuff here. )) ) )) (add-hook 'term-setup-hook 'munge-keyboard) =============================================================================== -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Thu Nov 4 13:30:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA27742 for xemacs-beta-out; Thu, 4 Nov 1999 13:30:49 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA27736 for ; Thu, 4 Nov 1999 13:30:46 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA23697 for ; Thu, 4 Nov 1999 19:30:44 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005mC; Thu Nov 4 19:30:36 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA16955; Thu, 4 Nov 1999 19:30:35 +0100 To: xemacs-beta@xemacs.org Subject: Gutter Crash [was Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer] References: From: Jan Vroonhof Date: 04 Nov 1999 19:30:35 +0100 In-Reply-To: ALTMARK@de.ibm.com's message of "Thu, 4 Nov 1999 12:11:35 +0100" Message-ID: Lines: 80 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [No it is not week-end here but I have 21.2 on our new linux box] ALTMARK@de.ibm.com writes: > 5. Moved the mouse pointer out of the Ediff control buffer. Crash ... > #4 0x807cf7e in assert_failed () > #5 0x8112604 in start_end_of_last_line () > #6 0x8114f69 in pixel_to_glyph_translation () Ok, here is what happens. The ediff window is very small. Thus if you run with the buffer tabs, the buffer tabs take all the place of the window, so the buffers window isn't actually displayed. Only the modeline is. (Side issue: This window really shouldn't have tabs) (Side issue: Why is the size of the gutters not taken into account to set the frame size?) Then you move the mouse outside. The mouse code tries to find the nearest point in the buffer (pixel_to_glyph_translation), because the displayed parts of the buffer are not near, it thinks the last displayed line is closest and thus calls end_of_last_line (which is really start_end_of_last_line). These kinds of computation are really done in redisplay and thus start_end_of_last_line calls point_in_line_start_cache to update the cache that says where the display lines begin. As the window really isn't displayed the display structures are empty and thus point_in_line_start_cache does a quick minimal redisplay (without actually updating the screen), that is the call to update_line_start_cache on line 7254. As the cache is empty it hits this code. while (startp < old_lb || low_bound == -1) { int ic_elt; Bufpos new_startp; regenerate_window (w, startp, point, CMOTION_DISP); update_internal_cache_list (w, CMOTION_DISP); regenerate_window does that redisplaying.. However only the modeline is displayed. update_internal_cache_list then copies all info form the redisplay structures to a temporary working copy of the line start cache. However as there aren't any real buffer lines displayed there is no info to copy and the cache stays empty. That turns to be a known problem /* If this assert is triggered then regenerate_window failed to layout a single line. That is not supposed to be possible because we impose a minimum height on the buffer and override vertical clip when we are in here. */ /* #### Ah, but it is because the window may temporarily exist but not have any lines at all if the minibuffer is real big. Look into that situation better. */ if (!Dynarr_length (internal_cache)) { if (old_lb == -1 && low_bound == -1) { updating_line_start_cache = 0; w->line_cache_validation_override--; return; } and thus update_line_start_cache returns without doing anything and leaving the cache empty. Then point_in_line_start_cache returns "-1" because the value of window-start couldn't be find in the buffer. This then triggers the abort. The question is now how to solve it. Should we enforce the conditions that part of a window should always be displayed? Should we remove the abort and return a sensible guess? Should generate_window be fixed to always layout a line regardless of whether it fixed? Additionally, I see no gutter code in pixel_to_glyph_translation, is that correct? Andy? Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 13:54:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA29248 for xemacs-beta-out; Thu, 4 Nov 1999 13:54:10 -0500 Received: from macon.informatik.uni-tuebingen.de (macon.Informatik.Uni-Tuebingen.De [134.2.12.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA29245 for ; Thu, 4 Nov 1999 13:54:08 -0500 Received: from informatik.uni-tuebingen.de (brabantio.Informatik.Uni-Tuebingen.De [134.2.12.25]) by macon.informatik.uni-tuebingen.de (8.9.3/8.9.1) with ESMTP id TAA21496 for ; Thu, 4 Nov 1999 19:54:06 +0100 Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id TAA23626; Thu, 4 Nov 1999 19:54:04 +0100 To: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: <14369.53043.459000.631229@glynn.ingames.com> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 04 Nov 1999 19:54:03 +0100 In-Reply-To: Glynn Clements's message of "Thu, 4 Nov 1999 19:23:44 +0100 (GMT--1:00)" Message-ID: Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id NAA29246 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Glynn" == Glynn Clements writes: Glynn> Michael Sperber [Mr. Preprocessor] wrote: >> All excellent answers. (Thanks, Jan!) They still doesn't answer the >> basic question why I can't rebind this key inside XEmacs, when I can >> rebind every other key. Glynn> Why you can't rebind what key? 'backspace or [(control ?h)]? Well, (global-set-key 'backspace 'delete-backward-char) doesn't cut the mustard. Despite "stty erase ^?". However, (global-set-key "\C-h" 'delete-backward-char) works. Does 'backspace correspond to the event generated by the erase character? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Nov 4 14:12:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29838 for xemacs-beta-out; Thu, 4 Nov 1999 14:12:42 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA29833 for ; Thu, 4 Nov 1999 14:12:40 -0500 Received: (qmail 30119 invoked from network); 4 Nov 1999 19:11:24 -0000 Received: from usrpri2-2.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.67) by biff.kiva.net with SMTP; 4 Nov 1999 19:11:24 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA02287; Thu, 4 Nov 1999 14:14:15 -0500 To: xemacs-beta@xemacs.org Subject: I thought someone had made widget/custom use native widgets? X-Now-Listening-To: Tom Petty & The Heartbreakers - About To Give Out Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I don't see anything but the older pixmap-based buttons. Updated all my packages, etc, using the latest CVS. Am I misremembering? -bp From owner-xemacs-beta@xemacs.org Thu Nov 4 14:23:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA30145 for xemacs-beta-out; Thu, 4 Nov 1999 14:23:06 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA30141 for ; Thu, 4 Nov 1999 14:23:03 -0500 Received: by crystal.WonderWorks.COM id QQhnxl25785; Thu, 4 Nov 1999 11:23:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14369.56596.600777.582496@crystal.WonderWorks.COM> Date: Thu, 4 Nov 1999 11:23:00 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: Large lisp chars and big XEmacs buffers In-Reply-To: References: <19991027162400.B343@nemesis.ncsl.nist.gov> <3817C64A.E78366DF@666.com> <19991028035922.A2136@nemesis.ncsl.nist.gov> <38196718.E875D524@666.com> <19991029182217.B19557@nemesis.ncsl.nist.gov> <14362.37496.905536.411227@turnbull.sk.tsukuba.ac.jp X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > "Stephen J. Turnbull" writes: > > > Jan> But surely diff would have an > > Jan> --ignore-unicode-composing-differences and this would default > > Jan> to on? > > > > This is a joke, right? Unicode changes, non-GNU diffs, non-diff > > comparison programs, .... > > No, I am dead serious. Diff compares text files, if your text encoding > has various encodings for the same thing it needs to deal with that. Please explain Unicode composing differences for the Unicode ignoramuses among us. Is this some kind of overstriking convention used to build complex glyphs, where you can permute the code order and achieve the same glyph. Or what? From owner-xemacs-beta@xemacs.org Thu Nov 4 15:03:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA31762 for xemacs-beta-out; Thu, 4 Nov 1999 15:03:49 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA31752; Thu, 4 Nov 1999 15:03:43 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA25281; Thu, 4 Nov 1999 21:03:37 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006Az; Thu Nov 4 21:03:26 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA16996; Thu, 4 Nov 1999 21:03:26 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 04 Nov 1999 21:03:26 +0100 In-Reply-To: wmperry@aventail.com's message of "04 Nov 1999 12:01:08 -0500" Message-ID: Lines: 36 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Here is a reworked version of the GPM support. This is equivalent > functionality-wise to the current implementation, but does not sink its > teeth into all the console and event loops like the old one. Cool... The patch is mangled however. It has broken lines and there is the tab vs space problem. > ----------------- > `gpm-mode' is a built-in function > (gpm-mode &optional ARG) How do you suppose this gets enabled? I would love for this to be still the default. > - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { > - select_filedesc (mousefd, console); > } > - } > -#endif > -} You really don't want to delete that brace. However if you want to progress from mere coolness to utter enlightenment then you should 0. make sure the case when we have frames on more than one VC works 1. make sure the xterm mouse stuff works. 2. [Bonus points] include the xterm only file that libgpm supports in the source so that if you are not on Linux you still get xterm mouse support. 3. Make XEmacs support the GPM selection protocol. Jan From owner-xemacs-beta@xemacs.org Thu Nov 4 15:43:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA00593 for xemacs-beta-out; Thu, 4 Nov 1999 15:43:21 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id PAA00581 for ; Thu, 4 Nov 1999 15:43:19 -0500 Received: (qmail 11723 invoked from network); 4 Nov 1999 20:42:02 -0000 Received: from usrpri2-2.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.67) by biff.kiva.net with SMTP; 4 Nov 1999 20:42:02 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id PAA11800; Thu, 4 Nov 1999 15:44:53 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Reworked GPM support... X-Now-Listening-To: Tom Petty & The Heartbreakers - About To Give Out References: <867ljyi42z.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 59 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > Here is a reworked version of the GPM support. This is equivalent > > functionality-wise to the current implementation, but does not sink its > > teeth into all the console and event loops like the old one. > > Cool... The patch is mangled however. It has broken lines and there is > the tab vs space problem. Tabs are your friend. :) > > ----------------- > > `gpm-mode' is a built-in function > > (gpm-mode &optional ARG) > > How do you suppose this gets enabled? I would love for this to be still > the default. We could throw a call to it in syms_of_gpmevent() if you want. > > - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { > > - select_filedesc (mousefd, console); > > } > > - } > > -#endif > > -} > > You really don't want to delete that brace. But there's an extra one from up above - everything balances out, it just looks a little odd. :) > However if you want to progress from mere coolness to utter > enlightenment then you should > > 0. make sure the case when we have frames on more than one VC works > 1. make sure the xterm mouse stuff works. There is no way to get this working using GPM, because it requires you to use a GPM function to read characters from the terminal, and it deals with cooking them into GPM events or really passing them back to you. > 2. [Bonus points] include the xterm only file that libgpm supports in > the source so that if you are not on Linux you still get xterm > mouse support. Now that Hrvoje made make-event actually useful, we could port xt-mouse.el from Emacs. It works off of function-key-map, and in trivial testing right now, it mostly works. Just a few functions missing in XEmacs (window-at, coordinates-in-window-p), but that should be easy to work around. > 3. Make XEmacs support the GPM selection protocol. Where is this documented? I couldn't find anything in the GPM headers or documentation. -Bill P. From owner-xemacs-beta@xemacs.org Thu Nov 4 16:59:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA03447 for xemacs-beta-out; Thu, 4 Nov 1999 16:59:59 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA03442 for ; Thu, 4 Nov 1999 16:59:50 -0500 Received: by crystal.WonderWorks.COM id QQhnxv28340; Thu, 4 Nov 1999 13:59:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14370.467.720486.430849@crystal.WonderWorks.COM> Date: Thu, 4 Nov 1999 13:59:47 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? In-Reply-To: <86n1su1oxl.fsf@megalith.bp.aventail.com> References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> <86n1su1oxl.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: William M. Perry writes: > Jan Vroonhof writes: > > > wmperry@aventail.com (William M. Perry) writes: > > > > > And it actually seems to work. Unfortunately there is no > > > CONSOLE_NO_LONGER_HAS_METHOD(...) macro to go with it. :) > > > > Just call CONSOLE_HAS_METHOD with a NULL method value? > > Nope, that's not how it works - you tell it what method and it > automatically constructs the function name from the console type (tty) and > method name (set_mouse_position). I just cheat a little and set the method > slots directly. I think you're running into problem because you're piggybacking GPM support on top of the tty console. The console init code is not designed with a run-time variable feature set in mind. I think GPM-enabled ttys should be a separate console type. From owner-xemacs-beta@xemacs.org Thu Nov 4 18:57:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA06992 for xemacs-beta-out; Thu, 4 Nov 1999 18:57:16 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA06988; Thu, 4 Nov 1999 18:57:10 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id PAA22270; Thu, 4 Nov 1999 15:56:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14370.7477.417869.254425@lasker.666.com> Date: Thu, 4 Nov 1999 15:56:37 -0800 (PST) From: Martin Buchholz To: Stef Epardaud , Andy Piper , "Edward A. Falk" Cc: xemacs-beta@xemacs.org Subject: Re: compiler warnings mess In-Reply-To: <19991104112657.A22485@tanglefoot.lunatech.com> References: <19991103175234.A4872@faerie.whatever.org> <14369.18398.863185.115614@lasker.666.com> <19991104112657.A22485@tanglefoot.lunatech.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stef, thanks for your work. >>>>> "Stef" == Stef Epardaud writes: Stef> On Thu, Nov 04, 1999 at 11:14:02AM +0100, Jan Vroonhof wrote: >> Martin Buchholz writes: >> >> > It seems that you have examined the warnings in 21.1.7. >> >> His patch has a xlwtabs in it, seems to be for 21.2. Stef> yes, so far i am updating from cvs for 21.2 and i get a 21.2 when i Stef> compile :-/ what makes you think it was for 21.1 ? Stef> i mean... i am not a guru in C like you guys are, abd yes i do mistakes Stef> and i am clumbsy in my mails, ... but i really think it is 21.2 ;) Stef> or the world is plotting against me and i am in the matrix, they try to Stef> make me think it is the latest, but in fact it is only a version Stef> maintained by computers to keep me in line ! ;) We all make mistakes. I thought you were looking at 21.1. My mistake. >> >> > Currently, the warnings we get in the src directory in 21.2 are as >> > follows: >> >> Yes, but he fixes stuff in the other directories. That is important >> too. (if you do a full make you see those too). >> Stef> basicly it is very small stuff and some things commented in xlwtabs Stef> because probably the code is under devel and some variables are declared Stef> but not initialized yet, but it does get rid of ten of the 15 total Stef> warnings i get when compiling XEmacs 21.2 from scratch. The work in xlwtabs.c orginates outside of XEmacs (Tabs widget by "Edward A. Falk ") and is being imported into XEmacs by "Andy Piper ". A number of warnings have already been fixed, and I have communicated with them about the remaining ones. Andy and Ed, please look at Stef's patch for xlwtabs.c. The work in etags.c originates outside of XEmacs (the etags package by "Francesco Potorti` ". I communicate occasionally with Francesco. A new import of Francesco's code is due soon (I will do this, please do not start) from ftp://fly.cnuce.cnr.it/pub/. Please don't fix warnings in etags.c. If you find a real bug, see if it is fixed in Francesco's latest code at his ftp site. Stef, you'll be happy to know that I applied your warning suppression patch to mule-ccl.c and gnuserv.c in 21.2. Martin From owner-xemacs-beta@xemacs.org Thu Nov 4 19:48:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA08234 for xemacs-beta-out; Thu, 4 Nov 1999 19:48:49 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id TAA08231 for ; Thu, 4 Nov 1999 19:48:48 -0500 Received: (qmail 28874 invoked from network); 5 Nov 1999 00:47:31 -0000 Received: from usrpri2-2.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.67) by biff.kiva.net with SMTP; 5 Nov 1999 00:47:31 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id TAA01611; Thu, 4 Nov 1999 19:50:22 -0500 To: Kyle Jones Cc: xemacs-beta@xemacs.org Subject: Re: Is it ok to call CONSOLE_HAS_METHOD() after initialization? X-Now-Listening-To: Insane Clown Posse - Under The Moon References: <86r9i7w8uf.fsf@megalith.bp.aventail.com> <19991103191306.C32122@nemesis.ncsl.nist.gov> <86iu3jaw8x.fsf@megalith.bp.aventail.com> <86n1su1oxl.fsf@megalith.bp.aventail.com> <14370.467.720486.430849@crystal.WonderWorks.COM> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 27 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > William M. Perry writes: > > Jan Vroonhof writes: > > > > > wmperry@aventail.com (William M. Perry) writes: > > > > > > > And it actually seems to work. Unfortunately there is no > > > > CONSOLE_NO_LONGER_HAS_METHOD(...) macro to go with it. :) > > > > > > Just call CONSOLE_HAS_METHOD with a NULL method value? > > > > Nope, that's not how it works - you tell it what method and it > > automatically constructs the function name from the console type (tty) and > > method name (set_mouse_position). I just cheat a little and set the method > > slots directly. > > I think you're running into problem because you're piggybacking GPM > support on top of the tty console. The console init code is not designed > with a run-time variable feature set in mind. I think GPM-enabled ttys > should be a separate console type. *shudder* I don't wanna write it. :) Since there is no way to set the GPM mouse position, and the getting of it is very unreliable, I'm probably just going to punt on setting those methods anyway. -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 5 00:49:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA15971 for xemacs-beta-out; Fri, 5 Nov 1999 00:49:29 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id AAA15964 for ; Fri, 5 Nov 1999 00:49:27 -0500 Received: (qmail 22890 invoked by alias); 5 Nov 1999 05:49:24 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 22858 invoked by uid 0); 5 Nov 1999 05:49:23 -0000 Received: from dialupa147.tcsn.uswest.net (HELO 666.com) (209.180.113.147) by tcsnpop1.tcsn.uswest.net with SMTP; 5 Nov 1999 05:49:23 -0000 Message-ID: <38226FC5.6AE12680@666.com> Date: Thu, 04 Nov 1999 22:48:53 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: Jan Vroonhof , xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> <86u2n2c7ga.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "William M. Perry" wrote: > Jan Vroonhof writes: > > > wmperry@aventail.com (William M. Perry) writes: > > > > > Here is a reworked version of the GPM support. This is equivalent > > > functionality-wise to the current implementation, but does not sink its > > > teeth into all the console and event loops like the old one. > > > > Cool... The patch is mangled however. It has broken lines and there is > > the tab vs space problem. > > Tabs are your friend. :) > > > > ----------------- > > > `gpm-mode' is a built-in function > > > (gpm-mode &optional ARG) > > > > How do you suppose this gets enabled? I would love for this to be still > > the default. > > We could throw a call to it in syms_of_gpmevent() if you want. No -- you need to create a separate init_gpmevent() function. ben From owner-xemacs-beta@xemacs.org Fri Nov 5 04:08:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA19785 for xemacs-beta-out; Fri, 5 Nov 1999 04:08:30 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA19782 for ; Fri, 5 Nov 1999 04:08:26 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA10298; Fri, 5 Nov 1999 10:08:21 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002Ws; Fri Nov 5 10:08:13 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA17120; Fri, 5 Nov 1999 10:08:12 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> <86u2n2c7ga.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 05 Nov 1999 10:08:12 +0100 In-Reply-To: wmperry@aventail.com's message of "04 Nov 1999 15:44:53 -0500" Message-ID: Lines: 36 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > > Cool... The patch is mangled however. It has broken lines and there is > > the tab vs space problem. > > Tabs are your friend. :) Tabs are evil. However regardless of that you should never re-/untabify the result of diff because patch thinks there are difference and won't apply the chunk. Neither of course should you break lines. I failed hand applying your patch (i.e. get weird errors where the DEFSUBR in syms_of_gpmevent calls assert). Could you please make a new patch? > > How do you suppose this gets enabled? I would love for this to be still > > the default. > > We could throw a call to it in syms_of_gpmevent() if you want. I was rather thinking of a function to call in after make-device on a tty. BTW I don't like the idea of making gpm-mode a C function. You really should do the interface in lisp. Then you can much easier do things like call hooks and avoid loading the C module if we are not on a linux tty etc. > > 0. make sure the case when we have frames on more than one VC works > > There is no way to get this working using GPM, because it requires you to > use a GPM function to read characters from the terminal :-( Jan From owner-xemacs-beta@xemacs.org Fri Nov 5 05:37:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA21047 for xemacs-beta-out; Fri, 5 Nov 1999 05:37:32 -0500 Received: from nirvana.ingames.com (nirvana.ingames.no [195.159.15.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA21034 for ; Fri, 5 Nov 1999 05:37:06 -0500 Received: from glynn.ingames.com ([195.159.15.204]) by nirvana.ingames.com (8.8.7/8.8.7) with SMTP id LAA31485; Fri, 5 Nov 1999 11:39:41 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14370.45946.379000.879846@glynn.ingames.com> Date: Fri, 5 Nov 1999 11:37:43 +0100 (GMT--1:00) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? In-Reply-To: References: <14369.53043.459000.631229@glynn.ingames.com> X-Mailer: VM 6.67 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote: > >> All excellent answers. (Thanks, Jan!) They still doesn't answer the > >> basic question why I can't rebind this key inside XEmacs, when I can > >> rebind every other key. > > Glynn> Why you can't rebind what key? 'backspace or [(control ?h)]? > > Well, > > (global-set-key 'backspace 'delete-backward-char) > > doesn't cut the mustard. Despite "stty erase ^?". But does your backspace key generate \177? > However, > > (global-set-key "\C-h" 'delete-backward-char) > > works. Which it probably shouldn't if your backspace key generates \177. > Does 'backspace correspond to the event generated by the erase > character? character_to_event translates the code which matches tty-erase-char to 'backspace, provided that the do_backspace_mapping parameter is true (note that this is always the case when called from Fcharacter_to_event). tty-erase-char should be initalised to the terminal's erase setting. The default mapping (if tty-erase-char is nil) is that \177 is mapped to 'delete and \010 is mapped to [(control ?h)]. IOW, nothing will generate 'backspace. You can determine what is coming out of character_to_event using M-: (next-event) -- Glynn Clements From owner-xemacs-beta@xemacs.org Fri Nov 5 06:08:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA21781 for xemacs-beta-out; Fri, 5 Nov 1999 06:08:05 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA21778 for ; Fri, 5 Nov 1999 06:08:02 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA19053; Fri, 5 Nov 1999 12:08:01 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004dZ; Fri Nov 5 12:07:52 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA17367; Fri, 5 Nov 1999 12:07:52 +0100 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Stupid question: How to get Backspace working in TTY mode? References: <14369.53043.459000.631229@gly From: Jan Vroonhof Date: 05 Nov 1999 12:07:51 +0100 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "04 Nov 1999 19:54:03 +0100" Message-ID: Lines: 18 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > (global-set-key 'backspace 'delete-backward-char) > > doesn't cut the mustard. Despite "stty erase ^?". That is exactly the problem. It should be "stty erase ^h" > However, > > (global-set-key "\C-h" 'delete-backward-char) > > works. Does 'backspace correspond to the event generated by the erase > character? Bingo! Jan From owner-xemacs-beta@xemacs.org Fri Nov 5 06:16:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA22075 for xemacs-beta-out; Fri, 5 Nov 1999 06:16:28 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA22072 for ; Fri, 5 Nov 1999 06:16:26 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA19212; Fri, 5 Nov 1999 12:16:21 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004g3; Fri Nov 5 12:16:20 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA17369; Fri, 5 Nov 1999 12:16:20 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: I thought someone had made widget/custom use native widgets? References: <863dumvzll.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 05 Nov 1999 12:16:20 +0100 In-Reply-To: wmperry@aventail.com's message of "04 Nov 1999 14:14:14 -0500" Message-ID: Lines: 8 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > I don't see anything but the older pixmap-based buttons. Updated all my > packages, etc, using the latest CVS. Am I misremembering? Currently only make-gui-button has been made native. Jan From owner-xemacs-beta@xemacs.org Fri Nov 5 10:23:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27337 for xemacs-beta-out; Fri, 5 Nov 1999 10:23:38 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA27327 for ; Fri, 5 Nov 1999 10:23:36 -0500 Received: (qmail 13442 invoked from network); 5 Nov 1999 15:22:19 -0000 Received: from usrpri2-6.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.71) by biff.kiva.net with SMTP; 5 Nov 1999 15:22:19 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA03279; Fri, 5 Nov 1999 10:25:10 -0500 To: Ben Wing Cc: Jan Vroonhof , xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> <86u2n2c7ga.fsf@megalith.bp.aventail.com> <38226FC5.6AE12680@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 34 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > "William M. Perry" wrote: > > > Jan Vroonhof writes: > > > > > wmperry@aventail.com (William M. Perry) writes: > > > > > > > Here is a reworked version of the GPM support. This is equivalent > > > > functionality-wise to the current implementation, but does not sink its > > > > teeth into all the console and event loops like the old one. > > > > > > Cool... The patch is mangled however. It has broken lines and there is > > > the tab vs space problem. > > > > Tabs are your friend. :) > > > > > > ----------------- > > > > `gpm-mode' is a built-in function > > > > (gpm-mode &optional ARG) > > > > > > How do you suppose this gets enabled? I would love for this to be still > > > the default. > > > > We could throw a call to it in syms_of_gpmevent() if you want. > > No -- you need to create a separate init_gpmevent() function. I'll work on changing the C code to be more of a toggle-gpm-mode, and write a gpm.el to go along with this, and it can take care of starting up gpm automatically, etc. It should also add hooks to suspend/resume emacs to let the main gpm program handle things. -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 5 10:23:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27339 for xemacs-beta-out; Fri, 5 Nov 1999 10:23:39 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA27331 for ; Fri, 5 Nov 1999 10:23:37 -0500 Received: (qmail 13414 invoked from network); 5 Nov 1999 15:22:17 -0000 Received: from usrpri2-6.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.71) by biff.kiva.net with SMTP; 5 Nov 1999 15:22:17 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA03274; Fri, 5 Nov 1999 10:25:08 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> <86u2n2c7ga.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 62 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > > Cool... The patch is mangled however. It has broken lines and there is > > > the tab vs space problem. > > > > Tabs are your friend. :) > > Tabs are evil. However regardless of that you should never re-/untabify > the result of diff because patch thinks there are difference and won't > apply the chunk. Neither of course should you break lines. I didn't - I just tabified gpmevent.c. Although I did use 'cvs diff -uw' to ignore whitespace changes. Perhaps I'll leave off the 'w' on the next round of patches. > Could you please make a new patch? I'll try to get one later today. I'm trying to get pasting from the internal linux buffers working. I'm a little lost as to how the selection methods work though. I created tty_get_foreign_selection, which does the appropriate ioctl() to write to the console (not exactly what I want, but I think I can slap a memory-lstream onto DEVICE_INFD temporarily, do the ioctl, and return the data in the lstream as a string). But hitting button2 doesn't do anything. Calling (get-selection-internal nil 'string) does work though. > > > How do you suppose this gets enabled? I would love for this to be still > > > the default. > > > > We could throw a call to it in syms_of_gpmevent() if you want. > > I was rather thinking of a function to call in after make-device on a > tty. BTW I don't like the idea of making gpm-mode a C function. You > really should do the interface in lisp. Then you can much easier do > things like call hooks and avoid loading the C module if we are not on a > linux tty etc. I'll work on changing it early this morning, before work gets into full swing. > > > 0. make sure the case when we have frames on more than one VC works > > > > There is no way to get this working using GPM, because it requires you to > > use a GPM function to read characters from the terminal > > :-( But, it should be relatively easy to do with function-key-map. I don't know if I'll have time or inclination to get this to work (I never use XEmacs in an xterm, so...) I'm attaching the latest version of xt-mouse.el - it works in emacs 20.x, and gets so far as to call the right function when you move the mouse or push buttons in XEmacs, but then the translation function chokes. -Bill P. --=-=-= Content-Disposition: attachment; filename=xt-mouse.el ;;; xt-mouse.el --- Support the mouse when emacs run in an xterm. ;; Copyright (C) 1994 Free Software Foundation ;; Author: Per Abrahamsen ;; Keywords: mouse, terminals ;; 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, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;;; Comments: ;; Enable mouse support when running inside an xterm or Linux console. ;; This is actually useful when you are running X11 locally, but is ;; working on remote machine over a modem line or through a gateway. ;; It works by translating xterm escape codes into generic emacs mouse ;; events so it should work with any package that uses the mouse. ;; The xterm mouse escape codes are supposedly also supported by the ;; Linux console, but I have not been able to verify this. ;; You don't have to turn off xterm mode to use the normal xterm mouse ;; functionality, it is still available by holding down the SHIFT key ;; when you press the mouse button. ;;; Todo: ;; Support multi-click -- somehow. ;; Clicking on the mode-line does not work, although it should. ;;; Code: (define-key function-key-map "\e[M" 'xterm-mouse-translate) (defvar xterm-mouse-last) (defun xterm-mouse-translate (event) ;; Read a click and release event from XTerm. (save-excursion (save-window-excursion (deactivate-mark) (let* ((xterm-mouse-last) (down (xterm-mouse-event)) (down-command (nth 0 down)) (down-data (nth 1 down)) (down-where (nth 1 down-data)) (down-binding (key-binding (if (symbolp down-where) (vector down-where down-command) (vector down-command))))) (or (and (eq (read-char) ?\e) (eq (read-char) ?\[) (eq (read-char) ?M)) (error "Unexpected escape sequence from XTerm")) (let* ((click (xterm-mouse-event)) (click-command (nth 0 click)) (click-data (nth 1 click)) (click-where (nth 1 click-data))) (if (memq down-binding '(nil ignore)) (if (and (symbolp click-where) (not (eq 'menu-bar click-where))) (vector (list click-where click-data) click) (vector click)) (setq unread-command-events (if (eq down-where click-where) (list click) (list ;; Cheat `mouse-drag-region' with move event. (list 'mouse-movement click-data) ;; Generate a drag event. (if (symbolp down-where) 0 (list (intern (format "drag-mouse-%d" (+ 1 xterm-mouse-last))) down-data click-data)) ))) (if (and (symbolp down-where) (not (eq 'menu-bar down-where))) (vector (list down-where down-data) down) (vector down)))))))) (defvar xterm-mouse-x 0 "Position of last xterm mouse event relative to the frame.") (defvar xterm-mouse-y 0 "Position of last xterm mouse event relative to the frame.") ;; Indicator for the xterm-mouse mode. (defvar xterm-mouse-mode nil) (defadvice mouse-position (around xterm-mouse activate) "Use last key from xterm-mouse-mode if available." (let ((answer ad-do-it)) (setq ad-return-value (if xterm-mouse-mode (cons (car answer) (cons xterm-mouse-x xterm-mouse-y)) answer)))) (defun xterm-mouse-event () ;; Convert XTerm mouse event to Emacs mouse event. (let* ((type (- (read-char) ? )) (x (- (read-char) ? 1)) (y (- (read-char) ? 1)) (point (cons x y)) (window (window-at x y)) (where (if window (coordinates-in-window-p point window) 'menu-bar)) (pos (if (consp where) (progn (select-window window) (goto-char (window-start window)) (move-to-window-line (cdr where)) (move-to-column (+ (car where) (current-column) (if (string-match "\\` \\*Minibuf" (buffer-name)) (- (minibuffer-prompt-width)) 0) (max 0 (1- (window-hscroll))))) (point)) where)) (mouse (intern (if (eq type 3) (format "mouse-%d" (+ 1 xterm-mouse-last)) (setq xterm-mouse-last type) (format "down-mouse-%d" (+ 1 type)))))) (setq xterm-mouse-x x xterm-mouse-y y) (list mouse (list window pos point (/ (nth 2 (current-time)) 1000))))) (or (assq 'xterm-mouse-mode minor-mode-alist) (setq minor-mode-alist (cons '(xterm-mouse-mode (" Mouse")) minor-mode-alist))) ;;;###autoload (defun xterm-mouse-mode (arg) "Toggle XTerm mouse mode. With prefix arg, turn XTerm mouse mode on iff arg is positive. Turn it on to use emacs mouse commands, and off to use xterm mouse commands." (interactive "P") (if (or (and (null arg) xterm-mouse-mode) (<= (prefix-numeric-value arg) 0)) ;; Turn it off (if xterm-mouse-mode (progn (turn-off-xterm-mouse-tracking) (setq xterm-mouse-mode nil) (set-buffer-modified-p (buffer-modified-p)))) ;;Turn it on (if xterm-mouse-mode () (setq xterm-mouse-mode t) (turn-on-xterm-mouse-tracking) (set-buffer-modified-p (buffer-modified-p))))) (defun turn-on-xterm-mouse-tracking () ;; Enable emacs mouse tracking in xterm. (if xterm-mouse-mode (send-string-to-terminal "\e[?1000h"))) (defun turn-off-xterm-mouse-tracking () ;; Disable disable emacs mouse tracking in xterm. (if xterm-mouse-mode (send-string-to-terminal "\e[?1000l"))) ;; Restore normal mouse behaviour outside Emacs. (add-hook 'suspend-hook 'turn-off-xterm-mouse-tracking) (add-hook 'suspend-resume-hook 'turn-on-xterm-mouse-tracking) (add-hook 'kill-emacs-hook 'turn-off-xterm-mouse-tracking) (provide 'xt-mouse) ;;; xt-mouse.el ends here --=-=-=-- From owner-xemacs-beta@xemacs.org Fri Nov 5 10:36:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27761 for xemacs-beta-out; Fri, 5 Nov 1999 10:36:26 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA27758 for ; Fri, 5 Nov 1999 10:36:22 -0500 Received: (qmail 19263 invoked from network); 5 Nov 1999 15:35:00 -0000 Received: from usrpri2-6.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.71) by biff.kiva.net with SMTP; 5 Nov 1999 15:35:00 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA03292; Fri, 5 Nov 1999 10:37:52 -0500 To: xemacs-beta@xemacs.org Subject: Another GPM patch... X-Now-Listening-To: Tom Petty & The Heartbreakers - Free Girl Now Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 51 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= This supercedes the last one. I didn't have time this morning to reorganize the C code and write a lisp-level interface for gpm-minor-mode to make it more flexible, but you can now paste from other linux consoles into XEmacs. It's kind of a hack, since the paste code in the linux kernel writes directly to the console. If anyone can think of a better way to do it, please let me know. This is what I do right now: 1) Hook up a filedesc_input_stream to DEVICE_INFD() of the device. 2) Make the filedescriptor non-blocking. I really hate doing this, but there was no other way (that I could find) to make Lstream_read() correctly bail out after reading all the ioctl-inspired data. 3) call { char c = 3; ioctl(fd, TIOCLINUX, &c); } - this actually copies the pasted data into the virtual console's input buffer. 4) Read from the lstream until we stop getting data (<= 0 bytes read), and write the data to a resizing_buffer_stream. 5) flush the buffer stream and make a string out of it 6) kill the streams The reason I dislike #2 so much is that there is no set_descriptor_blocking() function call, but in my testing under linux, it has not proved fatal to leave the descriptor in non-blocking mode. There was also a patch needed to mouse.el - it would just call (yank) if you were not on a window system. I don't know how many other areas like this there are lying around. Unfortunately, I can't see an easy way to make the 'own_selection' method work with the ioctl's that linux provides right now. The ioctl requires the starting and ending positions on screen that you want to copy to the cut buffer, which is nothing like the current XEmacs selection model. With this latest patch, I can cut & paste from a virtual console to XEmacs, and can also select & paste from within emacs. The selection is a little weird, since you don't see the highlighting while the mouse is dragging, but the old GPM code behaved in the same way. The mouse-cursur flickering is still there as well. Anybody have a clue on how to make this better? I could provide a lisp-function to call GPM_DRAWPOINTER and push a magic eval even somewhere, but that seems kind of icky, and I don't think there are any ways to do this type of event mucking outside of event-Xt.c or event-unixoid.c - everything in there is static. I'm not sending this to xemacs-patches until a few more people can try it out. I'd love to get the flicker problem fixed sometime tonight, so if anybody has any ideas, lemme know. -Bill P. --=-=-= Content-Disposition: inline; filename=gpm-patch-2 Index: lisp/mouse.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/mouse.el,v retrieving revision 1.19.2.6 diff -u -r1.19.2.6 mouse.el --- mouse.el 1999/09/02 08:47:55 1.19.2.6 +++ mouse.el 1999/11/05 15:03:12 @@ -88,7 +88,9 @@ the X cutbuffer. A mark is pushed, so that the inserted text lies between point and mark." (interactive) - (if (not (console-on-window-system-p)) + (if (and (not (console-on-window-system-p)) + (and (featurep 'gpm) + (not gpm-minor-mode))) (yank) (push-mark) (if (region-active-p) Index: src/console-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.5 diff -u -r1.18.2.5 console-tty.c --- console-tty.c 1999/10/24 03:48:31 1.18.2.5 +++ console-tty.c 1999/11/05 15:03:15 @@ -38,9 +38,6 @@ #ifdef FILE_CODING #include "file-coding.h" #endif -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif DEFINE_CONSOLE_TYPE (tty); DECLARE_IMAGE_INSTANTIATOR_FORMAT (nothing); @@ -129,10 +126,6 @@ #endif /* MULE */ tty_con->terminal_type = terminal_type; tty_con->controlling_process = controlling_process; - -#ifdef HAVE_GPM - connect_to_gpm (con); -#endif if (NILP (CONSOLE_NAME (con))) CONSOLE_NAME (con) = Ffile_name_nondirectory (tty); Index: src/console-tty.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 console-tty.h --- console-tty.h 1999/02/17 20:03:57 1.8.2.2 +++ console-tty.h 1999/11/05 15:03:15 @@ -41,9 +41,6 @@ struct tty_console { int infd, outfd; -#ifdef HAVE_GPM - int mouse_fd; -#endif Lisp_Object instream, outstream; Lisp_Object terminal_type; Lisp_Object controlling_process; @@ -203,9 +200,6 @@ unsigned int is_stdio :1; }; -#ifdef HAVE_GPM -#define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd) -#endif #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty) #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x) #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y) Index: src/device-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-tty.c,v retrieving revision 1.9 diff -u -r1.9 device-tty.c --- device-tty.c 1998/05/27 20:42:00 1.9 +++ device-tty.c 1999/11/05 15:03:15 @@ -38,10 +38,6 @@ #include "syssignal.h" /* for SIGWINCH */ -#ifdef HAVE_GPM -#include -#endif - #include Lisp_Object Qinit_pre_tty_win, Qinit_post_tty_win; @@ -155,15 +151,6 @@ CONSOLE_TTY_DATA (con)->width = width; CONSOLE_TTY_DATA (con)->height = height; -#ifdef HAVE_GPM - /* We need to tell GPM how big our screen is now - ** I am pretty sure the GPM library will get incredibly confused - ** if you try to connect to more than one mouse-capable device, - ** so I don't think it will cause any more damage in that case. - */ - gpm_mx = width; - gpm_my = height; -#endif for (tail = DEVICE_FRAME_LIST (d); !NILP (tail); tail = XCDR (tail)) Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/05 15:03:23 @@ -1088,6 +1088,10 @@ syms_of_eldap (); #endif +#ifdef HAVE_GPM + syms_of_gpmevent (); +#endif + /* Now create the subtypes for the types that have them. We do this before the vars_*() because more symbols may get initialized here. */ @@ -1481,6 +1485,10 @@ #ifdef HAVE_LDAP vars_of_eldap (); +#endif + +#ifdef HAVE_GPM + vars_of_gpmevent (); #endif /* Now initialize any specifier variables. We do this later Index: src/event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.14 diff -u -r1.41.2.14 event-Xt.c --- event-Xt.c 1999/10/10 11:45:15 1.41.2.14 +++ event-Xt.c 1999/11/05 15:03:30 @@ -2034,9 +2034,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2044,22 +2041,6 @@ infd = event_stream_unixoid_select_console (con); XSETCONSOLE (console, con); select_filedesc (infd, console); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - /* We check filedesc_to_what_closure[fd] here because if you run - ** XEmacs from a TTY, it will fire up GPM, select the mouse fd, then - ** if you run gnuattach to connect to another TTY, it will fire up - ** GPM again, and try to reselect the mouse fd. GPM uses the same - ** fd for every connection apparently, and select_filedesc will - ** fail its assertion if we try to select it twice. - */ - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { - select_filedesc (mousefd, console); - } - } -#endif } static void @@ -2067,9 +2048,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2077,15 +2055,6 @@ infd = event_stream_unixoid_unselect_console (con); XSETCONSOLE (console, con); unselect_filedesc (infd); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - if (mousefd >= 0) { - unselect_filedesc (mousefd); - } - } -#endif } /* read an event from a tty, if one is available. Returns non-zero Index: src/event-unixoid.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-unixoid.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 event-unixoid.c --- event-unixoid.c 1999/03/07 15:25:17 1.9.2.1 +++ event-unixoid.c 1999/11/05 15:03:30 @@ -41,10 +41,6 @@ #include "sysproc.h" /* select stuff */ #include "systime.h" -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif - /* Mask of bits indicating the descriptors that we wait for input on. These work as follows: @@ -83,12 +79,6 @@ Lisp_Object console; XSETCONSOLE (console, con); - -#ifdef HAVE_GPM - if (fd == CONSOLE_TTY_MOUSE_FD (con)) { - return handle_gpm_read (event,con,fd); - } -#endif nread = read (fd, &ch, 1); if (nread <= 0) Index: src/frame-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame-tty.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 frame-tty.c --- frame-tty.c 1998/12/05 16:55:48 1.8.2.1 +++ frame-tty.c 1999/11/05 15:03:31 @@ -33,10 +33,6 @@ #include "events.h" -#ifdef HAVE_GPM -#include -#endif - /* Default properties to use when creating frames. */ Lisp_Object Vdefault_tty_frame_plist; @@ -86,33 +82,6 @@ call1 (Qinit_post_tty_win, FRAME_CONSOLE (f)); } -#ifdef HAVE_GPM -static int -tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) -{ - Gpm_Event ev; - int num_buttons; - - num_buttons = Gpm_GetSnapshot(&ev); - *x = ev.x; - *y = ev.y; - *frame = DEVICE_SELECTED_FRAME (d); - return (1); -} - -static void -tty_set_mouse_position (struct window *w, int x, int y) -{ - /* XXX - I couldn't find any GPM functions that set the mouse position. - Mr. Perry had left this function empty; that must be why. - karlheg - */ -} - -#endif - - /* Change from withdrawn state to mapped state. */ static void tty_make_frame_visible (struct frame *f) @@ -223,10 +192,6 @@ CONSOLE_HAS_METHOD (tty, init_frame_1); CONSOLE_HAS_METHOD (tty, init_frame_3); CONSOLE_HAS_METHOD (tty, after_init_frame); -#ifdef HAVE_GPM - CONSOLE_HAS_METHOD (tty, get_mouse_position); - CONSOLE_HAS_METHOD (tty, set_mouse_position); -#endif CONSOLE_HAS_METHOD (tty, make_frame_visible); CONSOLE_HAS_METHOD (tty, make_frame_invisible); CONSOLE_HAS_METHOD (tty, frame_visible_p); Index: src/gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5 diff -u -r1.5 gpmevent.c --- gpmevent.c 1998/03/31 20:11:47 1.5 +++ gpmevent.c 1999/11/05 15:03:31 @@ -1,5 +1,28 @@ -/* William Perry 1997 */ +/* GPM functions + Copyright (C) 1997 William M. Perry + Copyright (C) 1999 Free Software Foundation, Inc. + +This file is part of XEmacs. + +XEmacs 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. + +XEmacs 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 XEmacs; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* Synched up with: Not in FSF. */ + +/* Authors: William Perry */ + #include #include "lisp.h" #include "console.h" @@ -8,11 +31,17 @@ #include "events.h" #include "events-mod.h" #include "sysdep.h" +#include "commands.h" +#include "lstream.h" #ifdef HAVE_GPM #include "gpmevent.h" #include +/* This is commented out in commands.h, I'm not sure why */ +extern Lisp_Object Vunread_command_events; +extern Lisp_Object Vunread_command_event; + #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 @@ -21,94 +50,383 @@ #include #endif -int -handle_gpm_read (struct Lisp_Event *event, struct console *con, int fd) +Lisp_Object Vgpm_minor_mode; + +DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* +Run GPM_GetEvent(). +This function is the process handler for the GPM connection. +*/ + (ignore1, ignore2)) { - Gpm_Event ev; - int modifiers = 0; - int type = -1; - int button = 1; - - if (!Gpm_GetEvent(&ev)) - return 0; - - event->timestamp = 0; - event->channel = CONSOLE_SELECTED_FRAME (con); - - /* Whow, wouldn't named defines be NICE!?!?! */ - modifiers = 0; - - if (ev.modifiers & 1) modifiers |= MOD_SHIFT; - if (ev.modifiers & 2) modifiers |= MOD_META; - if (ev.modifiers & 4) modifiers |= MOD_CONTROL; - if (ev.modifiers & 8) modifiers |= MOD_META; - - if (ev.type & GPM_DOWN) - type = GPM_DOWN; - else if (ev.type & GPM_UP) - type = GPM_UP; - else if (ev.type & GPM_MOVE) { - type = GPM_MOVE; - GPM_DRAWPOINTER(&ev); - } + Gpm_Event ev; + int modifiers = 0; + int type = -1; + int button = 1; + Lisp_Object fake_event; + struct Lisp_Event *event = NULL; + struct gcpro gcpro1; + static int num_events; + + if (!Gpm_GetEvent(&ev)) + { + warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed"); + return(Qzero); + } + + GCPRO1(fake_event); + + num_events++; + + fake_event = Fmake_event (Qnil, Qnil); + event = XEVENT(fake_event); + + event->timestamp = 0; + event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ + + /* Whow, wouldn't named defines be NICE!?!?! */ + modifiers = 0; + + if (ev.modifiers & 1) modifiers |= MOD_SHIFT; + if (ev.modifiers & 2) modifiers |= MOD_META; + if (ev.modifiers & 4) modifiers |= MOD_CONTROL; + if (ev.modifiers & 8) modifiers |= MOD_META; + + if (ev.type & GPM_DOWN) + { + type = GPM_DOWN; + } + else if (ev.type & GPM_UP) + { + type = GPM_UP; + } + else if (ev.type & GPM_MOVE) + { + type = GPM_MOVE; + } + + if (ev.buttons & GPM_B_LEFT) + { + button = 1; + } + else if (ev.buttons & GPM_B_MIDDLE) + { + button = 2; + } + else if (ev.buttons & GPM_B_RIGHT) + { + button = 3; + } + + switch (type) { + case GPM_DOWN: + case GPM_UP: + event->event_type = + type == GPM_DOWN ? button_press_event : button_release_event; + event->event.button.x = ev.x; + event->event.button.y = ev.y; + event->event.button.button = button; + event->event.button.modifiers = modifiers; + break; + case GPM_MOVE: + event->event_type = pointer_motion_event; + event->event.motion.x = ev.x; + event->event.motion.y = ev.y; + event->event.motion.modifiers = modifiers; + default: + /* This will never happen */ + break; + } + + /* Handle the event */ + /* Let's try sticking it on the unread events queue */ + if (!command_event_p (fake_event)) + { + /* unread_command_events does not like motion events */ + Fdispatch_event (fake_event); + } + else if (NILP (Vunread_command_events)) + { + Vunread_command_events = Fcons (fake_event, Qnil); + } + else + { + Lisp_Object arg[2]; + arg[0] = Vunread_command_events; + arg[1] = fake_event; - if (ev.buttons & GPM_B_LEFT) - button = 1; - else if (ev.buttons & GPM_B_MIDDLE) - button = 2; - else if (ev.buttons & GPM_B_RIGHT) - button = 3; - - switch (type) { - case GPM_DOWN: - case GPM_UP: - event->event_type = - type == GPM_DOWN ? button_press_event : button_release_event; - event->event.button.x = ev.x; - event->event.button.y = ev.y; - event->event.button.button = button; - event->event.button.modifiers = modifiers; - break; - case GPM_MOVE: - event->event_type = pointer_motion_event; - event->event.motion.x = ev.x; - event->event.motion.y = ev.y; - event->event.motion.modifiers = modifiers; - default: - return 0; - } - return 1; + Vunread_command_events = Fappend (2,arg); + } + + GPM_DRAWPOINTER(&ev); + + UNGCPRO; + + return (Qzero); } -void -connect_to_gpm (struct console *con) +static void turn_off_gpm (void) { - /* Only do this if we are running after dumping and really interactive */ - if (!noninteractive && initialized) { - /* We really only want to do this on a TTY */ - CONSOLE_TTY_MOUSE_FD (con) = -1; - if (EQ (CONSOLE_TYPE (con), Qtty)) { - Gpm_Connect conn; - int rval; - - conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; - conn.defaultMask = GPM_MOVE; - conn.minMod = 0; - conn.maxMod = ((1<get_mouse_position_method = NULL; + tty_console_methods->set_mouse_position_method = NULL; + tty_console_methods->own_selection_method = NULL; + tty_console_methods->get_foreign_selection_method = NULL; +} + +#ifdef TIOCLINUX +static Lisp_Object +tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) +{ + /* This function can GC */ + struct device *d = decode_device (Qnil); + int fd = DEVICE_INFD (d); + char c = 3; + Lisp_Object output_stream; + Lisp_Object terminal_stream; + Lisp_Object output_string; + struct gcpro gcpro1,gcpro2,gcpro3; + + GCPRO3(output_stream,terminal_stream,output_string); + + /* The ioctl() to paste actually puts things in the input queue of + ** the virtual console, so we need to trap that data, since we are + ** supposed to return the actual string selection from this + ** function. + */ + + /* I really hate doing this, but it doesn't seem to cause any + ** problems, and it makes the Lstream_read stuff further down + ** error out correctly instead of trying to indefinitely read from + ** the console. + ** + ** There is no set_descriptor_blocking() function call, but in my + ** testing under linux, it has not proved fatal to leave the + ** descriptor in non-blocking mode. + ** + ** William Perry Nov 5, 1999 + */ + set_descriptor_non_blocking (fd); + + /* We need two streams, one for reading from the selected device, + ** and one to write the data into. There is no writable version + ** of the lisp-string lstream, so we make do with a resizing + ** buffer stream, and make a string out of it after we are + ** done. + */ + output_stream = make_resizing_buffer_output_stream (); + terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); + output_string = Qnil; + + /* We should arguably use a specbind() and an unwind routine here, + ** but I don't care that much right now. + ** ### FIXME? + */ + if (NILP (output_stream) || NILP (terminal_stream)) + { + /* Should we signal an error here? */ + goto out; + } + + if (ioctl (fd, TIOCLINUX, &c) < 0) + { + /* Could not get the selection - eek */ + UNGCPRO; + return (Qnil); + } + + while (1) + { + Bufbyte tempbuf[1024]; /* some random amount */ + int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), + tempbuf, sizeof (tempbuf)); + + if (size_in_bytes <= 0) + { + /* end of the stream */ + break; + } + + Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); + } + + Lstream_flush (XLSTREAM (output_stream)); + + output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), + Lstream_byte_count (XLSTREAM (output_stream))); + + Lstream_delete (XLSTREAM (output_stream)); + Lstream_delete (XLSTREAM (terminal_stream)); + + out: + UNGCPRO; + return (output_string); +} + +static Lisp_Object +tty_selection_exists_p (Lisp_Object selection) +{ + return (Qt); +} +#endif /* TIOCLINUX */ + +#if 0 +static Lisp_Object +tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) +{ + /* There is no way to do this cleanly - the GPM selection + ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and + ** end position on the _screen_, not a string to stick in there. + ** Lame. + ** + ** William Perry Nov 4, 1999 */ +} +#endif + +/* This function appears to work once in a blue moon. I'm not sure +** exactly why either. *sigh* +** William Perry Nov 4, 1999 +*/ +static int +tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) +{ + Gpm_Event ev; + int num_buttons; + + memset(&ev,'\0',sizeof(ev)); + num_buttons = Gpm_GetSnapshot(&ev); + + if (!num_buttons) + { + /* This means there are events pending... */ + return(-1); } + *x = ev.x; + *y = ev.y; + *frame = DEVICE_SELECTED_FRAME (d); + return (1); } +static void +tty_set_mouse_position (struct window *w, int x, int y) +{ + /* XXX + I couldn't find any GPM functions that set the mouse position. + Mr. Perry had left this function empty; that must be why. + karlheg + */ +} + +DEFUN ("gpm-minor-mode", Fgpm_minor_mode, 0, 1, 0, /* +Start accepting GPM mouse events iff ARG is positive. +*/ + (arg)) +{ + Gpm_Connect conn; + int rval; + Lisp_Object gpm_process; + Lisp_Object gpm_filter; + + if (NILP (arg)) + { + /* Toggle current GPM mode */ + if (!NILP (Vgpm_minor_mode)) + { + /* Need to turn it off */ + turn_off_gpm (); + return (Qnil); + } + } + else + { + int i; + + CHECK_INT (arg); + + i = XINT (arg); + + if (i < 0) + { + turn_off_gpm (); + return (Qnil); + } + } + + if (!NILP (Vgpm_minor_mode)) + { + error ("Already connected to GPM"); + } + + if (noninteractive) + { + error ("Can't connect to GPM in batch mode."); + } + + /* Install the mouse position methods for the TTY console type */ + CONSOLE_HAS_METHOD (tty, get_mouse_position); + CONSOLE_HAS_METHOD (tty, set_mouse_position); + +#ifdef TIOCLINUX + CONSOLE_HAS_METHOD (tty, get_foreign_selection); + CONSOLE_HAS_METHOD (tty, selection_exists_p); +#if 0 + CONSOLE_HAS_METHOD (tty, own_selection); #endif +#endif /* TIOCLINUX */ + + conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; + conn.defaultMask = GPM_MOVE; + conn.minMod = 0; + conn.maxMod = ((1<; Fri, 5 Nov 1999 11:49:59 -0500 Received: (from mthomas@localhost) by justresearch.com (8.8.7/8.8.7) id LAA12362; Fri, 5 Nov 1999 11:49:54 -0500 Date: Fri, 5 Nov 1999 11:49:54 -0500 Message-Id: <199911051649.LAA12362@justresearch.com> From: Mark Thomas To: xemacs-beta@xemacs.org Subject: 21.2.19-sneaky: file-variables/enable-local-variables/gutter error Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Sneaky Bastard 19991102" [Lucid] (i686-pc-linux, Mule) of Fri Nov 5 1999 on ulysses.jprc.com configured using `configure --prefix=/home/xemacs/debug --with-png --with-mule' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When (1) I start XEmacs with the -vanilla switch, (2) I'm running under X with gutters visible, (3) I set enable-local-variables to 'ask, and (4) I type C-x C-f /tmp/foo.el where the entire contents of /tmp/foo.el is: -----cut----- ;; Local Variables: *** ;; foo: bar *** ;; End: *** -----cut----- XEmacs gives the warning: (1) (local-variables/warning) File local-variables error: Missing colon in local variables entry and does not set the local variable foo. If I turn off the gutters, or run in TTY mode, or leave enable-local-variables set to t, the local-variable section behaves normally, i.e., foo gets set to bar. Recent keystrokes: M-( e DEL s e t q SPC e n a b l e - l o c a l - v a r i a b l e s SPC ' a s k right C-j C-x C-f / t m p / f o o . e l RET y M-: f o o RET M-x r e p o r t - e m a c s - b TAB RET Recent messages (most recent first): Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Symbol's value as variable is void: foo Set local variables as specified at end of foo.el? (y or n) Yes Set local variables as specified at end of foo.el? (y or n) Loading efs-cu...done Loading efs-cu... From owner-xemacs-beta@xemacs.org Fri Nov 5 12:26:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA32208 for xemacs-beta-out; Fri, 5 Nov 1999 12:26:03 -0500 Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA32198; Fri, 5 Nov 1999 12:25:58 -0500 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id MAA12742; Fri, 5 Nov 1999 12:28:42 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id MAA16116; Fri, 5 Nov 1999 12:21:07 -0500 (EST) Received: from ltrpluim.corpemea.baynetworks.com ([141.251.166.11]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id MAA20207; Fri, 5 Nov 1999 12:25:05 -0500 for Received: (from rpluim@localhost) by ltrpluim.corpemea.baynetworks.com (8.8.7/8.8.7) id SAA24989; Fri, 5 Nov 1999 18:22:58 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OGofXSng4V" Content-Transfer-Encoding: 7bit Message-ID: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> Date: Fri, 5 Nov 1999 18:22:54 +0100 (CET) To: xemacs-patches@xemacs.org CC: xemacs-beta@xemacs.org Subject: Give people with crashes more of a clue X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Attribution: Robert Reply-To: rpluim@bigfoot.com From: rpluim@bigfoot.com Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --OGofXSng4V Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I've finally cracked, I've had it with skip-syntax-backwards crashes on gnu.emacs.xemacs. Polite (for once) patch attached. Recommended for every version of XEmacs in the universe. 1999-11-05 Robert Pluim * emacs.c (shut_down_emacs): Point users to PROBLEMS file --OGofXSng4V Content-Type: text/plain Content-Transfer-Encoding: 7bit Index: emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.92 diff -u -w -u -r1.92 emacs.c --- emacs.c 1999/11/02 04:17:14 1.92 +++ emacs.c 1999/11/05 17:20:06 @@ -2262,12 +2262,16 @@ ("Your files have been auto-saved.\n" "Use `M-x recover-session' to recover them.\n" "\n" + "If you have access to the PROBLEMS file that came with your\n" + "version of XEmacs, please check to see if your crash is described\n" + "there, as there may be a workaround available.\n" #ifdef INFODOCK - "Please report this bug by selecting `Report-Bug' in the InfoDock\n" - "menu.\n" + "Otherwise, please report this bug by selecting `Report-Bug'\n" + "in the InfoDock menu.\n" #else - "Please report this bug by running the send-pr script included\n" - "with XEmacs, or selecting `Send Bug Report' from the help menu.\n" + "Otherwise, please report this bug by running the send-pr\n" + "script included with XEmacs, or selecting `Send Bug Report'\n" + "from the help menu.\n" "As a last resort send ordinary email to `crashes@xemacs.org'.\n" #endif "*MAKE SURE* to include the information in the command\n" --OGofXSng4V Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- The above are my opinions, and my opinions only. --OGofXSng4V-- From owner-xemacs-beta@xemacs.org Fri Nov 5 14:59:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA06023 for xemacs-beta-out; Fri, 5 Nov 1999 14:59:57 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA06019 for ; Fri, 5 Nov 1999 14:59:52 -0500 Received: (qmail 24427 invoked from network); 5 Nov 1999 19:58:33 -0000 Received: from usrpri2-4.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.69) by biff.kiva.net with SMTP; 5 Nov 1999 19:58:33 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id PAA04294; Fri, 5 Nov 1999 15:01:24 -0500 To: xemacs-beta@xemacs.org, ben@666.com Subject: GPM mouse tracking issues solved, kindof X-Now-Listening-To: The Jeff Healey Band - I Can't Get My Hands On You Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I finally figured out a nice clean way to stick the GPM event into the queue, and now everything works, including mouse-tracking when while doing selection, so you get good incremental feedback and all that stuff. I removed the static-ness of enqueue_command_event(). I can't use unread-command-events, because mouse-motion events screw that up. With this approach, everything works beautifully. My question is, is this a completely bad way to achieve my goals? I want to insert arbitrary events into the data stream from outside event-stream.c or any of the event-XXX.c files. I could find no other way to do it. I hope you don't get this twice ben, I wasn't sure if you were on the normal xemacs-beta list, or just xemacs-review. -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 5 20:03:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA13985 for xemacs-beta-out; Fri, 5 Nov 1999 20:03:07 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA13980 for ; Fri, 5 Nov 1999 20:03:03 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id CAA14688; Sat, 6 Nov 1999 02:02:59 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003.U; Sat Nov 6 02:02:57 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id CAA18839; Sat, 6 Nov 1999 02:02:56 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org, ben@666.com Subject: Re: GPM mouse tracking issues solved, kindof References: <86g0ykzp0s.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 06 Nov 1999 02:02:56 +0100 In-Reply-To: wmperry@aventail.com's message of "05 Nov 1999 15:01:23 -0500" Message-ID: Lines: 25 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > I removed the static-ness of enqueue_command_event(). I can't use > unread-command-events, because mouse-motion events screw that up. With > this approach, everything works beautifully. > > My question is, is this a completely bad way to achieve my goals? I want > to insert arbitrary events into the data stream from outside event-stream.c > or any of the event-XXX.c files. I could find no other way to do it. Well. enqueue_command_event() is already accessible from outside of event-stream.c by means of the wrappers for misc_user and magic_eval events. The biggest thing I have against this is that mouse_motion events are not command-events. The over solution would be to maintain your own que for stuff you want to insert and then put your own wrappers in event_stream's int (*event_pending_p) (int); void (*next_event_cb) (struct Lisp_Event *); slots. Then you set these to drain your own queue first and call the original if empty. Jan From owner-xemacs-beta@xemacs.org Fri Nov 5 21:18:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA15602 for xemacs-beta-out; Fri, 5 Nov 1999 21:18:28 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id VAA15599 for ; Fri, 5 Nov 1999 21:18:26 -0500 Received: (qmail 29281 invoked by alias); 6 Nov 1999 02:18:15 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 29257 invoked by uid 0); 6 Nov 1999 02:18:14 -0000 Received: from dialupa200.tcsn.uswest.net (HELO 666.com) (209.180.113.200) by tcsnpop1.tcsn.uswest.net with SMTP; 6 Nov 1999 02:18:14 -0000 Message-ID: <38238FA8.BC636725@666.com> Date: Fri, 05 Nov 1999 19:17:12 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: xemacs-beta@xemacs.org Subject: Re: GPM mouse tracking issues solved, kindof References: <86g0ykzp0s.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I didn't receive it twice, but I don't care about receiving things twice in any case. But you shouldn't be doing what you're doing. The event-stream code has many places that assume that only specific types of events (i.e. not mouse motion events) are on the command-event queue. We could modify such code to allow for this possibility, but it seems as though you might run into the "excessive numbers of motion events" problem -- i.e. if XEmacs is very slow and behind in processing events, the queue could fill up with large numbers of GPM motion events. With X or MSWIN, this won't happen because XEmacs won't ask for an event until it's ready for one, and X and MSWIN won't generate mouse events until they're requested. So I think the cleanest way would be to do exactly what Jan proposes -- don't try to stuff your events at all; instead, create your own queue for motion, button, and all other GPM events, and put wrapper functions around the next-event and event-pending-p callbacks. When you do this, however, make sure you grep through the code for all places that might change these callbacks -- I have a vague feeling that in some cases (e.g. some debug-enabled code?), the callbacks might get changed in the middle of a running XEmacs. ben "William M. Perry" wrote: > I finally figured out a nice clean way to stick the GPM event into the > queue, and now everything works, including mouse-tracking when while doing > selection, so you get good incremental feedback and all that stuff. > > I removed the static-ness of enqueue_command_event(). I can't use > unread-command-events, because mouse-motion events screw that up. With > this approach, everything works beautifully. > > My question is, is this a completely bad way to achieve my goals? I want > to insert arbitrary events into the data stream from outside event-stream.c > or any of the event-XXX.c files. I could find no other way to do it. > > I hope you don't get this twice ben, I wasn't sure if you were on the > normal xemacs-beta list, or just xemacs-review. > > -Bill P. From owner-xemacs-beta@xemacs.org Sat Nov 6 06:33:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA24015 for xemacs-beta-out; Sat, 6 Nov 1999 06:33:20 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA24010; Sat, 6 Nov 1999 06:33:16 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA09356; Sat, 6 Nov 1999 03:32:50 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-229.beasys.com [192.168.11.229]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id LAA27206; Sat, 6 Nov 1999 11:33:21 GMT Message-Id: <3.0.5.32.19991106113339.0099e710@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 06 Nov 1999 11:33:39 +0000 To: martin@xemacs.org, Stef Epardaud From: Andy Piper Subject: Re: compiler warnings mess Cc: xemacs-beta@xemacs.org, XEmacs Review In-Reply-To: <14369.18398.863185.115614@lasker.666.com> References: <19991103175234.A4872@faerie.whatever.org> <19991103175234.A4872@faerie.whatever.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 12:46 AM 11/4/99 -0800, Martin Buchholz wrote: >Andy has the job of fixing the gui_add_item_keywords_to_plist warning. The fix is in my source tree but when that will see the light of day I don't know. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sat Nov 6 06:33:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA24039 for xemacs-beta-out; Sat, 6 Nov 1999 06:33:56 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA24033 for ; Sat, 6 Nov 1999 06:33:51 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA09376; Sat, 6 Nov 1999 03:33:26 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-229.beasys.com [192.168.11.229]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id LAA27218; Sat, 6 Nov 1999 11:34:05 GMT Message-Id: <3.0.5.32.19991106113448.009b3db0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 06 Nov 1999 11:34:48 +0000 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Gutter Crash [was Re: 21.2-b19 "Sneaky Bastard 19991102" crashes when using toolbar for Ediff control buffer] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 07:30 PM 11/4/99 +0100, Jan Vroonhof wrote: >(Side issue: Why is the size of the gutters not taken into account to >set the frame size?) Because generally you do *not* want the frame to change size if the gutter changes. If it did you could never really have dynamic updates to the gutter (which is sized automatically depending on what's in it). Whether that's what you want when the frame gets created I don't know. >Additionally, I see no gutter code in pixel_to_glyph_translation, is >that correct? Andy? Probably not. What do you suggest? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sat Nov 6 06:33:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA24026 for xemacs-beta-out; Sat, 6 Nov 1999 06:33:42 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA24021 for ; Sat, 6 Nov 1999 06:33:41 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA09370; Sat, 6 Nov 1999 03:33:17 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-229.beasys.com [192.168.11.229]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id LAA27214; Sat, 6 Nov 1999 11:33:53 GMT Message-Id: <3.0.5.32.19991106113436.00acee10@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 06 Nov 1999 11:34:36 +0000 To: wmperry@aventail.com, xemacs-beta@xemacs.org From: Andy Piper Subject: Re: I thought someone had made widget/custom use native widgets? In-Reply-To: <863dumvzll.fsf@megalith.bp.aventail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 02:14 PM 11/4/99 -0500, William M. Perry wrote: >I don't see anything but the older pixmap-based buttons. Updated all my >packages, etc, using the latest CVS. Am I misremembering? I have a private change that does some of this. I have not commited it because there is a problem with specifiers which stops us doing it generally at the moment. I have mostly fixed the specifier problem but have had to little time recently to get all the code in a releasable state. Thus the only native widgets you will see are on the file open dialog. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sat Nov 6 07:27:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA24871 for xemacs-beta-out; Sat, 6 Nov 1999 07:27:23 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id HAA24868 for ; Sat, 6 Nov 1999 07:27:21 -0500 Received: (qmail 24038 invoked from network); 6 Nov 1999 12:26:01 -0000 Received: from usrpri2-43.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.108) by biff.kiva.net with SMTP; 6 Nov 1999 12:26:01 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id HAA07485; Sat, 6 Nov 1999 07:28:53 -0500 To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: GPM mouse tracking issues solved, kindof References: <86g0ykzp0s.fsf@megalith.bp.aventail.com> <38238FA8.BC636725@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 58 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Ben Wing writes: > I didn't receive it twice, but I don't care about receiving things twice > in any case. > > But you shouldn't be doing what you're doing. The event-stream code has > many places that assume that only specific types of events (i.e. not > mouse motion events) are on the command-event queue. We could modify > such code to allow for this possibility, but it seems as though you might > run into the "excessive numbers of motion events" problem -- i.e. if > XEmacs is very slow and behind in processing events, the queue could fill > up with large numbers of GPM motion events. With X or MSWIN, this won't > happen because XEmacs won't ask for an event until it's ready for one, > and X and MSWIN won't generate mouse events until they're requested. > > So I think the cleanest way would be to do exactly what Jan proposes -- > don't try to stuff your events at all; instead, create your own queue for > motion, button, and all other GPM events, and put wrapper functions > around the next-event and event-pending-p callbacks. > > When you do this, however, make sure you grep through the code for all > places that might change these callbacks -- I have a vague feeling that > in some cases (e.g. some debug-enabled code?), the callbacks might get > changed in the middle of a running XEmacs. It doesn't look like anybody (but me now) changes event_stream once it is created. The attached patch seems to work, and was really easy to add. My only question is should 'real' events get priority? Right now, gpm events get flushed first - will this screw up anything? The only thing that doesn't work right now is multiple GPM-aware devices within the same running XEmacs. I tried to get this working, but multiple calls to Gpm_Open don't seem to work. My basic approach was going to be: 1) gpm-enable would call Gpm_Open 2) If it succeeded, it would create the subprocess object 3) reset global gpm_fd to -1 4) reset global gpm_tried to 0, so that Gpm_Open will retry opening its supposedly 'dead' socket. 5) reset gpm_fd just before the Gpm_GetEvent() call in Freceive_gpm_event by grabbing the input fd from the process object, and set it back to -1 afterwards. Some of the internal caching that Gpm_Open does screws this up, I'm not sure why. I'm going to call this good enough for now. If I can get ViaVoice running on my desktop or my laptop I might start playing around with converting that to the connect_to_file_descriptor() method of things. Anybody played with ViaVoice OutLoud yet? You could make a speech synthesizer for EmacsSpeak that didnt' require a separate synthesizer. You could hook right into redisplay... -Bill P. --=-=-= Content-Disposition: inline; filename=gpm-patch-4 Index: lisp/gpm.el *** gpm.el Tue May 5 15:32:27 1998 --- gpm.el Fri Nov 5 13:57:23 1999 *************** *** 0 **** --- 1,70 ---- + ;;; gpm.el --- Support the mouse when emacs run on a Linux console. + + ;; Copyright (C) 1999 Free Software Foundation + + ;; Author: William Perry + ;; Keywords: mouse, terminals + + ;; This file is part of XEmacs. + + ;; XEmacs 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. + + ;; XEmacs 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, Inc., 59 Temple Place - Suite 330, + ;; Boston, MA 02111-1307, USA. + + (defvar gpm-minor-mode nil + "Non-nil when gpm-minor-mode is active. Call `gpm-minor-mode' to toggle.") + + (defun gpm-minor-mode (&optional arg) + "Toggle GPM mouse mode. + With prefix arg, turn GPM mouse mode on if and only if arg is positive." + (interactive "P") + (cond + ((null arg) ; Toggle + (if gpm-minor-mode + (progn + (gpm-enable nil) + (setq gpm-minor-mode nil)) + (if (gpm-enable t) + (setq gpm-minor-mode t)))) + ((> arg 0) ; Turn on + (if (gpm-enable t) + (setq gpm-minor-mode t))) + (t ; Turn off + (gpm-enable nil) + (setq gpm-minor-mode nil)))) + + (defun turn-on-gpm-mouse-tracking () + ;; Enable mouse tracking on linux console + (if gpm-minor-mode + (gpm-enable t))) + + (defun turn-off-gpm-mouse-tracking () + ;; Disable mouse tracking on linux console + (if gpm-minor-mode + (gpm-enable nil))) + + ;; Restore normal mouse behaviour outside Emacs + + (add-hook 'suspend-hook 'turn-off-gpm-mouse-tracking) + (add-hook 'suspend-resume-hook 'turn-on-gpm-mouse-tracking) + (add-hook 'kill-emacs-hook 'turn-off-gpm-mouse-tracking) + + (if (and (not noninteractive) ; Don't want to do this in batch mode + (fboundp 'gpm-enable) ; Must have C-level GPM support + (eq system-type 'linux) ; Must be running linux + (eq (device-type) 'tty) ; on a tty + (equal "linux" (getenv "TERM"))) ; and it must be a linux virtual console + (gpm-minor-mode 5)) + + (provide 'gpm) Index: lisp/mouse.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/mouse.el,v retrieving revision 1.19.2.6 diff -u -r1.19.2.6 mouse.el --- mouse.el 1999/09/02 08:47:55 1.19.2.6 +++ mouse.el 1999/11/06 12:07:37 @@ -88,7 +88,9 @@ the X cutbuffer. A mark is pushed, so that the inserted text lies between point and mark." (interactive) - (if (not (console-on-window-system-p)) + (if (and (not (console-on-window-system-p)) + (and (featurep 'gpm) + (not gpm-minor-mode))) (yank) (push-mark) (if (region-active-p) Index: src/console-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.5 diff -u -r1.18.2.5 console-tty.c --- console-tty.c 1999/10/24 03:48:31 1.18.2.5 +++ console-tty.c 1999/11/06 12:07:39 @@ -38,9 +38,6 @@ #ifdef FILE_CODING #include "file-coding.h" #endif -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif DEFINE_CONSOLE_TYPE (tty); DECLARE_IMAGE_INSTANTIATOR_FORMAT (nothing); @@ -129,10 +126,6 @@ #endif /* MULE */ tty_con->terminal_type = terminal_type; tty_con->controlling_process = controlling_process; - -#ifdef HAVE_GPM - connect_to_gpm (con); -#endif if (NILP (CONSOLE_NAME (con))) CONSOLE_NAME (con) = Ffile_name_nondirectory (tty); Index: src/console-tty.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 console-tty.h --- console-tty.h 1999/02/17 20:03:57 1.8.2.2 +++ console-tty.h 1999/11/06 12:07:39 @@ -41,9 +41,6 @@ struct tty_console { int infd, outfd; -#ifdef HAVE_GPM - int mouse_fd; -#endif Lisp_Object instream, outstream; Lisp_Object terminal_type; Lisp_Object controlling_process; @@ -203,9 +200,6 @@ unsigned int is_stdio :1; }; -#ifdef HAVE_GPM -#define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd) -#endif #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty) #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x) #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y) Index: src/device-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-tty.c,v retrieving revision 1.9 diff -u -r1.9 device-tty.c --- device-tty.c 1998/05/27 20:42:00 1.9 +++ device-tty.c 1999/11/06 12:07:39 @@ -38,10 +38,6 @@ #include "syssignal.h" /* for SIGWINCH */ -#ifdef HAVE_GPM -#include -#endif - #include Lisp_Object Qinit_pre_tty_win, Qinit_post_tty_win; @@ -155,15 +151,6 @@ CONSOLE_TTY_DATA (con)->width = width; CONSOLE_TTY_DATA (con)->height = height; -#ifdef HAVE_GPM - /* We need to tell GPM how big our screen is now - ** I am pretty sure the GPM library will get incredibly confused - ** if you try to connect to more than one mouse-capable device, - ** so I don't think it will cause any more damage in that case. - */ - gpm_mx = width; - gpm_my = height; -#endif for (tail = DEVICE_FRAME_LIST (d); !NILP (tail); tail = XCDR (tail)) Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/06 12:07:44 @@ -1088,6 +1088,10 @@ syms_of_eldap (); #endif +#ifdef HAVE_GPM + syms_of_gpmevent (); +#endif + /* Now create the subtypes for the types that have them. We do this before the vars_*() because more symbols may get initialized here. */ @@ -1481,6 +1485,10 @@ #ifdef HAVE_LDAP vars_of_eldap (); +#endif + +#ifdef HAVE_GPM + vars_of_gpmevent (); #endif /* Now initialize any specifier variables. We do this later Index: src/event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.14 diff -u -r1.41.2.14 event-Xt.c --- event-Xt.c 1999/10/10 11:45:15 1.41.2.14 +++ event-Xt.c 1999/11/06 12:07:46 @@ -2034,9 +2034,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2044,22 +2041,6 @@ infd = event_stream_unixoid_select_console (con); XSETCONSOLE (console, con); select_filedesc (infd, console); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - /* We check filedesc_to_what_closure[fd] here because if you run - ** XEmacs from a TTY, it will fire up GPM, select the mouse fd, then - ** if you run gnuattach to connect to another TTY, it will fire up - ** GPM again, and try to reselect the mouse fd. GPM uses the same - ** fd for every connection apparently, and select_filedesc will - ** fail its assertion if we try to select it twice. - */ - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { - select_filedesc (mousefd, console); - } - } -#endif } static void @@ -2067,9 +2048,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2077,15 +2055,6 @@ infd = event_stream_unixoid_unselect_console (con); XSETCONSOLE (console, con); unselect_filedesc (infd); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - if (mousefd >= 0) { - unselect_filedesc (mousefd); - } - } -#endif } /* read an event from a tty, if one is available. Returns non-zero Index: src/event-unixoid.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-unixoid.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 event-unixoid.c --- event-unixoid.c 1999/03/07 15:25:17 1.9.2.1 +++ event-unixoid.c 1999/11/06 12:07:53 @@ -41,10 +41,6 @@ #include "sysproc.h" /* select stuff */ #include "systime.h" -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif - /* Mask of bits indicating the descriptors that we wait for input on. These work as follows: @@ -83,12 +79,6 @@ Lisp_Object console; XSETCONSOLE (console, con); - -#ifdef HAVE_GPM - if (fd == CONSOLE_TTY_MOUSE_FD (con)) { - return handle_gpm_read (event,con,fd); - } -#endif nread = read (fd, &ch, 1); if (nread <= 0) Index: src/frame-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame-tty.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 frame-tty.c --- frame-tty.c 1998/12/05 16:55:48 1.8.2.1 +++ frame-tty.c 1999/11/06 12:07:53 @@ -33,10 +33,6 @@ #include "events.h" -#ifdef HAVE_GPM -#include -#endif - /* Default properties to use when creating frames. */ Lisp_Object Vdefault_tty_frame_plist; @@ -86,33 +82,6 @@ call1 (Qinit_post_tty_win, FRAME_CONSOLE (f)); } -#ifdef HAVE_GPM -static int -tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) -{ - Gpm_Event ev; - int num_buttons; - - num_buttons = Gpm_GetSnapshot(&ev); - *x = ev.x; - *y = ev.y; - *frame = DEVICE_SELECTED_FRAME (d); - return (1); -} - -static void -tty_set_mouse_position (struct window *w, int x, int y) -{ - /* XXX - I couldn't find any GPM functions that set the mouse position. - Mr. Perry had left this function empty; that must be why. - karlheg - */ -} - -#endif - - /* Change from withdrawn state to mapped state. */ static void tty_make_frame_visible (struct frame *f) @@ -223,10 +192,6 @@ CONSOLE_HAS_METHOD (tty, init_frame_1); CONSOLE_HAS_METHOD (tty, init_frame_3); CONSOLE_HAS_METHOD (tty, after_init_frame); -#ifdef HAVE_GPM - CONSOLE_HAS_METHOD (tty, get_mouse_position); - CONSOLE_HAS_METHOD (tty, set_mouse_position); -#endif CONSOLE_HAS_METHOD (tty, make_frame_visible); CONSOLE_HAS_METHOD (tty, make_frame_invisible); CONSOLE_HAS_METHOD (tty, frame_visible_p); Index: src/gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5 diff -u -r1.5 gpmevent.c --- gpmevent.c 1998/03/31 20:11:47 1.5 +++ gpmevent.c 1999/11/06 12:07:53 @@ -1,5 +1,28 @@ -/* William Perry 1997 */ +/* GPM functions + Copyright (C) 1997 William M. Perry + Copyright (C) 1999 Free Software Foundation, Inc. + +This file is part of XEmacs. + +XEmacs 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. + +XEmacs 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 XEmacs; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* Synched up with: Not in FSF. */ + +/* Authors: William Perry */ + #include #include "lisp.h" #include "console.h" @@ -8,11 +31,18 @@ #include "events.h" #include "events-mod.h" #include "sysdep.h" +#include "commands.h" +#include "lstream.h" +#include "process.h" #ifdef HAVE_GPM #include "gpmevent.h" #include +/* This is commented out in commands.h, I'm not sure why */ +extern Lisp_Object Vunread_command_events; +extern Lisp_Object Vunread_command_event; + #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 @@ -20,95 +50,405 @@ #else #include #endif + +static int (*orig_event_pending_p) (int); +static void (*orig_next_event_cb) (struct Lisp_Event *); + +static Lisp_Object gpm_event_queue; +static Lisp_Object gpm_event_queue_tail; + +static int +get_process_infd (struct Lisp_Process *p) +{ + Lisp_Object instr, outstr; + get_process_streams (p, &instr, &outstr); + assert (!NILP (instr)); + return filedesc_stream_fd (XLSTREAM (instr)); +} + +DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* +Run GPM_GetEvent(). +This function is the process handler for the GPM connection. +*/ + (process, string)) +{ + Gpm_Event ev; + int modifiers = 0; + int type = -1; + int button = 1; + Lisp_Object fake_event; + Lisp_Process *proc; + struct Lisp_Event *event = NULL; + struct gcpro gcpro1; + static int num_events; + + CHECK_PROCESS (process); + + if (!Gpm_GetEvent(&ev)) + { + warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed"); + return(Qzero); + } + + GCPRO1(fake_event); + + num_events++; + + fake_event = Fmake_event (Qnil, Qnil); + event = XEVENT(fake_event); + + event->timestamp = 0; + event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ + + /* Whow, wouldn't named defines be NICE!?!?! */ + modifiers = 0; + + if (ev.modifiers & 1) modifiers |= MOD_SHIFT; + if (ev.modifiers & 2) modifiers |= MOD_META; + if (ev.modifiers & 4) modifiers |= MOD_CONTROL; + if (ev.modifiers & 8) modifiers |= MOD_META; + + if (ev.buttons & GPM_B_LEFT) + { + button = 1; + } + else if (ev.buttons & GPM_B_MIDDLE) + { + button = 2; + } + else if (ev.buttons & GPM_B_RIGHT) + { + button = 3; + } + + switch (GPM_BARE_EVENTS(ev.type)) { + case GPM_DOWN: + case GPM_UP: + event->event_type = + (ev.type & GPM_DOWN) ? button_press_event : button_release_event; + event->event.button.x = ev.x; + event->event.button.y = ev.y; + event->event.button.button = button; + event->event.button.modifiers = modifiers; + break; + case GPM_MOVE: + case GPM_DRAG: + event->event_type = pointer_motion_event; + event->event.motion.x = ev.x; + event->event.motion.y = ev.y; + event->event.motion.modifiers = modifiers; + default: + /* This will never happen */ + break; + } + + /* Handle the event */ + enqueue_event (fake_event, &gpm_event_queue, &gpm_event_queue_tail); + + GPM_DRAWPOINTER(&ev); + UNGCPRO; + + return (Qzero); +} -int -handle_gpm_read (struct Lisp_Event *event, struct console *con, int fd) +static void turn_off_gpm (void) { - Gpm_Event ev; - int modifiers = 0; - int type = -1; - int button = 1; - - if (!Gpm_GetEvent(&ev)) - return 0; - - event->timestamp = 0; - event->channel = CONSOLE_SELECTED_FRAME (con); - - /* Whow, wouldn't named defines be NICE!?!?! */ - modifiers = 0; - - if (ev.modifiers & 1) modifiers |= MOD_SHIFT; - if (ev.modifiers & 2) modifiers |= MOD_META; - if (ev.modifiers & 4) modifiers |= MOD_CONTROL; - if (ev.modifiers & 8) modifiers |= MOD_META; - - if (ev.type & GPM_DOWN) - type = GPM_DOWN; - else if (ev.type & GPM_UP) - type = GPM_UP; - else if (ev.type & GPM_MOVE) { - type = GPM_MOVE; - GPM_DRAWPOINTER(&ev); - } - - if (ev.buttons & GPM_B_LEFT) - button = 1; - else if (ev.buttons & GPM_B_MIDDLE) - button = 2; - else if (ev.buttons & GPM_B_RIGHT) - button = 3; - - switch (type) { - case GPM_DOWN: - case GPM_UP: - event->event_type = - type == GPM_DOWN ? button_press_event : button_release_event; - event->event.button.x = ev.x; - event->event.button.y = ev.y; - event->event.button.button = button; - event->event.button.modifiers = modifiers; - break; - case GPM_MOVE: - event->event_type = pointer_motion_event; - event->event.motion.x = ev.x; - event->event.motion.y = ev.y; - event->event.motion.modifiers = modifiers; - default: - return 0; - } - return 1; -} - -void -connect_to_gpm (struct console *con) -{ - /* Only do this if we are running after dumping and really interactive */ - if (!noninteractive && initialized) { - /* We really only want to do this on a TTY */ - CONSOLE_TTY_MOUSE_FD (con) = -1; - if (EQ (CONSOLE_TYPE (con), Qtty)) { - Gpm_Connect conn; - int rval; - - conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; - conn.defaultMask = GPM_MOVE; - conn.minMod = 0; - conn.maxMod = ((1<get_mouse_position_method = NULL; + tty_console_methods->set_mouse_position_method = NULL; + tty_console_methods->own_selection_method = NULL; + tty_console_methods->get_foreign_selection_method = NULL; +} + +#ifdef TIOCLINUX +static Lisp_Object +tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) +{ + /* This function can GC */ + struct device *d = decode_device (Qnil); + int fd = DEVICE_INFD (d); + char c = 3; + Lisp_Object output_stream; + Lisp_Object terminal_stream; + Lisp_Object output_string; + struct gcpro gcpro1,gcpro2,gcpro3; + + GCPRO3(output_stream,terminal_stream,output_string); + + /* The ioctl() to paste actually puts things in the input queue of + ** the virtual console, so we need to trap that data, since we are + ** supposed to return the actual string selection from this + ** function. + */ + + /* I really hate doing this, but it doesn't seem to cause any + ** problems, and it makes the Lstream_read stuff further down + ** error out correctly instead of trying to indefinitely read from + ** the console. + ** + ** There is no set_descriptor_blocking() function call, but in my + ** testing under linux, it has not proved fatal to leave the + ** descriptor in non-blocking mode. + ** + ** William Perry Nov 5, 1999 + */ + set_descriptor_non_blocking (fd); + + /* We need two streams, one for reading from the selected device, + ** and one to write the data into. There is no writable version + ** of the lisp-string lstream, so we make do with a resizing + ** buffer stream, and make a string out of it after we are + ** done. + */ + output_stream = make_resizing_buffer_output_stream (); + terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); + output_string = Qnil; + + /* We should arguably use a specbind() and an unwind routine here, + ** but I don't care that much right now. + ** ### FIXME? + */ + if (NILP (output_stream) || NILP (terminal_stream)) + { + /* Should we signal an error here? */ + goto out; + } + + if (ioctl (fd, TIOCLINUX, &c) < 0) + { + /* Could not get the selection - eek */ + UNGCPRO; + return (Qnil); + } + + while (1) + { + Bufbyte tempbuf[1024]; /* some random amount */ + int i; + int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), + tempbuf, sizeof (tempbuf)); + + if (size_in_bytes <= 0) + { + /* end of the stream */ + break; + } + + /* convert CR->LF */ + for (i = 0; i < size_in_bytes; i++) + { + if (tempbuf[i] == '\r') + { + tempbuf[i] = '\n'; + } + } + + Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); + } + + Lstream_flush (XLSTREAM (output_stream)); + + output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), + Lstream_byte_count (XLSTREAM (output_stream))); + + Lstream_delete (XLSTREAM (output_stream)); + Lstream_delete (XLSTREAM (terminal_stream)); + + out: + UNGCPRO; + return (output_string); +} + +static Lisp_Object +tty_selection_exists_p (Lisp_Object selection) +{ + return (Qt); } +#endif /* TIOCLINUX */ +#if 0 +static Lisp_Object +tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) +{ + /* There is no way to do this cleanly - the GPM selection + ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and + ** end position on the _screen_, not a string to stick in there. + ** Lame. + ** + ** William Perry Nov 4, 1999 + */ +} #endif + +/* This function appears to work once in a blue moon. I'm not sure +** exactly why either. *sigh* +** William Perry Nov 4, 1999 +*/ +static int +tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) +{ + Gpm_Event ev; + int num_buttons; + + memset(&ev,'\0',sizeof(ev)); + num_buttons = Gpm_GetSnapshot(&ev); + + if (!num_buttons) + { + /* This means there are events pending... */ + return(-1); + } + *x = ev.x; + *y = ev.y; + *frame = DEVICE_SELECTED_FRAME (d); + return (1); +} + +static void +tty_set_mouse_position (struct window *w, int x, int y) +{ + /* XXX + I couldn't find any GPM functions that set the mouse position. + Mr. Perry had left this function empty; that must be why. + karlheg + */ +} + +static int gpm_event_pending_p (int user_p) +{ + if (!NILP (gpm_event_queue)) + { + /* We have a GPM event baked and ready to use */ + return(1); + } + return (orig_event_pending_p (user_p)); +} + +static void gpm_next_event_cb (struct Lisp_Event *event) +{ + if (!NILP (gpm_event_queue)) + { + Lisp_Object queued_event = dequeue_event (&gpm_event_queue, &gpm_event_queue_tail); + *event = *(XEVENT (queued_event)); + return; + } + + return (orig_next_event_cb (event)); +} + +static void hook_event_callbacks_once (void) +{ + static int hooker; + + if (!hooker) + { + orig_event_pending_p = event_stream->event_pending_p; + orig_next_event_cb = event_stream->next_event_cb; + event_stream->event_pending_p = gpm_event_pending_p; + event_stream->next_event_cb = gpm_next_event_cb; + hooker = 1; + } +} + +DEFUN ("gpm-enable", Fgpm_enable, 0, 1, 0, /* +Toggle accepting of GPM mouse events. +*/ + (arg)) +{ + Gpm_Connect conn; + int rval; + Lisp_Object gpm_process; + Lisp_Object gpm_filter; + + if (NILP (arg)) + { + turn_off_gpm (); + return (Qnil); + } + + if (noninteractive) + { + error ("Can't connect to GPM in batch mode."); + } + + hook_event_callbacks_once (); + + /* DANGER DANGER. + ** Though shalt not call (gpm-enable t) after we have already + ** started, or stuff blows up. + */ + if (!NILP (Fget_process ( build_string("gpm")))) + { + error ("GPM already enabled."); + } + + /* Install the mouse position methods for the TTY console type */ + CONSOLE_HAS_METHOD (tty, get_mouse_position); + CONSOLE_HAS_METHOD (tty, set_mouse_position); + +#ifdef TIOCLINUX + CONSOLE_HAS_METHOD (tty, get_foreign_selection); + CONSOLE_HAS_METHOD (tty, selection_exists_p); +#if 0 + CONSOLE_HAS_METHOD (tty, own_selection); +#endif +#endif /* TIOCLINUX */ + + conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE|GPM_DRAG; + conn.defaultMask = GPM_MOVE; + conn.minMod = 0; + conn.maxMod = ((1< X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 06 Nov 1999 16:33:07 +0100 In-Reply-To: rpluim@bigfoot.com's message of "Fri, 5 Nov 1999 18:22:54 +0100 (CET)" Message-ID: <9t9yacbiqj0.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: rpluim@bigfoot.com writes: > I've finally cracked, I've had it with skip-syntax-backwards crashes > on gnu.emacs.xemacs. Polite (for once) patch attached. Recommended > for every version of XEmacs in the universe. Good idea, but isn't it pointless to refer people to a PROBLEMS file that's not there anymore? If we aren't already shipping PROBLEMS with XEmacs, maybe we should start. From owner-xemacs-beta@xemacs.org Sat Nov 6 13:23:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA31138 for xemacs-beta-out; Sat, 6 Nov 1999 13:23:11 -0500 Received: from kens.com (kens.com [129.250.30.40]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA31134 for ; Sat, 6 Nov 1999 13:23:09 -0500 Received: from socha.net (IDENT:root@next3.rhrz.uni-bonn.de [131.220.224.32]) by kens.com (8.9.3/8.9.3-mod-for-majordomo) with ESMTP id NAA29588 for ; Sat, 6 Nov 1999 13:23:06 -0500 (EST) Received: (from robin@localhost) by socha.net (8.9.3/8.9.3) id SAA28335; Sat, 6 Nov 1999 18:44:26 +0100 To: xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> Organization: Usenet Death Squad X-URL: X-Face: #Z}0zkbqU,m`+S)^0R[.23L-o>U{UQ|(DvIqu^Bjw:po_g9;4JnT9tbn;QX$ga/LYS From: "Robin S. Socha" Date: 06 Nov 1999 18:44:24 +0100 In-Reply-To: Hrvoje Niksic's message of "06 Nov 1999 16:33:07 +0100" Message-ID: Lines: 13 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: * Hrvoje Niksic writes: > isn't it pointless to refer people to a PROBLEMS file that's not there > anymore? If we aren't already shipping PROBLEMS with XEmacs, maybe we > should start. Would it make any sense at all to not call the file PROBLEMS but PROBLEMS. or even README., and advertise it in the splash buffer/startup.el and the Help menu/menubar-items.el? I remember seeing intimidated users that only knew KDE. Yes, I know they should be using the RPMs. -- Robin S. Socha Big. Black. Beautified. From owner-xemacs-beta@xemacs.org Sat Nov 6 14:38:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32635 for xemacs-beta-out; Sat, 6 Nov 1999 14:38:46 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA32625 for ; Sat, 6 Nov 1999 14:38:41 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11kBfb-0004uU-00 for ; Sat, 06 Nov 1999 20:38:39 +0100 To: XEmacs Beta List Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 06 Nov 1999 20:38:39 +0100 In-Reply-To: "Robin S. Socha"'s message of "06 Nov 1999 18:44:24 +0100" Message-ID: <9t9k8nvh0lc.fsf@mraz.iskon.hr> Lines: 24 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Robin S. Socha" writes: > * Hrvoje Niksic writes: > > isn't it pointless to refer people to a PROBLEMS file that's not there > > anymore? If we aren't already shipping PROBLEMS with XEmacs, maybe we > > should start. > > Would it make any sense at all to not call the file PROBLEMS but > PROBLEMS. Many items in PROBLEMS are OS-independent. > or even README., and advertise it in the splash > buffer/startup.el and the Help menu/menubar-items.el? PROBLEMS is supposed to be primarily a helper file for people who build XEmacs. Quite possibly some of the user-level documentation has leaked there, but I don't think it's sufficient to warrant a place at the menubar. > I remember seeing intimidated users that only knew KDE. Yes, I know > they should be using the RPMs. Huh? From owner-xemacs-beta@xemacs.org Sat Nov 6 17:09:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA03715 for xemacs-beta-out; Sat, 6 Nov 1999 17:09:10 -0500 Received: from vector.intergate.ca (vector.intergate.ca [207.34.179.20]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA03712 for ; Sat, 6 Nov 1999 17:09:08 -0500 Received: from idyllic (pm33s15.intergate.bc.ca [207.34.182.74]) by vector.intergate.ca (8.9.3/8.9.3) with SMTP id OAA24556 for ; Sat, 6 Nov 1999 14:08:59 -0800 (PST) From: Gerald Gutierrez MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14372.42839.527423.158098@gargle.gargle.HOWL> Date: Sat, 6 Nov 1999 14:10:31 -0800 (PST) To: xemacs-beta@xemacs.org Subject: Adaptive Fill Mode X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi all. Under GNU Emacs, I can go into text-mode, enable auto-fill-mode, start typing garbage and get it to auto-indent subsequent lines: - asdf asdfklj asdkj asdklfj asdfklj fdasjkl asdlfkj asdfklj asdkj asdlfj asdlfkj asdkj asdf asdlf asdlfj asd asdfkl asdfkl asdfkj asdkj asdfkj asdklfj asdf How do I achieve this same effect in XEmacs? I know that XEmacs has the same adaptive-fill-* variables, but 1) it doesn't have the dash, and 2) even when I use one of the listed characters (in adaptive-fill-regexp) as the start of the "paragraph", it doesn't give me the leading spaces like GNU Emacs does: > asdf asdlfkj asdfklja sdflkj asdfklj asdfklj asdfklj asdj asdfkl asdfklj asdfj asdj asdklf asdklfj asdfklj asdfkla sdfklj asd asdfkj asdfj asdfkla If I hit M-q, I get: > asdf asdlfkj asdfklja sdflkj asdfklj asdfklj asdfklj asdj asdfkl > asdfklj asdfj asdj asdklf asdklfj asdfklj asdfkla sdfklj asd asdfkj > asdfj asdfkla which is obviously not what is wanted. Thanks for any help. From owner-xemacs-beta@xemacs.org Sat Nov 6 18:11:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA05019 for xemacs-beta-out; Sat, 6 Nov 1999 18:11:43 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA05013 for ; Sat, 6 Nov 1999 18:11:39 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11kEzh-00053x-00 for ; Sun, 07 Nov 1999 00:11:37 +0100 To: XEmacs Beta List Subject: Re: Adaptive Fill Mode References: <14372.42839.527423.158098@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 07 Nov 1999 00:11:37 +0100 In-Reply-To: Gerald Gutierrez's message of "Sat, 6 Nov 1999 14:10:31 -0800 (PST)" Message-ID: <9t9iu3ffc5y.fsf@mraz.iskon.hr> Lines: 12 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Gerald Gutierrez writes: > Under GNU Emacs, I can go into text-mode, enable auto-fill-mode, start > typing garbage and get it to auto-indent subsequent lines: > > - asdf asdfklj asdkj asdklfj asdfklj fdasjkl asdlfkj asdfklj asdkj > asdlfj asdlfkj asdkj asdf asdlf asdlfj asd asdfkl asdfkl asdfkj > asdkj asdfkj asdklfj asdf > > How do I achieve this same effect in XEmacs? M-x filladapt-mode RET From owner-xemacs-beta@xemacs.org Sat Nov 6 18:31:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA05560 for xemacs-beta-out; Sat, 6 Nov 1999 18:31:33 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA05552 for ; Sat, 6 Nov 1999 18:31:32 -0500 Received: (qmail 2661 invoked by alias); 6 Nov 1999 23:31:20 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 2606 invoked by uid 0); 6 Nov 1999 23:31:17 -0000 Received: from dialupc146.tcsn.uswest.net (HELO 666.com) (209.180.115.146) by tcsnpop1.tcsn.uswest.net with SMTP; 6 Nov 1999 23:31:17 -0000 Message-ID: <3824B845.1268D099@666.com> Date: Sat, 06 Nov 1999 16:22:45 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: xemacs-beta@xemacs.org Subject: Re: GPM mouse tracking issues solved, kindof References: <86g0ykzp0s.fsf@megalith.bp.aventail.com> <38238FA8.BC636725@666.com> <864sezst16.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Some comments: -- Your code to enable GPM is definitely wrong. It will fail with run-temacs, when you start on an X device and later connect to a TTY, etc. You need to hook into create-device-hook. -- Your next_event callback does not honor user_p, like it should. (Motion events are not user events.) -- Replace XXX, ### and FIXME with ####. >The attached patch seems to work, and was really easy to add. My only >question is should 'real' events get priority? Right now, gpm events get >flushed first - will this screw up anything? Probably the events need to get ordered properly, but this is a hassle, and probably not worth it, esp. on TTY's where you can't have focus problems. But put a #### comments about this. ben "William M. Perry" wrote: > Ben Wing writes: > > > I didn't receive it twice, but I don't care about receiving things twice > > in any case. > > > > But you shouldn't be doing what you're doing. The event-stream code has > > many places that assume that only specific types of events (i.e. not > > mouse motion events) are on the command-event queue. We could modify > > such code to allow for this possibility, but it seems as though you might > > run into the "excessive numbers of motion events" problem -- i.e. if > > XEmacs is very slow and behind in processing events, the queue could fill > > up with large numbers of GPM motion events. With X or MSWIN, this won't > > happen because XEmacs won't ask for an event until it's ready for one, > > and X and MSWIN won't generate mouse events until they're requested. > > > > So I think the cleanest way would be to do exactly what Jan proposes -- > > don't try to stuff your events at all; instead, create your own queue for > > motion, button, and all other GPM events, and put wrapper functions > > around the next-event and event-pending-p callbacks. > > > > When you do this, however, make sure you grep through the code for all > > places that might change these callbacks -- I have a vague feeling that > > in some cases (e.g. some debug-enabled code?), the callbacks might get > > changed in the middle of a running XEmacs. > > It doesn't look like anybody (but me now) changes event_stream once it is > created. > > The attached patch seems to work, and was really easy to add. My only > question is should 'real' events get priority? Right now, gpm events get > flushed first - will this screw up anything? > > The only thing that doesn't work right now is multiple GPM-aware devices > within the same running XEmacs. I tried to get this working, but multiple > calls to Gpm_Open don't seem to work. My basic approach was going to be: > > 1) gpm-enable would call Gpm_Open > 2) If it succeeded, it would create the subprocess object > 3) reset global gpm_fd to -1 > 4) reset global gpm_tried to 0, so that Gpm_Open will retry opening its > supposedly 'dead' socket. > 5) reset gpm_fd just before the Gpm_GetEvent() call in Freceive_gpm_event > by grabbing the input fd from the process object, and set it back to -1 > afterwards. > > Some of the internal caching that Gpm_Open does screws this up, I'm not > sure why. I'm going to call this good enough for now. If I can get > ViaVoice running on my desktop or my laptop I might start playing around > with converting that to the connect_to_file_descriptor() method of things. > > Anybody played with ViaVoice OutLoud yet? You could make a speech > synthesizer for EmacsSpeak that didnt' require a separate synthesizer. You > could hook right into redisplay... > > -Bill P. From owner-xemacs-beta@xemacs.org Sat Nov 6 19:03:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA06771 for xemacs-beta-out; Sat, 6 Nov 1999 19:03:02 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id TAA06767 for ; Sat, 6 Nov 1999 19:02:59 -0500 Received: (qmail 22338 invoked from network); 7 Nov 1999 00:01:39 -0000 Received: from usrpri2-46.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.111) by biff.kiva.net with SMTP; 7 Nov 1999 00:01:39 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id TAA01454; Sat, 6 Nov 1999 19:04:33 -0500 To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: GPM mouse tracking issues solved, kindof References: <86g0ykzp0s.fsf@megalith.bp.aventail.com> <38238FA8.BC636725@666.com> <864sezst16.fsf@megalith.bp.aventail.com> <3824B845.1268D099@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 40 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Some comments: > > -- Your code to enable GPM is definitely wrong. It will fail with run-temacs, when you start on an X device and later > connect to a TTY, etc. You need to hook into create-device-hook. Like this? (defun gpm-create-device-hook (device) (if (and (not noninteractive) ; Don't want to do this in batch mode (fboundp 'gpm-enable) ; Must have C-level GPM support (eq system-type 'linux) ; Must be running linux (eq (device-type device) 'tty) ; on a tty (equal "linux" (console-tty-terminal-type ; an a linux terminal type (device-console device)))) (gpm-minor-mode 5))) (add-hook 'create-device-hook 'gpm-create-device-hook) > -- Your next_event callback does not honor user_p, like it should. (Motion events are not user events.) Fixed... I'll be sending a final patch to xemacs-beta & xemacs-patches later tonight or tomorrow morning. > -- Replace XXX, ### and FIXME with ####. Done as well. > >The attached patch seems to work, and was really easy to add. My only > >question is should 'real' events get priority? Right now, gpm events get > >flushed first - will this screw up anything? > > Probably the events need to get ordered properly, but this is a hassle, > and probably not worth it, esp. on TTY's where you can't have focus > problems. But put a #### comments about this. Will do. -bp From owner-xemacs-beta@xemacs.org Sat Nov 6 22:45:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA10427 for xemacs-beta-out; Sat, 6 Nov 1999 22:45:18 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id WAA10419 for ; Sat, 6 Nov 1999 22:45:15 -0500 Received: (qmail 10513 invoked from network); 7 Nov 1999 03:43:49 -0000 Received: from usrpri2-37.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.102) by biff.kiva.net with SMTP; 7 Nov 1999 03:43:49 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id WAA01806; Sat, 6 Nov 1999 22:46:47 -0500 To: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: Hopefully final GPM patch... Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 10 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= This incorporates all of ben's recent suggestions. If someone wants to hack whatever is necessary (dumped-lisp.el?) to get gpm.el loaded before dump time, the device creation hooking seems to work, and correctly brings up XEmacs with GPM enabled with no mucking about by the user on the linux console. -Bill P. --=-=-= Content-Disposition: inline; filename=gpm-patch-5 Index: lisp/gpm.el =================================================================== *** gpm.el Tue May 5 15:32:27 1998 --- gpm.el Sat Nov 6 19:01:45 1999 *************** *** 0 **** --- 1,73 ---- + ;;; gpm.el --- Support the mouse when emacs run on a Linux console. + + ;; Copyright (C) 1999 Free Software Foundation + + ;; Author: William Perry + ;; Keywords: mouse, terminals + + ;; This file is part of XEmacs. + + ;; XEmacs 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. + + ;; XEmacs 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, Inc., 59 Temple Place - Suite 330, + ;; Boston, MA 02111-1307, USA. + + (defvar gpm-minor-mode nil + "Non-nil when gpm-minor-mode is active. Call `gpm-minor-mode' to toggle.") + + (defun gpm-minor-mode (&optional arg) + "Toggle GPM mouse mode. + With prefix arg, turn GPM mouse mode on if and only if arg is positive." + (interactive "P") + (cond + ((null arg) ; Toggle + (if gpm-minor-mode + (progn + (gpm-enable nil) + (setq gpm-minor-mode nil)) + (if (gpm-enable t) + (setq gpm-minor-mode t)))) + ((> arg 0) ; Turn on + (if (gpm-enable t) + (setq gpm-minor-mode t))) + (t ; Turn off + (gpm-enable nil) + (setq gpm-minor-mode nil)))) + + (defun turn-on-gpm-mouse-tracking () + ;; Enable mouse tracking on linux console + (if gpm-minor-mode + (gpm-enable t))) + + (defun turn-off-gpm-mouse-tracking () + ;; Disable mouse tracking on linux console + (if gpm-minor-mode + (gpm-enable nil))) + + (defun gpm-create-device-hook (device) + (if (and (not noninteractive) ; Don't want to do this in batch mode + (fboundp 'gpm-enable) ; Must have C-level GPM support + (eq system-type 'linux) ; Must be running linux + (eq (device-type device) 'tty) ; on a tty + (equal "linux" (console-tty-terminal-type ; an a linux terminal type + (device-console device)))) + (gpm-minor-mode 5))) + + ;; Restore normal mouse behaviour outside Emacs + + (add-hook 'suspend-hook 'turn-off-gpm-mouse-tracking) + (add-hook 'suspend-resume-hook 'turn-on-gpm-mouse-tracking) + (add-hook 'kill-emacs-hook 'turn-off-gpm-mouse-tracking) + (add-hook 'create-device-hook 'gpm-create-device-hook) + + (provide 'gpm) Index: lisp/mouse.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/mouse.el,v retrieving revision 1.19.2.6 diff -u -r1.19.2.6 mouse.el --- mouse.el 1999/09/02 08:47:55 1.19.2.6 +++ mouse.el 1999/11/07 03:30:16 @@ -88,7 +88,9 @@ the X cutbuffer. A mark is pushed, so that the inserted text lies between point and mark." (interactive) - (if (not (console-on-window-system-p)) + (if (and (not (console-on-window-system-p)) + (and (featurep 'gpm) + (not gpm-minor-mode))) (yank) (push-mark) (if (region-active-p) Index: src/console-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.5 diff -u -r1.18.2.5 console-tty.c --- console-tty.c 1999/10/24 03:48:31 1.18.2.5 +++ console-tty.c 1999/11/07 03:30:17 @@ -38,9 +38,6 @@ #ifdef FILE_CODING #include "file-coding.h" #endif -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif DEFINE_CONSOLE_TYPE (tty); DECLARE_IMAGE_INSTANTIATOR_FORMAT (nothing); @@ -129,10 +126,6 @@ #endif /* MULE */ tty_con->terminal_type = terminal_type; tty_con->controlling_process = controlling_process; - -#ifdef HAVE_GPM - connect_to_gpm (con); -#endif if (NILP (CONSOLE_NAME (con))) CONSOLE_NAME (con) = Ffile_name_nondirectory (tty); Index: src/console-tty.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 console-tty.h --- console-tty.h 1999/02/17 20:03:57 1.8.2.2 +++ console-tty.h 1999/11/07 03:30:18 @@ -41,9 +41,6 @@ struct tty_console { int infd, outfd; -#ifdef HAVE_GPM - int mouse_fd; -#endif Lisp_Object instream, outstream; Lisp_Object terminal_type; Lisp_Object controlling_process; @@ -203,9 +200,6 @@ unsigned int is_stdio :1; }; -#ifdef HAVE_GPM -#define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd) -#endif #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty) #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x) #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y) Index: src/device-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-tty.c,v retrieving revision 1.9 diff -u -r1.9 device-tty.c --- device-tty.c 1998/05/27 20:42:00 1.9 +++ device-tty.c 1999/11/07 03:30:18 @@ -38,10 +38,6 @@ #include "syssignal.h" /* for SIGWINCH */ -#ifdef HAVE_GPM -#include -#endif - #include Lisp_Object Qinit_pre_tty_win, Qinit_post_tty_win; @@ -155,15 +151,6 @@ CONSOLE_TTY_DATA (con)->width = width; CONSOLE_TTY_DATA (con)->height = height; -#ifdef HAVE_GPM - /* We need to tell GPM how big our screen is now - ** I am pretty sure the GPM library will get incredibly confused - ** if you try to connect to more than one mouse-capable device, - ** so I don't think it will cause any more damage in that case. - */ - gpm_mx = width; - gpm_my = height; -#endif for (tail = DEVICE_FRAME_LIST (d); !NILP (tail); tail = XCDR (tail)) Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/07 03:30:20 @@ -1088,6 +1088,10 @@ syms_of_eldap (); #endif +#ifdef HAVE_GPM + syms_of_gpmevent (); +#endif + /* Now create the subtypes for the types that have them. We do this before the vars_*() because more symbols may get initialized here. */ @@ -1481,6 +1485,10 @@ #ifdef HAVE_LDAP vars_of_eldap (); +#endif + +#ifdef HAVE_GPM + vars_of_gpmevent (); #endif /* Now initialize any specifier variables. We do this later Index: src/event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.14 diff -u -r1.41.2.14 event-Xt.c --- event-Xt.c 1999/10/10 11:45:15 1.41.2.14 +++ event-Xt.c 1999/11/07 03:30:22 @@ -2034,9 +2034,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2044,22 +2041,6 @@ infd = event_stream_unixoid_select_console (con); XSETCONSOLE (console, con); select_filedesc (infd, console); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - /* We check filedesc_to_what_closure[fd] here because if you run - ** XEmacs from a TTY, it will fire up GPM, select the mouse fd, then - ** if you run gnuattach to connect to another TTY, it will fire up - ** GPM again, and try to reselect the mouse fd. GPM uses the same - ** fd for every connection apparently, and select_filedesc will - ** fail its assertion if we try to select it twice. - */ - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { - select_filedesc (mousefd, console); - } - } -#endif } static void @@ -2067,9 +2048,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2077,15 +2055,6 @@ infd = event_stream_unixoid_unselect_console (con); XSETCONSOLE (console, con); unselect_filedesc (infd); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - if (mousefd >= 0) { - unselect_filedesc (mousefd); - } - } -#endif } /* read an event from a tty, if one is available. Returns non-zero Index: src/event-unixoid.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-unixoid.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 event-unixoid.c --- event-unixoid.c 1999/03/07 15:25:17 1.9.2.1 +++ event-unixoid.c 1999/11/07 03:30:27 @@ -41,10 +41,6 @@ #include "sysproc.h" /* select stuff */ #include "systime.h" -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif - /* Mask of bits indicating the descriptors that we wait for input on. These work as follows: @@ -83,12 +79,6 @@ Lisp_Object console; XSETCONSOLE (console, con); - -#ifdef HAVE_GPM - if (fd == CONSOLE_TTY_MOUSE_FD (con)) { - return handle_gpm_read (event,con,fd); - } -#endif nread = read (fd, &ch, 1); if (nread <= 0) Index: src/frame-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame-tty.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 frame-tty.c --- frame-tty.c 1998/12/05 16:55:48 1.8.2.1 +++ frame-tty.c 1999/11/07 03:30:27 @@ -33,10 +33,6 @@ #include "events.h" -#ifdef HAVE_GPM -#include -#endif - /* Default properties to use when creating frames. */ Lisp_Object Vdefault_tty_frame_plist; @@ -86,33 +82,6 @@ call1 (Qinit_post_tty_win, FRAME_CONSOLE (f)); } -#ifdef HAVE_GPM -static int -tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) -{ - Gpm_Event ev; - int num_buttons; - - num_buttons = Gpm_GetSnapshot(&ev); - *x = ev.x; - *y = ev.y; - *frame = DEVICE_SELECTED_FRAME (d); - return (1); -} - -static void -tty_set_mouse_position (struct window *w, int x, int y) -{ - /* XXX - I couldn't find any GPM functions that set the mouse position. - Mr. Perry had left this function empty; that must be why. - karlheg - */ -} - -#endif - - /* Change from withdrawn state to mapped state. */ static void tty_make_frame_visible (struct frame *f) @@ -223,10 +192,6 @@ CONSOLE_HAS_METHOD (tty, init_frame_1); CONSOLE_HAS_METHOD (tty, init_frame_3); CONSOLE_HAS_METHOD (tty, after_init_frame); -#ifdef HAVE_GPM - CONSOLE_HAS_METHOD (tty, get_mouse_position); - CONSOLE_HAS_METHOD (tty, set_mouse_position); -#endif CONSOLE_HAS_METHOD (tty, make_frame_visible); CONSOLE_HAS_METHOD (tty, make_frame_invisible); CONSOLE_HAS_METHOD (tty, frame_visible_p); Index: src/gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5 diff -u -r1.5 gpmevent.c --- gpmevent.c 1998/03/31 20:11:47 1.5 +++ gpmevent.c 1999/11/07 03:30:28 @@ -1,5 +1,28 @@ -/* William Perry 1997 */ +/* GPM functions + Copyright (C) 1997 William M. Perry + Copyright (C) 1999 Free Software Foundation, Inc. + +This file is part of XEmacs. + +XEmacs 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. + +XEmacs 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 XEmacs; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* Synched up with: Not in FSF. */ + +/* Authors: William Perry */ + #include #include "lisp.h" #include "console.h" @@ -8,11 +31,18 @@ #include "events.h" #include "events-mod.h" #include "sysdep.h" +#include "commands.h" +#include "lstream.h" +#include "process.h" #ifdef HAVE_GPM #include "gpmevent.h" #include +/* This is commented out in commands.h, I'm not sure why */ +extern Lisp_Object Vunread_command_events; +extern Lisp_Object Vunread_command_event; + #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 @@ -20,95 +50,414 @@ #else #include #endif + +static int (*orig_event_pending_p) (int); +static void (*orig_next_event_cb) (struct Lisp_Event *); + +static Lisp_Object gpm_event_queue; +static Lisp_Object gpm_event_queue_tail; + +static int +get_process_infd (struct Lisp_Process *p) +{ + Lisp_Object instr, outstr; + get_process_streams (p, &instr, &outstr); + assert (!NILP (instr)); + return filedesc_stream_fd (XLSTREAM (instr)); +} + +DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* +Run GPM_GetEvent(). +This function is the process handler for the GPM connection. +*/ + (process, string)) +{ + Gpm_Event ev; + int modifiers = 0; + int type = -1; + int button = 1; + Lisp_Object fake_event; + Lisp_Process *proc; + struct Lisp_Event *event = NULL; + struct gcpro gcpro1; + static int num_events; + + CHECK_PROCESS (process); + + if (!Gpm_GetEvent(&ev)) + { + warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed"); + return(Qzero); + } + + GCPRO1(fake_event); + + num_events++; + + fake_event = Fmake_event (Qnil, Qnil); + event = XEVENT(fake_event); + + event->timestamp = 0; + event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ + + /* Whow, wouldn't named defines be NICE!?!?! */ + modifiers = 0; + + if (ev.modifiers & 1) modifiers |= MOD_SHIFT; + if (ev.modifiers & 2) modifiers |= MOD_META; + if (ev.modifiers & 4) modifiers |= MOD_CONTROL; + if (ev.modifiers & 8) modifiers |= MOD_META; + + if (ev.buttons & GPM_B_LEFT) + { + button = 1; + } + else if (ev.buttons & GPM_B_MIDDLE) + { + button = 2; + } + else if (ev.buttons & GPM_B_RIGHT) + { + button = 3; + } + + switch (GPM_BARE_EVENTS(ev.type)) { + case GPM_DOWN: + case GPM_UP: + event->event_type = + (ev.type & GPM_DOWN) ? button_press_event : button_release_event; + event->event.button.x = ev.x; + event->event.button.y = ev.y; + event->event.button.button = button; + event->event.button.modifiers = modifiers; + break; + case GPM_MOVE: + case GPM_DRAG: + event->event_type = pointer_motion_event; + event->event.motion.x = ev.x; + event->event.motion.y = ev.y; + event->event.motion.modifiers = modifiers; + default: + /* This will never happen */ + break; + } + + /* Handle the event */ + enqueue_event (fake_event, &gpm_event_queue, &gpm_event_queue_tail); + + GPM_DRAWPOINTER(&ev); + UNGCPRO; + + return (Qzero); +} -int -handle_gpm_read (struct Lisp_Event *event, struct console *con, int fd) +static void turn_off_gpm (void) { - Gpm_Event ev; - int modifiers = 0; - int type = -1; - int button = 1; - - if (!Gpm_GetEvent(&ev)) - return 0; - - event->timestamp = 0; - event->channel = CONSOLE_SELECTED_FRAME (con); - - /* Whow, wouldn't named defines be NICE!?!?! */ - modifiers = 0; - - if (ev.modifiers & 1) modifiers |= MOD_SHIFT; - if (ev.modifiers & 2) modifiers |= MOD_META; - if (ev.modifiers & 4) modifiers |= MOD_CONTROL; - if (ev.modifiers & 8) modifiers |= MOD_META; - - if (ev.type & GPM_DOWN) - type = GPM_DOWN; - else if (ev.type & GPM_UP) - type = GPM_UP; - else if (ev.type & GPM_MOVE) { - type = GPM_MOVE; - GPM_DRAWPOINTER(&ev); - } - - if (ev.buttons & GPM_B_LEFT) - button = 1; - else if (ev.buttons & GPM_B_MIDDLE) - button = 2; - else if (ev.buttons & GPM_B_RIGHT) - button = 3; - - switch (type) { - case GPM_DOWN: - case GPM_UP: - event->event_type = - type == GPM_DOWN ? button_press_event : button_release_event; - event->event.button.x = ev.x; - event->event.button.y = ev.y; - event->event.button.button = button; - event->event.button.modifiers = modifiers; - break; - case GPM_MOVE: - event->event_type = pointer_motion_event; - event->event.motion.x = ev.x; - event->event.motion.y = ev.y; - event->event.motion.modifiers = modifiers; - default: - return 0; - } - return 1; -} - -void -connect_to_gpm (struct console *con) -{ - /* Only do this if we are running after dumping and really interactive */ - if (!noninteractive && initialized) { - /* We really only want to do this on a TTY */ - CONSOLE_TTY_MOUSE_FD (con) = -1; - if (EQ (CONSOLE_TYPE (con), Qtty)) { - Gpm_Connect conn; - int rval; - - conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; - conn.defaultMask = GPM_MOVE; - conn.minMod = 0; - conn.maxMod = ((1<get_mouse_position_method = NULL; + tty_console_methods->set_mouse_position_method = NULL; + tty_console_methods->own_selection_method = NULL; + tty_console_methods->get_foreign_selection_method = NULL; +} + +#ifdef TIOCLINUX +static Lisp_Object +tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) +{ + /* This function can GC */ + struct device *d = decode_device (Qnil); + int fd = DEVICE_INFD (d); + char c = 3; + Lisp_Object output_stream; + Lisp_Object terminal_stream; + Lisp_Object output_string; + struct gcpro gcpro1,gcpro2,gcpro3; + + GCPRO3(output_stream,terminal_stream,output_string); + + /* The ioctl() to paste actually puts things in the input queue of + ** the virtual console, so we need to trap that data, since we are + ** supposed to return the actual string selection from this + ** function. + */ + + /* I really hate doing this, but it doesn't seem to cause any + ** problems, and it makes the Lstream_read stuff further down + ** error out correctly instead of trying to indefinitely read from + ** the console. + ** + ** There is no set_descriptor_blocking() function call, but in my + ** testing under linux, it has not proved fatal to leave the + ** descriptor in non-blocking mode. + ** + ** William Perry Nov 5, 1999 + */ + set_descriptor_non_blocking (fd); + + /* We need two streams, one for reading from the selected device, + ** and one to write the data into. There is no writable version + ** of the lisp-string lstream, so we make do with a resizing + ** buffer stream, and make a string out of it after we are + ** done. + */ + output_stream = make_resizing_buffer_output_stream (); + terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); + output_string = Qnil; + + /* #### We should arguably use a specbind() and an unwind routine here, + ** #### but I don't care that much right now. + */ + if (NILP (output_stream) || NILP (terminal_stream)) + { + /* Should we signal an error here? */ + goto out; + } + + if (ioctl (fd, TIOCLINUX, &c) < 0) + { + /* Could not get the selection - eek */ + UNGCPRO; + return (Qnil); + } + + while (1) + { + Bufbyte tempbuf[1024]; /* some random amount */ + int i; + int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), + tempbuf, sizeof (tempbuf)); + + if (size_in_bytes <= 0) + { + /* end of the stream */ + break; + } + + /* convert CR->LF */ + for (i = 0; i < size_in_bytes; i++) + { + if (tempbuf[i] == '\r') + { + tempbuf[i] = '\n'; + } + } + + Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); + } + + Lstream_flush (XLSTREAM (output_stream)); + + output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), + Lstream_byte_count (XLSTREAM (output_stream))); + + Lstream_delete (XLSTREAM (output_stream)); + Lstream_delete (XLSTREAM (terminal_stream)); + + out: + UNGCPRO; + return (output_string); +} + +static Lisp_Object +tty_selection_exists_p (Lisp_Object selection) +{ + return (Qt); +} +#endif /* TIOCLINUX */ + +#if 0 +static Lisp_Object +tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) +{ + /* There is no way to do this cleanly - the GPM selection + ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and + ** end position on the _screen_, not a string to stick in there. + ** Lame. + ** + ** William Perry Nov 4, 1999 + */ +} +#endif + +/* This function appears to work once in a blue moon. I'm not sure +** exactly why either. *sigh* +** William Perry Nov 4, 1999 +*/ +static int +tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) +{ + Gpm_Event ev; + int num_buttons; + + memset(&ev,'\0',sizeof(ev)); + num_buttons = Gpm_GetSnapshot(&ev); + + if (!num_buttons) + { + /* This means there are events pending... */ + return(-1); + } + *x = ev.x; + *y = ev.y; + *frame = DEVICE_SELECTED_FRAME (d); + return (1); +} + +static void +tty_set_mouse_position (struct window *w, int x, int y) +{ + /* + #### I couldn't find any GPM functions that set the mouse position. + #### Mr. Perry had left this function empty; that must be why. + #### karlheg + */ +} + +static int gpm_event_pending_p (int user_p) +{ + Lisp_Object event; + + EVENT_CHAIN_LOOP (event, gpm_event_queue) + { + if (!user_p || command_event_p (event)) + { + return (1); + } + } + return (orig_event_pending_p (user_p)); +} + +static void gpm_next_event_cb (struct Lisp_Event *event) +{ + /* #### It would be nice to preserve some sort of ordering of the + ** #### different types of events, but that would be quite a bit + ** #### of work, and would more than likely break the abstraction + ** #### between the other event loops and this one. + */ + + if (!NILP (gpm_event_queue)) + { + Lisp_Object queued_event = dequeue_event (&gpm_event_queue, &gpm_event_queue_tail); + *event = *(XEVENT (queued_event)); + return; + } + + return (orig_next_event_cb (event)); +} + +static void hook_event_callbacks_once (void) +{ + static int hooker; + + if (!hooker) + { + orig_event_pending_p = event_stream->event_pending_p; + orig_next_event_cb = event_stream->next_event_cb; + event_stream->event_pending_p = gpm_event_pending_p; + event_stream->next_event_cb = gpm_next_event_cb; + hooker = 1; + } } +DEFUN ("gpm-enable", Fgpm_enable, 0, 1, 0, /* +Toggle accepting of GPM mouse events. +*/ + (arg)) +{ + Gpm_Connect conn; + int rval; + Lisp_Object gpm_process; + Lisp_Object gpm_filter; + + if (NILP (arg)) + { + turn_off_gpm (); + return (Qnil); + } + + if (noninteractive) + { + error ("Can't connect to GPM in batch mode."); + } + + hook_event_callbacks_once (); + + /* DANGER DANGER. + ** Though shalt not call (gpm-enable t) after we have already + ** started, or stuff blows up. + */ + if (!NILP (Fget_process ( build_string("gpm")))) + { + error ("GPM already enabled."); + } + + /* Install the mouse position methods for the TTY console type */ + CONSOLE_HAS_METHOD (tty, get_mouse_position); + CONSOLE_HAS_METHOD (tty, set_mouse_position); + +#ifdef TIOCLINUX + CONSOLE_HAS_METHOD (tty, get_foreign_selection); + CONSOLE_HAS_METHOD (tty, selection_exists_p); +#if 0 + CONSOLE_HAS_METHOD (tty, own_selection); #endif +#endif /* TIOCLINUX */ + + conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE|GPM_DRAG; + conn.defaultMask = GPM_MOVE; + conn.minMod = 0; + conn.maxMod = ((1<; Sun, 7 Nov 1999 01:41:45 -0500 Received: from socha.net (IDENT:root@next3.rhrz.uni-bonn.de [131.220.224.32]) by kens.com (8.9.3/8.9.3-mod-for-majordomo) with ESMTP id BAA11288 for ; Sun, 7 Nov 1999 01:41:43 -0500 (EST) Received: (from robin@localhost) by socha.net (8.9.3/8.9.3) id BAA09486; Sun, 7 Nov 1999 01:12:10 +0100 To: XEmacs Beta List Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <9t9k8nvh0lc.fsf@mraz.iskon.hr> Organization: Usenet Death Squad X-URL: X-Face: #Z}0zkbqU,m`+S)^0R[.23L-o>U{UQ|(DvIqu^Bjw:po_g9;4JnT9tbn;QX$ga/LYS From: "Robin S. Socha" Date: 07 Nov 1999 01:12:09 +0100 In-Reply-To: Hrvoje Niksic's message of "06 Nov 1999 20:38:39 +0100" Message-ID: Lines: 33 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: * Hrvoje Niksic writes: > "Robin S. Socha" writes: >> * Hrvoje Niksic writes: >> Would it make any sense at all to not call the file PROBLEMS but >> PROBLEMS. > Many items in PROBLEMS are OS-independent. [...] >> I remember seeing intimidated users that only knew KDE. Yes, I know >> they should be using the RPMs. > Huh? Like you said: "Many items in PROBLEMS are OS-independent." So the file tells a novice user whose sole conception of, say, Linux is that of "the better Windows" about Alpha Linux ("is that a new distib?"), pgcc ("huh?"), AIX and other things Joe Random Linux-Poweruser ("look, Ma, I found a DeadRat") has never heard of. I was trying to say that a file that says "if you're using Linux or a SPARC, *read* me" is more likely to be read. I recall reading the problems file months after my first install, mainly because this kind of file is not too common in the Linux world. > PROBLEMS is supposed to be primarily a helper file for people who > build XEmacs. Quite possibly some of the user-level documentation has > leaked there, but I don't think it's sufficient to warrant a place at > the menubar. Is there reliable statistic about the XEmacs userbase? I may be very wrong, but I would imagine that a large (and rapidly growing) number of user are their own admins (ie single user systems running Linux or *BSD). And why do I need a "Splash" entry in the Help menu? -- Robin S. Socha Big. Black. Beautified. From owner-xemacs-beta@xemacs.org Sun Nov 7 09:03:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA19899 for xemacs-beta-out; Sun, 7 Nov 1999 09:03:54 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA19896; Sun, 7 Nov 1999 09:03:52 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA00407; Sun, 7 Nov 1999 15:03:51 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0006L; Sun Nov 7 15:03:41 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA19385; Sun, 7 Nov 1999 15:03:41 +0100 To: wmperry@aventail.com Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Hopefully final GPM patch... References: <86wvrvneu0.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 07 Nov 1999 15:03:41 +0100 In-Reply-To: wmperry@aventail.com's message of "06 Nov 1999 22:46:47 -0500" Message-ID: Lines: 13 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > This incorporates all of ben's recent suggestions. Thanks. I'll try it out. I'll try to a few of the reported failure modes of the old implementation to see whether they are gone with this cleaner version. Do you have an idea whether it should now be possible to turn the GPM support into a module? From a first glance it looks that way. Jan P.S. How can this be final patch if there are no ChangeLogs? :-) From owner-xemacs-beta@xemacs.org Sun Nov 7 09:37:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA20589 for xemacs-beta-out; Sun, 7 Nov 1999 09:37:58 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id JAA20580 for ; Sun, 7 Nov 1999 09:37:57 -0500 Received: (qmail 26274 invoked from network); 7 Nov 1999 14:36:40 -0000 Received: from usrpri2-65.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.130) by biff.kiva.net with SMTP; 7 Nov 1999 14:36:40 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id JAA03282; Sun, 7 Nov 1999 09:39:35 -0500 To: Jan Vroonhof Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Hopefully final GPM patch... References: <86wvrvneu0.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 23 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > This incorporates all of ben's recent suggestions. > > Thanks. I'll try it out. I'll try to a few of the reported failure modes > of the old implementation to see whether they are gone with this cleaner > version. Do you have an idea whether it should now be possible to turn > the GPM support into a module? From a first glance it looks that way. Yup, I've actually got xemacs/modules/gpm ready to go if anybody wants. But to use this the temacs binary MUST be linked in such a way to export all symbols (-Wl,--export-dynamic under Linux, etc) since we modify 2 global variables (event_stream and tty_console_methods) > P.S. How can this be final patch if there are no ChangeLogs? :-) I'll send those along in a separate message later today. Have to get my son ready to go to a birthday party, and we haven't gotten the present yet. :) -bp From owner-xemacs-beta@xemacs.org Sun Nov 7 10:07:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA21465 for xemacs-beta-out; Sun, 7 Nov 1999 10:07:45 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA21461 for ; Sun, 7 Nov 1999 10:07:44 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA00823; Sun, 7 Nov 1999 16:07:43 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Cp; Sun Nov 7 16:07:37 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA19400; Sun, 7 Nov 1999 16:07:37 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Hopefully final GPM patch... References: <86wvrvneu0.fsf@megalith.bp.aventail.com> <86so2i1i3d.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 07 Nov 1999 16:07:36 +0100 In-Reply-To: wmperry@aventail.com's message of "07 Nov 1999 09:39:34 -0500" Message-ID: Lines: 23 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Yup, I've actually got xemacs/modules/gpm ready to go if anybody > wants. Is there way to use the same source file for this so that it can be decided at configure time? (not that it is that relevant at this time, because Linux supports modules anyway). > But to use this the temacs binary MUST be linked in such a way to export > all symbols (-Wl,--export-dynamic under Linux, etc) since we modify 2 > global variables (event_stream and tty_console_methods) Don't we do that already? I thought that was part of the module support. You have more module experience than I do. Would it be more appropriate to introduce some wrappers to set these (and make the variables static?). Jan From owner-xemacs-beta@xemacs.org Sun Nov 7 14:13:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA26746 for xemacs-beta-out; Sun, 7 Nov 1999 14:13:53 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA26743 for ; Sun, 7 Nov 1999 14:13:51 -0500 Received: (qmail 21183 invoked from network); 7 Nov 1999 19:12:34 -0000 Received: from usrpri2-7.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.72) by biff.kiva.net with SMTP; 7 Nov 1999 19:12:34 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA04872; Sun, 7 Nov 1999 14:15:29 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Hopefully final GPM patch... References: <86wvrvneu0.fsf@megalith.bp.aventail.com> <86so2i1i3d.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 35 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > Yup, I've actually got xemacs/modules/gpm ready to go if anybody > > wants. > > Is there way to use the same source file for this so that it can be > decided at configure time? (not that it is that relevant at this time, > because Linux supports modules anyway). It does use the exact some source file. > > But to use this the temacs binary MUST be linked in such a way to export > > all symbols (-Wl,--export-dynamic under Linux, etc) since we modify 2 > > global variables (event_stream and tty_console_methods) > > Don't we do that already? I thought that was part of the module support. It didn't seem to get put into the link flags here with a clean configure. > You have more module experience than I do. Would it be more appropriate > to introduce some wrappers to set these (and make the variables static?). event_stream cannot be static, too many places muck around with them. I don't think it is worth it. I'll try to figure out why the link flags weren't set correctly, and submit a patch if necessary. I'm attaching the modules/gpm/Makefile that I hacked up. Just copy gpmevent.c over into the directly and you should be all set. -Bill P. --=-=-= Content-Disposition: attachment; filename=Makefile # # Sample makefile for a simple Emacs module. # This is slightly more complicated than would normally be the case, # as this makefile has been tailored to work in the Emacs source tree. # For samples of how to compile modules outside of the source tree # (as would be the case if a user had downloaded a module and wanted # to compile it for use within Emacs), see the samples in the sub-directory # 'installed'. # CC=../../lib-src/ellcc CFLAGS=-I. -I../../src LD=$(CC) --mode=link MKINIT=$(CC) --mode=init SRCS=gpmevent.c OBJS=$(SRCS:.c=.o) .c.o: $(CC) $(CFLAGS) -c $< MODNAME=gpmevent MODVER=1.0.0 MODTITLE="GPM mouse support" all: $(MODNAME).ell distclean: clean clean: rm -f $(MODNAME).ell $(OBJS) gpmevent_i.o gpmevent_i.c $(MODNAME).ell: $(OBJS) gpmevent_i.o $(LD) --mod-output=$@ $(OBJS) gpmevent_i.o -lgpm gpmevent_i.o: gpmevent_i.c gpmevent_i.c: $(SRCS) ELLMAKEDOC=../../lib-src/make-docfile $(MKINIT) --mod-output=$@ \ --mod-name=$(MODNAME) --mod-version=$(MODVER) \ --mod-title=$(MODTITLE) $(SRCS) --=-=-=-- From owner-xemacs-beta@xemacs.org Sun Nov 7 18:14:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA30839 for xemacs-beta-out; Sun, 7 Nov 1999 18:14:35 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA30832 for ; Sun, 7 Nov 1999 18:14:33 -0500 Received: (qmail 15742 invoked by alias); 7 Nov 1999 23:14:26 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 15724 invoked by uid 0); 7 Nov 1999 23:14:26 -0000 Received: from dialupb179.tcsn.uswest.net (HELO 666.com) (209.180.114.179) by tcsnpop1.tcsn.uswest.net with SMTP; 7 Nov 1999 23:14:26 -0000 Message-ID: <382607BA.BB023BB2@666.com> Date: Sun, 07 Nov 1999 16:14:02 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Hopefully final GPM patch... References: <86wvrvneu0.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Just verify that it works in the case where you start up XEmacs under X and then later do gnuserv -nw on a console. "William M. Perry" wrote: > This incorporates all of ben's recent suggestions. If someone wants to > hack whatever is necessary (dumped-lisp.el?) to get gpm.el loaded before > dump time, the device creation hooking seems to work, and correctly brings > up XEmacs with GPM enabled with no mucking about by the user on the linux > console. From owner-xemacs-beta@xemacs.org Sun Nov 7 22:10:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA03939 for xemacs-beta-out; Sun, 7 Nov 1999 22:10:27 -0500 Received: from unknown (1Cust196.tnt26.atl2.da.uu.net [63.28.221.196]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id WAA03913; Sun, 7 Nov 1999 22:10:11 -0500 From: art1234@pacsun.com Subject: laser printer toner advertisement Date: Sun, 8 Nov 1998 18:25:05 Message-Id: <377.195329.657317@> To: undisclosed-recipients:; Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-532-7170**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. NOTE NUMBER (3): OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE THEREOF. From owner-xemacs-beta@xemacs.org Mon Nov 8 03:44:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA11619 for xemacs-beta-out; Mon, 8 Nov 1999 03:44:46 -0500 Received: from shrimp.baynetworks.com (ns4.BayNetworks.COM [192.32.253.7]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA11616 for ; Mon, 8 Nov 1999 03:44:44 -0500 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id DAA22388 for ; Mon, 8 Nov 1999 03:40:33 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id DAA08481 for ; Mon, 8 Nov 1999 03:39:58 -0500 (EST) Received: from ltrpluim.corpemea.baynetworks.com ([141.251.166.11]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id DAA10546; Mon, 8 Nov 1999 03:43:59 -0500 for Received: (from rpluim@localhost) by ltrpluim.corpemea.baynetworks.com (8.8.7/8.8.7) id JAA26364; Mon, 8 Nov 1999 09:41:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14374.36039.728677.585296@ltrpluim.corpemea.baynetworks.com> Date: Mon, 8 Nov 1999 09:41:43 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue In-Reply-To: <9t9yacbiqj0.fsf@mraz.iskon.hr> References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Reply-To: Robert Pluim Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > rpluim@bigfoot.com writes: > > > I've finally cracked, I've had it with skip-syntax-backwards crashes > > on gnu.emacs.xemacs. Polite (for once) patch attached. Recommended > > for every version of XEmacs in the universe. > > Good idea, but isn't it pointless to refer people to a PROBLEMS file > that's not there anymore? If we aren't already shipping PROBLEMS with > XEmacs, maybe we should start. I did say "If you have access ...". If we're not shipping it, either we should ship it, or put the information in something we do ship (README? INSTALL? The FAQ? [Hmm, we don't seem to ship the FAQ, either. Maybe we should]). Robert -- The above are my opinions, and my opinions only. From owner-xemacs-beta@xemacs.org Mon Nov 8 03:47:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA11679 for xemacs-beta-out; Mon, 8 Nov 1999 03:47:03 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA11669; Mon, 8 Nov 1999 03:46:53 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id RAA29672; Mon, 8 Nov 1999 17:46:48 +0900 (JST) Mail-Copies-To: never To: xemacs-patches@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Mon_Nov__8_17:39:38_1999-1" Date: 08 Nov 1999 17:39:38 +0900 In-Reply-To: (SL Baur's message of "21 Jun 1999 17:19:08 +0900") Message-ID: <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 59 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Mon_Nov__8_17:39:38_1999-1 Content-Type: text/plain; charset=US-ASCII SL Baur writes: > Yoshiki Hayashi writes in xemacs-beta@xemacs.org: > > > xemacs -vanilla > > (insert 8000) > > Ouch! I finally traced this bug and fixed it. Integer 8000 is in the range of private charset. It is usually not defined, so every integer around 8000 can cause core dump. XEmacs 21.1 doesn't crash since it does not usually have error checking code. However, this patch is recommended for XEmacs 21.1 as it goes to hard uninterruptible loop with (insert 8000). 1999-11-08 Yoshiki Hayashi * mule-charset.h (breakup_char_1): Check whether charset exists or not. --Multipart_Mon_Nov__8_17:39:38_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="mule-charset.h.diff" Content-Transfer-Encoding: 7bit Index: mule-charset.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.h,v retrieving revision 1.7.2.5 diff -u -r1.7.2.5 mule-charset.h --- mule-charset.h 1999/10/24 03:48:45 1.7.2.5 +++ mule-charset.h 1999/11/08 08:41:35 @@ -747,6 +747,8 @@ breakup_char_1 (Emchar c, Lisp_Object *charset, int *c1, int *c2) { *charset = CHAR_CHARSET (c); + if (!CHARSETP (*charset)) + error ("Invalid character 0%o, %d, 0x%x", c, c, c); BREAKUP_CHAR_1_UNSAFE (c, *charset, *c1, *c2); } --Multipart_Mon_Nov__8_17:39:38_1999-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Mon_Nov__8_17:39:38_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 8 05:07:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA13837 for xemacs-beta-out; Mon, 8 Nov 1999 05:07:32 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA13833 for ; Mon, 8 Nov 1999 05:07:27 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11klhr-00007y-00 for ; Mon, 08 Nov 1999 11:07:23 +0100 To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 08 Nov 1999 11:07:22 +0100 In-Reply-To: Yoshiki Hayashi's message of "08 Nov 1999 17:39:38 +0900" Message-ID: <9t9ln892t5x.fsf@mraz.iskon.hr> Lines: 14 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: > 1999-11-08 Yoshiki Hayashi > > * mule-charset.h (breakup_char_1): Check whether > charset exists or not. > breakup_char_1() might not be the right place for this fix. It seems that function assumes it will get an existing charset. Maybe a more appropriate fix would be up at the callers? Also, I see that BREAKUP_CHAR is called from within redisplay. In redisplay, an error will cause a coredump. From owner-xemacs-beta@xemacs.org Mon Nov 8 06:17:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA15276 for xemacs-beta-out; Mon, 8 Nov 1999 06:17:20 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA15273 for ; Mon, 8 Nov 1999 06:17:17 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id UAA02016; Mon, 8 Nov 1999 20:17:04 +0900 (JST) Mail-Copies-To: never To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 08 Nov 1999 20:09:52 +0900 In-Reply-To: <9t9ln892t5x.fsf@mraz.iskon.hr> (Hrvoje Niksic's message of "Mon, 08 Nov 1999 11:07:22 +0100") Message-ID: <87g0yhz1bz.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 32 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Yoshiki Hayashi writes: > > > 1999-11-08 Yoshiki Hayashi > > > > * mule-charset.h (breakup_char_1): Check whether > > charset exists or not. > > > > breakup_char_1() might not be the right place for this fix. It seems > that function assumes it will get an existing charset. Maybe a more > appropriate fix would be up at the callers? But that is the only place to check. The core dump is caused at next line, BREAKUP_CHAR_1_UNSAFE (c, *charset, *c1, *c2); > Also, I see that BREAKUP_CHAR is called from within redisplay. In > redisplay, an error will cause a coredump. Then I cant fix the problem. Redisplay area is all greek to me. However, I traced redisplay-x.c part a little bit furthur. BREAKUP_CHAR is called from `separate_textual_runs'. x_output_string and x_text_width calls it. I assume those are dealing with already present text in some buffers. If this assumption is correct, passing wrong characters to BREAKUP_CHAR in redisplay part rewards core dump, I think. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Mon Nov 8 06:49:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA15982 for xemacs-beta-out; Mon, 8 Nov 1999 06:49:04 -0500 Received: from rasp.eng.cam.ac.uk (rasp.eng.cam.ac.uk [129.169.8.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA15977 for ; Mon, 8 Nov 1999 06:49:02 -0500 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by rasp.eng.cam.ac.uk with ESMTP id LAA01471; Mon, 8 Nov 1999 11:49:00 GMT Received: from kennet.eng.cam.ac.uk (via kennet [129.169.81.54]) by tigger.eng.cam.ac.uk with ESMTP id LAA14761; Mon, 8 Nov 1999 11:48:55 GMT Received: (via ge204@localhost) by kennet.eng.cam.ac.uk id LAA00884; Mon, 8 Nov 1999 11:48:54 GMT To: xemacs-beta@xemacs.org Cc: aj@suse.de Subject: Re: applying patches References: From: Gunnar Evermann In-Reply-To: Andreas Jaeger's message of "02 Nov 1999 19:20:59 +0100" Date: 08 Nov 1999 11:48:54 +0000 Message-ID: Lines: 53 User-Agent: Gnus/5.070092 (Pterodactyl Gnus v0.92) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > >>>>> Jan Vroonhof writes: > > Jan> Gunnar Evermann writes: > >> How are patches sent to xemacs-patches handled at the moment? > > Jan> Extremely ad-hoc. AFAICS nobody is applying patches to the packages at > Jan> the moment. I know -- It was more of a rhetorical question, I just wanted to kick-start the discussion :-) > >> Is anyone applying the patches sent there by people without cvs-write > >> access? > > Jan> Andy and Michael have applied most them. Normally Steve applies all > Jan> that were left out, just before a new beta releases. > > can I help out? After considering this for some time, I'm > volunteering to help. > > I should have enough time to keep the CVS archive for the packages > uptodate. I'm not sure whether there is a debate about this going on in xemacs-review, but FWIW I think this is an excellent idea. I guess it would be easier for everyone if we had a split of responsibilities like the following: - 21.1 Vin - 21.2 Steve - packages Andreas Your (Andreas) contribution would be even more significant if you could not only apply the package patches, but regularly build the new packages and sumos. We REALLY REALLY need to update them! Do we still ship that sumo with broken lookup etc.? > For those who don't know me, let me introduce myself briefly. I'm one > of the glibc developers and XEmacs is one of my favorite programs. [...] I'm sure nobody doubts that you are qualified! Many thanks for volunteering. Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Cambridge University Engineering Department From owner-xemacs-beta@xemacs.org Mon Nov 8 07:13:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA16675 for xemacs-beta-out; Mon, 8 Nov 1999 07:13:23 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA16672 for ; Mon, 8 Nov 1999 07:13:21 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id NAA21074; Mon, 8 Nov 1999 13:12:54 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11knbZ-0006qX-00; Mon, 08 Nov 1999 13:09:01 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 1EED118BA; Mon, 8 Nov 1999 13:08:59 +0100 (CET) To: Gunnar Evermann Cc: xemacs-beta@xemacs.org Subject: Re: applying patches References: From: Andreas Jaeger Date: 08 Nov 1999 13:08:59 +0100 In-Reply-To: Gunnar Evermann's message of "08 Nov 1999 11:48:54 +0000" Message-ID: Lines: 58 User-Agent: Gnus/5.07009801 (Pterodactyl Gnus v0.98.1) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Gunnar Evermann writes: Gunnar> Andreas Jaeger writes: >> >>>>> Jan Vroonhof writes: >> Jan> Gunnar Evermann writes: >> >> How are patches sent to xemacs-patches handled at the moment? >> Jan> Extremely ad-hoc. AFAICS nobody is applying patches to the packages at Jan> the moment. Gunnar> I know -- It was more of a rhetorical question, I just wanted to Gunnar> kick-start the discussion :-) You've been successfull;-) >> >> Is anyone applying the patches sent there by people without cvs-write >> >> access? >> Jan> Andy and Michael have applied most them. Normally Steve applies all Jan> that were left out, just before a new beta releases. >> >> can I help out? After considering this for some time, I'm >> volunteering to help. >> >> I should have enough time to keep the CVS archive for the packages >> uptodate. Gunnar> I'm not sure whether there is a debate about this going on in Gunnar> xemacs-review, but FWIW I think this is an excellent idea. It is going on - and the result is that I'm looking at the packages. Now I only need to have all infrastructure set up. Gunnar> I guess it would be easier for everyone if we had a split of Gunnar> responsibilities like the following: Gunnar> - 21.1 Vin Gunnar> - 21.2 Steve Gunnar> - packages Andreas Gunnar> Your (Andreas) contribution would be even more significant if you Gunnar> could not only apply the package patches, but regularly build the new Gunnar> packages and sumos. We REALLY REALLY need to update them! Do we still I know :-( Gunnar> ship that sumo with broken lookup etc.? I'll try to find my way through the packages. Updating everything will be the first job - but I'll also try to make new packages and sumos regularly available. Gunnar> [...] Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Mon Nov 8 07:45:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA18601 for xemacs-beta-out; Mon, 8 Nov 1999 07:45:07 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA18597 for ; Mon, 8 Nov 1999 07:45:05 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id HAA08110; Mon, 8 Nov 1999 07:51:57 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id NAA01360; Mon, 8 Nov 1999 13:44:45 +0100 (MET) To: Andreas Jaeger Cc: Gunnar Evermann , xemacs-beta@xemacs.org Subject: Re: applying patches References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 08 Nov 1999 13:45:19 +0100 In-Reply-To: Andreas Jaeger's message of "08 Nov 1999 13:08:59 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andreas" == Andreas Jaeger writes: Andreas> I'll try to find my way through the packages. Updating Andreas> everything will be the first job - but I'll also try to Andreas> make new packages and sumos regularly available. I'm looking forward, thanks for your work! Gunnar> [...] Andreas> Andreas Andreas> -- Andreas> Andreas Jaeger Andreas> SuSE Labs aj@suse.de Andreas> private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Mon Nov 8 07:51:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA18756 for xemacs-beta-out; Mon, 8 Nov 1999 07:51:18 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id HAA18752 for ; Mon, 8 Nov 1999 07:51:16 -0500 Received: (qmail 23484 invoked from network); 8 Nov 1999 12:49:58 -0000 Received: from usrpri2-63.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.128) by biff.kiva.net with SMTP; 8 Nov 1999 12:49:58 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id HAA08193; Mon, 8 Nov 1999 07:52:53 -0500 To: Robert Pluim Cc: xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <14374.36039.728677.585296@ltrpluim.corpemea.baynetworks.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 79 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Robert Pluim writes: > Hrvoje Niksic writes: > > rpluim@bigfoot.com writes: > > > > > I've finally cracked, I've had it with skip-syntax-backwards crashes > > > on gnu.emacs.xemacs. Polite (for once) patch attached. Recommended > > > for every version of XEmacs in the universe. > > > > Good idea, but isn't it pointless to refer people to a PROBLEMS file > > that's not there anymore? If we aren't already shipping PROBLEMS with > > XEmacs, maybe we should start. > > I did say "If you have access ...". If we're not shipping it, either > we should ship it, or put the information in something we do ship > (README? INSTALL? The FAQ? [Hmm, we don't seem to ship the FAQ, > either. Maybe we should]). For some of the problems in PROBLEMS, I would vote for configure hacking to make sure people don't even try to build XEmacs that way unless they know what they are doing. GCC_VERSION=`some magic here` dnl Search for GCC specific build problems we know about if test "$GCC" = "yes"; then case `uname -s`:`uname -m`:$GCC_VERSION in *:sun4*:gcc_281|sun4*egcs_10*) dnl Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures dnl without also using `-fno-schedule-insns'. case "$CFLAGS" in *-O2*) case "$CFLAGS" in *-fno-schedule-insns*) ;; *) AC_MSG_WARN(Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures) AC_MSG_WARN(without also using `-fno-schedule-insns'.) AC_MSG_ERROR(Aborting due to known problem) ;; esac ;; esac ;; Linux:alpha:egcs_11*) AC_MSG_WARN(There have been reports of egcs-1.1 not compiling XEmacs correctly on) AC_MSG_WARN(Alpha Linux. There have also been reports that egcs-1.0.3a is O.K.) AC_MSG_ERROR(Aborting due to known problem) ;; *:i*86*:gcc_272) case "$CFLAGS" in *-O2*) case "$CFLAGS" in *-fno-strength-reduce*) ;; *) AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) AC_MSG_WARN(`-fno-strength-reduce'.) AC_MSG_ERROR(Aborting due to known problem) ;; esac ;; case "$CFLAGS" in *-fno-caller-saves*) ;; *) AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) AC_MSG_WARN(`-fno-caller-saves'.) AC_MSG_ERROR(Aborting due to known problem) ;; esac ;; esac ;; . . . esac fi -bp From owner-xemacs-beta@xemacs.org Mon Nov 8 08:27:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA19853 for xemacs-beta-out; Mon, 8 Nov 1999 08:27:12 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id IAA19846 for ; Mon, 8 Nov 1999 08:27:10 -0500 Received: (qmail 4001 invoked from network); 8 Nov 1999 13:25:50 -0000 Received: from usrpri2-48.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.113) by biff.kiva.net with SMTP; 8 Nov 1999 13:25:50 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id IAA08503; Mon, 8 Nov 1999 08:28:45 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 28 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= Jan Vroonhof writes: > However if you want to progress from mere coolness to utter enlightenment > then you should Well, in the process of getting 'gnuclient -nw' to work correctly after you start XEmacs in X, I'm proceeding towards utter enlightenment. :) > 0. make sure the case when we have frames on more than one VC works This is working now, although the pointer disappears from both VCs when you have multiple ones going. Very very odd. I'm attaching the latest gpmevent.c in case you want to play with it. I'm not going to send a diff, because it is now 90 lines longer than the file itself. :) > 1. make sure the xterm mouse stuff works. Still not going to work at the C level. I still have high hopes for xt-mouse.el though. Maybe I'll hack on it sometime this week. > 3. Make XEmacs support the GPM selection protocol. Done in the latest round of patches. -Bill P. --=-=-= Content-Disposition: attachment; filename=gpmevent.c /* GPM functions Copyright (C) 1997 William M. Perry Copyright (C) 1999 Free Software Foundation, Inc. This file is part of XEmacs. XEmacs 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. XEmacs 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 XEmacs; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* Synched up with: Not in FSF. */ /* Authors: William Perry */ #include #include "lisp.h" #include "console.h" #include "console-tty.h" #include "device.h" #include "events.h" #include "events-mod.h" #include "sysdep.h" #include "commands.h" #include "lstream.h" #include "sysproc.h" /* for MAXDESC */ #include "process.h" #ifdef HAVE_GPM #include "gpmevent.h" #include #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 #define KG_ALT 3 #else #include #endif extern int gpm_tried; extern void *gpm_stack; static int (*orig_event_pending_p) (int); static void (*orig_next_event_cb) (struct Lisp_Event *); static Lisp_Object gpm_event_queue; static Lisp_Object gpm_event_queue_tail; struct __gpm_state { int gpm_tried; int gpm_flag; void *gpm_stack; }; static struct __gpm_state gpm_state_information[MAXDESC]; static void store_gpm_state (int fd) { gpm_state_information[fd].gpm_tried = gpm_tried; gpm_state_information[fd].gpm_flag = gpm_flag; gpm_state_information[fd].gpm_stack = gpm_stack; } static void restore_gpm_state (int fd) { gpm_tried = gpm_state_information[fd].gpm_tried; gpm_flag = gpm_state_information[fd].gpm_flag; gpm_stack = gpm_state_information[fd].gpm_stack; gpm_consolefd = gpm_fd = fd; } static void clear_gpm_state (int fd) { if (fd >= 0) { memset(&gpm_state_information[fd], '\0', sizeof(struct __gpm_state)); } gpm_tried = gpm_flag = 1; gpm_fd = gpm_consolefd = -1; gpm_stack = NULL; } static int get_process_infd (struct Lisp_Process *p) { Lisp_Object instr, outstr; get_process_streams (p, &instr, &outstr); assert (!NILP (instr)); return filedesc_stream_fd (XLSTREAM (instr)); } DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* Run GPM_GetEvent(). This function is the process handler for the GPM connection. */ (process, string)) { Gpm_Event ev; int modifiers = 0; int type = -1; int button = 1; Lisp_Object fake_event; Lisp_Process *proc; struct Lisp_Event *event = NULL; struct gcpro gcpro1; static int num_events; CHECK_PROCESS (process); restore_gpm_state (get_process_infd (XPROCESS (process))); if (!Gpm_GetEvent(&ev)) { warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed - %d", gpm_fd); return(Qzero); } GCPRO1(fake_event); num_events++; fake_event = Fmake_event (Qnil, Qnil); event = XEVENT(fake_event); event->timestamp = 0; event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ /* Whow, wouldn't named defines be NICE!?!?! */ modifiers = 0; if (ev.modifiers & 1) modifiers |= MOD_SHIFT; if (ev.modifiers & 2) modifiers |= MOD_META; if (ev.modifiers & 4) modifiers |= MOD_CONTROL; if (ev.modifiers & 8) modifiers |= MOD_META; if (ev.buttons & GPM_B_LEFT) { button = 1; } else if (ev.buttons & GPM_B_MIDDLE) { button = 2; } else if (ev.buttons & GPM_B_RIGHT) { button = 3; } switch (GPM_BARE_EVENTS(ev.type)) { case GPM_DOWN: case GPM_UP: event->event_type = (ev.type & GPM_DOWN) ? button_press_event : button_release_event; event->event.button.x = ev.x; event->event.button.y = ev.y; event->event.button.button = button; event->event.button.modifiers = modifiers; break; case GPM_MOVE: case GPM_DRAG: event->event_type = pointer_motion_event; event->event.motion.x = ev.x; event->event.motion.y = ev.y; event->event.motion.modifiers = modifiers; default: /* This will never happen */ break; } /* Handle the event */ enqueue_event (fake_event, &gpm_event_queue, &gpm_event_queue_tail); UNGCPRO; return (Qzero); } static void turn_off_gpm (char *process_name) { Lisp_Object process = Fget_process (build_string (process_name)); int fd = get_process_infd (XPROCESS (process)); restore_gpm_state (fd); Gpm_Close(); clear_gpm_state (fd); Fdelete_process (build_string (process_name)); } #ifdef TIOCLINUX static Lisp_Object tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) { /* This function can GC */ struct device *d = decode_device (Qnil); int fd = DEVICE_INFD (d); char c = 3; Lisp_Object output_stream; Lisp_Object terminal_stream; Lisp_Object output_string; struct gcpro gcpro1,gcpro2,gcpro3; GCPRO3(output_stream,terminal_stream,output_string); /* The ioctl() to paste actually puts things in the input queue of ** the virtual console, so we need to trap that data, since we are ** supposed to return the actual string selection from this ** function. */ /* I really hate doing this, but it doesn't seem to cause any ** problems, and it makes the Lstream_read stuff further down ** error out correctly instead of trying to indefinitely read from ** the console. ** ** There is no set_descriptor_blocking() function call, but in my ** testing under linux, it has not proved fatal to leave the ** descriptor in non-blocking mode. ** ** William Perry Nov 5, 1999 */ set_descriptor_non_blocking (fd); /* We need two streams, one for reading from the selected device, ** and one to write the data into. There is no writable version ** of the lisp-string lstream, so we make do with a resizing ** buffer stream, and make a string out of it after we are ** done. */ output_stream = make_resizing_buffer_output_stream (); terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); output_string = Qnil; /* #### We should arguably use a specbind() and an unwind routine here, ** #### but I don't care that much right now. */ if (NILP (output_stream) || NILP (terminal_stream)) { /* Should we signal an error here? */ goto out; } if (ioctl (fd, TIOCLINUX, &c) < 0) { /* Could not get the selection - eek */ UNGCPRO; return (Qnil); } while (1) { Bufbyte tempbuf[1024]; /* some random amount */ int i; int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), tempbuf, sizeof (tempbuf)); if (size_in_bytes <= 0) { /* end of the stream */ break; } /* convert CR->LF */ for (i = 0; i < size_in_bytes; i++) { if (tempbuf[i] == '\r') { tempbuf[i] = '\n'; } } Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); } Lstream_flush (XLSTREAM (output_stream)); output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), Lstream_byte_count (XLSTREAM (output_stream))); Lstream_delete (XLSTREAM (output_stream)); Lstream_delete (XLSTREAM (terminal_stream)); out: UNGCPRO; return (output_string); } static Lisp_Object tty_selection_exists_p (Lisp_Object selection) { return (Qt); } #endif /* TIOCLINUX */ #if 0 static Lisp_Object tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) { /* There is no way to do this cleanly - the GPM selection ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and ** end position on the _screen_, not a string to stick in there. ** Lame. ** ** William Perry Nov 4, 1999 */ } #endif /* This function appears to work once in a blue moon. I'm not sure ** exactly why either. *sigh* ** ** William Perry Nov 4, 1999 ** ** Apparently, this is the way (mouse-position) is supposed to work, ** and I was just expecting something else. (mouse-pixel-position) ** works just fine. ** ** William Perry Nov 7, 1999 */ static int tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) { Gpm_Event ev; int num_buttons; memset(&ev,'\0',sizeof(ev)); num_buttons = Gpm_GetSnapshot(&ev); if (!num_buttons) { /* This means there are events pending... */ /* #### In theory, we should drain the events pending, stick ** #### them in the queue, and return the mouse position ** #### anyway. */ return(-1); } *x = ev.x; *y = ev.y; *frame = DEVICE_SELECTED_FRAME (d); return (1); } static void tty_set_mouse_position (struct window *w, int x, int y) { /* #### I couldn't find any GPM functions that set the mouse position. #### Mr. Perry had left this function empty; that must be why. #### karlheg */ } static int gpm_event_pending_p (int user_p) { Lisp_Object event; EVENT_CHAIN_LOOP (event, gpm_event_queue) { if (!user_p || command_event_p (event)) { return (1); } } return (orig_event_pending_p (user_p)); } static void gpm_next_event_cb (struct Lisp_Event *event) { /* #### It would be nice to preserve some sort of ordering of the ** #### different types of events, but that would be quite a bit ** #### of work, and would more than likely break the abstraction ** #### between the other event loops and this one. */ if (!NILP (gpm_event_queue)) { Lisp_Object queued_event = dequeue_event (&gpm_event_queue, &gpm_event_queue_tail); *event = *(XEVENT (queued_event)); if (event->event_type == pointer_motion_event) { struct device *d = decode_device (event->channel); int fd = DEVICE_INFD (d); Gpm_DrawPointer (event->event.motion.x,event->event.motion.y, fd); } return; } return (orig_next_event_cb (event)); } static void hook_event_callbacks_once (void) { static int hooker; if (!hooker) { orig_event_pending_p = event_stream->event_pending_p; orig_next_event_cb = event_stream->next_event_cb; event_stream->event_pending_p = gpm_event_pending_p; event_stream->next_event_cb = gpm_next_event_cb; hooker = 1; } } static void hook_console_methods_once (void) { static int hooker; if (!hooker) { /* Install the mouse position methods for the TTY console type */ CONSOLE_HAS_METHOD (tty, get_mouse_position); CONSOLE_HAS_METHOD (tty, set_mouse_position); CONSOLE_HAS_METHOD (tty, get_foreign_selection); CONSOLE_HAS_METHOD (tty, selection_exists_p); #if 0 CONSOLE_HAS_METHOD (tty, own_selection); #endif } } DEFUN ("gpm-enable", Fgpm_enable, 0, 2, 0, /* Toggle accepting of GPM mouse events. */ (device, arg)) { Gpm_Connect conn; int rval; Lisp_Object gpm_process; Lisp_Object gpm_filter; struct device *d = decode_device (device); int fd = DEVICE_INFD (d); char *console_name = ttyname (fd); char process_name[1024]; hook_event_callbacks_once (); hook_console_methods_once (); if (noninteractive) { error ("Can't connect to GPM in batch mode."); } if (!console_name) { /* Something seriously wrong here... */ return (Qnil); } memset (process_name, '\0', sizeof(process_name)); snprintf (process_name, sizeof(process_name) - 1, "gpm for %s", console_name); if (NILP (arg)) { turn_off_gpm (process_name); return (Qnil); } /* DANGER DANGER. ** Though shalt not call (gpm-enable t) after we have already ** started, or stuff blows up. */ if (!NILP (Fget_process (build_string (process_name)))) { error ("GPM already enabled for this console."); } conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE|GPM_DRAG; conn.defaultMask = GPM_MOVE; conn.minMod = 0; conn.maxMod = ((1<; Mon, 8 Nov 1999 08:51:13 -0500 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id FAA14846 for ; Mon, 8 Nov 1999 05:45:24 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA16462 for ; Mon, 8 Nov 1999 08:46:44 -0500 (EST) Received: from ltrpluim.corpemea.baynetworks.com ([141.251.166.11]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id IAA05440; Mon, 8 Nov 1999 08:50:57 -0500 for Received: (from rpluim@localhost) by ltrpluim.corpemea.baynetworks.com (8.8.7/8.8.7) id OAA26445; Mon, 8 Nov 1999 14:48:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14374.54464.602027.209638@ltrpluim.corpemea.baynetworks.com> Date: Mon, 8 Nov 1999 14:48:48 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue In-Reply-To: <861za1f8m2.fsf@megalith.bp.aventail.com> References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <14374.36039.728677.585296@ltrpluim.corpemea.baynetworks.com> <861za1f8m2.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Reply-To: Robert Pluim Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: William M. Perry writes: > Robert Pluim writes: > > I did say "If you have access ...". If we're not shipping it, either > > we should ship it, or put the information in something we do ship > > (README? INSTALL? The FAQ? [Hmm, we don't seem to ship the FAQ, > > either. Maybe we should]). > > For some of the problems in PROBLEMS, I would vote for configure hacking to > make sure people don't even try to build XEmacs that way unless they know > what they are doing. > Hmm, I've just tested the skip-syntax-backwards crash recipe here with gcc 2.8.1 at -O3, and it crashes. Maybe we need *:sun4*:gcc_281|sun4*egcs_10*) dnl Don't use -O2 or higher with gcc 2.8.1 and egcs 1.0 under SPARC architectures dnl without also using `-fno-schedule-insns'. case "$CFLAGS" in *-O[23456789]*) case "$CFLAGS" in *-fno-schedule-insns*) ;; *) and similarly for the other problems that depend on the optimization level. Robert -- The above are my opinions, and my opinions only. From owner-xemacs-beta@xemacs.org Mon Nov 8 09:28:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA21681 for xemacs-beta-out; Mon, 8 Nov 1999 09:28:05 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA21678 for ; Mon, 8 Nov 1999 09:28:02 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1097149E for ; Mon, 8 Nov 1999 15:27:59 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id PAA16660; Mon, 8 Nov 1999 15:27:52 +0100 To: xemacs-beta@xemacs.org Subject: [HEADS UP] movemail locking overhaul ahead Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 08 Nov 1999 15:27:52 +0100 Message-ID: Lines: 46 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id JAA21679 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I was recently charged with overhauling our institutional mailing system. It has turned out that one of the principal issues is the coordination of locking policies between MTAs and MUAs. For various reasons, our MTA uses "dot-locking", i.e. atomic creation of dummy a dummy file "mailbox.lock" alongside the file itself, "mailbox". Along the way, I checked XEmacs and found out that locking seems to be an OS issue, but can be configured. --mail-locking=file was supposed to do the trick, and configure reports that it's using "dot-locking". However, this is a lie: movemail only uses dot-locking in the absence of other locking methods. Since quite a few src/s headers declare a locking method, dot-locking never gets used on these systems. So, obviously, there's a bug here. I could fix it, but I think the whole mail-locking issue is conceptually broken in XEmacs: - The locking policy is not an OS issue, but rather a site issue. The OS issue is what policies *work*, not which ones are in use. - This means our binary kits are broken by design on many sites. I therefore propose the following changes: The locking policies can be controlled through three mechanisms (by descending precedence): - Specification on the movemail command line. - Specification of an environment variable EMACSLOCKMETHOD with the same possible values as the --mail-locking argument to configure. - Configuration via autoconf and src/config.h. Moreover, XEmacs itself should have a variable `mail-lock-method' (values 'file, 'lockf, 'flock) initialized from a variable `configure-mail-lock-method' set by autoconf which prompts XEmacs to call movemail with the appropriate command-line argument. Of course, this will take convincing the various XEmacs MUA package authors. If nobody objects by the upcoming weekend, I'll implement this. Opinions? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Mon Nov 8 10:07:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA23420 for xemacs-beta-out; Mon, 8 Nov 1999 10:07:07 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA23409 for ; Mon, 8 Nov 1999 10:07:03 -0500 Received: by localhost id m11kqNp-00012mC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 9 Nov 1999 00:07:01 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14374.59157.478354.127829@turnbull.sk.tsukuba.ac.jp> Date: Tue, 9 Nov 1999 00:07:01 +0900 (JST) To: xemacs-beta@xemacs.org Subject: [HEADS UP] movemail locking overhaul ahead In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "ms" == Michael Sperber writes: ms> The locking policies can be controlled through three ms> mechanisms (by descending precedence): ms> - Specification on the movemail command line. ms> - Specification of an environment variable EMACSLOCKMETHOD ms> with the same possible values as the --mail-locking argument ms> to configure. ms> - Configuration via autoconf and src/config.h. Obviously XEmacs shouldn't be allowed to specify locking methods not implemented on the system in question. How do you plan to handle that given the precedence specified above? Or is this not a problem? Maybe XEmacs should bitch on startup (disabled through a site-start facility) if the environment variable or the 'mail-lock-variable is set to something strange for the system. We've already had one incident where somebody made a RedHat package using flock when all of the Linux MTAs use file locking. I don't know how this would be implemented, though :-( -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 8 11:12:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA25959 for xemacs-beta-out; Mon, 8 Nov 1999 11:12:47 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA25953 for ; Mon, 8 Nov 1999 11:12:43 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA16170; Mon, 8 Nov 1999 17:12:29 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003wc; Mon Nov 8 17:12:25 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA21355; Mon, 8 Nov 1999 17:12:25 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Reworked GPM support... References: <867ljyi42z.fsf@megalith.bp.aventail.com> <864sexru2a.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 08 Nov 1999 17:12:25 +0100 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 08:28:45 -0500" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Well, in the process of getting 'gnuclient -nw' to work correctly after you > start XEmacs in X, I'm proceeding towards utter enlightenment. :) Nice. Unfortunately I messed up the CVS tree on our linux machine (that I don't hav easy console access to anyway) so badly when handapplying the origional patches that I cannot easily test it now. I hope I find the time to play with the (by then perfect :-)) version later this week. Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 11:27:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA26668 for xemacs-beta-out; Mon, 8 Nov 1999 11:27:10 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA26660 for ; Mon, 8 Nov 1999 11:27:07 -0500 Received: (qmail 22693 invoked from network); 8 Nov 1999 16:25:48 -0000 Received: from usrpri2-31.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.96) by biff.kiva.net with SMTP; 8 Nov 1999 16:25:48 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id LAA11443; Mon, 8 Nov 1999 11:28:43 -0500 To: xemacs-beta@xemacs.org Subject: Another GPM change... X-Now-Listening-To: Metallica - Overkill Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 28 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= This adds support for GPM on multiple VCs using 'gnuclient', adds a lisp-level (gpm-enabled-p) function, and reworks the gpm.el code. It also now hooks delete-device-hook instead of kill-emacs-hook, so that the GPM stuff gets shut down correctly if you connect to a XEmacs running in X, then kill the tty connection. It is also safe now to call (progn (gpm-enable nil t) (gpm-enable nil nil) (gpm-enable nil nil)) Last round of patches it would explode because of insufficient checking of the return value of Fget_process. The GPM processes are now named uniquely for what TTY they are attached to. Well, lunch is over, time to get back to real work. :( No patch because they are all longer than the files now. If anybody on linux could try this out, I would appreciate it. With this, I'm pretty close to happy using it instead of X on my linux w/frame-buffer support compiled in. The screen is sure a lot wider :) -Bill P. --=-=-= Content-Disposition: attachment; filename=gpm.el ;;; gpm.el --- Support the mouse when emacs run on a Linux console. ;; Copyright (C) 1999 Free Software Foundation ;; Author: William Perry ;; Keywords: mouse, terminals ;; This file is part of XEmacs. ;; XEmacs 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. ;; XEmacs 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, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. (defvar gpm-enabled-devices (make-hash-table :test 'eq :size 13 :weakness 'key) "A hash table of devices with GPM currently turned on.") (defun gpm-mode (&optional arg device) "Toggle GPM mouse mode. With prefix arg, turn GPM mouse mode on if and only if arg is positive." (interactive (list current-prefix-arg (selected-device))) (cond ((null arg) ; Toggle (if (gethash device gpm-enabled-devices) (progn (gpm-enable device nil) (remhash device gpm-enabled-devices)) (gpm-enable device t) (puthash device t gpm-enabled-devices))) ((> arg 0) ; Turn on (gpm-enable device t) (puthash device t gpm-enabled-devices)) ((gethash device gpm-enabled-devices) ; Turn off (gpm-enable device nil) (remhash device gpm-enabled-devices)))) (defun turn-on-gpm-mouse-tracking (&optional device) ;; Enable mouse tracking on linux console (gpm-mode 5 device)) (defun turn-off-gpm-mouse-tracking (&optional device) ;; Disable mouse tracking on linux console (gpm-mode -5 device)) (defun gpm-create-device-hook (device) (if (and (not noninteractive) ; Don't want to do this in batch mode (fboundp 'gpm-enable) ; Must have C-level GPM support (eq system-type 'linux) ; Must be running linux (eq (device-type device) 'tty) ; on a tty (equal "linux" (console-tty-terminal-type ; an a linux terminal type (device-console device)))) (turn-on-gpm-mouse-tracking device))) (defun gpm-delete-device-hook (device) (if (and (not noninteractive) ; Don't want to do this in batch mode (fboundp 'gpm-enable) ; Must have C-level GPM support (eq system-type 'linux) ; Must be running linux (eq (device-type device) 'tty) ; on a tty (equal "linux" (console-tty-terminal-type ; an a linux terminal type (device-console device)))) (turn-off-gpm-mouse-tracking device))) ;; Restore normal mouse behaviour outside Emacs (add-hook 'suspend-hook 'turn-off-gpm-mouse-tracking) (add-hook 'suspend-resume-hook 'turn-on-gpm-mouse-tracking) (add-hook 'create-device-hook 'gpm-create-device-hook) (add-hook 'delete-device-hook 'gpm-delete-device-hook) (provide 'gpm) --=-=-= Content-Disposition: attachment; filename=gpmevent.c /* GPM functions Copyright (C) 1997 William M. Perry Copyright (C) 1999 Free Software Foundation, Inc. This file is part of XEmacs. XEmacs 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. XEmacs 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 XEmacs; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* Synched up with: Not in FSF. */ /* Authors: William Perry */ #include #include "lisp.h" #include "console.h" #include "console-tty.h" #include "device.h" #include "events.h" #include "events-mod.h" #include "sysdep.h" #include "commands.h" #include "lstream.h" #include "sysproc.h" /* for MAXDESC */ #include "process.h" #ifdef HAVE_GPM #include "gpmevent.h" #include #if (!defined(__linux__)) /* possible under xterm */ #define KG_SHIFT 0 #define KG_CTRL 2 #define KG_ALT 3 #else #include #endif extern int gpm_tried; extern void *gpm_stack; static int (*orig_event_pending_p) (int); static void (*orig_next_event_cb) (struct Lisp_Event *); static Lisp_Object gpm_event_queue; static Lisp_Object gpm_event_queue_tail; struct __gpm_state { int gpm_tried; int gpm_flag; void *gpm_stack; }; static struct __gpm_state gpm_state_information[MAXDESC]; static void store_gpm_state (int fd) { gpm_state_information[fd].gpm_tried = gpm_tried; gpm_state_information[fd].gpm_flag = gpm_flag; gpm_state_information[fd].gpm_stack = gpm_stack; } static void restore_gpm_state (int fd) { gpm_tried = gpm_state_information[fd].gpm_tried; gpm_flag = gpm_state_information[fd].gpm_flag; gpm_stack = gpm_state_information[fd].gpm_stack; gpm_consolefd = gpm_fd = fd; } static void clear_gpm_state (int fd) { if (fd >= 0) { memset(&gpm_state_information[fd], '\0', sizeof(struct __gpm_state)); } gpm_tried = gpm_flag = 1; gpm_fd = gpm_consolefd = -1; gpm_stack = NULL; } static int get_process_infd (struct Lisp_Process *p) { Lisp_Object instr, outstr; get_process_streams (p, &instr, &outstr); assert (!NILP (instr)); return filedesc_stream_fd (XLSTREAM (instr)); } DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* Run GPM_GetEvent(). This function is the process handler for the GPM connection. */ (process, string)) { Gpm_Event ev; int modifiers = 0; int type = -1; int button = 1; Lisp_Object fake_event; Lisp_Process *proc; struct Lisp_Event *event = NULL; struct gcpro gcpro1; static int num_events; CHECK_PROCESS (process); restore_gpm_state (get_process_infd (XPROCESS (process))); if (!Gpm_GetEvent(&ev)) { warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed - %d", gpm_fd); return(Qzero); } GCPRO1(fake_event); num_events++; fake_event = Fmake_event (Qnil, Qnil); event = XEVENT(fake_event); event->timestamp = 0; event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ /* Whow, wouldn't named defines be NICE!?!?! */ modifiers = 0; if (ev.modifiers & 1) modifiers |= MOD_SHIFT; if (ev.modifiers & 2) modifiers |= MOD_META; if (ev.modifiers & 4) modifiers |= MOD_CONTROL; if (ev.modifiers & 8) modifiers |= MOD_META; if (ev.buttons & GPM_B_LEFT) { button = 1; } else if (ev.buttons & GPM_B_MIDDLE) { button = 2; } else if (ev.buttons & GPM_B_RIGHT) { button = 3; } switch (GPM_BARE_EVENTS(ev.type)) { case GPM_DOWN: case GPM_UP: event->event_type = (ev.type & GPM_DOWN) ? button_press_event : button_release_event; event->event.button.x = ev.x; event->event.button.y = ev.y; event->event.button.button = button; event->event.button.modifiers = modifiers; break; case GPM_MOVE: case GPM_DRAG: event->event_type = pointer_motion_event; event->event.motion.x = ev.x; event->event.motion.y = ev.y; event->event.motion.modifiers = modifiers; default: /* This will never happen */ break; } /* Handle the event */ enqueue_event (fake_event, &gpm_event_queue, &gpm_event_queue_tail); UNGCPRO; return (Qzero); } static void turn_off_gpm (char *process_name) { Lisp_Object process = Fget_process (build_string (process_name)); int fd = -1; if (NILP (process)) { /* Something happened to our GPM process - fail silently */ return; } fd = get_process_infd (XPROCESS (process)); restore_gpm_state (fd); Gpm_Close(); clear_gpm_state (fd); Fdelete_process (build_string (process_name)); } #ifdef TIOCLINUX static Lisp_Object tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) { /* This function can GC */ struct device *d = decode_device (Qnil); int fd = DEVICE_INFD (d); char c = 3; Lisp_Object output_stream; Lisp_Object terminal_stream; Lisp_Object output_string; struct gcpro gcpro1,gcpro2,gcpro3; GCPRO3(output_stream,terminal_stream,output_string); /* The ioctl() to paste actually puts things in the input queue of ** the virtual console, so we need to trap that data, since we are ** supposed to return the actual string selection from this ** function. */ /* I really hate doing this, but it doesn't seem to cause any ** problems, and it makes the Lstream_read stuff further down ** error out correctly instead of trying to indefinitely read from ** the console. ** ** There is no set_descriptor_blocking() function call, but in my ** testing under linux, it has not proved fatal to leave the ** descriptor in non-blocking mode. ** ** William Perry Nov 5, 1999 */ set_descriptor_non_blocking (fd); /* We need two streams, one for reading from the selected device, ** and one to write the data into. There is no writable version ** of the lisp-string lstream, so we make do with a resizing ** buffer stream, and make a string out of it after we are ** done. */ output_stream = make_resizing_buffer_output_stream (); terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); output_string = Qnil; /* #### We should arguably use a specbind() and an unwind routine here, ** #### but I don't care that much right now. */ if (NILP (output_stream) || NILP (terminal_stream)) { /* Should we signal an error here? */ goto out; } if (ioctl (fd, TIOCLINUX, &c) < 0) { /* Could not get the selection - eek */ UNGCPRO; return (Qnil); } while (1) { Bufbyte tempbuf[1024]; /* some random amount */ int i; int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), tempbuf, sizeof (tempbuf)); if (size_in_bytes <= 0) { /* end of the stream */ break; } /* convert CR->LF */ for (i = 0; i < size_in_bytes; i++) { if (tempbuf[i] == '\r') { tempbuf[i] = '\n'; } } Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); } Lstream_flush (XLSTREAM (output_stream)); output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), Lstream_byte_count (XLSTREAM (output_stream))); Lstream_delete (XLSTREAM (output_stream)); Lstream_delete (XLSTREAM (terminal_stream)); out: UNGCPRO; return (output_string); } static Lisp_Object tty_selection_exists_p (Lisp_Object selection) { return (Qt); } #endif /* TIOCLINUX */ #if 0 static Lisp_Object tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) { /* There is no way to do this cleanly - the GPM selection ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and ** end position on the _screen_, not a string to stick in there. ** Lame. ** ** William Perry Nov 4, 1999 */ } #endif /* This function appears to work once in a blue moon. I'm not sure ** exactly why either. *sigh* ** ** William Perry Nov 4, 1999 ** ** Apparently, this is the way (mouse-position) is supposed to work, ** and I was just expecting something else. (mouse-pixel-position) ** works just fine. ** ** William Perry Nov 7, 1999 */ static int tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) { Gpm_Event ev; int num_buttons; memset(&ev,'\0',sizeof(ev)); num_buttons = Gpm_GetSnapshot(&ev); if (!num_buttons) { /* This means there are events pending... */ /* #### In theory, we should drain the events pending, stick ** #### them in the queue, and return the mouse position ** #### anyway. */ return(-1); } *x = ev.x; *y = ev.y; *frame = DEVICE_SELECTED_FRAME (d); return (1); } static void tty_set_mouse_position (struct window *w, int x, int y) { /* #### I couldn't find any GPM functions that set the mouse position. #### Mr. Perry had left this function empty; that must be why. #### karlheg */ } static int gpm_event_pending_p (int user_p) { Lisp_Object event; EVENT_CHAIN_LOOP (event, gpm_event_queue) { if (!user_p || command_event_p (event)) { return (1); } } return (orig_event_pending_p (user_p)); } static void gpm_next_event_cb (struct Lisp_Event *event) { /* #### It would be nice to preserve some sort of ordering of the ** #### different types of events, but that would be quite a bit ** #### of work, and would more than likely break the abstraction ** #### between the other event loops and this one. */ if (!NILP (gpm_event_queue)) { Lisp_Object queued_event = dequeue_event (&gpm_event_queue, &gpm_event_queue_tail); *event = *(XEVENT (queued_event)); if (event->event_type == pointer_motion_event) { struct device *d = decode_device (event->channel); int fd = DEVICE_INFD (d); Gpm_DrawPointer (event->event.motion.x,event->event.motion.y, fd); } return; } return (orig_next_event_cb (event)); } static void hook_event_callbacks_once (void) { static int hooker; if (!hooker) { orig_event_pending_p = event_stream->event_pending_p; orig_next_event_cb = event_stream->next_event_cb; event_stream->event_pending_p = gpm_event_pending_p; event_stream->next_event_cb = gpm_next_event_cb; hooker = 1; } } static void hook_console_methods_once (void) { static int hooker; if (!hooker) { /* Install the mouse position methods for the TTY console type */ CONSOLE_HAS_METHOD (tty, get_mouse_position); CONSOLE_HAS_METHOD (tty, set_mouse_position); CONSOLE_HAS_METHOD (tty, get_foreign_selection); CONSOLE_HAS_METHOD (tty, selection_exists_p); #if 0 CONSOLE_HAS_METHOD (tty, own_selection); #endif } } DEFUN ("gpm-enable", Fgpm_enable, 0, 2, 0, /* Toggle accepting of GPM mouse events. */ (device, arg)) { Gpm_Connect conn; int rval; Lisp_Object gpm_process; Lisp_Object gpm_filter; struct device *d = decode_device (device); int fd = DEVICE_INFD (d); char *console_name = ttyname (fd); char process_name[1024]; hook_event_callbacks_once (); hook_console_methods_once (); if (noninteractive) { error ("Can't connect to GPM in batch mode."); } if (!console_name) { /* Something seriously wrong here... */ return (Qnil); } memset (process_name, '\0', sizeof(process_name)); snprintf (process_name, sizeof(process_name) - 1, "gpm for %s", console_name); if (NILP (arg)) { turn_off_gpm (process_name); return (Qnil); } /* DANGER DANGER. ** Though shalt not call (gpm-enable t) after we have already ** started, or stuff blows up. */ if (!NILP (Fget_process (build_string (process_name)))) { error ("GPM already enabled for this console."); } conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE|GPM_DRAG; conn.defaultMask = GPM_MOVE; conn.minMod = 0; conn.maxMod = ((1<; Mon, 8 Nov 1999 11:39:44 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA21177; Mon, 8 Nov 1999 17:39:41 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005Aq; Mon Nov 8 17:39:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA21412; Mon, 8 Nov 1999 17:39:32 +0100 To: wmperry@aventail.com Cc: Robert Pluim , xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <14374.36039.728677.585296@ltrpluim.corpemea.baynetworks.com> <861za1f8m2.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 08 Nov 1999 17:39:32 +0100 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 07:52:53 -0500" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > GCC_VERSION=`some magic here` > > dnl Search for GCC specific build problems we know about > if test "$GCC" = "yes"; then > case `uname -s`:`uname -m`:$GCC_VERSION in If this could be made into a real patch than this is approved and retroactively recommended for every XEmacs known to man. Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 11:46:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA27563 for xemacs-beta-out; Mon, 8 Nov 1999 11:46:04 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA27560 for ; Mon, 8 Nov 1999 11:46:01 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA21310; Mon, 8 Nov 1999 17:45:42 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005Cu; Mon Nov 8 17:45:36 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA21414; Mon, 8 Nov 1999 17:45:35 +0100 To: Andreas Jaeger Cc: Gunnar Evermann , xemacs-beta@xemacs.org Subject: Re: applying patches References: From: Jan Vroonhof Date: 08 Nov 1999 17:45:35 +0100 In-Reply-To: Andreas Jaeger's message of "08 Nov 1999 13:08:59 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > I'll try to find my way through the packages. Updating everything > will be the first job - but I'll also try to make new packages and > sumos regularly available. Do you have CVS access already (or a working tree?), maybe we could try a divide and conquer approach. Everybody takes half a month from July to now and then we sift through the backlog that way testing patches and recommending them. Many are of the obviously correct type. Note that 'everybody' here is _not_ limited to the review board. Things are urgent enough to bend the rules a bit. Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 11:48:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA27700 for xemacs-beta-out; Mon, 8 Nov 1999 11:48:22 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA27692 for ; Mon, 8 Nov 1999 11:48:18 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA21388; Mon, 8 Nov 1999 17:48:15 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005E9; Mon Nov 8 17:48:06 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA21416; Mon, 8 Nov 1999 17:48:06 +0100 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: From: Jan Vroonhof Date: 08 Nov 1999 17:48:06 +0100 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "08 Nov 1999 15:27:52 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > The locking policies can be controlled through three mechanisms (by > descending precedence): > > - Specification on the movemail command line. > - Specification of an environment variable EMACSLOCKMETHOD with the > same possible values as the --mail-locking argument to configure. > - Configuration via autoconf and src/config.h. I propose that it should (by default) always use dotlocking (even together with any other method). Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 11:53:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA28034 for xemacs-beta-out; Mon, 8 Nov 1999 11:53:52 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA28030 for ; Mon, 8 Nov 1999 11:53:50 -0500 Received: (qmail 1263 invoked from network); 8 Nov 1999 16:52:34 -0000 Received: from usrpri2-31.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.96) by biff.kiva.net with SMTP; 8 Nov 1999 16:52:34 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id LAA11563; Mon, 8 Nov 1999 11:55:29 -0500 To: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: URL loading library? X-Now-Listening-To: Metallica - The More I See Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I was contemplating finally rewriting the HTTP code in Emacs/W3 in C. Does anybody have ideas for what HTTP library to use? I'd prefer not having to write it myself. The `libghttp' stuff from gnome looks like it could be useful. It can do asynch fetches, etc. Another alternative would be to use the W3C libwww, but I never really had good experiences with that back in my Spry days (but that was more than 4 years ago). There is code to glue it into the gtk event mechanism at http://cvs.gnome.org/lxr/source/gnorpm/tests/glibwww.c that could be fairly easily adapted to the XEmacs event mechanism. Alternatively, we could ask hrvoje to let us use the code from wget, but I don't know if that allows for asynch fetches or not. Suggestions anyone? -Bill P. From owner-xemacs-beta@xemacs.org Mon Nov 8 11:59:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA28215 for xemacs-beta-out; Mon, 8 Nov 1999 11:59:45 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA28212 for ; Mon, 8 Nov 1999 11:59:43 -0500 Received: (qmail 4213 invoked from network); 8 Nov 1999 16:58:24 -0000 Received: from usrpri2-31.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.96) by biff.kiva.net with SMTP; 8 Nov 1999 16:58:24 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id MAA11674; Mon, 8 Nov 1999 12:01:18 -0500 To: Jan Vroonhof Cc: Robert Pluim , xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue X-Now-Listening-To: Metallica - Mercyful Fate References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <14374.36039.728677.585296@ltrpluim.corpemea.baynetworks.com> <861za1f8m2.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > GCC_VERSION=`some magic here` > > > > dnl Search for GCC specific build problems we know about > > if test "$GCC" = "yes"; then > > case `uname -s`:`uname -m`:$GCC_VERSION in > > If this could be made into a real patch than this is approved and > retroactively recommended for every XEmacs known to man. Unfortunately, I don't have the time to hack on it right now... have to get back to real work and housebreaking the new puppy. :) -bp From owner-xemacs-beta@xemacs.org Mon Nov 8 12:08:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA28547 for xemacs-beta-out; Mon, 8 Nov 1999 12:08:42 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA28544 for ; Mon, 8 Nov 1999 12:08:40 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id SAA13444; Mon, 8 Nov 1999 18:07:53 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11ksDf-0008Mh-00; Mon, 08 Nov 1999 18:04:39 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id C095618BA; Mon, 8 Nov 1999 18:04:37 +0100 (CET) To: Jan Vroonhof Cc: Gunnar Evermann , xemacs-beta@xemacs.org Subject: Re: applying patches References: From: Andreas Jaeger Date: 08 Nov 1999 18:04:37 +0100 In-Reply-To: Jan Vroonhof's message of "08 Nov 1999 17:45:35 +0100" Message-ID: Lines: 35 User-Agent: Gnus/5.07009801 (Pterodactyl Gnus v0.98.1) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Jan Vroonhof writes: Jan> Andreas Jaeger writes: >> I'll try to find my way through the packages. Updating everything >> will be the first job - but I'll also try to make new packages and >> sumos regularly available. Jan> Do you have CVS access already (or a working tree?), maybe we could Jan> try a divide and conquer approach. Everybody takes half a month from Jan> July to now and then we sift through the backlog that way testing Jan> patches and recommending them. Many are of the obviously correct Jan> type. Note that 'everybody' here is _not_ limited to the review board. Jan> Things are urgent enough to bend the rules a bit. I don't have CVS write access yet[1] - but I do have the CVS tree checked out. I'd like to wait with applying patches until I've got CVS write access. I'm now downloading the xemacs-patches archives from july to november 1999. I think it's better to take a full month each. How do you want to handle this? Sending an email with a patch to Xemacs-beta asking if it is ok - and then apply it? Andreas Footnotes: [1] I'm waiting for an answer from Jareth. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Mon Nov 8 12:32:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA29334 for xemacs-beta-out; Mon, 8 Nov 1999 12:32:17 -0500 Received: from lolo.martelli.fremiet (d085.paris-35.cybercable.fr [212.198.35.85]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA29328 for ; Mon, 8 Nov 1999 12:32:10 -0500 Received: (from laurent@localhost) by lolo.martelli.fremiet (8.9.3/8.9.3/Laurent Martelli - 15/03/99) id SAA12498; Mon, 8 Nov 1999 18:31:56 +0100 To: wmperry@aventail.com Cc: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: Re: URL loading library? References: <86vh7cexdr.fsf@megalith.bp.aventail.com> From: Laurent Martelli Date: 08 Nov 1999 18:31:55 +0100 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 11:55:28 -0500" Message-ID: <87ln8828l0.fsf@lolo.martelli.fremiet> Lines: 19 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "William" == William M Perry writes: William> I was contemplating finally rewriting the HTTP code in William> Emacs/W3 in C. Does anybody have ideas for what HTTP William> library to use? I'd prefer not having to write it myself. William> The `libghttp' stuff from gnome looks like it could be William> useful. It can do asynch fetches, etc. [...] William> Alternatively, we could ask hrvoje to let us use the code William> from wget, but I don't know if that allows for asynch William> fetches or not. wget is under GPL, so you don't even need to ask him. -- Laurent Martelli martelli@iie.cnam.fr From owner-xemacs-beta@xemacs.org Mon Nov 8 13:11:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA30223 for xemacs-beta-out; Mon, 8 Nov 1999 13:11:25 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA30220 for ; Mon, 8 Nov 1999 13:11:23 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA24055; Mon, 8 Nov 1999 19:11:18 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005ri; Mon Nov 8 19:11:14 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA21676; Mon, 8 Nov 1999 19:11:14 +0100 To: Andreas Jaeger Cc: Gunnar Evermann , xemacs-beta@xemacs.org Subject: Re: applying patches References: Date: 08 Nov 1999 19:11:12 +0100 In-Reply-To: Andreas Jaeger's message of "08 Nov 1999 18:04:37 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > I think it's better to take a full month each. > > How do you want to handle this? Sending an email with a patch to > Xemacs-beta asking if it is ok - and then apply it? That would be using xemacs-beta as a substitute review but that should work. It would just be nice if you sent a confirmation message to the patch author and xemacs-review when you actually apply the patch. Maybe you should maintain a list of applied patches, like Vince does for the .1.x releases. Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 14:10:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32113 for xemacs-beta-out; Mon, 8 Nov 1999 14:10:12 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA32109 for ; Mon, 8 Nov 1999 14:10:08 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA25677; Mon, 8 Nov 1999 20:10:03 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006H9; Mon Nov 8 20:09:57 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA21724; Mon, 8 Nov 1999 20:09:56 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Another GPM change... References: <861za1eymc.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 08 Nov 1999 20:09:56 +0100 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 11:28:43 -0500" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > This adds support for GPM on multiple VCs using 'gnuclient', Wow! Could you make a big mail with all the changes and mail that to xemacs-patches.org for archiving purposes and for me. I have lost track a bit :-(. You're way too productive :-) Jan From owner-xemacs-beta@xemacs.org Mon Nov 8 14:11:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32151 for xemacs-beta-out; Mon, 8 Nov 1999 14:11:13 -0500 Received: from djlvig.dl.ac.uk (djlvig.dl.ac.uk [148.79.112.146]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA32148 for ; Mon, 8 Nov 1999 14:11:09 -0500 Received: (from fx@localhost) by djlvig.dl.ac.uk (8.8.7/8.8.5) id TAA13162; Mon, 8 Nov 1999 19:11:04 GMT To: wmperry@aventail.com Cc: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: Re: URL loading library? References: <86vh7cexdr.fsf@megalith.bp.aventail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Dave Love Date: 08 Nov 1999 19:11:04 +0000 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 11:55:28 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.07007 (Pterodactyl Gnus v0.70) Emacs/21.0 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Bill" == William M Perry writes: Bill> I was contemplating finally rewriting the HTTP code in Emacs/W3 Bill> in C. Why so? (I'm not saying it's a bad idea.) Bill> Does anybody have ideas for what HTTP library to use? This seems to be addressed only to XEmacs, but I think it would be helpful generally only to consider libraries which rms approves for Emacs use. (This sort of thing came up recently, and it seems that a library with a GPL-compatible licence may not need an assignment of the code, so there _may_ not be much of an issue.) IANrms and all that. From owner-xemacs-beta@xemacs.org Mon Nov 8 14:37:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA00886 for xemacs-beta-out; Mon, 8 Nov 1999 14:37:53 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA00882 for ; Mon, 8 Nov 1999 14:37:49 -0500 Received: (qmail 7500 invoked from network); 8 Nov 1999 19:36:32 -0000 Received: from usrpri2-49.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.114) by biff.kiva.net with SMTP; 8 Nov 1999 19:36:32 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA17169; Mon, 8 Nov 1999 14:39:27 -0500 To: Dave Love Cc: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: Re: URL loading library? X-Now-Listening-To: Metallica - Whiskey In The Jar References: <86vh7cexdr.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 31 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Dave Love writes: > >>>>> "Bill" == William M Perry writes: > > Bill> I was contemplating finally rewriting the HTTP code in Emacs/W3 > Bill> in C. > > Why so? (I'm not saying it's a bad idea.) To get better support for streaming (maybe), things like persistent connections, chunked encoding, etc. > Bill> Does anybody have ideas for what HTTP library to use? > > This seems to be addressed only to XEmacs, but I think it would be > helpful generally only to consider libraries which rms approves for Emacs > use. (This sort of thing came up recently, and it seems that a library > with a GPL-compatible licence may not need an assignment of the code, so > there _may_ not be much of an issue.) IANrms and all that. Nice acronym. :) I'd implement the glue code for both Emacs and XEmacs, so it would definitely need to be GPL'd which points towards libghttp or wget, but libghttp doesn't really work all that well, and the asynchronousness leaves a lot to be desired (polling - ick). I might break down and look at libwww again tonight - if I can leave out the chunks I don't need, it should be able to integrate with the event loops nicely. If it can deal with Gtk, it should be childs play to make it work with Emacs/XEmacs. :) -Bill P. From owner-xemacs-beta@xemacs.org Mon Nov 8 14:57:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA01572 for xemacs-beta-out; Mon, 8 Nov 1999 14:57:47 -0500 Received: from faerie.whatever.org (Nice-10-243.abo.wanadoo.fr [164.138.223.243]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA01567 for ; Mon, 8 Nov 1999 14:57:45 -0500 Received: (from stephane@localhost) by faerie.whatever.org (8.9.3/8.9.3/Debian/GNU) id UAA01080 for xemacs-beta@xemacs.org; Mon, 8 Nov 1999 20:57:42 +0100 Date: Mon, 8 Nov 1999 20:57:42 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Subject: XEmacs 21.2.19 crash Message-ID: <19991108205741.A1075@faerie.whatever.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: as of CVS some days ago: uname -a: Linux labyrinth 2.2.5 #1 Tue Oct 12 17:50:33 CEST 1999 i686 unknown ./configure '--with-mule' '--with-widgets=athena3d' '--with-dialogs=athena3d' XEmacs 21.2-b19 "Shinjuku" configured for `i686-pc-linux'. Where should the build process find the source code? /opt/src/xemacs What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) -------- mmmm.... not much, and i do not have a core because it was not enabled. i have NO clue why it crashed or when or what it was doing. i was just focusing it back for the thousandth time with my autoraise mouse on X. i will cvs update and try to run it with core enabled and see what happens. -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Rotterdam # Lunatech Research, # NETHERLANDS # soon we will drop the searching for the finding... # # From owner-xemacs-beta@xemacs.org Mon Nov 8 16:30:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA05283 for xemacs-beta-out; Mon, 8 Nov 1999 16:30:07 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA05279 for ; Mon, 8 Nov 1999 16:30:04 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id QAA11363; Mon, 8 Nov 1999 16:36:51 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id WAA02827; Mon, 8 Nov 1999 22:29:40 +0100 (MET) To: Andreas Jaeger Cc: Jan Vroonhof , Gunnar Evermann , xemacs-beta@xemacs.org Subject: Re: applying patches References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 08 Nov 1999 22:29:35 +0100 In-Reply-To: Andreas Jaeger's message of "08 Nov 1999 18:04:37 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andreas" == Andreas Jaeger writes: Andreas> How do you want to handle this? Sending an email with a Andreas> patch to Xemacs-beta asking if it is ok - and then apply Andreas> it? How about just sending the xemacs-patches mail archive article URL to the list? Regards, Adrian Andreas> Andreas From owner-xemacs-beta@xemacs.org Mon Nov 8 16:33:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA05423 for xemacs-beta-out; Mon, 8 Nov 1999 16:33:47 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA05418 for ; Mon, 8 Nov 1999 16:33:43 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id WAA25696 for ; Mon, 8 Nov 1999 22:33:41 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id WAA13181 for xemacs-beta@xemacs.org; Mon, 8 Nov 1999 22:33:41 +0100 Date: Mon, 8 Nov 1999 22:33:41 +0100 From: Stef Epardaud To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.2.19 crash: stack here Message-ID: <19991108223341.A12738@tanglefoot.lunatech.com> References: <19991108205741.A1075@faerie.whatever.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19991108205741.A1075@faerie.whatever.org>; from Stef Epardaud on Mon, Nov 08, 1999 at 08:57:42PM +0100 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: updated to latest cvs and it crashed after a while, not responding for a second then boom! could not catch the list backtrace this time though, sorry. if anybody wants one, i'm sure it will crash again ... :( more details: ask me, you are welcome :) GNU gdb 19990928 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libXaw3d.so.6...done. Reading symbols from /usr/lib/libtiff.so.3...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libncurses.so.4...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_compat.so.2...done. Reading symbols from /lib/libnsl.so.1...done. #0 0x402f15d1 in kill () from /lib/libc.so.6 (gdb) where #0 0x402f15d1 in kill () from /lib/libc.so.6 #1 0x808d2d4 in fatal_error_signal (sig=11) at emacs.c:276 #2 0x402f1508 in sigaction () from /lib/libc.so.6 #3 0x81e05f6 in XawTabsSetHighlight (t=0x8591fe8, w=0x8594a60) at xlwtabs.c:1285 #4 0x81dfd40 in XawTabsSetTop (w=0x8594a60, callCallbacks=1) at xlwtabs.c:1264 #5 0x81e09ff in TabsSelect (w=0x8591fe8, event=0xbffff1ac, params=0x0, num_params=0x4016cd14) at xlwtabs.c:1049 #6 0x4015e773 in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #7 0x4015ebcc in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #8 0x4015f0e4 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x4013cd15 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x4013d63e in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 #11 0x4013d888 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #12 0x40148074 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #13 0x81a943b in emacs_Xt_next_event (emacs_event=0x882e320) at event-Xt.c:2427 #14 0x80d48e8 in event_stream_next_event (event=0x882e320) at event-stream.c:565 #15 0x80d6a90 in next_event_internal (target_event=142795552, allow_queued=1) at event-stream.c:2020 #16 0x80d710d in Fnext_event (event=142795552, prompt=136859988) at event-stream.c:2237 #17 0x8071481 in Fcommand_loop_1 () at cmdloop.c:566 #18 0x807172d in command_loop_1 (dummy=136859988) at cmdloop.c:490 #19 0x808f7ae in condition_case_1 (handlers=136860084, bfun=0x80716e4 , barg=136859988, hfun=0x807179c , harg=136859988) at eval.c:1630 #20 0x807188f in command_loop_2 (dummy=136859988) at cmdloop.c:252 #21 0x80969cc in internal_catch (tag=136934204, func=0x8071850 , arg=136859988, threw=0x0) at eval.c:1305 #22 0x8070c9e in initial_command_loop (load_me=136859988) at cmdloop.c:301 #23 0x808b67d in xemacs_21_2_b19_i686_pc_linux () at emacs.c:1873 #24 0x808d4f0 in voodoo_free_hook (mem=0x1) at emacs.c:2298 #25 0x402eb7a2 in __libc_start_main () from /lib/libc.so.6 mmm :-/ ... looks like it is in xlwtabs.c, and i just sent a patch to remove warnings from the file :(, i hope it is not my changes, but i looked quickly and i do not think it is , or it is not obvious. anyways, sorry if it makes debugging any harder, the patch has been sent to xemacs-patches some days ago. (i really hope it is not me) -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Mon Nov 8 17:28:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA07606 for xemacs-beta-out; Mon, 8 Nov 1999 17:28:12 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA07602 for ; Mon, 8 Nov 1999 17:28:07 -0500 Received: by crystal.WonderWorks.COM id QQhomr09533; Mon, 8 Nov 1999 14:28:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.20084.353313.115522@crystal.WonderWorks.COM> Date: Mon, 8 Nov 1999 14:28:04 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: [HEADS UP] movemail locking overhaul ahead In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] writes: > - The locking policy is not an OS issue, but rather a site issue. > The OS issue is what policies *work*, not which ones are in use. The locking stuff in a s/*.h file reflects the locking policy in use by the default delivery agent on that operating system. Example: Under BSD/OS, mail.local is the default delivery agent and it locks mailboxes with flock() during delivery. Dot-locking is possible under BSD/OS, but if you make movemail use it, you will be sorry, because you will lose a lot of mail. Since the prevalent mailbox locking policy isn't testable under autoconf, we need to preserve this information. > The locking policies can be controlled through three mechanisms (by > descending precedence): > > - Specification on the movemail command line. > - Specification of an environment variable EMACSLOCKMETHOD with the > same possible values as the --mail-locking argument to configure. > - Configuration via autoconf and src/config.h. OK with me, so long as it is heavily stressed that the OS-based locking default should not be changed unless you know what you are doing, it voids your warranty, cows will bark, etc. From owner-xemacs-beta@xemacs.org Mon Nov 8 17:53:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA08625 for xemacs-beta-out; Mon, 8 Nov 1999 17:53:52 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA08556; Mon, 8 Nov 1999 17:52:01 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id RAA21137; Mon, 8 Nov 1999 17:59:05 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id XAA02985; Mon, 8 Nov 1999 23:51:52 +0100 (MET) To: XEmacs Beta List , XEmacs NT List Subject: fstat/stat bugs on Windows NT? X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 08 Nov 1999 23:51:42 +0100 Message-ID: Lines: 77 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello Groups, I am asking for your help on another problem in XEmacs on Windows NT native: fstat and stat seem wrong on Windows NT. XEmacs tries to work around the stat problem by implementing its own version. It does however use the equally buggy fstat version of Windows NT. This creates the issue that .el files appear newer than their .elc files (created while DST was on) after DST is switches off. Inside DEFUN ("load-internal", Fload_internal, 1, 6, 0, /* in lread.c the .elc file is fstat'ed with NT's native implementation while the .el file is stat'ed with XEmacs's stat implementation. perl (This is perl, version 5.005_03 built for MSWin32-x86) gives the same results as the Windows NT compatibility function stat. Here's what I see: My computer is in the MET-1MDT timezone. I have not explicitely set env. var. TZ in the experiments below, but that did not help when I tried. With system date "nov 8 1999" I create a file called "winter". I switch the system date to "oct 8 1999" and create "summer". Now I get different time_t values for their modification time both in perl and Windows NT functions fstat/stat, depending on the current date of the computer: With computer date "oct 8 1999": d:\Users\AichnerAd\tz\summer st_mtime: 939409806 gmtime Fri Oct 8 19:10:06 1999 localtime Fri Oct 8 21:10:06 1999 d:\Users\AichnerAd\tz\winter st_mtime: 942095185 gmtime Mon Nov 8 21:06:25 1999 localtime Mon Nov 8 22:06:25 1999 With computer date "nov 8 1999": d:\Users\AichnerAd\tz\summer st_mtime: 939406206 gmtime Fri Oct 8 18:10:06 1999 localtime Fri Oct 8 20:10:06 1999 d:\Users\AichnerAd\tz\winter st_mtime: 942091585 gmtime Mon Nov 8 20:06:25 1999 localtime Mon Nov 8 21:06:25 1999 I am happy with the distances between GMT (=UTC) and localtime, which are 2 hours in summer, 1 hour in winter (for MidEuropeanTime). However, the supposedly absolute modification time of a file changes with the current computer date setting (see st_mtime: ...) above. Please confirm that this is actually a Windows NT bug! FileTimeToLocalFileTime has this bothering remark, that a FILETIME will be adjusted according to the current DST status, not according to the file's time. Yuck! Could the knowledgable please comment? Currently I suppose the fix is to also encapsulate fstat in XEmacs Windows NT native. Any suggestions? Best regards, Adrian From owner-xemacs-beta@xemacs.org Mon Nov 8 18:19:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA09631 for xemacs-beta-out; Mon, 8 Nov 1999 18:19:06 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA09626 for ; Mon, 8 Nov 1999 18:19:03 -0500 Received: by crystal.WonderWorks.COM id QQhomv10379; Mon, 8 Nov 1999 15:19:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.23141.101599.635073@crystal.WonderWorks.COM> Date: Mon, 8 Nov 1999 15:19:00 -0800 (PST) From: Kyle Jones To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 In-Reply-To: <9t9ln892t5x.fsf@mraz.iskon.hr> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: (insert 8000) seems fundamentally broken to me. Integers are not characters. We went through reams of Ebola warnings last year (or was it the year before) to get rid of stuff like this. I think Finsert ought to be made to signal wrong-type-argument when handed an integer. From owner-xemacs-beta@xemacs.org Mon Nov 8 20:12:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA16210 for xemacs-beta-out; Mon, 8 Nov 1999 20:12:36 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA16206 for ; Mon, 8 Nov 1999 20:12:35 -0500 Received: (qmail 14243 invoked from network); 9 Nov 1999 01:11:12 -0000 Received: from usrpri2-36.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.101) by biff.kiva.net with SMTP; 9 Nov 1999 01:11:12 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA20424; Mon, 8 Nov 1999 20:14:06 -0500 To: xemacs-beta@xemacs.org Subject: xterm mouse support... kindof... X-Now-Listening-To: Tom Petty & The Heartbreakers - Echo Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 34 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= This gets it mostly working. I think I'll leave it for someone else to actually hack it the rest of the way. :) Main differences were writing the functions window-at and coordinates-in-window-p. coordinates-in-window-p is not 100% correct. According to the docs of Emacs 21, it should be: ------------------------------------------------------------------------------- Return non-nil if COORDINATES are in WINDOW. COORDINATES is a cons of the form (X . Y), X and Y being distances measured in characters from the upper-left corner of the frame. (0 . 0) denotes the character in the upper left corner of the frame. If COORDINATES are in the text portion of WINDOW, the coordinates relative to the window are returned. If they are in the mode line of WINDOW, `mode-line' is returned. If they are in the top mode line of WINDOW, `header-line' is returned. If they are in the bitmap-area to the left of the window, `left-bitmap-area' is returned, if they are in the area on the right of the window, `right-bitmap-area' is returned. If they are on the border between WINDOW and its right sibling, `vertical-line' is returned. ------------------------------------------------------------------------------- Nothing but the coordinate munging is done, so dragging the mode line and friends won't work. And since XEmacs unread-command-events really does what it says (command-events only), motion events are unimplemented. Enjoy! -Bill P. --=-=-= Content-Disposition: attachment; filename=xt-mouse.el ;;; xt-mouse.el --- Support the mouse when emacs run in an xterm. ;; Copyright (C) 1994 Free Software Foundation ;; Author: Per Abrahamsen ;; Keywords: mouse, terminals ;; 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, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;;; Comments: ;; Enable mouse support when running inside an xterm or Linux console. ;; This is actually useful when you are running X11 locally, but is ;; working on remote machine over a modem line or through a gateway. ;; It works by translating xterm escape codes into generic emacs mouse ;; events so it should work with any package that uses the mouse. ;; The xterm mouse escape codes are supposedly also supported by the ;; Linux console, but I have not been able to verify this. ;; You don't have to turn off xterm mode to use the normal xterm mouse ;; functionality, it is still available by holding down the SHIFT key ;; when you press the mouse button. ;;; Todo: ;; Support multi-click -- somehow. ;; Clicking on the mode-line does not work, although it should. ;;; Code: (define-key function-key-map "\e[M" 'xterm-mouse-translate) (defvar xterm-mouse-last) (defun xterm-mouse-translate (event) ;; Read a click and release event from XTerm. (save-excursion (save-window-excursion ;;(deactivate-mark) ; Emacs-ism (let* ((xterm-mouse-last) (down (xterm-mouse-event)) ;;; (down-command (nth 0 down)) ;;; (down-data (nth 1 down)) (down-where (cons (event-x down) (event-y down))) (down-binding (key-binding down))) (or (and (eq (read-char) ?\e) (eq (read-char) ?\[) (eq (read-char) ?M)) (error "Unexpected escape sequence from XTerm")) ;(debug) (let* ((click (xterm-mouse-event)) ;;; (click-command (nth 0 click)) ;;; (click-data (nth 1 click)) (click-where (cons (event-x click) (event-y click)))) (if (memq down-binding '(nil ignore)) (if (and (symbolp click-where) (not (eq 'menu-bar click-where))) (error "Not sure what to do here") ; (vector (list click-where click-data) click) click) (setq unread-command-events (if unread-command-events (append unread-command-events click) (list click))))) (vector down))))) (defvar xterm-mouse-x 0 "Position of last xterm mouse event relative to the frame.") (defvar xterm-mouse-y 0 "Position of last xterm mouse event relative to the frame.") ;; Indicator for the xterm-mouse mode. (defvar xterm-mouse-mode nil) (defadvice mouse-position (around xterm-mouse activate) "Use last key from xterm-mouse-mode if available." (let ((answer ad-do-it)) (setq ad-return-value (if xterm-mouse-mode (cons (car answer) (cons xterm-mouse-x xterm-mouse-y)) answer)))) (if (not (fboundp 'window-at)) (defun window-at (x y &optional frame) (let ((windows (window-list frame t)) (edges nil) (found nil)) (while windows (setq edges (window-pixel-edges (car windows))) (if (and (>= x (nth 0 edges)) (<= x (nth 2 edges)) (>= y (nth 1 edges)) (<= y (nth 3 edges))) (setq found (car windows) windows nil)) (setq windows (cdr windows))) found))) (if (not (fboundp 'coordinates-in-window-p)) (defun coordinates-in-window-p (coordinates window) (let ((edges (window-pixel-edges window)) (x (car coordinates)) (y (cdr coordinates))) (if (and (>= x (nth 0 edges)) (<= x (nth 2 edges)) (>= y (nth 1 edges)) (<= y (nth 3 edges))) (cons (- x (nth 0 edges)) (- y (nth 1 edges))))))) (defun xterm-mouse-event () ;; Convert XTerm mouse event to Emacs mouse event. (let* ((type (- (read-char) ? )) (x (- (read-char) ? 1)) (y (- (read-char) ? 1)) (point (cons x y)) (window (window-at x y)) (where (if window (coordinates-in-window-p point window) 'menu-bar)) (pos (if (consp where) (progn (select-window window) (goto-char (window-start window)) (move-to-window-line (cdr where)) (move-to-column (+ (car where) (current-column) (if (string-match "\\` \\*Minibuf" (buffer-name)) (- (minibuffer-prompt-width)) 0) (max 0 (1- (window-hscroll))))) (point)) where)) (mouse-button (if (eq type 3) (+ 1 xterm-mouse-last) (setq xterm-mouse-last type) (+ 1 type))) (event-type (if (eq type 3) 'button-release 'button-press))) (setq xterm-mouse-x x xterm-mouse-y y) (allocate-event event-type (list 'channel (window-frame window) 'button mouse-button 'x x 'y (1+ y))))) (or (assq 'xterm-mouse-mode minor-mode-alist) (setq minor-mode-alist (cons '(xterm-mouse-mode (" Mouse")) minor-mode-alist))) ;;;###autoload (defun xterm-mouse-mode (arg) "Toggle XTerm mouse mode. With prefix arg, turn XTerm mouse mode on iff arg is positive. Turn it on to use emacs mouse commands, and off to use xterm mouse commands." (interactive "P") (if (or (and (null arg) xterm-mouse-mode) (<= (prefix-numeric-value arg) 0)) ;; Turn it off (if xterm-mouse-mode (progn (turn-off-xterm-mouse-tracking) (setq xterm-mouse-mode nil) (set-buffer-modified-p (buffer-modified-p)))) ;;Turn it on (if xterm-mouse-mode () (setq xterm-mouse-mode t) (turn-on-xterm-mouse-tracking) (set-buffer-modified-p (buffer-modified-p))))) (defun turn-on-xterm-mouse-tracking () ;; Enable emacs mouse tracking in xterm. (if xterm-mouse-mode (send-string-to-terminal "\e[?1000h" nil (selected-device)))) (defun turn-off-xterm-mouse-tracking () ;; Disable disable emacs mouse tracking in xterm. (if xterm-mouse-mode (send-string-to-terminal "\e[?1000l" nil (selected-device)))) ;; Restore normal mouse behaviour outside Emacs. (add-hook 'suspend-hook 'turn-off-xterm-mouse-tracking) (add-hook 'suspend-resume-hook 'turn-on-xterm-mouse-tracking) (add-hook 'kill-emacs-hook 'turn-off-xterm-mouse-tracking) (provide 'xt-mouse) ;;; xt-mouse.el ends here --=-=-=-- From owner-xemacs-beta@xemacs.org Mon Nov 8 20:47:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA17252 for xemacs-beta-out; Mon, 8 Nov 1999 20:47:21 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA17249 for ; Mon, 8 Nov 1999 20:47:18 -0500 Received: by localhost id m11l0NO-00012mC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 9 Nov 1999 10:47:14 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> Date: Tue, 9 Nov 1999 10:47:14 +0900 (JST) To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 In-Reply-To: <14375.23141.101599.635073@crystal.WonderWorks.COM> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> (insert 8000) seems fundamentally broken to me. [...] Kyle> I think Finsert ought to be made to signal Kyle> wrong-type-argument when handed an integer. Agree. In Mule characters must be opaque objects---currently they have internal structure, and internal representation is under consideration for revision. FSFmacs has the appropriate character-creation functions because it uses the same representation; code that doesn't use them is broken in both variants. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 8 22:37:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA20340 for xemacs-beta-out; Mon, 8 Nov 1999 22:37:07 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA20331; Mon, 8 Nov 1999 22:36:58 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id MAA24142; Tue, 9 Nov 1999 12:36:48 +0900 (JST) Mail-Copies-To: never To: "Stephen J. Turnbull" Cc: XEmacs Beta List , xemacs-patches@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Tue_Nov__9_12:29:38_1999-1" Date: 09 Nov 1999 12:29:38 +0900 In-Reply-To: <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 09 Nov 1999 10:47:14 +0900 (JST)") Message-ID: <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 65 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Tue_Nov__9_12:29:38_1999-1 Content-Type: text/plain; charset=US-ASCII "Stephen J. Turnbull" writes: > >>>>> "Kyle" == Kyle Jones writes: > > Kyle> (insert 8000) seems fundamentally broken to me. [...] > > Kyle> I think Finsert ought to be made to signal > Kyle> wrong-type-argument when handed an integer. > > Agree. > > In Mule characters must be opaque objects---currently they have > internal structure, and internal representation is under consideration > for revision. FSFmacs has the appropriate character-creation > functions because it uses the same representation; code that doesn't > use them is broken in both variants. OK. Here is the patch. With this patch, Finsert will be OK, but you can still make XEmacs crash with (int-to-char 8000). I'll write fix for that later. When this patch is applied, w3 must be fixed since it uses (insert INT) to insert Ϩ or something like that. 1999-11-09 Yoshiki Hayashi * editfns.c (buffer_insert_1): Don't treat an integer as a character. --Multipart_Tue_Nov__9_12:29:38_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="editfns.c.diff" Content-Transfer-Encoding: 7bit Index: editfns.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/editfns.c,v retrieving revision 1.22.2.7 diff -u -r1.22.2.7 editfns.c --- editfns.c 1999/09/03 08:30:17 1.22.2.7 +++ editfns.c 1999/11/09 03:35:37 @@ -1433,9 +1433,9 @@ struct gcpro gcpro1; GCPRO1 (arg); retry: - if (CHAR_OR_CHAR_INTP (arg)) + if (CHARP (arg)) { - buffer_insert_emacs_char (buf, XCHAR_OR_CHAR_INT (arg)); + buffer_insert_emacs_char (buf, XCHAR (arg)); } else if (STRINGP (arg)) { --Multipart_Tue_Nov__9_12:29:38_1999-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Tue_Nov__9_12:29:38_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 8 23:14:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA21629 for xemacs-beta-out; Mon, 8 Nov 1999 23:14:12 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id XAA21625 for ; Mon, 8 Nov 1999 23:14:11 -0500 Received: (qmail 18526 invoked by alias); 9 Nov 1999 04:13:59 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 18496 invoked by uid 0); 9 Nov 1999 04:13:58 -0000 Received: from dialupe105.tcsn.uswest.net (HELO 666.com) (209.180.112.105) by tcsnpop1.tcsn.uswest.net with SMTP; 9 Nov 1999 04:13:58 -0000 Message-ID: <38279F70.47668B26@666.com> Date: Mon, 08 Nov 1999 21:13:37 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Veto. Instead, fix buffer_insert_1() and Finsert_markers() -- they need a call to CHECK_CHAR_COERCE_INT() inserted. Yoshiki Hayashi wrote: > SL Baur writes: > > > Yoshiki Hayashi writes in xemacs-beta@xemacs.org: > > > > > xemacs -vanilla > > > (insert 8000) > > > > Ouch! > > I finally traced this bug and fixed it. > > Integer 8000 is in the range of private charset. It is > usually not defined, so every integer around 8000 can cause > core dump. > > XEmacs 21.1 doesn't crash since it does not usually have > error checking code. However, this patch is recommended for > XEmacs 21.1 as it goes to hard uninterruptible loop with > (insert 8000). > > 1999-11-08 Yoshiki Hayashi > > * mule-charset.h (breakup_char_1): Check whether > charset exists or not. > > ------------------------------------------------------------------------ > Name: mule-charset.h.diff > mule-charset.h.diff Type: Plain Text (text/plain) > Encoding: 7bit > > ------------------------------------------------------------------------ > > -- > Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Tue Nov 9 01:42:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA25740 for xemacs-beta-out; Tue, 9 Nov 1999 01:42:21 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA25683; Tue, 9 Nov 1999 01:40:45 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id PAA27280; Tue, 9 Nov 1999 15:40:37 +0900 (JST) Mail-Copies-To: never To: Ben Wing Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <38279F70.47668B26@666.com> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 09 Nov 1999 15:33:28 +0900 In-Reply-To: <38279F70.47668B26@666.com> (Ben Wing's message of "Mon, 08 Nov 1999 21:13:37 -0700") Message-ID: <87g0ygyy13.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 36 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Veto. Instead, fix buffer_insert_1() and Finsert_markers() -- they need a call to > CHECK_CHAR_COERCE_INT() inserted. Thanks. I found bug in Finsert_char and others. It calls CHECK_CHAR_COERCE_INT but it is not sufficient. Its definition is #define CHECK_CHAR_COERCE_INT(x) do { \ if (CHARP (x)) \ ; \ else if (CHAR_INTP (x)) \ x = make_char (XINT (x)); \ else \ x = wrong_type_argument (Qcharacterp, x); \ } while (0) so it accepts integer as an argument. (insert-char ?8000) is OK while (insert-char 8000) makes XEmacs crash. It should reject integer argument, right? Other function which call CHECK_CHAR_COERCE_INT is also broken. For example, you can crash XEmacs with (make-string 1 8000). How should I fix this? Should I change CHECK_CHAR_COERCE_INT not to accept integer or make new macro CHECK_CHAR_COERCE which doesn't accept integer? BTW, I couldn't find Finsert_markers. I found Finsert_before_markers but it just calls buffer_insert_1 when argument is char or int. So it's OK when we fix buffer_insert_1. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Tue Nov 9 01:54:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA26016 for xemacs-beta-out; Tue, 9 Nov 1999 01:54:30 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA26009; Tue, 9 Nov 1999 01:54:16 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id WAA25164; Mon, 8 Nov 1999 22:54:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.50455.447946.792924@lasker.666.com> Date: Mon, 8 Nov 1999 22:54:15 -0800 (PST) From: Ben Wing , Martin Buchholz To: XEmacs Beta Test Subject: JOBS list for XEmacs X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: Ben Wing Cc: Ben Wing Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben and I have come up with a tentative list of XEmacs `jobs', or areas of responsibility. The idea here is that the people listed as `Primary' are responsible for any problems in this area. However, in the event that all of the listed Primaries disapppear and become unresponsive to email, the Secondary agrees to step up and take over, at least temporarily. Please suggest changes and additions to this list. It will be wonderful if people would volunteer for unfilled positions. Position Primary Secondary ------------------------------------------------------------ Beta Release Maintainer Martin Buchholz Stable Release Maintainer Vinnie Shelton Jobs-List-Maintainer Ben Wing Japanese Liaison Stephen Turnbull Core Patch Tender Jan Vroonhof Andy Piper, Martin Buchholz Package Patch Tender Andreas Jaeger Martin Buchholz CVS Manager Jareth Hein Mailing List Manager Jason Mastaler Martin Buchholz Webmaster John Anderson Bug Tracker Miscellaneous Documentation --------------------------- Lisp Reference Manual Martin Buchholz XEmacs User Manual Martin Buchholz Internals Manual Martin Buchholz PROBLEMS Martin Buchholz FAQ Martin Buchholz NEWS Hrvoje Niksic Martin Buchholz README README Martin Buchholz Coding Projects --------------- Coding Standards Martin Buchholz Portable Dumper Olivier Galibert Windows support Configure support Martin Buchholz Mule Ben Wing, Martin Buchhlz, Olivier Galibert GUI support Andy Piper Redisplay Andy Piper Ben and Martin From owner-xemacs-beta@xemacs.org Tue Nov 9 02:06:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA26398 for xemacs-beta-out; Tue, 9 Nov 1999 02:06:24 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id CAA26389 for ; Tue, 9 Nov 1999 02:06:21 -0500 Received: (qmail 13629 invoked by alias); 9 Nov 1999 07:06:17 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 13597 invoked by uid 0); 9 Nov 1999 07:06:15 -0000 Received: from dialupe78.tcsn.uswest.net (HELO 666.com) (209.180.112.78) by tcsnpop1.tcsn.uswest.net with SMTP; 9 Nov 1999 07:06:15 -0000 Message-ID: <3827C7A4.6B7AE63E@666.com> Date: Tue, 09 Nov 1999 00:05:08 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: "Stephen J. Turnbull" , XEmacs Beta List , xemacs-review@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Veto. When I wrote all this code, I made a conscious decision, for compatibility reasons, to allow integers wherever characters are allowed. If we're going to change this, (a) we should think carefully about what this means, and (b) we should fix this all throughout XEmacs. The bug you're seeing looks to actually be a bug in CHAR_INTP(), which is supposed to recognize valid character integers. Therefore, you should fix this macro. ben Yoshiki Hayashi wrote: > "Stephen J. Turnbull" writes: > > > >>>>> "Kyle" == Kyle Jones writes: > > > > Kyle> (insert 8000) seems fundamentally broken to me. [...] > > > > Kyle> I think Finsert ought to be made to signal > > Kyle> wrong-type-argument when handed an integer. > > > > Agree. > > > > In Mule characters must be opaque objects---currently they have > > internal structure, and internal representation is under consideration > > for revision. FSFmacs has the appropriate character-creation > > functions because it uses the same representation; code that doesn't > > use them is broken in both variants. > > OK. Here is the patch. With this patch, Finsert will be OK, > but you can still make XEmacs crash with (int-to-char 8000). > I'll write fix for that later. > When this patch is applied, w3 must be fixed since it uses > (insert INT) to insert Ϩ or something like that. > > 1999-11-09 Yoshiki Hayashi > > * editfns.c (buffer_insert_1): Don't treat an integer as > a character. > > ------------------------------------------------------------------------ > Name: editfns.c.diff > editfns.c.diff Type: Plain Text (text/plain) > Encoding: 7bit > > ------------------------------------------------------------------------ > > -- > Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Tue Nov 9 02:10:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA26552 for xemacs-beta-out; Tue, 9 Nov 1999 02:10:24 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA26538; Tue, 9 Nov 1999 02:10:20 -0500 Received: by crystal.WonderWorks.COM id QQhooa17473; Mon, 8 Nov 1999 23:09:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.51390.690653.232933@crystal.WonderWorks.COM> Date: Mon, 8 Nov 1999 23:09:50 -0800 (PST) From: Kyle Jones To: Yoshiki Hayashi Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 In-Reply-To: <87g0ygyy13.fsf@dp50.ecc.u-tokyo.ac.jp> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <38279F70.47668B26@666.com> <87g0ygyy13.fsf@dp50.ecc.u-tokyo.ac.jp> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: So far on xemacs-beta the current plan is to make Finsert (and presumably any other buffer insertion function that accepts chars) signal wrong-type-argument when presented with an integer. As for the ?\ooo read syntax, \ooo should be allowed for \000-\377. It should fail with some kind of read syntax error for anything over 0377. This keep compatbility with 8-bit XEmacs, and doens't break the abstraction layer for whatever the wide char turns out to be. From owner-xemacs-beta@xemacs.org Tue Nov 9 03:12:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28120 for xemacs-beta-out; Tue, 9 Nov 1999 03:12:27 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28117 for ; Tue, 9 Nov 1999 03:12:23 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11l6Nw-0001Qu-00; Tue, 09 Nov 1999 09:12:12 +0100 To: wmperry@aventail.com Cc: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: Re: URL loading library? References: <86vh7cexdr.fsf@megalith.bp.aventail.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 Nov 1999 09:12:11 +0100 In-Reply-To: wmperry@aventail.com's message of "08 Nov 1999 11:55:28 -0500" Message-ID: <9t9g0ygytgk.fsf@mraz.iskon.hr> Lines: 18 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > I was contemplating finally rewriting the HTTP code in Emacs/W3 in > C. Does anybody have ideas for what HTTP library to use? I'd > prefer not having to write it myself. The `libghttp' stuff from > gnome looks like it could be useful. It can do asynch fetches, etc. A friend of mine has looked into libghttp and told me it's entirely broken. I haven't checked, but I've a hunch that he might be right. Wget is hardly useful for your purposes -- as I no longer have time for it (see http://fly.srk.fer.hr/archive/wget?id=87wvs347gk.fsf@pc-hrvoje.srce.hr), it grows dusty, and it was never able to do async downloads in the first place. I was told that libwww is in much better shape than it was four years ago (people in the Lynx project also had bad experiences with old versions), and it's compatible with the GPL. From owner-xemacs-beta@xemacs.org Tue Nov 9 03:17:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28205 for xemacs-beta-out; Tue, 9 Nov 1999 03:17:33 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28202 for ; Tue, 9 Nov 1999 03:17:31 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7BC4E49E for ; Tue, 9 Nov 1999 09:17:29 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA23700; Tue, 9 Nov 1999 09:17:23 +0100 To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: <14374.59157.478354.127829@turnbull.sk.tsukuba.ac.jp> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 09 Nov 1999 09:17:23 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Tue, 9 Nov 1999 00:07:01 +0900 (JST)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA28203 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Stephen" == Stephen J Turnbull writes: >>>>> "ms" == Michael Sperber writes: ms> The locking policies can be controlled through three ms> mechanisms (by descending precedence): ms> - Specification on the movemail command line. ms> - Specification of an environment variable EMACSLOCKMETHOD ms> with the same possible values as the --mail-locking argument ms> to configure. ms> - Configuration via autoconf and src/config.h. Stephen> Obviously XEmacs shouldn't be allowed to specify locking methods not Stephen> implemented on the system in question. How do you plan to handle that Stephen> given the precedence specified above? Or is this not a problem? Stephen> Maybe XEmacs should bitch on startup (disabled through a site-start Stephen> facility) if the environment variable or the 'mail-lock-variable is Stephen> set to something strange for the system. Right, point taken. Thanks for the note! -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Nov 9 03:18:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28225 for xemacs-beta-out; Tue, 9 Nov 1999 03:18:02 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28219 for ; Tue, 9 Nov 1999 03:17:58 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 282A349E for ; Tue, 9 Nov 1999 09:17:56 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA18250; Tue, 9 Nov 1999 09:17:49 +0100 To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 09 Nov 1999 09:17:49 +0100 In-Reply-To: Jan Vroonhof's message of "08 Nov 1999 17:48:06 +0100" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA28222 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> The locking policies can be controlled through three mechanisms (by >> descending precedence): >> >> - Specification on the movemail command line. >> - Specification of an environment variable EMACSLOCKMETHOD with the >> same possible values as the --mail-locking argument to configure. >> - Configuration via autoconf and src/config.h. Jan> I propose that it should (by default) always use dotlocking (even Jan> together with any other method). I don't believe that's a good idea: Locking would no longer be atomic, and you can get deadlocks that way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Nov 9 03:20:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28316 for xemacs-beta-out; Tue, 9 Nov 1999 03:20:30 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28308 for ; Tue, 9 Nov 1999 03:20:17 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id E287B49E for ; Tue, 9 Nov 1999 09:20:14 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA24830; Tue, 9 Nov 1999 09:20:07 +0100 To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: <14375.20084.353313.115522@crystal.WonderWorks.COM> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 09 Nov 1999 09:20:07 +0100 In-Reply-To: Kyle Jones's message of "Mon, 8 Nov 1999 14:28:04 -0800 (PST)" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA28313 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> Michael Sperber [Mr. Preprocessor] writes: >> - The locking policy is not an OS issue, but rather a site issue. >> The OS issue is what policies *work*, not which ones are in use. Kyle> The locking stuff in a s/*.h file reflects the locking policy Kyle> in use by the default delivery agent on that operating system. Exactly. But the delivery agent may not even run on the same system as movemail. Or it may have been replaced by something else. Kyle> OK with me, so long as it is heavily stressed that the OS-based Kyle> locking default should not be changed unless you know what you Kyle> are doing, it voids your warranty, cows will bark, etc. Right. Moreover, I think we should yell in the documentation that the installer should make an effort to find out. Otherwise it voids your warranty, cows will bark, and ET will serve your lunch. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Nov 9 03:21:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28355 for xemacs-beta-out; Tue, 9 Nov 1999 03:21:26 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28348; Tue, 9 Nov 1999 03:21:19 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id RAA29216; Tue, 9 Nov 1999 17:21:05 +0900 (JST) To: Ben Wing Cc: Kyle Jones , "Stephen J. Turnbull" , XEmacs Beta List , xemacs-review@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> <38279F70.47668B26@666.com> <87g0ygyy13.fsf@dp50.ecc.u-tokyo.ac.jp> <14375.51390.690653.232933@crystal.WonderWorks.COM> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 09 Nov 1999 17:13:56 +0900 In-Reply-To: <3827C7A4.6B7AE63E@666.com> (Ben Wing's message of "Tue, 09 Nov 1999 00:05:08 -0700") Message-ID: <874sewytdn.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 82 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > When I wrote all this code, I made a conscious decision, for compatibility > reasons, to allow integers wherever characters are allowed. If we're going to > change this, (a) we should think carefully about what this means, and (b) we > should fix this all throughout XEmacs. I am confused. Your plan and Kyles' plan below can't coexist. > The bug you're seeing looks to actually be a bug in CHAR_INTP(), which is > supposed to recognize valid character integers. Therefore, you should fix > this macro. It's easy to fix and here is the patch. I'll send this to xemacs-patches if this is needed after discussions are over. Index: mule-charset.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.c,v retrieving revision 1.12.2.20 diff -u -r1.12.2.20 mule-charset.c --- mule-charset.c 1999/10/26 05:48:52 1.12.2.20 +++ mule-charset.c 1999/11/09 08:03:45 @@ -267,7 +267,8 @@ if (f3 < 0x20) return 0; - if (f3 != 0x20 && f3 != 0x7F) + if (f3 != 0x20 && f3 != 0x7F && !(f2 > MIN_CHAR_FIELD2_PRIVATE && + f2 < MAX_CHAR_FIELD2_PRIVATE)) return 1; /* @@ -276,6 +277,8 @@ FIELD2_TO_PRIVATE_LEADING_BYTE are the same. */ charset = CHARSET_BY_LEADING_BYTE (f2 + FIELD2_TO_OFFICIAL_LEADING_BYTE); + if (EQ (charset, Qnil)) + return 0; return (XCHARSET_CHARS (charset) == 96); } else @@ -300,7 +303,8 @@ } #endif /* ENABLE_COMPOSITE_CHARS */ - if (f2 != 0x20 && f2 != 0x7F && f3 != 0x20 && f3 != 0x7F) + if (f2 != 0x20 && f2 != 0x7F && f3 != 0x20 && f3 != 0x7F + && !(f1 > MIN_CHAR_FIELD1_PRIVATE && f1 < MAX_CHAR_FIELD1_PRIVATE)) return 1; if (f1 <= MAX_CHAR_FIELD1_OFFICIAL) @@ -310,6 +314,8 @@ charset = CHARSET_BY_LEADING_BYTE (f1 + FIELD1_TO_PRIVATE_LEADING_BYTE); + if (EQ (charset, Qnil)) + return 0; return (XCHARSET_CHARS (charset) == 96); } } Kyle Jones writes: > So far on xemacs-beta the current plan is to make Finsert (and > presumably any other buffer insertion function that accepts > chars) signal wrong-type-argument when presented with an integer. I'm for this idea but as Ben pointed out, it will be a hard work. Any suggestions? > As for the ?\ooo read syntax, \ooo should be allowed for \000-\377. > It should fail with some kind of read syntax error for anything > over 0377. This keep compatbility with 8-bit XEmacs, and doens't > break the abstraction layer for whatever the wide char turns out > to be. I agree with this. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Tue Nov 9 03:29:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28763 for xemacs-beta-out; Tue, 9 Nov 1999 03:29:51 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28754; Tue, 9 Nov 1999 03:29:49 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11l6e1-0001RX-00; Tue, 09 Nov 1999 09:28:49 +0100 To: Yoshiki Hayashi Cc: Ben Wing , Kyle Jones , "Stephen J. Turnbull" , XEmacs Beta List , xemacs-review@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> <38279F70.47668B26@666.com> <87g0ygyy13.fsf@dp50.ecc.u-tokyo.ac.jp> <14375.51390.690653.232933@crystal.WonderWorks.COM> <874sewytdn.fsf@dp50.ecc.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 Nov 1999 09:28:49 +0100 In-Reply-To: Yoshiki Hayashi's message of "09 Nov 1999 17:13:56 +0900" Message-ID: <9t9zowoxe4e.fsf@mraz.iskon.hr> Lines: 28 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: > Ben Wing writes: > > > When I wrote all this code, I made a conscious decision, for compatibility > > reasons, to allow integers wherever characters are allowed. If we're going to > > change this, (a) we should think carefully about what this means, and (b) we > > should fix this all throughout XEmacs. > > I am confused. Your plan and Kyles' plan below can't coexist. Which means that they disagree on this one. I agree with Ben here, for two reasons: 2. If we are to disallow inserting integers, we should do it with some more care about where integers can popup. Believe me, it's in many many places (as both Ben and Kyle know); 1. The patch as it stands doesn't really fix the source of the problem. If (insert 8000) signals an error, but (insert (int-char 8000)) crashes XEmacs, then something is wrong. > It's easy to fix and here is the patch. I'll send this to > xemacs-patches if this is needed after discussions are over. [...] This patch looks good to me, but I'll wait for Ben's judgement, as he is the one who really understands that code. From owner-xemacs-beta@xemacs.org Tue Nov 9 03:52:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA29519 for xemacs-beta-out; Tue, 9 Nov 1999 03:52:00 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA29515 for ; Tue, 9 Nov 1999 03:51:52 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id RAA29941; Tue, 9 Nov 1999 17:51:45 +0900 (JST) Mail-Copies-To: never To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Ethiopic in 21.1.7++ References: <14369.5571.420089.132460@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 09 Nov 1999 17:44:36 +0900 In-Reply-To: <14369.5571.420089.132460@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 04 Nov 1999 14:12:35 +0900 (JST)") Message-ID: <87yac8xde3.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 48 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > >>>>> "Jan" == Jan Vroonhof writes: > > Jan> Vin Shelton writes: > >> Symbol's function definition is void: > >> setup-ethiopic-environment-internal > >> > >> I'd like to get this working before I release 21.1.8 (tonight, > >> I hope). Can anyone offer a patch? > > This looks like the same thing that was happening with Japanese and > some other languages. The FSF changed the language environemnt API, > and that got ported to a couple of language environments but not > the rest. :-( Like Jan said, it must not be Symbol's function definition is void error since it is defined at ethio-util.el Maybe Vin hasn't installed mule-base? However, it requires exit-function handling to be implemented in setup-language-environment so it is problematic to use code in ethio-util.el (it defines f2, f3 and other keys so after setting up Ethiopic language environment in XEmacs 21.1, the original definition of those keys won't be recovered). > Jan> I tried making the obvious path (namely copying > Jan> 'setup-ethiopic-environment-internal from an old mule base > Jan> into the core), however then I stopped. auto-autoloads.el > Jan> from mule-base contains > > Ethiopic is one of the things that got ported from FSF and ignored, I > think disabling it is the best route until somebody is willing to take > a good look at it. I think so, too. Until someone who knows Ethiopic is going to use and test it, removing Ethiopic support would not hurt. > That is my suggestion for any non-ISO-8859, non-Asian-ideographic > language that breaks, unfortunately. I think a real solution to this, > one that is robust to ++patchlevel, even, will have to wait until we > define real APIs for Mule and convince porters from FSF to stick to > them. Yes, we need APIs. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Tue Nov 9 03:59:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA29663 for xemacs-beta-out; Tue, 9 Nov 1999 03:59:10 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA29659 for ; Tue, 9 Nov 1999 03:59:07 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id JAA25639 for xemacs-beta@xemacs.org; Tue, 9 Nov 1999 09:59:06 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11l74W-00025L-00 for xemacs-beta@xemacs.org; Tue, 09 Nov 1999 09:56:12 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id CF0F218BA; Tue, 9 Nov 1999 09:56:10 +0100 (CET) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: JOBS list for XEmacs References: <14375.50455.447946.792924@lasker.666.com> From: Andreas Jaeger Date: 09 Nov 1999 09:56:10 +0100 In-Reply-To: Ben Wing's message of "Mon, 8 Nov 1999 22:54:15 -0800 (PST)" Message-ID: Lines: 61 User-Agent: Gnus/5.07009801 (Pterodactyl Gnus v0.98.1) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Ben Wing writes: Ben> Ben and I have come up with a tentative list of XEmacs `jobs', or Ben> areas of responsibility. The idea here is that the people listed as Ben> `Primary' are responsible for any problems in this area. However, in Ben> the event that all of the listed Primaries disapppear and become Ben> unresponsive to email, the Secondary agrees to step up and take over, Ben> at least temporarily. Please suggest changes and additions to this Ben> list. It will be wonderful if people would volunteer for unfilled Ben> positions. Thanks a lot for coming up with this list. We should archive this file somewhere for _internal_ together use with email addresses. I'm missing one position: Package Release Maintainer. It seems that this will be part of my job but I'd like to have it as a separat position for documentation and in case anybody else likes to do this. Ben> Position Primary Secondary Ben> ------------------------------------------------------------ Ben> Beta Release Maintainer Martin Buchholz Ben> Stable Release Maintainer Vinnie Shelton Ben> Jobs-List-Maintainer Ben Wing Ben> Japanese Liaison Stephen Turnbull Ben> Core Patch Tender Jan Vroonhof Andy Piper, Martin Buchholz Ben> Package Patch Tender Andreas Jaeger Martin Buchholz Ben> CVS Manager Jareth Hein Ben> Mailing List Manager Jason Mastaler Martin Buchholz Ben> Webmaster John Anderson Ben> Bug Tracker Ben> Miscellaneous Documentation Ben> --------------------------- Ben> Lisp Reference Manual Martin Buchholz Ben> XEmacs User Manual Martin Buchholz Ben> Internals Manual Martin Buchholz Ben> PROBLEMS Martin Buchholz Ben> FAQ Martin Buchholz Ben> NEWS Hrvoje Niksic Martin Buchholz Ben> README README Martin Buchholz Ben> Coding Projects Ben> --------------- Ben> Coding Standards Martin Buchholz Ben> Portable Dumper Olivier Galibert Ben> Windows support Ben> Configure support Martin Buchholz Ben> Mule Ben Wing, Martin Buchhlz, Olivier Galibert Martin, there's a typo in your name - it seems you've written it down to often;-) Ben> GUI support Andy Piper Ben> Redisplay Andy Piper I hope others fill in the empty spaces, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 9 04:15:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA30393 for xemacs-beta-out; Tue, 9 Nov 1999 04:15:00 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA30385; Tue, 9 Nov 1999 04:14:51 -0500 Received: by localhost id m11l7MO-00016JC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 9 Nov 1999 18:14:40 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.58879.781592.978297@turnbull.sk.tsukuba.ac.jp> Date: Tue, 9 Nov 1999 18:14:39 +0900 (JST) To: Ben Wing Cc: Yoshiki Hayashi , XEmacs Beta List , xemacs-review@xemacs.org Subject: Re: (insert 8000) crashes XEmacs 21.2.16 In-Reply-To: <3827C7A4.6B7AE63E@666.com> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Ben" == Ben Wing writes: Ben> When I wrote all this code, I made a conscious decision, for Ben> compatibility reasons, to allow integers wherever characters Ben> are allowed. If we're going to change this, (a) we should Ben> think carefully about what this means, I don't have a problem with allowing people to use `255' as an abbreviation for `?\377', as long as they don't care if we define the default interpretation for bytes in GR to be Latin-2. A move which is long overdue IMHO. ;-) But I can't see a good reason why "characters" with "code points" bigger than 255 should be permitted to be represented by integers as long as `int-char' doesn't take a character set argument. I'm tempted to restrict that to ASCII + C1 controls, even. It doesn't necessarily make sense. Japanese, for example, should properly have its code points defined by ku-ten, a pair of integers in the range 1-94; I don't even know that it really makes sense to talk of an integer representation for Japanese characters outside of Unicode. What did you have in mind as the semantics for say `(int-char 161)'? Or '(int-char 8000)' for that matter? The bug you're seeing looks to actually be a bug in CHAR_INTP(), which is supposed to recognize valid character integers. Therefore, you should fix this macro. ben Yoshiki Hayashi wrote: > "Stephen J. Turnbull" writes: > > > >>>>> "Kyle" == Kyle Jones writes: > > > > Kyle> (insert 8000) seems fundamentally broken to me. [...] > > > > Kyle> I think Finsert ought to be made to signal > > Kyle> wrong-type-argument when handed an integer. > > > > Agree. > > > > In Mule characters must be opaque objects---currently they have > > internal structure, and internal representation is under consideration > > for revision. FSFmacs has the appropriate character-creation > > functions because it uses the same representation; code that doesn't > > use them is broken in both variants. > > OK. Here is the patch. With this patch, Finsert will be OK, > but you can still make XEmacs crash with (int-to-char 8000). > I'll write fix for that later. > When this patch is applied, w3 must be fixed since it uses > (insert INT) to insert Ϩ or something like that. > > 1999-11-09 Yoshiki Hayashi > > * editfns.c (buffer_insert_1): Don't treat an integer as > a character. > > ------------------------------------------------------------------------ > Name: editfns.c.diff > editfns.c.diff Type: Plain Text (text/plain) > Encoding: 7bit > > ------------------------------------------------------------------------ > > -- > Yoshiki Hayashi -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 9 04:38:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA31332 for xemacs-beta-out; Tue, 9 Nov 1999 04:38:20 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA31327 for ; Tue, 9 Nov 1999 04:38:16 -0500 Received: by localhost id m11l7jC-00016JC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 9 Nov 1999 18:38:14 +0900 (JST) From: "Stephen J. Turnbull" Message-ID: <14375.60294.35543.864163@turnbull.sk.tsukuba.ac.jp> Date: Tue, 9 Nov 1999 18:38:14 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 Summary: READ ME FIRST! this messages parent was prematurely sent In-Reply-To: <3827C7A4.6B7AE63E@666.com> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Sorry for the duplicate; I accidentally sent the first copy before I deleted the unquoted stuff left from Ben's message, making it hard to figure out where my message ended. >>>>> "Ben" == Ben Wing writes: Ben> When I wrote all this code, I made a conscious decision, for Ben> compatibility reasons, to allow integers wherever characters Ben> are allowed. If we're going to change this, (a) we should Ben> think carefully about what this means, I don't have a problem with allowing people to use `255' as an abbreviation for `?\377', as long as they don't care if we define the default interpretation for bytes in GR to be Latin-2. A move which is long overdue IMHO. ;-) But I can't see a good reason why "characters" with "code points" bigger than 255 should be permitted to be represented by integers as long as `int-char' doesn't take a character set argument. I'm tempted to restrict that to ASCII + C1 controls, even. It doesn't necessarily make sense. Japanese, for example, should properly have its code points defined by ku-ten, a pair of integers in the range 1-94; I don't even know that it really makes sense to talk of an integer representation for Japanese characters outside of Unicode. What did you have in mind as the semantics for say `(int-char 161)'? Or '(int-char 8000)' for that matter? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 9 06:19:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA00645 for xemacs-beta-out; Tue, 9 Nov 1999 06:19:51 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA00641 for ; Tue, 9 Nov 1999 06:19:47 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11l9JR-0002Fe-00 for ; Tue, 09 Nov 1999 12:19:45 +0100 To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> <14375.60294.35543.864163@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 Nov 1999 12:19:45 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Tue, 9 Nov 1999 18:38:14 +0900 (JST)" Message-ID: <9t97ljrykry.fsf@mraz.iskon.hr> Lines: 20 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > I don't have a problem with allowing people to use `255' as an > abbreviation for `?\377', as long as they don't care if we define > the default interpretation for bytes in GR to be Latin-2. That would be a bad idea, I think. There could be code that assumes that stuff in [0, 256) range is Latin 1, or that internal representation is independent of the selected environment. (However, `C-q ddd' *should* default to Latin 2 characters in the Latin 2 environment.) > But I can't see a good reason why "characters" with "code points" > bigger than 255 should be permitted to be represented by integers as > long as `int-char' doesn't take a character set argument. Because it can be useful at times. I wouldn't disregard that possibility completely. Also note that `make-char' does take a charset argument. From owner-xemacs-beta@xemacs.org Tue Nov 9 06:52:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA01148 for xemacs-beta-out; Tue, 9 Nov 1999 06:52:24 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA01145 for ; Tue, 9 Nov 1999 06:52:22 -0500 Received: (qmail 9874 invoked from network); 9 Nov 1999 11:51:06 -0000 Received: from usrpri2-13.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.78) by biff.kiva.net with SMTP; 9 Nov 1999 11:51:06 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA21663; Tue, 9 Nov 1999 06:54:01 -0500 To: Hrvoje Niksic Cc: w3-beta@indiana.edu, xemacs-beta@xemacs.org Subject: Re: URL loading library? X-Now-Listening-To: Van Morisson - Goin Down Geneva References: <86vh7cexdr.fsf@megalith.bp.aventail.com> <9t9g0ygytgk.fsf@mraz.iskon.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 33 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > wmperry@aventail.com (William M. Perry) writes: > > > I was contemplating finally rewriting the HTTP code in Emacs/W3 in > > C. Does anybody have ideas for what HTTP library to use? I'd > > prefer not having to write it myself. The `libghttp' stuff from > > gnome looks like it could be useful. It can do asynch fetches, etc. > > A friend of mine has looked into libghttp and told me it's entirely > broken. I haven't checked, but I've a hunch that he might be right. It seems to be woefully inadequate for what we need. :( > Wget is hardly useful for your purposes -- as I no longer have time for > it (see > http://fly.srk.fer.hr/archive/wget?id=87wvs347gk.fsf@pc-hrvoje.srce.hr), > it grows dusty, and it was never able to do async downloads in the first > place. That's what I was afraid of. :( Oh well. :) > I was told that libwww is in much better shape than it was four years ago > (people in the Lynx project also had bad experiences with old versions), > and it's compatible with the GPL. The old versions were pretty nasty... I added SSL and HTTPS support to the (then CERN) web server at spry. God what a memory. :) I downloaded it last night, but can't get it to even configure because of automake weirdness. *sigh* -Bill P. From owner-xemacs-beta@xemacs.org Tue Nov 9 07:53:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA02595 for xemacs-beta-out; Tue, 9 Nov 1999 07:53:03 -0500 Received: from nirvana.ingames.com (nirvana.ingames.no [195.159.15.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA02590 for ; Tue, 9 Nov 1999 07:53:00 -0500 Received: from glynn.ingames.com ([195.159.15.204]) by nirvana.ingames.com (8.8.7/8.8.7) with SMTP id NAA11088 for ; Tue, 9 Nov 1999 13:58:05 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14375.44456.639000.720720@glynn.ingames.com> Date: Tue, 9 Nov 1999 06:14:13 +0100 (GMT--1:00) To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead In-Reply-To: References: X-Mailer: VM 6.67 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote: > Jan> I propose that it should (by default) always use dotlocking (even > Jan> together with any other method). > > I don't believe that's a good idea: Locking would no longer be atomic, > and you can get deadlocks that way. I don't think that it's that big a problem. If the second lock fails, you release the first lock and wait for a bit. Then the worst that can happen is a livelock. FWIW, procmail (on Linux at least) uses both dot-locking and kernel locks (can't remember whether it's flock, fcntl or lockf). -- Glynn Clements From owner-xemacs-beta@xemacs.org Tue Nov 9 07:58:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA02752 for xemacs-beta-out; Tue, 9 Nov 1999 07:58:57 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA02748 for ; Tue, 9 Nov 1999 07:58:55 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id E611849E for ; Tue, 9 Nov 1999 13:58:45 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id NAA25478; Tue, 9 Nov 1999 13:58:45 +0100 To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: <14375.44456.639000.720720@glynn.ingames.com> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 09 Nov 1999 13:58:44 +0100 In-Reply-To: Glynn Clements's message of "Tue, 9 Nov 1999 06:14:13 +0100 (GMT--1:00)" Message-ID: Lines: 30 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id HAA02749 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Glynn" == Glynn Clements writes: Glynn> Michael Sperber [Mr. Preprocessor] wrote: Jan> I propose that it should (by default) always use dotlocking (even Jan> together with any other method). >> >> I don't believe that's a good idea: Locking would no longer be atomic, >> and you can get deadlocks that way. Glynn> I don't think that it's that big a problem. If the second lock fails, Glynn> you release the first lock and wait for a bit. Then the worst that can Glynn> happen is a livelock. I'd rather avoid the complexity. Sysadmins *need* to coordinate locking methods between MDA and MUA, and that's easiest when theres a 1-1 match. Glynn> FWIW, procmail (on Linux at least) uses both dot-locking and kernel Glynn> locks (can't remember whether it's flock, fcntl or lockf). That depends on how it's configured. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Nov 9 12:12:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10465 for xemacs-beta-out; Tue, 9 Nov 1999 12:12:11 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA10461 for ; Tue, 9 Nov 1999 12:12:06 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA11944; Tue, 9 Nov 1999 18:12:05 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002ua; Tue Nov 9 18:12:00 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA23143; Tue, 9 Nov 1999 18:12:00 +0100 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: From: Jan Vroonhof Date: 09 Nov 1999 18:11:59 +0100 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "09 Nov 1999 09:17:49 +0100" Message-ID: Lines: 16 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Jan> I propose that it should (by default) always use dotlocking (even > Jan> together with any other method). > > I don't believe that's a good idea: Locking would no longer be atomic, > and you can get deadlocks that way. Not if everybody acquires the locks in the same order. Which is indeed the case. Note that for instance mutt uses the combination .lock+fcntl() by default. Jan From owner-xemacs-beta@xemacs.org Tue Nov 9 12:23:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10749 for xemacs-beta-out; Tue, 9 Nov 1999 12:23:56 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA10743; Tue, 9 Nov 1999 12:23:48 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA12108; Tue, 9 Nov 1999 18:23:46 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002x9; Tue Nov 9 18:23:36 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA23145; Tue, 9 Nov 1999 18:23:36 +0100 To: Ben Wing Cc: XEmacs Beta Test Subject: Re: JOBS list for XEmacs References: <14375.50455.447946.792924@lasker.666.com> From: Jan Vroonhof Date: 09 Nov 1999 18:23:35 +0100 In-Reply-To: Ben Wing's message of "Mon, 8 Nov 1999 22:54:15 -0800 (PST)" Message-ID: Lines: 22 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing , Martin Buchholz writes: > Core Patch Tender Jan Vroonhof Andy Piper, Martin Buchholz What have I just volunteered for? i.e. what is job description for this. > Bug Tracker This currently de facto "Gunnar Evermann" > README README Martin Buchholz Is the README maintaining itself? > Configure support Martin Buchholz > Mule Ben Wing, Martin Buchhlz, Olivier Galibert > GUI support Andy Piper > Redisplay Andy Piper Customize Jan Vroonhof Jan From owner-xemacs-beta@xemacs.org Tue Nov 9 14:27:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA15004 for xemacs-beta-out; Tue, 9 Nov 1999 14:27:27 -0500 Received: from kens.com (kens.com [129.250.30.40]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA15001 for ; Tue, 9 Nov 1999 14:27:24 -0500 Received: from socha.net (IDENT:root@next3.rhrz.uni-bonn.de [131.220.224.32]) by kens.com (8.9.3/8.9.3-mod-for-majordomo) with ESMTP id OAA14503 for ; Tue, 9 Nov 1999 14:27:19 -0500 (EST) Received: (from robin@localhost) by socha.net (8.9.3/8.9.3) id UAA27467; Tue, 9 Nov 1999 20:07:48 +0100 To: XEmacs Beta List Subject: [pdumper] "Cannot open doc string file..." Organization: Usenet Death Squad X-URL: X-Face: #Z}0zkbqU,m`+S)^0R[.23L-o>U{UQ|(DvIqu^Bjw:po_g9;4JnT9tbn;QX$ga/LYS From: "Robin S. Socha" Date: 09 Nov 1999 20:07:47 +0100 Message-ID: Lines: 22 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Sneaky Bastard 19991102) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I tried compiling sneaky bastard with --pdump=yes. The make process failed (as promised) but when running temacs -f gnus, I get the following backtrace: Signaling: (error "Cannot open doc string file \"../lib-src/../lisp/gnus-art.elc\"") ad-Orig-documentation(article-hide-headers t) documentation(article-hide-headers t) #(article-hide-headers) mapcar(# (article-hide-headers article-hide-boring-headers article-treat-overstrike article-fill-long-lines article-capitalize-sentences article-remove-cr article-display-x-face article-de-quoted-unreadable article-mime-decode-quoted-printable article-hide-list-identifiers article-hide-pgp article-strip-banner article-babel article-hide-pem article-hide-signature article-strip-headers-in-body article-remove-trailing-blank-lines article-strip-leading-blank-lines article-strip-multiple-blank-lines article-strip-leading-space article-strip-trailing-space article-strip-blank-lines article-strip-all-blank-lines article-date-local article-date-iso8601 article-date-original article-date-ut article-decode-mime-words ! article-decode-charset article-decode-encoded-words article-date-user article-date-lapsed article-emphasize article-treat-dumbquotes article-normalize-headers (article-show-all . gnus-article-show-all-headers))) byte-code("..." [mapcar # (article-hide-headers article-hide-boring-headers article-treat-overstrike article-fill-long-lines article-capitalize-sentences article-remove-cr article-display-x-face article-de-quoted-unreadable article-mime-decode-quoted-printable article-hide-list-identifiers article-hide-pgp article-strip-banner article-babel article-hide-pem article-hide-signature article-strip-headers-in-body article-remove-trailing-blank-lines article-strip-leading-blank-lines article-strip-multiple-blank-lines article-strip-leading-space article-strip-trailing-space article-strip-blank-lines article-strip-all-blank-lines article-date-local article-date-iso8601 article-date-original article-date-ut article-decode-mime-words article-decode-charset article-decode-encoded-words article-! date-user article-date-lapsed article-emphasize article-treat-dumbquotes article-normalize-headers (article-show-all . gnus-article-show-all-headers)) put gnus-article-mode mode-class special set-keymap-parent gnus-article-mode-map widget-keymap gnus-define-keys-1 (" " gnus-article-goto-next-page "" gnus-article-goto-prev-page [delete] gnus-article-goto-prev-page [backspace] gnus-article-goto-prev-page "^" gnus-article-refer-article "h" gnus-article-show-summary "s" gnus-article-show-summary " " gnus-article-mail "?" gnus-article-describe-briefly "e" gnus-article-edit "<" beginning-of-buffer ">" end-of-buffer " " gnus-info-find-node "" gnus-bug "" gnus-article-read-summary-keys "ª" gnus-article-read-summary-keys "£" gnus-article-read-summary-keys "Þ" gnus-article-read-summary-keys "ç" gnus-article-read-summary-keys) substitute-key-definition undefined gnus-article-read-summary-keys] 4) load-internal("gnus-art" nil nil nil nil nil) load("gnus-art" nil nil nil) gnus-article-prepare(3782 nil) gnus-summary-display-article(3782 nil) gnus-summary-select-article(nil nil pseudo) gnus-summary-scroll-up(1) call-interactively(gnus-summary-scroll-up) I will be away from my mail for a few days, so if that isn't enough, I'm really sorry ;-) -- Robin S. Socha From owner-xemacs-beta@xemacs.org Tue Nov 9 14:53:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA15856 for xemacs-beta-out; Tue, 9 Nov 1999 14:53:22 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA15853 for ; Tue, 9 Nov 1999 14:53:19 -0500 Received: (qmail 18835 invoked from network); 9 Nov 1999 19:52:00 -0000 Received: from usrpri2-25.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.90) by biff.kiva.net with SMTP; 9 Nov 1999 19:52:00 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA05892; Tue, 9 Nov 1999 14:57:38 -0500 To: xemacs-beta@xemacs.org Subject: FSF named in federal antitrust action X-Now-Listening-To: Sean Keane - Galway To Graceland Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 48 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Wasn't sure if everybody had seen this yet. That's what I get for writing a web browser I guess. :) -Bill P. Washington, D.C. -- The U.S. Department of Justice today announced a major new antitrust action against the Free Software Foundation of Cambridge, MA. "After our successful prosecution of Microsoft, we feel ready to pursue similar cases elsewhere in the software industry," said Attorney General Janet Reno in a press conference. "The FSF, under the guidance of Mr. Richard M. Stallman, has pursued, and continues to pursue, anti-competitive practices designed to perpetuate its illegal monopoly of the so-called 'free software' market." In particular, the Attorney General cited the FSF's ongoing effort to gain market share in various product categories by illegally bundling other products into their successful Emacs text editor. "Thanks to Judge Jackson, we now have legal precedent that a web browser cannot be considered part of an operating system," she said. "We feel that this finding is also applicable to text editors. Emacs, in fact, does include a web browser as well as e-mail and other capabilities that are not normally considered to be part and parcel of a text editor." Responding to a reporter's question, Ms. Reno confirmed that "Emacs is the primary focus of our action." Ms. Reno also addressed the FSF's ambitions in the operating system niche. "FSF had been attempting for some time to dominate the market for free operating systems with their 'GNU' platform. However, while they produced a number of user-level tools, their kernel was even more mythical than a reliable version of Windows 98 until their successful takeover of the Linux franchise, now known, significantly, as 'GNU/Linux'." Federal prosecutors Joel Klein and David Boies, both veterans of the successful Microsoft suit, are heading up the FSF enquiry. "I realize that some users feel that they use FSF products by choice," said Klein. "But how many Linux systems have you seen that don't have the core GNU utilities installed? Our estimate is that these programs are present on 100% of Linux machines. When such a high percentage of market share is held by one player, it's clear that an illegal monopoly exists." Initial analysis/speculation by various media talking heads failed to find consensus regarding the possible outcome of the government suit. At minimum, the government will most likely seek to have the FSF break out the various functional components of Emacs into separate products and discontinue the use of the anti-competitive GNU Public License, which has been described as a "free-software virus" which forces third-party software developers to release their products under terms dictated by the FSF. Other possibilities include punitive damages and even the breakup of the FSF into separate operating system and application groups. From owner-xemacs-beta@xemacs.org Tue Nov 9 15:12:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA16562 for xemacs-beta-out; Tue, 9 Nov 1999 15:12:59 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA16557 for ; Tue, 9 Nov 1999 15:12:57 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA15783; Tue, 9 Nov 1999 21:12:55 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003q.; Tue Nov 9 21:12:55 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA23820; Tue, 9 Nov 1999 21:12:54 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: FSF named in federal antitrust action References: <863dufsaj2.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 09 Nov 1999 21:12:52 +0100 In-Reply-To: wmperry@aventail.com's message of "09 Nov 1999 14:57:37 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Wasn't sure if everybody had seen this yet. That's what I get for writing > a web browser I guess. :) You actually had me scared for second :-). This is definitely one for r.h.funny Jan From owner-xemacs-beta@xemacs.org Tue Nov 9 17:29:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA21853 for xemacs-beta-out; Tue, 9 Nov 1999 17:29:37 -0500 Received: from justresearch.com (ULYSSES.JPRC.COM [207.86.147.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA21847 for ; Tue, 9 Nov 1999 17:29:34 -0500 Received: (from mthomas@localhost) by justresearch.com (8.8.7/8.8.7) id RAA19160; Tue, 9 Nov 1999 17:29:34 -0500 Date: Tue, 9 Nov 1999 17:29:34 -0500 Message-Id: <199911092229.RAA19160@justresearch.com> From: Mark Thomas To: xemacs-beta@xemacs.org Subject: 21.2-b19-sneaky: linux: make-frame-on-display seg fault Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In XEmacs 21.2 (beta19) "Sneaky Bastard 19991102" [Lucid] (i686-pc-linux, Mule) of Tue Nov 9 1999 on ulysses.jprc.com configured using `configure --prefix=/home/xemacs/debug --with-mule --site-libraries=/home/xemacs/lib --site-includes=/home/xemacs/include --site-runtime-libraries=/home/xemacs/lib '--cflags=-g -Wall -Wno-switch' --with-dialogs=athena --with-widgets=athena' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: xemacs -vanilla in the *scratch* buffer evaluate: (make-frame-on-display (concat (system-name) ":0")) I discovered the crash when trying to use gnuclient between machines, but I can make XEmacs crash by giving make-frame-on-display a hostname. If I use ":0.0", "localhost:0.0", or "unix:0.0", make-frame-on-display works fine, but if I give it the name of my host, XEmacs crashes. This is a RedHat Linux 5.2 box running a 2.2.12 kernel; XFree86 info from rpm: Name : XFree86 Distribution: Manhattan Version : 3.3.2.3 Vendor: Red Hat Software Release : 25 Build Date: Sat Oct 10 04:01:26 1998 Install date: Mon Feb 8 15:46:28 1999 Build Host: porky.redhat.com Group : X11/XFree86 Source RPM: XFree86-3.3.2.3-25.src.rpm The describe-installation, lisp backtrace, and the contents of my *gdb* buffer follow. uname -a: Linux ulysses.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown ../xemacs-cvs-snapshot-19991102/configure '--prefix=/home/xemacs/debug' '--with-mule' '--site-libraries=/home/xemacs/lib' '--site-includes=/home/xemacs/include' '--site-runtime-libraries=/home/xemacs/lib' '--cflags=-g -Wall -Wno-switch' '--with-dialogs=athena' '--with-widgets=athena' XEmacs 21.2-b19 "Sneaky Bastard 19991102" configured for `i686-pc-linux'. Where should the build process find the source code? /home/xemacs/build/xemacs-cvs-snapshot-19991102 What installation prefix should install use? /home/xemacs/debug What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /home/xemacs/include Additional libraries: /home/xemacs/lib Runtime library search path: /home/xemacs/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena native widgets. Using Athena dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Lisp backtrace follows: # bind (frame-being-created) make-frame(nil #) # bind (props connection type) make-frame-on-device(x "ulysses.jprc.com:0" nil) # bind (props display) make-frame-on-display("ulysses.jprc.com:0") eval((make-frame-on-display (concat (system-name) ":0"))) # bind (expr) eval-interactive((make-frame-on-display (concat (system-name) ":0"))) # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) eval-last-sexp(t) # bind (standard-output) #() call-interactively(eval-print-last-sexp) # (condition-case ... . error) # (catch top-level ...) [1] + 19143 segmentation fault xemacs-21.2-b19 -vanilla *gdb* buffer contents (changed non-ASCII characters to hexadecimal): Current directory is /home/xemacs/debug/bin/ GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support (gdb) attach 19143 Attaching to program `/home/xemacs/debug/bin/xemacs-21.2-b19', Pid 19143 Reading symbols from /usr/arla/lib/libgetcwd.so.0.27...done. Reading symbols from /usr/X11R6/lib/libXaw.so.6...done. Reading symbols from /usr/lib/libtiff.so.3...done. Reading symbols from /home/xemacs/lib/libpng.so.2...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libdb.so.2...done. Reading symbols from /usr/lib/libgdbm.so.2...done. Reading symbols from /usr/lib/libgpm.so.1...done. Reading symbols from /usr/lib/libncurses.so.4...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.1...done. 0x2ad732de in __select () (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x2ac21502 in XGetIMValues () (gdb) where #0 0x2ac21502 in XGetIMValues () #1 0x80cf621 in IMInstantiateCallback (dpy=0x86a2bd8, client_data=0x86aba70 "\034\200=d9*P=baj\b=ba'", call_data=0x0) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:249 #2 0x2ac46846 in _XimRegisterIMInstantiateCallback () #3 0x2ac219aa in XRegisterIMInstantiateCallback () #4 0x80cf915 in XIM_init_frame (f=0x86aba70) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:333 #5 0x81cf9ab in x_popup_frame (f=0x86aba70) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame-x.c:2085 #6 0x81cfc3a in x_init_frame_3 (f=0x86aba70) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame-x.c:2204 #7 0x8118a3d in Fmake_frame (props=137151492, device=141086784) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame.c:472 #8 0x8098577 in Ffuncall (nargs=3, args=0x7fffe954) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3178 #9 0x8063608 in execute_optimized_program ( program=0x86a0140 "=c0\t=c2\013\f\t#\"\207", stack_depth=6, constants_data=0x83e2358) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743 #10 0x80630b1 in funcall_compiled_function (fun=138258500, nargs=3, args=0x7fffeaf8) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516 #11 0x8098811 in Ffuncall (nargs=4, args=0x7fffeaf4) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210 #12 0x8063608 in execute_optimized_program ( program=0x86a0118 "\b=c1k=ab\003=c2\020=c3=c4\b\r#\207\204=d9*", stack_depth=4, constants_data=0x853cf00) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743 #13 0x80630b1 in funcall_compiled_function (fun=139671456, nargs=1, args=0x7fffec00) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516 #14 0x8097fda in Feval (form=139568696) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3034 #15 0x809854e in Ffuncall (nargs=2, args=0x7fffee24) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3178 #16 0x8063608 in execute_optimized_program ( program=0x8687448 "\b=a2=c1a=ab!\bG=c2V=ab\e=c3=c4\bAB!\210\r=ab\r=c6=c7!\210=c8=c9!\210=c6=ca!\210\bA@\207\b=a2=cba=ab0\bG=c2V=ab*=cc\bA@!=ab#=cd\bA@=c3=c2\b8!\"\210=c3\b!\210\r=ab\r=c6=ce!\210=c8=c9!\210=c6=ca!\210\bA@\207=c3\b!\207", stack_depth=5, constants_data=0x83fc518) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743 #17 0x80630b1 in funcall_compiled_function (fun=138392680, nargs=1, args=0x7fffefcc) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516 #18 0x8098811 in Ffuncall (nargs=2, args=0x7fffefc8) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210 #19 0x8063608 in execute_optimized_program ( program=0x86872e0 "\b=ab\004p=aa\002=c1`=c2\e\034\035=c6=c7=c8 \036\t=ca\216=cb\016\f!\210\212=c2f=cda=ae\005=ce =cda\023=cf=d0!\210\013=ab\n=c2f=d1a=ab\004=c2u\210\214e\f}\210=d2p!\211\036\023=a2=d4a=ab\r=d5=d6=d7\016\023=d8BBBD=aa\003\016\023-!!+\207a", stack_depth=8, constants_data=0x83fc568) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743 #20 0x80630b1 in funcall_compiled_function (fun=138392708, nargs=1, args=0x7ffff178) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516 #21 0x8098811 in Ffuncall (nargs=2, args=0x7ffff174) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210 #22 0x8063608 in execute_optimized_program ( program=0x867dd58 "p\030=c1 \210=c2=c3!\210=c1 )\207", stack_depth=2, constants_data=0x84aa9e0) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743 #23 0x80630b1 in funcall_compiled_function (fun=138392652, nargs=0, args=0x7ffff344) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516 #24 0x8098811 in Ffuncall (nargs=1, args=0x7ffff340) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210 #25 0x8099ab7 in apply1 (fn=138392652, arg=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3793 #26 0x8069113 in Fcall_interactively (function=138395404, record_flag=137151492, keys=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/callint.c:394 #27 0x8096b64 in Fcommand_execute (cmd=138395404, record=137151492, keys=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:2613 #28 0x80eb712 in execute_command_event (command_builder=0x85df450, event=141149120) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/event-stream.c:4343 #29 0x80ebe4f in Fdispatch_event (event=141149120) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/event-stream.c:4634 #30 0x8072aed in Fcommand_loop_1 () at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:575 #31 0x807286f in command_loop_1 (dummy=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:490 #32 0x8094972 in condition_case_1 (handlers=137151588, bfun=0x8072848 , barg=137151492, hfun=0x8072064 , harg=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:1630 #33 0x807218b in command_loop_3 () at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:252 #34 0x80721b3 in command_loop_2 (dummy=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:263 #35 0x8094502 in internal_catch (tag=137225708, func=0x80721a8 , arg=137151492, threw=0x0) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:1305 #36 0x80723f8 in initial_command_loop (load_me=137151492) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:301 #37 0x808fa9c in xemacs_21_2_b19_i686_pc_linux (argc=2, argv=0x7ffff9b4, envp=0x7ffff9c0, restart=0) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/emacs.c:1873 #38 0x80906a4 in main (argc=2, argv=0x7ffff9b4, envp=0x7ffff9c0) at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/emacs.c:2298 (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /home/xemacs/debug/bin/xemacs-21.2-b19 Pid 19143 From owner-xemacs-beta@xemacs.org Tue Nov 9 20:21:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA28539 for xemacs-beta-out; Tue, 9 Nov 1999 20:21:52 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA28536 for ; Tue, 9 Nov 1999 20:21:50 -0500 Received: (qmail 8121 invoked from network); 10 Nov 1999 01:20:28 -0000 Received: from usrpri2-43.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.108) by biff.kiva.net with SMTP; 10 Nov 1999 01:20:28 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA11314; Tue, 9 Nov 1999 20:20:26 -0500 To: xemacs-beta@xemacs.org Subject: Wow, I must have been bored... GPM stuff X-Now-Listening-To: Jimmy Buffett - Love And Luck Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 55 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Comment I just added to gpmevent.c after trying to get the mouse cursor drawing correctly. This only happens if you attach to a running XEmacs. /* Ok, now this is just freaky. Bear with me though. ** ** If you run gnuclient and attach to a XEmacs running in ** X or on another TTY, the mouse cursor does not get ** drawn correctly. This is because the ioctl() fails ** with EPERM because the TTY specified is not our ** controlling terminal. If you are the superuser, it ** will work just spiffy. The appropriate source file (at ** least in linux 2.2.x) is ** .../linux/drivers/char/console.c in the function ** tioclinux(). The following bit of code is brutal to ** us: ** ** if (current->tty != tty && !suser()) ** return -EPERM; ** ** I even tried setting us as a process leader, removing ** our controlling terminal, and then using the TIOCSCTTY ** to set up a new controlling terminal, all with no luck. ** ** What is even weirder is if you run XEmacs in a VC, and ** attach to it from another VC with gnuclient, go back to ** the original VC and hit a key, the mouse pointer ** displays (in BOTH VCs), until you hit a key in the ** second VC, after which it does not display in EITHER ** VC. Bizarre, no? ** ** All I can say is thank god Linux comes with source code ** or I would have been completely confused. Well, ok, ** I'm still completely confused. I don't see why they ** don't just check the permissions on the device ** (actually, if you have enough access to it to get the ** console's file descriptor, you should be able to do ** with it as you wish, but maybe that is just me). ** ** William M. Perry - Nov 9, 1999 */ If anybody cares to wade through linux/drivers/char/ and show me a way to get this working, the appropriate files are tty_io.c and console.c. The reason they do the check (I think) is that so somebody can't just call an ioctl() to set the selection on a VC that they do not own, and then call the ioctl() to do a paste, in effect getting a screendump of that other VC. It is still annoying though. *sigh* Any Linux kernel jockeys out there that can get this working? Without a kernel patch? :) -Bill P. From owner-xemacs-beta@xemacs.org Tue Nov 9 20:23:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA28643 for xemacs-beta-out; Tue, 9 Nov 1999 20:23:50 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA28640 for ; Tue, 9 Nov 1999 20:23:49 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id UAA14022 for ; Tue, 9 Nov 1999 20:30:53 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-6.ecf.teradyne.com [131.101.192.126]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id CAA00894; Wed, 10 Nov 1999 02:23:43 +0100 (MET) To: xemacs-beta@xemacs.org Subject: Re: [PATCH] *.el is newer, etc. [was: [Success] XEmacs 21.1.8 "Bryce Canyon", i386-pc-win32] References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 10 Nov 1999 02:22:32 +0100 In-Reply-To: Adrian Aichner's message of "06 Nov 1999 23:52:34 +0100" Message-ID: Lines: 13 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> 1) It fixes incorrect messages stating APA> file *.el is newer APA> for packages installed during DST when DST ends. This patch is incorrect. Please don't apply it. A real solution is immanent. Regards, Adrian From owner-xemacs-beta@xemacs.org Tue Nov 9 21:44:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA00893 for xemacs-beta-out; Tue, 9 Nov 1999 21:44:53 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA00605; Tue, 9 Nov 1999 21:41:29 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id VAA19217; Tue, 9 Nov 1999 21:48:31 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-6.ecf.teradyne.com [131.101.192.126]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id DAA01313; Wed, 10 Nov 1999 03:41:18 +0100 (MET) To: XEmacs Beta List , XEmacs NT List Subject: Fixing call-process and fstat in 21.2-b19 on Windows NT X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 10 Nov 1999 03:40:06 +0100 Message-ID: Lines: 400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Could the experts in these areas please comment on this patch of mine? I will add a ChangeLog after I resolve any remaining issues. Please see http://www.xemacs.org/list-archives/xemacs-beta/9911/msg00193.html for my assessment of the fstat/stat problems on Windows NT. I'd like to hear from you if I've drawn any wrong conclusions. Changes to src/callproc.c src/ntproc.c src/sysdep.c and src/sysdep.h implement the call-process patch which is in 21.1.8 already. However, following Ben's request, I have replaced stderr_out () with warn_when_safe (). The part I am concerned about is my ENCAPSULATION for fstat, which is required on Windows NT to avoid inconsistencies between the already encapsulated stat system call and the broken fstat on NT. Do I need to qualify it somehow, so that it only affects native Windows NT builds? I didn't understand how stat is only encapsualted on NT native. The files changed are: src/nt.c src/sysdep.c src/sysfile.h Please advise about any shortcomings of this patch and directions for possible fixes. Many thanks! Adrian I have verified a patched XEmacs to report consistent file times cd d:\tmp\21.2\xemacs\ cvs diff Compilation started at Wed Nov 10 03:09:36 1999 +0100 (W. Europe Standard Time) Index: src/callproc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/callproc.c,v retrieving revision 1.29.2.6 diff -u -r1.29.2.6 callproc.c --- callproc.c 1999/05/01 05:13:23 1.29.2.6 +++ callproc.c 1999/11/10 02:13:47 @@ -104,6 +104,9 @@ { int fd = XINT (Fcar (fdpid)); int pid = XINT (Fcdr (fdpid)); +#ifdef WINDOWSNT + HANDLE pHandle; +#endif if (!call_process_exited && EMACS_KILLPG (pid, SIGINT) == 0) @@ -114,7 +117,17 @@ /* #### "c-G" -- need non-consing Single-key-description */ message ("Waiting for process to die...(type C-g again to kill it instantly)"); +#ifdef WINDOWSNT + pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid); + if (pHandle == NULL) + { + warn_when_safe (Qprocess, Qerror, + "OpenProcess returns NULL process handle."); + } + wait_for_termination (pHandle); +#else wait_for_termination (pid); +#endif /* "Discard" the unwind protect. */ XCAR (fdpid) = Qnil; @@ -170,6 +183,9 @@ Lisp_Object infile, buffer, current_dir, display, path; int fd[2]; int filefd; +#ifdef WINDOWSNT + HANDLE pHandle; +#endif int pid; char buf[16384]; char *bufptr = buf; @@ -359,6 +375,20 @@ #ifdef WINDOWSNT pid = child_setup (filefd, fd1, fd_error, new_argv, (char *) XSTRING_DATA (current_dir)); + if (!INTP (buffer)) + { + /* OpenProcess() as soon after child_setup as possible. It's too + late once the process terminated. */ + pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid); + if (pHandle == NULL) + { + warn_when_safe (Qprocess, Qerror, + "OpenProcess returns NULL process handle."); + } + } + /* Close STDERR into the parent process. We no longer need it. */ + if (fd_error >= 0) + close (fd_error); #else /* not WINDOWSNT */ pid = fork (); @@ -394,12 +424,14 @@ if (!NILP (fork_error)) signal_error (Qfile_error, fork_error); +#ifndef WINDOWSNT if (pid < 0) { if (fd[0] >= 0) close (fd[0]); report_file_error ("Doing fork", Qnil); } +#endif if (INTP (buffer)) { @@ -507,7 +539,11 @@ QUIT; /* Wait for it to terminate, unless it already has. */ +#ifdef WINDOWSNT + wait_for_termination (pHandle); +#else wait_for_termination (pid); +#endif /* Don't kill any children that the subprocess may have left behind when exiting. */ Index: src/nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/nt.c,v retrieving revision 1.17.2.4 diff -u -r1.17.2.4 nt.c --- nt.c 1999/07/05 05:56:43 1.17.2.4 +++ nt.c 1999/11/10 02:14:24 @@ -1313,6 +1313,40 @@ #endif +/* Since stat is encapsulated on Windows NT, we need to encapsulate + the equally broken fstat as well. */ +int +fstat (int handle, struct stat *buffer) +{ + int ret; + BY_HANDLE_FILE_INFORMATION lpFileInfo; + /* Initialize values */ + buffer->st_mode = 0; + buffer->st_size = 0; + buffer->st_dev = 0; + buffer->st_rdev = 0; + buffer->st_atime = 0; + buffer->st_ctime = 0; + buffer->st_mtime = 0; + buffer->st_nlink = 0; + ret = GetFileInformationByHandle((HANDLE) handle, &lpFileInfo); + if (!ret) + { + return -1; + } + else + { + buffer->st_mtime = convert_time (lpFileInfo.ftLastWriteTime); + buffer->st_atime = convert_time (lpFileInfo.ftLastAccessTime); + if (buffer->st_atime == 0) buffer->st_atime = buffer->st_mtime; + buffer->st_ctime = convert_time (lpFileInfo.ftCreationTime); + if (buffer->st_ctime == 0) buffer->st_ctime = buffer->st_mtime; + buffer->st_size = lpFileInfo.nFileSizeLow; + buffer->st_nlink = (short) lpFileInfo.nNumberOfLinks; + return 0; + } +} + /* MSVC stat function can't cope with UNC names and has other bugs, so replace it with our own. This also allows us to calculate consistent inode values without hacks in the main Emacs code. */ Index: src/ntproc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/ntproc.c,v retrieving revision 1.14.2.10 diff -u -r1.14.2.10 ntproc.c --- ntproc.c 1999/10/10 12:40:13 1.14.2.10 +++ ntproc.c 1999/11/10 02:14:30 @@ -445,16 +445,8 @@ cp->procinfo.hThread=NULL; cp->procinfo.hProcess=NULL; - /* Hack for Windows 95, which assigns large (ie negative) pids */ - if (cp->pid < 0) - cp->pid = -cp->pid; - /* pid must fit in a Lisp_Int */ -#ifdef USE_UNION_TYPE - cp->pid = (cp->pid & ((1U << VALBITS) - 1)); -#else - cp->pid = (cp->pid & VALMASK); -#endif + *pPid = cp->pid; Index: src/sysdep.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.c,v retrieving revision 1.32.2.7 diff -u -r1.32.2.7 sysdep.c --- sysdep.c 1999/07/05 05:56:44 1.32.2.7 +++ sysdep.c 1999/11/10 02:14:44 @@ -234,8 +234,11 @@ #endif /* NO_SUBPROCESSES */ -void -wait_for_termination (int pid) +#ifdef WINDOWSNT +void wait_for_termination (HANDLE pHandle) +#else +void wait_for_termination (int pid) +#endif { /* #### With the new improved SIGCHLD handling stuff, there is much less danger of race conditions and some of the comments below @@ -345,6 +348,53 @@ Since implementations may add their own error indicators on top, we ignore it by default. */ +#elif defined (WINDOWSNT) + int ret = 0, status = 0; + if (pHandle == NULL) + { + warn_when_safe (Qprocess, Qerror, "Cannot wait for NULL process handle."); + return; + } + do + { + QUIT; + ret = WaitForSingleObject(pHandle, 100); + } + while (ret == WAIT_TIMEOUT); + if (ret == WAIT_FAILED) + { + warn_when_safe (Qprocess, Qerror, + "WaitForSingleObject returns WAIT_FAILED for process handle %p.", + pHandle); + } + if (ret == WAIT_ABANDONED) + { + warn_when_safe (Qprocess, Qerror, + "WaitForSingleObject returns WAIT_ABANDONED for process handle %p.", + pHandle); + } + if (ret == WAIT_OBJECT_0) + { + ret = GetExitCodeProcess(pHandle, &status); + if (ret) + { + synch_process_alive = 0; + synch_process_retcode = status; + } + else + { + /* GetExitCodeProcess() didn't return a valid exit status, + nothing to do. APA */ + warn_when_safe (Qprocess, Qerror, + "GetExitCodeProcess fails for process handle %p.", + pHandle); + } + } + if (pHandle != NULL && !CloseHandle(pHandle)) + { + warn_when_safe (Qprocess, Qerror, + "CloseHandle fails for process handle %p.", pHandle); + } #elif defined (EMACS_BLOCK_SIGNAL) && !defined (BROKEN_WAIT_FOR_SIGNAL) && defined (SIGCHLD) while (1) { @@ -376,7 +426,7 @@ Try defining BROKEN_WAIT_FOR_SIGNAL. */ EMACS_WAIT_FOR_SIGNAL (SIGCHLD); } -#else /* not HAVE_WAITPID and (not EMACS_BLOCK_SIGNAL or BROKEN_WAIT_FOR_SIGNAL) */ +#else /* not HAVE_WAITPID and not WINDOWSNT and (not EMACS_BLOCK_SIGNAL or BROKEN_WAIT_FOR_SIGNAL) */ /* This approach is kind of cheesy but is guaranteed(?!) to work for all systems. */ while (1) @@ -578,7 +628,11 @@ static void sys_subshell (void) { +#ifdef WINDOWSNT + HANDLE pid; +#else int pid; +#endif struct save_signal saved_handlers[5]; Lisp_Object dir; unsigned char *str = 0; @@ -617,7 +671,7 @@ xyzzy: #ifdef WINDOWSNT - pid = -1; + pid = NULL; #else /* not WINDOWSNT */ pid = fork (); @@ -651,7 +705,7 @@ #ifdef WINDOWSNT /* Waits for process completion */ pid = _spawnlp (_P_WAIT, sh, sh, NULL); - if (pid == -1) + if (pid == NULL) write (1, "Can't execute subshell", 22); #else /* not WINDOWSNT */ @@ -3036,6 +3090,15 @@ return readlink (path, buf, bufsiz); } #endif /* ENCAPSULATE_READLINK */ + + +#ifdef ENCAPSULATE_FSTAT +int +sys_fstat (int fd, struct stat *buf) +{ + return fstat (fd, buf); +} +#endif /* ENCAPSULATE_FSTAT */ #ifdef ENCAPSULATE_STAT Index: src/sysdep.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.h,v retrieving revision 1.11.2.1 diff -u -r1.11.2.1 sysdep.h --- sysdep.h 1998/12/05 16:56:31 1.11.2.1 +++ sysdep.h 1999/11/10 02:14:45 @@ -48,7 +48,12 @@ /* Wait for subprocess with process id `pid' to terminate and make sure it will get eliminated (not remain forever as a zombie) */ +#ifdef WINDOWSNT +#include +void wait_for_termination (HANDLE pid); +#else void wait_for_termination (int pid); +#endif /* flush any pending output * (may flush input as well; it does not matter the way we use it) Index: src/sysfile.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysfile.h,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 sysfile.h --- sysfile.h 1998/12/05 16:56:32 1.7.2.1 +++ sysfile.h 1999/11/10 02:14:46 @@ -380,6 +380,18 @@ # define sys_readlink readlink #endif +#ifdef ENCAPSULATE_FSTAT +int sys_fstat (int fd, struct stat *buf); +#endif +#if defined (ENCAPSULATE_FSTAT) && !defined (DONT_ENCAPSULATE) +# undef fstat +/* Need to use arguments to avoid messing with struct stat */ +# define fstat(fd, buf) sys_fstat (fd, buf) +#endif +#if !defined (ENCAPSULATE_FSTAT) && defined (DONT_ENCAPSULATE) +# define sys_fstat fstat +#endif + #ifdef ENCAPSULATE_STAT int sys_stat (CONST char *path, struct stat *buf); #endif cvs server: Diffing src/m cvs server: Diffing src/s cvs server: Diffing tests cvs server: Diffing tests/DLL cvs server: Diffing tests/Dnd cvs server: Diffing tests/automated cvs server: Diffing tests/mule cvs server: Diffing tests/tooltalk Compilation exited abnormally with code 1 at Wed Nov 10 03:14:21 From owner-xemacs-beta@xemacs.org Tue Nov 9 23:04:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA04000 for xemacs-beta-out; Tue, 9 Nov 1999 23:04:33 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA03992 for ; Tue, 9 Nov 1999 23:04:28 -0500 Received: by localhost id m11lOzb-00016LC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 10 Nov 1999 13:04:19 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14376.61123.351697.770363@turnbull.sk.tsukuba.ac.jp> Date: Wed, 10 Nov 1999 13:04:19 +0900 (JST) To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 In-Reply-To: <9t97ljrykry.fsf@mraz.iskon.hr> References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> <14375.60294.35543.864163@turnbull.sk.tsukuba.ac.jp> <9t97ljrykry.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: >> I don't have a problem with allowing people to use `255' as an >> abbreviation for `?\377', as long as they don't care if we >> define the default interpretation for bytes in GR to be >> Latin-2. Hrvoje> That would be a bad idea, I think. There could be code Hrvoje> that assumes that stuff in [0, 256) range is Latin 1, or Hrvoje> that internal representation is independent of the Hrvoje> selected environment. Good. Let's smoke those bad assumptions out. Ebola Redux! :-) Of course I'm only about 10% serious. But I think this is on the agenda anyway. I see no good reason why Latin-1 should be privileged once we get the 1-byte buffer stuff working, and a very good reason why it shouldn't be (subtle bugs). In fact, putting the default interpretation of ?\xA1 under user control is _exactly_ the point of the 1-byte buffers. To my mind, the real question may very well be timing. Do we implement the 1-byte buffers first, and then try to flush out the Latin-1 assumptions hidden throughout (possibly, anyway) the code? Or do we make Latin-2 the default, and flush out those assumptions in an environment that will provide lots more opportunities to go wrong? >> But I can't see a good reason why "characters" with "code >> points" bigger than 255 should be permitted to be represented >> by integers as long as `int-char' doesn't take a character set >> argument. Hrvoje> Because it can be useful at times. Please be explicit. My point is precisely that the only use I can see for it is trying to find new ways to crash XEmacs. All of the sensible usages I can think of are perfectly well served by `make-char', perhaps preceded by `make-charset'. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 9 23:54:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA05481 for xemacs-beta-out; Tue, 9 Nov 1999 23:54:54 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA05478 for ; Tue, 9 Nov 1999 23:54:52 -0500 Received: by localhost id m11lPmR-00016LC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 10 Nov 1999 13:54:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14376.64150.886097.465471@turnbull.sk.tsukuba.ac.jp> Date: Wed, 10 Nov 1999 13:54:46 +0900 (JST) To: XEmacs Beta Test Subject: JOBS list for XEmacs In-Reply-To: <14375.50455.447946.792924@lasker.666.com> References: <14375.50455.447946.792924@lasker.666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Comments on proposed JOBS list: Ben> Japanese Liaison Stephen Turnbull This is, uh, condescending. We don't need a Japanese Liaison. We've got several Japanese who can liaise for themselves. Although some Japanese do have problems with the XEmacs development process as a matter of cultural differences, we should consider that the exception, not the rule, and deal with it ad hoc, as a matter of courtesy when the issue comes up in individual cases. What we do need is an I18N Liaison for Mule. Somebody whose job it is to do what Hrvoje has done for Latin-2, but for environments that don't have core developers who speak them natively. Somebody's whose job it is to be aware of which language environments have what degree of support. Which language environments have no beta testers (and maybe try to find some). What environments the Mule guys at ETL and perhaps elsewhere are adding. Further suggestions as to what an I18N Liaison could do are welcome. (Maybe do Mule base and language environment package maintenance? But see below.) If that job is on offer, I'll take it. Ben> Possible job to give a name: Package Release Maintainer. I would think that SUMOs and the package-list, and similar responsibilities, probably have quite different timing and other requirements from either the Stable Release or the Beta Release series of the core code. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Wed Nov 10 02:24:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA09761 for xemacs-beta-out; Wed, 10 Nov 1999 02:24:41 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA09755 for ; Wed, 10 Nov 1999 02:24:39 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id QAA16345; Wed, 10 Nov 1999 16:22:51 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Splash screen in help menu References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> <9t9yacbiqj0.fsf@mraz.iskon.hr> <9t9k8nvh0lc.fsf@mraz.iskon.hr> X-Attribution: sb From: SL Baur In-Reply-To: "Robin S. Socha"'s message of "07 Nov 1999 01:12:09 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 10 Nov 1999 16:22:50 +0900 Message-ID: Lines: 7 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Robin S Socha writes in xemacs-beta@xemacs.org: > And why do I need a "Splash" entry in the Help menu? It's the same place where Netscape puts it. An entry was made for it because there was no other single screen which displayed all the relevant copyright notices. From owner-xemacs-beta@xemacs.org Wed Nov 10 03:18:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA11088 for xemacs-beta-out; Wed, 10 Nov 1999 03:18:16 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA11082 for ; Wed, 10 Nov 1999 03:18:13 -0500 Received: from miho (localhost [127.0.0.1]) by miho.m17n.org (8.9.3/8.9.3) with ESMTP id RAA20122 for ; Wed, 10 Nov 1999 17:16:19 +0900 (JST) Date: Wed, 10 Nov 1999 17:16:19 +0900 (JST) Message-Id: <199911100816.RAA20122@miho.m17n.org> Mail-Copies-To: Never From: "XEmacs Build 'Bot" Subject: XEmacs Build Report for XEmacs-21.2.20 To: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Good afternoon XEmacs beta testers. I am in the process of building XEmacs-21.2.20 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ./configure '--prefix=/usr/local/devel/xemacs-builds' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.2-b20 "Yoko" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /usr/local/devel/xemacs-builds/xemacs-21.2 What installation prefix should install use? /usr/local/devel/xemacs-builds What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -O Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Runtime library search path: /usr/local/qt/lib:/usr/local/lib:/usr/local/X11R6/lib Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in support for Canna on Mule. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. From owner-xemacs-beta@xemacs.org Wed Nov 10 04:17:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA12826 for xemacs-beta-out; Wed, 10 Nov 1999 04:17:36 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA12821 for ; Wed, 10 Nov 1999 04:17:32 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11lTsg-0002du-00 for ; Wed, 10 Nov 1999 10:17:30 +0100 To: XEmacs Beta List Subject: Re: (insert 8000) crashes XEmacs 21.2.16 References: <1zivhcidm1p.fsf@as303.ecc.u-tokyo.ac.jp> <877ljt1inp.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9ln892t5x.fsf@mraz.iskon.hr> <14375.23141.101599.635073@crystal.WonderWorks.COM> <14375.32034.178089.276155@turnbull.sk.tsukuba.ac.jp> <87aeoo736l.fsf@dp50.ecc.u-tokyo.ac.jp> <3827C7A4.6B7AE63E@666.com> <14375.60294.35543.864163@turnbull.sk.tsukuba.ac.jp> <9t97ljrykry.fsf@mraz.iskon.hr> <14376.61123.351697.770363@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 10 Nov 1999 10:17:30 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 10 Nov 1999 13:04:19 +0900 (JST)" Message-ID: <9t9k8nq1z9x.fsf@mraz.iskon.hr> Lines: 43 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Hrvoje> That would be a bad idea, I think. There could be code > Hrvoje> that assumes that stuff in [0, 256) range is Latin 1, or > Hrvoje> that internal representation is independent of the > Hrvoje> selected environment. > > Good. Let's smoke those bad assumptions out. Ebola Redux! :-) Not now, John. :-) Yes, we'll exorcise Ebola sooner or later. The bulk of the work has been done, and we *think* we've faced the worst of the consequences. Now we can afford time to think about the issues and we needn't rush into anything. Case in point: a lot of code tries to increment characters, and gets integers in return. The code works because insert and friends work reasonably well with integers. If/when we modify insert to barf on integers, (1+ ?a) will need to signal an error instead of returning 98. (It could also return ?b, but that's too ugly to think about.) > Of course I'm only about 10% serious. But I think this is on the > agenda anyway. I see no good reason why Latin-1 should be > privileged once we get the 1-byte buffer stuff working, and a very > good reason why it shouldn't be (subtle bugs). In fact, putting the > default interpretation of ?\xA1 under user control is _exactly_ the > point of the 1-byte buffers. It's impossible to bring the interpretation of ?\xA1 under user control because such things are evaluated at read-time, not at run-time. (That's an important property of Lisp.) I suppose you could make (insert #xA1) do the "right" thing at run-time, but I think it would only create more confusion. As a certain lady would say, bad gut feeling. > To my mind, the real question may very well be timing. Do we > implement the 1-byte buffers first, and then try to flush out the > Latin-1 assumptions hidden throughout (possibly, anyway) the code? As I pointed out above, there is no need to hurry with the latter. There are much more important things to worry about in Mule, both with the internals and with the interface. From owner-xemacs-beta@xemacs.org Wed Nov 10 04:39:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA13378 for xemacs-beta-out; Wed, 10 Nov 1999 04:39:31 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA13374 for ; Wed, 10 Nov 1999 04:39:28 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id SAA20401; Wed, 10 Nov 1999 18:37:40 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 10 Nov 1999 18:37:40 +0900 Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've put XEmacs 21.2.20 on the FTP site: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ The patch kit is corrupted by two new binary files that weren't checked into CVS properly. The -info and -elc tarballs are no more. There is only a single xemacs-21.2.20.tar.gz file. I'll make a regular announcement over xemacs-announce tomorrow. Have a nice night/day/afternoon/whatever. From owner-xemacs-beta@xemacs.org Wed Nov 10 04:48:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA13612 for xemacs-beta-out; Wed, 10 Nov 1999 04:48:31 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA13609 for ; Wed, 10 Nov 1999 04:48:29 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA05314; Wed, 10 Nov 1999 10:48:26 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001J0; Wed Nov 10 10:48:20 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA24499; Wed, 10 Nov 1999 10:48:20 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Wow, I must have been bored... GPM stuff References: <86wvrrta5j.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 10 Nov 1999 10:48:18 +0100 In-Reply-To: wmperry@aventail.com's message of "09 Nov 1999 20:20:24 -0500" Message-ID: Lines: 43 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > ** .../linux/drivers/char/console.c in the function > ** tioclinux(). The following bit of code is brutal to > ** us: > ** > ** if (current->tty != tty && !suser()) > ** return -EPERM; > ** > ** I even tried setting us as a process leader, removing > ** our controlling terminal, and then using the TIOCSCTTY > ** to set up a new controlling terminal, all with no luck. If I read the code correctly you cannot use TIOCSCTTY on a tty that already has a sesssion on it (if you are not root). > ** What is even weirder is if you run XEmacs in a VC, and > ** attach to it from another VC with gnuclient, go back to > ** the original VC and hit a key, the mouse pointer > ** displays (in BOTH VCs), until you hit a key in the > ** second VC, after which it does not display in EITHER > ** VC. Bizarre, no? How do you see both VT's at once? Maybe the kernel just forgets to remove the mouse cursor until at least one character is drawn (that would be another kernel bug) > If anybody cares to wade through linux/drivers/char/ and show me a way to > get this working, the appropriate files are tty_io.c and console.c. #if 0 the check out. If you look in tty_io.c you'll see that almost all other such checks have met the same fate. > The reason they do the check (I think) is that so somebody can't just call > an ioctl() to set the selection on a VC that they do not own, and then call > the ioctl() to do a paste, in effect getting a screendump of that other > VC. It is still annoying though. Yes, but as you wrote before if you don't have the tty open you cannot call the ioctl in the first place. You can read from and write to the tty, why shouldn't you be able to mess with the mouse cursor? Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 04:52:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA13765 for xemacs-beta-out; Wed, 10 Nov 1999 04:52:50 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA13761 for ; Wed, 10 Nov 1999 04:52:48 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA05397; Wed, 10 Nov 1999 10:52:46 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001KI; Wed Nov 10 10:52:37 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA24501; Wed, 10 Nov 1999 10:52:37 +0100 To: Mark Thomas Cc: xemacs-beta@xemacs.org Subject: Re: 21.2-b19-sneaky: linux: make-frame-on-display seg fault References: <199911092229.RAA19160@justresearch.com> From: Jan Vroonhof Date: 10 Nov 1999 10:52:36 +0100 In-Reply-To: Mark Thomas's message of "Tue, 9 Nov 1999 17:29:34 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mark Thomas writes: > #0 0x2ac21502 in XGetIMValues () > #1 0x80cf621 in IMInstantiateCallback (dpy=0x86a2bd8, > client_data=0x86aba70 "\034\200=d9*P=baj\b=ba'", call_data=0x0) > at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:249 > #2 0x2ac46846 in _XimRegisterIMInstantiateCallback () > #3 0x2ac219aa in XRegisterIMInstantiateCallback () > #4 0x80cf915 in XIM_init_frame (f=0x86aba70) I think this is a known problem. There might even already be a patch in the patch queue. Please contact Kazuyuki IENAGA Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 06:36:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA15922 for xemacs-beta-out; Wed, 10 Nov 1999 06:36:53 -0500 Received: from ns.jsys.co.jp (ns.jsys.co.jp [202.33.240.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA15919 for ; Wed, 10 Nov 1999 06:36:50 -0500 Received: from cosmos.jsys.co.jp (cosmos.jsys.co.jp [172.31.80.5]) by ns.jsys.co.jp (8.9.3/8.9.3) with ESMTP id UAA25927; Wed, 10 Nov 1999 20:36:42 +0900 (JST) Received: from skywalk.jsys.co.jp (skywalk.jsys.co.jp [172.31.49.72]) by cosmos.jsys.co.jp (8.9.3/8.9.3/NOTES) with ESMTP id UAA18337; Wed, 10 Nov 1999 20:36:41 +0900 (JST) Received: (from ienaga@localhost) by skywalk.jsys.co.jp (8.9.3/3.7W) id UAA14673; Wed, 10 Nov 1999 20:38:49 +0900 To: Jan Vroonhof Cc: Mark Thomas , xemacs-beta@xemacs.org Subject: Re: 21.2-b19-sneaky: linux: make-frame-on-display seg fault References: <199911092229.RAA19160@justresearch.com> MIME-Version: 1.0 (generated by WEMI 1.13.5 - "Fijieda") Content-Type: text/plain; charset=US-ASCII From: Kazuyuki IENAGA Date: 10 Nov 1999 20:38:49 +0900 In-Reply-To: (Jan Vroonhof's message of "10 Nov 1999 10:52:36 +0100") Message-ID: Lines: 21 User-Agent: T-gnus/6.13.1 (based on Pterodactyl Gnus v0.96) (revision 01) X-Face: 8USaCFc~lusX>!w&WSKn|Y>{Xn3WCwoV[9?YtJcat&+&H{7'`-2#q,@WbK$2h?^E~KEcxb2 ccau$twWn%fCVrpm7`eA Jan Vroonhof writes: > Mark Thomas writes: > > > #0 0x2ac21502 in XGetIMValues () > > #1 0x80cf621 in IMInstantiateCallback (dpy=0x86a2bd8, > > client_data=0x86aba70 "\034\200=d9*P=baj\b=ba'", call_data=0x0) > > at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:249 > > #2 0x2ac46846 in _XimRegisterIMInstantiateCallback () > > #3 0x2ac219aa in XRegisterIMInstantiateCallback () > > #4 0x80cf915 in XIM_init_frame (f=0x86aba70) > > I think this is a known problem. There might even already be a patch > in the patch queue. Please contact Kazuyuki IENAGA The latest code (21.2.20 still has it) initializes an XIM when the X frame was initialized. I confirmed both with your operation; the genuine 21.2.20 was crashed and one with my latest patch was safe. -- kazz From owner-xemacs-beta@xemacs.org Wed Nov 10 08:31:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18175 for xemacs-beta-out; Wed, 10 Nov 1999 08:31:26 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA18170; Wed, 10 Nov 1999 08:31:21 -0500 Received: by avon.delcam.com; Wed, 10 Nov 1999 13:30:33 GMT Received: by pat.delcam.com; Wed, 10 Nov 1999 13:31:36 GMT Received: by dr2.delcam.com; Wed, 10 Nov 1999 13:31:38 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14377.29626.83861.397556@pub.news.uk.psi.net> Date: Wed, 10 Nov 1999 13:31:38 +0000 (GMT) To: xemacs-build-reports@xemacs.org CC: xemacs-beta@xemacs.org Subject: [Failure] 21.2.20 under IRIX 6.2 X-Mailer: VM 6.71 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) X-Face: "+N/{>9S5,OIk<0$%[)LGd} This is the same problem as I reported last week without any hints :-( After cvs updating, configuring and building my Installation file says this. uname -a: IRIX dr2 6.2 03131015 IP22 ../configure '--site-libraries=/usr/local/lib' '--site-includes=/usr/local/include' '--cflags=-g' '--package-path=/devdisk/d54man/gnu/xemacs-beta/packages' '--with-mule=no' XEmacs 21.2-b20 "Yoko" configured for `mips-sgi-irix6.2'. Where should the build process find the source code? /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -g Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- After loads of build stuff I get . . . Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loadhist.elc... Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... Fatal error: assertion failed, file /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/lisp.h, line 650, RECORD_TYPEP (obj, &lrecord_cons) make[1]: *** [xemacs] Abort make[1]: *** Deleting file `xemacs' make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 -- Paul Bibilo, Delcam plc, | Tel: +44 121 766 5544 Talbot Way, Small Heath, Birmingham, | Fax: +44 121 766 5511 England, B10 0HJ. _____|_____ ICBM-mail: 52 17N 1 30W #include | BLAT FOOP | ICQ: 32045109 From owner-xemacs-beta@xemacs.org Wed Nov 10 08:34:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18325 for xemacs-beta-out; Wed, 10 Nov 1999 08:34:56 -0500 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id IAA18319 for ; Wed, 10 Nov 1999 08:34:50 -0500 Received: (qmail 7733 invoked by alias); 10 Nov 1999 13:34:44 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 7702 invoked by uid 0); 10 Nov 1999 13:34:43 -0000 Received: from dialupb138.tcsn.uswest.net (HELO 666.com) (209.180.114.138) by tcsnpop1.tcsn.uswest.net with SMTP; 10 Nov 1999 13:34:43 -0000 Message-ID: <3829745A.90E45A14@666.com> Date: Wed, 10 Nov 1999 06:34:18 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Curtin CC: xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Veto. I am absolutely, positively sure that there's a version of browse-url out there that fixes this. In fact, I've already seen this fix been put into browse-url *numerous* times. Someone must have reverted our version, so let's fix that instead. ben Matt Curtin wrote: > Sending URLs to Netscape barfs if there are commas in the URL (as > there often are at news.com, britannica.com, and elsewhere). I added > a function to hexify the commas so it will work properly. Patch is > attached. > > (brwose-url.el seems to be abandoned; the URL in the comments is dead > and nothing on the site seems to point to the new place. If it really > is abandoned, I'll act as the maintainer.) > > -- > Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ > > Paula Corbin Jones David John Oates DES munitions Panama Saddam > Hussein Treasury Monica Lewinsky FBI class struggle SEAL Team 6 NWO > Vickie Weaver Kibo Noriega > > ------------------------------------------------------------------------ > *** browse-url.el Thu Mar 4 23:53:37 1999 > --- /home/cmcurtin/src/emacs/browse-url.el Tue Nov 9 13:20:25 1999 > *************** > *** 5,11 **** > ;; Author: Denis Howe > ;; Maintainer: Denis Howe > ;; Created: 03 Apr 1995 > ! ;; Version: 0.38 18 Jun 1996 > ;; Keywords: hypertext > ;; X-Home page: http://wombat.doc.ic.ac.uk/ > > --- 5,11 ---- > ;; Author: Denis Howe > ;; Maintainer: Denis Howe > ;; Created: 03 Apr 1995 > ! ;; Version: 0.38.1 9 Nov 1999 (cmcurtin patch to 0.38) > ;; Keywords: hypertext > ;; X-Home page: http://wombat.doc.ic.ac.uk/ > > *************** > *** 342,347 **** > --- 342,352 ---- > ;; b-u-file-url encodes fewer chars. Multi-display support for > ;; Netscape. Thanks Richard Mlynarik > > + ;; 0.38.1 9 Nov 1999 > + ;; browse-url-escape-url-for-netscape added to hexify commas > + ;; in URLs. -- Matt Curtin > + > + > ;;; Code: > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > *************** > *** 676,681 **** > --- 681,688 ---- > process-environment) > process-environment))) > > + (defun browse-url-escape-url-for-netscape (url) > + (replace-in-string url "," "%2c" t)) > > ;;;###autoload > (defun browse-url-netscape (url &optional new-window) > *************** > *** 699,705 **** > (append browse-url-netscape-arguments > (if new-window '("-noraise")) > (list "-remote" > ! (concat "openURL(" url > (if new-window ",new-window") > ")")))))) > (set-process-sentinel process > --- 706,713 ---- > (append browse-url-netscape-arguments > (if new-window '("-noraise")) > (list "-remote" > ! (concat "openURL(" > ! (browse-url-escape-url-for-netscape url) > (if new-window ",new-window") > ")")))))) > (set-process-sentinel process From owner-xemacs-beta@xemacs.org Wed Nov 10 09:15:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA19698 for xemacs-beta-out; Wed, 10 Nov 1999 09:15:13 -0500 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA19689; Wed, 10 Nov 1999 09:15:11 -0500 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11lYW3-0007L9-00; Wed, 10 Nov 1999 09:14:27 -0500 To: Ben Wing Cc: Matt Curtin , xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 10 Nov 1999 09:14:27 -0500 In-Reply-To: Ben Wing's message of "Wed, 10 Nov 1999 06:34:18 -0700" Message-ID: Lines: 1 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Does this only apply to netscape? From owner-xemacs-beta@xemacs.org Wed Nov 10 09:45:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA20893 for xemacs-beta-out; Wed, 10 Nov 1999 09:45:27 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA20890; Wed, 10 Nov 1999 09:45:24 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA19000; Wed, 10 Nov 1999 15:45:22 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004co; Wed Nov 10 15:45:15 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA25392; Wed, 10 Nov 1999 15:45:15 +0100 To: Paul Bibilo Cc: xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 References: <14377.29626.83861.397556@pub.news.uk.psi.net> From: Jan Vroonhof Date: 10 Nov 1999 15:45:14 +0100 In-Reply-To: Paul Bibilo's message of "Wed, 10 Nov 1999 13:31:38 +0000 (GMT)" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Paul Bibilo writes: > This is the same problem as I reported last week without any hints :-( Just for the sake of it, what happens when you build with "--pdump" > Fatal error: assertion failed, file /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/lisp.h, line 650, RECORD_TYPEP (obj, &lrecord_cons) This probably a dumping bug and thys it is hard to track down :-) Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 10:25:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA22374 for xemacs-beta-out; Wed, 10 Nov 1999 10:25:48 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA22357; Wed, 10 Nov 1999 10:25:36 -0500 Received: by avon.delcam.com; Wed, 10 Nov 1999 15:24:35 GMT Received: by pat.delcam.com; Wed, 10 Nov 1999 15:25:38 GMT Received: by dr2.delcam.com; Wed, 10 Nov 1999 15:25:41 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14377.36468.816633.95689@pub.news.uk.psi.net> Date: Wed, 10 Nov 1999 15:25:40 +0000 (GMT) To: Jan Vroonhof Cc: Paul Bibilo , xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 In-Reply-To: Jan Vroonhof's messaage of 10 November 1999 15:45:14 References: <14377.29626.83861.397556@pub.news.uk.psi.net> X-Mailer: VM 6.71 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) X-Face: "+N/{>9S5,OIk<0$%[)LGd} Jan Vroonhof writes: > Paul Bibilo writes: > > > This is the same problem as I reported last week without any hints :-( > > Just for the sake of it, what happens when you build with "--pdump" > It fails as follows: . . . Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/auto-show.elc... Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loadhist.elc... Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... make[1]: execve: ./xemacs: No such file or directory make[1]: *** [xemacs] Error 127 make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 -- Paul From owner-xemacs-beta@xemacs.org Wed Nov 10 10:40:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA23088 for xemacs-beta-out; Wed, 10 Nov 1999 10:40:30 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA23085 for ; Wed, 10 Nov 1999 10:40:28 -0500 Received: (qmail 77 invoked from network); 10 Nov 1999 15:39:10 -0000 Received: from usrpri2-24.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.89) by biff.kiva.net with SMTP; 10 Nov 1999 15:39:10 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA03063; Wed, 10 Nov 1999 10:42:09 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Wow, I must have been bored... GPM stuff References: <86wvrrta5j.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 47 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > ** .../linux/drivers/char/console.c in the function > > ** tioclinux(). The following bit of code is brutal to > > ** us: > > ** > > ** if (current->tty != tty && !suser()) > > ** return -EPERM; > > ** > > ** I even tried setting us as a process leader, removing > > ** our controlling terminal, and then using the TIOCSCTTY > > ** to set up a new controlling terminal, all with no luck. > > If I read the code correctly you cannot use TIOCSCTTY on a tty that > already has a sesssion on it (if you are not root). Looks that way. :( > > ** What is even weirder is if you run XEmacs in a VC, and > > ** attach to it from another VC with gnuclient, go back to > > ** the original VC and hit a key, the mouse pointer > > ** displays (in BOTH VCs), until you hit a key in the > > ** second VC, after which it does not display in EITHER > > ** VC. Bizarre, no? > > How do you see both VT's at once? Maybe the kernel just forgets to remove > the mouse cursor until at least one character is drawn (that would be > another kernel bug) If you switch back and forth between then with Alt-F1/Alt-F2 it works, until you hit a key that actually causes the tty to 'wake up' and see real input. > > If anybody cares to wade through linux/drivers/char/ and show me a way to > > get this working, the appropriate files are tty_io.c and console.c. > > #if 0 the check out. If you look in tty_io.c you'll see that almost > all other such checks have met the same fate. I did, and now everything works great. Unfortunately, I can't find the VC stuff in the MAINTAINERS file. I'll mail the patch to linux-kernel@vger.rutgers.edu later today to see if there are any objections to it, etc. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 10 11:55:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA26103 for xemacs-beta-out; Wed, 10 Nov 1999 11:55:44 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA26100 for ; Wed, 10 Nov 1999 11:55:42 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id LAA13941; Wed, 10 Nov 1999 11:55:43 -0500 To: xemacs-beta@xemacs.org Subject: Re: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site References: X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 10 Nov 1999 11:55:43 -0500 In-Reply-To: SL Baur's message of "10 Nov 1999 18:37:40 +0900" Message-ID: Lines: 7 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Looking at the dir, I see: xemacs-21.2.19.tar.gz 6500 Kb Thu Jul 29 23:52:00 1999 xemacs-21.2.20.tar.gz 8907 Kb Wed Nov 10 04:29:00 1999 Good lord. Has 21.2 *really* grown 2.4Mbytes (compressed!) between 2 beta releases? Over a third larger than the previous release? From owner-xemacs-beta@xemacs.org Wed Nov 10 12:02:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26299 for xemacs-beta-out; Wed, 10 Nov 1999 12:02:22 -0500 Received: (from jason@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26295 for xemacs-beta@xemacs.org; Wed, 10 Nov 1999 12:02:21 -0500 Date: Wed, 10 Nov 1999 12:02:20 -0500 From: Jason R Mastaler To: xemacs-beta@xemacs.org Subject: Re: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site Message-ID: <19991110120220.A26076@xemacs.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from SL Baur on Wed, Nov 10, 1999 at 06:37:40PM +0900 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > I'll make a regular announcement over xemacs-announce tomorrow. Actually, please don't. Remember, since all xemacs-announce messages will also go to both the xemacs (comp.emacs.xemacs) and xemacs-beta lists, we decided it would be best to send Beta related messages to xemacs-beta only, and continue to send all other announcements to xemacs-announce. Please see the "Announcements" thread on xemacs-beta for more info: From owner-xemacs-beta@xemacs.org Wed Nov 10 12:03:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26377 for xemacs-beta-out; Wed, 10 Nov 1999 12:03:42 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA26367; Wed, 10 Nov 1999 12:03:36 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA28817; Wed, 10 Nov 1999 18:03:34 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa0072D; Wed Nov 10 18:03:30 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id SAA05838; Wed, 10 Nov 1999 18:03:30 +0100 To: Paul Bibilo Cc: xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> From: Jan Vroonhof Date: 10 Nov 1999 18:03:30 +0100 In-Reply-To: Paul Bibilo's message of "Wed, 10 Nov 1999 15:25:40 +0000 (GMT)" Message-ID: Lines: 18 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Paul Bibilo writes: > It fails as follows: > Dumping under the name xemacs > Testing for Lisp shadows ... > make[1]: execve: ./xemacs: No such file or directory > make[1]: *** [xemacs] Error 127 > make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' > make: *** [src] Error 1 This is not failure this is success :-). The pdump'er doesn't produce xemacs it produces an xemacs.dmp file Start "./temacs" and it will see the xemacs.dmp file is there and load it. Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 12:47:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA27994 for xemacs-beta-out; Wed, 10 Nov 1999 12:47:54 -0500 Received: from gate.ispras.ru (gate.ispras.ru [194.67.37.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA27988 for ; Wed, 10 Nov 1999 12:47:49 -0500 Received: from fog (fog [194.67.37.129]) by gate.ispras.ru (8.9.3/8.9.3) with SMTP id VAA09784 for ; Wed, 10 Nov 1999 21:47:37 +0400 (GMT) Received: tid VAA07134; Wed, 10 Nov 1999 21:46:56 +0200 X-Authentication-Warning: fog: Host kazbek claimed to be kazbek.kazbek.ispras.ru Received: from dallas.kazbek.ispras.ru (dallas [194.186.94.155]) by kazbek.kazbek.ispras.ru (8.9.3/8.9.3) with ESMTP id UAA08306 for ; Wed, 10 Nov 1999 20:47:25 +0300 (MSK) Received: (from barancev@localhost) by dallas.kazbek.ispras.ru (8.9.3/8.8.7) id UAA14945; Wed, 10 Nov 1999 20:48:20 +0300 Date: Wed, 10 Nov 1999 20:48:20 +0300 Message-Id: <199911101748.UAA14945@dallas.kazbek.ispras.ru> From: "Alexey V. Barancev" To: xemacs-beta@xemacs.org Subject: Last frame deletion Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i686-pc-linux) of Wed Nov 10 1999 on dallas configured using `configure --with-pop --package-path=/usr/local/lib/xemacs/packages' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: 1. Start "xemacs -unmapped -f gnuserv-start" 2. Start "gnuclient" 3. Delete frame with "delete-frame" (I have bound C-x C-c on this defun) 4. Frame of the client killed 5. ANOTHER FRAME APPEARS INSTEAD! 6. Attempt to delete this frame gets error "Attempt to delete last frame" Variable `allow-deletion-of-last-visible-frame' set `t' with command (setq allow-deletion-of-last-visible-frame t) Recent keystrokes: button1 button1up C-x C-c button1 button1up C-x C-c C-x C-f ~ / . e / x e TAB RET down down down down down down down down down down down C-h v a l l o TAB d e TAB RET q C-x C-c M-x d e l e t e - f TAB r TAB RET misc-user Recent messages (most recent first): Parsing /localhome/alexey/.mailrc... Loading emacsbug...done Attempt to delete the only frame Loading emacsbug... Making completion list... Attempt to delete the only frame Loading view-less...done Loading view-less... Loading func-menu...done Loading func-menu... From owner-xemacs-beta@xemacs.org Wed Nov 10 12:56:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA28373 for xemacs-beta-out; Wed, 10 Nov 1999 12:56:22 -0500 Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA28367; Wed, 10 Nov 1999 12:56:16 -0500 Received: from gold.cis.ohio-state.edu (cmcurtin@gold.cis.ohio-state.edu [164.107.112.16]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA17134; Wed, 10 Nov 1999 12:56:15 -0500 (EST) Received: (from cmcurtin@localhost) by gold.cis.ohio-state.edu (8.9.1/8.9.1) id MAA10907; Wed, 10 Nov 1999 12:56:15 -0500 (EST) To: Ben Wing Cc: XEmacs Beta Test Subject: Re: JOBS list for XEmacs References: <14375.50455.447946.792924@lasker.666.com> X-Face: L"IcL.b%SDN]0Kql2b`e.}+i05V9fi\yX#H1+Xl)3!+n/3?5`%-SA-HDgPk9uTk<3dv^J5DCgal)-E{`zN#*o6F|y>r)\< Date: 10 Nov 1999 12:56:14 -0500 In-Reply-To: Ben Wing's message of "Mon, 8 Nov 1999 22:54:15 -0800 (PST)" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On Mon, 8 Nov 1999 22:54:15 -0800 (PST), >>>>> Ben Wing , Martin Buchholz said: Ben> Miscellaneous Documentation Ben> --------------------------- Ben> Lisp Reference Manual I'll volunteer for this. Ben> XEmacs User Manual I'm also interested in this, but I'd like to look at the Lisp Reference Manual job and be sure I can do that well before taking on something else at the same time. -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ From owner-xemacs-beta@xemacs.org Wed Nov 10 12:57:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA28427 for xemacs-beta-out; Wed, 10 Nov 1999 12:57:42 -0500 Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA28422; Wed, 10 Nov 1999 12:57:39 -0500 Received: from gold.cis.ohio-state.edu (cmcurtin@gold.cis.ohio-state.edu [164.107.112.16]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA17205; Wed, 10 Nov 1999 12:57:32 -0500 (EST) Received: (from cmcurtin@localhost) by gold.cis.ohio-state.edu (8.9.1/8.9.1) id MAA11720; Wed, 10 Nov 1999 12:57:32 -0500 (EST) To: nbecker@fred.net Cc: Ben Wing , xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> X-Face: L"IcL.b%SDN]0Kql2b`e.}+i05V9fi\yX#H1+Xl)3!+n/3?5`%-SA-HDgPk9uTk<3dv^J5DCgal)-E{`zN#*o6F|y>r)\< Date: 10 Nov 1999 12:57:32 -0500 In-Reply-To: nbecker@fred.net's message of "10 Nov 1999 09:14:27 -0500" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On 10 Nov 1999 09:14:27 -0500, nbecker@fred.net said: nbecker> Does this only apply to netscape? As far as I know, yes. (The issue is that in Netscape's remote control, there are multiple options available, comma separated.) -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ From owner-xemacs-beta@xemacs.org Wed Nov 10 13:12:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA29156 for xemacs-beta-out; Wed, 10 Nov 1999 13:12:17 -0500 Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA29149; Wed, 10 Nov 1999 13:12:11 -0500 Received: from gold.cis.ohio-state.edu (cmcurtin@gold.cis.ohio-state.edu [164.107.112.16]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id NAA18080; Wed, 10 Nov 1999 13:12:10 -0500 (EST) Received: (from cmcurtin@localhost) by gold.cis.ohio-state.edu (8.9.1/8.9.1) id NAA26546; Wed, 10 Nov 1999 13:12:09 -0500 (EST) To: Ben Wing Cc: xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> X-Face: L"IcL.b%SDN]0Kql2b`e.}+i05V9fi\yX#H1+Xl)3!+n/3?5`%-SA-HDgPk9uTk<3dv^J5DCgal)-E{`zN#*o6F|y>r)\< Date: 10 Nov 1999 13:12:08 -0500 In-Reply-To: Ben Wing's message of "Wed, 10 Nov 1999 06:34:18 -0700" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On Wed, 10 Nov 1999 06:34:18 -0700, Ben Wing said: Ben> Veto. I am absolutely, positively sure that there's a version of Ben> browse-url out there that fixes this. In fact, I've already seen Ben> this fix been put into browse-url *numerous* times. Someone must Ben> have reverted our version, so let's fix that instead. I just grabbed browse-url.el from GNU Emacs 20.2. It still has the problem. The code itself (both ours and FSF's version) points to http://wombat.doc.ic.ac.uk/emacs/browse-url.el, which is 404. FSF does have a new maintainer, though; perhaps I should submit the patch to him, and then we can incorporate the new browse-url.el that way. -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ From owner-xemacs-beta@xemacs.org Wed Nov 10 13:19:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA29367 for xemacs-beta-out; Wed, 10 Nov 1999 13:19:57 -0500 Received: from mail-out.globalone.net (mail-out.globalone.net [199.184.38.11]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA29364 for ; Wed, 10 Nov 1999 13:19:55 -0500 Received: from master.res.globalone.net (master.res.globalone.net [192.168.75.50]) by mail-out.globalone.net (8.8.5/8.8.5) with ESMTP id NAA24869 for ; Wed, 10 Nov 1999 13:19:09 -0500 Received: from mail3.res.globalone.net (mail3.res.globalone.net [160.81.232.17]) by master.res.globalone.net (8.8.5/8.8.5) with ESMTP id NAA19814 for ; Wed, 10 Nov 1999 13:19:07 -0500 Received: from globalone.net ([160.81.228.229]) by mail3.res.globalone.net (Netscape Messaging Server 3.62) with ESMTP id 388 for ; Wed, 10 Nov 1999 13:19:06 -0500 Message-ID: <3829B711.E2D7E3EF@globalone.net> Date: Wed, 10 Nov 1999 13:18:57 -0500 From: "Kevin Delia" Organization: Global One X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: Request for ps-print.el Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello, I have used NT Emacs ps-print.el, which allows line numbers to be printed with my output. No such variable (ps-line-number) exists in the NT XEmacs version of ps-print.el. Are there any plans to upgrade this package to provide similar support, or does an equivalent package already exist which allows for this functionality? Thanks in advance for your help.... From owner-xemacs-beta@xemacs.org Wed Nov 10 13:24:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA29517 for xemacs-beta-out; Wed, 10 Nov 1999 13:24:23 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA29512 for ; Wed, 10 Nov 1999 13:24:19 -0500 Received: by crystal.WonderWorks.COM id QQhotl04563; Wed, 10 Nov 1999 10:24:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14377.47185.474175.765662@crystal.WonderWorks.COM> Date: Wed, 10 Nov 1999 10:24:17 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Karl Kleinpaste writes: > Looking at the dir, I see: > > xemacs-21.2.19.tar.gz 6500 Kb Thu Jul 29 23:52:00 1999 > xemacs-21.2.20.tar.gz 8907 Kb Wed Nov 10 04:29:00 1999 > > Good lord. Has 21.2 *really* grown 2.4Mbytes (compressed!) between 2 > beta releases? Over a third larger than the previous release? The info and elc files are back in the core tar file. I'm sure this accounts for almost all the size increase. From owner-xemacs-beta@xemacs.org Wed Nov 10 13:39:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA30345 for xemacs-beta-out; Wed, 10 Nov 1999 13:39:27 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA30340 for ; Wed, 10 Nov 1999 13:39:26 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id NAA23666; Wed, 10 Nov 1999 13:39:26 -0500 To: xemacs-beta@xemacs.org Subject: gnuclient makes 21.2.b20 unhappy X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 10 Nov 1999 13:39:26 -0500 Message-ID: Lines: 94 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: 1. Start XEmacs 2. (gnuserv-start) 3. Start Gnus 4. read a few articles. 5. In an xterm, start "gnuclient -nw", which comes to life and displays the *Summary* buffer that is current in the main X window. 6. Hang. The main X window won't even redraw. 23544 pts/0 S 0:00 /usr/local/lib/xemacs-21.2-b20/i686-pc-linux/gnuserv 23543 tty1 S 0:20 xemacs -geometry 207x89+1282+0 -f gnus-init Attaching a gdb rewards me with this trace: #0 0x2ae11534 in __libc_read () #1 0xffffffff in ?? () #2 0x80cd313 in read_event_from_tty_or_stream_desc (event=0x87db8f0, con=0x8a1a910, fd=11) at event-unixoid.c:93 #3 0x81a06ca in Xt_tty_to_emacs_event (emacs_event=0x87db8f0) at event-Xt.c:2114 #4 0x81a0fa2 in emacs_Xt_next_event (emacs_event=0x87db8f0) at event-Xt.c:2441 #5 0x80d130b in event_stream_next_event (event=0x87db8f0) at event-stream.c:565 #6 0x80d32fa in next_event_internal (target_event=142457072, allow_queued=1) at event-stream.c:2020 #7 0x80d3915 in Fnext_event (event=142457072, prompt=136860660) at event-stream.c:2237 #8 0x8070d49 in Fcommand_loop_1 () at cmdloop.c:566 #9 0x8070f8d in command_loop_1 (dummy=136860660) at cmdloop.c:490 #10 0x8094f3c in condition_case_1 (handlers=136860756, bfun=0x8070f48 , barg=136860660, hfun=0x8070150 , harg=136860660) at eval.c:1630 #11 0x807106c in command_loop_2 (dummy=136860660) at cmdloop.c:252 #12 0x8094e1f in internal_catch (tag=136934876, func=0x8071034 , arg=136860660, threw=0x0) at eval.c:1305 #13 0x8070584 in initial_command_loop (load_me=136860660) at cmdloop.c:301 #14 0x8089b02 in xemacs_21_2_b20_i686_pc_linux () at emacs.c:1873 #15 0x808b7df in main () at emacs.c:2298 #16 0x2ad86cb3 in __libc_start_main (main=0x808b6e0
, argc=5, argv=0x7ffff944, init=0x804e4ec <_init>, fini=0x81da2b4 <_fini>, rtld_fini=0x2aab5350 <_dl_fini>, stack_end=0x7ffff93c) at ../sysdeps/generic/libc-start.c:78 I couldn't see any way of bringing it back to life, and had to resort to a blind kill. RH6.0 + 2.2.12. Installation contents: uname -a: Linux beaver.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown ./configure '--with-pop' '--with-mule' '--with-png' XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. Where should the build process find the source code? /home/src/Packages/xemacs/xemacs-21.2.20 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From owner-xemacs-beta@xemacs.org Wed Nov 10 13:54:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA31144 for xemacs-beta-out; Wed, 10 Nov 1999 13:54:58 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA31140; Wed, 10 Nov 1999 13:54:52 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA00854; Wed, 10 Nov 1999 19:54:40 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000DK; Wed Nov 10 19:54:35 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id TAA05949; Wed, 10 Nov 1999 19:54:34 +0100 To: Matt Curtin Cc: Ben Wing , xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> From: Jan Vroonhof Date: 10 Nov 1999 19:54:34 +0100 In-Reply-To: Matt Curtin's message of "10 Nov 1999 13:12:08 -0500" Message-ID: Lines: 1399 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Matt Curtin writes: > FSF does have a new maintainer, though; perhaps I should submit the > patch to him, and then we can incorporate the new browse-url.el that > way. FSF 20.4's browse-url escape's "," and ")". Here is the diff between there version and ours. Note that the diff cannot be applied as is because it removes useful stuff (like in annyoing FSF tradition the version numbers and history) I suggest you still act as "our" Maintainer. What would be cool if somebody would implement the netscape remote protocol directly (Unfortunately part of that includes "Grab the global X lock") Jan diff -u /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/mail-lib/browse-url.el /usr/local/app/emacs/20.4/share/emacs/20.4/lisp/browse-url.el --- /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/mail-lib/browse-url.el Wed Nov 10 19:45:59 1999 +++ /usr/local/app/emacs/20.4/share/emacs/20.4/lisp/browse-url.el Wed Nov 10 19:45:59 1999 @@ -1,37 +1,31 @@ -;;; browse-url.el --- ask a WWW browser to load a URL +;;; browse-url.el --- Pass a URL to a WWW browser -;; Copyright 1995 Free Software Foundation, Inc. +;; Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc. ;; Author: Denis Howe -;; Maintainer: Denis Howe +;; Maintainer: Dave Love ;; Created: 03 Apr 1995 -;; Version: 0.38 18 Jun 1996 -;; Keywords: hypertext -;; X-Home page: http://wombat.doc.ic.ac.uk/ - -;; This file is part of XEmacs. - -;; XEmacs 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) +;; Keywords: hypertext, hypermedia, mouse + +;; 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. -;; XEmacs 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. +;; 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 XEmacs; see the file COPYING. If not, write to the Free -;; Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA -;; 02111-1307, USA. +;; along with GNU Emacs; see the file COPYING. If not, write to the +;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;; Boston, MA 02111-1307, USA. -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Commentary: -;; The latest version of this package should be available from -;; . - ;; This package provides functions which read a URL (Uniform Resource ;; Locator) from the minibuffer, defaulting to the URL around point, ;; and ask a World-Wide Web browser to load it. It can also load the @@ -41,20 +35,25 @@ ;; is started. Currently there is support for: ;; Function Browser Earliest version -;; browse-url-netscape Netscape 1.1b1 -;; browse-url-mosaic XMosaic <= 2.4 +;; browse-url-netscape Netscape 1.1b1 +;; browse-url-mosaic XMosaic/mMosaic <= 2.4 ;; browse-url-cci XMosaic 2.5 ;; browse-url-w3 w3 0 +;; browse-url-w3-gnudoit w3 remotely ;; browse-url-iximosaic IXI Mosaic ? ;; browse-url-lynx-* Lynx 0 ;; browse-url-grail Grail 0.3b1 -;; browse-url-kfm kde +;; browse-url-mmm MMM ? +;; browse-url-generic arbitrary + +;; [A version of the Netscape browser is now free software +;; , albeit not GPLed, so it is +;; reasonable to have that as the default.] ;; Note that versions of Netscape before 1.1b1 did not have remote -;; control. -;; and . +;; control. . -;; Netscape can cache Web pages so it may be necessary to tell it to +;; Browsers can cache Web pages so it may be necessary to tell them to ;; reload the current page if it has changed (e.g. if you have edited ;; it). There is currently no perfect automatic solution to this. @@ -74,27 +73,51 @@ ;; Emacs ;; has a function w3-follow-url-at-point, but that ;; doesn't let you edit the URL like browse-url. - -;; I recommend Nelson Minar 's excellent -;; html-helper-mode.el for editing HTML and thank Nelson for -;; his many useful comments on this code. -;; - -;; This package generalises function html-previewer-process in Marc -;; Andreessen 's html-mode (LCD -;; modes/html-mode.el.Z) and provides better versions of the URL -;; functions in Michelangelo Grigni 's ffap.el -;; (find-file-at-point) . The huge -;; hyperbole package also contains similar functions. +;; The `gnuserv' package that can be used to control it in another +;; Emacs process is available from +;; . ;; Grail is the freely available WWW browser implemented in Python, a ;; cool object-oriented freely available interpreted language. Grail ;; 0.3b1 was the first version to have remote control as distributed. ;; For more information on Grail see -;; and for more information on +;; and for more information on ;; Python see . Grail support in ;; browse-url.el written by Barry Warsaw . +;; MMM is the freely available WWW browser implemented in Objective +;; Caml, a cool impure functional programming language, by Francois +;; Rouaix. See the MMM home page +;; . + +;; Lynx is now distributed by the FSF. See also +;; . + +;; Free graphical browsers that could be used by `browse-url-generic' +;; include Chimera and +;; , Arena +;; and Amaya +;; . mMosaic +;; (with development +;; support for Java applets and multicast) can be used like Mosaic by +;; setting `browse-url-mosaic-program' appropriately. + +;; I [Denis Howe, not Dave Love] recommend Nelson Minar +;; 's excellent html-helper-mode.el for editing +;; HTML and thank Nelson for his many useful comments on this code. +;; + +;; See also hm--html-menus . For composing correct HTML see also +;; PSGML the general SGML structure editor package +;; ; hm--html-menus can be used +;; with this. + +;; This package generalises function html-previewer-process in Marc +;; Andreessen's html-mode (LCD modes/html-mode.el.Z). See also the +;; ffap.el package. The huge hyperbole package also contains similar +;; functions. + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Help! @@ -104,34 +127,26 @@ ;; Do any other browsers have remote control? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -;; Installation - -;; Put the following in your ~/.emacs file: -;; -;; (autoload 'browse-url-at-point "browse-url" -;; "Ask a WWW browser to load the URL at or before point." t) -;; (autoload 'browse-url-at-mouse "browse-url" -;; "Ask a WWW browser to load a URL clicked with the mouse." t) -;; (autoload 'browse-url-of-buffer "browse-url" -;; "Ask a WWW browser to display BUFFER." t) -;; (autoload 'browse-url-of-file "browse-url" -;; "Ask a WWW browser to display FILE." t) -;; (autoload 'browse-url-of-dired-file "browse-url" -;; "In Dired, ask a WWW browser to display the file named on this line." t) - -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Usage ;; To display the URL at or before point: ;; M-x browse-url-at-point RET +;; or, similarly but with the opportunity to edit the URL extracted from +;; the buffer, use: +;; M-x browse-url ;; To display a URL by shift-clicking on it, put this in your ~/.emacs ;; file: -;; (global-set-key [S-mouse-1] 'browse-url-at-mouse) +;; (global-set-key [S-mouse-2] 'browse-url-at-mouse) +;; (Note that using Shift-mouse-1 is not desirable because +;; that event has a standard meaning in Emacs.) ;; To display the current buffer in a web browser: ;; M-x browse-url-of-buffer RET +;; To display the current region in a web browser: +;; M-x browse-url-of-region RET + ;; In Dired, to display the file named on the current line: ;; M-x browse-url-of-dired-file RET @@ -139,25 +154,30 @@ ;; Customisation (~/.emacs) ;; To see what variables are available for customization, type -;; `M-x set-variable browse-url TAB'. +;; `M-x set-variable browse-url TAB'. Better, use +;; `M-x customize-group browse-url'. ;; Bind the browse-url commands to keys with the `C-c C-z' prefix ;; (as used by html-helper-mode): ;; (global-set-key "\C-c\C-z." 'browse-url-at-point) ;; (global-set-key "\C-c\C-zb" 'browse-url-of-buffer) +;; (global-set-key "\C-c\C-zr" 'browse-url-of-region) ;; (global-set-key "\C-c\C-zu" 'browse-url) ;; (global-set-key "\C-c\C-zv" 'browse-url-of-file) ;; (add-hook 'dired-mode-hook -;; (function (lambda () -;; (local-set-key "\C-c\C-zf" 'browse-url-of-dired-file)))) +;; (lambda () +;; (local-set-key "\C-c\C-zf" 'browse-url-of-dired-file))) ;; Browse URLs in mail messages by clicking mouse-2: -;; (add-hook 'rmail-mode-hook (function (lambda () ; rmail-mode startup -;; (define-key rmail-mode-map [mouse-2] 'browse-url-at-mouse)))) +;; (add-hook 'rmail-mode-hook (lambda () ; rmail-mode startup +;; (define-key rmail-mode-map [mouse-2] 'browse-url-at-mouse))) ;; Browse URLs in Usenet messages by clicking mouse-2: ;; (eval-after-load "gnus" ;; '(define-key gnus-article-mode-map [mouse-2] 'browse-url-at-mouse)) +;; [The current version of Gnus provides a standard feature to +;; activate URLs in article buffers for invocation of browse-url with +;; mouse-2.] ;; Use the Emacs w3 browser when not running under X11: ;; (or (eq window-system 'x) @@ -172,14 +192,14 @@ ;; (autoload 'browse-url-netscape-reload "browse-url" ;; "Ask a WWW browser to redisplay the current file." t) ;; (add-hook 'html-helper-mode-hook -;; (function (lambda () +;; (lambda () ;; (add-hook 'local-write-file-hooks -;; (function (lambda () +;; (lambda () ;; (let ((local-write-file-hooks)) ;; (save-buffer)) ;; (browse-url-netscape-reload) -;; t)) ; => file written by hook -;; t)))) ; append to l-w-f-hooks +;; t) ; => file written by hook +;; t))) ; append to l-w-f-hooks ;; ;; OR have browse-url-of-file ask Netscape to load and then reload the ;; file: @@ -189,247 +209,158 @@ ;; You may also want to customise browse-url-netscape-arguments, e.g. ;; (setq browse-url-netscape-arguments '("-install")) ;; -;; or similarly for mosaic. - -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -;;; Change Log: - -;; 0.00 03 Apr 1995 Denis Howe -;; Created. - -;; 0.01 04 Apr 1995 -;; All names start with "browse-url-". Added provide. - -;; 0.02 05 Apr 1995 -;; Save file at start of browse-url-of-file. -;; Use start-process instead of start-process-shell-command. - -;; 0.03 06 Apr 1995 -;; Add browse-url-netscape-reload, browse-url-netscape-send. -;; browse-url-of-file save file option. - -;; 0.04 08 Apr 1995 -;; b-u-file-url separate function. Change b-u-filename-alist -;; default. - -;; 0.05 09 Apr 1995 -;; Added b-u-of-file-hook. - -;; 0.06 11 Apr 1995 -;; Improved .emacs suggestions and documentation. - -;; 0.07 13 Apr 1995 -;; Added browse-url-interactive-arg optional prompt. - -;; 0.08 18 Apr 1995 -;; Exclude final "." from browse-url-regexp. - -;; 0.09 21 Apr 1995 -;; Added mouse-set-point to browse-url-interactive-arg. - -;; 0.10 24 Apr 1995 -;; Added Mosaic signal sending variations. -;; Thanks Brian K Servis . -;; Don't use xprop for Netscape. - -;; 0.11 25 Apr 1995 -;; Fix reading of ~/.mosaicpid. Thanks Dag.H.Wanvik@kvatro.no. - -;; 0.12 27 Apr 1995 -;; Interactive prefix arg => URL *after* point. -;; Thanks Michelangelo Grigni . -;; Added IXI Mosaic support. -;; Thanks David Karr . - -;; 0.13 28 Apr 1995 -;; Exclude final [,;] from browse-url-regexp. - -;; 0.14 02 May 1995 -;; Provide browser argument variables. - -;; 0.15 07 May 1995 -;; More Netscape options. Thanks Peter Arius -;; . - -;; 0.16 17 May 1995 -;; Added browse-url-at-mouse. -;; Thanks Wayne Mesard - -;; 0.17 27 Jun 1995 -;; Renamed browse-url-at-point to browse-url-url-at-point. -;; Added browse-url-at-point. -;; Thanks Jonathan Cano . - -;; 0.18 16 Aug 1995 -;; Fixed call to browse-url-url-at-point in browse-url-at-point. -;; Thanks Eric Ding . - -;; 0.19 24 Aug 1995 -;; Improved documentation. -;; Thanks Kevin Rodgers . - -;; 0.20 31 Aug 1995 -;; browse-url-of-buffer to handle file-less buffers. -;; browse-url-of-dired-file browses current file in dired. -;; Thanks Kevin Rodgers . - -;; 0.21 09 Sep 1995 -;; XMosaic CCI functions. -;; Thanks Marc Furrer . - -;; 0.22 13 Sep 1995 -;; Fixed new-window documentation and added to browse-url-cci. -;; Thanks Dilip Sequeira . - -;; 0.23 10 Nov 1995 -;; Added b-u-lynx. Thanks Steven L. Baur . - -;; 0.24 22 Nov 1995 -;; Renamed b-u-netscape command to b-u-netscape-send. -;; Added b-u-netscape-command variable. - -;; 0.25 03 Dec 1995 -;; Added event-buffer and event-point for XEmacs compatibility. -;; Thanks Eric Engstrom +;; or similarly for the other browsers. -;; 0.26 13 Jan 1996 -;; Changed b-u-lynx to b-u-lynx-xterm, added b-u-lynx-emacs to -;; run Lynx in an Emacs buffer under terminal-emulator. -;; Thanks Jari Aalto - -;; 0.27 27 Feb 1996 -;; Changed event-buffer and event-point from macros to functions. -;; Other fixes for byte-compilation. - -;; 0.28 07 Mar 1996 -;; browse-url-lynx-emacs uses term.el instead of terminal.el. - -;; 0.29 13 Mar 1996 -;; Added browse-url-CCI-host. Thanks Greg Marr . - -;; 0.30 23 Mar 1996 -;; Contact/start Netscape in the background. -;; Thanks Per Abrahamsen - -;; 0.31 28 Apr 1996 -;; Added browse-url command. -;; Added new-window logic to b-u-interactive-arg. -;; b-u-file-url checks for EFS path. - -;; 0.32 02 May 1996 -;; Improved b-u-url-at-point matching to supply missing "http://". - -;; 0.33 01 Jun 1996 -;; Jari Aalto browse-url-lynx-emacs -;; fix. Thanks Jari. - -;; 0.34 05 Jun 1996 -;; b-u-file-url checks for EFS after alist. Thanks -;; Jens-U H Petersen - -;; 0.35 11 Jun 1996 -;; Grail support. Thanks Barry A. Warsaw -;; . - -;; 0.36 12 Jun 1996 -;; Fixed browse-url-looking-at (I hope). - -;; 0.37 15 Jun 1996 -;; b-u-file-url URL-encodes special chars. -;; Thanks Martin Schwenke . - -;; 0.38 17 Jun 1996 -;; b-u-file-url encodes fewer chars. Multi-display support for -;; Netscape. Thanks Richard Mlynarik +;; To invoke different browsers for different URLs: +;; (setq browse-url-browser-function '(("^mailto:" . browse-url-mail) +;; ("." . browse-url-netscape))) +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Code: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Variables -;; (eval-when-compile (require 'dired)) +(eval-when-compile (require 'thingatpt) + (require 'term) + (require 'w3-auto nil t)) (defgroup browse-url nil - "Ask a WWW browser to load a URL." + "Use a web browser to look at a URL." + :prefix "browse-url-" :group 'hypermedia) - -(defvar browse-url-path-regexp - "[^]\t\n \"'()<>[^`{}]*[^]\t\n \"'()<>[^`{}.,;]+" - "A regular expression probably matching the host, path or e-mail -part of a URL.") - -(defvar browse-url-short-regexp - (concat "[-A-Za-z0-9.]+" browse-url-path-regexp) - "A regular expression probably matching a URL without an access scheme. -Hostname matching is stricter in this case than for -``browse-url-regexp''.") - -(defvar browse-url-regexp - (concat - "\\(https?://\\|ftp://\\|gopher://\\|telnet://\\|wais://\\|file:/\\|s?news:\\|mailto:\\)" - browse-url-path-regexp) - "A regular expression probably matching a complete URL.") - - ;;;###autoload -(defcustom browse-url-browser-function 'browse-url-w3 +(defcustom browse-url-browser-function + (if (eq system-type 'windows-nt) + 'browse-url-default-windows-browser + 'browse-url-netscape) "*Function to display the current buffer in a WWW browser. -Used by the `browse-url-at-point', `browse-url-at-mouse', and -`browse-url-of-file' commands." - :type '(radio (function-item browse-url-w3) - (function-item browse-url-netscape) - (function-item browse-url-mosaic) - (function-item browse-url-cci) - (function-item browse-url-iximosaic) - (function-item browse-url-lynx-xterm) - (function-item browse-url-lynx-emacs) - (function-item browse-url-grail) - (function-item browse-url-kfm) - (function :tag "Other" nil)) +This is used by the `browse-url-at-point', `browse-url-at-mouse', and +`browse-url-of-file' commands. + +If the value is not a function it should be a list of pairs +(REGEXP . FUNCTION). In this case the function called will be the one +associated with the first REGEXP which matches the current URL. The +function is passed the URL and any other args of `browse-url'. The last +regexp should probably be \".\" to specify a default browser." + :type '(choice + (function-item :tag "Emacs W3" :value browse-url-w3) + (function-item :tag "W3 in another Emacs via `gnudoit'" + :value browse-url-w3-gnudoit) + (function-item :tag "Netscape" :value browse-url-netscape) + (function-item :tag "Mosaic" :value browse-url-mosaic) + (function-item :tag "Mosaic using CCI" :value browse-url-cci) + (function-item :tag "IXI Mosaic" :value browse-url-iximosaic) + (function-item :tag "Lynx in an xterm window" + :value browse-url-lynx-xterm) + (function-item :tag "Lynx in an Emacs window" + :value browse-url-lynx-emacs) + (function-item :tag "Grail" :value browse-url-grail) + (function-item :tag "MMM" :value browse-url-mmm) + (function-item :tag "Specified by `Browse Url Generic Program'" + :value browse-url-generic) + (function-item :tag "Default Windows browser" + :value browse-url-default-windows-browser) + (function :tag "Your own function")) + :version "20.4" :group 'browse-url) -(defcustom browse-url-netscape-command "netscape" - "*The name by which to invoke Netscape." +(defcustom browse-url-netscape-program "netscape" + ;; Info about netscape-remote from Karl Berry. + "The name by which to invoke Netscape. + +The free program `netscape-remote' from + is said to start +up very much quicker than `netscape'. Reported to compile on a GNU +system, given vroot.h from the same directory, with cc flags + -DSTANDALONE -L/usr/X11R6/lib -lXmu -lX11." :type 'string :group 'browse-url) (defcustom browse-url-netscape-arguments nil - "*A list of strings to pass to Netscape as arguments." + "A list of strings to pass to Netscape as arguments." :type '(repeat (string :tag "Argument")) :group 'browse-url) +(defcustom browse-url-netscape-startup-arguments browse-url-netscape-arguments + "A list of strings to pass to Netscape when it starts up. +Defaults to the value of `browse-url-netscape-arguments' at the time +`browse-url' is loaded." + :type '(repeat (string :tag "Argument")) + :group 'browse-url) + +;;;###autoload (defcustom browse-url-new-window-p nil - "*If non-nil, always open a new browser window. -Passing an interactive argument to \\[browse-url-netscape] or -\\[browse-url-cci] reverses the effect of this variable. Requires -Netscape version 1.1N or later or XMosaic version 2.5 or later." + "*If non-nil, always open a new browser window with appropriate browsers. +Passing an interactive argument to \\[browse-url], or specific browser +commands reverses the effect of this variable. Requires Netscape version +1.1N or later or XMosaic version 2.5 or later if using those browsers." :type 'boolean :group 'browse-url) +;;;###autoload +(defcustom browse-url-netscape-display nil + "*The X display for running Netscape, if not same as Emacs'." + :type '(choice string (const :tag "Default" nil)) + :group 'browse-url) + +(defcustom browse-url-mosaic-program "xmosaic" + "The name by which to invoke Mosaic (or mMosaic)." + :type 'string + :version "20.3" + :group 'browse-url) + (defcustom browse-url-mosaic-arguments nil - "*A list of strings to pass to Mosaic as arguments." + "A list of strings to pass to Mosaic as arguments." :type '(repeat (string :tag "Argument")) :group 'browse-url) -(defvar browse-url-filename-alist - '(("^/+" . "file:/")) - "An alist of (REGEXP . STRING) pairs. +(defcustom browse-url-filename-alist + '(("^/\\(ftp@\\|anonymous@\\)?\\([^:]+\\):/*" . "ftp://\\2/") + ;; The above loses the username to avoid the browser prompting for + ;; it in anonymous cases. If it's not anonymous the next regexp + ;; applies. + ("^/\\([^:@]+@\\)?\\([^:]+\\):/*" . "ftp://\\1\\2/") + ("^/+" . "file:/")) + "An alist of (REGEXP . STRING) pairs used by `browse-url-of-file'. Any substring of a filename matching one of the REGEXPs is replaced by -the corresponding STRING. All pairs are applied in the order given. -The default value prepends `file:' to any path beginning with `/'. -Used by the `browse-url-of-file' command.") - -(defvar browse-url-save-file nil - "If non-nil, save the buffer before displaying its file. -Used by the `browse-url-of-file' command.") - -(defvar browse-url-of-file-hook nil - "A hook to be run with run-hook after `browse-url-of-file' has asked -a browser to load a file. +the corresponding STRING using `replace-match', not treating STRING +literally. All pairs are applied in the order given. The default +value converts ange-ftp/EFS-style paths into ftp URLs and prepends +`file:' to any path beginning with `/'. + +For example, adding to the default a specific translation of an ange-ftp +address to an HTTP URL: + + (setq browse-url-filename-alist + '((\"/webmaster@webserver:/home/www/html/\" . + \"http://www.acme.co.uk/\") + (\"^/\\(ftp@\\|anonymous@\\)?\\([^:]+\\):/*\" . \"ftp://\\2/\") + (\"^/\\([^:@]+@\\)?\\([^:]+\\):/*\" . \"ftp://\\1\\2/\") + (\"^/+\" . \"file:/\"))) +" + :type '(repeat (cons :format "%v" + (regexp :tag "Regexp") + (string :tag "Replacement"))) + :version "20.3" + :group 'browse-url) + +;;;###autoload +(defcustom browse-url-save-file nil + "*If non-nil, save the buffer before displaying its file. +Used by the `browse-url-of-file' command." + :type 'boolean + :group 'browse-url) + +(defcustom browse-url-of-file-hook nil + "Run after `browse-url-of-file' has asked a browser to load a file. Set this to `browse-url-netscape-reload' to force Netscape to load the -file rather than displaying a cached copy.") +file rather than displaying a cached copy." + :type 'hook + :options '(browse-url-netscape-reload) + :group 'browse-url) (defvar browse-url-usr1-signal (if (and (boundp 'emacs-major-version) @@ -440,55 +371,113 @@ Emacs 19.29 accepts 'SIGUSR1, earlier versions require an integer which is 30 on SunOS and 16 on HP-UX and Solaris.") -(defvar browse-url-CCI-port 3003 +(defcustom browse-url-CCI-port 3003 "Port to access XMosaic via CCI. This can be any number between 1024 and 65535 but must correspond to -the value set in the browser.") +the value set in the browser." + :type 'integer + :group 'browse-url) -(defvar browse-url-CCI-host "localhost" +(defcustom browse-url-CCI-host "localhost" "*Host to access XMosaic via CCI. This should be the host name of the machine running XMosaic with CCI -enabled. The port number should be set in `browse-url-CCI-port'.") +enabled. The port number should be set in `browse-url-CCI-port'." + :type 'string + :group 'browse-url) (defvar browse-url-temp-file-name nil) (make-variable-buffer-local 'browse-url-temp-file-name) +(defcustom browse-url-xterm-program "xterm" + "The name of the terminal emulator used by `browse-url-lynx-xterm'. +This might, for instance, be a separate colour version of xterm." + :type 'string + :group 'browse-url) + +(defcustom browse-url-xterm-args nil + "*A list of strings defining options for `browse-url-xterm-program'. +These might set its size, for instance." + :type '(repeat (string :tag "Argument")) + :group 'browse-url) + +(defcustom browse-url-lynx-emacs-args (and (not window-system) + '("-show_cursor")) + "A list of strings defining options for Lynx in an Emacs buffer. + +The default is none in a window system, otherwise `-show_cursor' to +indicate the position of the current link in the absence of +highlighting, assuming the normal default for showing the cursor." + :type '(repeat (string :tag "Argument")) + :version "20.3" + :group 'browse-url) + +(defcustom browse-url-gnudoit-program "gnudoit" + "The name of the `gnudoit' program used by `browse-url-w3-gnudoit'." + :type 'string + :group 'browse-url) + +(defcustom browse-url-gnudoit-args '("-q") + "*A list of strings defining options for `browse-url-gnudoit-program'. +These might set the port, for instance." + :type '(repeat (string :tag "Argument")) + :group 'browse-url) + +;;;###autoload +(defcustom browse-url-generic-program nil + "*The name of the browser program used by `browse-url-generic'." + :type '(choice string (const :tag "None" nil)) + :group 'browse-url) + +(defcustom browse-url-generic-args nil + "*A list of strings defining options for `browse-url-generic-program'." + :type '(repeat (string :tag "Argument")) + :group 'browse-url) + +(defcustom browse-url-temp-dir temporary-file-directory + "The name of a directory for browse-url's temporary files. +Such files are generated by functions like `browse-url-of-region'. +You might want to set this to somewhere with restricted read permissions +for privacy's sake." + :type 'string + :group 'browse-url) + +(defcustom browse-url-netscape-version + 3 + "The version of Netscape you are using. +This affects how URL reloading is done; the mechanism changed +incompatibly at version 4." + :type 'number + :group 'browse-url) + +(defcustom browse-url-lynx-input-field 'avoid + "*Action on selecting an existing Lynx buffer at an input field. +What to do when sending a new URL to an existing Lynx buffer in Emacs +if the Lynx cursor is on an input field (in which case the `g' command +would be entered as data). Such fields are recognized by the +underlines ____. Allowed values: nil: disregard it, 'warn: warn the +user and don't emit the URL, 'avoid: try to avoid the field by moving +down (this *won't* always work)." + :type '(choice (const :tag "Move to try to avoid field" :value avoid) + (const :tag "Disregard" :value nil) + (const :tag "Warn, don't emit URL" :value warn)) + :version "20.3" + :group 'browse-url) + +(defvar browse-url-lynx-input-attempts 10 + "*How many times to try to move down from a series of lynx input fields.") + +(defcustom browse-url-lynx-input-delay 0.2 + "How many seconds to wait for lynx between moves down from an input field.") + (defvar browse-url-temp-file-list '()) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; URL input -;; thingatpt.el doesn't work for complex regexps - (defun browse-url-url-at-point () - "Return the URL around or before point. -Search backwards for the start of a URL ending at or after -point. If no URL found, return the empty string. The -access scheme, `http://' will be prepended if absent." - (cond ((browse-url-looking-at browse-url-regexp) - (buffer-substring (match-beginning 0) (match-end 0))) - ;; Access scheme omitted? - ((browse-url-looking-at browse-url-short-regexp) - (concat "http://" - (buffer-substring (match-beginning 0) (match-end 0)))) - (t ""))) ; No match - -(defun browse-url-looking-at (regexp) - "Return non-nil if point is in or just after a match for REGEXP. -Set the match data from the earliest such match in the current line -ending at or after point." - (save-excursion - (let ((old-point (point)) - (eol (progn (end-of-line) (point))) - (hit nil)) - (beginning-of-line) - (or (and (looking-at regexp) - (>= (match-end 0) old-point)) - (progn - (while (and (re-search-forward regexp eol t) - (<= (match-beginning 0) old-point) - (not (setq hit (>= (match-end 0) old-point))))) - hit))))) + (let ((url (thing-at-point 'url))) + (set-text-properties 0 (length url) nil url) + url)) ;; Having this as a separate function called by the browser-specific ;; functions allows them to be stand-alone commands, making it easier @@ -496,9 +485,9 @@ (defun browse-url-interactive-arg (prompt) "Read a URL from the minibuffer, prompting with PROMPT. -Default to the URL at or before point. If invoke with a mouse button, +Default to the URL at or before point. If invoked with a mouse button, set point to the position clicked first. Return a list for use in -`interactive' containing the URL and browse-url-new-window-p or its +`interactive' containing the URL and `browse-url-new-window-p' or its negation if a prefix argument was given." (let ((event (elt (this-command-keys) 0))) (and (listp event) (mouse-set-point event))) @@ -509,12 +498,13 @@ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Browse current buffer +;;;###autoload (defun browse-url-of-file (&optional file) "Ask a WWW browser to display FILE. Display the current buffer's file if FILE is nil or if called interactively. Turn the filename into a URL with function -browse-url-file-url. Pass the URL to a browser using variable -`browse-url-browser-function' then run `browse-url-of-file-hook'." +`browse-url-file-url'. Pass the URL to a browser using the +`browse-url' function then run `browse-url-of-file-hook'." (interactive) (or file (setq file (buffer-file-name)) @@ -526,21 +516,20 @@ (cond ((not (buffer-modified-p))) (browse-url-save-file (save-buffer)) (t (message "%s modified since last save" file)))))) - (funcall browse-url-browser-function (browse-url-file-url file)) + (browse-url (browse-url-file-url file)) (run-hooks 'browse-url-of-file-hook)) (defun browse-url-file-url (file) "Return the URL corresponding to FILE. -Use variable `browse-url-filename-alist' to map filenames to URLs. -Convert EFS file names of the form /USER@HOST:PATH to ftp://HOST/PATH." +Use variable `browse-url-filename-alist' to map filenames to URLs." ;; URL-encode special chars, do % first (let ((s 0)) (while (setq s (string-match "%" file s)) (setq file (replace-match "%25" t t file) s (1+ s)))) (while (string-match "[*\"()',=;? ]" file) - (setq file (replace-match (format "%%%x" (aref file (match-beginning 0))) - t t file))) + (let ((enc (format "%%%x" (aref file (match-beginning 0))))) + (setq file (replace-match enc t t file)))) (let ((maps browse-url-filename-alist)) (while maps (let* ((map (car maps)) @@ -548,33 +537,30 @@ (to-string (cdr map))) (setq maps (cdr maps)) (and (string-match from-re file) - (setq file (replace-match to-string t t file)))))) - ;; Check for EFS path - (and (string-match "^/\\([^:@]+@\\)?\\([^:]+\\):/*" file) - (setq file (concat "ftp://" - (substring file (match-beginning 2) (match-end 2)) - "/" (substring file (match-end 0))))) + (setq file (replace-match to-string t nil file)))))) file) +;;;###autoload (defun browse-url-of-buffer (&optional buffer) "Ask a WWW browser to display BUFFER. -Display the current buffer if BUFFER is nil." +Display the current buffer if BUFFER is nil. Display only the +currently visible part of BUFFER (from a temporary file) if buffer is +narrowed." (interactive) (save-excursion (and buffer (set-buffer buffer)) (let ((file-name - (or buffer-file-name - (and (boundp 'dired-directory) dired-directory)))) + ;; Ignore real name if restricted + (and (= (- (point-max) (point-min)) (buffer-size)) + (or buffer-file-name + (and (boundp 'dired-directory) dired-directory))))) (or file-name (progn (or browse-url-temp-file-name (setq browse-url-temp-file-name - (make-temp-name - (expand-file-name (buffer-name) - (or (getenv "TMPDIR") "/tmp"))) - browse-url-temp-file-list - (cons browse-url-temp-file-name - browse-url-temp-file-list))) + (convert-standard-filename + (make-temp-name + (expand-file-name "burl" browse-url-temp-dir))))) (setq file-name browse-url-temp-file-name) (write-region (point-min) (point-max) file-name nil 'no-message))) (browse-url-of-file file-name)))) @@ -603,79 +589,103 @@ (add-hook 'kill-buffer-hook 'browse-url-delete-temp-file) (add-hook 'kill-emacs-hook 'browse-url-delete-temp-file-list) +;;;###autoload (defun browse-url-of-dired-file () "In Dired, ask a WWW browser to display the file named on this line." (interactive) (browse-url-of-file (dired-get-filename))) +;;;###autoload +(defun browse-url-of-region (min max) + "Ask a WWW browser to display the current region." + (interactive "r") + (save-excursion + (save-restriction + (narrow-to-region min max) + (browse-url-of-buffer)))) + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -;; Browser-independant commands +;; Browser-independent commands -;; A generic command to call the current b-u-browser-function +;; A generic command to call the current browse-url-browser-function -(defun browse-url (&rest args) +;;;###autoload +(defun browse-url (url &rest args) "Ask a WWW browser to load URL. Prompts for a URL, defaulting to the URL at or before point. Variable `browse-url-browser-function' says which browser to use." (interactive (browse-url-interactive-arg "URL: ")) - (apply browse-url-browser-function args)) + (let ((bf browse-url-browser-function) re) + (unless (functionp bf) + (while (consp bf) + (setq re (car (car bf)) + bf (if (string-match re url) + (cdr (car bf)) ; The function + (cdr bf))))) ; More pairs + (or bf (error "No browser in browse-url-browser-function matching URL %s" + url)) + (apply bf url args))) +;;;###autoload (defun browse-url-at-point () "Ask a WWW browser to load the URL at or before point. -Doesn't let you edit the URL like browse-url. Variable +Doesn't let you edit the URL like `browse-url'. Variable `browse-url-browser-function' says which browser to use." (interactive) - (funcall browse-url-browser-function (browse-url-url-at-point))) + (browse-url (browse-url-url-at-point))) -;; Define these if not already defined (XEmacs compatibility) +(defun browse-url-event-buffer (event) + (window-buffer (posn-window (event-start event)))) -(eval-and-compile - (or (fboundp 'event-buffer) - (defun event-buffer (event) - (window-buffer (posn-window (event-start event)))))) - -(eval-and-compile - (or (fboundp 'event-point) - (defun event-point (event) - (posn-point (event-start event))))) +(defun browse-url-event-point (event) + (posn-point (event-start event))) +;;;###autoload (defun browse-url-at-mouse (event) "Ask a WWW browser to load a URL clicked with the mouse. The URL is the one around or before the position of the mouse click but point is not changed. Doesn't let you edit the URL like -browse-url. Variable `browse-url-browser-function' says which browser +`browse-url'. Variable `browse-url-browser-function' says which browser to use." (interactive "e") (save-excursion - (set-buffer (event-buffer event)) - (goto-char (event-point event)) + (set-buffer (browse-url-event-buffer event)) + (goto-char (browse-url-event-point event)) (let ((url (browse-url-url-at-point))) (if (string-equal url "") (error "No URL found")) - (funcall browse-url-browser-function url)))) + (browse-url url browse-url-new-window-p)))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Browser-specific commands -;; --- Netscape --- +;; --- Default MS-Windows browser --- -;; Put the correct DISPLAY value in the environment for Netscape -;; launched from multi-display Emacs. +(defun browse-url-default-windows-browser (url &optional new-window) + (interactive (browse-url-interactive-arg "URL: ")) + (w32-shell-execute "open" url)) + +;; --- Netscape --- (defun browse-url-process-environment () - (let* ((device (and (fboundp 'selected-device) - (fboundp 'device-connection) - (selected-device))) - (display (and device (fboundp 'device-type) - (eq (device-type device) 'x) - (not (equal (device-connection device) - (getenv "DISPLAY")))))) + "Set DISPLAY in the environment to the X display Netscape is running on. +This is either the value of variable `browse-url-netscape-display' if +non-nil, or the same display as Emacs if different from the current +environment, otherwise just use the current environment." + (let ((display (or browse-url-netscape-display (browse-url-emacs-display)))) (if display - ;; Attempt to run on the correct display - (cons (concat "DISPLAY=" (device-connection device)) - process-environment) + (cons (concat "DISPLAY=" display) process-environment) process-environment))) +(defun browse-url-emacs-display () + "Return the X display Emacs is running on. +This is nil if the display is the same as the DISPLAY environment variable. + +Actually Emacs could be using several displays; this just returns the +one showing the selected frame." + (let ((display (cdr-safe (assq 'display (frame-parameters))))) + (and (not (equal display (getenv "DISPLAY"))) + display))) ;;;###autoload (defun browse-url-netscape (url &optional new-window) @@ -687,24 +697,33 @@ When called interactively, if variable `browse-url-new-window-p' is non-nil, load the document in a new Netscape window, otherwise use a random existing one. A non-nil interactive prefix argument reverses -the effect of browse-url-new-window-p. +the effect of `browse-url-new-window-p'. When called non-interactively, optional second argument NEW-WINDOW is -used instead of browse-url-new-window-p." +used instead of `browse-url-new-window-p'." (interactive (browse-url-interactive-arg "Netscape URL: ")) + ;; URL encode any `confusing' characters in the URL. This needs to + ;; include at least commas; presumably also close parens. + (while (string-match "[,)]" url) + (setq url (replace-match + (format "%%%x" (string-to-char (match-string 0 url))) t t url))) (let* ((process-environment (browse-url-process-environment)) (process (apply 'start-process - (concat "netscape " url) nil - browse-url-netscape-command - (append browse-url-netscape-arguments - (if new-window '("-noraise")) - (list "-remote" - (concat "openURL(" url - (if new-window ",new-window") - ")")))))) + (concat "netscape " url) nil + browse-url-netscape-program + (append + browse-url-netscape-arguments + (if (eq window-system 'w32) + (list url) + (append + (if new-window '("-noraise")) + (list "-remote" + (concat "openURL(" url + (if new-window ",new-window") + ")")))))))) (set-process-sentinel process - (list 'lambda '(process change) - (list 'browse-url-netscape-sentinel 'process url))))) + (list 'lambda '(process change) + (list 'browse-url-netscape-sentinel 'process url))))) (defun browse-url-netscape-sentinel (process url) "Handle a change to the process communicating with Netscape." @@ -713,19 +732,24 @@ ;; Netscape not running - start it (message "Starting Netscape...") (apply 'start-process (concat "netscape" url) nil - browse-url-netscape-command - (append browse-url-netscape-arguments (list url)))))) + browse-url-netscape-program + (append browse-url-netscape-startup-arguments (list url)))))) (defun browse-url-netscape-reload () - "Ask Netscape to reload its current document." + "Ask Netscape to reload its current document. +How depends on `browse-url-netscape-version'." (interactive) - (browse-url-netscape-send "reload")) + ;; Backwards incompatibility reported by + ;; . + (browse-url-netscape-send (if (>= browse-url-netscape-version 4) + "xfeDoCommand(reload)" + "reload"))) (defun browse-url-netscape-send (command) "Send a remote control command to Netscape." (let* ((process-environment (browse-url-process-environment))) (apply 'start-process "netscape" nil - browse-url-netscape-command + browse-url-netscape-program (append browse-url-netscape-arguments (list "-remote" command))))) @@ -733,9 +757,20 @@ ;;;###autoload (defun browse-url-mosaic (url &optional new-window) - ;; new-window ignored "Ask the XMosaic WWW browser to load URL. -Default to the URL around or before point." + +Default to the URL around or before point. The strings in variable +`browse-url-mosaic-arguments' are also passed to Mosaic and the +program is invoked according to the variable +`browse-url-mosaic-program'. + +When called interactively, if variable `browse-url-new-window-p' is +non-nil, load the document in a new Mosaic window, otherwise use a +random existing one. A non-nil interactive prefix argument reverses +the effect of `browse-url-new-window-p'. + +When called non-interactively, optional second argument NEW-WINDOW is +used instead of `browse-url-new-window-p'." (interactive (browse-url-interactive-arg "Mosaic URL: ")) (let ((pidfile (expand-file-name "~/.mosaicpid")) pid) @@ -749,7 +784,10 @@ (save-excursion (find-file (format "/tmp/Mosaic.%d" pid)) (erase-buffer) - (insert "goto\n" url "\n") + (insert (if new-window + "newwin\n" + "goto\n") + url "\n") (save-buffer) (kill-buffer nil) ;; Send signal SIGUSR to Mosaic @@ -761,20 +799,20 @@ ) ;; Mosaic not running - start it (message "Starting Mosaic...") - (apply 'start-process "xmosaic" nil "xmosaic" + (apply 'start-process "xmosaic" nil browse-url-mosaic-program (append browse-url-mosaic-arguments (list url))) (message "Starting Mosaic...done")))) ;; --- Grail --- +;;;###autoload (defvar browse-url-grail (concat (or (getenv "GRAILDIR") "~/.grail") "/user/rcgrail.py") - "*Location of Grail remote control client script `rcgrail.py'. + "Location of Grail remote control client script `rcgrail.py'. Typically found in $GRAILDIR/rcgrail.py, or ~/.grail/user/rcgrail.py.") ;;;###autoload (defun browse-url-grail (url &optional new-window) - ;; new-window ignored "Ask the Grail WWW browser to load URL. Default to the URL around or before point. Runs the program in the variable `browse-url-grail'." @@ -784,7 +822,9 @@ (set-buffer (get-buffer-create " *Shell Command Output*")) (erase-buffer) ;; don't worry about this failing. - (call-process browse-url-grail nil 0 nil url) + (if new-window + (call-process browse-url-grail nil 0 nil "-b" url) + (call-process browse-url-grail nil 0 nil url)) (message "Sending URL to Grail... done"))) ;; --- Mosaic using CCI --- @@ -801,17 +841,20 @@ When called interactively, if variable `browse-url-new-window-p' is non-nil, load the document in a new browser window, otherwise use a random existing one. A non-nil interactive prefix argument reverses -the effect of browse-url-new-window-p. +the effect of `browse-url-new-window-p'. When called non-interactively, optional second argument NEW-WINDOW is -used instead of browse-url-new-window-p." +used instead of `browse-url-new-window-p'." (interactive (browse-url-interactive-arg "Mosaic URL: ")) (open-network-stream "browse-url" " *browse-url*" browse-url-CCI-host browse-url-CCI-port) ;; Todo: start browser if fails (process-send-string "browse-url" (concat "get url (" url ") output " - (if new-window "new" "current") "\r\n")) + (if new-window + "new" + "current") + "\r\n")) (process-send-string "browse-url" "disconnect\r\n") (delete-process "browse-url")) @@ -830,11 +873,31 @@ ;;;###autoload (defun browse-url-w3 (url &optional new-window) - ;; new-window ignored "Ask the w3 WWW browser to load URL. -Default to the URL around or before point." +Default to the URL around or before point. + +When called interactively, if variable `browse-url-new-window-p' is +non-nil, load the document in a new window. A non-nil interactive +prefix argument reverses the effect of `browse-url-new-window-p'. + +When called non-interactively, optional second argument NEW-WINDOW is +used instead of `browse-url-new-window-p'." (interactive (browse-url-interactive-arg "W3 URL: ")) - (w3-fetch url)) + (require 'w3) ; w3-fetch-other-window not autoloaded + (if new-window + (w3-fetch-other-window url) + (w3-fetch url))) + +;;;###autoload +(defun browse-url-w3-gnudoit (url &optional new-window) + ;; new-window ignored + "Ask another Emacs running gnuserv to load the URL using the W3 browser. +The `browse-url-gnudoit-program' program is used with options given by +`browse-url-gnudoit-args'. Default to the URL around or before point." + (interactive (browse-url-interactive-arg "W3 URL: ")) + (apply 'start-process (concat "gnudoit:" url) nil + browse-url-gnudoit-program + (append browse-url-gnudoit-args (list (concat "(w3-fetch \"" url "\")") "(raise-frame)")))) ;; --- Lynx in an xterm --- @@ -843,43 +906,140 @@ ;; new-window ignored "Ask the Lynx WWW browser to load URL. Default to the URL around or before point. A new Lynx process is run -in an Xterm window." +in an Xterm window using the Xterm program named by `browse-url-xterm-program' +with possible additional arguments `browse-url-xterm-args'." (interactive (browse-url-interactive-arg "Lynx URL: ")) - (start-process (concat "lynx" url) nil "xterm" "-e" "lynx" url)) - + (apply #'start-process `(,(concat "lynx" url) nil ,browse-url-xterm-program + ,@browse-url-xterm-args "-e" "lynx" ,url))) ;; --- Lynx in an Emacs "term" window --- ;;;###autoload -(defun browse-url-lynx-emacs (url &optional new-window) - ;; new-window ignored +(defun browse-url-lynx-emacs (url &optional new-buffer) "Ask the Lynx WWW browser to load URL. -Default to the URL around or before point. Run a new Lynx process in -an Emacs buffer." +Default to the URL around or before point. With a prefix argument, run +a new Lynx process in a new buffer. + +When called interactively, if variable `browse-url-new-window-p' is +non-nil, load the document in a new lynx in a new term window, +otherwise use any existing one. A non-nil interactive prefix argument +reverses the effect of `browse-url-new-window-p'. + +When called non-interactively, optional second argument NEW-WINDOW is +used instead of `browse-url-new-window-p'." (interactive (browse-url-interactive-arg "Lynx URL: ")) - (unless (featurep 'term) - (condition-case nil - (require 'term) - (t (error "No terminal emulation in this XEmacs")))) - (let ((system-uses-terminfo t)) ; Lynx uses terminfo - (cond ((fboundp 'make-term) - (let ((term-term-name "vt100")) - (set-buffer (make-term "browse-url" "lynx" nil url)) - (term-mode) - (term-char-mode) - (switch-to-buffer "*browse-url*"))) - ((fboundp 'terminal-emulator) - (terminal-emulator "*browse-url*" "lynx" (list url))) - (t (error "No terminal emulation in this XEmacs"))))) + (let* ((system-uses-terminfo t) ; Lynx uses terminfo + ;; (term-term-name "vt100") ; ?? + (buf (get-buffer "*lynx*")) + (proc (and buf (get-buffer-process buf))) + (n browse-url-lynx-input-attempts)) + (if (and new-buffer buf) + ;; Rename away the OLD buffer. This isn't very polite, but + ;; term insists on working in a buffer named *lynx* and would + ;; choke on *lynx*<1> + (progn (set-buffer buf) + (rename-uniquely))) + (if (or new-buffer + (not buf) + (not proc) + (not (memq (process-status proc) '(run stop)))) + ;; start a new lynx + (progn + (setq buf + (apply #'make-term + `("lynx" "lynx" nil ,@browse-url-lynx-emacs-args ,url))) + (switch-to-buffer buf) + (term-char-mode) + (set-process-sentinel + (get-buffer-process buf) + ;; Don't leave around a dead one (especially because of its + ;; munged keymap.) + (lambda (process event) + (if (not (memq (process-status process) '(run stop))) + (let ((buf (process-buffer process))) + (if buf (kill-buffer buf))))))) + ;; send the url to lynx in the old buffer + (let ((win (get-buffer-window buf t))) + (if win + (select-window win) + (switch-to-buffer buf))) + (if (eq (following-char) ?_) + (cond ((eq browse-url-lynx-input-field 'warn) + (error "Please move out of the input field first.")) + ((eq browse-url-lynx-input-field 'avoid) + (while (and (eq (following-char) ?_) (> n 0)) + (term-send-down) ; down arrow + (sit-for browse-url-lynx-input-delay)) + (if (eq (following-char) ?_) + (error "Cannot move out of the input field, sorry."))))) + (term-send-string proc (concat "g" ; goto + "\C-u" ; kill default url + url + "\r"))))) + +;; --- MMM --- ;;;###autoload -(defun browse-url-kfm (url &optional new-window) - ;; new-window ignored - "Ask the kfm WWW browser to load URL. +(defun browse-url-mmm (url &optional new-window) + "Ask the MMM WWW browser to load URL. Default to the URL around or before point." - (interactive (browse-url-interactive-arg "kfm URL: ")) - (message "Sending URL to kfm...") - (start-process "kfmclient" nil "kfmclient" "openURL" url)) + (interactive (browse-url-interactive-arg "MMM URL: ")) + (message "Sending URL to MMM...") + (save-excursion + (set-buffer (get-buffer-create " *Shell Command Output*")) + (erase-buffer) + ;; mmm_remote just SEGVs if the file isn't there... + (if (or (file-exists-p (expand-file-name "~/.mmm_remote")) + ;; location in v 0.4: + (file-exists-p (expand-file-name "~/.mmm/remote"))) + (call-process "mmm_remote" nil 0 nil url) + (call-process "mmm" nil 0 nil "-external" url)) + (message "Sending URL to MMM... done"))) + +;; --- mailto --- + +;;;###autoload +(defun browse-url-mail (url &optional new-window) + "Open a new mail message buffer within Emacs. +Default to using the mailto: URL around or before point as the +recipient's address. Supplying a non-nil interactive prefix argument +will cause the mail to be composed in another window rather than the +current one. + +When called interactively, if variable `browse-url-new-window-p' is +non-nil use `compose-mail-other-window', otherwise `compose-mail'. A +non-nil interactive prefix argument reverses the effect of +`browse-url-new-window-p'. + +When called non-interactively, optional second argument NEW-WINDOW is +used instead of `browse-url-new-window-p'." + (interactive (browse-url-interactive-arg "Mailto URL: ")) + (save-excursion + (let ((to (if (string-match "^mailto:" url) + (substring url 7) + url))) + (if new-window + (compose-mail-other-window to nil nil nil + (list 'insert-buffer (current-buffer))) + (compose-mail to nil nil nil nil + (list 'insert-buffer (current-buffer))))))) + +;; --- Random browser --- + +;;;###autoload +(defun browse-url-generic (url &optional new-window) + ;; new-window ignored + "Ask the WWW browser defined by `browse-url-generic-program' to load URL. +Default to the URL around or before point. A fresh copy of the +browser is started up in a new process with possible additional arguments +`browse-url-generic-args'. This is appropriate for browsers which +don't offer a form of remote control." + (interactive (browse-url-interactive-arg "URL: ")) + (if (not browse-url-generic-program) + (error "No browser defined (`browse-url-generic-program')")) + (apply 'start-process (concat browse-url-generic-program url) nil + browse-url-generic-program + (append browse-url-generic-args (list url)))) (provide 'browse-url) From owner-xemacs-beta@xemacs.org Wed Nov 10 14:02:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA31488 for xemacs-beta-out; Wed, 10 Nov 1999 14:02:07 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA31483 for ; Wed, 10 Nov 1999 14:02:05 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA01649; Wed, 10 Nov 1999 20:01:50 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000Pi; Wed Nov 10 20:01:41 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id UAA05996; Wed, 10 Nov 1999 20:01:41 +0100 To: "Kevin Delia" Cc: xemacs-beta@xemacs.org Subject: Re: Request for ps-print.el References: <3829B711.E2D7E3EF@globalone.net> From: Jan Vroonhof Date: 10 Nov 1999 20:01:41 +0100 In-Reply-To: "Kevin Delia"'s message of "Wed, 10 Nov 1999 13:18:57 -0500" Message-ID: Lines: 19 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Kevin Delia" writes: > I have used NT Emacs ps-print.el, which allows line numbers to be > printed with my output. No such variable (ps-line-number) exists in the > NT XEmacs version of ps-print.el. Are there any plans to upgrade this > package to provide similar support, or does an equivalent package > already exist which allows for this functionality? We already have a ps-print version which can do that. However that only works under Mule. Therefore we ship the old version for non-mule. If you are a bit lisp savvy you can try making a version that works on both starting from http://www.xemacs.org/list-archives/xemacs-beta/9906/msg00534.html Basically you need a lot of (when (featurep 'mule) ...) wrappers around what I commented out above. Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 15:13:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA01510 for xemacs-beta-out; Wed, 10 Nov 1999 15:13:47 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA01507 for ; Wed, 10 Nov 1999 15:13:44 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA02279; Wed, 10 Nov 1999 21:13:43 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000Z.; Wed Nov 10 21:13:35 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id VAA06082; Wed, 10 Nov 1999 21:13:35 +0100 To: Karl Kleinpaste Cc: xemacs-beta@xemacs.org Subject: Re: gnuclient makes 21.2.b20 unhappy References: From: Jan Vroonhof Date: 10 Nov 1999 21:13:35 +0100 In-Reply-To: Karl Kleinpaste's message of "10 Nov 1999 13:39:26 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Karl Kleinpaste writes: > #0 0x2ae11534 in __libc_read () > #1 0xffffffff in ?? () > #2 0x80cd313 in read_event_from_tty_or_stream_desc (event=0x87db8f0, It is block in read() which is weird because XEmacs opens everything with O_NONBLOCK Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 15:21:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA01739 for xemacs-beta-out; Wed, 10 Nov 1999 15:21:39 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA01735 for ; Wed, 10 Nov 1999 15:21:36 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA02338; Wed, 10 Nov 1999 21:21:33 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000_U; Wed Nov 10 21:21:25 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id VAA06102; Wed, 10 Nov 1999 21:21:25 +0100 To: "Alexey V. Barancev" Cc: xemacs-beta@xemacs.org Subject: Re: Last frame deletion References: <199911101748.UAA14945@dallas.kazbek.ispras.ru> From: Jan Vroonhof Date: 10 Nov 1999 21:21:25 +0100 In-Reply-To: "Alexey V. Barancev"'s message of "Wed, 10 Nov 1999 20:48:20 +0300" Message-ID: Lines: 16 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Alexey V. Barancev" writes: > 1. Start "xemacs -unmapped -f gnuserv-start" > 2. Start "gnuclient" > 3. Delete frame with "delete-frame" (I have bound C-x C-c on this defun) > 4. Frame of the client killed > 5. ANOTHER FRAME APPEARS INSTEAD! > 6. Attempt to delete this frame gets error "Attempt to delete last frame" This is strange. I cannot reproduce this. Does this also happen when you use "xemacs -vanilla -unmapped -f gnuserv-start" (and use C-x 5 0 to delete the frame) Jan From owner-xemacs-beta@xemacs.org Wed Nov 10 16:46:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA04024 for xemacs-beta-out; Wed, 10 Nov 1999 16:46:51 -0500 Received: from home.plutonium.net (home.plutonium.net [205.216.126.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA04021 for ; Wed, 10 Nov 1999 16:46:50 -0500 Received: from dogbert (skaro.limolink.com [205.216.126.26]) by home.plutonium.net (8.8.7/8.8.6) with SMTP id PAA19928 for ; Wed, 10 Nov 1999 15:50:51 -0600 Message-ID: <005b01bf2bc5$47c15ef0$1a7ed8cd@dogbert.plutonium.net> From: "James N. Potts" To: "XEmacs Beta Mailing List" Subject: spam from mailing list Date: Wed, 10 Nov 1999 15:48:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm getting a little tired of the "laser printer toner advertisement" spam from the mailing list. Can't these be filtered out (if not at the majordomo level, then at the MT level)? James Potts From owner-xemacs-beta@xemacs.org Wed Nov 10 16:46:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA04002 for xemacs-beta-out; Wed, 10 Nov 1999 16:46:01 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA03993 for ; Wed, 10 Nov 1999 16:45:58 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id QAA01643; Wed, 10 Nov 1999 16:45:58 -0500 To: xemacs-beta@xemacs.org Subject: 21.2.b20 simply departs life with exit 1 on Xt error Keywords: tabs,exit,xt X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 10 Nov 1999 16:45:57 -0500 Message-ID: Lines: 162 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have seen this 4 times today already, all while reading news with Gnus. I am not yet sure of circumstances; it is surely not directly reproducible. But the last 2 times, when I was especially aware of what had just gone down, it was when leaving groups that had just displayed MIMEd HTML content. That is, that's where I've noticed it, though I have no idea whether MIMEd HTML is relevant to the death. A sample error being generated is Error: Widget *Article* has zero width and/or height which is a fairly fascinating assertion on Xt's part. Next time it happens, I'll leave the dying XEmacs around, stuck in gdb, so I can poke at values in which it believes; I would welcome suggestions for particular items to look at. I will note, however, that it looks like "tabs" are guilty yet again (frames 11 & 17), and I notice rather a lot of tab flickering (highly annoying, regardless of relative bugginess) as I move from group to group. There are few matters of programming which annoy me more than library functions which unilaterally conclude to exit the process. Xt sucks. RH6.0 + 2.2.12 + XFree 3.3.5. Installation file at bottom. (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y 0x2ad8f532 in exit at exit.c:40 2 breakpoint keep y 0x2adfd910 <_exit> (gdb) c Continuing. Breakpoint 1, exit (status=1) at exit.c:40 exit.c:40: No such file or directory. (gdb) bt #0 exit (status=1) at exit.c:40 #1 0x2abc5eb3 in _XtDefaultError () #2 0x2abc5f2a in XtError () #3 0x2abc5a94 in DefaultMsg () #4 0x2abc5b0b in _XtDefaultErrorMsg () #5 0x2abc5c0e in XtAppErrorMsg () #6 0x2abcf102 in XtCreateWindow () #7 0x2aae0d4a in Realize () #8 0x2aaefd5c in Realize () #9 0x2abceb7b in RealizeWidget () #10 0x2abcee54 in XtRealizeWidget () #11 0x81d7345 in TabsChangeManaged (w=0x8a28ce8) at xlwtabs.c:971 #12 0x2abd1a33 in ManageChildren () #13 0x2abd1be2 in XtManageChildren () #14 0x2abd1cbb in XtManageChild () #15 0x2abc2ed9 in XtCreateManagedWidget () #16 0x81cb47e in xaw_create_label (parent=0x8a28ce8, val=0x85c2350) at lwlib-Xaw.c:773 #17 0x81d24ad in xlw_update_tab_control (instance=0x86ba3e8, widget=0x8a28ce8, val=0x85bb4c8) at lwlib-Xlw.c:406 #18 0x81d2600 in xlw_update_one_widget (instance=0x86ba3e8, widget=0x8a28ce8, val=0x85bb4c8, deep_p=1) at lwlib-Xlw.c:560 #19 0x81c96d2 in lw_modify_all_widgets (id=65618, val=0x85bf478, deep_p=1 '\001') at lwlib.c:687 #20 0x81ab928 in x_tab_control_set_property (image_instance=143741720, prop=136984236, val=146339012) at glyphs-x.c:2711 #21 0x811f4bf in widget_set_property (image_instance=143741720, prop=136984236, val=146339012) at glyphs-widget.c:309 #22 0x810eb63 in Fset_image_instance_property (image_instance=143741720, prop=136984236, val=146339012) at glyphs.c:1362 #23 0x80908ba in Ffuncall (nargs=4, args=0x7ffff0b0) at eval.c:3178 #24 0x80628c9 in execute_optimized_program ( program=0x87852b0 "ÀÁ!­5Â\013!­0Ä\r!ÆÇ!\036\b\036\t\016\b¬\022ÊË!C\036\bÌ\036\rÎÏ\016\b\"*\026\bÐ\016\tÑ\016\b#\210Ò\016\tÓ Ì#*\207å*\021", stack_depth=4, constants_data=0x84e1f90) at bytecode.c:743 #25 0x80624ae in funcall_compiled_function (fun=139232104, nargs=0, args=0x7ffff238) at bytecode.c:519 #26 0x8090a04 in Ffuncall (nargs=1, args=0x7ffff234) at eval.c:3210 #27 0x80917ff in run_hook_with_args_in_buffer (buf=0x8ae0bb8, nargs=1, args=0x7ffff234, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #28 0x809436f in run_hook_with_args (nargs=1, args=0x7ffff234, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3674 #29 0x809438a in run_hook (hook=139289988) at eval.c:3528 #30 0x805c64c in Fkill_buffer (buffer=145623992) at buffer.c:1218 #31 0x8090894 in Ffuncall (nargs=2, args=0x7ffff2e4) at eval.c:3178 #32 0x80628c9 in execute_optimized_program ( program=0x8a0dd50 "À \210\t\211\032­\013Ã\n!­\006ÄÃ\n!!)«\013\212\tq\210Å\016\006!\210)Ç \210È \210\016\t\036\nË\016\t!\036\f\016\r\036\016Ï\036\020p\036\02---Type to continue, or q to quit--- 1\016\f¬\017\016\022«\004Ó \210\016\024«\004Õ \210Ö×!\210\016\030¬ \016\031\211\036\021\211\032­\013\n;«\004ê\002Ä\n!)«\006Ú\016\021!\210)Ï\026\e\016\034«\aÝ \210Þ \210ß\016\n!\210\016 «\004á \210\016\"«\006ã\016\n!\210ä\016\n\036%æç\016%\"«\t\016%è\225ÏOª\003\016%)!\210\016\f¬\bÖé!\210ê \210ë\016\n!\210\016,q\210\016\f¬\006í\016\n!\210Ö"..., stack_depth=5, constants_data=0x88bd638) at bytecode.c:743 #33 0x80624ae in funcall_compiled_function (fun=143325164, nargs=0, args=0x7ffff40c) at bytecode.c:519 #34 0x8090a04 in Ffuncall (nargs=1, args=0x7ffff408) at eval.c:3210 #35 0x80943c0 in apply1 (fn=143325164, arg=136860660) at eval.c:3793 #36 0x8066a4d in Fcall_interactively (function=141130804, record_flag=136860660, keys=136860660) at callint.c:394 #37 0x808f0e2 in Fcommand_execute (cmd=141130804, record=136860660, keys=136860660) at eval.c:2613 #38 0x80d79a2 in execute_command_event (command_builder=0x853e5d8, event=146972516) at event-stream.c:4343 #39 0x80d858f in Fdispatch_event (event=146972516) at event-stream.c:4682 #40 0x8070d5b in Fcommand_loop_1 () at cmdloop.c:575 #41 0x8070f8d in command_loop_1 (dummy=136860660) at cmdloop.c:490 #42 0x8094f3c in condition_case_1 (handlers=136860756, bfun=0x8070f48 , barg=136860660, hfun=0x8070150 , harg=136860660) at eval.c:1630 #43 0x807106c in command_loop_2 (dummy=136860660) at cmdloop.c:252 #44 0x8094e1f in internal_catch (tag=136934876, func=0x8071034 , arg=136860660, threw=0x0) at eval.c:1305 #45 0x8070584 in initial_command_loop (load_me=136860660) at cmdloop.c:301 #46 0x8089b02 in xemacs_21_2_b20_i686_pc_linux () at emacs.c:1873 #47 0x808b7df in main () at emacs.c:2298 #48 0x2ad86cb3 in __libc_start_main (main=0x808b6e0
, argc=5, argv=0x7ffff934, init=0x804e4ec <_init>, fini=0x81da2b4 <_fini>, rtld_fini=0x2aab5350 <_dl_fini>, stack_end=0x7ffff92c) at ../sysdeps/generic/libc-start.c:78 (gdb) c Continuing. Breakpoint 2, 0x2adfd910 in _exit () (gdb) c Continuing. Program exited with code 01. uname -a: Linux beaver.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown ./configure '--with-pop' '--with-mule' '--with-png' XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. Where should the build process find the source code? /home/src/Packages/xemacs/xemacs-21.2.20 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From owner-xemacs-beta@xemacs.org Wed Nov 10 17:11:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA05006 for xemacs-beta-out; Wed, 10 Nov 1999 17:11:25 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA05001 for ; Wed, 10 Nov 1999 17:11:23 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id RAA01903; Wed, 10 Nov 1999 17:11:22 -0500 To: xemacs-beta@xemacs.org Subject: Re: 21.2.b20 simply departs life with exit 1 on Xt error References: X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 10 Nov 1999 17:11:22 -0500 In-Reply-To: Karl Kleinpaste's message of "10 Nov 1999 16:45:57 -0500" Message-ID: Lines: 197 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Well, it didn't take long to get another victim -- all of about 3 minutes. It's sitting here in gdb hell now. And I've backed down to .b19. The output of "xwininfo -tree" is rather more impressive these days. *64* children?!? Half of those with multiple grandchildren? Is it proper that *nothing* has a name? xwininfo: Window id: 0x4c00029 "emacs: *Summary comp.protocols.dns.bind*" Root window id: 0x26 (the root window) (has no name) Parent window id: 0x1800302 (has no name) 1 child: 0x4c0002a (has no name): () 1267x976+0+0 +5+21 64 children: 0x4c00478 (has no name): () 15x661+1248+287 +1253+308 0x4c0054c (has no name): () 1244x15+4+258 +9+279 0x4c00484 (has no name): () 15x173+1248+85 +1253+106 0x4c02561 (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c02562 (has no name): () 10x23+0+0 +9+88 0x4c012f8 (has no name): () 1244x15+4+258 +9+279 0x4c02440 (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c02441 (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c025e7 (has no name): () 62617x61355+1+22 +10+110 0x4c02603 (has no name): () 62363x61101+1+22 +10+110 0x4c025fc (has no name): () 1257x65531+1+22 +10+110 0x4c025f5 (has no name): () 62617x61355+1+22 +10+110 0x4c025ee (has no name): () 62617x61355+1+22 +10+110 0x4c0231f (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c02320 (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c024e2 (has no name): () 1257x65531+1+22 +10+110 0x4c024c6 (has no name): () 1257x65531+1+22 +10+110 0x4c024db (has no name): () 62617x61355+1+22 +10+110 0x4c024d4 (has no name): () 1257x65531+1+22 +10+110 0x4c024cd (has no name): () 1257x65531+1+22 +10+110 0x4c021fe (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c021ff (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c023c1 (has no name): () 1257x65531+1+22 +10+110 0x4c023a5 (has no name): () 1257x65531+1+22 +10+110 0x4c023ba (has no name): () 1257x65531+1+22 +10+110 0x4c023b3 (has no name): () 1257x65531+1+22 +10+110 0x4c023ac (has no name): () 1257x65531+1+22 +10+110 0x4c020dd (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c020de (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c022a0 (has no name): () 1257x65531+1+22 +10+110 0x4c02284 (has no name): () 1257x65531+1+22 +10+110 0x4c02299 (has no name): () 15877x14615+1+22 +10+110 0x4c02292 (has no name): () 1257x65531+1+22 +10+110 0x4c0228b (has no name): () 62617x61355+1+22 +10+110 0x4c01fbc (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c01fbd (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c0217f (has no name): () 62617x61355+1+22 +10+110 0x4c02163 (has no name): () 1257x65531+1+22 +10+110 0x4c02178 (has no name): () 1253x65527+1+22 +10+110 0x4c02171 (has no name): () 62335x61073+1+22 +10+110 0x4c0216a (has no name): () 1257x65531+1+22 +10+110 0x4c01825 (has no name): () 481x15+4+258 +9+279 0x4c001e6 (has no name): () 15x173+485+85 +490+106 0x4c00147 (has no name): () 15x661+485+287 +490+308 0x4c01d26 (has no name): () 80x18+0+0 +5+21 0x4c01c91 (has no name): () 1259x18+4+67 +9+88 0x4c01c88 (has no name): () 80x18+0+0 +5+21 0x4c01c15 (has no name): () 1259x18+4+67 +9+88 0x4c01ab5 (has no name): () 80x18+0+0 +5+21 0x4c01a20 (has no name): () 1259x18+4+67 +9+88 0x4c01a17 (has no name): () 80x18+0+0 +5+21 0x4c019a5 (has no name): () 1259x18+4+67 +9+88 0x4c01764 (has no name): () 80x18+0+0 +5+21 0x4c016cf (has no name): () 1259x18+4+67 +9+88 0x4c016c6 (has no name): () 80x18+0+0 +5+21 0x4c01547 (has no name): () 80x18+0+0 +5+21 1 child: 0x4c01548 (has no name): () 1259x18+0+0 +6+22 4 children: 0x4c015e2 (has no name): () 62x14+1+22 +7+44 0x4c015f7 (has no name): () 4238x4190+1+22 +7+44 0x4c015f0 (has no name): () 4238x4190+1+22 +7+44 0x4c015e9 (has no name): () 4238x4190+1+22 +7+44 0x4c014ce (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c014cf (has no name): () 1259x18+0+0 +9+88 3 children: 0x4c01942 (has no name): () 50x14+1+22 +10+110 0x4c01950 (has no name): () 4226x4190+1+22 +10+110 0x4c01949 (has no name): () 4226x4190+1+22 +10+110 0x4c014c5 (has no name): () 80x18+0+0 +5+21 1 child: 0x4c014c6 (has no name): () 1259x18+0+0 +6+22 4 children: 0x4c0162f (has no name): () 4230x4182+1+22 +7+44 0x4c0161a (has no name): () 4230x4182+1+22 +7+44 0x4c01628 (has no name): () 62x14+1+22 +7+44 0x4c01621 (has no name): () 4230x4182+1+22 +7+44 0x4c01467 (has no name): () 1259x18+4+67 +9+88 1 child: 0x4c01468 (has no name): () 1259x18+0+0 +9+88 5 children: 0x4c019fa (has no name): () 50x14+1+22 +10+110 0x4c01a16 (has no name): () 4536x4500+1+22 +10+110 0x4c01a0f (has no name): () 4536x4500+1+22 +10+110 0x4c01a08 (has no name): () 4536x4500+1+22 +10+110 0x4c01a01 (has no name): () 360x324+1+22 +10+110 0x4c01393 (has no name): () 1259x18+4+67 +9+88 0x4c012b0 (has no name): () 1259x18+4+67 +9+88 0x4c011ce (has no name): () 1259x18+4+67 +9+88 0x4c0016d (has no name): () 481x15+4+258 +9+279 0x4c01083 (has no name): () 80x18+0+0 +5+21 0x4c0100a (has no name): () 1259x18+4+67 +9+88 0x4c01001 (has no name): () 80x18+0+0 +5+21 0x4c00f9d (has no name): () 1259x18+4+67 +9+88 0x4c00e52 (has no name): () 80x18+0+0 +5+21 0x4c00dd9 (has no name): () 1259x18+4+67 +9+88 0x4c00dd0 (has no name): () 80x18+0+0 +5+21 0x4c00d72 (has no name): () 1259x18+4+67 +9+88 0x4c00c26 (has no name): () 80x18+0+0 +5+21 0x4c00bad (has no name): () 1259x18+4+67 +9+88 0x4c00ba4 (has no name): () 80x18+0+0 +5+21 0x4c00b25 (has no name): () 1259x18+4+67 +9+88 0x4c00a03 (has no name): () 80x18+0+0 +5+21 0x4c0098a (has no name): () 1259x18+4+67 +9+88 0x4c00981 (has no name): () 80x18+0+0 +5+21 0x4c00924 (has no name): () 1259x18+4+67 +9+88 0x4c0080a (has no name): () 80x18+0+0 +5+21 0x4c00791 (has no name): () 1259x18+4+67 +9+88 0x4c00788 (has no name): () 80x18+0+0 +5+21 0x4c0072b (has no name): () 1259x18+4+67 +9+88 0x4c005b4 (has no name): () 80x18+0+0 +5+21 0x4c00557 (has no name): () 1259x18+4+67 +9+88 0x4c0054e (has no name): () 80x18+0+0 +5+21 0x4c00504 (has no name): () 1259x18+4+67 +9+88 0x4c003a4 (has no name): () 80x18+0+0 +5+21 0x4c0032b (has no name): () 1259x18+4+67 +9+88 0x4c00322 (has no name): () 80x18+0+0 +5+21 0x4c001ae (has no name): () 80x18+0+0 +5+21 0x4c00043 (has no name): () 80x18+0+0 +5+21 1 child: 0x4c00044 (has no name): () 1259x18+0+0 +6+22 5 children: 0x4c018d6 (has no name): () 158x14+1+22 +7+44 0x4c018ba (has no name): () 4400x4256+1+22 +7+44 0x4c018cf (has no name): () 224x80+1+22 +7+44 0x4c018c8 (has no name): () 4400x4256+1+22 +7+44 0x4c018c1 (has no name): () 224x80+1+22 +7+44 0x4c00031 (has no name): () 1259x18+4+67 +9+88 0x4c0002c (has no name): () 1267x950+0+26 +5+47 0x4c0002b (has no name): () 1265x24+0+0 +5+21 The beginning of the stack trace: #0 exit (status=1) at exit.c:40 #1 0x2abc5eb3 in _XtDefaultError () #2 0x2abc5f2a in XtError () #3 0x2abc5a94 in DefaultMsg () #4 0x2abc5b0b in _XtDefaultErrorMsg () #5 0x2abc5c0e in XtAppErrorMsg () #6 0x2abcf102 in XtCreateWindow () #7 0x2aae0d4a in Realize () #8 0x2aaefd5c in Realize () #9 0x2abceb7b in RealizeWidget () #10 0x2abcee54 in XtRealizeWidget () #11 0x81d7345 in TabsChangeManaged (w=0x8ba3b00) at xlwtabs.c:971 #12 0x2abd1a33 in ManageChildren () #13 0x2abd1be2 in XtManageChildren () #14 0x2abd1cbb in XtManageChild () #15 0x2abc2ed9 in XtCreateManagedWidget () #16 0x81cb47e in xaw_create_label (parent=0x8ba3b00, val=0x85be1d8) at lwlib-Xaw.c:773 #17 0x81d24ad in xlw_update_tab_control (instance=0x8964470, widget=0x8ba3b00, val=0x8807910) at lwlib-Xlw.c:406 #18 0x81d2600 in xlw_update_one_widget (instance=0x8964470, widget=0x8ba3b00, val=0x8807910, deep_p=1) at lwlib-Xlw.c:560 #19 0x81c96d2 in lw_modify_all_widgets (id=65652, val=0x8b42b50, deep_p=1 '\001') at lwlib.c:687 #20 0x81ab928 in x_tab_control_set_property (image_instance=143931648, prop=136984236, val=146341840) at glyphs-x.c:2711 #21 0x811f4bf in widget_set_property (image_instance=143931648, prop=136984236, val=146341840) at glyphs-widget.c:309 #22 0x810eb63 in Fset_image_instance_property (image_instance=143931648, prop=136984236, val=146341840) at glyphs.c:1362 It is perhaps significant that the parent referenced in frame #16 (used again in frame #11) does not appear in the output of "xwininfo -tree" at all. XFree 3.3.5 RH6.0 2.2.12. From owner-xemacs-beta@xemacs.org Wed Nov 10 17:36:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA08084 for xemacs-beta-out; Wed, 10 Nov 1999 17:36:31 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA08081 for ; Wed, 10 Nov 1999 17:36:30 -0500 Received: from postal.sr.hp.com (postal.sr.hp.com [15.4.46.173]) by palrel1.hp.com (Postfix) with ESMTP id F3286321 for ; Wed, 10 Nov 1999 14:36:28 -0800 (PST) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id OAA02298 for ; Wed, 10 Nov 1999 14:36:36 -0800 (PST) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id OAA09166 for ; Wed, 10 Nov 1999 14:36:27 -0800 (PST) Message-Id: <199911102236.OAA09166@mina.sr.hp.com> To: XEmacs Beta List Subject: Re: spam from mailing list Reply-To: Darryl Okahata In-reply-to: Your message of "Wed, 10 Nov 1999 15:48:10 CST." <005b01bf2bc5$47c15ef0$1a7ed8cd@dogbert.plutonium.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Nov 1999 14:36:26 -0800 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "James N. Potts" wrote: > I'm getting a little tired of the "laser printer toner advertisement" spam > from the mailing list. Can't these be filtered out (if not at the majordomo > level, then at the MT level)? Use a spam filter (I'm using one). For more information, see: http://www.ecofuture.org/ecofuture/jmemail.html#efilters [ Oh, sorry. ;-( I just noticed that you're using a PC mail program. Unfortunately, filtering on a PC is non-trivial, and generally costs $$$ (unlike Unix). ] Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Wed Nov 10 22:05:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA15881 for xemacs-beta-out; Wed, 10 Nov 1999 22:05:07 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA15878 for ; Wed, 10 Nov 1999 22:05:04 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id MAA20594; Thu, 11 Nov 1999 12:03:16 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site References: <14377.47185.474175.765662@crystal.WonderWorks.COM> X-Attribution: sb From: SL Baur In-Reply-To: Kyle Jones's message of "Wed, 10 Nov 1999 10:24:17 -0800 (PST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 11 Nov 1999 12:03:16 +0900 Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes in xemacs-beta@xemacs.org: > Karl Kleinpaste writes: >> Looking at the dir, I see: >> >> xemacs-21.2.19.tar.gz 6500 Kb Thu Jul 29 23:52:00 1999 >> xemacs-21.2.20.tar.gz 8907 Kb Wed Nov 10 04:29:00 1999 >> >> Good lord. Has 21.2 *really* grown 2.4Mbytes (compressed!) between 2 >> beta releases? Over a third larger than the previous release? > The info and elc files are back in the core tar file. I'm sure > this accounts for almost all the size increase. Yup. In 21.2.19 the -info tarball is 1.5MB and the -elc tarball is .79MB. If having these put into the core is a problem I will take them back out. If you have a problem with the size and you are living in an area with highly expensive telecommunications, your vote counts for more. From owner-xemacs-beta@xemacs.org Thu Nov 11 00:49:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA20534 for xemacs-beta-out; Thu, 11 Nov 1999 00:49:05 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA20531 for ; Thu, 11 Nov 1999 00:49:02 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id OAA20745; Thu, 11 Nov 1999 14:47:04 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: XEmacs 21.2.20 "Yoko" is released X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 11 Nov 1999 14:47:04 +0900 Message-ID: Lines: 41 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Get it from the usual places: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ http://cvs.xemacs.org/ There is a packaging change. For this beta, the -elc and -info tarballs have not been separated into their own tarballs. This causes about a ~2.5MB increase in size. If this causes problems for people, particularly people who live in areas with high telecommunications costs, please let me know and the -elc and -info tarballs will return. There will be another packaging change for 21.2.2x "Mercedes". I will be making two tarballs, one with the full minimal core as in 21.2.20, the other will additionally include a minimum of packages to bootstrap from. In particular this will include efs. to 21.2.20 "Yoko" -- UTF-8 & file-coding magic cookie fix from MORIOKA Tomohiko -- bug fixes from Adrian Aichner, Sean MacLennan, and Jeff Miller -- glyph widget support under X/Athena from Andy Piper -- tab widget support under X (all variants) from Andy Piper -- many gutter, redisplay & widget fixes from Andy Piper -- mswindows mousewheel support from Mike Woolley -- combo box support under X/Motif from Andy Piper -- buffer tab grouping from Andy Piper -- layout widget support from Andy Piper -- partial display line scrolling support from Andy Piper -- cleanup patches from Gleb Arshinov -- hash table FSF API sync from Martin Buchholz -- widget cleanup from Martin Buchholz -- process-environment fix for nt from Julian Back -- widget to frame fix from Jan Vroonhof -- animated glyph support from Andy Piper -- glyph redisplay improvements from Andy Piper -- color cells allocation fix from Lee Kindness -- recover file fix for windows nt -- mingw install fix from Craig Lanning -- recognize keypad keys under MS-Windows from Jonathan Harris -- Switch gui dialogs to native widgets from Andy Piper -- fixes from Yoshiki Hayashi and Norbert Koch From owner-xemacs-beta@xemacs.org Thu Nov 11 03:22:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA23128 for xemacs-beta-out; Thu, 11 Nov 1999 03:22:04 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA23120 for ; Thu, 11 Nov 1999 03:22:01 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11lpUV-0004yg-00 for ; Thu, 11 Nov 1999 09:21:59 +0100 To: XEmacs Beta List Subject: Re: Yes, Virginia, that is really XEmacs 21.2.20 on the FTP site References: <19991110120220.A26076@xemacs.org> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 11 Nov 1999 09:21:59 +0100 In-Reply-To: Jason R Mastaler's message of "Wed, 10 Nov 1999 12:02:20 -0500" Message-ID: <9t9g0ydmo9k.fsf@mraz.iskon.hr> Lines: 21 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jason R Mastaler writes: > SL Baur writes: > > > I'll make a regular announcement over xemacs-announce tomorrow. > > Actually, please don't. Remember, since all xemacs-announce > messages will also go to both the xemacs (comp.emacs.xemacs) and > xemacs-beta lists, we decided it would be best to send Beta related > messages to xemacs-beta only, and continue to send all other > announcements to xemacs-announce. When xemacs-announce was started, we agreed that the beta announcements *will* go to the announce list. Even in the "worst" case of having weekly betas, the announce list would still be low-traffic. This is, for instance, how the Gnus announce list operates. I agree that the beta announcements shouldn't be forwarded to c.e.x. Maybe a filter should filter out the announcements with the word "beta" in the subject? From owner-xemacs-beta@xemacs.org Thu Nov 11 04:49:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA24599 for xemacs-beta-out; Thu, 11 Nov 1999 04:49:34 -0500 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA24587 for ; Thu, 11 Nov 1999 04:49:25 -0500 From: ALTMARK@de.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA289792 for ; Thu, 11 Nov 1999 10:49:11 +0100 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA24926 for ; Thu, 11 Nov 1999 10:49:12 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256826.0035F043 ; Thu, 11 Nov 1999 10:49:09 +0100 X-Lotus-FromDomain: IBMDE To: xemacs-beta@xemacs.org Message-ID: Date: Thu, 11 Nov 1999 10:34:50 +0100 Subject: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --text follows this line-- This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta20) "Yoko" [Lucid] (rs6000-ibm-aix4.3.2.0) of Wed Nov 10 1999 on pdw22.boeblingen.de.ibm.com configured using `configure rs6000-ibm-aix4.3.2.0 --site-includes=/afs/bb/rs_aix43/usr/local/include --site-libraries=/afs/bb/rs_aix43/usr/local/lib --compiler=cc '--cflags=-O -qmaxmem=-1 -I/usr/include/Motif1.2 /usr/lpp/X11/lib/R6/Motif1.2/Xm12.imp /usr/lpp/X11/lib/R6/Motif1.2/Mrm12.imp' --debug=no --error-checking=none --prefix=/afs/bb/u/altmark/rs_aix43/xemacs --with-jpeg' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Actions: 1. Started Xemacs: xemacs -vanilla & 2. Load any file, e.g. ~/.Xdefaults 3. Press the key (i.e. `next') which runs `scroll-up-command' or issue `M-x scroll-up RET' 4. The text does not scroll. Notes: 1. Jumping to the end of the buffer using `C-end' or `M-x end-of-buffer' works. 2. Scrolling down (e.g. from the end of the buffer) pressing the key or via `M-x scroll-down RET is ok. 3. Scrolling up and down dragging the scrollbar's slider also works, but if I click on the area of the scrollbar *below* the slider, the slider does not move down (and does not scroll the text). Clicking above the slider (e.g. when at the end of the buffer) works as expected. 4. As far as I can remember, I had the same effect with 21.2-b19 "Sneaky Bastard 19991102" a few days ago, but that one and b20 should be quite similar, right? Output of `M-x describe-installation': uname -a: AIX pdw22 3 4 009621754C00 ./configure 'rs6000-ibm-aix4.3.2.0' '--site-includes=/afs/bb/rs_aix43/usr/local/include' '--site-libraries=/afs/bb/rs_aix43/usr/local/lib' '--compiler=cc' '--cflags=-O -qmaxmem=-1 -I/usr/include/Motif1.2 /usr/lpp/X11/lib/R6/Motif1.2/Xm12.imp /usr/lpp/X11/lib/R6/Motif1.2/Mrm12.imp' '--debug=no' '--error-checking=none' '--prefix=/afs/bb/u/altmark/rs_aix43/xemacs' '--with-jpeg' XEmacs 21.2-b20 "Yoko" configured for `rs6000-ibm-aix4.3.2.0'. Where should the build process find the source code? /afs/bb/u/altmark/tools/xemacs/xemacs-21.2/build/xemacs What installation prefix should install use? /afs/bb/u/altmark/rs_aix43/xemacs What operating system and machine description files should XEmacs use? `s/aix4-2.h' and `m/ibmrs6000.h' What compiler should XEmacs be built with? cc_r -O -qmaxmem=-1 -I/usr/include/Motif1.2 /usr/lpp/X11/lib/R6/Motif1.2/Xm12.imp /usr/lpp/X11/lib/R6/Motif1.2/Mrm12.imp Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include Where do we find X Windows libraries? /usr/dt/lib Additional header files: /afs/bb/rs_aix43/usr/local/include Additional libraries: /afs/bb/rs_aix43/usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for DBM. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. *WARNING* The Motif dialog boxes cause problems on AIX 4.3 and higher. We recommend using the Athena dialog boxes instead. Install libXaw and re-run configure with --with-dialogs='athena'. Read the PROBLEMS file for more information. movemail will use "lockf" for locking mail spool files. Recent keystrokes: C-x C-f . X d e f a u l t s RET next ESC x s c r o l l - u p RET misc-user Recent messages (most recent first): Parsing /afs/bb/u/altmark/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading xrdb-mode...done Loading xrdb-mode... Loading efs-cu...done Loading efs-cu... --- Markus Alt IBM Laboratory Boeblingen, Germany From owner-xemacs-beta@xemacs.org Thu Nov 11 04:51:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA24648 for xemacs-beta-out; Thu, 11 Nov 1999 04:51:03 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA24641 for ; Thu, 11 Nov 1999 04:50:53 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id KAA07648 for xemacs-beta@xemacs.org; Thu, 11 Nov 1999 10:50:52 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11lqs7-0001Kx-00 for xemacs-beta@xemacs.org; Thu, 11 Nov 1999 10:50:27 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id A2E0718BA; Thu, 11 Nov 1999 10:50:26 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Package Numbers From: Andreas Jaeger Date: 11 Nov 1999 10:50:26 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.07009801 (Pterodactyl Gnus v0.98.1) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: What's the philosophy behind the numbering scheme for packages? I guess the number should get increased for each release if anything has changed. Or are their more sophisticated rules when (and when not) to increase a package? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Thu Nov 11 04:57:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA24924 for xemacs-beta-out; Thu, 11 Nov 1999 04:57:02 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA24919 for ; Thu, 11 Nov 1999 04:57:00 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 37D7549E for ; Tue, 9 Nov 1999 19:10:11 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id TAA18382; Tue, 9 Nov 1999 19:10:04 +0100 To: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 09 Nov 1999 19:10:04 +0100 In-Reply-To: Jan Vroonhof's message of "09 Nov 1999 18:11:59 +0100" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id EAA24920 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Jan> I propose that it should (by default) always use dotlocking (even Jan> together with any other method). >> >> I don't believe that's a good idea: Locking would no longer be atomic, >> and you can get deadlocks that way. Jan> Not if everybody acquires the locks in the same order. Which is indeed Jan> the case. What's the order? And why is this the case? Is there a standard or agreement on this? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Nov 11 05:03:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25261 for xemacs-beta-out; Thu, 11 Nov 1999 05:03:49 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25256 for ; Thu, 11 Nov 1999 05:03:47 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA24257; Thu, 11 Nov 1999 11:03:45 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005ux; Thu Nov 11 11:03:38 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA28250; Thu, 11 Nov 1999 11:03:37 +0100 To: Andreas Jaeger Cc: xemacs-beta@xemacs.org Subject: Re: Package Numbers References: From: Jan Vroonhof Date: 11 Nov 1999 11:03:36 +0100 In-Reply-To: Andreas Jaeger's message of "11 Nov 1999 10:50:26 +0100" Message-ID: Lines: 8 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > I guess the number should get increased for each release if anything > has changed. I think this all there is too it. Jan From owner-xemacs-beta@xemacs.org Thu Nov 11 05:03:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25285 for xemacs-beta-out; Thu, 11 Nov 1999 05:03:58 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25253; Thu, 11 Nov 1999 05:03:44 -0500 Received: by avon.delcam.com; Thu, 11 Nov 1999 10:02:34 GMT Received: by pat.delcam.com; Thu, 11 Nov 1999 10:03:34 GMT Received: by dr2.delcam.com; Thu, 11 Nov 1999 10:03:36 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14378.38008.41663.157166@pub.news.uk.psi.net> Date: Thu, 11 Nov 1999 10:03:36 +0000 (GMT) To: Jan Vroonhof Cc: Paul Bibilo , xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 In-Reply-To: Jan Vroonhof's messaage of 10 November 1999 18:03:30 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> X-Mailer: VM 6.71 under 21.2 (beta20) "Yoko" XEmacs Lucid X-Face: "+N/{>9S5,OIk<0$%[)LGd} Jan Vroonhof writes: > Paul Bibilo writes: > > > It fails as follows: > > > Dumping under the name xemacs > > Testing for Lisp shadows ... > > make[1]: execve: ./xemacs: No such file or directory > > make[1]: *** [xemacs] Error 127 > > make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' > > make: *** [src] Error 1 > > This is not failure this is success :-). The pdump'er doesn't produce > xemacs it produces an xemacs.dmp file > > Start "./temacs" and it will see the xemacs.dmp file is there and load > it. > OK, I tried this and it does seem to work. If I start temacs from any other directory than src then I get a "temacs can only be run in -batch mode" message. Surely end users aren't expected to work like this ? -- Paul From owner-xemacs-beta@xemacs.org Thu Nov 11 05:09:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25432 for xemacs-beta-out; Thu, 11 Nov 1999 05:09:32 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25429 for ; Thu, 11 Nov 1999 05:09:30 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA24465; Thu, 11 Nov 1999 11:09:26 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005yF; Thu Nov 11 11:09:24 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA28285; Thu, 11 Nov 1999 11:09:23 +0100 To: ALTMARK@de.ibm.com Cc: xemacs-beta@xemacs.org Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) References: From: Jan Vroonhof Date: 11 Nov 1999 11:09:22 +0100 In-Reply-To: ALTMARK@de.ibm.com's message of "Thu, 11 Nov 1999 10:34:50 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: ALTMARK@de.ibm.com writes: > 1. Started Xemacs: xemacs -vanilla & > 2. Load any file, e.g. ~/.Xdefaults > 3. Press the key (i.e. `next') which runs > `scroll-up-command' or issue `M-x scroll-up RET' > 4. The text does not scroll. It works for me (If I load a file which is actually larger than will fit the window). There seem to be some very weird bugs in the recent betas. Jan From owner-xemacs-beta@xemacs.org Thu Nov 11 05:13:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25482 for xemacs-beta-out; Thu, 11 Nov 1999 05:13:55 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25479 for ; Thu, 11 Nov 1999 05:13:51 -0500 Received: by crystal.WonderWorks.COM id QQhovw18344; Thu, 11 Nov 1999 02:13:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14378.38620.827863.477678@crystal.WonderWorks.COM> Date: Thu, 11 Nov 1999 02:13:48 -0800 (PST) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > ALTMARK@de.ibm.com writes: > > > 1. Started Xemacs: xemacs -vanilla & > > 2. Load any file, e.g. ~/.Xdefaults > > 3. Press the key (i.e. `next') which runs > > `scroll-up-command' or issue `M-x scroll-up RET' > > 4. The text does not scroll. > > It works for me (If I load a file which is actually larger than will > fit the window). > > There seem to be some very weird bugs in the recent betas. Yes, my interest is definitely becoming piqued again. :) From owner-xemacs-beta@xemacs.org Thu Nov 11 05:28:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25921 for xemacs-beta-out; Thu, 11 Nov 1999 05:28:11 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25916 for ; Thu, 11 Nov 1999 05:28:09 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA24873; Thu, 11 Nov 1999 11:28:08 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0064b; Thu Nov 11 11:28:03 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA28334; Thu, 11 Nov 1999 11:28:03 +0100 To: Paul Bibilo Cc: xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> From: Jan Vroonhof Date: 11 Nov 1999 11:28:02 +0100 In-Reply-To: Paul Bibilo's message of "Thu, 11 Nov 1999 10:03:36 +0000 (GMT)" Message-ID: Lines: 19 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Paul Bibilo writes: > > Start "./temacs" and it will see the xemacs.dmp file is there and load > > it. > > > OK, I tried this and it does seem to work. Be Positive! Feel proud! You have just had the first obscure dumping problem that the pdumper "fixed"! > If I start temacs from any > other directory than src then I get a "temacs can only be run in > -batch mode" message. > > Surely end users aren't expected to work like this ? Of course not. This is why this is a development version. Jan From owner-xemacs-beta@xemacs.org Thu Nov 11 05:34:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA26141 for xemacs-beta-out; Thu, 11 Nov 1999 05:34:27 -0500 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA26133 for ; Thu, 11 Nov 1999 05:34:14 -0500 From: ALTMARK@de.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA245434; Thu, 11 Nov 1999 11:34:10 +0100 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA24178; Thu, 11 Nov 1999 11:34:09 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256826.003A08BB ; Thu, 11 Nov 1999 11:33:53 +0100 X-Lotus-FromDomain: IBMDE To: Jan Vroonhof cc: xemacs-beta@xemacs.org Message-ID: Date: Thu, 11 Nov 1999 11:33:18 +0100 Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On my Linux build of 21.2-b20, it works, too. But on AIX, I see this strange behaviour which is quite annoying as scrolling should be considered one of your 'basic rights' in an editor ... :-( Markus --- Markus Alt IBM Laboratory Boeblingen, Germany Jan Vroonhof on 11/11/99 11:09:22 AM Please respond to Jan Vroonhof To: Markus Alt/Germany/IBM@IBMDE cc: xemacs-beta@xemacs.org Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) ALTMARK@de.ibm.com writes: > 1. Started Xemacs: xemacs -vanilla & > 2. Load any file, e.g. ~/.Xdefaults > 3. Press the key (i.e. `next') which runs > `scroll-up-command' or issue `M-x scroll-up RET' > 4. The text does not scroll. It works for me (If I load a file which is actually larger than will fit the window). There seem to be some very weird bugs in the recent betas. Jan From owner-xemacs-beta@xemacs.org Thu Nov 11 08:00:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA29985 for xemacs-beta-out; Thu, 11 Nov 1999 08:00:51 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA29981 for ; Thu, 11 Nov 1999 08:00:48 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11ltqE-0006Of-00 for ; Thu, 11 Nov 1999 14:00:42 +0100 To: XEmacs Beta List Subject: Re: [Failure] 21.2.20 under IRIX 6.2 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 11 Nov 1999 14:00:41 +0100 In-Reply-To: Jan Vroonhof's message of "11 Nov 1999 11:28:02 +0100" Message-ID: <9t99045qj2e.fsf@mraz.iskon.hr> Lines: 17 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Paul Bibilo writes: > > > > Start "./temacs" and it will see the xemacs.dmp file is there and load > > > it. > > > > > OK, I tried this and it does seem to work. > > Be Positive! Feel proud! You have just had the first obscure dumping > problem that the pdumper "fixed"! Provided it really is a dumping bug. No offense intended, but I'm always sceptic to that kind of "bug-fixing" where you change your configuration and the bug disappears. If you're sure it's a dumping bug, great. But for all I know, it could as well be a weird memory corruption/gc/whatever bug that --pdump merely sweeps under the rug. From owner-xemacs-beta@xemacs.org Thu Nov 11 08:21:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA30440 for xemacs-beta-out; Thu, 11 Nov 1999 08:21:53 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA30435 for ; Thu, 11 Nov 1999 08:21:49 -0500 Received: by localhost id m11luAc-00016LC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 11 Nov 1999 22:21:46 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14378.49898.168130.299052@turnbull.sk.tsukuba.ac.jp> Date: Thu, 11 Nov 1999 22:21:46 +0900 (JST) To: XEmacs Beta List Subject: `make beta': what it does and doesn't do X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ought to be in etc/BETA. And useful targets for things it doesn't do. In particular, `make info'. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 11 08:32:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA30732 for xemacs-beta-out; Thu, 11 Nov 1999 08:32:46 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA30729 for ; Thu, 11 Nov 1999 08:32:42 -0500 Received: by localhost id m11luLB-00016LC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 11 Nov 1999 22:32:41 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14378.50553.534328.478864@turnbull.sk.tsukuba.ac.jp> Date: Thu, 11 Nov 1999 22:32:41 +0900 (JST) To: XEmacs Beta List Subject: `make info' on 21.2.20 generates a bunch of warnings In-Reply-To: <9t99045qj2e.fsf@mraz.iskon.hr> References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> <9t99045qj2e.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Is this normal? If so, should make generate an "expect warnings like this" comment? Typical examples (there were a couple hundred altogether, I guess): ./objects.texi:1547: warning: @sc argument all uppercase, thus no effect. ./custom1.texi:172: warning: unlikely character ( in @var. Debian potato, current as of about this week. GNU makeinfo 4.0. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 11 10:45:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA02166 for xemacs-beta-out; Thu, 11 Nov 1999 10:45:32 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA02162 for ; Thu, 11 Nov 1999 10:45:30 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11lwPg-0006TS-00 for ; Thu, 11 Nov 1999 16:45:28 +0100 To: XEmacs Beta List Subject: Re: `make info' on 21.2.20 generates a bunch of warnings References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> <9t99045qj2e.fsf@mraz.iskon.hr> <14378.50553.534328.478864@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 11 Nov 1999 16:45:28 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 11 Nov 1999 22:32:41 +0900 (JST)" Message-ID: <9t9r9hxniav.fsf@mraz.iskon.hr> Lines: 7 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Is this normal? Most of them are not normal; our documentation should be fixed. (There are exceptions, though.) From owner-xemacs-beta@xemacs.org Thu Nov 11 12:24:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA05408 for xemacs-beta-out; Thu, 11 Nov 1999 12:24:49 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA05402 for ; Thu, 11 Nov 1999 12:24:44 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA17425; Thu, 11 Nov 1999 18:24:38 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004G6; Thu Nov 11 18:24:34 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA29629; Thu, 11 Nov 1999 18:24:34 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: [Failure] 21.2.20 under IRIX 6.2 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> Date: 11 Nov 1999 18:24:33 +0100 In-Reply-To: Hrvoje Niksic's message of "11 Nov 1999 14:00:41 +0100" Message-ID: Lines: 17 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > > Be Positive! Feel proud! You have just had the first obscure dumping > > problem that the pdumper "fixed"! > > Provided it really is a dumping bug. He this is IRIX, it must be a dumping bug :-) > No offense intended, but I'm always sceptic to that kind of > "bug-fixing" where you change your configuration and the bug > disappears. Of course, that is why I wrote the quotes in "fixed". Note that if it worked before it could very well be the pdump changes that broke it. Jan From owner-xemacs-beta@xemacs.org Thu Nov 11 18:24:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA19106 for xemacs-beta-out; Thu, 11 Nov 1999 18:24:24 -0500 Received: from mail.dycon.com (samuel.dycon.com [12.13.144.15]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA19102 for ; Thu, 11 Nov 1999 18:24:21 -0500 Received: (qmail 6779 invoked from network); 11 Nov 1999 23:28:40 -0000 Received: from p4m47.dycon.net (HELO craig) (12.13.145.247) by samuel.dycon.com with SMTP; 11 Nov 1999 23:28:40 -0000 Message-Id: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> X-Sender: craigl@mail.dycon.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 11 Nov 1999 18:21:13 -0500 To: xemacs-beta@xemacs.org From: Craig Lanning Subject: Re: XEmacs 21.2.20 "Yoko" is released In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 02:47 PM 11/11/99 +0900, SL Baur wrote: >Get it from the usual places: > ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ > http://cvs.xemacs.org/ > > ... > > > >to 21.2.20 "Yoko" > ... >-- mingw install fix from Craig Lanning I think that I should point out that, while I submitted a patch for this, my patch was rejected. The patch that was accepted was submitted by Andy Piper (I think). Craig From owner-xemacs-beta@xemacs.org Thu Nov 11 21:02:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA23122 for xemacs-beta-out; Thu, 11 Nov 1999 21:02:05 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA23119 for ; Thu, 11 Nov 1999 21:02:03 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id SAA18303; Thu, 11 Nov 1999 18:01:38 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-227.beasys.com [192.168.11.227]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id CAA20801; Fri, 12 Nov 1999 02:01:33 GMT Message-Id: <3.0.5.32.19991112020301.00b05bf0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Nov 1999 02:03:01 +0000 To: Craig Lanning , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: XEmacs 21.2.20 "Yoko" is released In-Reply-To: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 06:21 PM 11/11/99 -0500, Craig Lanning wrote: >>to 21.2.20 "Yoko" >> ... >>-- mingw install fix from Craig Lanning > >I think that I should point out that, while I submitted a patch for this, >my patch was rejected. The patch that was accepted was submitted by Andy >Piper (I think). It was your idea so I credited you with it in CHANGES-beta andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Nov 11 22:05:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA24834 for xemacs-beta-out; Thu, 11 Nov 1999 22:05:56 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA24829 for ; Thu, 11 Nov 1999 22:05:53 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id MAA21044; Fri, 12 Nov 1999 12:04:04 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Package Numbers References: X-Attribution: sb From: SL Baur In-Reply-To: Andreas Jaeger's message of "11 Nov 1999 10:50:26 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 12 Nov 1999 12:04:04 +0900 Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes in xemacs-beta@xemacs.org: > What's the philosophy behind the numbering scheme for packages? . where is alphabetically sortable from 0 to 99. gets incremented any time there is a major incompatible change and should be done sparingly. The numbering was introduced because there are so many different ways authors number their version and I felt that it would be intrusive to insist that version numbers appear in a certain format (or to force version numbers at all, for that matter). > I guess the number should get increased for each release if anything > has changed. No. The number has to change every time a new release is made because the MD5 hash of the tarball will change and make the package-index file out of date. Keeping the package-index file in synch has been a _major_ problem so far. > Or are their more sophisticated rules when (and when not) to increase > a package? The number increases every time a new tarball is created to put in the packages/ directory on ftp.xemacs.org. Please feel free to direct any other questions you might have about the numbering to me. From owner-xemacs-beta@xemacs.org Thu Nov 11 22:39:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA25751 for xemacs-beta-out; Thu, 11 Nov 1999 22:39:38 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA25748 for ; Thu, 11 Nov 1999 22:39:35 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id MAA21086; Fri, 12 Nov 1999 12:37:47 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `make beta': what it does and doesn't do References: <14378.49898.168130.299052@turnbull.sk.tsukuba.ac.jp> X-Attribution: sb From: SL Baur In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 11 Nov 1999 22:21:46 +0900 (JST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 12 Nov 1999 12:37:47 +0900 Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stephen J Turnbull writes in xemacs-beta@xemacs.org: > Ought to be in etc/BETA. And useful targets for things it doesn't > do. In particular, `make info'. Hmm. That's a bug in `make beta'. As I understood it, `make beta' is supposed to work like `make World' in X11 -- rebuild everything from scratch. `make beta' is probably obsolete now, though. It's original purpose was to make it easier to apply beta upgrade patches. That really isn't necessary now that source file dependencies are computed rather than hand done and the amount of code/documentation has been greatly streamlined. From owner-xemacs-beta@xemacs.org Thu Nov 11 22:41:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA25852 for xemacs-beta-out; Thu, 11 Nov 1999 22:41:53 -0500 Received: from home.plutonium.net (home.plutonium.net [205.216.126.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA25848 for ; Thu, 11 Nov 1999 22:41:51 -0500 Received: from dogbert (skaro.limolink.com [205.216.126.26]) by home.plutonium.net (8.8.7/8.8.6) with SMTP id VAA32649; Thu, 11 Nov 1999 21:42:46 -0600 Message-ID: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> From: "James N. Potts" To: "Darryl Okahata" Cc: "XEmacs Beta Mailing List" Subject: Re: spam from mailing list Date: Thu, 11 Nov 1999 21:40:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I administer sendmail for my domain, so I can certainly block it there. But the point is, if it's going to be blocked at the MTA level, it might as well be blocked _once_ at the origin of the mailing list (gwyn.tux.org) rather than at the hundreds of MTAs that receive the list. -Jim Darryl Okahata wrote: >"James N. Potts" wrote: > >> I'm getting a little tired of the "laser printer toner advertisement" spam >> from the mailing list. Can't these be filtered out (if not at the majordomo >> level, then at the MT level)? > > Use a spam filter (I'm using one). For more information, see: > > http://www.ecofuture.org/ecofuture/jmemail.html#efilters > >[ Oh, sorry. ;-( I just noticed that you're using a PC mail program. > Unfortunately, filtering on a PC is non-trivial, and generally costs > $$$ (unlike Unix). ] > >-- > Darryl Okahata > darrylo@sr.hp.com > >DISCLAIMER: this message is the author's personal opinion and does not >constitute the support, opinion, or policy of Agilent Technologies, or >of the little green men that have been following him all day. > From owner-xemacs-beta@xemacs.org Fri Nov 12 01:28:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA31081 for xemacs-beta-out; Fri, 12 Nov 1999 01:28:16 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA31078 for ; Fri, 12 Nov 1999 01:28:10 -0500 Received: by crystal.WonderWorks.COM id QQhoyz12309; Thu, 11 Nov 1999 22:28:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14379.45942.961076.644324@crystal.WonderWorks.COM> Date: Thu, 11 Nov 1999 22:28:06 -0800 (PST) From: Kyle Jones To: "XEmacs Beta Mailing List" Subject: Re: spam from mailing list In-Reply-To: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: James N. Potts writes: > I administer sendmail for my domain, so I can certainly block > it there. But the point is, if it's going to be blocked at > the MTA level, it might as well be blocked _once_ at the > origin of the mailing list (gwyn.tux.org) rather than at the > hundreds of MTAs that receive the list. The spam blocking tools all have the same problem: they also block legitimate messages, which is no good for a mailing list. The usual course of action for mailing lists is to allow posts only from subscribers. That's the way to go, if we care that much. Me, I've gotten used to the spam and can filter it mentally pretty effectively at this point. From owner-xemacs-beta@xemacs.org Fri Nov 12 02:51:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA32545 for xemacs-beta-out; Fri, 12 Nov 1999 02:51:44 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA32541 for ; Fri, 12 Nov 1999 02:51:40 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 07A2B49E for ; Fri, 12 Nov 1999 08:51:39 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id IAA26894; Fri, 12 Nov 1999 08:51:22 +0100 To: xemacs-beta@xemacs.org Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 12 Nov 1999 08:51:22 +0100 In-Reply-To: ALTMARK@de.ibm.com's message of "Thu, 11 Nov 1999 11:33:18 +0100" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA32543 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "MA" == ALTMARK writes: MA> On my Linux build of 21.2-b20, it works, too. But on AIX, I see this strange MA> behaviour which is quite annoying as scrolling should be considered one of your MA> 'basic rights' in an editor ... :-( Motif fuckage? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Fri Nov 12 02:55:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA32645 for xemacs-beta-out; Fri, 12 Nov 1999 02:55:01 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA32642 for ; Fri, 12 Nov 1999 02:54:59 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4099949E for ; Fri, 12 Nov 1999 08:54:52 +0100 (NFT) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id IAA14824; Fri, 12 Nov 1999 08:54:45 +0100 To: xemacs-beta@xemacs.org Subject: Re: `make beta': what it does and doesn't do References: <14378.49898.168130.299052@turnbull.sk.tsukuba.ac.jp> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 12 Nov 1999 08:54:45 +0100 In-Reply-To: SL Baur's message of "12 Nov 1999 12:37:47 +0900" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA32643 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Stephen J Turnbull writes in xemacs-beta@xemacs.org: >> Ought to be in etc/BETA. And useful targets for things it doesn't >> do. In particular, `make info'. sb> Hmm. That's a bug in `make beta'. As I understood it, `make beta' is sb> supposed to work like `make World' in X11 -- rebuild everything from sb> scratch. sb> `make beta' is probably obsolete now, though. No! Some changes (e.g. in Lisp object representation) don't get caught by just `make'. I've been bitten by that pretty recently. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Fri Nov 12 03:17:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA00996 for xemacs-beta-out; Fri, 12 Nov 1999 03:17:16 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA00992 for ; Fri, 12 Nov 1999 03:17:14 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11mBtQ-0008GW-00; Fri, 12 Nov 1999 09:17:12 +0100 To: XEmacs Beta List , Yoshiki Hayashi Subject: Char-related crashes (hopefully) fixed X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 12 Nov 1999 09:17:12 +0100 In-Reply-To: Yoshiki Hayashi's message of "10 Nov 1999 12:28:54 +0900" Message-ID: <9t9ogd0dszb.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: [...] After applying two of Yoshiki's patches, the crashes are gone. Cool. I'll submit my `test-chars' functions as a test case for the automated test-suite. As Ben said, now that we've fixed the actual bugs, we can think about changing the behaviour for int-char conversions for 21.2. From owner-xemacs-beta@xemacs.org Fri Nov 12 03:57:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA02147 for xemacs-beta-out; Fri, 12 Nov 1999 03:57:35 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA02144 for ; Fri, 12 Nov 1999 03:57:32 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11mCWR-0008Id-00 for ; Fri, 12 Nov 1999 09:57:31 +0100 To: XEmacs Beta List Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 12 Nov 1999 09:57:31 +0100 In-Reply-To: Kyle Jones's message of "Thu, 11 Nov 1999 22:28:06 -0800 (PST)" Message-ID: <9t9g0ycdr44.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > The usual course of action for mailing lists is to allow posts only > from subscribers. That's the way to go, if we care that much. I, for one, don't care that much. Like with spam filter, the problem with disallowing non-subscriber messages is that legitimate messages also get blocked. We've often had discussions that involved non-subscribers in Cc, and I consider it a very useful feature. From owner-xemacs-beta@xemacs.org Fri Nov 12 04:54:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA03896 for xemacs-beta-out; Fri, 12 Nov 1999 04:54:37 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA03891 for ; Fri, 12 Nov 1999 04:54:33 -0500 Received: by avon.delcam.com; Fri, 12 Nov 1999 09:53:40 GMT Received: by pat.delcam.com; Fri, 12 Nov 1999 09:54:43 GMT Received: by dr2.delcam.com; Fri, 12 Nov 1999 09:54:42 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14379.58337.910446.326906@pub.news.uk.psi.net> Date: Fri, 12 Nov 1999 09:54:41 +0000 (GMT) To: xemacs-beta@xemacs.org Subject: Re: [Failure] 21.2.20 under IRIX 6.2 In-Reply-To: Jan Vroonhof's messaage of 11 November 1999 18:24:33 References: <14377.29626.83861.397556@pub.news.uk.psi.net> <14377.36468.816633.95689@pub.news.uk.psi.net> <14378.38008.41663.157166@pub.news.uk.psi.net> X-Mailer: VM 6.71 under 21.2 (beta20) "Yoko" XEmacs Lucid X-Face: "+N/{>9S5,OIk<0$%[)LGd} Jan Vroonhof writes: > Hrvoje Niksic writes: > > > > Be Positive! Feel proud! You have just had the first obscure dumping > > > problem that the pdumper "fixed"! > > > > Provided it really is a dumping bug. > > He this is IRIX, it must be a dumping bug :-) > You may say that, but over quite a few years building beta versions of XEmacs on IRIX machines, I've only had dumping problems once or twice. > > No offense intended, but I'm always sceptic to that kind of > > "bug-fixing" where you change your configuration and the bug > > disappears. > > Of course, that is why I wrote the quotes in "fixed". Note that if it > worked before it could very well be the pdump changes that broke it. > I'd be surprised if it isn't to do with this, as up until the b19 version of a week or so ago, I haven't had any problems building. -- Paul From owner-xemacs-beta@xemacs.org Fri Nov 12 05:16:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04432 for xemacs-beta-out; Fri, 12 Nov 1999 05:16:34 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA04426 for ; Fri, 12 Nov 1999 05:16:30 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id FAA29250; Fri, 12 Nov 1999 05:23:29 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id LAA22063; Fri, 12 Nov 1999 11:16:17 +0100 (MET) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> <9t9g0ycdr44.fsf@mraz.iskon.hr> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 12 Nov 1999 11:13:33 +0100 In-Reply-To: Hrvoje Niksic's message of "12 Nov 1999 09:57:31 +0100" Message-ID: Lines: 16 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Kyle Jones writes: >> The usual course of action for mailing lists is to allow posts only >> from subscribers. That's the way to go, if we care that much. Hrvoje> I, for one, don't care that much. Like with spam filter, Hrvoje> the problem with disallowing non-subscriber messages is Hrvoje> that legitimate messages also get blocked. We've often Hrvoje> had discussions that involved non-subscribers in Cc, and I Hrvoje> consider it a very useful feature. But Kyle's suggestion to "allow posts only from subscribers" sounds like a very good one, doesn't it? Adrian From owner-xemacs-beta@xemacs.org Fri Nov 12 05:36:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04970 for xemacs-beta-out; Fri, 12 Nov 1999 05:36:54 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA04965 for ; Fri, 12 Nov 1999 05:36:51 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11mDrj-00009k-00; Fri, 12 Nov 1999 11:23:35 +0100 To: Adrian Aichner Cc: XEmacs Beta List Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> <9t9g0ycdr44.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 12 Nov 1999 11:23:35 +0100 In-Reply-To: Adrian Aichner's message of "12 Nov 1999 11:13:33 +0100" Message-ID: <9t93ducdn4o.fsf@mraz.iskon.hr> Lines: 18 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Kyle Jones writes: > >> The usual course of action for mailing lists is to allow posts only > >> from subscribers. That's the way to go, if we care that much. > > Hrvoje> I, for one, don't care that much. Like with spam filter, > Hrvoje> the problem with disallowing non-subscriber messages is > Hrvoje> that legitimate messages also get blocked. We've often > Hrvoje> had discussions that involved non-subscribers in Cc, and I > Hrvoje> consider it a very useful feature. > > But Kyle's suggestion to "allow posts only from subscribers" sounds > like a very good one, doesn't it? Not to me, for the reasons quoted above. From owner-xemacs-beta@xemacs.org Fri Nov 12 06:10:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA05494 for xemacs-beta-out; Fri, 12 Nov 1999 06:10:58 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA05491 for ; Fri, 12 Nov 1999 06:10:56 -0500 Received: from 666.com (dialup09ip002.tus.azstarnet.com [169.197.34.2]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id EAA29333 for ; Fri, 12 Nov 1999 04:10:53 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <382BF574.D345981A@666.com> Date: Fri, 12 Nov 1999 04:09:41 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs beta list Subject: [Fwd: xemacs-question] Content-Type: multipart/mixed; boundary="------------710F25BDFD0C9CDE7EEBCF6E" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a multi-part message in MIME format. --------------710F25BDFD0C9CDE7EEBCF6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------710F25BDFD0C9CDE7EEBCF6E Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Return-Path: wing@netcom.com Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.13]) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id XAA02383 for <666-ben@pplus.shell5.ba.best.com>; Mon, 25 Oct 1999 23:38:03 -0700 (PDT) Received: from mail3.netcom.com (wing@mail3.netcom.com [199.183.9.133]) by proxy3.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id XAA14532 for ; Mon, 25 Oct 1999 23:37:43 -0700 (PDT) Received: (from wing@localhost) by mail3.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id XAA08263 for ben@666.com; Mon, 25 Oct 1999 23:37:33 -0700 (PDT) Received: from piggy.mdstud.chalmers.se (piggy.mdstud.chalmers.se [129.16.234.10]) by mail3.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) with ESMTP id XAA08256 for ; Mon, 25 Oct 1999 23:37:31 -0700 (PDT) Received: from fraggel32.mdstud.chalmers.se (fraggel32.mdstud.chalmers.se [129.16.235.162]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id IAA13938; Tue, 26 Oct 1999 08:33:57 +0200 (MET DST) Received: from localhost (md5hb@localhost) by fraggel32.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id IAA24046; Tue, 26 Oct 1999 08:33:57 +0200 (MET DST) X-Authentication-Warning: fraggel32.mdstud.chalmers.se: md5hb owned process doing -bs Date: Tue, 26 Oct 1999 08:33:57 +0200 (MET DST) From: =?ISO-8859-1?Q?H=E5kan_Berggren?= To: wing@netcom.com, cthomp@cs.uiuc.edu, rossini@stat.sc.edu Subject: xemacs-question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Mozilla-Status2: 00000000 Hi! I hope you can answer my question, or pass me to someone who might answer it. I'm using xemacs as my texteditor when coding programs. My problem is: I type the sam code very often, i.e. when programming c: #include I have seen someone doing like this: #i and then hitting space, and the result is #include . It works for me when coding Java with the following entered in .emacs: (custom-set-variables '(jde-global-classpath (quote ("/u/eramicl/Java/SDE/" "/proj/smas_n/newsce/JDK1.2-RI/jdk1.2/src.jar"))) '(jde-mode-abbreviations (quote (("ab" . "abstract") ("bo" . "boolean") ("boo" . "boolean") ("br" . "break;") ("by" . "byte") ("byv" . "byvalue") ("cas" . "cast") ("ca" . "catch") ("ch" . "char") ("cl" . "class") ("co" . "const") ("con" . "continue") ("def" . "default") ("dou" . "double") ("el" . "else") ("ex" . "extends") ("ext" . "extends") ("fa" . "false") ("fal" . "false") ("fi" . "final") ("fin" . "finally") ("fl" . "float") ("fo" . "for") ("fu" . "future") ("ge" . "generic") ("gen" . "generic") ("go" . "goto") ("im" . "import") ("imp" . "import") ("impo" . "import") ("impl" . "implements") ("ins" . "instanceof") ("inte" . "interface") ("lo" . "long") ("na" . "native") ("ne" . "new") ("nu" . "null") ("pa" . "package") ("pr" . "private") ("pri" . "private") ("pro" . "protected") ("pu" . "public") ("pub" . "public") ("re" . "return") ("ret" . "return") ("sh" . "short") ("st" . "static") ("str" . "String") ("su" . "super") ("sw" . "switch") ("sy" . "System.out.print (\" \"); System.out.flush ();") ("syn" . "synchronized") ("sync" . "synchronized") ("th" . "this") ("thr" . "throw") ("tra" . "transient") ("tr" . "true") ("vo" . "void") ("vol" . "volatile") ("wh" . "while") ("sys" . "System.out.println (\" \");") ("main" . "public static void main (String[] argv) {") ("i:swing" . "import javax.swing.*;") ("p:sde" . "package se.ericsson.sde") ("i:sde" . "import se.ericsson.sde") ("p:ctwidgets" . "package se.ericsson.sde.ctwidgets") ("p:ctw" . "package se.ericsson.sde.ctwidgets") ("p:util" . "package se.ericsson.sde.util;") ("i:ctwidgets" . "import se.ericsson.sde.ctwidgets.*;") ("i:ctw" . "import se.ericsson.sde.ctwidgets.*;") ("i:util" . "import se.ericsson.sde.util.*;")))) '(jde-enable-abbrev-mode t) '(user-mail-address "md5hb@mdstud.chalmers.se" t) '(query-user-mail-address nil)) (custom-set-faces) But how can I fix this for all modes? I would be very thankful if You can help me! Thanks in advance /Håkan md5hb@mdstud.chalmers.se --------------710F25BDFD0C9CDE7EEBCF6E-- From owner-xemacs-beta@xemacs.org Fri Nov 12 06:45:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA06331 for xemacs-beta-out; Fri, 12 Nov 1999 06:45:51 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA06327; Fri, 12 Nov 1999 06:45:49 -0500 Received: from 666.com (dialup09ip002.tus.azstarnet.com [169.197.34.2]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id EAA01440; Fri, 12 Nov 1999 04:45:46 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <382BFDCC.3D44080C@666.com> Date: Fri, 12 Nov 1999 04:45:16 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs MULE , XEmacs beta list , ", Noor Dawod" Subject: [Fwd: fonts for X] Content-Type: multipart/mixed; boundary="------------083C3D2D95EC2AA3B6405E53" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a multi-part message in MIME format. --------------083C3D2D95EC2AA3B6405E53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit better late than never .... --------------083C3D2D95EC2AA3B6405E53 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: wing@netcom.com Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by shell5.ba.best.com (8.9.0/8.9.0/best.sh) with ESMTP id AAA01828 for <666-ben@pplus.shell5.ba.best.com>; Tue, 15 Dec 1998 00:57:12 -0800 (PST) Received: from mail6.netcom.com (wing@mail6.netcom.com [192.100.81.142]) by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with ESMTP id AAA02111 for ; Tue, 15 Dec 1998 00:55:26 -0800 (PST) Received: (from wing@localhost) by mail6.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id AAA03881 for ben@666.com; Tue, 15 Dec 1998 00:55:18 -0800 (PST) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by mail6.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) with ESMTP id AAA03869 for ; Tue, 15 Dec 1998 00:55:15 -0800 (PST) Received: from nvt (nvt.netvision.net.il [194.90.6.14]) by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id KAA07856 for ; Tue, 15 Dec 1998 10:51:17 +0200 (IST) Date: Tue, 15 Dec 1998 10:52:01 +0200 (IST) From: Noor Dawod To: Ben Wing Subject: fonts for X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Ben, I've came into a site at http://SunSITE.sut.ac.jp/pub/archives/packages/xemacs/aux/fonts/ that states that you maintain it. I am sorry if this is not the case, and if it is, I hope you could help me.. I am trying to find a way to convert the Arabic fonts you have there to TrueType fonts files useable in Windows. If you could direct me to a program to do that, I'd be greatly thankful to you. TIA, Noor. --------------083C3D2D95EC2AA3B6405E53-- From owner-xemacs-beta@xemacs.org Fri Nov 12 07:01:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA06858 for xemacs-beta-out; Fri, 12 Nov 1999 07:01:25 -0500 Received: from apollonius.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA06824 for ; Fri, 12 Nov 1999 07:01:13 -0500 Received: from KEATS.eai-delta.de (keats.eai-delta.de [192.9.200.85]) by apollonius.eai-delta.de (8.9.3/8.8.7) with SMTP id NAA05946 for ; Fri, 12 Nov 1999 13:01:09 +0100 To: XEmacs Beta List Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> <9t9g0ycdr44.fsf@mraz.iskon.hr> Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: . Date: 12 Nov 1999 13:01:08 +0100 In-Reply-To: Adrian Aichner's message of "12 Nov 1999 11:13:33 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > But Kyle's suggestion to "allow posts only from subscribers" sounds > like a very good one, doesn't it? That depends on the number of reports we get from people not subscribed to the list. If the ratio other/subscribed is very small, I second this. norbert. From owner-xemacs-beta@xemacs.org Fri Nov 12 07:09:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA07201 for xemacs-beta-out; Fri, 12 Nov 1999 07:09:46 -0500 Received: from rasp.eng.cam.ac.uk (rasp.eng.cam.ac.uk [129.169.8.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA07197 for ; Fri, 12 Nov 1999 07:09:43 -0500 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by rasp.eng.cam.ac.uk with ESMTP id MAA05965 for ; Fri, 12 Nov 1999 12:09:42 GMT Received: from kennet.eng.cam.ac.uk (via kennet [129.169.81.54]) by tigger.eng.cam.ac.uk with ESMTP id MAA01621 for ; Fri, 12 Nov 1999 12:09:40 GMT Received: (via ge204@localhost) by kennet.eng.cam.ac.uk id MAA16043; Fri, 12 Nov 1999 12:09:40 GMT To: XEmacs Developers Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> <9t9g0ycdr44.fsf@mraz.iskon.hr> From: Gunnar Evermann In-Reply-To: Adrian Aichner's message of "12 Nov 1999 11:13:33 +0100" Date: 12 Nov 1999 12:09:40 +0000 Message-ID: Lines: 29 User-Agent: Gnus/5.070092 (Pterodactyl Gnus v0.92) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Kyle Jones writes: > >> The usual course of action for mailing lists is to allow posts only > >> from subscribers. That's the way to go, if we care that much. > > Hrvoje> I, for one, don't care that much. Like with spam filter, > Hrvoje> the problem with disallowing non-subscriber messages is > Hrvoje> that legitimate messages also get blocked. We've often > Hrvoje> had discussions that involved non-subscribers in Cc, and I > Hrvoje> consider it a very useful feature. > > But Kyle's suggestion to "allow posts only from subscribers" sounds > like a very good one, doesn't it? No, not at all. Some of the discussions Hrvoje is referring to were initiated by post from non-subscribers to xemacs-beta. Personally I can live with the spam on the xemacs lists, I think Jason is doing a good job filtering most of it. I complained to the laser-toner advertiser's ISP a couple of times when they spammed the XEmacs BTS but never heard back. Maybe Jason can tighten the filter @xemacs.org another notch, but if that's not possible than we should be able to live with that. You can always use procmail or gnus or whatever to get rid of the spam that's left. Gunnar From owner-xemacs-beta@xemacs.org Fri Nov 12 08:33:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA09075 for xemacs-beta-out; Fri, 12 Nov 1999 08:33:42 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA09072 for ; Fri, 12 Nov 1999 08:33:41 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id IAA11833; Fri, 12 Nov 1999 08:40:40 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id OAA22452; Fri, 12 Nov 1999 14:33:27 +0100 (MET) To: Gunnar Evermann Cc: XEmacs Developers Subject: Re: spam from mailing list References: <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> <14379.45942.961076.644324@crystal.WonderWorks.COM> <9t9g0ycdr44.fsf@mraz.iskon.hr> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 12 Nov 1999 14:30:43 +0100 In-Reply-To: Gunnar Evermann's message of "12 Nov 1999 12:09:40 +0000" Message-ID: Lines: 16 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Gunnar" == Gunnar Evermann writes: Gunnar> be able to live with that. You can always use procmail or Gunnar> gnus or whatever to get rid of the spam that's left. I'm not really complaining, all the useless Spam goes to nnml:Spam in my setup, which is effectively filtered by my lower brain. Occasionally nnml:Spam received an interesting mail from an individual missing from my `nnmail-split-fancy', which I swiftly rectify. all-hail-gnus, Adrian Gunnar> Gunnar From owner-xemacs-beta@xemacs.org Fri Nov 12 10:26:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA12759 for xemacs-beta-out; Fri, 12 Nov 1999 10:26:41 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA12754 for ; Fri, 12 Nov 1999 10:26:37 -0500 Received: (qmail 3038 invoked from network); 12 Nov 1999 15:25:14 -0000 Received: from usrpri2-15.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.80) by biff.kiva.net with SMTP; 12 Nov 1999 15:25:14 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id KAA04096; Fri, 12 Nov 1999 10:28:13 -0500 To: xemacs-beta@xemacs.org Subject: Swallowing windows in X... X-Now-Listening-To: The Chieftains - Gol na Mban San ar Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 37 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: So, how difficult would it be to allow for 'swallowing' an X window in XEmacs? This would be easier than what I had to do ages ago to get mpegs playing inside XEmacs (adding a '-window xxxxx' switch) I was playing around with this, and can correctly make an 'xterm' disappear, but it does not get drawn correctly inside of XEmacs (it does sometimes, ONCE, but...) This would make it easier for displaying Java applets inside XEmacs, things like that. Running hotjava or another VM and then walking the window tree would be much easier than trying to get the various java runtimes to accept a '-window' argument. Ditto for other programs. Anybody with more X experience want to comment? Basically, I changed x_subwindow_instantiate() to do: char *provided_window = "0x280000e"; if (provided_window) { win = strtol (provided_window, NULL, 0); XReparentWindow (dpy, win, IMAGE_INSTANCE_X_CLIPWINDOW (ii), 0, 0); XChangeWindowAttributes (dpy, win, valueMask, &xswa); XSetWindowColormap (dpy, win, DefaultColormapOfScreen (xs)); } else { win = XCreateWindow (dpy, IMAGE_INSTANCE_X_CLIPWINDOW (ii), 0, 0, w, h, 0, CopyFromParent, InputOutput, CopyFromParent, valueMask, &xswa); } Also, I've got no idea how events should be passed from XEmacs to the underlying X application. -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 12 12:52:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA18160 for xemacs-beta-out; Fri, 12 Nov 1999 12:52:49 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA18153 for ; Fri, 12 Nov 1999 12:52:46 -0500 Received: from postal.sr.hp.com (postal.sr.hp.com [15.4.46.173]) by palrel1.hp.com (Postfix) with ESMTP id 3F7A977E; Fri, 12 Nov 1999 09:52:39 -0800 (PST) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id JAA11589; Fri, 12 Nov 1999 09:52:47 -0800 (PST) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id JAA23745; Fri, 12 Nov 1999 09:52:37 -0800 (PST) Message-Id: <199911121752.JAA23745@mina.sr.hp.com> To: "James N. Potts" Cc: "XEmacs Beta Mailing List" Subject: Re: spam from mailing list Reply-To: Darryl Okahata In-reply-to: Your message of "Thu, 11 Nov 1999 21:40:16 CST." <001401bf2cbf$a2d61ce0$1a7ed8cd@dogbert.plutonium.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Nov 1999 09:52:36 -0800 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "James N. Potts" wrote: > I administer sendmail for my domain, so I can certainly block it there. But > the point is, if it's going to be blocked at the MTA level, it might as well > be blocked _once_ at the origin of the mailing list (gwyn.tux.org) rather > than at the hundreds of MTAs that receive the list. In an ideal world -- yes. However, as others have pointed out, it's very nontrivial to write a spam filter that doesn't get any false positives. Writing a spam filter that gets an occasional false positive is easy enough, but it's extremely difficult to write one that gets none. Given the current desires, I don't think there's much more that can be done at the XEmacs end. Filtering (at the user-MTA or mail client end) is, perhaps, the only thing that can be done by those bothered by spam. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Fri Nov 12 13:57:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA21459 for xemacs-beta-out; Fri, 12 Nov 1999 13:57:39 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA21454 for ; Fri, 12 Nov 1999 13:57:37 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA08603; Fri, 12 Nov 1999 19:57:35 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0026P; Fri Nov 12 19:57:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA02080; Fri, 12 Nov 1999 19:57:30 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Swallowing windows in X... References: <86so2benle.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 12 Nov 1999 19:57:29 +0100 In-Reply-To: wmperry@aventail.com's message of "12 Nov 1999 10:28:13 -0500" Message-ID: Lines: 35 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Anybody with more X experience want to comment? Basically, I changed > x_subwindow_instantiate() to do: > > [ugly "first try interface" deleted to protect minors] > > XReparentWindow (dpy, win, IMAGE_INSTANCE_X_CLIPWINDOW (ii), 0, 0); > XChangeWindowAttributes (dpy, win, valueMask, &xswa); > XSetWindowColormap (dpy, win, DefaultColormapOfScreen (xs)); I am not an X expert, but I can stand on the shoulders of Rob Nation (from the FVWM 2.2 sources:) XReparentWindow(dpy,Buttons[button].IconWin, main_win, j*ButtonWidth+2, i*ButtonHeight+2); XMapWindow(dpy,Buttons[button].IconWin); XSelectInput(dpy,(Window)body[0], PropertyChangeMask|StructureNotifyMask); Note that the FVWM swallow routine also looks up the WM hints to determine a natural size. I can mail you the complete routine if you want. Note that the gnome sources do something very weird when deleting windows. They reparent back to root and then delete .... Jan P.S. With all this X hackery going on it is becoming reasonable to define set-x-window-property, set-x-window-property-change-callback etc for elisp. P.P.S. Please submit a comprehensive GPM patch to xemacs-patches. I have lost track. I will apply it to 21.2 then. From owner-xemacs-beta@xemacs.org Fri Nov 12 15:09:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA25166 for xemacs-beta-out; Fri, 12 Nov 1999 15:09:20 -0500 Received: from pops.interhack.net (pops.interhack.net [209.190.37.60]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA25150; Fri, 12 Nov 1999 15:09:10 -0500 Received: from strangepork.interhack.net (strangepork.interhack.net [192.168.1.12]) by pops.interhack.net (8.8.8/8.8.8/spamkiller) with ESMTP id PAA05343; Fri, 12 Nov 1999 15:22:55 -0500 (EST) Received: (from cmcurtin@localhost) by strangepork.interhack.net (8.8.5/8.8.5) id PAA10374; Fri, 12 Nov 1999 15:19:51 -0500 (EST) From: Matt Curtin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14380.30310.710203.130391@strangepork.interhack.net> Date: Fri, 12 Nov 1999 15:19:50 -0500 (EST) To: Jan Vroonhof Cc: xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el In-Reply-To: References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Attribution: Matvey X-URL: http://www.interhack.net/people/cmcurtin/ X-Face: L"IcL.b%SDN]0Kql2b`e.}+i05V9fi\yX#H1+Xl)3!+n/3?5`%-SA-HDgPk9uTk<3dv^J5DCgal)-E{`zN#*o6F|y>r)\< >>>>> On 10 Nov 1999 19:54:34 +0100, Jan Vroonhof said: Jan> I suggest you still act as "our" Maintainer. OK. I have taken FSF's browse-url.el from GNU Emacs 20.4 and made it happy under XEmacs with a few `featurep's and I put the change logs back in where they used to live (from the original, and then by grabbing the appropriate entries from the ChangeLog file from FSF). I also listed myself as the maintainer, since it looks like it'll be difficult or impossible to have a single copy that works for both FSF and us. (I plan only to track changes from FSF to keep ours in sync; functionality changes I'd do through FSF's maintainer.) There is one thing that I'm not sure about, though: in the FSF version, browse-url-browser-function has "20.4" listed for :version. Is there any reason to change this? (I don't see what it will hurt, but it sort of bugs me because it's not the same as FSF's 20.4.) Once I know what, if anything, to do about that, I'll send the patch to get our browse-url.el in sync. -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ From owner-xemacs-beta@xemacs.org Fri Nov 12 17:36:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA00628 for xemacs-beta-out; Fri, 12 Nov 1999 17:36:05 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA00623; Fri, 12 Nov 1999 17:36:03 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id XAA11059; Fri, 12 Nov 1999 23:36:02 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002gl; Fri Nov 12 23:35:55 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id XAA02138; Fri, 12 Nov 1999 23:35:54 +0100 To: Matt Curtin Cc: xemacs-review@xemacs.org, XEmacs beta list Subject: Re: Patch: browse-url.el References: <14376.26281.839744.974769@gold.cis.ohio-state.edu> <3829745A.90E45A14@666.com> <14380.30310.710203.130391@strangepork.interhack.net> From: Jan Vroonhof Date: 12 Nov 1999 23:35:54 +0100 In-Reply-To: Matt Curtin's message of "Fri, 12 Nov 1999 15:19:50 -0500 (EST)" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Matt Curtin writes: > There is one thing that I'm not sure about, though: in the FSF > version, browse-url-browser-function has "20.4" listed for :version. > Is there any reason to change this? (I don't see what it will hurt, > but it sort of bugs me because it's not the same as FSF's 20.4.) The whole custom :version keyword doesn't make any sense with packages anyway, so it doesn't matter either way. Jan From owner-xemacs-beta@xemacs.org Fri Nov 12 17:42:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA01026 for xemacs-beta-out; Fri, 12 Nov 1999 17:42:52 -0500 Received: from mail.dycon.com (samuel.dycon.com [12.13.144.15]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id RAA01023 for ; Fri, 12 Nov 1999 17:42:49 -0500 Received: (qmail 14854 invoked from network); 12 Nov 1999 22:47:15 -0000 Received: from p3m23.dycon.net (HELO craig) (12.13.145.173) by samuel.dycon.com with SMTP; 12 Nov 1999 22:47:15 -0000 Message-Id: <3.0.6.32.19991112174038.007f7520@mail.dycon.com> X-Sender: craigl@mail.dycon.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 12 Nov 1999 17:40:38 -0500 To: Andy Piper From: Craig Lanning Subject: Re: XEmacs 21.2.20 "Yoko" is released Cc: xemacs-beta@xemacs.org In-Reply-To: <3.0.5.32.19991112020301.00b05bf0@london.beasys.com> References: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 02:03 AM 11/12/99 +0000, Andy Piper wrote: >At 06:21 PM 11/11/99 -0500, Craig Lanning wrote: >>>to 21.2.20 "Yoko" >>> ... >>>-- mingw install fix from Craig Lanning >> >>I think that I should point out that, while I submitted a patch for this, >>my patch was rejected. The patch that was accepted was submitted by Andy >>Piper (I think). > >It was your idea so I credited you with it in CHANGES-beta OK. >andy >-------------------------------------------------------------- >Dr Andy Piper >Senior Consultant Architect, BEA Systems Ltd > > From owner-xemacs-beta@xemacs.org Fri Nov 12 18:59:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA04661 for xemacs-beta-out; Fri, 12 Nov 1999 18:59:05 -0500 Received: from justresearch.com (ULYSSES.JPRC.COM [207.86.147.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA04655 for ; Fri, 12 Nov 1999 18:59:03 -0500 Received: (from mthomas@localhost) by justresearch.com (8.8.7/8.8.7) id SAA13574; Fri, 12 Nov 1999 18:59:04 -0500 Date: Fri, 12 Nov 1999 18:59:04 -0500 Message-Id: <199911122359.SAA13574@justresearch.com> To: xemacs-beta@xemacs.org From: Mark Thomas Subject: changing buffers with gutters visible resets match-data Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In XEmacs 21.2 (beta20) "Yoko" [Lucid] (i686-pc-linux, Mule) of Wed Nov 10 1999 on ulysses.jprc.com configured using `configure --prefix=/home/xemacs/debug --with-mule --site-libraries=/home/xemacs/lib --site-includes=/home/xemacs/include --site-runtime-libraries=/home/xemacs/lib '--cflags=-g -Wall -Wno-switch' --with-dialogs=athena --with-widgets=athena' When gutters are visible, changing buffers (including going into the minibuffer via M-x or M-:) resets the match-data. This makes it impossible to interactively debug emacs-lisp code. My test is start xemacs -vanilla, in the *scratch* buffer enter the text (match-data t) then press C-x 2 C-a C-s data C-e C-x C-e to split the window and search for "data"; you'll see "(205 209)" in the minibuffer. Now press C-x o C-x C-e and you'll see "(0 1)" in the minibuffer. If you make the gutters invisible and repeat, you'll get the same expression "(205 209)" in the minibuffer from both views of *scratch* uname -a: Linux ulysses.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown ../xemacs-21.2.20/configure '--prefix=/home/xemacs/debug' '--with-mule' '--site-libraries=/home/xemacs/lib' '--site-includes=/home/xemacs/include' '--site-runtime-libraries=/home/xemacs/lib' '--cflags=-g -Wall -Wno-switch' '--with-dialogs=athena' '--with-widgets=athena' XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. Where should the build process find the source code? /home/xemacs/build/xemacs-21.2.20 What installation prefix should install use? /home/xemacs/debug What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /home/xemacs/include Additional libraries: /home/xemacs/lib Runtime library search path: /home/xemacs/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena native widgets. Using Athena dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From owner-xemacs-beta@xemacs.org Fri Nov 12 19:44:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA06185 for xemacs-beta-out; Fri, 12 Nov 1999 19:44:12 -0500 Received: from justresearch.com (ULYSSES.JPRC.COM [207.86.147.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA06182 for ; Fri, 12 Nov 1999 19:44:10 -0500 Received: (from mthomas@localhost) by justresearch.com (8.8.7/8.8.7) id TAA13620; Fri, 12 Nov 1999 19:44:04 -0500 To: xemacs-beta@xemacs.org Subject: Re: changing buffers with gutters visible resets match-data References: <199911122359.SAA13574@justresearch.com> From: Mark Thomas Date: 12 Nov 1999 19:44:04 -0500 In-Reply-To: Mark Thomas's message of "Fri, 12 Nov 1999 18:59:04 -0500" Message-ID: Lines: 35 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > In XEmacs 21.2 (beta20) "Yoko" [Lucid] (i686-pc-linux, Mule) of Wed > Nov 10 1999 on ulysses.jprc.com > When gutters are visible, changing buffers resets the match-data. Here's an easier way to exhibit the bug. The only difference is whether gutters are visible: $ xemacs -vanilla -batch -eval ' (let (x y) (setq gutter-visible-p (set-specifier default-gutter-visible-p nil)) (insert "foo") (beginning-of-line) (re-search-forward "foo") (setq x (match-data t)) (split-window-vertically) (other-window 1) (setq y (match-data t)) (message "%s %s" x y))' (1 4) (1 4) $ xemacs -vanilla -batch -eval ' (let (x y) (insert "foo") (beginning-of-line) (re-search-forward "foo") (setq x (match-data t)) (split-window-vertically) (other-window 1) (setq y (match-data t)) (message "%s %s" x y))' (1 4) (0 1) From owner-xemacs-beta@xemacs.org Fri Nov 12 19:54:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA06406 for xemacs-beta-out; Fri, 12 Nov 1999 19:54:38 -0500 Received: from vals.intramed.rito.no (vals.intramed.Rito.No [193.157.80.171]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA06401 for ; Fri, 12 Nov 1999 19:54:33 -0500 Received: from ODIN4.rito.no (odin.rito.no [172.20.4.17]) by vals.intramed.rito.no (8.9.3/8.9.3) with ESMTP id BAA12098 for ; Sat, 13 Nov 1999 01:54:31 +0100 (CET) Message-Id: <199911130054.BAA12098@vals.intramed.rito.no> Received: from 10.0.0.47 (172.19.2.37 [172.19.2.37]) by ODIN4.rito.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WD4G988V; Sat, 13 Nov 1999 01:52:00 +0100 Date: Sat, 13 Nov 1999 01:33:28 +0100 From: Terje Bless Subject: Re: XEmacs 21.2.20 "Yoko" is released To: XEmacs-Beta X-Priority: 3 In-Reply-To: <3.0.5.32.19991112020301.00b05bf0@london.beasys.com> MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII X-Mailer: Mailsmith 1.1.4 (Bluto) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 12.11.99 at 02:03, Andy Piper wrote: >At 06:21 PM 11/11/99 -0500, Craig Lanning wrote: > >>I think that I should point out that, while I submitted a patch for this, >>my patch was rejected. The patch that was accepted was submitted by Andy >>Piper (I think). > >It was your idea so I credited you with it in CHANGES-beta Is this really the place to give credits? Isn't this the place to assign _blame_ and credits go in a CREDITS file? If this patch is broken, should Craig or Andy get shot? From owner-xemacs-beta@xemacs.org Fri Nov 12 20:10:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA06778 for xemacs-beta-out; Fri, 12 Nov 1999 20:10:55 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA06774 for ; Fri, 12 Nov 1999 20:10:52 -0500 Received: by crystal.WonderWorks.COM id QQhpbw03326; Fri, 12 Nov 1999 17:10:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14380.47769.516350.36895@crystal.WonderWorks.COM> Date: Fri, 12 Nov 1999 17:10:49 -0800 (PST) From: Kyle Jones To: XEmacs-Beta Subject: Re: XEmacs 21.2.20 "Yoko" is released In-Reply-To: <199911130054.BAA12098@vals.intramed.rito.no> References: <3.0.5.32.19991112020301.00b05bf0@london.beasys.com> <199911130054.BAA12098@vals.intramed.rito.no> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > > > I think that I should point out that, while I submitted a > > > patch for this, my patch was rejected. The patch that was > > > accepted was submitted by Andy Piper (I think). > > > > It was your idea so I credited you with it in CHANGES-beta > > Is this really the place to give credits? Isn't this the place > to assign _blame_ and credits go in a CREDITS file? Yah, this is the place, historically speaking. > If this patch is broken, should Craig or Andy get shot? Both of them, but only in the legs. :) From owner-xemacs-beta@xemacs.org Fri Nov 12 23:32:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA10723 for xemacs-beta-out; Fri, 12 Nov 1999 23:32:11 -0500 Received: from vals.intramed.rito.no (vals.intramed.Rito.No [193.157.80.171]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA10720 for ; Fri, 12 Nov 1999 23:32:09 -0500 Received: from ODIN4.rito.no (odin.rito.no [172.20.4.17]) by vals.intramed.rito.no (8.9.3/8.9.3) with ESMTP id FAA19775 for ; Sat, 13 Nov 1999 05:32:08 +0100 (CET) Message-Id: <199911130432.FAA19775@vals.intramed.rito.no> Received: from 10.0.0.47 (172.19.2.37 [172.19.2.37]) by ODIN4.rito.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WD4G99AN; Sat, 13 Nov 1999 05:29:36 +0100 Date: Sat, 13 Nov 1999 05:32:57 +0100 From: Terje Bless Subject: Re: XEmacs 21.2.20 "Yoko" is released To: XEmacs-Beta X-Priority: 3 In-Reply-To: <14380.47769.516350.36895@crystal.WonderWorks.COM> MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII X-Mailer: Mailsmith 1.1.4 (Bluto) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 12.11.99 at 17:10, Kyle Jones wrote: >Yah, this is the place, historically speaking. And, historically speaking, 640K ought to be enough? :-) Not arguing either way; just nitpicking. It struck me as odd is all. If a patch breaks something, the sane thing to do is to bitch at whomever touched the patch last not the one who came up with the idea. I'm probably just not familiar enough with what goes where and how these things are tracked and should probably have kept my mouth shut in the first place. :-) From owner-xemacs-beta@xemacs.org Sat Nov 13 08:54:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA17329 for xemacs-beta-out; Sat, 13 Nov 1999 08:54:25 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA17324 for ; Sat, 13 Nov 1999 08:54:21 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id OAA00816; Sat, 13 Nov 1999 14:54:20 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Ch; Sat Nov 13 14:54:17 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id OAA02331; Sat, 13 Nov 1999 14:54:17 +0100 To: Mark Thomas Cc: xemacs-beta@xemacs.org Subject: Re: changing buffers with gutters visible resets match-data References: <199911122359.SAA13574@justresearch.com> From: Jan Vroonhof Date: 13 Nov 1999 14:54:17 +0100 In-Reply-To: Mark Thomas's message of "12 Nov 1999 19:44:04 -0500" Message-ID: Lines: 8 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mark Thomas writes: > > When gutters are visible, changing buffers resets the match-data. I guess the whole of buffers-tab-items should be wrapped in a save-match-data Jan From owner-xemacs-beta@xemacs.org Sat Nov 13 10:54:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA19731 for xemacs-beta-out; Sat, 13 Nov 1999 10:54:30 -0500 Received: from lsppc4.epfl.ch (lsppc4.epfl.ch [128.178.75.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA19728 for ; Sat, 13 Nov 1999 10:54:26 -0500 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id QAA07182; Sat, 13 Nov 1999 16:54:25 +0100 To: xemacs-beta@xemacs.org Subject: I need help from a signal expert ! X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Sat_Nov_13_16:54:21_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 13 Nov 1999 16:54:25 +0100 Message-ID: Lines: 38 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Sat_Nov_13_16:54:21_1999-1 Content-Type: text/plain; charset=US-ASCII I am currently implementing functions for adding and deleting LDAP records in eldap.c. The functions seem to work (records get added and deleted from the server) except for the fact that they return an error code indicating they can't contact the server which is obviously wrong. The problem boils down to a select function being interrupted (errno=EINTR) in a call to `ldap_result'. I had the exact same problem when I implemented the open/search/close functions and it was solved by adding calls to `slow_down_interrupts' and `speed_up_interrupts' around calls to LDAP library functions. Of course I tried to do the same here but to no avail. `ldap_result' is still interrupted though surrounded by {slow_down,speed_up}_interrupts. I even tried `stop_interrupts' and `start_interrupts' with no success. I can't understand why it works for searches (which also call `ldap_result') and not for addition and deletion. I'd appreciate very much some help from someone knowledgeable in this area. Oscar --pgp-sign-Multipart_Sat_Nov_13_16:54:21_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOC2Jrp7CaiYEgqPZAQEzpQIAghQgGwwWIDkooQg/lfmuVVHAxMLiqW9O 8+lgsssCkMG+4FbzLY8copxNGUSOyZRhrPR+GMMXsotZ+lYvGiy7Uw== =MIPt -----END PGP MESSAGE----- --pgp-sign-Multipart_Sat_Nov_13_16:54:21_1999-1-- From owner-xemacs-beta@xemacs.org Sat Nov 13 14:13:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA24013 for xemacs-beta-out; Sat, 13 Nov 1999 14:13:52 -0500 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA24010 for ; Sat, 13 Nov 1999 14:13:51 -0500 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA15033 for ; Sat, 13 Nov 1999 11:13:46 -0800 (PST) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id LAA06739; Sat, 13 Nov 1999 11:13:55 -0800 (PST) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id LAA15014; Sat, 13 Nov 1999 11:13:44 -0800 (PST) Message-Id: <199911131913.LAA15014@mina.sr.hp.com> To: Oscar Figueiredo cc: xemacs-beta@xemacs.org Subject: Re: I need help from a signal expert ! Reply-To: Darryl Okahata In-reply-to: Your message of "13 Nov 1999 16:54:25 +0100." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 13 Nov 1999 11:13:43 -0800 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo wrote: > The problem boils down to a select function being interrupted (errno=EINTR) i > n > a call to `ldap_result'. Which ldap libraries are you using? The low-level ldap code should handle EINTR during select() and restart. Looking over the source code, the UM-LDAP libraries appear to do so. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Sat Nov 13 14:32:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA24524 for xemacs-beta-out; Sat, 13 Nov 1999 14:32:10 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA24521 for ; Sat, 13 Nov 1999 14:32:08 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA07527; Sat, 13 Nov 1999 20:32:07 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa001p.; Sat Nov 13 20:32:02 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id UAA09069; Sat, 13 Nov 1999 20:32:02 +0100 To: Oscar Figueiredo Cc: xemacs-beta@xemacs.org Subject: Re: I need help from a signal expert ! References: From: Jan Vroonhof Date: 13 Nov 1999 20:32:02 +0100 In-Reply-To: Oscar Figueiredo's message of "13 Nov 1999 16:54:25 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > surrounded by {slow_down,speed_up}_interrupts. I even tried `stop_interrupts> and `start_interrupts' with no success. I can't understand why it works for > searches (which also call `ldap_result') and not for addition and deletion. That could just be some timing issue. It could also be that there is a file descriptor involved that unrequest_sigio doesn't know about. > I'd appreciate very much some help from someone knowledgeable in > this area. Could you check with strace or truss which signal is interrupting the syscal? Jan From owner-xemacs-beta@xemacs.org Sat Nov 13 19:58:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA32512 for xemacs-beta-out; Sat, 13 Nov 1999 19:58:28 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id TAA32505 for ; Sat, 13 Nov 1999 19:58:25 -0500 Received: (qmail 20227 invoked from network); 14 Nov 1999 00:57:04 -0000 Received: from usrpri2-31.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.96) by biff.kiva.net with SMTP; 14 Nov 1999 00:57:04 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA11747; Sat, 13 Nov 1999 20:00:05 -0500 To: xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: latest GPM patch... Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=gpm-patch-6 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Index: lisp/gpm.el =================================================================== --- lisp/gpm.el Tue May 5 15:32:27 1998 +++ lisp/gpm.el Mon Nov 8 11:22:39 1999 @@ -0,0 +1,82 @@ +;;; gpm.el --- Support the mouse when emacs run on a Linux console. + +;; Copyright (C) 1999 Free Software Foundation + +;; Author: William Perry +;; Keywords: mouse, terminals + +;; This file is part of XEmacs. + +;; XEmacs 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. + +;; XEmacs 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, Inc., 59 Temple Place - Suite 330, +;; Boston, MA 02111-1307, USA. + +(defvar gpm-enabled-devices (make-hash-table :test 'eq + :size 13 + :weakness 'key) + "A hash table of devices with GPM currently turned on.") + +(defun gpm-mode (&optional arg device) + "Toggle GPM mouse mode. +With prefix arg, turn GPM mouse mode on if and only if arg is positive." + (interactive (list current-prefix-arg (selected-device))) + (cond + ((null arg) ; Toggle + (if (gethash device gpm-enabled-devices) + (progn + (gpm-enable device nil) + (remhash device gpm-enabled-devices)) + (gpm-enable device t) + (puthash device t gpm-enabled-devices))) + ((> arg 0) ; Turn on + (gpm-enable device t) + (puthash device t gpm-enabled-devices)) + ((gethash device gpm-enabled-devices) ; Turn off + (gpm-enable device nil) + (remhash device gpm-enabled-devices)))) + +(defun turn-on-gpm-mouse-tracking (&optional device) + ;; Enable mouse tracking on linux console + (gpm-mode 5 device)) + +(defun turn-off-gpm-mouse-tracking (&optional device) + ;; Disable mouse tracking on linux console + (gpm-mode -5 device)) + +(defun gpm-create-device-hook (device) + (if (and (not noninteractive) ; Don't want to do this in batch mode + (fboundp 'gpm-enable) ; Must have C-level GPM support + (eq system-type 'linux) ; Must be running linux + (eq (device-type device) 'tty) ; on a tty + (equal "linux" (console-tty-terminal-type ; an a linux terminal type + (device-console device)))) + (turn-on-gpm-mouse-tracking device))) + +(defun gpm-delete-device-hook (device) + (if (and (not noninteractive) ; Don't want to do this in batch mode + (fboundp 'gpm-enable) ; Must have C-level GPM support + (eq system-type 'linux) ; Must be running linux + (eq (device-type device) 'tty) ; on a tty + (equal "linux" (console-tty-terminal-type ; an a linux terminal type + (device-console device)))) + (turn-off-gpm-mouse-tracking device))) + +;; Restore normal mouse behaviour outside Emacs + +(add-hook 'suspend-hook 'turn-off-gpm-mouse-tracking) +(add-hook 'suspend-resume-hook 'turn-on-gpm-mouse-tracking) +(add-hook 'create-device-hook 'gpm-create-device-hook) +(add-hook 'delete-device-hook 'gpm-delete-device-hook) + +(provide 'gpm) Index: lisp/mouse.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/mouse.el,v retrieving revision 1.19.2.6 diff -u -r1.19.2.6 mouse.el --- mouse.el 1999/09/02 08:47:55 1.19.2.6 +++ mouse.el 1999/11/14 00:53:22 @@ -88,7 +88,9 @@ the X cutbuffer. A mark is pushed, so that the inserted text lies between point and mark." (interactive) - (if (not (console-on-window-system-p)) + (if (and (not (console-on-window-system-p)) + (and (featurep 'gpm) + (not (gpm-enabled-p)))) (yank) (push-mark) (if (region-active-p) Index: src/console-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.5 diff -u -r1.18.2.5 console-tty.c --- console-tty.c 1999/10/24 03:48:31 1.18.2.5 +++ console-tty.c 1999/11/14 00:53:37 @@ -38,9 +38,6 @@ #ifdef FILE_CODING #include "file-coding.h" #endif -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif DEFINE_CONSOLE_TYPE (tty); DECLARE_IMAGE_INSTANTIATOR_FORMAT (nothing); @@ -129,10 +126,6 @@ #endif /* MULE */ tty_con->terminal_type = terminal_type; tty_con->controlling_process = controlling_process; - -#ifdef HAVE_GPM - connect_to_gpm (con); -#endif if (NILP (CONSOLE_NAME (con))) CONSOLE_NAME (con) = Ffile_name_nondirectory (tty); Index: src/console-tty.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 console-tty.h --- console-tty.h 1999/02/17 20:03:57 1.8.2.2 +++ console-tty.h 1999/11/14 00:53:39 @@ -41,9 +41,6 @@ struct tty_console { int infd, outfd; -#ifdef HAVE_GPM - int mouse_fd; -#endif Lisp_Object instream, outstream; Lisp_Object terminal_type; Lisp_Object controlling_process; @@ -203,9 +200,6 @@ unsigned int is_stdio :1; }; -#ifdef HAVE_GPM -#define CONSOLE_TTY_MOUSE_FD(c) (CONSOLE_TTY_DATA (c)->mouse_fd) -#endif #define CONSOLE_TTY_DATA(c) CONSOLE_TYPE_DATA (c, tty) #define CONSOLE_TTY_CURSOR_X(c) (CONSOLE_TTY_DATA (c)->cursor_x) #define CONSOLE_TTY_CURSOR_Y(c) (CONSOLE_TTY_DATA (c)->cursor_y) Index: src/device-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-tty.c,v retrieving revision 1.9 diff -u -r1.9 device-tty.c --- device-tty.c 1998/05/27 20:42:00 1.9 +++ device-tty.c 1999/11/14 00:53:39 @@ -38,10 +38,6 @@ #include "syssignal.h" /* for SIGWINCH */ -#ifdef HAVE_GPM -#include -#endif - #include Lisp_Object Qinit_pre_tty_win, Qinit_post_tty_win; @@ -155,15 +151,6 @@ CONSOLE_TTY_DATA (con)->width = width; CONSOLE_TTY_DATA (con)->height = height; -#ifdef HAVE_GPM - /* We need to tell GPM how big our screen is now - ** I am pretty sure the GPM library will get incredibly confused - ** if you try to connect to more than one mouse-capable device, - ** so I don't think it will cause any more damage in that case. - */ - gpm_mx = width; - gpm_my = height; -#endif for (tail = DEVICE_FRAME_LIST (d); !NILP (tail); tail = XCDR (tail)) Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.32 diff -u -r1.82.2.32 emacs.c --- emacs.c 1999/11/02 02:41:45 1.82.2.32 +++ emacs.c 1999/11/14 00:53:42 @@ -1088,6 +1088,10 @@ syms_of_eldap (); #endif +#ifdef HAVE_GPM + syms_of_gpmevent (); +#endif + /* Now create the subtypes for the types that have them. We do this before the vars_*() because more symbols may get initialized here. */ @@ -1481,6 +1485,10 @@ #ifdef HAVE_LDAP vars_of_eldap (); +#endif + +#ifdef HAVE_GPM + vars_of_gpmevent (); #endif /* Now initialize any specifier variables. We do this later Index: src/event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.14 diff -u -r1.41.2.14 event-Xt.c --- event-Xt.c 1999/10/10 11:45:15 1.41.2.14 +++ event-Xt.c 1999/11/14 00:53:45 @@ -2034,9 +2034,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2044,22 +2041,6 @@ infd = event_stream_unixoid_select_console (con); XSETCONSOLE (console, con); select_filedesc (infd, console); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - /* We check filedesc_to_what_closure[fd] here because if you run - ** XEmacs from a TTY, it will fire up GPM, select the mouse fd, then - ** if you run gnuattach to connect to another TTY, it will fire up - ** GPM again, and try to reselect the mouse fd. GPM uses the same - ** fd for every connection apparently, and select_filedesc will - ** fail its assertion if we try to select it twice. - */ - if ((mousefd >= 0) && !filedesc_to_what_closure[mousefd]) { - select_filedesc (mousefd, console); - } - } -#endif } static void @@ -2067,9 +2048,6 @@ { Lisp_Object console; int infd; -#ifdef HAVE_GPM - int mousefd; -#endif if (CONSOLE_X_P (con)) return; /* X consoles are automatically selected for when we @@ -2077,15 +2055,6 @@ infd = event_stream_unixoid_unselect_console (con); XSETCONSOLE (console, con); unselect_filedesc (infd); -#ifdef HAVE_GPM - /* On a stream device (ie: noninteractive), bad things can happen. */ - if (EQ (CONSOLE_TYPE (con), Qtty)) { - mousefd = CONSOLE_TTY_MOUSE_FD (con); - if (mousefd >= 0) { - unselect_filedesc (mousefd); - } - } -#endif } /* read an event from a tty, if one is available. Returns non-zero Index: src/event-unixoid.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-unixoid.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 event-unixoid.c --- event-unixoid.c 1999/03/07 15:25:17 1.9.2.1 +++ event-unixoid.c 1999/11/14 00:53:45 @@ -41,10 +41,6 @@ #include "sysproc.h" /* select stuff */ #include "systime.h" -#ifdef HAVE_GPM -#include "gpmevent.h" -#endif - /* Mask of bits indicating the descriptors that we wait for input on. These work as follows: @@ -83,12 +79,6 @@ Lisp_Object console; XSETCONSOLE (console, con); - -#ifdef HAVE_GPM - if (fd == CONSOLE_TTY_MOUSE_FD (con)) { - return handle_gpm_read (event,con,fd); - } -#endif nread = read (fd, &ch, 1); if (nread <= 0) Index: src/frame-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame-tty.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 frame-tty.c --- frame-tty.c 1998/12/05 16:55:48 1.8.2.1 +++ frame-tty.c 1999/11/14 00:53:45 @@ -33,10 +33,6 @@ #include "events.h" -#ifdef HAVE_GPM -#include -#endif - /* Default properties to use when creating frames. */ Lisp_Object Vdefault_tty_frame_plist; @@ -86,33 +82,6 @@ call1 (Qinit_post_tty_win, FRAME_CONSOLE (f)); } -#ifdef HAVE_GPM -static int -tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) -{ - Gpm_Event ev; - int num_buttons; - - num_buttons = Gpm_GetSnapshot(&ev); - *x = ev.x; - *y = ev.y; - *frame = DEVICE_SELECTED_FRAME (d); - return (1); -} - -static void -tty_set_mouse_position (struct window *w, int x, int y) -{ - /* XXX - I couldn't find any GPM functions that set the mouse position. - Mr. Perry had left this function empty; that must be why. - karlheg - */ -} - -#endif - - /* Change from withdrawn state to mapped state. */ static void tty_make_frame_visible (struct frame *f) @@ -223,10 +192,6 @@ CONSOLE_HAS_METHOD (tty, init_frame_1); CONSOLE_HAS_METHOD (tty, init_frame_3); CONSOLE_HAS_METHOD (tty, after_init_frame); -#ifdef HAVE_GPM - CONSOLE_HAS_METHOD (tty, get_mouse_position); - CONSOLE_HAS_METHOD (tty, set_mouse_position); -#endif CONSOLE_HAS_METHOD (tty, make_frame_visible); CONSOLE_HAS_METHOD (tty, make_frame_invisible); CONSOLE_HAS_METHOD (tty, frame_visible_p); Index: src/gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5 diff -u -r1.5 gpmevent.c --- gpmevent.c 1998/03/31 20:11:47 1.5 +++ gpmevent.c 1999/11/14 00:53:55 @@ -1,5 +1,28 @@ -/* William Perry 1997 */ +/* GPM functions + Copyright (C) 1997 William M. Perry + Copyright (C) 1999 Free Software Foundation, Inc. + +This file is part of XEmacs. + +XEmacs 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. + +XEmacs 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 XEmacs; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* Synched up with: Not in FSF. */ + +/* Authors: William Perry */ + #include #include "lisp.h" #include "console.h" @@ -8,6 +31,10 @@ #include "events.h" #include "events-mod.h" #include "sysdep.h" +#include "commands.h" +#include "lstream.h" +#include "sysproc.h" /* for MAXDESC */ +#include "process.h" #ifdef HAVE_GPM #include "gpmevent.h" @@ -20,95 +47,603 @@ #else #include #endif + +extern int gpm_tried; +extern void *gpm_stack; + +static int (*orig_event_pending_p) (int); +static void (*orig_next_event_cb) (struct Lisp_Event *); + +static Lisp_Object gpm_event_queue; +static Lisp_Object gpm_event_queue_tail; + +struct __gpm_state { + int gpm_tried; + int gpm_flag; + void *gpm_stack; +}; -int -handle_gpm_read (struct Lisp_Event *event, struct console *con, int fd) +static struct __gpm_state gpm_state_information[MAXDESC]; + +static void +store_gpm_state (int fd) { - Gpm_Event ev; - int modifiers = 0; - int type = -1; - int button = 1; - - if (!Gpm_GetEvent(&ev)) - return 0; - - event->timestamp = 0; - event->channel = CONSOLE_SELECTED_FRAME (con); - - /* Whow, wouldn't named defines be NICE!?!?! */ - modifiers = 0; - - if (ev.modifiers & 1) modifiers |= MOD_SHIFT; - if (ev.modifiers & 2) modifiers |= MOD_META; - if (ev.modifiers & 4) modifiers |= MOD_CONTROL; - if (ev.modifiers & 8) modifiers |= MOD_META; - - if (ev.type & GPM_DOWN) - type = GPM_DOWN; - else if (ev.type & GPM_UP) - type = GPM_UP; - else if (ev.type & GPM_MOVE) { - type = GPM_MOVE; - GPM_DRAWPOINTER(&ev); - } - - if (ev.buttons & GPM_B_LEFT) - button = 1; - else if (ev.buttons & GPM_B_MIDDLE) - button = 2; - else if (ev.buttons & GPM_B_RIGHT) - button = 3; - - switch (type) { - case GPM_DOWN: - case GPM_UP: - event->event_type = - type == GPM_DOWN ? button_press_event : button_release_event; - event->event.button.x = ev.x; - event->event.button.y = ev.y; - event->event.button.button = button; - event->event.button.modifiers = modifiers; - break; - case GPM_MOVE: - event->event_type = pointer_motion_event; - event->event.motion.x = ev.x; - event->event.motion.y = ev.y; - event->event.motion.modifiers = modifiers; - default: - return 0; - } - return 1; -} - -void -connect_to_gpm (struct console *con) -{ - /* Only do this if we are running after dumping and really interactive */ - if (!noninteractive && initialized) { - /* We really only want to do this on a TTY */ - CONSOLE_TTY_MOUSE_FD (con) = -1; - if (EQ (CONSOLE_TYPE (con), Qtty)) { - Gpm_Connect conn; - int rval; - - conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE; - conn.defaultMask = GPM_MOVE; - conn.minMod = 0; - conn.maxMod = ((1<= 0) + { + memset(&gpm_state_information[fd], '\0', sizeof(struct __gpm_state)); + } + gpm_tried = gpm_flag = 1; + gpm_fd = gpm_consolefd = -1; + gpm_stack = NULL; +} + +static int +get_process_infd (struct Lisp_Process *p) +{ + Lisp_Object instr, outstr; + get_process_streams (p, &instr, &outstr); + assert (!NILP (instr)); + return filedesc_stream_fd (XLSTREAM (instr)); +} + +DEFUN ("receive-gpm-event", Freceive_gpm_event, 0, 2, 0, /* +Run GPM_GetEvent(). +This function is the process handler for the GPM connection. +*/ + (process, string)) +{ + Gpm_Event ev; + int modifiers = 0; + int type = -1; + int button = 1; + Lisp_Object fake_event; + Lisp_Process *proc; + struct Lisp_Event *event = NULL; + struct gcpro gcpro1; + static int num_events; + + CHECK_PROCESS (process); + + restore_gpm_state (get_process_infd (XPROCESS (process))); + + if (!Gpm_GetEvent(&ev)) + { + warn_when_safe (Qnil, Qcritical, "Gpm_GetEvent failed - %d", gpm_fd); + return(Qzero); + } + + GCPRO1(fake_event); + + num_events++; + + fake_event = Fmake_event (Qnil, Qnil); + event = XEVENT(fake_event); + + event->timestamp = 0; + event->channel = Fselected_frame (Qnil); /* CONSOLE_SELECTED_FRAME (con); */ + + /* Whow, wouldn't named defines be NICE!?!?! */ + modifiers = 0; + + if (ev.modifiers & 1) modifiers |= MOD_SHIFT; + if (ev.modifiers & 2) modifiers |= MOD_META; + if (ev.modifiers & 4) modifiers |= MOD_CONTROL; + if (ev.modifiers & 8) modifiers |= MOD_META; + + if (ev.buttons & GPM_B_LEFT) + { + button = 1; + } + else if (ev.buttons & GPM_B_MIDDLE) + { + button = 2; + } + else if (ev.buttons & GPM_B_RIGHT) + { + button = 3; + } + + switch (GPM_BARE_EVENTS(ev.type)) { + case GPM_DOWN: + case GPM_UP: + event->event_type = + (ev.type & GPM_DOWN) ? button_press_event : button_release_event; + event->event.button.x = ev.x; + event->event.button.y = ev.y; + event->event.button.button = button; + event->event.button.modifiers = modifiers; + break; + case GPM_MOVE: + case GPM_DRAG: + event->event_type = pointer_motion_event; + event->event.motion.x = ev.x; + event->event.motion.y = ev.y; + event->event.motion.modifiers = modifiers; + default: + /* This will never happen */ + break; + } + + /* Handle the event */ + enqueue_event (fake_event, &gpm_event_queue, &gpm_event_queue_tail); + + UNGCPRO; + + return (Qzero); +} + +static void turn_off_gpm (char *process_name) +{ + Lisp_Object process = Fget_process (build_string (process_name)); + int fd = -1; + + if (NILP (process)) + { + /* Something happened to our GPM process - fail silently */ + return; + } + + fd = get_process_infd (XPROCESS (process)); + + restore_gpm_state (fd); + Gpm_Close(); - break; - default: - set_descriptor_non_blocking (gpm_fd); - CONSOLE_TTY_MOUSE_FD (con) = gpm_fd; - } - } - } + + clear_gpm_state (fd); + + Fdelete_process (build_string (process_name)); } +#ifdef TIOCLINUX +static Lisp_Object +tty_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type) +{ + /* This function can GC */ + struct device *d = decode_device (Qnil); + int fd = DEVICE_INFD (d); + char c = 3; + Lisp_Object output_stream; + Lisp_Object terminal_stream; + Lisp_Object output_string; + struct gcpro gcpro1,gcpro2,gcpro3; + + GCPRO3(output_stream,terminal_stream,output_string); + + /* The ioctl() to paste actually puts things in the input queue of + ** the virtual console, so we need to trap that data, since we are + ** supposed to return the actual string selection from this + ** function. + */ + + /* I really hate doing this, but it doesn't seem to cause any + ** problems, and it makes the Lstream_read stuff further down + ** error out correctly instead of trying to indefinitely read from + ** the console. + ** + ** There is no set_descriptor_blocking() function call, but in my + ** testing under linux, it has not proved fatal to leave the + ** descriptor in non-blocking mode. + ** + ** William Perry Nov 5, 1999 + */ + set_descriptor_non_blocking (fd); + + /* We need two streams, one for reading from the selected device, + ** and one to write the data into. There is no writable version + ** of the lisp-string lstream, so we make do with a resizing + ** buffer stream, and make a string out of it after we are + ** done. + */ + output_stream = make_resizing_buffer_output_stream (); + terminal_stream = make_filedesc_input_stream (fd, 0, -1, LSTR_BLOCKED_OK); + output_string = Qnil; + + /* #### We should arguably use a specbind() and an unwind routine here, + ** #### but I don't care that much right now. + */ + if (NILP (output_stream) || NILP (terminal_stream)) + { + /* Should we signal an error here? */ + goto out; + } + + if (ioctl (fd, TIOCLINUX, &c) < 0) + { + /* Could not get the selection - eek */ + UNGCPRO; + return (Qnil); + } + + while (1) + { + Bufbyte tempbuf[1024]; /* some random amount */ + int i; + int size_in_bytes = Lstream_read (XLSTREAM (terminal_stream), + tempbuf, sizeof (tempbuf)); + + if (size_in_bytes <= 0) + { + /* end of the stream */ + break; + } + + /* convert CR->LF */ + for (i = 0; i < size_in_bytes; i++) + { + if (tempbuf[i] == '\r') + { + tempbuf[i] = '\n'; + } + } + + Lstream_write (XLSTREAM (output_stream), tempbuf, size_in_bytes); + } + + Lstream_flush (XLSTREAM (output_stream)); + + output_string = make_string (resizing_buffer_stream_ptr (XLSTREAM (output_stream)), + Lstream_byte_count (XLSTREAM (output_stream))); + + Lstream_delete (XLSTREAM (output_stream)); + Lstream_delete (XLSTREAM (terminal_stream)); + + out: + UNGCPRO; + return (output_string); +} + +static Lisp_Object +tty_selection_exists_p (Lisp_Object selection) +{ + return (Qt); +} +#endif /* TIOCLINUX */ + +#if 0 +static Lisp_Object +tty_own_selection (Lisp_Object selection_name, Lisp_Object selection_value) +{ + /* There is no way to do this cleanly - the GPM selection + ** 'protocol' (actually the TIOCLINUX ioctl) requires a start and + ** end position on the _screen_, not a string to stick in there. + ** Lame. + ** + ** William Perry Nov 4, 1999 + */ +} #endif + +/* This function appears to work once in a blue moon. I'm not sure +** exactly why either. *sigh* +** +** William Perry Nov 4, 1999 +** +** Apparently, this is the way (mouse-position) is supposed to work, +** and I was just expecting something else. (mouse-pixel-position) +** works just fine. +** +** William Perry Nov 7, 1999 +*/ +static int +tty_get_mouse_position (struct device *d, Lisp_Object *frame, int *x, int *y) +{ + Gpm_Event ev; + int num_buttons; + + memset(&ev,'\0',sizeof(ev)); + + num_buttons = Gpm_GetSnapshot(&ev); + + if (!num_buttons) + { + /* This means there are events pending... */ + + /* #### In theory, we should drain the events pending, stick + ** #### them in the queue, and return the mouse position + ** #### anyway. + */ + return(-1); + } + *x = ev.x; + *y = ev.y; + *frame = DEVICE_SELECTED_FRAME (d); + return (1); +} + +static void +tty_set_mouse_position (struct window *w, int x, int y) +{ + /* + #### I couldn't find any GPM functions that set the mouse position. + #### Mr. Perry had left this function empty; that must be why. + #### karlheg + */ +} + +static int gpm_event_pending_p (int user_p) +{ + Lisp_Object event; + + EVENT_CHAIN_LOOP (event, gpm_event_queue) + { + if (!user_p || command_event_p (event)) + { + return (1); + } + } + return (orig_event_pending_p (user_p)); +} + +static void gpm_next_event_cb (struct Lisp_Event *event) +{ + /* #### It would be nice to preserve some sort of ordering of the + ** #### different types of events, but that would be quite a bit + ** #### of work, and would more than likely break the abstraction + ** #### between the other event loops and this one. + */ + + if (!NILP (gpm_event_queue)) + { + Lisp_Object queued_event = dequeue_event (&gpm_event_queue, &gpm_event_queue_tail); + *event = *(XEVENT (queued_event)); + + if (event->event_type == pointer_motion_event) + { + struct device *d = decode_device (event->channel); + int fd = DEVICE_INFD (d); + + /* Ok, now this is just freaky. Bear with me though. + ** + ** If you run gnuclient and attach to a XEmacs running in + ** X or on another TTY, the mouse cursor does not get + ** drawn correctly. This is because the ioctl() fails + ** with EPERM because the TTY specified is not our + ** controlling terminal. If you are the superuser, it + ** will work just spiffy. The appropriate source file (at + ** least in linux 2.2.x) is + ** .../linux/drivers/char/console.c in the function + ** tioclinux(). The following bit of code is brutal to + ** us: + ** + ** if (current->tty != tty && !suser()) + ** return -EPERM; + ** + ** I even tried setting us as a process leader, removing + ** our controlling terminal, and then using the TIOCSCTTY + ** to set up a new controlling terminal, all with no luck. + ** + ** What is even weirder is if you run XEmacs in a VC, and + ** attach to it from another VC with gnuclient, go back to + ** the original VC and hit a key, the mouse pointer + ** displays (in BOTH VCs), until you hit a key in the + ** second VC, after which it does not display in EITHER + ** VC. Bizarre, no? + ** + ** All I can say is thank god Linux comes with source code + ** or I would have been completely confused. Well, ok, + ** I'm still completely confused. I don't see why they + ** don't just check the permissions on the device + ** (actually, if you have enough access to it to get the + ** console's file descriptor, you should be able to do + ** with it as you wish, but maybe that is just me). + ** + ** William M. Perry - Nov 9, 1999 + */ + + Gpm_DrawPointer (event->event.motion.x,event->event.motion.y, fd); + } + + return; + } + + return (orig_next_event_cb (event)); +} + +static void hook_event_callbacks_once (void) +{ + static int hooker; + + if (!hooker) + { + orig_event_pending_p = event_stream->event_pending_p; + orig_next_event_cb = event_stream->next_event_cb; + event_stream->event_pending_p = gpm_event_pending_p; + event_stream->next_event_cb = gpm_next_event_cb; + hooker = 1; + } +} + +static void hook_console_methods_once (void) +{ + static int hooker; + + if (!hooker) + { + /* Install the mouse position methods for the TTY console type */ + CONSOLE_HAS_METHOD (tty, get_mouse_position); + CONSOLE_HAS_METHOD (tty, set_mouse_position); + CONSOLE_HAS_METHOD (tty, get_foreign_selection); + CONSOLE_HAS_METHOD (tty, selection_exists_p); +#if 0 + CONSOLE_HAS_METHOD (tty, own_selection); +#endif + } +} + +DEFUN ("gpm-enabled-p", Fgpm_enabled_p, 0, 1, 0, /* +Return non-nil if GPM mouse support is currently enabled on DEVICE. +*/ + (device)) +{ + char *console_name = ttyname (DEVICE_INFD (decode_device (device))); + char process_name[1024]; + Lisp_Object proc; + + if (!console_name) + { + return (Qnil); + } + + memset (process_name, '\0', sizeof(process_name)); + snprintf (process_name, sizeof(process_name) - 1, "gpm for %s", console_name); + + proc = Fget_process (build_string (process_name)); + + if (NILP (proc)) + { + return (Qnil); + } + + if (1) /* (PROCESS_LIVE_P (proc)) */ + { + return (Qt); + } + return (Qnil); +} + +DEFUN ("gpm-enable", Fgpm_enable, 0, 2, 0, /* +Toggle accepting of GPM mouse events. +*/ + (device, arg)) +{ + Gpm_Connect conn; + int rval; + Lisp_Object gpm_process; + Lisp_Object gpm_filter; + struct device *d = decode_device (device); + int fd = DEVICE_INFD (d); + char *console_name = ttyname (fd); + char process_name[1024]; + + hook_event_callbacks_once (); + hook_console_methods_once (); + + if (noninteractive) + { + error ("Can't connect to GPM in batch mode."); + } + + if (!console_name) + { + /* Something seriously wrong here... */ + return (Qnil); + } + + memset (process_name, '\0', sizeof(process_name)); + snprintf (process_name, sizeof(process_name) - 1, "gpm for %s", console_name); + + if (NILP (arg)) + { + turn_off_gpm (process_name); + return (Qnil); + } + + /* DANGER DANGER. + ** Though shalt not call (gpm-enable t) after we have already + ** started, or stuff blows up. + */ + if (!NILP (Fgpm_enabled_p (device))) + { + error ("GPM already enabled for this console."); + } + + conn.eventMask = GPM_DOWN|GPM_UP|GPM_MOVE|GPM_DRAG; + conn.defaultMask = GPM_MOVE; + conn.minMod = 0; + conn.maxMod = ((1<; Sun, 14 Nov 1999 00:01:57 -0500 Received: by crystal.WonderWorks.COM id QQhpfh03750; Sat, 13 Nov 1999 15:17:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14381.61857.452475.536489@crystal.WonderWorks.COM> Date: Sat, 13 Nov 1999 15:17:53 -0800 (PST) From: Kyle Jones To: XEmacs-Beta Subject: Re: XEmacs 21.2.20 "Yoko" is released In-Reply-To: <199911130432.FAA19775@vals.intramed.rito.no> References: <14380.47769.516350.36895@crystal.WonderWorks.COM> <199911130432.FAA19775@vals.intramed.rito.no> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Terje Bless writes: > On 12.11.99 at 17:10, Kyle Jones wrote: > > >Yah, this is the place, historically speaking. > > And, historically speaking, 640K ought to be enough? :-) > > Not arguing either way; just nitpicking. It struck me as odd is all. If a > patch breaks something, the sane thing to do is to bitch at whomever > touched the patch last not the one who came up with the idea. In that case, the best place to look is the ChangeLog file. From owner-xemacs-beta@xemacs.org Sun Nov 14 00:19:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA05589 for xemacs-beta-out; Sun, 14 Nov 1999 00:19:50 -0500 Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [202.216.228.37]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA05584 for ; Sun, 14 Nov 1999 00:19:48 -0500 Received: from orihime.remus.dti.ne.jp (PPP71.tokyo-ap3.dti.ne.jp [210.170.144.71]) by smtp2.dti.ne.jp (8.9.3/3.7W) with ESMTP id OAA24060 for ; Sun, 14 Nov 1999 14:19:43 +0900 (JST) From: Tsukamoto Tetsuo To: xemacs-beta@xemacs.org Subject: [XEmacs 21.2.20] Widget's odd behaviour X-Face-Version: X-Face utility v1.3.6 - "Yellow Submarine (remix)" with Select X-Face v0.13 - "Junk" X-Face: *IhG%k^cb!\'Z`No2BN]U=$@5S0wq)wnsVzo}Ax|r+=/HO{/@BqFQ{8JnG&fs#vs^]Bxn=o M32pJUEKU5j^lRe!R1jl`@IQUHpdc.@sb#!EiE"2,NgIIv*T\fofNj.gNwX/*%minqsQ'rEc/cKFkahYu$R2ZS!Q~!P^miru`> X-Gnus-Offline-Backend: Gnus offline backend utiliy v2.20 - "Cup of life" with nnagent 1.0 MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 14 Nov 1999 14:21:57 +0900 Message-ID: User-Agent: T-gnus/6.13.3 (based on Pterodactyl Gnus v0.98) SEMI/1.13.7 (Awazu) CLIME/1.13.5 (=?ISO-2022-JP?B?GyRCMkMybEohMiwbKEI=?=) MULE XEmacs/21.2 (beta20) (Yoko) (i586-mazekoze-linux) Linux version 2.2.13 for NEC PC-9800 002pre Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In the *scratch* buffer, evaluate the form below. (widget-create 'push-button :tag "ignore" :help-echo "ignore" :action 'ignore) The button appears. Type C-h k and click the button, help says misc-user runs (funcall (quote widget-gui-action) (quote (push-button :action ignore :help-echo ignore :tag ignore))) Seems weired. Then get back to the last form and evaluate it again. The two "ignore" buttons both flicker for ever. Again type C-h k and click one of them (though a little difficult due to the flickering :-), help says button1 runs `widget-button1-click' Isn't it what it should be? -- Tsukamoto, Tetsuo From owner-xemacs-beta@xemacs.org Sun Nov 14 04:02:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA09756 for xemacs-beta-out; Sun, 14 Nov 1999 04:02:51 -0500 Received: from lsppc4.epfl.ch (lsppc4.epfl.ch [128.178.75.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA09753 for ; Sun, 14 Nov 1999 04:02:48 -0500 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id KAA08787; Sun, 14 Nov 1999 10:02:46 +0100 To: xemacs-beta@xemacs.org Subject: Re: I need help from a signal expert ! References: X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Sun_Nov_14_10:02:38_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 14 Nov 1999 10:02:46 +0100 In-Reply-To: Jan Vroonhof's message of "13 Nov 1999 20:32:02 +0100" Message-ID: Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Sun_Nov_14_10:02:38_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Jan" == Jan Vroonhof writes: Jan> Oscar Figueiredo writes: >> surrounded by {slow_down,speed_up}_interrupts. I even tried >> `stop_interrupts> and `start_interrupts' with no success. I can't >> understand why it works for searches (which also call `ldap_result') and >> not for addition and deletion. Jan> That could just be some timing issue. It could also be that there is a Jan> file descriptor involved that unrequest_sigio doesn't know about. >> I'd appreciate very much some help from someone knowledgeable in >> this area. Jan> Could you check with strace or truss which signal is interrupting the Jan> syscal? >From what I saw in DDD, it's a SIGIO. I have been investigating the problem a little further since my last post and it appears that `slow_down_interrupts' does not disable SIGIO correctly at least on RedHat 6.0 Linux. Adding a pair of EMACS_{UN}BLOCK_SIGNAL (SIGIO); around calls to `ldap_result' solves the problem. Therefore I believe `unrequest_sigio' (called from `slow_down_interrupts') is not doing its job correctly. Oscar --pgp-sign-Multipart_Sun_Nov_14_10:02:38_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOC56tJ7CaiYEgqPZAQFW2AH8CiMLN7fGBtXyEeksE7KAnjRZyWVtMtpZ Lz1VIUoRBQw8ByA7mRduL/pyuDhTb+rqCN8ANYJqgt7z2mWvf9fdsg== =o3ut -----END PGP MESSAGE----- --pgp-sign-Multipart_Sun_Nov_14_10:02:38_1999-1-- From owner-xemacs-beta@xemacs.org Sun Nov 14 05:34:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA11311 for xemacs-beta-out; Sun, 14 Nov 1999 05:34:28 -0500 Received: from lsppc4.epfl.ch (lsppc4.epfl.ch [128.178.75.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA11308 for ; Sun, 14 Nov 1999 05:34:26 -0500 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id LAA09336; Sun, 14 Nov 1999 11:34:25 +0100 To: xemacs-beta@xemacs.org Subject: Re: I need help from a signal expert ! References: <199911131913.LAA15014@mina.sr.hp.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Sun_Nov_14_11:28:32_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 14 Nov 1999 11:34:24 +0100 In-Reply-To: Darryl Okahata's message of "Sat, 13 Nov 1999 11:13:43 -0800" Message-ID: Lines: 41 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Sun_Nov_14_11:28:32_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Darryl" == Darryl Okahata writes: Darryl> Oscar Figueiredo wrote: >> The problem boils down to a select function being interrupted (errno=EINTR) i >> n >> a call to `ldap_result'. Darryl> Which ldap libraries are you using? The low-level ldap code should Darryl> handle EINTR during select() and restart. Looking over the source code, Darryl> the UM-LDAP libraries appear to do so. You're very right. Thanks a lot for pointing that out, I've been toying with those libraries for months and I missed that !!! I guess it's because it's not mentioned in the RFC but it's in the man pages, I should have seen it ! There's indeed an option in the LDAP API that restarts a select() call when interrupted with EINTR. I activated it now and I do not need the {slow_down,speed_up}_interrupt calls anymore... Feel free to flame me... :-( Oscar --pgp-sign-Multipart_Sun_Nov_14_11:28:32_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOC6O1Z7CaiYEgqPZAQFt0QH+N/lkzdYtPhRK5VkiciN/8CctgVTRYoKa QSCNtSysNrHxuOq6DuDDAXm6GedvvjHyyr6a5/WQ8T7LifPbjq4Ojg== =hOFK -----END PGP MESSAGE----- --pgp-sign-Multipart_Sun_Nov_14_11:28:32_1999-1-- From owner-xemacs-beta@xemacs.org Sun Nov 14 06:13:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA11860 for xemacs-beta-out; Sun, 14 Nov 1999 06:13:02 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA11856 for ; Sun, 14 Nov 1999 06:12:59 -0500 Received: from 666.com (dialup01ip054.tus.azstarnet.com [169.197.30.54]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id EAA18761; Sun, 14 Nov 1999 04:12:33 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <382E9902.538EEE4E@666.com> Date: Sun, 14 Nov 1999 04:12:02 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Oscar Figueiredo CC: xemacs-beta@xemacs.org Subject: Re: I need help from a signal expert ! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Although you seem to have solved your problems through a different library, I think it would be worthwhile to step through unrequest_sigio() and see what functions are actually being called to affect the SIGIO signal. It's quite possible that something is indeed wrong here and needs fixing. If so, it's going to affect lots of places, and presumably all RedHat 6.0 users, and definitely needs to be fixed. If you can't figure out what's going on, at least put in a #### comment in the right place indicating that this function apparently doesn't do its job on RH 6.0, which could lead to a lot of strange results. ben Oscar Figueiredo wrote: > >>>>> "Jan" == Jan Vroonhof writes: > > Jan> Oscar Figueiredo writes: > > >> surrounded by {slow_down,speed_up}_interrupts. I even tried > >> `stop_interrupts> and `start_interrupts' with no success. I can't > >> understand why it works for searches (which also call `ldap_result') and > >> not for addition and deletion. > > Jan> That could just be some timing issue. It could also be that there is a > Jan> file descriptor involved that unrequest_sigio doesn't know about. > > >> I'd appreciate very much some help from someone knowledgeable in > >> this area. > > Jan> Could you check with strace or truss which signal is interrupting the > Jan> syscal? > > >From what I saw in DDD, it's a SIGIO. I have been investigating the problem a > little further since my last post and it appears that `slow_down_interrupts' > does not disable SIGIO correctly at least on RedHat 6.0 Linux. > > Adding a pair of EMACS_{UN}BLOCK_SIGNAL (SIGIO); around calls to `ldap_result' > solves the problem. Therefore I believe `unrequest_sigio' (called from > `slow_down_interrupts') is not doing its job correctly. > > Oscar > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit From owner-xemacs-beta@xemacs.org Sun Nov 14 07:26:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA13384 for xemacs-beta-out; Sun, 14 Nov 1999 07:26:26 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA13374; Sun, 14 Nov 1999 07:26:24 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA22060; Sun, 14 Nov 1999 13:26:23 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005Oe; Sun Nov 14 13:26:17 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id NAA02586; Sun, 14 Nov 1999 13:26:16 +0100 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: latest GPM patch... References: <86vh75yjje.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 14 Nov 1999 13:26:16 +0100 In-Reply-To: wmperry@aventail.com's message of "13 Nov 1999 20:00:05 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > Index: lisp/gpm.el > =================================================================== > --- lisp/gpm.el Tue May 5 15:32:27 1998 > +++ lisp/gpm.el Mon Nov 8 11:22:39 1999 Thanks, I'll have one more look at them and then apply them to 21.2. I assume the ChangeLogs you posted before are still current. Jan From owner-xemacs-beta@xemacs.org Sun Nov 14 09:08:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA15140 for xemacs-beta-out; Sun, 14 Nov 1999 09:08:04 -0500 Received: from lsppc4.epfl.ch (lsppc4.epfl.ch [128.178.75.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA15136 for ; Sun, 14 Nov 1999 09:08:02 -0500 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id PAA15339; Sun, 14 Nov 1999 15:08:00 +0100 To: xemacs-beta@xemacs.org Subject: stop_interrupts not working (was: Re: I need help from a signal expert !) References: <382E9902.538EEE4E@666.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Sun_Nov_14_15:07:54_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 14 Nov 1999 15:08:00 +0100 In-Reply-To: Ben Wing's message of "Sun, 14 Nov 1999 04:12:02 -0700" Message-ID: Lines: 47 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Sun_Nov_14_15:07:54_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Ben" == Ben Wing writes: Ben> Although you seem to have solved your problems through a different library, I think Ben> it would be worthwhile to step through unrequest_sigio() and see what functions are Ben> actually being called to affect the SIGIO signal. It's quite possible that Ben> something is indeed wrong here and needs fixing. If so, it's going to affect lots Ben> of places, and presumably all RedHat 6.0 users, and definitely needs to be fixed. Ben> If you can't figure out what's going on, at least put in a #### comment in the Ben> right place indicating that this function apparently doesn't do its job on RH 6.0, Ben> which could lead to a lot of strange results. Ben> ben I made some more tests. The function `emacs_sleep' appears not to be working for me. strace confirms that it is interrupted by a series of SIGIO signals. The debugger shows that the function `unrequest_sigio_on_device' is executed properly for a series of devices. Apparently a few are missing from the loop. I made the same test with xemacs -nw and the problem does not show up in that case. The guilty device(s) seem therefore to be X-related. I have no idea how to trace the SIGIOs back to the device(s) that generated them. I wonder, in the function `stop_interrupts', instead of calling unrequest_sigio which disables SIGIO on each device one by one, wouldn't it be faster and safer to simply disable SIGIO as a whole with a call to EMACS_BLOCK_SIGNAL (SIGIO) ? Oscar --pgp-sign-Multipart_Sun_Nov_14_15:07:54_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOC7CPp7CaiYEgqPZAQEMeAH/UH6yhSd2L63SD7wMngqUMVFV3tBbTl3t ijiBKON9963OXxWbm2j7OPiAvqJN/35qMyEQ8Lk9VsRzvIM6ZgMjEQ== =ftge -----END PGP MESSAGE----- --pgp-sign-Multipart_Sun_Nov_14_15:07:54_1999-1-- From owner-xemacs-beta@xemacs.org Sun Nov 14 10:35:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA16572 for xemacs-beta-out; Sun, 14 Nov 1999 10:35:00 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA16569 for ; Sun, 14 Nov 1999 10:34:58 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA27687; Sun, 14 Nov 1999 16:34:57 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006k.; Sun Nov 14 16:34:52 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA02893; Sun, 14 Nov 1999 16:34:51 +0100 To: Oscar Figueiredo Cc: xemacs-beta@xemacs.org Subject: Re: stop_interrupts not working (was: Re: I need help from a signal expert !) References: <382E9902.538EEE4E@666.com> From: Jan Vroonhof Date: 14 Nov 1999 16:34:50 +0100 In-Reply-To: Oscar Figueiredo's message of "14 Nov 1999 15:08:00 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > I made the same test with xemacs -nw and the problem does not show up in that > case. The guilty device(s) seem therefore to be X-related. I don't think you can include that so easily. terminal devices produce much less I/O. > I have no idea how to trace the SIGIOs back to the device(s) that generated > them. Call select? Jan From owner-xemacs-beta@xemacs.org Sun Nov 14 13:05:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA19314 for xemacs-beta-out; Sun, 14 Nov 1999 13:05:42 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA19311 for ; Sun, 14 Nov 1999 13:05:38 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11n41t-00066f-00 for ; Sun, 14 Nov 1999 19:05:33 +0100 From: Hrvoje "Martin" Niksic To: XEmacs Beta List Subject: Cosmetic fixes X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Lines: 68 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin alert. Except that I'm not Martin. Index: src/lread.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lread.c,v retrieving revision 1.36.2.13 diff -u -r1.36.2.13 lread.c --- lread.c 1999/10/10 12:40:11 1.36.2.13 +++ lread.c 1999/11/14 18:04:39 @@ -903,17 +903,18 @@ nil, a list, or a string (for backward compatibility), with the following semantics: - a) nil - no suffix, just search for file name intact (semantically - different from "empty suffix list") + a) nil - no suffix, just search for file name intact + (semantically different from "empty suffix list", which + would be meaningless.) b) list - list of suffixes to append to file name. Each of these must be a string. c) string - colon-separated suffixes to append to file name (backward compatibility). - All of this got hairy, so I decided to use write a mapper. Calling - a function for each suffix shouldn't slow things down, since - locate_file is rarely call with enough suffixes for it to make a - difference. */ + All of this got hairy, so I decided to use a mapper. Calling a + function for each suffix shouldn't slow things down, since + locate_file is rarely called with enough suffixes for funcalls to + make any difference. */ /* Map FUN over SUFFIXES, as described above. FUN will be called with a char * containing the current file name, and ARG. Mapping stops when Index: etc/NEWS =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/etc/NEWS,v retrieving revision 1.58.2.23 diff -u -r1.58.2.23 NEWS --- NEWS 1999/09/26 19:46:46 1.58.2.23 +++ NEWS 1999/11/14 18:04:40 @@ -236,15 +236,21 @@ colon-separated string. MODE is now a symbol or a list of symbols (symbols `exists', `executable', `writable', and `readable' are supported) instead of an integer code. See the documentation for -details. +details. Of course, the old form is still accepted for backward +compatibility. -Of course, the old form is still accepted for backward compatibility. +Several bugs in locate-file have been fixed, most notably its failure +to call expand-file-name on elements of PATH-LIST. Because of that +elements of load-path of the form "~/..." used to not work. +locate-file is now guaranteed to expand files during its course of +operation. ** `translate-region' has been improved in several ways. Its TABLE argument used to be a 256-character string. In addition to this, it -can now also be a vector or a char-table (which is useful for Mule.) -If TABLE a vector or a generic char-table, you can map characters to -strings instead of to other characters. For instance: +can now also be a vector or a char-table, which makes the function +useful for Mule, which it wasn't. If TABLE a vector or a generic +char-table, you can map characters to strings instead of to other +characters. For instance: (let ((table (make-char-table 'generic))) (put-char-table ?a "the letter a" table) From owner-xemacs-beta@xemacs.org Sun Nov 14 14:11:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA21109 for xemacs-beta-out; Sun, 14 Nov 1999 14:11:40 -0500 Received: from rasp.eng.cam.ac.uk (rasp.eng.cam.ac.uk [129.169.8.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA21100 for ; Sun, 14 Nov 1999 14:11:38 -0500 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by rasp.eng.cam.ac.uk with ESMTP id TAA14419; Sun, 14 Nov 1999 19:11:19 GMT Received: from kennet.eng.cam.ac.uk (via kennet [129.169.81.54]) by tigger.eng.cam.ac.uk with ESMTP id TAA24229; Sun, 14 Nov 1999 19:11:17 GMT Received: (via ge204@localhost) by kennet.eng.cam.ac.uk id TAA22962; Sun, 14 Nov 1999 19:11:16 GMT To: Hrvoje "Martin" Niksic Cc: XEmacs Beta List Subject: Re: Cosmetic fixes References: <9t9aeohne36.fsf@mraz.iskon.hr> From: Gunnar Evermann In-Reply-To: Hrvoje "Martin" Niksic's message of "14 Nov 1999 19:05:33 +0100" Date: 14 Nov 1999 19:11:15 +0000 Message-ID: Lines: 12 User-Agent: Gnus/5.070092 (Pterodactyl Gnus v0.92) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje "Martin" Niksic writes: > Martin alert. Except that I'm not Martin. > [snip patches] Hey, where are the ChangeLogs? Sorry, couldn't resist -- I'm sure that's the response Martin would have expected :-) Gunnar From owner-xemacs-beta@xemacs.org Sun Nov 14 14:19:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA21446 for xemacs-beta-out; Sun, 14 Nov 1999 14:19:57 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id OAA21438 for ; Sun, 14 Nov 1999 14:19:55 -0500 Received: (qmail 25197 invoked from network); 14 Nov 1999 19:18:38 -0000 Received: from usrpri2-15.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.80) by biff.kiva.net with SMTP; 14 Nov 1999 19:18:38 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id OAA18349; Sun, 14 Nov 1999 14:21:39 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: latest GPM patch... References: <86vh75yjje.fsf@megalith.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > wmperry@aventail.com (William M. Perry) writes: > > > Index: lisp/gpm.el > > =================================================================== > > --- lisp/gpm.el Tue May 5 15:32:27 1998 > > +++ lisp/gpm.el Mon Nov 8 11:22:39 1999 > > Thanks, > > I'll have one more look at them and then apply them to 21.2. I assume > the ChangeLogs you posted before are still current. Yes. -bp From owner-xemacs-beta@xemacs.org Sun Nov 14 18:56:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA26883 for xemacs-beta-out; Sun, 14 Nov 1999 18:56:50 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA26879; Sun, 14 Nov 1999 18:56:48 -0500 Received: from 666.com (dialup18ip048.tus.azstarnet.com [169.197.38.176]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id QAA18186; Sun, 14 Nov 1999 16:56:26 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <382F4C0A.2949CB1A@666.com> Date: Sun, 14 Nov 1999 16:55:54 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Oscar Figueiredo CC: XEmacs Review , XEmacs beta list Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Why don't you use a more standard API? LDAP is basically a database, so why don't you model the API after the other database interfaces in XEmacs? ben Oscar Figueiredo wrote: > LDAP calls should now be more robust with regard to interruptions. New > functions for adding and deleting records from an LDAP server. Record > modification is on its way. > > Oscar > > 1999-11-14 Oscar Figueiredo > > * eldap.h(Fldap_add_internal, Fldap_delete_internal): New > functions > * eldap.c (Fldap_add_internal, Fldap_delete_internal): New > functions > (Fldap_open): Set the `LDAP_OPT_RESTART' option to avoid LDAP > calls being interrupted by XEmacs signals > (Fldap_search_internal): Remove useless calls to > `slow_down_interrupts' and `speed_up_interrupts' > > 1999-11-14 Oscar Figueiredo > > * ldap.el (toplevel): Signal error when XEmacs has been compiled > without LDAP > (ldap-add, ldap-delete): New defuns From owner-xemacs-beta@xemacs.org Sun Nov 14 19:18:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA27637 for xemacs-beta-out; Sun, 14 Nov 1999 19:18:25 -0500 Received: from unknown (1Cust220.tnt3.atl2.da.uu.net [63.22.17.220]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id TAA27498; Sun, 14 Nov 1999 19:15:26 -0500 From: art1234@pacsun.com Subject: laser printer toner advertisement Date: Sun, 15 Nov 1998 15:30:42 Message-Id: <839.665950.115907@> To: undisclosed-recipients:; Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. From owner-xemacs-beta@xemacs.org Sun Nov 14 19:40:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA28508 for xemacs-beta-out; Sun, 14 Nov 1999 19:40:21 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id TAA28502 for ; Sun, 14 Nov 1999 19:40:18 -0500 Received: (qmail 12210 invoked from network); 15 Nov 1999 00:39:02 -0000 Received: from usrpri2-61.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.126) by biff.kiva.net with SMTP; 15 Nov 1999 00:39:02 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id TAA19558; Sun, 14 Nov 1999 19:42:00 -0500 To: Ben Wing Cc: Oscar Figueiredo , XEmacs Review , XEmacs beta list Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes X-Now-Listening-To: Annie Lennox - Don't Let It Bring You Down References: <382F4C0A.2949CB1A@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Why don't you use a more standard API? LDAP is basically a database, so > why don't you model the API after the other database interfaces in > XEmacs? The other databases have no heirarchy to them, and they are all file based. You could pervert the 'file' argument to open-database to be a database or hostname. The other main problem is that get-database currently expects there to be only one value per 'key'. To merge the LDAP code, you would have to do a major overhaul of the existing database code, and I'm not sure you would be able to get the full power of LDAP without making the 'normal' databases pretty difficult to use. -Bill P. From owner-xemacs-beta@xemacs.org Sun Nov 14 21:26:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA31554 for xemacs-beta-out; Sun, 14 Nov 1999 21:26:15 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA31545 for ; Sun, 14 Nov 1999 21:26:13 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 22563472F; Sun, 14 Nov 1999 21:32:36 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Re: Ethiopic in 21.1.7++ References: <14369.5571.420089.132460@turnbull.sk.tsukuba.ac.jp> <87yac8xde3.fsf@dp50.ecc.u-tokyo.ac.jp> From: Vin Shelton Organization: The XEmacs Development Team Date: 14 Nov 1999 21:32:36 -0500 In-Reply-To: Yoshiki Hayashi's message of "09 Nov 1999 17:44:36 +0900" Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I did not have mule-base installed when I ran my very simple test of attempting to set each language environment one at a time. None of the other language environments gave me a problem, BTW. - vin >>>>> On 09 Nov 1999, Yoshiki Hayashi said: Yoshiki> "Stephen J. Turnbull" writes: >> >>>>> "Jan" == Jan Vroonhof writes: >> Jan> Vin Shelton writes: >> >> Symbol's function definition is void: >> >> setup-ethiopic-environment-internal >> >> >> >> I'd like to get this working before I release 21.1.8 (tonight, >> >> I hope). Can anyone offer a patch? >> >> This looks like the same thing that was happening with Japanese and >> some other languages. The FSF changed the language environemnt API, >> and that got ported to a couple of language environments but not >> the rest. :-( Yoshiki> Like Jan said, it must not be Symbol's function definition Yoshiki> is void error since it is defined at ethio-util.el Maybe Vin Yoshiki> hasn't installed mule-base? However, it requires Yoshiki> exit-function handling to be implemented in Yoshiki> setup-language-environment so it is problematic to use code Yoshiki> in ethio-util.el (it defines f2, f3 and other keys so after Yoshiki> setting up Ethiopic language environment in XEmacs 21.1, the Yoshiki> original definition of those keys won't be recovered). Jan> I tried making the obvious path (namely copying Jan> 'setup-ethiopic-environment-internal from an old mule base Jan> into the core), however then I stopped. auto-autoloads.el Jan> from mule-base contains >> >> Ethiopic is one of the things that got ported from FSF and ignored, I >> think disabling it is the best route until somebody is willing to take >> a good look at it. Yoshiki> I think so, too. Until someone who knows Ethiopic is going Yoshiki> to use and test it, removing Ethiopic support would not Yoshiki> hurt. >> That is my suggestion for any non-ISO-8859, non-Asian-ideographic >> language that breaks, unfortunately. I think a real solution to this, >> one that is robust to ++patchlevel, even, will have to wait until we >> define real APIs for Mule and convince porters from FSF to stick to >> them. Yoshiki> Yes, we need APIs. From owner-xemacs-beta@xemacs.org Sun Nov 14 21:41:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA32051 for xemacs-beta-out; Sun, 14 Nov 1999 21:41:24 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA32047 for ; Sun, 14 Nov 1999 21:41:17 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw301.ecc.u-tokyo.ac.jp [133.11.171.251]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id LAA00620; Mon, 15 Nov 1999 11:41:14 +0900 (JST) Mail-Copies-To: never To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 15 Nov 1999 11:33:27 +0900 In-Reply-To: <9t9ogd0dszb.fsf@mraz.iskon.hr> (Hrvoje Niksic's message of "Fri, 12 Nov 1999 09:17:12 +0100") Message-ID: <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 49 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > As Ben said, now that we've fixed the actual bugs, we can think about > changing the behaviour for int-char conversions for 21.2. Following are proposed which integers should be accepted where characters are expected: 1) Don't allow anything 2) Accept 0-127 3) Accept 0-256 4) Accept everything Other things proposed are: a) When doing C-q, treat 128-256 as Latin-2 in Latin 2 language environment. So far, most of the proposal is intended to apply to every int-char conversions, I'd like to make some functions to accept. My plan is: Accept only 0-256 in every place except int-to-char. int-to-char accepts every valid integers. Make new function which does int-to-char conversion correctly according to the language environment. This way, most of the code which does (insert (1+ ?a)) or something continues working. Now internal representation is changed a little bit, so disabling > 256 characters will warn those who are dealing with internal representation directly, which is bad. Still, you can do (let ((i 1442)) (while (i < 2000) (insert (int-to-char i)) (setq i (+1 i)))) to achieve old behaviour. For C-q, I'm not for changing it's original definition, since it might confuse people who are expecting Latin-1 in other language environment and typing just 1 integer doesn't make sense for multibyte world. It's cleaner to make new function, which does make-char according to the charset of language-info-alist so that people who use that often can bind it to C-q or some other keys. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Sun Nov 14 23:27:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA02011 for xemacs-beta-out; Sun, 14 Nov 1999 23:27:09 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA02008 for ; Sun, 14 Nov 1999 23:27:06 -0500 Received: by localhost id m11nDjL-00016RC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 15 Nov 1999 13:27:03 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14383.35735.457609.476890@turnbull.sk.tsukuba.ac.jp> Date: Mon, 15 Nov 1999 13:27:03 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: Swallowing windows in X... In-Reply-To: References: <86so2benle.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> wmperry@aventail.com (William M. Perry) writes: >> Anybody with more X experience want to comment? Basically, I >> changed x_subwindow_instantiate() to do: Jan> I am not an X expert, but I can stand on the shoulders of Rob Jan> Nation (from the FVWM 2.2 sources:) I don't know to what extent fvwm does fancy redisplay. Another place to look would be the MagicPoint code http://www.mew.org/MagicPoint/, although I'm not sure they do anything particularly fancy either. One advantage to the MagicPoint code is that I know that swallowing windows can help crash MagicPoint, so there's definitely some "don't do it this way" educational value. ;-) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Sun Nov 14 23:31:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA02134 for xemacs-beta-out; Sun, 14 Nov 1999 23:31:21 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA02129 for ; Sun, 14 Nov 1999 23:31:19 -0500 Received: by localhost id m11nDnR-00016RC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 15 Nov 1999 13:31:17 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> Date: Mon, 15 Nov 1999 13:31:17 +0900 (JST) To: XEmacs beta list Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes In-Reply-To: <86yac04mco.fsf@megalith.bp.aventail.com> References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "-BP" == William M Perry writes: -BP> To merge the LDAP code, you would have to do a major overhaul -BP> of the existing database code, and I'm not sure you would be -BP> able to get the full power of LDAP without making the -BP> 'normal' databases pretty difficult to use. OK, that's why it might be hard. It still sounds like it's a good idea to me. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 15 03:23:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA06901 for xemacs-beta-out; Mon, 15 Nov 1999 03:23:56 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA06898 for ; Mon, 15 Nov 1999 03:23:53 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11nHQU-0006L1-00 for ; Mon, 15 Nov 1999 09:23:50 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 Nov 1999 09:23:50 +0100 In-Reply-To: Yoshiki Hayashi's message of "15 Nov 1999 11:33:27 +0900" Message-ID: <9t9g0y8f9ih.fsf@mraz.iskon.hr> Lines: 20 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: > Make new function which does int-to-char conversion > correctly according to the language environment. [...] > For C-q, I'm not for changing it's original definition, since it > might confuse people who are expecting Latin-1 in other language > environment I don't think there really are many people in Latin * environments who want C-q to mean "insert a Latin 1 character". The vast majority will want to get their "native" character. The function you propose above would be mostly useless, as `make-char' already does the job, with some work required to convert the "language environment" to a charset. > and typing just 1 integer doesn't make sense for multibyte world. I don't leave in the multibyte word, so I want to type 1 integer. From owner-xemacs-beta@xemacs.org Mon Nov 15 03:57:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA07481 for xemacs-beta-out; Mon, 15 Nov 1999 03:57:18 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA07477; Mon, 15 Nov 1999 03:57:14 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0377649E; Mon, 15 Nov 1999 09:57:12 +0100 (MET) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA22328; Mon, 15 Nov 1999 09:57:01 +0100 To: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 15 Nov 1999 09:57:01 +0100 In-Reply-To: sperber@Informatik.Uni-Tuebingen.De's message of "08 Nov 1999 15:27:52 +0100" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA07479 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm not sure I'm seeing through the RMS #ifdef maze in movemail: What mail locking method should be the default on Cygwin? (Please reply to me directly as well --- I'm not subscribed to xemacs-nt.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Mon Nov 15 05:39:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA09920 for xemacs-beta-out; Mon, 15 Nov 1999 05:39:44 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA09916 for ; Mon, 15 Nov 1999 05:39:42 -0500 Received: by localhost id m11nJXx-00016MC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 15 Nov 1999 19:39:41 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> Date: Mon, 15 Nov 1999 19:39:40 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> This way, most of the code which does (insert (1+ ?a)) or Yoshiki> something continues working. But only in the range of Latin-1. It _currently_ works in Mule because of the dependence of representation on character sets. But it will stop working, in particular for all other Latin-* character sets and kanji, if we go to a Unicode-based internal encoding. I guess most scripts will be OK, since they get their own ranges, and those in general are contiguous to allow this kind of optimization. But any scripts using lots of unified characters (accented characters in Latin-* and kanji) are hosed. Yoshiki> Now internal representation is changed a little bit, so Yoshiki> disabling > 256 characters will warn those who are Yoshiki> dealing with internal representation directly, which is Yoshiki> bad. Dealing with the internal representation directly _is_ bad, period. People who do that deserve what they get. Unfortunately, innocent users sometimes get handed such code, and they should be protected. If we are going to continue to allow this, we should figure out what the API is supposed to be. Yoshiki> Still, you can do Yoshiki> (let ((i 1442)) Yoshiki> (while (i < 2000) Yoshiki> (insert (int-to-char i)) Yoshiki> (setq i (+1 i)))) This is exactly the kind of code that we should disallow. What does each of those 558 characters mean when inserted in the buffer? Surely most of them are not characters in any known character set. Should they be inserted? Ignored? Do you tell the user what you've done? In which functions do you want to put the checking code? What are you supposed to do with the integers that are not characters: signal an error, display a warning, set a flag for user code to check? One thing to do with this kind of code is to fix the arithmetic functions to check the type of the object, and have them (eg) return an object cast to the type of the first operand. Maybe they should make the (probably slow) check that the result is really a valid object of that type. And then they should do something sensible if it's invalid. The problem is that none of the questions above have been answered, including, "what's `sensible' behavior for undefined characters?" If you want to maintain backwards compatibility so that broken code will not signal errors on ambiguous operations, OK, I can understand that doing it right is hard and "mendokusai." But let's not fix things so that broken code accidentally does the right thing more often, and bind ourselves to more backwards-compatibility kludges in the future. Yoshiki> It's cleaner to make new function, which does make-char Yoshiki> according to the charset of language-info-alist so that Yoshiki> people who use that often can bind it to C-q or some Yoshiki> other keys. Possibly you should make a new function for C-q; it should have an optional argument which can either be a language environment or a charset. You could redefine make-char that way, although I don't like that much. Probably charsets should be preferred in case there's a name conflict. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 15 06:01:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA10570 for xemacs-beta-out; Mon, 15 Nov 1999 06:01:43 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA10567 for ; Mon, 15 Nov 1999 06:01:41 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA28691; Mon, 15 Nov 1999 12:01:36 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0070F; Mon Nov 15 12:01:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA04217; Mon, 15 Nov 1999 12:01:32 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9g0y8f9ih.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 15 Nov 1999 12:01:30 +0100 In-Reply-To: Hrvoje Niksic's message of "15 Nov 1999 09:23:50 +0100" Message-ID: Lines: 13 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > I don't think there really are many people in Latin * environments who > want C-q to mean "insert a Latin 1 character". I am not sure. Don't forget that latin-1 is currently noconv-unix alias binary. I think there are lot of case where you use C-q where you are only interested in the byte that actually ends up in the file. i.e. C-x C-f newfile C-q 201 C-x RET b binary C-x C-s Jan From owner-xemacs-beta@xemacs.org Mon Nov 15 06:02:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA10594 for xemacs-beta-out; Mon, 15 Nov 1999 06:02:04 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA10591 for ; Mon, 15 Nov 1999 06:02:03 -0500 Received: (qmail 27049 invoked from network); 15 Nov 1999 11:00:45 -0000 Received: from usrpri2-37.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.102) by biff.kiva.net with SMTP; 15 Nov 1999 11:00:45 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA21064; Mon, 15 Nov 1999 06:03:38 -0500 To: "Stephen J. Turnbull" Cc: XEmacs beta list Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes X-Now-Listening-To: Beastie Boys - Shambala References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 115 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > >>>>> "-BP" == William M Perry writes: > > -BP> To merge the LDAP code, you would have to do a major overhaul > -BP> of the existing database code, and I'm not sure you would be > -BP> able to get the full power of LDAP without making the > -BP> 'normal' databases pretty difficult to use. > > OK, that's why it might be hard. It still sounds like it's a good > idea to me. Perhaps, but I think that the code to do anything ldap-ish would still look very ldap-ish as opposed to abstract-database-ish. Another big problem with LDAP vs. the other database types is the ability to have multiple values off of a single attribute, and each 'key' in the database can have multiple attributes. In LDAP you have: uid=wmperry,ou=aventail.com,c=us -> cn = William M. Perry Bill Perry Emacs Dork mail = wmperry@aventail.com The older database backends would require you to do: You could theoretically do: - extend open-database to take a plist, but this breaks all (any?) existing code. LDAP would be a generic instance with (open-database '(:host "ldap.in.aventail.com" :type ldap :subtype 3 :bind-username "something" :bind-password "somethingelse" :base "o=aventail.com, c=us")) - extend get-database to be able to return multiple hits for a key. (get-database KEY ATTRIBUTE DATABASE) Documentation: Return value(s) for ATTRIBUTE on object KEY in DATABASE. An assoc list is returned, the car of each entry in the list the attribute name. The cdr is a list of values for that attribute. If there is no corresponding value, return nil. If ATTRIBUTE is t, returns all attributes and values. (get-database "uid=wmperry, o=aventail.com, c=us" "mail" dbhandle) => '(("mail" "wmperry@aventail.com")) (get-database "uid=wmperry, o=aventail.com, c=us" "cn" dbhandle) => '(("mail" "wmperry@aventail.com") ("cn" "William M. Perry" "Bill Perry" "Emacs Dork")) - extend put-database to be able to set multiple hits for a key, and submit multiple changes at once. (put-database KEY VALUES DATABASE &optional replace) Documentation: Updated record KEY in DATABASE with new VALUES. VALUES is an assoc list of attribute/value pairs. Some databases support multiple values. If optional fourth arg REPLACE is non-nil, replace any existing entry in the database. This whole doc string needs better updates. :) (put-database "uid=wmperry, o=aventail.com, c=us" '("cn" "Willie Perry") dbhandle nil) => t Would _add_ a CN to the record, so we'd now look like: uid=wmperry,ou=aventail.com,c=us -> cn = William M. Perry Bill Perry Emacs Dork Willie Perry mail = wmperry@aventail.com - New function search-database (search-database DATABASE CRITERIA) Documentation: Search DATABASE for records matching CRITERIA. CRITERIA is a property list. It is up to the backend database to convert this to native representation. Maybe we could have something for this that looks more lispish than an LDAP request. I'm not sure how a berkeley db database would implement this. For LDAP, we could have something like: (search-database dbhandle '(& (| ("cn" "William M. Perry" "Bill Perry")) ("mail" "wmperry@aventail.com"))) The ldap backend would convert this into: "(& (| (cn=William M. Perry") (cn="Bill Perry")) (mail=wmperry@aventail.com"))" And pass that off to ldap_search() - map-database would have to be revamped to return new values, etc. It would be nice if you could register new database backends at runtime, even for lisp functions. Then you could write an SQL backend in lisp using . That could be done by having a generic 'elisp' backend in database.c, and be able to do something like: (define-database TYPE FUNCPLIST) Where the entries in FUNCPLIST would be the generic name 'open' 'close' 'search' etc would be the key, and the value would be the actual lisp function to call to do the searching. That's all just off the top of my head, but it might work. :) -Bill P. From owner-xemacs-beta@xemacs.org Mon Nov 15 06:09:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA10743 for xemacs-beta-out; Mon, 15 Nov 1999 06:09:32 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA10740 for ; Mon, 15 Nov 1999 06:09:30 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11nK0j-0006SQ-00; Mon, 15 Nov 1999 12:09:25 +0100 To: Jan Vroonhof Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9g0y8f9ih.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 Nov 1999 12:09:25 +0100 In-Reply-To: Jan Vroonhof's message of "15 Nov 1999 12:01:30 +0100" Message-ID: <9t99040810a.fsf@mraz.iskon.hr> Lines: 17 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Hrvoje Niksic writes: > > > I don't think there really are many people in Latin * environments > > who want C-q to mean "insert a Latin 1 character". > > I am not sure. Don't forget that latin-1 is currently noconv-unix > alias binary. Then we can make C-q insert Latin 1 characters in binary files. What definitely doesn't make sense is C-q always inserting Latin 1 characters for 128-255 range. For me it is sometimes useful to insert Latin 2 characters by number, and I really have no idea what numbers Mule assigns to Latin 2 characters. From owner-xemacs-beta@xemacs.org Mon Nov 15 07:28:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA13392 for xemacs-beta-out; Mon, 15 Nov 1999 07:28:54 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA13387 for ; Mon, 15 Nov 1999 07:28:51 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id VAA11623; Mon, 15 Nov 1999 21:28:49 +0900 (JST) Mail-Copies-To: never To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 15 Nov 1999 21:20:43 +0900 In-Reply-To: <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 15 Nov 1999 19:39:40 +0900 (JST)") Message-ID: <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 44 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: | 1) Don't allow anything | 2) Accept 0-127 | 3) Accept 0-256 ^^^ I meant 255. Thanks, Adrian. "Stephen J. Turnbull" writes: > Yoshiki> Still, you can do > > Yoshiki> (let ((i 1442)) > Yoshiki> (while (i < 2000) > Yoshiki> (insert (int-to-char i)) > Yoshiki> (setq i (+1 i)))) > > This is exactly the kind of code that we should disallow. What does > each of those 558 characters mean when inserted in the buffer? Surely > most of them are not characters in any known character set. Should > they be inserted? Ignored? Do you tell the user what you've done? > In which functions do you want to put the checking code? What are you > supposed to do with the integers that are not characters: signal an > error, display a warning, set a flag for user code to check? Signal an error. This is for people who understand the problem dealing with internal representation and still want to use it. Desired code is like this (let ((i 32)) (while (< i 128) (insert (make-char 'latin-iso8859-9 i)) (setq i (1+ i)))) which does not depend on internal representation. int-to-char is broken except US-ASCII range, but if compatibility is needed, I'd like to force people to use only int-to-char to know it is broken. If we won't make any change, the code dealing with 1442 and such will become silently broken, due to two leading-byte change. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Mon Nov 15 08:01:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA14432 for xemacs-beta-out; Mon, 15 Nov 1999 08:01:41 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA14429 for ; Mon, 15 Nov 1999 08:01:38 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11nLlJ-0006W2-00 for ; Mon, 15 Nov 1999 14:01:37 +0100 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 Nov 1999 14:01:37 +0100 In-Reply-To: wmperry@aventail.com's message of "15 Nov 1999 06:03:38 -0500" Message-ID: <9t9u2mn7vta.fsf@mraz.iskon.hr> Lines: 22 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > "Stephen J. Turnbull" writes: > > > >>>>> "-BP" == William M Perry writes: > > > > -BP> To merge the LDAP code, you would have to do a major overhaul > > -BP> of the existing database code, and I'm not sure you would be > > -BP> able to get the full power of LDAP without making the > > -BP> 'normal' databases pretty difficult to use. > > > > OK, that's why it might be hard. It still sounds like it's a good > > idea to me. > > Perhaps, but I think that the code to do anything ldap-ish would > still look very ldap-ish as opposed to abstract-database-ish. I agree with Bill. Abstract interfaces are a nice thing up to a point, i.e. as long as they serve to us and not the other way around. If LDAP serves a purpose totally different than a flat database, it's quite fine to have a different interface for the two. From owner-xemacs-beta@xemacs.org Mon Nov 15 08:04:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA14501 for xemacs-beta-out; Mon, 15 Nov 1999 08:04:11 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA14497; Mon, 15 Nov 1999 08:04:09 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id FAA26599; Mon, 15 Nov 1999 05:03:42 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-159.beasys.com [192.168.11.159]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id NAA14473; Mon, 15 Nov 1999 13:03:31 GMT Message-Id: <3.0.5.32.19991115130428.00aaf380@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Nov 1999 13:04:28 +0000 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), xemacs-beta@xemacs.org, xemacs-nt@xemacs.org From: Andy Piper Subject: Re: [HEADS UP] movemail locking overhaul ahead In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 09:57 AM 11/15/99 +0100, Michael Sperber [Mr. Preprocessor] wrote: > >I'm not sure I'm seeing through the RMS #ifdef maze in movemail: What >mail locking method should be the default on Cygwin? > >(Please reply to me directly as well --- I'm not subscribed to >xemacs-nt.) movemail on cygwin should use pop3, does this actually use locking? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Nov 15 08:21:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA15151 for xemacs-beta-out; Mon, 15 Nov 1999 08:21:25 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA15147 for ; Mon, 15 Nov 1999 08:21:21 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11nM4N-0006Wr-00 for ; Mon, 15 Nov 1999 14:21:19 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 Nov 1999 14:21:19 +0100 In-Reply-To: Yoshiki Hayashi's message of "15 Nov 1999 21:20:43 +0900" Message-ID: <9t9hfin7uwg.fsf@mraz.iskon.hr> Lines: 29 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Note: it should really be int-char and char-int, not int-to-char and char-to-int. Yoshiki Hayashi writes: > > This is exactly the kind of code that we should disallow. What > > does each of those 558 characters mean when inserted in the > > buffer? Surely most of them are not characters in any known > > character set. Should they be inserted? Ignored? Do you tell > > the user what you've done? In which functions do you want to put > > the checking code? What are you supposed to do with the integers > > that are not characters: signal an error, display a warning, set a > > flag for user code to check? > > Signal an error. I hope you don't propose that int-char signals an error. It would be a serious breach of compatibility. What should happen is that it returns nil, just as before. (insert nil) will, of course, signal an error. > Desired code is like this > > (let ((i 32)) > (while (< i 128) > (insert (make-char 'latin-iso8859-9 i)) > (setq i (1+ i)))) Yup. That's where we all agree. From owner-xemacs-beta@xemacs.org Mon Nov 15 08:38:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA15657 for xemacs-beta-out; Mon, 15 Nov 1999 08:38:04 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id IAA15650 for ; Mon, 15 Nov 1999 08:38:02 -0500 Received: (qmail 1010 invoked from network); 15 Nov 1999 13:36:45 -0000 Received: from usrpri2-13.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.78) by biff.kiva.net with SMTP; 15 Nov 1999 13:36:45 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id IAA22276; Mon, 15 Nov 1999 08:39:47 -0500 To: w3-beta@xemacs.org, w3-dev@xemacs.org cc: xemacs-beta@xemacs.org Subject: JavaScript support... X-Now-Listening-To: Beastie - High Plains Drifter Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: So, does anyone want to help get javascript working in Emacs & XEmacs? I was looking at the netscape javascript source, and it comes with a Perl -> JavaScript glue layer that might be a good starting point. It allows calling Perl from JavaScript and vice versa. Increasingly, getting javascript'd web pages to even display correctly in w3 is hellish. :( -Bill P. From owner-xemacs-beta@xemacs.org Mon Nov 15 10:56:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA20539 for xemacs-beta-out; Mon, 15 Nov 1999 10:56:18 -0500 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA20535 for ; Mon, 15 Nov 1999 10:56:16 -0500 From: ALTMARK@de.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA253028; Mon, 15 Nov 1999 16:56:12 +0100 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA13272; Mon, 15 Nov 1999 16:56:12 +0100 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C125682A.005787B7 ; Mon, 15 Nov 1999 16:56:03 +0100 X-Lotus-FromDomain: IBMDE To: sperber@informatik.uni-tuebingen.de, xemacs-beta@xemacs.org Message-ID: Date: Mon, 15 Nov 1999 16:43:58 +0100 Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=WabC1Ea4sYALvQNpgiNmfTPU3rOVxjjd3oPUPpez40Z3KYYMK8aGDfxr" Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --0__=WabC1Ea4sYALvQNpgiNmfTPU3rOVxjjd3oPUPpez40Z3KYYMK8aGDfxr Content-type: text/plain; charset=us-ascii Content-Disposition: inline Doesn't look like that ... (At least as far as I can say.) I recompiled giving configure `--with-scrollbars=athena' and also '--with-scrollbars=no'. No difference. --- Markus Alt IBM Laboratory Boeblingen, Germany sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) on 11/12/99 08:51:22 AM Please respond to sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) To: xemacs-beta@xemacs.org cc: (bcc: Markus Alt/Germany/IBM) Subject: Re: [BUG] `scroll-up' command broken in 21.2-b20 (AIX 4.3.2) --0__=WabC1Ea4sYALvQNpgiNmfTPU3rOVxjjd3oPUPpez40Z3KYYMK8aGDfxr Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable >>>>> "MA" =3D=3D ALTMARK writes: MA> On my Linux build of 21.2-b20, it works, too. But on AIX, I see thi= s strange MA> behaviour which is quite annoying as scrolling should be considered= one of your MA> 'basic rights' in an editor ... :-( Motif fuckage? -- Cheers =3D8-} Chipsy Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla = --0__=WabC1Ea4sYALvQNpgiNmfTPU3rOVxjjd3oPUPpez40Z3KYYMK8aGDfxr-- From owner-xemacs-beta@xemacs.org Mon Nov 15 11:29:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA22391 for xemacs-beta-out; Mon, 15 Nov 1999 11:29:59 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA22388 for ; Mon, 15 Nov 1999 11:29:57 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id RAA15992 for ; Mon, 15 Nov 1999 17:29:55 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id RAA06334; Mon, 15 Nov 1999 17:29:55 +0100 (MET) To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Mon_Nov_15_17:29:47_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 15 Nov 1999 17:29:55 +0100 In-Reply-To: Hrvoje Niksic's message of "15 Nov 1999 14:01:37 +0100" Message-ID: Lines: 37 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Mon_Nov_15_17:29:47_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Hrvoje" == Hrvoje Niksic writes: >> Perhaps, but I think that the code to do anything ldap-ish would >> still look very ldap-ish as opposed to abstract-database-ish. Hrvoje> I agree with Bill. Abstract interfaces are a nice thing up to a Hrvoje> point, i.e. as long as they serve to us and not the other way around. Hrvoje> If LDAP serves a purpose totally different than a flat database, it's Hrvoje> quite fine to have a different interface for the two. Just to add my 2 cts, I also like abstraction and uniform interfaces (after all EUDC is a simple attempt at that) but I agree 200% with Bill and Hrvoje. The LDAP APIs are still evolving, adhering to them is the simple way to go. Even if we devised a good interface above the current API now, nothing guarantees we could easily fit forthcoming evolutions into it. I, for one, won't go that way but I won't discourage anyone that would like to implement such an interface. Oscar --pgp-sign-Multipart_Mon_Nov_15_17:29:47_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBODA1AZ7CaiYEgqPZAQGYpgIAnlEBWf0tQhEjHUe37qNoJYKgNLZDemzM jb2FpC/Q+nvEWt724FuYrXFiK7YoDs795suC4T7mENzvKeIGzyobLg== =5tKp -----END PGP MESSAGE----- --pgp-sign-Multipart_Mon_Nov_15_17:29:47_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 15 11:37:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA22961 for xemacs-beta-out; Mon, 15 Nov 1999 11:37:36 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA22953 for ; Mon, 15 Nov 1999 11:37:32 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA19109; Mon, 15 Nov 1999 17:37:29 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004eZ; Mon Nov 15 17:37:28 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA06202; Mon, 15 Nov 1999 17:37:27 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9g0y8f9ih.fsf@mraz.iskon.hr> <9t99040810a.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 15 Nov 1999 17:37:26 +0100 In-Reply-To: Hrvoje Niksic's message of "15 Nov 1999 12:09:25 +0100" Message-ID: Lines: 19 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Then we can make C-q insert Latin 1 characters in binary files. What > definitely doesn't make sense is C-q always inserting Latin 1 > characters for 128-255 range. The problem is that the user may change the coding system only later. > For me it is sometimes useful to insert Latin 2 characters by number, > and I really have no idea what numbers Mule assigns to Latin 2 > characters. Yes. Maybe we should just document that doing the thing I mentioned above is the wrong thing to do and you should make sure buffer-file-coding-system is set correctly before doing C-q. i.e. treat C-q like external I/O and handle it like that with respect to all the coding system settings. Jan From owner-xemacs-beta@xemacs.org Mon Nov 15 11:41:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA23188 for xemacs-beta-out; Mon, 15 Nov 1999 11:41:04 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA23184 for ; Mon, 15 Nov 1999 11:41:01 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA19181; Mon, 15 Nov 1999 17:41:00 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004fd; Mon Nov 15 17:40:56 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA06260; Mon, 15 Nov 1999 17:40:56 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 15 Nov 1999 17:40:55 +0100 In-Reply-To: Hrvoje Niksic's message of "15 Nov 1999 14:01:37 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > > Perhaps, but I think that the code to do anything ldap-ish would > > still look very ldap-ish as opposed to abstract-database-ish. > > I agree with Bill. Abstract interfaces are a nice thing up to a > point, i.e. as long as they serve to us and not the other way around. In fact, given that LDAP is the general protocol, a single interface should probably mean that you should make POD (plain old Databases) look like LDAP and not the other way around. EDBC.el anyone? Jan From owner-xemacs-beta@xemacs.org Mon Nov 15 11:55:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA23836 for xemacs-beta-out; Mon, 15 Nov 1999 11:55:23 -0500 Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA23833; Mon, 15 Nov 1999 11:55:17 -0500 Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAFGsne20110; Mon, 15 Nov 1999 11:54:49 -0500 Message-Id: <199911151654.dAFGsne20110@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: wmperry@aventail.com Cc: w3-beta@xemacs.org, w3-dev@xemacs.org, xemacs-beta@xemacs.org Subject: Re: JavaScript support... In-Reply-To: Your message of "Mon, 15 Nov 1999 08:39:47 EST." <86puxb98m4.fsf@megalith.bp.aventail.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-521373680P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 15 Nov 1999 11:54:45 -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Exmh_-521373680P Content-Type: text/plain; charset=us-ascii On Mon, 15 Nov 1999 08:39:47 EST, William M. Perry said: > So, does anyone want to help get javascript working in Emacs & XEmacs? I > was looking at the netscape javascript source, and it comes with a Perl -> > JavaScript glue layer that might be a good starting point. It allows > calling Perl from JavaScript and vice versa. > > Increasingly, getting javascript'd web pages to even display correctly in > w3 is hellish. :( And getting Javascript to work securely is equally hellish. Look at the number of bugs both Netscape and Microsoft have had with their browswers. Does anybody seriously think that they can Get It Right layering Javascript on top of a general-purpose interpreter like Elisp? Please, if you do this, I want a flag that *disables* Javascript, period, end of discussion.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-521373680P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBODA61NQBOOoptg9JAQGyCAP8D42zhwwSegCkfhZtq/3wBgdhKA14gIXq iT4RrKbvKAec/6swhnmksMgZMVQgT7DpojmibtLpd3WAtEROplzY8fL4yls1cj3x SSl8ms5BMsqVfNhwJ6SxxvfdPROgoNXUldGDBdzdnapumeed5f6vqOeWCxXkn5f1 djeKNYDwxBw= =LxBe -----END PGP MESSAGE----- --==_Exmh_-521373680P-- From owner-xemacs-beta@xemacs.org Mon Nov 15 12:11:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA24521 for xemacs-beta-out; Mon, 15 Nov 1999 12:11:45 -0500 Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA24516; Mon, 15 Nov 1999 12:11:42 -0500 Received: from gold.cis.ohio-state.edu (cmcurtin@gold.cis.ohio-state.edu [164.107.112.16]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA00457; Mon, 15 Nov 1999 12:11:37 -0500 (EST) Received: (from cmcurtin@localhost) by gold.cis.ohio-state.edu (8.9.1/8.9.1) id MAA00600; Mon, 15 Nov 1999 12:11:37 -0500 (EST) To: wmperry@aventail.com Cc: w3-beta@xemacs.org, w3-dev@xemacs.org, xemacs-beta@xemacs.org Subject: Re: JavaScript support... References: <86puxb98m4.fsf@megalith.bp.aventail.com> X-Face: L"IcL.b%SDN]0Kql2b`e.}+i05V9fi\yX#H1+Xl)3!+n/3?5`%-SA-HDgPk9uTk<3dv^J5DCgal)-E{`zN#*o6F|y>r)\< Date: 15 Nov 1999 12:11:37 -0500 In-Reply-To: wmperry@aventail.com's message of "15 Nov 1999 08:39:47 -0500" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On 15 Nov 1999 08:39:47 -0500, >>>>> wmperry@aventail.com (William M. Perry) said: BillP> Increasingly, getting javascript'd web pages to even display BillP> correctly in w3 is hellish. :( And we can't much longer blame the site creators who use it, as the stuff is being sanctioned now (i.e., HTML 4 DTDs and ECMA standards). Of course, we could just throw away all of the JavaScript before trying to display the page. :-) But that wouldn't be the Right Thing. -- Matt Curtin cmcurtin@interhack.net http://www.interhack.net/people/cmcurtin/ From owner-xemacs-beta@xemacs.org Mon Nov 15 13:03:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26717 for xemacs-beta-out; Mon, 15 Nov 1999 13:03:20 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA26711 for ; Mon, 15 Nov 1999 13:03:17 -0500 Received: (qmail 27666 invoked from network); 15 Nov 1999 18:02:01 -0000 Received: from usrpri2-65.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.130) by biff.kiva.net with SMTP; 15 Nov 1999 18:02:01 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA17050; Mon, 15 Nov 1999 13:05:03 -0500 To: Oscar Figueiredo Cc: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes X-Now-Listening-To: Beastie - Hey Ladies References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 36 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > >> Perhaps, but I think that the code to do anything ldap-ish would > >> still look very ldap-ish as opposed to abstract-database-ish. > > Hrvoje> I agree with Bill. Abstract interfaces are a nice thing up to > Hrvoje> a point, i.e. as long as they serve to us and not the other way > Hrvoje> around. > > Hrvoje> If LDAP serves a purpose totally different than a flat > Hrvoje> database, it's quite fine to have a different interface for the > Hrvoje> two. > > Just to add my 2 cts, I also like abstraction and uniform interfaces > (after all EUDC is a simple attempt at that) but I agree 200% with Bill > and Hrvoje. The LDAP APIs are still evolving, adhering to them is the > simple way to go. Even if we devised a good interface above the current > API now, nothing guarantees we could easily fit forthcoming evolutions > into it. I, for one, won't go that way but I won't discourage anyone > that would like to implement such an interface. After spitting out those ideas this morning, I think you could make it fit fairly easily, but whether anyone thinks the costs are worth it. There IS code out there that uses the existing LDAP routines (Emacs/W3, EUDC, etc), but nothing that really uses the db routines (can anyone contradict this? I couldn't find anything), so... If we reworked the database routines like I suggested, you could write the lisp-level database routines and layer them on top of LDAP to experiment with. Then you could see which one makes more sense. The whole database.c needs to get reworked anyway, and probably moved to a module. I don't know if I'll have time to do it or not though. Damn job. :) -Bill P. From owner-xemacs-beta@xemacs.org Mon Nov 15 13:13:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA27219 for xemacs-beta-out; Mon, 15 Nov 1999 13:13:59 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA27213 for ; Mon, 15 Nov 1999 13:13:57 -0500 Received: (qmail 32267 invoked from network); 15 Nov 1999 18:12:40 -0000 Received: from usrpri2-65.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.130) by biff.kiva.net with SMTP; 15 Nov 1999 18:12:40 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA17122; Mon, 15 Nov 1999 13:15:42 -0500 To: Valdis.Kletnieks@vt.edu Cc: w3-beta@xemacs.org, w3-dev@xemacs.org, xemacs-beta@xemacs.org Subject: Re: JavaScript support... X-Now-Listening-To: Beastie Boys - Root Down (PP Balloon Mix) References: <199911151654.dAFGsne20110@black-ice.cc.vt.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 36 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Valdis.Kletnieks@vt.edu writes: > On Mon, 15 Nov 1999 08:39:47 EST, William M. Perry said: > > So, does anyone want to help get javascript working in Emacs & XEmacs? > > I was looking at the netscape javascript source, and it comes with a > > Perl -> JavaScript glue layer that might be a good starting point. It > > allows calling Perl from JavaScript and vice versa. > > > > Increasingly, getting javascript'd web pages to even display correctly > > in w3 is hellish. :( > > And getting Javascript to work securely is equally hellish. Look at the > number of bugs both Netscape and Microsoft have had with their browswers. Yeah, but we're better than that. :) > Does anybody seriously think that they can Get It Right layering > Javascript on top of a general-purpose interpreter like Elisp? It wouldn't be layered on top of it, at least the way I imagined it. I considered converting the javascript to elisp and then just eval'ing it, but that would leave you really wide open to bad things. The non-core classes in javascript could be written in elisp, registered with a real javascript parser, and then you could just have a (javascript-eval ...) function. You'd have to be able to create multiple parser instances, but that would be pretty easy. > Please, if you do this, I want a flag that *disables* Javascript, period, > end of discussion.... But of course. There is already the w3-do-scripting variable that disables the emacs-lisp scripting that is in there. Don't worry, it is disabled by default, and has basic safety guidelines. :) -bp From owner-xemacs-beta@xemacs.org Mon Nov 15 13:28:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA27678 for xemacs-beta-out; Mon, 15 Nov 1999 13:28:49 -0500 Received: from ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA27675 for ; Mon, 15 Nov 1999 13:28:48 -0500 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by ericsson.com (8.9.3/8.9.3) with ESMTP id MAA13227 for ; Mon, 15 Nov 1999 12:28:47 -0600 (CST) Received: from netmanager7.rtp.ericsson.se (netmanager7.rtp.ericsson.se [147.117.132.245]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA22575 for ; Mon, 15 Nov 1999 12:28:46 -0600 (CST) Received: from edgedsp4 (edgedsp4.rtp.ericsson.se [147.117.125.206]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id NAA29735 for ; Mon, 15 Nov 1999 13:28:46 -0500 (EST) Received: (toy@localhost) by edgedsp4 (8.6.8/8.6.8) id NAA05508; Mon, 15 Nov 1999 13:28:45 -0500 To: XEmacs Developers Subject: 21.2-b20 crash on Solaris 2.7 From: Raymond Toy Date: 15 Nov 1999 13:28:44 -0500 Message-ID: <4nbt8vmwwz.fsf@rtp.ericsson.se> Lines: 95 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I was in VM reading a folder, and pressed "q" because I was done. XEmacs crashed. If it helps, I had the gutter tabs on. Here's the Lisp backtrace: resize-subwindow(# (#)Buffers 648x21 on # 0x198ca00 0x27be6> 648 nil) # bind (inst locale frame-or-buffer) update-tab-in-gutter(#) delete-window(#) # bind (delete-me done all-frames start w obj-2 obj-1 action) vm-window-loop(delete #) # bind (buffer) vm-maybe-delete-windows-or-frames-on(#) # bind (vm-mutable-frames) # (unwind-protect ...) # bind (vm-sbe-buffer buffer) vm-undisplay-buffer(#) # bind (wf w) # (unwind-protect ...) # bind (vm-sbe-buffer do-not-raise configs commands display buffer) vm-display(# nil nil nil) # bind (summary-buffer pres-buffer mail-buffer virtual no-change) vm-quit(nil) # bind (no-change) (lambda (&optional no-change) "Quit visiting the current folder, saving changes. Deleted messages \n are not expunged. If another VM folder exists, that becomes the\n selected buffer." (interacti ve) (vm-quit no-change) (let (...) (if vm-buffer ...)))() call-interactively(rlt-vm-quit) # (condition-case ... . error) # (catch top-level ...) Here's the C backtrace: #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa755c in fatal_error_signal (sig=11) at emacs.c:276 #2 #3 0xfeeb217c in _XtWindowedAncestor () from /usr/openwin/lib/libXt.so.4 #4 0xfeeab36c in XtWindowOfObject () from /usr/openwin/lib/libXt.so.4 #5 0x20beb4 in x_resize_subwindow (ii=0x18f4300, w=648, h=21) at glyphs-x.c:2288 #6 0x153220 in Fresize_subwindow (subwindow=26166016, width=648, height=21) at glyphs.c:4157 #7 0xb1e9c in Ffuncall (nargs=3, args=0xffbecf6c) at eval.c:3178 #8 0x78d60 in execute_optimized_program (program=0xffbecf6c "", stack_depth=3, constants_data=0x58ac90) at bytecode.c:743 #9 0x78528 in funcall_compiled_function (fun=5883964, nargs=1, args=0xffbed278) at bytecode.c:519 #10 0xb204c in Ffuncall (nargs=1, args=0xffbed270) at eval.c:3210 #11 0xb3238 in run_hook_with_args_in_buffer (buf=0x2f6804, nargs=2, args=0xffbed270, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #12 0xb3368 in va_run_hook_with_args (hook_var=3108284, nargs=1) at eval.c:3674 #13 0x7235c in Frecord_buffer (buffer=22842368) at buffer.c:1412 #14 0x221218 in Fselect_window (window=20243456, norecord=3106820) at window.c:3244 #15 0x21df70 in Fdelete_window (window=26788352, force=20243456) at window.c:1899 #16 0xb1e84 in Ffuncall (nargs=-1, args=0xffbed56c) at eval.c:3178 #17 0x78d60 in execute_optimized_program (program=0xffbed56c "", stack_depth=1, constants_data=0xa07690) at bytecode.c:743 #18 0x78528 in funcall_compiled_function (fun=10509608, nargs=2, args=0xffbed7d0) at bytecode.c:519 #19 0xb204c in Ffuncall (nargs=2, args=0xffbed7c4) at eval.c:3210 #20 0x78d60 in execute_optimized_program (program=0xffbed7c4 "", stack_depth=2, constants_data=0xa16790) at bytecode.c:743 #21 0x78528 in funcall_compiled_function (fun=10509664, nargs=1, args=0xffbeda1c) at bytecode.c:519 #22 0xb204c in Ffuncall (nargs=1, args=0xffbeda14) at eval.c:3210 #23 0x78d60 in execute_optimized_program (program=0xffbeda14 "", stack_depth=1, constants_data=0xa16910) at bytecode.c:743 #24 0x78528 in funcall_compiled_function (fun=10509300, nargs=1, args=0xffbedc6c) at bytecode.c:519 #25 0xb204c in Ffuncall (nargs=1, args=0xffbedc64) at eval.c:3210 #26 0x78d60 in execute_optimized_program (program=0xffbedc64 "", stack_depth=1, constants_data=0xa07810) at bytecode.c:743 #27 0x78528 in funcall_compiled_function (fun=10509244, nargs=4, args=0xffbedec8) at bytecode.c:519 #28 0xb204c in Ffuncall (nargs=4, args=0xffbedeb4) at eval.c:3210 #29 0x78d60 in execute_optimized_program (program=0xffbedeb4 "", stack_depth=4, constants_data=0xa35010) at bytecode.c:743 #30 0x78528 in funcall_compiled_function (fun=10673476, nargs=1, args=0xffbee06c) at bytecode.c:519 #31 0xb190c in Feval (form=10397416) at eval.c:3034 #32 0xabd60 in Fprogn (args=10397380) at eval.c:767 #33 0xb2c3c in funcall_lambda (fun=10397940, nargs=0, args=0xffbee460) at eval.c:3497 #34 0xb20ac in Ffuncall (nargs=0, args=0xffbee45c) at eval.c:3218 #35 0xb34c0 in apply1 (fn=10397940, arg=3106820) at eval.c:3793 #36 0x7dedc in Fcall_interactively (function=10588012, record_flag=3106820, keys=3106820) at callint.c:394 #37 0xb0530 in Fcommand_execute (cmd=10588012, record=3106820, keys=3106820) at eval.c:2613 #38 0x108308 in execute_command_event (command_builder=0x643a00, event=9286912) at event-stream.c:4343 #39 0x108da8 in Fdispatch_event (event=9286912) at event-stream.c:4634 #40 0x897f0 in Fcommand_loop_1 () at cmdloop.c:575 #41 0x8953c in command_loop_1 (dummy=3106820) at cmdloop.c:490 #42 0xada3c in condition_case_1 (handlers=2888704, bfun=0x894d8 , barg=3106820, hfun=0x899c4 , harg=3106820) at eval.c:1630 #43 0x89ad4 in command_loop_2 (dummy=3106820) at cmdloop.c:252 #44 0xad588 in internal_catch (tag=3189076, func=0x89a88 , arg=3106820, threw=0x0) at eval.c:1305 #45 0x88d50 in initial_command_loop (load_me=563848) at cmdloop.c:301 #46 0xa9138 in xemacs_21_2_b20_sparc_sun_solaris2_7 (argc=4, argv=0xffbeed5c, envp=0xffbeed70, restart=0) at emacs.c:1873 #47 0xa9950 in main (argc=4, argv=0xffbeed5c, envp=0xffbeed70) at emacs.c:2298 From owner-xemacs-beta@xemacs.org Mon Nov 15 15:24:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA31422 for xemacs-beta-out; Mon, 15 Nov 1999 15:24:17 -0500 Received: from fw.lunatech.com (fw.lunatech.com [194.151.25.136]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA31389; Mon, 15 Nov 1999 15:24:07 -0500 Received: from tanglefoot.lunatech.com (root@tanglefoot.lunatech.com [193.172.191.161]) by fw.lunatech.com (8.9.3/8.9.1/Debian/GNU) with ESMTP id VAA16801; Mon, 15 Nov 1999 21:22:45 +0100 Received: (from stephane@localhost) by tanglefoot.lunatech.com (8.9.3/8.9.3/Debian/GNU) id VAA08278; Mon, 15 Nov 1999 21:22:45 +0100 Date: Mon, 15 Nov 1999 21:22:45 +0100 From: Stef Epardaud To: "William M. Perry" Cc: w3-beta@xemacs.org, w3-dev@xemacs.org, xemacs-beta@xemacs.org Subject: Re: JavaScript support... a good thing me says. Message-ID: <19991115212245.A8117@tanglefoot.lunatech.com> References: <86puxb98m4.fsf@megalith.bp.aventail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <86puxb98m4.fsf@megalith.bp.aventail.com>; from William M. Perry on Mon, Nov 15, 1999 at 08:39:47AM -0500 Organisation: Lunatech Research Function: Java Defeater Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: that'd be great to have javascript support in w3 ! i'd say go go go! ;) i don't think i am good enough to help you nor to have time to learn, but i will find plenty of time if you want me to test things, or even run test cases and report bugs. good idea! On Mon, Nov 15, 1999 at 08:39:47AM -0500, William M. Perry wrote: > So, does anyone want to help get javascript working in Emacs & XEmacs? I > was looking at the netscape javascript source, and it comes with a Perl -> > JavaScript glue layer that might be a good starting point. It allows > calling Perl from JavaScript and vice versa. > > Increasingly, getting javascript'd web pages to even display correctly in > w3 is hellish. :( > > -Bill P. -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding... From owner-xemacs-beta@xemacs.org Mon Nov 15 20:55:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA11195 for xemacs-beta-out; Mon, 15 Nov 1999 20:55:33 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA11190 for ; Mon, 15 Nov 1999 20:55:30 -0500 Received: by localhost id m11nXpw-00016WC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 16 Nov 1999 10:55:12 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> Date: Tue, 16 Nov 1999 10:55:12 +0900 (JST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9hfin7uwg.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Note: it should really be int-char and char-int, not Hrvoje> int-to-char and char-to-int. Huh? C-h f int-char: `int-char' is an alias for `int-to-char', a built-in function -- loaded from "/playpen/src/xemacs-21/lisp/subr.elc" (int-char INTEGER) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 16 00:58:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA22529 for xemacs-beta-out; Tue, 16 Nov 1999 00:58:22 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA22526 for ; Tue, 16 Nov 1999 00:58:18 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11nbcx-0006w4-00; Tue, 16 Nov 1999 06:58:03 +0100 To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 16 Nov 1999 06:58:03 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Tue, 16 Nov 1999 10:55:12 +0900 (JST)" Message-ID: <9t9ogcvc710.fsf@mraz.iskon.hr> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Note: it should really be int-char and char-int, not > Hrvoje> int-to-char and char-to-int. > > Huh? C-h f int-char: > > `int-char' is an alias for `int-to-char', a built-in function That was a novelty, after Steve didn't like the name `int-to-char'. I think we should revert to the old versions, as Common Lisp has them too. From owner-xemacs-beta@xemacs.org Tue Nov 16 01:35:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA23436 for xemacs-beta-out; Tue, 16 Nov 1999 01:35:47 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA23429 for ; Tue, 16 Nov 1999 01:35:44 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id WAA20109; Mon, 15 Nov 1999 22:35:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14384.64310.736273.697671@lasker.666.com> Date: Mon, 15 Nov 1999 22:35:34 -0800 (PST) From: Martin Buchholz To: Hrvoje Niksic Cc: "Stephen J. Turnbull" , XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9ogcvc710.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> <9t9ogcvc710.fsf@mraz.iskon.hr> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrv" == Hrvoje Niksic writes: Hrvoje> Note: it should really be int-char and char-int, not Hrvoje> int-to-char and char-to-int. >> >> Huh? C-h f int-char: >> >> `int-char' is an alias for `int-to-char', a built-in function Hrv> That was a novelty, after Steve didn't like the name `int-to-char'. I Hrv> think we should revert to the old versions, as Common Lisp has them Hrv> too. Usually we should use the names in the Common Lisp standard as the `approved' names for these functions. Strangely, Common Lisp has char-int (and also char-code, which would be equivalent), but no int-char. Maybe that's a hint to us. Martin From owner-xemacs-beta@xemacs.org Tue Nov 16 02:00:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA24011 for xemacs-beta-out; Tue, 16 Nov 1999 02:00:57 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA24005; Tue, 16 Nov 1999 02:00:53 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11ncbj-0006xP-00; Tue, 16 Nov 1999 08:00:51 +0100 To: martin@xemacs.org Cc: "Stephen J. Turnbull" , XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> <9t9ogcvc710.fsf@mraz.iskon.hr> <14384.64310.736273.697671@lasker.666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 16 Nov 1999 08:00:51 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 15 Nov 1999 22:35:34 -0800 (PST)" Message-ID: <9t9d7tac44c.fsf@mraz.iskon.hr> Lines: 15 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > Usually we should use the names in the Common Lisp standard as the > `approved' names for these functions. Yes. > Strangely, Common Lisp has char-int (and also char-code, which would > be equivalent), but no int-char. Maybe that's a hint to us. :-) But Common Lisp's char concept is evil in its own way. I believe Common Lisp allows various modifiers to be encoded in the character itself. Yuck. From owner-xemacs-beta@xemacs.org Tue Nov 16 02:20:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA24547 for xemacs-beta-out; Tue, 16 Nov 1999 02:20:41 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA24544 for ; Tue, 16 Nov 1999 02:20:37 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id QAA06455 for ; Tue, 16 Nov 1999 16:20:35 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: [21.2] kill-rectangle and kill-* in read-only buffer From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Tue_Nov_16_16:20:29_1999-1" Date: 16 Nov 1999 16:20:29 +0900 Message-ID: <87iu329a2q.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 75 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Tue_Nov_16_16:20:29_1999-1 Content-Type: text/plain; charset=US-ASCII It may be controversial so I'm sending to here. Most of the function which does kill-region or something and has name of kill-* has `*' in its interactive spec. So, It signals an error before executing function body. However, kill-rectangle and kill-region is designed to work in read-only buffer and I'd like to use it even in read-only buffer. What confuses me is the fact that comments and the code in the source says different thing. For example, in rect.el, (defun kill-rectangle (start end &optional fill) [...] (interactive "*r\nP") [...] ;; ### NOTE: this is actually the only function that needs to do complicated ;; stuff like what's happening in `operate-on-rectangle', because the buffer ;; might be read-only. --dv (defun extract-rectangle-line (startcol endcol lines) kill-paragraph, kill-sentence, kill-primary-selection, backward-or-forward-kill-word, backward-or-forward-kill-sentence, backward-or-forward-kill-sentence, zap-to-char, kill-line, kill-comment, kill-word, backward-kill-word are the list of functions which have `*' spec. Some of the are clearly marked with `;; XEmacs modified' or `; XEmacs' but there's no entry in the ChangeLog and no hit in xemacs-beta archive search. My question is, is it OK to change them to be executed in a read-only buffer? I sometimes use kill-rectangle in read-only buffer and think it as useful. The patch is attached. --Multipart_Tue_Nov_16_16:20:29_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="rect.el.diff" Content-Transfer-Encoding: 7bit Index: rect.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/rect.el,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 rect.el --- rect.el 1999/08/24 08:08:59 1.1.2.2 +++ rect.el 1999/11/16 07:17:07 @@ -144,7 +144,7 @@ When called from a program, the rectangle's corners are START and END. With a prefix (or FILL) argument, also fill lines where nothing has to be deleted." - (interactive "*r\nP") + (interactive "r\nP") (when buffer-read-only (setq killed-rectangle (extract-rectangle start end)) (barf-if-buffer-read-only)) --Multipart_Tue_Nov_16_16:20:29_1999-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Tue_Nov_16_16:20:29_1999-1-- From owner-xemacs-beta@xemacs.org Tue Nov 16 02:31:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA24925 for xemacs-beta-out; Tue, 16 Nov 1999 02:31:19 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA24921; Tue, 16 Nov 1999 02:31:16 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id E511549E; Tue, 16 Nov 1999 08:31:13 +0100 (MET) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id IAA14742; Tue, 16 Nov 1999 08:31:12 +0100 To: Andy Piper Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: <3.0.5.32.19991115130428.00aaf380@london.beasys.com> Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 16 Nov 1999 08:31:11 +0100 In-Reply-To: Andy Piper's message of "Mon, 15 Nov 1999 13:04:28 +0000" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA24922 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> At 09:57 AM 11/15/99 +0100, Michael Sperber [Mr. Preprocessor] wrote: >> >> I'm not sure I'm seeing through the RMS #ifdef maze in movemail: What >> mail locking method should be the default on Cygwin? >> >> (Please reply to me directly as well --- I'm not subscribed to >> xemacs-nt.) Andy> movemail on cygwin should use pop3, does this actually use locking? Is WINDOWSNT defined on Cygwin? (If so, no. If no, yes.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Nov 16 02:47:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA25655 for xemacs-beta-out; Tue, 16 Nov 1999 02:47:27 -0500 Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA25651 for ; Tue, 16 Nov 1999 02:47:24 -0500 Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id IAA28798 for ; Tue, 16 Nov 1999 08:47:22 +0100 (MET) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id IAA15408; Tue, 16 Nov 1999 08:47:27 +0100 (MET) To: XEmacs beta list Subject: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes) References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 16 Nov 1999 08:47:27 +0100 In-Reply-To: wmperry@aventail.com's message of "15 Nov 1999 06:03:38 -0500" Message-ID: Lines: 279 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Suggestion: if database.c is redone would it be possible to name the functions `database-get' etc rather than `get-database' ? Here is some proof-of-concept code for supporting multiple database-like backends with a generic interface: it supports dbm, pg.el and in-memory/filesystem-persistent backends. The trickiest bit is handling searches uniformly ; billp's syntax could work with SQL and ldap, but for dbm & in-memory would require mapping over the entire database. EIEIO is at (with stuff like this I occasionally manage to forget I'm programming in a crummy imitation of a Lisp :-). ;;; db.el -- various types of databases for emacs ;; ;; Copyright: (C) 1999 Eric Marsden ;; Author: Eric Marsden ;; Time-stamp: <1999-11-16 ecm> ;; ;; ;; quasi-uniform access to different types of databases from emacs: ;; PostgreSQL tables using pg.el, XEmacs dbm/berkeley_db database API, ;; and file+hashtable-based in-memory tables. (require 'cl) (require 'eieio) (defclass db:database () () "The class of objects accessible via the database API") (defclass db:dbm-database (db:database) ((file :initarg :file :documentation "Path to file which contains the data for this database") (access :initarg :access :initform "rw+" :documentation "Access rights to the database (any combination of `r', `w' and `+' for read, write and creation flags)") (mode :initarg :mode :initform 420 :documentation "Permissions on the database") (db :initarg :db :initform nil)) "A dbm database") (defclass db:pg-database (db:database) ((dbname :initform "template1" :documentation "Name of the database") (user :documentation "Username under which to connect to the database") (password :initform "") (port :initform 5432 :documentation "Port where postmaster is listening") (host :initform "localhost") (connection :initform nil)) "A PostgreSQL database, accessed via pg.el") (defclass db:file-database (db:database) ((file :initarg :file :documentation "Path to file which contains the data for this database") (access :initarg :access :initform "rw+" :documentation "Access rights to the database (any combination of `r', `w' and `+' for read, write and creation flags)") (mode :initarg :mode :initform 420 :documentation "Permissions on the database") (db :initarg :db :initform nil)) "A hashtable-based database (persistence via filesystem)") (defgeneric db:open ((db database)) "Initialize a connection to the database") (defgeneric db:close ((db database)) "Close a connection to the database") (defgeneric db:live-p ((db database)) "Is the connection alive?") (defgeneric db:get ((db database) key &optional default) "Extract value corresponding to KEY from the database") (defgeneric db:put ((db database) key value &optional replace) "Add a relation between KEY and VALUE in the database. If REPLACE is non-nil, replace old value if it exists.") (defgeneric db:map ((db database) function) "Apply FUNCTION to each (key, value) pair in the database. Order is unspecified; FUNCTION should take two arguments.") (defgeneric db:remove ((db database) key) "Remove the relation for KEY from the database.") ;; PostgreSQL methods (using pg.el) (defmethod db:open ((db db:pg-database)) (require 'pg) (setf (slot-value db :connection) (with-slots (db) (pg:connect dbname user password host port)))) (defmethod db:close ((db db:pg-database)) (require 'pg) (pg:disconnect (slot-value db :connection)) (setf (db:pg-database-connection db) nil)) (defmethod db:live-p ((db db:pg-database)) (slot-value db :connection)) (defmethod db:get ((db db:pg-database) key &optional default) (require 'pg) (let* ((con (slot-value db :connection)) (sql (format "SELECT value FROM emacs_db WHERE key = %s" key)) (res (pg:exec con sql))) (pg:result res :tuple 1))) (defmethod db:put ((db db:pg-database) key value &optional replace) ) (defmethod db:map ((db db:pg-database) function) ) (defmethod db:remove ((db db:pg-database) key) ) ;; dbm methods using XEmacs API (when (fboundp 'databasep) (defmethod db:open ((db db:dbm-database)) (setf (slot-value db :db) (with-slots ((f file) (a access) (m mode)) db (open-database f 'dbm nil a m)))) (defmethod db:close ((db db:dbm-database)) (close-database (slot-value db :db))) (defmethod db:live-p ((db db:dbm-database)) (slot-value db :db)) (defmethod db:get ((db db:dbm-database) key &optional default) (get-database key (slot-value db :db) default)) (defmethod db:put ((db db:dbm-database) key val &optional replace) (put-database key val (slot-value db :db) replace)) (defmethod db:map ((db db:dbm-database) function) (map-database function (slot-value db :db))) (defmethod db:remove ((db db:dbm-database) key) (remove-database key (slot-value db :db))) ) ;; (fboundp 'databasep) ;; hash-table databases (in memory until closed) (defmethod db:open ((db db:file-database)) (let* ((filename (slot-value db :file)) (access (slot-value db :access)) buf data table) (cond ((position ?+ access) ;; start with an empty hash table (setq table (make-hash-table :test #'string=)) (setf (slot-value db :db) table)) (t ;; read data from disk into hash table (unless (file-readable-p filename) (error "database is not readable" filename)) (setq buf (find-file-noselect filename t t)) (setq data (read buf)) (setq table (make-hash-table :test #'string=)) (mapcar #'(lambda (c) (setf (gethash (car c) table) (cdr c))) table) (setf (slot-value db :db) table))))) (defmethod db:close ((db db:file-database)) (let* ((filename (slot-value db :file)) (access (slot-value db :access)) (table (slot-value db :db)) (buf (get-buffer-create " *db-work*")) (alist '())) (when (and (position ?+ access) (file-exists-p filename)) (delete-file filename)) ;; write data to alist (maphash #'(lambda (key val) (push (cons key val) alist)) table) (save-excursion (set-buffer buf) (erase-buffer) (prin1 alist) (write-file filename) (kill-buffer buf)))) (defmethod db:live-p ((db db:file-database)) (slot-value db :db)) (defmethod db:get ((db db:file-database) key &optional default) (gethash key (slot-value db :db) default)) (defmethod db:put ((db db:file-database) key val &optional replace) (setf (gethash key (slot-value db :db)) val)) (defmethod db:map ((db db:file-database) function) (maphash function (slot-value db :db))) (defmethod db:remove ((db db:file-database) key) (remhash key (slot-value db :db))) ;; testing (defun db:test/dbm () (require 'db) (let ((db (make-instance 'db:dbm-database :file "/tmp/try"))) (db:open db) (loop for i from 1 to 200 for positive = (format "%d" i) for negative = (format "%d" (- i)) do (db:put db positive negative)) (loop for i from 200 downto 1 for positive = (format "%d" i) for negative = (format "%d" (- i)) unless (string= (db:get db positive) negative) do (error "test failed for i = %d" i)) (db:close db))) (defun db:test/file () (require 'db) (let ((db (make-instance 'db:file-database :file "/tmp/zob.db"))) (db:open db) (loop for i from 1 to 200 for positive = (format "%d" i) for negative = (format "%d" (- i)) do (db:put db positive negative)) (loop for i from 200 downto 1 for positive = (format "%d" i) for negative = (format "%d" (- i)) unless (string= (db:get db positive) negative) do (error "test failed for i = %d" i)) (db:close db))) (provide 'db) ;; db.el ends here From owner-xemacs-beta@xemacs.org Tue Nov 16 03:30:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA27478 for xemacs-beta-out; Tue, 16 Nov 1999 03:30:47 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA27470 for ; Tue, 16 Nov 1999 03:30:41 -0500 Received: by localhost id m11ne0V-00016WC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 16 Nov 1999 17:30:31 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14385.5671.204789.105025@turnbull.sk.tsukuba.ac.jp> Date: Tue, 16 Nov 1999 17:30:31 +0900 (JST) To: XEmacs Beta List Subject: Crash on signal in tabs with --pdump X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Wasn't doing much. I had some gutter-related files open. The crash was apparently triggered by clicking on the tab for gutter.info (which doesn't exist in the distribution yet, so don't get your hopes up). Immediately before that I had read that file with C-x C-f, inserted src/gutter.c with C-x i, and then read src/gutter.h with C-x C-f. I had a crash on the same binary temacs/xemacs.dmp a few days ago, but had ulimit -c 0 :-( I have the core file if anyone can think of useful things to do with it. Debian linux "potato", current as of mid last week. XEmacs 21.2.20 by CVS update a few hours after the 21.2.20 release was announced. Lisp backtrace, C backtrace, and Installation appended. Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) gdb /home/steve/Projects/XEmacs/xemacs-21.2/src/temacs core GNU gdb 19990928 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `./temacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libaudio.so.2...done. Reading symbols from /usr/lib/libcanna.so.1...done. Reading symbols from /usr/lib/libRKC.so.1...done. Reading symbols from /usr/X11R6/lib/libXaw3d.so.6...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libncurses.so.4...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_compat.so.2...done. Reading symbols from /lib/libnsl.so.1...done. #0 0x402fd5d1 in kill () from /lib/libc.so.6 (gdb) where #0 0x402fd5d1 in kill () from /lib/libc.so.6 #1 0x808fce4 in fatal_error_signal (sig=11) at emacs.c:276 #2 0x402fd508 in sigaction () from /lib/libc.so.6 #3 0x81e5ca6 in XawTabsSetHighlight (t=0x841fab8, w=0x85211f0) at xlwtabs.c:1283 #4 0x81e53f0 in XawTabsSetTop (w=0x85211f0, callCallbacks=1) at xlwtabs.c:1262 #5 0x81e60af in TabsSelect (w=0x841fab8, event=0xbffff73c, params=0x0, num_params=0x40178d14) at xlwtabs.c:1047 #6 0x4016a773 in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #7 0x4016abcc in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #8 0x4016b0e4 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x40148d15 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x4014963e in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 #11 0x40149888 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #12 0x40154074 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #13 0x81aeb4b in emacs_Xt_next_event (emacs_event=0x84adb70) at event-Xt.c:2427 #14 0x80dac48 in event_stream_next_event (event=0x84adb70) at event-stream.c:565 #15 0x80dcdf0 in next_event_internal (target_event=139123568, allow_queued=1) at event-stream.c:2020 #16 0x80dd46d in Fnext_event (event=139123568, prompt=1078469536) at event-stream.c:2237 #17 0x8073cb1 in Fcommand_loop_1 () at cmdloop.c:566 #18 0x8073f5d in command_loop_1 (dummy=1078469536) at cmdloop.c:490 #19 0x80921be in condition_case_1 (handlers=1078469344, bfun=0x8073f14 , barg=1078469536, hfun=0x8073fcc , harg=1078469536) at eval.c:1630 #20 0x80740bf in command_loop_2 (dummy=1078469536) at cmdloop.c:252 #21 0x80993dc in internal_catch (tag=1078287784, func=0x8074080 , arg=1078469536, threw=0x0) at eval.c:1305 #22 0x80734ce in initial_command_loop (load_me=1078469536) at cmdloop.c:301 #23 0x808e0bd in xemacs_21_2_b20_i686_pc_linux () at emacs.c:1873 #24 0x808fe5b in main (argc=1, argv=0xbffffd64, envp=0xbffffd6c) at emacs.c:2236 (gdb) uname -a: Linux tleepslib 2.2.10 #2 Thu Jun 24 19:22:23 JST 1999 i686 unknown ./configure '--with-mule' '--with-xim=xlib' '--with-xfs' '--with-sound=both' '--with-widgets=athena3d' '--with-dialogs=athena3d' '--pdump' XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. Where should the build process find the source code? /home/steve/Projects/XEmacs/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in both network and native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using the new portable dumper (wishful thinking). Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 16 03:41:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA27957 for xemacs-beta-out; Tue, 16 Nov 1999 03:41:33 -0500 Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA27917 for ; Tue, 16 Nov 1999 03:41:28 -0500 Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAG8fEe26066 for ; Tue, 16 Nov 1999 03:41:14 -0500 Message-Id: <199911160841.dAG8fEe26066@black-ice.cc.vt.edu> To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-reply-to: Your message of "Tue, 16 Nov 1999 08:00:51 +0100." <9t9d7tac44c.fsf@mraz.iskon.hr> From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> <9t9ogcvc710.fsf@mraz.iskon.hr> <14384.64310.736273.697671@lasker.666.com> <9t9d7tac44c.fsf@mraz.iskon.hr> Date: Tue, 16 Nov 1999 03:40:53 -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Tue, 16 Nov 1999 08:00:51 +0100, Hrvoje Niksic said: > But Common Lisp's char concept is evil in its own way. I believe > Common Lisp allows various modifiers to be encoded in the character > itself. Yuck. The mind boggles. You mean you can have a green A, a blue A, an A with a swedish accent (not to be confused with any ISO8859-1 character that looks like a modified A)? At least control-meta-alt-cokebottle-A is a different character than A on most sane hardware. ;) From owner-xemacs-beta@xemacs.org Tue Nov 16 04:11:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA29650 for xemacs-beta-out; Tue, 16 Nov 1999 04:11:33 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA29643 for ; Tue, 16 Nov 1999 04:11:30 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA10527 for ; Tue, 16 Nov 1999 10:11:28 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002_T; Tue Nov 16 10:11:25 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA06577; Tue, 16 Nov 1999 10:11:25 +0100 To: xemacs-beta@xemacs.org Subject: Re: [21.2] kill-rectangle and kill-* in read-only buffer References: <87iu329a2q.fsf@dp50.ecc.u-tokyo.ac.jp> From: Jan Vroonhof Date: 16 Nov 1999 10:11:24 +0100 In-Reply-To: Yoshiki Hayashi's message of "16 Nov 1999 16:20:29 +0900" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: > - (interactive "*r\nP") > + (interactive "r\nP") > (when buffer-read-only > (setq killed-rectangle (extract-rectangle start end)) > (barf-if-buffer-read-only)) I think this patch is correct. Jan From owner-xemacs-beta@xemacs.org Tue Nov 16 04:34:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA30517 for xemacs-beta-out; Tue, 16 Nov 1999 04:34:28 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA30508 for ; Tue, 16 Nov 1999 04:34:25 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA15583; Tue, 16 Nov 1999 10:34:20 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003nT; Tue Nov 16 10:34:12 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA06583; Tue, 16 Nov 1999 10:34:12 +0100 To: Eric Marsden Cc: XEmacs beta list Subject: Re: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes) References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> From: Jan Vroonhof Date: 16 Nov 1999 10:34:11 +0100 In-Reply-To: Eric Marsden's message of "16 Nov 1999 08:47:27 +0100" Message-ID: Lines: 51 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Eric Marsden writes: [Yet another message marked for "Rereading when there is a non-zero amount of free time] > EIEIO is at (with > stuff like this I occasionally manage to forget I'm programming in a > crummy imitation of a Lisp :-). Now that we have your attention. I have been wanting to look into this for some time, but still haven't come around to it. Are there any bottlenecks or imperfections with EIEIO that could be solved with a little help from the C core? For instance I am thinking of opaque-cons (car cdr) Internal function. Like cons, but the return value is an opaque type and will signal an error unless passed to opaque-* opaque-car (ocons) opaque-cdr (ocons) opaque-to-cons (ocons) opaque-cons-p (ocons) Then you would have in usertype.el (defun deftype (type operations) (put type 'type-operations operations) (define-function (make-symbol (cons "make-" (symbol-name type))) '(value) `(opaque-cons ,type value)) (define-function (make-symbol (cons (symbol-name type))) "-value" '(t) `((let ((c (opaque-to-cons t))) (if (eq (car c) ,type) (cdr c) (error 'type-error "...."))))) (define-function (make-symbol (cons (symbol-name type))) "-p" '(t) `(and (opaque-cons-p t) (eq (opaque-car t) ,type)))) etc Jan From owner-xemacs-beta@xemacs.org Tue Nov 16 05:25:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA32182 for xemacs-beta-out; Tue, 16 Nov 1999 05:25:21 -0500 Received: from uta.fi (uta.fi [153.1.1.12]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA32177 for ; Tue, 16 Nov 1999 05:25:18 -0500 Received: from vuokko.uta.fi (ssjaaa@vuokko [153.1.1.11]) by uta.fi (8.8.7/8.8.2) with ESMTP id MAA15406; Tue, 16 Nov 1999 12:25:19 +0200 (EET) Received: (from ssjaaa@localhost) by vuokko.uta.fi (8.8.5/8.8.2) id MAA10949; Tue, 16 Nov 1999 12:25:19 +0200 (EET) From: jari.aalto@poboxes.com (Jari Aalto) CC: jari.aalto@poboxes.com (Jari Aalto) To: XEmacs Mailing List - Subject: Win32 21.1.6 immediate crash bug in Win98 Date: 16 Nov 1999 12:25:18 +0200 Message-ID: Lines: 48 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [please keep CC, since I'm not currently in the list] I'm Running Win98 with IE 5. For some reason the ~ is not interpreted as HOME -- My Home disks are under drive d: -- And Unix replicate is on drive e: (setenv "HOME" "d:/home/jaalto/") (expand-file-name "~") "e:\\usr\\local\\bin\\emacs\\xemacs\\XEmacs-21.1.6\\i386-pc-win32\\home\\jaalto\\" Since expand-file-name is used in numerous places I tried to fix this with simple advice code. But using the adviced function makes Xemacs to die with windows exception :-) (defun my-expand-file-name (path) "Expand ~ to mean HOME. XEmacs 21.1.6 win32 expands it somehow wrong." (let ((home (getenv "HOME")) ) (cond ((string-match "~/" path) (concat (file-name-as-directory home) (substring path 2))) ((string-match "~" path) (file-name-as-directory home)) (t path )))) (when (string-match "21\.1.*win32" (emacs-version)) (defadvice expand-file-name (before my act) "Replace Function with `my-expand-file-name'." (ad-set-arg 0 (my-expand-file-name (ad-get-arg 0))))) (expand-file-name "~") C-xC-e ---> and XEmacs is taken down by the Win98.... jari From owner-xemacs-beta@xemacs.org Tue Nov 16 07:23:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA02948 for xemacs-beta-out; Tue, 16 Nov 1999 07:23:18 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA02944 for ; Tue, 16 Nov 1999 07:23:16 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id EAA08428; Tue, 16 Nov 1999 04:22:51 -0800 (PST) Received: from andyppc (london-129 [10.5.1.129]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id MAA10693; Tue, 16 Nov 1999 12:22:51 GMT Message-Id: <3.0.5.32.19991116122357.00a3e750@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Nov 1999 12:23:57 +0000 To: "Stephen J. Turnbull" , XEmacs Beta List From: Andy Piper Subject: Re: Crash on signal in tabs with --pdump In-Reply-To: <14385.5671.204789.105025@turnbull.sk.tsukuba.ac.jp> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_942755037==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_942755037==_ Content-Type: text/plain; charset="us-ascii" Someone else has reported this. I suspect it was introduced when I resynced the Tab code. Does the attached patch help? andy At 05:30 PM 11/16/99 +0900, Stephen J. Turnbull wrote: >Wasn't doing much. I had some gutter-related files open. The crash >was apparently triggered by clicking on the tab for gutter.info (which >doesn't exist in the distribution yet, so don't get your hopes up). >Immediately before that I had read that file with C-x C-f, inserted >src/gutter.c with C-x i, and then read src/gutter.h with C-x C-f. > >I had a crash on the same binary temacs/xemacs.dmp a few days ago, but >had ulimit -c 0 :-( > >I have the core file if anyone can think of useful things to do with >it. > >Debian linux "potato", current as of mid last week. XEmacs 21.2.20 by >CVS update a few hours after the 21.2.20 release was announced. >Lisp backtrace, C backtrace, and Installation appended. > >Lisp backtrace follows: > > # (condition-case ... . error) > # (catch top-level ...) > >gdb /home/steve/Projects/XEmacs/xemacs-21.2/src/temacs core >GNU gdb 19990928 >Copyright 1998 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "i686-pc-linux-gnu"... >Core was generated by `./temacs'. >Program terminated with signal 11, Segmentation fault. >Reading symbols from /usr/lib/libaudio.so.2...done. >Reading symbols from /usr/lib/libcanna.so.1...done. >Reading symbols from /usr/lib/libRKC.so.1...done. >Reading symbols from /usr/X11R6/lib/libXaw3d.so.6...done. >Reading symbols from /usr/lib/libpng.so.2...done. >Reading symbols from /usr/lib/libz.so.1...done. >Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. >Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. >Reading symbols from /usr/X11R6/lib/libXt.so.6...done. >Reading symbols from /usr/X11R6/lib/libXext.so.6...done. >Reading symbols from /usr/X11R6/lib/libX11.so.6...done. >Reading symbols from /usr/X11R6/lib/libSM.so.6...done. >Reading symbols from /usr/X11R6/lib/libICE.so.6...done. >Reading symbols from /lib/libdl.so.2...done. >Reading symbols from /lib/libdb.so.3...done. >Reading symbols from /lib/libncurses.so.4...done. >Reading symbols from /lib/libm.so.6...done. >Reading symbols from /lib/libc.so.6...done. >Reading symbols from /lib/ld-linux.so.2...done. >Reading symbols from /lib/libnss_files.so.2...done. >Reading symbols from /lib/libnss_compat.so.2...done. >Reading symbols from /lib/libnsl.so.1...done. >#0 0x402fd5d1 in kill () from /lib/libc.so.6 >(gdb) where >#0 0x402fd5d1 in kill () from /lib/libc.so.6 >#1 0x808fce4 in fatal_error_signal (sig=11) at emacs.c:276 >#2 0x402fd508 in sigaction () from /lib/libc.so.6 >#3 0x81e5ca6 in XawTabsSetHighlight (t=0x841fab8, w=0x85211f0) > at xlwtabs.c:1283 >#4 0x81e53f0 in XawTabsSetTop (w=0x85211f0, callCallbacks=1) at xlwtabs.c:1262 >#5 0x81e60af in TabsSelect (w=0x841fab8, event=0xbffff73c, params=0x0, > num_params=0x40178d14) at xlwtabs.c:1047 >#6 0x4016a773 in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 >#7 0x4016abcc in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 >#8 0x4016b0e4 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 >#9 0x40148d15 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 >#10 0x4014963e in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 >#11 0x40149888 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 >#12 0x40154074 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 >#13 0x81aeb4b in emacs_Xt_next_event (emacs_event=0x84adb70) at event-Xt.c:2427 >#14 0x80dac48 in event_stream_next_event (event=0x84adb70) > at event-stream.c:565 >#15 0x80dcdf0 in next_event_internal (target_event=139123568, allow_queued=1) > at event-stream.c:2020 >#16 0x80dd46d in Fnext_event (event=139123568, prompt=1078469536) > at event-stream.c:2237 >#17 0x8073cb1 in Fcommand_loop_1 () at cmdloop.c:566 >#18 0x8073f5d in command_loop_1 (dummy=1078469536) at cmdloop.c:490 >#19 0x80921be in condition_case_1 (handlers=1078469344, > bfun=0x8073f14 , barg=1078469536, > hfun=0x8073fcc , harg=1078469536) at eval.c:1630 >#20 0x80740bf in command_loop_2 (dummy=1078469536) at cmdloop.c:252 >#21 0x80993dc in internal_catch (tag=1078287784, > func=0x8074080 , arg=1078469536, threw=0x0) at eval.c:1305 >#22 0x80734ce in initial_command_loop (load_me=1078469536) at cmdloop.c:301 >#23 0x808e0bd in xemacs_21_2_b20_i686_pc_linux () at emacs.c:1873 >#24 0x808fe5b in main (argc=1, argv=0xbffffd64, envp=0xbffffd6c) > at emacs.c:2236 >(gdb) > >uname -a: Linux tleepslib 2.2.10 #2 Thu Jun 24 19:22:23 JST 1999 i686 unknown > >./configure '--with-mule' '--with-xim=xlib' '--with-xfs' '--with-sound=both' '--with-widgets=athena3d' '--with-dialogs=athena3d' '--pdump' > > >XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. > > Where should the build process find the source code? /home/steve/Projects/XEmacs/xemacs-21.2 > What installation prefix should install use? /usr/local > What operating system and machine description files should XEmacs use? > `s/linux.h' and `m/intel386.h' > What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch > Should XEmacs use the GNU version of malloc? yes > (Using Doug Lea's new malloc from the GNU C Library.) > Should XEmacs use the relocating allocator for buffers? yes > What window system should XEmacs use? x11 > Where do we find X Windows header files? /usr/X11R6/include > Where do we find X Windows libraries? /usr/X11R6/lib > Compiling in support for XAUTH. > Compiling in support for XPM images. > Compiling in support for PNG image handling. > Compiling in support for (builtin) GIF image handling. > Compiling in both network and native sound support. > Compiling in support for Berkeley DB. > Compiling in support for ncurses. > Compiling in Mule (multi-lingual) support. > Compiling in XIM (X11R5+ I18N input method) support. > Using raw Xlib to provide XIM support. > Using XFontSet to provide bilingual menubar. > Compiling in support for Canna on Mule. > Compiling in support for proper WM_COMMAND handling. > Using Lucid menubars. > Using Lucid scrollbars. > Using Athena-3d native widgets. > Using Athena-3d dialog boxes. > Compiling in DSO module support. > movemail will use "dot-locking" for locking mail spool files. > Using the new portable dumper (wishful thinking). > Compiling in extra code for debugging. > WARNING: --------------------------------------------------------- > WARNING: Compiling in support for runtime error checking. > WARNING: XEmacs will run noticeably more slowly as a result. > WARNING: Error checking is on by default for XEmacs beta releases. > WARNING: --------------------------------------------------------- > > >-- >University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN >Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 >__________________________________________________________________________ >__________________________________________________________________________ >What are those two straight lines for? "Free software rules." > > --=====================_942755037==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="t.patch" --- l Tue Nov 16 12:23:10 1999 +++ l2 Tue Nov 16 12:23:00 1999 @@ -1279,9 +1279,9 @@ if( XtIsRealized(t) && w != tw->tabs.hilight ) { - if( tw->tabs.hilight != NULL ) + if( tw->tabs.hilight != NULL && XtIsRealized (tw->tabs.hilight)) DrawHighlight(tw, tw->tabs.hilight, True) ; - if( w != NULL ) + if( w != NULL && XtIsRealized (w)) DrawHighlight(tw, w, False) ; } --=====================_942755037==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_942755037==_-- From owner-xemacs-beta@xemacs.org Tue Nov 16 07:48:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA04278 for xemacs-beta-out; Tue, 16 Nov 1999 07:48:48 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA04272 for ; Tue, 16 Nov 1999 07:48:45 -0500 Received: by localhost id m11ni2K-00016XC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 16 Nov 1999 21:48:40 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14385.21159.828640.411488@turnbull.sk.tsukuba.ac.jp> Date: Tue, 16 Nov 1999 21:48:39 +0900 (JST) To: XEmacs Beta List Subject: Re: Crash on signal in tabs with --pdump In-Reply-To: <3.0.5.32.19991116122357.00a3e750@london.beasys.com> References: <14385.5671.204789.105025@turnbull.sk.tsukuba.ac.jp> <3.0.5.32.19991116122357.00a3e750@london.beasys.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> Someone else has reported this. I suspect it was introduced Andy> when I resynced the Tab code. Does the attached patch help? Andy> --- l Tue Nov 16 12:23:10 1999 Andy> +++ l2 Tue Nov 16 12:23:00 1999 Andy> @@ -1279,9 +1279,9 @@ I assume this is against lwlib/xlwtabs.c? I'll try it, but I don't have a surefire recipe for reproduction so I'll only be able to say "no crash yet".... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Tue Nov 16 09:34:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA10514 for xemacs-beta-out; Tue, 16 Nov 1999 09:34:42 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA10510 for ; Tue, 16 Nov 1999 09:34:40 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id GAA19888; Tue, 16 Nov 1999 06:34:15 -0800 (PST) Received: from andyppc (london-129 [10.5.1.129]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id OAA14407; Tue, 16 Nov 1999 14:34:16 GMT Message-Id: <3.0.5.32.19991116143521.00b53b70@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Nov 1999 14:35:21 +0000 To: "Stephen J. Turnbull" , XEmacs Beta List From: Andy Piper Subject: Re: Crash on signal in tabs with --pdump In-Reply-To: <14385.21159.828640.411488@turnbull.sk.tsukuba.ac.jp> References: <3.0.5.32.19991116122357.00a3e750@london.beasys.com> <14385.5671.204789.105025@turnbull.sk.tsukuba.ac.jp> <3.0.5.32.19991116122357.00a3e750@london.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 09:48 PM 11/16/99 +0900, Stephen J. Turnbull wrote: >>>>>> "Andy" == Andy Piper writes: > > Andy> Someone else has reported this. I suspect it was introduced > Andy> when I resynced the Tab code. Does the attached patch help? > > Andy> --- l Tue Nov 16 12:23:10 1999 > Andy> +++ l2 Tue Nov 16 12:23:00 1999 > Andy> @@ -1279,9 +1279,9 @@ > >I assume this is against lwlib/xlwtabs.c? Yes :) andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 16 09:56:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA11750 for xemacs-beta-out; Tue, 16 Nov 1999 09:56:52 -0500 Received: from ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA11743 for ; Tue, 16 Nov 1999 09:56:50 -0500 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by ericsson.com (8.9.3/8.9.3) with ESMTP id IAA08535 for ; Tue, 16 Nov 1999 08:56:49 -0600 (CST) Received: from netmanager7.rtp.ericsson.se (netmanager7.rtp.ericsson.se [147.117.132.245]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA14043 for ; Tue, 16 Nov 1999 08:56:48 -0600 (CST) Received: from edgedsp4 (edgedsp4.rtp.ericsson.se [147.117.125.206]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id JAA27358 for ; Tue, 16 Nov 1999 09:56:47 -0500 (EST) Received: (toy@localhost) by edgedsp4 (8.6.8/8.6.8) id JAA07505; Tue, 16 Nov 1999 09:56:47 -0500 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> <9t9ogcvc710.fsf@mraz.iskon.hr> <14384.64310.736273.697671@lasker.666.com> <9t9d7tac44c.fsf@mraz.iskon.hr> <199911160841.dAG8fEe26066@black-ice.cc.vt.edu> From: Raymond Toy Date: 16 Nov 1999 09:56:46 -0500 In-Reply-To: Valdis.Kletnieks@vt.edu's message of "Tue, 16 Nov 1999 03:40:53 -0500" Message-ID: <4n3du6mqmp.fsf@rtp.ericsson.se> Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Valdis" == Valdis Kletnieks writes: Valdis> On Tue, 16 Nov 1999 08:00:51 +0100, Hrvoje Niksic said: >> But Common Lisp's char concept is evil in its own way. I believe >> Common Lisp allows various modifiers to be encoded in the character >> itself. Yuck. Valdis> The mind boggles. You mean you can have a green A, a blue A, Valdis> an A with a swedish accent (not to be confused with any ISO8859-1 Valdis> character that looks like a modified A)? I believe that was so up through CLtL2, but ANSI CL got rid of the character attributes. Ray From owner-xemacs-beta@xemacs.org Tue Nov 16 13:33:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA20595 for xemacs-beta-out; Tue, 16 Nov 1999 13:33:36 -0500 Received: from rpgsparc.scra.org (rpgsparc.scra.org [147.120.110.10]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA20590 for ; Tue, 16 Nov 1999 13:33:29 -0500 Received: from alnitak.scra.org (alnitak.scra.org [147.120.176.28]) by rpgsparc.scra.org (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA20758; Tue, 16 Nov 1999 13:33:16 -0500 (EST) Received: from ngds1.scra.org.scra.org (ngds1.scra.org [147.120.171.139]) by alnitak.scra.org (8.8.8+Sun/8.8.8) with SMTP id NAA27160; Tue, 16 Nov 1999 13:33:17 -0500 (EST) From: Craig Lanning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14385.42020.337122.240108@ngds1.scra.org> Date: Tue, 16 Nov 1999 13:36:20 -0500 (EST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <4n3du6mqmp.fsf@rtp.ericsson.se> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <14383.58092.769729.579856@turnbull.sk.tsukuba.ac.jp> <87ogcwj690.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9hfin7uwg.fsf@mraz.iskon.hr> <14384.47488.60680.415315@turnbull.sk.tsukuba.ac.jp> <9t9ogcvc710.fsf@mraz.iskon.hr> <14384.64310.736273.697671@lasker.666.com> <9t9d7tac44c.fsf@mraz.iskon.hr> <199911160841.dAG8fEe26066@black-ice.cc.vt.edu> <4n3du6mqmp.fsf@rtp.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Raymond Toy writes: > >>>>> "Valdis" == Valdis Kletnieks writes: > > Valdis> On Tue, 16 Nov 1999 08:00:51 +0100, Hrvoje Niksic said: > >> But Common Lisp's char concept is evil in its own way. I believe > >> Common Lisp allows various modifiers to be encoded in the character > >> itself. Yuck. > > Valdis> The mind boggles. You mean you can have a green A, a blue A, > Valdis> an A with a swedish accent (not to be confused with any ISO8859-1 > Valdis> character that looks like a modified A)? > > I believe that was so up through CLtL2, but ANSI CL got rid of the > character attributes. > > Ray CLtL1 stated that objects of type character had the three attributes 'code', 'bits', and 'font'. 'code' is the numerical value of the character (ASCII code). 'bits' are the modifier bits such as Shift, Control, and Meta (on a Lisp Machine Super and Hyper are also included). 'font' allowed a specific font to be associated with a character. CLtL2 noted that the X3J13 committee had voted to remove the attributes 'bits' and 'font' and replace them with "implementation-defined attributes." Harlequin has a document called the "Common Lisp HyperSpec" which is available at the URL http://www.harlequin.com/education/books/HyperSpec/. This document is an HTML version of the ANSI Common Lisp standard. (The HyperSpec was put together by the editor of the ANSI Common Lisp standard, Kent Pitman.) The concept of 'character' is discussed in chapter 13: http://www.harlequin.com/education/books/HyperSpec/Body/chap-13.html. The concept of character attributes is discussed in the subsection http://www.harlequin.com/education/books/HyperSpec/Body/sec_13-1-3.html. [Sorry to just jump into the middle of this conversation, but I thought this info might be useful.] Craig [10 year veteran of Lisp hacking. Zetalisp, Common Lisp, and ANSI Common Lisp in Symbolics' Genera (Lisp Machines), Franz Allegro (Unix), and Harlequin LispWorks (Unix and Win32)] -- ---------------------------------------------------------------------- Craig Lanning Principal Engineer Logicon, Inc. a Northrop Grumman company E-Mail: Lanning@scra.org 5300 International Blvd. Voice: 843-760-3246 North Charleston, SC 29418 FAX: 843-760-3780 USA From owner-xemacs-beta@xemacs.org Tue Nov 16 15:08:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA24233 for xemacs-beta-out; Tue, 16 Nov 1999 15:08:20 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA24226 for ; Tue, 16 Nov 1999 15:08:15 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id MAA30768; Tue, 16 Nov 1999 12:08:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14385.47524.289812.698251@lasker.666.com> Date: Tue, 16 Nov 1999 12:08:04 -0800 (PST) From: Martin Buchholz To: XEmacs Beta Test , "Ravi Wikramanayake" , Andreas Jaeger Subject: Re: elisp packages In-Reply-To: <19991116050414.6212.qmail@hotmail.com> References: <19991116050414.6212.qmail@hotmail.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "R" == Ravi Wikramanayake writes: R> I recently purchased cygwin 1.0 from cygnus. It appears that the xemacs R> bundled with it does not seem to have c++-mode, c-mode, java-mode *.el and R> *.elc files. Could you please suggest how I can gain access to the R> respective *.el and associated *.elc files. Get the `sumo' package tarball from ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz Also get xemacs-mule-sumo.tar.gz if your binaries are using the `Mule' feature. I predicted in private that this sort of thing would happen. There is such a legacy of being able to build *functional* software using the algorithm: get foo-n.m.tar.gz tar xzf foo-n.m.tar.gz cd foo-n.m configure make make install that it is entirely natural that people would omit including the packages, even if they are professional GNU software maintainers such as inhabit Cygnus. Also, people who did try to follow the instructions and use documented interfaces to install packages after installing the `core' XEmacs often failed (and reverted to 20.4, since that actually `worked'). >From this point of view, the package system has been an unmitigated disaster. Martin From owner-xemacs-beta@xemacs.org Tue Nov 16 16:26:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA26877 for xemacs-beta-out; Tue, 16 Nov 1999 16:26:40 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA26868; Tue, 16 Nov 1999 16:26:33 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id WAA18288; Tue, 16 Nov 1999 22:26:27 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa004Ta; Tue Nov 16 22:26:17 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id WAA16703; Tue, 16 Nov 1999 22:26:17 +0100 To: martin@xemacs.org Cc: XEmacs Beta Test , "Ravi Wikramanayake" , Andreas Jaeger Subject: Re: elisp packages References: <19991116050414.6212.qmail@hotmail.com> <14385.47524.289812.698251@lasker.666.com> From: Jan Vroonhof Date: 16 Nov 1999 22:26:16 +0100 In-Reply-To: Martin Buchholz's message of "Tue, 16 Nov 1999 12:08:04 -0800 (PST)" Message-ID: Lines: 30 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > that it is entirely natural that people would omit including the > packages, even if they are professional GNU software maintainers such > as inhabit Cygnus. Are you sure that the Cygwin people forgot to put the packages on the CD? I really cannot believe that. > Also, people who did try to follow the > instructions and use documented interfaces to install packages after > installing the `core' XEmacs often failed (and reverted to 20.4, since > that actually `worked'). > > >From this point of view, the package system has been an unmitigated disaster. Frankly I think the package system hasn't had a fair chance yet. Our communication, QA and maintenance crisis has amplified it weaknesses while not allowing us to profit from its benefits. We actually have had a split tarball system for the binaries for ages and I have seen relatively few complaints about that. The only real conceptual difference was that the binaries complained loudly if they couldn't bind the stuff from xemacs-common. Jan From owner-xemacs-beta@xemacs.org Tue Nov 16 17:38:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA28850 for xemacs-beta-out; Tue, 16 Nov 1999 17:38:49 -0500 Received: from ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA28847 for ; Tue, 16 Nov 1999 17:38:48 -0500 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by ericsson.com (8.9.3/8.9.3) with ESMTP id QAA09514 for ; Tue, 16 Nov 1999 16:38:47 -0600 (CST) Received: from netmanager7.rtp.ericsson.se (netmanager7.rtp.ericsson.se [147.117.132.245]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA28468 for ; Tue, 16 Nov 1999 16:38:47 -0600 (CST) Received: from edgedsp4 (edgedsp4.rtp.ericsson.se [147.117.125.206]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id RAA14534 for ; Tue, 16 Nov 1999 17:38:46 -0500 (EST) Received: (toy@localhost) by edgedsp4 (8.6.8/8.6.8) id RAA08434; Tue, 16 Nov 1999 17:38:45 -0500 To: XEmacs Beta Test Subject: Re: elisp packages References: <19991116050414.6212.qmail@hotmail.com> <14385.47524.289812.698251@lasker.666.com> From: Raymond Toy Date: 16 Nov 1999 17:38:43 -0500 In-Reply-To: Martin Buchholz's message of "Tue, 16 Nov 1999 12:08:04 -0800 (PST)" Message-ID: <4nln7ykqoc.fsf@rtp.ericsson.se> Lines: 25 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Martin> that it is entirely natural that people would omit including the Martin> packages, even if they are professional GNU software maintainers such Martin> as inhabit Cygnus. Also, people who did try to follow the Martin> instructions and use documented interfaces to install packages after Martin> installing the `core' XEmacs often failed (and reverted to 20.4, since Martin> that actually `worked'). >> From this point of view, the package system has been an unmitigated disaster. I wouldn't exactly say that. Of course, being behind a firewall with an ftp that efs doesn't like, I've never had to really deal with packages. I just download the sumo tarballs whenever I feel like it, or the individual packages if I need them. However, I think the whole package stuff would work better if it used http instead of ftp to get the packages. "Everyone" has a working http access. ftp is much more difficult, and, in my case, unusable. (It works just fine from the command line, but not via efs.) I wish I had time (and knowledge) to make the package stuff use http instead of efs.... Ray From owner-xemacs-beta@xemacs.org Tue Nov 16 18:23:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA30762 for xemacs-beta-out; Tue, 16 Nov 1999 18:23:46 -0500 Received: from justresearch.com (ULYSSES.JPRC.COM [207.86.147.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA30757 for ; Tue, 16 Nov 1999 18:23:44 -0500 Received: (from mthomas@localhost) by justresearch.com (8.8.7/8.8.7) id SAA16808; Tue, 16 Nov 1999 18:23:42 -0500 To: XEmacs Beta Test Subject: 21.2.b20: C-g in isearch differs from old b17 behavior From: Mark Thomas Date: 16 Nov 1999 18:23:42 -0500 In-Reply-To: Martin Buchholz's message of "Tue, 16 Nov 1999 12:08:04 -0800 (PST)" Message-ID: Lines: 18 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've recently upgraded from 21.2.b17 to 21.2.b20 and I notice that C-g behaves differently during incremental search. Suppose I isearch (successfully) for "foo" and press RET to exit isearch. Next I isearch (successfully) for "bar" and use C-g to exit isearch. In b17, pressing C-s C-s would isearch for "bar"; in b20, it searches for "foo". Is this by design? I don't remember seeing mention of it on the xemacs-beta list. I notice that isearch-quit (bound by default to (ugh!) ESC ESC ESC) remembers the most recent search string. Perhaps I'll just bind isearch-quit to something more convenient (and eventually retrain my fingers). -Mark From owner-xemacs-beta@xemacs.org Tue Nov 16 18:48:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA31479 for xemacs-beta-out; Tue, 16 Nov 1999 18:48:16 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA31475 for ; Tue, 16 Nov 1999 18:48:14 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id AAA19632; Wed, 17 Nov 1999 00:48:12 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa004mi; Wed Nov 17 00:48:07 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id AAA16896; Wed, 17 Nov 1999 00:48:07 +0100 To: Pete Forman Cc: xemacs-beta@xemacs.org Subject: Re: Timer does not delay References: From: Jan Vroonhof Date: 17 Nov 1999 00:48:07 +0100 In-Reply-To: Pete Forman's message of "16 Nov 1999 15:50:50 +0000" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Pete Forman writes: > This code should post a message after a delay of 10 seconds. Only the > third method (sleep-for) works. The first two execute the message > function immediately, or very quickly. > > (run-at-time 10 nil 'message "pwf run-at-time") > ("itimer-0" 9.999781 nil message nil t ("pwf run-at-time") (0 0 0)) The problem seems to be that only the first time out isn't working... Strange... From owner-xemacs-beta@xemacs.org Tue Nov 16 19:21:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA32385 for xemacs-beta-out; Tue, 16 Nov 1999 19:21:54 -0500 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA32377; Tue, 16 Nov 1999 19:21:44 -0500 Received: from cygnus.com (echristo.cygnus.com [205.180.231.150]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA18496; Tue, 16 Nov 1999 16:21:28 -0800 (PST) Message-ID: <3831F585.19B1C25E@cygnus.com> Date: Tue, 16 Nov 1999 16:23:33 -0800 From: Eric Christopher Organization: Cygnus Solutions X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof CC: martin@xemacs.org, XEmacs Beta Test , Ravi Wikramanayake , Andreas Jaeger Subject: Re: elisp packages References: <19991116050414.6212.qmail@hotmail.com> <14385.47524.289812.698251@lasker.666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Are you sure that the Cygwin people forgot to put the packages on the > CD? I really cannot believe that. > Yes. To my chagrin we really did forget to do that. Previously it had "just built" for the groups running the release and when it was discovered it was too late to fix. -eric From owner-xemacs-beta@xemacs.org Tue Nov 16 20:22:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA01922 for xemacs-beta-out; Tue, 16 Nov 1999 20:22:37 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA01918; Tue, 16 Nov 1999 20:22:35 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id SAA17832; Tue, 16 Nov 1999 18:22:27 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3832032F.B9A443ED@666.com> Date: Tue, 16 Nov 1999 18:21:51 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof CC: XEmacs Review , XEmacs beta list Subject: Re: 10% redisplay speed up... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Thank you so much for doing this! We need WAY more profiling done of XEmacs. Why don't you post exactly the steps you took in order to get the profiling output, as well as the relevant part of the output itself? I think people are scared off of profiling because XEmacs is big and does nonstandard things with its executable, and they don't want to figure out how to do it. I really really think you should implement your comment about memcmp(). Do something like this: 1. Move the non-compared fields to the end (Bufpos and Endpos, I think) and create an extra substructure that includes everything else. This means you have to change all the places in the code that access the fields, but there will be no slowdown as a result of this. 2. Give the union a name, and make sure it's bzero()d whenever it's changed. (This should cause negligible slowdown, right? The structure is compared *much* more often than changed, I presume.) 3. Replace compare_runes() with a memcmp() of the substructure and a call to WINDOW_FACE_CACHEL_DIRTY(). ben Jan Vroonhof wrote: > ...and for free too! If I count correctly the change to struct rune > does not change its size at all. > > A while ago I ran XEmacs under C level profiling and this is the result > > time xemacs.old -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 93.300u 2.080s 1:41.36 94.1% 0+0k 0+0io 1387pf+0w > time xemacs.new -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 82.100u 2.030s 1:27.44 96.2% 0+0k 0+0io 1488pf+0w > time xemacs.new -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 80.910u 2.280s 1:28.60 93.8% 0+0k 0+0io 1386pf+0w > time xemacs.old -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 94.700u 2.030s 1:41.31 95.4% 0+0k 0+0io 1387pf+0w > > 1999-11-16 Jan Vroonhof > > * src/redisplay-output.c (compare_runes): Add comments about > results from profiling. > > * src/redisplay.h (struct rune): Do not use bitfields for members. > (struct rune): Add various comments about further optimizations. > > Index: src/redisplay-output.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-output.c,v > retrieving revision 1.11.2.19 > diff -u -u -r1.11.2.19 redisplay-output.c > --- redisplay-output.c 1999/10/15 10:11:50 1.11.2.19 > +++ redisplay-output.c 1999/11/16 21:05:23 > @@ -190,6 +190,27 @@ > /* Do not compare the values of bufpos and endpos. They do not > affect the display characteristics. */ > > + /* Note: (hanoi 6) spends 95% of its time in redisplay, and about > + 30% here. Not using bitfields for rune.type alone gives a redisplay > + speed up of 10%. > + > + #### In profile arcs run of a normal Gnus session this function > + is run 6.76 million times, only to return 1 in 6.73 million of > + those. > + > + In addition a quick look GCC sparc assembly shows that GCC is not > + doing a good job here. > + 1. The function is not inlined (too complicated?) > + 2. It seems to be reloading the crb and drb variables all the > + time. > + 3. It doesn't seem to notice that the second half of these if's > + are really a switch statement. > + > + So I (JV) conjecture > + > + #### It would really be worth it to arrange for this function to > + be (almost) a single call to memcmp. */ > + > if ((crb->findex != drb->findex) || > (WINDOW_FACE_CACHEL_DIRTY (w, drb->findex))) > return 0; > Index: src/redisplay.h > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.h,v > retrieving revision 1.7.2.13 > diff -u -u -r1.7.2.13 redisplay.h > --- redisplay.h 1999/10/26 05:48:53 1.7.2.13 > +++ redisplay.h 1999/11/16 21:05:46 > @@ -91,6 +91,13 @@ > but control characters have two -- a ^ and a letter -- and other > non-printing characters (those displayed in octal) have four. */ > > +/* WARNING! In compare_runes (one of the most heavily used functions) > + two runes are compared. So please be careful with changes to this > + structure. See comments in compare_runes. > + > + #### This should really be made smaller. > +*/ > + > typedef struct rune rune; > struct rune > { > @@ -105,10 +112,6 @@ > each of the face properties in this > particular window. */ > > - short xpos; /* horizontal starting position in pixels */ > - short width; /* pixel width of rune */ > - > - > Bufpos bufpos; /* buffer position this rune is displaying; > for the modeline, the value here is a > Charcount, but who's looking? */ > @@ -116,11 +119,26 @@ > /* #### Chuck, what does it mean for a rune > to cover a range of pos? I don't get > this. */ > - unsigned int cursor_type :3; /* is this rune covered by the cursor? */ > - unsigned int type :3; /* type of rune object */ > + /* #### This isn't used as an rvalue anywhere! > + remove! */ > + > + > + short xpos; /* horizontal starting position in pixels */ > + short width; /* pixel width of rune */ > + > + > + unsigned char cursor_type; /* is this rune covered by the cursor? */ > + unsigned char type; /* type of rune object */ > + /* We used to do bitfields here, but if I > + (JV) count correctly that doesn't matter > + for the size of the structure. All the bit > + fiddling _does_ slow down redisplay by > + about 10%. So don't do that */ > > union /* Information specific to the type of rune */ > { > + /* #### GLyps are are. Is it really necessary to waste 8 bytes on every > + rune for that?! */ > /* DGLYPH */ > struct > { From owner-xemacs-beta@xemacs.org Tue Nov 16 20:36:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA02281 for xemacs-beta-out; Tue, 16 Nov 1999 20:36:03 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA02277; Tue, 16 Nov 1999 20:36:01 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id SAA21506; Tue, 16 Nov 1999 18:35:42 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3832064A.5A8B3C69@666.com> Date: Tue, 16 Nov 1999 18:35:06 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: XEmacs Review , XEmacs beta list , Jan Vroonhof Subject: Re: read-coding-system References: <87puxa9b50.fsf@dp50.ecc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Approved, but: 1) You should never combine patches like this. Instead, resubmit the patch that was not approved, with a comment about this fact. (Which the patch tender -- currently Jan -- ought to have noticed, and done something about.) 2) Try to put some comment into the source whenever you change anything -- e.g. in case 1: ; exclude blank arguments, which result when the user accepts the default value in case 2: change the doc string from Prompting with string PROMPT. If the user enters null input, return second argument DEFAULT-CODING-SYSTEM." to Prompting with string PROMPT. If the user enters null input, return second argument DEFAULT-CODING-SYSTEM. DEFAULT-CODING-SYSTEM can be a string, symbol, or coding-system object." (and in the process, fix up the code so this is actually true.) ben Yoshiki Hayashi wrote: > xemacs -vanilla > > C-x RET c RET > Wrong type argument: stringp, iso-2022-8 > > C-x RET c or universal-coding-system-argument passes > buffer-file-coding-system as a default value to > read-coding-system. > However, read-coding-system only expects string as a default > argument. It should recognize symbol. > > Because of CVS, this patch cantains another patch, > http://www.xemacs.org/list-archives/xemacs-patches/9910/msg00047.html > which I've got no reply. > > 1999-11-16 Yoshiki Hayashi > > * minibuf.el (read-coding-system): Accept symbol as > a default-coding-system. > > ------------------------------------------------------------------------ > Index: minibuf.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/minibuf.el,v > retrieving revision 1.14.2.7 > diff -u -r1.14.2.7 minibuf.el > --- minibuf.el 1999/07/22 06:19:44 1.14.2.7 > +++ minibuf.el 1999/11/16 06:44:55 > @@ -327,7 +327,7 @@ > (defvar current-minibuffer-contents) > (defvar current-minibuffer-point) > > -(defcustom minibuffer-history-minimum-string-length nil > +(defcustom minibuffer-history-minimum-string-length 1 > "*If this variable is non-nil, a string will not be added to the > minibuffer history if its length is less than that value." > :type '(choice (const :tag "Any" nil) > @@ -2118,7 +2118,9 @@ > Prompting with string PROMPT. > If the user enters null input, return second argument DEFAULT-CODING-SYSTEM." > (intern (completing-read prompt obarray 'find-coding-system t nil nil > - default-coding-system))) > + (if (symbolp default-coding-system) > + (symbol-name default-coding-system) > + default-coding-system)))) > > (defun read-non-nil-coding-system (prompt) > "Read a non-nil coding-system from the minibuffer. > > ------------------------------------------------------------------------ > > -- > Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Wed Nov 17 00:30:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA08741 for xemacs-beta-out; Wed, 17 Nov 1999 00:30:44 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA08728; Wed, 17 Nov 1999 00:30:33 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA22320; Tue, 16 Nov 1999 22:30:13 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <38323D41.39E7A8B4@666.com> Date: Tue, 16 Nov 1999 22:29:37 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof , zappo@ultranet.com CC: Eric Marsden , XEmacs beta list , Martin Buchholz Subject: Re: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes) References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I had absolutely no idea about the existence of EIEIO. Why isn't this an XEmacs package? Or even better, why isn't it distributed as a *standard* part of the distribution? Eric (Ludlam): Please read what Jan has to say below. If there is any change to the C code of XEmacs that would make EIEIO work significantly better, faster, or more reliably, I can guarantee that it will go into the XEmacs core. Even if you are not familiar with the C core, let me know generally what you are looking for and I can design it. ben Jan Vroonhof wrote: > Eric Marsden writes: > > [Yet another message marked for "Rereading when there is a non-zero > amount of free time] > > > EIEIO is at (with > > stuff like this I occasionally manage to forget I'm programming in a > > crummy imitation of a Lisp :-). > > Now that we have your attention. I have been wanting to look into this > for some time, but still haven't come around to it. Are there any > bottlenecks or imperfections with EIEIO that could be solved with a > little help from the C core? > > For instance I am thinking of > > opaque-cons (car cdr) > > Internal function. Like cons, but the return value is an opaque type > and will signal an error unless passed to opaque-* > > opaque-car (ocons) > opaque-cdr (ocons) > opaque-to-cons (ocons) > opaque-cons-p (ocons) > > Then you would have in usertype.el > > (defun deftype (type operations) > (put type 'type-operations operations) > (define-function > (make-symbol (cons "make-" (symbol-name type))) '(value) > `(opaque-cons ,type value)) > (define-function > (make-symbol (cons (symbol-name type))) "-value" '(t) > `((let ((c (opaque-to-cons t))) > (if (eq (car c) ,type) > (cdr c) > (error 'type-error "...."))))) > (define-function > (make-symbol (cons (symbol-name type))) "-p" '(t) > `(and (opaque-cons-p t) (eq (opaque-car t) ,type)))) > > etc > > Jan > > From owner-xemacs-beta@xemacs.org Wed Nov 17 00:44:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA09579 for xemacs-beta-out; Wed, 17 Nov 1999 00:44:57 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA09575 for ; Wed, 17 Nov 1999 00:44:55 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA25146; Tue, 16 Nov 1999 22:44:28 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <38324099.B2EED3F2@666.com> Date: Tue, 16 Nov 1999 22:43:53 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Oscar Figueiredo CC: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Actually, Oscar, I was suggesting more simple changes, i.e. just make your API consistent with general Elisp API principles. For example: -- Instead of ldap-add-internal, just call it ldap-put and make it the advertised interface. There is no need to provide an interface like ldap-add that automatically does an open and a close, displays messages, looks for ldap-default-host, etc. Follow standard convention and make the caller do this. ben Oscar Figueiredo wrote: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > >> Perhaps, but I think that the code to do anything ldap-ish would > >> still look very ldap-ish as opposed to abstract-database-ish. > > Hrvoje> I agree with Bill. Abstract interfaces are a nice thing up to a > Hrvoje> point, i.e. as long as they serve to us and not the other way around. > > Hrvoje> If LDAP serves a purpose totally different than a flat database, it's > Hrvoje> quite fine to have a different interface for the two. > > Just to add my 2 cts, I also like abstraction and uniform interfaces (after all > EUDC is a simple attempt at that) but I agree 200% with Bill and Hrvoje. The > LDAP APIs are still evolving, adhering to them is the simple way to go. Even > if we devised a good interface above the current API now, nothing guarantees we > could easily fit forthcoming evolutions into it. I, for one, won't go that way > but I won't discourage anyone that would like to implement such an interface. > > Oscar > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit From owner-xemacs-beta@xemacs.org Wed Nov 17 01:04:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA09908 for xemacs-beta-out; Wed, 17 Nov 1999 01:04:01 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA09904 for ; Wed, 17 Nov 1999 01:03:59 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id XAA28895; Tue, 16 Nov 1999 23:03:49 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <38324521.33BD67AB@666.com> Date: Tue, 16 Nov 1999 23:03:13 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: Hrvoje Niksic , XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Either int-char should be the mirror opposite of char-int (i.e. accept all legal char integers), or it should be removed entirely. int-char should *never* have any dependence on the language environment. I don't think C-q should either. If Hrvoje wants to insert Latin-2 characters by number, then make C-u C-q work so that it also prompts for a character set, with a default chosen from the language environment. ben Yoshiki Hayashi wrote: > Hrvoje Niksic writes: > > > As Ben said, now that we've fixed the actual bugs, we can think about > > changing the behaviour for int-char conversions for 21.2. > > Following are proposed which integers should be accepted > where characters are expected: > > 1) Don't allow anything > 2) Accept 0-127 > 3) Accept 0-256 > 4) Accept everything > > Other things proposed are: > > a) When doing C-q, treat 128-256 as Latin-2 in Latin 2 > language environment. > > So far, most of the proposal is intended to apply to every > int-char conversions, I'd like to make some functions to > accept. > > My plan is: > Accept only 0-256 in every place except int-to-char. > int-to-char accepts every valid integers. > Make new function which does int-to-char conversion > correctly according to the language environment. > > This way, most of the code which does (insert (1+ ?a)) or > something continues working. Now internal representation is > changed a little bit, so disabling > 256 characters will > warn those who are dealing with internal representation > directly, which is bad. Still, you can do > (let ((i 1442)) > (while (i < 2000) > (insert (int-to-char i)) > (setq i (+1 i)))) > to achieve old behaviour. > > For C-q, I'm not for changing it's original definition, > since it might confuse people who are expecting Latin-1 in > other language environment and typing just 1 integer doesn't > make sense for multibyte world. It's cleaner to make new > function, which does make-char according to the charset of > language-info-alist so that people who use that often can > bind it to C-q or some other keys. > > -- > Yoshiki Hayashi -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Wed Nov 17 01:11:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA10033 for xemacs-beta-out; Wed, 17 Nov 1999 01:11:32 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA10028 for ; Wed, 17 Nov 1999 01:11:30 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA26314; Tue, 16 Nov 1999 22:50:09 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <383241ED.362F7D79@666.com> Date: Tue, 16 Nov 1999 22:49:33 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Oscar Figueiredo CC: xemacs-beta@xemacs.org Subject: Re: stop_interrupts not working (was: Re: I need help from a signal expert !) References: <382E9902.538EEE4E@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Well, I can't see any reason why your proposal wouldn't work. So, why don't you either (a) Implement this simple change and see if it works, fixes problems, causes problems, etc. or (b) Put in a #### comment indicating that someone should do this. Oscar Figueiredo wrote: > >>>>> "Ben" == Ben Wing writes: > > Ben> Although you seem to have solved your problems through a different library, I think > Ben> it would be worthwhile to step through unrequest_sigio() and see what functions are > Ben> actually being called to affect the SIGIO signal. It's quite possible that > Ben> something is indeed wrong here and needs fixing. If so, it's going to affect lots > Ben> of places, and presumably all RedHat 6.0 users, and definitely needs to be fixed. > Ben> If you can't figure out what's going on, at least put in a #### comment in the > Ben> right place indicating that this function apparently doesn't do its job on RH 6.0, > Ben> which could lead to a lot of strange results. > > Ben> ben > > I made some more tests. The function `emacs_sleep' appears not to be working > for me. strace confirms that it is interrupted by a series of SIGIO signals. > The debugger shows that the function `unrequest_sigio_on_device' is executed > properly for a series of devices. Apparently a few are missing from the loop. > > I made the same test with xemacs -nw and the problem does not show up in that > case. The guilty device(s) seem therefore to be X-related. > > I have no idea how to trace the SIGIOs back to the device(s) that generated > them. > > I wonder, in the function `stop_interrupts', instead of calling unrequest_sigio > which disables SIGIO on each device one by one, wouldn't it be faster and safer > to simply disable SIGIO as a whole with a call to EMACS_BLOCK_SIGNAL (SIGIO) ? > > Oscar > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit From owner-xemacs-beta@xemacs.org Wed Nov 17 01:12:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA10087 for xemacs-beta-out; Wed, 17 Nov 1999 01:12:54 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA10083 for ; Wed, 17 Nov 1999 01:12:52 -0500 Received: from 666.com (dialup14ip030.tus.azstarnet.com [169.197.36.158]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA25847; Tue, 16 Nov 1999 22:47:55 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <38324167.5F3E4B41@666.com> Date: Tue, 16 Nov 1999 22:47:19 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: "Stephen J. Turnbull" , XEmacs beta list Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: No need to pervert the interfaces as much as you propose. Instead, provide new functions get-database-many and put-database-many that handle multiple this and that. "William M. Perry" wrote: > "Stephen J. Turnbull" writes: > > > >>>>> "-BP" == William M Perry writes: > > > > -BP> To merge the LDAP code, you would have to do a major overhaul > > -BP> of the existing database code, and I'm not sure you would be > > -BP> able to get the full power of LDAP without making the > > -BP> 'normal' databases pretty difficult to use. > > > > OK, that's why it might be hard. It still sounds like it's a good > > idea to me. > > Perhaps, but I think that the code to do anything ldap-ish would still look > very ldap-ish as opposed to abstract-database-ish. Another big problem > with LDAP vs. the other database types is the ability to have multiple > values off of a single attribute, and each 'key' in the database can have > multiple attributes. In LDAP you have: > > uid=wmperry,ou=aventail.com,c=us -> cn = William M. Perry > Bill Perry > Emacs Dork > mail = wmperry@aventail.com > > The older database backends would require you to do: > > You could theoretically do: > > - extend open-database to take a plist, but this breaks all (any?) existing > code. LDAP would be a generic instance with > (open-database '(:host "ldap.in.aventail.com" :type ldap :subtype 3 > :bind-username "something" > :bind-password "somethingelse" > :base "o=aventail.com, c=us")) > > - extend get-database to be able to return multiple hits for a key. > (get-database KEY ATTRIBUTE DATABASE) > > Documentation: > Return value(s) for ATTRIBUTE on object KEY in DATABASE. > An assoc list is returned, the car of each entry in the list the > attribute name. The cdr is a list of values for that attribute. > > If there is no corresponding value, return nil. > If ATTRIBUTE is t, returns all attributes and values. > > (get-database "uid=wmperry, o=aventail.com, c=us" "mail" dbhandle) > => '(("mail" "wmperry@aventail.com")) > > (get-database "uid=wmperry, o=aventail.com, c=us" "cn" dbhandle) > => '(("mail" "wmperry@aventail.com") > ("cn" "William M. Perry" "Bill Perry" "Emacs Dork")) > > - extend put-database to be able to set multiple hits for a key, and submit > multiple changes at once. > > (put-database KEY VALUES DATABASE &optional replace) > Documentation: > Updated record KEY in DATABASE with new VALUES. > VALUES is an assoc list of attribute/value pairs. > Some databases support multiple values. > If optional fourth arg REPLACE is non-nil, > replace any existing entry in the database. > This whole doc string needs better updates. :) > > (put-database "uid=wmperry, o=aventail.com, c=us" > '("cn" "Willie Perry") > dbhandle nil) > => t > > Would _add_ a CN to the record, so we'd now look like: > > uid=wmperry,ou=aventail.com,c=us -> cn = William M. Perry > Bill Perry > Emacs Dork > Willie Perry > mail = wmperry@aventail.com > > - New function search-database > (search-database DATABASE CRITERIA) > Documentation: > Search DATABASE for records matching CRITERIA. > CRITERIA is a property list. It is up to the backend database to convert > this to native representation. > > Maybe we could have something for this that looks more lispish than an > LDAP request. I'm not sure how a berkeley db database would implement > this. For LDAP, we could have something like: > > (search-database dbhandle > '(& (| ("cn" "William M. Perry" "Bill Perry")) > ("mail" "wmperry@aventail.com"))) > > The ldap backend would convert this into: > > "(& (| (cn=William M. Perry") (cn="Bill Perry")) (mail=wmperry@aventail.com"))" > > And pass that off to ldap_search() > > - map-database would have to be revamped to return new values, etc. > > It would be nice if you could register new database backends at runtime, > even for lisp functions. Then you could write an SQL backend in lisp using > . That could be done by > having a generic 'elisp' backend in database.c, and be able to do something > like: > > (define-database TYPE FUNCPLIST) > > Where the entries in FUNCPLIST would be the generic name 'open' 'close' > 'search' etc would be the key, and the value would be the actual lisp > function to call to do the searching. > > That's all just off the top of my head, but it might work. :) > > -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 17 03:07:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA13564 for xemacs-beta-out; Wed, 17 Nov 1999 03:07:32 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA13561 for ; Wed, 17 Nov 1999 03:07:30 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o07a-0007eC-00; Wed, 17 Nov 1999 09:07:18 +0100 To: Ben Wing Cc: Yoshiki Hayashi , XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 09:07:18 +0100 In-Reply-To: Ben Wing's message of "Tue, 16 Nov 1999 23:03:13 -0700" Message-ID: <9t9n1sdh77t.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > If Hrvoje wants to insert Latin-2 characters by number Not only me. Everyone from the Latin 2 world will find it very strange that C-q inserts Latin 1 chars. (I say "will" rather than "did" because the Latin 2 world has yet to discover Mule.) From owner-xemacs-beta@xemacs.org Wed Nov 17 03:24:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14088 for xemacs-beta-out; Wed, 17 Nov 1999 03:24:13 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14084 for ; Wed, 17 Nov 1999 03:24:08 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o0NW-0007fE-00 for ; Wed, 17 Nov 1999 09:23:46 +0100 To: XEmacs Beta List Subject: Re: 21.2.b20: C-g in isearch differs from old b17 behavior References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 09:23:46 +0100 In-Reply-To: Mark Thomas's message of "16 Nov 1999 18:23:42 -0500" Message-ID: <9t9ln7xfrvx.fsf@mraz.iskon.hr> Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mark Thomas writes: > Suppose I isearch (successfully) for "foo" and press RET to exit > isearch. Next I isearch (successfully) for "bar" and use C-g to > exit isearch. In b17, pressing C-s C-s would isearch for "bar"; in > b20, it searches for "foo". > > Is this by design? Yes. C-g cancels the incremental search, which means that it backs up the point to where it was, and forgets the old search string. The change happened because I merged isearch-mode.el with FSF Emacs. I was careful not to destroy useful XEmacs features in the process, but I think this behaviour is acceptable. > I notice that isearch-quit (bound by default to (ugh!) ESC ESC ESC) > remembers the most recent search string. For me it doesn't. ESC ESC ESC is bound to isearch-cancel, and behaves almost exactly the same as C-g, bound to isearch-abort. From owner-xemacs-beta@xemacs.org Wed Nov 17 03:49:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14724 for xemacs-beta-out; Wed, 17 Nov 1999 03:49:46 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14720 for ; Wed, 17 Nov 1999 03:49:43 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id AAA14816; Wed, 17 Nov 1999 00:49:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14386.27674.246870.272704@lasker.666.com> Date: Wed, 17 Nov 1999 00:49:30 -0800 (PST) From: Martin Buchholz To: Jan Vroonhof Cc: XEmacs Beta Test , "Ravi Wikramanayake" , Andreas Jaeger Subject: Re: elisp packages In-Reply-To: References: <19991116050414.6212.qmail@hotmail.com> <14385.47524.289812.698251@lasker.666.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Martin Buchholz writes: >> that it is entirely natural that people would omit including the >> packages, even if they are professional GNU software maintainers such >> as inhabit Cygnus. Jan> Are you sure that the Cygwin people forgot to put the packages on the Jan> CD? I really cannot believe that. It's incredibly easy to do. What other packages on the Net build and install `successfully', yet are effectively useless when actually used? It's all too easy for someone whose job it is to populate a CD with many `working' programs to repeat the algorithm ftp; tar -x; cd; configure; make; make install; copy to CD and consider the job finished when they get rc=0. For this reason the distinction between a `core' library and an optional separately installable library is so crucial. For example, I consider `libnet' the single most useful non-core library for perl. It is non-core (personal communication from the author) only for perl-internal political reasons. I would bet that *no* Linux distribution out there would distribute a perl that comes with any extra libraries such as libnet. ("Why not trust Larry?") As a result, scripts that have any pretense at portability at all would either not use libnet, or come with their own pre-built libnet library directory. Even if you have administrative control over all the machines that would use that script, you still have the hassle of having your script broken every time you upgrade the OS on your machine, because the upgraded perl fails to have its own libnet. It's annoying having your OS upgrade procedure contain another random step that's easy to forget. I consider it a mini-disaster that perl does not come with libnet. Fortunately for perl, many uses of perl use just the standard core functionality. Few users of XEmacs just use the current `core' functionality. >> Also, people who did try to follow the >> instructions and use documented interfaces to install packages after >> installing the `core' XEmacs often failed (and reverted to 20.4, since >> that actually `worked'). >> >> >From this point of view, the package system has been an unmitigated disaster. Jan> Frankly I think the package system hasn't had a fair chance yet. Our Jan> communication, QA and maintenance crisis has amplified it weaknesses Jan> while not allowing us to profit from its benefits. Jan> We actually have had a split tarball system for the binaries for ages Jan> and I have seen relatively few complaints about that. The only real Jan> conceptual difference was that the binaries complained loudly if they Jan> couldn't bind the stuff from xemacs-common. It's true that having good READMEs and having the relevant files in a common directory helps a *lot*. Complaining loudly and making it clear that XEmacs was incorrectly installed is a good clue. The worst thing about the current XEmacs distribution is that it builds, installs and even runs without complaint. It seems `obvious' that the program maintainers intended the editor to be used that way. Yet we the maintainers know that it's actually useless for doing any real work. Martin From owner-xemacs-beta@xemacs.org Wed Nov 17 03:49:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14730 for xemacs-beta-out; Wed, 17 Nov 1999 03:49:53 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14727; Wed, 17 Nov 1999 03:49:52 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id JAA01324; Wed, 17 Nov 1999 09:49:41 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000Kc; Wed Nov 17 09:49:39 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id JAA17487; Wed, 17 Nov 1999 09:49:38 +0100 To: Ben Wing Cc: Yoshiki Hayashi , XEmacs Review , XEmacs beta list Subject: Re: read-coding-system References: <87puxa9b50.fsf@dp50.ecc.u-tokyo.ac.jp> <3832064A.5A8B3C69@666.com> From: Jan Vroonhof Date: 17 Nov 1999 09:49:38 +0100 In-Reply-To: Ben Wing's message of "Tue, 16 Nov 1999 18:35:06 -0700" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > 1) You should never combine patches like this. Instead, resubmit the patch that > was not approved, with a comment about this fact. (Which the patch tender -- > currently Jan -- ought to have noticed, and done something about.) I still never volunteered for that, I just seem to be the only one doing that. All Yoshiki patches are sitting in a bright right in my xemacs-review buffer. I just need a few straight hours at home to apply them, and those have been rare. Yoshiki please mail me again if any stuff is not in by next monday. Jan From owner-xemacs-beta@xemacs.org Wed Nov 17 03:55:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14910 for xemacs-beta-out; Wed, 17 Nov 1999 03:55:56 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14907 for ; Wed, 17 Nov 1999 03:55:53 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id JAA01496; Wed, 17 Nov 1999 09:55:51 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa000NL; Wed Nov 17 09:55:48 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id JAA17496; Wed, 17 Nov 1999 09:55:48 +0100 To: Mark Thomas Cc: XEmacs Beta Test Subject: Re: 21.2.b20: C-g in isearch differs from old b17 behavior References: From: Jan Vroonhof Date: 17 Nov 1999 09:55:48 +0100 In-Reply-To: Mark Thomas's message of "16 Nov 1999 18:23:42 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Mark Thomas writes: > Suppose I isearch (successfully) for "foo" and press RET to exit > isearch. Next I isearch (successfully) for "bar" and use C-g to exit > isearch. In b17, pressing C-s C-s would isearch for "bar"; in b20, it > searches for "foo". > > Is this by design? I don't remember seeing mention of it on the > xemacs-beta list. I don't think so. Hrvoje did a lot of work on isearch to feature sync with FSF. He probably made a mistake somewhere. Jan From owner-xemacs-beta@xemacs.org Wed Nov 17 04:15:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA15844 for xemacs-beta-out; Wed, 17 Nov 1999 04:15:34 -0500 Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA15832 for ; Wed, 17 Nov 1999 04:15:29 -0500 Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id KAA22114; Wed, 17 Nov 1999 10:15:09 +0100 (MET) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id KAA23327; Wed, 17 Nov 1999 10:15:14 +0100 (MET) To: XEmacs Beta List Cc: Yoshiki Hayashi Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 17 Nov 1999 10:15:13 +0100 In-Reply-To: Ben Wing's message of "Tue, 16 Nov 1999 23:03:13 -0700" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "bw" == Ben Wing writes: bw> Either int-char should be the mirror opposite of char-int (i.e. bw> accept all legal char integers), or it should be removed bw> entirely. if you get rid of int-char, you will have to add some way of generating "special" characters, like #\null, #\tab etc. -- Eric Marsden From owner-xemacs-beta@xemacs.org Wed Nov 17 05:18:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA17609 for xemacs-beta-out; Wed, 17 Nov 1999 05:18:09 -0500 Received: from nemesis.ncsl.nist.gov (nemesis.ncsl.nist.gov [129.6.57.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA17606 for ; Wed, 17 Nov 1999 05:18:08 -0500 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id FAA03084; Wed, 17 Nov 1999 05:18:02 -0500 Date: Wed, 17 Nov 1999 05:18:01 -0500 From: Olivier Galibert To: Eric Marsden Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed Message-ID: <19991117051801.A2845@nemesis.ncsl.nist.gov> Mail-Followup-To: Eric Marsden , XEmacs Beta List References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Eric Marsden on Wed, Nov 17, 1999 at 10:15:13AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 17, 1999 at 10:15:13AM +0100, Eric Marsden wrote: > if you get rid of int-char, you will have to add some way of > generating "special" characters, like #\null, #\tab etc. #\null : ?\0 or (make-char 'ascii 0) #\tab : ?\t or ?\011 or (make-char 'ascii 9) OG. From owner-xemacs-beta@xemacs.org Wed Nov 17 05:26:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA17760 for xemacs-beta-out; Wed, 17 Nov 1999 05:26:18 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA17757 for ; Wed, 17 Nov 1999 05:26:15 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o2Hy-0007lf-00 for ; Wed, 17 Nov 1999 11:26:10 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 11:26:10 +0100 In-Reply-To: Eric Marsden's message of "17 Nov 1999 10:15:13 +0100" Message-ID: <9t9u2mle7nh.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Eric Marsden writes: > if you get rid of int-char, you will have to add some way of > generating "special" characters, like #\null, #\tab etc. ?\0, ?\t and friends will always work. But I think int-char should definitely stay, at least in the 0-255 range. From owner-xemacs-beta@xemacs.org Wed Nov 17 05:28:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA17798 for xemacs-beta-out; Wed, 17 Nov 1999 05:28:42 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA17794 for ; Wed, 17 Nov 1999 05:28:41 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id CAA15472; Wed, 17 Nov 1999 02:28:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14386.33623.74736.850257@lasker.666.com> Date: Wed, 17 Nov 1999 02:28:39 -0800 (PST) From: Martin Buchholz To: XEmacs Beta Test Subject: index.texi and CVS updates X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: There is a change I just committed to CVS that will not quite work with `cvs update'. The file index.texi used to be a generated symlink, but now it's a regular file in CVS. So do rm man/*/index.texi before cvs update (although things should work anyways if you omit this; however, CVS will continue to issue scary messages until you remove the index.texi files and re-run `cvs update'. Martin From owner-xemacs-beta@xemacs.org Wed Nov 17 05:30:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA17882 for xemacs-beta-out; Wed, 17 Nov 1999 05:30:49 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA17879 for ; Wed, 17 Nov 1999 05:30:48 -0500 Received: by localhost id m11o2MQ-00016mC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 17 Nov 1999 19:30:46 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> Date: Wed, 17 Nov 1999 19:30:46 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <38324521.33BD67AB@666.com> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Can somebody give a bunch of examples where using integers as characters is useful? For that matter, where they are actually used? Ben said "backward compatibility," but I haven't seen this used, and I don't really know how to grep for it. I have grepped for int-char, int-to-char, char-int, and char-to-int and they're pretty rare in the core and package code (2/3 of it) that I have. The only one that I ever use is the C-q hack for inserting characters by code value at the keyboard, and that could arguably (and in Japanese invariably is) delegated to an input method which would know about language environment (and return a true character). For iterating over a character set in "natural" order, only ASCII satisfies the requirement of having one, and even that's shaky. AFAIK the Swedes and the Norwegians, or is it the Danes, disagree on ordering the _letters_ in ISO-8859-1 character set. This really should be table-driven, and will have to be for everything except ASCII and ISO-8859-1 if we go to a Unicode internal representation. We already have primitives for efficient case conversion and the like. The only example I can think of offhand where you would really really want the facility is to iterate over a code space where you don't know which points are legal characters. Eg, to print out tables of fonts. Pretty specialized. And this can be done through make-char, anyway. According to CLtL1, the main portable use for char-int is for hashing. But that doesn't square with the kind of usage we've been talking about (in loops and the like). What else am I missing? Ben's desiderata have some problems. >>>>> "Ben" == Ben Wing writes: Ben> Either int-char should be the mirror opposite of char-int Ben> (i.e. accept all legal char integers), or it should be Ben> removed entirely. OK. I agree with this. Ben> int-char should *never* have any dependence on the language Ben> environment. In one-byte buffers (either Olivier's 1/2/4 extension or `xemacs -font *-iso8859-2') it implicitly will have dependence whatever you say. Even without Mule, people can always use external encoders to change raw ISO-8859-2 to ISO-2022 (not that anybody sane ever would, OK, Hrvoje?). Then the two files will be interpreted differently in a Latin-1 locale Mule; the ISO-8859-2 file will be recognized as ISO-8859-1, and the ISO-2022 file will be internally interpreted as ISO-8859-2. The point is that people normally assume that int-char should accept their "natural" integer to character map. For Americans, that's ASCII, for Germans, that's ISO-8859-1, for Croatians, that's ISO-8859-2. And it works "correctly" in a no-mule XEmacs with `-font *-iso8859-2'! Japanese usually use ku-ten or JIS, and there's a "natural" map from byte-sized integer pairs to shorts, but it's full of holes. So language environments don't agree on what a legal char integer is, and where they do (eg, ISO-8859-1 and ISO-8859-2), they don't agree on the map. To satisfy your dictum (with which I agree, but I take to mean we should get rid of these functions) we can take the intersection where they agree ==> legal char integers == ASCII which is what I prefer, or pick something arbitrary and efficient ==> char-int returns the internal representation which I really hate, or something else. Suggestions? Ben> I don't think C-q should either. If Hrvoje wants to insert Ben> Latin-2 characters by number, then make C-u C-q work so that Ben> it also prompts for a character set, with a default chosen Ben> from the language environment. And restrict this to ASCII? Or assume Latin-1 in GR if there is no prefix argument? This is a useful feature. C-q currently inserts Latin-2 characters for Hrvoje in no-mule XEmacs (stretching the point only a little); I think it should continue to do so in Mule. This really is an input method issue, not a keyboard issue. In XEmacs, inserting an integer into a buffer has no meaning. Users insert characters. So this is a completely different issue from the programming API, and should not be considered analogous. Maybe we could have C-q insert according to the Unicode standard, and treat C-u C-q as part of the input method. But I think most users would prefer to have C-q insert according to their locale-standard tables, and select Unicode explicitly using the C-u C-q idiom. In fact (again this points to the input method idea), Japanese users would probably like to have the alternatives of using kuten (pairs from 1--94 x 1--94) or JIS (pairs from 0x21--0x7E x 0x21--0x7E) as options since both indexing systems are common in tables. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Wed Nov 17 05:31:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA17892 for xemacs-beta-out; Wed, 17 Nov 1999 05:31:20 -0500 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA17884; Wed, 17 Nov 1999 05:31:04 -0500 Received: from hpbbse.bbn.hp.com (root@hpbbse.bbn.hp.com [15.136.26.26]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id CAA23445; Wed, 17 Nov 1999 02:31:01 -0800 (PST) Received: from bbn.hp.com (tmbbwmt.bbn.hp.com [15.136.25.175]) by hpbbse.bbn.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id LAA11925; Wed, 17 Nov 1999 11:30:59 +0100 (MEZ) Received: (from thiessel@localhost) by bbn.hp.com (8.8.6 (PHNE_17190)/8.8.6) id LAA21556; Wed, 17 Nov 1999 11:30:59 +0100 (MET) From: Marcus Thiessel Message-ID: <14386.33763.182913.31187@gargle.gargle.HOWL> Date: Wed, 17 Nov 1999 11:30:59 +0100 (MET) To: ben@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: JOBS list for XEmacs In-Reply-To: <14375.50455.447946.792924@lasker.666.com> References: <14375.50455.447946.792924@lasker.666.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid X-Face: $Ni[2@rr#(N|NUCz5KIWbyoZAxlt%A0v\FN^6!ES@.B}HU9e_* 9(ruLWwCx'bZvjoKvMR #;;T1kZYsWEGnbkXl76=Eb%qdUBo7]:[AmX&RqthqAPcqSQ95n{ fJBPEP{fXYYdGezPd7;=(g{*FDUw8!XB*EXNi@@x&Qi>~Ha'$V%` X-Attribution: mt Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing , Martin Buchholz writes: > > Position Primary Secondary > ------------------------------------------------------------ > Webmaster John Anderson You can keep as secondary for webmaster. From owner-xemacs-beta@xemacs.org Wed Nov 17 05:35:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA18004 for xemacs-beta-out; Wed, 17 Nov 1999 05:35:33 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA18001 for ; Wed, 17 Nov 1999 05:35:32 -0500 Received: by localhost id m11o2R0-00016mC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 17 Nov 1999 19:35:30 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14386.34034.615608.257908@turnbull.sk.tsukuba.ac.jp> Date: Wed, 17 Nov 1999 19:35:30 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9u2mle7nh.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <9t9u2mle7nh.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> But I think int-char should definitely stay, at least in Hrvoje> the 0-255 range. What should `(int-char 161)' evaluate to in Mule? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Wed Nov 17 06:07:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA18787 for xemacs-beta-out; Wed, 17 Nov 1999 06:07:01 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA18784 for ; Wed, 17 Nov 1999 06:06:59 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o2vR-0007mx-00 for ; Wed, 17 Nov 1999 12:06:57 +0100 To: XEmacs Beta List Subject: cperl-mode bugs X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 12:06:57 +0100 Message-ID: <9t9ln7xe5ri.fsf@mraz.iskon.hr> Lines: 3 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Who do I report cperl-mode bugs to? Bob Olson and Ilya Zakharevich are listed as authors, and "XEmacs Development Team" as maintainer, but the bug I want to report is not XEmacs-specific. From owner-xemacs-beta@xemacs.org Wed Nov 17 06:09:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA18875 for xemacs-beta-out; Wed, 17 Nov 1999 06:09:38 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA18872 for ; Wed, 17 Nov 1999 06:09:28 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o2xr-0007n9-00 for ; Wed, 17 Nov 1999 12:09:27 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <9t9u2mle7nh.fsf@mraz.iskon.hr> <14386.34034.615608.257908@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 12:09:27 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 17 Nov 1999 19:35:30 +0900 (JST)" Message-ID: <9t9hfile5nc.fsf@mraz.iskon.hr> Lines: 15 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id GAA18873 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> But I think int-char should definitely stay, at least in > Hrvoje> the 0-255 range. > > What should `(int-char 161)' evaluate to in Mule? The same as now -- ?¡. That's not perfect, but it's good enough for me. People who want other Latin charsets can use make-char. Additionally, the same code will work with and without Mule, now that non-Mule XEmacs has make-char. From owner-xemacs-beta@xemacs.org Wed Nov 17 06:37:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA19853 for xemacs-beta-out; Wed, 17 Nov 1999 06:37:52 -0500 Received: from apollonius.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA19847 for ; Wed, 17 Nov 1999 06:37:50 -0500 Received: from KEATS.eai-delta.de (keats.eai-delta.de [192.9.200.85]) by apollonius.eai-delta.de (8.9.3/8.8.7) with SMTP id MAA02436 for ; Wed, 17 Nov 1999 12:37:45 +0100 To: XEmacs Beta List Subject: Can't build latest CVS Sources Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: . Date: 17 Nov 1999 12:37:45 +0100 Message-ID: Lines: 16 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi! I get the following error: console-msw.c ..\src\lisp.h(2138) : error C2143: syntax error : missing ')' before '*' ..\src\lisp.h(2138) : error C2143: syntax error : missing '{' before '*' ..\src\lisp.h(2138) : error C2059: syntax error : ')' ..\src\lisp.h(2138) : error C2059: syntax error : ';' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. The culprit seems to be 'uid_t'. Where is it defined? Thanks, norbert. From owner-xemacs-beta@xemacs.org Wed Nov 17 07:41:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA22487 for xemacs-beta-out; Wed, 17 Nov 1999 07:41:50 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA22482 for ; Wed, 17 Nov 1999 07:41:46 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA13490; Wed, 17 Nov 1999 13:41:44 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa003Ik; Wed Nov 17 13:41:42 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id NAA17671; Wed, 17 Nov 1999 13:41:41 +0100 To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> From: Jan Vroonhof Date: 17 Nov 1999 13:41:41 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 17 Nov 1999 19:30:46 +0900 (JST)" Message-ID: Lines: 24 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > don't really know how to grep for it. I have grepped for int-char, > int-to-char, char-int, and char-to-int and they're pretty rare in the > core and package code (2/3 of it) that I have. I think that doesn't work. A lot of the conversions are implicit, like in the loops you mentioned. (let ((myvar ?a)) (while (<= myvar ?z) (insert myvar) (setq myvar (1+ myvar)))) (For this case it would be sufficient to have int->char conversion work in ascii.) Jan -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof @ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085 From owner-xemacs-beta@xemacs.org Wed Nov 17 07:49:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA22664 for xemacs-beta-out; Wed, 17 Nov 1999 07:49:18 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA22661 for ; Wed, 17 Nov 1999 07:49:14 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o4WI-0007pf-00; Wed, 17 Nov 1999 13:49:06 +0100 To: XEmacs Beta List Cc: Ben Wing Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 13:49:06 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 17 Nov 1999 19:30:46 +0900 (JST)" Message-ID: <9t9u2mlcmgt.fsf@mraz.iskon.hr> Lines: 57 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [ I've added Ben to Cc because he AFAIR doesn't read xemacs-beta. ] "Stephen J. Turnbull" writes: > Can somebody give a bunch of examples where using integers as > characters is useful? I can. Here are four: (let ((letter ?a)) (while (< letter ?z) ... do something with letter ... (incf letter))) ;; The above example can be coded more nicely after my changes to ;; translate-region (which see), but we're talking legacy code here. (defun turn-a-into-b () (let ((string (make-string 256 ?\0))) (dotimes (i 265) (aset string i i)) (aset string ?a ?b) (translate-region (point-min) (point-max)))) (defvar foo-legal-chars (mapcar #'int-char '(... a bunch of numeric values imported from somewhere ...))) (defun stupid () (let ((number (read-number "Please enter a number: "))) (message "The character that corresponds to %d is: %c" number (int-char number)))) I could think of more of such, but I don't really see the point. Remember that characters have been indistinguishable from characters within Emacs for *decades*. > For that matter, where they are actually used? Ben said "backward > compatibility," but I haven't seen this used, and I don't really > know how to grep for it. I have grepped for int-char, int-to-char, > char-int, and char-to-int and they're pretty rare in the core and > package code (2/3 of it) that I have. The ones without them are even worse because they are implicit. See my examples. > The only one that I ever use is the C-q hack for inserting > characters by code value at the keyboard, and that could arguably > (and in Japanese invariably is) delegated to an input method which > would know about language environment (and return a true character). Some of us don't do input methods. But that's beside the point, because C-q can as well use make-char or whatever. > We already have primitives for efficient case conversion ...which don't work. More about that in a separate message. From owner-xemacs-beta@xemacs.org Wed Nov 17 09:12:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25100 for xemacs-beta-out; Wed, 17 Nov 1999 09:12:13 -0500 Received: from choochoo.ultranet.com (choochoo.ultranet.com [199.232.59.230]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25092; Wed, 17 Nov 1999 09:12:05 -0500 Received: (from zappo@localhost) by choochoo.ultranet.com (8.9.3/8.9.3) id JAA13283; Wed, 17 Nov 1999 09:11:55 -0500 Date: Wed, 17 Nov 1999 09:11:55 -0500 Message-Id: <199911171411.JAA13283@choochoo.ultranet.com> X-Authentication-Warning: choochoo.ultranet.com: zappo set sender to zappo@ultranet.com using -f From: "Eric M. Ludlam" To: ben@666.com CC: vroonhof@math.ethz.ch, emarsden@mail.dotcom.fr, xemacs-beta@xemacs.org, martin@xemacs.org In-reply-to: <38323D41.39E7A8B4@666.com> (message from Ben Wing on Tue, 16 Nov 1999 22:29:37 -0700) Subject: Re[1]: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes) Reply-to: zappo@ultranet.com References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <38323D41.39E7A8B4@666.com> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello everyone on this thread: >>> Ben Wing seems to think that: >I had absolutely no idea about the existence of EIEIO. > >Why isn't this an XEmacs package? Or even better, why isn't it >distributed as a *standard* part of the distribution? > >Eric (Ludlam): Please read what Jan has to say below. If there is any >change to the C code of XEmacs that would make EIEIO work significantly >better, faster, or more reliably, I can guarantee that it will go into the >XEmacs core. Even if you are not familiar with the C core, let me know >generally what you are looking for and I can design it. [ ... ] These are the following "problems" that I have had trouble with in that are directly related to Emacs. Most probably require no action other than information. * EIEIO objects are vectors, and display as vectors. I hacked edebug to print them in an object like notation * Whenever byte compilers get tweaked, I have to figure out the new nuances and fix `eieio-comp.el'. In particular I had trouble dumping byte-code streams. * Doc strings for classes and methods are rebuilt from their component parts. It would be nice if the eieio function `describe-class' could be used from `describe-variable' automatically. * CLOS uses fset to set fields while I wrote special oset,oref functions. I think I still correctly interface with cl.el for that though. A side affect is that you can't fset in `with-slots', and a few other strange things. >Jan Vroonhof wrote: > >> Eric Marsden writes: >> >> [Yet another message marked for "Rereading when there is a non-zero >> amount of free time] >> >> > EIEIO is at (with >> > stuff like this I occasionally manage to forget I'm programming in a >> > crummy imitation of a Lisp :-). >> >> Now that we have your attention. I have been wanting to look into this >> for some time, but still haven't come around to it. Are there any >> bottlenecks or imperfections with EIEIO that could be solved with a >> little help from the C core? >> >> For instance I am thinking of >> >> opaque-cons (car cdr) >> >> Internal function. Like cons, but the return value is an opaque type >> and will signal an error unless passed to opaque-* >> >> opaque-car (ocons) >> opaque-cdr (ocons) >> opaque-to-cons (ocons) >> opaque-cons-p (ocons) >> >> Then you would have in usertype.el >> >> (defun deftype (type operations) >> (put type 'type-operations operations) >> (define-function >> (make-symbol (cons "make-" (symbol-name type))) '(value) >> `(opaque-cons ,type value)) >> (define-function >> (make-symbol (cons (symbol-name type))) "-value" '(t) >> `((let ((c (opaque-to-cons t))) >> (if (eq (car c) ,type) >> (cdr c) >> (error 'type-error "...."))))) >> (define-function >> (make-symbol (cons (symbol-name type))) "-p" '(t) >> `(and (opaque-cons-p t) (eq (opaque-car t) ,type)))) [ ... ] In my case, I use vectors instead of lists for everything for purposes of speed. The first versions of EIEIO made things practically unusable when it used all lists, so I spent a bunch of time doing this. Unfortunately my lack of lispy knowledge at the time had me choose a rather convoluted technique. (I still debate between object obarrays and my existing single occurance obarray with array indices.) While storing a vector in an opaque cons cell is certainly a possibility, it just adds one more layer to dereference, and would make it tough to track versions of Emacs with the above change against those without. I would also hazard a guess that individuals trying to hack new types will also want to use vectors instead of lists. (though I may be missing something...) If instead I could do this in my code: (if (fboundp 'make-normal-vector-special) (make-normal-vector-special V PREDICATE PRINTER WHATEVER)) Then in a ref/set function I could do this: (let ((some-variable-with-special-meaning 'eieio-object)) (do normal stuff)) or have this in eieio: (if (fboundp 'reference-special-vector) (defalias eieio-....) ...) then maintenance would be much easier. I know deep down this will probably be considered an evil hack, but my main concern is compatibility with as many Emacses as possible. I still get bug reports from very old versions of Emacs and XEmacs (and sometimes from versions of [X]Emacs I never thought were released). Anyway, to add to your typing function above, a -print type function would also be useful. It can take emacs a long time to print a 20 element vector with deep lists in it when only 80 characters will be displayed. A nice short # is usually plenty. Anyway, those are my thoughts of the day. You happened to write during a week when I was trying to make multiple-inheritance work so I didn't have to make a big context-switch. Thanks. :) Enjoy Eric (Ludlam) From owner-xemacs-beta@xemacs.org Wed Nov 17 09:14:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25222 for xemacs-beta-out; Wed, 17 Nov 1999 09:14:10 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25219 for ; Wed, 17 Nov 1999 09:14:08 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA21906; Wed, 17 Nov 1999 15:14:04 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa005MG; Wed Nov 17 15:14:01 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id PAA17778; Wed, 17 Nov 1999 15:14:00 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: 21.2.b20: C-g in isearch differs from old b17 behavior References: <9t9ln7xfrvx.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 17 Nov 1999 15:14:00 +0100 In-Reply-To: Hrvoje Niksic's message of "17 Nov 1999 09:23:46 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > > Is this by design? > > Yes. C-g cancels the incremental search, which means that it backs up > the point to where it was, and forgets the old search string. Can you give me an example where that would be useful. I very often use isearch to just look something up below and then type C-g to get back where I was. Although I am trying to get used to using vcursor.el for that kind of stuff. Jan From owner-xemacs-beta@xemacs.org Wed Nov 17 09:15:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25271 for xemacs-beta-out; Wed, 17 Nov 1999 09:15:47 -0500 Received: from reagan.ppllc.com (leonardo.ppllc.com [209.208.206.194]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25268 for ; Wed, 17 Nov 1999 09:15:45 -0500 Received: (from colman@localhost) by reagan.ppllc.com (8.9.1b+Sun/8.9.0) id JAA04760; Wed, 17 Nov 1999 09:28:13 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Whatever happened to 21.1.8? From: Jake Colman Date: 17 Nov 1999 09:28:13 -0500 Message-ID: <76n1sdi45e.fsf@ppllc.com> Lines: 18 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Was 21.1.8 ever released? I remember the maintainer mentioning that he was about to release it several weekends ago but I don't recall having seen it. TIA! -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 505-2795 Jersey City, NJ 07311 E-mail: colman@ppllc.com E-mail: jcolman@jnc.com web: http://www.ppllc.com "Every time I think I've idiot-proofed something someone comes up with a better idiot" From owner-xemacs-beta@xemacs.org Wed Nov 17 09:19:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25434 for xemacs-beta-out; Wed, 17 Nov 1999 09:19:57 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25431 for ; Wed, 17 Nov 1999 09:19:55 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA22020; Wed, 17 Nov 1999 15:19:55 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa005O2; Wed Nov 17 15:19:49 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id PAA17781; Wed, 17 Nov 1999 15:19:48 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: cperl-mode bugs References: <9t9ln7xe5ri.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 17 Nov 1999 15:19:48 +0100 In-Reply-To: Hrvoje Niksic's message of "17 Nov 1999 12:06:57 +0100" Message-ID: Lines: 21 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Who do I report cperl-mode bugs to? You made a mistake by saying "I" :-) > Bob Olson and Ilya Zakharevich > are listed as authors, and "XEmacs Development Team" as maintainer, > but the bug I want to report is not XEmacs-specific. You check whether the bug is fixed in Ilya Zakharevich latest version (which it probably is) and then do the sync that is long overdue :-). If it is not fixed by Ilya., you do the sync anyway, Ilya is again the maintainer and you mail it him. Problem Solved :-) Jan P.S. The only really import XEmacs specific stuff in our versions is the support for delete-key-deletes-backwards. IIRC From owner-xemacs-beta@xemacs.org Wed Nov 17 09:22:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25526 for xemacs-beta-out; Wed, 17 Nov 1999 09:22:43 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25523 for ; Wed, 17 Nov 1999 09:22:38 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o5yj-0007th-00 for ; Wed, 17 Nov 1999 15:22:33 +0100 To: XEmacs Beta List Subject: Re: 21.2.b20: C-g in isearch differs from old b17 behavior References: <9t9ln7xfrvx.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 15:22:33 +0100 In-Reply-To: Jan Vroonhof's message of "17 Nov 1999 15:14:00 +0100" Message-ID: <9t94selci52.fsf@mraz.iskon.hr> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Hrvoje Niksic writes: > > > > Is this by design? > > > > Yes. C-g cancels the incremental search, which means that it > > backs up the point to where it was, and forgets the old search > > string. > > Can you give me an example where that would be useful. No idea, but that's what FSF does, and I copied it intentionally. I suppose we could ask RMS. From owner-xemacs-beta@xemacs.org Wed Nov 17 09:54:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26730 for xemacs-beta-out; Wed, 17 Nov 1999 09:54:42 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA26726 for ; Wed, 17 Nov 1999 09:54:40 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA22738; Wed, 17 Nov 1999 15:54:38 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa005ZD; Wed Nov 17 15:54:34 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id PAA17812; Wed, 17 Nov 1999 15:54:33 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 17 Nov 1999 15:54:33 +0100 In-Reply-To: Hrvoje Niksic's message of "17 Nov 1999 13:49:06 +0100" Message-ID: Lines: 21 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > > Can somebody give a bunch of examples where using integers as > > characters is useful? > > I can. Here are four: > > (let ((letter ?a)) > (while (< letter ?z) > ... do something with letter ... > (incf letter))) If only everybody used incf. I think it could make sense to make incf and < work with characters (and not convert them to int). Things get tricky with (+ ?a 1) ;; Return char (+ ?a ?z) ;; Signal error? Jan From owner-xemacs-beta@xemacs.org Wed Nov 17 10:08:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27302 for xemacs-beta-out; Wed, 17 Nov 1999 10:08:38 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27299 for ; Wed, 17 Nov 1999 10:08:34 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11o6h4-0007wv-00; Wed, 17 Nov 1999 16:08:22 +0100 To: Jan Vroonhof Cc: XEmacs Beta List , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 Nov 1999 16:08:22 +0100 In-Reply-To: Jan Vroonhof's message of "17 Nov 1999 15:54:33 +0100" Message-ID: <9t9bt8tb1g9.fsf@mraz.iskon.hr> Lines: 31 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Hrvoje Niksic writes: > > > > Can somebody give a bunch of examples where using integers as > > > characters is useful? > > > > I can. Here are four: > > > > (let ((letter ?a)) > > (while (< letter ?z) > > ... do something with letter ... > > (incf letter))) > > If only everybody used incf. I think it could make sense to make > incf and < work with characters (and not convert them to int). (incf foo) is exactly equivalent to (setf foo (1+ foo)). If you don't get my drift, try to imagine what (incf (car letters)) does. The point is, incf is a macro, and it doesn't know at compile-time whether the symbol will hold characters or numbers at run-time. If you want magic, build it into 1+. But I think I'd be against it. > Things get tricky with > > (+ ?a 1) ;; Return char > (+ ?a ?z) ;; Signal error? How about (+ 1 ?a)? And (+ 1 2 3 ?b)? It'd have to be *way* too much magic. From owner-xemacs-beta@xemacs.org Wed Nov 17 10:08:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27285 for xemacs-beta-out; Wed, 17 Nov 1999 10:08:04 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27281 for ; Wed, 17 Nov 1999 10:08:02 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA23784; Wed, 17 Nov 1999 16:07:59 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa005na; Wed Nov 17 16:07:51 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id QAA17827; Wed, 17 Nov 1999 16:07:50 +0100 To: Jake Colman Cc: xemacs-beta@xemacs.org Subject: Re: Whatever happened to 21.1.8? References: <76n1sdi45e.fsf@ppllc.com> From: Jan Vroonhof Date: 17 Nov 1999 16:07:50 +0100 In-Reply-To: Jake Colman's message of "17 Nov 1999 09:28:13 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jake Colman writes: > Was 21.1.8 ever released? I remember the maintainer mentioning that he was > about to release it several weekends ago but I don't recall having seen it. It's out http://www.xemacs.org/list-archives/xemacs-announce/9911/msg00000.html Jan From owner-xemacs-beta@xemacs.org Wed Nov 17 12:37:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA01238 for xemacs-beta-out; Wed, 17 Nov 1999 12:37:39 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA01232 for ; Wed, 17 Nov 1999 12:37:32 -0500 Received: by crystal.WonderWorks.COM id QQhpte18856; Wed, 17 Nov 1999 09:37:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14386.59352.593670.417652@crystal.WonderWorks.COM> Date: Wed, 17 Nov 1999 09:37:28 -0800 (PST) From: Kyle Jones To: Pete Forman , xemacs-beta@xemacs.org Subject: Re: Timer does not delay In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Pete Forman writes: > > > This code should post a message after a delay of 10 seconds. Only the > > third method (sleep-for) works. The first two execute the message > > function immediately, or very quickly. > > > > (run-at-time 10 nil 'message "pwf run-at-time") > > ("itimer-0" 9.999781 nil message nil t ("pwf run-at-time") (0 0 0)) > > The problem seems to be that only the first time out isn't working... I assume this is using the timer.el compatbility package. What version of XEmacs was used and how was it compiled? From owner-xemacs-beta@xemacs.org Wed Nov 17 17:53:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA09875 for xemacs-beta-out; Wed, 17 Nov 1999 17:53:58 -0500 Received: from bittersweet.sysc.pdx.edu (bittersweet.sysc.pdx.edu [131.252.30.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA09871 for ; Wed, 17 Nov 1999 17:53:53 -0500 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian 8.9.3-6) id OAA18712; Wed, 17 Nov 1999 14:53:46 -0800 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: [HEADS UP] movemail locking overhaul ahead References: X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Sperber writes: >>>>> "Jan" == Jan Vroonhof writes: Jan> sperber@informatik.uni-tuebingen.de (Michael Sperber Jan> [Mr. Preprocessor]) writes: Jan> I propose that it should (by default) always use dotlocking Jan> (even together with any other method). >>> >>> I don't believe that's a good idea: Locking would no longer be >>> atomic, and you can get deadlocks that way. Jan> Not if everybody acquires the locks in the same order. Which Jan> is indeed the case. Michael> What's the order? And why is this the case? Is there a Michael> standard or agreement on this? Debian has a standard/policy on mail locking. Please see: Perhaps `liblockfile' would be usefull for `movemail' as well? From owner-xemacs-beta@xemacs.org Wed Nov 17 17:55:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA09911 for xemacs-beta-out; Wed, 17 Nov 1999 17:55:30 -0500 Received: from bittersweet.sysc.pdx.edu (bittersweet.sysc.pdx.edu [131.252.30.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA09908 for ; Wed, 17 Nov 1999 17:55:27 -0500 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian 8.9.3-6) id OAA18719; Wed, 17 Nov 1999 14:55:21 -0800 To: Jan Vroonhof Cc: Karl Kleinpaste , xemacs-beta@xemacs.org Subject: Re: gnuclient makes 21.2.b20 unhappy References: X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Lines: 8 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Karl Kleinpaste writes: > #0 0x2ae11534 in __libc_read () > #1 0xffffffff in ?? () > #2 0x80cd313 in read_event_from_tty_or_stream_desc (event=0x87db8f0, Please tell me what frame #1 represents. Why is it all `f' and ?? ()? From owner-xemacs-beta@xemacs.org Wed Nov 17 18:09:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA10229 for xemacs-beta-out; Wed, 17 Nov 1999 18:09:49 -0500 Received: from bittersweet.sysc.pdx.edu (bittersweet.sysc.pdx.edu [131.252.30.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA10223 for ; Wed, 17 Nov 1999 18:09:47 -0500 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian 8.9.3-6) id PAA18764; Wed, 17 Nov 1999 15:09:23 -0800 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <8666z38wc0.fsf@megalith.bp.aventail.com> X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "William" == William M Perry writes: William> After spitting out those ideas this morning, I think you William> could make it fit fairly easily, but whether anyone William> thinks the costs are worth it. There IS code out there William> that uses the existing LDAP routines (Emacs/W3, EUDC, William> etc), but nothing that really uses the db routines (can William> anyone contradict this? I couldn't find anything), so... `where-was-i-db.el' uses it. From owner-xemacs-beta@xemacs.org Wed Nov 17 18:11:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA10297 for xemacs-beta-out; Wed, 17 Nov 1999 18:11:03 -0500 Received: from bittersweet.sysc.pdx.edu (bittersweet.sysc.pdx.edu [131.252.30.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA10293 for ; Wed, 17 Nov 1999 18:11:01 -0500 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian 8.9.3-6) id PAA18767; Wed, 17 Nov 1999 15:10:59 -0800 To: Ben Wing Cc: Oscar Figueiredo , XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Ben" == Ben Wing writes: Ben> Actually, Oscar, I was suggesting more simple changes, Ben> i.e. just make your API consistent with general Elisp API Ben> principles. Ben> For example: Ben> -- Instead of ldap-add-internal, just call it ldap-put and Ben> make it the advertised Ben> interface. There is no need to provide an interface like Ben> ldap-add that automatically does an open and a close, Ben> displays messages, looks for ldap-default-host, etc. Follow Ben> standard convention and make the caller do this. But then just about every program that uses it will need to define a wrapper function that does all that. From owner-xemacs-beta@xemacs.org Wed Nov 17 18:31:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA11002 for xemacs-beta-out; Wed, 17 Nov 1999 18:31:15 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA10995 for ; Wed, 17 Nov 1999 18:31:10 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id SAA03677; Wed, 17 Nov 1999 18:31:10 -0500 To: xemacs-beta@xemacs.org Subject: Re: gnuclient makes 21.2.b20 unhappy References: <87ln7wwwx2.fsf@bittersweet.sysc.pdx.edu> X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 17 Nov 1999 18:31:10 -0500 In-Reply-To: karlheg@cathcart.sysc.pdx.edu's message of "17 Nov 1999 14:55:21 -0800" Message-ID: Lines: 8 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > Please tell me what frame #1 represents. Why is it all `f' and ?? ()? The source line in event-unixoid.c:93 is just nread = read (fd, &ch, 1); so evidently that frame is a piece of the glibc2.1 syscall interface. From owner-xemacs-beta@xemacs.org Wed Nov 17 18:32:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA11070 for xemacs-beta-out; Wed, 17 Nov 1999 18:32:08 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA11067 for ; Wed, 17 Nov 1999 18:32:05 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id PAA17323; Wed, 17 Nov 1999 15:32:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14387.15092.35621.764154@lasker.666.com> Date: Wed, 17 Nov 1999 15:32:04 -0800 (PST) From: Martin Buchholz To: XEmacs Beta Test Subject: CVS broken wrt subdirectories X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: CVS appears to have a bug where if part of a commit involves files in directory and subdirectories of that directory, it forgets about the parent directory and only the subdirectory gets committed. I got bitten *twice* by this bug in one day. Unknown whether it's a client or server problem. I am running cvs 1.10.5 on Linux. If you run the same commit again, the remaining files actually make it to the repository. So I ran two extra `cvs commit's today. So do another CVS update. Again, the instructions to get your CVS tree up-to-date: rm man/*/index.texi # (only need to do this once) cvs update Martin From owner-xemacs-beta@xemacs.org Wed Nov 17 19:03:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA12375 for xemacs-beta-out; Wed, 17 Nov 1999 19:03:21 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA12364; Wed, 17 Nov 1999 19:03:07 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id TAA15153; Wed, 17 Nov 1999 19:10:11 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id BAA24898; Thu, 18 Nov 1999 01:02:56 +0100 (MET) To: Martin Buchholz Cc: xemacs-beta@xemacs.org, "J. Kean Johnston" Subject: Re: Martin makes man & Makefile makeover References: <14384.56980.560513.767776@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 18 Nov 1999 01:02:36 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 15 Nov 1999 20:33:24 -0800 (PST)" Message-ID: Lines: 48 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Hi Martin, building on Windows NT native I get as far as this: Wrote d:\tmp\21.2\xemacs\info\xemacs.info-19 Splitting Info file...done. Saving modified d:\tmp\21.2\xemacs\info\xemacs.info Wrote d:\tmp\21.2\xemacs\info\xemacs.info NMAKE : fatal error U1073: don't know how to make '..\man\lispref\index.perm' Stop. Compilation exited abnormally with code 2 at Thu Nov 18 00:44:43 Have you removed $(MANDIR)\lispref\index.perm ? nt/xemacs.mak has this rule: $(INFODIR)\lispref.info: $(MANDIR)\lispref\lispref.texi copy $(MANDIR)\lispref\index.perm $(MANDIR)\lispref\index.texi $(MAKEINFO) $** Why should $(MANDIR)\lispref\index.perm be discontinued? Regards, Adrian Martin> * internals/Makefile: Martin> * xemacs/Makefile: Martin> * lispref/Makefile: Martin> * new-users-guide/Makefile: Martin> * lispref/index.perm: Martin> * lispref/index.unperm: Martin> * lispref/permute-index: Martin> * internals/index.perm: Martin> * internals/index.unperm: Martin> Remove these Makefiles. Martin> Include all functionality in man/Makefile. Martin> Support only non-permuted indexes for simplicity. Martin> * emodules.texi: Martin> - TeX doesn't tolerate `_' in variable names; use `-' instead. Martin> * lispref/commands.texi: From owner-xemacs-beta@xemacs.org Wed Nov 17 19:17:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA12721 for xemacs-beta-out; Wed, 17 Nov 1999 19:17:34 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA12710; Wed, 17 Nov 1999 19:17:20 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id TAA16369; Wed, 17 Nov 1999 19:24:27 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-6.ecf.teradyne.com [131.101.192.126]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id BAA24918; Thu, 18 Nov 1999 01:17:12 +0100 (MET) To: Martin Buchholz Cc: xemacs-beta@xemacs.org, Norbert Koch , Andy Piper Subject: Re: Use Unix 98 types uid_t, gid_t, pid_t. References: <14387.10831.728480.651463@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 18 Nov 1999 01:16:53 +0100 In-Reply-To: Martin Buchholz's message of "Wed, 17 Nov 1999 14:21:03 -0800 (PST)" Message-ID: Lines: 28 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Martin> OK, I decided to go ahead and make this change now, since Martin> it seems a step forward, and might let the CVS sources Martin> build on Windows. Commit is imminent. Hello Martin, I have updated form CVS, verified your patches to nt.c and sysdep.c were merged in, and was able to build "Yoko" OK on Windows NT native. Regards, Adrian Martin> Again, Windows maintainers: feel free to redo this if you Martin> like. Martin> ChangeLog: Martin> 1999-11-17 Martin Buchholz Martin> * nt.c: Martin> * sysdep.c: Martin> * s/mingw32.h: Martin> * s/windowsnt.h: Martin> - Use Unix 98 types uid_t, gid_t, pid_t. Martin> - Define them. From owner-xemacs-beta@xemacs.org Wed Nov 17 20:06:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA14662 for xemacs-beta-out; Wed, 17 Nov 1999 20:06:31 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA14659; Wed, 17 Nov 1999 20:06:22 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id UAA20290; Wed, 17 Nov 1999 20:13:27 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-2.ecf.teradyne.com [131.101.192.122]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id CAA24994; Thu, 18 Nov 1999 02:06:12 +0100 (MET) To: Martin Buchholz , xemacs-beta@xemacs.org, "J. Kean Johnston" Subject: Re: Martin makes man & Makefile makeover References: <14384.56980.560513.767776@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 18 Nov 1999 02:05:52 +0100 In-Reply-To: Adrian Aichner's message of "18 Nov 1999 01:02:36 +0100" Message-ID: Lines: 105 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: >>>>> "Martin" == Martin Buchholz writes: APA> Hi Martin, APA> building on Windows NT native I get as far as this: APA> Wrote d:\tmp\21.2\xemacs\info\xemacs.info-19 APA> Splitting Info file...done. APA> Saving modified d:\tmp\21.2\xemacs\info\xemacs.info APA> Wrote d:\tmp\21.2\xemacs\info\xemacs.info APA> NMAKE : fatal error U1073: don't know how to make '..\man\lispref\index.perm' APA> Stop. APA> Compilation exited abnormally with code 2 at Thu Nov 18 00:44:43 APA> Have you removed APA> $(MANDIR)\lispref\index.perm APA> ? APA> nt/xemacs.mak has this rule: APA> $(INFODIR)\lispref.info: $(MANDIR)\lispref\lispref.texi APA> copy $(MANDIR)\lispref\index.perm $(MANDIR)\lispref\index.texi APA> $(MAKEINFO) $** APA> Why should $(MANDIR)\lispref\index.perm be discontinued? Hi again! I updated xemacs\man again. The previous distclean had removed index.texi files. The update gave me the info-related files: CVSROOT directory: :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot Working directory: d:\tmp\21.2\xemacs\man In directory .: Unknown .cvsignore Patched ChangeLog Patched Makefile Updated emodules.texi Removed info-stnd.texi Patched info.texi Patched standards.texi Patched texinfo.tex Patched texinfo.texi Patched xemacs-faq.texi In directory .\internals: Unknown .cvsignore Updated index.texi In directory .\lispref: Unknown .cvsignore Updated index.texi --------------------- End --------------------- Now I get stopped by this error: Saving modified d:\tmp\21.2\xemacs\info\emodules.info Wrote d:\tmp\21.2\xemacs\info\emodules.info ..\src\xemacs.exe -no-site-file -no-init-file -batch -l texinfmt -f batch-texinfo-format ..\man\info.texi texinfo formatting d:\tmp\21.2\xemacs\man\info.texi... Formatting Info file... Formatting Info file: ../info/info.info Converting info.texi to Info format... Removing trailing whitespace from Info buffer... >> Error: (error "@ifnottex is not handled by texinfo") >> point at >> >> @node Top >> @top Info: An Introduction >> Info is a program for reading documentation, which you are us NMAKE : fatal error U1077: '..\src\xemacs.exe' : return code '0x1' Stop. Compilation exited abnormally with code 2 at Thu Nov 18 01:39:23 APA> Regards, APA> Adrian Martin> * internals/Makefile: Martin> * xemacs/Makefile: Martin> * lispref/Makefile: Martin> * new-users-guide/Makefile: Martin> * lispref/index.perm: Martin> * lispref/index.unperm: Martin> * lispref/permute-index: Martin> * internals/index.perm: Martin> * internals/index.unperm: Martin> Remove these Makefiles. Martin> Include all functionality in man/Makefile. Martin> Support only non-permuted indexes for simplicity. Martin> * emodules.texi: Martin> - TeX doesn't tolerate `_' in variable names; use `-' instead. Martin> * lispref/commands.texi: From owner-xemacs-beta@xemacs.org Wed Nov 17 20:27:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA15433 for xemacs-beta-out; Wed, 17 Nov 1999 20:27:34 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA15430 for ; Wed, 17 Nov 1999 20:27:32 -0500 Received: (qmail 10662 invoked from network); 18 Nov 1999 01:26:08 -0000 Received: from usrpri2-36.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.101) by biff.kiva.net with SMTP; 18 Nov 1999 01:26:08 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA04644; Wed, 17 Nov 1999 20:28:22 -0500 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: Ben Wing , Oscar Figueiredo , XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 30 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > >>>>> "Ben" == Ben Wing writes: > > Ben> Actually, Oscar, I was suggesting more simple changes, > Ben> i.e. just make your API consistent with general Elisp API > Ben> principles. > > Ben> For example: > > Ben> -- Instead of ldap-add-internal, just call it ldap-put and > Ben> make it the advertised > Ben> interface. There is no need to provide an interface like > Ben> ldap-add that automatically does an open and a close, > Ben> displays messages, looks for ldap-default-host, etc. Follow > Ben> standard convention and make the caller do this. > > But then just about every program that uses it will need to define a > wrapper function that does all that. The current ldap-add is very inneficient if you are going to be making anything other than _1_ modification, which isn't usually the case (at least when I use ldap :) I was thrown off by the fact that the LDAP routines you are supposed to use if you make the connection your self are all named 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. Kind of like open-network-stream-internal and friends. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 17 22:25:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA18305 for xemacs-beta-out; Wed, 17 Nov 1999 22:25:44 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA18298 for ; Wed, 17 Nov 1999 22:25:41 -0500 Received: by localhost id m11oICQ-00016kC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 18 Nov 1999 12:25:30 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> Date: Thu, 18 Nov 1999 12:25:30 +0900 (JST) To: XEmacs Beta List , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9u2mlcmgt.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> [ I've added Ben to Cc because he AFAIR doesn't read xemacs-beta. ] Oops! Thank you. I just forwarded my message to him. Hrvoje> "Stephen J. Turnbull" writes: >> Can somebody give a bunch of examples where using integers as >> characters is useful? Hrvoje> I can. Here are four: Hrvoje> [iterating over letters] OK, I can imagine that being common in legacy code. Hrvoje> (defun turn-a-into-b () Yuck. But I can see people doing that. Hrvoje> (defvar foo-legal-chars (mapcar #'int-char Hrvoje> (defun stupid () Explicit calls to int-char can always be translated to make-char, which will be Mule-safe. Note that given your proposal that int-char return Latin-1 characters in \xA1--\xFE, (stupid) will give different behavior in `xemacs-nomule -font *-iso8859-2' and `xemacs-mule'. Hrvoje> I could think of more of such, but I don't really see the Hrvoje> point. The point is that at least two of your four examples are bugs. (`foo-legal-chars' suffers from the same problem as `stupid'.) And the implicit ones, if they turn out to be bugs after all (eg, because the internal representation of characters changes) are going to be practically impossible to find until they bite. Hrvoje> The ones without them are even worse because they are Hrvoje> implicit. See my examples. Sigh. So really the only way to find them is to make a private XEmacs without the implicit conversion and see where it barfs. Hrvoje> Some of us don't do input methods. But that's beside the Hrvoje> point, because C-q can as well use make-char or whatever. Sorry, I've been living in I18N too long. What I mean by an "input method" is normally called a "keymap". :-) Ie, the user's input interface. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 18 02:27:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA06484 for xemacs-beta-out; Thu, 18 Nov 1999 02:27:08 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA06481; Thu, 18 Nov 1999 02:27:04 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id XAA20037; Wed, 17 Nov 1999 23:27:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14387.43590.807635.654577@lasker.666.com> Date: Wed, 17 Nov 1999 23:27:02 -0800 (PST) From: Martin Buchholz To: Adrian Aichner , XEmacs Patches Cc: xemacs-beta@xemacs.org Subject: Re: Martin makes man & Makefile makeover In-Reply-To: References: <14384.56980.560513.767776@lasker.666.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "A" == Adrian Aichner writes: >>>>> "Martin" == Martin Buchholz writes: A> Hi Martin, A> building on Windows NT native I get as far as this: A> Wrote d:\tmp\21.2\xemacs\info\xemacs.info-19 A> Splitting Info file...done. A> Saving modified d:\tmp\21.2\xemacs\info\xemacs.info A> Wrote d:\tmp\21.2\xemacs\info\xemacs.info A> NMAKE : fatal error U1073: don't know how to make '..\man\lispref\index.perm' A> Stop. A> Compilation exited abnormally with code 2 at Thu Nov 18 00:44:43 A> Have you removed A> $(MANDIR)\lispref\index.perm A> ? Actually, there is now a real index.texi, which is the previous index.unperm. You should not notice any difference, once we get the .info's to build. A> nt/xemacs.mak has this rule: A> $(INFODIR)\lispref.info: $(MANDIR)\lispref\lispref.texi A> copy $(MANDIR)\lispref\index.perm $(MANDIR)\lispref\index.texi A> $(MAKEINFO) $** Those copy's are now no longer necessary. ObPatch (Adrian et al, please test.) : (This patch is not only completely untested, but even worse, I have never even used this language (NMAKE syntax) before) ChangeLog: 1999-11-17 Martin Buchholz * xemacs.mak: Remove references to index.unperm, index.perm. Fix dependencies. Shouldn't .obj and .info be in SUFFIXES? Remove extra `\'. Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.41.2.30 diff -u -w -r1.41.2.30 xemacs.mak --- xemacs.mak 1999/10/15 10:20:55 1.41.2.30 +++ xemacs.mak 1999/11/18 06:50:20 @@ -861,7 +861,7 @@ # Rules .SUFFIXES: -.SUFFIXES: .c .texi +.SUFFIXES: .c .obj .texi .info # nmake rule !if $(DEBUG_XEMACS) @@ -950,10 +950,7 @@ {$(MANDIR)}.texi{$(INFODIR)}.info: $(MAKEINFO) $** -$(INFODIR)\xemacs.info: $(MANDIR)\xemacs\xemacs.texi - $(MAKEINFO) $** - -$(MANDIR)\xemacs\xemacs.texi: \ +XEMACS_SRCS = \ $(MANDIR)\xemacs\abbrevs.texi \ $(MANDIR)\xemacs\basic.texi \ $(MANDIR)\xemacs\buffers.texi \ @@ -965,13 +962,13 @@ $(MANDIR)\xemacs\entering.texi \ $(MANDIR)\xemacs\files.texi \ $(MANDIR)\xemacs\fixit.texi \ + $(MANDIR)\xemacs\frame.texi \ $(MANDIR)\xemacs\glossary.texi \ $(MANDIR)\xemacs\gnu.texi \ $(MANDIR)\xemacs\help.texi \ $(MANDIR)\xemacs\indent.texi \ $(MANDIR)\xemacs\keystrokes.texi \ $(MANDIR)\xemacs\killing.texi \ - $(MANDIR)\xemacs\\xemacs.texi \ $(MANDIR)\xemacs\m-x.texi \ $(MANDIR)\xemacs\major.texi \ $(MANDIR)\xemacs\mark.texi \ @@ -979,25 +976,23 @@ $(MANDIR)\xemacs\mini.texi \ $(MANDIR)\xemacs\misc.texi \ $(MANDIR)\xemacs\mouse.texi \ + $(MANDIR)\xemacs\mule.texi \ $(MANDIR)\xemacs\new.texi \ + $(MANDIR)\xemacs\packages.texi \ $(MANDIR)\xemacs\picture.texi \ $(MANDIR)\xemacs\programs.texi \ $(MANDIR)\xemacs\reading.texi \ $(MANDIR)\xemacs\regs.texi \ - $(MANDIR)\xemacs\frame.texi \ $(MANDIR)\xemacs\search.texi \ $(MANDIR)\xemacs\sending.texi \ + $(MANDIR)\xemacs\startup.texi \ $(MANDIR)\xemacs\text.texi \ $(MANDIR)\xemacs\trouble.texi \ $(MANDIR)\xemacs\undo.texi \ - $(MANDIR)\xemacs\windows.texi - + $(MANDIR)\xemacs\windows.texi \ + $(MANDIR)\xemacs\xemacs.texi -$(INFODIR)\lispref.info: $(MANDIR)\lispref\lispref.texi - copy $(MANDIR)\lispref\index.perm $(MANDIR)\lispref\index.texi - $(MAKEINFO) $** - -$(MANDIR)\lispref\lispref.texi: \ +LISPREF_SRCS = \ $(MANDIR)\lispref\abbrevs.texi \ $(MANDIR)\lispref\annotations.texi \ $(MANDIR)\lispref\back.texi \ @@ -1008,10 +1003,12 @@ $(MANDIR)\lispref\compile.texi \ $(MANDIR)\lispref\consoles-devices.texi \ $(MANDIR)\lispref\control.texi \ + $(MANDIR)\lispref\customize.texi \ $(MANDIR)\lispref\databases.texi \ $(MANDIR)\lispref\debugging.texi \ $(MANDIR)\lispref\dialog.texi \ $(MANDIR)\lispref\display.texi \ + $(MANDIR)\lispref\dragndrop.texi \ $(MANDIR)\lispref\edebug-inc.texi \ $(MANDIR)\lispref\edebug.texi \ $(MANDIR)\lispref\errors.texi \ @@ -1025,12 +1022,12 @@ $(MANDIR)\lispref\hash-tables.texi \ $(MANDIR)\lispref\help.texi \ $(MANDIR)\lispref\hooks.texi \ - $(MANDIR)\lispref\index.perm \ - $(MANDIR)\lispref\index.unperm \ + $(MANDIR)\lispref\index.texi \ $(MANDIR)\lispref\internationalization.texi \ $(MANDIR)\lispref\intro.texi \ $(MANDIR)\lispref\keymaps.texi \ $(MANDIR)\lispref\ldap.texi \ + $(MANDIR)\lispref\lispref.texi \ $(MANDIR)\lispref\lists.texi \ $(MANDIR)\lispref\loading.texi \ $(MANDIR)\lispref\locals.texi \ @@ -1062,34 +1059,38 @@ $(MANDIR)\lispref\tooltalk.texi \ $(MANDIR)\lispref\variables.texi \ $(MANDIR)\lispref\windows.texi \ - $(MANDIR)\lispref\x-windows.texi \ - $(MANDIR)\lispref\index.unperm \ - $(MANDIR)\lispref\index.perm - + $(MANDIR)\lispref\x-windows.texi -$(INFODIR)\new-users-guide.info: $(MANDIR)\new-users-guide\new-users-guide.texi - $(MAKEINFO) $** +INTERNALS_SRCS = \ + $(MANDIR)\internals\internals.texi \ + $(MANDIR)\internals\index.texi -$(MANDIR)\new-users-guide\new-users-guide.texi: \ +NEW_USERS_GUIDE_SRCS = \ $(MANDIR)\new-users-guide\custom1.texi \ - $(MANDIR)\new-users-guide\files.texi \ - $(MANDIR)\new-users-guide\region.texi \ $(MANDIR)\new-users-guide\custom2.texi \ - $(MANDIR)\new-users-guide\help.texi \ - $(MANDIR)\new-users-guide\search.texi \ $(MANDIR)\new-users-guide\edit.texi \ + $(MANDIR)\new-users-guide\enter.texi \ + $(MANDIR)\new-users-guide\files.texi \ + $(MANDIR)\new-users-guide\help.texi \ $(MANDIR)\new-users-guide\modes.texi \ - $(MANDIR)\new-users-guide\xmenu.texi \ - $(MANDIR)\new-users-guide\enter.texi + $(MANDIR)\new-users-guide\new-users-guide.texi \ + $(MANDIR)\new-users-guide\region.texi \ + $(MANDIR)\new-users-guide\search.texi \ + $(MANDIR)\new-users-guide\xmenu.texi -$(INFODIR)\internals.info: $(MANDIR)\internals\internals.texi - copy $(MANDIR)\internals\index.perm $(MANDIR)\internals\index.texi - $(MAKEINFO) $** +$(INFODIR)\xemacs.info: $(XEMACS_SRCS) + $(MAKEINFO) $(MANDIR)\xemacs\xemacs.texi + +$(INFODIR)\lispref.info: $(LISPREF_SRCS) + $(MAKEINFO) $(MANDIR)\lispref\lispref.texi + +$(INFODIR)\internals.info: $(INTERNALS_SRCS) + $(MAKEINFO) $(MANDIR)\internals\internals.texi + +$(INFODIR)\new-users-guide.info: $(NEW_USERS_GUIDE_SRCS) + $(MAKEINFO) $(MANDIR)\new-users-guide\new-users-guide.texi -$(MANDIR)\internals\internals.texi: \ - $(MANDIR)\internals\index.unperm \ - $(MANDIR)\internals\index.perm info: $(INFO_FILES) From owner-xemacs-beta@xemacs.org Thu Nov 18 02:41:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA06788 for xemacs-beta-out; Thu, 18 Nov 1999 02:41:42 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA06782 for ; Thu, 18 Nov 1999 02:41:38 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id IAA26048 for ; Thu, 18 Nov 1999 08:41:19 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id IAA09318; Thu, 18 Nov 1999 08:41:18 +0100 (MET) To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Thu_Nov_18_08:41:11_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 18 Nov 1999 08:41:18 +0100 In-Reply-To: wmperry@aventail.com's message of "17 Nov 1999 20:28:22 -0500" Message-ID: Lines: 73 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Thu_Nov_18_08:41:11_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "William" == William M Perry writes: William> karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: >> >>>>> "Ben" == Ben Wing writes: >> Ben> Actually, Oscar, I was suggesting more simple changes, Ben> i.e. just make your API consistent with general Elisp API Ben> principles. >> Ben> For example: >> Ben> -- Instead of ldap-add-internal, just call it ldap-put and Ben> make it the advertised Ben> interface. There is no need to provide an interface like Ben> ldap-add that automatically does an open and a close, Ben> displays messages, looks for ldap-default-host, etc. Follow Ben> standard convention and make the caller do this. >> >> But then just about every program that uses it will need to define a >> wrapper function that does all that. William> The current ldap-add is very inneficient if you are going to be making William> anything other than _1_ modification, which isn't usually the case (at William> least when I use ldap :) Then we should make it better. I do not agree with Ben when he says that there is no need to provide an interface like ldap-add. As Karl stated, most applications will need to perform the same sequence of calls the same host parameters lookup, etc... Such an interface provides (or should provide) what the vast majority of programmers will want to do in a clean, safe and efficient way. Adding a record or performing a search always involves the same sequence of calls, we will avoid duplication and most of all, mistakes by providing good high-level functions. For instance, when using the ldap-*-internal functions, Bill forgot to use ldap-close. If he did, then most programmers will as well. William> I was thrown off by the fact that the LDAP routines you are supposed to use William> if you make the connection your self are all named 'xxx-internal', which William> means (to me) 'DO NOT USE THIS DIRECTLY', etc. Kind of like William> open-network-stream-internal and friends. That was indeed my intention. It's not that the ldap-*-internal should not be used by programmers at all, they're just not the preferred way to do things. Let me restate the rationale of the current API. I've had two goals when designing it. First I wanted the C code to be kept as small as possible, all complex argument processing being moved to the Lisp-level. Then I wanted to provide an API reminding the traditional LDAP command-line tools so that someone who knows LDAP wouldn't be put off by a new API. Therefore the C code is designed to provide the most basic wrappers around the LDAP API calls. The functions in ldap.el provide the preferred programmer interface. If they're not good enough then we should strive to make them better, not simply discard them. Oscar --pgp-sign-Multipart_Thu_Nov_18_08:41:11_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBODOtnJ7CaiYEgqPZAQGrPQH9GVgQD4iqWm0w7owPqqOwfwAfCnYiTVmx vQBKHdGxD1U1UbRxf/T3Bp4bY63Qwe3epb3yFBN7GfTJNZec2AI2sA== =Em8D -----END PGP MESSAGE----- --pgp-sign-Multipart_Thu_Nov_18_08:41:11_1999-1-- From owner-xemacs-beta@xemacs.org Thu Nov 18 02:52:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA07075 for xemacs-beta-out; Thu, 18 Nov 1999 02:52:41 -0500 Received: from diamond.waii.com (diamond.waii.com [198.3.192.201]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA07072 for ; Thu, 18 Nov 1999 02:52:34 -0500 Received: from mail1.wg.waii.com (mail.wg.waii.com [137.144.128.17]) by diamond.waii.com (8.9.1/8.9.1) with ESMTP id BAA25209; Thu, 18 Nov 1999 01:52:26 -0600 (CST) Received: from merlin.london.waii.com (merlin.london.waii.com [136.250.33.1]) by mail1.wg.waii.com (8.8.7/8.8.7) with ESMTP id BAA30272; Thu, 18 Nov 1999 01:52:24 -0600 Received: from kryten.bedford (kryten.bedford.waii.com [136.250.3.220]) by merlin.london.waii.com (8.8.4/8.8.4) with SMTP id HAA33654; Thu, 18 Nov 1999 07:52:23 GMT Received: by kryten.bedford (SMI-8.6/SMI-SVR4) id HAA10995; Thu, 18 Nov 1999 07:52:20 GMT Date: Thu, 18 Nov 1999 07:52:20 GMT Message-Id: <199911180752.HAA10995@kryten.bedford> From: Pete Forman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kyle Jones Cc: xemacs-beta@xemacs.org Subject: Re: Timer does not delay In-Reply-To: <14386.59352.593670.417652@crystal.WonderWorks.COM> References: <14386.59352.593670.417652@crystal.WonderWorks.COM> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > Jan Vroonhof writes: > > Pete Forman writes: > > > > > This code should post a message after a delay of 10 seconds. > > > Only the third method (sleep-for) works. The first two > > > execute the message function immediately, or very quickly. > > > > > > (run-at-time 10 nil 'message "pwf run-at-time") > > > ("itimer-0" 9.999781 nil message nil t ("pwf run-at-time") (0 0 0)) > > > > The problem seems to be that only the first time out isn't > > working... > > I assume this is using the timer.el compatbility package. What > version of XEmacs was used and how was it compiled? I posted a fuller report to news:comp.emacs.xemacs only, Jan copied his reply to the xemacs-beta list. I am not subscribed to that. In my original post: > If I provide a REPEAT argument to run-at-time, it still executes > the function immediately but thereafter repeats at the proper > interval. > > The version is 21.1 (patch 7) "Biscayne" XEmacs Lucid running on > AIX 4.3.2. I see the same problem with 20.3 plus > fsf-compat/timer.el on Solaris 2.6 and on IRIX 6.5. The above code > works on Emacs 19.34. I posted there as it was not obvious whether timer.el or itimer.el was at fault. -- Pete Forman Western Geophysical pete.forman@westgeo.com From owner-xemacs-beta@xemacs.org Thu Nov 18 03:27:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA07880 for xemacs-beta-out; Thu, 18 Nov 1999 03:27:29 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA07623 for ; Thu, 18 Nov 1999 03:13:19 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11oMbP-0008G2-00 for ; Thu, 18 Nov 1999 09:07:35 +0100 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 18 Nov 1999 09:07:35 +0100 In-Reply-To: wmperry@aventail.com's message of "17 Nov 1999 20:28:22 -0500" Message-ID: <9t9bt8s9q9k.fsf@mraz.iskon.hr> Lines: 12 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > I was thrown off by the fact that the LDAP routines you are supposed > to use if you make the connection your self are all named > 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. I was begging Oscar not to use the name -internal if he doesn't mean it, but he convinced me that the -internal routines exist for the ease of implementation, and that the routines a Lisp user should call are the ones defined in ldap.el. Oscar, what's the current status of your API? From owner-xemacs-beta@xemacs.org Thu Nov 18 03:43:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA08468 for xemacs-beta-out; Thu, 18 Nov 1999 03:43:45 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA08193 for ; Thu, 18 Nov 1999 03:38:12 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11oMep-0008GE-00 for ; Thu, 18 Nov 1999 09:11:07 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 18 Nov 1999 09:11:07 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 18 Nov 1999 12:25:30 +0900 (JST)" Message-ID: <9t97ljg9q3o.fsf@mraz.iskon.hr> Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Hrvoje> I could think of more of such, but I don't really see > Hrvoje> the point. > > The point is that at least two of your four examples are bugs. > (`foo-legal-chars' suffers from the same problem as `stupid'.) And > the implicit ones, if they turn out to be bugs after all (eg, > because the internal representation of characters changes) are going > to be practically impossible to find until they bite. I agree completely. *But*, they work for many (most?) people, and I believe they should continue to work unchanged at least for some more time. Retaining a measure of backward-compatibility is important. During the years I've come to the conclusion that Emacs is not a very smart thing; it's good because it's old and because lots of code has been written. APIs _do_ change (as witness by the coming of Emacs 19 and XEmacs), but they should change slowly and at the right time, unless we wish to alienate our user-base. From owner-xemacs-beta@xemacs.org Thu Nov 18 03:53:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA08699 for xemacs-beta-out; Thu, 18 Nov 1999 03:53:29 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA08686 for ; Thu, 18 Nov 1999 03:53:10 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11oMbP-0008G2-00 for ; Thu, 18 Nov 1999 09:07:35 +0100 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 18 Nov 1999 09:07:35 +0100 In-Reply-To: wmperry@aventail.com's message of "17 Nov 1999 20:28:22 -0500" Message-ID: <9t9bt8s9q9k.fsf@mraz.iskon.hr> Lines: 12 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry@aventail.com (William M. Perry) writes: > I was thrown off by the fact that the LDAP routines you are supposed > to use if you make the connection your self are all named > 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. I was begging Oscar not to use the name -internal if he doesn't mean it, but he convinced me that the -internal routines exist for the ease of implementation, and that the routines a Lisp user should call are the ones defined in ldap.el. Oscar, what's the current status of your API? From owner-xemacs-beta@xemacs.org Thu Nov 18 05:31:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA11879 for xemacs-beta-out; Thu, 18 Nov 1999 05:31:18 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA11875; Thu, 18 Nov 1999 05:31:13 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id FAA24894; Thu, 18 Nov 1999 05:38:20 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id LAA00045; Thu, 18 Nov 1999 11:31:04 +0100 (MET) To: Martin Buchholz Cc: "J. Kean Johnston" , xemacs-beta@xemacs.org Subject: Re: Martin makes man & Makefile makeover References: <14384.56980.560513.767776@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 18 Nov 1999 11:30:27 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 15 Nov 1999 20:33:24 -0800 (PST)" Message-ID: Lines: 39 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Martin> - Make sources compatible with makeinfo 4.0 *and* 3.12. Hello Martin, trying to generate info.info using texinfo-3.12 on Windows NT I get this error: cd d:\tmp\21.2\xemacs\man\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe info.texi Compilation started at Thu Nov 18 10:55:16 1999 +0100 (W. Europe Standard Time) Making info file `../info/info.info' from `info.texi'. info.texi:69: No matching `@end ifnottex'. info.texi:77: Unmatched `@end'. makeinfo.exe: Removing output file `../info/info.info' due to errors; use --force to preserve. Compilation exited abnormally with code 2 at Thu Nov 18 10:55:18 What do you make of this? Can you generate .info files for all .texi files in the latest 21.2 CVS sources using cd c:\XEmacs\xemacs-packages\etc\psgml\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe --version Compilation started at Thu Nov 18 11:28:48 1999 +0100 (W. Europe Standard Time) makeinfo (GNU texinfo 3.12) 1.68 Copyright (C) 1998 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Compilation finished at Thu Nov 18 11:28:48 ? Best regards, Adrian From owner-xemacs-beta@xemacs.org Thu Nov 18 05:38:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA12021 for xemacs-beta-out; Thu, 18 Nov 1999 05:38:34 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA12018 for ; Thu, 18 Nov 1999 05:38:31 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id LAA26848 for ; Thu, 18 Nov 1999 11:38:30 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id LAA09662; Thu, 18 Nov 1999 11:38:29 +0100 (MET) To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> <9t9bt8s9q9k.fsf@mraz.iskon.hr> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Thu_Nov_18_11:38:16_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 18 Nov 1999 11:38:29 +0100 In-Reply-To: Hrvoje Niksic's message of "18 Nov 1999 09:07:35 +0100" Message-ID: Lines: 50 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Thu_Nov_18_11:38:16_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> wmperry@aventail.com (William M. Perry) writes: >> I was thrown off by the fact that the LDAP routines you are supposed >> to use if you make the connection your self are all named >> 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. Hrvoje> I was begging Oscar not to use the name -internal if he doesn't mean Hrvoje> it, but he convinced me that the -internal routines exist for the ease Hrvoje> of implementation, and that the routines a Lisp user should call are Hrvoje> the ones defined in ldap.el. Hrvoje> Oscar, what's the current status of your API? Please see my other post. It's not that I insist on the -internal suffix. If we want to have -1 suffixes instead or whatever it's fine with me. What's actually important is that the API is designed in two layers: - a low-level layer implemented in C which is to be kept as small as possible and provides basic wrappers around the LDAP C API - a higher-level layer written in Lisp which provides functions to access LDAP. This higher-level layer should be the preferred (not exclusive) way for package programmers to use LDAP. Therefore those functions should be safe, efficient and general enough for most programmers to use This design has been discussed a while ago and has even been presented at the m17n99 conference. There has been no change in philosophy since then. Oscar --pgp-sign-Multipart_Thu_Nov_18_11:38:16_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBODPXHZ7CaiYEgqPZAQE6VQH+NvrZ/Zswnc8AwhEWUC0OHSOMAWeD3Pwo CnUnEKbJXbeRdS0ts6iLByGKzF3EC8VaowmwYNq6ai6+MFyR4Oa6Lw== =zcJX -----END PGP MESSAGE----- --pgp-sign-Multipart_Thu_Nov_18_11:38:16_1999-1-- From owner-xemacs-beta@xemacs.org Thu Nov 18 06:17:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA12773 for xemacs-beta-out; Thu, 18 Nov 1999 06:17:45 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA12770 for ; Thu, 18 Nov 1999 06:17:43 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA00240; Thu, 18 Nov 1999 12:17:35 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0003i; Thu Nov 18 12:17:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA12644; Thu, 18 Nov 1999 12:17:32 +0100 To: Kyle Jones Cc: Pete Forman , xemacs-beta@xemacs.org Subject: Re: Timer does not delay References: <14386.59352.593670.417652@crystal.WonderWorks.COM> From: Jan Vroonhof Date: 18 Nov 1999 12:17:31 +0100 In-Reply-To: Kyle Jones's message of "Wed, 17 Nov 1999 09:37:28 -0800 (PST)" Message-ID: Lines: 20 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > I assume this is using the timer.el compatbility package. Yes. But it doesn't matter. I can see the problem here too when I do make-itimer directly. Jan P.S. Itimers seem to be broken in 21.1.x, see http://www.xemacs.org/list-archives/xemacs/9911/msg00442.html I am seeing that using Gnus can sometimes leave tens of timers lying around (this makes XEmacs suck up CPU time like mad). That could be related. Which reminds me, there is a bugfix for edit-itimer that I still need to submit. From owner-xemacs-beta@xemacs.org Thu Nov 18 07:46:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA16025 for xemacs-beta-out; Thu, 18 Nov 1999 07:46:23 -0500 Received: from gate.ispras.ru (gate.ispras.ru [194.67.37.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA16007 for ; Thu, 18 Nov 1999 07:45:57 -0500 Received: from fog (fog [194.67.37.129]) by gate.ispras.ru (8.9.3/8.9.3) with SMTP id QAA21372 for ; Thu, 18 Nov 1999 16:45:38 +0400 (GMT) Received: tid QAA02926; Thu, 18 Nov 1999 16:44:09 +0200 X-Authentication-Warning: fog: Host kazbek claimed to be kazbek.kazbek.ispras.ru Received: from pegas.kazbek.ispras.ru (pegas [194.186.94.143]) by kazbek.kazbek.ispras.ru (8.9.3/8.9.3) with ESMTP id PAA16184 for ; Thu, 18 Nov 1999 15:44:39 +0300 (MSK) Received: (from npak@localhost) by pegas.kazbek.ispras.ru (8.9.3/8.9.3) id PAA02068; Thu, 18 Nov 1999 15:43:24 +0300 Date: Thu, 18 Nov 1999 15:43:24 +0300 Message-Id: <199911181243.PAA02068@pegas.kazbek.ispras.ru> From: "Nick V. Pakoulin" To: xemacs-beta@xemacs.org Subject: 21.2.20 crash Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta20) "Yoko" [Lucid] (i686-pc-linux) of Tue Nov 16 1999 on pegas.kazbek.ispras.ru configured using `configure --with-pop --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I worked with Gnus, read articles. Before the crash I opened my mail group named "misc" and saw the summary buffer. In the buffers-tab there were 3 buffers - Summary, mail<2> and one more. I tried to switch to mail<2>, Xemacs hung and then crashed. -------------------------------------------------------------------------------- Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) [2]- Segmentation fault (core dumped) xemacs-21.2-b20 -l gnus-mime -f gnus -------------------------------------------------------------------------------- #0 0x402ce111 in __kill () from /lib/libc.so.6 #1 0x8078d31 in fatal_error_signal (sig=11) at emacs.c:276 #2 0xbffff0d4 in ?? () #3 0x8158866 in XawTabsSetHighlight (t=0x889b260, w=0x8aa4378) at xlwtabs.c:1283 #4 0x8157ff4 in XawTabsSetTop (w=0x8aa4378, callCallbacks=1) at xlwtabs.c:1262 #5 0x8158c24 in TabsSelect (w=0x889b260, event=0xbffff744, params=0x0, num_params=0x4014b294) at xlwtabs.c:1047 #6 0x4013ce8d in HandleActions () from /usr/X11R6/lib/libXt.so.6 #7 0x4013d342 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.6 #8 0x4013d851 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x4011a9f7 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x4011b5ad in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6 #11 0x4011b873 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #12 0x40126b8f in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #13 0x812c196 in emacs_Xt_next_event (emacs_event=0x886e130) at event-Xt.c:2427 #14 0x809a955 in event_stream_next_event (event=0x886e130) at event-stream.c:565 #15 0x809ba7c in next_event_internal (target_event=143057200, allow_queued=1) at event-stream.c:2020 #16 0x809bf96 in Fnext_event (event=143057200, prompt=136070036) at event-stream.c:2237 #17 0x80631bd in Fcommand_loop_1 () at cmdloop.c:566 #18 0x80633de in command_loop_1 (dummy=136070036) at cmdloop.c:490 #19 0x807fe8b in condition_case_1 (handlers=136070132, bfun=0x80633c8 , barg=136070036, hfun=0x8062cd0 , harg=136070036) at eval.c:1630 #20 0x80634bc in command_loop_2 (dummy=136070036) at cmdloop.c:252 #21 0x807fd6f in internal_catch (tag=136143988, func=0x8063484 , arg=136070036, threw=0x0) at eval.c:1305 #22 0x8062f0c in initial_command_loop (load_me=136070036) at cmdloop.c:301 #23 0x8077752 in xemacs_21_2_b20_i686_pc_linux (argc=5, argv=0xbffffc44, envp=0xbffffc5c, restart=0) at emacs.c:1873 #24 0x8078f0f in main (argc=5, argv=0xbffffc44, envp=0xbffffc5c) at emacs.c:2298 #25 0x402c7cb3 in __libc_start_main (main=0x8078e10
, argc=5, argv=0xbffffc44, init=0x804dad4 <_init>, fini=0x815ae14 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffc3c) at ../sysdeps/generic/libc-start.c:78 Recent keystrokes: i a b i p 1 5 a RET button2 button2up 3 RET misc-user misc-user misc-user Recent messages (most recent first): Parsing /home/npakoulin/.mailrc... Loading emacsbug...done Loading emacsbug... Generating summary...done Generating summary... Sorting articles...done Sorting articles... Scoring...done Scoring... Loading gnus-score...done From owner-xemacs-beta@xemacs.org Thu Nov 18 08:19:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA17343 for xemacs-beta-out; Thu, 18 Nov 1999 08:19:51 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA17336 for ; Thu, 18 Nov 1999 08:19:47 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11oRTV-0008PJ-00 for ; Thu, 18 Nov 1999 14:19:45 +0100 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> <9t9bt8s9q9k.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 18 Nov 1999 14:19:44 +0100 In-Reply-To: Oscar Figueiredo's message of "18 Nov 1999 11:38:29 +0100" Message-ID: <9t9hfik3pjj.fsf@mraz.iskon.hr> Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > It's not that I insist on the -internal suffix. If we want to have > -1 suffixes instead or whatever it's fine with me. Argh. :-) You're missing the point. Just like -internal, the -1 suffix screams "DON'T USE ME YOU'LL BE SORRY" to the user. If that's what you want to do, fine. If not, not. > - a low-level layer implemented in C which is to be kept as small as > possible and provides basic wrappers around the LDAP C API > > - a higher-level layer written in Lisp which provides functions to > access LDAP. This higher-level layer should be the preferred (not > exclusive) way for package programmers to use LDAP. Therefore > those functions should be safe, efficient and general enough for > most programmers to use This is good design, except that if Lisp programmers are ever expected to use the lower-level API, you should remove the "-internal" suffix and choose better names for functions. From owner-xemacs-beta@xemacs.org Thu Nov 18 12:37:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA25838 for xemacs-beta-out; Thu, 18 Nov 1999 12:37:55 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA25835 for ; Thu, 18 Nov 1999 12:37:53 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id SAA08867 for ; Thu, 18 Nov 1999 18:37:45 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id SAA09959; Thu, 18 Nov 1999 18:37:45 +0100 (MET) To: xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> <9t9bt8s9q9k.fsf@mraz.iskon.hr> <9t9hfik3pjj.fsf@mraz.iskon.hr> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Thu_Nov_18_18:37:35_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 18 Nov 1999 18:37:45 +0100 In-Reply-To: Hrvoje Niksic's message of "18 Nov 1999 14:19:44 +0100" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Thu_Nov_18_18:37:35_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> This is good design, except that if Lisp programmers are ever Hrvoje> expected to use the lower-level API, you should remove the Hrvoje> "-internal" suffix and choose better names for functions. Fine I guess I simply misjudged the meaning of "-internal" in function names. I can rename the "-internal" functions to something else. What's your suggestion to add the meaning "you're using stones to make fire, use the lighter function instead otherwise if you're not really skilful you're going to crush your fingers" to a function ? Would names like ldap-basic-add, ldap-basic-search, ldap-basic-delete be good enough ? Oscar --pgp-sign-Multipart_Thu_Nov_18_18:37:35_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBODQ5Yp7CaiYEgqPZAQHj1QIAkUYrZPiBCOvDgadDB3ttCOP6YH74oZoV +rKbdTQa5YcM/Yk506J34Vws1csUfqwbR+iPI9Ow5nI8dw0975KAqg== =To4Q -----END PGP MESSAGE----- --pgp-sign-Multipart_Thu_Nov_18_18:37:35_1999-1-- From owner-xemacs-beta@xemacs.org Thu Nov 18 13:04:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26581 for xemacs-beta-out; Thu, 18 Nov 1999 13:04:25 -0500 Received: from klapaucius.hip.berkeley.edu (klapaucius.HIP.Berkeley.EDU [136.152.119.220]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26574; Thu, 18 Nov 1999 13:04:19 -0500 Received: (from smikes@localhost) by klapaucius.hip.berkeley.edu (8.9.1/8.9.1) id JAA11379; Thu, 18 Nov 1999 09:52:01 -0800 X-Authentication-Warning: klapaucius.hip.berkeley.edu: smikes set sender to smikes@alumni.hmc.edu using -f X-Mailer: emacs 19.34.1 (via feedmail 9-beta-4 I); VM 6.75 under Emacs 19.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14388.15545.802573.108952@klapaucius.hip.berkeley.edu> Date: Thu, 18 Nov 1999 09:51:53 -0800 (PST) From: Samuel Mikes To: xemacs-beta@xemacs.org Cc: Martin Buchholz Subject: Re: Use Unix 98 types uid_t, gid_t, pid_t. In-Reply-To: References: <14387.10831.728480.651463@lasker.666.com> Reply-To: Samuel Mikes X-Attribution: smikes Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >> "APA" == Adrian Aichner writes: >>>>>> "Martin" == Martin Buchholz writes: Martin> OK, I decided to go ahead and make this change now, since it Martin> seems a step forward, and might let the CVS sources build on Martin> Windows. Commit is imminent. APA> I have updated form CVS, verified your patches to nt.c and APA> sysdep.c were merged in, and was able to build "Yoko" OK on APA> Windows NT native. Building from latest CVS on cygwin failed. I had to #include in lisp.h to get uid_t and friends. That sounds like the wrong solution: what should I *really* do? Cheers, -- Sam Mikes smikes@alumni.hmc.edu From owner-xemacs-beta@xemacs.org Thu Nov 18 13:04:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26592 for xemacs-beta-out; Thu, 18 Nov 1999 13:04:41 -0500 Received: from klapaucius.hip.berkeley.edu (klapaucius.HIP.Berkeley.EDU [136.152.119.220]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26579 for ; Thu, 18 Nov 1999 13:04:24 -0500 Received: (from smikes@localhost) by klapaucius.hip.berkeley.edu (8.9.1/8.9.1) id JAA11173; Thu, 18 Nov 1999 09:45:02 -0800 X-Authentication-Warning: klapaucius.hip.berkeley.edu: smikes set sender to smikes@alumni.hmc.edu using -f X-Mailer: emacs 19.34.1 (via feedmail 9-beta-4 I); VM 6.75 under Emacs 19.34.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="smuggle-security-FBI-qBvnyIN4bI" Content-Transfer-Encoding: 7bit Message-ID: <14388.15101.741790.258122@klapaucius.hip.berkeley.edu> Date: Thu, 18 Nov 1999 09:44:29 -0800 (PST) From: Samuel Mikes To: XEmacs beta list Cc: Jan Vroonhof Subject: Redisplay loss on frame resize [21.2.20,cygwin32] possibly related to Re: 10% redisplay speed up... In-Reply-To: <3832032F.B9A443ED@666.com> References: <3832032F.B9A443ED@666.com> Reply-To: Samuel Mikes X-Attribution: smikes Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --smuggle-security-FBI-qBvnyIN4bI Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Folks, With the latest from CVS, my XEmacs does not redraw the frame after a frame resize operation but waits for another event (e.g., mouse click, keystroke). The upshot is that if I shrink the window, I see a frame with no modeline or scrollbars. It's purely a visual bug and easily worked around. --smuggle-security-FBI-qBvnyIN4bI Content-Type: image/png Content-Description: Screen shot of clipped XEmacs frameL 9k Content-Disposition: inline; filename="bad1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAnwAAAIWCAIAAABC4Mc9AAAl8ElEQVR42u3dP5rcxrkv4J7z MDhLsENqB3ImhXYmh84UawcOyZDKjncgp8qcKjNDMpN2MBNe7uDebG5r2sQBgapCAQV8QHe/ 76MHGmIAVOHP4NcFoFEPj4+PJwBgY1999dWr8/9ev369d00A4Jb9+OOP5+Gryz8+fvy4d30A 4Mb9194VAIB78ar/j2+/fb93fQDgpnz48OfuZy1dAAjyanKKX3/9rvv5j7/7ZzfmT3/60+n0 bu9VAODePT+/qZ/44eHh+fl51vSXsJtbyjgiJ0L3zZv/+69//evy8+vXr3/44Yc3b95cxlwe xAKAI3h6eqqZ7Oeff142fctcnVLofv31v3755T8/n1u4f/vb377++utfXkb99ttvL6P3b+YO Pnc8PPw4+FV/TEBNuuJiSg9eR4Aj+/Tp09zpv/3229xvP3z4sEopfaXQ/Zysv/vuu+9eLib3 7Zy4Xdz2cy4yhPp5f8+xZzsAd+iS1v1gHo8ZKz9I9Z9YPTdwz8H+008/jX+1u/5ZPviM3xW3 V9J0aTfrNsPtbQeAFh9SauY6fQ7aU13inmoepDr7Py9++OGHX3/9tfzw1LjRk8yDwTXYWSP7 ix0XcR5zae8OAqCyoOTF6lzruZ955bzpljD4YVaVKiOtsAq5LXbKX6Wv3xc12wHglpwj9tsX 3T8nZ5n8ytDv+Xpu5v7yyy9v3ry5pO/p9DY5aZcouTP7KZUBg+mTC8lF7KnupmZ5mTVxm1x+ V/nBjeTuKvek+irlIr9Q/3K+5iZYsC+S2wHgHnRBW5O4p8qW7unzFebPoVsy61JneeJ+VCfb rxtpKSXZRpxl32vFNSsYuS8Ajqx/ebkmd2tD9xK3T09Pf/zjH8tT1p+LC+3X5GKT5/pufH+Z V21WmO2yvnIX4PTlfdzLdeb2e7r/uZJ8aeZeEnfyzu5ppa+yJG+FXs71g58DN/IS/U8Gs27N 5iYe/zYsBcf7ImILAlQbfwuo8trvglL6l5drcrccur8n7k8//XTO2r/+9a+XC8uX5X7+7Re5 O2h0Tp6OB9MXFlIIrZrz/uQyy7Vd8WtIuce75lZpUmEhhVJq6rPgAwTAkRW+qlswDtcVLi9/ 9913Hz9+/Oc//3n556WNew7gl38lWrrJU3zuh1PmrF05srsunXvydkFByVkqo2V83XvuLJVj aiab9c/20gGOY1a7dotGcEEhdH9v5p5T9tOnT3/4wx8+vTiP+RzAR/ye7jGt0nIFoCz35sW1 pm+Zq5ML3f+9lXvO10+f+v88HSdxr0JwY3HZkn0gAK7aS+8CG07fMldfLnTfFf8JAIcSk1Ot pehPFwCCfNHS7fduDwCsS0sXAIIIXQAIInQBIIjQBYAg0x0eDN6PdXkNZDdcVup4meMJWopo qdviFakpcdOK1Vemq8YW9ZncubtsHIBKg3NR4dS04KxV1cvQYKGrnBlrFrJdMKxiwY7ZekW6 5ddUZqMNe/C9BrCjG7y83LWS964IAHyhtj/dvnEL7/JDe8tmkJRrtcnG112TV2IH/TStWNxp dMF8sNH6HxTWrU9/0423Z6E+yZ9X2SyDFRwvfK0SAdaVPGvNus9YFbqFWE2e05ctc7Co/sQL 7gsObgmPSynEYfvpvlDcqS4Il9Wn8gPQYLMk65OL52XGReSOnK2vfgNMSl4rLeRdfQ4uuadb U7nGZcbrYmCvio1vnC+oz7IPQKf8TozfLLvvCIBcQ7b9xuWSy8uFyh3B4o3S+Ej26iLrUygl frMcbUcAXLSfl9Z8kGr3Z5e6FlKnvkrdfcTd12Kj+lQuZ3xbPXizHG1HAIwtPkG1tnT7J8fF 1zP7d2FzRbQ/TzSo5GDM+DmmWet+ylyOyN1gntxoC+qTXM3+csrXkJP1WVaNmiJyha5VIsC6 CqfK+hx8eHx8fP369cePH/denQ2NM3vrl1QIDIA7UXnOf//+/du3b2/we7oAcEx3EbrjzyCb tkQ1cwHux6xz/l2ELgAcgdAFgCBCFwCCfPGVoffv3+9dHwC4HW/evOl/P2j4Pd23b9/uXUMA uAWPj4+DMYmXY1wexPrmm2/2ru0tu+0vRgOQlH4j1Tlxn56e9q7bLfMCDYA7lAjdS+J++vRp 77rdsnfv3p1z9/n5ee+KHI5rAMANW6GXIRZzOWHMNQDghgndPbmcMHa5BiB3gZvU+j3dZE9w wb59EV8uAMxy9S/H6PrQlbsAHNy80O2C7SAJl+ukdvdaDX5oX9RaC9yudNcbACbNu6db2cH4 4J7c5Z/dsFtU99v+8vvTD6aslJy9vfRkf/XJkffZDftxPvQAHNaM0O2fUvuhUn+q7YdxP4kH EwzGL3isZjx7cpnJ0uvrmRuZ3Eqzqn3bTxLdyWoCjM0I3X7E9s+Vg+CZXMLAZGZPtqrnzjI5 QWUSDFq0/eGylu5VXEg4Zdr3uXqOC7rPKwEAp7mXlxe0UQYtv9X7k09GfmMTqn72ZMQua8kd 80LCuPTc5YH6KiVXE+AezL6nO/ghN1m/fZP7eTzjWtcbG1tylbN3tR1EbOVWSm7bo11IyH2m mbVSNasJcA+2ejlG7nw6GD9o+qx4Fq5ZVKH0mnquXvkDXkjIbbe5a9S4mgC3oTV0x+F0mnky TU456+pu5VwtBbXPPquIg19IqF9m7p7uFlsP4Pg2aelu137lYscLCcllDq48F64ZANyzuMvL YSffFZ/M2t0xLyTsuHMBrpoOD66PCwkAV0roXqWraGsesEoA+7r6Dg8A4Fpo6e7pm2++2bsK h3PeJm/evNm7FgAreHp6GowRuvv485///OHDh/H+AOCGpUP3559/3rtiAHDdvv/++8GYROg+ PDzsXU8AuHpVofv8/Lx3PQHg6o3vIXp6GQCC3GDoPjz84/zfYMzeldpnO+xdhavxjy9vqfyj eIflHy9H2N5VblrZXVZh3RKvehckV+Hyz1mH4habZfLYmCxirQPs6nbxeK2Tq3DE0G1Mi+fn v191/a+iSgdcxzB/v577L+O/+fOYc/0v//V/u/oJLvKMedWVL5S+SzUaD++wA+yUObzXXeAs lZtuRuh2D1h50qps99S/iioRoHwW6P/2ij5JzF1N9rL1AXal+33G93Sfn58vcVt+0urcBupO 8d3Pl4bR+ef+b3Oz96cfjP9ck78XRpaXXJ79Ur3xlLnVzC1zUPPxP3MbpKVKyXUsVKlmg+Sq VLmPkgUlN8hpV5dP5Ze/4e6H05effAt/4f1Z+v+snD055WUh3fhylQoja05MySnrC8otsLzY uctMzpsspXHT5SpfuY9yB8NY7qjrljloLBY2SK6q5dWsrGduy9dbsI8mC8rtoJodV1hg5ez1 B23C4+PjOUQ/vHj37t3pJVPHxjM+Z5xO/zP++fJDf3j5YfDfeAnJMYPlFMrtF5T7bbKqg4LG 9Swss1D/8gZJzpUsKFel+lVOLrN+I1fuo/qCtvA/o81UnnjwQ26C8TTJf5anqZl9XOLcgsa/ ym2Kddco+dv6NarZ/oXVTG6EWWtUv31a1ii5nMHeP8hhk9vy4yrVH2Dlek7+wdbspsW7Y3Ij 12+6ccLWtnSfX3K3pqVbL7J9kyxr8sbkZa5cPevr32/alqdMVmk81+Ry+u3L+o1TuUEWC27R tl99irlF1G/Z9KudrP/kMgtr3W9aLah8rp71lq1RYYvNKrRl0y1eu+0WNeuwWbFihc046wCb vPexym3g9oN2dTMuL58Tt4veQu52l0yPcNmwuDrZ67rLlrBdlcK2ZPz+Os4DWYM/zlPq+tuC Zc6aslyBucts3yCV9dyioLA12lRNzLdszC12x+052laa8SBVF7RrtXRrrHVSLi9nWSmXDxaX /yZvtV4e6KsvaHB/tLKgFbdbcgn1I1fZbsdRn7i5KQtL6N/HGtzo6r59Ud9G3O4x0Vw9A7be 6utYv+nmljW519ayeHe0rGPYA9Vr7eKAg3auTTo8yDVzK8+w40dvBnFVGNlvHfZLLC9zVhwW 1ihZen9TDLbMYPZClWo2XXL23AYpz17eyPX7qHK7HdM4/06jr3N016zGUw7+wiev+ianHMyV nDI5MlnPpMk1Ko+s3HoL1n3x7qgvKFf6uPJz1/20vcYDrPHwrrdsH5ULyi2zfcfVzN74F/fw +Pj4+vXrjx8/nv/x/v37t2/fRjZkr1dYK+2KmoPL1uj2VnAVW7eT2Misp4K5eU9PT4OE1bUf 0RY04uFazGpacYeE7kJhUXGTmXSTK7UuJ+vrZd9RcMTXQALATRK6VXSicNsa3zK/SgW2eIHw 1b0yfsE6jv+5+94MXutDqXzp/3VZt4+Qewnda+9EgVuSfO/E6qXc80XO+j4DjhkJO9Yq5qX/ kVVtf8VNsguHxXR4AL+LPM3dcxxSwxFSI34rrVLiETs8SH6fpKXDg2vpRIEdJd9gV98PwVj5 le6LXxyffF/Vjh0zFLZSZUEtL5Rv7DOg/RX5uQ4P5nY5MN6bkx1FtO+4xg0y6yHt+g1S2edB ZScKjd1XzNqetRvkaB0e1L92PzfyKjpRIEB9hwfj180/z3yh/Ligwkv5kzWZfL17zUKeq99c /zz/Bf01U859w/6KPSss6DPgue0V+bldvKDLgZo9NSh01lZasD3LlZnbzUa59MKmq69qze4o b97yn3a5GrmtdK0dHgw6DCi8oP9aOlEgwLI38i94LX6h77aYNd2l7+76jgS66ZOvnt+iZ4XF c61eyurV6B+iR3ipYWWdF1RprR41lm2Q/sunxottqfzVdHgwuEzdH3kc7Z0osLu1HpfYrm6D E0Fkxwxjs0pPvnq+sWeFxj4DGrW8cCq5N+cuYUElj3B4716lsGN+7NAdHgzeG/xSdLbbgGV9 CaxSvU1LgXqbdswwOWW5w4CaV883vqQ+bOt1wro3mKzkFo/yrrXly8uJTNzV+whZsDsO1+FB 8q39s97FX7PYWcsM7kSBg9jifX7Jt6LXvyr9lLretW/HDJPLLBfU3rNCo8ZX5FdWr9yzQrLZ tNGOm/wQs8VL/8vL3LQThfo1qjfr8H56ehrMrsMDgCV0ZsCkcYcH9/JyDADYndAFWEIzlwWE LgAEue7Q1Q/BJBsE4Dh2Dt2b7IegcqXEIcC9ue6W7jEd86MAALtb/3u6uR4LklOerqEfgtyU hXqOt8Bg9vp1n9VfQm4rtWyQWVsegIL1Q7f/ZoxkH0HdZMl3aCQzuz7IB7/tfh7PPljsIHL6 9UwuM1el5ELGs9eve309Cx001WyQWasJwAIbvpHqtNNLklv6IcjVs7H+9bO31DPXLUT9Blm2 6QCotEnoHk17PwRhLbxV0n181bpygyx+eScANTZ5kKp/XXTWXGuVvnopl3W5/LdFCDV24TCY ftbGH9yyLa+mVi9Ai20fpJrs4O+K+iEYrMWsKrWs+6waVs5e2CA1qwnAMjo8mHYnTw/dyWoC hNHhAQDsJnF5+bcvuzb8+u4bvnfS/ruT1QTYkZYuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE 6AJAEKELAEGELgAEEboAEEToAkAQoQsAQRIdHujhAAC2oKULAEGELgAEEboAEEToAkAQoQsA QYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQu AAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQR ugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQ ROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgC QBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBCh CwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBB hC4ABBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4A BBG6ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6 ABBE6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE 6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJA EKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKEL AEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGE LgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAE EboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboA EEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEETo AkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABEmE7tMcDw8PHz9+PM9laGhoaGho2B8mPD4+ Pj8/f3jx7t27bkyNy/SX2Q0NDQ0NDQ37w3HCZkP3Q4XL9LuvlaGhoaGh4QGHm4Tu7mtlaGho aGh4wGFT6J5/Ox6jpWtoaGhoaJgcLg/ddy8G47V0DQ0NDQ0Nc8OFofvus/F4LV1DQ0NDQ8Pk cEnovuvpj/+gpWtoaGhoaJgfaukaGhoaGhoGDd3TNTQ0NDQ0DBq2Pr08GK+la2hoaGhomBu2 fk93MF5L19DQ0NDQMDf0RipDQ0NDQ8OgoTdSGRoaGhoaBg1rQ/ddNS1dQ0NDQ0PD5LAqdOfa fa0MDQ0NDQ0POBwn7MN51OvXry89/71///7t27fnMQuiFwAYGCTsq9xEe9cTAK7b09PTYMyr 3KTnTN67tgBwxcYt2P/au0oAcC+yofuXL21aif/3ww/Jn2v85S+/Ff4Z41zoLuWuVfnTqttt vDVWWfjq9Vxvff/z1zE4dOceyas4F7pLuQVbnz1OsScraFRq6f67Z7tD+XyO+O+ffjramaLe OQb+/e+vz/8dMA8Wr1HL7OdNsfcaxDn/XZz/OvauxX9c/pSO9te06dmjK+LUO1+Vi5PK7Gv/ y8uXc8R5ePp81riM704chzqDDFwS9/Lz0XL3UJVha/2/naPlLtB5NXeG/ufEywfM/of9ZR/8 x4l76p04+iOrK/lbv711+Wc3/Fz5r7vf9tbo6/70gylnlT6Yvb308ZS5kafexdjJyl8mGCzw MhwvsLL03GZp2fKDeh5BzdE+OKq76zr9XBx/0Dx9+UcxnrJScvb20sdT5kZeXFqf8ZcEkier bnicSxTclVLojg/Z05dHauEPafxBO/npO3cSGd/lLcxe36Trh1A/iQcTDMbXRNdkQcllJkuv r2du9tPnZveCiErOOLf0mg1yGoX6Klt+X/Xty8FFnf71nv7IwfjcvZhCGI9nzy1zXHp9PXOz j42v7iYvCM8aOVjyuDHQ/TMZ/1tUyUgjL8bvvSiFbuUB2o3vT5n8k6s8NZx6H7T7c+VmzzXI ylNWznKaal0lZ69sXy77bX+yfpN0MNeh4mqLLX9Ag+CpnLJylm6umo+q5YLqJ6hsWw+uSxXm Sn5Mbxw5+NXcVvUWVTLSyJyJy8uD3B1/eJwsoEbhY/Wp+Km5Rv/Mnmw5NZ7Zk5Hf2ESrn71r GbevSLBxQ3nvGs0296rp4PrN+KhuOc5Pmchv/POpnz35QfniUI+bwb6m7+nmziwbJW73z8kG brHOX9wXzP08nnGt65ktt4TrZx9cp511vbfSWhtk8uJzexHHNLgnmvt5PGNjWOYqsNHsgz/b tSq/NZ8GiFf1IFWXu/1r1t3P3W8bj+DxnaEWuVP8+BrsrKeB2itQWXpNPQuz1z9IVa5VoaDk yH5bv1+l8jKP9uD3nG01fdjnDunB+MHN2hVDq2ZRhdJr6lmYPSDY+o9HnXrfIMo9lTKYEiKl Ozw4j7nq10DWPPgTVnrw7KsvhxY1jx2FlR48O/D6xXSHB9duu/brFbnPtT6a7dqvwDVKt3R/ /vnnvSsGANft+++/n27pfvXVV3vXEwCu3jl0B2MSofv8/Lx3PQHg6o37093/3csAcCeELgAE EboAEEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboA EEToAkAQoQsAQYQuAAQRugAQROgCQBChCwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEETo AkCQuwvdh4eHvasAwJ16lftFP5yen5/ja3auwOJyu8qPl1C5zJbSASAp29K9RM7zi6trHV6q vXctAOALr2ZNfUnfLoa7YBu0LHOTnVJt0OTEl5/HY/pTnmY2wXNz5aqUq7w4B2CZefd0u/wb RNHzZ4OYHDSUx1PmltlvZw/GDIazKj+epavSeDU1lwFY10RLN9m262de4d5nskGZu1I9yNHy LdXut+OllWMyudhx7uZKl8EAtCg9SJXLp8mFzgqt+keWLu3jcYN4Vh2SVXLdGIAAa35lqJ9z g0vKyYkrl1kopb3Clx9yC+yX/vBixc0FwL1Jt3QLzzENGoW5x5rGT1ENnoIe3OudnL3/q/Iq JRebK6uy8gDQLh26s6Ku8p7uKXNveO5iJ9Vf2Z61UgIYgEbrv5Gq/MBUy2Jd3QXgqs37nm6N jVqEGpoAXLu7e/cyAOxF6AJAEKELAEGELgAEEboAEEToAkAQoQsAQYQuAAQRugAQROgCQBCh CwBBhC4ABBG6ABBE6AJAEKELAEGELgAEEboAEETocsUeHh5WmQYgxqt9i7+cEJ+fn3dfQuNC BotaZWmUnbd2fyMP/tk5j8z9CiDY1bd0n180LuE4lQHghrW2dAfX7i6tisHPlxwqTDlorQ7a i8nLg4PxgxbPYMpTpg1a2Uoer1G5ApOzF6pUX6s7N27mnvKbTmMXOIimlm53juu38JKntv6U 3cj+LOMg7JJpsOT++NxpdPCr8TL7Iyfv+SVP4oMVLyykZoO479iov0f2rgtA1pr3dCubjFuf FvsxVmgB96fv/yrZUC6sTotcI37T7QPAXoIepEo2MbcrLllEZYmFh3HG69LYTpWvi826Yuza MnAQaz5IVciehxflq39rXWKdjMPByPpyt7sIPGhqu9rcyAYEjqmppXtpbYy/cjMYP/4hOWV3 W26wzNwJdHxNOHcxOVnPbmRXxKz20GCZp0yWJ1eqK3TFbyvdoUFjd3w14kIzFziO1svLhUeZ Fi+hcFm4/yzVrCqVR9bUdrKea80uIerV3EGwPYHjuPrv6QLAtRC6ABBE6AJAEKELAEGELgAE EboAEETocsu8aQQ4lJ1D9/bOibe3RldkvOV9SRc4FC1dboeIBQ7uivvTLdenpvPaQu9+9bPP XaNkBRr3wl3pv7nzZGMCV+WK+9NNVqm/nMIyT6nEzfXHUJ597hrRrus8I/e+ZYBjuu7+dAt9 347f0lzZn25lWXPXqKW3QQZsN+BKXXd/uo1dDrSUVb9GwX0JA3BYN9if7tx6zi23i8/KNSpM 6VFngLty3f3pJmOs/0Numf2RgyJm9X1bs0a5KVlRcr/nnmsD2Mut9ac7qz71E8/qTLf+xq0Y WCC5efWkC1yFe/+ebrJFDgBbCHqQ6rA0hgAIc+8tXQAII3QBIIjQBYAgQhcAgghdrlj/gfOW N40sfg/oisuPkdtKy14RcxsePosscbsq7fvKnXHp13KoFF4Ise4q3HV/ul4IddUGb0c57IPo ybe47KXw3fT6v4XFa7T7n9u4AsnOM/ataq5KlQq9tizbRO2lR1p9TVdfIy1d4F6UT6AH/Ax3 kGpckZb3MsW4tf50kwWNl3kqviPQWwOPr7Kxldvvl+NqsIRcH72nzBs9TxUHyaCUQY+TuWP+ 1Hv/6GRB9cssS26Tmi0/2dv0gj4/6jdIZen1ReembNlHp+ZjKVd6Yb8M5q1Z/dyU9Ru5fvW3 O+brj8/Ci4Tn7o7cZI+Pj4ORTaGbDMtkTCbTd5DKySn7u6E7KXTjy1XKvY+3u3ojXG9e8qzU P5Byf7rj35aXuXo9C9VrWffVJU/9yZHlDzr9aufipLyPyiNPqVNTLmOSU7bso+SxlKt8rkqL 92b9ls9NWb+Ra1Y/2e9qbnsm61le08nKn/I5NXdvLqjnbfanO/l5p3FFuBZr7fTxhZngei44 JmPuSg4+vCY/psxdr9wyl92tnDxHV27btfZR+VjKVWn1vRl5lmvZcY31zB1Ljdtk1keBgVvr T7dQkCi9JTWny/EH0vZy5y5zUM/JRvaCeq61zMr4GW/5wXX7/sjFkstM1jDs73qLgurzfvUj eV9bHPOFiU9rN/lalnNr/ekuLmjw4OINHNb0Te7Q8gSTx0xYPQ+yzPHCC0/bzt16uWV2t5bK d5cCVr9lmbl5K5fZvo5hTzJXLmf347OxJnPnurX+dJMF1dRTO/jq9D/nJu/fj8/X/XmTS+v/ Njl7YZk19TxlWopzl1kuIrfM5FbqxtT/CfSLS27Y3NaufEymsLMGc9WXXlj3gclj6TT/dDF5 LNVvkPKhmFvNyi1/mvpDWLaRK/+4FmzSZHN5csfV13OLg+Gu+9PNjRfA12LyYmb54BnMXj4U k2XV38Yr/LOmoLlFTK775Oz1xc36I1q2xeZOWX8VumXKxfUs7+LJkYVDcZVdXLlNZk0WcMw3 7uJkPdsDbsz3dAEgiNAFroDrT1yd5EErdAEgiNAFgCBCFwCCtIZu7iutYV+YA4Br0Rq6hSeq c28423uVAWAfLi8DQJBE6A5eiNj/uVOzaI1dAOib8UaqxS+NAwBOs0JXCxUAWiRCd9OewjSR AbhbSx6k0uQFgAXSl5c36ilMMxeAe5a9p7tFT2ESF4B75nu6ABBE6AJAEKELAEGELgAEEbpc mfZvrNW/yhRgXTuH7hanP6dUyjxFD+xFSxcAgsx493LSoE2ZfIfGpWFRmHLwbo3+lLleiXKN leQyx1UaLz9X+mDJGkkH0d+ngzGTI8sLLM/evSG1ZpkAA02hm4yrZEyWIzCXbZcLxf3Jun/m Xm6VXGYhawcLTJa+8y5iZPxW8PG7wXMjJxfY/2dyZOGd5ABlrS3dvsmzz+qNxXGUrlLnWW1r 4m2xL5I73ZEArGvN0C3ot3FXjN76hXTN2Zq5nFXv0OSrwj2dB7Rb80Gqwlmpu1RbyLMtTmqT yyxP0P+th6KPY+sdkbs/AtCoqaXbbz6eem2FwfjxD8kpu7tog2Xmznfl27q5Ru1gzOA+bm6N OJTxo0yD46QwMvmo3eTsheMQoF7r5eVcLM268FseM6t3o7mll4tbvEy2kzsGKju2mrV/J489 RwUwy118T3fc7O7/UwsGgBhBD1Ltq765AwDbuYuWLgAcgdAFgCBCFwCCCF0ACCJ0uWL1726M qYyH4evVvLhm8fbcd0eMS7+Wo6LwUoSwlxddy7ZabJPQXWUPNZ7CVjwDPvSsvq1YLPl2lJge CJKvrHr+bPAis4DSY+aNlNuelerfqZ4rvaXyu385YvU13WiNkjv35l9Ec9yWbuNuXvEoKb+9 kjtUPh7Gr9SILP323Nv6tmt5NxFb27A/3cl+anN9BCXf4FiYPdlxb2WXR6fi2/5q3hRd6DZY d7zbqWzm1neIW98db/2urD+S6/voTfaGWblGuR5HtthKhcpPlj45+6Ceg01RmLdm39VvpVmV T65+y8GQ62Ky8qgrbI1Zh2JlPXPLHHfBmRt5M1brTzcXQp3+nu6uHfU7yn0YdZ1bOXt/xtzs Y7kixgVVzj7eIDd83FyF3Bn5oa073vGuz52mk1OOlzkoa3CS6i/tlD/watYody7bYiuVd0f/ o3nuA0Rye9YUlJRc9+RGzk3Zsu6nTEY2HgyFNZ2s/Kn6WJpcncl6Vi7zTqzwRqq5LctK9ffG ci/FLcy+aWdHySXc+XG2i3FvFt348cQ1n9LKBVXu4sqCWt4fXlj3+irVv+F82T3XwSWxmu25 +q2+yL/KlqOu/V5b/cFQX1b9RwFnv77WXoZOdddtchdgKzXOnqvY+KJHe0EnR1iIyqtSyTsO k629rWseWdDkZ+JxkyV4jeo/rDTW82ga16g72ms+8M269VZfgWVrOvmr224NNz1I1b/SW5hm 8cIb6xZTUOWSPfwcr/+JanznvnD9P7mnjvYc8rJ1L5c+qz4tWyk3Wcvs7ZVvnLJlOZueHGoO hsaalOea/Iu7K6tdXj7N6SX3lP+zGd/f7Y9Mzp4saDB75bpM1rOwUuN6Orw2NdnYHZxfcncH c1MmRw4uitZ83BwfM7lqTKovPVfQ+OrO+OPIrGXWr1GyoBVnH9wMHm+lygeUJrfSadER0rLl y/VMNpcnj7r6eq5yJOc+3d5bM/e0yuXlyl/V30hI3nubFZz1szReZqyf/bYPo73k7hqUJ1i2 qPICG4+EynrWzDt5/JermntCor3yp4o/8/o1LZwlZp2X6qdsOUJyFavfIJX1bDw+y3t/8cas rPxaiz24435PFwBujNDlvtz852g4FH9xA0IXAIIIXQAIInQBIIjQBYAgQhcAgghdAAgidAEg iNAFgCBCFwCCCF0ACCJ0ASCI0AWAIEIXAIIIXQAIInQBIIjQBYAgQhcAgghdAAgidAEgiNAF gCBCFwCCCF0ACCJ0ASCI0AWAIEIXAIK8Gvz78fHx6elp71oBwA36InTfvHmzd30A4GZ9Ebof P37cuz4AcLPc0wWAIL+3dH/88ce9qwEAAAAr+f96NwyWv9UCkQAAAABJRU5ErkJggg== --smuggle-security-FBI-qBvnyIN4bI Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit uname -a: CYGWIN_NT-4.0 LOON 20.1 (0.3/1/1) 1998-12-3 20:39:18 i586 unknown ./configure '--cppflags=-I/usr/local/include' '--ldflags=-L/usr/local/lib' XEmacs 21.2-b20 "Yoko" configured for `i586-pc-cygwin32'. Where should the build process find the source code? /usr/local/src/xemacs-cvs What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/cygwin32.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? default What window system should XEmacs use? msw Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in File coding support. Compiling in EXPERIMENTAL support for Drag'n'Drop ( msw ). Using MS-Windows menubars. Using MS-Windows scrollbars. Using MS-Windows native widgets. Using MS-Windows dialog boxes. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- Sam Mikes smikes@alumni.hmc.edu --smuggle-security-FBI-qBvnyIN4bI-- From owner-xemacs-beta@xemacs.org Thu Nov 18 14:16:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29137 for xemacs-beta-out; Thu, 18 Nov 1999 14:16:44 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA29121; Thu, 18 Nov 1999 14:16:36 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA24724; Thu, 18 Nov 1999 20:14:07 +0100 (MET) Received: from riesz(129.132.144.7), claiming to be "riesz.math.ethz.ch" via SMTP by frege, id smtpdAAAa0062H; Thu Nov 18 20:13:57 1999 Received: (vroonhof@localhost) by riesz.math.ethz.ch (8.6.12/D-MATH-client) id UAA15394; Thu, 18 Nov 1999 20:13:57 +0100 Date: Thu, 18 Nov 1999 20:13:56 +0100 From: Jan Vroonhof To: Brad Giaccio Cc: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org, kyle_jones@wonderworks.com Subject: [patch, 21.x] Re: itimer in xemacs 21.x Message-ID: <19991118201356.A15389@riesz.math.ethz.ch> References: <80ugbo$g9n$1@flint.psrw.com> <199911181754.MAA13070@jojo.psrw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199911181754.MAA13070@jojo.psrw.com>; from Brad Giaccio on Thu, Nov 18, 1999 at 12:54:21PM -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Is it something to do with speedbar having idle == yes, or should I > continue to try and parse the itimer-run-expired-timers function. > > Thanks for your help so far, at least now I know where its failing. I think I found it. It is this code (if (if (itimer-is-idle itimer) (or (> (itimer-time-difference recorded-run-time last-event-time) 0) (< idle-time (itimer-value itimer))) recorded-run-time = (0 0 0) and then the computation in itimer-time-difference overflows an emacs integer. The attached patch fixes this. The question now is... How could this ever have worked before? itimer.el needs to be reworked to use modern interfaces 1999-11-18 Jan Vroonhof * itimer.el (itimer-run-expired-timers): Don't use save-excursion. list-itimers rewrites contents! * lisp/itimer.el (itimer-time-difference): Use floats always to avoid overflow. Index: lisp/itimer.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/itimer.el,v retrieving revision 1.5 diff -u -u -r1.5 itimer.el --- itimer.el 1998/05/18 05:42:08 1.5 +++ itimer.el 1999/11/18 18:46:18 @@ -425,43 +425,43 @@ (opoint (point)) (standard-output buf) (itimers (reverse itimer-list))) - (set-buffer buf) - (itimer-edit-mode) - (setq buffer-read-only nil) - (erase-buffer) - (insert + (with-current-buffer buf + (itimer-edit-mode) + (setq buffer-read-only nil) + (erase-buffer) + (insert "Name Value Restart Function Idle Arguments" "\n" "---- ----- ------- -------- ---- --------") - (if (null itimer-edit-start-marker) - (setq itimer-edit-start-marker (point))) - (while itimers - (newline 1) - (prin1 (itimer-name (car itimers))) - (tab-to-tab-stop) - (insert (itimer-truncate-string - (format "%5.5s" (itimer-value (car itimers))) 5)) - (tab-to-tab-stop) - (insert (itimer-truncate-string - (format "%5.5s" (itimer-restart (car itimers))) 5)) - (tab-to-tab-stop) - (insert (itimer-truncate-string + (if (null itimer-edit-start-marker) + (setq itimer-edit-start-marker (point))) + (while itimers + (newline 1) + (prin1 (itimer-name (car itimers))) + (tab-to-tab-stop) + (insert (itimer-truncate-string + (format "%5.5s" (itimer-value (car itimers))) 5)) + (tab-to-tab-stop) + (insert (itimer-truncate-string + (format "%5.5s" (itimer-restart (car itimers))) 5)) + (tab-to-tab-stop) + (insert (itimer-truncate-string (format "%.19s" (itimer-function (car itimers))) 19)) - (tab-to-tab-stop) - (if (itimer-is-idle (car itimers)) - (insert "yes") - (insert "no")) - (tab-to-tab-stop) - (if (itimer-uses-arguments (car itimers)) - (prin1 (itimer-function-arguments (car itimers))) - (prin1 'NONE)) - (setq itimers (cdr itimers))) - ;; restore point - (goto-char opoint) - (if (< (point) itimer-edit-start-marker) + (tab-to-tab-stop) + (if (itimer-is-idle (car itimers)) + (insert "yes") + (insert "no")) + (tab-to-tab-stop) + (if (itimer-uses-arguments (car itimers)) + (prin1 (itimer-function-arguments (car itimers))) + (prin1 'NONE)) + (setq itimers (cdr itimers))) + ;; restore point + (goto-char opoint) + (if (< (point) itimer-edit-start-marker) (goto-char itimer-edit-start-marker)) - (setq buffer-read-only t) - (display-buffer buf))) + (setq buffer-read-only t) + (display-buffer buf)))) (defun edit-itimers () "Display a list of all itimers and select it for editing. @@ -693,7 +693,7 @@ (if (if (itimer-is-idle itimer) (or (> (itimer-time-difference recorded-run-time last-event-time) - 0) + 0) (< idle-time (itimer-value itimer))) (> (itimer-value itimer) 0)) (setq next-wakeup @@ -741,8 +741,7 @@ ;; if user is viewing the timer list, update displayed info. (let ((b (get-buffer "*Itimer List*"))) (if (and b (get-buffer-window b)) - (save-excursion - (list-itimers)))) + (list-itimers))) next-wakeup )) (defun itimer-process-filter (process string) @@ -840,7 +839,8 @@ (setq 65536-secs (- (nth 0 t1) (nth 0 t2) carry)) ;; loses for interval larger than the maximum signed Lisp integer. ;; can't really be helped. - (+ (* 65536-secs 65536) + ;; JV So we use floats always. + (+ (* 65536-secs 65536.0) secs (/ usecs (if (featurep 'lisp-float-type) 1e6 1000000))))) From owner-xemacs-beta@xemacs.org Thu Nov 18 18:02:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA04769 for xemacs-beta-out; Thu, 18 Nov 1999 18:02:59 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA04766 for ; Thu, 18 Nov 1999 18:02:57 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id SAA22019 for ; Thu, 18 Nov 1999 18:10:02 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-3.ecf.teradyne.com [131.101.192.123]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id AAA01209; Fri, 19 Nov 1999 00:02:48 +0100 (MET) To: XEmacs Beta List Subject: Any objections against xemacs/*/xemacs.mak files in 21.2? X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 00:01:36 +0100 Message-ID: Lines: 34 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello Reviewers, while trying to improve makefile[1] support for Windows NT native I am faced with this problem: ALL make rules for building XEmacs Windows NT native[2] are in nt\xemacs.mak. However, @setfilename in man\*\*.texi are obviously relative to man\*, not nt. Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info target (just like on Unix) would be must superior. There is no danger in clashing with Unix makefiles since they are always called Makefile. I would be willing to send in patches for 21.2 to make xemacs.mak build recursively if any objections/problems can be resolved. Any objections? Regards, Adrian Footnotes: [1] triggered by Martin's > From: Martin Buchholz > Subject: Martin makes man & Makefile makeover > Message-ID: <14384.56980.560513.767776@lasker.666.com> [2] Building in lisp, src, man, lib-src From owner-xemacs-beta@xemacs.org Thu Nov 18 19:40:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA08056 for xemacs-beta-out; Thu, 18 Nov 1999 19:40:25 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA08043; Thu, 18 Nov 1999 19:40:20 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id TAA00951; Thu, 18 Nov 1999 19:47:26 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id BAA01285; Fri, 19 Nov 1999 01:40:04 +0100 (MET) To: Martin Buchholz , "J. Kean Johnston" Cc: xemacs-beta@xemacs.org Subject: Re: Martin makes man & Makefile makeover References: <14384.56980.560513.767776@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 01:38:54 +0100 In-Reply-To: Adrian Aichner's message of "18 Nov 1999 11:30:27 +0100" Message-ID: Lines: 62 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: >>>>> "Martin" == Martin Buchholz writes: Martin> - Make sources compatible with makeinfo 4.0 *and* 3.12. APA> Hello Martin, APA> trying to generate info.info using texinfo-3.12 on Windows NT I get APA> this error: Hi Martin, All files process fine with texinfo-4.0 on Windows NT: cd d:\tmp\21.2\xemacs\nt\ d:\tmp\texinfo-4.0\makeinfo\makeinfo.exe --version Compilation started at Fri Nov 19 01:35:29 1999 +0100 (W. Europe Standard Time) makeinfo (GNU texinfo) 4.0 Copyright (C) 1999 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Compilation finished at Fri Nov 19 01:35:29 So obviously, contrary to what the ChangeLog says, not all texi files are compliant with makeinfo 1.68 after your patch. Adrian APA> cd d:\tmp\21.2\xemacs\man\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe APA> info.texi Compilation started at Thu Nov 18 10:55:16 1999 +0100 APA> (W. Europe Standard Time) Making info file `../info/info.info' from APA> `info.texi'. info.texi:69: No matching `@end ifnottex'. APA> info.texi:77: Unmatched `@end'. makeinfo.exe: Removing output file APA> `../info/info.info' due to errors; use --force to preserve. APA> Compilation exited abnormally with code 2 at Thu Nov 18 10:55:18 APA> What do you make of this? APA> Can you generate .info files for all .texi files in the latest 21.2 CVS APA> sources using APA> cd c:\XEmacs\xemacs-packages\etc\psgml\ APA> d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe --version APA> Compilation started at Thu Nov 18 11:28:48 1999 +0100 (W. Europe Standard Time) APA> makeinfo (GNU texinfo 3.12) 1.68 APA> Copyright (C) 1998 Free Software Foundation, Inc. APA> There is NO warranty. You may redistribute this software APA> under the terms of the GNU General Public License. APA> For more information about these matters, see the files named COPYING. APA> Compilation finished at Thu Nov 18 11:28:48 APA> ? APA> Best regards, APA> Adrian From owner-xemacs-beta@xemacs.org Thu Nov 18 20:05:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA09088 for xemacs-beta-out; Thu, 18 Nov 1999 20:05:04 -0500 Received: from fw1. (ibnnet.ibelong.net [4.17.130.131] (may be forged)) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA09083 for ; Thu, 18 Nov 1999 20:04:59 -0500 Received: from ibnmail.ibelong.com by fw1. (SMI-8.6/SMI-SVR4) id UAA08516; Thu, 18 Nov 1999 20:02:45 -0500 Received: from belonger900 ([192.168.20.248]) by ibnmail.ibelong.com (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with SMTP id <0FLF00MBQ6VSB8@ibnmail.ibelong.com> for xemacs-beta@xemacs.org; Thu, 18 Nov 1999 20:02:16 -0500 (EST) Date: Thu, 18 Nov 1999 20:10:11 -0500 From: Paul Krause Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? To: XEmacs Beta List Message-id: <02d001bf322a$f07c81d0$f814a8c0@ibelong.net> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 References: X-Priority: 3 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info A name like man\xemacsNT.mak or even man\infoNT.mak might reduce confusion later. -- Paul Krause 781.672.8220 fax 781.684.8252 iBelong Inc, 950 Winter St, Waltham MA 02125 From owner-xemacs-beta@xemacs.org Thu Nov 18 20:24:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA09664 for xemacs-beta-out; Thu, 18 Nov 1999 20:24:57 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA09657 for ; Thu, 18 Nov 1999 20:24:53 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id UAA04514; Thu, 18 Nov 1999 20:32:02 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id CAA01331; Fri, 19 Nov 1999 02:24:45 +0100 (MET) To: Paul Krause Cc: XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? References: <02d001bf322a$f07c81d0$f814a8c0@ibelong.net> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 02:23:36 +0100 In-Reply-To: Paul Krause's message of "Thu, 18 Nov 1999 20:10:11 -0500" Message-ID: Lines: 26 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Paul" == Paul Krause writes: >> Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info Paul> A name like man\xemacsNT.mak or even man\infoNT.mak might reduce Paul> confusion later. Hello Paul, the idea is that the name should be the same in all subdirs, so that the top-level makefile can invoke them easily. Also, it's easier to understand which makefiles go together. configure/Makefile: Unixoid platforms xemacs.mak: native Windows platform Renaming xemacs.mak to something like windows.mak may be more intuitive than xemacs.mak, which doesn't really convey much meaning. Adrian Paul> -- Paul> Paul Krause 781.672.8220 fax 781.684.8252 Paul> iBelong Inc, 950 Winter St, Waltham MA 02125 From owner-xemacs-beta@xemacs.org Thu Nov 18 22:37:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA13735 for xemacs-beta-out; Thu, 18 Nov 1999 22:37:39 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA13732; Thu, 18 Nov 1999 22:37:37 -0500 Received: from 666.com (dialup001ip125.tus.azstarnet.com [169.197.12.125]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id UAA04866; Thu, 18 Nov 1999 20:37:19 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3834C5CA.DC2C9DF7@666.com> Date: Thu, 18 Nov 1999 20:36:44 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof CC: XEmacs Review , kyle_jones@wonderworks.com, XEmacs beta list Subject: Re: itimer rewrite References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Could you possibly rewrite this a bit so as to use defstruct? cl is now a standard part of XEmacs so there's absolutely no point in continuing to use vectors for structs. ben Jan Vroonhof wrote: > This was long overdue. Apart from streamlining the code this fixes two > important bugs in the idle timer code. > 1. The integer overflow reported earlier, causing no idle timers to > run at all! > 2. If XEmacs had been idle for a while at the moment of activation > then, it would launch the ideal timers immediately. This version > does what the FSF does, namely consider idle time from start time. > > This is intended for 21.2 and should go in 21.1 after some testing. > Should there have been insufficient testing I suggest the patch for > bug #1 I submitted earlier is used. > > Patch against 21.1.8 and complete file included. > > 1999-11-19 Jan Vroonhof > > * itimer.el: Modernized, removed compatibility code. > Use vectors for representation. > Use floats for time everywhere. > Start counting idle time from activation point for idle timers. > Try to keep the code in the inner drivers loops fast by avoiding > duplication of work and some defsubst. > _Correctly_ keep cursor from jumping around in M-x edit-itimers > Enforce a minimal update frequency for timer list buffer. > > Index: lisp/itimer.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/itimer.el,v > retrieving revision 1.5 > diff -u -u -r1.5 itimer.el > --- itimer.el 1998/05/18 05:42:08 1.5 > +++ itimer.el 1999/11/18 23:55:29 > @@ -1,5 +1,6 @@ > -;;; Interval timers for GNU Emacs > +;;; Interval timers for XEmacs > ;;; Copyright (C) 1988, 1991, 1993, 1997, 1998 Kyle E. Jones > +;;; Copyight 1999 Free Software Foundation > ;;; > ;;; This program is free software; you can redistribute it and/or modify > ;;; it under the terms of the GNU General Public License as published by > @@ -17,6 +18,11 @@ > ;;; 02139, USA. > ;;; > ;;; Send bug reports to kyle_jones@wonderworks.com > +;;; > +;;; Modernized and major bug fixes by jan@xemacs.org > +;;; > +;;; Synced with FSF: Not in FSF. Identical functionality with timer.el > +;;; wrappers. > > (provide 'itimer) > > @@ -46,23 +52,19 @@ > ;; > ;; See the doc strings of these functions for more information. > > -(defvar itimer-version "1.07" > +(defvar itimer-version "2.00" > "Version number of the itimer package.") > > (defvar itimer-list nil > "List of all active itimers.") > > -(defvar itimer-process nil > - "Process that drives all itimers, if a subprocess is being used.") > - > (defvar itimer-timer nil > - "Emacs internal timer that drives the itimer system, if a subprocess > -is not being used to drive the system.") > + "Emacs internal timer that drives the itimer system.") > > -(defvar itimer-timer-last-wakeup nil > +(defvar itimer-timer-last-wakeup 'wakeup-not-set > "The time the timer driver function last ran.") > > -(defvar itimer-short-interval (if (featurep 'lisp-float-type) 1e-3 1) > +(defvar itimer-short-interval 1e-3 > "Interval used for scheduling an event a very short time in the future. > Used internally to make the scheduler wake up early. > Unit is seconds.") > @@ -76,7 +78,7 @@ > ;; be delays due to system and Emacs internal activity that delay > ;; dealing with synchronous events and process output. > (defvar itimer-next-wakeup itimer-short-interval > - "Itimer process will wakeup to service running itimers within this > + "Itimer timer will wakeup to service running itimers within this > many seconds.") > > (defvar itimer-edit-map nil > @@ -98,21 +100,15 @@ > > (defvar itimer-inside-driver nil) > > +(defvar itimer-list-buffer nil) > + > +(defvar itimer-list-update-interval 1.0) > + > (defvar itimer-edit-start-marker nil) > > ;; macros must come first... or byte-compile'd code will throw back its > ;; head and scream. > > -(defmacro itimer-decrement (variable) > - (list 'setq variable (list '1- variable))) > - > -(defmacro itimer-increment (variable) > - (list 'setq variable (list '1+ variable))) > - > -(defmacro itimer-signum (n) > - (list 'if (list '> n 0) 1 > - (list 'if (list 'zerop n) 0 -1))) > - > ;; Itimer access functions should behave as if they were subrs. These > ;; macros are used to check the arguments to the itimer functions and > ;; signal errors appropriately if the arguments are not valid. > @@ -120,102 +116,108 @@ > (defmacro check-itimer (var) > "If VAR is not bound to an itimer, signal wrong-type-argument. > This is a macro." > - (list 'setq var > - (list 'if (list 'itimerp var) var > - (list 'signal ''wrong-type-argument > - (list 'list ''itimerp var))))) > - > + `(setq ,var (if (itimerp ,var) ,var > + (signal 'wrong-type-argument (list 'itimerp ,var))))) > + > (defmacro check-itimer-coerce-string (var) > "If VAR is not bound to a string, look up the itimer that it names and > bind VAR to it. Otherwise, if VAR is not bound to an itimer, signal > wrong-type-argument. This is a macro." > - (list 'setq var > - (list 'cond > - (list (list 'itimerp var) var) > - (list (list 'stringp var) (list 'get-itimer var)) > - (list t (list 'signal ''wrong-type-argument > - (list 'list ''string-or-itimer-p var)))))) > + `(setq ,var (cond > + ((itimerp ,var) ,var) > + ((stringp ,var) (get-itimer ,var))))) > > (defmacro check-nonnegative-number (var) > "If VAR is not bound to a number, signal wrong-type-argument. > If VAR is not bound to a positive number, signal args-out-of-range. > This is a macro." > - (list 'setq var > - (list 'if (list 'not (list 'numberp var)) > - (list 'signal ''wrong-type-argument > - (list 'list ''natnump var)) > - (list 'if (list '< var 0) > - (list 'signal ''args-out-of-range (list 'list var)) > - var)))) > + `(setq ,var (if (not (numberp ,var)) > + (signal 'wrong-type-argument (list 'natnump ,var)) > + (if (< ,var 0) > + (signal 'args-out-of-range (list ,var)) > + ,var)))) > > (defmacro check-string (var) > "If VAR is not bound to a string, signal wrong-type-argument. > This is a macro." > - (list 'setq var > - (list 'if (list 'stringp var) var > - (list 'signal ''wrong-type-argument > - (list 'list ''stringp var))))) > + `(setq ,var (if (stringp ,var) ,var > + (signal 'wrong-type-argument (list 'stringp ,var))))) > > ;; Functions to access and modify itimer attributes. > > (defun itimerp (obj) > "Return t if OBJ is an itimer." > - (and (consp obj) (eq (length obj) 8))) > + (and (vectorp obj) (eq (length obj) 8))) > > (defun itimer-live-p (obj) > "Return non-nil if OBJ is an itimer and is active. > ``Active'' means Emacs will run it when it expires. > -`activate-timer' must be called on an itimer to make it active. > +`activate-itimer' must be called on an itimer to make it active. > Itimers started with `start-itimer' are automatically active." > (and (itimerp obj) (memq obj itimer-list))) > > (defun itimer-name (itimer) > "Return the name of ITIMER." > (check-itimer itimer) > - (car itimer)) > + (aref itimer 0)) > > +(defsubst itimer-value-internal (itimer) > + (aref itimer 1)) > + > (defun itimer-value (itimer) > "Return the number of seconds until ITIMER expires." > (check-itimer itimer) > - (nth 1 itimer)) > + (itimer-value-internal itimer)) > > (defun itimer-restart (itimer) > "Return the value to which ITIMER will be set at restart. > Return nil if this itimer doesn't restart." > (check-itimer itimer) > - (nth 2 itimer)) > + (aref itimer 2)) > > (defun itimer-function (itimer) > "Return the function of ITIMER. > This function is called each time ITIMER expires." > (check-itimer itimer) > - (nth 3 itimer)) > + (aref itimer 3)) > + > +(defsubst itimer-is-idle-internal (itimer) > + (aref itimer 4)) > > +;; Reuse value > +(defsubst itimer-activate-time (itimer) > + (itimer-is-idle-internal itimer)) > + > (defun itimer-is-idle (itimer) > "Return non-nil if ITIMER is an idle timer. > Normal timers expire after a set interval. Idle timers expire > only after Emacs has been idle for a specific interval. > ``Idle'' means no command events occur within the interval." > (check-itimer itimer) > - (nth 4 itimer)) > + (itimer-is-idle-internal itimer)) > > (defun itimer-uses-arguments (itimer) > "Return non-nil if the function of ITIMER will be called with arguments. > ITIMER's function is called with the arguments each time ITIMER expires. > The arguments themselves are retrievable with `itimer-function-arguments'." > (check-itimer itimer) > - (nth 5 itimer)) > + (aref itimer 5)) > > (defun itimer-function-arguments (itimer) > "Return the function arguments of ITIMER as a list. > ITIMER's function is called with these argument each time ITIMER expires." > (check-itimer itimer) > - (nth 6 itimer)) > + (aref itimer 6)) > > (defun itimer-recorded-run-time (itimer) > - (check-itimer itimer) > - (nth 7 itimer)) > + ;; (check-itimer itimer) > + (aref itimer 7)) > > +;; Same as set-itimer-value but does not wakeup the driver. > +;; Only should be used by the drivers when processing expired timers. > +(defsubst set-itimer-value-internal (itimer value) > + (aset itimer 1 value)) > + > (defun set-itimer-value (itimer value) > "Set the timeout value of ITIMER to be VALUE. > Itimer will expire in this many seconds. > @@ -231,20 +233,13 @@ > ;; wakeup, wakeup now and recompute a new wakeup time. > (or (and (< value itimer-next-wakeup) > (and (itimer-name itimer) (get-itimer (itimer-name itimer))) > - (progn (itimer-driver-wakeup) > - (setcar (cdr itimer) value) > - (itimer-driver-wakeup) > + (progn (itimer-timer-wakeup) > + (set-itimer-value-internal itimer value) > + (itimer-timer-wakeup) > t )) > - (setcar (cdr itimer) value)) > + (set-itimer-value-internal itimer value)) > value)) > > -;; Same as set-itimer-value but does not wakeup the driver. > -;; Only should be used by the drivers when processing expired timers. > -(defun set-itimer-value-internal (itimer value) > - (check-itimer itimer) > - (check-nonnegative-number value) > - (setcar (cdr itimer) value)) > - > (defun set-itimer-restart (itimer restart) > "Set the restart value of ITIMER to be RESTART. > If RESTART is nil, ITIMER will not restart when it expires. > @@ -254,21 +249,22 @@ > Returns RESTART." > (check-itimer itimer) > (if restart (check-nonnegative-number restart)) > - (setcar (cdr (cdr itimer)) restart)) > + (aset itimer 2 restart)) > > (defun set-itimer-function (itimer function) > "Set the function of ITIMER to be FUNCTION. > FUNCTION will be called when itimer expires. > Returns FUNCTION." > (check-itimer itimer) > - (setcar (nthcdr 3 itimer) function)) > + (aset itimer 3 function)) > > (defun set-itimer-is-idle (itimer flag) > "Set flag that says whether ITIMER is an idle timer. > If FLAG is non-nil, then ITIMER will be considered an idle timer. > Returns FLAG." > (check-itimer itimer) > - (setcar (nthcdr 4 itimer) flag)) > + (aset itimer 4 0) > + flag) > > (defun set-itimer-uses-arguments (itimer flag) > "Set flag that says whether the function of ITIMER is called with arguments. > @@ -276,19 +272,22 @@ > otherwise the function will be called with no arguments. > Returns FLAG." > (check-itimer itimer) > - (setcar (nthcdr 5 itimer) flag)) > + (aset itimer 5 flag)) > > (defun set-itimer-function-arguments (itimer &optional arguments) > "Set the function arguments of ITIMER to be ARGUMENTS. > The function of ITIMER will be called with ARGUMENTS when itimer expires. > Returns ARGUMENTS." > (check-itimer itimer) > - (setcar (nthcdr 6 itimer) arguments)) > + (aset itimer 6 arguments)) > > -(defun set-itimer-recorded-run-time (itimer time) > - (check-itimer itimer) > - (setcar (nthcdr 7 itimer) time)) > +(defsubst set-itimer-recorded-run-time (itimer time) > + (aset itimer 7 time)) > > +;; Reuses the idle slot > +(defun sync-itimer-activate-time (itimer time) > + (aset itimer 4 time)) > + > (defun get-itimer (name) > "Return itimer named NAME, or nil if there is none." > (check-string name) > @@ -358,9 +357,9 @@ > (num 2)) > (while (get-itimer name) > (setq name (format "%s<%d>" oname num)) > - (itimer-increment num))) > - (activate-itimer (list name value restart function is-idle > - with-args function-arguments (list 0 0 0))) > + (incf num))) > + (activate-itimer (vector name value restart function is-idle > + with-args function-arguments 0)) > (car itimer-list)) > > (defun make-itimer () > @@ -369,7 +368,7 @@ > Set the itimer's expire interval with `set-itimer-value'. > Set the itimer's function interval with `set-itimer-function'. > Once this is done, the timer can be activated." > - (list nil 0 nil 'ignore nil nil nil (list 0 0 0))) > + (vector nil 0 nil 'ignore nil nil nil 0)) > > (defun activate-itimer (itimer) > "Activate ITIMER, which was previously created with `make-itimer'. > @@ -382,22 +381,27 @@ > (error "itimer timeout value not a number: %s" (itimer-value itimer))) > (if (<= (itimer-value itimer) 0) > (error "itimer timeout value not positive: %s" (itimer-value itimer))) > - ;; If there's no itimer driver/process, start one now. > + ;; make sure we count idle time _from now_ > + (when (itimer-is-idle-internal itimer) > + (sync-itimer-activate-time itimer (itimer-time-float (current-time))) > + (set-itimer-recorded-run-time > + itimer (itimer-time-float last-command-event-time))) > + ;; If there's no itimer driver, start one now. > ;; Otherwise wake up the itimer driver so that seconds slept before > ;; the new itimer is created won't be counted against it. > - (if (or itimer-process itimer-timer) > - (itimer-driver-wakeup) > - (itimer-driver-start)) > + (if itimer-timer > + (itimer-timer-wakeup) > + (itimer-timer-start)) > ;; Roll a unique name for the timer if it doesn't have a name > ;; already. > - (if (not (stringp (car itimer))) > + (if (not (stringp (aref itimer 0))) > (let ((name "itimer-0") > (oname "itimer-") > (num 1)) > (while (get-itimer name) > (setq name (format "%s<%d>" oname num)) > - (itimer-increment num)) > - (setcar itimer name)) > + (incf num)) > + (aset itimer 0 name)) > ;; signal an error if the timer's name matches an already > ;; activated timer. > (if (get-itimer (itimer-name itimer)) > @@ -406,11 +410,11 @@ > (let ((inhibit-quit t)) > ;; add the itimer to the global list > (setq itimer-list (cons itimer itimer-list)) > - ;; If the itimer process is scheduled to wake up too late for > + ;; If the itimer timer is scheduled to wake up too late for > ;; the itimer we wake it up to calculate a correct wakeup > ;; value giving consideration to the newly added itimer. > (if (< (itimer-value itimer) itimer-next-wakeup) > - (itimer-driver-wakeup)))) > + (itimer-timer-wakeup)))) > > ;; User level functions to list and modify existing itimers. > ;; Itimer Edit major mode, and the editing commands thereof. > @@ -421,47 +425,49 @@ > commands to manipulate itimers; see the documentation for > `itimer-edit-mode' for more information." > (interactive) > - (let* ((buf (get-buffer-create "*Itimer List*")) > + (let* ((buf (or (if (buffer-live-p itimer-list-buffer) itimer-list-buffer) > + (setq > + itimer-list-buffer (get-buffer-create "*Itimer List*")))) > (opoint (point)) > (standard-output buf) > (itimers (reverse itimer-list))) > - (set-buffer buf) > - (itimer-edit-mode) > - (setq buffer-read-only nil) > - (erase-buffer) > - (insert > + (with-current-buffer buf > + (itimer-edit-mode) > + (setq buffer-read-only nil) > + (erase-buffer) > + (insert > "Name Value Restart Function Idle Arguments" > "\n" > "---- ----- ------- -------- ---- --------") > - (if (null itimer-edit-start-marker) > - (setq itimer-edit-start-marker (point))) > - (while itimers > - (newline 1) > - (prin1 (itimer-name (car itimers))) > - (tab-to-tab-stop) > - (insert (itimer-truncate-string > - (format "%5.5s" (itimer-value (car itimers))) 5)) > - (tab-to-tab-stop) > - (insert (itimer-truncate-string > - (format "%5.5s" (itimer-restart (car itimers))) 5)) > - (tab-to-tab-stop) > - (insert (itimer-truncate-string > + (if (null itimer-edit-start-marker) > + (setq itimer-edit-start-marker (point))) > + (while itimers > + (newline 1) > + (prin1 (itimer-name (car itimers))) > + (tab-to-tab-stop) > + (insert (itimer-truncate-string > + (format "%5.5s" (itimer-value (car itimers))) 5)) > + (tab-to-tab-stop) > + (insert (itimer-truncate-string > + (format "%5.5s" (itimer-restart (car itimers))) 5)) > + (tab-to-tab-stop) > + (insert (itimer-truncate-string > (format "%.19s" (itimer-function (car itimers))) 19)) > - (tab-to-tab-stop) > - (if (itimer-is-idle (car itimers)) > - (insert "yes") > - (insert "no")) > - (tab-to-tab-stop) > - (if (itimer-uses-arguments (car itimers)) > - (prin1 (itimer-function-arguments (car itimers))) > - (prin1 'NONE)) > - (setq itimers (cdr itimers))) > - ;; restore point > - (goto-char opoint) > - (if (< (point) itimer-edit-start-marker) > + (tab-to-tab-stop) > + (if (itimer-is-idle (car itimers)) > + (insert "yes") > + (insert "no")) > + (tab-to-tab-stop) > + (if (itimer-uses-arguments (car itimers)) > + (prin1 (itimer-function-arguments (car itimers))) > + (prin1 'NONE)) > + (setq itimers (cdr itimers))) > + ;; restore point > + (goto-char opoint) > + (if (< (point) itimer-edit-start-marker) > (goto-char itimer-edit-start-marker)) > - (setq buffer-read-only t) > - (display-buffer buf))) > + (setq buffer-read-only t) > + (display-buffer buf)))) > > (defun edit-itimers () > "Display a list of all itimers and select it for editing. > @@ -470,8 +476,8 @@ > for `itimer-edit-mode' for more information." > (interactive) > ;; since user is editing, make sure displayed data is reasonably up-to-date > - (if (or itimer-process itimer-timer) > - (itimer-driver-wakeup)) > + (if itimer-timer > + (itimer-timer-wakeup)) > (list-itimers) > (select-window (get-buffer-window "*Itimer List*")) > (goto-char itimer-edit-start-marker) > @@ -503,7 +509,7 @@ > tab-stop-list '(22 32 40 60 67)) > (abbrev-mode 0) > (auto-fill-mode 0) > - (buffer-flush-undo (current-buffer)) > + (buffer-disable-undo) > (use-local-map itimer-edit-map) > (set-syntax-table emacs-lisp-mode-syntax-table)) > > @@ -549,7 +555,7 @@ > (while (and (>= opoint (point)) (< n 6)) > (forward-sexp 2) > (backward-sexp) > - (itimer-increment n)) > + (incf n)) > (cond ((eq n 1) (error "Cannot change itimer name.")) > ((eq n 2) 'value) > ((eq n 3) 'restart) > @@ -610,7 +616,7 @@ > (defun itimer-edit-next-field (count) > (interactive "p") > (itimer-edit-beginning-of-field) > - (cond ((> (itimer-signum count) 0) > + (cond ((> count 0) > (while (not (zerop count)) > (forward-sexp) > ;; wrap from eob to itimer-edit-start-marker > @@ -625,8 +631,8 @@ > (progn > (forward-sexp 2) > (backward-sexp))) > - (itimer-decrement count))) > - ((< (itimer-signum count) 0) > + (decf count))) > + ((< count 0) > (while (not (zerop count)) > (backward-sexp) > ;; treat fields at beginning of line as if they weren't there. > @@ -637,7 +643,7 @@ > (progn > (goto-char (point-max)) > (backward-sexp))) > - (itimer-increment count))))) > + (incf count))))) > > (defun itimer-edit-previous-field (count) > (interactive "p") > @@ -657,53 +663,44 @@ > > ;; internals of the itimer implementation. > > -(defun itimer-run-expired-timers (time-elapsed) > - (let ((itimers (copy-sequence itimer-list)) > +(defsubst itimer-time-float (time) > + (+ (* 65536.0 (first time)) (second time) (* 1e-6 (third time)))) > + > +(defun itimer-run-expired-timers (time-elapsed now) > + (let* ((itimers (copy-sequence itimer-list)) > (itimer) > + (dorun) > (next-wakeup 600) > + ;; last-command-event-time is nil on startup > + (last-event-time (if last-command-event-time > + (itimer-time-float last-command-event-time) > + 0)) > (idle-time) > - (last-event-time) > - (recorded-run-time) > ;; process filters can be hit by stray C-g's from the user, > ;; so we must protect this stuff appropriately. > ;; Quit's are allowed from within itimer functions, but we > ;; catch them and print a message. > - (inhibit-quit t)) > - (setq next-wakeup 600) > - (cond ((and (boundp 'last-command-event-time) > - (consp 'last-command-event-time)) > - (setq last-event-time last-command-event-time > - idle-time (itimer-time-difference (current-time) > - last-event-time))) > - ((and (boundp 'last-input-time) (consp last-input-time)) > - (setq last-event-time (list (car last-input-time) > - (cdr last-input-time) > - 0) > - idle-time (itimer-time-difference (current-time) > - last-event-time))) > - ;; no way to do this under FSF Emacs yet. > - (t (setq last-event-time '(0 0 0) > - idle-time 0))) > + (inhibit-quit t)) > (while itimers > (setq itimer (car itimers)) > (if (itimer-is-idle itimer) > - (setq recorded-run-time (itimer-recorded-run-time itimer)) > - (set-itimer-value-internal itimer (max 0 (- (itimer-value itimer) > - time-elapsed)))) > - (if (if (itimer-is-idle itimer) > - (or (> (itimer-time-difference recorded-run-time > - last-event-time) > - 0) > - (< idle-time (itimer-value itimer))) > - (> (itimer-value itimer) 0)) > - (setq next-wakeup > - (if (itimer-is-idle itimer) > - (if (< idle-time (itimer-value itimer)) > - (min next-wakeup (- (itimer-value itimer) idle-time)) > - (min next-wakeup (itimer-value itimer))) > - (min next-wakeup (itimer-value itimer)))) > - (and (itimer-is-idle itimer) > - (set-itimer-recorded-run-time itimer (current-time))) > + (if (<= (itimer-recorded-run-time itimer) last-event-time) > + (let ((idle-time (- now (max last-event-time > + (itimer-activate-time itimer))))) > + (if (< idle-time (itimer-value itimer)) > + (setq next-wakeup > + (min next-wakeup > + (- (itimer-value itimer) idle-time))) > + (set-itimer-recorded-run-time > + itimer (itimer-time-float (current-time))) > + (setq dorun t))) > + (setq next-wakeup (min next-wakeup (itimer-value itimer)))) > + (if (> (set-itimer-value-internal itimer > + (max 0 (- (itimer-value itimer) time-elapsed))) > + 0) > + (setq next-wakeup (itimer-value itimer)) > + (setq dorun t))) > + (when dorun > ;; itimer has expired, we must call its function. > ;; protect our local vars from the itimer function. > ;; allow keyboard quit to occur, but catch and report it. > @@ -731,6 +728,7 @@ > (delete-itimer itimer) > (set-itimer-value-internal itimer (itimer-restart itimer)) > (setq next-wakeup (min next-wakeup (itimer-value itimer)))))) > + (setq dorun nil) > (setq itimers (cdr itimers))) > ;; make another sweep through the list to catch any timers > ;; that might have been added by timer functions above. > @@ -739,111 +737,25 @@ > (setq next-wakeup (min next-wakeup (itimer-value (car itimers))) > itimers (cdr itimers))) > ;; if user is viewing the timer list, update displayed info. > - (let ((b (get-buffer "*Itimer List*"))) > - (if (and b (get-buffer-window b)) > - (save-excursion > - (list-itimers)))) > + (when (and itimer-list-buffer (buffer-live-p itimer-list-buffer) > + (get-buffer-window itimer-list-buffer)) > + (setq next-wakeup (min itimer-list-update-interval next-wakeup)) > + (list-itimers)) > next-wakeup )) > > -(defun itimer-process-filter (process string) > - ;; If the itimer process dies and generates output while doing > - ;; so, we may be called before the process-sentinel. Sanity > - ;; check the output just in case... > - (if (not (string-match "^[0-9]" string)) > - (progn (message "itimer process gave odd output: %s" string) > - ;; it may be still alive and waiting for input > - (process-send-string itimer-process "3\n")) > - ;; if there are no active itimers, return quickly. > - (if itimer-list > - (let ((wakeup nil)) > - (unwind-protect > - (setq wakeup (itimer-run-expired-timers (string-to-int string))) > - (and (null wakeup) (process-send-string process "1\n"))) > - (setq itimer-next-wakeup wakeup)) > - (setq itimer-next-wakeup 600)) > - ;; tell itimer-process when to wakeup again > - (process-send-string itimer-process > - (concat (int-to-string itimer-next-wakeup) > - "\n")))) > - > -(defun itimer-process-sentinel (process message) > - (let ((inhibit-quit t)) > - (if (eq (process-status process) 'stop) > - (continue-process process) > - ;; not stopped, so it must have died. > - ;; cleanup first... > - (delete-process process) > - (setq itimer-process nil) > - ;; now, if there are any active itimers then we need to immediately > - ;; start another itimer process, otherwise we can wait until the next > - ;; start-itimer call, which will start one automatically. > - (if (null itimer-list) > - () > - ;; there may have been an error message in the echo area; > - ;; give the user at least a little time to read it. > - (sit-for 2) > - (message "itimer process %s... respawning." (substring message 0 -1)) > - (itimer-process-start))))) > - > -(defun itimer-process-start () > - (let ((inhibit-quit t) > - (process-connection-type nil)) > - (setq itimer-process (start-process "itimer" nil "itimer")) > - (process-kill-without-query itimer-process) > - (set-process-filter itimer-process 'itimer-process-filter) > - (set-process-sentinel itimer-process 'itimer-process-sentinel) > - ;; Tell itimer process to wake up quickly, so that a correct > - ;; wakeup time can be computed. Zero loses because of > - ;; underlying itimer implementations that use 0 to mean > - ;; `disable the itimer'. > - (setq itimer-next-wakeup itimer-short-interval) > - (process-send-string itimer-process > - (format "%s\n" itimer-next-wakeup)))) > - > -(defun itimer-process-wakeup () > - (interrupt-process itimer-process) > - (accept-process-output)) > - > (defun itimer-timer-start () > (let ((inhibit-quit t)) > (setq itimer-next-wakeup itimer-short-interval > - itimer-timer-last-wakeup (current-time) > + itimer-timer-last-wakeup (itimer-time-float (current-time)) > itimer-timer (add-timeout itimer-short-interval > 'itimer-timer-driver nil nil)))) > > -(defun itimer-disable-timeout (timeout) > - ;; Disgusting hack, but necessary because there is no other way > - ;; to remove a timer that has a restart value from while that > - ;; timer's function is being run. (FSF Emacs only.) > - (if (vectorp timeout) > - (aset timeout 4 nil)) > - (disable-timeout timeout)) > - > (defun itimer-timer-wakeup () > (let ((inhibit-quit t)) > - (itimer-disable-timeout itimer-timer) > + (disable-timeout itimer-timer) > (setq itimer-timer (add-timeout itimer-short-interval > 'itimer-timer-driver nil 5)))) > > -(defun itimer-time-difference (t1 t2) > - (let (usecs secs 65536-secs carry) > - (setq usecs (- (nth 2 t1) (nth 2 t2))) > - (if (< usecs 0) > - (setq carry 1 > - usecs (+ usecs 1000000)) > - (setq carry 0)) > - (setq secs (- (nth 1 t1) (nth 1 t2) carry)) > - (if (< secs 0) > - (setq carry 1 > - secs (+ secs 65536)) > - (setq carry 0)) > - (setq 65536-secs (- (nth 0 t1) (nth 0 t2) carry)) > - ;; loses for interval larger than the maximum signed Lisp integer. > - ;; can't really be helped. > - (+ (* 65536-secs 65536) > - secs > - (/ usecs (if (featurep 'lisp-float-type) 1e6 1000000))))) > - > (defun itimer-timer-driver (&rest ignored) > ;; inhibit quit because if the user quits at an inopportune > ;; time, the timer process won't be launched again and the > @@ -853,21 +765,11 @@ > (if (not itimer-inside-driver) > (let* ((inhibit-quit t) > (itimer-inside-driver t) > - (now (current-time)) > - (elapsed (itimer-time-difference now itimer-timer-last-wakeup)) > + (now (itimer-time-float (current-time))) > + (elapsed (- now itimer-timer-last-wakeup)) > (sleep nil)) > (setq itimer-timer-last-wakeup now > - sleep (itimer-run-expired-timers elapsed)) > - (itimer-disable-timeout itimer-timer) > + sleep (itimer-run-expired-timers elapsed now)) > + (disable-timeout itimer-timer) > (setq itimer-next-wakeup sleep > - itimer-timer (add-timeout sleep 'itimer-timer-driver nil 5))))) > - > -(defun itimer-driver-start () > - (if (fboundp 'add-timeout) > - (itimer-timer-start) > - (itimer-process-start))) > - > -(defun itimer-driver-wakeup () > - (if (fboundp 'add-timeout) > - (itimer-timer-wakeup) > - (itimer-process-wakeup))) > + itimer-timer (add-timeout sleep 'itimer-timer-driver nil 5))))) > \ No newline at end of file > > ------------------------------------------------------------------------ > Name: itimer.el > itimer.el Type: application/emacs-lisp > Encoding: 8bit > Description: Itimer 2.00 -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Thu Nov 18 22:50:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA14018 for xemacs-beta-out; Thu, 18 Nov 1999 22:50:05 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA14005 for ; Thu, 18 Nov 1999 22:49:58 -0500 Received: from 666.com (dialup001ip125.tus.azstarnet.com [169.197.12.125]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id UAA07358; Thu, 18 Nov 1999 20:46:39 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3834C7FB.5F5C8B3C@666.com> Date: Thu, 18 Nov 1999 20:46:03 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner CC: XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I say, put all the nt makefiles in the proper directories, not in nt. Windows is not a second-class citizen w.r.t. xemacs. Adrian Aichner wrote: > Hello Reviewers, > > while trying to improve makefile[1] support for Windows NT native I am > faced with this problem: > > ALL make rules for building XEmacs Windows NT native[2] are in > nt\xemacs.mak. > > However, @setfilename in man\*\*.texi are obviously relative to man\*, > not nt. > > Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info > target (just like on Unix) would be must superior. There is no danger > in clashing with Unix makefiles since they are always called Makefile. > > I would be willing to send in patches for 21.2 to make xemacs.mak > build recursively if any objections/problems can be resolved. > > Any objections? > > Regards, > > Adrian > > Footnotes: > [1] triggered by Martin's > > From: Martin Buchholz > > Subject: Martin makes man & Makefile makeover > > Message-ID: <14384.56980.560513.767776@lasker.666.com> > > [2] Building in lisp, src, man, lib-src -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Thu Nov 18 22:55:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA14203 for xemacs-beta-out; Thu, 18 Nov 1999 22:55:59 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA14199 for ; Thu, 18 Nov 1999 22:55:57 -0500 Received: from 666.com (dialup001ip125.tus.azstarnet.com [169.197.12.125]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id UAA09772; Thu, 18 Nov 1999 20:55:46 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3834CA1E.8614E00D@666.com> Date: Thu, 18 Nov 1999 20:55:10 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Oscar Figueiredo CC: xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> <9t9bt8s9q9k.fsf@mraz.iskon.hr> <9t9hfik3pjj.fsf@mraz.iskon.hr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Again, please please follow standard conventions. The lower-level functions should be called ldap-add, ldap-delete, etc. (Or even better, use ldap-put, ldap-remove.) No -internal, -basic-, -1, whatever. These are parallel to the database routines. I'm still not completely convinced we need convenience wrappers. The db interface doesn't have them, for example. If you want them, though, call them something like create-ldap-entry, or similar names -- i.e. longer, to convey that they do more than you might expect. Also, the message displaying should be optional, and not the default. ben Oscar Figueiredo wrote: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> This is good design, except that if Lisp programmers are ever > Hrvoje> expected to use the lower-level API, you should remove the > Hrvoje> "-internal" suffix and choose better names for functions. > > Fine I guess I simply misjudged the meaning of "-internal" in function names. > I can rename the "-internal" functions to something else. What's your > suggestion to add the meaning "you're using stones to make fire, use the > lighter function instead otherwise if you're not really skilful you're going to > crush your fingers" to a function ? Would names like ldap-basic-add, > ldap-basic-search, ldap-basic-delete be good enough ? > > Oscar > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Thu Nov 18 23:03:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA14505 for xemacs-beta-out; Thu, 18 Nov 1999 23:03:02 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA14501 for ; Thu, 18 Nov 1999 23:03:01 -0500 Received: from 666.com (dialup001ip125.tus.azstarnet.com [169.197.12.125]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id VAA11666; Thu, 18 Nov 1999 21:02:52 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3834CBC9.F0FAE528@666.com> Date: Thu, 18 Nov 1999 21:02:17 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stephen J. Turnbull" CC: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: OK, in summation: 1. C-q is a user-level function and should do whatever makes the most sense. 2. int-char is a low-level primitive and should never depend on high-level settings like language environment. 3. Everything you can do with int-char can and should be done with make-char -- representation-independent, much less likelihood of bugs, etc. Therefore int-char should be removed. 4. Note that CLTL2 also removes int-char. 5. Your statement > In one-byte buffers (either Olivier's 1/2/4 extension or `xemacs -font > *-iso8859-2') it implicitly will have dependence whatever you say. is confusing internal and external representations. ben "Stephen J. Turnbull" wrote: > Can somebody give a bunch of examples where using integers as > characters is useful? For that matter, where they are actually used? > Ben said "backward compatibility," but I haven't seen this used, and I > don't really know how to grep for it. I have grepped for int-char, > int-to-char, char-int, and char-to-int and they're pretty rare in the > core and package code (2/3 of it) that I have. > > The only one that I ever use is the C-q hack for inserting characters > by code value at the keyboard, and that could arguably (and in > Japanese invariably is) delegated to an input method which would know > about language environment (and return a true character). > > For iterating over a character set in "natural" order, only ASCII > satisfies the requirement of having one, and even that's shaky. AFAIK > the Swedes and the Norwegians, or is it the Danes, disagree on > ordering the _letters_ in ISO-8859-1 character set. This really > should be table-driven, and will have to be for everything except > ASCII and ISO-8859-1 if we go to a Unicode internal representation. > > We already have primitives for efficient case conversion and the like. > > The only example I can think of offhand where you would really really > want the facility is to iterate over a code space where you don't know > which points are legal characters. Eg, to print out tables of fonts. > Pretty specialized. And this can be done through make-char, anyway. > > According to CLtL1, the main portable use for char-int is for hashing. > But that doesn't square with the kind of usage we've been talking > about (in loops and the like). > > What else am I missing? > > Ben's desiderata have some problems. > > >>>>> "Ben" == Ben Wing writes: > > Ben> Either int-char should be the mirror opposite of char-int > Ben> (i.e. accept all legal char integers), or it should be > Ben> removed entirely. > > OK. I agree with this. > > Ben> int-char should *never* have any dependence on the language > Ben> environment. > > In one-byte buffers (either Olivier's 1/2/4 extension or `xemacs -font > *-iso8859-2') it implicitly will have dependence whatever you say. > Even without Mule, people can always use external encoders to change > raw ISO-8859-2 to ISO-2022 (not that anybody sane ever would, OK, > Hrvoje?). Then the two files will be interpreted differently in a > Latin-1 locale Mule; the ISO-8859-2 file will be recognized as > ISO-8859-1, and the ISO-2022 file will be internally interpreted as > ISO-8859-2. > > The point is that people normally assume that int-char should accept > their "natural" integer to character map. For Americans, that's > ASCII, for Germans, that's ISO-8859-1, for Croatians, that's > ISO-8859-2. And it works "correctly" in a no-mule XEmacs with `-font > *-iso8859-2'! Japanese usually use ku-ten or JIS, and there's a > "natural" map from byte-sized integer pairs to shorts, but it's full > of holes. So language environments don't agree on what a legal char > integer is, and where they do (eg, ISO-8859-1 and ISO-8859-2), they > don't agree on the map. To satisfy your dictum (with which I agree, > but I take to mean we should get rid of these functions) we can take > the intersection where they agree > > ==> legal char integers == ASCII > > which is what I prefer, or pick something arbitrary and efficient > > ==> char-int returns the internal representation > > which I really hate, or something else. Suggestions? > > Ben> I don't think C-q should either. If Hrvoje wants to insert > Ben> Latin-2 characters by number, then make C-u C-q work so that > Ben> it also prompts for a character set, with a default chosen > Ben> from the language environment. > > And restrict this to ASCII? Or assume Latin-1 in GR if there is no > prefix argument? > > This is a useful feature. C-q currently inserts Latin-2 characters > for Hrvoje in no-mule XEmacs (stretching the point only a little); I > think it should continue to do so in Mule. This really is an input > method issue, not a keyboard issue. In XEmacs, inserting an integer > into a buffer has no meaning. Users insert characters. So this is a > completely different issue from the programming API, and should not be > considered analogous. > > Maybe we could have C-q insert according to the Unicode standard, and > treat C-u C-q as part of the input method. But I think most users > would prefer to have C-q insert according to their locale-standard > tables, and select Unicode explicitly using the C-u C-q idiom. In > fact (again this points to the input method idea), Japanese users > would probably like to have the alternatives of using kuten (pairs > from 1--94 x 1--94) or JIS (pairs from 0x21--0x7E x 0x21--0x7E) as > options since both indexing systems are common in tables. > > -- > University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN > Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 > __________________________________________________________________________ > __________________________________________________________________________ > What are those two straight lines for? "Free software rules." -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Fri Nov 19 01:08:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA18455 for xemacs-beta-out; Fri, 19 Nov 1999 01:08:20 -0500 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA18428; Fri, 19 Nov 1999 01:07:04 -0500 Message-Id: <4.2.2.19991119010539.00c6b4c0@mailhost.arbortext.com> X-Sender: mta@mailhost.arbortext.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 Nov 1999 01:08:51 -0500 To: Adrian Aichner From: Mike Alexander Subject: Re: "Forked child base mismatch" using MKS Toolkit shell Cc: Adrian Aichner , Andy Piper , acs@xemacs.org, XEmacs NT List , xemacs-beta@xemacs.org In-Reply-To: References: <3.0.5.32.19991102100751.00ab8430@london.beasys.com> <4.2.1.19991103233925.00bff280@mailhost.arbortext.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 04:54 AM 11/4/99 , Adrian Aichner wrote: > >>>>> "Mike" == Mike Alexander writes: > > Mike> Several people have tried MKS Toolkit shell with this patch > Mike> and found that it works fine, so I don't think that is the > Mike> issue right now. A more interesting question is whether the > Mike> patch interacts badly with your process patch. I looked at > Mike> what you did and it looks like they should be ok together, > Mike> and independent of each other, but I haven't actually tried > Mike> them together. > >Hello Mike, > >please do if you can, now that XEmacs-21.1.8 (including my >call-process patch) is available. > >Let me know if you find problems with my patch. I tried the two patches together and they both seem to work fine. I can't see any reason they shouldn't both be included. Mike Alexander From owner-xemacs-beta@xemacs.org Fri Nov 19 03:27:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA22100 for xemacs-beta-out; Fri, 19 Nov 1999 03:27:21 -0500 Received: from mailhost.telia-resellers.co.uk (mailhost.telia-resellers.co.uk [195.12.224.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA22097 for ; Fri, 19 Nov 1999 03:27:16 -0500 Received: from lonexs2.telia.co.uk (unverified) by mailhost.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 19 Nov 1999 08:27:39 +0000 Received: by lonexs2.telia.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Nov 1999 08:22:30 -0000 Message-Id: From: Ian MacKinnon To: XEmacs beta list Subject: RE: Redisplay loss on frame resize [21.2.20,cygwin32] possibly re lated to Re: 10% redisplay speed up... Date: Fri, 19 Nov 1999 08:23:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ditto with Fabrice's NT 21.2.20 --- Ian > -----Original Message----- > From: Samuel Mikes [mailto:smikes@alumni.hmc.edu] > Sent: 18 November 1999 17:44 > To: XEmacs beta list > Cc: Jan Vroonhof > Subject: Redisplay loss on frame resize [21.2.20,cygwin32] possibly > related to Re: 10% redisplay speed up... > > > Folks, > > With the latest from CVS, my XEmacs does not redraw the frame after > a frame resize operation but waits for another event (e.g., > mouse click, > keystroke). The upshot is that if I shrink the window, I see a frame > with no modeline or scrollbars. It's purely a visual bug and easily > worked around. > > ************************************************************* NOTE: The information in this email is confidential and may be legally privileged. If you are not the intended recipient, you must not read, use or disseminate that information. Any opinions or advice contained in this email are not necessarily those of Telia UK Ltd. Although this email and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Telia UK Ltd for any loss or damage arising in any way from receipt or use thereof. www.telia.co.uk ************************************************************* From owner-xemacs-beta@xemacs.org Fri Nov 19 03:42:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA22633 for xemacs-beta-out; Fri, 19 Nov 1999 03:42:23 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA22628 for ; Fri, 19 Nov 1999 03:42:19 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id JAA11430 for ; Fri, 19 Nov 1999 09:42:18 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id JAA10228; Fri, 19 Nov 1999 09:42:17 +0100 (MET) To: xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> <38324099.B2EED3F2@666.com> <87g0y4ww70.fsf@bittersweet.sysc.pdx.edu> <86r9ho8u6h.fsf@megalith.bp.aventail.com> <9t9bt8s9q9k.fsf@mraz.iskon.hr> <9t9hfik3pjj.fsf@mraz.iskon.hr> <3834CA1E.8614E00D@666.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Fri_Nov_19_09:41:14_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 19 Nov 1999 09:42:17 +0100 In-Reply-To: Ben Wing's message of "Thu, 18 Nov 1999 20:55:10 -0700" Message-ID: Lines: 48 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Fri_Nov_19_09:41:14_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Ben" == Ben Wing writes: Ben> Again, please please follow standard conventions. Ben> The lower-level functions should be called ldap-add, ldap-delete, etc. (Or even Ben> better, use ldap-put, ldap-remove.) No -internal, -basic-, -1, whatever. These are Ben> parallel to the database routines. Ben> I'm still not completely convinced we need convenience wrappers. The db interface Ben> doesn't have them, for example. IIRC someone said on that list nobody actually uses the db interface. That might explain why we don't need those wrappers. LDAP on the other hand is already used by three packages. Ben> If you want them, though, call them something like create-ldap-entry, or Ben> similar names -- i.e. longer, to convey that they do more than you might Ben> expect. Though I'm not convinced this renaming is good, I'll send the corresponding patch, you probably know better than I what's good for XEmacs. I still think someone used to LDAP will find its way more easily through the current high-level API which reminds the traditional LDAP command-line tools rather than through the naming you propose. Someone not used to LDAP won't care that much. Ben> Also, the message displaying should be optional, and not the default. I agree. Oscar --pgp-sign-Multipart_Fri_Nov_19_09:41:14_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBODUNUJ7CaiYEgqPZAQEipQIArfuN2jZCouahwyh05UthYFjpBdk8zg4s wPi1X+nrYkeLlajQW8KZXmXlezUL63rVBrDCilGYFIasQ8NgNA1kVQ== =ScJR -----END PGP MESSAGE----- --pgp-sign-Multipart_Fri_Nov_19_09:41:14_1999-1-- From owner-xemacs-beta@xemacs.org Fri Nov 19 03:55:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA23253 for xemacs-beta-out; Fri, 19 Nov 1999 03:55:23 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA23241; Fri, 19 Nov 1999 03:55:18 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11ojp6-0001dV-00; Fri, 19 Nov 1999 09:55:16 +0100 To: XEmacs Review , XEmacs beta list Subject: Re: itimer rewrite References: <3834C5CA.DC2C9DF7@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 19 Nov 1999 09:55:16 +0100 In-Reply-To: Ben Wing's message of "Thu, 18 Nov 1999 20:36:44 -0700" Message-ID: <9t94sei3lor.fsf@mraz.iskon.hr> Lines: 8 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Could you possibly rewrite this a bit so as to use defstruct? Although I know Kyle dislikes CL, I was going to propose the same thing. If itimer.el is modernized and if the code is rewritten to use vectors, I see no reason not to reuse the existing (and well-working) functionality. From owner-xemacs-beta@xemacs.org Fri Nov 19 04:02:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA23703 for xemacs-beta-out; Fri, 19 Nov 1999 04:02:51 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA23700 for ; Fri, 19 Nov 1999 04:02:48 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id EAA01822; Fri, 19 Nov 1999 04:09:49 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-4.ecf.teradyne.com [131.101.192.124]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id KAA05770; Fri, 19 Nov 1999 10:02:31 +0100 (MET) To: Ben Wing Cc: Adrian Aichner , XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? References: <3834C7FB.5F5C8B3C@666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 10:01:08 +0100 In-Reply-To: Ben Wing's message of "Thu, 18 Nov 1999 20:46:03 -0700" Message-ID: Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Ben" == Ben Wing writes: Ben> I say, put all the nt makefiles in the proper directories, Ben> not in nt. Windows is not a second-class citizen Ben> w.r.t. xemacs. Hurrah! How about a suggestion by Paul Krause to rename xemacs.mak to someting meaningful? I'd suggest "windows.mak" as the name for a native windows makefile for NMAKE (MS's make, ahem, "invention"), regardless of where it is in the xemacs source tree. The question remains whether it will be able to handle NT, 95, 98 always. The xemacs95.mak of 21.1 is gone in 21.2 so it seems feasible. TIA for any suggestions, Adrian From owner-xemacs-beta@xemacs.org Fri Nov 19 05:20:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA25811 for xemacs-beta-out; Fri, 19 Nov 1999 05:20:10 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA25808 for ; Fri, 19 Nov 1999 05:20:08 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id CAA20922; Fri, 19 Nov 1999 02:19:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14389.9236.882408.759879@lasker.666.com> Date: Fri, 19 Nov 1999 02:19:00 -0800 (PST) From: Martin Buchholz To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: Martin makes man & Makefile makeover In-Reply-To: References: <14384.56980.560513.767776@lasker.666.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: >>>>> "APA" == Adrian Aichner writes: >>>>> "Martin" == Martin Buchholz writes: Martin> - Make sources compatible with makeinfo 4.0 *and* 3.12. APA> Hello Martin, APA> trying to generate info.info using texinfo-3.12 on Windows NT I get APA> this error: APA> Hi Martin, APA> All files process fine with texinfo-4.0 on Windows NT: APA> cd d:\tmp\21.2\xemacs\nt\ APA> d:\tmp\texinfo-4.0\makeinfo\makeinfo.exe --version APA> Compilation started at Fri Nov 19 01:35:29 1999 +0100 (W. Europe Standard Time) APA> makeinfo (GNU texinfo) 4.0 APA> Copyright (C) 1999 Free Software Foundation, Inc. APA> There is NO warranty. You may redistribute this software APA> under the terms of the GNU General Public License. APA> For more information about these matters, see the files named COPYING. APA> Compilation finished at Fri Nov 19 01:35:29 APA> So obviously, contrary to what the ChangeLog says, not all texi files APA> are compliant with makeinfo 1.68 after your patch. xemacs.mak uses the built-in lisp formatter texinfmt.el, not makeinfo. For the record, even the texinfmt.el in a 20.5 GNU Emacs pretest fails with info.texi in the same manner. So currently texinfmt.el is broken for processing standard info files. Someone could take on the project of syncing the texinfo stuff from GNU Emacs 20.5 (release should be imminent) and then fixing it so that all of the info files can be formatted by it. Martin From owner-xemacs-beta@xemacs.org Fri Nov 19 05:46:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA26746 for xemacs-beta-out; Fri, 19 Nov 1999 05:46:22 -0500 Received: from mailgrd.orion.no (postkontor.orion.no [194.143.1.101]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA26740 for ; Fri, 19 Nov 1999 05:46:18 -0500 Date: Fri, 19 Nov 1999 05:46:18 -0500 Received: from postkontor.orion.no (unverified) by mailgrd.orion.no (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 19 Nov 1999 11:35:04 +0100 Message-Id: Received: from knut.orion.no by postkontor.orion.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id VZGMDLTG; Fri, 19 Nov 1999 11:41:57 +0100 From: "Knut-Håvard Aksnes" To: xemacs-beta@xemacs.org Subject: Core dump on linux Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta20) "Yoko" [Lucid] (i686-pc-linux, Mule) of Thu Nov 18 1999 on knut.orion.no configured using `configure --with-pop --with-mule --with-xfs' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: System went down with Fatal error(11) after I pressed the Mail button on the toolbar. Recent keystrokes: button1 button1up misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading gnuserv...done Loading gnuserv... Loading /home/knut/.recent-files.el...done Loading /home/knut/.recent-files.el... Loading disp-table...done Loading disp-table... Loading cus-face...done Stack trace: (gdb) where #0 0x402df111 in __kill () from /lib/libc.so.6 #1 0x808ee24 in fatal_error_signal (sig=11) at emacs.c:276 #2 0xbfffeb4c in ?? () #3 0x81e7fba in XawTabsSetHighlight (t=0x8c0e798, w=0x877ae18) at xlwtabs.c:1283 #4 0x81e76d4 in XawTabsSetTop (w=0x877ae18, callCallbacks=1) at xlwtabs.c:1262 #5 0x81e83d1 in TabsSelect (w=0x8c0e798, event=0xbffff200, params=0x0, num_params=0x40152bf4) at xlwtabs.c:1047 #6 0x401444c4 in HandleActions () from /usr/X11R6/lib/libXt.so.6 #7 0x401449a6 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.6 #8 0x40144ee1 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x401202f7 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x40120ead in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6 #11 0x40121173 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #12 0x4012ca8f in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #13 0x81b07d0 in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:2631 #14 0x80d7fce in detect_input_pending () at event-stream.c:942 #15 0x816a157 in redisplay_device (d=0x83267b8) at redisplay.c:6410 #16 0x816a596 in redisplay_without_hooks () at redisplay.c:6517 #17 0x81714ba in redisplay () at redisplay.c:6574 #18 0x80d9d1f in Fnext_event (event=142231476, prompt=136927124) at event-stream.c:2236 #19 0x80725d2 in Fcommand_loop_1 () at cmdloop.c:566 ---Type to continue, or q to quit--- #20 0x807287d in command_loop_1 (dummy=136927124) at cmdloop.c:490 #21 0x809132f in condition_case_1 (handlers=136927220, bfun=0x8072834 , barg=136927124, hfun=0x80728f0 , harg=136927124) at eval.c:1630 #22 0x80729e7 in command_loop_2 (dummy=136927124) at cmdloop.c:252 #23 0x809872c in internal_catch (tag=137001340, func=0x80729ac , arg=136927124, threw=0x0) at eval.c:1305 #24 0x8071dee in initial_command_loop (load_me=136927124) at cmdloop.c:301 #25 0x808d07f in xemacs_21_2_b20_i686_pc_linux (argc=1, argv=0xbffff824, envp=0xbffff82c, restart=0) at emacs.c:1873 #26 0x808f050 in voodoo_free_hook (mem=0x1) at emacs.c:2298 #27 0x402d8cb3 in __libc_start_main (main=0x808ef40
, argc=1, argv=0xbffff824, init=0x804e41c <_init>, fini=0x81ea714 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff81c) at ../sysdeps/generic/libc-start.c:78 From owner-xemacs-beta@xemacs.org Fri Nov 19 06:01:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA27296 for xemacs-beta-out; Fri, 19 Nov 1999 06:01:30 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA27293; Fri, 19 Nov 1999 06:01:28 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id GAA08434; Fri, 19 Nov 1999 06:08:36 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id MAA05943; Fri, 19 Nov 1999 12:01:17 +0100 (MET) To: martin@xemacs.org Cc: Adrian Aichner , xemacs-beta@xemacs.org Subject: Re: Martin makes man & Makefile makeover References: <14384.56980.560513.767776@lasker.666.com> <14389.9236.882408.759879@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 11:59:38 +0100 In-Reply-To: Martin Buchholz's message of "Fri, 19 Nov 1999 02:19:00 -0800 (PST)" Message-ID: Lines: 40 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Hi Martin! Martin> xemacs.mak uses the built-in lisp formatter texinfmt.el, Martin> not makeinfo. I sure know because I put it in and made it work! :-) I added external makeinfo support in following patch to xemacs-patches. > From: Adrian Aichner > Subject: 21.2 xemacs.mak: generate info with texinfo package or makeinfo.exe > To: xemacs-patches@xemacs.org > Date: 19 Nov 1999 03:20:10 +0100 > References: <14384.56980.560513.767776@lasker.666.com> > > <14387.43590.807635.654577@lasker.666.com> > Message-ID: Hacked on the texinfo package a while back too to make this work. Martin> For the record, even the texinfmt.el in a 20.5 GNU Emacs Martin> pretest fails with info.texi in the same manner. So Martin> currently texinfmt.el is broken for processing standard Martin> info files. Someone could take on the project of syncing Martin> the texinfo stuff from GNU Emacs 20.5 (release should be Martin> imminent) and then fixing it so that all of the info files Martin> can be formatted by it. Well, I have run all your texi files past c:\temp\texinfo-3.12\makeinfo\makeinfo.exe. See my previous mails for what fails. I may take a look at them. As it stands now, it is not true that all texi files are conformant to texinfo-3.12. Best regards, Adrian Martin> Martin From owner-xemacs-beta@xemacs.org Fri Nov 19 06:03:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA27325 for xemacs-beta-out; Fri, 19 Nov 1999 06:03:01 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA27320; Fri, 19 Nov 1999 06:02:57 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA17765; Fri, 19 Nov 1999 12:02:55 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004LX; Fri Nov 19 12:02:50 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA16232; Fri, 19 Nov 1999 12:02:49 +0100 To: Ben Wing Cc: XEmacs Review , kyle_jones@wonderworks.com, XEmacs beta list Subject: Re: itimer rewrite References: <3834C5CA.DC2C9DF7@666.com> From: Jan Vroonhof Date: 19 Nov 1999 12:02:48 +0100 In-Reply-To: Ben Wing's message of "Thu, 18 Nov 1999 20:36:44 -0700" Message-ID: Lines: 15 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Could you possibly rewrite this a bit so as to use defstruct? cl is > now a standard part of XEmacs so there's absolutely no point in > continuing to use vectors for structs. I thought about that. But if I interpret the defstruct macro correctly that generates functions that cannot be inlined and do redundant type checks. I don't want those in the inner loop. I would love to be proven wrong though. Jan From owner-xemacs-beta@xemacs.org Fri Nov 19 06:09:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA27534 for xemacs-beta-out; Fri, 19 Nov 1999 06:09:30 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA27526 for ; Fri, 19 Nov 1999 06:09:28 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA17880; Fri, 19 Nov 1999 12:09:26 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004NJ; Fri Nov 19 12:09:19 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA16234; Fri, 19 Nov 1999 12:09:19 +0100 To: Ben Wing Cc: Oscar Figueiredo , xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> Date: 19 Nov 1999 12:09:19 +0100 In-Reply-To: Ben Wing's message of "Thu, 18 Nov 1999 20:55:10 -0700" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Again, please please follow standard conventions. Huh? The standard convention is to use -internal for C level functions that are not supposed to be used directly. I still cannot see your point. Jan From owner-xemacs-beta@xemacs.org Fri Nov 19 07:38:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA30019 for xemacs-beta-out; Fri, 19 Nov 1999 07:38:28 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id HAA30013 for ; Fri, 19 Nov 1999 07:38:25 -0500 Received: (qmail 10543 invoked from network); 19 Nov 1999 12:37:04 -0000 Received: from usrpri2-11.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.76) by biff.kiva.net with SMTP; 19 Nov 1999 12:37:04 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id HAA28698; Fri, 19 Nov 1999 07:39:19 -0500 To: Jan Vroonhof Cc: Ben Wing , Oscar Figueiredo , xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes X-Now-Listening-To: Beastie Boys - Root Down (LP) References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Ben Wing writes: > > > Again, please please follow standard conventions. > > Huh? The standard convention is to use -internal for C level functions > that are not supposed to be used directly. But these SHOULD be used directly in certain circumstances (long-lived LDAP connections, multiple operations (like search, add, modify, etc). -bp From owner-xemacs-beta@xemacs.org Fri Nov 19 07:53:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA30388 for xemacs-beta-out; Fri, 19 Nov 1999 07:53:10 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA30384 for ; Fri, 19 Nov 1999 07:53:05 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11onXD-0004GX-00 for ; Fri, 19 Nov 1999 13:53:03 +0100 To: XEmacs Beta List Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: <382F4C0A.2949CB1A@666.com> <86yac04mco.fsf@megalith.bp.aventail.com> <14383.35989.608403.789328@turnbull.sk.tsukuba.ac.jp> <863du89fud.fsf@megalith.bp.aventail.com> <9t9u2mn7vta.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 19 Nov 1999 13:53:03 +0100 In-Reply-To: Jan Vroonhof's message of "19 Nov 1999 12:09:19 +0100" Message-ID: <9t9aeoaej80.fsf@mraz.iskon.hr> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Ben Wing writes: > > > Again, please please follow standard conventions. > > Huh? The standard convention is to use -internal for C level > functions that are not supposed to be used directly. But if I understand Oscar correctly, the users who want the lower-level functionality *are* supposed to use the C functions. So they shouldn't be called "-internal". The -internal stuff is something you *never* ought to want to use. From owner-xemacs-beta@xemacs.org Fri Nov 19 08:06:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA30748 for xemacs-beta-out; Fri, 19 Nov 1999 08:06:23 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA30738; Fri, 19 Nov 1999 08:06:18 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11onjs-0004H1-00; Fri, 19 Nov 1999 14:06:08 +0100 To: Jan Vroonhof Cc: Ben Wing , XEmacs Review , kyle_jones@wonderworks.com, XEmacs beta list Subject: Re: itimer rewrite References: <3834C5CA.DC2C9DF7@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 19 Nov 1999 14:06:08 +0100 In-Reply-To: Jan Vroonhof's message of "19 Nov 1999 12:02:48 +0100" Message-ID: <9t94seieim7.fsf@mraz.iskon.hr> Lines: 58 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Ben Wing writes: > > > Could you possibly rewrite this a bit so as to use defstruct? cl is > > now a standard part of XEmacs so there's absolutely no point in > > continuing to use vectors for structs. > > I thought about that. But if I interpret the defstruct macro > correctly that generates functions that cannot be inlined and do > redundant type checks. They can and they don't. Accessors like `person-name' normally check their arguments (effectively using `person-p') and signal an error if the argument is the wrong type. This check is affected by `(optimize (safety ...))' declarations. Safety level 1, the default, uses a somewhat optimized check that will detect all incorrect arguments, but may use an uninformative error message (e.g., "expected a vector" instead of "expected a `person'"). Safety level 0 omits all checks except as provided by the underlying `aref' call; safety levels 2 and 3 do rigorous checking that will always print a descriptive error message for incorrect inputs. Test it like this. Create a file, say x.el, with the following contents: (proclaim '(optimize (speed 3) (safety 0))) (defstruct (foo) (bar nil) (count 0)) (defun test (x) (foo-count x)) Byte-compile it and load-file x.elc. Then try: (disassemble 'test) byte code for test: args: (x) 0 varref x 1 constant 2 2 aref 3 return So foo-count is inlined and there are no safety checks. Note that #'foo-count is still a regular function, not a macro, meaning you can feed it to #'mapcar etc. But when you *compile* the stuff, the CL additions to the compiler do the right thing. cl.el is smarter than you think. > I would love to be proven wrong though. Good enough? :-) From owner-xemacs-beta@xemacs.org Fri Nov 19 09:18:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA00590 for xemacs-beta-out; Fri, 19 Nov 1999 09:18:40 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id JAA00587 for ; Fri, 19 Nov 1999 09:18:37 -0500 Received: (qmail 27988 invoked from network); 19 Nov 1999 14:17:21 -0000 Received: from usrpri2-11.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.76) by biff.kiva.net with SMTP; 19 Nov 1999 14:17:21 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id JAA30193; Fri, 19 Nov 1999 09:19:36 -0500 To: Oscar Figueiredo Cc: xemacs-beta@xemacs.org Subject: Re: [21.2] LDAP add and delete functions + interrupt fixes References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 41 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > >>>>> "Ben" == Ben Wing writes: > > Ben> Again, please please follow standard conventions. The lower-level > Ben> functions should be called ldap-add, ldap-delete, etc. (Or even > Ben> better, use ldap-put, ldap-remove.) No -internal, -basic-, -1, > Ben> whatever. These are parallel to the database routines. > > Ben> I'm still not completely convinced we need convenience wrappers. > Ben> The db interface doesn't have them, for example. > > IIRC someone said on that list nobody actually uses the db interface. But I was proved wrong. :) > That might explain why we don't need those wrappers. LDAP on the other > hand is already used by three packages. > > Ben> If you want them, though, call them something like > Ben> create-ldap-entry, or similar names -- i.e. longer, to convey that > Ben> they do more than you might expect. > > Though I'm not convinced this renaming is good, I'll send the > corresponding patch, you probably know better than I what's good for > XEmacs. I still think someone used to LDAP will find its way more easily > through the current high-level API which reminds the traditional LDAP > command-line tools rather than through the naming you propose. Someone > not used to LDAP won't care that much. I would agree that your high-level interface is akin to the command line tools, and the ldap-*-internal routines are much closer to the actual C LDAP API. And since we are using a 'real' programming language (just assume for the moment :) we should encourage using the API-level functions, which is what most LDAP programmers will be used to. I'd say there are a lot less people writing shell scripts around the 'ldapmodify' and 'ldapsearch' commandline tools, especially since there are 'real' Perl modules for ldap, etc. -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 19 13:03:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA08230 for xemacs-beta-out; Fri, 19 Nov 1999 13:03:37 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA08226; Fri, 19 Nov 1999 13:03:33 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA09819; Fri, 19 Nov 1999 19:03:18 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002PP; Fri Nov 19 19:03:12 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA17423; Fri, 19 Nov 1999 19:03:11 +0100 To: Hrvoje Niksic Cc: Ben Wing , XEmacs Review , kyle_jones@wonderworks.com, XEmacs beta list Subject: Re: itimer rewrite References: <3834C5CA.DC2C9DF7@666.com> <9t94seieim7.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 19 Nov 1999 19:03:11 +0100 In-Reply-To: Hrvoje Niksic's message of "19 Nov 1999 14:06:08 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > cl.el is smarter than you think. I really have to read the documentation. But can I switch the safety of just for the inner-loops? > > > I would love to be proven wrong though. > > Good enough? :-) Yes. But this time I would love to have Kyle's permission first. Jan From owner-xemacs-beta@xemacs.org Fri Nov 19 13:21:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA08843 for xemacs-beta-out; Fri, 19 Nov 1999 13:21:19 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA08827; Fri, 19 Nov 1999 13:21:14 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11oseX-0004NP-00; Fri, 19 Nov 1999 19:20:57 +0100 To: Jan Vroonhof Cc: Ben Wing , XEmacs Review , kyle_jones@wonderworks.com, XEmacs beta list Subject: Re: itimer rewrite References: <3834C5CA.DC2C9DF7@666.com> <9t94seieim7.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 19 Nov 1999 19:20:57 +0100 In-Reply-To: Jan Vroonhof's message of "19 Nov 1999 19:03:11 +0100" Message-ID: <9t9emdm9wc6.fsf@mraz.iskon.hr> Lines: 20 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Hrvoje Niksic writes: > > > cl.el is smarter than you think. > > I really have to read the documentation. But can I switch the safety > of just for the inner-loops? I think you can, but I'm not sure. See `declaim' docs. > > > I would love to be proven wrong though. > > > > Good enough? :-) > > Yes. But this time I would love to have Kyle's permission first. So would I. I argue for defstruct only if Kyle agrees to modernize itimer.el at all. The CL interfaces are pretty nice, but make little sense in an extremely portable Lisp application. From owner-xemacs-beta@xemacs.org Fri Nov 19 16:38:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA14947 for xemacs-beta-out; Fri, 19 Nov 1999 16:38:25 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA14939 for ; Fri, 19 Nov 1999 16:38:20 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id QAA19824; Fri, 19 Nov 1999 16:44:55 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-1.ecf.teradyne.com [131.101.192.121]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id WAA08258; Fri, 19 Nov 1999 22:37:36 +0100 (MET) To: Karl Berry Cc: XEmacs Beta List Subject: @ifnottex: texinfo 3.12, 4.0, and XEamcs 21.2 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 19 Nov 1999 22:35:40 +0100 Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello Karl, the latest XEmacs 21.2-b20 CVS sources have been synched with texinfo 4.0. This surfaced the problem that the `texinfo' package of XEmacs does not support the @ifnottex .. @end ifnottex construct. Further investigation shows that texinfo-3.12 has problems with this construct also. Was this a bug in 3.12? Sources indicate that it should support the construct. makeinfo-4.0 has not problems translating texinfo.txi and info.texi. Thanks for any insight into the issue. d:\tmp\texinfo-4.0\ChangeLog: Sun Nov 29 17:12:35 1998 Karl Berry * doc/texinfo.txi: Use @ifnottex rather than @ifinfo for @top. (makeinfo top): document this. * doc/info-stnd.texi, * doc/info.texi: Use @ifnottex rather than @ifinfo for @top. Best regards, Adrian From owner-xemacs-beta@xemacs.org Fri Nov 19 18:09:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA17924 for xemacs-beta-out; Fri, 19 Nov 1999 18:09:26 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA17921 for ; Fri, 19 Nov 1999 18:09:21 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id PAA21479; Fri, 19 Nov 1999 15:08:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14389.55379.594174.575910@lasker.666.com> Date: Fri, 19 Nov 1999 15:08:03 -0800 (PST) From: Martin Buchholz To: Adrian Aichner Cc: Karl Berry , XEmacs Beta List Subject: Re: @ifnottex: texinfo 3.12, 4.0, and XEamcs 21.2 In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> Further investigation shows that texinfo-3.12 has problems with this APA> construct also. Was this a bug in 3.12? Sources indicate that it APA> should support the construct. I did not have the same experience as Adrian, but I am on Linux using makeinfo 3.12f (and 4.0) and Adrian is on Windows NT. For me makeinfo 3.12f works fine. Shell transcript follows. $ rm -f info/*.info*; (PATH=/usr/bin:$PATH; make info); cd /home/martin/x/ws/fiddle/man && make info make[1]: Entering directory `/home/martin/x/ws/fiddle/man' makeinfo -o ../info/cl.info cl.texi makeinfo -o ../info/custom.info custom.texi makeinfo -o ../info/emodules.info emodules.texi makeinfo -o ../info/external-widget.info external-widget.texi makeinfo -o ../info/info.info info.texi makeinfo -P lispref -o ../info/lispref.info lispref/lispref.texi makeinfo -P internals -o ../info/internals.info internals/internals.texi makeinfo -P new-users-guide -o ../info/new-users-guide.info new-users-guide/new-users-guide.texi makeinfo -o ../info/standards.info standards.texi makeinfo -o ../info/term.info term.texi makeinfo -o ../info/termcap.info termcap.texi makeinfo -o ../info/texinfo.info texinfo.texi makeinfo -o ../info/widget.info widget.texi makeinfo -P xemacs -o ../info/xemacs.info xemacs/xemacs.texi makeinfo -o ../info/xemacs-faq.info xemacs-faq.texi make[1]: Leaving directory `/home/martin/x/ws/fiddle/man' ( PATH=/usr/bin:$PATH ; make info ) 9.79s user 0.70s system 99% cpu 10.492 total $ rm -f info/*.info*; (make info); cd /home/martin/x/ws/fiddle/man && make info make[1]: Entering directory `/home/martin/x/ws/fiddle/man' makeinfo -o ../info/cl.info cl.texi makeinfo -o ../info/custom.info custom.texi makeinfo -o ../info/emodules.info emodules.texi makeinfo -o ../info/external-widget.info external-widget.texi makeinfo -o ../info/info.info info.texi makeinfo -P lispref -o ../info/lispref.info lispref/lispref.texi makeinfo -P internals -o ../info/internals.info internals/internals.texi makeinfo -P new-users-guide -o ../info/new-users-guide.info new-users-guide/new-users-guide.texi makeinfo -o ../info/standards.info standards.texi makeinfo -o ../info/term.info term.texi makeinfo -o ../info/termcap.info termcap.texi makeinfo -o ../info/texinfo.info texinfo.texi makeinfo -o ../info/widget.info widget.texi makeinfo -P xemacs -o ../info/xemacs.info xemacs/xemacs.texi makeinfo -o ../info/xemacs-faq.info xemacs-faq.texi make[1]: Leaving directory `/home/martin/x/ws/fiddle/man' $ makeinfo --version makeinfo (GNU texinfo) 4.0 Copyright (C) 1999 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. $ (PATH=/usr/bin:$PATH; makeinfo --version) makeinfo (GNU texinfo) 3.12f Copyright (C) 1999 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. From owner-xemacs-beta@xemacs.org Fri Nov 19 21:40:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA22772 for xemacs-beta-out; Fri, 19 Nov 1999 21:40:23 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA22769 for ; Fri, 19 Nov 1999 21:40:21 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 6FA3E472F; Fri, 19 Nov 1999 21:46:50 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Can't load user-init-file in latest 21.2 From: Vin Shelton Organization: The XEmacs Development Team Date: 19 Nov 1999 21:46:50 -0500 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: 'xemacs-21.2 -vanilla' produces the following lisp backtrace when I click on the "Load .emacs" button. Signaling: (wrong-number-of-arguments # 1) load-user-init-file("acs") (progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name))) ) eval((progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name)))) - vin From owner-xemacs-beta@xemacs.org Sat Nov 20 00:45:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA26925 for xemacs-beta-out; Sat, 20 Nov 1999 00:45:15 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA26922 for ; Sat, 20 Nov 1999 00:45:13 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id VAA21766; Fri, 19 Nov 1999 21:44:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14390.13609.686264.416143@lasker.666.com> Date: Fri, 19 Nov 1999 21:44:09 -0800 (PST) From: Martin Buchholz To: Adrian Aichner Cc: XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> Hello Reviewers, APA> while trying to improve makefile[1] support for Windows NT native I am APA> faced with this problem: APA> ALL make rules for building XEmacs Windows NT native[2] are in APA> nt\xemacs.mak. APA> However, @setfilename in man\*\*.texi are obviously relative to man\*, APA> not nt. man/Makefile uses makeinfo with the -o option, which explicitly specifies the output filename. So the @setfilenames are ignored. There seems to be no way to explicitly specify an output filename with texinfmt's batch-texinfo-format, and so the @setfilename must be used. But maybe that's a bug in texinfo. An alternative is not to create files in a new directory at all. Generate the .info files in the current directory, and then use mv to move them to the target directory. Besides, why do we even bother with a separate info directory? We could just create all the .info files in man/ (where they can be used), and copied to some info directory at `make install' time. We could also take a look at what GNU Emacs 20.4 does. APA> Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info APA> target (just like on Unix) would be must superior. There is no danger APA> in clashing with Unix makefiles since they are always called Makefile. or GNUmakefile. APA> I would be willing to send in patches for 21.2 to make xemacs.mak APA> build recursively if any objections/problems can be resolved. APA> Any objections? It seems reasonable. Check the FSF implementation first. If we can be compatible with them easily, that would also be a win. Martin From owner-xemacs-beta@xemacs.org Sat Nov 20 13:36:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA10023 for xemacs-beta-out; Sat, 20 Nov 1999 13:36:48 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA10016; Sat, 20 Nov 1999 13:36:45 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id NAA01032; Sat, 20 Nov 1999 13:43:48 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-3.ecf.teradyne.com [131.101.192.123]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id TAA13286; Sat, 20 Nov 1999 19:36:31 +0100 (MET) To: Vin Shelton Cc: xemacs-beta@xemacs.org Subject: Re: Can't load user-init-file in latest 21.2 References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 20 Nov 1999 19:33:54 +0100 Message-ID: Lines: 43 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Vin" == Vin Shelton writes: Vin> 'xemacs-21.2 -vanilla' produces the following lisp backtrace Vin> when I click on the "Load .emacs" button. Hello Vin, the menu entry callback function is broken: misc-user runs (progn (delete-menu-item (quote (Load .emacs))) (load-user-init-file (user-login-name))) `progn' is a built-in function Documentation: (progn BODY...): eval BODY forms sequentially and return value of last one. because `load-user-init-file' does not take an argument in XEmacs-21.2-b20. Handling of user-init-* is an open issue which was discussed starting at http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html An additional problem on native Windows is that (expand-file-name "~OTHER_USER") does not work either. Regards, Adrian Vin> Signaling: (wrong-number-of-arguments # 1) Vin> load-user-init-file("acs") Vin> (progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name))) Vin> ) Vin> eval((progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name)))) Vin> - vin From owner-xemacs-beta@xemacs.org Sat Nov 20 16:26:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA13724 for xemacs-beta-out; Sat, 20 Nov 1999 16:26:50 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA13693; Sat, 20 Nov 1999 16:26:46 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id WAA08696; Sat, 20 Nov 1999 22:26:44 +0100 (MET) Received: from dynppp041.dialup-dyn.ethz.ch(192.33.94.168), claiming to be "petteflet.dialup.ethz.ch" via SMTP by frege, id smtpdAAAa0027d; Sat Nov 20 22:26:39 1999 Received: by petteflet.dialup.ethz.ch (Postfix, from userid 1000) id B375A1108A; Sat, 20 Nov 1999 22:13:22 +0100 (CET) To: rpluim@bigfoot.com Cc: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Give people with crashes more of a clue References: <14371.4718.238975.515777@ltrpluim.corpemea.baynetworks.com> From: Jan Vroonhof Date: 20 Nov 1999 22:13:22 +0100 In-Reply-To: rpluim@bigfoot.com's message of "Fri, 5 Nov 1999 18:22:54 +0100 (CET)" Message-ID: <873du0g93h.fsf@petteflet.dialup.ethz.ch> Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: rpluim@bigfoot.com writes: Thanks. > 1999-11-05 Robert Pluim > > * emacs.c (shut_down_emacs): Point users to PROBLEMS file I've applied this to 21.2. Recommended for 21.1. Jan From owner-xemacs-beta@xemacs.org Sat Nov 20 17:22:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA15126 for xemacs-beta-out; Sat, 20 Nov 1999 17:22:40 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA15036; Sat, 20 Nov 1999 17:17:17 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id RAA08522; Sat, 20 Nov 1999 17:24:23 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-2.ecf.teradyne.com [131.101.192.122]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id XAA13386; Sat, 20 Nov 1999 23:17:05 +0100 (MET) To: Craig Lanning Cc: Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, Bill Tutt , XEmacs Beta List , XEmacs NT List Subject: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> <3.0.6.32.19991112173747.007ca1d0@mail.dycon.com> <3.0.6.32.19991113212055.007e0c60@mail.dycon.com> <3.0.6.32.19991115202724.007cb3e0@mail.dycon.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 20 Nov 1999 23:14:27 +0100 In-Reply-To: Craig Lanning's message of "Mon, 15 Nov 1999 20:27:24 -0500" Message-ID: Lines: 120 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Craig" == Craig Lanning writes: Hi All, this article discusses FILETIME handling on NT and 9[58] and puts up the question how to best cope with it in XEmacs (native and mingw32). Please bear with me while I give Craig two anserws. Other may fast-forward to My analysis: Craig> Are these files on an NTFS disk or FAT disk? These files are all on NTFS. Craig> My files are on a FAT32 disk. Craig> Does NTFS store the timestamp as a GMT integer like unix? Yes, that's it. Here's an extract from MSDN, which is still true for NT4: FileTimeToLocalFileTime() Adjusts for Daylight Saving Time Last reviewed: September 25, 1995 Article ID: Q128126 The information in this article applies to: Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows NT version 3.5 SUMMARY Under NTFS, the API GetFileTime() returns the create time, last access time, and last write time for the specified file. The times returned in the FILETIME structures are in Universal Coordinated Time (UTC). This is also the time that NTFS uses. You can use FileTimeToLocalFileTime() to convert a file time to a local time. However, if you automatically adjust for Daylight Saving Time, FileTimeToLocalFileTime() will adjust for Daylight Saving Time based on whether the current date should be adjusted for Daylight Saving Time, not based on whether the date represented by the FILETIME structure should be adjusted. The behavior in this situation is different under FAT, but may be changed to match the behavior under NTFS in a future version of Windows NT. The FAT file system stores local time, not UTC. GetFileTime() gets cached UTC times from FAT. In this sample, the time stored is 1pm and the cached time is 9pm. When it becomes Daylight Saving Time, sample codes 1 and 2 will demonstrate the same behavior that they do under NTFS, because 9pm is still used. However, when you restart the machine, the new cached time will be 8pm (UTC = LocalTime + 7). The call to FileTimeToLocalFileTime() cancels the adjustment made by GetFileTime() (LocalTime = UTC - 7). Therefore, sample code 1 will report the correct time under FAT, but sample code 2 will not. On the other hand, FindFirstFile() on FAT always reads the time from the file (stored as local time) and converts it into UTC, adjusting for DST based on the current date. So if FindFirstFile() is called, the date is changed to a different DST season, and then FindFirstFile() is called again, the UTC returned by the two calls will be different. Craig> (FAT and FAT32 do not.) If so, that would explain why you Craig> see the time change in Explorer. Exactly. My analysis: I guess MS ``designed´´ FileTimeToLocalFileTime to interpret a FILETIME according to a computer's current DST and TZ setting because they have no way to know what a FAT FILETIME really means (by design, yeah right) since it is stored in local time. My vote is for doing it RIGHT for NTFS and POSIX partitions, interpreting these as UTC, and interpreting FAT partition file times to be relative to the current TZ and DST. That's all we can do, right? Craig> It is compiled and linked in, but I'm not sure how many of Craig> its functions are called. Andy would probably have a Craig> better idea on that. Could any of you tell me how to distinguish NTFS from FAT partitions both on Windows NT and Windows9[58] safely? After a lot of clicking in MSDN I found DeviceIoControl(BOOL DeviceIoControl( (HANDLE) hDevice, // handle to device of interest IOCTL_DISK_GET_PARTITION_INFO, // dwIoControlCode, control code // of operation to perform NULL, // lpInBuffer is not used; must be NULL 0, // nInBufferSize is not used; must be zero (LPVOID) lpOutBuffer, // pointer to output buffer (DWORD) nOutBufferSize, // size, in bytes, of lpOutBuffer (LPDWORD) lpBytesReturned, // pointer to variable to receive // output byte count (LPOVERLAPPED) lpOverlapped // pointer to OVERLAPPED structure // for asynchronous operation ); which is appealing at first glance. However, hDevice can only be opened directly with CreateFile on NT. 95 is incompatible and requires dealing with VxDs. Am I on the right track? What would be the simplest working way to tell apart NTFS and FAT files on the Windows NT, 95, 98 kindred? Thanks for any help! Adrian From owner-xemacs-beta@xemacs.org Sat Nov 20 18:29:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA18434 for xemacs-beta-out; Sat, 20 Nov 1999 18:29:45 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA18431 for ; Sat, 20 Nov 1999 18:29:43 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id AAA09648; Sun, 21 Nov 1999 00:29:38 +0100 (MET) Received: from dynppp001.dialup-dyn.ethz.ch(192.33.94.128), claiming to be "petteflet.dialup.ethz.ch" via SMTP by frege, id smtpdAAAa002Mi; Sun Nov 21 00:29:36 1999 Received: by petteflet.dialup.ethz.ch (Postfix, from userid 1000) id 6105B11084; Sun, 21 Nov 1999 00:28:59 +0100 (CET) To: xemacs-beta@xemacs.org Cc: "William M.Perry" Subject: XEmacs infloops on C-z with new GPM From: Jan Vroonhof Date: 21 Nov 1999 00:28:56 +0100 Message-ID: <87so20oi87.fsf@petteflet.dialup.ethz.ch> Lines: 25 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: With XEmacs 21.2, latest CVS. libgpm 1.14 (I still need to start GPM by hand. Shouldn't loading gpm.el be done by term/linux.el ?) Start xemacs on linux console M-x load-library RET gpm RET M-x gpm-mode RET C-z XEmacs spins printing libgpm: zero screen dimension, assuming 80x25 Attaching with gdb shows XEmacs is in some signal handler from the GPM library. Given that 1.14 is also the version that has the hang problems with the older XEmacs versions, maybe we should make configure check for libgpm 1.15 or greater? Jan From owner-xemacs-beta@xemacs.org Sat Nov 20 18:59:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA19263 for xemacs-beta-out; Sat, 20 Nov 1999 18:59:58 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA19260 for ; Sat, 20 Nov 1999 18:59:55 -0500 Received: by crystal.WonderWorks.COM id QQhqff18339; Sat, 20 Nov 1999 15:59:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14391.13815.892522.347857@crystal.WonderWorks.COM> Date: Sat, 20 Nov 1999 15:59:51 -0800 (PST) From: Kyle Jones To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t97ljg9q3o.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Retaining a measure of backward-compatibility is important. > During the years I've come to the conclusion that Emacs is not > a very smart thing; it's good because it's old and because > lots of code has been written. APIs _do_ change (as witness > by the coming of Emacs 19 and XEmacs), but they should change > slowly and at the right time, unless we wish to alienate our > user-base. Thank you, thank you, thank you. I was losing faith in my fellow man. People support the project by writing XEmacs specific code and then we thank them by breaking their code in the name of 'modernization' or 'improvement'. Leave the old APIs alone! If you want new functionality, make up new function names, add pragmas to the compiler, or whatever. There are ways to maintain backward compatibility most of the time. We can certainly bully people into changing their code, since forking the distribution or refusing to use new versions is unsupportable long-term. But developers remember abuse like this. From owner-xemacs-beta@xemacs.org Sun Nov 21 08:32:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA03899 for xemacs-beta-out; Sun, 21 Nov 1999 08:32:04 -0500 Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA03894; Sun, 21 Nov 1999 08:32:02 -0500 Received: from morpheus.demon.co.uk ([158.152.8.30] helo=morpheus) by finch-post-12.mail.demon.net with smtp (Exim 2.12 #1) id 11pX60-0009fp-0C; Sun, 21 Nov 1999 13:32:01 +0000 From: "Paul Moore" To: , Subject: Redraw bug on Windows native build Date: Sun, 21 Nov 1999 13:34:15 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi, I'm relatively new to XEmacs, so apologies if this issue is already known - I did search the archives and couldn't find an obvious reference... The native build of 21.2.20 on Win32 has a redraw bug. I checked 20.2.19, and the bug isn't in there, so it appeared between 19 and 20. To demonstrate the bug, just start 21.2.20, and then immediately drag the right hand edge of the window out. The newly exposed area doesn't redraw. Actually, it does redraw a few seconds later. I haven't any experience with the XEmacs sources, so I'm afraid I don't know where to begin to look for a solution. Also, I haven't got CVS access set up, so I can't check whether it's been fixed since 20. Hope this is useful, Paul Moore. From owner-xemacs-beta@xemacs.org Sun Nov 21 08:37:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA03970 for xemacs-beta-out; Sun, 21 Nov 1999 08:37:15 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA03935; Sun, 21 Nov 1999 08:34:51 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id OAA28380; Sun, 21 Nov 1999 14:34:45 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006vO; Sun Nov 21 14:34:42 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id OAA18291; Sun, 21 Nov 1999 14:34:42 +0100 To: Adrian Aichner Cc: Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, Bill Tutt , XEmacs Beta List , XEmacs NT List Subject: Re: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> <3.0.6.32.19991112173747.007ca1d0@mail.dycon.com> <3.0.6.32.1999111 From: Jan Vroonhof Date: 21 Nov 1999 14:34:41 +0100 In-Reply-To: Adrian Aichner's message of "20 Nov 1999 23:14:27 +0100" Message-ID: Lines: 24 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > this article discusses FILETIME handling on NT and 9[58] and puts up > the question how to best cope with it in XEmacs (native and mingw32). Unfortunately I cannot remember the origional discussion. However reading between the lines it seems that when going over the DST changeover barrier the Apparent UTC time of a FAT file changes. And thus XEmacs view of the times becomes confused. (Question: Do other windows programs use a differnt API that doesn't go through UTC, and thus do not notice it?) If it is indeed the case that 1. It can be done sanely for sane file systems (i.e. NTFS) 2. Doing it this way goes wrong for FAT only when going over DST barrier. 3. Microsoft Exporer gets it "wrong" too. then my vote would be to not do any file system type checks (can you do those over the network?). Just direct any complainers to Redmond with tar and feathers. Jan From owner-xemacs-beta@xemacs.org Sun Nov 21 09:10:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA05127 for xemacs-beta-out; Sun, 21 Nov 1999 09:10:52 -0500 Received: from esemetz.ese-metz.fr (esemetz.ese-metz.fr [193.48.224.212]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA05118; Sun, 21 Nov 1999 09:10:43 -0500 Received: from NEVERYON.ese-metz.fr (ppp3.ese-metz.fr [193.48.224.223]) by esemetz.ese-metz.fr (8.9.1a/8.9.1) with SMTP id PAA18107; Sun, 21 Nov 1999 15:11:36 +0100 To: Adrian Aichner Cc: Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, Bill Tutt , XEmacs Beta List , XEmacs NT List Subject: Re: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> <3.0.6.32.19991112173747.007ca1d0@mail.dycon.com> <3.0.6.32.19991113212055.007e0c60@mail.dycon.com> <3.0.6.32.19991115202724.007cb3e0@mail.dycon.com> From: Fabrice POPINEAU Date: 21 Nov 1999 15:13:01 +0100 In-Reply-To: Adrian Aichner's message of "20 Nov 1999 23:14:27 +0100" Message-ID: Lines: 18 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: * Adrian Aichner writes: > which is appealing at first glance. > However, hDevice can only be opened directly with CreateFile on NT. > 95 is incompatible and requires dealing with VxDs. > Am I on the right track? > What would be the simplest working way to tell apart NTFS and FAT > files on the Windows NT, 95, 98 kindred? Sorry, I have not much time to investigate the problem you are talking about, but there are chances you can distinguish between FAT and NTFS using GetVolumeInformation() ... There are a bunch of flags returned there that FAT can't handle. Fabrice From owner-xemacs-beta@xemacs.org Sun Nov 21 15:43:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA13774 for xemacs-beta-out; Sun, 21 Nov 1999 15:43:21 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA13766 for ; Sun, 21 Nov 1999 15:43:18 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA01918; Sun, 21 Nov 1999 12:42:55 -0800 (PST) Received: from andyppc (london-shiva-2-3.beasys.com [10.5.1.23]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id UAA02478; Sun, 21 Nov 1999 20:42:51 GMT Message-Id: <3.0.5.32.19991121204358.009b3a20@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 21 Nov 1999 20:43:58 +0000 To: Ben Wing , Adrian Aichner From: Andy Piper Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? Cc: XEmacs Beta List In-Reply-To: <3834C7FB.5F5C8B3C@666.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 08:46 PM 11/18/99 -0700, Ben Wing wrote: >I say, put all the nt makefiles in the proper directories, not in nt. >Windows is not a second-class citizen w.r.t. xemacs. I agree, but this is not strictly true - the windows build uses its own private versions of some header files and source files, noteably config.h, so it is defintely not the same as all other builds. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sun Nov 21 15:43:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA13778 for xemacs-beta-out; Sun, 21 Nov 1999 15:43:23 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA13775 for ; Sun, 21 Nov 1999 15:43:22 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA01923; Sun, 21 Nov 1999 12:42:59 -0800 (PST) Received: from andyppc (london-shiva-2-3.beasys.com [10.5.1.23]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id UAA02509; Sun, 21 Nov 1999 20:42:55 GMT Message-Id: <3.0.5.32.19991121204402.00b4e150@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 21 Nov 1999 20:44:02 +0000 To: "Nick V. Pakoulin" , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: 21.2.20 crash In-Reply-To: <199911181243.PAA02068@pegas.kazbek.ispras.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_943217042==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_943217042==_ Content-Type: text/plain; charset="us-ascii" This is the same one Stephen reported, can you try the attached patch to xlwtabs.c to see if it helps at all? Thanks andy --=====================_943217042==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="t.patch" --- l Tue Nov 16 12:23:10 1999 +++ l2 Tue Nov 16 12:23:00 1999 @@ -1279,9 +1279,9 @@ if( XtIsRealized(t) && w != tw->tabs.hilight ) { - if( tw->tabs.hilight != NULL ) + if( tw->tabs.hilight != NULL && XtIsRealized (tw->tabs.hilight)) DrawHighlight(tw, tw->tabs.hilight, True) ; - if( w != NULL ) + if( w != NULL && XtIsRealized (w)) DrawHighlight(tw, w, False) ; } --=====================_943217042==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_943217042==_-- From owner-xemacs-beta@xemacs.org Sun Nov 21 17:31:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA16944 for xemacs-beta-out; Sun, 21 Nov 1999 17:31:00 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA16930; Sun, 21 Nov 1999 17:30:43 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id RAA00432; Sun, 21 Nov 1999 17:37:54 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-6.ecf.teradyne.com [131.101.192.126]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id XAA18430; Sun, 21 Nov 1999 23:30:37 +0100 (MET) To: Andy Piper Cc: Ben Wing , Adrian Aichner , XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? References: <3.0.5.32.19991121204358.009b3a20@london.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 21 Nov 1999 23:27:46 +0100 Message-ID: Lines: 39 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> At 08:46 PM 11/18/99 -0700, Ben Wing wrote: >> I say, put Andy> all the nt makefiles in the proper directories, not in nt. Andy> >> Windows is not a second-class citizen w.r.t. xemacs. Andy> I agree, but this is not strictly true - the windows build Andy> uses its own private versions of some header files and Andy> source files, noteably config.h, so it is defintely not the Andy> same as all other builds. Hi Andy, I'd say let's keep the nt subdir, but move nt\xemacs.mak to xemacs.mak and adjust the paths for nt\config.h, etc., as required. How about changing the name xemacs.mak to windows.mak, while we're at it? One concern I have with breaking nt\xemacs.mak into recursive makefiles is this: I wrote a lisp package called build, which parses nt\xemacs.mak and then lets you customize-browse all the configuration variables. The module also supports UNIX build by parsing configure.usage. Now, parsing all the windows.mak files in various directories to come up with all the configuration variables would be harder to do. Cheers, Adrian Andy> andy Andy> -------------------------------------------------------------- Andy> Dr Andy Piper Andy> Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sun Nov 21 17:34:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA17061 for xemacs-beta-out; Sun, 21 Nov 1999 17:34:51 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA16920; Sun, 21 Nov 1999 17:30:27 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id RAA00418; Sun, 21 Nov 1999 17:37:29 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-6.ecf.teradyne.com [131.101.192.126]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id XAA18425; Sun, 21 Nov 1999 23:30:10 +0100 (MET) To: Jan Vroonhof Cc: Adrian Aichner , Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, Bill Tutt , XEmacs Beta List , XEmacs NT List Subject: Re: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <3.0.6.32.19991111182113.007c05c0@mail.dycon.com> <3.0.6.32.19991112173747.007ca1d0@mail.dycon.com> <3.0.6.32.1999111 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 21 Nov 1999 23:27:20 +0100 Message-ID: Lines: 63 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Unfortunately I cannot remember the origional Jan> discussion. However reading between the lines it seems that There wasn't really one. I was agonizing, Craig was helping me out with results from the FAT/mingw32 world, and the rest of the group was kindly ignoring us :-) Jan> when going over the DST changeover barrier the Apparent UTC Jan> time of a FAT file changes. And thus XEmacs view of the Jan> times becomes confused. When you change over the DST boundary, MS Explorer will interpret FILETIME differently, irregardless of when the file was modified. That's the best they can do for FAT, which is too dumb to live, and plain wrong for NTFS. In order to stay ``compatible´´ with FAT FILETIME, which is not in UTC, they also interpret NTFS FILETIME wrong. Quite an elegant cover-up approach, eh? Jan> (Question: Do other windows programs use a differnt API that Jan> doesn't go through UTC, and thus do not notice it?) Don't know. Under Windows NT/NTFS: If you create a file at 22:00 in summer (with DST on), MS explorer in winter will show: The file was created at 21:00. It's easy to understand: If it would have been winter in summer too, then the time would have been 21:00 at 22:00 DST. Jan> If it is indeed the case that Jan> 1. It can be done sanely for sane file systems (i.e. NTFS) Jan> 2. Doing it this way goes wrong for FAT only when going over DST Jan> barrier. Jan> 3. Microsoft Exporer gets it "wrong" too. Jan> then my vote would be to not do any file system type checks Jan> (can you do those over the network?). Just direct any Yes, I can GetVolumeInformation for both DOS paths, and UNC path due to a good hint from Fabrice POPINEAU . I found NTFS, CDFS, Samba, FAT on computers in our network. I think it would be a win for XEmacs NT to be the only program there to interpret NTFS FILETIME correctly, and warn about FAT partitions (once per partition) that these have local times stored (at time of creation) and will be interpreted according to current TZ and DST, to come up with SOME numbers :-) Jan> complainers to Redmond with tar and feathers. Oh, by the way, did you hear about MS relocation plans? I heard they will set up their own little village. I think it's called "Potemkin", or something. Best regards, Adrian Jan> Jan From owner-xemacs-beta@xemacs.org Sun Nov 21 18:20:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA18334 for xemacs-beta-out; Sun, 21 Nov 1999 18:20:56 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA18329 for ; Sun, 21 Nov 1999 18:20:54 -0500 Received: (qmail 7887 invoked from network); 21 Nov 1999 23:19:37 -0000 Received: from usrpri2-34.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.99) by biff.kiva.net with SMTP; 21 Nov 1999 23:19:37 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id SAA05144; Sun, 21 Nov 1999 18:22:49 -0500 To: Andy Piper Cc: Ben Wing , Adrian Aichner , XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? X-Now-Listening-To: Beastie Boys - Shambala References: <3.0.5.32.19991121204358.009b3a20@london.beasys.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 28 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes: > At 08:46 PM 11/18/99 -0700, Ben Wing wrote: > >I say, put all the nt makefiles in the proper directories, not in nt. > >Windows is not a second-class citizen w.r.t. xemacs. > > I agree, but this is not strictly true - the windows build uses its own > private versions of some header files and source files, noteably > config.h, so it is defintely not the same as all other builds. Most of the stuff in nt/inc is empty, and only needed because certain parts of the code unconditionally include things like netdb.h instead of wrapping them in #ifdef HAVE_NETDB_H, and doing the appropriate autoconf checks. sys/param.h can be removed and the definition of NBPG put in nt/config.h sys/ioctl.h, netinet/in.h, arpa/inet.h, netdb.h, unistd.h can be completely nuked sys/time.h is probably doing the wrong thing. We should just include the correct file under windows instead of creating our own prototypes for struct timeval, etc. sys/socket.h should just be nuked and all the checks for net-specific errnos should be wrapped in a new macro. In some of our code we use ISSOCKETERROR(var,ENOTCONN), on windows this expands the WSA stuff for you. -Bill P. From owner-xemacs-beta@xemacs.org Sun Nov 21 18:38:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA18707 for xemacs-beta-out; Sun, 21 Nov 1999 18:38:21 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA18703 for ; Sun, 21 Nov 1999 18:38:19 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id SAA05273; Sun, 21 Nov 1999 18:38:09 -0500 To: xemacs-beta@xemacs.org Subject: Tabs' name strings are not font-switched with the rest of XEmacs X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 21 Nov 1999 18:38:09 -0500 Message-ID: Lines: 8 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= I have a small function which toggles the default font between the normal font and "nil2", which lets me conveniently put aside an XEmacs that's not currently interesting. Unfortunately, while XEmacs as a whole reacts to this by smallifying as the text reduces to the "nil2" font, the font used in the tabs continues to be original size. --=-=-= Content-Type: image/gif Content-Disposition: inline; filename=xemacs.gif Content-Transfer-Encoding: base64 Content-Description: tab font not reduced in xemacs R0lGODdhfAAYAfcAAAAAAAAAiwCLAE1NTV9fX2ZmZnp6epmZmaOjo7IiIr6+vszMzM0AAOXl 5fX19f8AAP+lAP///xQDFAhACOS0MDY4PhQUFAgICAJs3ADzNgD/FAC/CAAEFMAAAAUAAJw4 APTqAP8LwL9ABej4oLAv8gQU/0AIv1b46DcvsBQUBAgIQIRs/jnzNgz/FAi/CALceADAsQCy EAAACHyYXgDzUQD/AwC/QCMYjQH0AAD/AAC/AIcEDTkAAAwAAAgAADikiurzAAv/AEC/AJQk KIb0Nwb/FEC/CAPu0ABE8gAD/wBAvygEQjYAahQABwgACFy0XgLzUTg0jer0ALAEDfQAAL8A AFTAipLzAAb/ALhAMDX0NxT/FCju0DZE8hQD/whAv1zwdAI2agAUBwAICDjA+OrzLwv/FCgE gzYAABQAwAgABdw4MPTqPv8LFL9ACBr4jd0vAAQUAEAIALj4EDUvABQUAAgIACjAizbzABT/ AAi/ABgEEvUAACHsZ0DzAAj/AJxs3Ef08gz//wi/vwDuNgBEcQADBwBACIwkHPU3X/8UE78I CKDsAevzAAAEjAAAsQAAEPA47PTq8v8L/79Avzv4PdwvZQQUB0AICIj40PUvXIzsOPXz+L+/ v6AA7OsA9RQA/wgAvwDcYwDAfACyBRf4Z4IvAAcUAKAwAOs+AAGoOAA4+AAU/wAIvwAKOAAA +AAA/wAAvwAAXAEA9QDA/wAFvwBIAAD0AJToAPWwAP8EAL9AAJAiAPU5AP8UAL8IAIywAPX0 AP//AL+/AEgKOPUA+P8A/78Av1GwAIL0AAf/AKBgOOu16hQQC3y7/wD0/wD//wC//xj/wAFH LAADIQBAQAAECgADADgDxPgA8wBUBAD/YABH8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAfAAYAQAI/gAjCBxIsCBBAgYTKlzIsKHD hwoRQixIoKLFixgzatzIsaPHjyBDiqwoUOJEkxNTQkT5kKVDlw0lwlxIUqXNmDMj5kxYc6VM gQqCCh06tCbRo0iTKl1qdKnQpk4VQHVaU2LUoFOvatWaVWnXpF+RVgV6NezWs0fNElVb1KoC mlh/RuBqFYBdAEHx3lWwN29fvn/v4vX71G1UtoXJzhUbtyTZwxLtEpYMePJgyZQxX96ceDHk x1Tdel7bOILVmFIjc87Meahmon/FGg4N+m3JtaLBlj7NNLVAwa8rCwcuHDbltLODmkZeezEB 3Ip1+zYNdHTa6ccJD9e7evDR2J2P/i6Hbt05eeXSx8413RF7d+3B43OH7x1xaaLsn7eNznh6 cq919cUaffMJJpSB2k1HV20A8nedfwyC9R9aFO5nXYMXSuggaRBmKFuEFVZon4JlicbRbiAy 52GIaI3o4oQfUrfieSzWSOJnM1q4IHUjIdTjjyDlF5KQQfZIJJBIJqnkkkMSANyTUEYp5ZRU VmnllVhOKRMADnTp5ZdghinmmGSWaeaZaKaJJgBbqunmm3DGKeeZBrBZEpcOLKDnnnz26eef gAYq6KCEFmpooAbU2Waehzbq6KOQRgpoonaahqekmGaqqaaULrrpp6CGOqmid3Yp6qmockqq pabyOcCr/rC+uoCsjcZK656y0noroLvOOgCvvz7aa5+dlsoorsH2Oeygy+rZa7PIKpustMLC iuiqTrYabbS6WivosLn+Gi60viZrbbe+Ouvtt86qm+4CxbJ6rLvcihssuc/aay+9ga577r37 otsvwOWmG2+285YbbroCAxvruwu/O/C4+zJcMb4Eo3vwpa5Ou7Ct0/qZr7sNAzvryRF/bOu3 K2uMLcfbklwxoSNbzK/J/0IccMgmI+typQhTW6/OLFObM8MDt2tzziULrW7OG2t7c8rrOuyt yjH/qSu9WCtctM8VR51wqmSXnTW8L0tt9tqp9io223C3HfLbcdddNt125y0q/t56960q0Hgm KvjghBdu+OGIJ6744ow3vjjgDjgu+eSUV27541tmqfnmnHfueZQyNTCnmgaMnmbpptMZpgEN hJ66mYm+Xmbsso9Ju5eJtl6S6GODSjvZv6caPNq6m8Y78Kgjr3aow+fueu97Tlno8KdSv3fy ejq/+/J8AqCQXYRazzz2fm7+Z/OsPy+o9wkBcAAAg4rfJ/zl0x+9/dmTP/8B7zfg//8AdN/7 zkc+7RmPe9H7Hv/w5yf5LeAuEbAfBOl3lwHyyYECBAAAN9iADBJQWwYkwPECxT6DAOday7ML QQQzEMHwb4HE0l/3FsjBAL6PgfkDYfq2Bz09lXAh/jjck/h+WJAKvvCFOMQgDWvoPw82sIA7 PGAPH+iQIOawd0SMoACPeMQkyjB6S2SiE2Oow+KJEIE+rCIKsWjCLtoFiR+EXgaZ2EQYPrGM 6iOhGkfFvSy6z4hdjCOg5kjHMV4QimYc4SD3KMg//XCLXITjHeUYxhoaUoiIzOMiG2JFtCHw kUiEpAUnOcgFUsmOZDxWCBXpSEaScpMZFOVd+EjJSNoSlYfEIw/X58pU6jGCkZyloJR4S1sG EX2JRCMVObnGX25RmOH7og9NOSVcYlKXUuQlM2m5vj+Cr1HEBEABxknOAmiwg9a8IiaTOcUs mrCZJPzmo8JZTnKe85Lq/swfO7XJkE46cFP0rKc56zjKXKoyimdsp5Xgiap//lGgA0VnQa95 0H0KT5qf+ucDsdRI4mmyehgFaEhVhc2EKm+KmdJoSjO5y4sqc6UvxRQyP3q9mPpwUF60aaRm 2lJHynOeGBWMoXLaQ2gCtaSs7F70NipBH/6UooNcKvym+sD7ETWq97tpVbfa0VV+Uqo3pSoF X1k+sIJPrFo16CB/StWqtpWsXpUjWN161rRC1ZFmdWpbr7o+pm51qk+9q0d7Or+5vnWsvsRr WP+6VK4KNqpoRSw39UnT7n0TmnV1bD7rd1muXjawGPysWy072cFms1CdZChIdQopnh7wco6L /hxsGSfb2SqutoJLpG13y9veSi6RdAyucIdL3OIa97jI9V/oksvc5jr3ucxdLnSnS93qNle6 1s2udrf7P+xy97vgve7uOJiS8Jo3u95tQASIK5gOavCc7oXvXf433+HC15LnHa5312tf+qrQ eyUEcAQF0sECG/e+HESwfPML3P/xV7hQKrBd4tve9wLHvf69Z33j20QMdxjB4d1vIembYQlX 2MAT/vA9N7hiEqtYxRs2r4gtmWIK13jCU7Jxgut7XwW7+L0MbrD/HpxgGgfQxSX+MIt/rOQm SxjJMh6vg5FbYxrjuL0GDuCGb5ziBQcZgDM+MIgLOeYvczfMxa0y/oTLbGbtopm9bN5xm8/7 ZvvGmcV3nvN067xmMes5xFJWb3NvQuhCG7olgSbynxctXuNNmdGQjm6iI03p42JXi5/LtKY3 zTnsPqABn0ZuqCv9XMeBOdCffoCqU71qULN61bB+tatj3WpYz1rVs771rVud3cY54NSO9l+q Sd3mRCHg2Md2ALKT/evuonrXtX41rm1N7WrnutrTjna2Y21dYyO7SwZYdpeALcL/jZrYX/Z2 suEl7mYr99nY5jatse1qaLPa3vWe97m1q25T9dvdQt43uvPrbR0ym9wAlPa8db1wbdt64P8r OLEO7uxg21vfGM+4xjeu7+8aW20fB7in/jlO8pKbnNYeD3fvVC7yQOcZyjAHMsRrSDvEjbvi 5W5ihaNk4yvXVwAzZ2LsEnfzd1t8uy8PoACWDkCm6zy86l52uxEOXs39b+lYzzrTk97c25WJ 6t/lehOx3vSlq5m7Xl9d0YWM9CxdXetkF3vXpUk7sHNX7gAg+9sFcPbtyq/uOA+v1f0H97if 9++oszvSqax3wgNdyynnHuCNnvO7u93xhc96lvlN98QHvuqMd/rTGYz4tac3u4NvANw3b97S t/zo2pV7pF2v+NgHXeidN32gqy57PdP+89Wl0u0jnvvXV17gw/d78e2O/OT3evnAB/UGcW1e 6s8e+pRPeL4d/h5veTdc29f2vsKtT93fZ9/czoc69gOefvCaX8heLrJ1e9/69WMXABCAQM+7 zOm+M/r9p8d6MNd2iwaAu5dhF6Z6haeAWqeADKh5C0h/1WWAsPdyZRZj7dcAFFh5Oid8D6h5 /pd8G5hwDFCCJZiBE2h/qGaCJ4iC0zWC6OeCzyd5nnd+wgZtF8dtMshBMHiDO5iCNKh7Ftd8 P5hcPbh5YpdnEphuKmhxWIYlHXhhWHZ7R9hjVNZfVNiElfeEULh/FhaClVaFR8ZeWCiCWqhl /OeBPDeFwyeGAxhcSmiGuFU4QriFPHYlUbhzYBiGi1OH2leELxhuUid1fhiDgFhq/oI4iN9m fGPoZ4dIfIo4ddFndXuIglGniIXog484d5G4iMy3ic51iYOYidIHiswlioTIiOiXcaaIe51I cTZYiq14XKgoibFIhLPoiq9IimwWZxYof8KFi8r3igjAi/l3jMeYh1iWeQ3IYZUofR3XfZy4 i6rYYWIEXb0IjLJIcIkYicaIjMnohXj4gZrnjPc1ftuWjsKoi53IiyN2hWUIc+v4fMT4jeCo f+LIc+S4gOY4fRfHcA9nhN2IidUogG8IYWS4ZH9IegM5igWJf/eIj1VSQ8xYjvOlZugobbs2 je34kO8YjwIod+dGfsNIjXYHkfeojBH2gR3oYcY1fu7X/pCp+Im5aFy16InRN4816T83CYvw d1y/WIka9HhJxo31+JARmZSYV5EIqI8RuITI1ZPF6JEHRoZCqXp4BpW0KJO2CH9JGZFLyYxN uZJPGWRSSYo6uZNnWZBpWZNrSZPQuI07yZNciZO3+I/Xtn3dF5Az95aTmJBGpl1tGYhHeZIT uY9bt10aqX6F+ZfsBXR8p5Wk5pexOI6Gt4mUyX5zOVyZ6WmbyZl16ZOe+ZnB1Znw9n0LB4qm OYSkWZqhOZVw2Zo8+JruGHtESZTWOJm0+ZB66Dlh2YzEtpocGHa3qZCUJpxwuGm/WY582Jix KJt0hJxk1jkG2Ya7WXvQOZvO/sl2WZlpHGad2xmA1BV/4GmS0bdj1MmA7Sed0yWZ1xeeB4iG E+mekMae2cmO3liQ6Mk51ZmF8Al7tpdgWveMRmmez9md1EmWIHic13mezkWg1/ieBsqd8qmG 3imhHYmdYWeG/zmcFXqhUqKbHcp7CeifEyqe+TifT8KhJxqfD7qiGWif+2kl+2eJDXqg9wlA Moqgm9OffXmjFPqgB2mcT5acjNmiADqWwgeRKZpiFkmjMTmidweUPjp6UYqkHlpdFbl6y9mA 9ImfBKmhyfWlBQikKNqFPTpwO5qjkIilyQmFGBijZuqibLqmStqjZFp/Uhp8EFpcgwlddqqS ORan/tC1mFeaoQ7KpnS5p1a2pH36o4zanoAYqE2agCW6nnOapHWaqVkqqJ/znWrKqag3pI1Y pGR2pIiKo3caokwKpU96mCkXqfPXdFR6X7gpRpJJqdC1pUzZpWKZq6KqqNrpptM5n4+YdmMi plWJmahjJsqqoqqpcucDmzkprBrIcjFErXcprAV3UKL5bAn3p4rJQeJaXP0mRHbJfukIkNv2 j9GoccKWmmiXiP5Gr2xprVGXJ92Ilvi6r5HTlfdHqvS1oICJbpeobADrcvlXqWHpqZcanGmi rPepJnZXOxZ7sbXDOs5WEQCEsR77sW+SO93lIx3rAELFJwEQACiLWgnQiyctuycC0Fh6ZVd+ s07R1yWCkQA6q7Mp27MpuwA++7Pzs7NEu7MLkHX9l7RRIrKxOIe+9bRQWzl2F7VUW7W/lajW ilwomrXEtbVcK1xe+7V0FLZiW0NkW7YbdLZoi7VrO7Z02rZm+7Zwm7ZyO7dsa7cSi7dBqrc4 xyR++7eACySEthOHVriG6xg2ERAAOw== --=-=-=-- From owner-xemacs-beta@xemacs.org Sun Nov 21 20:00:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA21017 for xemacs-beta-out; Sun, 21 Nov 1999 20:00:56 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA21014; Sun, 21 Nov 1999 20:00:53 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id CAA07133; Mon, 22 Nov 1999 02:00:48 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001jR; Mon Nov 22 02:00:47 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id CAA18455; Mon, 22 Nov 1999 02:00:45 +0100 To: Ben Wing Cc: XEmacs Review , XEmacs beta list Subject: Re: 10% redisplay speed up... References: <3832032F.B9A443ED@666.com> From: Jan Vroonhof Date: 22 Nov 1999 02:00:44 +0100 In-Reply-To: Ben Wing's message of "Tue, 16 Nov 1999 18:21:51 -0700" Message-ID: Lines: 89 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben Wing writes: > Why don't you post exactly the steps you took in order to get the > profiling output, as well as the relevant part of the output itself? > I think people are scared off of profiling because XEmacs is big and > does nonstandard things with its executable, and they don't want to > figure out how to do it. I had originally planned to do make a --enable-profiling configure option. Because now you have to hand edit the makefile to make sure the right startup code gets linked in. Maybe I should indeed just do a Q&D README becuase the pdumper will make all linking magic unnecessary hopefully. > I really really think you should implement your comment about > memcmp(). Do something like this: It is on the todo list for one of those long winter nights (Unfortunately, "Write thesis" is also on that list). Let me take this opportunity to discuss some things. grprof data from doing (hanoi 6) 100-times Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 19.87 128.23 128.23 6977571 0.02 0.03 create_text_block 16.35 233.71 105.48 577884641 0.00 0.00 add_emchar_rune 15.36 332.81 99.10 543668585 0.00 0.00 compare_runes 6.99 377.94 45.13 544418806 0.00 0.00 display_table_entry 3.29 399.16 21.22 6977832 0.00 0.00 compare_display_blocks 2.89 417.78 18.62 715922 0.03 0.04 generate_fstring_runes 1.76 429.15 11.37 6978119 0.00 0.00 output_display_line 1.44 438.44 9.29 14864431 0.00 0.00 specifier_instance 1.36 447.23 8.79 23712557 0.00 0.00 specifier_instance_from_inst_list 1.06 454.08 6.85 44087313 0.00 0.00 find_symbol_value_1 Notes 1. add_emchar_rune and compare_runes are called approximately equal numbers of times. So we must take care not to add too much overhead to the one to optimize the other. 2. The self_seconds data seems fairly inaccurate and/or I am interpreting the data wrong. Here is the callgraph data for add_emchar_rune 33107464 generate_fstring_runes [16] 544777177 create_text_block [5] [8] 16.3 105.48 0.00 577884641 add_emchar_rune [8] 0.00 0.00 362/980266 Dynarr_resize [173] 9125117 ensure_face_cachel_contains_charset [86] Note how its children takeup almost no time, so where did the CPU time go... Now to completely differnt data. This is from gcov (compile using --profile-arcs). This was a normal news reading and writing session using Gnus. This is in point_in_line_start_cache from redisplay.c 1563 if (!Dynarr_length (cache) || line_start_cache_start (w) > point branch 0 taken = 37% call 1 returns = 100% branch 2 taken = 1% call 3 returns = 100% branch 4 taken = 0% branch 5 taken = 100% || line_start_cache_end (w) < point) { 589 int loop; Notice that in almost 40% of the cases, there was no cache present. Note also the callcount of the function and compare that with the callcount in redisplay_window. /* Don't pollute the cache if not sure if we are correct */ 8843 if (w->start_at_line_beg) branch 0 taken = 0% 8842 update_line_start_cache (w, start, end, pointm, 1); call 0 returns = 100% Is the line_start_cache being ineffective? Jan From owner-xemacs-beta@xemacs.org Mon Nov 22 00:36:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA28473 for xemacs-beta-out; Mon, 22 Nov 1999 00:36:15 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA28468; Mon, 22 Nov 1999 00:36:07 -0500 Received: from 666.com (dialup18ip058.tus.azstarnet.com [169.197.38.186]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA12524; Sun, 21 Nov 1999 22:36:00 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3838D61B.FA70C9D1@666.com> Date: Sun, 21 Nov 1999 22:35:23 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wmperry@aventail.com CC: Andy Piper , Adrian Aichner , XEmacs Beta List Subject: Re: Any objections against xemacs/*/xemacs.mak files in 21.2? References: <3.0.5.32.19991121204358.009b3a20@london.beasys.com> <86emdjsa46.fsf@megalith.bp.aventail.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Interesting, I just had a discussion with Martin about this ... and I completely agree, all those wrapped header files should be removed. Probably we should also eventually make something similar to the configure mechanism for mswin -- not necessarily an autoconf script, but at least something that asks questions about how you want XEmacs compiled, and sets up the files appropriately. So I still think the Makefiles should go into the proper directories. Adrian -- surely it can't be that difficult to rewrite your Lisp code. ben "William M. Perry" wrote: > Andy Piper writes: > > > At 08:46 PM 11/18/99 -0700, Ben Wing wrote: > > >I say, put all the nt makefiles in the proper directories, not in nt. > > >Windows is not a second-class citizen w.r.t. xemacs. > > > > I agree, but this is not strictly true - the windows build uses its own > > private versions of some header files and source files, noteably > > config.h, so it is defintely not the same as all other builds. > > Most of the stuff in nt/inc is empty, and only needed because certain parts > of the code unconditionally include things like netdb.h instead of wrapping > them in #ifdef HAVE_NETDB_H, and doing the appropriate autoconf checks. > > sys/param.h can be removed and the definition of NBPG put in nt/config.h > sys/ioctl.h, netinet/in.h, arpa/inet.h, netdb.h, unistd.h can be completely > nuked > > sys/time.h is probably doing the wrong thing. We should just include the > correct file under windows instead of creating our own prototypes for > struct timeval, etc. > > sys/socket.h should just be nuked and all the checks for net-specific > errnos should be wrapped in a new macro. In some of our code we use > ISSOCKETERROR(var,ENOTCONN), on windows this expands the WSA stuff for > you. > > -Bill P. -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Mon Nov 22 00:42:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA28606 for xemacs-beta-out; Mon, 22 Nov 1999 00:42:13 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA28603; Mon, 22 Nov 1999 00:42:11 -0500 Received: from 666.com (dialup18ip058.tus.azstarnet.com [169.197.38.186]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id WAA13571; Sun, 21 Nov 1999 22:42:00 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <3838D784.5CDAE0B3@666.com> Date: Sun, 21 Nov 1999 22:41:24 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vroonhof CC: XEmacs Review , XEmacs beta list Subject: Re: 10% redisplay speed up... References: <3832032F.B9A443ED@666.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I think you should still put in that configure option, but make it take a flag, e.g. --enable-profiling=gprof, because different code is needed for different profiling systems (Quantify, Sun's Analyzer, etc.). I don't trust claims at all about pdumper making the need for this to go away -- not in the general case, certainly. Jan Vroonhof wrote: > Ben Wing writes: > > > Why don't you post exactly the steps you took in order to get the > > profiling output, as well as the relevant part of the output itself? > > I think people are scared off of profiling because XEmacs is big and > > does nonstandard things with its executable, and they don't want to > > figure out how to do it. > > I had originally planned to do make a --enable-profiling configure > option. Because now you have to hand edit the makefile to make sure > the right startup code gets linked in. > > Maybe I should indeed just do a Q&D README becuase the pdumper will > make all linking magic unnecessary hopefully. > > > I really really think you should implement your comment about > > memcmp(). Do something like this: > > It is on the todo list for one of those long winter nights > (Unfortunately, "Write thesis" is also on that list). > > Let me take this opportunity to discuss some things. > > grprof data from doing (hanoi 6) 100-times > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 19.87 128.23 128.23 6977571 0.02 0.03 create_text_block > 16.35 233.71 105.48 577884641 0.00 0.00 add_emchar_rune > 15.36 332.81 99.10 543668585 0.00 0.00 compare_runes > 6.99 377.94 45.13 544418806 0.00 0.00 display_table_entry > 3.29 399.16 21.22 6977832 0.00 0.00 compare_display_blocks > 2.89 417.78 18.62 715922 0.03 0.04 generate_fstring_runes > 1.76 429.15 11.37 6978119 0.00 0.00 output_display_line > 1.44 438.44 9.29 14864431 0.00 0.00 specifier_instance > 1.36 447.23 8.79 23712557 0.00 0.00 specifier_instance_from_inst_list > 1.06 454.08 6.85 44087313 0.00 0.00 find_symbol_value_1 > > Notes > 1. add_emchar_rune and compare_runes are called approximately equal > numbers of times. So we must take care not to add too much > overhead to the one to optimize the other. > 2. The self_seconds data seems fairly inaccurate and/or I am > interpreting the data wrong. Here is the callgraph data for > add_emchar_rune > > 33107464 generate_fstring_runes [16] > 544777177 create_text_block [5] > [8] 16.3 105.48 0.00 577884641 add_emchar_rune [8] > 0.00 0.00 362/980266 Dynarr_resize [173] > 9125117 ensure_face_cachel_contains_charset [86] > > Note how its children takeup almost no time, so where did the CPU time > go... > > Now to completely differnt data. This is from gcov (compile using > --profile-arcs). This was a normal news reading and writing session > using Gnus. > > This is in point_in_line_start_cache from redisplay.c > > 1563 if (!Dynarr_length (cache) || line_start_cache_start (w) > point > branch 0 taken = 37% > call 1 returns = 100% > branch 2 taken = 1% > call 3 returns = 100% > branch 4 taken = 0% > branch 5 taken = 100% > || line_start_cache_end (w) < point) > { > 589 int loop; > > Notice that in almost 40% of the cases, there was no cache present. > Note also the callcount of the function and compare that with the > callcount in redisplay_window. > > /* Don't pollute the cache if not sure if we are correct */ > 8843 if (w->start_at_line_beg) > branch 0 taken = 0% > 8842 update_line_start_cache (w, start, end, pointm, 1); > call 0 returns = 100% > > Is the line_start_cache being ineffective? > > Jan -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Mon Nov 22 03:55:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA32758 for xemacs-beta-out; Mon, 22 Nov 1999 03:55:08 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA32755 for ; Mon, 22 Nov 1999 03:55:07 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8FFC149E for ; Mon, 22 Nov 1999 09:55:04 +0100 (MET) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id JAA18506; Mon, 22 Nov 1999 09:54:29 +0100 To: xemacs-beta@xemacs.org Subject: Re: Can't load user-init-file in latest 21.2 References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 Nov 1999 09:54:29 +0100 In-Reply-To: Adrian Aichner's message of "20 Nov 1999 19:33:54 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA32756 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html What's open about it? There was design, discussion, redesign, implementation, and agreement, and so far, noone has complained. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Mon Nov 22 05:00:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA02667 for xemacs-beta-out; Mon, 22 Nov 1999 05:00:25 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA02664 for ; Mon, 22 Nov 1999 05:00:24 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id FAA03616; Mon, 22 Nov 1999 05:07:29 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id LAA23328; Mon, 22 Nov 1999 11:00:09 +0100 (MET) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Can't load user-init-file in latest 21.2 References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 22 Nov 1999 10:56:42 +0100 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "22 Nov 1999 09:54:29 +0100" Message-ID: Lines: 25 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Sperber writes: >>>>> "APA" == Adrian Aichner writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html Michael> What's open about it? There was design, discussion, redesign, Michael> implementation, and agreement, and so far, noone has complained. I missed the redesign, implementation, and agreement part. Are you suggesting xemacs -u aichner works for you in 21.2-b20? It surely can't work under a native Windows build, but that's a different matter. Windows users are all homeless, except for the use of a HOME env. var. by XEmacs. Adrian Michael> -- Michael> Cheers =8-} Chipsy Michael> Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Mon Nov 22 05:20:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA03245 for xemacs-beta-out; Mon, 22 Nov 1999 05:20:23 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA03237; Mon, 22 Nov 1999 05:20:15 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id TAA08258; Mon, 22 Nov 1999 19:20:12 +0900 (JST) Mail-Copies-To: never To: Adrian Aichner Cc: martin@xemacs.org, Karl Berry , XEmacs Beta List Subject: Re: @ifnottex: texinfo 3.12, 4.0, and XEamcs 21.2 References: <14389.55379.594174.575910@lasker.666.com> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: 22 Nov 1999 19:32:26 +0900 In-Reply-To: (Adrian Aichner's message of "Fri, 19 Nov 1999 22:35:40 +0100") Message-ID: <873dtybyv9.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 37 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes: > This surfaced the problem that the `texinfo' package of XEmacs does > not support the @ifnottex .. @end ifnottex construct. I send patch against texinfmt.el to both bug-gnu-emacs and bug-texinfo and got reply from rms, but it wasn't applied to Emacs 20.4.91 in some reason. I've just resended it to rms. If no one volunteers, I'll sync texinfo stuff with 20.5 when it is released. You only need to add just these two lines to handle @ifnottex. It's semantically equivalent to @ifinfo when formatting Info. (put 'ifnottex 'texinfo-format 'texinfo-discard-line) (put 'ifnottex 'texinfo-end 'texinfo-discard-command) Martin Buchholz writes: > >>>>> "APA" == Adrian Aichner writes: > > APA> Further investigation shows that texinfo-3.12 has problems with this > APA> construct also. Was this a bug in 3.12? Sources indicate that it > APA> should support the construct. > > I did not have the same experience as Adrian, but I am on Linux using > makeinfo 3.12f (and 4.0) and Adrian is on Windows NT. For me makeinfo > 3.12f works fine. 3.12f is a pretest version and has many bug fixes and some new bugs. :-) I've no longer have texinfo 3.12 installed, so I cannot test if it's actually a bug of 3.12. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Mon Nov 22 05:27:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA03477 for xemacs-beta-out; Mon, 22 Nov 1999 05:27:20 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA03473 for ; Mon, 22 Nov 1999 05:27:18 -0500 Received: by localhost id m11pqgm-00016vC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 22 Nov 1999 19:27:16 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> Date: Mon, 22 Nov 1999 19:27:16 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <14391.13815.892522.347857@crystal.WonderWorks.COM> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> Hrvoje Niksic writes: >> Retaining a measure of backward-compatibility is important. As much backward-compatibility as possible. I'm sorry I haven't made that clear. I was under the impression that this kind of thing was mostly gotten rid of by de-Ebola-ification. I was thinking that this might be a good time to push to get rid of it entirely, because any backward compatibility in this department is dangerous under Mule. Apparently this is not the time. Of course I don't speak for Ben on that. Kyle> Thank you, thank you, thank you. I was losing faith in my Kyle> fellow man. People support the project by writing XEmacs Kyle> specific code and then we thank them by breaking their code Kyle> in the name of 'modernization' or 'improvement'. Mule, by definition, breaks the kind of code we're discussing. XEmacs can make Mule go away, but I doubt anyone will thank us for that. Certainly Japanese, Chinese, Indians, et al won't. And probably not anybody, not 5 years from now, anyway. Kyle> Leave the old APIs alone! But we can't, without sacrificing Mule. The old APIs are simply not well-defined in the Mule environment. Admittedly, Mule being my most important XEmacs application, I would like those APIs, especially the implicit ones, to go away. But I'm not adamant. For preserving backward compatibility for well-behaved applications, I don't think the alternatives (to removal) I've proposed are objectionable. We do need to decide what it's going to be, and document it. One thing I want is to discourage developers from writing new code that will not do what they expect from it in the Mule environment. I would prefer that the int-char, char-int, and implicit variants not be used at all in new code. I guess that's impossible. If they must be used, I would strongly prefer that they signal errors if they're given things outside of the ASCII (or ISO-8859-1) domain. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 22 05:35:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA03712 for xemacs-beta-out; Mon, 22 Nov 1999 05:35:06 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA03709 for ; Mon, 22 Nov 1999 05:35:04 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA00589; Mon, 22 Nov 1999 11:34:46 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0009B; Mon Nov 22 11:34:46 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA19158; Mon, 22 Nov 1999 11:34:45 +0100 To: Hrvoje Niksic Cc: XEmacs Patch Reviews , Yoshiki Hayashi Subject: Re: Empty string in mini buffer history References: <874sffsumz.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9bt8n5411.fsf@mraz.iskon.hr> From: Jan Vroonhof Date: 22 Nov 1999 11:34:45 +0100 In-Reply-To: Hrvoje Niksic's message of "22 Nov 1999 09:22:50 +0100" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Recording zero-length input makes sense in the situations where what > you record really is a zero-length string. It does not make sense and > is annoying in the situations where just typing RET activates a > default. In that case typing RET to activate a default should maybe put that default value in the history? Jan From owner-xemacs-beta@xemacs.org Mon Nov 22 05:40:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA03845 for xemacs-beta-out; Mon, 22 Nov 1999 05:40:06 -0500 Received: from lesbains.informatik.uni-tuebingen.de (lesbains.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA03841 for ; Mon, 22 Nov 1999 05:40:04 -0500 Received: from informatik.uni-tuebingen.de (brabantio [134.2.12.25]) by lesbains.informatik.uni-tuebingen.de (Postfix) with ESMTP id E54B949E for ; Mon, 22 Nov 1999 11:40:02 +0100 (MET) Received: (from sperber@localhost) by informatik.uni-tuebingen.de (AIX4.3/UCB 8.8.8/8.8.8) id LAA23376; Mon, 22 Nov 1999 11:40:01 +0100 To: xemacs-beta@xemacs.org Subject: Re: Can't load user-init-file in latest 21.2 References: Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: multipart/mixed; boundary="Multipart_Mon_Nov_22_11:40:01_1999-1" Content-Transfer-Encoding: 7bit From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 Nov 1999 11:40:01 +0100 In-Reply-To: Adrian Aichner's message of "22 Nov 1999 10:56:42 +0100" Message-ID: Lines: 49 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Mon_Nov_22_11:40:01_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "APA" == Adrian Aichner writes: >>>>> "Michael" == Michael Sperber writes: >>>>> "APA" == Adrian Aichner writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html Michael> What's open about it? There was design, discussion, redesign, Michael> implementation, and agreement, and so far, noone has complained. APA> I missed the redesign, implementation, and agreement part. >From etc/NEWS: --Multipart_Mon_Nov_22_11:40:01_1999-1 Content-Type: text/plain; charset=US-ASCII ** New command-line switches -user-init-file and -user-init-directory. These can be used to specify alternate locations for what is normally ~/.emacs and ~/.xemacs. Moreover, -user (which used to only work in unpredictable ways) is now equivalent to -user-init-file ~/.emacs -user-init-directory ~/.xemacs. --Multipart_Mon_Nov_22_11:40:01_1999-1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable APA> Are you suggesting APA> xemacs -u aichner APA> works for you in 21.2-b20? As far as such a thing can work given the design constraints, yes. A couple of people (Jan, notably) who depend on it also approved the fixes. -- = Cheers =3D8-} Chipsy Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla --Multipart_Mon_Nov_22_11:40:01_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 22 05:45:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04010 for xemacs-beta-out; Mon, 22 Nov 1999 05:45:45 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA04001; Mon, 22 Nov 1999 05:45:35 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id FAA05715; Mon, 22 Nov 1999 05:52:41 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id LAA23737; Mon, 22 Nov 1999 11:45:23 +0100 (MET) To: Adrian Aichner Cc: martin@xemacs.org, Karl Berry , XEmacs Beta List Subject: Re: @ifnottex: texinfo 3.12, 4.0, and XEamcs 21.2 References: <14389.55379.594174.575910@lasker.666.com> <873dtybyv9.fsf@dp50.ecc.u-tokyo.ac.jp> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 22 Nov 1999 11:41:58 +0100 In-Reply-To: Yoshiki Hayashi's message of "22 Nov 1999 19:32:26 +0900" Message-ID: Lines: 38 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Yoshiki" == Yoshiki Hayashi writes: Hello Yoshiki, Yoshiki> rms. If no one volunteers, I'll sync texinfo stuff with 20.5 Yoshiki> when it is released. That would be great! Yoshiki> You only need to add just these two lines to handle Yoshiki> @ifnottex. It's semantically equivalent to @ifinfo when Yoshiki> formatting Info. Yoshiki> (put 'ifnottex 'texinfo-format 'texinfo-discard-line) Yoshiki> (put 'ifnottex 'texinfo-end 'texinfo-discard-command) Can you send a patch to xemacs-patches? I will be happy to test it. I have the latest: Author version: 21.1 1998-07-20: XEmacs Development Team Yoshiki> I've no longer have texinfo 3.12 installed, so I cannot test Yoshiki> if it's actually a bug of 3.12. I have built texinfo-4.0 for WIN32 and it works great. I also added support for using this external texinfo program in a patch to nt\xemac.mak, which is still in the patch queue for 21.2. Best regards, Adrian Yoshiki> -- Yoshiki> Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Mon Nov 22 05:52:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04250 for xemacs-beta-out; Mon, 22 Nov 1999 05:52:34 -0500 Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id FAA04245 for ; Mon, 22 Nov 1999 05:52:32 -0500 Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Nov 1999 02:50:00 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Nov 1999 02:49:59 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB9158E@RED-MSG-50> From: Bill Tutt To: "'Adrian Aichner'" , Jan Vroonhof Cc: Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, XEmacs Beta List , XEmacs NT List Subject: RE: [what to do?] Windows FILETIME breakage between NT and 9[58] Date: Mon, 22 Nov 1999 02:49:56 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian, your stat wrapping makes sense to me. The explination behind this mess is fairly straight forward: NT doesn't use the standard timezone handling library that everyone knows and loves in Unix land. See KB article: Q115231 for details on what Win32 actually does. Which is why FileTimeToLocalTime() can only use the current DST state, and stat() uses FileTimeToLocalTime() due to various backwards compatibility reasons. See the MS CRT source for the grungy details. glibc appears to do the correct thing by searching through the timezone's transition history and makes the appropriate adjustment. (including leap seconds) Bill From owner-xemacs-beta@xemacs.org Mon Nov 22 06:13:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA04930 for xemacs-beta-out; Mon, 22 Nov 1999 06:13:26 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA04914; Mon, 22 Nov 1999 06:13:16 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id GAA07126; Mon, 22 Nov 1999 06:20:22 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id MAA23952; Mon, 22 Nov 1999 12:13:03 +0100 (MET) To: Bill Tutt Cc: "'Adrian Aichner'" , Jan Vroonhof , Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, XEmacs Beta List , XEmacs NT List Subject: Re: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <4D0A23B3F74DD111ACCD00805F31D8100DB9158E@RED-MSG-50> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 22 Nov 1999 12:09:38 +0100 In-Reply-To: Bill Tutt's message of "Mon, 22 Nov 1999 02:49:56 -0800" Message-ID: Lines: 35 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Bill" == Bill Tutt writes: Hello Bill! Bill> Adrian, your stat wrapping makes sense to me. What I have yet to put in, is to determine whether the current volume actually has UTC dates. Fabrice suggested using GetVolumeInformation() and that works fine too. Does CDFS have UTC times? Bill> The explination behind this mess is fairly straight forward: Bill> NT doesn't use the standard timezone handling library that Bill> everyone knows and loves in Unix land. See KB article: Bill> Q115231 for details on what Win32 actually does. Bill> Which is why FileTimeToLocalTime() can only use the current Bill> DST state, and stat() uses FileTimeToLocalTime() due to Bill> various backwards compatibility reasons. See the MS CRT Bill> source for the grungy details. Bill> glibc appears to do the correct thing by searching through Bill> the timezone's transition history and makes the appropriate Bill> adjustment. (including leap seconds) Isn't that neat? Bill> Bill Cheers, and thanks for the insight! Adrian From owner-xemacs-beta@xemacs.org Mon Nov 22 06:16:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA05058 for xemacs-beta-out; Mon, 22 Nov 1999 06:16:18 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA05055 for ; Mon, 22 Nov 1999 06:16:14 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11prRv-0008EV-00; Mon, 22 Nov 1999 12:15:59 +0100 To: Jan Vroonhof Cc: XEmacs Patch Reviews , Yoshiki Hayashi Subject: Re: Empty string in mini buffer history References: <874sffsumz.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9bt8n5411.fsf@mraz.iskon.hr> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 22 Nov 1999 12:15:59 +0100 In-Reply-To: Jan Vroonhof's message of "22 Nov 1999 11:34:45 +0100" Message-ID: <9t9emdi22vk.fsf@mraz.iskon.hr> Lines: 13 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Hrvoje Niksic writes: > > > Recording zero-length input makes sense in the situations where what > > you record really is a zero-length string. It does not make sense and > > is annoying in the situations where just typing RET activates a > > default. > > In that case typing RET to activate a default should maybe put that > default value in the history? Yes, that would be very very nice. From owner-xemacs-beta@xemacs.org Mon Nov 22 06:38:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA05752 for xemacs-beta-out; Mon, 22 Nov 1999 06:38:19 -0500 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA05745 for ; Mon, 22 Nov 1999 06:38:17 -0500 Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Nov 1999 03:36:22 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Nov 1999 03:36:22 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB91590@RED-MSG-50> From: Bill Tutt To: "'Adrian Aichner'" Cc: Jan Vroonhof , Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, XEmacs Beta List , XEmacs NT List Subject: RE: [what to do?] Windows FILETIME breakage between NT and 9[58] Date: Mon, 22 Nov 1999 03:36:21 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > From: Adrian Aichner [mailto:aichner@ecf.teradyne.com] > >>>>> "Bill" == Bill Tutt writes: > > Hello Bill! > > Bill> Adrian, your stat wrapping makes sense to me. > > What I have yet to put in, is to determine whether the current volume > actually has UTC dates. Fabrice suggested using > GetVolumeInformation() and that works fine too. > > Does CDFS have UTC times? > With your current fix, what would this gain? As long as you compare file times using identical methods all the time, then it should never matter. To fill in the details on the ISO CD FS spec: (not the Win32 CDFS driver) Volume creation date/times are formatted something like: struct sCDFS { DWORD dwYear; WORD wMonth; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wHundredths; BYTE bOffsetFromGMT; // This is for 15min. intervals }; > Bill> The explination behind this mess is fairly straight forward: > > Bill> NT doesn't use the standard timezone handling library that > Bill> everyone knows and loves in Unix land. See KB article: > Bill> Q115231 for details on what Win32 actually does. > > Bill> Which is why FileTimeToLocalTime() can only use the current > Bill> DST state, and stat() uses FileTimeToLocalTime() due to > Bill> various backwards compatibility reasons. See the MS CRT > Bill> source for the grungy details. > > Bill> glibc appears to do the correct thing by searching through > Bill> the timezone's transition history and makes the appropriate > Bill> adjustment. (including leap seconds) > > Isn't that neat? > Yeah it is. It'd be even neater if time_t could handle all of the timezone transitions that the timezone file has. Bill From owner-xemacs-beta@xemacs.org Mon Nov 22 07:08:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA06861 for xemacs-beta-out; Mon, 22 Nov 1999 07:08:09 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA06851 for ; Mon, 22 Nov 1999 07:07:55 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11psFR-0008GE-00 for ; Mon, 22 Nov 1999 13:07:09 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 22 Nov 1999 13:07:09 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Mon, 22 Nov 1999 19:27:16 +0900 (JST)" Message-ID: <9t9ogcmzq4y.fsf@mraz.iskon.hr> Lines: 8 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Mule, by definition, breaks the kind of code we're discussing. Why do you keep repeating that? It breaks that kind of code only for Asian use. For Americans or some Europeans, that code continues to work unchanged and without problems. If done right, it could have continued working for all Europeans, but that's an old gripe. From owner-xemacs-beta@xemacs.org Mon Nov 22 07:59:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA08273 for xemacs-beta-out; Mon, 22 Nov 1999 07:59:28 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA08237; Mon, 22 Nov 1999 07:57:57 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id IAA13666; Mon, 22 Nov 1999 08:04:59 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (zj75t.ecf.teradyne.com [131.101.192.85]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id NAA24182; Mon, 22 Nov 1999 13:57:43 +0100 (MET) To: Bill Tutt Cc: "'Adrian Aichner'" , Jan Vroonhof , Craig Lanning , Andy Piper , Jonathan Harris , Fabrice.Popineau@supelec.fr, XEmacs Beta List , XEmacs NT List Subject: Re: [what to do?] Windows FILETIME breakage between NT and 9[58] References: <4D0A23B3F74DD111ACCD00805F31D8100DB91590@RED-MSG-50> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 22 Nov 1999 13:54:17 +0100 In-Reply-To: Bill Tutt's message of "Mon, 22 Nov 1999 03:36:21 -0800" Message-ID: Lines: 26 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Bill" == Bill Tutt writes: >> >> What I have yet to put in, is to determine whether the current >> volume actually has UTC dates. Fabrice suggested using >> GetVolumeInformation() and that works fine too. >> >> Does CDFS have UTC times? >> Bill> With your current fix, what would this gain? As long as you Oh, I get it. Just assume UTC always? If it's FAT you loose. Maybe I should submit my patch as it is. Bill> compare file times using identical methods all the time, Bill> then it should never matter. Bill> To fill in the details on the ISO CD FS spec: (not the Win32 Bill> CDFS driver) Volume creation date/times are formatted Bill> something like: Thanks, Adrian From owner-xemacs-beta@xemacs.org Mon Nov 22 18:28:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA29503 for xemacs-beta-out; Mon, 22 Nov 1999 18:28:36 -0500 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA29499 for ; Mon, 22 Nov 1999 18:28:34 -0500 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Nov 1999 15:21:51 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Nov 1999 15:21:50 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB91592@RED-MSG-50> From: Bill Tutt To: "'Adrian Aichner'" Cc: "'XEmacs Beta List'" , "'XEmacs NT List'" Subject: RE: [what to do?] Windows FILETIME breakage between NT and 9[58] Date: Mon, 22 Nov 1999 15:21:45 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > -----Original Message----- > From: Adrian Aichner [mailto:aichner@ecf.teradyne.com] > > Bill> With your current fix, what would this gain? As long as you > > Oh, I get it. Just assume UTC always? If it's FAT you loose. > I saw the same behavior on a FAT drive that I did on my NTFS drive. But yes, always assume UTC, that way you'll always get the ordering correct at the exspense of possibly an incorrect localtime() display. > Maybe I should submit my patch as it is. > That'd be my suggestion. :) Bill From owner-xemacs-beta@xemacs.org Mon Nov 22 20:25:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA32430 for xemacs-beta-out; Mon, 22 Nov 1999 20:25:42 -0500 Received: from zion.ne.mediaone.net (ethersoft.ne.mediaone.net [24.218.196.76]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA32426 for ; Mon, 22 Nov 1999 20:25:39 -0500 Received: by zion.ne.mediaone.net (Postfix, from userid 501) id 090DA472F; Mon, 22 Nov 1999 20:32:17 -0500 (EST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Can't load user-init-file in latest 21.2 References: From: Vin Shelton Organization: The XEmacs Development Team Date: 22 Nov 1999 20:32:16 -0500 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "22 Nov 1999 09:54:29 +0100" Message-ID: Lines: 21 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Consider my previous email a complaint: 'xemacs-21.2 -vanilla' produces the following lisp backtrace when I click on the "Load .emacs" button. Signaling: (wrong-number-of-arguments # 1) load-user-init-file("acs") (progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name))) ) eval((progn (delete-menu-item (quote ...)) (load-user-init-file (user-login-name)))) - vin >>>>> On 22 Nov 1999, sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) said: >>>>> "APA" == Adrian Aichner writes: APA> Handling of user-init-* is an open issue which was discussed starting at APA> http://www.xemacs.org/list-archives/xemacs-beta/9908/msg00772.html Michael> What's open about it? There was design, discussion, redesign, Michael> implementation, and agreement, and so far, noone has complained. From owner-xemacs-beta@xemacs.org Mon Nov 22 21:21:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA01328 for xemacs-beta-out; Mon, 22 Nov 1999 21:21:05 -0500 Received: from localhost.localdomain (ae04162.powerup.com.au [203.147.163.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA01325 for ; Mon, 22 Nov 1999 21:20:56 -0500 Received: from netscape.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA01782 for ; Tue, 23 Nov 1999 12:16:52 +1000 Message-ID: <3839F914.8BCF2EF0@netscape.net> Date: Tue, 23 Nov 1999 12:16:52 +1000 From: "Peter B. West" Organization: Dis X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, Chinese, zh, Japanese, ja, Korean, ko, Russian,  ¾ù MIME-Version: 1.0 To: xemacs-beta Subject: Problem with cvs? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have just done a cvs update of both XEmacs and the packages for the first time since the end of June. Both seemed to go extremely slowly, but, after a few restarts, the packages update did complete. XEmacs proper, however, stalled during the update of the man directory. I tried blowing a few of the .tex files away to see if that would break the log jam (it seemed a good idea at the time) but to no avail. The update stalls here: cvs server: Updating lwlib S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink(CVS/Entries.Log) cvs server: Updating man S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink(CVS/Entries.Log) S-> checkout (/usr/CVSroot/XEmacs/xemacs/man/cl.texi,v, 1.7.2.2, , (function)) S-> server_register(cl.texi, 1.7.2.2, , , release-21-2, , ) S-> Register(cl.texi, 1.7.2.2, , , release-21-2 ) I have this in my .cvsrc: cvs -z3 diff -u update -P I issue `cvs update' in the top level directory. Any ideas? Yours faithfully, -- __ /__ Peter B. West pbwest@netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" From owner-xemacs-beta@xemacs.org Mon Nov 22 22:52:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA03546 for xemacs-beta-out; Mon, 22 Nov 1999 22:52:35 -0500 Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA03542 for ; Mon, 22 Nov 1999 22:52:34 -0500 Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta7/8.10.0.Beta7) with ESMTP id dAN3qRF27118; Mon, 22 Nov 1999 22:52:29 -0500 Message-Id: <199911230352.dAN3qRF27118@black-ice.cc.vt.edu> To: Hrvoje Niksic cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-reply-to: Your message of "Mon, 22 Nov 1999 13:07:09 +0100." <9t9ogcmzq4y.fsf@mraz.iskon.hr> From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> Date: Mon, 22 Nov 1999 22:52:26 -0500 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, 22 Nov 1999 13:07:09 +0100, Hrvoje Niksic said: > "Stephen J. Turnbull" writes: > > > Mule, by definition, breaks the kind of code we're discussing. > > Why do you keep repeating that? It breaks that kind of code only for > Asian use. For Americans or some Europeans, that code continues to > work unchanged and without problems. If done right, it could have > continued working for all Europeans, but that's an old gripe. Yes, but it "works" only in a "dont do that then" mode. If you're an American, or other 8859-X denizen, it "works" as long as it doesn't see something off the wall. Unfortunately, things like Gnus and the like are often handed Truly Weird Stuff - in fact, *MY* only reason for using --with-mule is so that headers Look As The Sender Intended when I read newsgroups that get postings from the Pacific Rim. No, I can't read/speak any of the languages involved. But I happen to like it when the glyphs I see are the ones the sender intended - after all the hassles of getting RFC2047 done, seeing =Q or =B in a message header pisses me off. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-xemacs-beta@xemacs.org Tue Nov 23 00:38:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA06394 for xemacs-beta-out; Tue, 23 Nov 1999 00:38:05 -0500 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA06389; Tue, 23 Nov 1999 00:38:04 -0500 Mime-Version: 1.0 X-Sender: mta@pophost.arbortext.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 23 Nov 1999 00:00:24 -0500 To: "Paul Moore" , , From: Mike Alexander Subject: Re: Redraw bug on Windows native build Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 1:34 PM +0000 11/21/99, Paul Moore wrote: >Hi, >I'm relatively new to XEmacs, so apologies if this issue is already >known - I did search the archives and couldn't find an obvious >reference... > >The native build of 21.2.20 on Win32 has a redraw bug. I checked >20.2.19, and the bug isn't in there, so it appeared between 19 and >20. > >To demonstrate the bug, just start 21.2.20, and then immediately >drag the right hand edge of the window out. The newly exposed area >doesn't redraw. Actually, it does redraw a few seconds later. > >I haven't any experience with the XEmacs sources, so I'm afraid I >don't know where to begin to look for a solution. Also, I haven't >got CVS access set up, so I can't check whether it's been fixed since 20. > >Hope this is useful, >Paul Moore. I've noticed this too. Here's a patch that makes resize work. It probably isn't the right patch since I haven't spent much time figuring out how this code is supposed to work, but it does make resize work and it hasn't caused any crashes that I know of. All I did was add size_changed to REDISPLAY_FLAGS. It may need to go into RESET_CHANGED_FLAGS too, but it seems to work without that. Mike Alexander Index: src/redisplay.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.h,v retrieving revision 1.7.2.14 diff -u -r1.7.2.14 redisplay.h --- redisplay.h 1999/11/20 20:29:17 1.7.2.14 +++ redisplay.h 1999/11/23 04:35:25 @@ -526,7 +526,6 @@ #define MARK_SUBWINDOWS_CHANGED MARK_TYPE_CHANGED (subwindows) #define MARK_SUBWINDOWS_STATE_CHANGED MARK_TYPE_CHANGED (subwindows_state) - #define CLASS_RESET_CHANGED_FLAGS(p) do { \ (p)->buffers_changed = 0; \ (p)->clip_changed = 0; \ @@ -575,6 +574,7 @@ (p)->menubar_changed || \ (p)->modeline_changed || \ (p)->point_changed || \ + (p)->size_changed || \ (p)->toolbar_changed || \ (p)->gutter_changed || \ (p)->glyphs_changed || \ @@ -593,6 +593,7 @@ menubar_changed || \ modeline_changed || \ point_changed || \ + size_changed || \ toolbar_changed || \ gutter_changed || \ glyphs_changed || \ From owner-xemacs-beta@xemacs.org Tue Nov 23 00:41:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA06604 for xemacs-beta-out; Tue, 23 Nov 1999 00:41:46 -0500 Received: from localhost.localdomain (ae04139.powerup.com.au [203.147.163.139]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA06599 for ; Tue, 23 Nov 1999 00:41:41 -0500 Received: from netscape.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA02193 for ; Tue, 23 Nov 1999 13:41:24 +1000 Message-ID: <383A0CE3.4EE796DC@netscape.net> Date: Tue, 23 Nov 1999 13:41:23 +1000 From: "Peter B. West" Organization: Dis X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, Chinese, zh, Japanese, ja, Korean, ko, Russian,  ¾ù MIME-Version: 1.0 To: xemacs-beta Subject: Binary edits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Using a 21.2 build from last June, I tried to edit a file with hexl. My changes to x0D were stubbornly modified to x0A whenever I wrote the file. I set the coding to binary, but the D->A changes just kept on happening. Am I missing something, or was this a bug in an earlier version? Semper in Domino, Peter -- __ /__ Peter B. West pbwest@netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" From owner-xemacs-beta@xemacs.org Tue Nov 23 02:22:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA09339 for xemacs-beta-out; Tue, 23 Nov 1999 02:22:52 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA09335 for ; Tue, 23 Nov 1999 02:22:49 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id XAA09801; Mon, 22 Nov 1999 23:22:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14394.16577.821236.175504@lasker.666.com> Date: Mon, 22 Nov 1999 23:22:41 -0800 (PST) From: Martin Buchholz To: "Peter B. West" Cc: xemacs-beta Subject: Re: Problem with cvs? In-Reply-To: <3839F914.8BCF2EF0@netscape.net> References: <3839F914.8BCF2EF0@netscape.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "P" == Peter B West writes: The weirdest thing that has happened is that the index.texi generated files are now in CVS. Also, the sub-Makefiles are gone. Try cd man; rm */Makefile */index* and then rerun cvs update P> I have just done a cvs update of both XEmacs and the packages for the P> first time since the end of June. Both seemed to go extremely slowly, P> but, after a few restarts, the packages update did complete. XEmacs P> proper, however, stalled during the update of the man directory. I P> tried blowing a few of the .tex files away to see if that would break P> the log jam (it seemed a good idea at the time) but to no avail. The P> update stalls here: From owner-xemacs-beta@xemacs.org Tue Nov 23 08:42:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18333 for xemacs-beta-out; Tue, 23 Nov 1999 08:42:56 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA18327; Tue, 23 Nov 1999 08:42:54 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id FAA27934; Tue, 23 Nov 1999 05:42:30 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-132.beasys.com [192.168.11.132]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id NAA09945; Tue, 23 Nov 1999 13:42:15 GMT Message-Id: <3.0.5.32.19991123134317.00bdc190@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Nov 1999 13:43:17 +0000 To: Mike Alexander , "Paul Moore" , , From: Andy Piper Subject: Re: Redraw bug on Windows native build In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oops. This looks like the correct fix and is definitely my fault. andy At 12:00 AM 11/23/99 -0500, Mike Alexander wrote: >At 1:34 PM +0000 11/21/99, Paul Moore wrote: >>Hi, >>I'm relatively new to XEmacs, so apologies if this issue is already >>known - I did search the archives and couldn't find an obvious >>reference... >> >>The native build of 21.2.20 on Win32 has a redraw bug. I checked >>20.2.19, and the bug isn't in there, so it appeared between 19 and >>20. >> >>To demonstrate the bug, just start 21.2.20, and then immediately >>drag the right hand edge of the window out. The newly exposed area >>doesn't redraw. Actually, it does redraw a few seconds later. >> >>I haven't any experience with the XEmacs sources, so I'm afraid I >>don't know where to begin to look for a solution. Also, I haven't >>got CVS access set up, so I can't check whether it's been fixed since 20. >> >>Hope this is useful, >>Paul Moore. > >I've noticed this too. Here's a patch that makes resize work. It >probably isn't the right patch since I haven't spent much time >figuring out how this code is supposed to work, but it does make >resize work and it hasn't caused any crashes that I know of. All I >did was add size_changed to REDISPLAY_FLAGS. It may need to go into >RESET_CHANGED_FLAGS too, but it seems to work without that. > > Mike Alexander > >Index: src/redisplay.h >=================================================================== >RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.h,v >retrieving revision 1.7.2.14 >diff -u -r1.7.2.14 redisplay.h >--- redisplay.h 1999/11/20 20:29:17 1.7.2.14 >+++ redisplay.h 1999/11/23 04:35:25 >@@ -526,7 +526,6 @@ > #define MARK_SUBWINDOWS_CHANGED MARK_TYPE_CHANGED (subwindows) > #define MARK_SUBWINDOWS_STATE_CHANGED MARK_TYPE_CHANGED (subwindows_state) > >- > #define CLASS_RESET_CHANGED_FLAGS(p) do { \ > (p)->buffers_changed = 0; \ > (p)->clip_changed = 0; \ >@@ -575,6 +574,7 @@ > (p)->menubar_changed || \ > (p)->modeline_changed || \ > (p)->point_changed || \ >+ (p)->size_changed || \ > (p)->toolbar_changed || \ > (p)->gutter_changed || \ > (p)->glyphs_changed || \ >@@ -593,6 +593,7 @@ > menubar_changed || \ > modeline_changed || \ > point_changed || \ >+ size_changed || \ > toolbar_changed || \ > gutter_changed || \ > glyphs_changed || \ > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 23 08:42:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18324 for xemacs-beta-out; Tue, 23 Nov 1999 08:42:50 -0500 Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA18317 for ; Tue, 23 Nov 1999 08:42:43 -0500 Received: from london.beasys.com (london.beasys.com [10.5.1.10]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id FAA27923; Tue, 23 Nov 1999 05:42:13 -0800 (PST) Received: from andyppc (hqvpn-192-168-11-132.beasys.com [192.168.11.132]) by london.beasys.com (8.9.1b+Sun/8.9.1) with SMTP id NAA09939; Tue, 23 Nov 1999 13:41:59 GMT Message-Id: <3.0.5.32.19991123134303.00bdb7a0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Nov 1999 13:43:03 +0000 To: Karl Kleinpaste , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Tabs' name strings are not font-switched with the rest of XEmacs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 06:38 PM 11/21/99 -0500, Karl Kleinpaste wrote: >I have a small function which toggles the default font between the >normal font and "nil2", which lets me conveniently put aside an XEmacs >that's not currently interesting. Unfortunately, while XEmacs as a >whole reacts to this by smallifying as the text reduces to the "nil2" >font, the font used in the tabs continues to be original size. Hmmn, we can't be far off fixing this - the tab font is default by default and the font changing code is in there, maybe we just have to kick XEmacs when the font change occurs. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Nov 23 11:33:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA24627 for xemacs-beta-out; Tue, 23 Nov 1999 11:33:46 -0500 Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA24622 for ; Tue, 23 Nov 1999 11:33:40 -0500 Received: from castor.hrz.uni-bielefeld.de by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FLN0051PSO2QP@mail.uni-bielefeld.de> for xemacs-beta@xemacs.org; Tue, 23 Nov 1999 17:33:38 +0100 (MET) Received: (from bokerman@localhost) by castor.hrz.uni-bielefeld.de (8.8.6 (PHNE_17135)/8.8.6) id RAA20624; Tue, 23 Nov 1999 17:33:37 +0100 (MET) Date: Tue, 23 Nov 1999 17:33:36 +0100 From: Nils Bokermann Subject: build-failure on solaris2.6 To: xemacs-beta@xemacs.org Cc: nilsb@bermuda.de Message-id: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi Maybe I'm too blind too see, but temacs crashes with segfault when dumping to xemacs:( Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Segmentation Fault - core dumped gmake[1]: [xemacs] Error 139 (ignored) --- bash-2.02$ gdb src/temacs src/core [...] (gdb) bt #0 0xeef9e93c in ?? () #1 0xef008328 in ?? () #2 0xef7d9f58 in ?? () #3 0xef7d69c8 in ?? () #4 0xef7d47d8 in ?? () #5 0xef7e0678 in ?? () #6 0xef7d3a88 in ?? () #7 0xef7dd588 in ?? () #8 0xef7dd12c in ?? () #9 0xef7dd278 in ?? () #10 0xef7de0b0 in ?? () #11 0xef7ddf68 in ?? () #12 0xb074c in unexec ( new_name=0xefffed60 "/opt/packages/xemacs-21.2.20/src/xemacs", old_name=0xefffed38 "/opt/packages/xemacs-21.2.20/src/temacs", data_start=2565776, bss_start=0, entry_address=0) at unexsol2-6.c:33 #13 0x9bbd4 in Fdump_emacs (intoname=4608612, symname=4608628) at emacs.c:2647 #14 0xa3094 in Feval (form=4509796) at eval.c:2975 #15 0x9dbe0 in Fprogn (args=4630676) at eval.c:767 #16 0xa2f04 in Feval (form=4630688) at eval.c:2947 #17 0x9d8dc in Fif (args=4630688) at eval.c:683 #18 0xa2f04 in Feval (form=4630724) at eval.c:2947 #19 0xa34a4 in Feval (form=4557116) at eval.c:3055 #20 0x152120 in readevalloop (readcharfun=3066752, sourcename=3081572, evalfun=0xa2810 , printflag=0) at lread.c:1447 #21 0x1508cc in Fload_internal (file=3081572, no_error=2551940, nomessage=2628608, nosuffix=2795524, codesys=2627584, used_codesys=3) at lread.c:736 #22 0xa3160 in Feval (form=3059480) at eval.c:2975 #23 0x9f7cc in condition_case_1 (handlers=2580480, bfun=0xa2810 , barg=3059480, hfun=0x7c3bc , harg=2795524) at eval.c:1630 #24 0x7c44c in top_level_1 (dummy=2627584) at cmdloop.c:202 #25 0xa8284 in internal_catch (tag=2877516, func=0x7c410 , arg=2795524, threw=0x0) at eval.c:1305 #26 0x7b2f4 in initial_command_loop (load_me=3081572) at cmdloop.c:281 #27 0x9aec8 in sort_args (argc=2178048, argv=0xeffffbd4) at emacs.c:1873 #28 0x9ccdc in main (argc=5, argv=0xeffffbd4, envp=0xeffffbec) at emacs.c:2236 (gdb) --- bash-2.02$ ldd src/temacs libXm.so.3 => /usr/dt/lib/libXm.so.3 libDtSvc.so.1 => /usr/dt/lib/libDtSvc.so.1 libtt.so.2 => /usr/dt/lib/libtt.so.2 libXmu.so.4 => /usr/openwin/lib/libXmu.so.4 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libXext.so.0 => /usr/openwin/lib/libXext.so.0 libX11.so.4 => /usr/openwin/lib/libX11.so.4 libSM.so.6 => /usr/openwin/lib/libSM.so.6 libICE.so.6 => /usr/openwin/lib/libICE.so.6 libdl.so.1 => /usr/lib/libdl.so.1 libkvm.so.1 => /usr/lib/libkvm.so.1 libkstat.so.1 => /usr/lib/libkstat.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 => /usr/lib/libmp.so.2 bash-2.02$ --- # Run this file to recreate the current configuration. # This directory was configured as follows, # on host hermes: # # ./configure --prefix=/opt/gnu/xemacs/21.2.20 I hope I didn't forget anything interesting... Bye, Nils -- Nils Bokermann Phone: +49 521 88074398 From owner-xemacs-beta@xemacs.org Tue Nov 23 17:06:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA01767 for xemacs-beta-out; Tue, 23 Nov 1999 17:06:30 -0500 Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA01760; Tue, 23 Nov 1999 17:06:21 -0500 Received: from morpheus.demon.co.uk ([158.152.8.30] helo=morpheus) by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1) id 11qO4h-000Gvk-0B; Tue, 23 Nov 1999 22:06:12 +0000 From: "Paul Moore" To: "Andy Piper" , "Mike Alexander" , , Subject: RE: Redraw bug on Windows native build Date: Tue, 23 Nov 1999 22:08:33 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.5.32.19991123134317.00bdc190@london.beasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: From: Andy Piper [mailto:andy@xemacs.org] > > Oops. This looks like the correct fix and is definitely my fault. > > At 12:00 AM 11/23/99 -0500, Mike Alexander wrote: > >I've noticed this too. Here's a patch that makes resize work. It > >probably isn't the right patch since I haven't spent much time > >figuring out how this code is supposed to work, but it does make > >resize work and it hasn't caused any crashes that I know of. All I > >did was add size_changed to REDISPLAY_FLAGS. It may need to go into > >RESET_CHANGED_FLAGS too, but it seems to work without that. I can confirm that this patch fixes the problem. Thanks for the quick replies! Paul. From owner-xemacs-beta@xemacs.org Tue Nov 23 18:25:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA04324 for xemacs-beta-out; Tue, 23 Nov 1999 18:25:30 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA04094; Tue, 23 Nov 1999 18:23:18 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id SAA07155; Tue, 23 Nov 1999 18:30:16 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id AAA00913; Wed, 24 Nov 1999 00:22:58 +0100 (MET) To: xemacs@xemacs.org Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: M-x compile leaves 3 handles open on native Windows (21.1 and 21.2) X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 24 Nov 1999 00:18:22 +0100 Message-ID: Lines: 55 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.1 (patch 8) "Bryce Canyon" [Lucid] (i386-pc-win32) of Wed Nov 10 1999 on ZJ75T configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Bring up Windows NT Task Manager Start xemacs -vanilla Note the number Handles XEmacs has open. Run M-x compile RET dir RET Note new number of open handles, which will have increased by 3. Best regards, Adrian Recent keystrokes: C-x o C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n RET button3 misc-user button3up C-x 0 C-x ` C-x o C-l C-x ` C-x 1 M-> M-< M-> C-x C-b C-x o C-x C-b C-s G r RET C-s C-s C-s RET C-x C-z button1 button1up misc-user misc-user C-x C-b M-x c o m p i l e RET C-a C-k d i r RET M-x M-p RET M-p M-n M-p RET C-x C-n M-x c o m p i l e RET RET M-x M-p RET M-p M-n M-p RET M-x M-p RET RET misc-user Recent messages (most recent first): Wrong type argument: natnump, -1 No preceding item in compile-history C-x C-n not defined. Wrong type argument: natnump, -1 No preceding item in compile-history No more errors yet Auto-saved xemacs-make-all.err No more grep hits Wrote d:\tmp\21.2\xemacs\src\sysdep.c Wrote d:\tmp\21.2\xemacs\src\sysdep.c From owner-xemacs-beta@xemacs.org Tue Nov 23 20:02:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA10601 for xemacs-beta-out; Tue, 23 Nov 1999 20:02:33 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id UAA10598 for ; Tue, 23 Nov 1999 20:02:31 -0500 Received: (qmail 10463 invoked from network); 24 Nov 1999 01:01:14 -0000 Received: from usrpri2-23.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.88) by biff.kiva.net with SMTP; 24 Nov 1999 01:01:14 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA01529; Tue, 23 Nov 1999 20:04:30 -0500 To: xemacs-beta@xemacs.org Subject: URL retrieval rewrite... X-Now-Listening-To: Beastie Boys - Something's Got to Give Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm most of the way through rewriting the URL loading for Emacs/W3. In the process, I'm making the URL library much more standalone. This means that it would be much easier to include just it in the base XEmacs tarball and use it for package retrieval, etc. This way a user would be able to stick FTP and HTTP URLs in the package directory list, and all would be well with the world. The new HTTP loader is 100% asynchronous, and does all the work of waiting for headers, decoding 'chunked' transfer-encodings, parsing headers, etc, with after-change-functions. It will be up to the calling application to deal with making it a synchronous operation. I'm probably going to be hacking on this late tonight, so I hope to have something I can ship out to the w3-(beta|dev) and xemacs-beta lists tomorrow. -Bill P. From owner-xemacs-beta@xemacs.org Tue Nov 23 22:08:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA15614 for xemacs-beta-out; Tue, 23 Nov 1999 22:08:17 -0500 Received: from najohnson.az76.honeywell.com (najohnson.az76.honeywell.com [129.239.73.45]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id WAA15606 for ; Tue, 23 Nov 1999 22:08:14 -0500 Received: by najohnson.az76.honeywell.com via sendmail with stdio id for xemacs-beta@xemacs.org; Tue, 23 Nov 1999 20:08:12 -0700 (MST) (Smail-3.2 1996-Jul-4 #1 built 1999-Aug-23) Message-Id: Date: Tue, 23 Nov 1999 20:08:12 -0700 (MST) To: xemacs-beta@xemacs.org Subject: crash From: nn@uswest.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: M-x w3 caused xemacs to crash I just installed w3-4.0pre.46 I'm using glibc 2.0 under linux If someone would like the core dump, or if there is additional information which would be usefull, and I could furnish, please let me know. I can be contacted as nn@uswest.net OUTPUT OF 'where' in gdb ------------------------------------------------------------------------------- GNU gdb 4.18 This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/Xaw95/libXaw3d.so.6...done. Reading symbols from /usr/local/lib/libtiff.so.3...done. Reading symbols from /usr/local/lib/libpng.so.2...done. Reading symbols from /usr/local/lib/libjpeg.so.6...done. Reading symbols from /usr/local/lib/libz.so.1...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /usr/local/lib/libgdbm.so.1...done. Reading symbols from /usr/local/lib/libgpm.so.1...done. Reading symbols from /lib/libncurses.so.4...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_dns.so.2...done. Reading symbols from /lib/libresolv.so.2...done. #0 0x40307ab1 in __kill () from /lib/libc.so.6 (gdb) where #0 0x40307ab1 in __kill () from /lib/libc.so.6 #1 0x80895c9 in fatal_error_signal (sig=11) at emacs.c:276 #2 0x403079b8 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125 #3 0x81c46d5 in MaxLabel (gw=0x8583338, wid=0xbfffd248, hgt=0xbfffd24a, w0=0xbfffd24c, w1=0xbfffd24e) at xlwgauge.c:967 #4 0x81c32cc in GaugeResize (w=0x8583338) at xlwgauge.c:327 #5 0x4002f99b in Initialize () from /usr/X11R6/lib/Xaw95/libXaw3d.so.6 #6 0x40130185 in CallInitialize () from /usr/X11R6/lib/libXt.so.6 #7 0x4013014d in CallInitialize () from /usr/X11R6/lib/libXt.so.6 #8 0x401306a2 in xtCreate () from /usr/X11R6/lib/libXt.so.6 #9 0x40130b8f in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x40130cb0 in XtCreateManagedWidget () from /usr/X11R6/lib/libXt.so.6 #11 0x81bd434 in xaw_create_progress (instance=0x8583158) at lwlib-Xaw.c:808 #12 0x81bb7f3 in instantiate_widget_instance (instance=0x8583158) at lwlib.c:879 #13 0x81bb8f4 in lw_make_widget (id=65548, parent=0x8582ff0, pop_up_p=0 '\000') at lwlib.c:358 #14 0x81bc1dc in lw_create_widget (type=0x821b499 "progress", name=0x854c268 "Progress", id=65548, val=0x85343c8, parent=0x8582ff0, pop_up_p=0 '\000', pre_activate_cb=0, selection_cb=0x80abff0 , post_activate_cb=0) at lwlib.c:931 #15 0x819bbf3 in x_widget_instantiate (image_instance=139996784, instantiator=138403256, pointer_fg=136731044, pointer_bg=136731044, dest_mask=239, domain=139583576, type=0x821b499 "progress", wv=0x85343c8) at glyphs-x.c:2439 #16 0x819db84 in x_progress_gauge_instantiate (image_instance=139996784, instantiator=138403256, pointer_fg=136731044, pointer_bg=136731044, dest_mask=239, domain=139583576) at glyphs-x.c:2580 #17 0x80fd462 in instantiate_image_instantiator (device=139127048, domain=139583576, instantiator=138403256, pointer_fg=136731044, pointer_bg=136731044, dest_mask=239) at glyphs.c:605 #18 0x81018d4 in image_instantiate (specifier=138402976, matchspec=136516812, domain=139583576, instantiator=138403256, depth=3) at glyphs.c:2564 #19 0x808cf55 in call_with_suspended_errors ( fun=0x8101370 , retval=136516812, class=136852068, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, nargs=5) at eval.c:2126 #20 0x817397b in specifier_instance_from_inst_list (specifier=138402976, matchspec=136516812, domain=139583576, inst_list=138319160, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, depth=3) at specifier.c:2444 #21 0x8173d47 in specifier_instance (specifier=138402976, matchspec=136516812, domain=139583576, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, no_fallback=0, depth=1) at specifier.c:2559 #22 0x8175515 in Fspecifier_instance (specifier=138402976, domain=136731044, default_=136731044, no_fallback=136731044) at specifier.c:2649 #23 0x808f1e1 in Ffuncall (nargs=5, args=0xbfffddb8) at eval.c:3178 #24 0x8061ae6 in execute_optimized_program ( program=0x85475a8 "À\t!¬\006ÂÀ\t\"\021\t\013N\034Å\f!«\013Æ\f\016\a\016\b\016\t$\024\f)\207\003", stack_depth=5, constants_data=0x8309d38) at bytecode.c:743 #25 0x8061639 in funcall_compiled_function (fun=137394056, nargs=5, args=0xbfffdec0) at bytecode.c:519 #26 0x808f353 in Ffuncall (nargs=6, args=0xbfffdebc) at eval.c:3210 #27 0x8061ae6 in execute_optimized_program ( program=0x8547588 "À\tÂ\013\f\r%\207ÿÿÿÿA", stack_depth=6, constants_data=0x8314bf8) at bytecode.c:743 #28 0x8061639 in funcall_compiled_function (fun=137394224, nargs=1, args=0xbfffdfcc) at bytecode.c:519 #29 0x808f353 in Ffuncall (nargs=2, args=0xbfffdfc8) at eval.c:3210 #30 0x8061ae6 in execute_optimized_program (program=0x86e9068 "\bÁk?\205¡", stack_depth=6, constants_data=0x83fe9c0) at bytecode.c:743 #31 0x8061639 in funcall_compiled_function (fun=138290616, nargs=3, args=0xbfffe0d0) at bytecode.c:519 #32 0x808f353 in Ffuncall (nargs=4, args=0xbfffe0cc) at eval.c:3210 #33 0x8061ae6 in execute_optimized_program ( program=0x86e8ff0 "\b¬\004Á \020\n@\211\eA\034\r\013@a«.\013\016\006¡\210\f\016\006a«\rÇÈ\016\t!Ê\016\013#\210ª\tÌ\016\006\016\013\b#\210Í \210Î «\027ÏÐ !\210ª\020\r\016\006B\nB\022Ì\016\006\016\013\b#\210\016\013Ña­\tÒÓÔ\"\210Õ\r!*\207s-packÁ", stack_depth=5, constants_data=0x83fe890) at bytecode.c:743 #34 0x8061639 in funcall_compiled_function (fun=138290560, nargs=4, args=0xbfffe1d4) at bytecode.c:519 #35 0x808f353 in Ffuncall (nargs=5, args=0xbfffe1d0) at eval.c:3210 #36 0x8061ae6 in execute_optimized_program ( program=0x86e85b8 "À\t\nÃ#\210\fÅa«\bÆ\t\016\a\n#\207È\t\016\a\f\n$\207", stack_depth=5, constants_data=0x83fea90) at bytecode.c:743 #37 0x8061639 in funcall_compiled_function (fun=138290644, nargs=3, args=0xbfffe2d8) at bytecode.c:519 #38 0x808f353 in Ffuncall (nargs=4, args=0xbfffe2d4) at eval.c:3210 #39 0x8061ae6 in execute_optimized_program ( program=0x86e8580 "\b¬\n\t¬\aÂÃÂ!\210\207ÄÅ\b\t#\036\006ÇÈ\016\006\016\t#\210\016\006)\207@ipt,1", stack_depth=4, constants_data=0x83ff2c8) at bytecode.c:743 #40 0x8061639 in funcall_compiled_function (fun=138290728, nargs=2, args=0xbfffe3d8) at bytecode.c:519 #41 0x808f353 in Ffuncall (nargs=5, args=0xbfffe3d4) at eval.c:3210 #42 0x8061ae6 in execute_optimized_program ( program=0x86e8b50 "\b¬F\212eb\210ÁÂw\210ÃÄ!¬\005Å\020ª4ÆÇÂÈ#­\002`\026\tÆÊ\016\tÈ#«\013ËÌ\224Ì\225{!\227\026\reb\210ÆÎ\016\tÈ#«\013ÏÌ\224Ì\225{!\020ª\003Â\020)d\016\t«\ad\016\tZª\002d]\036\020\b«0\bÌV«+\016\r«'ÑÒ!«\017ÒÓÔ\016\020\b\"\016\rÕ\b!$\210Ö×\016\rÕ\016\020!Õ\b!Ô\016\020\b\"%ªT\b«*\bÌV«%ÑÒ!«\017ÒØÔ\016\020\b\"\016\rÕ\b!$\210ÖÙÕ\016\020!Õ\b!Ô\016\020\b\"$ª(Ì\016\020U¬\020\016\r«\fÖÚ\016\rÕ\016\020!#"..., stack_depth=8, constants_data=0x865c0a0) at bytecode.c:743 #43 0x8061639 in funcall_compiled_function (fun=140867052, nargs=3, args=0xbfffe540) at bytecode.c:519 #44 0x808f353 in Ffuncall (nargs=4, args=0xbfffe53c) at eval.c:3210 #45 0x809032f in run_hook_with_args_in_buffer (buf=0x86d4510, nargs=4, args=0xbfffe53c, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #46 0x809042d in va_run_hook_with_args (hook_var=136732604, nargs=3) at eval.c:3674 #47 0x811b8fb in signal_after_change (buf=0x86d4510, start=1, orig_end=1, new_end=1025) at insdel.c:2284 #48 0x811ca41 in buffer_insert_string_1 (buf=0x86d4510, pos=1, nonreloc=0xbfffe6a0 "HTTP/1.1 200 OK\r\nDate: Wed, 24 Nov 1999 02:46:26 GMT\r\nServer: Apache/1.3.9 Ben-SSL/1.37 (Unix) PHP/3.0.12\r\nLast-Modified: Sun, 14 Nov 1999 21:59:36 GMT\r\nETag: \"4174e-a27-382f30c8\"\r\nAccept-Ranges: byte"..., reloc=136731044, offset=0, length=1024, flags=0) at insdel.c:2571 #49 0x811f3a6 in buffer_insert_raw_string_1 (buf=0x86d4510, pos=-1, nonreloc=0xbfffe6a0 "HTTP/1.1 200 OK\r\nDate: Wed, 24 Nov 1999 02:46:26 GMT\r\nServer: Apache/1.3.9 Ben-SSL/1.37 (Unix) PHP/3.0.12\r\nLast-Modified: Sun, 14 Nov 1999 21:59:36 GMT\r\nETag: \"4174e-a27-382f30c8\"\r\nAccept-Ranges: byte"..., length=1024, flags=0) at insdel.c:2591 #50 0x81409a6 in read_process_output (proc=141460256) at process.c:915 #51 0x80c1a96 in execute_internal_event (event=139916204) at event-stream.c:2960 #52 0x80c0f75 in Faccept_process_output (process=141460256, timeout_secs=3, timeout_msecs=136731044) at event-stream.c:2647 #53 0x808f1bd in Ffuncall (nargs=3, args=0xbfffeb94) at eval.c:3178 #54 0x8061ae6 in execute_optimized_program ( program=0x86e8560 "À\tÂ\"\207plicati9", stack_depth=3, constants_data=0x860cb10) at bytecode.c:743 #55 0x8061639 in funcall_compiled_function (fun=140972808, nargs=1, args=0xbfffec94) at bytecode.c:519 #56 0x808f353 in Ffuncall (nargs=2, args=0xbfffec90) at eval.c:3210 #57 0x8061ae6 in execute_optimized_program ( program=0x86e7388 "À\t!\032\013®\004ÄÅ!\036\006Ç \210\nÈH\036\t\nÊH®\016\nËH­\tÌ\nÍH\016\016\"£\036\017\016\020®\036\n\211\036\021ÒH«\021\016\021ÓHÔÕÖ\016\021ÒHÔ#Qª\005\016\021ÓH)\036\027\nØH\036\031Ú\036\e\016\017Ük«\004Ý\026\017\016\027Ük«\004Þ\026\027\016\t¬\bßà\t\"\202½", stack_depth=7, constants_data=0x869ab00) at bytecode.c:743 #58 0x8061639 in funcall_compiled_function (fun=141200960, nargs=1, args=0xbfffeda0) at bytecode.c:519 #59 0x808f353 in Ffuncall (nargs=2, args=0xbfffed9c) at eval.c:3210 #60 0x8061ae6 in execute_optimized_program ( program=0x86afad8 "\b«\024Á\n!«\006Ã\n!ª\002\n\f\230«\005Å ª\002\n\032Æ\016\a!\211\036\bÉH\036\n\016\bËH­\bÌ\016\b\211ËH\"\036\rÎ\036\017\016\a\036\020Î\036\021\016\r«\004Ò\026\nÓ\016\a!\211\026\021­\bÔ\016\a\016\021\"?\211\026\021«\004Õª\fÖ\016\n®\002×\016\030\"£¢\026\017\016\021«\aÙ\016\a!ª\003\016\a\026\a\212Ú\n!q\210ÛÜ!\210ÝÞ!«\004Î\026\036\016\037?\026 \016\b\026!)\016\017«\017â\016\017!«\t\016\017\016\a!\210ª!Ú\n!q\210ã \210ä\026%æçèé\016\n\"êëì\016-îïð\016-ñ±\f\210\0162«\013"..., stack_depth=13, constants_data=0x86154a0) at bytecode.c:743 #61 0x8061639 in funcall_compiled_function (fun=140594344, nargs=2, args=0xbfffeec4) at bytecode.c:519 #62 0x808f353 in Ffuncall (nargs=3, args=0xbfffeec0) at eval.c:3210 #63 0x8061ae6 in execute_optimized_program ( program=0x86afa98 "À \210ÁÂ!«\017ÃÂK!«\tÂÄ\rGÆ\r$\210\r«\rÇÈ\r\"«\a\rÄ\225ÆO\025É\r\016\n\"\207ly\001", stack_depth=6, constants_data=0x86155e0) at bytecode.c:743 #64 0x8061639 in funcall_compiled_function (fun=140594372, nargs=1, args=0xbfffefcc) at bytecode.c:519 #65 0x808f353 in Ffuncall (nargs=2, args=0xbfffefc8) at eval.c:3210 #66 0x8061ae6 in execute_optimized_program ( program=0x86d40a8 "\b¬\004Á \210ÂÃ!«\003\f\023ÂÅ!«\023\r«\020Æ\016\a\r@\"«\b\r@\026\b\rA\025\016\b«\a\016\bÉk«\005ÊË!\210ÆÌ\016\b\"«\017Í\016\016ÏH!\016\bÐÑOP\026\bÒ\016\b!ÓU«\n\016\bÔÑO\026\bªð\016\025¬\005\016\026\026\025\016\025;«\b×\016\025\227!\026\025\016\025«3\016\025\016\030·£\211\036\031§«\bÚ\016\031!\210ª\037\016\025Ûs«\bÜ\016\b!\210ª\022\016\025Ýa«\006Þ \210ª\aßà\016\025\"\210)Ò\016\b!áU«\006â\016\b!\207t«\005\016#¬\005\016$«\006å\016\b!\207æç!ppè\016\b!"..., stack_depth=6, constants_data=0x862e8e0) at bytecode.c:743 #67 0x8061639 in funcall_compiled_function (fun=140697340, nargs=1, args=0xbffff0d4) at bytecode.c:519 #68 0x808f353 in Ffuncall (nargs=2, args=0xbffff0d0) at eval.c:3210 #69 0x8061ae6 in execute_optimized_program ( program=0x869f540 "\b¬\004Á \210\n«\026Ã\f!«\021Å\f!«\fÆ\f!\210ÇÈÉÊ!\"\207\016\013¬\005ÌÍ!\207\016\013;¬\aÎÏ\016\013\"\207ÐÑ\016\013\"¬\bÍÒ\016\013P!\207Í\016\013!\207ù", stack_depth=4, constants_data=0x864e580) at bytecode.c:743 #70 0x8061639 in funcall_compiled_function (fun=140687920, nargs=0, args=0xbffff1ec) at bytecode.c:519 #71 0x808f353 in Ffuncall (nargs=1, args=0xbffff1e8) at eval.c:3210 #72 0x80931ec in apply1 (fn=140687920, arg=136731044) at eval.c:3793 #73 0x8065d1a in Fcall_interactively (function=138292436, record_flag=136731068, keys=136731044) at callint.c:394 #74 0x808d7be in Fcommand_execute (cmd=138292436, record=136731068, keys=136731044) at eval.c:2613 #75 0x808f1bd in Ffuncall (nargs=3, args=0xbffff3e4) at eval.c:3178 #76 0x8061ae6 in execute_optimized_program ( program=0x8574be0 "\b\030Á\bÂa«\004ê$\bÄk«\004Ū\034\b¨«\aÆÇ\b\"ª\022\b:«\r\b@¨«\bÆÇ\b@\"ª\002È!\026\t)\016\n«Ut«RË\016\t!\016\t\036\f\036\rÎ\016\tÏ\"\210\016\r­<\016\020¬\023Ñ Ò a«\aÓ pa«\006Ô \210ª\004Õ \210Ö×!­\036ØÙÆ\016\rA«\004Úª\002Û\016\fÜ\016\r!#\"\210Ö\016\035!\210ÞÙ!*\207Î\016\tÏ\"\207", stack_depth=7, constants_data=0x82f2e30) at bytecode.c:743 #77 0x8061639 in funcall_compiled_function (fun=137275364, nargs=1, args=0xbffff4f8) at bytecode.c:519 #78 0x808f353 in Ffuncall (nargs=2, args=0xbffff4f4) at eval.c:3210 #79 0x8067794 in Fcall_interactively (function=137303492, record_flag=136731044, keys=136731044) at callint.c:946 #80 0x808d7be in Fcommand_execute (cmd=137303492, record=136731044, keys=136731044) at eval.c:2613 #81 0x80c4452 in execute_command_event (command_builder=0x8469b10, event=139915972) at event-stream.c:4343 #82 0x80c506c in Fdispatch_event (event=139915972) at event-stream.c:4634 #83 0x806ce6b in Fcommand_loop_1 () at cmdloop.c:575 #84 0x806d0dd in command_loop_1 (dummy=136731044) at cmdloop.c:490 #85 0x8093e4b in condition_case_1 (handlers=136731140, bfun=0x806d090 , barg=136731044, hfun=0x806c1c0 , harg=136731044) at eval.c:1630 #86 0x806d1dc in command_loop_2 (dummy=136731044) at cmdloop.c:252 #87 0x8093d19 in internal_catch (tag=136804996, func=0x806d1a0 , arg=136731044, threw=0x0) at eval.c:1305 #88 0x806c62d in initial_command_loop (load_me=136731044) at cmdloop.c:301 #89 0x8087b37 in xemacs_21_2_b20_i686_pc_linux (argc=1, argv=0xbffff9f4, envp=0xbffff9fc, restart=0) at emacs.c:1873 #90 0x808982d in main (argc=1, argv=0xbffff9f4, envp=0xbffff9fc) at emacs.c:2298 #91 0x40301213 in __libc_start_main (main=0x8089710
, argc=1, argv=0xbffff9f4, init=0x804dc40 <_init>, fini=0x81ccb00 <_fini>, rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff9ec) at ../sysdeps/generic/libc-start.c:90 (gdb) quit OUTPUT OF xemacs>&file ------------------------------------------------------------------------------- Warning: Representation size 4 must match superclass's to override value Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/bin/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: # (unwind-protect ...) specifier-instance(# nil nil nil) # bind (value no-fallback default domain property glyph) glyph-property-instance(#0x168b> image nil nil nil) # bind (no-fallback default domain glyph) glyph-image-instance(#0x168b>) # bind (inhibit-read-only zmacs-region-stays val frame value message) raw-append-progress("Reading [text/html] 2k" 39 #) # bind (tmsg top frame value message label) append-progress(progress "Reading [text/html] 2k" 39 nil) # bind (frame value message label) display-progress(progress "Reading [text/html] 2k" 39) # bind (str args value fmt) progress("Reading [%s] %s" 39 "text/html" "2k") # bind (current-length args) url-after-change-function(1 1025 0) # (unwind-protect ...) # (unwind-protect ...) accept-process-output(# 1) # bind (proc) url-accept-process-output(#) # (unwind-protect ...) # (unwind-protect ...) # bind (process request dest file port server ref-url urlobj proxy-info url) url-http("http://www.cs.indiana.edu/elisp/w3/docs.html") # bind (cached original-url handler url-using-proxy type urlobj url-working-buffer no-cache url) url-retrieve-internally("http://www.cs.indiana.edu/elisp/w3/docs.html" nil) # bind (expected-md5 no-cache url) url-retrieve("http://www.cs.indiana.edu/elisp/w3/docs.html") # bind (x lastbuf w3-current-buffer buf target url) w3-fetch("http://www.cs.indiana.edu/elisp/w3/docs.html") #() call-interactively(w3) command-execute(w3 t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) OUTPUT OF describe-installation ------------------------------------------------------------------------------- uname -a: Linux najohnson 2.2.13 #2 Mon Nov 15 18:04:57 MST 1999 i686 unknown configure '-prefix=/usr' XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/src/xemacs-21.2.20 What installation prefix should install use? /usr What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- ------------------------------------------------------------------------------- From owner-xemacs-beta@xemacs.org Wed Nov 24 00:10:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA19176 for xemacs-beta-out; Wed, 24 Nov 1999 00:10:11 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA19173 for ; Wed, 24 Nov 1999 00:10:06 -0500 Received: by localhost id m11qUgr-000172C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 24 Nov 1999 14:10:01 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> Date: Wed, 24 Nov 1999 14:10:01 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9ogcmzq4y.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: >> Mule, by definition, breaks the kind of code we're discussing. Hrvoje> Why do you keep repeating that? It breaks that kind of Hrvoje> code only for Asian use. First of all, it breaks it for all multilingual use. That means Croats who want to write in Latin-1 and Latin-2 at the same time, and pretty much all Israelis, Greeks, Arabs, and Russians, I bet. Second, I'm repeating it because as far as I know everybody who writes Emacs Lisp would prefer that their code function correctly in as many environments as possible, as long as it costs them nothing to write it that way. You feel that way, too, you've said so. Do you habitually write code _knowing_ that if the wrong somebody borrows it, their application will break? I thought not! There may be a few die-hards who would insist that the cost of fixing this problem be exactly zero, but I doubt that even you or Kyle are among them. The question is how high can it go? I would rather not break anybody's code at all. But code that uses int-char, explicitly or implicitly, is _already_ broken _by design_ unless either the code traps out-of-bounds data (fat chance, it's an optimization in the first place), or we do. Leaving it alone means breaking somebody's XEmacs someday. Why does it matter if that person is an Asian or a polyglot? Kyle's right: we owe our existing users and developers due consideration, and given the current distribution, that may mean compromising reliability for some existing users and many future ones. But Hope is out of Pandora's box; it is no longer possible to avoid some kind of compromise by ignoring the needs of Mule users. "They" is (some of) us, now; we can't go back. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Wed Nov 24 03:08:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA23904 for xemacs-beta-out; Wed, 24 Nov 1999 03:08:25 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA23901 for ; Wed, 24 Nov 1999 03:08:23 -0500 Received: from hniksic by mraz.iskon.hr with local (Exim 3.03 #1 (Debian)) id 11qXTR-0000zW-00 for ; Wed, 24 Nov 1999 09:08:21 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 24 Nov 1999 09:08:21 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 24 Nov 1999 14:10:01 +0900 (JST)" Message-ID: <9t9hfic9uru.fsf@mraz.iskon.hr> Lines: 20 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Second, I'm repeating it because as far as I know everybody who > writes Emacs Lisp would prefer that their code function correctly in > as many environments as possible, as long as it costs them nothing > to write it that way. You feel that way, too, you've said so. Do > you habitually write code _knowing_ that if the wrong somebody > borrows it, their application will break? I don't know how I write code anymore. The MULE APIs have never been documented, and it's never been published what is and what is not safe in Mule. I know my code contained the implicit int->char conversions, because that was easier to write. Mule breaks too much to be worthy of so much consideration at this level. Yes, I believe new C code should adhere to existing abstractions, but I'm not so convinced that we should break (the rest of) the Lisp world for the sake of Asians. I explained to you many times now why I tell all my friends to compile _without_ Mule. I'm not about to repeat it. From owner-xemacs-beta@xemacs.org Wed Nov 24 06:15:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA28995 for xemacs-beta-out; Wed, 24 Nov 1999 06:15:16 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA28992 for ; Wed, 24 Nov 1999 06:15:13 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA12999; Wed, 24 Nov 1999 12:15:03 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003B4; Wed Nov 24 12:15:02 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA26243; Wed, 24 Nov 1999 12:15:01 +0100 To: Nils Bokermann Cc: xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> From: Jan Vroonhof Date: 24 Nov 1999 12:15:00 +0100 In-Reply-To: Nils Bokermann's message of "Tue, 23 Nov 1999 17:33:36 +0100" Message-ID: Lines: 36 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Nils Bokermann writes: > #12 0xb074c in unexec ( > new_name=0xefffed60 "/opt/packages/xemacs-21.2.20/src/xemacs", > old_name=0xefffed38 "/opt/packages/xemacs-21.2.20/src/temacs", > data_start=2565776, bss_start=0, entry_address=0) at unexsol2-6.c:33 Please include less subtle info about your platform next time :-) I think wmperry had a similar problem recently. on some Solaris 2.6 versions the dldump library doesn't work that well... I think the work around would be to change .../src/s/sol2.h from #undef UNEXEC #if OS_RELEASE < 56 #define UNEXEC "unexsol2.o" #else #define UNEXEC "unexsol2-6.o" #endif to #undef UNEXEC #if OS_RELEASE < 56 #define UNEXEC "unexsol2.o" #else #define UNEXEC "unexsol2.o" #endif Could you report back if this works for you too? It is very nice from sun to provide a dumping library with the OS, but it would be even nicer if it worked :-) Jan From owner-xemacs-beta@xemacs.org Wed Nov 24 06:26:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA29269 for xemacs-beta-out; Wed, 24 Nov 1999 06:26:03 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA29263 for ; Wed, 24 Nov 1999 06:26:00 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA13125; Wed, 24 Nov 1999 12:25:54 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003D2; Wed Nov 24 12:25:49 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA26271; Wed, 24 Nov 1999 12:25:49 +0100 To: nn@uswest.net Cc: xemacs-beta@xemacs.org Subject: Re: crash References: From: Jan Vroonhof Date: 24 Nov 1999 12:25:48 +0100 In-Reply-To: nn@uswest.net's message of "Tue, 23 Nov 1999 20:08:12 -0700 (MST)" Message-ID: Lines: 31 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nn@uswest.net writes: > M-x w3 caused xemacs to crash Do you get this consistently? If you can reproduce can you find the out the exact lisp call that is causing this? > #3 0x81c46d5 in MaxLabel (gw=0x8583338, wid=0xbfffd248, hgt=0xbfffd24a, > w0=0xbfffd24c, w1=0xbfffd24e) at xlwgauge.c:967 if( lbl != NULL ) { ---> lw = XTextWidth(font, lbl, strlen(lbl)) ; w = Max( w, lw ) ; } Could you check whether the font and lbl have sensible values in this frame? > #4 0x81c32cc in GaugeResize (w=0x8583338) at xlwgauge.c:327 > #5 0x4002f99b in Initialize () from /usr/X11R6/lib/Xaw95/libXaw3d.so.6 > #6 0x40130185 in CallInitialize () from /usr/X11R6/lib/libXt.so.6 > #7 0x4013014d in CallInitialize () from /usr/X11R6/lib/libXt.so.6 > #8 0x401306a2 in xtCreate () from /usr/X11R6/lib/libXt.so.6 > #9 0x40130b8f in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6 > #10 0x40130cb0 in XtCreateManagedWidget () from /usr/X11R6/lib/libXt.so.6 > #11 0x81bd434 in xaw_create_progress (instance=0x8583158) at lwlib-Xaw.c:808 It is making a new progress bar. This is still very new functionality. I think Andy and E. Falk would love it if you could find out a simple case causing the crash. Jan From owner-xemacs-beta@xemacs.org Wed Nov 24 07:57:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA32227 for xemacs-beta-out; Wed, 24 Nov 1999 07:57:43 -0500 Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA32223 for ; Wed, 24 Nov 1999 07:57:40 -0500 Received: from castor.hrz.uni-bielefeld.de by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FLP008E3DC0YJ@mail.uni-bielefeld.de> for xemacs-beta@xemacs.org; Wed, 24 Nov 1999 13:57:37 +0100 (MET) Received: (from bokerman@localhost) by castor.hrz.uni-bielefeld.de (8.8.6 (PHNE_17135)/8.8.6) id NAA19351; Wed, 24 Nov 1999 13:57:36 +0100 (MET) Date: Wed, 24 Nov 1999 13:57:35 +0100 From: Nils Bokermann Subject: Re: build-failure on solaris2.6 In-reply-to: ; from vroonhof@math.ethz.ch on Wed, Nov 24, 1999 at 12:15:00PM +0100 To: Jan Vroonhof Cc: Nils Bokermann , xemacs-beta@xemacs.org, nilsb@bermuda.de Message-id: <19991124135735.A12017@castor.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: > Nils Bokermann writes: > > > #12 0xb074c in unexec ( > > new_name=0xefffed60 "/opt/packages/xemacs-21.2.20/src/xemacs", > > old_name=0xefffed38 "/opt/packages/xemacs-21.2.20/src/temacs", > > data_start=2565776, bss_start=0, entry_address=0) at unexsol2-6.c:33 > > Please include less subtle info about your platform next time :-) Thought better too much than too less information :-) > > It is very nice from sun to provide a dumping library with the OS, but > it would be even nicer if it worked :-) Hihi ;-) Bye, Nils -- Nils Bokermann Phone: +49 521 88074398 From owner-xemacs-beta@xemacs.org Wed Nov 24 09:21:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA02209 for xemacs-beta-out; Wed, 24 Nov 1999 09:21:58 -0500 Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA02204 for ; Wed, 24 Nov 1999 09:21:56 -0500 Received: from castor.hrz.uni-bielefeld.de by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FLP00A5YH8JUV@mail.uni-bielefeld.de> for xemacs-beta@xemacs.org; Wed, 24 Nov 1999 15:21:55 +0100 (MET) Received: (from bokerman@localhost) by castor.hrz.uni-bielefeld.de (8.8.6 (PHNE_17135)/8.8.6) id PAA28741; Wed, 24 Nov 1999 15:21:54 +0100 (MET) Date: Wed, 24 Nov 1999 15:21:54 +0100 From: Nils Bokermann Subject: Re: build-failure on solaris2.6 In-reply-to: ; from vroonhof@math.ethz.ch on Wed, Nov 24, 1999 at 12:15:00PM +0100 To: Jan Vroonhof Cc: Nils Bokermann , xemacs-beta@xemacs.org, nilsb@bermuda.de Message-id: <19991124152154.A28418@castor.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: > I think wmperry had a similar problem recently. on some Solaris 2.6 > versions the dldump library doesn't work that well... > > I think the work around would be to change .../src/s/sol2.h from > > #undef UNEXEC > #if OS_RELEASE < 56 > #define UNEXEC "unexsol2.o" > #else > #define UNEXEC "unexsol2-6.o" > #endif > > to > > #undef UNEXEC > #if OS_RELEASE < 56 > #define UNEXEC "unexsol2.o" > #else > #define UNEXEC "unexsol2.o" > #endif > > Could you report back if this works for you too? Hmm -- but this won't work too :( Finding pointers to doc strings...done Dumping under the name xemacs Segmentation Fault - core dumped *** Error code 139 (ignored) ... Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me a line -- Nils Bokermann Phone: +49 521 88074398 From owner-xemacs-beta@xemacs.org Wed Nov 24 10:28:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA04800 for xemacs-beta-out; Wed, 24 Nov 1999 10:28:22 -0500 Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA04797 for ; Wed, 24 Nov 1999 10:28:18 -0500 Received: from bt02e0.god.bel.alcatel.be (bt02e0.god.bel.alcatel.be [138.203.144.185]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id QAA17888; Wed, 24 Nov 1999 16:28:12 +0100 (MET) Received: from btzp12.atess.bel.alcatel.be (btzp12.atess.bel.alcatel.be [138.203.12.66]) by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id QAA22160; Wed, 24 Nov 1999 16:27:35 +0100 (MET) Received: from andyppc (btk0hg.atess.bel.alcatel.be) by btzp12.atess.bel.alcatel.be (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with SMTP id <0FLP00D02KAPS3@btzp12.atess.bel.alcatel.be>; Wed, 24 Nov 1999 16:28:01 +0100 (MET) Date: Wed, 24 Nov 1999 15:28:44 +0000 From: Andy Piper Subject: Re: crash In-reply-to: X-Sender: andyp@london.beasys.com (Unverified) To: nn@uswest.net, xemacs-beta@xemacs.org Message-id: <3.0.5.32.19991124152844.00b62490@london.beasys.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA04798 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oh I see. Bill P is using the new progress stuff :) This is currently way beyond the bleeding edge. I don't think I've tried progress gauges with anything other than Motif and MS-Windows. There is a good chance that there is a bug in xlwgauge.c andy At 08:08 PM 11/23/99 -0700, nn@uswest.net wrote: >M-x w3 caused xemacs to crash >I just installed w3-4.0pre.46 >I'm using glibc 2.0 under linux >If someone would like the core dump, or if there is additional >information which would be usefull, and I could furnish, please let me >know. I can be contacted as > >nn@uswest.net > > OUTPUT OF 'where' in gdb >--------------------------------------------------------------------------- ---- >GNU gdb 4.18 >This GDB was configured as "i686-pc-linux-gnu"... >Core was generated by `xemacs'. >Program terminated with signal 11, Segmentation fault. >Reading symbols from /usr/X11R6/lib/Xaw95/libXaw3d.so.6...done. >Reading symbols from /usr/local/lib/libtiff.so.3...done. >Reading symbols from /usr/local/lib/libpng.so.2...done. >Reading symbols from /usr/local/lib/libjpeg.so.6...done. >Reading symbols from /usr/local/lib/libz.so.1...done. >Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. >Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. >Reading symbols from /usr/X11R6/lib/libXt.so.6...done. >Reading symbols from /usr/X11R6/lib/libXext.so.6...done. >Reading symbols from /usr/X11R6/lib/libX11.so.6...done. >Reading symbols from /usr/X11R6/lib/libSM.so.6...done. >Reading symbols from /usr/X11R6/lib/libICE.so.6...done. >Reading symbols from /lib/libdl.so.2...done. >Reading symbols from /lib/libdb.so.3...done. >Reading symbols from /usr/local/lib/libgdbm.so.1...done. >Reading symbols from /usr/local/lib/libgpm.so.1...done. >Reading symbols from /lib/libncurses.so.4...done. >Reading symbols from /lib/libm.so.6...done. >Reading symbols from /lib/libc.so.6...done. >Reading symbols from /lib/ld-linux.so.2...done. >Reading symbols from /lib/libnss_files.so.2...done. >Reading symbols from /lib/libnss_dns.so.2...done. >Reading symbols from /lib/libresolv.so.2...done. >#0 0x40307ab1 in __kill () from /lib/libc.so.6 >(gdb) where >#0 0x40307ab1 in __kill () from /lib/libc.so.6 >#1 0x80895c9 in fatal_error_signal (sig=11) at emacs.c:276 >#2 0x403079b8 in __restore () > at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125 >#3 0x81c46d5 in MaxLabel (gw=0x8583338, wid=0xbfffd248, hgt=0xbfffd24a, > w0=0xbfffd24c, w1=0xbfffd24e) at xlwgauge.c:967 >#4 0x81c32cc in GaugeResize (w=0x8583338) at xlwgauge.c:327 >#5 0x4002f99b in Initialize () from /usr/X11R6/lib/Xaw95/libXaw3d.so.6 >#6 0x40130185 in CallInitialize () from /usr/X11R6/lib/libXt.so.6 >#7 0x4013014d in CallInitialize () from /usr/X11R6/lib/libXt.so.6 >#8 0x401306a2 in xtCreate () from /usr/X11R6/lib/libXt.so.6 >#9 0x40130b8f in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6 >#10 0x40130cb0 in XtCreateManagedWidget () from /usr/X11R6/lib/libXt.so.6 >#11 0x81bd434 in xaw_create_progress (instance=0x8583158) at lwlib-Xaw.c:808 >#12 0x81bb7f3 in instantiate_widget_instance (instance=0x8583158) > at lwlib.c:879 >#13 0x81bb8f4 in lw_make_widget (id=65548, parent=0x8582ff0, pop_up_p=0 '\000') > at lwlib.c:358 >#14 0x81bc1dc in lw_create_widget (type=0x821b499 "progress", > name=0x854c268 "Progress", id=65548, val=0x85343c8, parent=0x8582ff0, > pop_up_p=0 '\000', pre_activate_cb=0, > selection_cb=0x80abff0 , post_activate_cb=0) > at lwlib.c:931 >#15 0x819bbf3 in x_widget_instantiate (image_instance=139996784, > instantiator=138403256, pointer_fg=136731044, pointer_bg=136731044, > dest_mask=239, domain=139583576, type=0x821b499 "progress", wv=0x85343c8) > at glyphs-x.c:2439 >#16 0x819db84 in x_progress_gauge_instantiate (image_instance=139996784, > instantiator=138403256, pointer_fg=136731044, pointer_bg=136731044, > dest_mask=239, domain=139583576) at glyphs-x.c:2580 >#17 0x80fd462 in instantiate_image_instantiator (device=139127048, > domain=139583576, instantiator=138403256, pointer_fg=136731044, > pointer_bg=136731044, dest_mask=239) at glyphs.c:605 >#18 0x81018d4 in image_instantiate (specifier=138402976, matchspec=136516812, > domain=139583576, instantiator=138403256, depth=3) at glyphs.c:2564 >#19 0x808cf55 in call_with_suspended_errors ( > fun=0x8101370 , retval=136516812, class=136852068, > errb={ > really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, nargs=5) at eval.c:2126 >#20 0x817397b in specifier_instance_from_inst_list (specifier=138402976, > matchspec=136516812, domain=139583576, inst_list=138319160, errb={ > really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, depth=3) at specifier.c:2444 >#21 0x8173d47 in specifier_instance (specifier=138402976, matchspec=136516812, > domain=139583576, errb={ > really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, no_fallback=0, depth=1) at specifier.c:2559 >#22 0x8175515 in Fspecifier_instance (specifier=138402976, domain=136731044, > default_=136731044, no_fallback=136731044) at specifier.c:2649 >#23 0x808f1e1 in Ffuncall (nargs=5, args=0xbfffddb8) at eval.c:3178 >#24 0x8061ae6 in execute_optimized_program ( > program=0x85475a8 "À\t!¬\006ÂÀ\t\"\021\t\013N\034Å\f!«\013Æ\f\016\a\016\b\016\t$\024\f)\207\00 3", stack_depth=5, constants_data=0x8309d38) > at bytecode.c:743 >#25 0x8061639 in funcall_compiled_function (fun=137394056, nargs=5, > args=0xbfffdec0) at bytecode.c:519 >#26 0x808f353 in Ffuncall (nargs=6, args=0xbfffdebc) at eval.c:3210 >#27 0x8061ae6 in execute_optimized_program ( > program=0x8547588 "À\tÂ\013\f\r%\207ÿÿÿÿA", stack_depth=6, > constants_data=0x8314bf8) at bytecode.c:743 >#28 0x8061639 in funcall_compiled_function (fun=137394224, nargs=1, > args=0xbfffdfcc) at bytecode.c:519 >#29 0x808f353 in Ffuncall (nargs=2, args=0xbfffdfc8) at eval.c:3210 >#30 0x8061ae6 in execute_optimized_program (program=0x86e9068 "\bÁk?\205¡", > stack_depth=6, constants_data=0x83fe9c0) at bytecode.c:743 >#31 0x8061639 in funcall_compiled_function (fun=138290616, nargs=3, > args=0xbfffe0d0) at bytecode.c:519 >#32 0x808f353 in Ffuncall (nargs=4, args=0xbfffe0cc) at eval.c:3210 >#33 0x8061ae6 in execute_optimized_program ( > program=0x86e8ff0 "\b¬\004Á \020\n@\211\eA\034\r\013@a«.\013\016\006¡\210\f\016\006a«\rÇÈ\016\t!Ê\016\01 3#\210ª\tÌ\016\006\016\013\b#\210Í \210Î «\027ÏÐ !\210ª\020\r\016\006B\nB\022Ì\016\006\016\013\b#\210\016\013Ña­\tÒÓÔ\"\210Õ\ r!*\207s-packÁ", stack_depth=5, constants_data=0x83fe890) at bytecode.c:743 >#34 0x8061639 in funcall_compiled_function (fun=138290560, nargs=4, > args=0xbfffe1d4) at bytecode.c:519 >#35 0x808f353 in Ffuncall (nargs=5, args=0xbfffe1d0) at eval.c:3210 >#36 0x8061ae6 in execute_optimized_program ( > program=0x86e85b8 "À\t\nÃ#\210\fÅa«\bÆ\t\016\a\n#\207È\t\016\a\f\n$\207", > stack_depth=5, constants_data=0x83fea90) at bytecode.c:743 >#37 0x8061639 in funcall_compiled_function (fun=138290644, nargs=3, > args=0xbfffe2d8) at bytecode.c:519 >#38 0x808f353 in Ffuncall (nargs=4, args=0xbfffe2d4) at eval.c:3210 >#39 0x8061ae6 in execute_optimized_program ( > program=0x86e8580 "\b¬\n\t¬\aÂÃÂ!\210\207ÄÅ\b\t#\036\006ÇÈ\016\006\016\t#\210\016\006)\207@ipt ,1", stack_depth=4, constants_data=0x83ff2c8) > at bytecode.c:743 >#40 0x8061639 in funcall_compiled_function (fun=138290728, nargs=2, > args=0xbfffe3d8) at bytecode.c:519 >#41 0x808f353 in Ffuncall (nargs=5, args=0xbfffe3d4) at eval.c:3210 >#42 0x8061ae6 in execute_optimized_program ( > program=0x86e8b50 "\b¬F\212eb\210ÁÂw\210ÃÄ!¬\005Å\020ª4ÆÇÂÈ#­\002`\026\tÆÊ\016\tÈ#«\013ËÌ\224Ì \225{!\227\026\reb\210ÆÎ\016\tÈ#«\013ÏÌ\224Ì\225{!\020ª\003Â\020)d\016\t«\ad \016\tZª\002d]\036\020\b«0\bÌV«+\016\r«'ÑÒ!«\017ÒÓÔ\016\020\b\"\016\rÕ\b!$\2 10Ö×\016\rÕ\016\020!Õ\b!Ô\016\020\b\"%ªT\b«*\bÌV«%ÑÒ!«\017ÒØÔ\016\020\b\"\01 6\rÕ\b!$\210ÖÙÕ\016\020!Õ\b!Ô\016\020\b\"$ª(Ì\016\020U¬\020\016\r«\fÖÚ\016\r Õ\016\020!#"..., stack_depth=8, constants_data=0x865c0a0) at bytecode.c:743 >#43 0x8061639 in funcall_compiled_function (fun=140867052, nargs=3, > args=0xbfffe540) at bytecode.c:519 >#44 0x808f353 in Ffuncall (nargs=4, args=0xbfffe53c) at eval.c:3210 >#45 0x809032f in run_hook_with_args_in_buffer (buf=0x86d4510, nargs=4, > args=0xbfffe53c, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 >#46 0x809042d in va_run_hook_with_args (hook_var=136732604, nargs=3) > at eval.c:3674 >#47 0x811b8fb in signal_after_change (buf=0x86d4510, start=1, orig_end=1, > new_end=1025) at insdel.c:2284 >#48 0x811ca41 in buffer_insert_string_1 (buf=0x86d4510, pos=1, > nonreloc=0xbfffe6a0 "HTTP/1.1 200 OK\r\nDate: Wed, 24 Nov 1999 02:46:26 GMT\r\nServer: Apache/1.3.9 Ben-SSL/1.37 (Unix) PHP/3.0.12\r\nLast-Modified: Sun, 14 Nov 1999 21:59:36 GMT\r\nETag: \"4174e-a27-382f30c8\"\r\nAccept-Ranges: byte"..., reloc=136731044, offset=0, length=1024, flags=0) at insdel.c:2571 >#49 0x811f3a6 in buffer_insert_raw_string_1 (buf=0x86d4510, pos=-1, > nonreloc=0xbfffe6a0 "HTTP/1.1 200 OK\r\nDate: Wed, 24 Nov 1999 02:46:26 GMT\r\nServer: Apache/1.3.9 Ben-SSL/1.37 (Unix) PHP/3.0.12\r\nLast-Modified: Sun, 14 Nov 1999 21:59:36 GMT\r\nETag: \"4174e-a27-382f30c8\"\r\nAccept-Ranges: byte"..., length=1024, flags=0) at insdel.c:2591 >#50 0x81409a6 in read_process_output (proc=141460256) at process.c:915 >#51 0x80c1a96 in execute_internal_event (event=139916204) > at event-stream.c:2960 >#52 0x80c0f75 in Faccept_process_output (process=141460256, timeout_secs=3, > timeout_msecs=136731044) at event-stream.c:2647 >#53 0x808f1bd in Ffuncall (nargs=3, args=0xbfffeb94) at eval.c:3178 >#54 0x8061ae6 in execute_optimized_program ( > program=0x86e8560 "À\tÂ\"\207plicati9", stack_depth=3, > constants_data=0x860cb10) at bytecode.c:743 >#55 0x8061639 in funcall_compiled_function (fun=140972808, nargs=1, > args=0xbfffec94) at bytecode.c:519 >#56 0x808f353 in Ffuncall (nargs=2, args=0xbfffec90) at eval.c:3210 >#57 0x8061ae6 in execute_optimized_program ( > program=0x86e7388 "À\t!\032\013®\004ÄÅ!\036\006Ç \210\nÈH\036\t\nÊH®\016\nËH­\tÌ\nÍH\016\016\"£\036\017\016\020®\036\n\211\03 6\021ÒH«\021\016\021ÓHÔÕÖ\016\021ÒHÔ#Qª\005\016\021ÓH)\036\027\nØH\036\031Ú\ 036\e\016\017Ük«\004Ý\026\017\016\027Ük«\004Þ\026\027\016\t¬\bßà\t\"\202½", stack_depth=7, > constants_data=0x869ab00) at bytecode.c:743 >#58 0x8061639 in funcall_compiled_function (fun=141200960, nargs=1, > args=0xbfffeda0) at bytecode.c:519 >#59 0x808f353 in Ffuncall (nargs=2, args=0xbfffed9c) at eval.c:3210 >#60 0x8061ae6 in execute_optimized_program ( > program=0x86afad8 "\b«\024Á\n!«\006Ã\n!ª\002\n\f\230«\005Å ª\002\n\032Æ\016\a!\211\036\bÉH\036\n\016\bËH­\bÌ\016\b\211ËH\"\036\rÎ\036\0 17\016\a\036\020Î\036\021\016\r«\004Ò\026\nÓ\016\a!\211\026\021­\bÔ\016\a\01 6\021\"?\211\026\021«\004Õª\fÖ\016\n®\002×\016\030\"£¢\026\017\016\021«\aÙ\0 16\a!ª\003\016\a\026\a\212Ú\n!q\210ÛÜ!\210ÝÞ!«\004Î\026\036\016\037?\026 \016\b\026!)\016\017«\017â\016\017!«\t\016\017\016\a!\210ª!Ú\n!q\210ã \210ä\026%æçèé\016\n\"êëì\016-îïð\016-ñ±\f\210\0162«\013"..., stack_depth=13, constants_data=0x86154a0) at bytecode.c:743 >#61 0x8061639 in funcall_compiled_function (fun=140594344, nargs=2, > args=0xbfffeec4) at bytecode.c:519 >#62 0x808f353 in Ffuncall (nargs=3, args=0xbfffeec0) at eval.c:3210 >#63 0x8061ae6 in execute_optimized_program ( > program=0x86afa98 "À \210ÁÂ!«\017ÃÂK!«\tÂÄ\rGÆ\r$\210\r«\rÇÈ\r\"«\a\rÄ\225ÆO\025É\r\016\n\"\207ly \001", stack_depth=6, constants_data=0x86155e0) > at bytecode.c:743 >#64 0x8061639 in funcall_compiled_function (fun=140594372, nargs=1, > args=0xbfffefcc) at bytecode.c:519 >#65 0x808f353 in Ffuncall (nargs=2, args=0xbfffefc8) at eval.c:3210 >#66 0x8061ae6 in execute_optimized_program ( > program=0x86d40a8 "\b¬\004Á \210ÂÃ!«\003\f\023ÂÅ!«\023\r«\020Æ\016\a\r@\"«\b\r@\026\b\rA\025\016\b«\a\01 6\bÉk«\005ÊË!\210ÆÌ\016\b\"«\017Í\016\016ÏH!\016\bÐÑOP\026\bÒ\016\b!ÓU«\n\01 6\bÔÑO\026\bªð\016\025¬\005\016\026\026\025\016\025;«\b×\016\025\227!\026\02 5\016\025«3\016\025\016\030·£\211\036\031§«\bÚ\016\031!\210ª\037\016\025Ûs«\ bÜ\016\b!\210ª\022\016\025Ýa«\006Þ \210ª\aßà\016\025\"\210)Ò\016\b!áU«\006â\016\b!\207t«\005\016#¬\005\016$«\00 6å\016\b!\207æç!ppè\016\b!"..., > stack_depth=6, constants_data=0x862e8e0) at bytecode.c:743 >#67 0x8061639 in funcall_compiled_function (fun=140697340, nargs=1, > args=0xbffff0d4) at bytecode.c:519 >#68 0x808f353 in Ffuncall (nargs=2, args=0xbffff0d0) at eval.c:3210 >#69 0x8061ae6 in execute_optimized_program ( > program=0x869f540 "\b¬\004Á \210\n«\026Ã\f!«\021Å\f!«\fÆ\f!\210ÇÈÉÊ!\"\207\016\013¬\005ÌÍ!\207\016\013;¬ \aÎÏ\016\013\"\207ÐÑ\016\013\"¬\bÍÒ\016\013P!\207Í\016\013!\207ù", stack_depth=4, constants_data=0x864e580) at bytecode.c:743 >#70 0x8061639 in funcall_compiled_function (fun=140687920, nargs=0, > args=0xbffff1ec) at bytecode.c:519 >#71 0x808f353 in Ffuncall (nargs=1, args=0xbffff1e8) at eval.c:3210 >#72 0x80931ec in apply1 (fn=140687920, arg=136731044) at eval.c:3793 >#73 0x8065d1a in Fcall_interactively (function=138292436, > record_flag=136731068, keys=136731044) at callint.c:394 >#74 0x808d7be in Fcommand_execute (cmd=138292436, record=136731068, > keys=136731044) at eval.c:2613 >#75 0x808f1bd in Ffuncall (nargs=3, args=0xbffff3e4) at eval.c:3178 >#76 0x8061ae6 in execute_optimized_program ( > program=0x8574be0 "\b\030Á\bÂa«\004ê$\bÄk«\004Ū\034\b¨«\aÆÇ\b\"ª\022\b:«\r\b@¨«\bÆÇ\b@\"ª\00 2È!\026\t)\016\n«Ut«RË\016\t!\016\t\036\f\036\rÎ\016\tÏ\"\210\016\r­<\016\02 0¬\023Ñ Ò a«\aÓ pa«\006Ô \210ª\004Õ \210Ö×!­\036ØÙÆ\016\rA«\004Úª\002Û\016\fÜ\016\r!#\"\210Ö\016\035!\210ÞÙ!*\20 7Î\016\tÏ\"\207", stack_depth=7, > constants_data=0x82f2e30) at bytecode.c:743 >#77 0x8061639 in funcall_compiled_function (fun=137275364, nargs=1, > args=0xbffff4f8) at bytecode.c:519 >#78 0x808f353 in Ffuncall (nargs=2, args=0xbffff4f4) at eval.c:3210 >#79 0x8067794 in Fcall_interactively (function=137303492, > record_flag=136731044, keys=136731044) at callint.c:946 >#80 0x808d7be in Fcommand_execute (cmd=137303492, record=136731044, > keys=136731044) at eval.c:2613 >#81 0x80c4452 in execute_command_event (command_builder=0x8469b10, > event=139915972) at event-stream.c:4343 >#82 0x80c506c in Fdispatch_event (event=139915972) at event-stream.c:4634 >#83 0x806ce6b in Fcommand_loop_1 () at cmdloop.c:575 >#84 0x806d0dd in command_loop_1 (dummy=136731044) at cmdloop.c:490 >#85 0x8093e4b in condition_case_1 (handlers=136731140, > bfun=0x806d090 , barg=136731044, > hfun=0x806c1c0 , harg=136731044) at eval.c:1630 >#86 0x806d1dc in command_loop_2 (dummy=136731044) at cmdloop.c:252 >#87 0x8093d19 in internal_catch (tag=136804996, > func=0x806d1a0 , arg=136731044, threw=0x0) at eval.c:1305 >#88 0x806c62d in initial_command_loop (load_me=136731044) at cmdloop.c:301 >#89 0x8087b37 in xemacs_21_2_b20_i686_pc_linux (argc=1, argv=0xbffff9f4, > envp=0xbffff9fc, restart=0) at emacs.c:1873 >#90 0x808982d in main (argc=1, argv=0xbffff9f4, envp=0xbffff9fc) > at emacs.c:2298 >#91 0x40301213 in __libc_start_main (main=0x8089710
, argc=1, > argv=0xbffff9f4, init=0x804dc40 <_init>, fini=0x81ccb00 <_fini>, > rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff9ec) > at ../sysdeps/generic/libc-start.c:90 >(gdb) quit > > OUTPUT OF xemacs>&file >--------------------------------------------------------------------------- ---- >Warning: Representation size 4 must match superclass's to override value > >Fatal error (11). >Your files have been auto-saved. >Use `M-x recover-session' to recover them. > >Please report this bug by running the send-pr script included >with XEmacs, or selecting `Send Bug Report' from the help menu. >As a last resort send ordinary email to `crashes@xemacs.org'. >*MAKE SURE* to include the information in the command >M-x describe-installation. > >If at all possible, *please* try to obtain a C stack backtrace; >it will help us immensely in determining what went wrong. >To do this, locate the core file that was produced as a result >of this crash (it's usually called `core' and is located in the >directory in which you started the editor, or maybe in your home >directory), and type > > gdb /usr/bin/xemacs core > >then type `where' when the debugger prompt comes up. >(If you don't have GDB on your system, you might have DBX, >or XDB, or SDB. A similar procedure should work for all of >these. Ask your system administrator if you need more help.) > >Lisp backtrace follows: > > # (unwind-protect ...) > specifier-instance(# nil nil nil) > # bind (value no-fallback default domain property glyph) > glyph-property-instance(#0x168b> image nil nil nil) > # bind (no-fallback default domain glyph) > glyph-image-instance(#0x168b>) > # bind (inhibit-read-only zmacs-region-stays val frame value message) > raw-append-progress("Reading [text/html] 2k" 39 #) > # bind (tmsg top frame value message label) > append-progress(progress "Reading [text/html] 2k" 39 nil) > # bind (frame value message label) > display-progress(progress "Reading [text/html] 2k" 39) > # bind (str args value fmt) > progress("Reading [%s] %s" 39 "text/html" "2k") > # bind (current-length args) > url-after-change-function(1 1025 0) > # (unwind-protect ...) > # (unwind-protect ...) > accept-process-output(# 1) > # bind (proc) > url-accept-process-output(#) > # (unwind-protect ...) > # (unwind-protect ...) > # bind (process request dest file port server ref-url urlobj proxy-info url) > url-http("http://www.cs.indiana.edu/elisp/w3/docs.html") > # bind (cached original-url handler url-using-proxy type urlobj url-working-buffer no-cache url) > url-retrieve-internally("http://www.cs.indiana.edu/elisp/w3/docs.html" nil) > # bind (expected-md5 no-cache url) > url-retrieve("http://www.cs.indiana.edu/elisp/w3/docs.html") > # bind (x lastbuf w3-current-buffer buf target url) > w3-fetch("http://www.cs.indiana.edu/elisp/w3/docs.html") > #() > call-interactively(w3) > command-execute(w3 t) > # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) > execute-extended-command(nil) > # bind (command-debug-status) > call-interactively(execute-extended-command) > # (condition-case ... . error) > # (catch top-level ...) > > > OUTPUT OF describe-installation >--------------------------------------------------------------------------- ---- >uname -a: Linux najohnson 2.2.13 #2 Mon Nov 15 18:04:57 MST 1999 i686 unknown > >configure '-prefix=/usr' > > >XEmacs 21.2-b20 "Yoko" configured for `i686-pc-linux'. > > Where should the build process find the source code? /usr/src/xemacs-21.2.20 > What installation prefix should install use? /usr > What operating system and machine description files should XEmacs use? > `s/linux.h' and `m/intel386.h' > What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch > Should XEmacs use the GNU version of malloc? yes > (Using Doug Lea's new malloc from the GNU C Library.) > Should XEmacs use the relocating allocator for buffers? yes > What window system should XEmacs use? x11 > Where do we find X Windows header files? /usr/X11/include > Where do we find X Windows libraries? /usr/X11/lib > Compiling in support for XAUTH. > Compiling in support for XPM images. > Compiling in support for PNG image handling. > Compiling in support for (builtin) GIF image handling. > Compiling in support for JPEG image handling. > Compiling in support for TIFF image handling. > Compiling in native sound support. > Compiling in support for Berkeley DB. > Compiling in support for GNU DBM. > Compiling in support for ncurses. > Compiling in support for GPM (General Purpose Mouse). > Compiling in support for proper WM_COMMAND handling. > Using Lucid menubars. > Using Lucid scrollbars. > Using Athena-3d native widgets. > Using Athena-3d dialog boxes. > Compiling in DSO module support. > movemail will use "dot-locking" for locking mail spool files. > Compiling in extra code for debugging. > WARNING: --------------------------------------------------------- > WARNING: Compiling in support for runtime error checking. > WARNING: XEmacs will run noticeably more slowly as a result. > WARNING: Error checking is on by default for XEmacs beta releases. > WARNING: --------------------------------------------------------- >--------------------------------------------------------------------------- ---- > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Wed Nov 24 10:36:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05056 for xemacs-beta-out; Wed, 24 Nov 1999 10:36:14 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA05052 for ; Wed, 24 Nov 1999 10:36:10 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA28287; Wed, 24 Nov 1999 16:36:09 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006tx; Wed Nov 24 16:36:08 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA27253; Wed, 24 Nov 1999 16:36:07 +0100 To: Nils Bokermann Cc: xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> From: Jan Vroonhof Date: 24 Nov 1999 16:36:07 +0100 In-Reply-To: Nils Bokermann's message of "Wed, 24 Nov 1999 15:21:54 +0100" Message-ID: Lines: 8 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Nils Bokermann writes: > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > a line Hmmm.. Wmperry also has a sparcbook. Jan From owner-xemacs-beta@xemacs.org Wed Nov 24 10:54:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05756 for xemacs-beta-out; Wed, 24 Nov 1999 10:54:47 -0500 Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA05752 for ; Wed, 24 Nov 1999 10:54:45 -0500 Received: from castor.hrz.uni-bielefeld.de by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FLP00DJDLJ3GI@mail.uni-bielefeld.de> for xemacs-beta@xemacs.org; Wed, 24 Nov 1999 16:54:39 +0100 (MET) Received: (from bokerman@localhost) by castor.hrz.uni-bielefeld.de (8.8.6 (PHNE_17135)/8.8.6) id QAA08120; Wed, 24 Nov 1999 16:54:39 +0100 (MET) Date: Wed, 24 Nov 1999 16:54:38 +0100 From: Nils Bokermann Subject: Re: build-failure on solaris2.6 In-reply-to: ; from vroonhof@math.ethz.ch on Wed, Nov 24, 1999 at 04:36:07PM +0100 To: Jan Vroonhof Cc: Nils Bokermann , xemacs-beta@xemacs.org, nilsb@bermuda.de Message-id: <19991124165438.B28418@castor.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 24, 1999 at 04:36:07PM +0100, Jan Vroonhof wrote: > Nils Bokermann writes: > > > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > > a line > > Hmmm.. Wmperry also has a sparcbook. Hmm.. Then there is something else wrong with this book :( And I DO want xemacs on it ;) Bye, Nils -- Nils Bokermann Phone: +49 521 88074398 From owner-xemacs-beta@xemacs.org Wed Nov 24 13:25:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA11348 for xemacs-beta-out; Wed, 24 Nov 1999 13:25:20 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA11345 for ; Wed, 24 Nov 1999 13:25:18 -0500 Received: (qmail 30707 invoked from network); 24 Nov 1999 18:23:53 -0000 Received: from usrpri2-24.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.89) by biff.kiva.net with SMTP; 24 Nov 1999 18:23:53 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA03304; Wed, 24 Nov 1999 13:27:08 -0500 To: Jan Vroonhof Cc: Nils Bokermann , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 X-Now-Listening-To: Beastie Boys - Dr. Lee, PhD References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Nils Bokermann writes: > > > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > > a line > > Hmmm.. Wmperry also has a sparcbook. _had_ - I couldn't get the new hard drive I bought working in it, so I traded up to a sony vaio. Sweet machine if anyone is thinking of buying one. Linux works great other than the #%!@ winmodem. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 24 13:24:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA11325 for xemacs-beta-out; Wed, 24 Nov 1999 13:24:51 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA11319 for ; Wed, 24 Nov 1999 13:24:41 -0500 Received: (qmail 30523 invoked from network); 24 Nov 1999 18:23:22 -0000 Received: from usrpri2-24.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.89) by biff.kiva.net with SMTP; 24 Nov 1999 18:23:22 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA03299; Wed, 24 Nov 1999 13:26:33 -0500 To: Nils Bokermann Cc: Jan Vroonhof , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 X-Now-Listening-To: Beastie Boys - Dr. Lee, PhD References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 37 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Nils Bokermann writes: > On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: > > I think wmperry had a similar problem recently. on some Solaris 2.6 > > versions the dldump library doesn't work that well... > > > > I think the work around would be to change .../src/s/sol2.h from > > > > #undef UNEXEC > > #if OS_RELEASE < 56 > > #define UNEXEC "unexsol2.o" > > #else > > #define UNEXEC "unexsol2-6.o" > > #endif > > > > to > > > > #undef UNEXEC > > #if OS_RELEASE < 56 > > #define UNEXEC "unexsol2.o" > > #else > > #define UNEXEC "unexsol2.o" > > #endif > > > > Could you report back if this works for you too? > > Hmm -- but this won't work too :( > Finding pointers to doc strings...done > Dumping under the name xemacs > Segmentation Fault - core dumped > *** Error code 139 (ignored) > ... Did you completely reconfigure? You have to regenerate EVERYTHING for this change to take effect. -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 24 13:23:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA11270 for xemacs-beta-out; Wed, 24 Nov 1999 13:23:16 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA11266 for ; Wed, 24 Nov 1999 13:23:12 -0500 Received: (qmail 30101 invoked from network); 24 Nov 1999 18:21:52 -0000 Received: from usrpri2-24.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.89) by biff.kiva.net with SMTP; 24 Nov 1999 18:21:52 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA03294; Wed, 24 Nov 1999 13:25:08 -0500 To: Andy Piper Cc: nn@uswest.net, xemacs-beta@xemacs.org Subject: Re: crash X-Now-Listening-To: Beastie Boys - Ricky s Theme References: <3.0.5.32.19991124152844.00b62490@london.beasys.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes: > Oh I see. Bill P is using the new progress stuff :) Hehehe... Boom! > This is currently way beyond the bleeding edge. I don't think I've tried > progress gauges with anything other than Motif and MS-Windows. There is > a good chance that there is a bug in xlwgauge.c I didn't mean for those to get into the CVS tree - I was playing around with them. They work ok for me here. If you grep for (fboundp 'progress) in w3-parse.el and url-http.el, you should be able to remove them easily. Or just (fmakunbound 'progress) -Bill P. From owner-xemacs-beta@xemacs.org Wed Nov 24 19:12:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA21680 for xemacs-beta-out; Wed, 24 Nov 1999 19:12:51 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA21676 for ; Wed, 24 Nov 1999 19:12:48 -0500 Received: by localhost id m11qmWj-000173C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 25 Nov 1999 09:12:45 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> Date: Thu, 25 Nov 1999 09:12:45 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <9t9hfic9uru.fsf@mraz.iskon.hr> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Mule breaks too much to be worthy of so much consideration Hrvoje> at this level. I see it differently: Mule breaks too much to not get fixed. Mule breaks so much that it needs to be fixed by design, not by patching a few weak spots. The questions are what needs to be fixed and how, in what order. Life would be a lot easier for Mule fixers if there were no int-char. You and Kyle are rightly objecting to that as a burden on the traditional (ASCII -> Latin-1) developer/user base. So I'm looking for a compromise. But because there are fundamental design problems in the current Mule, we need to think about the transition to a sensible design. That is going to break things; but if handled well the transition can be a minimal burden. One simple fix is to remove Mule. Of course I'll object to that, but that's certainly an option for the XEmacs community. I won't be able to afford to remain a member, though :-( -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Wed Nov 24 19:35:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA22171 for xemacs-beta-out; Wed, 24 Nov 1999 19:35:05 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA22167 for ; Wed, 24 Nov 1999 19:35:01 -0500 Received: by crystal.WonderWorks.COM id QQhquc18107; Wed, 24 Nov 1999 16:34:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14396.33842.957468.846764@crystal.WonderWorks.COM> Date: Wed, 24 Nov 1999 16:34:58 -0800 (PST) From: Kyle Jones To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stephen J. Turnbull writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Mule breaks too much to be worthy of so much consideration > Hrvoje> at this level. > > I see it differently: Mule breaks too much to not get fixed. Mule > breaks so much that it needs to be fixed by design, not by patching > a few weak spots. I agree with this. > The questions are what needs to be fixed and how, in what order. Life > would be a lot easier for Mule fixers if there were no int-char. You > and Kyle are rightly objecting to that as a burden on the traditional > (ASCII -> Latin-1) developer/user base. So I'm looking for a > compromise. But because there are fundamental design problems in the > current Mule, we need to think about the transition to a sensible > design. That is going to break things; but if handled well the > transition can be a minimal burden. Yes, we need a transition plan, but I don't think it necessarily needs to break things. Right now we have the --with-mule configuration option. We could leave MULE as it is and essentially abandon it. We add a new configure option, --with-i18n=MULE that gives access to the old MULE code for those who want it or have apps that need it. --with-i18n=NEWGOOP can build XEmacs with whatever the new design is. With this, we don't break MULE code or non-MULE code. Stuff only breaks if you build with --with-i18n=, which is ideal since it continues to let us roll releases during development. I think using a name other than MULE for the new design will be an overall win. The MULE name has baggage associated with it that I think we want to be free of. > One simple fix is to remove Mule. That is certainly not something I want to see. From owner-xemacs-beta@xemacs.org Wed Nov 24 20:07:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA22897 for xemacs-beta-out; Wed, 24 Nov 1999 20:07:49 -0500 Received: from max3p131.smart.net (max3p131.smart.net [216.84.81.131]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA22894 for ; Wed, 24 Nov 1999 20:07:44 -0500 Received: (from jmiller@localhost) by max3p131.smart.net (8.9.3/8.9.3) id UAA04700; Wed, 24 Nov 1999 20:04:47 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14396.35630.884784.880490@max3p131.smart.net> Date: Wed, 24 Nov 1999 20:04:46 -0500 (EST) To: xemacs-beta@xemacs.org Subject: Re: crash In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "JV" == Jan Vroonhof writes: I get what appears to be the same or similar crash. Redhat 6.1, fairly recent cvs... maybe a week old. All i have to do is load tests/glyph-test.el and eval it. Ka-boom. Lisp backtrace follows: # (unwind-protect ...) specifier-instance(# nil nil nil) # bind (value no-fallback default domain property glyph) glyph-property-instance(#0x30dd> image nil nil nil) # bind (no-fallback default domain glyph) glyph-image-instance(#0x30dd>) (set-image-instance-property (glyph-image-instance pgauge) :percent x) ) (while (<= x 100) (set-image-instance-property (glyph-image-instance pgauge) :percent x) (setq x (+ x 5)) (sit-for 0.1)) ) # bind (x) (let ((x 0)) (while (<= x 100) (set-image-instance-property ... :percent x) (setq x ...) (sit-for 0.1))) ) # bind (current-load-list) # (unwind-protect ...) # bind (standard-output) eval-buffer("glyph-test.el") # bind (command-debug-status) call-interactively(eval-buffer) command-execute(eval-buffer t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) Segmentation fault (core dumped) Reading symbols from /lib/libnss_files.so.2...done. #0 0x403114e1 in __kill () from /lib/libc.so.6 (gdb) where #0 0x403114e1 in __kill () from /lib/libc.so.6 #1 0x8083b41 in fatal_error_signal (sig=11) at emacs.c:276 #2 0x40311408 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x819ec63 in MaxLabel (gw=0x8561e48, wid=0xbfffe100, hgt=0xbfffe102, w0=0xbfffe104, w1=0xbfffe106) at xlwgauge.c:967 #4 0x819da7e in GaugeResize (w=0x8561e48) at xlwgauge.c:327 #5 0x40060487 in Initialize () from /usr/X11R6/lib/libXaw3d.so.6 #6 0x4014d405 in CallInitialize () from /usr/X11R6/lib/libXt.so.6 #7 0x4014d3cd in CallInitialize () from /usr/X11R6/lib/libXt.so.6 #8 0x4014d913 in xtCreate () from /usr/X11R6/lib/libXt.so.6 #9 0x4014ddd1 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6 #10 0x4014ded1 in XtCreateManagedWidget () from /usr/X11R6/lib/libXt.so.6 #11 0x8198401 in xaw_create_progress (instance=0x851b110) at lwlib-Xaw.c:808 #12 0x8196a58 in instantiate_widget_instance (instance=0x851b110) at lwlib.c:879 #13 0x8196b34 in lw_make_widget (id=65544, parent=0x85252b0, pop_up_p=0 '\000') at lwlib.c:358 #14 0x819735e in lw_create_widget (type=0x81f7339 "progress", name=0x84ec820 "ok", id=65544, val=0x853b2c0, parent=0x85252b0, pop_up_p=0 '\000', pre_activate_cb=0, selection_cb=0x80a39f0 , post_activate_cb=0) at lwlib.c:931 ---Type to continue, or q to quit--- #15 0x8179cfc in x_widget_instantiate (image_instance=139613320, instantiator=139613208, pointer_fg=136627076, pointer_bg=136627076, dest_mask=239, domain=139686624, type=0x81f7339 "progress", wv=0x853b2c0) at glyphs-x.c:2439 #16 0x817bbf4 in x_progress_gauge_instantiate (image_instance=139613320, instantiator=139613208, pointer_fg=136627076, pointer_bg=136627076, dest_mask=239, domain=139686624) at glyphs-x.c:2580 #17 0x80ec491 in instantiate_image_instantiator (device=139505808, domain=139686624, instantiator=139613208, pointer_fg=136627076, pointer_bg=136627076, dest_mask=239) at glyphs.c:605 #18 0x80f01a7 in image_instantiate (specifier=139613760, matchspec=136369548, domain=139686624, instantiator=139613208, depth=3) at glyphs.c:2564 #19 0x8086da2 in call_with_suspended_errors ( fun=0x80efce0 , retval=136369548, class=136748100, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, nargs=5) at eval.c:2126 From owner-xemacs-beta@xemacs.org Wed Nov 24 23:37:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA28577 for xemacs-beta-out; Wed, 24 Nov 1999 23:37:39 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA28572 for ; Wed, 24 Nov 1999 23:37:35 -0500 Received: by localhost id m11qqeq-000173C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Thu, 25 Nov 1999 13:37:24 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14396.48388.457894.599629@turnbull.sk.tsukuba.ac.jp> Date: Thu, 25 Nov 1999 13:37:24 +0900 (JST) To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <14396.33842.957468.846764@crystal.WonderWorks.COM> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> <14396.33842.957468.846764@crystal.WonderWorks.COM> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> Right now we have the --with-mule configuration option. We Kyle> could leave MULE as it is and essentially abandon it. We Kyle> add a new configure option, --with-i18n=MULE that gives Kyle> access to the old MULE code for those who want it or have Kyle> apps that need it. OK by me. Note that this could easily result in a definitive break with the FSF line of development if we take advantage of the freedom that --with-i18n=NEWGOOP gives us in terms of design. Kyle> --with-i18n=NEWGOOP can build XEmacs with whatever the new Kyle> design is. With this, we don't break MULE code or non-MULE Kyle> code. Stuff only breaks if you build with Kyle> --with-i18n=, which is ideal since Kyle> it continues to let us roll releases during development. At some point, code using int-char will have to be retired; but the transition period will be long and the people who want the new stuff can bear the burden of hunting it down. What about byte-compiler warnings and maybe runtime debugging output a la Ebola for the --with-i18n=no case (the byte-compiler warnings would be automatic, the runtime stuff would be optional for volunteers willing to help fix stuff)? I'm happy with this. One caveat is that I can't volunteer to deal with the autoconf magic, I just don't have the skills. The other caveat is that Ben has already expressed opposition to this; he wants --with-mule gone. Kyle> I think using a name other than MULE for the new design will Kyle> be an overall win. The MULE name has baggage associated Kyle> with it that I think we want to be free of. "Steve" would do except that it has the same semantic connotations as "Mule". :-) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Thu Nov 25 03:58:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA02913 for xemacs-beta-out; Thu, 25 Nov 1999 03:58:54 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA02900; Thu, 25 Nov 1999 03:58:47 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw301.ecc.u-tokyo.ac.jp [133.11.171.251]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id RAA22363; Thu, 25 Nov 1999 17:58:38 +0900 (JST) Mail-Copies-To: never To: xemacs-patches@xemacs.org Cc: Adrian Aichner , XEmacs Beta List Subject: [texinfo] @ifnottex (was Re: @ifnottex: ...) References: <14389.55379.594174.575910@lasker.666.com> <873dtybyv9.fsf@dp50.ecc.u-tokyo.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Thu_Nov_25_18:15:30_1999-1" Date: 25 Nov 1999 18:15:30 +0900 In-Reply-To: (Adrian Aichner's message of "Mon, 22 Nov 1999 11:41:58 +0100") Message-ID: <87iu2r6ifh.fsf_-_@dp50.ecc.u-tokyo.ac.jp> Lines: 67 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Thu_Nov_25_18:15:30_1999-1 Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > Yoshiki> You only need to add just these two lines to handle > Yoshiki> @ifnottex. It's semantically equivalent to @ifinfo when > Yoshiki> formatting Info. > > Yoshiki> (put 'ifnottex 'texinfo-format 'texinfo-discard-line) > Yoshiki> (put 'ifnottex 'texinfo-end 'texinfo-discard-command) > > Can you send a patch to xemacs-patches? > > I will be happy to test it. rms said, the patch to add @ifnottex handling is adding a new feature and it won't go into 20.5. That means syncing with 20.5 will not have @ifnottex handling. So there's no reason waiting for 20.5 w.r.t @ifnottex. Here's the patch against texinfmt.el 1999-11-25 Yoshiki Hayashi * texinfmt.el: Handle @ifnottex. --Multipart_Thu_Nov_25_18:15:30_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: inline; filename="texinfmt.el.diff" Content-Transfer-Encoding: 7bit Index: texinfmt.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-packages/wp/texinfo/texinfmt.el,v retrieving revision 1.4 diff -u -r1.4 texinfmt.el --- texinfmt.el 1998/07/10 09:30:38 1.4 +++ texinfmt.el 1999/11/25 08:52:34 @@ -2093,7 +2093,7 @@ (setq fill-column existing-fill-column))) -;;; @ifinfo, @iftex, @tex, @ifhtml, @html +;;; @ifinfo, @iftex, @tex, @ifhtml, @html, @ifnottex (put 'ifinfo 'texinfo-format 'texinfo-discard-line) (put 'ifinfo 'texinfo-end 'texinfo-discard-command) @@ -2121,6 +2121,9 @@ (delete-region texinfo-command-start (progn (re-search-forward "@end html[ \t]*\n") (point)))) + +(put 'ifnottex 'texinfo-format 'texinfo-discard-line) +(put 'ifnottex 'texinfo-end 'texinfo-discard-command) ;;; @titlepage --Multipart_Thu_Nov_25_18:15:30_1999-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Thu_Nov_25_18:15:30_1999-1-- From owner-xemacs-beta@xemacs.org Thu Nov 25 04:00:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA02986 for xemacs-beta-out; Thu, 25 Nov 1999 04:00:06 -0500 Received: from btmplq.god.bel.alcatel.be (gate.alcatel.be [195.207.101.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA02982 for ; Thu, 25 Nov 1999 04:00:04 -0500 Received: from btzp12.atess.bel.alcatel.be ([138.203.12.66]) by btmplq.god.bel.alcatel.be (8.9.3+Sun/8.9.1) with ESMTP id JAA24026; Thu, 25 Nov 1999 09:59:53 +0100 (MET) Received: from andyppc (btk0hg.atess.bel.alcatel.be) by btzp12.atess.bel.alcatel.be (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with SMTP id <0FLQ00002X0296@btzp12.atess.bel.alcatel.be>; Thu, 25 Nov 1999 10:00:02 +0100 (MET) Date: Thu, 25 Nov 1999 09:00:46 +0000 From: Andy Piper Subject: Re: crash In-reply-to: <14396.35630.884784.880490@max3p131.smart.net> X-Sender: andyp@london.beasys.com To: jmiller@smart.net, xemacs-beta@xemacs.org Message-id: <3.0.5.32.19991125090046.009c7230@london.beasys.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset=us-ascii References: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 08:04 PM 11/24/99 -0500, Jeff Miller wrote: >>>>>> "JV" == Jan Vroonhof writes: > >I get what appears to be the same or similar crash. > >Redhat 6.1, fairly recent cvs... maybe a week old. All i have to do >is load tests/glyph-test.el and eval it. Ka-boom. Well I have finally loaded RH 6.0 onto my home PC so when I get around to building XEmacs on that I'll take a look. Currently I'm trying to get my NT/cygwin config sorted out. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Nov 25 04:52:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA05456 for xemacs-beta-out; Thu, 25 Nov 1999 04:52:50 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA05450 for ; Thu, 25 Nov 1999 04:52:45 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA00546; Thu, 25 Nov 1999 10:52:43 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0008T; Thu Nov 25 10:52:36 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA28658; Thu, 25 Nov 1999 10:52:36 +0100 To: Kyle Jones Cc: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t From: Jan Vroonhof Date: 25 Nov 1999 10:52:35 +0100 In-Reply-To: Kyle Jones's message of "Wed, 24 Nov 1999 16:34:58 -0800 (PST)" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > Yes, we need a transition plan, but I don't think it necessarily > needs to break things. Right now we have the --with-mule > configuration option. Yes, and it is a big maintenance headache. See broken calendar and jka-compr packages. Jan From owner-xemacs-beta@xemacs.org Thu Nov 25 08:33:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA12955 for xemacs-beta-out; Thu, 25 Nov 1999 08:33:06 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA12946 for ; Thu, 25 Nov 1999 08:32:55 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id OAA19816; Thu, 25 Nov 1999 14:32:49 +0100 To: XEmacs Beta List Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> <14396.33842.957468.846764@crystal.WonderWorks.COM> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 25 Nov 1999 14:32:49 +0100 In-Reply-To: Kyle Jones's message of "Wed, 24 Nov 1999 16:34:58 -0800 (PST)" Message-ID: <9t9u2maitmm.fsf@mraz.iskon.hr> Lines: 19 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > Stephen J. Turnbull writes: > > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > > > Hrvoje> Mule breaks too much to be worthy of so much consideration > > Hrvoje> at this level. > > > > I see it differently: Mule breaks too much to not get fixed. Mule > > breaks so much that it needs to be fixed by design, not by patching > > a few weak spots. > > I agree with this. So do I, except that no two persons seem to agree on the desirable design traits, and no one person has volunteered to implement any of it. I'd love to be proven wrong on all this. From owner-xemacs-beta@xemacs.org Thu Nov 25 17:03:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA22772 for xemacs-beta-out; Thu, 25 Nov 1999 17:03:56 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA22769 for ; Thu, 25 Nov 1999 17:03:50 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id OAA21359; Thu, 25 Nov 1999 14:03:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14397.45617.789578.987839@lasker.666.com> Date: Thu, 25 Nov 1999 14:03:29 -0800 (PST) From: Martin Buchholz To: wmperry@aventail.com Cc: Nils Bokermann , Jan Vroonhof , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 In-Reply-To: <86bt8j925j.fsf@megalith.bp.aventail.com> References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> <86bt8j925j.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "B" == William M Perry writes: B> Nils Bokermann writes: >> On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: >> > I think wmperry had a similar problem recently. on some Solaris 2.6 >> > versions the dldump library doesn't work that well... >> > >> > I think the work around would be to change .../src/s/sol2.h from >> > >> > #undef UNEXEC >> > #if OS_RELEASE < 56 >> > #define UNEXEC "unexsol2.o" >> > #else >> > #define UNEXEC "unexsol2-6.o" >> > #endif >> > >> > to >> > >> > #undef UNEXEC >> > #if OS_RELEASE < 56 >> > #define UNEXEC "unexsol2.o" >> > #else >> > #define UNEXEC "unexsol2.o" >> > #endif >> > >> > Could you report back if this works for you too? >> >> Hmm -- but this won't work too :( >> Finding pointers to doc strings...done >> Dumping under the name xemacs >> Segmentation Fault - core dumped >> *** Error code 139 (ignored) >> ... B> Did you completely reconfigure? You have to regenerate EVERYTHING for this B> change to take effect. It seems highly unlikely that the unexec's for Solaris have to be changed. This stuff has worked for years, at least for Solaris < 2.7. "Georg Nikodym " is the expert. There has to be a lot of evidence to the contrary. So I veto this patch for the time being. Martin From owner-xemacs-beta@xemacs.org Thu Nov 25 17:19:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA23036 for xemacs-beta-out; Thu, 25 Nov 1999 17:19:29 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA23031; Thu, 25 Nov 1999 17:19:22 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id OAA22491; Thu, 25 Nov 1999 14:19:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14397.46555.352061.354596@lasker.666.com> Date: Thu, 25 Nov 1999 14:19:07 -0800 (PST) From: Martin Buchholz To: Kyle Jones Cc: XEmacs Beta List , XEmacs Mule , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <14396.33842.957468.846764@crystal.WonderWorks.COM> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> <14396.33842.957468.846764@crystal.WonderWorks.COM> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> Stephen J. Turnbull writes: >> >>>>> "Hrvoje" == Hrvoje Niksic writes: >> Hrvoje> Mule breaks too much to be worthy of so much consideration Hrvoje> at this level. >> >> I see it differently: Mule breaks too much to not get fixed. Mule >> breaks so much that it needs to be fixed by design, not by patching >> a few weak spots. Kyle> I agree with this. >> The questions are what needs to be fixed and how, in what order. Life >> would be a lot easier for Mule fixers if there were no int-char. You >> and Kyle are rightly objecting to that as a burden on the traditional >> (ASCII -> Latin-1) developer/user base. So I'm looking for a >> compromise. But because there are fundamental design problems in the >> current Mule, we need to think about the transition to a sensible >> design. That is going to break things; but if handled well the >> transition can be a minimal burden. Kyle> Yes, we need a transition plan, but I don't think it necessarily Kyle> needs to break things. Right now we have the --with-mule Kyle> configuration option. We could leave MULE as it is and Kyle> essentially abandon it. We add a new configure option, Kyle> --with-i18n=MULE that gives access to the old MULE code for those Kyle> who want it or have apps that need it. --with-i18n=NEWGOOP can Kyle> build XEmacs with whatever the new design is. With this, we Kyle> don't break MULE code or non-MULE code. Stuff only breaks if you Kyle> build with --with-i18n=, which is ideal Kyle> since it continues to let us roll releases during development. Kyle> I think using a name other than MULE for the new design will be Kyle> an overall win. The MULE name has baggage associated with it Kyle> that I think we want to be free of. >> One simple fix is to remove Mule. Kyle> That is certainly not something I want to see. Conceptually, it should be trivial to have a --with-mule build that that acts in a Latin-1 way -- provide a function that makes sure that only 'binary is used for all encoding/decoding operations. This way there will be no unexpected surprises decoding tar.gz files or whatever. This should probably be implemented using a language environment. Maybe it should even be the default ???!!?? And in this case users could still explicitly edit, say, Latin-2 files using C-u C-x C-f foo RET iso-8859-2 RET This is similar in spirit to FSF Emacs' --unibyte flag, but seems cleaner. Ben? (What will not work, however, is using the `font trick' (i.e. specifying a Latin-2 font in a non-mule XEmacs) for editing Latin-2 files. I suppose we could change the registry setting for all one-byte charsets in this language environment so that all iso8859-* fonts would be valid for latin-1 instead of just iso8859-1. (get-charset 'latin-iso8859-1) # I've added xemacs-mule to the CC list. Martin From owner-xemacs-beta@xemacs.org Thu Nov 25 17:34:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA23446 for xemacs-beta-out; Thu, 25 Nov 1999 17:34:22 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA23443; Thu, 25 Nov 1999 17:34:20 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id OAA22504; Thu, 25 Nov 1999 14:34:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14397.47465.607847.71511@lasker.666.com> Date: Thu, 25 Nov 1999 14:34:17 -0800 (PST) From: Martin Buchholz To: Jan Vroonhof Cc: Kyle Jones , XEmacs Beta List , XEmacs Mule Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Kyle Jones writes: >> Yes, we need a transition plan, but I don't think it necessarily >> needs to break things. Right now we have the --with-mule >> configuration option. Jan> Yes, and it is a big maintenance headache. See broken calendar and Jan> jka-compr packages. Yes, all of those have to be fixed. We could look to see if they have been fixed for FSF Emacs 20. Unfortunately, we may need more infrastructure to fix them `properly'. Martin From owner-xemacs-beta@xemacs.org Thu Nov 25 18:33:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA25272 for xemacs-beta-out; Thu, 25 Nov 1999 18:33:59 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA25269 for ; Thu, 25 Nov 1999 18:33:56 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id PAA22580; Thu, 25 Nov 1999 15:33:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14397.51041.618000.665446@lasker.666.com> Date: Thu, 25 Nov 1999 15:33:53 -0800 (PST) From: Martin Buchholz To: Yoshiki Hayashi Cc: Adrian Aichner , XEmacs Beta List Subject: Re: [texinfo] @ifnottex (was Re: @ifnottex: ...) In-Reply-To: <87iu2r6ifh.fsf_-_@dp50.ecc.u-tokyo.ac.jp> References: <14389.55379.594174.575910@lasker.666.com> <873dtybyv9.fsf@dp50.ecc.u-tokyo.ac.jp> <87iu2r6ifh.fsf_-_@dp50.ecc.u-tokyo.ac.jp> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've committed Yoshiki's patch to CVS. >>>>> "Y" == Yoshiki Hayashi writes: Y> 1999-11-25 Yoshiki Hayashi Y> * texinfmt.el: Handle @ifnottex. Martin From owner-xemacs-beta@xemacs.org Thu Nov 25 18:35:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA25368 for xemacs-beta-out; Thu, 25 Nov 1999 18:35:48 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id SAA25358 for ; Thu, 25 Nov 1999 18:35:46 -0500 Received: (qmail 16368 invoked from network); 25 Nov 1999 23:34:29 -0000 Received: from usrpri2-33.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.98) by biff.kiva.net with SMTP; 25 Nov 1999 23:34:29 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id SAA05237; Thu, 25 Nov 1999 18:37:46 -0500 To: martin@xemacs.org Cc: Nils Bokermann , Jan Vroonhof , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> <86bt8j925j.fsf@megalith.bp.aventail.com> <14397.45617.789578.987839@lasker.666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 53 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > >>>>> "B" == William M Perry writes: > > B> Nils Bokermann writes: > >> On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: > >> > I think wmperry had a similar problem recently. on some Solaris 2.6 > >> > versions the dldump library doesn't work that well... > >> > > >> > I think the work around would be to change .../src/s/sol2.h from > >> > > >> > #undef UNEXEC > >> > #if OS_RELEASE < 56 > >> > #define UNEXEC "unexsol2.o" > >> > #else > >> > #define UNEXEC "unexsol2-6.o" > >> > #endif > >> > > >> > to > >> > > >> > #undef UNEXEC > >> > #if OS_RELEASE < 56 > >> > #define UNEXEC "unexsol2.o" > >> > #else > >> > #define UNEXEC "unexsol2.o" > >> > #endif > >> > > >> > Could you report back if this works for you too? > >> > >> Hmm -- but this won't work too :( > >> Finding pointers to doc strings...done > >> Dumping under the name xemacs > >> Segmentation Fault - core dumped > >> *** Error code 139 (ignored) > >> ... > > B> Did you completely reconfigure? You have to regenerate EVERYTHING for this > B> change to take effect. > > It seems highly unlikely that the unexec's for Solaris have to be > changed. This stuff has worked for years, at least for Solaris < 2.7. > "Georg Nikodym " is the expert. There has to be a > lot of evidence to the contrary. So I veto this patch for the time > being. The sparcbook is the only 2.6 or higher box I have access to, and I was never able to build successfully on it using the built-in dldump() support in unexsol2-6.c I've seen other posts on comp.emacs.xemacs about similar build failures, that were on non-sparcbook machines though. -Bill P. From owner-xemacs-beta@xemacs.org Thu Nov 25 21:02:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA28152 for xemacs-beta-out; Thu, 25 Nov 1999 21:02:18 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA28148; Thu, 25 Nov 1999 21:02:14 -0500 Received: by localhost id m11rAiC-000177C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Fri, 26 Nov 1999 11:02:12 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14397.59940.483520.755789@turnbull.sk.tsukuba.ac.jp> Date: Fri, 26 Nov 1999 11:02:12 +0900 (JST) To: XEmacs Beta List , XEmacs Mule , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed In-Reply-To: <14397.46555.352061.354596@lasker.666.com> References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> <14396.33842.957468.846764@crystal.WonderWorks.COM> <14397.46555.352061.354596@lasker.666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "mb" == Martin Buchholz writes: mb> Conceptually, it should be trivial to have a --with-mule build mb> that that acts in a Latin-1 way -- provide a function that mb> makes sure that only 'binary is used for all encoding/decoding mb> operations. This way there will be no unexpected surprises mb> decoding tar.gz files or whatever. This should probably be mb> implemented using a language environment. Maybe it should mb> even be the default ???!!?? Welcome, Martin! A lot of this was hashed over a couple of weeks ago (on a CC list), I put forward a pretty detailed proposal which Ben reviewed. As soon as I finish grading final exams I'll get back to that. You were on the CC list, so you should have a copy; if not I can send you a digest of the relevant discussion. Olivier Galibert has a pretty detailed plan for dealing with the `unibyte' issue. No naming problems, it will all be totally automatic. As for new architecture, Ben's pretty much signed off on that, as has Steve. We can call it Mule or not; at a high level, it will have to integrate with existing Mule APPs[1] for backward compatibility, but internally we are substantially diverging from FSF already. I think it's time for a clean break _if_ Ben and Olivier have the resources to follow up on the plans they've already suggested. Ben at least has a lot of other things in mind I know, but he seemed to put pretty high priority on Mule when we were discussing it earlier. Footnotes: [1] Application Programming Practices. I will not dignify the current mess with the name "interface". -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Fri Nov 26 03:56:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA08041 for xemacs-beta-out; Fri, 26 Nov 1999 03:56:54 -0500 Received: from komaba.ecc.u-tokyo.ac.jp (m.komaba.ecc.u-tokyo.ac.jp [157.82.50.211]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA08034; Fri, 26 Nov 1999 03:56:43 -0500 Received: from dp50.ecc.u-tokyo.ac.jp (fw302.ecc.u-tokyo.ac.jp [133.11.171.252]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id RAA22079; Fri, 26 Nov 1999 17:56:28 +0900 (JST) Mail-Copies-To: never To: Hrvoje Niksic Cc: Jan Vroonhof , xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: Re: Empty string in mini buffer history References: <874sffsumz.fsf@dp50.ecc.u-tokyo.ac.jp> <9t9bt8n5411.fsf@mraz.iskon.hr> <9t9emdi22vk.fsf@mraz.iskon.hr> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Fri_Nov_26_18:13:16_1999-1" Date: 26 Nov 1999 18:13:16 +0900 In-Reply-To: <9t9emdi22vk.fsf@mraz.iskon.hr> (Hrvoje Niksic's message of "Mon, 22 Nov 1999 12:15:59 +0100") Message-ID: <87ln7ly5sj.fsf@dp50.ecc.u-tokyo.ac.jp> Lines: 113 User-Agent: T-gnus/6.13.2 (based on Pterodactyl Gnus v0.97) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i686-pc-linux) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Fri_Nov_26_18:13:16_1999-1 Content-Type: text/plain; charset=US-ASCII Hrvoje Niksic writes: > Jan Vroonhof writes: > > > Hrvoje Niksic writes: > > > > > Recording zero-length input makes sense in the situations where what > > > you record really is a zero-length string. It does not make sense and > > > is annoying in the situations where just typing RET activates a > > > default. > > > > In that case typing RET to activate a default should maybe put that > > default value in the history? > > Yes, that would be very very nice. Then this would satisfy everyone. Note with this patch applied, read-from-minibuffer returns default value when it is given and user enters an empty string. FSF version returns empty string instead. Right now there's no code using this argument and XEmacs has extra argument ABBREV-TABLE, I don't think this will raise a compatibility problem. 1999-11-26 Yoshiki Hayashi * minibuf.el (read-from-minibuffer): Add optional argument DEFAULT to have better mini-buffer history support. (completing-read): Pass default to read-from-minibuffer. (read-buffer): Pass default to completing-read. --Multipart_Fri_Nov_26_18:13:16_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: inline; filename="minibuf.el.diff" Content-Transfer-Encoding: 7bit Index: minibuf.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/minibuf.el,v retrieving revision 1.14.2.9 diff -u -r1.14.2.9 minibuf.el --- minibuf.el 1999/11/22 10:19:08 1.14.2.9 +++ minibuf.el 1999/11/26 08:53:27 @@ -344,7 +344,8 @@ keymap readp history - abbrev-table) + abbrev-table + default) "Read a string from the minibuffer, prompting with string PROMPT. If optional second arg INITIAL-CONTENTS is non-nil, it is a string to be inserted into the minibuffer before reading input. @@ -366,6 +367,8 @@ Positions are counted starting from 1 at the beginning of the list. Sixth arg ABBREV-TABLE, if non-nil, becomes the value of `local-abbrev-table' in the minibuffer. +Seventh arg DEFAULT, if non-nil, will be returned when user enters + an empty string. See also the variable completion-highlight-first-word-only for control over completion display." @@ -490,8 +493,13 @@ (let* ((val (progn (set-buffer buffer) (if minibuffer-exit-hook (run-hooks 'minibuffer-exit-hook)) - (buffer-string))) - (histval val) + (if (and (eq (char-after (point-min)) nil) + default) + default + (buffer-string)))) + (histval (if (and default (string= val "")) + default + val)) (err nil)) (if readp (condition-case e @@ -784,7 +792,9 @@ minibuffer-local-completion-map minibuffer-local-must-match-map) nil - history)) + history + nil + default)) (if (and (string= ret "") default) default @@ -1434,7 +1444,8 @@ result) (while (progn (setq result (completing-read prompt alist nil require-match - nil 'buffer-history)) + nil 'buffer-history + (if default (buffer-name default)))) (cond ((not (equal result "")) nil) ((not require-match) --Multipart_Fri_Nov_26_18:13:16_1999-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Fri_Nov_26_18:13:16_1999-1-- From owner-xemacs-beta@xemacs.org Fri Nov 26 05:46:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA11481 for xemacs-beta-out; Fri, 26 Nov 1999 05:46:57 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA11438; Fri, 26 Nov 1999 05:45:54 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA28005; Fri, 26 Nov 1999 11:41:53 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006pW; Fri Nov 26 11:41:43 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA01265; Fri, 26 Nov 1999 11:41:43 +0100 To: martin@xemacs.org Cc: Kyle Jones , XEmacs Beta List , XEmacs Mule Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t From: Jan Vroonhof Date: 26 Nov 1999 11:41:43 +0100 In-Reply-To: Martin Buchholz's message of "Thu, 25 Nov 1999 14:34:17 -0800 (PST)" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > Yes, all of those have to be fixed. We could look to see if they have > been fixed for FSF Emacs 20. They have already have been fixed (we just need to get the d*mn packages released). I was just alluding to the fact unless you stick an apel style compatibility layer in all the versions (which I am not convinced is a good idea) having yet another build variant is going to be awful. Jan From owner-xemacs-beta@xemacs.org Fri Nov 26 07:29:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA14155 for xemacs-beta-out; Fri, 26 Nov 1999 07:29:39 -0500 Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA14151; Fri, 26 Nov 1999 07:29:35 -0500 Received: from cr308749-a.wlfdle1.on.wave.home.com ([24.112.10.88]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991126122736.MFAC6014.mail.rdc3.on.home.com@cr308749-a.wlfdle1.on.wave.home.com>; Fri, 26 Nov 1999 04:27:36 -0800 Received: (from georgn@localhost) by cr308749-a.wlfdle1.on.wave.home.com (8.9.3+Sun/8.9.3) id HAA08557; Fri, 26 Nov 1999 07:29:32 -0500 (EST) From: Georg Nikodym MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14398.32043.809439.112042@cr308749-a.wlfdle1.on.wave.home.com> Date: Fri, 26 Nov 1999 07:29:31 -0500 (EST) To: wmperry@aventail.com Cc: martin@xemacs.org, Nils Bokermann , Jan Vroonhof , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: build-failure on solaris2.6 In-Reply-To: <86so1uuoqd.fsf@megalith.bp.aventail.com> References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> <86bt8j925j.fsf@megalith.bp.aventail.com> <14397.45617.789578.987839@lasker.666.com> <86so1uuoqd.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: georgn@home.com Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "WMP" == William M Perry writes: WMP> Martin Buchholz writes: >> >>>>> "B" == William M Perry writes: >> B> Nils Bokermann writes: >> >> On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof wrote: >> >> > I think wmperry had a similar problem recently. on some >> >> > Solaris 2.6 versions the dldump library doesn't work that >> >> > well... >> >> > >> >> > I think the work around would be to change .../src/s/sol2.h >> >> > from >> >> > >> >> > #undef UNEXEC if OS_RELEASE < 56 define UNEXEC "unexsol2.o" >> >> > #else define UNEXEC "unexsol2-6.o" endif >> >> > >> >> > to >> >> > >> >> > #undef UNEXEC if OS_RELEASE < 56 define UNEXEC "unexsol2.o" >> >> > #else define UNEXEC "unexsol2.o" endif >> >> > >> >> > Could you report back if this works for you too? >> >> >> >> Hmm -- but this won't work too :( Finding pointers to doc >> >> strings...done Dumping under the name xemacs Segmentation Fault >> >> - core dumped >> >> *** Error code 139 (ignored) >> >> ... >> B> Did you completely reconfigure? You have to regenerate EVERYTHING B> for this change to take effect. >> >> It seems highly unlikely that the unexec's for Solaris have to be >> changed. This stuff has worked for years, at least for Solaris < >> 2.7. "Georg Nikodym " is the expert. >> There has to be a lot of evidence to the contrary. So I veto this >> patch for the time being. WMP> The sparcbook is the only 2.6 or higher box I have access to, WMP> and I was never able to build successfully on it using the WMP> built-in dldump() support in unexsol2-6.c WMP> I've seen other posts on comp.emacs.xemacs about similar build WMP> failures, that were on non-sparcbook machines though. If somebody can provide me with enough information that I might reasonably attempt to re-produce this problem then I'd be happy to investigate. Specifically, the information I'm looking for is: - solaris version, including patches (showrev -p will list the latter) - hardware platform info - gcc version (and any relevant info about config) - xemacs version and complete configuration info However, the best outcome is that I'll start the wheels turning on a patch. If using dynodump (the pre-2.6 Solaris dumping code) works for these problem cases, then maybe a switch in configure would be better? From owner-xemacs-beta@xemacs.org Fri Nov 26 07:44:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA14559 for xemacs-beta-out; Fri, 26 Nov 1999 07:44:41 -0500 Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA14556 for ; Fri, 26 Nov 1999 07:44:38 -0500 Received: from castor.hrz.uni-bielefeld.de by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FLT002EG22B0U@mail.uni-bielefeld.de> for xemacs-beta@xemacs.org; Fri, 26 Nov 1999 13:44:36 +0100 (MET) Received: (from bokerman@localhost) by castor.hrz.uni-bielefeld.de (8.8.6 (PHNE_17135)/8.8.6) id NAA03781; Fri, 26 Nov 1999 13:44:31 +0100 (MET) Date: Fri, 26 Nov 1999 13:44:31 +0100 From: Nils Bokermann Subject: Success on solaris2.6 [STIKE :) (Was Re: build-failure on solaris2.6) In-reply-to: ; from vroonhof@math.ethz.ch on Wed, Nov 24, 1999 at 04:36:07PM +0100 To: Jan Vroonhof Cc: Nils Bokermann , xemacs-beta@xemacs.org, nilsb@bermuda.de Message-id: <19991126134431.A3694@castor.hrz.uni-bielefeld.de> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Nov 24, 1999 at 04:36:07PM +0100, Jan Vroonhof wrote: > Nils Bokermann writes: > > > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > > a line > > Hmmm.. Wmperry also has a sparcbook. After a new compilation (and configure) I have a XEmacs running :-) Bye, Nils (and Thanks for help) -- Nils Bokermann Phone: +49 521 88074398 From owner-xemacs-beta@xemacs.org Fri Nov 26 09:28:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA17515 for xemacs-beta-out; Fri, 26 Nov 1999 09:28:26 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA17509 for ; Fri, 26 Nov 1999 09:28:19 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id PAA25912; Fri, 26 Nov 1999 15:28:14 +0100 To: XEmacs Beta List Subject: Re: build-failure on solaris2.6 References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> <86bt8j925j.fsf@megalith.bp.aventail.com> <14397.45617.789578.987839@lasker.666.com> <86so1uuoqd.fsf@megalith.bp.aventail.com> <14398.32043.809439.112042@cr308749-a.wlfdle1.on.wave.home.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 26 Nov 1999 15:28:14 +0100 In-Reply-To: Georg Nikodym's message of "Fri, 26 Nov 1999 07:29:31 -0500 (EST)" Message-ID: <9t9d7sx8gzl.fsf@mraz.iskon.hr> Lines: 12 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Georg Nikodym writes: > However, the best outcome is that I'll start the wheels turning on a > patch. I assume you mean a Solaris patch. If the symptom really is the result of a Solaris bug, patch will be definitely useful because people can be told to patch up their systems to make XEmacs work. Also, configure can check the Solaris version and the existence of the life-saving patch, and decide whether to use dynodump or dldump() based on that information. From owner-xemacs-beta@xemacs.org Fri Nov 26 12:27:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA25341 for xemacs-beta-out; Fri, 26 Nov 1999 12:27:37 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id MAA25338 for ; Fri, 26 Nov 1999 12:27:35 -0500 Received: (qmail 5006 invoked from network); 26 Nov 1999 17:26:18 -0000 Received: from usrpri2-46.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.111) by biff.kiva.net with SMTP; 26 Nov 1999 17:26:18 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id MAA09274; Fri, 26 Nov 1999 12:29:35 -0500 To: Nils Bokermann Cc: Jan Vroonhof , xemacs-beta@xemacs.org, nilsb@bermuda.de Subject: Re: Success on solaris2.6 [STIKE :) (Was Re: build-failure on solaris2.6) X-Now-Listening-To: John Mellencamp - Ain't Even Done With The Night References: <19991123173336.A18059@castor.hrz.uni-bielefeld.de> <19991124152154.A28418@castor.hrz.uni-bielefeld.de> <19991126134431.A3694@castor.hrz.uni-bielefeld.de> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Nils Bokermann writes: > On Wed, Nov 24, 1999 at 04:36:07PM +0100, Jan Vroonhof wrote: > > Nils Bokermann writes: > > > > > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > > > a line > > > > Hmmm.. Wmperry also has a sparcbook. > > > After a new compilation (and configure) I have a XEmacs running :-) Is this using the unexsol2.o or unexsol2-6.o? -Bill P. From owner-xemacs-beta@xemacs.org Fri Nov 26 19:04:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA02534 for xemacs-beta-out; Fri, 26 Nov 1999 19:04:13 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA02531 for ; Fri, 26 Nov 1999 19:04:10 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id TAA23068; Fri, 26 Nov 1999 19:11:22 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com (mushiva-5.ecf.teradyne.com [131.101.192.125]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id BAA20094; Sat, 27 Nov 1999 01:03:58 +0100 (MET) To: Andreas Jaeger Cc: XEmacs Beta List Subject: imenu.el; Sync with FSF 20.4 is in the queue since August X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 27 Nov 1999 01:03:40 +0100 Message-ID: Lines: 22 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hello Andreas, I have tested imenu.el; Sync with FSF 20.4 by Christoph Wedler which can be found at http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00077.html I would like to suggest that this patch should be applied to xemacs-packages\libs\xemacs-base\imenu.el INSTEAD of my earlier patches http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00054.html and http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00064.html Schöne Grüße, Adrian From owner-xemacs-beta@xemacs.org Fri Nov 26 23:19:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA09459 for xemacs-beta-out; Fri, 26 Nov 1999 23:19:13 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA09455 for ; Fri, 26 Nov 1999 23:19:10 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id NAA04643; Sat, 27 Nov 1999 13:17:08 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Fix this X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 27 Nov 1999 13:17:08 +0900 Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Somebody left the XEmacs CVS in a fucked up state. Never do this. Compiling files without .elc... Done cd /usr/local/devel/xemacs-builds/xemacs-21.2/man && make info make[1]: Entering directory `/usr/local/devel/xemacs-builds/xemacs-21.2/man' makeinfo -o ../info/cl.info cl.texi Making info file `../info/cl.info' from `cl.texi'. makeinfo -o ../info/custom.info custom.texi Making info file `../info/custom.info' from `custom.texi'. makeinfo -o ../info/emodules.info emodules.texi Making info file `../info/emodules.info' from `emodules.texi'. makeinfo -o ../info/external-widget.info external-widget.texi Making info file `../info/external-widget.info' from `external-widget.texi'. makeinfo -o ../info/info.info info.texi Making info file `../info/info.info' from `info.texi'. info.texi:69: No matching `@end ifnottex'. info.texi:77: Unmatched `@end'. makeinfo: Removing output file `../info/info.info' due to errors; use --force to preserve. make[1]: *** [../info/info.info] Error 2 make[1]: Leaving directory `/usr/local/devel/xemacs-builds/xemacs-21.2/man' make: *** [info] Error 2 From owner-xemacs-beta@xemacs.org Fri Nov 26 23:34:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA09978 for xemacs-beta-out; Fri, 26 Nov 1999 23:34:22 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA09969; Fri, 26 Nov 1999 23:34:13 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id UAA08275; Fri, 26 Nov 1999 20:34:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14399.24386.685515.394889@lasker.666.com> Date: Fri, 26 Nov 1999 20:34:10 -0800 (PST) From: Martin Buchholz To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: Fix this In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Somebody left the XEmacs CVS in a fucked up state. Never do this. sb> Compiling files without .elc... Done sb> cd /usr/local/devel/xemacs-builds/xemacs-21.2/man && make info sb> make[1]: Entering directory `/usr/local/devel/xemacs-builds/xemacs-21.2/man' sb> makeinfo -o ../info/cl.info cl.texi sb> Making info file `../info/cl.info' from `cl.texi'. sb> makeinfo -o ../info/custom.info custom.texi sb> Making info file `../info/custom.info' from `custom.texi'. sb> makeinfo -o ../info/emodules.info emodules.texi sb> Making info file `../info/emodules.info' from `emodules.texi'. sb> makeinfo -o ../info/external-widget.info external-widget.texi sb> Making info file `../info/external-widget.info' from `external-widget.texi'. sb> makeinfo -o ../info/info.info info.texi sb> Making info file `../info/info.info' from `info.texi'. sb> info.texi:69: No matching `@end ifnottex'. sb> info.texi:77: Unmatched `@end'. sb> makeinfo: Removing output file `../info/info.info' due to errors; use --force to preserve. sb> make[1]: *** [../info/info.info] Error 2 sb> make[1]: Leaving directory `/usr/local/devel/xemacs-builds/xemacs-21.2/man' sb> make: *** [info] Error 2 I don't typically do commits without at least being able to build. You must be using some old broken makeinfo. Both versions 3.12f and 4.0 of makeinfo work for me. Upgrade. If you look at the source file info.texi, you'll see that the complaint lines 69 and 77 are in fact matching each other, so there is no obvious workaround for this brokenness, except perhaps to change all the @ifnottex to @ifinfo. Upgrade. Martin From owner-xemacs-beta@xemacs.org Sat Nov 27 04:09:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA16481 for xemacs-beta-out; Sat, 27 Nov 1999 04:09:24 -0500 Received: from localhost.localdomain (ae02191.powerup.com.au [203.147.161.191]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA16475 for ; Sat, 27 Nov 1999 04:09:14 -0500 Received: from netscape.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id SAA24252 for ; Sat, 27 Nov 1999 18:57:38 +1000 Message-ID: <383F9CFE.95450DB@netscape.net> Date: Sat, 27 Nov 1999 18:57:34 +1000 From: "Peter B. West" Organization: Dis X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, Chinese, zh, Japanese, ja, Korean, ko, Russian,  ¾ù MIME-Version: 1.0 To: xemacs-beta Subject: Problems with CVS build Content-Type: multipart/mixed; boundary="------------A1B04D5E1CB9A52A9490CA11" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a multi-part message in MIME format. --------------A1B04D5E1CB9A52A9490CA11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I encountered the following problems in building packages from the CVS sources: make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/oa/text-modes' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- ispell fsf-compat xemacs-base -- filladapt.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/xemacs-base/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/fsf-compat/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/oa/ispell/auto-autoloads... Symbol's value as variable is void: ispell-xemacs xemacs exiting. make[2]: *** [filladapt.elc] Error 255 make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/comm/eudc' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- fsf-compat xemacs-base bbdb -- eudc.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... xemacs exiting.Cannot open load file: /opt2/src/xemacs/xemacs-packages/comm/bbdb/lisp/auto-autoloads make[2]: *** [eudc.elc] Error 255 make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/libs/mail-lib' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- xemacs-base -- browse-url.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/xemacs-base/auto-autoloads... Compiling /opt2/src/xemacs/xemacs-packages/libs/mail-lib/browse-url.el... Loading cl-macs... (file cl-macs.el is newer) While compiling toplevel forms in file /opt2/src/xemacs/xemacs-packages/libs/mail-lib/browse-url.el: !! File error (("Cannot open load file" "term")) Done --------------------------------- Note that I do not have the bbdb package, which probably means I should not have eudc either. I do have term.el from the eterm package. The following warning is thrown when I open my first file: (1) (warning/warning) Autoload error in: /usr/local/lib/xemacs/xemacs-packages/lisp/ispell/auto-autoloads: Symbol's value as variable is void: ispell-xemacs How do I fix this one? When compiling viper I ran into a problem with viper.texi. Attached is a patch for that problem. There were two alternatives for fixing this trivial problem, so maybe the author should be consulted. I have no idea about patching - where the patch should go, how it should be created, etc - so advice is welcome. In Domino. Peter -- __ /__ Peter B. West pbwest@netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" --------------A1B04D5E1CB9A52A9490CA11 Content-Type: text/plain; charset=us-ascii; name="viper.texi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="viper.texi.patch" --- viper.texi Sat Nov 27 02:31:11 1999 +++ viper.texi.patched Sat Nov 27 02:54:10 1999 @@ -3427,7 +3427,7 @@ @item m . Set the Emacs mark (@pxref{Emacs Preliminaries}) at point. @item m ^ -Set the Emacs mark (@xref{Emacs Preliminaries}) back to where it was last +Set the Emacs mark (@xref{Emacs Preliminaries},) back to where it was last set with the @kbd{m.} command. This is useful when you set the mark with @kbd{m.}, but then some other command (such as @kbd{L} or @kbd{G}) changes it in a way that you didn't like. --------------A1B04D5E1CB9A52A9490CA11-- From owner-xemacs-beta@xemacs.org Sat Nov 27 04:29:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA16694 for xemacs-beta-out; Sat, 27 Nov 1999 04:29:11 -0500 Received: from localhost.localdomain (ae02191.powerup.com.au [203.147.161.191]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA16690 for ; Sat, 27 Nov 1999 04:29:05 -0500 Received: from netscape.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id TAA24282 for ; Sat, 27 Nov 1999 19:16:44 +1000 Message-ID: <383FA179.5128839B@netscape.net> Date: Sat, 27 Nov 1999 19:16:41 +1000 From: "Peter B. West" Organization: Dis X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, Chinese, zh, Japanese, ja, Korean, ko, Russian,  ¾ù MIME-Version: 1.0 To: xemacs-beta Subject: ChangeLog entry for viper.texi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Sorry, forgot a ChangeLog entry. 1999-11-27 Peter B. West * viper.texi: Add trailing `,' omitted after xref entry. -- __ /__ Peter B. West pbwest@netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" From owner-xemacs-beta@xemacs.org Sat Nov 27 04:39:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA16875 for xemacs-beta-out; Sat, 27 Nov 1999 04:39:21 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA16871; Sat, 27 Nov 1999 04:39:16 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id BAA16733; Sat, 27 Nov 1999 01:38:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14399.42654.178260.635076@lasker.666.com> Date: Sat, 27 Nov 1999 01:38:38 -0800 (PST) From: Martin Buchholz To: XEmacs Patches , "Peter B. West" , Michael Kifer Cc: xemacs-beta Subject: Re: ChangeLog entry for viper.texi In-Reply-To: <383FA179.5128839B@netscape.net> References: <383FA179.5128839B@netscape.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In future, please submit patches to xemacs-patches@xemacs.org. viper is special - Michael Kifer is the maintainer. Michael, please review. 1999-11-27 Peter B. West * viper.texi: Add trailing `,' omitted after xref entry. --- viper.texi Sat Nov 27 02:54:10 1999 +++ viper.texi.patched Sat Nov 27 02:54:10 1999 @@ -3427,7 +3427,7 @@ @item m . Set the Emacs mark (@pxref{Emacs Preliminaries}) at point. @item m ^ -Set the Emacs mark (@xref{Emacs Preliminaries}) back to where it was last +Set the Emacs mark (@xref{Emacs Preliminaries},) back to where it was last set with the @kbd{m.} command. This is useful when you set the mark with @kbd{m.}, but then some other command (such as @kbd{L} or @kbd{G}) changes it in a way that you didn't like. From owner-xemacs-beta@xemacs.org Sat Nov 27 06:09:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA18978 for xemacs-beta-out; Sat, 27 Nov 1999 06:09:22 -0500 Received: from localhost.localdomain (ae02191.powerup.com.au [203.147.161.191]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA18971 for ; Sat, 27 Nov 1999 06:09:04 -0500 Received: from netscape.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id UAA24403 for ; Sat, 27 Nov 1999 20:55:16 +1000 Message-ID: <383FB88F.DA38B188@netscape.net> Date: Sat, 27 Nov 1999 20:55:12 +1000 From: "Peter B. West" Organization: Dis X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, Chinese, zh, Japanese, ja, Korean, ko, Russian,  ¾ù MIME-Version: 1.0 To: xemacs-beta Subject: Binary editing problems persist Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when using hexl-mode to edit a file, whose coding had been set to binary, I have just re-compiled from the latest CVS sources, and the problem persists. Did I mention that I compile --with-mule? In the past I have looked at the documentation and code involved in file coding in a Mule environment, and given myself a fright. I have also looked on in bemusement at some of the exchanges in this list about file coding. Does anyone have any suggestions as to how this problem can be resolved? Can it be solved? Is there an assumption that one of the EOL transformation must always be applied? The info has this: Each of the coding systems that appear in this list--except for `binary', which means no conversion of any kind--specifies how and whether to convert printing characters, but leaves the choice of end-of-line conversion to be decided based on the contents of each file. and... In contrast, the coding system `binary' specifies no character code conversion at all--none for non-Latin-1 byte values and none for end of line. This is useful for reading or writing binary files, tar files, and other files that must be examined verbatim. The easiest way to edit a file with no conversion of any kind is with the `M-x find-file-literally' command. This uses `binary', and also suppresses other XEmacs features that might convert the file contents before you see them. *Note Visiting::. Note the reference to `find-file-literally'. grepping my source files yields only one reference, in files.el, as follows: (if rawfile ;; #### FSF 20.3 sets buffer-file-coding-system to ;; `no-conversion' here. Should we copy? It also ;; makes `find-file-literally' a local variable ;; and sets it to t. nil (after-find-file error (not nowarn)) (setq buf (current-buffer)))) Setting `binary' by hand, as noted, does not prevent bitrot. Has no one else seen this problem? What is the avenue of attack? Is this the sort of change that is guaranteed to break something else? Yours faithfully, Peter -- __ /__ Peter B. West pbwest@netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" From owner-xemacs-beta@xemacs.org Sat Nov 27 10:51:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA25101 for xemacs-beta-out; Sat, 27 Nov 1999 10:51:06 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA25098 for ; Sat, 27 Nov 1999 10:51:05 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id QAA20754; Sat, 27 Nov 1999 16:48:31 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11rk4r-00026E-00; Sat, 27 Nov 1999 16:47:57 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 510D318BA; Sat, 27 Nov 1999 16:47:56 +0100 (CET) To: Adrian Aichner Cc: XEmacs Beta List , Christoph Wedler Subject: Re: imenu.el; Sync with FSF 20.4 is in the queue since August References: From: Andreas Jaeger Date: 27 Nov 1999 16:47:56 +0100 In-Reply-To: Adrian Aichner's message of "27 Nov 1999 01:03:40 +0100" Message-ID: Lines: 29 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Adrian Aichner writes: > Hello Andreas, > I have tested > imenu.el; Sync with FSF 20.4 > by > Christoph Wedler > which can be found at > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00077.html > I would like to suggest that this patch should be applied to > xemacs-packages\libs\xemacs-base\imenu.el > INSTEAD of my earlier patches > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00054.html > and > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00064.html As this patch has been approved already, I've added it now to the CVS archive. Thanks Christoph for the patch, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Sat Nov 27 11:03:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA25297 for xemacs-beta-out; Sat, 27 Nov 1999 11:03:11 -0500 Received: from lsppc4.epfl.ch (lsppc4.epfl.ch [128.178.75.18]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA25290; Sat, 27 Nov 1999 11:03:08 -0500 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id RAA11243; Sat, 27 Nov 1999 17:03:07 +0100 To: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: LDAP extended and revamped X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Sat_Nov_27_17:02:52_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 27 Nov 1999 17:03:06 +0100 Message-ID: Lines: 673 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: multipart/mixed; boundary="Multipart_Sat_Nov_27_17:02:52_1999-1" Content-Transfer-Encoding: 7bit --Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: text/plain; charset=US-ASCII Here's a new patch to the current LDAP code that takes into account the recent discussion on the subject. The LDAP code design remains unchanged, it consists of two layers: - a low level layer that closely matches the C LDAP API. These functions that used to be named `*-internal' are now named more simply: `ldap-open', `ldap-close', `ldap-search', `ldap-add', `ldap-modify'. They should be used directly for very specific purposes (such as multiple operations on a connection) only. - a higher-level layer provides a more convenient way to access LDAP directories hiding the subtleties of handling the connection, translating arguments and ensuring compliance with LDAP internationalization rules and formats (currently partly implemented only). This layer provides atomic operations for searches, modification, addition and deletion of multiple entries at once: ldap-search-entries, ldap-add-entries, ldap-delete-entries and ldap-modify-entries *** IMPORTANT NOTE *** Due to the function renaming, this patch introduces an incompatible change that breaks the packages using the current LDAP API, most notably EUDC and W3. A new version of EUDC is ready for commit if the patch is accepted, please notify me. Oscar --Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: text/plain; charset=US-ASCII 1999-11-27 Oscar Figueiredo * eldap.h (Fldap_search) Renamed from Fldap_search_internal: (Fldap_add, Fldap_modify, Fldap_delete): New functions * eldap.c (Qadd, Qreplace): New constant symbols (Fldap_open): Use the LDAP_OPT_RESTART option to avoid interruptions by XEmacs signals Remove unnecessary calls to slow_down_interrupts and speed_up_interrupts (Fldap_search): Renamed from Fldap_search_internal Added new optional parameter VERBOSE that triggers progress messages display Remove unnecessary calls to slow_down_interrupts and speed_up_interrupts LDAP result code analysis rewritten (Fldap_add, Fldap_modify, Fldap_delete): New functions (syms_of_eldap): Define the new symbols and functions --Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: text/plain; charset=US-ASCII 1999-11-27 Oscar Figueiredo * ldap.el (toplevel): Test if LDAP support has been compiled in (ldap-verbose): New option (ldap-search-entries): Renamed from ldap-search Conditionalize message display on ldap-verbose (ldap-add-entries, ldap-modify-entries, ldap-delete-entries): New defuns --Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ldap.patch" Content-Transfer-Encoding: 7bit Index: src/eldap.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/eldap.c,v retrieving revision 1.13.2.10 diff -u -u -r1.13.2.10 eldap.c --- eldap.c 1999/10/24 03:48:33 1.13.2.10 +++ eldap.c 1999/11/27 15:22:33 @@ -54,6 +54,9 @@ static Lisp_Object Qkrbv41, Qkrbv42; /* Deref policy */ static Lisp_Object Qnever, Qalways, Qfind; +/* Modification types (Qdelete is defined in general.c) */ +static Lisp_Object Qadd, Qreplace; + /************************************************************************/ /* Utility Functions */ @@ -313,6 +316,9 @@ if ((err = ldap_set_option (ld, LDAP_OPT_REFERRALS, LDAP_OPT_ON)) != LDAP_SUCCESS) signal_ldap_error (ld, NULL, err); + if ((err = ldap_set_option (ld, LDAP_OPT_RESTART, + LDAP_OPT_ON)) != LDAP_SUCCESS) + signal_ldap_error (ld, NULL, err); #else /* not HAVE_LDAP_SET_OPTION */ ld->ld_deref = ldap_deref; ld->ld_timelimit = ldap_timelimit; @@ -322,12 +328,11 @@ #else /* not LDAP_REFERRALS */ ld->ld_options = 0; #endif /* not LDAP_REFERRALS */ + /* XEmacs uses interrupts (SIGIO,SIGALRM), LDAP calls need to ignore them */ + ld->ld_options |= LDAP_OPT_RESTART; #endif /* not HAVE_LDAP_SET_OPTION */ - /* ldap_bind_s calls select and may be wedged by SIGIO. */ - slow_down_interrupts (); err = ldap_bind_s (ld, ldap_binddn, ldap_passwd, ldap_auth); - speed_up_interrupts (); if (err != LDAP_SUCCESS) signal_simple_error ("Failed binding to the server", build_string (ldap_err2string (err))); @@ -365,7 +370,6 @@ struct berval **vals; }; - static Lisp_Object ldap_search_unwind (Lisp_Object unwind_obj) { @@ -378,7 +382,7 @@ return Qnil; } -DEFUN ("ldap-search-internal", Fldap_search_internal, 2, 7, 0, /* +DEFUN ("ldap-search", Fldap_search, 2, 8, 0, /* Perform a search on an open LDAP connection. LDAP is an LDAP connection object created with `ldap-open'. FILTER is a filter string for the search as described in RFC 1558. @@ -389,13 +393,14 @@ for each matching entry. If nil return all available attributes. If ATTRSONLY is non-nil then only the attributes are retrieved, not the associated values. -If WITHDN is non-nil each entry in the result will be prepennded with +If WITHDN is non-nil each entry in the result will be prepended with its distinguished name DN. +If VERBOSE is non-nil progress messages will be echoed. The function returns a list of matching entries. Each entry is itself an alist of attribute/value pairs optionally preceded by the DN of the entry according to the value of WITHDN. */ - (ldap, filter, base, scope, attrs, attrsonly, withdn)) + (ldap, filter, base, scope, attrs, attrsonly, withdn, verbose)) { /* This function can GC */ @@ -491,10 +496,8 @@ /* Build the results list */ matches = 0; - /* ldap_result calls select() and can get wedged by EINTR signals */ - slow_down_interrupts (); rc = ldap_result (ld, LDAP_RES_ANY, 0, NULL, &unwind.res); - speed_up_interrupts (); + while (rc == LDAP_RES_SEARCH_ENTRY) { QUIT; @@ -504,7 +507,8 @@ destroys the current echo area contents, even when invoked from Lisp. It should use echo_area_message() instead, and restore the old echo area contents later. */ - message ("Parsing ldap results... %d", matches); + if (! NILP (verbose)) + message ("Parsing ldap results... %d", matches); entry = Qnil; /* Get the DN if required */ if (! NILP (withdn)) @@ -540,39 +544,229 @@ ldap_msgfree (unwind.res); unwind.res = NULL; - slow_down_interrupts (); rc = ldap_result (ld, LDAP_RES_ANY, 0, NULL, &(unwind.res)); - speed_up_interrupts (); } - if (rc == -1) - signal_ldap_error (ld, unwind.res, 0); - - if (rc == 0) - signal_ldap_error (ld, NULL, LDAP_TIMELIMIT_EXCEEDED); - #if defined HAVE_LDAP_PARSE_RESULT rc2 = ldap_parse_result (ld, unwind.res, &rc, NULL, NULL, NULL, NULL, 0); if (rc2 != LDAP_SUCCESS) rc = rc2; -#elif defined HAVE_LDAP_RESULT2ERROR +#else + if (rc == 0) + signal_ldap_error (ld, NULL, LDAP_TIMELIMIT_EXCEEDED); + + if (rc == -1) + signal_ldap_error (ld, unwind.res, (unwind.res==NULL) ? ld->ld_errno : 0); + +#if defined HAVE_LDAP_RESULT2ERROR rc = ldap_result2error (ld, unwind.res, 0); #endif - if ((rc != LDAP_SUCCESS) && (rc != LDAP_SIZELIMIT_EXCEEDED)) +#endif + + if (rc != LDAP_SUCCESS) signal_ldap_error (ld, NULL, rc); ldap_msgfree (unwind.res); unwind.res = (LDAPMessage *)NULL; + /* #### See above for calling message(). */ - message ("Parsing ldap results... done"); + if (! NILP (verbose)) + message ("Parsing ldap results... done"); unbind_to (speccount, Qnil); UNGCPRO; return Fnreverse (result); } +DEFUN ("ldap-add", Fldap_add, 3, 3, 0, /* +Add an entry to an LDAP directory. +LDAP is an LDAP connection object created with `ldap-open'. +DN is the distinguished name of the entry to add. +ENTRY is an entry specification, i.e., a list of cons cells +containing attribute/value string pairs. +*/ + (ldap, dn, entry)) +{ + LDAP *ld; + LDAPMod *ldap_mods, **ldap_mods_ptrs; + struct berval *bervals; + int rc; + int i, j; + + Lisp_Object current, values; + struct gcpro gcpro1, gcpro2; + GCPRO2 (current, values); + + /* Do all the parameter checking */ + CHECK_LIVE_LDAP (ldap); + ld = XLDAP (ldap)->ld; + + /* Check the DN */ + CHECK_STRING (dn); + + /* Check the entry */ + CHECK_CONS (entry); + if (NILP (entry)) + signal_simple_error ("Cannot add void entry", entry); + + /* Build the ldap_mods array */ + ldap_mods = alloca_array (LDAPMod, XINT (Flength (entry))); + ldap_mods_ptrs = alloca_array (LDAPMod *, 1 + XINT (Flength (entry))); + i = 0; + EXTERNAL_LIST_LOOP (entry, entry) + { + current = XCAR (entry); + CHECK_CONS (current); + CHECK_STRING (XCAR (current)); + ldap_mods_ptrs[i] = &(ldap_mods[i]); + GET_C_STRING_OS_DATA_ALLOCA ( XCAR (current), ldap_mods[i].mod_type); + ldap_mods[i].mod_op = LDAP_MOD_ADD | LDAP_MOD_BVALUES; + values = XCDR (current); + if (CONSP (values)) + { + bervals = + alloca_array (struct berval, XINT (Flength (values))); + ldap_mods[i].mod_vals.modv_bvals = + alloca_array (struct berval *, 1 + XINT (Flength (values))); + j = 0; + EXTERNAL_LIST_LOOP (values, values) + { + current = XCAR (values); + CHECK_STRING (current); + ldap_mods[i].mod_vals.modv_bvals[j] = &(bervals[j]); + GET_STRING_OS_DATA_ALLOCA (current, + bervals[j].bv_val, + bervals[j].bv_len); + j++; + } + ldap_mods[i].mod_vals.modv_bvals[j] = NULL; + } + else + { + CHECK_STRING (values); + bervals = alloca_array (struct berval, 1); + ldap_mods[i].mod_vals.modv_bvals = alloca_array (struct berval *, 2); + ldap_mods[i].mod_vals.modv_bvals[0] = &(bervals[0]); + GET_STRING_OS_DATA_ALLOCA (values, + bervals[0].bv_val, + bervals[0].bv_len); + ldap_mods[i].mod_vals.modv_bvals[1] = NULL; + } + i++; + } + ldap_mods_ptrs[i] = NULL; + rc = ldap_add_s (ld, (char *) XSTRING_DATA (dn), ldap_mods_ptrs); + if (rc != LDAP_SUCCESS) + signal_ldap_error (ld, NULL, rc); + + UNGCPRO; +} + +DEFUN ("ldap-modify", Fldap_modify, 3, 3, 0, /* +Add an entry to an LDAP directory. +LDAP is an LDAP connection object created with `ldap-open'. +DN is the distinguished name of the entry to modify. +MODS is a list of modifications to apply. +A modification is a list of the form (MOD-OP ATTR VALUE1 VALUE2 ...) +MOD-OP and ATTR are mandatory, VALUEs are optional depending on MOD-OP. +MOD-OP is the type of modification, one of the symbols `add', `delete' +or `replace'. ATTR is the LDAP attribute type to modify +*/ + (ldap, dn, mods)) +{ + LDAP *ld; + LDAPMod *ldap_mods, **ldap_mods_ptrs; + struct berval *bervals; + int i, j, rc; + + Lisp_Object current, mod_op, values; + struct gcpro gcpro1, gcpro2; + + GCPRO2 (current, values); + + /* Do all the parameter checking */ + CHECK_LIVE_LDAP (ldap); + ld = XLDAP (ldap)->ld; + + /* Check the DN */ + CHECK_STRING (dn); + + /* Check the entry */ + CHECK_CONS (mods); + if (NILP (mods)) + return Qnil; + + /* Build the ldap_mods array */ + ldap_mods = alloca_array (LDAPMod, XINT (Flength (mods))); + ldap_mods_ptrs = alloca_array (LDAPMod *, 1 + XINT (Flength (mods))); + i = 0; + EXTERNAL_LIST_LOOP (mods, mods) + { + current = XCAR (mods); + CHECK_CONS (current); + CHECK_SYMBOL (XCAR (current)); + mod_op = XCAR (current); + ldap_mods_ptrs[i] = &(ldap_mods[i]); + ldap_mods[i].mod_op = LDAP_MOD_BVALUES; + if (EQ (mod_op, Qadd)) + ldap_mods[i].mod_op |= LDAP_MOD_ADD; + else if (EQ (mod_op, Qdelete)) + ldap_mods[i].mod_op |= LDAP_MOD_DELETE; + else if (EQ (mod_op, Qreplace)) + ldap_mods[i].mod_op |= LDAP_MOD_REPLACE; + else + signal_simple_error ("Invalid LDAP modification type", mod_op); + current = XCDR (current); + CHECK_STRING (XCAR (current)); + GET_C_STRING_OS_DATA_ALLOCA ( XCAR (current), ldap_mods[i].mod_type); + values = XCDR (current); + bervals = alloca_array (struct berval, XINT (Flength (values))); + ldap_mods[i].mod_vals.modv_bvals = + alloca_array (struct berval *, 1 + XINT (Flength (values))); + j = 0; + EXTERNAL_LIST_LOOP (values, values) + { + current = XCAR (values); + CHECK_STRING (current); + ldap_mods[i].mod_vals.modv_bvals[j] = &(bervals[j]); + GET_STRING_OS_DATA_ALLOCA (current, + bervals[j].bv_val, + bervals[j].bv_len); + j++; + } + ldap_mods[i].mod_vals.modv_bvals[j] = NULL; + i++; + } + ldap_mods_ptrs[i] = NULL; + rc = ldap_modify_s (ld, (char *) XSTRING_DATA (dn), ldap_mods_ptrs); + if (rc != LDAP_SUCCESS) + signal_ldap_error (ld, NULL, rc); + + UNGCPRO; +} + + +DEFUN ("ldap-delete", Fldap_delete, 2, 2, 0, /* +Delete an entry to an LDAP directory. +LDAP is an LDAP connection object created with `ldap-open'. +DN is the distinguished name of the entry to delete. +*/ + (ldap, dn)) +{ + LDAP *ld; + int rc; + + /* Check parameters */ + CHECK_LIVE_LDAP (ldap); + ld = XLDAP (ldap)->ld; + CHECK_STRING (dn); + + rc = ldap_delete_s (ld, (char *) XSTRING_DATA (dn)); + if (rc != LDAP_SUCCESS) + signal_ldap_error (ld, NULL, rc); +} void syms_of_eldap (void) @@ -593,13 +787,18 @@ defsymbol (&Qnever, "never"); defsymbol (&Qalways, "always"); defsymbol (&Qfind, "find"); + defsymbol (&Qadd, "add"); + defsymbol (&Qreplace, "replace"); DEFSUBR (Fldapp); DEFSUBR (Fldap_host); DEFSUBR (Fldap_status); DEFSUBR (Fldap_open); DEFSUBR (Fldap_close); - DEFSUBR (Fldap_search_internal); + DEFSUBR (Fldap_search); + DEFSUBR (Fldap_add); + DEFSUBR (Fldap_modify); + DEFSUBR (Fldap_delete); } void Index: src/eldap.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/eldap.h,v retrieving revision 1.7.2.3 diff -u -u -r1.7.2.3 eldap.h --- eldap.h 1999/10/24 03:48:33 1.7.2.3 +++ eldap.h 1999/11/27 15:22:33 @@ -61,12 +61,21 @@ Lisp_Object Fldap_open (Lisp_Object host, Lisp_Object ldap_plist); Lisp_Object Fldap_close (Lisp_Object ldap); -Lisp_Object Fldap_search_internal (Lisp_Object ldap, - Lisp_Object filter, - Lisp_Object base, - Lisp_Object scope, - Lisp_Object attrs, - Lisp_Object attrsonly, - Lisp_Object withdn); +Lisp_Object Fldap_search (Lisp_Object ldap, + Lisp_Object filter, + Lisp_Object base, + Lisp_Object scope, + Lisp_Object attrs, + Lisp_Object attrsonly, + Lisp_Object withdn, + Lisp_Object verbose); +Lisp_Object Fldap_add (Lisp_Object ldap, + Lisp_Object dn, + Lisp_Object entry); +Lisp_Object Fldap_modify (Lisp_Object ldap, + Lisp_Object dn, + Lisp_Object entry); +Lisp_Object Fldap_delete (Lisp_Object ldap, + Lisp_Object dn); #endif /* _XEMACS_ELDAP_H_ */ Index: lisp/ldap.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/ldap.el,v retrieving revision 1.7.2.6 diff -u -u -r1.7.2.6 ldap.el --- ldap.el 1999/08/24 08:30:28 1.7.2.6 +++ ldap.el 1999/11/27 15:22:34 @@ -35,6 +35,10 @@ ;;; Code: +(eval-when '(load) + (if (not (fboundp 'ldap-open)) + (error "No LDAP support compiled in this XEmacs"))) + (defgroup ldap nil "Lightweight Directory Access Protocol" :group 'comm) @@ -145,6 +149,11 @@ (integer :tag "(number of records)"))))) :group 'ldap) +(defcustom ldap-verbose nil + "*If non-nil, LDAP operations echo progress messages." + :type 'boolean + :group 'ldap) + (defcustom ldap-ignore-attribute-codings nil "*If non-nil, do not perform any encoding/decoding on LDAP attribute values." :type 'boolean @@ -437,7 +446,7 @@ attr))) -(defun ldap-search (filter &optional host attributes attrsonly withdn) +(defun ldap-search-entries (filter &optional host attributes attrsonly withdn) "Perform an LDAP search. FILTER is the search filter in RFC1558 syntax, i.e., something that looks like \"(cn=John Smith)\". @@ -459,13 +468,16 @@ (let ((host-plist (cdr (assoc host ldap-host-parameters-alist))) ldap result) - (message "Opening LDAP connection to %s..." host) + (if ldap-verbose + (message "Opening LDAP connection to %s..." host)) (setq ldap (ldap-open host host-plist)) - (message "Searching with LDAP on %s..." host) - (setq result (ldap-search-internal ldap filter - (plist-get host-plist 'base) - (plist-get host-plist 'scope) - attributes attrsonly withdn)) + (if ldap-verbose + (message "Searching with LDAP on %s..." host)) + (setq result (ldap-search ldap filter + (plist-get host-plist 'base) + (plist-get host-plist 'scope) + attributes attrsonly withdn + ldap-verbose)) (ldap-close ldap) (if ldap-ignore-attribute-codings result @@ -473,6 +485,120 @@ (lambda (record) (mapcar 'ldap-decode-attribute record))) result)))) + +(defun ldap-add-entries (entries &optional host binddn passwd) + "Add entries to an LDAP directory. +ENTRIES is a list of entry specifications of +the form (DN (ATTR . VALUE) (ATTR . VALUE) ...) where +DN is the distinguished name of an entry to add, the following +are cons cells containing attribute/value string pairs. +HOST is the LDAP host, defaulting to `ldap-default-host' +BINDDN is the DN to bind as to the server +PASSWD is the corresponding password" + (or host + (setq host ldap-default-host) + (error "No LDAP host specified")) + (let ((host-plist (cdr (assoc host ldap-host-parameters-alist))) + ldap + (i 1)) + (if (or binddn passwd) + (setq host-plist (copy-seq host-plist))) + (if binddn + (setq host-plist (plist-put host-plist 'binddn binddn))) + (if passwd + (setq host-plist (plist-put host-plist 'passwd passwd))) + (if ldap-verbose + (message "Opening LDAP connection to %s..." host)) + (setq ldap (ldap-open host host-plist)) + (if ldap-verbose + (message "Adding LDAP entries...")) + (mapcar (function + (lambda (thisentry) + (ldap-add ldap (car thisentry) (cdr thisentry)) + (if ldap-verbose + (message "%d added" i)) + (setq i (1+ i)))) + entries) + (ldap-close ldap))) + + +(defun ldap-modify-entries (entry-mods &optional host binddn passwd) + "Modify entries of an LDAP directory. +ENTRY_MODS is a list of entry modifications of the form + (DN MOD-SPEC1 MOD-SPEC2 ...) where DN is the distinguished name of +the entry to modify, the following are modification specifications. +A modification specification is itself a list of the form +(MOD-OP ATTR VALUE1 VALUE2 ...) MOD-OP and ATTR are mandatory, +VALUEs are optional depending on MOD-OP. +MOD-OP is the type of modification, one of the symbols `add', `delete' +or `replace'. ATTR is the LDAP attribute type to modify. +HOST is the LDAP host, defaulting to `ldap-default-host' +BINDDN is the DN to bind as to the server +PASSWD is the corresponding password" + (or host + (setq host ldap-default-host) + (error "No LDAP host specified")) + (let ((host-plist (cdr (assoc host ldap-host-parameters-alist))) + ldap + (i 1)) + (if (or binddn passwd) + (setq host-plist (copy-seq host-plist))) + (if binddn + (setq host-plist (plist-put host-plist 'binddn binddn))) + (if passwd + (setq host-plist (plist-put host-plist 'passwd passwd))) + (if ldap-verbose + (message "Opening LDAP connection to %s..." host)) + (setq ldap (ldap-open host host-plist)) + (if ldap-verbose + (message "Modifying LDAP entries...")) + (mapcar (function + (lambda (thisentry) + (ldap-modify ldap (car thisentry) (cdr thisentry)) + (if ldap-verbose + (message "%d modified" i)) + (setq i (1+ i)))) + entry-mods) + (ldap-close ldap))) + + +(defun ldap-delete-entries (dn &optional host binddn passwd) + "Delete an entry from an LDAP directory. +DN is the distinguished name of an entry to delete or +a list of those. +HOST is the LDAP host, defaulting to `ldap-default-host' +BINDDN is the DN to bind as to the server +PASSWD is the corresponding password." + (or host + (setq host ldap-default-host) + (error "No LDAP host specified")) + (let ((host-plist (cdr (assoc host ldap-host-parameters-alist))) + ldap) + (if (or binddn passwd) + (setq host-plist (copy-seq host-plist))) + (if binddn + (setq host-plist (plist-put host-plist 'binddn binddn))) + (if passwd + (setq host-plist (plist-put host-plist 'passwd passwd))) + (if ldap-verbose + (message "Opening LDAP connection to %s..." host)) + (setq ldap (ldap-open host host-plist)) + (if (consp dn) + (let ((i 1)) + (if ldap-verbose + (message "Deleting LDAP entries...")) + (mapcar (function + (lambda (thisdn) + (ldap-delete ldap thisdn) + (if ldap-verbose + (message "%d deleted" i)) + (setq i (1+ i)))) + dn)) + (if ldap-verbose + (message "Deleting LDAP entry...")) + (ldap-delete ldap dn)) + (ldap-close ldap))) + (provide 'ldap) --Multipart_Sat_Nov_27_17:02:52_1999-1-- --pgp-sign-Multipart_Sat_Nov_27_17:02:52_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOEAAtJ7CaiYEgqPZAQHXtwH+NCaF7tkWHXA9nVLNTMLphLk5xKoAQ/Vd H/0epw8Zoj30L5nW0GLJEJifOTEk77QRa7h9Ak6QoNgyoQMroXNz/Q== =z22E -----END PGP MESSAGE----- --pgp-sign-Multipart_Sat_Nov_27_17:02:52_1999-1-- From owner-xemacs-beta@xemacs.org Sat Nov 27 11:08:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA25471 for xemacs-beta-out; Sat, 27 Nov 1999 11:08:01 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA25468 for ; Sat, 27 Nov 1999 11:07:59 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id RAA21882; Sat, 27 Nov 1999 17:07:56 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11rkKE-00027y-00; Sat, 27 Nov 1999 17:03:50 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id BE84918BA; Sat, 27 Nov 1999 17:03:48 +0100 (CET) Mail-Copies-To: never To: "Peter B. West" Cc: xemacs-beta Subject: Re: Problems with CVS build References: <383F9CFE.95450DB@netscape.net> From: Andreas Jaeger Date: 27 Nov 1999 17:03:48 +0100 In-Reply-To: "Peter B. West"'s message of "Sat, 27 Nov 1999 18:57:34 +1000" Message-ID: Lines: 42 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Peter B West writes: > I encountered the following problems in building packages from the CVS > sources: > make[2]: Entering directory > `/opt2/src/xemacs/xemacs-packages/oa/text-modes' > /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l > ../../package-compile.el -- ispell fsf-compat xemacs-base -- > filladapt.el > Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... > Loading > /opt2/src/xemacs/xemacs-packages/libs/xemacs-base/auto-autoloads... > Loading > /opt2/src/xemacs/xemacs-packages/libs/fsf-compat/auto-autoloads... > Loading /opt2/src/xemacs/xemacs-packages/oa/ispell/auto-autoloads... > Symbol's value as variable is void: ispell-xemacs > xemacs exiting. > make[2]: *** [filladapt.elc] Error 255 Please try the following patch. Andreas 1999-11-27 Andreas Jaeger * ispell.el (ispell-xemacs): Autoload it. --- ispell.el.~1~ Sat Oct 16 09:39:50 1999 +++ ispell.el Sat Nov 27 17:00:55 1999 @@ -629,6 +629,7 @@ ;;; Break out XEmacs menu and split into several calls to avoid having ;;; long lines in loaddefs.el. Detect need off following constant. +;;;###autoload (defconst ispell-xemacs (string-match "Lucid\\|XEmacs" emacs-version) "Non nil if running XEmacs.") -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Sat Nov 27 12:37:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA27988 for xemacs-beta-out; Sat, 27 Nov 1999 12:37:33 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA27983 for ; Sat, 27 Nov 1999 12:37:28 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id SAA28323 for xemacs-beta@xemacs.org; Sat, 27 Nov 1999 18:37:27 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11rlf8-0002Sm-00 for xemacs-beta@xemacs.org; Sat, 27 Nov 1999 18:29:30 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 2E2DE18BA; Sat, 27 Nov 1999 18:29:28 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Patches to xemacs-packages From: Andreas Jaeger Date: 27 Nov 1999 18:29:28 +0100 Message-ID: Lines: 157 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi, I've applied a number of patches to the CVS archive of xemacs-packages. For details, please check the ChangeLog files. These are (besides w3) patches from before september 1999 which Jan forwarded me. I've pasted together the cvs commit messages and appended them below. This way it should be clear what has been added. I've given most patches only minimal testing - they do compile cleanly. Therefore I'm asking others to check that the patches are working fine. Thanks, Andreas P.S. Here are the commit messages: Update of /usr/CVSroot/XEmacs/xemacs-packages/comm/w3/lisp In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv15979/lisp Modified Files: Makefile.in base64.el css.el custom-load.el docomp.el font.el images.el mm.el mule-sysdp.el socks.el ssl.el url-auth.el url-cache.el url-cid.el url-cookie.el url-file.el url-http.el url-ldap.el url-mail.el url-parse.el url-vars.el url.el w3-cus.el w3-display.el w3-forms.el w3-hot.el w3-keyword.el w3-menu.el w3-parse.el w3-sysdp.el w3-vars.el w3-widget.el w3.el Added Files: w3-java.el Log Message: Imported w3-4.0pre.46. Update of /usr/CVSroot/XEmacs/xemacs-packages/comm/w3/contrib In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv15979/contrib Added Files: http-tunnel.el Log Message: Imported w3-4.0pre.46. Update of /usr/CVSroot/XEmacs/xemacs-packages/comm/w3/etc In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv15979/etc Modified Files: default.css Log Message: Imported w3-4.0pre.46. Update of /usr/CVSroot/XEmacs/xemacs-packages/comm/w3/texi In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv15979/texi Modified Files: w3-faq.txi w3.txi Log Message: Imported w3-4.0pre.46. Update of /usr/CVSroot/XEmacs/xemacs-packages/libs/xemacs-base In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv16376 Modified Files: ChangeLog imenu.el Log Message: Applied Christoph Wedler's patch from to synch imenu with FSF 20.4. Update of /usr/CVSroot/XEmacs/xemacs-packages/libs/xemacs-base In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv17358 Modified Files: ChangeLog compile.el Log Message: Applied Gabe Foster's patch from <37CD4EE5.48A2419B@sgrail.com> with subject "Added support for SGI MipsPro 7.3 compilers to compile.el" Update of /usr/CVSroot/XEmacs/xemacs-packages/prog/prog-modes In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv17670 Modified Files: ChangeLog ksh-mode.el Log Message: Added latest ksh-mode version from Gary Ellison (see <199905131849.LAA15109@bootsy.eng.sun.com> with subject "Re: latest ksh-mode.el") Update of /usr/CVSroot/XEmacs/xemacs-packages/libs/xemacs-devel In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv17287 Modified Files: ChangeLog trace.el Log Message: Applied Christopf Wedler's patch from with subject " trace.el: default arg for trace functions" Update of /usr/CVSroot/XEmacs/xemacs-packages/oa/calendar In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv17323 Modified Files: ChangeLog calendar.el Log Message: Applied Barry Warsaw's patch from <14273.33716.633011.225078@anthem.cnri.reston.va.us> with subject "[REPOST] patch for calendar.el when not using MULE". Update of /usr/CVSroot/XEmacs/xemacs-packages/os/os-utils In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv17714/os/os-utils Modified Files: jka-compr.el ChangeLog Log Message: Added Jan Vroonhof's patch from with subject " More Mule Screwage in packages: jka-compr and lookup". Update of /usr/CVSroot/XEmacs/xemacs-packages/oa/edit-utils In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv18024/oa/edit-utils Modified Files: uniquify.el ChangeLog Log Message: Applied Christoph Wedler's patch from with subject "uniquify.el: Sync with Emacs-20.3." Update of /usr/CVSroot/XEmacs/xemacs-packages/oa/speedbar In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv18066/oa/speedbar Modified Files: speedbar.el ChangeLog Log Message: Applied patch from Christoph Wedler to sync speedbar with FSF 20.4 (speedbar-0.8.1). Update of /usr/CVSroot/XEmacs/xemacs-packages/oa/edit-utils In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv18107/oa/edit-utils Modified Files: ChangeLog avoid.el Log Message: Applied Jerry James patch from with subject "emacs-minor-version fix for avoid". Update of /usr/CVSroot/XEmacs/xemacs-packages/comm/w3 In directory camelot-soft.camelot-soft.com:/tmp/cvs-serv18438 Modified Files: ChangeLog Makefile README aclocal.m4 build.bat configure Log Message: Final patches for W3 update. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Sat Nov 27 13:33:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA28998 for xemacs-beta-out; Sat, 27 Nov 1999 13:33:50 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA28993 for ; Sat, 27 Nov 1999 13:33:48 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA22869; Sat, 27 Nov 1999 19:33:46 +0100 (MET) Received: from urysohn(129.132.146.167), claiming to be "urysohn.math.ethz.ch" via SMTP by frege, id smtpdAAAa005.J; Sat Nov 27 19:33:41 1999 Received: (vroonhof@localhost) by urysohn.math.ethz.ch (8.9.3/D-MATH-client) id TAA16521; Sat, 27 Nov 1999 19:33:41 +0100 To: "Peter B. West" Cc: xemacs-beta Subject: Re: Binary editing problems persist References: <383FB88F.DA38B188@netscape.net> From: Jan Vroonhof Date: 27 Nov 1999 19:33:41 +0100 In-Reply-To: "Peter B. West"'s message of "Sat, 27 Nov 1999 20:55:12 +1000" Message-ID: Lines: 42 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Peter B. West" writes: > Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when > using hexl-mode to edit a file, whose coding had been set to binary, I > have just re-compiled from the latest CVS sources, and the problem > persists. Did I mention that I compile --with-mule? This is of course an inexcusable bug. Can you give a recipe to reproduce? Note that you must specify the coding system before reading in the file. > coding. Does anyone have any suggestions as to how this problem can be > resolved? Can it be solved? Is there an assumption that one of the EOL > transformation must always be applied? hexl seems broken for Mule at the moment. hexl-find-file now does some weird conditioning on the system type. Maybe a sync with the hexl from FSF Emacs 20.4 is in order. > The easiest way to edit a file with no conversion of any kind is with > the `M-x find-file-literally' command. This uses `binary', and also > suppresses other XEmacs features that might convert the file contents > before you see them. *Note Visiting::. This function does not exist, maybe it should be reinstated. The closest function that does is insert-file-contents-literally. That function is currently also broken (I have a patch but am waiting for a new version of EFS) > Setting `binary' by hand, as noted, does not prevent bitrot. Has no one > else seen this problem? What is the avenue of attack? Is this the sort > of change that is guaranteed to break something else? A start would be to sync hexl-mode from FSF emacs. Since they have mule always, they must have fixed the coding problems. If it uses i-f-c-literally, just give me yell and I will get it fixed. Your problems are exactly why Mule has a bad name. It breaks stuff that used to work, the API changes all the time and thus function are broken and the documentation is out of date. Jan From owner-xemacs-beta@xemacs.org Sat Nov 27 20:23:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA07348 for xemacs-beta-out; Sat, 27 Nov 1999 20:23:42 -0500 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA07343 for ; Sat, 27 Nov 1999 20:23:40 -0500 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA29193; Sat, 27 Nov 1999 17:23:36 -0800 (PST) Received: from mina.sr.hp.com (root@mina.sr.hp.com [15.4.42.247]) by postal.sr.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0) id RAA23096; Sat, 27 Nov 1999 17:23:51 -0800 (PST) Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id RAA22748; Sat, 27 Nov 1999 17:23:33 -0800 (PST) Message-Id: <199911280123.RAA22748@mina.sr.hp.com> To: Jan Vroonhof cc: "Peter B. West" , xemacs-beta Subject: Re: Binary editing problems persist Reply-To: Darryl Okahata In-reply-to: Your message of "27 Nov 1999 19:33:41 +0100." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 27 Nov 1999 17:23:33 -0800 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof wrote: > "Peter B. West" writes: > > > Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when > > using hexl-mode to edit a file, whose coding had been set to binary, I > > have just re-compiled from the latest CVS sources, and the problem > > persists. Did I mention that I compile --with-mule? > > This is of course an inexcusable bug. Can you give a recipe to > reproduce? Note that you must specify the coding system before reading > in the file. The bug is caused by file-coding, the design of which is, well, "very sub-optimal". Try this patch (which I made long ago when I went mad while venturing into the dark recesses of file-coding). I'm not sure it's complete, though (you may need some C source code changes). [ P.S. -- crypt.el is also broken. We talked about this a while back, but I never got around to submitting any patches. ] -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. =============================================================================== *** /tmp/hexl.el Tue Jan 13 22:38:01 1998 --- hexl.el Wed Sep 1 16:47:12 1999 *************** *** 241,246 (dehexlify-buffer) ;; Prevent infinite recursion. (let ((hexl-in-save-buffer t) (buffer-file-type t)) ; for ms-dos (save-buffer)) (setq modified (buffer-modified-p)) --- 241,250 ----- (dehexlify-buffer) ;; Prevent infinite recursion. (let ((hexl-in-save-buffer t) + (buffer-file-coding-system 'binary) + (coding-system-for-write 'binary) + (jka-compr-compression-info-list nil) + (jam-zcat-filename-list nil) (buffer-file-type t)) ; for ms-dos (save-buffer)) (setq modified (buffer-modified-p)) *************** *** 260,266 (interactive "fFilename: ") (if (or (eq system-type 'ms-dos) (eq system-type 'windows-nt)) (find-file-binary filename) ! (find-file filename)) (if (not (eq major-mode 'hexl-mode)) (hexl-mode))) --- 264,273 ----- (interactive "fFilename: ") (if (or (eq system-type 'ms-dos) (eq system-type 'windows-nt)) (find-file-binary filename) ! (switch-to-buffer ! (find-file-noselect filename nil t)) ! ) ! ; (find-file filename)) (if (not (eq major-mode 'hexl-mode)) (hexl-mode))) *************** *** 568,573 (setq buffer-undo-list nil) (let ((binary-process-output nil) ; for Ms-Dos (binary-process-input t) (buffer-undo-list t)) (shell-command-on-region (point-min) (point-max) hexlify-command t))) --- 575,582 ----- (setq buffer-undo-list nil) (let ((binary-process-output nil) ; for Ms-Dos (binary-process-input t) + (coding-system-for-read nil) + (coding-system-for-write 'binary) (buffer-undo-list t)) (shell-command-on-region (point-min) (point-max) hexlify-command t))) *************** *** 581,586 (setq buffer-undo-list nil) (let ((binary-process-output t) ; for Ms-Dos (binary-process-input nil) (buffer-undo-list t)) (shell-command-on-region (point-min) (point-max) dehexlify-command t))) --- 590,597 ----- (setq buffer-undo-list nil) (let ((binary-process-output t) ; for Ms-Dos (binary-process-input nil) + (coding-system-for-read 'binary) + (coding-system-for-write nil) (buffer-undo-list t)) (shell-command-on-region (point-min) (point-max) dehexlify-command t))) From owner-xemacs-beta@xemacs.org Sat Nov 27 22:54:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA12444 for xemacs-beta-out; Sat, 27 Nov 1999 22:54:11 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA12438 for ; Sat, 27 Nov 1999 22:54:09 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id TAA00372; Sat, 27 Nov 1999 19:52:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14400.42776.657116.398082@lasker.666.com> Date: Sat, 27 Nov 1999 19:52:56 -0800 (PST) From: Martin Buchholz To: Darryl Okahata Cc: Jan Vroonhof , "Peter B. West" , xemacs-beta Subject: Re: Binary editing problems persist In-Reply-To: <199911280123.RAA22748@mina.sr.hp.com> References: <199911280123.RAA22748@mina.sr.hp.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'd like someone on xemacs-beta to test this patch. Darryl, could you put your stamp of approval on this patch, i.e. if you feel it's the Right Patch, then send it to xemacs-patches@xemacs.org, and we'll try to apply it to the sources. Martin From owner-xemacs-beta@xemacs.org Sat Nov 27 22:58:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA12669 for xemacs-beta-out; Sat, 27 Nov 1999 22:58:16 -0500 Received: from mharnois.workgroup.net (ps12alo.willinet.net [198.49.28.109]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA12664 for ; Sat, 27 Nov 1999 22:58:11 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian 8.9.3-6) id VAA10456; Sat, 27 Nov 1999 21:58:01 -0600 To: xemacs-beta@xemacs.org Subject: zero size widget crashes continue From: Michael Harnois Date: 27 Nov 1999 21:58:01 -0600 Message-ID: <87ln7je08m.fsf@mharnois.workgroup.net> Lines: 16 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is not critical to me, since I kept a working copy of an older 21.2 beta to actually use ... but I haven't been able to use a current CVS beta for at least a month because, in gnus, they crash after no more than ten minutes with errors like these: xemacs: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 12 (X_ConfigureWindow) Value in failed request: 0x0 Serial number of failed request: 79626 Current serial number in output stream: 79659 Error: Widget *Article* has zero width and/or height -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org "Waiter, there's no fly in my soup!" - Kermit the Frog From owner-xemacs-beta@xemacs.org Sat Nov 27 23:19:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA13746 for xemacs-beta-out; Sat, 27 Nov 1999 23:19:15 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA13727; Sat, 27 Nov 1999 23:18:56 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id UAA09667; Sat, 27 Nov 1999 20:18:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14400.44334.96890.937081@lasker.666.com> Date: Sat, 27 Nov 1999 20:18:54 -0800 (PST) From: Martin Buchholz To: Michael Harnois , Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: zero size widget crashes continue In-Reply-To: <87ln7je08m.fsf@mharnois.workgroup.net> References: <87ln7je08m.fsf@mharnois.workgroup.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "M" == Michael Harnois writes: M> This is not critical to me, since I kept a working copy of an older M> 21.2 beta to actually use ... but I haven't been able to use a current M> CVS beta for at least a month because, in gnus, they crash after no M> more than ten minutes with errors like these: This likely has to do with Andy's current hacking. M> xemacs: X Error of failed request: BadValue (integer parameter out of range for operation) M> Major opcode of failed request: 12 (X_ConfigureWindow) M> Value in failed request: 0x0 M> Serial number of failed request: 79626 M> Current serial number in output stream: 79659 M> Error: Widget *Article* has zero width and/or height Try disabling Andy's gutters like this in .emacs: ;;; No 21.2 tabs, please (defmacro when-specifierp (specifier &rest form) `(when (and (boundp ',specifier) (specifierp ,specifier)) ,@form)) (put 'when-specifierp 'lisp-indent-function 1) (when-specifierp default-gutter-visible-p (set-specifier default-gutter-visible-p nil) (setq gutter-visible-p nil)) I am currently running this way without crashes, but then I don't use gnus much, either. Martin From owner-xemacs-beta@xemacs.org Sun Nov 28 00:03:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA15679 for xemacs-beta-out; Sun, 28 Nov 1999 00:03:26 -0500 Received: from mharnois.workgroup.net (ps12alo.willinet.net [198.49.28.109]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA15668; Sun, 28 Nov 1999 00:03:08 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian 8.9.3-6) id XAA14813; Sat, 27 Nov 1999 23:02:55 -0600 To: martin@xemacs.org Cc: Andy Piper , xemacs-beta@xemacs.org Subject: Re: zero size widget crashes continue References: <87ln7je08m.fsf@mharnois.workgroup.net> <14400.44334.96890.937081@lasker.666.com> From: Michael Harnois Date: 27 Nov 1999 23:02:55 -0600 In-Reply-To: Martin Buchholz's message of "Sat, 27 Nov 1999 20:18:54 -0800 (PST)" Message-ID: <87zovzryww.fsf@mharnois.workgroup.net> Lines: 10 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Sat, 27 Nov 1999 20:18:54 -0800 (PST), Martin Buchholz said: > Try disabling Andy's gutters like this in .emacs: That does seem to work around the problem for the time being, thanks. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org "Waiter, there's no fly in my soup!" - Kermit the Frog From owner-xemacs-beta@xemacs.org Sun Nov 28 00:45:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA17740 for xemacs-beta-out; Sun, 28 Nov 1999 00:45:01 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA17726; Sun, 28 Nov 1999 00:44:55 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id VAA11971; Sat, 27 Nov 1999 21:44:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14400.49493.460079.407371@lasker.666.com> Date: Sat, 27 Nov 1999 21:44:53 -0800 (PST) From: Martin Buchholz To: Andy Piper Cc: Michael Harnois , xemacs-beta@xemacs.org Subject: Re: zero size widget crashes continue In-Reply-To: <87zovzryww.fsf@mharnois.workgroup.net> References: <87ln7je08m.fsf@mharnois.workgroup.net> <14400.44334.96890.937081@lasker.666.com> <87zovzryww.fsf@mharnois.workgroup.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "M" == Michael Harnois writes: M> On Sat, 27 Nov 1999 20:18:54 -0800 (PST), Martin Buchholz said: >> Try disabling Andy's gutters like this in .emacs: M> That does seem to work around the problem for the time being, thanks. Andy, that's an important clue for you. I'd look at it myself, but I really don't want to start another project at this time. Martin From owner-xemacs-beta@xemacs.org Sun Nov 28 02:51:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA21627 for xemacs-beta-out; Sun, 28 Nov 1999 02:51:10 -0500 Received: from max3p153.smart.net (max3p153.smart.net [216.84.81.153]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA21617; Sun, 28 Nov 1999 02:50:56 -0500 Received: (from jmiller@localhost) by max3p153.smart.net (8.9.3/8.9.3) id CAA20472; Sun, 28 Nov 1999 02:47:37 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14400.56857.18908.582744@max3p153.smart.net> Date: Sun, 28 Nov 1999 02:47:37 -0500 (EST) To: Michael Harnois Cc: martin@xemacs.org, Andy Piper , xemacs-beta@xemacs.org Subject: Re: zero size widget crashes continue In-Reply-To: <87zovzryww.fsf@mharnois.workgroup.net> References: <87ln7je08m.fsf@mharnois.workgroup.net> <14400.44334.96890.937081@lasker.666.com> <87zovzryww.fsf@mharnois.workgroup.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "MH" == Michael Harnois writes: MH> On Sat, 27 Nov 1999 20:18:54 -0800 (PST), Martin Buchholz said: >> Try disabling Andy's gutters like this in .emacs: MH> That does seem to work around the problem for the time being, thanks. it's most definitely a gutter problem. i get them in vm and gnus and whatever else i happen to be editing. very sporadic... haven't been able to tie it to anything in particular one of these days i'll compile a debugged version of xemacs and maybe get a core dump...... jeff From owner-xemacs-beta@xemacs.org Sun Nov 28 07:21:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA29829 for xemacs-beta-out; Sun, 28 Nov 1999 07:21:35 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA29765; Sun, 28 Nov 1999 07:19:37 -0500 Received: from 666.com (dialup04ip081.tus.azstarnet.com [169.197.31.209]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with ESMTP id FAA20617; Sun, 28 Nov 1999 05:19:25 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <38411DA7.6C6D1686@666.com> Date: Sun, 28 Nov 1999 05:18:47 -0700 From: Ben Wing X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stephen J. Turnbull" CC: XEmacs Beta List , XEmacs Mule , Ben Wing Subject: Re: Char-related crashes (hopefully) fixed References: <9t9ogd0dszb.fsf@mraz.iskon.hr> <877ljko554.fsf@dp50.ecc.u-tokyo.ac.jp> <38324521.33BD67AB@666.com> <14386.33750.111810.683435@turnbull.sk.tsukuba.ac.jp> <9t9u2mlcmgt.fsf@mraz.iskon.hr> <14387.29098.672084.950046@turnbull.sk.tsukuba.ac.jp> <9t97ljg9q3o.fsf@mraz.iskon.hr> <14391.13815.892522.347857@crystal.WonderWorks.COM> <14393.6788.226904.399854@turnbull.sk.tsukuba.ac.jp> <9t9ogcmzq4y.fsf@mraz.iskon.hr> <14395.29481.360777.116611@turnbull.sk.tsukuba.ac.jp> <9t9hfic9uru.fsf@mraz.iskon.hr> <14396.32509.507974.27380@turnbull.sk.tsukuba.ac.jp> <14396.33842.957468.846764@crystal.WonderWorks.COM> <14397.46555.352061.354596@lasker.666.com> <14397.59940.483520.755789@turnbull.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Help!!!!!!!!!!!!!! I step away for a week and suddenly there's a whole slew of messages proposing all sorts of grand ideas for Mule, and lots of comments about Ben this and Ben that ... I'm gonna have to spend some time (tomorrow, perhaps) going through this mail and figuring out what you guys are getting at. We also need some god-damned ORGANIZATION here. This means we need a document that contains -- all the concrete proposals that anyone has made, along with who made them. the proposals listed here should be SHORT. If anyone has long proposals, put an abstract here and the proposal itself down below. -- a list of the major players. -- the long proposals referenced above. Perhaps I'll make something like this and put it on a website, so people can look and suggest changes. (I am, after all, according to the official Job list that I made up, the "meta-maintainer", and so it's probably my job anyway to do this organizing -- that is, until we get an official Secretary, who doesn't fucking have any god-damned hand problems!) ben "Stephen J. Turnbull" wrote: > >>>>> "mb" == Martin Buchholz writes: > > mb> Conceptually, it should be trivial to have a --with-mule build > mb> that that acts in a Latin-1 way -- provide a function that > mb> makes sure that only 'binary is used for all encoding/decoding > mb> operations. This way there will be no unexpected surprises > mb> decoding tar.gz files or whatever. This should probably be > mb> implemented using a language environment. Maybe it should > mb> even be the default ???!!?? > > Welcome, Martin! > > A lot of this was hashed over a couple of weeks ago (on a CC list), I > put forward a pretty detailed proposal which Ben reviewed. As soon as > I finish grading final exams I'll get back to that. You were on the > CC list, so you should have a copy; if not I can send you a digest of > the relevant discussion. > > Olivier Galibert has a pretty detailed plan for dealing with the > `unibyte' issue. No naming problems, it will all be totally > automatic. > > As for new architecture, Ben's pretty much signed off on that, as has > Steve. We can call it Mule or not; at a high level, it will have to > integrate with existing Mule APPs[1] for backward compatibility, but > internally we are substantially diverging from FSF already. > > I think it's time for a clean break _if_ Ben and Olivier have the > resources to follow up on the plans they've already suggested. Ben at > least has a lot of other things in mind I know, but he seemed to put > pretty high priority on Mule when we were discussing it earlier. > > Footnotes: > [1] Application Programming Practices. I will not dignify the > current mess with the name "interface". > > -- > University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN > Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 > __________________________________________________________________________ > __________________________________________________________________________ > What are those two straight lines for? "Free software rules." -- ben -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it’s not apparent in your message, please say so. Thanks for your understanding. From owner-xemacs-beta@xemacs.org Sun Nov 28 18:51:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA14636 for xemacs-beta-out; Sun, 28 Nov 1999 18:51:02 -0500 Received: from max3p151.smart.net (max3p151.smart.net [216.84.81.151]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA14632 for ; Sun, 28 Nov 1999 18:50:58 -0500 Received: (from jmiller@localhost) by max3p151.smart.net (8.9.3/8.9.3) id SAA03031; Sun, 28 Nov 1999 18:47:22 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.48901.944542.719371@max3p151.smart.net> Date: Sun, 28 Nov 1999 18:47:17 -0500 (EST) To: xemacs-beta@xemacs.org Subject: mule broken? X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D I have attempted to build a mule xemacs after a long time of not doing so..... I get the following error during the dump Loading /cvs/xemacs/xemacs/lisp/mule/mule-cmds.elc... Loading /cvs/xemacs/xemacs/lisp/mule/arabic.elc... Loading /cvs/xemacs/xemacs/lisp/mule/chinese.elc...*** Error in XEmacs initialization (void-variable ccl-encode-big5-font) *** Backtrace really-early-error-handler((void-variable ccl-encode-big5-font)) byte-code("..." [set-language-info-alist "Chinese-GB" ((setup-function . setup-chinese-gb-environment-internal) (charset chinese-gb2312 sisheng) (coding-system cn-gb-2312 iso-2022-7bit hz-gb-2312) (coding-priority cn-gb-2312 big5 iso-2022-7bit) (input-method . "chinese-py-punct") (features china-util) (sample-text . "Chinese (ESC$AVPNDESC(B,ESC$AFUM(;0ESC(B,ESC$A::SoESC(B) ESC$ADc:CESC(B") (documentation . "Support for Chinese GB2312 character set.")) ("Chinese") make-coding-system big5 "Coding-system of BIG5." (mnemonic "Zh/Big5") define-coding-system-alias cn-big5 define-ccl-program ccl-encode-big5-font 0 (r2 = (... - ?\!)) if r0 == charset-id chinese-big5-2 ((r2 += 6280)) ((r1 = ...) (r2 %= 157) (if ... ... ...)) "CCL program to encode a Big5 code to code point of Big5 font." set-charset-ccl-program chinese-big5-1 "Chinese-BIG5" ((charset chinese-big5-1 chinese-big5-2) (coding-system big5 iso-2022-7bit) (coding-priority big5 cn-gb-2312: this is from a cvs update today. I believe I also have the latest mule-base. Jeff From owner-xemacs-beta@xemacs.org Sun Nov 28 19:40:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA16067 for xemacs-beta-out; Sun, 28 Nov 1999 19:40:54 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA16063 for ; Sun, 28 Nov 1999 19:40:51 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id QAA20159; Sun, 28 Nov 1999 16:40:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.52111.586027.995934@lasker.666.com> Date: Sun, 28 Nov 1999 16:40:47 -0800 (PST) From: Martin Buchholz To: jmiller@smart.net Cc: xemacs-beta@xemacs.org Subject: Re: mule broken? In-Reply-To: <14401.48901.944542.719371@max3p151.smart.net> References: <14401.48901.944542.719371@max3p151.smart.net> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jeff" == Jeff Miller writes: Jeff> I have attempted to build a mule xemacs after a long time of not doing Jeff> so..... I get the following error during the dump Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/mule-cmds.elc... Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/arabic.elc... Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/chinese.elc...*** Error in XEmacs initialization Jeff> (void-variable ccl-encode-big5-font) ???? 21.2, I assume? Jeff> this is from a cvs update today. I believe I also have the latest Jeff> mule-base. Shouldn't be dependent on packages - should be defined in the core tarball. Try something like find lisp/. -name '*.elc' -print | xargs rm make Martin From owner-xemacs-beta@xemacs.org Sun Nov 28 22:25:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA21186 for xemacs-beta-out; Sun, 28 Nov 1999 22:25:04 -0500 Received: from max3p151.smart.net (max3p151.smart.net [216.84.81.151]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA21159; Sun, 28 Nov 1999 22:24:19 -0500 Received: (from jmiller@localhost) by max3p151.smart.net (8.9.3/8.9.3) id WAA03631; Sun, 28 Nov 1999 22:20:24 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14401.61685.318762.587790@max3p151.smart.net> Date: Sun, 28 Nov 1999 22:20:21 -0500 (EST) To: martin@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: mule broken? In-Reply-To: <14401.52111.586027.995934@lasker.666.com> References: <14401.48901.944542.719371@max3p151.smart.net> <14401.52111.586027.995934@lasker.666.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "MB" == Martin Buchholz writes: >>>>> "Jeff" == Jeff Miller writes: Jeff> I have attempted to build a mule xemacs after a long time of not doing Jeff> so..... I get the following error during the dump Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/mule-cmds.elc... Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/arabic.elc... Jeff> Loading /cvs/xemacs/xemacs/lisp/mule/chinese.elc...*** Error in XEmacs initialization Jeff> (void-variable ccl-encode-big5-font) MB> ???? MB> 21.2, I assume? oops, yes. Jeff> this is from a cvs update today. I believe I also have the latest Jeff> mule-base. MB> Shouldn't be dependent on packages - should be defined in the core MB> tarball. hmm, i thought the instructions said mule-base was required for building w/mule? MB> Try something like MB> find lisp/. -name '*.elc' -print | xargs rm MB> make done...... makeing....... well, that did the trick. Thanks.... Jeff From owner-xemacs-beta@xemacs.org Mon Nov 29 02:35:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA29299 for xemacs-beta-out; Mon, 29 Nov 1999 02:35:16 -0500 Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA29295 for ; Mon, 29 Nov 1999 02:35:14 -0500 Received: from localhost.localdomain (dialup20ip099.tus.azstarnet.com [169.197.39.227]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id AAA24724; Mon, 29 Nov 1999 00:35:10 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ To: Pedro Sam Cc: xemacs-beta@xemacs.org Subject: Re: xemacs 21.1.8 & hm--html--menus 1.12 References: <3841405C.837224E6@undergrad.math.uwaterloo.ca> Organization: geneHackCorps X-URL: X-Attribution: jsja From: john s jacobs anderson Date: 29 Nov 1999 00:35:43 -0700 In-Reply-To: Pedro Sam's message of "Sun, 28 Nov 1999 09:46:52 -0500" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Yoko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Pedro" == Pedro Sam writes: Pedro> Hi, I installed the big 3 xemacs tgz files from the xemacs21.1 Pedro> directory, then i downloaded efs and xemacs-base. Now I'm Pedro> trying to get hm--html--menus 1.12(as listed in the Manage Pedro> Package menu) Except it says that it couldn't find it. I went Pedro> searching for the file in the packages directory and there is Pedro> no file that starts with an 'h'. Thanks; I'll pass word on to the appropriate people to let them know that one of the packages has gone missing. (Martin and/or Steve and/or Vinnie -- could somebody please get this taken care of?) Thanks, john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ You'll have to pry my Emacs from my cold \ jacobs@xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz From owner-xemacs-beta@xemacs.org Mon Nov 29 03:23:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA31093 for xemacs-beta-out; Mon, 29 Nov 1999 03:23:52 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA31090 for ; Mon, 29 Nov 1999 03:23:49 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id JAA11835; Mon, 29 Nov 1999 09:23:46 +0100 To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 29 Nov 1999 09:23:46 +0100 In-Reply-To: Oscar Figueiredo's message of "27 Nov 1999 17:03:06 +0100" Message-ID: <9t93dtpzox9.fsf@mraz.iskon.hr> Lines: 10 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > *** IMPORTANT NOTE *** > Due to the function renaming, this patch introduces an incompatible > change that breaks the packages using the current LDAP API, most > notably EUDC and W3. Renaming doesn't necessarily entail breaking backward compatibility. If you want to be kind to your users, define functions with old names that do nothing except call the new functions. From owner-xemacs-beta@xemacs.org Mon Nov 29 03:38:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA31554 for xemacs-beta-out; Mon, 29 Nov 1999 03:38:20 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA31551 for ; Mon, 29 Nov 1999 03:38:18 -0500 Received: by localhost id m11sMK4-00017RC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 29 Nov 1999 17:38:12 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> Date: Mon, 29 Nov 1999 17:38:12 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Broken makeinfo? [was: Re: Fix this] In-Reply-To: <14399.24386.685515.394889@lasker.666.com> References: <14399.24386.685515.394889@lasker.666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "mb" == Martin Buchholz writes: mb> You must be using some old broken makeinfo. C'mon, old != broken. The question is, how many "old makeinfos" are out there, and how many of them are going to get tickled by that construct? The lack of reports on xemacs-beta is quite possibly meaningless; as I reported recently, "make beta" does not rebuild info by default. Try adding info to the top-level makefile dependency for beta (I don't grok Makefile\(.in\)+, sorry, no patch) and see what happens. Or maybe we don't care, because we don't care if people can build their own info docs or nobody ever does? (Is that why rebuilding info doesn't go automatically with make beta?) Or maybe we should think about abandoning (!) Texinfo in favor of a real DTD not defined by an implementation? mb> there is no obvious workaround for this brokenness, except mb> perhaps to change all the @ifnottex to @ifinfo. What about -@node Top +@node Top, Getting Started, , (dir) which reverses the other change to the Texinfo commands in that region. (The three @nodes that don't have a full complement of pointers were all introduced by your patch, probably need to change the others too.) Dunno if that will help, but I know makeinfo has been sensitive to xref issues in the past, and has never been good at giving useful error messages. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 29 04:24:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA01419 for xemacs-beta-out; Mon, 29 Nov 1999 04:24:28 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA01399 for ; Mon, 29 Nov 1999 04:24:19 -0500 Received: from miho (localhost [127.0.0.1]) by miho.m17n.org (8.9.3/8.9.3) with ESMTP id SAA14597 for ; Mon, 29 Nov 1999 18:22:12 +0900 (JST) Date: Mon, 29 Nov 1999 18:22:12 +0900 (JST) Message-Id: <199911290922.SAA14597@miho.m17n.org> Mail-Copies-To: Never From: "XEmacs Build 'Bot" Subject: XEmacs Build Report for XEmacs-21.2.22 To: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Good evening XEmacs beta testers. I am in the process of building XEmacs-21.2.22 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ./configure '--prefix=/usr/local/devel/xemacs-builds' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.2-b22 "Mercedes" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /usr/local/devel/xemacs-builds/xemacs-21.2 What installation prefix should install use? /usr/local/devel/xemacs-builds What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -O Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Runtime library search path: /usr/local/qt/lib:/usr/local/lib:/usr/local/X11R6/lib Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in support for Canna on Mule. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. From owner-xemacs-beta@xemacs.org Mon Nov 29 04:31:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA02333 for xemacs-beta-out; Mon, 29 Nov 1999 04:31:12 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA02325 for ; Mon, 29 Nov 1999 04:31:10 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id BAA01048; Mon, 29 Nov 1999 01:30:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.18349.405786.824478@lasker.666.com> Date: Mon, 29 Nov 1999 01:30:21 -0800 (PST) From: Martin Buchholz To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] In-Reply-To: <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "S" == Stephen J Turnbull writes: >>>>> "mb" == Martin Buchholz writes: mb> You must be using some old broken makeinfo. S> C'mon, old != broken. The question is, how many "old makeinfos" are S> out there, and how many of them are going to get tickled by that S> construct? People who download pre-packaged tarballs will not have any problems since their info files will already be up-to-date. Only CVS users will have to upgrade, or get up-to-date info files from the packaged tarballs. S> The lack of reports on xemacs-beta is quite possibly meaningless; as I S> reported recently, "make beta" does not rebuild info by default. ??? Just `make' rebuilds the info files by default. S> Try adding info to the top-level makefile dependency for beta (I don't S> grok Makefile\(.in\)+, sorry, no patch) and see what happens. S> Or maybe we don't care, because we don't care if people can build S> their own info docs or nobody ever does? (Is that why rebuilding info S> doesn't go automatically with make beta?) S> Or maybe we should think about abandoning (!) Texinfo in favor of a S> real DTD not defined by an implementation? mb> there is no obvious workaround for this brokenness, except mb> perhaps to change all the @ifnottex to @ifinfo. S> What about S> -@node Top S> +@node Top, Getting Started, , (dir) I merely imported the info.texi file from the texinfo distribution. Now that I look at it, there is only 2 occurrence of @ifnottex in man/, so it is actually reasonable to change them, for now, assuming this causes no problems for texi2html. Do we actually know that makeinfo from 3.12 fails, while 3.12f works fine? S> which reverses the other change to the Texinfo commands in that S> region. (The three @nodes that don't have a full complement of S> pointers were all introduced by your patch, probably need to change S> the others too.) Dunno if that will help, but I know makeinfo has S> been sensitive to xref issues in the past, and has never been good at S> giving useful error messages. Martin From owner-xemacs-beta@xemacs.org Mon Nov 29 04:33:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA02652 for xemacs-beta-out; Mon, 29 Nov 1999 04:33:25 -0500 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA02643 for ; Mon, 29 Nov 1999 04:33:21 -0500 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id BAA01404 for ; Mon, 29 Nov 1999 01:31:59 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id EAA05584 for ; Mon, 29 Nov 1999 04:28:56 -0500 (EST) Received: from ltrpluim.corpemea.baynetworks.com ([141.251.166.11]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id EAA29904; Mon, 29 Nov 1999 04:33:14 -0500 for Received: (from rpluim@localhost) by ltrpluim.corpemea.baynetworks.com (8.8.7/8.8.7) id KAA03512; Mon, 29 Nov 1999 10:30:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> Date: Mon, 29 Nov 1999 10:30:48 +0100 (CET) To: XEmacs Beta List Subject: Re: LDAP extended and revamped In-Reply-To: <9t93dtpzox9.fsf@mraz.iskon.hr> References: <9t93dtpzox9.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Reply-To: Robert Pluim Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Oscar Figueiredo writes: > > > *** IMPORTANT NOTE *** > > Due to the function renaming, this patch introduces an incompatible > > change that breaks the packages using the current LDAP API, most > > notably EUDC and W3. > > Renaming doesn't necessarily entail breaking backward compatibility. > If you want to be kind to your users, define functions with old names > that do nothing except call the new functions. Wouldn't define-{obsolete,compatible}-function-alias be better here? Or are they intended only for 'core' emacs functions? Robert -- The above are my opinions, and my opinions only. From owner-xemacs-beta@xemacs.org Mon Nov 29 04:50:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA04310 for xemacs-beta-out; Mon, 29 Nov 1999 04:50:20 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA04305 for ; Mon, 29 Nov 1999 04:50:14 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id KAA12167; Mon, 29 Nov 1999 10:50:12 +0100 To: XEmacs Beta List Subject: Re: Broken makeinfo? [was: Re: Fix this] References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 29 Nov 1999 10:50:12 +0100 In-Reply-To: "Stephen J. Turnbull"'s message of "Mon, 29 Nov 1999 17:38:12 +0900 (JST)" Message-ID: <9t9yabhvd7v.fsf@mraz.iskon.hr> Lines: 19 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Stephen J. Turnbull" writes: > Or maybe we don't care, because we don't care if people can build > their own info docs or nobody ever does? If we ship the pre-built info docs with the source tarballs (as GNU programs normally do), then people's ability to build their own docs with obsolete makeinfo's is not of paramount importance. If we do not distribute the pre-built infos, we should at least try to make sure people can build them with the versions of makeinfo that are generally available. Depending on the latest-and-greatest versions of software in order to build XEmacs is permissible, but annoying. > Or maybe we should think about abandoning (!) Texinfo in favor of a > real DTD not defined by an implementation? Please please not that discussion again. Texinfo serves nicely for what we want to do. From owner-xemacs-beta@xemacs.org Mon Nov 29 05:14:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05154 for xemacs-beta-out; Mon, 29 Nov 1999 05:14:50 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05151 for ; Mon, 29 Nov 1999 05:14:49 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id LAA09441 for ; Mon, 29 Nov 1999 11:14:29 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id LAA25736; Mon, 29 Nov 1999 11:14:29 +0100 (MET) To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Mon_Nov_29_11:14:21_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 29 Nov 1999 11:14:29 +0100 In-Reply-To: Robert Pluim's message of "Mon, 29 Nov 1999 10:30:48 +0100 (CET)" Message-ID: Lines: 53 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Mon_Nov_29_11:14:21_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Robert" == Robert Pluim writes: Robert> Hrvoje Niksic writes: >> Oscar Figueiredo writes: >> >> > *** IMPORTANT NOTE *** >> > Due to the function renaming, this patch introduces an incompatible >> > change that breaks the packages using the current LDAP API, most >> > notably EUDC and W3. >> >> Renaming doesn't necessarily entail breaking backward compatibility. >> If you want to be kind to your users, define functions with old names >> that do nothing except call the new functions. Robert> Wouldn't define-{obsolete,compatible}-function-alias be better here? Robert> Or are they intended only for 'core' emacs functions? Of course I've been concerned by this problem. But I don't know what to do for the particular case of ldap-search. Currently ldap-search is the name of the high-level search function (vs. ldap-search-internal which is the low-level function). But according to the recent discussion on the subject, what we want is the low-level function to be called ldap-search and the high-level one called something else (my patch proposes ldap-search-entries). In this particular case I don't know how to rename backward compatible. That's the reason why I didn't provide compatibility aliases at all, compatibility will be broken anyway... :-(( I am not satisfied by this but I've seen no workaround. I don't know how many packages are currently using the LDAP API. I know of two: EUDC which I maintain myself and W3. As I said, I can provide a compatible version of EUDC as soon as necessary and I guess Bill is responsive enough these days to do the same. I just hope the consequences of this incompatible change will be minor, the LDAP API has been out since version 21.0 only. Oscar --pgp-sign-Multipart_Mon_Nov_29_11:14:21_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOEJSAp7CaiYEgqPZAQHHUAIAzUAcRd2+aiCHCJdYXiAPTY9IA5giFdN0 zORnvjPfCKsccqCOgyarRGynITCxKkxeyFyGPkAPq89mKFjmxTXpEg== =72AB -----END PGP MESSAGE----- --pgp-sign-Multipart_Mon_Nov_29_11:14:21_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 29 05:25:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05712 for xemacs-beta-out; Mon, 29 Nov 1999 05:25:51 -0500 Received: from btmplq.god.bel.alcatel.be (gate.alcatel.be [195.207.101.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05701; Mon, 29 Nov 1999 05:25:34 -0500 Received: from btzp12.atess.bel.alcatel.be ([138.203.12.66]) by btmplq.god.bel.alcatel.be (8.9.3+Sun/8.9.1) with ESMTP id LAA20712; Mon, 29 Nov 1999 11:25:14 +0100 (MET) Received: from andyppc (btk0hg.atess.bel.alcatel.be) by btzp12.atess.bel.alcatel.be (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with SMTP id <0FLY00602FMCV9@btzp12.atess.bel.alcatel.be>; Mon, 29 Nov 1999 11:25:25 +0100 (MET) Date: Mon, 29 Nov 1999 10:26:14 +0000 From: Andy Piper Subject: Re: zero size widget crashes continue In-reply-to: <14400.49493.460079.407371@lasker.666.com> X-Sender: andyp@london.beasys.com To: martin@xemacs.org, Andy Piper Cc: Michael Harnois , xemacs-beta@xemacs.org Message-id: <3.0.5.32.19991129102614.00b9dca0@london.beasys.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset=us-ascii References: <87zovzryww.fsf@mharnois.workgroup.net> <87ln7je08m.fsf@mharnois.workgroup.net> <14400.44334.96890.937081@lasker.666.com> <87zovzryww.fsf@mharnois.workgroup.net> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 09:44 PM 11/27/99 -0800, Martin Buchholz wrote: >Andy, that's an important clue for you. I'd look at it myself, but I >really don't want to start another project at this time. I know its my fault. I have tried to code workarounds but without a reproducible test case it is difficult. I also have zero time right now, as evidenced by my lack of commiting. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Nov 29 05:26:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05726 for xemacs-beta-out; Mon, 29 Nov 1999 05:26:09 -0500 Received: from btmplq.god.bel.alcatel.be (gate.alcatel.be [195.207.101.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05723 for ; Mon, 29 Nov 1999 05:26:08 -0500 Received: from btzp12.atess.bel.alcatel.be ([138.203.12.66]) by btmplq.god.bel.alcatel.be (8.9.3+Sun/8.9.1) with ESMTP id LAA20736; Mon, 29 Nov 1999 11:26:03 +0100 (MET) Received: from andyppc (btk0hg.atess.bel.alcatel.be) by btzp12.atess.bel.alcatel.be (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with SMTP id <0FLY00602FNPVM@btzp12.atess.bel.alcatel.be>; Mon, 29 Nov 1999 11:26:13 +0100 (MET) Date: Mon, 29 Nov 1999 10:27:02 +0000 From: Andy Piper Subject: Re: zero size widget crashes continue In-reply-to: <87ln7je08m.fsf@mharnois.workgroup.net> X-Sender: andyp@london.beasys.com To: Michael Harnois , xemacs-beta@xemacs.org Message-id: <3.0.5.32.19991129102702.00ba3320@london.beasys.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 09:58 PM 11/27/99 -0600, Michael Harnois wrote: >This is not critical to me, since I kept a working copy of an older >21.2 beta to actually use ... but I haven't been able to use a current >CVS beta for at least a month because, in gnus, they crash after no >more than ten minutes with errors like these: > >xemacs: X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 12 (X_ConfigureWindow) > Value in failed request: 0x0 > Serial number of failed request: 79626 > Current serial number in output stream: 79659 >Error: Widget *Article* has zero width and/or height I've not been able to reproduce this. I will fix it if I can reproduce it. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Nov 29 05:28:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05817 for xemacs-beta-out; Mon, 29 Nov 1999 05:28:51 -0500 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05814 for ; Mon, 29 Nov 1999 05:28:48 -0500 Received: by localhost id m11sO34-00017SC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 29 Nov 1999 19:28:46 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.21854.191050.800335@turnbull.sk.tsukuba.ac.jp> Date: Mon, 29 Nov 1999 19:28:46 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] In-Reply-To: <14402.18349.405786.824478@lasker.666.com> References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <14402.18349.405786.824478@lasker.666.com> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "mb" == Martin Buchholz writes: mb> People who download pre-packaged tarballs will not have any mb> problems since their info files will already be up-to-date. mb> Only CVS users will have to upgrade, or get up-to-date info mb> files from the packaged tarballs. OK, so we don't have to care, I guess. S> The lack of reports on xemacs-beta is quite possibly S> meaningless; as I reported recently, "make beta" does not S> rebuild info by default. mb> ??? mb> Just `make' rebuilds the info files by default. Well, I read most of the traffic on xemacs-beta. I do not recall having seen "./config.status --recheck; make beta" deprecated as the normal way to build an XEmacs beta. This is still the procedure as of CVS checked out 2.5 hours ago in etc/BETA. I always thought that was a good idea. People in active development do `make' and rebuild only out-of-date dependencies. `make beta' cleans out the cruft and makes sure of a clean build. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." From owner-xemacs-beta@xemacs.org Mon Nov 29 05:38:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA06197 for xemacs-beta-out; Mon, 29 Nov 1999 05:38:46 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA06190; Mon, 29 Nov 1999 05:38:41 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA06051; Mon, 29 Nov 1999 11:38:33 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001UX; Mon Nov 29 11:38:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA04715; Mon, 29 Nov 1999 11:38:29 +0100 To: martin@xemacs.org Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <14402.18349.405786.824478@lasker.666.com> From: Jan Vroonhof Date: 29 Nov 1999 11:38:29 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 29 Nov 1999 01:30:21 -0800 (PST)" Message-ID: Lines: 30 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > I merely imported the info.texi file from the texinfo distribution. Isn't this a bad idea in itself..? The documentation we ship should document the code we ship, in particular our versions of texinfo.el and texinfmt.el. Let the makeinfo program carry its own version of 'info.texi'. (Yes I know these will shadow each other, but that is just the dir system being broken). > Now that I look at it, there is only 2 occurrence of @ifnottex in > man/, so it is actually reasonable to change them, for now, assuming > this causes no problems for texi2html. That might be difficult as the new version was introduced for texi2html. Anyhow, I would say "scr*w texi2html". > Do we actually know that makeinfo from 3.12 fails, while 3.12f works fine? This version fails... urysohn:/scratch/vroonhof/xemacs/man> makeinfo --version makeinfo (GNU texinfo 3.12) 1.68 Note that this version comes from TeXLive 3.99 which is one of the most up to date TeX distributions there is. Does anybody have teTeX 1.0 installed to check which version that uses? Jan From owner-xemacs-beta@xemacs.org Mon Nov 29 05:40:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA06320 for xemacs-beta-out; Mon, 29 Nov 1999 05:40:44 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA06308 for ; Mon, 29 Nov 1999 05:40:40 -0500 Received: by crystal.WonderWorks.COM id QQhrkk27951; Mon, 29 Nov 1999 02:40:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.22564.957986.71828@crystal.WonderWorks.COM> Date: Mon, 29 Nov 1999 02:40:36 -0800 (PST) From: Kyle Jones To: XEmacs Beta List Subject: Re: LDAP extended and revamped In-Reply-To: References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > >>>>> "Robert" == Robert Pluim writes: > > Robert> Hrvoje Niksic writes: > >> Oscar Figueiredo writes: > >> > >> > *** IMPORTANT NOTE *** > >> > Due to the function renaming, this patch introduces an incompatible > >> > change that breaks the packages using the current LDAP API, most > >> > notably EUDC and W3. > >> > >> Renaming doesn't necessarily entail breaking backward compatibility. > >> If you want to be kind to your users, define functions with old names > >> that do nothing except call the new functions. > > Robert> Wouldn't define-{obsolete,compatible}-function-alias be better here? > Robert> Or are they intended only for 'core' emacs functions? > > Of course I've been concerned by this problem. But I don't > know what to do for the particular case of ldap-search. > Currently ldap-search is the name of the high-level search > function (vs. ldap-search-internal which is the low-level > function). But according to the recent discussion on the > subject, what we want is the low-level function to be called > ldap-search and the high-level one called something else (my > patch proposes ldap-search-entries). I'm in favor of keeping compatibility with the old interface and, if necessary, accepting some awkwardness in the new names. But given that low level and high level search functions take different parameters, ldap-search could be smart and call the high level function if it looks like that's what the application wants. So maybe the problem can be avoided. From owner-xemacs-beta@xemacs.org Mon Nov 29 05:44:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA06401 for xemacs-beta-out; Mon, 29 Nov 1999 05:44:17 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA06395; Mon, 29 Nov 1999 05:44:11 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA06087; Mon, 29 Nov 1999 11:40:43 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001V5; Mon Nov 29 11:40:38 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA04717; Mon, 29 Nov 1999 11:40:38 +0100 To: john s jacobs anderson Cc: Pedro Sam , xemacs-beta@xemacs.org Subject: Re: xemacs 21.1.8 & hm--html--menus 1.12 References: <3841405C.837224E6@undergrad.math.uwaterloo.ca> From: Jan Vroonhof Date: 29 Nov 1999 11:40:38 +0100 In-Reply-To: john s jacobs anderson's message of "29 Nov 1999 00:35:43 -0700" Message-ID: Lines: 17 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: john s jacobs anderson writes: > Pedro> directory, then i downloaded efs and xemacs-base. Now I'm > Pedro> trying to get hm--html--menus 1.12(as listed in the Manage > Pedro> Package menu) Except it says that it couldn't find it. I went > Pedro> searching for the file in the packages directory and there is > Pedro> no file that starts with an 'h'. It is indeed missing. It is part of the Sumo tarball.. > (Martin and/or Steve and/or Vinnie -- could somebody please get this > taken care of?) Andreas is working to finally get a new package release out of the door that should also fix this problem. Jan From owner-xemacs-beta@xemacs.org Mon Nov 29 05:46:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA06469 for xemacs-beta-out; Mon, 29 Nov 1999 05:46:50 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA06466 for ; Mon, 29 Nov 1999 05:46:44 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id LAA13463; Mon, 29 Nov 1999 11:46:41 +0100 To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 29 Nov 1999 11:46:41 +0100 In-Reply-To: Robert Pluim's message of "Mon, 29 Nov 1999 10:30:48 +0100 (CET)" Message-ID: <9t9r9h9k226.fsf@mraz.iskon.hr> Lines: 12 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Robert Pluim writes: > > Renaming doesn't necessarily entail breaking backward > > compatibility. If you want to be kind to your users, define > > functions with old names that do nothing except call the new > > functions. > > Wouldn't define-{obsolete,compatible}-function-alias be better here? Yes, good point -- except when the calling conventions differ, and the compatibility functions have to do trivial processing to retrofit old arguments into new ones. From owner-xemacs-beta@xemacs.org Mon Nov 29 06:23:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08187 for xemacs-beta-out; Mon, 29 Nov 1999 06:23:16 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA08182 for ; Mon, 29 Nov 1999 06:23:14 -0500 Received: (qmail 1160 invoked from network); 29 Nov 1999 11:21:53 -0000 Received: from usrpri2-66.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.131) by biff.kiva.net with SMTP; 29 Nov 1999 11:21:53 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA18783; Mon, 29 Nov 1999 06:25:11 -0500 To: Oscar Figueiredo Cc: XEmacs Beta List Subject: Re: LDAP extended and revamped X-Now-Listening-To: Bach, Johann Sebastian (1685-1 - [4] G maj BWV 1049: Andante References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 43 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > >>>>> "Robert" == Robert Pluim writes: > > Robert> Hrvoje Niksic writes: > >> Oscar Figueiredo writes: > >> > >> > *** IMPORTANT NOTE *** > >> > Due to the function renaming, this patch introduces an > incompatible > >> > change that breaks the packages using the current LDAP API, most > >> > notably EUDC and W3. > >> > >> Renaming doesn't necessarily entail breaking backward > compatibility. > >> If you want to be kind to your users, define functions with old > names > >> that do nothing except call the new functions. > > Robert> Wouldn't define-{obsolete,compatible}-function-alias be better > here? > Robert> Or are they intended only for 'core' emacs functions? > > Of course I've been concerned by this problem. But I don't know what to > do for the particular case of ldap-search. Currently ldap-search is the > name of the high-level search function (vs. ldap-search-internal which is > the low-level function). But according to the recent discussion on the > subject, what we want is the low-level function to be called ldap-search > and the high-level one called something else (my patch proposes > ldap-search-entries). In this particular case I don't know how to rename > backward compatible. That's the reason why I didn't provide > compatibility aliases at all, compatibility will be broken anyway... :-(( > > I am not satisfied by this but I've seen no workaround. I don't know how > many packages are currently using the LDAP API. I know of two: EUDC > which I maintain myself and W3. As I said, I can provide a compatible > version of EUDC as soon as necessary and I guess Bill is responsive > enough these days to do the same. Yup, if this gets approved, I'll hack up url-ldap.el to deal with it. I'll try to make it work with both interfaces if I can find a nice clean way. -bp From owner-xemacs-beta@xemacs.org Mon Nov 29 06:29:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08406 for xemacs-beta-out; Mon, 29 Nov 1999 06:29:02 -0500 Received: from biff.kiva.net (biff.kiva.net [206.97.64.31]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id GAA08401 for ; Mon, 29 Nov 1999 06:29:00 -0500 Received: (qmail 1826 invoked from network); 29 Nov 1999 11:27:43 -0000 Received: from usrpri2-66.kiva.net (HELO megalith.bp.aventail.com) (206.97.75.131) by biff.kiva.net with SMTP; 29 Nov 1999 11:27:43 -0000 Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA18794; Mon, 29 Nov 1999 06:31:02 -0500 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Broken makeinfo? [was: Re: Fix this] X-Now-Listening-To: Mozart - Voi, Che Sapete References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <9t9yabhvd7v.fsf@mraz.iskon.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 26 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > "Stephen J. Turnbull" writes: > > > Or maybe we don't care, because we don't care if people can build > > their own info docs or nobody ever does? > > If we ship the pre-built info docs with the source tarballs (as GNU > programs normally do), then people's ability to build their own docs > with obsolete makeinfo's is not of paramount importance. > > If we do not distribute the pre-built infos, we should at least try to > make sure people can build them with the versions of makeinfo that are > generally available. Depending on the latest-and-greatest versions of > software in order to build XEmacs is permissible, but annoying. > > > Or maybe we should think about abandoning (!) Texinfo in favor of a > > real DTD not defined by an implementation? > > Please please not that discussion again. Texinfo serves nicely for what > we want to do. Unless a LOT of the SGML display engine was done in C, which we want to avoid right now I think :) -bp From owner-xemacs-beta@xemacs.org Mon Nov 29 06:31:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08500 for xemacs-beta-out; Mon, 29 Nov 1999 06:31:51 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA08497; Mon, 29 Nov 1999 06:31:49 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id DAA01182; Mon, 29 Nov 1999 03:31:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.25632.530738.757272@lasker.666.com> Date: Mon, 29 Nov 1999 03:31:44 -0800 (PST) From: Martin Buchholz To: "Stephen J. Turnbull" , XEmacs Patches Cc: xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] In-Reply-To: <14402.21854.191050.800335@turnbull.sk.tsukuba.ac.jp> References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <14402.18349.405786.824478@lasker.666.com> <14402.21854.191050.800335@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "S" == Stephen J Turnbull writes: >>>>> "mb" == Martin Buchholz writes: mb> People who download pre-packaged tarballs will not have any mb> problems since their info files will already be up-to-date. mb> Only CVS users will have to upgrade, or get up-to-date info mb> files from the packaged tarballs. S> OK, so we don't have to care, I guess. S> The lack of reports on xemacs-beta is quite possibly S> meaningless; as I reported recently, "make beta" does not S> rebuild info by default. mb> ??? mb> Just `make' rebuilds the info files by default. S> Well, I read most of the traffic on xemacs-beta. I do not recall S> having seen "./config.status --recheck; make beta" deprecated as the S> normal way to build an XEmacs beta. This is still the procedure as of S> CVS checked out 2.5 hours ago in etc/BETA. Oh, now I understand. Well, of course `make beta' should remake the info files. This is a bug. Try this obvious untested patch (can this be wrong?) ChangeLog: 1999-11-29 Martin Buchholz * Makefile.in.in (beta): `make beta' should rebuild info. Index: Makefile.in.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/Attic/Makefile.in.in,v retrieving revision 1.1.2.17 diff -u -w -r1.1.2.17 Makefile.in.in --- Makefile.in.in 1999/11/27 21:30:49 1.1.2.17 +++ Makefile.in.in 1999/11/29 11:30:57 @@ -260,7 +260,7 @@ .PHONY: ${SUBDIR} all beta all-elc all-elcs dump-elc dump-elcs autoloads finder ## Convenience target for XEmacs beta testers -beta: clean all-elc finder +beta: clean all-elc finder info ## Convenience target for XEmacs maintainers ## This would run `make-xemacsdist' if I were really confident that everything From owner-xemacs-beta@xemacs.org Mon Nov 29 06:37:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08680 for xemacs-beta-out; Mon, 29 Nov 1999 06:37:41 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA08675 for ; Mon, 29 Nov 1999 06:37:38 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id DAA01193; Mon, 29 Nov 1999 03:37:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.25981.280195.940386@lasker.666.com> Date: Mon, 29 Nov 1999 03:37:33 -0800 (PST) From: Martin Buchholz To: Jan Vroonhof Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] In-Reply-To: References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <14402.18349.405786.824478@lasker.666.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Martin Buchholz writes: >> I merely imported the info.texi file from the texinfo distribution. Jan> Isn't this a bad idea in itself..? The documentation we ship should This is the way it's always been... Jan> document the code we ship, in particular our versions of texinfo.el Jan> and texinfmt.el. Let the makeinfo program carry its own version of Jan> 'info.texi'. (Yes I know these will shadow each other, but that is Jan> just the dir system being broken). >> Now that I look at it, there is only 2 occurrence of @ifnottex in >> man/, so it is actually reasonable to change them, for now, assuming >> this causes no problems for texi2html. Jan> That might be difficult as the new version was introduced for Jan> texi2html. Anyhow, I would say "scr*w texi2html". >> Do we actually know that makeinfo from 3.12 fails, while 3.12f works fine? Jan> This version fails... Jan> urysohn:/scratch/vroonhof/xemacs/man> makeinfo --version Jan> makeinfo (GNU texinfo 3.12) 1.68 Jan> Note that this version comes from TeXLive 3.99 which is one of the Jan> most up to date TeX distributions there is. Jan> Does anybody have teTeX 1.0 installed to check which version that uses? We could of course revert to the previous versions of info.texi and texinfo.texi. But my choice would be to fix the problems with the current .texi files. Or delete them. Martin From owner-xemacs-beta@xemacs.org Mon Nov 29 08:01:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11973 for xemacs-beta-out; Mon, 29 Nov 1999 08:01:47 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11970 for ; Mon, 29 Nov 1999 08:01:45 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id OAA09889 for ; Mon, 29 Nov 1999 14:01:43 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id OAA25964; Mon, 29 Nov 1999 14:01:43 +0100 (MET) To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Mon_Nov_29_14:01:38_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 29 Nov 1999 14:01:43 +0100 In-Reply-To: Kyle Jones's message of "Mon, 29 Nov 1999 02:40:36 -0800 (PST)" Message-ID: Lines: 37 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Mon_Nov_29_14:01:38_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Kyle" == Kyle Jones writes: Kyle> I'm in favor of keeping compatibility with the old interface Kyle> and, if necessary, accepting some awkwardness in the new names. Kyle> But given that low level and high level search functions take Kyle> different parameters, ldap-search could be smart and call the Kyle> high level function if it looks like that's what the application Kyle> wants. So maybe the problem can be avoided. I can name the low-level search function ldap-search1 or something and define a new wrapper ldap-search that calls either ldap-search1 or ldap-search-entries depending on the type of the first parameter (ldapp or not). But I wonder if it's really worth cluttering the code with such a compatibility hack when nobody will actually need it as soon as EUDC an W3 are updated. I agree compatibility *is* a MUST for features that are widely used. I believe the LDAP API currently is not. Oscar --pgp-sign-Multipart_Mon_Nov_29_14:01:38_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOEJ5NZ7CaiYEgqPZAQFmEwH9HmVlTJsU6tRscz2/E8wX25ih9Id0MxiL kM+4RghxamZEW6LwzXtWsqpXV/Sdz1NbdJtZMkyOygz8yCdJ2H/0Ig== =rChF -----END PGP MESSAGE----- --pgp-sign-Multipart_Mon_Nov_29_14:01:38_1999-1-- From owner-xemacs-beta@xemacs.org Mon Nov 29 08:48:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA13810 for xemacs-beta-out; Mon, 29 Nov 1999 08:48:07 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA13806; Mon, 29 Nov 1999 08:48:04 -0500 Received: by avon.delcam.com; Mon, 29 Nov 1999 13:46:57 GMT Received: by pat.delcam.com; Mon, 29 Nov 1999 13:48:01 GMT Received: by dr2.delcam.com; Mon, 29 Nov 1999 13:48:03 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.33810.975446.432893@pub.news.uk.psi.net> Date: Mon, 29 Nov 1999 13:48:02 +0000 (GMT) To: xemacs-build-reports@xemacs.org CC: xemacs-beta@xemacs.org Subject: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' X-Mailer: VM 6.71 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) X-Face: "+N/{>9S5,OIk<0$%[)LGd} I cvs updated and initially configured without the portable dumper. I got the same problem reported a couple of weeks ago, namely: Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loadhist.elc... Loading /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... Fatal error: assertion failed, file /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/lisp.h, line 647, RECORD_TYPEP (obj, &lrecord_cons) make[1]: *** [xemacs] Abort make[1]: *** Deleting file `xemacs' make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 So I configured with the portable dumping enabled. uname -a: IRIX dr2 6.2 03131015 IP22 ../configure '--site-libraries=/usr/local/lib' '--site-includes=/usr/local/include' '--cflags=-g' '--package-path=/devdisk/d54man/gnu/xemacs-beta/packages' '--with-mule=no' '--pdump=yes' XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2'. Where should the build process find the source code? /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -g Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using the new portable dumper (wishful thinking). Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- When I try to run temacs I get the following before any window appears. dr2% ./temacs Fatal error (11). When I run it under a debugger, I get the following traceback. I hope it is of some help. shut_down_emacs(sig = 11, stuff = 0) ["emacs.c":2494] fatal_error_signal(sig = 11) ["emacs.c":257] _sigtramp() ["sigtramp.s":59] pdump_load() ["alloc.c":5051] xemacs_21_2_b22_mips_sgi_irix6_2(argc = 1, argv = 0x7fff2f24, envp = 0x7fff2f2c, restart = 0) ["emacs.c":867] main(argc = 1, argv = 0x7fff2f24, envp = 0x7fff2f2c) ["emacs.c":2261] __istart() ["crt1tinit.s":13] If it helps, i is zero in the loop where it fails in pdump_load. I now have no way of running the latest stuff, so some help fixing it would be appreciated. -- Paul From owner-xemacs-beta@xemacs.org Mon Nov 29 09:06:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA14699 for xemacs-beta-out; Mon, 29 Nov 1999 09:06:48 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA14694; Mon, 29 Nov 1999 09:06:45 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA18864; Mon, 29 Nov 1999 15:06:38 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004af; Mon Nov 29 15:06:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA05667; Mon, 29 Nov 1999 15:06:32 +0100 To: Paul Bibilo Cc: xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' References: <14402.33810.975446.432893@pub.news.uk.psi.net> From: Jan Vroonhof Date: 29 Nov 1999 15:06:32 +0100 In-Reply-To: Paul Bibilo's message of "Mon, 29 Nov 1999 13:48:02 +0000 (GMT)" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Paul Bibilo writes: > I cvs updated and initially configured without the portable dumper. I > got the same problem reported a couple of weeks ago, namely: Does applying http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00042.html help? Jan From owner-xemacs-beta@xemacs.org Mon Nov 29 10:01:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA16833 for xemacs-beta-out; Mon, 29 Nov 1999 10:01:49 -0500 Received: from avon.delcam.com (avon.delcam.com [194.193.182.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA16829 for ; Mon, 29 Nov 1999 10:01:43 -0500 Received: by avon.delcam.com; Mon, 29 Nov 1999 15:00:34 GMT Received: by pat.delcam.com; Mon, 29 Nov 1999 15:01:37 GMT Received: by dr2.delcam.com; Mon, 29 Nov 1999 15:01:39 GMT From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.38227.288055.597083@pub.news.uk.psi.net> Date: Mon, 29 Nov 1999 15:01:39 +0000 (GMT) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' In-Reply-To: Jan Vroonhof's messaage of 29 November 1999 15:06:32 References: <14402.33810.975446.432893@pub.news.uk.psi.net> X-Mailer: VM 6.71 under 21.2 (beta22) "Mercedes" XEmacs Lucid X-Face: "+N/{>9S5,OIk<0$%[)LGd} Jan Vroonhof writes: > Paul Bibilo writes: > > > I cvs updated and initially configured without the portable dumper. I > > got the same problem reported a couple of weeks ago, namely: > > Does applying > > http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00042.html > > help? > Yes it does. Thankyou. The lib-src/Makefile.in.in didn't apply cleanly, but I didn't worry about it. I can now build and run xemacs without the portable dumper. I haven't tried with it yet. Please could somebody arrange for the above patch to be applied to 21.2. TIA, -- Paul From owner-xemacs-beta@xemacs.org Mon Nov 29 10:02:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA16856 for xemacs-beta-out; Mon, 29 Nov 1999 10:02:28 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA16842 for ; Mon, 29 Nov 1999 10:02:15 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id QAA01167; Mon, 29 Nov 1999 16:02:01 +0100 To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 29 Nov 1999 16:02:01 +0100 In-Reply-To: Oscar Figueiredo's message of "29 Nov 1999 14:01:43 +0100" Message-ID: <9t93dtptk7q.fsf@mraz.iskon.hr> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Mercedes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes: > But I wonder if it's really worth cluttering the code with such a > compatibility hack when nobody will actually need it as soon as EUDC > an W3 are updated. I agree compatibility *is* a MUST for features > that are widely used. I believe the LDAP API currently is not. I agree with you. Backward compatibility is a good thing, but it is not required in all cases. From owner-xemacs-beta@xemacs.org Mon Nov 29 12:15:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA21818 for xemacs-beta-out; Mon, 29 Nov 1999 12:15:42 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA21815 for ; Mon, 29 Nov 1999 12:15:39 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA01456; Mon, 29 Nov 1999 18:15:38 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Mi; Mon Nov 29 18:15:37 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA06776; Mon, 29 Nov 1999 18:15:37 +0100 To: Paul Bibilo Cc: xemacs-beta@xemacs.org Subject: Re: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' References: <14402.33810.975446.432893@pub.news.uk.psi.net> <14402.38227.288055.597083@pub.news.uk.psi.net> From: Jan Vroonhof Date: 29 Nov 1999 18:15:36 +0100 In-Reply-To: Paul Bibilo's message of "Mon, 29 Nov 1999 15:01:39 +0000 (GMT)" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Paul Bibilo writes: > Please could somebody arrange for the above patch to be applied to > 21.2. Unfortunately it cannot be included in this form (it possibly breaks other stuff and it needs documentation that was send separately folded in). Nobody has found the time yet do a proper patch. Something like this is also needed for 21.1.9 jan From owner-xemacs-beta@xemacs.org Mon Nov 29 12:17:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA21876 for xemacs-beta-out; Mon, 29 Nov 1999 12:17:17 -0500 Received: from hqinbh1.ms.com (hqinbh1-e1.ms.com [205.228.12.65] (may be forged)) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA21872 for ; Mon, 29 Nov 1999 12:17:13 -0500 Received: (from uucp@localhost) by hqinbh1.ms.com (8.8.6/fw v1.30) id MAA20869 for ; Mon, 29 Nov 1999 12:17:11 -0500 (EST) Received: from unknown(144.14.9.142) by hqinbh1 via smap (4.1) id xma020701; Mon, 29 Nov 99 12:17:00 -0500 Received: from yesha.morgan.com (yesha.morgan.com [144.14.16.237]) by samail3.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id MAA04550 for ; Mon, 29 Nov 1999 12:17:00 -0500 (EST) Received: (hollande@localhost) by yesha.morgan.com (8.8.5/sendmail.cf.client v1.05) id MAA27684; Mon, 29 Nov 1999 12:17:00 -0500 (EST) Date: Mon, 29 Nov 1999 12:17:00 -0500 (EST) Message-Id: <199911291717.MAA27684@yesha.morgan.com> From: Isaac Hollander To: xemacs-beta@xemacs.org Subject: 21.1.8 IRIX 6.5 IP27 build trouble Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm trying to build xemacs 21.1.8 on IRIX 6.5 IP27, and temacs is misbehaving. hollande@sag1:/ms/dev/fsf/xemacs>uname -a IRIX64 sag1 6.5 07151439 IP27 [ compiler kachunks ] ... EMACSBOOTSTRAPLOADPATH="/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/:/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5" ./temacs -batch -l /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/loadup.el dump Loading /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/loadup.el... Using load-path (/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/ /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5) [ lots of lisp loaded ] Dumping under the name xemacs Purespace usage: 655996 of 655996 (100%). XEmacs: Program segment above .bss in /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/temacs gmake[3]: [xemacs] Error 1 (ignored) Testing for Lisp shadows ... /bin/sh: ./xemacs: cannot execute Has anyone built xemacs with SGI's native compiler (version 7.213)? The error message comes from unexelfsgi.c. I tried using the unexelfsgi.c from the latest 21.2 beta (there are some changes), but got the same error. Worse yet, when I tried building with gcc 2.8.1, temacs coredumped: EMACSBOOTSTRAPLOADPATH="/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/:/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5" ./temacs -batch -l /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/loadup.el dump Loading /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/loadup.el... Using load-path (/ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5/src/../lisp/ /ms/dev/fsf/xemacs/21.1.8/build/mips4.irix.6.5) [ lots of lisp loaded ] Loading site-load... (280) Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Purespace usage: 655996 of 655996 (100%). gmake[2]: *** [xemacs] Bus error (core dumped) I have not yet tried gcc 2.95.2. Any ideas would be appreciated. Thanks Isaac From owner-xemacs-beta@xemacs.org Mon Nov 29 12:52:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA23305 for xemacs-beta-out; Mon, 29 Nov 1999 12:52:20 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA23300 for ; Mon, 29 Nov 1999 12:52:18 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA02168; Mon, 29 Nov 1999 18:52:12 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Xq; Mon Nov 29 18:52:06 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA06797; Mon, 29 Nov 1999 18:52:05 +0100 To: Isaac Hollander Cc: xemacs-beta@xemacs.org Subject: Re: 21.1.8 IRIX 6.5 IP27 build trouble References: <199911291717.MAA27684@yesha.morgan.com> From: Jan Vroonhof Date: 29 Nov 1999 18:52:05 +0100 In-Reply-To: Isaac Hollander's message of "Mon, 29 Nov 1999 12:17:00 -0500 (EST)" Message-ID: Lines: 11 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Isaac Hollander writes: > I'm trying to build xemacs 21.1.8 on IRIX 6.5 IP27, and temacs is > misbehaving. Try http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00042.html Jan From owner-xemacs-beta@xemacs.org Mon Nov 29 14:33:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA27005 for xemacs-beta-out; Mon, 29 Nov 1999 14:33:27 -0500 Received: from crystal.WonderWorks.COM (crystal.WonderWorks.COM [192.203.206.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA26996 for ; Mon, 29 Nov 1999 14:33:23 -0500 Received: by crystal.WonderWorks.COM id QQhrlu07016; Mon, 29 Nov 1999 11:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.54528.692442.58601@crystal.WonderWorks.COM> Date: Mon, 29 Nov 1999 11:33:20 -0800 (PST) From: Kyle Jones To: XEmacs Beta List Subject: Re: LDAP extended and revamped In-Reply-To: <9t93dtptk7q.fsf@mraz.iskon.hr> References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> <9t93dtptk7q.fsf@mraz.iskon.hr> X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Face: ;"N#erdo^~tQ=4fSo-v#C+fU)!c;WrKU2R.7N.P/0[D_o^D0bvXgo8 6Q1fPW\=9jq4`X)sCGLH],+MT8M1Ck.\var-d>CObqT[!mr{U{)Sba Fx!1QptHaPGO=CL5~M21kr7:RG\Fe~A*]F.]TFC6g!YZTFWCjX[iu$ ~RE Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Oscar Figueiredo writes: > > > But I wonder if it's really worth cluttering the code with such a > > compatibility hack when nobody will actually need it as soon as EUDC > > an W3 are updated. I agree compatibility *is* a MUST for features > > that are widely used. I believe the LDAP API currently is not. > > I agree with you. Backward compatibility is a good thing, but it is > not required in all cases. This looks like hand-waving to me. We don't know how much the existing API is being used. That's why we should adopt a philosophy of never breaking the API once it has been released. I could understand the "we can probably get away with it" excuse if maintaining compatibility were difficult. But this is easy. How are we going to maintain compatibility when it is difficult to do so, when we won't even insist on it when it is easy? From owner-xemacs-beta@xemacs.org Mon Nov 29 16:40:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA32198 for xemacs-beta-out; Mon, 29 Nov 1999 16:40:12 -0500 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA32181; Mon, 29 Nov 1999 16:39:54 -0500 Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by steadfast.teradyne.com (8.8.5/8.7.1) with ESMTP id QAA20973; Mon, 29 Nov 1999 16:46:55 -0500 (EST) Received: from ZJ75T.ecf.teradyne.com ([131.101.117.143]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id WAA04931; Mon, 29 Nov 1999 22:39:30 +0100 (MET) To: martin@xemacs.org Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: Broken makeinfo? [was: Re: Fix this] References: <14399.24386.685515.394889@lasker.666.com> <14402.15220.524736.172450@turnbull.sk.tsukuba.ac.jp> <14402.18349.405786.824478@lasker.666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 29 Nov 1999 22:37:20 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 29 Nov 1999 01:30:21 -0800 (PST)" Message-ID: Lines: 25 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Martin" == Martin Buchholz writes: Martin> since their info files will already be up-to-date. Only Martin> CVS users will have to upgrade, or get up-to-date info Martin> files from the packaged tarballs. Using the hopefully-soon-to-be-released texinfo package the latest info docs will build. Martin> Do we actually know that makeinfo from 3.12 fails, while Martin> 3.12f works fine? texinfo-3.12f does not support @ifnottex on WIN32. S> which reverses the other change to the Texinfo commands in that S> region. (The three @nodes that don't have a full complement of S> pointers were all introduced by your patch, probably need to change S> the others too.) Dunno if that will help, but I know makeinfo has S> been sensitive to xref issues in the past, and has never been good at S> giving useful error messages. Adrian Martin> Martin From owner-xemacs-beta@xemacs.org Mon Nov 29 17:14:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA01685 for xemacs-beta-out; Mon, 29 Nov 1999 17:14:29 -0500 Received: from hqinbh2.ms.com (hqinbh2.ms.com [205.228.12.72]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA01680 for ; Mon, 29 Nov 1999 17:14:22 -0500 Received: (from uucp@localhost) by hqinbh2.ms.com (8.8.6/fw v1.30) id RAA02409; Mon, 29 Nov 1999 17:14:19 -0500 (EST) Received: from unknown(144.14.19.186) by hqinbh2 via smap (4.1) id xma002215; Mon, 29 Nov 99 17:14:12 -0500 Received: from yesha.morgan.com (yesha.morgan.com [144.14.16.237]) by sasmh1.ms.com (8.8.5/hub+ldap v2.4) with ESMTP id RAA00327; Mon, 29 Nov 1999 17:14:11 -0500 (EST) Received: (hollande@localhost) by yesha.morgan.com (8.8.5/sendmail.cf.client v1.05) id RAA03155; Mon, 29 Nov 1999 17:14:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14402.64179.60192.523339@yesha.ms.com> Date: Mon, 29 Nov 1999 17:14:11 -0500 (EST) From: Isaac.Hollander@msdw.com To: Jan Vroonhof Cc: Isaac Hollander , xemacs-beta@xemacs.org Subject: Re: 21.1.8 IRIX 6.5 IP27 build trouble In-Reply-To: References: <199911291717.MAA27684@yesha.morgan.com> X-Mailer: VM 6.75 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >> I'm trying to build xemacs 21.1.8 on IRIX 6.5 IP27, and temacs is >> misbehaving. Jan> Try Jan> http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00042.html This seems to work. xemacs builds and starts. Are there any plans to include this patch[1] in 21.1.9 and/or the next 21.2 beta? Thanks for the help. Here is my Installation file, for those who record these things: uname -a: IRIX64 sag3 6.5 07151439 IP27 ./configure 'mips-sgi-irix6.5' '--extra-verbose' '--cflags=-DXTHREADS' '--with- scrollbars=athena' '--with-menubars=athena' '--with-cde=no' '--with-tooltalk=no' '--with-dragndrop=no' '--with-session=no' '--with-xpm=yes' '--with-xface=yes' ' --with-png=yes' '--prefix=/ms/dist/fsf/PROJ/xemacs/21.1.8/common' '--with-sound= native' '--run-in-place=no' '--exec-prefix=/ms/dist/fsf/PROJ/xemacs/21.1.8/exec' '--site-includes= /ms/dist/aurora/PROJ/xpm/3.4k/common/include /ms/dist/aurora/ PROJ/zlib/1.1.3/include /ms/dist/aurora/PROJ/png/1.0.3/include /ms/dist/aurora/P ROJ/compface/1.0/common/include /ms/dist/sec/PROJ/socks/5.1.0.10/include /ms/dis t/itsmg/include' '--site-libraries= /ms/dist/aurora/PROJ/xpm/3.4k/exec/lib /ms/d ist/aurora/PROJ/zlib/1.1.3/lib /ms/dist/aurora/PROJ/png/1.0.3/lib/ /ms/dist/auro ra/PROJ/compface/1.0/exec/lib /ms/dist/sec/PROJ/socks/5.1.0.10/lib /ms/dist/itsm g/lib' XEmacs 21.1.8 "Bryce Canyon" configured for `mips-sgi-irix6.5'. Where should the build process find the source code? /ms/dev/fsf/xemacs/21. 1.8/build/mips4.irix.6.5 What installation prefix should install use? /ms/dist/fsf/PROJ/xema cs/21.1.8/common What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -DXTHREADS Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Additional header files: /ms/dist/aurora/PROJ/ xpm/3.4k/common/include /ms/dist/aurora/PROJ/zlib/1.1.3/include /ms/dist/aurora/ PROJ/png/1.0.3/include /ms/dist/aurora/PROJ/compface/1.0/common/include /ms/dist /sec/PROJ/socks/5.1.0.10/include /ms/dist/itsmg/include Additional libraries: /ms/dist/aurora/PROJ/ xpm/3.4k/exec/lib /ms/dist/aurora/PROJ/zlib/1.1.3/lib /ms/dist/aurora/PROJ/png/1 .0.3/lib/ /ms/dist/aurora/PROJ/compface/1.0/exec/lib /ms/dist/sec/PROJ/socks/5.1 .0.10/lib /ms/dist/itsmg/lib Runtime library search path: /ms/dist/aurora/PROJ/x pm/3.4k/exec/lib:/ms/dist/aurora/PROJ/zlib/1.1.3/lib:/ms/dist/aurora/PROJ/png/1. 0.3/lib/:/ms/dist/sec/PROJ/socks/5.1.0.10/lib:/ms/dist/itsmg/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in support for LDAP (Netscape SDK). Using Lucid menubars. Using Athena scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. [1] Actually, the patch contained etags and windows fixes as well; I ignored them. From owner-xemacs-beta@xemacs.org Mon Nov 29 18:10:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA04308 for xemacs-beta-out; Mon, 29 Nov 1999 18:10:40 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA04298; Mon, 29 Nov 1999 18:10:36 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id PAA01617; Mon, 29 Nov 1999 15:10:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14403.2027.43065.65608@lasker.666.com> Date: Mon, 29 Nov 1999 15:10:35 -0800 (PST) From: Martin Buchholz To: XEmacs Patches , XEmacs Beta Test Subject: masochistically midwifing misfit makeinfos X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: If this works, it should make everyone happy. Someone has to test it with a broken makeinfo, however, before I commit. Please report results to me. ChangeLog: 1999-11-29 Martin Buchholz * info.texi (Top): * texinfo.texi (Top): Remove @ifnottex, which gives old makeinfos indigestion. Index: info.texi =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/man/info.texi,v retrieving revision 1.4.2.2 diff -u -w -r1.4.2.2 info.texi --- info.texi 1999/11/17 23:28:34 1.4.2.2 +++ info.texi 1999/11/29 22:57:44 @@ -66,15 +66,14 @@ by the Free Software Foundation. @end titlepage -@ifnottex @node Top @top Info: An Introduction -Info is a program for reading documentation, which you are using now. +Info is a program for reading documentation, which you might be using +now to read this. -To learn how to use Info, type the command @kbd{h}. It brings you -to a programmed instruction sequence. -@end ifnottex +To learn how to use Info, type the command @kbd{h} while using the Info +program. It brings you to a programmed instruction sequence. @menu * Getting Started:: Getting started using an Info reader. Index: texinfo.texi =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/man/texinfo.texi,v retrieving revision 1.8.2.3 diff -u -w -r1.8.2.3 texinfo.texi --- texinfo.texi 1999/11/17 23:28:29 1.8.2.3 +++ texinfo.texi 1999/11/29 22:57:59 @@ -132,7 +132,6 @@ @summarycontents @contents -@ifnottex @node Top @top Texinfo @@ -144,7 +143,6 @@ the menu lists all the lower level nodes in the document. This is Edition @value{VERSION} of the Texinfo manual, updated @value{UPDATED}. -@end ifnottex @menu * Copying:: Your rights. From owner-xemacs-beta@xemacs.org Mon Nov 29 20:08:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA09012 for xemacs-beta-out; Mon, 29 Nov 1999 20:08:18 -0500 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA09009 for ; Mon, 29 Nov 1999 20:08:14 -0500 Received: from mindspring.com (user-2inij56.dialup.mindspring.com [165.121.76.166]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA19825; Mon, 29 Nov 1999 20:07:44 -0500 (EST) Message-ID: <38432427.7404CFC9@mindspring.com> Date: Mon, 29 Nov 1999 20:11:03 -0500 From: Isaac Hollander X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kyle Jones CC: XEmacs Beta List , oscar.figueiredo@di.epfl.ch Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> <9t93dtptk7q.fsf@mraz.iskon.hr> <14402.54528.692442.58601@crystal.WonderWorks.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones wrote: > > Hrvoje Niksic writes: > > Oscar Figueiredo writes: > > > > > But I wonder if it's really worth cluttering the code with such a > > > compatibility hack when nobody will actually need it as soon as EUDC > > > an W3 are updated. I agree compatibility *is* a MUST for features > > > that are widely used. I believe the LDAP API currently is not. > > > > I agree with you. Backward compatibility is a good thing, but it is > > not required in all cases. > > This looks like hand-waving to me. We don't know how much the > existing API is being used. That's why we should adopt a > philosophy of never breaking the API once it has been released. > I could understand the "we can probably get away with it" excuse > if maintaining compatibility were difficult. But this is easy. > How are we going to maintain compatibility when it is difficult > to do so, when we won't even insist on it when it is easy? I would also add that the current configure test for the netscape LDAP SDK fails because newer netscape SDKs have ldap_open(), but configure thinks that only the umich ldap libraries have ldap_open(). I've worked around the problem by running $ with_umich_ldap=no with_ns_ldap=yes ./configure .... I'm not sure what the best way to fix this is... Isaac From owner-xemacs-beta@xemacs.org Tue Nov 30 00:35:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA19019 for xemacs-beta-out; Tue, 30 Nov 1999 00:35:59 -0500 Received: from miho.m17n.org (miho.m17n.org [192.47.44.106]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA19013 for ; Tue, 30 Nov 1999 00:35:56 -0500 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id OAA15232; Tue, 30 Nov 1999 14:33:55 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: xemacs-21.2.22 "Mercedes" is released X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Nov 1999 14:33:54 +0900 Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [There is no 21.2.21] There were problems with cvs.xemacs.org yesterday that look like they've been resolved today. If there are any problems with the packaging, hollar and I'll quickly make a new release, otherwise 21.2.23 is scheduled for Monday, December 6. to 21.2.22 "Mercedes" -- ESD Sound support from Robert Bihlmeyer -- 10% faster redisplay from Jan Vroonhof -- Fixes from Jeff Miller, Alexandre Oliva and Yoshiki Hayashi -- "If you've got problems, read PROBLEMS!" from Robert Pluim -- Lstream code now uses size_t, ssize_t consistently, Martin Buchholz -- Fix `make install' if prefix != exec_prefix, Martin Buchholz -- Fix compile warnings and C++ compilation, Martin Buchholz -- Fix detection of coding: cookie in -*- first line. -- More xim-xlib work by Kazuyuki Ienaga -- Fix crash in abbrev.c (abbrev_location), Eric Darve From owner-xemacs-beta@xemacs.org Tue Nov 30 01:08:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA20467 for xemacs-beta-out; Tue, 30 Nov 1999 01:08:26 -0500 Received: from apollonius.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA20464 for ; Tue, 30 Nov 1999 01:08:24 -0500 Received: from KEATS.eai-delta.de (keats.eai-delta.de [192.9.200.85]) by apollonius.eai-delta.de (8.9.3/8.8.7) with SMTP id HAA04298 for ; Tue, 30 Nov 1999 07:08:23 +0100 To: XEmacs Beta List Subject: Re: masochistically midwifing misfit makeinfos References: <14403.2027.43065.65608@lasker.666.com> Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: . Date: 30 Nov 1999 07:08:23 +0100 In-Reply-To: Martin Buchholz's message of "Mon, 29 Nov 1999 15:10:35 -0800 (PST)" Message-ID: Lines: 31 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Mercedes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Martin Buchholz writes: > If this works, it should make everyone happy. Someone has to test it > with a broken makeinfo, however, before I commit. Please report > results to me. [...] Martin, that's close, but now I get the following error: texinfo formatting d:\nok\xemacs\man\texinfo.texi... Formatting Info file... Formatting Info file: ../info/texinfo.info Converting texinfo.texi to Info format... Removing trailing whitespace from Info buffer... Formatting: Texinfo ... Formatting: Texinfo Copying Conditions ... Formatting: Overview of Texinfo ... Formatting: Reporting Bugs ... >> Error: (error "@command is not handled by texinfo") >> point at >> {configure}. >> @item the contents of any input files necessary to reproduce the bug. >> @item a descripti NMAKE : fatal error U1077: '..\src\xemacs.exe' : return code '0x1' Stop. At least, the other errors are gone :-) Norbert. From owner-xemacs-beta@xemacs.org Tue Nov 30 01:26:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA21331 for xemacs-beta-out; Tue, 30 Nov 1999 01:26:50 -0500 Received: from lasker.666.com (adsl-63-193-121-52.dsl.snfc21.pacbell.net [63.193.121.52]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA21320 for ; Tue, 30 Nov 1999 01:26:46 -0500 Received: (from martin@localhost) by lasker.666.com (8.9.3/8.9.3) id WAA01972; Mon, 29 Nov 1999 22:26:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14403.28191.305101.588471@lasker.666.com> Date: Mon, 29 Nov 1999 22:26:39 -0800 (PST) From: Martin Buchholz To: Norbert Koch Cc: XEmacs Beta List Subject: Re: masochistically midwifing misfit makeinfos In-Reply-To: References: <14403.2027.43065.65608@lasker.666.com> X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: martin@xemacs.org Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "N" == Norbert Koch writes: N> Martin Buchholz writes: >> If this works, it should make everyone happy. Someone has to test it >> with a broken makeinfo, however, before I commit. Please report >> results to me. N> [...] N> Martin, N> that's close, but now I get the following error: N> texinfo formatting d:\nok\xemacs\man\texinfo.texi... N> Formatting Info file... N> Formatting Info file: ../info/texinfo.info N> Converting texinfo.texi to Info format... N> Removing trailing whitespace from Info buffer... N> Formatting: Texinfo ... N> Formatting: Texinfo Copying Conditions ... N> Formatting: Overview of Texinfo ... N> Formatting: Reporting Bugs ... >>> Error: (error "@command is not handled by texinfo") >>> point at >>> {configure}. >>> @item the contents of any input files necessary to reproduce the bug. >>> @item a descripti N> NMAKE : fatal error U1077: '..\src\xemacs.exe' : return code '0x1' N> Stop. N> At least, the other errors are gone :-) That looks like it's not using makeinfo, but instead texinfmt.el. I guess texinfmt.el has not yet been upgraded to handle the new .info files, but there are plans to work on this. Martin From owner-xemacs-beta@xemacs.org Tue Nov 30 02:38:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA23763 for xemacs-beta-out; Tue, 30 Nov 1999 02:38:35 -0500 Received: from lspsun12.epfl.ch (lspsun12.epfl.ch [128.178.75.34]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA23755 for ; Tue, 30 Nov 1999 02:38:32 -0500 Received: from lspsun17.epfl.ch (figueire@lspsun17.epfl.ch [128.178.75.85]) by lspsun12.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id IAA12009 for ; Tue, 30 Nov 1999 08:38:27 +0100 (MET) Received: (from figueire@localhost) by lspsun17.epfl.ch (8.8.X/EPFL-8.1a) id IAA27203; Tue, 30 Nov 1999 08:38:27 +0100 (MET) To: XEmacs Beta List Subject: LDAP configure broken for Netscape (was: Re: LDAP extended and revamped) References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> <9t93dtptk7q.fsf@mraz.iskon.hr> <14402.54528.692442.58601@crystal.WonderWorks.COM> <38432427.7404CFC9@mindspring.com> X-Attribution: Oscar X-Face: &f0TVPZirOQ$"C[5pZkDY(1~+M1p0&edTtJPL-*?u$b(vr<1m?~iZBqp2YoDS[IyxDHVU~)KHl|Kpm"='5OF?vT]k_HQ1]|^}Pm>,;+]iJCt_-Y[S\ EpwT);2R8#[4dt8~*}$6xI4jNZM9lVHua'vIM[PEx*#cgxCVruf1zN0} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="pgp-sign-Multipart_Tue_Nov_30_08:38:20_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 30 Nov 1999 08:38:27 +0100 In-Reply-To: Isaac Hollander's message of "Mon, 29 Nov 1999 20:11:03 -0500" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Tue_Nov_30_08:38:20_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Isaac" == Isaac Hollander writes: Isaac> I would also add that the current configure test for the netscape LDAP Isaac> SDK fails because newer netscape SDKs have ldap_open(), but configure Isaac> thinks that only the umich ldap libraries have ldap_open(). I've worked Isaac> around the problem by running Isaac> $ with_umich_ldap=no with_ns_ldap=yes ./configure .... Isaac> I'm not sure what the best way to fix this is... Isaac> Isaac Can you provide a specific version number of the Netscape SDK where this problem shows up ? I'll try to give it a look. Oscar --pgp-sign-Multipart_Tue_Nov_30_08:38:20_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQBVAwUBOEN+8Z7CaiYEgqPZAQEM2QIAyYWI+I3rsTH2xW/4dgu5NiCYQcqrJQoE N07svRWYJ8uM82cOo5WxFkjFx71sbeGY86BgszPBQh8SSNTnWqzxpw== =tec1 -----END PGP MESSAGE----- --pgp-sign-Multipart_Tue_Nov_30_08:38:20_1999-1-- From owner-xemacs-beta@xemacs.org Tue Nov 30 03:12:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA25332 for xemacs-beta-out; Tue, 30 Nov 1999 03:12:51 -0500 Received: from mraz.iskon.hr (mraz.iskon.hr [195.29.170.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA25326 for ; Tue, 30 Nov 1999 03:12:47 -0500 Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id JAA03560; Tue, 30 Nov 1999 09:12:41 +0100 To: XEmacs Beta List Subject: Re: LDAP extended and revamped References: <9t93dtpzox9.fsf@mraz.iskon.hr> <14402.18376.579429.871466@ltrpluim.corpemea.baynetworks.com> <14402.22564.957986.71828@crystal.WonderWorks.COM> <9t93dtptk7q.fsf@mraz.iskon.hr> <14402.54528.692442.58601@crystal.WonderWorks.COM> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 30 Nov 1999 09:12:40 +0100 In-Reply-To: Kyle Jones's message of "Mon, 29 Nov 1999 11:33:20 -0800 (PST)" Message-ID: <9t9bt8cqtxj.fsf@mraz.iskon.hr> Lines: 27 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Mercedes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes: > Hrvoje Niksic writes: > > Oscar Figueiredo writes: > > > > > But I wonder if it's really worth cluttering the code with such a > > > compatibility hack when nobody will actually need it as soon as EUDC > > > an W3 are updated. I agree compatibility *is* a MUST for features > > > that are widely used. I believe the LDAP API currently is not. > > > > I agree with you. Backward compatibility is a good thing, but it > > is not required in all cases. > > This looks like hand-waving to me. Not hand-waving. The LDAP thing has AFAIK been more or less experimental all this time. This is not the first change in API and in the implementation, if memory serves me. > We don't know how much the existing API is being used. That's why > we should adopt a philosophy of never breaking the API once it has > been released. I could understand the "we can probably get away > with it" excuse if maintaining compatibility were difficult. But > this is easy. How are we going to maintain compatibility when it is > difficult to do so, when we won't even insist on it when it is easy? I see your point. Either way, it's up to Oscar IMO. From owner-xemacs-beta@xemacs.org Tue Nov 30 05:25:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA29314 for xemacs-beta-out; Tue, 30 Nov 1999 05:25:06 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA29310 for ; Tue, 30 Nov 1999 05:25:04 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id KAA29546 for xemacs-beta@xemacs.org; Tue, 30 Nov 1999 10:28:21 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11sjR4-0004vK-00 for xemacs-beta@xemacs.org; Tue, 30 Nov 1999 10:18:58 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 361AF18BA; Tue, 30 Nov 1999 10:18:56 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Using mktemp for temporary files From: Andreas Jaeger Date: 30 Nov 1999 10:18:56 +0100 Message-ID: Lines: 37 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: A couple of scripts create temporary files - but those names are easy to guess and could lead to security problems. A better solution would be to use mktemp. I've got here a patch which does the following: --- lib-src/rcs2log +++ lib-src/rcs2log Thu Nov 11 17:41:36 1999 @@ -279,6 +279,15 @@ llogout=$TMPDIR/rcs2log$$l rlogout=$TMPDIR/rcs2log$$r +rm -f $llogout $rlogout +if test -e $llogout -o -e $rlogout ; then + echo "$0: temporary files $llogout or/and $rlogout exists." 1>&2 + exit 1 +fi +if test -n "`type -p mktemp`" ; then + llogout="`mktemp ${llogout}.XXXXXX`" || exit 1 + rlogout="`mktemp ${rlogout}.XXXXXX`" || exit 1 +fi trap exit 1 2 13 15 trap "rm -f $llogout $rlogout; exit 1" 0 What strikes me is that I don't know whether type -p is available in /bin/sh. Besides, does anybody have better ideas to rewrite this. There are a number of other scripts which needs rewriting. I've some likes to do this, I can forward the complete patch set I have. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 30 06:13:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA00383 for xemacs-beta-out; Tue, 30 Nov 1999 06:13:03 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA00380 for ; Tue, 30 Nov 1999 06:13:00 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id MAA07184 for xemacs-beta@xemacs.org; Tue, 30 Nov 1999 12:12:58 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11slCm-000598-00 for xemacs-beta@xemacs.org; Tue, 30 Nov 1999 12:12:20 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id A356618BA; Tue, 30 Nov 1999 12:12:18 +0100 (CET) To: xemacs-beta@xemacs.org Subject: xemacs-packages: Current state From: Andreas Jaeger Date: 30 Nov 1999 12:12:18 +0100 Message-ID: Lines: 21 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've applied a number of patches to xemacs-packages and I think we should consider putting out new versions and sumo-tarballs. I've got the following open problems: - Are there any patches that need to be checked in? Steve, what is in your patch queue (btw. feel free to send all patches to me - I'll apply them asap) ? - psgml 1.2.1 is out. I haven't integrated it. Anybody else going to make a tested patch for me? - When and how will the package version numbers be upgraded? - Who is going to put out new package versions - and when? IMO we should have new versions out *before* the next beta release - this means before monday, 6th december. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 30 08:14:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA03547 for xemacs-beta-out; Tue, 30 Nov 1999 08:14:12 -0500 Received: from scallop.baynetworks.com (ns5.baynetworks.com [194.133.90.101]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA03540 for ; Tue, 30 Nov 1999 08:14:07 -0500 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA13806 for ; Tue, 30 Nov 1999 14:16:49 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA06731 for ; Tue, 30 Nov 1999 08:09:32 -0500 (EST) Received: from ltrpluim.corpemea.baynetworks.com ([141.251.166.11]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id IAA09871; Tue, 30 Nov 1999 08:13:49 -0500 for Received: (from rpluim@localhost) by ltrpluim.corpemea.baynetworks.com (8.8.7/8.8.7) id OAA03984; Tue, 30 Nov 1999 14:11:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14403.52469.443469.273441@ltrpluim.corpemea.baynetworks.com> Date: Tue, 30 Nov 1999 14:11:17 +0100 (CET) To: xemacs-beta@xemacs.org Subject: Re: Using mktemp for temporary files In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Reply-To: Robert Pluim Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > > What strikes me is that I don't know whether type -p is available in > /bin/sh. > Not on Solaris 2.5.1. Worse, mktemp doesn't appear to be available either: bash-2.02$ uname -a SunOS joat 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-1 bash-2.02$ /bin/sh \s-\v\$ type mktemp mktemp not found \s-\v\$ type -p mktemp -p not found mktemp not found \s-\v\$ Oh, and SunOS 4.1.4 is the same: $ [mbf23 rpluim]$ uname -a SunOS mbf23 4.1.4 1 sun4m [mbf23 rpluim]$ /bin/sh $ type mktemp mktemp not found $ type -p mktemp -p not found mktemp not found Robert -- The above are my opinions, and my opinions only. From owner-xemacs-beta@xemacs.org Tue Nov 30 08:36:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA04610 for xemacs-beta-out; Tue, 30 Nov 1999 08:36:14 -0500 Received: from nirvana.ingames.com (ingames.no [195.159.15.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA04607 for ; Tue, 30 Nov 1999 08:36:10 -0500 Received: from glynn.ingames.com (glynn.cvg.no [195.159.15.204]) by nirvana.ingames.com (8.8.7/8.8.7) with SMTP id OAA21735; Tue, 30 Nov 1999 14:38:38 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14403.54002.959000.366555@glynn.ingames.com> Date: Tue, 30 Nov 1999 14:36:47 +0100 (GMT--1:00) To: Andreas Jaeger Cc: xemacs-beta@xemacs.org Subject: Re: Using mktemp for temporary files In-Reply-To: References: X-Mailer: VM 6.67 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger wrote: > What strikes me is that I don't know whether type -p is available in > /bin/sh. It isn't available in ash (which is allegedly NetBSD's /bin/sh, according to the ash package description from Slackware 3.2). -- Glynn Clements From owner-xemacs-beta@xemacs.org Tue Nov 30 08:43:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA04792 for xemacs-beta-out; Tue, 30 Nov 1999 08:43:47 -0500 Received: from max3p112.smart.net (max3p112.smart.net [216.84.81.112]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA04789 for ; Tue, 30 Nov 1999 08:43:44 -0500 Received: (from jmiller@localhost) by max3p112.smart.net (8.9.3/8.9.3) id IAA11126; Tue, 30 Nov 1999 08:39:31 -0500 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14403.54162.130324.584623@max3p112.smart.net> Date: Tue, 30 Nov 1999 08:39:30 -0500 (EST) To: Andreas Jaeger Cc: xemacs-beta@xemacs.org Subject: Re: xemacs-packages: Current state In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta20) "Yoko" XEmacs Lucid Reply-To: jmiller@smart.net X-Face: &vGrMZ?Q&W5~yiCR_#hat=$tgJrK`J=2$se?0Nu9I3G|I<2-\:82zx>kz=l8(yw)G1i&0"D >>>>> "AJ" == Andreas Jaeger writes: AJ> I've applied a number of patches to xemacs-packages and I think we AJ> should consider putting out new versions and sumo-tarballs. yes AJ> I've got the following open problems: AJ> - Are there any patches that need to be checked in? Steve, what is in AJ> your patch queue (btw. feel free to send all patches to me - I'll apply AJ> them asap) ? i don't think the patch i sent in over the summer to synch hideif.el with 20.4 has been applied. if you can't find it, i can resend. AJ> - When and how will the package version numbers be upgraded? AJ> - Who is going to put out new package versions - and when? a) it was discussed at one point of setting up a beta package area so we can test them ( w/ 21.1.x as well as 21.2.x) prior to public release. are we still going to do that? b) someone should probably fix the problem with Options->Manage Packages->List and Install. I'm still getting the problem where it tries to save it to my non-existent ~/.xemacs area. AJ> IMO we should have new versions out *before* the next beta release - AJ> this means before monday, 6th december. From owner-xemacs-beta@xemacs.org Tue Nov 30 09:03:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA05584 for xemacs-beta-out; Tue, 30 Nov 1999 09:03:57 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA05579 for ; Tue, 30 Nov 1999 09:03:55 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA03851; Tue, 30 Nov 1999 15:03:51 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000w8; Tue Nov 30 15:03:41 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA09342; Tue, 30 Nov 1999 15:03:41 +0100 To: Isaac.Hollander@msdw.com Cc: Isaac Hollander , xemacs-beta@xemacs.org Subject: Re: 21.1.8 IRIX 6.5 IP27 build trouble References: <199911291717.MAA27684@yesha.morgan.com> <14402.64179.60192.523339@yesha.ms.com> From: Jan Vroonhof Date: 30 Nov 1999 15:03:41 +0100 In-Reply-To: Isaac.Hollander@msdw.com's message of "Mon, 29 Nov 1999 17:14:11 -0500 (EST)" Message-ID: Lines: 9 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Isaac.Hollander@msdw.com writes: > This seems to work. xemacs builds and starts. Are there any plans to > include this patch[1] in 21.1.9 and/or the next 21.2 beta? Not in this form. If anybody wants to turn this is into a real patch, feel free to contact me. Jan From owner-xemacs-beta@xemacs.org Tue Nov 30 09:09:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA05810 for xemacs-beta-out; Tue, 30 Nov 1999 09:09:46 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA05805 for ; Tue, 30 Nov 1999 09:09:44 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id PAA20405; Tue, 30 Nov 1999 15:09:22 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11snp5-0005wn-00; Tue, 30 Nov 1999 15:00:03 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 32D8818BA; Tue, 30 Nov 1999 15:00:01 +0100 (CET) To: jmiller@smart.net Cc: xemacs-beta@xemacs.org Subject: Re: xemacs-packages: Current state References: <14403.54162.130324.584623@max3p112.smart.net> From: Andreas Jaeger Date: 30 Nov 1999 15:00:01 +0100 In-Reply-To: Jeff Miller's message of "Tue, 30 Nov 1999 08:39:30 -0500 (EST)" Message-ID: Lines: 14 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Jeff Miller writes: Jeff> i don't think the patch i sent in over the summer to synch hideif.el Jeff> with 20.4 has been applied. if you can't find it, i can resend. It might be that it's still in Steve's pending queue but I don't know. Feel free to resend it to xemacs-patches. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 30 09:15:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA06044 for xemacs-beta-out; Tue, 30 Nov 1999 09:15:27 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA06039 for ; Tue, 30 Nov 1999 09:15:24 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA04157; Tue, 30 Nov 1999 15:15:23 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0010u; Tue Nov 30 15:15:14 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA09388; Tue, 30 Nov 1999 15:15:13 +0100 To: Andreas Jaeger Cc: xemacs-beta@xemacs.org Subject: Re: Using mktemp for temporary files References: From: Jan Vroonhof Date: 30 Nov 1999 15:15:13 +0100 In-Reply-To: Andreas Jaeger's message of "30 Nov 1999 10:18:56 +0100" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > Besides, does anybody have better ideas to rewrite this. 1. Take an rcs2log from a recent CVS distribution (which doesn't seem to have this problem). 2. (imho better) Stop shipping the script. I think 2 is better because getting rid of unmaintained an duplicated stuff seems like a good idea to me. Jan From owner-xemacs-beta@xemacs.org Tue Nov 30 10:05:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA09562 for xemacs-beta-out; Tue, 30 Nov 1999 10:05:56 -0500 Received: from gate.ispras.ru (gate.ispras.ru [194.67.37.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA09550 for ; Tue, 30 Nov 1999 10:05:46 -0500 Received: from fog (fog [194.67.37.129]) by gate.ispras.ru (8.9.3/8.9.3) with SMTP id TAA20975 for ; Tue, 30 Nov 1999 19:05:39 +0400 (GMT) Received: tid TAA12682; Tue, 30 Nov 1999 19:04:15 +0200 X-Authentication-Warning: fog: Host kazbek claimed to be kazbek.kazbek.ispras.ru Received: from pegas.kazbek.ispras.ru (pegas [194.186.94.143]) by kazbek.kazbek.ispras.ru (8.9.3/8.9.3) with ESMTP id SAA18088 for ; Tue, 30 Nov 1999 18:04:44 +0300 (MSK) Received: (from npak@localhost) by pegas.kazbek.ispras.ru (8.9.3/8.9.3) id SAA07125; Tue, 30 Nov 1999 18:04:43 +0300 Date: Tue, 30 Nov 1999 18:04:43 +0300 Message-Id: <199911301504.SAA07125@pegas.kazbek.ispras.ru> From: "Nick V. Pakoulin" To: xemacs-beta@xemacs.org Subject: Problems with 'Buffers' tab. Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta22) "Mercedes" [Lucid] (i686-pc-linux) of Tue Nov 30 1999 on pegas.kazbek.ispras.ru configured using `configure --with-pop' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: My settings: (custom-set-variables '(gutter-visible-p t) '(default-gutter-position (quote left)) '(buffers-tab-max-size 2)) 1. With this settings xemacs opens scratch buffer with "*scratch*" tab over the first line of the text. With the first cursor movement the tab disappears, but the text beneath is still invisible. Of course, it is not forever hidden, and there are more than one way to unhide it, but still ... 2. After changing default-gutter-position(via custom) from 'left to 'top or 'bottom, ugly blue(on my HP-400 workstation) regions are left in the current buffer window. These regiona are about 4 chars wide and attached to the left margin. Recent keystrokes: misc-user Recent messages (most recent first): Parsing /home/npakoulin/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading /home/npakoulin/.e/.xemacs-init...done Loading ~/.abbrev_defs...done Loading ~/.abbrev_defs... Loading time...done Loading time... From owner-xemacs-beta@xemacs.org Tue Nov 30 10:13:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA09895 for xemacs-beta-out; Tue, 30 Nov 1999 10:13:02 -0500 Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA09892 for ; Tue, 30 Nov 1999 10:13:00 -0500 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id QAA25652; Tue, 30 Nov 1999 16:12:59 +0100 (CET) (envelope-from aj@suse.de) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11sou0-00069K-00; Tue, 30 Nov 1999 16:09:12 +0100 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 0B24B18BA; Tue, 30 Nov 1999 16:09:11 +0100 (CET) Mail-Copies-To: never To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Using mktemp for temporary files References: From: Andreas Jaeger Date: 30 Nov 1999 16:09:10 +0100 In-Reply-To: Jan Vroonhof's message of "30 Nov 1999 15:15:13 +0100" Message-ID: Lines: 24 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Jan Vroonhof writes: > Andreas Jaeger writes: >> Besides, does anybody have better ideas to rewrite this. > 1. Take an rcs2log from a recent CVS distribution (which doesn't seem > to have this problem). Are you sure? I've just checked cvs-1.10.7 and it still has these problems. > 2. (imho better) Stop shipping the script. > I think 2 is better because getting rid of unmaintained an duplicated > stuff seems like a good idea to me. AFAIK rcs2log comes from Emacs and Emacs is still the "master source" for cvs. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From owner-xemacs-beta@xemacs.org Tue Nov 30 11:15:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA12445 for xemacs-beta-out; Tue, 30 Nov 1999 11:15:22 -0500 Received: from hqinbh2.ms.com (hqinbh2.ms.com [205.228.12.72]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA12441 for ; Tue, 30 Nov 1999 11:15:20 -0500 Received: (from uucp@localhost) by hqinbh2.ms.com (8.8.6/fw v1.30) id LAA21579; Tue, 30 Nov 1999 11:15:14 -0500 (EST) Received: from unknown(144.14.9.190) by hqinbh2 via smap (4.1) id xma015581; Tue, 30 Nov 99 11:12:32 -0500 Received: from sag3 (sag3.morgan.com [144.14.19.147]) by safid1.morgan.com (8.8.5/hub+ldap v2.4) with ESMTP id LAA21875; Tue, 30 Nov 1999 11:12:31 -0500 (EST) Received: (craffert@localhost) by sag3 (980427.SGI.8.8.8/sendmail.cf.client v1.05) id LAA33794; Tue, 30 Nov 1999 11:12:30 -0500 (EST) To: XEmacs Beta List Cc: Max Matveev , Isaac Hollander From: Colin Rafferty Subject: Re: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' References: <14402.33810.975446.432893@pub.news.uk.psi.net> <14402.38227.288055.597083@pub.news.uk.psi.net> X-Attribution: > Mail-Copies-To: never X-Face: $%/0:A=g/0mfAd_-AHyqWK$D&dZ;sk7OJFQw",'KwWutsgG|+n.E:(Q<*Sw=&]o4>i1<-[<;W,f#;.,W'}w"y2\8}Iki{CzF,/BaDHcMIvNQ~ZVw19<^CD}wZV2/NRg8.\WHR.%^H#CZ#&K]GQo!a;KtLwLlRk0MNdjf--29.ZW.[t'mOdEnN|a^;AV{<\[!h_0}/{h{iQILgp9mG*;]:_R_@bL<,Fkfm~GYf@<@UH$0?%.v"a[5Z X-Y-Zippy: Yow! I'm imagining a surfer van filled with soy sauce! Date: 30 Nov 1999 11:12:30 -0500 In-Reply-To: Jan Vroonhof's message of "29 Nov 1999 18:15:36 +0100" Message-ID: Lines: 25 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes: > Paul Bibilo writes: >> Jan Vroonhof writes: >>> http://www.xemacs.org/list-archives/xemacs-patches/9911/msg00042.html >> Please could somebody arrange for the above patch to be applied to >> 21.2. > Unfortunately it cannot be included in this form (it possibly breaks > other stuff and it needs documentation that was send separately folded > in). Nobody has found the time yet do a proper patch. If I were to just submit the iris*.h and unexecsgi.c part, along with a proper changelog, would that be fine? Could you please forward me the original comment (I'm not on xemacs-patches)? > Something like this is also needed for 21.1.9 I can check that, too. -- Colin From owner-xemacs-beta@xemacs.org Tue Nov 30 12:19:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA18492 for xemacs-beta-out; Tue, 30 Nov 1999 12:19:11 -0500 Received: from bagua.concmp.com (concmp.com [206.243.170.234]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id MAA18489 for ; Tue, 30 Nov 1999 12:19:09 -0500 From: cottons@concmp.com Received: (qmail 5940 invoked by uid 500); 30 Nov 1999 15:17:28 -0000 Date: 30 Nov 1999 15:17:28 -0000 Message-ID: <19991130151728.5939.qmail@bagua.concmp.com> To: xemacs-beta@xemacs.org Subject: incorrect gutter placement when menubar is not visible Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: When the menubar is not visible, the gutter is drawn over the top-most buffer in the window. The layout is correct, space is left in the frame for the gutter, it is just not drawn in the correct location. To reproduce, start xemacs (-q) and eval (add-spec-list-to-specifier menubar-visible-p '((global (nil . nil)))) The menubar disappears, and the the frame looks like [toolbar] [gray space the height of the gutter] [top half of first line of *scratch* buffer] [the gutter] ;; then enter the text in that file's own buffer [third line of *scratch* buffer] - Cotton From owner-xemacs-beta@xemacs.org Tue Nov 30 12:27:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA19930 for xemacs-beta-out; Tue, 30 Nov 1999 12:27:20 -0500 Received: from bagua.concmp.com (concmp.com [206.243.170.234]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id MAA19926 for ; Tue, 30 Nov 1999 12:27:18 -0500 From: cottons@concmp.com Received: (qmail 5955 invoked by uid 500); 30 Nov 1999 15:25:42 -0000 Date: 30 Nov 1999 15:25:42 -0000 Message-ID: <19991130152542.5954.qmail@bagua.concmp.com> To: xemacs-beta@xemacs.org Subject: up to date sumo package? Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The latest xemacs-sumo tarball in ftp.xemacs.org:/pub/xemacs/packages is dated July 29, but it is named xemacs-sumo.tar.gz, not xemacs-sumo-.tar.gz, as described in README.packages. There is a xemacs-sumo tarball so named dated July 13. This is about 5 months old. Is this really up to date? If not, are there plans to build a up to date xemacs-sumo tarball? - Cotton From owner-xemacs-beta@xemacs.org Tue Nov 30 12:33:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA20704 for xemacs-beta-out; Tue, 30 Nov 1999 12:33:22 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA20698 for ; Tue, 30 Nov 1999 12:33:20 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA15211; Tue, 30 Nov 1999 18:33:14 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003hd; Tue Nov 30 18:33:10 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA10088; Tue, 30 Nov 1999 18:33:10 +0100 To: XEmacs Beta List Cc: Max Matveev , Isaac Hollander Subject: Re: [FAILURE] XEmacs 21.2-b22 "Mercedes" configured for `mips-sgi-irix6.2' References: <14402.33810.975446.432893@pub.news.uk.psi.net> <14402.38227.288055.597083@pub.news.uk.psi.net> From: Jan Vroonhof Date: 30 Nov 1999 18:33:10 +0100 In-Reply-To: Colin Rafferty's message of "30 Nov 1999 11:12:30 -0500" Message-ID: Lines: 27 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Colin Rafferty writes: > If I were to just submit the iris*.h and unexecsgi.c part, along with > a proper changelog, would that be fine? No. What needs to be done 1. The etags stuff separated off (the patch is fine it just needs to be separate). 2. The patch to unexecsgi.c part needs to include a comment on how the new code works (Max Matveev later send this seperately). 3. The patch to the iris*.h stuff needs to be rewritten such as to only do this for Irix 6.x. I have a prototype patch for that. 4. Everything needs changelogs Basically all the stuff is there it just needs to be cleaned up (_and tested_) before it gets in, so that we can later see what happened and why. Otherwise the patch ping-pong just continues. > Could you please forward me the original comment (I'm not on > xemacs-patches)? I'll forward you the original patch, the comment and the prototype new iris6.d stuff. Jan From owner-xemacs-beta@xemacs.org Tue Nov 30 13:08:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26294 for xemacs-beta-out; Tue, 30 Nov 1999 13:08:39 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26286 for ; Tue, 30 Nov 1999 13:08:37 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA16302 for ; Tue, 30 Nov 1999 19:08:36 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003yb; Tue Nov 30 19:08:27 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA10092; Tue, 30 Nov 1999 19:08:26 +0100 To: xemacs-beta@xemacs.org Subject: Re: Using mktemp for temporary files References: From: Jan Vroonhof Date: 30 Nov 1999 19:08:26 +0100 In-Reply-To: Andreas Jaeger's message of "30 Nov 1999 16:09:10 +0100" Message-ID: Lines: 36 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andreas Jaeger writes: > > 1. Take an rcs2log from a recent CVS distribution (which doesn't seem > > to have this problem). > > Are you sure? I've just checked cvs-1.10.7 and it still has these > problems. Oops.. I forgot that on the linux machine I was one we use the Redhat CVS package. It uses mktemp too (which won't work on Solaris). There are some writeups on how to do this portably. The debian folk have one, I'l try finding it [time passes] I seem to have mistaken on the existence of write-ups. The best portable solution seems to be.. umask 077 tmpdir=${TMPDIR-/tmp}/foo.$$ mkdir $tmpdir || exit 1 trap "rm -rf $tmpdir; exit" 0 1 2 3 15 but that is still insecure on some platforms... Maybe we should simply ship mktemp? > AFAIK rcs2log comes from Emacs and Emacs is still the "master source" > for cvs. Maybe we should snarf the FSF 20.4 version in the same process at the same time. Jan From owner-xemacs-beta@xemacs.org Tue Nov 30 13:12:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26768 for xemacs-beta-out; Tue, 30 Nov 1999 13:12:34 -0500 Received: from hermes.epita.fr (hermes.epita.fr [194.98.116.10]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26759 for ; Tue, 30 Nov 1999 13:12:31 -0500 Received: from uzeb.lrde.epita.fr (uzeb.lrde.epita.fr [10.227.5.53]) by hermes.epita.fr id TAA02590 for EPITA Paris France Tue, 30 Nov 1999 19:12:48 GMT Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.03 #1 (Debian)) id 11srrr-0001g5-00 for ; Tue, 30 Nov 1999 19:19:11 +0100 To: xemacs-beta@xemacs.org Subject: Re: xemacs-21.2.22 "Mercedes" is released References: X-Attribution: dv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna From: Didier Verna In-Reply-To: SL Baur's message of "30 Nov 1999 14:33:54 +0900" X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Lines: 39 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Steve Baur wrote: > -- ESD Sound support from Robert Bihlmeyer Which esd is that ? I have 0.2.8 on my debian potato system, but no `esd-config' thing. Is that a program and if yes, shouldn't it be better to check for library files in configure.in ? dpkg -L libesd0: /. /usr /usr/lib /usr/lib/libesddsp.so.0 /usr/lib/libesd.so.0.2.15 /usr/lib/libesd.so.0 /usr/lib/libesddsp.so.0.2.15 /usr/share /usr/share/doc /usr/share/doc/libesd0 /usr/share/doc/libesd0/copyright /usr/share/doc/libesd0/TIPS /usr/share/doc/libesd0/changelog.gz /usr/share/doc/libesd0/TODO /usr/share/doc/libesd0/README /usr/share/doc/libesd0/NEWS /usr/share/doc/libesd0/esound.sgml /usr/share/doc/libesd0/changelog.Debian.gz /usr/share/doc-base /usr/share/doc-base/libesd0 -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99 From owner-xemacs-beta@xemacs.org Tue Nov 30 14:01:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA30459 for xemacs-beta-out; Tue, 30 Nov 1999 14:01:51 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA30454 for ; Tue, 30 Nov 1999 14:01:49 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA17627 for ; Tue, 30 Nov 1999 20:01:48 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004JP; Tue Nov 30 20:01:40 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA10325; Tue, 30 Nov 1999 20:01:40 +0100 To: xemacs-beta@xemacs.org Subject: Re: xemacs-21.2.22 "Mercedes" is released References: From: Jan Vroonhof Date: 30 Nov 1999 20:01:39 +0100 In-Reply-To: Didier Verna's message of "30 Nov 1999 19:19:11 +0100" Message-ID: Lines: 18 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes: > Which esd is that ? I have 0.2.8 on my debian potato system, but no > `esd-config' thing. Is that a program and if yes, shouldn't it be better to > check for library files in configure.in ? No. esd-config is the official (gnome/gtk style) way of finding ESD. > > > dpkg -L libesd0: Try looking libesd0-dev.. I tested this stuff on a slink system and on a slink system apt'ed up to October Gnome. Jan From owner-xemacs-beta@xemacs.org Tue Nov 30 14:03:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA30510 for xemacs-beta-out; Tue, 30 Nov 1999 14:03:11 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA30505 for ; Tue, 30 Nov 1999 14:03:09 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA17634; Tue, 30 Nov 1999 20:03:08 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004JV; Tue Nov 30 20:03:03 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA10327; Tue, 30 Nov 1999 20:03:03 +0100 To: cottons@concmp.com Cc: xemacs-beta@xemacs.org Subject: Re: up to date sumo package? References: <19991130152542.5954.qmail@bagua.concmp.com> From: Jan Vroonhof Date: 30 Nov 1999 20:03:02 +0100 In-Reply-To: cottons@concmp.com's message of "30 Nov 1999 15:25:42 -0000" Message-ID: Lines: 9 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: cottons@concmp.com writes: > old. Is this really up to date? If not, are there plans to build a > up to date xemacs-sumo tarball? Yes. Watch out messages from Andreas Jaeger on this list in order to help test them. jan From owner-xemacs-beta@xemacs.org Tue Nov 30 14:42:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32467 for xemacs-beta-out; Tue, 30 Nov 1999 14:42:41 -0500 Received: from psyche.kn-bremen.de (dyn205.pm3.access.hb.provi.de [195.222.200.205]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA32464 for ; Tue, 30 Nov 1999 14:42:39 -0500 Received: from plate by psyche.kn-bremen.de with local (Exim 3.03 #1 (Debian)) id 11st2e-0000OC-00; Tue, 30 Nov 1999 20:34:24 +0100 To: xemacs-beta@xemacs.org Subject: Re: xemacs-21.2.22 "Mercedes" is released References: From: Joerg Plate Reply-To: Joerg Plate Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: Didier Verna's message of "30 Nov 1999 19:19:11 +0100" Date: 30 Nov 1999 20:34:22 +0100 Message-ID: <87g0xnlqo1.fsf@psyche.kn-bremen.de> Lines: 7 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) XEmacs/21.2 (Mercedes) MIME-Version: 1.0 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > I have 0.2.8 on my debian potato system, but no `esd-config' thing. 1> dlocate esd-config esound-common: /usr/bin/esd-config -- PGP&GPG "I'm working on it." "There should be more math. This could be mathier." From owner-xemacs-beta@xemacs.org Tue Nov 30 14:49:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA00353 for xemacs-beta-out; Tue, 30 Nov 1999 14:49:39 -0500 Received: from beaver.jprc.com (BEAVER.JPRC.COM [207.86.147.217]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA00341 for ; Tue, 30 Nov 1999 14:49:30 -0500 Received: (from karl@localhost) by beaver.jprc.com (8.9.3/8.9.3) id OAA07117; Tue, 30 Nov 1999 14:49:29 -0500 To: xemacs-beta@xemacs.org Subject: 21.2-b22 again calls exit(1) out of Xt on invalid widget X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu From: Karl Kleinpaste Date: 30 Nov 1999 14:49:28 -0500 Message-ID: Lines: 354 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.2 (Mercedes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Error: Widget *Group* has zero width and/or height" I suspect that any X widget having (claiming to have) 153 children is pretty thoroughly broken. xwininfo: Window id: 0x5000029 "emacs: *Summary comp.emacs.xemacs*" Root window id: 0x26 (the root window) (has no name) Parent window id: 0x1801da4 (has no name) 1 child: 0x500002a (has no name): () 1267x976+0+0 +5+21 153 children: 0x500816c (has no name): () 80x18+0+0 +5+21 1 child: 0x500816d (has no name): () 1259x18+0+0 +6+22 4 children: 0x50081c8 (has no name): () 1257x65531+1+22 +7+44 0x50081b3 (has no name): () 1257x65531+1+22 +7+44 0x50081c1 (has no name): () 62617x61355+1+22 +7+44 0x50081ba (has no name): () 1257x65531+1+22 +7+44 0x50080f3 (has no name): () 80x18+0+0 +5+21 1 child: 0x50080f4 (has no name): () 4428x4419+0+0 +6+22 3 children: 0x50081f9 (has no name): () 4426x4396+1+22 +7+44 0x50081eb (has no name): () 250x220+1+22 +7+44 0x50081f2 (has no name): () 44x14+1+22 +7+44 0x50080ea (has no name): () 80x18+0+0 +5+21 1 child: 0x50080eb (has no name): () 1259x18+0+0 +6+22 4 children: 0x50081e4 (has no name): () 1257x65531+1+22 +7+44 0x50081cf (has no name): () 1257x65531+1+22 +7+44 0x50081dd (has no name): () 1257x65531+1+22 +7+44 0x50081d6 (has no name): () 1257x65531+1+22 +7+44 0x500049e (has no name): () 15x661+1248+287 +1253+308 0x5000aa1 (has no name): () 1244x15+4+258 +9+279 0x5000493 (has no name): () 15x173+1248+85 +1253+106 0x5008086 (has no name): () 1259x18+4+67 +9+88 1 child: 0x5008087 (has no name): () 1259x18+0+0 +9+88 4 children: 0x5008117 (has no name): () 62617x61355+1+22 +10+110 0x5008102 (has no name): () 1257x65531+1+22 +10+110 0x5008110 (has no name): () 1257x65531+1+22 +10+110 0x5008109 (has no name): () 1257x65531+1+22 +10+110 0x5000581 (has no name): () 1244x15+4+258 +9+279 0x5007fab (has no name): () 1259x18+4+67 +9+88 1 child: 0x5007fac (has no name): () 1259x18+0+0 +9+88 3 children: 0x50080cd (has no name): () 4334x4190+1+22 +10+110 0x50080bf (has no name): () 4334x4190+1+22 +10+110 0x50080c6 (has no name): () 158x14+1+22 +10+110 0x500017e (has no name): () 481x15+4+258 +9+279 0x500014b (has no name): () 15x173+485+85 +490+106 0x5000202 (has no name): () 15x661+485+287 +490+308 0x5007e98 (has no name): () 80x18+0+0 +5+21 1 child: 0x5007e99 (has no name): () 1259x18+0+0 +6+22 4 children: 0x5007ef4 (has no name): () 1257x65531+1+22 +7+44 0x5007edf (has no name): () 1259x65533+1+22 +-65529+-65492 0x5007eed (has no name): () 1257x65531+1+22 +7+44 0x5007ee6 (has no name): () 1257x65531+1+22 +7+44 0x5007e1f (has no name): () 1259x18+4+67 +9+88 1 child: 0x5007e20 (has no name): () 1259x18+0+0 +9+88 2 children: 0x5007f64 (has no name): () 62x14+1+22 +10+110 0x5007f6b (has no name): () 62x14+1+22 +10+110 0x5007e16 (has no name): () 80x18+0+0 +5+21 1 child: 0x5007e17 (has no name): () 1259x18+0+0 +6+22 4 children: 0x5007f33 (has no name): () 152x14+1+22 +7+44 0x5007f48 (has no name): () 152x14+1+22 +7+44 0x5007f41 (has no name): () 4330x4192+1+22 +-65529+-65492 0x5007f3a (has no name): () 152x14+1+22 +7+44 0x5007db2 (has no name): () 1259x18+4+67 +9+88 1 child: 0x5007db3 (has no name): () 1259x18+0+0 +9+88 4 children: 0x5007ff2 (has no name): () 152x14+1+22 +10+110 0x5008007 (has no name): () 4328x4190+1+22 +10+110 0x5008000 (has no name): () 4328x4190+1+22 +10+110 0x5007ff9 (has no name): () 152x14+1+22 +10+110 0x5007c13 (has no name): () 80x18+0+0 +5+21 1 child: 0x5007c14 (has no name): () 1259x18+0+0 +6+22 4 children: 0x5007cdf (has no name): () 50x14+1+22 +7+44 0x5007cca (has no name): () 4226x4190+1+22 +7+44 0x5007cd8 (has no name): () 50x14+1+22 +7+44 0x5007cd1 (has no name): () 4226x4190+1+22 +7+44 0x5007b9a (has no name): () 1259x18+4+67 +9+88 1 child: 0x5007b9b (has no name): () 1259x18+0+0 +9+88 3 children: 0x5007deb (has no name): () 50x14+1+22 +10+110 0x5007df9 (has no name): () 4226x4190+1+22 +10+110 0x5007df2 (has no name): () 4226x4190+1+22 +10+110 0x5007b91 (has no name): () 80x18+0+0 +5+21 1 child: 0x5007b92 (has no name): () 1259x18+0+0 +6+22 4 children: 0x5007cc3 (has no name): () 1257x65531+1+22 +7+44 0x5007cae (has no name): () 1257x65531+1+22 +7+44 0x5007cbc (has no name): () 1257x65531+1+22 +7+44 0x5007cb5 (has no name): () 10251x8989+1+22 +7+44 0x5007b34 (has no name): () 80x18+0+0 +5+21 1 child: 0x5007b35 (has no name): () 1259x18+0+0 +6+22 4 children: 0x5007d3a (has no name): () 62617x61355+1+22 +7+44 0x5007d4f (has no name): () 1257x65531+1+22 +7+44 0x5007d48 (has no name): () 1257x65531+1+22 +7+44 0x5007d41 (has no name): () 1257x65531+1+22 +7+44 0x5007a6e (has no name): () 1259x18+4+67 +9+88 0x500798c (has no name): () 1259x18+4+67 +9+88 0x5007841 (has no name): () 80x18+0+0 +5+21 0x50077c8 (has no name): () 1259x18+4+67 +9+88 0x50077bf (has no name): () 80x18+0+0 +5+21 0x5007762 (has no name): () 1259x18+4+67 +9+88 0x5007678 (has no name): () 80x18+0+0 +5+21 0x500761b (has no name): () 1259x18+4+67 +9+88 0x5007612 (has no name): () 80x18+0+0 +5+21 0x50075ca (has no name): () 1259x18+4+67 +9+88 0x500747d (has no name): () 80x18+0+0 +5+21 0x5007404 (has no name): () 1259x18+4+67 +9+88 0x50073fb (has no name): () 80x18+0+0 +5+21 0x5007396 (has no name): () 1259x18+4+67 +9+88 0x500722f (has no name): () 80x18+0+0 +5+21 0x50071b6 (has no name): () 1259x18+4+67 +9+88 0x50071ad (has no name): () 80x18+0+0 +5+21 0x500714f (has no name): () 80x18+0+0 +5+21 0x5007011 (has no name): () 80x18+0+0 +5+21 0x5006fb4 (has no name): () 1259x18+4+67 +9+88 0x5006fab (has no name): () 80x18+0+0 +5+21 0x5006f62 (has no name): () 1259x18+4+67 +9+88 0x5006e15 (has no name): () 80x18+0+0 +5+21 0x5006d9c (has no name): () 1259x18+4+67 +9+88 0x5006d93 (has no name): () 80x18+0+0 +5+21 0x5006d2f (has no name): () 80x18+0+0 +5+21 0x5006bff (has no name): () 80x18+0+0 +5+21 0x5006b86 (has no name): () 1259x18+4+67 +9+88 0x5006b7d (has no name): () 80x18+0+0 +5+21 0x5006b2e (has no name): () 1259x18+4+67 +9+88 0x50061b5 (has no name): () 80x18+0+0 +5+21 0x5006104 (has no name): () 1259x18+4+67 +9+88 0x50060fb (has no name): () 80x18+0+0 +5+21 0x5006074 (has no name): () 1259x18+4+67 +9+88 0x5005e1f (has no name): () 1259x18+4+67 +9+88 0x5005c1c (has no name): () 80x18+0+0 +5+21 0x5005b6b (has no name): () 1259x18+4+67 +9+88 0x5005b62 (has no name): () 80x18+0+0 +5+21 0x5005ac6 (has no name): () 1259x18+4+67 +9+88 0x5002867 (has no name): () 1244x15+4+258 +9+279 0x5005966 (has no name): () 1259x18+4+67 +9+88 0x5005549 (has no name): () 80x18+0+0 +5+21 0x5005498 (has no name): () 1259x18+4+67 +9+88 0x500548f (has no name): () 80x18+0+0 +5+21 0x50053f3 (has no name): () 1259x18+4+67 +9+88 0x5004f8a (has no name): () 80x18+0+0 +5+21 0x5004ed9 (has no name): () 1259x18+4+67 +9+88 0x5004ed0 (has no name): () 80x18+0+0 +5+21 0x5004e34 (has no name): () 1259x18+4+67 +9+88 0x5004ce9 (has no name): () 1259x18+4+67 +9+88 0x5004abe (has no name): () 80x18+0+0 +5+21 0x5004a0d (has no name): () 1259x18+4+67 +9+88 0x5004a04 (has no name): () 80x18+0+0 +5+21 0x5004968 (has no name): () 1259x18+4+67 +9+88 0x5004775 (has no name): () 80x18+0+0 +5+21 0x50046c4 (has no name): () 1259x18+4+67 +9+88 0x50046bb (has no name): () 80x18+0+0 +5+21 0x500461f (has no name): () 1259x18+4+67 +9+88 0x500442a (has no name): () 80x18+0+0 +5+21 0x5004379 (has no name): () 1259x18+4+67 +9+88 0x5004370 (has no name): () 80x18+0+0 +5+21 0x50042e9 (has no name): () 80x18+0+0 +5+21 0x50040e7 (has no name): () 80x18+0+0 +5+21 0x5004036 (has no name): () 1259x18+4+67 +9+88 0x500402d (has no name): () 80x18+0+0 +5+21 0x5003bb6 (has no name): () 80x18+0+0 +5+21 0x5003b21 (has no name): () 1259x18+4+67 +9+88 0x5003b18 (has no name): () 80x18+0+0 +5+21 0x50035d6 (has no name): () 1259x18+4+67 +9+88 1 child: 0x50035d7 (has no name): () 1259x18+0+0 +9+88 5 children: 0x5003d05 (has no name): () 74x14+1+22 +10+110 0x5003ce9 (has no name): () 4250x4190+1+22 +10+110 0x5003cfe (has no name): () 74x14+1+22 +10+110 0x5003cf7 (has no name): () 4250x4190+1+22 +10+110 0x5003cf0 (has no name): () 4250x4190+1+22 +10+110 0x500355d (has no name): () 1259x18+4+67 +9+88 0x5003554 (has no name): () 80x18+0+0 +5+21 0x50034f0 (has no name): () 1259x18+4+67 +9+88 0x50033a5 (has no name): () 80x18+0+0 +5+21 0x500332c (has no name): () 1259x18+4+67 +9+88 0x5003323 (has no name): () 80x18+0+0 +5+21 0x50032c6 (has no name): () 80x18+0+0 +5+21 0x5003200 (has no name): () 1259x18+4+67 +9+88 0x5002fb3 (has no name): () 80x18+0+0 +5+21 0x5002f3a (has no name): () 1259x18+4+67 +9+88 0x5002f31 (has no name): () 80x18+0+0 +5+21 0x5002ed4 (has no name): () 1259x18+4+67 +9+88 0x5002cfd (has no name): () 80x18+0+0 +5+21 0x5002c84 (has no name): () 1259x18+4+67 +9+88 0x5002c7b (has no name): () 80x18+0+0 +5+21 0x5002c17 (has no name): () 1259x18+4+67 +9+88 0x5002b35 (has no name): () 1259x18+4+67 +9+88 0x5002a53 (has no name): () 1259x18+4+67 +9+88 0x5002907 (has no name): () 80x18+0+0 +5+21 0x500288e (has no name): () 1259x18+4+67 +9+88 0x5002885 (has no name): () 80x18+0+0 +5+21 0x500281f (has no name): () 1259x18+4+67 +9+88 0x5002744 (has no name): () 1259x18+4+67 +9+88 0x500217d (has no name): () 80x18+0+0 +5+21 0x5002104 (has no name): () 1259x18+4+67 +9+88 0x50020fb (has no name): () 80x18+0+0 +5+21 0x5002097 (has no name): () 1259x18+4+67 +9+88 0x5001f99 (has no name): () 1259x18+4+67 +9+88 0x5001dfa (has no name): () 80x18+0+0 +5+21 0x5001d81 (has no name): () 1259x18+4+67 +9+88 0x5001d78 (has no name): () 80x18+0+0 +5+21 0x5001d13 (has no name): () 1259x18+4+67 +9+88 0x5001bc8 (has no name): () 80x18+0+0 +5+21 0x5001b4f (has no name): () 1259x18+4+67 +9+88 0x5001b46 (has no name): () 80x18+0+0 +5+21 0x5001ae9 (has no name): () 1259x18+4+67 +9+88 0x5000fce (has no name): () 80x18+0+0 +5+21 0x5000f55 (has no name): () 1259x18+4+67 +9+88 0x5000f4c (has no name): () 80x18+0+0 +5+21 0x5000ee5 (has no name): () 1259x18+4+67 +9+88 0x5000d70 (has no name): () 80x18+0+0 +5+21 0x5000d13 (has no name): () 1259x18+4+67 +9+88 0x5000d0a (has no name): () 80x18+0+0 +5+21 0x5000cc2 (has no name): () 1259x18+4+67 +9+88 0x5000be0 (has no name): () 1259x18+4+67 +9+88 0x5000afe (has no name): () 1259x18+4+67 +9+88 0x5000a59 (has no name): () 1259x18+4+67 +9+88 0x5000977 (has no name): () 1259x18+4+67 +9+88 0x500081e (has no name): () 80x18+0+0 +5+21 0x50007c1 (has no name): () 1259x18+4+67 +9+88 0x50007b8 (has no name): () 80x18+0+0 +5+21 0x5000770 (has no name): () 1259x18+4+67 +9+88 0x50005e8 (has no name): () 1259x18+4+67 +9+88 0x500058b (has no name): () 1259x18+4+67 +9+88 0x5000582 (has no name): () 80x18+0+0 +5+21 0x5000539 (has no name): () 1259x18+4+67 +9+88 0x5000269 (has no name): () 80x18+0+0 +5+21 0x500020c (has no name): () 1259x18+4+67 +9+88 0x5000203 (has no name): () 80x18+0+0 +5+21 0x50001ca (has no name): () 1259x18+4+67 +9+88 0x5000040 (has no name): () 80x18+0+0 +5+21 1 child: 0x5000041 (has no name): () 1259x18+0+0 +6+22 4 children: 0x50070d6 (has no name): () 62617x61355+1+22 +7+44 0x50070eb (has no name): () 62617x61355+1+22 +7+44 0x50070e4 (has no name): () 62385x61123+1+22 +7+44 0x50070dd (has no name): () 62617x61355+1+22 +7+44 0x500002e (has no name): () 1259x18+4+67 +9+88 0x500002c (has no name): () 1267x950+0+26 +5+47 0x500002b (has no name): () 1265x24+0+0 +5+21 Stack trace begins: #0 exit (status=1) at exit.c:40 #1 0x2abf6eb3 in _XtDefaultError () #2 0x2abf6f2a in XtError () #3 0x2abf6a94 in DefaultMsg () #4 0x2abf6b0b in _XtDefaultErrorMsg () #5 0x2abf6c0e in XtAppErrorMsg () #6 0x2ac00102 in XtCreateWindow () #7 0x2ab11d4a in Realize () #8 0x2ab20d5c in Realize () #9 0x2abffb7b in RealizeWidget () #10 0x2abffe54 in XtRealizeWidget () #11 0x81d7cd5 in TabsChangeManaged (w=0x87db1f8) at xlwtabs.c:973 #12 0x2ac02a33 in ManageChildren () #13 0x2ac02be2 in XtManageChildren () #14 0x2ac02cbb in XtManageChild () #15 0x2abf3ed9 in XtCreateManagedWidget () #16 0x81cbe0e in xaw_create_label (parent=0x87db1f8, val=0x85b73c8) at lwlib-Xaw.c:773 #17 0x81d2e3d in xlw_update_tab_control (instance=0x89f1bd8, widget=0x87db1f8, val=0x85a3838) at lwlib-Xlw.c:406 #18 0x81d2f90 in xlw_update_one_widget (instance=0x89f1bd8, widget=0x87db1f8, val=0x85a3838, deep_p=1) at lwlib-Xlw.c:560 #19 0x81ca062 in lw_modify_all_widgets (id=65828, val=0x85a1500, deep_p=1 '\001') at lwlib.c:687 #20 0x81ac2b8 in x_tab_control_set_property (image_instance=146134640, prop=137002508, val=146457024) at glyphs-x.c:2711 #21 0x812006f in widget_set_property (image_instance=146134640, prop=137002508, val=146457024) at glyphs-widget.c:309 #22 0x810f713 in Fset_image_instance_property (image_instance=146134640, prop=137002508, val=146457024) at glyphs.c:1362 #23 0x809098a in Ffuncall (nargs=4, args=0x7fffea5c) at eval.c:3178 The widget ident which begins to be seen in frame #18 is again not part of what "xwininfo -tree" found, as I found when this occurred with -b20. RH 6.0 + 2.2.12 + XFree 3.3.5. uname -a: Linux beaver.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown ./configure '--with-pop' '--with-mule' XEmacs 21.2-b22 "Mercedes" configured for `i686-pc-linux'. Where should the build process find the source code? /home/src/Packages/xemacs/xemacs-21.2.22 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Enlightened Sound Daemon. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d native widgets. Using Athena-3d dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From owner-xemacs-beta@xemacs.org Tue Nov 30 16:52:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA06357 for xemacs-beta-out; Tue, 30 Nov 1999 16:52:47 -0500 Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA06352 for ; Tue, 30 Nov 1999 16:52:45 -0500 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id WAA19533; Tue, 30 Nov 1999 22:52:44 +0100 (MET) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004lA; Tue Nov 30 22:52:40 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id WAA10676; Tue, 30 Nov 1999 22:52:39 +0100 To: Karl Kleinpaste Cc: xemacs-beta@xemacs.org Subject: Re: 21.2-b22 again calls exit(1) out of Xt on invalid widget References: From: Jan Vroonhof Date: 30 Nov 1999 22:52:39 +0100 In-Reply-To: Karl Kleinpaste's message of "30 Nov 1999 14:49:28 -0500" Message-ID: Lines: 26 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Karl Kleinpaste writes: > #16 0x81cbe0e in xaw_create_label (parent=0x87db1f8, val=0x85b73c8) > at lwlib-Xaw.c:773 Id don't claim at all to understand that code. But this changes an inconsistency with the rest of the code although I cannot see how it could matter unless the class got subclassed behind our back. This is also closer to the Motif code. Index: lwlib-Xaw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xaw.c,v retrieving revision 1.9.2.4 diff -u -u -r1.9.2.4 lwlib-Xaw.c --- lwlib-Xaw.c 1999/08/30 13:37:06 1.9.2.4 +++ lwlib-Xaw.c 1999/11/30 21:46:33 @@ -146,7 +146,7 @@ } #endif /* LWLIB_DIALOGS_ATHENA */ #ifdef LWLIB_WIDGETS_ATHENA - else if (XtClass (widget) == labelWidgetClass) + else if (XtIsSubclass (widget, labelWidgetClass)) { Arg al [1]; XtSetArg (al [0], XtNlabel, val->value); From owner-xemacs-beta@xemacs.org Tue Nov 30 17:29:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA07804 for xemacs-beta-out; Tue, 30 Nov 1999 17:29:42 -0500 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA07799 for ; Tue, 30 Nov 1999 17:29:37 -0500 Received: from anxur.fi.muni.cz (0@anxur.fi.muni.cz [147.251.48.3]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id XAA23654 for ; Tue, 30 Nov 1999 23:29:30 +0100 (MET) Received: from decibel.fi.muni.cz (mail@decibel.fi.muni.cz [147.251.51.14]) by anxur.fi.muni.cz (8.8.5/8.8.5) with ESMTP id XAA03472 for ; Tue, 30 Nov 1999 23:29:30 +0100 (MET) Received: from pekon by decibel.fi.muni.cz with local (Exim 3.03 #1 (Debian)) id 11svm5-0000YC-00; Tue, 30 Nov 1999 23:29:29 +0100 To: xemacs-beta@xemacs.org Subject: Re: xemacs-21.2.22 "Mercedes" is released References: X-URL: http://www.fi.muni.cz/~pekon/ From: Petr Konecny Date: 30 Nov 1999 23:29:28 +0100 In-Reply-To: Didier Verna's message of "30 Nov 1999 19:19:11 +0100" Message-ID: Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Yoko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> Didier Verna (dv) said: dv> Steve Baur wrote: >> -- ESD Sound support from Robert Bihlmeyer dv> Which esd is that ? I have 0.2.8 on my debian potato system, but no dv> `esd-config' thing. Is that a program and if yes, shouldn't it be dv> better to check for library files in configure.in ? dv> dpkg -L libesd0: This is just the shared library, you need to install libesd0-dev to get header files, etc. That's the Debian way. Petr -- Good day to let down old friends who need help.