From owner-xemacs-beta@xemacs.org Thu Jul 1 03:24:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16340 for xemacs-beta-out; Thu, 1 Jul 1999 03:24:17 -0400 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 DAA16337 for ; Thu, 1 Jul 1999 03:24:14 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 10zbCa-00084v-00; Thu, 1 Jul 1999 09:24:08 +0200 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.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: 01 Jul 1999 09:24:08 +0200 In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 1 Jul 1999 11:15:53 +0900 (JST)" Message-ID: <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> Lines: 50 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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> We aren't developing crappy commercial software here, > Hrvoje> after all. :-) > > Right. That's why we should do UCS-4 exactly right, and avoid > getting into "my buffers are bigger" can-you-piss-over-this-line > contests. No, we should get the buffers right and avoid UCS-x pissing contests. Your argument doesn't hold water here and I don't like Mule screwing the rest of us. > BTW: I don't care if Zed has .75GB buffers, or you do, or somebody > is simply trying to determine the period of (psychoanalyze-pinhead); > I think they're important. Just not as important to me, and I > believe to Mule-dependent people in general, as UCS-4. I think this conversation is starting to revert me to my original train of thought, that Mule is not the be-all end-all of everything. There are other people using XEmacs, and Mule advocates will have to realize that one of these days. > Yes. UCS-4 is going to be the standard unified character type in > the near future. It can handle all foreseeable needs for plain > text. Now your argument resembles to those of Markus Kuhn. The important question is whether UCS-4 is acceptable for our internal representation. To me it seems that it's not, regardless of whether it's the "standard unified character type" (ed is the standard editor, anyway). > >> o XEmacs will never again (well, for a future longer than the > >> history of electronic computers) need to change the abstract > >> format for a Lisp character. > > Hrvoje> This is true without UCS-4 too. It's only the > Hrvoje> implementation that changes. > > Unfortunately, probably not true. Current Mule representation has > probably reached the end of the line; we're running out of code > space. But who cares about that? You're not supposed to be relying on the value char-int returns, right? Right. The whole idea behind a character type is that things can be changed without breaking everything in sight. From owner-xemacs-beta@xemacs.org Thu Jul 1 04:43:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA19611 for xemacs-beta-out; Thu, 1 Jul 1999 04:43:52 -0400 Received: from bittersweet.sysc.pdx.edu ([131.252.30.68]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA19607 for ; Thu, 1 Jul 1999 04:43:49 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id BAA04988; Thu, 1 Jul 1999 01:44:11 -0700 To: XEmacs Beta Subject: [crash] Opening frame across ssh from inside a screen. 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" Date: 01 Jul 1999 01:44:11 -0700 Message-ID: <87emisrc84.fsf@bittersweet.sysc.pdx.edu> Lines: 227 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id EAA19608 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I logged in across the room vi ssh, started `screen -R', then ran an xemacs -nw. I started gnuserv, and used `make-frame-on-display' from the scratch buffer to try and project across to the display in front of me. It crashed. echo $DISPLAY cathcart.sysc.pdx.edu:11.0 cathcart:~ # w 12:19am up 2 days, 10:06, 3 users, load average: 0.00, 0.02, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root ttyp3 bittersweet:S.1 12:15am 0.00s 0.51s 0.06s w root ttyp1 bittersweet:S.0 12:15am 1:09 0.05s 0.05s /bin/bash cathcart:~ # tty /dev/ttyp3 cathcart:~ # xemacs -vanilla Fatal error: assertion failed, file device-x.c, line 1038, d != NULL 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/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 ...) make-device(x nil) # bind (display) make-x-device(nil) init-x-win() # bind (debugger debug-on-error command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Aborted [status 134] cathcart:~# gdb xemacs GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat 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 "i486-pc-linux-gnu"... (gdb) set args -vanilla (gdb) run Starting program: /usr/local/bin/xemacs -vanilla Fatal error: assertion failed, file device-x.c, line 1038, d != NULL Program received signal SIGABRT, Aborted. 0x40305e81 in () (gdb) where #0 0x40305e81 in () #1 0x40305acf in gsignal () #2 0x40307228 in abort () #3 0x807639a in assert_failed () at emacs.c:2665 #4 0x8123a40 in x_IO_error_handler (disp=0x823d900) at device-x.c:1038 #5 0x401bc2c9 in () #6 0x401b9cde in () #7 0x401ac801 in () #8 0x8122e5a in x_init_device (d=0x8264eb0, props=136233556) at device-x.c:487 #9 0x8069cd0 in Fmake_device (type=136355492, connection=136233556, props=136233556) at device.c:581 #10 0x807a72d in Ffuncall (nargs=3, args=0xbffff0e4) at eval.c:3189 #11 0x8059f9e in execute_optimized_program ( program=0x846e704 "ÀÁ\n\"\207karl@ca(", stack_depth=3, constants_data=0x82a6b40) at bytecode.c:748 #12 0x8059c46 in funcall_compiled_function (fun=137013920, nargs=1, args=0xbffff1d0) at bytecode.c:521 #13 0x807a887 in Ffuncall (nargs=2, args=0xbffff1cc) at eval.c:3221 #14 0x8059f9e in execute_optimized_program ( program=0x8481464 "\b?­%Á\nB\022à \210\f@\rB\026\006ÇÁ!«\b\t¬\005ÈÉ!\021ÊË!\210\016\006A\025Ì\211\020\207error t1", stack_depth=2, constants_data=0x83ee330) at bytecode.c:748 #15 0x8059c46 in funcall_compiled_function (fun=138331408, nargs=0, ---Type to continue, or q to quit--- args=0xbffff2b4) at bytecode.c:521 #16 0x807a887 in Ffuncall (nargs=1, args=0xbffff2b0) at eval.c:3221 #17 0x8059f9e in execute_optimized_program ( program=0x824225c "\bA\031ÂÃ\034\035Æ\t!\021ÇÈ!«\004É \210\016\n«\020\016\013¬\fÌÍÎ\016\n!ÏQ! \210Ð \210*Ñ \210rÒÓ!q\210Ô \210ÕÖ!\210\016\027Øa«\005\016\031 \210)Ú Ûa«\bË ¬\004Ü \210Ý \210Ö\026\036Ë ­\004ßÃ!)\207macs\037", stack_depth=4, constants_data=0x83285c0) at bytecode.c:748 #18 0x8059c46 in funcall_compiled_function (fun=137511132, nargs=0, args=0xbffff3a0) at bytecode.c:521 #19 0x807a887 in Ffuncall (nargs=1, args=0xbffff39c) at eval.c:3221 #20 0x8059f9e in execute_optimized_program ( program=0x8277104 "\b«\005ÁÂ!\207Ã\020Ä \211\035«\030\rG\016\006GW«\020Ç\016\006!Ç\r!k«\006È\r!\026\006)É\016\006!\026\006Ê \210Ë \210\016\f®\aÍÎ!­\002Ã\036\fÏ\016\020\016\021\"\026\022\016\f«\nÓÔÕ\016\022\"Ö\"\210\016\022¬\006× \210ª\fØ\016\022\016\031\016\032\016\f$\210Û \210)\016\034¬\022\016\035«\016Þßà\016!!\016\035\"âÃ#\210\016\034¬\024\016\031¬\006ã\016$!\210ã\016%!\210ã\016&!\210ç\216è )\207", stack_depth=6, constants_data=0x8328440) at bytecode.c:748 #21 0x8059c46 in funcall_compiled_function (fun=137511076, nargs=0, args=0xbffff430) at bytecode.c:521 #22 0x807a38e in Feval (form=137455784) at eval.c:3045 #23 0x80784ba in condition_case_1 (handlers=136233652, bfun=0x8079c54 , barg=137455784, hfun=0x8062fe8 , harg=136233556) at eval.c:1640 #24 0x806305d in top_level_1 (dummy=136233556) at cmdloop.c:205 ---Type to continue, or q to quit--- #25 0x80781ff in internal_catch (tag=136307820, func=0x8063034 , arg=136233556, threw=0x0) at eval.c:1315 #26 0x8063124 in initial_command_loop (load_me=136233556) at cmdloop.c:284 #27 0x8075508 in sort_args (argc=2, argv=0xbffff794) at emacs.c:1756 #28 0x8075c5e in main () at emacs.c:2181 #29 0x402ff18f in () (gdb) quit The program is running. Exit anyway? (y or n) y cathcart:~ # $ cvs status src/device-x.c =================================================================== File: device-x.c Status: Up-to-date Working revision: 1.33.2.8 Repository revision: 1.33.2.8 /usr/CVSroot/XEmacs/xemacs/src/device-x.c,v Sticky Tag: release-21-2 (branch: 1.33.2) Sticky Date: (none) Sticky Options: (none) uname -a: Linux cathcart.sysc.pdx.edu 2.2.9 #1 SMP Fri May 14 14:39:39 PDT 1999 i686 unknown ./configure '--compiler=egcc' '--cflags=-g -O2 -mpentiumpro' '--with-dialogs=athena3d' '--with-gpm=no' '--package-path=~/.xemacs/::/usr/local/src/XEmacs/Packages' '--debug=no' '--error-checking=none' '--with-clash-detection' '--lockdir=/var/lib/emacs/lock' '--infopath=/usr/share/info:/usr/info:/usr/local/share/info:/usr/local/info:~/.xemacs/info' '--with-mule' '--site-includes=/usr/include/db2' XEmacs 21.2-b17 "Chiyoda" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/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? egcc -g -O2 -mpentiumpro 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: /usr/include/db2 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 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 dialog boxes. Compiling in DLL support. Clash detection will use "/var/lib/emacs/lock" for locking files. movemail will use "dot-locking" for locking mail spool files. From owner-xemacs-beta@xemacs.org Thu Jul 1 06:01:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA22057 for xemacs-beta-out; Thu, 1 Jul 1999 06:01:34 -0400 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 GAA22054 for ; Thu, 1 Jul 1999 06:01:33 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA07005 for ; Thu, 1 Jul 1999 12:01:32 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001hK; Thu Jul 1 12:01:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA20874; Thu, 1 Jul 1999 12:01:29 +0200 To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-h From: Jan Vroonhof Date: 01 Jul 1999 12:01:28 +0200 In-Reply-To: "Stephen J. Turnbull"'s message of "Thu, 1 Jul 1999 11:15:53 +0900 (JST)" 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: "Stephen J. Turnbull" writes: > Jan> Maybe putting characters in lrecords for Mule is the way to > Jan> go. Maybe even with the ugly small-character/big-character > Jan> thing I reposed for unsigned/signed integers above. > > Nope, uh-uh, sorry. There are Emchars in every textual rune. See > redisplay.h. I am sorry but what has that got do with it? Or put otherwise: That is exactly the point. All code that deals with lots of characters already deals with emchars directly, not with LispObject. Jan From owner-xemacs-beta@xemacs.org Thu Jul 1 07:00:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA23994 for xemacs-beta-out; Thu, 1 Jul 1999 07:00:39 -0400 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 HAA23971 for ; Thu, 1 Jul 1999 07:00:33 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 10zeZr-0008Bc-00; Thu, 1 Jul 1999 13:00:23 +0200 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-h 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 Jul 1999 13:00:23 +0200 In-Reply-To: Jan Vroonhof's message of "01 Jul 1999 12:01:28 +0200" Message-ID: <876744d48o.fsf@pc-hrvoje.srce.hr> Lines: 26 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > "Stephen J. Turnbull" writes: > > > Jan> Maybe putting characters in lrecords for Mule is the way to > > Jan> go. Maybe even with the ugly small-character/big-character > > Jan> thing I reposed for unsigned/signed integers above. > > > > Nope, uh-uh, sorry. There are Emchars in every textual rune. See > > redisplay.h. > > I am sorry but what has that got do with it? Or put otherwise: That > is exactly the point. All code that deals with lots of characters > already deals with emchars directly, not with LispObject. I see two potential problems with lrecord characters. First is efficiency -- examining characters from Lisp would become even slower than it is now because it would involve the overhead of "creating" the character objects. This could be partially solved by implementing the small/big character thing, but it still wouldn't help with, say, large Japanese texts. The second problem is with GC -- any Lisp object storing a character will then need to be GCPRO'ed. I don't know if this is a big problem or not, but GCPRO troubles /are/ hard to debug so we should consider them carefully. From owner-xemacs-beta@xemacs.org Thu Jul 1 08:27:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA26592 for xemacs-beta-out; Thu, 1 Jul 1999 08:27:29 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA26589 for ; Thu, 1 Jul 1999 08:27:27 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 10zfvz-0006Fa-00 for xemacs-beta@xemacs.org; Thu, 01 Jul 1999 13:27:19 +0100 Date: Thu, 1 Jul 1999 13:27:19 +0100 (BST) From: Gunnar Evermann To: XEmacs Beta Subject: Re: [crash] Opening frame across ssh from inside a screen. In-Reply-To: <87emisrc84.fsf@bittersweet.sysc.pdx.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 1 Jul 1999, karlheg wrote: > I logged in across the room vi ssh, started `screen -R', then ran an > xemacs -nw. I started gnuserv, and used `make-frame-on-display' from > the scratch buffer to try and project across to the display in front > of me. It crashed. please look into this (if you have the time)! Some suggestions: recompile with '-g' only (no optimisation, they only introduce new bugs and mess up debug info) check which X function exactly is called (according to the line numbers it could be DefaultVisual, but I suspect those numbers are off already. look at all parameters of those functions. this is debian, right? get X with full debug info and single step into the function and figure out what exactly is going on. That's why OpenSource rules! (I wish I could debug X/Motif on my Sun) :-) ask somebody who knows more about X than I do.... > #4 0x8123a40 in x_IO_error_handler (disp=0x823d900) at device-x.c:1038 > #5 0x401bc2c9 in () > #6 0x401b9cde in () > #7 0x401ac801 in () > #8 0x8122e5a in x_init_device (d=0x8264eb0, props=136233556) at device-x.c:487 > #9 0x8069cd0 in Fmake_device (type=136355492, connection=136233556, > props=136233556) at device.c:581 cheers, Gunnar From owner-xemacs-beta@xemacs.org Thu Jul 1 09:07:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA28755 for xemacs-beta-out; Thu, 1 Jul 1999 09:07:39 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA28752 for ; Thu, 1 Jul 1999 09:07:37 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 10zgYv-0000M7-00 for xemacs-beta@xemacs.org; Thu, 01 Jul 1999 14:07:33 +0100 Date: Thu, 1 Jul 1999 14:07:32 +0100 (BST) From: Gunnar Evermann To: XEmacs Beta Subject: Re: [crash] Opening frame across ssh from inside a screen. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Thu, 1 Jul 1999, Gunnar Evermann wrote: > On 1 Jul 1999, karlheg wrote: > check which X function exactly is called (according to the line numbers > it could be DefaultVisual, but I suspect those numbers are off already. Uhm, sorry about that -- I was looking at the wrong version of device-x. That's what happens if you answer multiple bug reports at the same time. Actually there is a report in the BTS that looks just like yours -- only difference is, that it is for 19.14 :-) Why was there no stacktrace eye catcher in your backtrace, anyway? Overly aggressive inlining by egcs? Still it would be great if you could figure this out! From owner-xemacs-beta@xemacs.org Thu Jul 1 09:26:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA29616 for xemacs-beta-out; Thu, 1 Jul 1999 09:26:46 -0400 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 JAA29612 for ; Thu, 1 Jul 1999 09:26:44 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA25281 for ; Thu, 1 Jul 1999 15:26:43 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006Ak; Thu Jul 1 15:26:35 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA22821; Thu, 1 Jul 1999 15:26:34 +0200 To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-h From: Jan Vroonhof Date: 01 Jul 1999 15:26:34 +0200 In-Reply-To: Hrvoje Niksic's message of "01 Jul 1999 13:00:23 +0200" 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: > The second problem is with GC -- any Lisp object storing a character > will then need to be GCPRO'ed. I don't know if this is a big problem > or not, but GCPRO troubles /are/ hard to debug so we should consider > them carefully. I forgot about the damn GCPROs. There is bound to be code that assumes characters and integers don't need to be GCPRO'ed. Jan From owner-xemacs-beta@xemacs.org Thu Jul 1 10:23:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA32185 for xemacs-beta-out; Thu, 1 Jul 1999 10:23:10 -0400 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 KAA32179 for ; Thu, 1 Jul 1999 10:23:05 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 10zhPA-0008H8-00; Thu, 1 Jul 1999 16:01:32 +0200 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-h 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 Jul 1999 16:01:31 +0200 In-Reply-To: Jan Vroonhof's message of "01 Jul 1999 15:26:34 +0200" Message-ID: <87aetgbhac.fsf@pc-hrvoje.srce.hr> Lines: 8 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > I forgot about the damn GCPROs. There is bound to be code that > assumes characters and integers don't need to be GCPRO'ed. some_function_that_can_gc (make_int (foo), ...); There are hundreds of such in the code. Dozens with make_char(). From owner-xemacs-beta@xemacs.org Thu Jul 1 11:07:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA05129 for xemacs-beta-out; Thu, 1 Jul 1999 11:07:04 -0400 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 LAA05126 for ; Thu, 1 Jul 1999 11:07:02 -0400 Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d61F6n021024; Thu, 1 Jul 1999 11:06:49 -0400 Message-Id: <199907011506.d61F6n021024@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: Your message of "Thu, 01 Jul 1999 11:15:53 +0900." <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> 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[ <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1177919732P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 01 Jul 1999 11:06:48 -0400 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Exmh_1177919732P Content-Type: text/plain; charset=us-ascii On Thu, 01 Jul 1999 11:15:53 +0900, you said: > Yes. UCS-4 is going to be the standard unified character type in the > near future. It can handle all foreseeable needs for plain text. John Von Neuman once said "4K of memory should satisfy all forseeable computational requirements". A lot of programmers are busy fixing code that assumed that 2 bytes could signify all forseeable date fields. What happens to UCS-4 if http://setiathome.ssl.berkeley.edu actually finds something? ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1177919732P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN3uEB9QBOOoptg9JAQEFEAQAi5+JtCx41jYX/vD4gA1X0jXDg+ZDANGH BuqMo9w3yxJv7sgRwWS1VQ67/FxEUIfNHsZcoi6yaLshlY6zpg35Q3DAEnUx43ge ZZCY+aR6hP6iUe+JiBtMZXDnAjSRSjEbP8nwRhgjR4u0JC8lEpdrwOH02UM28awN QiyJh8OcYuo= =Chd6 -----END PGP MESSAGE----- --==_Exmh_1177919732P-- From owner-xemacs-beta@xemacs.org Thu Jul 1 11:55:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA07035 for xemacs-beta-out; Thu, 1 Jul 1999 11:55:08 -0400 Received: from nfssrv.Mat.UCM.Es (matnfs.mat.ucm.es [147.96.20.227]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA06988 for ; Thu, 1 Jul 1999 11:54:11 -0400 Received: from sunma2.mat.ucm.es ([147.96.5.227]) by nfssrv.Mat.UCM.Es (Netscape Mail Server v2.02) with SMTP id AAA14929 for ; Thu, 1 Jul 1999 17:36:00 +0200 X-Mailer: 20.3 "Vatican City" XEmacs Lucid (via feedmail 9-beta-4 I); VM 6.72 under 20.3 "Vatican City" XEmacs Lucid From: "Uwe Brauer" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14203.43195.162383.457879@sunma2.mat.ucm.es> Date: Thu, 1 Jul 1999 17:43:23 +0000 (GMT) To: xemacs-beta@xemacs.org Subject: support of bidirectional text? Reply-To: oub@eucmos.sim.ucm.es Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi I am quite interested to edit Hebrew text with emacs/xemacs. For that I re awoke an old Hebrew.el program of the beginning of the nineties. However there the text is written and SAVED from the right-to-the-left, which is sometimes called visual method. However for Tex and other purposes the text should be saved from-the-left-to-the-right and only displayed from the right-to-the-left. Now, although I am not specially attracted by MULE, is seems at the moment that they are only active group working on multilingual support within emacs/xemacs. TAKAHASHI Naoto, of the MULE team told me that they, in order to include Hebrew support within MULE, need something like a support of right-to-left display. As I understand it this would keep the text, written from the left-to-the-right but displayed vice versa. Now it is supposed that GNUemacs 20.4 will have something like this, but it is not clear when it will be released. Is there some hope that recent versions of xemacs will have such type of support. Thanks Uwe Brauer From owner-xemacs-beta@xemacs.org Thu Jul 1 12:21:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA08705 for xemacs-beta-out; Thu, 1 Jul 1999 12:21:36 -0400 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 MAA08700 for ; Thu, 1 Jul 1999 12:21:34 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA11565; Thu, 1 Jul 1999 18:21:33 +0200 (MET DST) Received: from thales(129.132.146.160), claiming to be "thales.math.ethz.ch" via SMTP by frege, id smtpdAAAa002o.; Thu Jul 1 18:21:27 1999 Received: (vroonhof@localhost) by thales.math.ethz.ch (8.6.12/D-MATH-client) id SAA28126; Thu, 1 Jul 1999 18:21:20 +0200 To: xemacs-beta@xemacs.org, oub@eucmos.sim.ucm.es Subject: Re: support of bidirectional text? References: <14203.43195.162383.457879@sunma2.mat.ucm.es> From: Jan Vroonhof Date: 01 Jul 1999 18:21:20 +0200 In-Reply-To: "Uwe Brauer"'s message of "Thu, 1 Jul 1999 17:43:23 +0000 (GMT)" 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: "Uwe Brauer" writes: > As I understand it this would keep the text, written from the > left-to-the-right but displayed vice versa. Now it is supposed that > GNUemacs 20.4 will have something like this, but it is not clear when > it will be released. Are you sure about the version number? Eli Za????? said in March that he was thinking about it. Progress must have been extremely fast then. It is more likely they meant 20.5 which is going to contain the new end-to-all-problems mystical display engine. > Is there some hope that recent versions of xemacs will have such > type of support. Unless you start hacking, I think this is unlikely. Unfortunately there are no developers who speak any of these R-to-L languages. I think a lesson to be drawn from Mule project is that it this is very important. There is a bit of a chicken and egg problem here. Jan From owner-xemacs-beta@xemacs.org Thu Jul 1 13:00:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA10968 for xemacs-beta-out; Thu, 1 Jul 1999 13:00:42 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA10965 for ; Thu, 1 Jul 1999 13:00:41 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 10zkCQ-00054y-00 for xemacs-beta@xemacs.org; Thu, 01 Jul 1999 18:00:34 +0100 Date: Thu, 1 Jul 1999 18:00:34 +0100 (BST) From: Gunnar Evermann To: xemacs-beta@xemacs.org Subject: Re: support of bidirectional text? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 1 Jul 1999, Jan Vroonhof wrote: > "Uwe Brauer" writes: > > > As I understand it this would keep the text, written from the > > left-to-the-right but displayed vice versa. Now it is supposed that > > GNUemacs 20.4 will have something like this, but it is not clear when > > it will be released. > > Are you sure about the version number? > > Eli Za????? said in March that he was thinking about it. Progress > must have been extremely fast then. didn't Handa-san actually demo this?? I seem to remember seeing it. > It is more likely they meant 20.5 which is going to contain the new > end-to-all-problems mystical display engine. :-) Has anyone actually ever seen that thing? Is there maybe even something like design document available somewhere (e.g. on the "secret FTP site")? Or is writing stuff like that just not the way FSF Emacs development is done? Gunnar From owner-xemacs-beta@xemacs.org Thu Jul 1 13:17:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA11992 for xemacs-beta-out; Thu, 1 Jul 1999 13:17:43 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA11988 for ; Thu, 1 Jul 1999 13:17:41 -0400 Received: from metheny.enst.fr (VcB2XlD7SOwjg/5nRgjF1HRqv1u1XQ8O@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id TAA21710; Thu, 1 Jul 1999 19:17:33 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id TAA12987; Thu, 1 Jul 1999 19:17:30 +0200 (MET DST) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, oub@eucmos.sim.ucm.es Subject: Re: support of bidirectional text? References: <14203.43195.162383.457879@sunma2.mat.ucm.es> 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: Jan Vroonhof's message of "01 Jul 1999 18:21:20 +0200" Mail-Copies-To: never 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: 11 User-Agent: Gnus/5.070089 (Pterodactyl Gnus v0.89) XEmacs/21.2 (Chiyoda) 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: > Eli Za????? --- retsky -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 1 16:12:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA22764 for xemacs-beta-out; Thu, 1 Jul 1999 16:12:23 -0400 Received: from max3p141.smart.net (max3p141.smart.net [216.84.81.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA22758 for ; Thu, 1 Jul 1999 16:12:19 -0400 Received: (from jmiller@localhost) by max3p141.smart.net (8.8.7/8.8.7) id QAA26673; Thu, 1 Jul 1999 16:00:27 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14203.51409.581676.214166@max3p123.smart.net> Date: Thu, 1 Jul 1999 16:00:17 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: building 21.2 with no-x fails X-Mailer: VM 6.62 under 21.0 "Pyrenean-pre6" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Well, after 7 months in Italy, I have finally made it back to the States. I grabbed 21.2.17 from cvs and the following configuration fails to compile. ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--package-path=/usr/local/lib/xemacs/packages- 21.0' '--with-x11=no' I get the following error: glyphs.c:2930: parse error before `struct' glyphs.c:2930: `image' undeclared here (not in a function) glyphs.c:2930: initializer element for `glyph_description[0].offset' is not cons tant make[1]: *** [glyphs.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 probably an ifdef based on whether X is available is missing. Jeff From owner-xemacs-beta@xemacs.org Thu Jul 1 16:14:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA22891 for xemacs-beta-out; Thu, 1 Jul 1999 16:14:05 -0400 Received: from max3p141.smart.net (max3p141.smart.net [216.84.81.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA22864 for ; Thu, 1 Jul 1999 16:13:41 -0400 Received: (from jmiller@localhost) by max3p141.smart.net (8.8.7/8.8.7) id QAA26722; Thu, 1 Jul 1999 16:01:43 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14203.51491.801808.460799@max3p123.smart.net> Date: Thu, 1 Jul 1999 16:01:39 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: another 21.2 failure X-Mailer: VM 6.62 under 21.0 "Pyrenean-pre6" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Doing a minimal build fails as well for me. ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--with-database=no' '--with-dialogs=none' '--w ith-gif=no' '--with-gpm=no' '--with-jpeg=no' '--with-menubars=none' '--with-offi x=no' '--package-path=/tmp' '--with-png=no' '--with-scrollbars=none' '--with-shl ib=no' '--with-sound=no' '--with-toolbars=no' '--with-tiff=no' '--with-xface=no' '--with-xpm=no' gives this error: glyphs-x.c: In function `x_widget_instantiate': glyphs-x.c:2184: `popup_selection_callback' undeclared (first use this function) glyphs-x.c:2184: (Each undeclared identifier is reported only once glyphs-x.c:2184: for each function it appears in.) make[1]: *** [glyphs-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 I think this is because the menubars are compiled out. jeff From owner-xemacs-beta@xemacs.org Thu Jul 1 16:16:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA23052 for xemacs-beta-out; Thu, 1 Jul 1999 16:16:33 -0400 Received: from max3p141.smart.net (max3p141.smart.net [216.84.81.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA23039 for ; Thu, 1 Jul 1999 16:16:23 -0400 Received: (from jmiller@localhost) by max3p141.smart.net (8.8.7/8.8.7) id QAA26783; Thu, 1 Jul 1999 16:04:26 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14203.51655.631851.941975@max3p123.smart.net> Date: Thu, 1 Jul 1999 16:04:23 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: a 3rd build failure for 21.2 X-Mailer: VM 6.62 under 21.0 "Pyrenean-pre6" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: this is the configuration i use to test building with lesstif ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -mal ign-jumps=2 -malign-functions=2' '--with-dialogs=motif' '--with-menubars=motif' '--package-path=/usr/local/lib/xemacs/packages-21.0' '--with-scrollbars=motif' I get this error: scrollbar-x.c: In function `update_one_scrollbar_bs': scrollbar-x.c:189: `XtNuseBackingStore' undeclared (first use this function) scrollbar-x.c:189: (Each undeclared identifier is reported only once scrollbar-x.c:189: for each function it appears in.) make[1]: *** [scrollbar-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 jeff From owner-xemacs-beta@xemacs.org Thu Jul 1 16:38:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA24565 for xemacs-beta-out; Thu, 1 Jul 1999 16:38:19 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA24560 for ; Thu, 1 Jul 1999 16:38:16 -0400 Received: from kramer.bp.aventail.com (wmperry@usrpri2-21.kiva.net [206.97.75.86]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id NAA16342; Thu, 1 Jul 1999 13:36:55 -0700 (PDT) Received: (from wmperry@localhost) by kramer.bp.aventail.com (8.9.3/8.9.3) id PAA12444; Thu, 1 Jul 1999 15:36:52 -0500 To: Gunnar Evermann Cc: xemacs-beta@xemacs.org Subject: Re: support of bidirectional text? References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 40 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2(beta14) (Dionysos) 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: > On 1 Jul 1999, Jan Vroonhof wrote: > > > "Uwe Brauer" writes: > > > > > As I understand it this would keep the text, written from the > > > left-to-the-right but displayed vice versa. Now it is supposed that > > > GNUemacs 20.4 will have something like this, but it is not clear when > > > it will be released. > > > > Are you sure about the version number? > > > > Eli Za????? said in March that he was thinking about it. Progress > > must have been extremely fast then. > > didn't Handa-san actually demo this?? I seem to remember seeing it. I don't remember seeing it, but I missed part of handa-san's demo that day, so may simply have been out of the room. > > It is more likely they meant 20.5 which is going to contain the new > > end-to-all-problems mystical display engine. > > :-) Has anyone actually ever seen that thing? Is there maybe even > something like design document available somewhere (e.g. on the "secret > FTP site")? Or is writing stuff like that just not the way FSF Emacs > development is done? I've seen it. :) If you want to actually see some of the code that takes advantage of it, look at 'font.el' in the latest Emacs/W3 releases. It works just fine with the new redisplay engine, which is really quite sexy. I haven't worked much with the graphics stuff, but I need try and patch PNG support into it in the next month or so. I'm not supposed to give out the URL to the source to public lists, but if anyone wants it, lemme know and I can email it to you privately. Gerd Moellmann is the one working on it. -Bill P. From owner-xemacs-beta@xemacs.org Thu Jul 1 19:42:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA03372 for xemacs-beta-out; Thu, 1 Jul 1999 19:42:37 -0400 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 TAA03367 for ; Thu, 1 Jul 1999 19:42:34 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id IAA19627; Fri, 2 Jul 1999 08:48:21 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: building 21.2 with no-x fails References: <14203.51409.581676.214166@max3p123.smart.net> X-Attribution: sb From: SL Baur In-Reply-To: Jeff Miller's message of "Thu, 1 Jul 1999 16:00:17 -0400 (EDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 02 Jul 1999 08:48:20 +0900 Message-ID: Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkBpQmVFRBsoQiI=?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a known problem, but I don't know what the hold up is about getting the fix in. At any rate, it will continue to delay b18 until it is fixed ... Jeff Miller writes in xemacs-beta@xemacs.org: > glyphs.c:2930: parse error before `struct' > glyphs.c:2930: `image' undeclared here (not in a function) > glyphs.c:2930: initializer element for `glyph_description[0].offset' is not cons > tant > make[1]: *** [glyphs.o] Error 1 > make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' > make: *** [dump-elcs] Error 2 > probably an ifdef based on whether X is available is missing. -- $B3?$N;R$O3?(B (Like father, like son) From owner-xemacs-beta@xemacs.org Thu Jul 1 19:47:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA03762 for xemacs-beta-out; Thu, 1 Jul 1999 19:47:16 -0400 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 TAA03754 for ; Thu, 1 Jul 1999 19:47:14 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id IAA13469; Fri, 2 Jul 1999 08:53:01 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [crash] Opening frame across ssh from inside a screen. References: X-Attribution: sb From: SL Baur In-Reply-To: Gunnar Evermann's message of "Thu, 1 Jul 1999 14:07:32 +0100 (BST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 02 Jul 1999 08:53:00 +0900 Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkBpQmVFRBsoQiI=?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Gunnar Evermann writes in xemacs-beta@xemacs.org: > Why was there no stacktrace eye catcher in your backtrace, anyway? Overly > aggressive inlining by egcs? Yup, this has been known since the day we put that "feature" in. We should probably rename sort_args in the same way we renamed main_1. -- $BAkHV9f$rF~NO$7$F2<$5$$!#(B (recorded keybox message at ETL) From owner-xemacs-beta@xemacs.org Thu Jul 1 23:19:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA13122 for xemacs-beta-out; Thu, 1 Jul 1999 23:19:14 -0400 Received: from localhost (tanko.sk.tsukuba.ac.jp [130.158.99.155]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA13119 for ; Thu, 1 Jul 1999 23:19:12 -0400 Received: by localhost id m10ztr5-00015aC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Fri, 2 Jul 1999 12:19:11 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14204.12206.919299.550261@tanko.sk.tsukuba.ac.jp> Date: Fri, 2 Jul 1999 12:19:10 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: <199907011506.d61F6n021024@black-ice.cc.vt.edu> References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <199907011506.d61F6n021024@black-ice.cc.vt.edu> X-Mailer: VM 6.71 under 21.1 (patch 3) "Acadia" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Valdis" == Valdis Kletnieks writes: Valdis> On Thu, 01 Jul 1999 11:15:53 +0900, you said: >> Yes. UCS-4 is going to be the standard unified character type >> in the near future. It can handle all foreseeable needs for >> plain text. Valdis> John Von Neuman once said "4K of memory should satisfy all Valdis> forseeable computational requirements". Good point. I thought for a while before being so rash as to publish a statement like that. JvN should have known better; I'm sure he knew what a Turing machine is. But plain text is different; plain text is historically determined by human language. No matter how creative we get in inventing new languages, I think it is unlikely that human beings are going to come up with 32760+ character sets larger than any currently in use by any single language. (Yes, we could do it before breakfast with cryptographic applications, but the one-time pad sorta suggests we won't _standardize_ them.) If we assume phonetics, we have room for 8.3 million of them.... Valdis> What happens to UCS-4 if Valdis> http://setiathome.ssl.berkeley.edu actually finds Valdis> something? ;) If they're smart enough or old enough or various enough to fill up that thirty-one-bit space, we've got bigger problems than just learning our ABCs. They will have already solved that one, I'm sure; their version of XEmacs will have a Lisp engine with lexical scope and a redisplay that works and can be understood. I can hardly wait! ;) -- 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 Jul 1 23:49:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA14893 for xemacs-beta-out; Thu, 1 Jul 1999 23:49:01 -0400 Received: from localhost (tanko.sk.tsukuba.ac.jp [130.158.99.155]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA14885 for ; Thu, 1 Jul 1999 23:48:54 -0400 Received: by localhost id m10zuJi-000132C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Fri, 2 Jul 1999 12:48:46 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> Date: Fri, 2 Jul 1999 12:48:46 +0900 (JST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.71 under 21.1 (patch 3) "Acadia" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> No, we should get the buffers right and avoid UCS-x Hrvoje> pissing contests. Your argument doesn't hold water here Hrvoje> and I don't like Mule screwing the rest of us. You're exactly right, and of course I'm exactly right too when I say the exact converse. (Except that both arguments do hold helium, as well as water.) Unfortunately, we're incompatible. So we have to choose. Hrvoje> I think this conversation is starting to revert me to my Hrvoje> original train of thought, that Mule is not the be-all Hrvoje> end-all of everything. There are other people using Hrvoje> XEmacs, and Mule advocates will have to realize that one Hrvoje> of these days. I do. I don't deny the need to choose. We each have the right to advocate that the main line support what we think is important. I will happily fork and maintain a private version of XEmacs, if it goes against me. If there seem to be people interested, I will revisit the issue occasionally. If not, I will bring it up again when changes in XEmacs make it preferable for me to consider a full fork rather than maintain a private version. >> Yes. UCS-4 is going to be the standard unified character type >> in the near future. It can handle all foreseeable needs for >> plain text. Hrvoje> Now your argument resembles to those of Markus Kuhn. The Hrvoje> important question is whether UCS-4 is acceptable for our Hrvoje> internal representation. To me it seems that it's not, Because you want that bit. If we weren't competing over the bit, it would be the obvious thing to do (it's been the obvious thing to do for a while; Ben knew that way back when). I'm sure you'd have no objection then, as long is it didn't break any code, and it doesn't need to. In fact, it would make code less likely to break. Hrvoje> regardless of whether it's the "standard unified character Hrvoje> type" (ed is the standard editor, anyway). So? I bet it would be rather easy to turn ed into a UCS-4 editor. >> Unfortunately, probably not true. Current Mule representation >> has probably reached the end of the line; we're running out of >> code space. Hrvoje> But who cares about that? You're not supposed to be Hrvoje> relying on the value char-int returns, right? Right. The Well, yes, but in practice people do rely on that value; often that value being more reliable than a true character is the reason they use it. I would be happy to break char-int and int-char beyond repair, personally, and spend the effort to make characters reliable. Hrvoje> whole idea behind a character type is that things can be Hrvoje> changed without breaking everything in sight. People who care about efficiency and transparency (ie, extensibility and maintainability) care about internal representation. I'm sure you could cobble up a big-buffer package out of Lisp code, but you would rightly consider that unacceptably fragile and complicated. It's not quite so bad with UCS-4, I admit; we could get half of that space with a not too horrible hack. But it would be a hack, it would hurt transparency, and I can imagine circumstances where we would want to revisit that decision. I see no reason why a full implementation of UCS-4 characters would change again in the life of XEmacs. On the other hand, as you point out, until a standard int is > 32 bits, you are going to need a horrible hack to get beyond 2GB buffers, and for practical purposes, 1GB. And I just don't think that buffer sizes are going to reach a natural constant upper limit at 99.44GB, and then politely give up. You (or someone) are going to implement that hack, and not too far off in the future, I bet. So it really comes down to whether your "rest of us" is bigger than mine. I'm not going to prejudge others' feelings about it. That's my last word in this thread on what we "should" do; we (both of us) are just going in circles. When I have something usable to show, I'll be back, of course. -- 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 Jul 1 23:52:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA15178 for xemacs-beta-out; Thu, 1 Jul 1999 23:52:54 -0400 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 XAA15172 for ; Thu, 1 Jul 1999 23:52:50 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id MAA20007; Fri, 2 Jul 1999 12:58:37 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "30 Jun 1999 09:22:46 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 02 Jul 1999 12:58:36 +0900 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkBpQmVFRBsoQiI=?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: ... > Note that no editor on 32-bit systems can grok a >2G buffer because of > limited pointer size. Thus a 1G limit is just one step below the > "theoretical" limit. You can argue that being two steps below it is > not much worse, but I am not really convinced. O.K. Since size matters to you, how about another alternative? What would/could we gain or lose by using long long as EMACS_INTs on 32 bit architectures? -- $B2LJs$O?2$FBT$F(B (All things come to those who wait) From owner-xemacs-beta@xemacs.org Fri Jul 2 03:00:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA22581 for xemacs-beta-out; Fri, 2 Jul 1999 03:00:26 -0400 Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA22572; Fri, 2 Jul 1999 03:00:20 -0400 Received: from sparrow.bear.com (user-2ive2ss.dialup.mindspring.com [165.247.11.156]) by smtp4.mindspring.com (8.8.5/8.8.5) with ESMTP id DAA03984; Fri, 2 Jul 1999 03:00:18 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.1/8.9.1) with SMTP id DAA08281; Fri, 2 Jul 1999 03:00:10 -0400 Date: Fri, 2 Jul 1999 03:00:01 -0400 (EDT) From: Justin Vallon To: SL Baur cc: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 2 Jul 1999, SL Baur wrote: > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > ... > > Note that no editor on 32-bit systems can grok a >2G buffer because of > > limited pointer size. Thus a 1G limit is just one step below the > > "theoretical" limit. You can argue that being two steps below it is > > not much worse, but I am not really convinced. > > O.K. Since size matters to you, how about another alternative? What > would/could we gain or lose by using long long as EMACS_INTs on 32 bit > architectures? Is `long long' ANSI? Further, is it guaranteed that sizeof(long long) > sizeof(long)? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Fri Jul 2 03:11:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA23088 for xemacs-beta-out; Fri, 2 Jul 1999 03:11:01 -0400 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 DAA23083 for ; Fri, 2 Jul 1999 03:10:57 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id QAA20232; Fri, 2 Jul 1999 16:16:36 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: X-Attribution: sb From: SL Baur In-Reply-To: Justin Vallon's message of "Fri, 2 Jul 1999 03:00:01 -0400 (EDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 02 Jul 1999 16:16:36 +0900 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Justin Vallon writes in xemacs-beta@xemacs.org: ... > Is `long long' ANSI? Further, is it guaranteed that sizeof(long long) > > sizeof(long)? I don't know, that's why I asked. I _know_ I don't like the other alternative I was presented with and that was to use a struct with two 32-bit ints as a Lisp Object. -- $B3?$N;R$O3?(B (Like father, like son) From owner-xemacs-beta@xemacs.org Fri Jul 2 03:41:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA24273 for xemacs-beta-out; Fri, 2 Jul 1999 03:41:10 -0400 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 DAA24269 for ; Fri, 2 Jul 1999 03:41:09 -0400 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 DAA25748 for ; Fri, 2 Jul 1999 03:46:48 -0400 (EDT) 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 JAA24692; Fri, 2 Jul 1999 09:41:01 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: psgml menus to work under window-system mswindows 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: 02 Jul 1999 09:38:58 +0200 In-Reply-To: Adrian Aichner's message of "13 Jun 1999 21:04:45 +0200" Message-ID: Lines: 39 User-Agent: Gnus/5.070085 (Pterodactyl Gnus v0.85) XEmacs/21.2 (Chiyoda) 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> I have fixed this at long last! APA> Please advise me about the disposition of this patch. Hello Reviewers, could someone please comment on the status of my patch? I would really like to see it adapted to make PSGML work in an MSwindows XEmacs. Regards, Adrian APA> Under MSwindows, no HTML elements or entities could be APA> inserted via the context-sensitive menues. APA> MSwindows and X people, could you please verify this, thanks! APA> Is is correct that package functions do not need to undergo APA> the obsoletion process? I have removed APA> sgml-xemacs-get-popup-value, which is no longer needed. APA> Here are ChangeLog and patch against CVS repository. APA> Regards, APA> Adrian APA> 1999-06-13 Adrian Aichner APA> * psgml-xemacs.el (sgml-popup-menu): Use APA> `get-popup-menu-response' APA> instead of APA> `sgml-xemacs-get-popup-value'. APA> (sgml-xemacs-get-popup-value): Remove this unused APA> function. From owner-xemacs-beta@xemacs.org Fri Jul 2 05:12:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA27227 for xemacs-beta-out; Fri, 2 Jul 1999 05:12:54 -0400 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 FAA27224 for ; Fri, 2 Jul 1999 05:12:52 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id SAA04215; Fri, 2 Jul 1999 18:18:38 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Athena-3D scrollbars broken in 21.2.17 References: <14199.56377.513923.266915@buffalo.fnal.gov> X-Attribution: sb From: SL Baur In-Reply-To: Charles G Waldman's message of "Mon, 28 Jun 1999 15:34:01 -0500 (CDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 02 Jul 1999 18:18:38 +0900 Message-ID: Lines: 69 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Charles G Waldman writes in xemacs-beta@xemacs.org: > Just noticed that if you ./configure --with-scrollbars=athena3d, the > resizing of the scrollbar thingamajig (what's the right name for > that?) doesn't work. With regular Athena scrollbars it seems OK. Can you explain this in more detail? > Anybody else see this? I'm actually using the XawXpm widgets, > "posing" as Athena3d. This always worked for me with earlier versions > of XEmacs. Which version of XawXpm (I don't think it has been updated in quite a long time)? I just did my first build with XawXpm on Dec OSF, XEmacs 21.2.17/InfoDock and it looks fine to me. I will try in Linux with fresh sources this weekend. TurboLinux comes with a different flavor of 3d Athena that doesn't quite work with the `athena3d' option. uname -a: OSF1 miho.m17n.org V4.0 1091 alpha ../../xemacs-21.0/configure '--with-infodock' '--debug=no' '--error-checking=none' '--verbose' '--with-gcc' '--with-gnu-make' '--srcdir=../../xemacs-21.0' '--cflags=-g -O3' '--prefix=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../..' '--bindir=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../../bin/alpha-dec-osf' '--with-mule' '--with-scrollbars=athena3d' '--with-dialogs=athena3d' '--site-prefixes=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../..:/usr/local:/usr/decfw40' '--site-includes=/usr/decfw40/canna/include' '--site-libraries=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../../lib/alpha-dec-osf' '--with-pop' '--mail-locking=file' '--with-system-malloc' InfoDock 4.0.7 configured for `alphaev56-dec-osf4.0e'. Where should the build process find the source code? /tmp_mnt/project/xemacs/infodock/xemacs-21.2 What installation prefix should install use? /tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../.. What operating system and machine description files should InfoDock use? `s/decosf4-0.h' and `m/alpha.h' What compiler should InfoDock be built with? gcc -g -O3 Should InfoDock use the GNU version of malloc? no (User chose not to use GNU allocators). Should InfoDock use the relocating allocator for buffers? yes What window system should InfoDock 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: /usr/decfw40/canna/include Additional libraries: /tmp_mnt/project/InfoDock/infodock/infodock/build/alpha-dec-osf/../../lib/alpha-dec-osf Additional prefixes: /tmp_mnt/project/InfoDock/infodock/infodock/build/alpha-dec-osf/../.. /usr/local /usr/decfw40 Runtime library search path: /usr/local/lib:/usr/decfw40/lib:/usr/dt/lib:/usr/shlib 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 DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. 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 dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access. -- $BA1$O5^$2(B (strike while the iron is hot) From owner-xemacs-beta@xemacs.org Fri Jul 2 06:20:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA29279 for xemacs-beta-out; Fri, 2 Jul 1999 06:20:31 -0400 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 GAA29276 for ; Fri, 2 Jul 1999 06:20:30 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA17828 for ; Fri, 2 Jul 1999 12:20:29 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004MY; Fri Jul 2 12:20:19 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA25531; Fri, 2 Jul 1999 12:20:17 +0200 To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> From: Jan Vroonhof Date: 02 Jul 1999 12:20:17 +0200 In-Reply-To: SL Baur's message of "02 Jul 1999 12:58:36 +0900" 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: SL Baur writes: > O.K. Since size matters to you, how about another alternative? What > would/could we gain or lose by using long long as EMACS_INTs on 32 bit > architectures? 1. Portability. Presumably gcc version < 2.8 generates awfull code for long long. Older Solaris compilers don't support it. 2. Speed. Even on a 64-bit processor a 64-bit XEmacs is much slower than a 32-bit one. 3. Yet another versioning headache. I would want 32-bit + UCS4. Jan From owner-xemacs-beta@xemacs.org Fri Jul 2 07:51:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA32274 for xemacs-beta-out; Fri, 2 Jul 1999 07:51:40 -0400 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 HAA32270 for ; Fri, 2 Jul 1999 07:51:38 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 1101qz-0000LJ-00; Fri, 2 Jul 1999 13:51:37 +0200 To: XEmacs Beta List Subject: Re: support of bidirectional text? References: <14203.43195.162383.457879@sunma2.mat.ucm.es> 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 Jul 1999 13:51:37 +0200 In-Reply-To: Didier Verna's message of "01 Jul 1999 19:17:29 +0200" Message-ID: <87n1xfqng6.fsf@pc-hrvoje.srce.hr> Lines: 8 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > Jan Vroonhof writes: > > > Eli Za????? > > --- retsky ii From owner-xemacs-beta@xemacs.org Fri Jul 2 10:43:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA07136 for xemacs-beta-out; Fri, 2 Jul 1999 10:43:03 -0400 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 KAA07132 for ; Fri, 2 Jul 1999 10:43:02 -0400 Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d62Eh0029772; Fri, 2 Jul 1999 10:43:00 -0400 Message-Id: <199907021443.d62Eh0029772@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: Your message of "02 Jul 1999 12:20:17 +0200." 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[ <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-31226792P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 02 Jul 1999 10:42:59 -0400 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Exmh_-31226792P Content-Type: text/plain; charset=us-ascii On 02 Jul 1999 12:20:17 +0200, Jan Vroonhof said: > 2. Speed. Even on a 64-bit processor a 64-bit XEmacs is much slower > than a 32-bit one. Has anybody done any benchmarking to determine why this is so? My first instinctive guess is that the fact that objects are twice as big means that only half as many can fit into the processor's L1/L2 caches. Are *most* programs affected by a slowdown if recompiled in 64-bit mode, or does it seem to be XEmacs-specific? If the latter, it should be (at least theoretically) possible to track down and shoot the culprit... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-31226792P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN3zP8dQBOOoptg9JAQER+gP9Fq4lMNavGGcOwTlEkpFFBx17Tp1mM4iV ax9dDFui7Ck4RbEOsPPic/9i4rwYIW7iXfnnkpqB9CSYGm/OuexodzZTZI8b7m14 rrfCg17AKl/GngcU8SbUongMnUygbcQAt8cnyMZZ65jSYgOf/czJzfWT9KU2Vadj cZhBm9BSniM= =0pU0 -----END PGP MESSAGE----- --==_Exmh_-31226792P-- From owner-xemacs-beta@xemacs.org Fri Jul 2 11:22:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA08321 for xemacs-beta-out; Fri, 2 Jul 1999 11:22:35 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA08312; Fri, 2 Jul 1999 11:22:27 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id KAA18954; Fri, 2 Jul 1999 10:22:27 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14204.55603.312138.545332@buffalo.fnal.gov> Date: Fri, 2 Jul 1999 10:22:27 -0500 (CDT) To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: Athena-3D scrollbars broken in 21.2.17 In-Reply-To: References: <14199.56377.513923.266915@buffalo.fnal.gov> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > Charles G Waldman writes in xemacs-beta@xemacs.org: > > > Just noticed that if you ./configure --with-scrollbars=athena3d, the > > resizing of the scrollbar thingamajig (what's the right name for > > that?) doesn't work. With regular Athena scrollbars it seems OK. > > Can you explain this in more detail? > I mean the way the size of the scrollbar "thumb" scales to reflect the ratio (chars visible)/(chars in buffer). With the straight Athena scrollbars, this works; with XawXpm the scrollbar "thumb" is either at its minimum size (about 10 pixels high) or at its maximum (filling the entire available vertical space). > Which version of XawXpm (I don't think it has been updated in quite a > long time)? v1.1 From owner-xemacs-beta@xemacs.org Fri Jul 2 12:14:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10069 for xemacs-beta-out; Fri, 2 Jul 1999 12:14:21 -0400 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 MAA10062 for ; Fri, 2 Jul 1999 12:14:14 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 1105x6-0000SB-00; Fri, 2 Jul 1999 18:14:12 +0200 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.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 Jul 1999 18:14:12 +0200 In-Reply-To: SL Baur's message of "02 Jul 1999 12:58:36 +0900" Message-ID: <87pv2b58rv.fsf@pc-hrvoje.srce.hr> Lines: 15 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > ... > > Note that no editor on 32-bit systems can grok a >2G buffer because of > > limited pointer size. Thus a 1G limit is just one step below the > > "theoretical" limit. You can argue that being two steps below it is > > not much worse, but I am not really convinced. > > O.K. Since size matters to you, how about another alternative? > What would/could we gain or lose by using long long as EMACS_INTs on > 32 bit architectures? We would lose portability and speed. Quite unacceptable, unfortunately. :-( From owner-xemacs-beta@xemacs.org Fri Jul 2 12:23:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10551 for xemacs-beta-out; Fri, 2 Jul 1999 12:23:39 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA10547 for ; Fri, 2 Jul 1999 12:23:37 -0400 Received: from metheny.enst.fr (BMwU2Xn6cYscKokjOFudwiENvqF6J262@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id SAA15852 for ; Fri, 2 Jul 1999 18:23:36 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id SAA14884; Fri, 2 Jul 1999 18:23:31 +0200 (MET DST) To: Xemacs Beta Testers Subject: move-to-column modification 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 Mail-Copies-To: never 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: 17 User-Agent: Gnus/5.070089 (Pterodactyl Gnus v0.89) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'd like to change a bit `move-to-column' to get a finer control on the FORCE argument. Sometimes, you may want to go to the precise column if that's possible (by converting tabs into characters), but not if the line is too short. My plan is to allow the FORCE argument a value special of 'coerce which means exactly that. Any other value will behave as usual. This way I don't think we break any existing code. Comments ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 2 12:24:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10571 for xemacs-beta-out; Fri, 2 Jul 1999 12:24:07 -0400 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 MAA10568 for ; Fri, 2 Jul 1999 12:24:03 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 2.05 #1 (Debian)) id 11066b-0000Sw-00; Fri, 2 Jul 1999 18:24:01 +0200 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.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: 02 Jul 1999 18:24:00 +0200 In-Reply-To: "Stephen J. Turnbull"'s message of "Fri, 2 Jul 1999 12:48:46 +0900 (JST)" Message-ID: <87k8sj58bj.fsf@pc-hrvoje.srce.hr> Lines: 59 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > >> Unfortunately, probably not true. Current Mule representation > >> has probably reached the end of the line; we're running out of > >> code space. > > Hrvoje> But who cares about that? You're not supposed to be > Hrvoje> relying on the value char-int returns, right? Right. The > > Well, yes, but in practice people do rely on that value; Who, and what for? > often that value being more reliable than a true character is the > reason they use it. How can it be more reliable than the "true character"? If there is something our API is lacking which makes Lisp coders use char-int where it's not appropriate, we should by all means improve the API. > I would be happy to break char-int and int-char beyond repair, > personally, and spend the effort to make characters reliable. I understand and concur with the latter sentiment, but not with the former. Sorry. > People who care about efficiency and transparency (ie, extensibility > and maintainability) care about internal representation. I'm sure > you could cobble up a big-buffer package out of Lisp code, but you > would rightly consider that unacceptably fragile and complicated. > It's not quite so bad with UCS-4, I admit; we could get half of that > space with a not too horrible hack. But it would be a hack, it > would hurt transparency, All of Mule is a non-transparent horrible hack. Hacking internal representation of characters is ideologically acceptable because it is not visible to the user. The same goes for the internal representation of Lisp objects, and for a bunch of other things. Simplicity of interface over simplicity of implementation! > So it really comes down to whether your "rest of us" is bigger than > mine. Hey, are now going to say that the Chinese need UCS-4, which will effectively end the discussion? :-) Seriously, it's not only about numbers, but about principles. I would hate to see Mule screwing us all by taking the bit from integers. As I said before, I don't like seeing Mule as an all-important aspect of XEmacs. > That's my last word in this thread on what we "should" do; we (both > of us) are just going in circles. When I have something usable to > show, I'll be back, of course. It's easy to come up with "something usable to show". What's *really* hard is to come up with a good design and a good implementation to match it. And I can't provide a definite answer to that any more than you can. :-( From owner-xemacs-beta@xemacs.org Sat Jul 3 03:02:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA26198 for xemacs-beta-out; Sat, 3 Jul 1999 03:02:52 -0400 Received: from localhost (tanko.sk.tsukuba.ac.jp [130.158.99.155]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA26194 for ; Sat, 3 Jul 1999 03:02:49 -0400 Received: by localhost id m110Jow-000136C (Debian Smail-3.2.0.102 1998-Aug-2 #2); Sat, 3 Jul 1999 16:02:42 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> Date: Sat, 3 Jul 1999 16:02:42 +0900 (JST) To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: <87k8sj58bj.fsf@pc-hrvoje.srce.hr> References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.71 under 21.1 (patch 3) "Acadia" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> But who cares about that? You're not supposed to be Hrvoje> relying on the value char-int returns, right? Right. The >> Well, yes, but in practice people do rely on that value; Hrvoje> Who, and what for? The byte-compiler uses it in couple of places, subr.el uses it I think, w3.el uses it a lot. (I'm upgrading the system where my notes are, I can't say more off hand.) ucs-conv has a file or two that don't use much of anything else. >> often that value being more reliable than a true character is >> the reason they use it. Hrvoje> How can it be more reliable than the "true character"? Dunno. I haven't really started tracking it down yet. That's a paraphrase of a comment in bytecode.el or somesuch. >> I would be happy to break char-int and int-char beyond repair, >> personally, and spend the effort to make characters reliable. Hrvoje> I understand and concur with the latter sentiment, but not Hrvoje> with the former. Sorry. I don't see _any_ appropriate use for those myself. Characters taken out of their locales are not integers: they are at best partially ordered (and in Unicode not even close), none of the arithmetic operations make sense, etc. And vice-versa; the operation `toupper' cannot be sensibly applied to integers. Any time those casts are used for anything but pure voyeurism (examining the internal representation), there's a flaw in the API. In practice, of course we need to support casts so that people can implement new operations on characters in Lisp. I'm not serious about "beyond repair." -- 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 Sat Jul 3 05:13:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA30944 for xemacs-beta-out; Sat, 3 Jul 1999 05:13:37 -0400 Received: from mailgw1a.lmco.com (mailgw1a.lmco.com [192.31.106.7]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA30941 for ; Sat, 3 Jul 1999 05:13:36 -0400 Received: from emss02g01.ems.lmco.com (emss02g01.ems.lmco.com [198.7.15.39]) by mailgw1a.lmco.com (8.8.8/8.8.8) with ESMTP id DAA28067 for ; Sat, 3 Jul 1999 03:13:28 -0600 (MDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38887) id <0FEA00L01EYJRD@lmco.com> for xemacs-beta@xemacs.org; Sat, 3 Jul 1999 03:13:31 -0600 (MDT) Received: from emss02i01.ems.lmco.com ([198.7.15.35]) by lmco.com (PMDF V5.2-32 #38887) with ESMTP id <0FEA00G0OEYE2B@lmco.com> for xemacs-beta@xemacs.org; Sat, 03 Jul 1999 03:13:26 -0600 (MDT) Received: by emss02i01.ems.lmco.com with Internet Mail Service (5.5.2232.9) id ; Sat, 03 Jul 1999 03:12:22 -0600 Content-return: allowed Date: Sat, 03 Jul 1999 03:13:15 -0600 From: "Horning, Jim" Subject: Bug in cua-mode.el To: "'xemacs-beta@xemacs.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: A while ago a ported version of cua-mode.el was sent out on this list. ;; Author: Kim F. Storm ;; Adapted-By: SL Baur ;; Maintainer: SL Baur ;; Keywords: emulations ;; Revision: 1.3 It has worked very well in most regards but has one bug that I occasionally run into. I didn't find it in the last sumo I downloaded and I can't get to the CVS site this morning to see if a newer version is available there. This is reproducible on both my NT and Sun builds of 21.1.3 and 21.2.14 on the Sun. It also is repeatable using -vanilla, at least on the NT version. Recipe: After having loaded and activated cua-mode, select a region in an editable file and begin to perform a query-replace in it. Either after you begin typing in characters into the query replace (NT) or when you hit enter after entering the first argument (Sun) you will get an error: (1) (error/warning) Error in `pre-command-hook' (setting hook to nil): (wrong-type-argument integer-or-marker-p nil) A backtrace looks like: Signaling: (wrong-type-argument integer-or-marker-p nil) delete-region(1 nil) (if killp (if (listp killp) (copy-region-as-kill ... ...) (kill-region ... ...)) (delete-region (point) (mark))) ) CUA-delete-active-region(nil) (cond ((eq type ...) (CUA-delete-active-region t)) ((eq type ...) (setq supersede ...)) ((eq type ...) (if ... ...) (CUA-delete-active-region nil)) ((eq type ...) (setq supersede ...)) ((eq type ...) (CUA-delete-active-region nil)) ((eq type ...) (setq supersede ...)) ((eq type ...) (setq supersede ...)) (t (setq ro t))) ) (if (not ro) (cond (... ...) (... ...) (... ... ...) (... ...) (... ...) (... ...) (... ...) (t ...))) ) (progn (if (not ro) (cond ... ... ... ... ... ... ... ...)) (if ro (cond ... ...))) ) (if zmacs-region-active-p (progn (if ... ...) (if ro ...))) ) (if (eq type (quote move)) (if (memq ... ...) (and ... ...)) (if zmacs-region-active-p (progn ... ...))) ) (let ((type ...) (ro buffer-read-only) (supersede nil)) (if (eq type ...) (if ... ...) (if zmacs-region-active-p ...)) (if supersede (setq this-command ...))) ) (if (and CUA-mode (symbolp this-command)) (let (... ... ...) (if ... ... ...) (if supersede ...))) ) CUA-pre-hook() read-minibuffer-internal("Query replace: ") byte-code("..." [recursion-depth minibuffer-depth t standard-input standard-output read-minibuffer-internal prompt] 2) read-from-minibuffer("Query replace: " nil nil nil query-replace-history) query-replace-read-args("Query replace" nil) call-interactively(query-replace) delete-region is getting called with a nil for end, yet the region was active when entering query-replace so (mark) should have been defined. Sorry, I don't know where to take it from there, it looks to me like it should have worked. Regards, Jim Horning -- Jim Horning Senior Engineering Specialist, Computer Architecture Lockheed Martin Vought Systems P.O. Box 650003, M/S L14-01, Dallas, TX 75265-0003 (972)603-1560 mailto:jim.horning@lmco.com From owner-xemacs-beta@xemacs.org Sat Jul 3 07:09:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA01844 for xemacs-beta-out; Sat, 3 Jul 1999 07:09:12 -0400 Received: from xiphias.pdc.kth.se (xiphias.pdc.kth.se [130.237.221.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA01841 for ; Sat, 3 Jul 1999 07:09:11 -0400 Received: (from jas@localhost) by xiphias.pdc.kth.se (8.8.5/8.8.5) id NAA16044; Sat, 3 Jul 1999 13:09:02 +0200 (METDST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: efs-hang on NT References: <199906291525.RAA23457@kindofblue.coling.uni-freiburg.de> <87d7yesr7k.fsf@pc-hrvoje.srce.hr> In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "30 Jun 1999 09:55:50 +0200" From: Simon Josefsson Mail-Copies-To: never Date: 03 Jul 1999 13:09:01 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.3.10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] writes: > >> Having EFS just implementing the FTP protocol or just shipping a > >> sane FTP client with the NT port sound more and more attractive now. > > Hrvoje> Implementing FTP is impossible without support for listening sockets > Hrvoje> -- we would have to rely on the "passive" transfer mode always being > Hrvoje> available. > > Also, you'd have to implement all that gateway crap low-level. And all security extensions (kerberos 4/5 etc), which also require bignums btw. ;) From owner-xemacs-beta@xemacs.org Sat Jul 3 08:36:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA04403 for xemacs-beta-out; Sat, 3 Jul 1999 08:36:04 -0400 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 IAA04400 for ; Sat, 3 Jul 1999 08:36:02 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 110P1U-0000DH-00 for ; Sat, 03 Jul 1999 12:36:00 +0000 To: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.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: 03 Jul 1999 12:36:00 +0000 In-Reply-To: "Stephen J. Turnbull"'s message of "Sat, 3 Jul 1999 16:02:42 +0900 (JST)" Message-ID: <87k8shuczz.fsf@pc-hrvoje.srce.hr> Lines: 28 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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> But who cares about that? You're not supposed to be > Hrvoje> relying on the value char-int returns, right? Right. The > >> Well, yes, but in practice people do rely on that value; > > Hrvoje> Who, and what for? > > The byte-compiler uses it in couple of places, subr.el uses it I > think, w3.el uses it a lot. (I'm upgrading the system where my > notes are, I can't say more off hand.) You haven't answered the "what for" part, which was the more important bit. That the byte-compiler uses it is of no consequence because it is an integral part of the system and can be fixed by us. As for subr.el, the only mention of char-int I can find is: (define-function 'char-int 'char-to-int) Ditto for char-to-int. I haven't looked at w3 sources. > ucs-conv has a file or two that don't use much of anything else. Please don't get me started on ucs-conv. From owner-xemacs-beta@xemacs.org Sat Jul 3 09:07:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA05408 for xemacs-beta-out; Sat, 3 Jul 1999 09:07:16 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA05403 for ; Sat, 3 Jul 1999 09:07:15 -0400 Received: from aventail.com (usrpri2-52.kiva.net [206.97.75.117]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id GAA10594; Sat, 3 Jul 1999 06:07:03 -0700 (PDT) Message-ID: <377E0B74.259E169E@aventail.com> Date: Sat, 03 Jul 1999 08:09:08 -0500 From: "William M. Perry" Organization: Aventail, Corp. X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic wrote: > "Stephen J. Turnbull" writes: > > > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > > > Hrvoje> But who cares about that? You're not supposed to be > > Hrvoje> relying on the value char-int returns, right? Right. The > > >> Well, yes, but in practice people do rely on that value; > > > > Hrvoje> Who, and what for? > > > > The byte-compiler uses it in couple of places, subr.el uses it I > > think, w3.el uses it a lot. (I'm upgrading the system where my > > notes are, I can't say more off hand.) > > You haven't answered the "what for" part, which was the more important > bit. That the byte-compiler uses it is of no consequence because it > is an integral part of the system and can be fixed by us. As for > subr.el, the only mention of char-int I can find is: > > (define-function 'char-int 'char-to-int) > > Ditto for char-to-int. > > I haven't looked at w3 sources. Emacs/W3 uses it in the SOCKS code, where the stuff _really_ is just an int from the wire protocol, so that is safe. It also uses it to make 'dingbats' characters, and only ever uses that on things like ?j ?i, etc, which are safe. If (make-char ...) can take something other than an int, let me know and this usage can disappear. It is used in w3-parse.el if you see an invalid SGML character, to look up things in the stupid #%!@!ing microsoft code pages for replacement. I believe I started using char-int here because of you Stephen - at least I think it was you that pointed out that it spewed tons of Ebola warnings on incorrectly marked japanese documents when we were in tokyo. All of these could fairly easily be removed, except for the SOCKS code. -Bill P. From owner-xemacs-beta@xemacs.org Sat Jul 3 15:57:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA18616 for xemacs-beta-out; Sat, 3 Jul 1999 15:57:51 -0400 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 PAA18609 for ; Sat, 3 Jul 1999 15:57:48 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 110Vur-0000LN-00; Sat, 03 Jul 1999 19:57:37 +0000 To: "William M. Perry" Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> <377E0B74.259E169E@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: 03 Jul 1999 19:57:37 +0000 In-Reply-To: "William M. Perry"'s message of "Sat, 03 Jul 1999 08:09:08 -0500" Message-ID: <87yagxsdzi.fsf@pc-hrvoje.srce.hr> Lines: 11 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "William M. Perry" writes: > It also uses it to make 'dingbats' characters, and only ever uses > that on things like ?j ?i, etc, which are safe. If (make-char ...) > can take something other than an int, You misunderstand. `make-char' is kosher. `int-char' is not, and neither is `char-int'. (Except in internal code, or if you really know what you're doing.) Why do you need int-char and char-int in SOCKS? From owner-xemacs-beta@xemacs.org Sat Jul 3 16:37:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA20375 for xemacs-beta-out; Sat, 3 Jul 1999 16:37:27 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA20372 for ; Sat, 3 Jul 1999 16:37:25 -0400 Received: from kramer.bp.aventail.com (wmperry@usrpri2-52.kiva.net [206.97.75.117]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id NAA13128; Sat, 3 Jul 1999 13:36:07 -0700 (PDT) Received: (from wmperry@localhost) by kramer.bp.aventail.com (8.9.3/8.9.3) id KAA00836; Sat, 3 Jul 1999 10:38:10 -0500 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> <377E0B74.259E169E@aventail.com> <87yagxsdzi.fsf@pc-hrvoje.srce.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 33 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2(beta14) (Dionysos) 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: > "William M. Perry" writes: > > > It also uses it to make 'dingbats' characters, and only ever uses > > that on things like ?j ?i, etc, which are safe. If (make-char ...) > > can take something other than an int, > > You misunderstand. `make-char' is kosher. `int-char' is not, and > neither is `char-int'. (Except in internal code, or if you really know > what you're doing.) I have to make the letter 'j' in a funky character set that I define, and the table I make them from has real chars in it because ?j is easier to read, and make-char will not take a char as an argument. > Why do you need int-char and char-int in SOCKS? Because I like to write things that will be reasonably sane looking like (if (= (char-int x) 5) ... ) instead of (if (= ?\005 x) ... ) At least, that looks better to me. :) -Bill P. From owner-xemacs-beta@xemacs.org Sat Jul 3 17:05:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA21541 for xemacs-beta-out; Sat, 3 Jul 1999 17:05:37 -0400 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 RAA21535 for ; Sat, 3 Jul 1999 17:05:33 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 110Wxl-0000NX-00; Sat, 03 Jul 1999 21:04:41 +0000 To: wmperry@aventail.com Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> <377E0B74.259E169E@aventail.com> <87yagxsdzi.fsf@pc-hrvoje.srce.hr> <863dz5yc9q.fsf@kramer.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: 03 Jul 1999 21:04:41 +0000 In-Reply-To: wmperry@aventail.com's message of "03 Jul 1999 10:38:09 -0500" Message-ID: <87u2rlqwba.fsf@pc-hrvoje.srce.hr> Lines: 31 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.2 (Dionysos) 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: > > You misunderstand. `make-char' is kosher. `int-char' is not, and > > neither is `char-int'. (Except in internal code, or if you really > > know what you're doing.) > > I have to make the letter 'j' in a funky character set that I > define, and the table I make them from has real chars in it because > ?j is easier to read, and make-char will not take a char as an > argument. (char-int ?j) is, again, perfectly fine. I don't think Stephen's (or anyone else's) changes will break it, either. The problem is with using (char-int (make-char 'latin-iso8859-2 57)) for something other than temporary storage within one Emacs image. > > Why do you need int-char and char-int in SOCKS? > > Because I like to write things that will be reasonably sane looking like > > (if (= (char-int x) 5) > ... > ) That's also OK. William, you're off the hook. You may go home to your wife and child now. Thank you for cooperating. You will receive the bill within a week. :-) From owner-xemacs-beta@xemacs.org Sat Jul 3 18:38:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA25065 for xemacs-beta-out; Sat, 3 Jul 1999 18:38:46 -0400 Received: from goliath.nomad.com (p84cd25.kws2.ap.so-net.ne.jp [210.132.205.37]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA25061 for ; Sat, 3 Jul 1999 18:38:43 -0400 Received: (from fukuda@localhost) by goliath.nomad.com (8.9.3/3.7W1.0) id HAA30568; Sun, 4 Jul 1999 07:38:35 +0900 Date: Sun, 4 Jul 1999 07:38:35 +0900 Message-Id: <199907032238.HAA30568@goliath.nomad.com> From: To: xemacs-beta@xemacs.org Subject: Core Dump 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 (beta17) "Chiyoda" [Lucid] (i586-pc-linux, Mule) of Sat Jul 3 1999 on goliath.nomad.com configured using `configure --with-mule' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: In the Mew application, hit RET while the cursor in summary mode. Recent keystrokes: C-[ x s e n d - SPC RET misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done send-pr: the GNATS site xemacs.org does not have a categories list Loading emacsbug... Loading env...done Loading env... Loading send-pr...done Loading send-pr... Loading japan-util...done Loading japan-util... uname -a: Linux goliath.nomad.com 2.2.9 #2 Wed May 26 10:31:16 JST 1999 i586 unknown ./configure '--with-mule' XEmacs 21.2-b17 "Chiyoda" configured for `i586-pc-linux'. Where should the build process find the source code? /home/fukuda/build/xemacs-21.2.16 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/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. -------------------------------------------------------------------- WARNING: Compiling without PNG image support. Reason: PNG library version too old (pre 1.0.2)! WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) -------------------------------------------------------------------- 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 Canna on Mule. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL 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 Sun Jul 4 02:55:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA13783 for xemacs-beta-out; Sun, 4 Jul 1999 02:55:46 -0400 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 CAA13779 for ; Sun, 4 Jul 1999 02:55:43 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id QAA06558; Sun, 4 Jul 1999 16:01:31 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Athena-3D scrollbars broken in 21.2.17 References: <14199.56377.513923.266915@buffalo.fnal.gov> <14204.55603.312138.545332@buffalo.fnal.gov> X-Attribution: sb From: SL Baur In-Reply-To: Charles G Waldman's message of "Fri, 2 Jul 1999 10:22:27 -0500 (CDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 04 Jul 1999 16:01:30 +0900 Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I just tested a Linux XawXPM build against the latest sources and it works (for me) too. Charles G Waldman writes in xemacs-beta@xemacs.org: > SL Baur writes: >> Charles G Waldman writes in xemacs-beta@xemacs.org: >> >> > Just noticed that if you ./configure --with-scrollbars=athena3d, the >> > resizing of the scrollbar thingamajig (what's the right name for >> > that?) doesn't work. With regular Athena scrollbars it seems OK. >> >> Can you explain this in more detail? >> > I mean the way the size of the scrollbar "thumb" scales to reflect the > ratio (chars visible)/(chars in buffer). With the straight Athena > scrollbars, this works; with XawXpm the scrollbar "thumb" is either > at its minimum size (about 10 pixels high) or at its maximum (filling > the entire available vertical space). That sounds familiar, I don't remember why. It still works for me so there must be something else wrong. Have you tried a `cvs update' and building against the very latest and greatest sources? >> Which version of XawXpm (I don't think it has been updated in quite a >> long time)? > v1.1 That's the same one I'm using. -- $BAkHV9f$rF~NO$7$F$/$@$5$$!#(B (recorded keybox message at ETL) From owner-xemacs-beta@xemacs.org Sun Jul 4 15:12:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05016 for xemacs-beta-out; Sun, 4 Jul 1999 15:12:10 -0400 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 PAA05007; Sun, 4 Jul 1999 15:12:08 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA05703; Sun, 4 Jul 1999 12:11:53 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-222.beasys.com [192.168.11.222]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA23128; Sun, 4 Jul 1999 12:11:46 -0700 (PDT) Message-Id: <3.0.5.32.19990704201155.00b132c0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 04 Jul 1999 20:11:55 +0100 To: xemacs-patches@xemacs.org From: Andy Piper Subject: Fprovide_on_console removed Cc: xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_931111915==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_931111915==_ Content-Type: text/plain; charset="us-ascii" As discussed this has been subsumed by valid-image-instantiator-format-p and friends. I will apply this to cvs. andy 1999-07-04 Andy Piper * console.c: undo earlier Fprovide changes. * fns.c: ditto. * console.h: ditto. * console-tty.c (image_instantiator_format_create_glyphs_tty): new function. validate appropriate image formats for tty. * glyphs.h (INITIALIZE_IMAGE_INSTANTIATOR_FORMAT_NO_SYM): initialize consoles parameter. (struct image_instantiator_methods): add consoles parameter. (IIFORMAT_VALID_CONSOLE): new function. validate the format on the console. (INITIALIZE_DEVICE_IIFORMAT): validate the format on the given console. * glyphs-msw.c: declare instantiators for later use. (image_instantiator_format_create_glyphs_mswindows): validate xpm and friends on the mswindows console. * glyphs-x.c: ditto. * glyphs.c (valid_image_instantiator_format_p): disallow glyphs that have not been registered on the supplied device. (Fvalid_image_instantiator_format_p): add locale argument. (instantiate_image_instantiator): valid image instantiator on the device. * symsinit.h: add image_instantiator_format_create_glyphs_tty() declaration. * emacs.c (main_1): add call to image_instantiator_format_create_glyphs_tty(). 1999-06-29 Andy Piper * event-msw.c: fix definition booboo. 1999-06-28 Andy Piper * glyphs-x.c: change tree -> tree-view, progress -> progress_gauge, edit -> edit-field, tab -> tab-control, combo -> combo-box. (complex_vars_of_glyphs_x): provide-on-console the implemented widget types. * glyphs-msw.c: ditto. (complex_vars_of_glyphs_mswindows): ditto. --=====================_931111915==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable diff -u -r1.111.2.30 configure.in --- configure.in 1999/06/23 12:25:48 1.111.2.30 +++ configure.in 1999/07/04 19:05:11 @@ -362,6 +362,7 @@ with_site_modules=3D'yes' with_menubars=3D'' with_scrollbars=3D'' +with_widgets=3D'' with_dialogs=3D'' with_file_coding=3D'' dnl const_is_losing is removed - we rely on AC_C_CONST instead. @@ -739,7 +740,8 @@ dnl Has the user specified the toolkit(s) to use for GUI elements? "with_menubars" | \ "with_scrollbars" | \ - "with_dialogs" ) + "with_dialogs" | \ + "with_widgets" ) case "$val" in l | lu | luc | luci | lucid ) val=3Dlucid ;; m | mo | mot | moti | motif ) val=3Dmotif ;; @@ -2878,8 +2880,13 @@ case "$with_scrollbars" in "" | "yes" ) with_scrollbars=3D"lucid" ;; esac +case "$with_widgets" in "" | "yes" ) + if test "$have_motif" =3D "yes"; then with_widgets=3D"motif" + else with_widgets=3Dno + fi ;; +esac -all_widgets=3D"$with_menubars $with_scrollbars $with_dialogs= $with_toolbars" +all_widgets=3D"$with_menubars $with_scrollbars $with_dialogs $with_toolbars= $with_widgets" case "$all_widgets" in *athena* ) AC_DEFINE(LWLIB_USES_ATHENA) @@ -2932,7 +2939,7 @@ test "$with_scrollbars" !=3D "no" && XE_ADD_OBJS(scrollbar-x.o) test "$with_dialogs" !=3D "no" && XE_ADD_OBJS(dialog-x.o) test "$with_toolbars" !=3D "no" && XE_ADD_OBJS(toolbar-x.o) - test "$all_widgets" !=3D "no no no no" && XE_ADD_OBJS(gui-x.o) + test "$all_widgets" !=3D "no no no no no" && XE_ADD_OBJS(gui-x.o) else if test \( "$with_sound" =3D "nas" \) -o \( "$with_sound" =3D "both" \);= then echo "Attempt to Build NAS sound without X" Index:= configure.usage =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/configure.usage,v retrieving revision 1.17.2.7 diff -u -r1.17.2.7 configure.usage --- configure.usage 1999/06/23 12:25:49 1.17.2.7 +++ configure.usage 1999/07/04 19:05:14 @@ -66,6 +66,9 @@ --with-dialogs=3DTYPE Use TYPE dialog boxes (motif, athena, athena3d,= or no). Lucid menubars and scrollbars are the default. Motif dialog boxes will be used if Motif can be= found. +--with-widgets=3DTYPE Use TYPE widgets (motif, athena, athena3d, or= no). + Motif widgets will be used if Motif can be found. + Other widget types are currently unsupported. --with-dragndrop (*) Compile in the generic drag and drop API. This is automatically added if one of the drag and drop protocols is found (currently CDE, OffiX,= MSWindows). Index:= src/console-tty.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/console-tty.c,v retrieving revision 1.18.2.2 diff -u -r1.18.2.2 console-tty.c --- src/console-tty.c 1998/12/18 05:42:03 1.18.2.2 +++ src/console-tty.c 1999/07/04 19:05:38 @@ -32,6 +32,7 @@ #include "faces.h" #include "frame.h" #include "lstream.h" +#include "glyphs.h" #include "sysdep.h" #include "sysfile.h" #ifdef FILE_CODING @@ -42,6 +43,10 @@ #endif DEFINE_CONSOLE_TYPE (tty); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (nothing); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (formatted_string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT (inherit); Lisp_Object Qterminal_type; Lisp_Object Qcontrolling_process; @@ -364,6 +369,15 @@ CONSOLE_HAS_METHOD (tty, canonicalize_device_connection); CONSOLE_HAS_METHOD (tty, semi_canonicalize_console_connection); CONSOLE_HAS_METHOD (tty,= semi_canonicalize_device_connection); +} + +void +image_instantiator_format_create_glyphs_tty (void) +{ + IIFORMAT_VALID_CONSOLE (tty, nothing); + IIFORMAT_VALID_CONSOLE (tty, string); + IIFORMAT_VALID_CONSOLE (tty, formatted_string); + IIFORMAT_VALID_CONSOLE (tty, inherit); } void Index:= src/console.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/console.c,v retrieving revision 1.17.2.4 diff -u -r1.17.2.4 console.c --- src/console.c 1999/06/29 14:35:31 1.17.2.4 +++ src/console.c 1999/07/04 19:05:43 @@ -781,14 +781,6 @@ return !EQ (type, Qtty) && !EQ (type, Qstream) ? Qt : Qnil; } -DEFUN ("console-features", Fconsole_features, 0, 1, 0, /* -Return a list of console-specific features. -*/ - (console)) -{ - return CONSOLE_FEATURES (decode_console (console)); -} - =0C /**********************************************************************/ @@ -1087,7 +1079,6 @@ DEFSUBR (Fconsole_enable_input); DEFSUBR (Fconsole_disable_input); DEFSUBR (Fconsole_on_window_system_p); - DEFSUBR (Fconsole_features); DEFSUBR (Fsuspend_console); DEFSUBR (Fresume_console); Index:= src/console.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/console.h,v retrieving revision 1.22.2.6 diff -u -r1.22.2.6 console.h --- src/console.h 1999/06/29 14:35:31 1.22.2.6 +++ src/console.h 1999/07/04 19:05:46 @@ -272,9 +272,6 @@ /* dialog methods */ void (*popup_dialog_box_method) (struct frame *, Lisp_Object dbox_desc); #endif - - /* Console-specific features */ - Lisp_Object features; }; /* @@ -286,9 +283,7 @@ #define CONSOLE_TYPE_NAME(c) ((c)->conmeths->name) #define CONSOLE_TYPE(c) ((c)->conmeths->symbol) -#define CONSOLE_FEATURES(c) ((c)->conmeths->features) #define CONMETH_TYPE(meths) ((meths)->symbol) -#define CONMETH_FEATURES(c) ((meths)->features) /******** Accessing / calling a console method *********/ @@ -354,8 +349,6 @@ add_entry_to_console_type_list (Q##type, type##_console_methods); \ type##_console_methods->image_conversion_list =3D Qnil; \ staticpro (&type##_console_methods->image_conversion_list); \ - type##_console_methods->features =3D Qnil; \ - staticpro (&type##_console_methods->features); \ } while (0) /* Declare that console-type TYPE has method M; used in Index:= src/emacs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.19 diff -u -r1.82.2.19 emacs.c --- src/emacs.c 1999/06/05 08:22:21 1.82.2.19 +++ src/emacs.c 1999/07/04 19:05:53 @@ -1200,6 +1202,9 @@ image_instantiator_format_create (); image_instantiator_format_create_glyphs_eimage (); image_instantiator_format_create_glyphs_widget (); +#ifdef HAVE_TTY + image_instantiator_format_create_glyphs_tty (); +#endif #ifdef HAVE_X_WINDOWS image_instantiator_format_create_glyphs_x (); #endif /* HAVE_X_WINDOWS */ Index:= src/event-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.38.2.14 diff -u -r1.38.2.14 event-msw.c --- src/event-msw.c 1999/06/29 14:35:31 1.38.2.14 +++ src/event-msw.c 1999/07/04 19:06:04 @@ -73,11 +73,7 @@ #include #if defined (__CYGWIN32__) && !defined (CYGWIN_VERSION_DLL_MAJOR) -typedef struct tagNMHDR { - HWND hwndFrom; - UINT idFrom; - UINT code; -} NMHDR, *PNMHDR, *LPNMHDR; +typedef NMHDR *LPNMHDR; #endif #ifdef HAVE_MENUBARS Index:= src/fns.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/fns.c,v retrieving revision 1.30.2.17 diff -u -r1.30.2.17 fns.c --- src/fns.c 1999/06/29 14:35:32 1.30.2.17 +++ src/fns.c 1999/07/04 19:06:13 @@ -3231,7 +3231,7 @@ =0C Lisp_Object Vfeatures; -DEFUN ("featurep", Ffeaturep, 1, 2, 0, /* +DEFUN ("featurep", Ffeaturep, 1, 1, 0, /* Return non-nil if feature FEXP is present in this Emacs. Use this to conditionalize execution of lisp code based on the presence or absence of emacs or environment extensions. @@ -3266,7 +3266,7 @@ for supporting multiple Emacs variants, lobby Richard Stallman at . */ - (fexp, console)) + (fexp)) { #ifndef FEATUREP_SYNTAX CHECK_SYMBOL (fexp); @@ -3278,11 +3278,7 @@ if (SYMBOLP (fexp)) { /* Original definition */ - return (NILP (Fmemq (fexp, Vfeatures)) - && - NILP (Fmemq (fexp, - CONSOLE_FEATURES (decode_console (console))))) - ? Qnil : Qt; + return NILP (Fmemq (fexp, Vfeatures)) ? Qnil : Qt; } else if (INTP (fexp) || FLOATP (fexp)) { @@ -3351,7 +3347,6 @@ CHECK_SYMBOL (feature); if (!NILP (Vautoload_queue)) Vautoload_queue =3D Fcons (Fcons (Vfeatures, Qnil),= Vautoload_queue); - tem =3D Fmemq (feature, Vfeatures); if (NILP (tem)) Vfeatures =3D Fcons (feature, Vfeatures); @@ -3359,38 +3354,6 @@ return feature; } -DEFUN ("provide-on-console", Fprovide_on_console, 2, 2, 0, /* -Announce that FEATURE is a feature of the current Emacs. -This function updates the value of `console-features' for the provided= CONSOLE. -*/ - (feature, console)) -{ - Lisp_Object tem; - CHECK_SYMBOL (feature); - - if (SYMBOLP (console)) - { - struct console_methods* meths =3D decode_console_type (console,= ERROR_ME); - - tem =3D Fmemq (feature, CONMETH_FEATURES (meths)); - if (NILP (tem)) - CONMETH_FEATURES (meths) =3D - Fcons (feature, CONMETH_FEATURES (meths)); - } - else - { - struct console* pconsole; - CHECK_CONSOLE (console); - - pconsole =3D decode_console (console); - tem =3D Fmemq (feature, CONSOLE_FEATURES (pconsole)); - if (NILP (tem)) - CONSOLE_FEATURES (pconsole) =3D - Fcons (feature, CONSOLE_FEATURES (pconsole)); - } - return feature; -} - DEFUN ("require", Frequire, 1, 2, 0, /* If feature FEATURE is not loaded, load it from FILENAME. If FEATURE is not a member of the list `features', then the feature @@ -3403,10 +3366,7 @@ CHECK_SYMBOL (feature); tem =3D Fmemq (feature, Vfeatures); LOADHIST_ATTACH (Fcons (Qrequire, feature)); - if (!NILP (tem) - || - !NILP (Fmemq (feature, CONSOLE_FEATURES - (XCONSOLE (Fselected_console ()))))) + if (!NILP (tem)) return feature; else =20 { @@ -3917,7 +3877,6 @@ DEFSUBR (Ffeaturep); DEFSUBR (Frequire); DEFSUBR (Fprovide); - DEFSUBR (Fprovide_on_console); DEFSUBR (Fbase64_encode_region); DEFSUBR (Fbase64_encode_string); DEFSUBR (Fbase64_decode_region); Index:= src/glyphs-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-msw.c,v retrieving revision 1.21.2.17 diff -u -r1.21.2.17 glyphs-msw.c --- src/glyphs-msw.c 1999/06/29 14:35:32 1.21.2.17 +++ src/glyphs-msw.c 1999/07/04 19:06:25 @@ -1,5 +1,5 @@ /* mswindows-specific glyph objects. - Copyright (C) 1998 Andy Piper. + Copyright (C) 1998, 99 Andy Piper. This file is part of XEmacs. @@ -53,6 +53,22 @@ #define WIDGET_GLYPH_SLOT 0 +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (nothing); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (formatted_string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT (inherit); +#ifdef HAVE_JPEG +DECLARE_IMAGE_INSTANTIATOR_FORMAT (jpeg); +#endif +#ifdef HAVE_TIFF +DECLARE_IMAGE_INSTANTIATOR_FORMAT (tiff); +#endif +#ifdef HAVE_PNG +DECLARE_IMAGE_INSTANTIATOR_FORMAT (png); +#endif +#ifdef HAVE_GIF +DECLARE_IMAGE_INSTANTIATOR_FORMAT (gif); +#endif #ifdef HAVE_XPM DEFINE_DEVICE_IIFORMAT (mswindows, xpm); #endif @@ -2728,6 +2744,10 @@ void image_instantiator_format_create_glyphs_mswindows (void) { + IIFORMAT_VALID_CONSOLE (mswindows, nothing); + IIFORMAT_VALID_CONSOLE (mswindows, string); + IIFORMAT_VALID_CONSOLE (mswindows, formatted_string); + IIFORMAT_VALID_CONSOLE (mswindows, inherit); /* image-instantiator types */ #ifdef HAVE_XPM INITIALIZE_DEVICE_IIFORMAT (mswindows, xpm); @@ -2739,6 +2759,18 @@ INITIALIZE_DEVICE_IIFORMAT (mswindows, xface); IIFORMAT_HAS_DEVMETHOD (mswindows, xface, instantiate); #endif +#ifdef HAVE_JPEG + IIFORMAT_VALID_CONSOLE (mswindows, jpeg); +#endif +#ifdef HAVE_TIFF + IIFORMAT_VALID_CONSOLE (mswindows, tiff); +#endif +#ifdef HAVE_PNG + IIFORMAT_VALID_CONSOLE (mswindows, png); +#endif +#ifdef HAVE_GIF + IIFORMAT_VALID_CONSOLE (mswindows, gif); +#endif /* button widget */ INITIALIZE_DEVICE_IIFORMAT (mswindows, button); IIFORMAT_HAS_DEVMETHOD (mswindows, button, property); @@ -2793,6 +2825,7 @@ IIFORMAT_VALID_KEYWORD (bmp, Q_data, check_valid_string); IIFORMAT_VALID_KEYWORD (bmp, Q_file, check_valid_string); + IIFORMAT_VALID_CONSOLE (mswindows, bmp); /* mswindows resources */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (mswindows_resource, @@ -2807,6 +2840,7 @@ check_valid_resource_symbol); IIFORMAT_VALID_KEYWORD (mswindows_resource, Q_resource_id,= check_valid_resource_id); IIFORMAT_VALID_KEYWORD (mswindows_resource, Q_file,= check_valid_string); + IIFORMAT_VALID_CONSOLE (mswindows, mswindows_resource); } void @@ -2822,14 +2856,4 @@ void complex_vars_of_glyphs_mswindows (void) { - Fprovide_on_console (Qbmp, Qmswindows); - Fprovide_on_console (Qmswindows_resource, Qmswindows); - Fprovide_on_console (Qbutton, Qmswindows); - Fprovide_on_console (Qedit_field, Qmswindows); - Fprovide_on_console (Qcombo_box, Qmswindows); - Fprovide_on_console (Qscrollbar, Qmswindows); - Fprovide_on_console (Qlabel, Qmswindows); - Fprovide_on_console (Qprogress_gauge, Qmswindows); - Fprovide_on_console (Qtree_view, Qmswindows); - Fprovide_on_console (Qtab_control, Qmswindows); } Index:= src/glyphs-x.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-x.c,v retrieving revision 1.49.2.11 diff -u -r1.49.2.11 glyphs-x.c --- src/glyphs-x.c 1999/06/29 14:35:33 1.49.2.11 +++ src/glyphs-x.c 1999/07/04 19:06:31 @@ -4,6 +4,7 @@ Copyright (C) 1995 Tinker Systems Copyright (C) 1995, 1996 Ben Wing Copyright (C) 1995 Sun Microsystems + Copyright (C) 1999 Andy Piper This file is part of XEmacs. @@ -89,6 +90,22 @@ #define LISP_DEVICE_TO_X_SCREEN(dev) XDefaultScreenOfDisplay= (DEVICE_X_DISPLAY (XDEVICE (dev))) +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (nothing); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT= (formatted_string); +DECLARE_IMAGE_INSTANTIATOR_FORMAT (inherit); +#ifdef HAVE_JPEG +DECLARE_IMAGE_INSTANTIATOR_FORMAT (jpeg); +#endif +#ifdef HAVE_TIFF +DECLARE_IMAGE_INSTANTIATOR_FORMAT (tiff); +#endif +#ifdef HAVE_PNG +DECLARE_IMAGE_INSTANTIATOR_FORMAT (png); +#endif +#ifdef HAVE_GIF +DECLARE_IMAGE_INSTANTIATOR_FORMAT (gif); +#endif #ifdef HAVE_XPM DEFINE_DEVICE_IIFORMAT (x, xpm); #endif @@ -2411,10 +2428,26 @@ void image_instantiator_format_create_glyphs_x (void) { + IIFORMAT_VALID_CONSOLE (x, nothing); + IIFORMAT_VALID_CONSOLE (x, string); + IIFORMAT_VALID_CONSOLE (x, formatted_string); + IIFORMAT_VALID_CONSOLE (x, inherit); #ifdef HAVE_XPM INITIALIZE_DEVICE_IIFORMAT (x, xpm); IIFORMAT_HAS_DEVMETHOD (x, xpm, instantiate); #endif +#ifdef HAVE_JPEG + IIFORMAT_VALID_CONSOLE (x, jpeg); +#endif +#ifdef HAVE_TIFF + IIFORMAT_VALID_CONSOLE (x, tiff); +#endif +#ifdef HAVE_PNG + IIFORMAT_VALID_CONSOLE (x, png); +#endif +#ifdef HAVE_GIF + IIFORMAT_VALID_CONSOLE (x, gif); +#endif INITIALIZE_DEVICE_IIFORMAT (x, xbm); IIFORMAT_HAS_DEVMETHOD (x, xbm, instantiate); @@ -2441,6 +2474,7 @@ IIFORMAT_HAS_DEVMETHOD (x, combo_box, instantiate); INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (cursor_font, "cursor-font"); + IIFORMAT_VALID_CONSOLE (x, cursor_font); IIFORMAT_HAS_METHOD (cursor_font, validate); IIFORMAT_HAS_METHOD (cursor_font, possible_dest_types); @@ -2455,6 +2489,7 @@ IIFORMAT_HAS_METHOD (font, validate); IIFORMAT_HAS_METHOD (font, possible_dest_types); IIFORMAT_HAS_METHOD (font, instantiate); + IIFORMAT_VALID_CONSOLE (x, font); IIFORMAT_VALID_KEYWORD (font, Q_data, check_valid_string); IIFORMAT_VALID_KEYWORD (font, Q_foreground, check_valid_string); @@ -2472,6 +2507,7 @@ IIFORMAT_HAS_METHOD (autodetect, normalize); IIFORMAT_HAS_METHOD (autodetect, possible_dest_types); IIFORMAT_HAS_METHOD (autodetect, instantiate); + IIFORMAT_VALID_CONSOLE (x, autodetect); IIFORMAT_VALID_KEYWORD (autodetect, Q_data, check_valid_string); } @@ -2508,8 +2544,4 @@ BUILD_GLYPH_INST (Vhscroll_glyph, hscroll); #undef BUILD_GLYPH_INST - Fprovide_on_console (Qbutton, Qx); - Fprovide_on_console (Qedit_field, Qx); - Fprovide_on_console (Qprogress_gauge, Qx); - /* Fprovide (Qcombo_box);*/ } Index:= src/glyphs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v retrieving revision 1.23.2.14 diff -u -r1.23.2.14 glyphs.c --- src/glyphs.c 1999/06/23 19:52:45 1.23.2.14 +++ src/glyphs.c 1999/07/04 19:06:41 @@ -174,21 +174,38 @@ } static int -valid_image_instantiator_format_p (Lisp_Object= format) +valid_image_instantiator_format_p (Lisp_Object format, Lisp_Object locale) { - return (decode_image_instantiator_format (format, ERROR_ME_NOT) !=3D= 0); + int i; + struct image_instantiator_methods* meths =3D + decode_image_instantiator_format (format, ERROR_ME_NOT); + struct console* console =3D decode_console (locale); + Lisp_Object contype =3D console ? CONSOLE_TYPE (console) : locale; + /* nothing is valid in all locales */ + if (EQ (format, Qnothing)) + return 1; + /* reject unknown formats */ + else if (!console || !meths) + return 0; + + for (i =3D 0; i < Dynarr_length (meths->consoles); i++) + if (EQ (contype, Dynarr_at (meths->consoles, i).symbol)) + return 1; + return 0; } DEFUN ("valid-image-instantiator-format-p",= Fvalid_image_instantiator_format_p, - 1, 1, 0, /* + 1, 2, 0, /* Given an IMAGE-INSTANTIATOR-FORMAT, return non-nil if it is valid. +If LOCALE is non-nil then the format is checked in that domain. +If LOCALE is nil the current console is used. Valid formats are some subset of 'nothing, 'string, 'formatted-string, 'xpm, 'xbm, 'xface, 'gif, 'jpeg, 'png, 'tiff, 'cursor-font, 'font, 'autodetect, 'widget and 'subwindow, depending on how XEmacs was compiled. */ - (image_instantiator_format)) + (image_instantiator_format, locale)) { - return valid_image_instantiator_format_p (image_instantiator_format) ? + return valid_image_instantiator_format_p (image_instantiator_format,= locale) ? Qt : Qnil; } @@ -547,6 +564,11 @@ int methp =3D 0; GCPRO1 (ii); + if (!valid_image_instantiator_format_p (XVECTOR_DATA (instantiator)[0],= device)) + signal_simple_error + ("Image instantiator format is invalid in this locale.", + instantiator); + meths =3D decode_image_instantiator_format (XVECTOR_DATA= (instantiator)[0], ERROR_ME); methp =3D (int)HAS_IIFORMAT_METH_P (meths, instantiate); @@ -4107,7 +4129,6 @@ IIFORMAT_HAS_METHOD (formatted_string, validate); IIFORMAT_HAS_METHOD (formatted_string, possible_dest_types); IIFORMAT_HAS_METHOD (formatted_string, instantiate); - IIFORMAT_VALID_KEYWORD (formatted_string, Q_data, check_valid_string); /* subwindows */ Index:= src/glyphs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.h,v retrieving revision 1.18.2.12 diff -u -r1.18.2.12 glyphs.h --- src/glyphs.h 1999/06/29 14:35:34 1.18.2.12 +++ src/glyphs.h 1999/07/04 19:06:43 @@ -85,6 +85,8 @@ Lisp_Object device; /* sometimes used */ ii_keyword_entry_dynarr *keywords; + /* consoles this ii is supported on */ + console_type_entry_dynarr *consoles; /* Implementation specific methods: */ /* Validate method: Given an instantiator vector, signal an error if @@ -170,6 +172,8 @@ format##_image_instantiator_methods->device =3D Qnil; \ format##_image_instantiator_methods->keywords =3D \ Dynarr_new (ii_keyword_entry); \ + format##_image_instantiator_methods->consoles =3D \ + Dynarr_new (console_type_entry); \ add_entry_to_image_instantiator_format_list \ (Q##format, format##_image_instantiator_methods); \ } while (0) @@ -215,7 +219,20 @@ =09 entry); \ } while (0) +/* Declare that image-instantiator format FORMAT is supported on + CONSOLE type. */ +#define IIFORMAT_VALID_CONSOLE(console, format) \ + do { \ + struct console_type_entry entry; \ + \ + entry.symbol =3D Q##console; \ + entry.meths =3D console##_console_methods; \ + Dynarr_add= (format##_image_instantiator_methods->consoles, \ + entry); \ + } while (0) + #define DEFINE_DEVICE_IIFORMAT(type,= format)\ +DECLARE_IMAGE_INSTANTIATOR_FORMAT(format); \ struct image_instantiator_methods= *type##_##format##_image_instantiator_methods #define INITIALIZE_DEVICE_IIFORMAT(type, format) \ @@ -228,6 +245,7 @@ Dynarr_new (ii_keyword_entry); \ add_entry_to_device_ii_format_list \ (Q##type, Q##format, type##_##format##_image_instantiator_methods); \ + IIFORMAT_VALID_CONSOLE(type,format); \ } while (0) /* Declare that image-instantiator format FORMAT has method M; used= in Index:= src/lisp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp.h,v retrieving revision 1.38.2.16 diff -u -r1.38.2.16 lisp.h --- src/lisp.h 1999/06/29 14:35:34 1.38.2.16 +++ src/lisp.h 1999/07/04 19:06:54 @@ -2739,7 +2739,6 @@ EXFUN (Fprocess_status, 1); EXFUN (Fprogn, UNEVALLED); EXFUN (Fprovide, 1); -EXFUN (Fprovide_on_console, 2); EXFUN (Fpurecopy, 1); EXFUN (Fput, 3); EXFUN (Fput_range_table, 4); Index:= src/symsinit.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/symsinit.h,v retrieving revision 1.31.2.6 diff -u -r1.31.2.6 symsinit.h --- src/symsinit.h 1999/06/03 07:53:04 1.31.2.6 +++ src/symsinit.h 1999/07/04 19:06:58 @@ -200,6 +202,7 @@ void image_instantiator_format_create_glyphs_widget (void); void image_instantiator_format_create_glyphs_x (void); void image_instantiator_format_create_glyphs_mswindows (void); +void image_instantiator_format_create_glyphs_tty (void); /* Initialize the lstream types (dump-time only). */ --=====================_931111915==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_931111915==_-- From owner-xemacs-beta@xemacs.org Sun Jul 4 15:25:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05500 for xemacs-beta-out; Sun, 4 Jul 1999 15:25:58 -0400 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 PAA05493; Sun, 4 Jul 1999 15:25:57 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA05849; Sun, 4 Jul 1999 12:25:42 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-221.beasys.com [192.168.11.221]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA23882; Sun, 4 Jul 1999 12:25:40 -0700 (PDT) Message-Id: <3.0.5.32.19990704202549.00aaf130@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 04 Jul 1999 20:25:49 +0100 To: xemacs-review@xemacs.org From: Andy Piper Subject: CVS, what gives? Cc: xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: CVS is telling me that all XEmacs files have been deleted. I trust this is not so. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sun Jul 4 16:19:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA07274 for xemacs-beta-out; Sun, 4 Jul 1999 16:19:08 -0400 Received: from smtp01.highway.ne.jp (smtp01.highway.ne.jp [210.159.117.14]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA07268; Sun, 4 Jul 1999 16:19:03 -0400 Received: from 210.166.107.188 (x52-188.atsuta.highway.ne.jp [210.166.107.188]) by smtp01.highway.ne.jp (8.9.1a/3.7W99052817) with SMTP id FAA06771; Mon, 5 Jul 1999 05:18:59 +0900 (JST) Message-Id: <19990705051424.Postino-023461@smtp01.highway.ne.jp> Date: Mon, 5 Jul 1999 05:14:24 +0900 To: SL Baur , xemacs-beta@xemacs.org From: Kaoru Fukui Subject: perl is old place /usr/local/bin/perl in bbdb X-Mailer: PostinoClassic Version 1.3 PPC X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==_Boundary-5714_==" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Boundary-5714_== Content-Type: text/plain; charset=us-ascii Hi! I'm appricate your good work. I haven,t seen for a long time. Yesterday I have successful building xemacs-21.1.3 on my machine. I use glibc-2.1.2 on MkLinux powermac-6100. Then I wish to fix perl's place moving to /usr/bin. When i make rpm package I think so every time. Here is the patch --==_Boundary-5714_== Content-Type: application/octet-stream; name="xemacs-sumo-bbdb.patch" ; x-mac-type="54455854" ; x-mac-creator="522a6368" Content-Disposition: attachment; filename="xemacs-sumo-bbdb.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdSB4ZW1hY3MtcGFja2FnZXMvZXRjL2JiZGIub3JpZy9iYmRiLWNpZC5wbCB4ZW1h Y3MtcGFja2FnZXMvZXRjL2JiZGIvYmJkYi1jaWQucGwKLS0tIHhlbWFjcy1wYWNrYWdlcy9l dGMvYmJkYi5vcmlnL2JiZGItY2lkLnBsCVRodSBEZWMgMTAgMDU6MjU6NDggMTk5OAorKysg eGVtYWNzLXBhY2thZ2VzL2V0Yy9iYmRiL2JiZGItY2lkLnBsCUZyaSBKdW4gMjUgMTM6MjY6 NTcgMTk5OQpAQCAtMSw0ICsxLDQgQEAKLSMhL3Vzci9sb2NhbC9iaW4vcGVybDUgLXcKKyMh L3Vzci9iaW4vcGVybCAtdwogIwogIyBDYWxsZXItSUQtbG9nZ2VyLCBieSBqd3ogKDE5LUph bi05NykKICMgTW9kaWZpZWQ6IDI0LUFwci05NwpkaWZmIC11IHhlbWFjcy1wYWNrYWdlcy9l dGMvYmJkYi5vcmlnL2JiZGItc3J2LnBsIHhlbWFjcy1wYWNrYWdlcy9ldGMvYmJkYi9iYmRi LXNydi5wbAotLS0geGVtYWNzLXBhY2thZ2VzL2V0Yy9iYmRiLm9yaWcvYmJkYi1zcnYucGwJ VGh1IERlYyAxMCAwNToyNTo0OCAxOTk4CisrKyB4ZW1hY3MtcGFja2FnZXMvZXRjL2JiZGIv YmJkYi1zcnYucGwJRnJpIEp1biAyNSAxMzoyNzoxNiAxOTk5CkBAIC0xLDQgKzEsNCBAQAot IyEvdXNyL2xvY2FsL2Jpbi9wZXJsCisjIS91c3IvYmluL3BlcmwKIAogIyBUaGlzIHNjcmlw dCByZWFkcyBhIGJsb2NrIG9mIG1lc3NhZ2UgaGVhZGVycyBvbiBzdGRpbiwgYW5kIGNvbnZl cnRzIHRoZW0KICMgdG8gYW4gZW1hY3MtbGlzcCBzdHJpbmcgKHF1b3RpbmcgIGFsbCBkYW5n ZXJvdXMgY2hhcmFjdGVycykgYW5kIHRoZW4gCmRpZmYgLXUgeGVtYWNzLXBhY2thZ2VzL2V0 Yy9iYmRiLm9yaWcvYmJkYi11bmxhenktbG9jay5wbCB4ZW1hY3MtcGFja2FnZXMvZXRjL2Ji ZGIvYmJkYi11bmxhenktbG9jay5wbAotLS0geGVtYWNzLXBhY2thZ2VzL2V0Yy9iYmRiLm9y aWcvYmJkYi11bmxhenktbG9jay5wbAlUaHUgRGVjIDEwIDA1OjI1OjQ5IDE5OTgKKysrIHhl bWFjcy1wYWNrYWdlcy9ldGMvYmJkYi9iYmRiLXVubGF6eS1sb2NrLnBsCUZyaSBKdW4gMjUg MTM6Mjc6MjUgMTk5OQpAQCAtMSw0ICsxLDQgQEAKLSMhL3Vzci9sb2NhbC9iaW4vcGVybAor IyEvdXNyL2Jpbi9wZXJsCiAjCiAjIEF1dGhvcjogQ2hyaXN0b3BoZXIgS2xpbmUgPGNrbGlu ZUBtZWRpYS5taXQuZWR1PgogIwpDb21tb24gc3ViZGlyZWN0b3JpZXM6IHhlbWFjcy1wYWNr YWdlcy9ldGMvYmJkYi5vcmlnL3RleCBhbmQgeGVtYWNzLXBhY2thZ2VzL2V0Yy9iYmRiL3Rl eAo= --==_Boundary-5714_== Content-Type: text/plain; charset=us-ascii Thanks Kaoru Fukui fukui@ppc.linux.or.jp --==_Boundary-5714_==-- From owner-xemacs-beta@xemacs.org Sun Jul 4 22:23:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA19333 for xemacs-beta-out; Sun, 4 Jul 1999 22:23:20 -0400 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 WAA19330 for ; Sun, 4 Jul 1999 22:23:16 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id LAA06869; Mon, 5 Jul 1999 11:29:03 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: CVS, what gives? References: <3.0.5.32.19990704202549.00aaf130@london.beasys.com> X-Attribution: sb From: SL Baur In-Reply-To: Andy Piper's message of "Sun, 04 Jul 1999 20:25:49 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 05 Jul 1999 11:29:02 +0900 Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes in xemacs-beta@xemacs.org: > CVS is telling me that all XEmacs files have been deleted. I trust this is > not so. Nope. Maybe something is wonky with your environment? $ cvs commit -m "Fix report-bug menuitem" lisp/menubar-items.el lisp/ChangeLog **** Access allowed: Personal Karma exceeds Environmental Karma. Checking in lisp/menubar-items.el; /usr/CVSroot/XEmacs/xemacs/lisp/menubar-items.el,v <-- menubar-items.el new revision: 1.6.2.10; previous revision: 1.6.2.9 done Checking in lisp/ChangeLog; /usr/CVSroot/XEmacs/xemacs/lisp/ChangeLog,v <-- ChangeLog new revision: 1.156.2.111; previous revision: 1.156.2.110 done $ -- $BI,MW$OH/L@$NJl(B (Necessity is the mother of invention) From owner-xemacs-beta@xemacs.org Mon Jul 5 03:21:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA31906 for xemacs-beta-out; Mon, 5 Jul 1999 03:21:48 -0400 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 DAA31900; Mon, 5 Jul 1999 03:21:41 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id AAA13341; Mon, 5 Jul 1999 00:21:24 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-182.beasys.com [192.168.11.182]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id AAA00459; Mon, 5 Jul 1999 00:21:12 -0700 (PDT) Message-Id: <3.0.5.32.19990705082113.00b20250@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 05 Jul 1999 08:21:13 +0100 To: SL Baur , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: CVS, what gives? In-Reply-To: References: <3.0.5.32.19990704202549.00aaf130@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:29 AM 7/5/99 +0900, SL Baur wrote: >Andy Piper writes in xemacs-beta@xemacs.org: > >> CVS is telling me that all XEmacs files have been deleted. I trust this is >> not so. > >Nope. Maybe something is wonky with your environment? I get the problem when I don't specify the release tag. But I shouldn't have to do this. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 5 03:32:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA32590 for xemacs-beta-out; Mon, 5 Jul 1999 03:32:11 -0400 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 DAA32579 for ; Mon, 5 Jul 1999 03:32:07 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id QAA08679; Mon, 5 Jul 1999 16:37:53 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: CVS, what gives? References: <3.0.5.32.19990704202549.00aaf130@london.beasys.com> <3.0.5.32.19990705082113.00b20250@london.beasys.com> X-Attribution: sb From: SL Baur In-Reply-To: Andy Piper's message of "Mon, 05 Jul 1999 08:21:13 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 05 Jul 1999 16:37:52 +0900 Message-ID: Lines: 60 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes in xemacs-beta@xemacs.org: > At 11:29 AM 7/5/99 +0900, SL Baur wrote: >> Andy Piper writes in xemacs-beta@xemacs.org: >> >>> CVS is telling me that all XEmacs files have been deleted. I trust this is >>> not so. >> >> Nope. Maybe something is wonky with your environment? > I get the problem when I don't specify the release tag. But I shouldn't > have to do this. That is correct. Do the files in CVS/ look correct? I see something like: $ lf CVS Entries Repository Root Tag $ cat CVS/Entries /.cvsignore/1.2.2.1/Thu Mar 4 16:00:29 1999/-ko/Trelease-21-2 /BUGS/1.2/Fri Mar 28 02:27:55 1997/-ko/Trelease-21-2 /COPYING/1.1.1.1/Wed Dec 18 22:42:14 1996/-ko/Trelease-21-2 /GETTING.GNU.SOFTWARE/1.1.1.1/Wed Dec 18 22:42:14 1996/-ko/Trelease-21-2 /PROBLEMS/1.26.2.11/Tue Mar 2 10:23:13 1999/-ko/Trelease-21-2 /README/1.10.2.1/Sun Jul 12 09:55:11 1998/-ko/Trelease-21-2 /aclocal.m4/1.2.2.2/Thu May 6 21:50:19 1999/-ko/Trelease-21-2 /config.guess/1.2.2.2/Sat Dec 5 16:54:01 1998/-ko/Trelease-21-2 /config.sub/1.2.2.2/Sat Dec 5 16:54:03 1998/-ko/Trelease-21-2 /install.sh/1.1.1.1/Wed Dec 18 22:42:15 1996/-ko/Trelease-21-2 /move-if-change/1.1.1.1/Wed Dec 18 22:42:15 1996/-ko/Trelease-21-2 /version.sh/1.111.2.35/Tue Jun 22 04:35:47 1999/-ko/Trelease-21-2 D/dynodump//// D/etc//// D/info//// D/lib-src//// D/lisp//// D/lock//// D/lwlib//// D/man//// D/modules//// D/nt//// D/src//// D/tests//// /INSTALL/1.21.2.5/Wed Jun 23 08:15:08 1999/-ko/Trelease-21-2 /Makefile.in.in/1.1.2.7/Wed Jun 23 08:15:08 1999/-ko/Trelease-21-2 /configure.usage/1.17.2.7/Wed Jun 23 08:15:08 1999/-ko/Trelease-21-2 /README.packages/1.1.2.6/Fri Jun 25 06:07:38 1999/-ko/Trelease-21-2 /CHANGES-beta/1.153.2.63/Thu Jul 1 05:39:00 1999/-ko/Trelease-21-2 /ChangeLog/1.155.2.60/Result of merge/-ko/Trelease-21-2 /configure/1.110.2.29/Mon Jul 5 02:56:16 1999/-ko/Trelease-21-2 /configure.in/1.111.2.31/Result of merge/-ko/Trelease-21-2 $ cat CVS/Repository /usr/CVSroot/XEmacs/xemacs $ cat CVS/Root :ext:steveb@cvs.xemacs.org:/usr/CVSroot $ cat CVS/Tag Trelease-21-2 $ -- $BMn2V;^$K5"$i$:GK6@:F$S>H$i$5$:(B (Don't cry over spilled milk) From owner-xemacs-beta@xemacs.org Mon Jul 5 05:38:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA06202 for xemacs-beta-out; Mon, 5 Jul 1999 05:38:17 -0400 Received: from boffi95.stru.polimi.it (boffi95.stru.polimi.it [131.175.24.94]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA06197 for ; Mon, 5 Jul 1999 05:38:14 -0400 Received: (from jim@localhost) by boffi95.stru.polimi.it (8.9.3/8.9.3) id LAA01515; Mon, 5 Jul 1999 11:37:44 +0200 From: giacomo boffi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14208.31975.238520.803730@boffi95.stru.polimi.it> Date: Mon, 5 Jul 1999 11:37:43 +0200 (CEST) To: xemacs-beta@xemacs.org Subject: finder-commentary doesn't works with compressed files X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Reply-To: giacomo.boffi@polimi.it Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: starting from C-h p (finder-by-keyword), if i first select a keyword, and then i select, with button2, a library description, i get the following: Signaling: (error "Can't find any Commentary section") signal(error ("Can't find any Commentary section")) cerror("Can't find any Commentary section") apply(cerror "Can't find any Commentary section") error("Can't find any Commentary section") finder-commentary("lisp-mnt.el") finder-select() finder-mouse-select(#) call-interactively(finder-mouse-select) i have all my .el sources gzipped, so i i tried to uncompress the relevant source file, to find that finder-commentary works fine apparently, finder-commentary works fine with uncompressed sources only From owner-xemacs-beta@xemacs.org Mon Jul 5 06:36:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08730 for xemacs-beta-out; Mon, 5 Jul 1999 06:36:21 -0400 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA08722; Mon, 5 Jul 1999 06:36:18 -0400 Received: from dsl.eng.cam.ac.uk (via root@dsl.eng.cam.ac.uk [129.169.81.1]) by spanner.eng.cam.ac.uk with ESMTP id LAA19189; Mon, 5 Jul 1999 11:36:17 +0100 (BST) Received: from sippi.eng.cam.ac.uk (via ge204@sippi.eng.cam.ac.uk [129.169.81.68]) by dsl.eng.cam.ac.uk with ESMTP id LAA21585; Mon, 5 Jul 1999 11:36:16 +0100 Received: (via ge204@localhost) by sippi.eng.cam.ac.uk id LAA14792; Mon, 5 Jul 1999 11:36:15 +0100 To: xemacs-beta@xemacs.org Cc: xemacs-patches@xemacs.org Subject: Re: zombies on Solaris 2.5[.1] with 21.1.3 References: From: Gunnar Evermann In-Reply-To: Jan Vroonhof's message of "28 Jun 1999 15:48:35 +0200" Date: 05 Jul 1999 11:36:15 +0100 Message-ID: Lines: 64 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) 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: Jan Vroonhof writes: > If I recall correctly there have been similar problems on AIX. > > Not sure. Does anybody every use tooltalk nowadays? Workshop now uses > this eserve stuff which is completely different isn't it? yes, but I think eserve still depends on tooltalk (somehow), could be wrong though. anyway here's a patch. I think on all platforms that have tooltalk POSIX signals are supported, so this should be ok on all of them. 1999-07-03 Gunnar Evermann * tooltalk.c (init_tooltalk): save signal actions for SIGQUIT, SIGINT and SIGCHLD before calling tt_open and restore the afterwards. This fixes e.g. the zombie subprocesses on Solaris Index: src/tooltalk.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/tooltalk.c,v retrieving revision 1.13.2.2 diff -u -r1.13.2.2 tooltalk.c --- tooltalk.c 1999/04/22 07:27:29 1.13.2.2 +++ tooltalk.c 1999/07/05 10:17:40 @@ -1256,7 +1256,28 @@ Lisp_Object lp; Lisp_Object fil; + + /* tt_open() messes with our signal handler flags (at least when no + ttsessions is running on the machine), therefore we save the + actions and restore them after the call */ +#ifdef HAVE_SIGPROCMASK + { + struct sigaction ActSIGQUIT; + struct sigaction ActSIGINT; + struct sigaction ActSIGCHLD; + sigaction (SIGQUIT, NULL, &ActSIGQUIT); + sigaction (SIGINT, NULL, &ActSIGINT); + sigaction (SIGCHLD, NULL, &ActSIGCHLD); +#endif retval = tt_open (); +#ifdef HAVE_SIGPROCMASK + sigaction (SIGQUIT, &ActSIGQUIT, NULL); + sigaction (SIGINT, &ActSIGINT, NULL); + sigaction (SIGCHLD, &ActSIGCHLD, NULL); + } +#endif + + if (tt_ptr_error (retval) != TT_OK) return; -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University From owner-xemacs-beta@xemacs.org Mon Jul 5 12:30:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA25488 for xemacs-beta-out; Mon, 5 Jul 1999 12:30:54 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA25484 for ; Mon, 5 Jul 1999 12:30:52 -0400 Received: from metheny.enst.fr (nDX+WpdnZ0DCad8CD4fWt/w21JvoNkd1@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id SAA12171 for ; Mon, 5 Jul 1999 18:30:50 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id SAA18388; Mon, 5 Jul 1999 18:30:47 +0200 (MET DST) To: Xemacs Beta Testers Subject: [RFC] the rectangle functions 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 Mail-Copies-To: never 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: 136 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Since I've been using whitespace.el, I've noticed that most of the rectangle functions are very intrusive: they put whitespaces in unexpected places. The reasons are: 1/ move-to-column doesn't make any difference between converting a tab into space and adding spaces at the end of a line. This is now fixed. 2/ operate-on-rectangle does too much blind work, notably messing with the end of the line even for functions like string-rectangle which shouldn't be concerned. So I've rewritten rect.el to correct these problems. The rectangle functions now avoid inserting spaces in unwanted places, unless a prefix is given for some of them, in which case the old behavior is (sort of) used. Here are examples of the differences, if anybody wants to comment the changes I propose. There's notably something on which I'm not completely decided yet: for the functions with a prefix, we could push even farther the choice: - don't add unnecessary blanks at all (no prefix) - add blanks on non empty lines only - add blanks blindly (current prefix meaning) Given a rectangle on the following lines, corners are noted with `*' (white spaces are converted to underscores): 123*45 1234 123 12 12345678*90 delete-rectangle: ================ old one / new one with a prefix: ------------------------------- 123 123 123 12_ ___ 12390 new one without prefix: ---------------------- 123 123 123 12 12390 open-rectangle: ============== old one: ------- 123_____45 123_____4 123_____ 12_____ _____ 123_____4567890 new one with a prefix: --------------------- 123_____45 123_____4 123_____ 12______ ________ 123_____4567890 new one without prefix: ---------------------- 123_____45 123_____4 123 12 123_____4567890 string-rectangle ("***"): ======================== old one: ------- 123***45_____ 123***4_ 123***_____ 12 ***_____ ***_____ 123***4567890 new one: ------- 123***45 123***4 123*** 12 *** *** 123***4567890 clear-rectangle: =============== old one / new one with a prefix: ------------------------------- 123_____ 123_____ 123_____ 12______ ________ 123_____90 new one without prefix: ------------------------ 123 123 123 12 123_____90 -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Mon Jul 5 12:51:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26199 for xemacs-beta-out; Mon, 5 Jul 1999 12:51:05 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA26195 for ; Mon, 5 Jul 1999 12:51:03 -0400 Received: from kramer.bp.aventail.com (wmperry@usrpri2-44.kiva.net [206.97.75.109]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id JAA23271 for ; Mon, 5 Jul 1999 09:49:45 -0700 (PDT) Received: (from wmperry@localhost) by kramer.bp.aventail.com (8.9.3/8.9.3) id LAA07125; Mon, 5 Jul 1999 11:49:42 -0500 To: Xemacs Beta Testers Subject: Re: [RFC] the rectangle functions References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 28 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2(beta14) (Dionysos) 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: > Since I've been using whitespace.el, I've noticed that most of the > rectangle functions are very intrusive: they put whitespaces in unexpected > places. The reasons are: > > 1/ move-to-column doesn't make any difference between converting a tab into > space and adding spaces at the end of a line. This is now fixed. > > 2/ operate-on-rectangle does too much blind work, notably messing with the end > of the line even for functions like string-rectangle which shouldn't be > concerned. > > > So I've rewritten rect.el to correct these problems. The rectangle > functions now avoid inserting spaces in unwanted places, unless a prefix is > given for some of them, in which case the old behavior is (sort of) used. Here > are examples of the differences, if anybody wants to comment the changes I > propose. There's notably something on which I'm not completely decided yet: > for the functions with a prefix, we could push even farther the choice: > - don't add unnecessary blanks at all (no prefix) > - add blanks on non empty lines only > - add blanks blindly (current prefix meaning) As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for it. :) -bp From owner-xemacs-beta@xemacs.org Mon Jul 5 12:59:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26506 for xemacs-beta-out; Mon, 5 Jul 1999 12:59:27 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA26500 for ; Mon, 5 Jul 1999 12:59:26 -0400 Received: from metheny.enst.fr (OOPoOJ9av54rhmvrmovZMAiWlgMwZXsx@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id SAA13464; Mon, 5 Jul 1999 18:59:25 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id SAA18427; Mon, 5 Jul 1999 18:59:21 +0200 (MET DST) To: wmperry@aventail.com Cc: Xemacs Beta Testers Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.bp.aventail.com> 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: wmperry@aventail.com's message of "05 Jul 1999 11:49:42 -0500" Mail-Copies-To: never 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: 12 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > it. :) So this is probably going to be a good test case ... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Mon Jul 5 14:06:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29933 for xemacs-beta-out; Mon, 5 Jul 1999 14:06:01 -0400 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 OAA29921 for ; Mon, 5 Jul 1999 14:05:59 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 111D7s-0005Pl-00 for ; Mon, 05 Jul 1999 20:05:56 +0200 To: XEmacs Beta List Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.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: 05 Jul 1999 20:05:55 +0200 In-Reply-To: Didier Verna's message of "05 Jul 1999 18:59:20 +0200" Message-ID: <873dz3q8e4.fsf@pc-hrvoje.srce.hr> Lines: 11 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Dionysos) 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: > wmperry@aventail.com (William M. Perry) writes: > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say > > go for it. :) > > So this is probably going to be a good test case ... How about a formal test case? `rect-tests.el' would be a welcome addition to our automated tests directory, if not to medical science. From owner-xemacs-beta@xemacs.org Mon Jul 5 15:02:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA32525 for xemacs-beta-out; Mon, 5 Jul 1999 15:02:47 -0400 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 PAA32516; Mon, 5 Jul 1999 15:02:39 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA18708; Mon, 5 Jul 1999 21:02:37 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004_D; Mon Jul 5 21:02:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA05352; Mon, 5 Jul 1999 21:02:29 +0200 To: xemacs-beta@xemacs.org Cc: colin@xemacs.org, mla@lausch.at Subject: [Michael Lausch ] xemacs component From: Jan Vroonhof Date: 05 Jul 1999 21:02:28 +0200 Message-ID: Lines: 535 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: --=-=-= I have forwarded this do the xemacs-beta mailing list so this gets archived for posterity. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit From mla@lausch.at Mon Jul 5 20:48:47 1999 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA17993 for ; Mon, 5 Jul 1999 20:48:46 +0200 (MET DST) Received: from UNKNOWN(194.42.98.136), claiming to be "loki.lausch.at" via SMTP by frege, id smtpdAAAa004Oq; Mon Jul 5 20:48:42 1999 Received: from loki.lausch.at (IDENT:mla@localhost [127.0.0.1]) by loki.lausch.at (8.9.3/8.9.3) with ESMTP id UAA17591; Mon, 5 Jul 1999 20:47:57 +0200 Message-Id: <199907051847.UAA17591@loki.lausch.at> To: marcush@knuut.de, vroonhof@math.ethz.ch, trussarv@CIRANO.UMontreal.CA Subject: xemacs component Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Mon_Jul__5_20:47:33_1999-1" Content-Transfer-Encoding: 7bit Date: Mon, 05 Jul 1999 20:47:57 +0200 From: Michael Lausch Status: RO Content-Length: 13173 Lines: 500 --Multipart_Mon_Jul__5_20:47:33_1999-1 Content-Type: text/plain; charset=US-ASCII Appended is the corba-emacs.c file, which implements the xemacs bonobo component and the makefile. Beware that the corba-emacs is _not_ the only target in the makefile. all other targets won't compile, i've used them for testing. Also the gnorba file is enclosed. Please report any ideas suggestions and other findings. I'm using xemacs 21.1.3, but i'll switch to 21.2 branch as soon as my internet connection is better. You need the newest bonobo source from CVS. You migh use test-container-autoload to test the emacs component. Beware that it might be necessary to edit test-container-autoload.c and replace "File/" in the the gnome_app_insert_menus() call with waitever string is used in yu locale for the File menu. With a german locale it's "Datei/" for example. You need to copy the xemacs-viewer executable somewhere in you path. --Multipart_Mon_Jul__5_20:47:33_1999-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Makefile" Content-Transfer-Encoding: 8bit OCF=`orbit-config --cflags server` GCF=`gnome-config --cflags bonobo` OLF=`orbit-config --libs server` GLF=`gnome-config --libs bonobo` `gnome-config --libs gnomeui` XLF=`gnome-config --libs gtk` CFLAGS=$(OCF) $(GCF) -g -O -Wall LDFLAGS=$(OLF) $(GLF) $(XLF) -g OBJECTS=corba-emacs.o all: xemacs-viewer xemacs-tester xemacs-viewer: $(OBJECTS) gcc -o xemacs-viewer $(OBJECTS) -L/usr/local/lib -lextcli_Xlib $(LDFLAGS) xemacs-tester: desktop-textviewer-stubs.o desktop-textviewer-common.o xemacs-tester.o gcc -o xemacs-tester desktop-textviewer-stubs.o desktop-textviewer-common.o xemacs-tester.o $(LDFLAGS) desktop-textviewer-skels.c: /usr/local/gnome-cvs/share/idl/desktop-textviewer.idl orbit-idl -I/usr/local/gnome-cvs/share/idl /usr/local/gnome-cvs/share/idl/desktop-textviewer.idl embed: embed.o gcc -o embed embed.o -L/usr/local/lib -lextcli_Xlib $(LDFLAGS) impl: orbit-idl -I/usr/local/gnome-cvs/share/idl -Eskeleton_impl /usr/local/gnome-cvs/share/idl/desktop-textviewer.idl xemacs-editor.o: xemacs-editor.c --Multipart_Mon_Jul__5_20:47:33_1999-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="corba-emacs.c" Content-Transfer-Encoding: 8bit /** * bonobo xemacs implementation * * TODO: * actual bonobo embedding, and filling in of view_factory * testing for success/failure in emacs_file_(load|save) * * Authors: * Matt Loper (matt@gnome-support.com) * Michael Lausch (mla@lausch.at) */ #include #include #include #include #include #include #include #include #include /* * Emacs object data */ typedef struct { /* buffer name associated with a particular * emacs object */ gchar *buffer_name; gchar *frame_name; /* List of this component's GNOME::Views. */ GList *views; } emacs_data_t; /* * View data */ typedef struct { GnomeView *view; GNOME_ViewFrame view_frame; float scale; gpointer scaled; emacs_data_t *emacs_object_data; GtkWidget *drawing_area; } view_data_t; CORBA_Environment ev; static gint embed_xemacs_frame(GdkWindow* window); static void destroy_view (GtkObject *view, view_data_t *view_data); static GdkFilterReturn emacs_filter(GdkXEvent* gdk_xevent, GdkEvent* evet, gpointer data) { GdkWindow* window = (GdkWindow*)data; XEvent* xevent; Window xwindow; g_print("emacs_filter entered\n"); xevent = (XEvent*) gdk_xevent; xwindow = GDK_WINDOW_XWINDOW(window); g_print("Event->xany.window = %ld[0x%lx], window = %ld[0x%lx]\n", xevent->xany.window, xevent->xany.window, xwindow, xwindow); if (xevent->xany.window == xwindow) { g_print("Calling ExternalCLient Event handler for %d\n", xevent->type); ExternalClientEventHandler(GDK_WINDOW_XDISPLAY(window), xwindow, xevent); g_print("ExternalClientEventHandler returned\n"); } return GDK_FILTER_CONTINUE; } void window_exposed(GtkWidget* drawing_area, gpointer data) { GdkWindow* window; /*view_data_t* view_data = data;*/ g_print("window_mapped called\n"); window = drawing_area->window; g_print("window = %p/%p\n", window, window ? (void*)GDK_WINDOW_XWINDOW(window) : 0); embed_xemacs_frame(window); } static gint embed_xemacs_frame(GdkWindow* window) { Window xwindow; gchar cmd[1024]; gchar answer[1024]; int fd1[2]; int pid; xwindow = GDK_WINDOW_XWINDOW(window); g_print("Window id = %ld[0x%lx]\n", xwindow, xwindow); gdk_window_add_filter(window, emacs_filter, window); ExternalClientInitialize(GDK_WINDOW_XDISPLAY(window), xwindow); pipe(fd1); pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid > 0) { /* parent*/ int nbytes; memset(answer, 0, sizeof(answer)); close(fd1[1]); nbytes = read(fd1[0], answer, sizeof(answer)); g_print("answer = '%s'\n", answer); close(fd1[0]); } else { close(fd1[0]); g_snprintf(cmd, sizeof(cmd),"(make-frame (quote (window-id \"%ld\")))", xwindow); g_print("executing '%s'\n", cmd); if (dup2(fd1[1], fileno(stdout)) < 0) { perror("in child: dup2"); exit(1); } if (dup2(fd1[1], fileno(stderr)) < 0) { perror("in child: dup2"); exit(1); } close(fd1[1]); execlp("gnuclient", "gnuclient", "-batch", "-eval", cmd, 0); perror("execlp"); exit(1); } return 0; } static void destroy_view (GtkObject *view, view_data_t *view_data) { view_data->emacs_object_data->views = g_list_remove (view_data->emacs_object_data->views, view_data); CORBA_exception_init (&ev); GNOME_obj_unref (view_data->view_frame, &ev); g_free (view_data); } /* destroy_view */ /* NYI */ static GnomeView * view_factory (GnomeBonoboObject *emacs_bonobo_object, const GNOME_ViewFrame view_frame, void *data) { #if 0 g_warning ("view_factory not implemented\n"); return NULL; #else /* this is code stolen from elsewhere, and won't * work until we can stick emacs into a gtk window * and really bonobize it */ GnomeView *view; /*GtkWidget *drawing_area;*/ /* emacs_data_t *emacs_object_data = data;*/ view_data_t *view_data = g_new (view_data_t, 1); view_data->scale = 1.0; /* FIXME: what's this???? */ /* view_data->bonobo_object_data = bonobo_object_data;*/ view_data->drawing_area = gtk_drawing_area_new (); view_data->scaled = NULL; gtk_signal_connect ( GTK_OBJECT (view_data->drawing_area), "expose_event", GTK_SIGNAL_FUNC (window_exposed), view_data); gtk_widget_show (view_data->drawing_area); view = gnome_view_new (view_data->drawing_area); gtk_signal_connect ( GTK_OBJECT (view), "destroy", GTK_SIGNAL_FUNC (destroy_view), view_data); /* FIXME: what's bonobo_objct_data ???? */ /* bonobo_object_data->views = g_list_prepend (bonobo_object_data->views, view_data); */ return view; #endif } /* * When a corba_xemacs object is destroyed, we free the views * and the emacs_object_data associated with it */ static gboolean bonobo_object_destroy_cb (GnomeBonoboObject *bonobo_object, emacs_data_t *emacs_object_data) { GList *l; /* Destroy all views. */ for (l = emacs_object_data->views; l; l = l->next) { view_data_t *view_data = l->data; destroy_view (0, view_data); } /* Destroy the BonoboObject. */ if (emacs_object_data->buffer_name) g_free (emacs_object_data->buffer_name); g_free (emacs_object_data); return FALSE; } /* bonobo_object_destroy_cb */ /* * When a corba_xemacs is asked to save through its * PersistFile->load function, this function is called */ static int emacs_file_load (GnomePersistFile *pf, const char *filename, void *closure) { gchar cmd[1024]; gchar answer[1024]; FILE* channel; gint nbytes; g_assert (pf); if (!filename || !strlen (filename)) { g_warning ("emacs_file_load: filename required!\n"); return -1; } g_snprintf(cmd, sizeof(cmd), "exec gnuclient -batch -eval '(find-file-other-screen \"%s\")' 2>&1\n", filename); channel = popen(cmd, "r"); memset(answer,0, sizeof(answer)); nbytes = fread(answer, 1, sizeof(answer) - 1, channel); fclose(channel); g_print("gnuclient returns '%s'", answer); answer[nbytes-1] = '\0'; /* FIXME: How do you know if the file loads successfully? * Fill that in below, and uncomment the following... */ /* if (load_is_successful) { if (pf->filename) g_free (pf->filename); pf->filename = g_strdup (filename); return 0; } else */ return -1; } /* * When a corba_xemacs is asked to save through its * PersistFile->save function, this function is called */ static int emacs_file_save (GnomePersistFile *pf, const char *filename, void *closure) { gchar cmd[1024]; gchar answer[1024]; FILE* channel; gint nbytes; if (!filename || !strlen(filename)) filename = pf->filename; if (!filename || !strlen(filename)) return -1; g_snprintf(cmd, sizeof(cmd), "exec gnuclient -batch -eval '(with-current-buffer (get-buffer \"%s\")" "(save-buffer))' 2>&1\n", filename); g_print("executing <%s>\n", cmd); memset(answer, 0, sizeof(answer)); channel = popen(cmd, "r"); nbytes = fread(answer, sizeof(gchar), sizeof(answer) - 1, channel); fclose(channel); g_print("gnuclient returns '%s'\n", answer); /* FIXME: How do you know if the file saves successfully? * Fill that in below, and uncomment the following... */ /* if (save_is_successful) { if (pf->filename) g_free (pf->filename); pf->filename = g_strdup (filename); return 0; } else */ return -1; } /* * Create an instance of a corba_xemacs object */ static GnomeObject * emacs_object_factory (GnomeComponentFactory *this, void *data) { GnomeBonoboObject *emacs_bonobo_object; GnomePersistFile *persist_file; emacs_data_t *emacs_object_data = g_new0 (emacs_data_t, 1); if (!emacs_object_data) return NULL; /* Create a BonoboObject server */ emacs_bonobo_object = gnome_bonobo_object_new (view_factory, emacs_object_data); g_print("emacs_bonobo_object created\n"); if (emacs_bonobo_object == NULL) { g_free (emacs_object_data); return NULL; } gtk_signal_connect (GTK_OBJECT (emacs_bonobo_object), "destroy", GTK_SIGNAL_FUNC (bonobo_object_destroy_cb), emacs_object_data); /* Add a GNOME::PersistFile interface. */ persist_file = gnome_persist_file_new (emacs_file_load, emacs_file_save, emacs_object_data); if (persist_file == NULL) { gtk_object_unref (GTK_OBJECT (emacs_bonobo_object)); g_free (emacs_object_data); return NULL; } gtk_object_add_interface (GTK_OBJECT (emacs_bonobo_object), GTK_OBJECT (persist_file)); g_print("gnome_persist_file interface added\n"); return (GnomeObject*) emacs_bonobo_object; } /* emacs_object_factory */ /* * This sets up the factory so that when it's asked for * an object, it knows to call the `emacs_object_factory' function */ static void init_emacs_factory (void) { GnomeComponentFactory *factory; factory = gnome_component_factory_new ( "emacs:19990625:emacs-factory", emacs_object_factory, NULL); g_print("gnome_component_factotry created\n"); } /* init_emacs_factory */ int main (int argc, char **argv) { CORBA_ORB orb; int output_fd; FILE* logstream; logstream = fopen("/tmp/corba-emacs.log", "a"); output_fd = fileno(logstream); setvbuf(stderr, 0, _IOLBF, 0); setvbuf(stdout, 0, _IOLBF, 0); dup2(output_fd, fileno(stdout)); dup2(output_fd, fileno(stderr)); close(output_fd); CORBA_exception_init (&ev); gnome_CORBA_init_with_popt_table ( "corba_xemacs", "0.1", &argc, argv, NULL, 0, NULL, GNORBA_INIT_SERVER_FUNC, &ev); fprintf(stderr,"gnome_CORBA_init done\n"); orb = gnome_CORBA_ORB (); if (bonobo_init (orb, NULL, NULL) == FALSE) g_error (_("I could not initialize Bonobo")); init_emacs_factory (); g_print("init_emacs_factory done\n"); gtk_main (); CORBA_exception_free (&ev); return 0; } /* main */ --Multipart_Mon_Jul__5_20:47:33_1999-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="AAA.gnorba" Content-Transfer-Encoding: 8bit [emacs:19990625:emacs-factory] type=exe repo_id=IDL:GNOME/BonoboObjectFactory:1.0 IDL:GNOME/GenericFactory:1.0 description=Xemacs textviewer factory location_info=xemacs-viewer [emacs:19990625:emacs-factory_object] type=factory repo_id=IDL:GNOME/BonoboObject:1.0 description=Emacs editor component location_info=emacs:19990625:emacs-factory --Multipart_Mon_Jul__5_20:47:33_1999-1-- --=-=-= -- 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 Jul 5 16:04:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA03264 for xemacs-beta-out; Mon, 5 Jul 1999 16:04:31 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA03260 for ; Mon, 5 Jul 1999 16:04:29 -0400 Received: from kramer.bp.aventail.com (wmperry@usrpri2-39.kiva.net [206.97.75.104]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id NAA24014 for ; Mon, 5 Jul 1999 13:03:12 -0700 (PDT) Received: (from wmperry@localhost) by kramer.bp.aventail.com (8.9.3/8.9.3) id KAA07350; Mon, 5 Jul 1999 10:05:18 -0500 To: Xemacs Beta Testers Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.bp.aventail.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 13 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2(beta14) (Dionysos) 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: > wmperry@aventail.com (William M. Perry) writes: > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > > it. :) > > So this is probably going to be a good test case ... Oh yea verily. It might actually help matters. Tables with colored cells can lead to some weird stuff under both emacsen right now. -Bill P. From owner-xemacs-beta@xemacs.org Mon Jul 5 16:07:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA03408 for xemacs-beta-out; Mon, 5 Jul 1999 16:07:58 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA03404 for ; Mon, 5 Jul 1999 16:07:56 -0400 Received: from kramer.bp.aventail.com (wmperry@usrpri2-39.kiva.net [206.97.75.104]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id NAA24071; Mon, 5 Jul 1999 13:06:38 -0700 (PDT) Received: (from wmperry@localhost) by kramer.bp.aventail.com (8.9.3/8.9.3) id KAA07355; Mon, 5 Jul 1999 10:08:44 -0500 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.bp.aventail.com> <873dz3q8e4.fsf@pc-hrvoje.srce.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 19 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2(beta14) (Dionysos) 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: > Didier Verna writes: > > > wmperry@aventail.com (William M. Perry) writes: > > > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say > > > go for it. :) > > > > So this is probably going to be a good test case ... > > How about a formal test case? `rect-tests.el' would be a welcome > addition to our automated tests directory, if not to medical science. Well, testing it for correctness is one thing. Testing it for backwards-compatibility and not breaking existing piece-of-#!%@! software like W3 is another test entirely. :) -bp From owner-xemacs-beta@xemacs.org Mon Jul 5 18:08:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA09494 for xemacs-beta-out; Mon, 5 Jul 1999 18:08:08 -0400 Received: from auckland.aotearoa.dom (ali-ca4-14.ix.netcom.com [207.93.32.14]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA09488 for ; Mon, 5 Jul 1999 18:08:00 -0400 Received: (from simmonmt@localhost) by auckland.aotearoa.dom (8.9.1b+Sun/8.9.0) id PAA14869; Mon, 5 Jul 1999 15:07:57 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: 21.2.17 changed menubar font from 21.2.15 Reply-To: simmonmt@acm.org X-URL: http://www.netcom.com/~simmonmt X-Face: &|zdM~9cI7q1uq~\EW'*S*":rE7Ruf/U)m!9:^^H0f7)Sd(DIB-;rJf%8QtHy|50!A< >1B\_71-&^x{|ovY@mJ;{AeMFDL[Q*o[1@nd@mZLjJAyJ7Lx`T[Q!H3>!o7~bM0S(7r fhkrufL From: Matt Simmons Date: 05 Jul 1999 15:07:55 -0700 Message-ID: Lines: 32 User-Agent: Gnus/5.07009 (Pterodactyl Gnus v0.90) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= On this i386-pc-solaris2.7, my lucid menubars looked like this in b15: --=-=-= Content-Type: image/gif Content-Disposition: inline; filename=b15.menu.gif Content-Transfer-Encoding: base64 Content-Description: b15 menubar R0lGODlhbQA0APQZAAAAAB0bECUiFDQwHEM+JEpFKFlTMG1SEGFaNXBoPVZTU351RXNzc3p2 dwCAAPoTQNqlIP/nR4CAgJqUlMvFxtnZ2e7fzPTt7v///wAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAABkALAAAAABtADQAhAAAAB0bECUiFDQwHEM+JEpFKFlTMG1SEGFaNXBoPVZTU351 RXNzc3p2dwCAAPoTQNqlIP/nR4CAgJqUlMvFxtnZ2e7fzPTt7v///wAAAAAAAAAAAAAAAAAA AAAAAAAAAAX+ICAeUQSd50FGS+s+8AO4rVrSi6PP+GKzi8pkSCwyaquecsmkiQArVGqVqFZj MWv1p03sulZuQlgsM7ZUsHrNtj6j0h9iPocBEDE6Qq533PV6fBMMhIWGDHN8gIuMjYtvJVIQ PwaVBnaWMZaUlgYAnaAGnKGkoiulqKmkkCZxKwWwBTKxsDASsD+xEhg6tL65vsG0wMLFxsWs kj8EzDLMz80AzMvMOjoS0NDU2dzP293g4d3JriUD5wDn6uvpAz/rOxLr6+/z9vQr9/r7/OQo PwICChxIUABAgRIASCgo8CBDhg4fSpw40N+UEgEyatzIMcCPjiA1fgwJciTJkyj+M1qcREKF y5cwYUaISTPmzJo4W+bcyfPAyp5AgwodShTmT59PkipdyrSp06dQo0p9CuefzwtYs2rdyrWr 169gw4odq/UoALJo06pdi9YsVgpw48qdS7eu3bt48+rdC9ftBb6AAwsevNcv4cOIE+c1rLix 48OMH0uejDcy5cuYLWPe/Niygs+fKYQOzRc0aLmjFYhWbZc0XNeoWQP+7Nl07NmmZa++3Vo3 7Li/9dIeEcnV2b/AfasmffpucNu5dcdmfTr17tXS6w6HUtzq8enWUzfXbht7+OzJqZ/fnRsv 6NrVl8u/Tr75+uDp29+f71x07dvi4feadPs5F918543+V99/ybGH3ly/FdibgxRal5dpDA7o oIIQ6gcdf+RV+KF5D16XIYXYudeeedcJuB6LzAmoIQWacWYjYjXeqGNgOe7o42LEteLdWz8W WViQylyFnJFM2tVjk0z61cCUVFZp5ZVYZqnlllx26eWUbn0p5phklvmlWVOlqeaabLJZ1RRt xinnnGu+yRKdeOapJ3dCwrnnn4BOZacKgRZq6FKDInXoooEmSqcFkEIKgAVMUTqVpVBJ+oSm czq6FKYigFrppo9GZempodLpaVKRbsrpqKly+mqro2qKKaqsKkUrpa82tWquwDp1K66TkvqU rcXGuuuupCJLVXd+lprqtMk+htqrscXeSu22kUoq6rN93vkpqNcGq+222LKK6qnEcqtrmr+m W21T5ya7bLnZDmvvu+q2C1W88wbM6MBMhQAAOw== --=-=-= That is, they used -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-* for the font. This, concidentally, is the same font as specified in src/Emacs.ad.h. In b17, it looks like this: --=-=-= Content-Type: image/gif Content-Disposition: inline; filename=b17.menu.gif Content-Transfer-Encoding: base64 Content-Description: b17 menubar R0lGODlhfAAzAPQYAAAAAB0bECUiFDQwHEM+JEpFKFlTMG1SEGFaNVZTU3Nzc3p2dwCAAHzN fPoTQNqlIP/XAP/nR4CAgJqUlMTExMvFxvTt7v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAABgALAAAAAB8ADMAhAAAAB0bECUiFDQwHEM+JEpFKFlTMG1SEGFaNVZTU3Nzc3p2 dwCAAHzNfPoTQNqlIP/XAP/nR4CAgJqUlMTExMvFxvTt7v///wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAX+4BFFT1keYoSsq+MAiOuwCDrSCAPjrK0iE4VwSFSsfLykcsls1kamU8pANbgA VVnVV6Viu2AueNwVk8/otDoMjfoK8MIrDndJ4G+45MJg0P95f4JxgYOGh4iJdClRDz4EkC+Q k5EAkI+QfX0SlJSYnaCTn6Gkpaannm0mPgOtAK2wsa8DrLB9ABKxsbW6vbC8vsHCw8S7qlIj AsrLzM0CPswSuM7L0NTX1tfa29zdjG4pAeLj5OUBPubp4+jq6ezt8PHy6t+rIij4+fr6Efv+ +/3+Cbw3sKDBg/6OOULIsKHDhxAdKkQBoKLFixgzatzIsaPHjyBDcqwnBYCFkyj+U6pcybKl y5cwY8qc2ZLkQpM0c+rcybMnS5sUT1YYSrSo0aNIkypdyrSp06dHgR7ACbWq1atYs0adOFWo 1q9gw2aVSlWs2bNoi5L1mratW6xrLbydS7dp3Lp48xK9azSB378JKvglOjgr4L9ICwsObFVx UcdLFfN9zJgy4cpXISeu7FjzUcSUMUeuPPkyU89PUVtOqvqyaNBNJXMtu7o2ZMCxRbtebHro 4ciCQ3PGrFg2CXC0e9smzrg178/NizOP/Ty49OV7Z7N1Dfq67+lKD0fHrjx89cDevysvrb7v 8PKtNXd+X561+vHt8xtvFFSue+jKiRefbvPBp9tn9+n+B1517FUXIH2pEbhggacleN6EpGnn X20P1neahOTlZ56CBq6nIYD/idjZaJt9B6GD9pGoIIQNyveiiwP+5uKF7h1IGGvMDZZeg3oV iRaRRiYJFpJKNnkVk05G6RSUUlaZFJVWZpndcfYkp+WXW3FZ0kkLlGnmmWimqeaabLbp5ptw xpnmWnLWaeedeOapJlki9ennn4AGupFUFBRq6KGIJqrooow26uijkEbKKKGCVmrppZZSiumm nHaakaaehiqqoKCOauqpHpUKwaqrorppAx/B2lEDtIpUakUQeJSrqyHJOuuvFfmaKlcUZLQr rq0ieyxGvspKq7OwNltrsNNRAvDsRtFKC22111pLrbfBUuvsrQAca65Fy2YUbbjhriust82C a9GztU67LrvvzgsvuPfG2wC55+Iqkrb17mvttfl2q66+9DrLLMIHX0RwtCEAADs= --=-=-= Presumably that's one of the default CDE fonts. I tried setting the font myself in my .Xdefaults with the string from the Emacs.ad.h (with the addition of the Emacs* prefix) as follows: Emacs*menubar*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-* but it doesn't work either. What happened? What can I do to return it to the earlier font? Thanks Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt Whose cruel idea was it for the word "lisp" to have an "s" in it? --=-=-=-- From owner-xemacs-beta@xemacs.org Mon Jul 5 23:34:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA22042 for xemacs-beta-out; Mon, 5 Jul 1999 23:34:08 -0400 Received: from mithril.ne.mediaone.net (ethersoft.ne.mediaone.net [24.128.29.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA22039; Mon, 5 Jul 1999 23:34:06 -0400 Received: by mithril.ne.mediaone.net (Postfix, from userid 500) id 602E4180E; Mon, 5 Jul 1999 23:40:31 -0400 (EDT) To: Olivier Galibert Cc: XEmacs patches , XEmacs beta Subject: Re: Recent configure.in bugs fix References: <19990623175843.A18294@nemesis.ncsl.nist.gov> From: Vin Shelton Organization: The XEmacs Development Team Date: 05 Jul 1999 23:40:31 -0400 In-Reply-To: Olivier Galibert's message of "Wed, 23 Jun 1999 17:58:43 -0400" Message-ID: Lines: 37 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On Wed, 23 Jun 1999, Olivier Galibert said: OG> Since we're not using autoheader, any #define-type option added to OG> configure.in MUST be added to src/config.h.in or it will be ignored. OG> OG. OG> PS: I apply that one immediatly. OG> 1999-06-23 Olivier Galibert OG> * config.h.in: Add missing #undef *_USER_DEFINED. OG> Index: src/config.h.in OG> =================================================================== OG> RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v OG> retrieving revision 1.49.2.9 OG> diff -u -r1.49.2.9 config.h.in OG> --- config.h.in 1999/06/18 11:48:55 1.49.2.9 OG> +++ config.h.in 1999/06/23 22:01:06 OG> @@ -798,6 +798,11 @@ OG> #define MAIL_USE_LOCKF OG> #endif OG> +#undef PREFIX_USER_DEFINED OG> +#undef EXEC_PREFIX_USER_DEFINED OG> +#undef MODULEDIR_USER_DEFINED OG> +#undef SITEMODULEDIR_USER_DEFINED OG> +#undef DOCDIR_USER_DEFINED OG> #undef LISPDIR_USER_DEFINED OG> #undef PACKAGE_PATH_USER_DEFINED OG> #undef SITELISPDIR_USER_DEFINED Do any of these (specifically DOCDIR) need to be applied for 21.1? I've applied (but not committed) Michael's docdir patch for 21.1.4. - vin From owner-xemacs-beta@xemacs.org Mon Jul 5 23:56:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA22688 for xemacs-beta-out; Mon, 5 Jul 1999 23:56:43 -0400 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 XAA22684 for ; Mon, 5 Jul 1999 23:56:38 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id NAA09707; Tue, 6 Jul 1999 13:02:23 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: 21.2.17 changed menubar font from 21.2.15 References: X-Attribution: sb From: SL Baur In-Reply-To: Matt Simmons's message of "05 Jul 1999 15:07:55 -0700" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 06 Jul 1999 13:02:22 +0900 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Matt Simmons writes in xemacs-beta@xemacs.org: ... > What happened? What can I do to return it to the earlier font? I don't know what has happened to you, however, it has never worked as simply as you described. I set the menubar font with the X resource: XEmacs*fontSet: -*-helvetica-bold-r-*--12-*-*-*-*-*-*-*,-*-fixed-medium-r-normal--14-* -- $B8@$o$L$,2V(B (Two heads are better than one) From owner-xemacs-beta@xemacs.org Tue Jul 6 03:02:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA27692 for xemacs-beta-out; Tue, 6 Jul 1999 03:02:36 -0400 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 DAA27681; Tue, 6 Jul 1999 03:02:26 -0400 Received: from brabantio.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 JAA18400; Tue, 6 Jul 1999 09:02:10 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id JAA17366; Tue, 6 Jul 1999 09:02:07 +0200 To: Vin Shelton Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: Recent configure.in bugs fix References: <19990623175843.A18294@nemesis.ncsl.nist.gov> 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: 06 Jul 1999 09:02:07 +0200 In-Reply-To: Vin Shelton's message of "05 Jul 1999 23:40:31 -0400" Message-ID: Lines: 48 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 DAA27685 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Vin" == Vin Shelton writes: >>>>> On Wed, 23 Jun 1999, Olivier Galibert said: OG> Since we're not using autoheader, any #define-type option added to OG> configure.in MUST be added to src/config.h.in or it will be ignored. OG> OG. OG> PS: I apply that one immediatly. OG> 1999-06-23 Olivier Galibert OG> * config.h.in: Add missing #undef *_USER_DEFINED. OG> Index: src/config.h.in OG> =================================================================== OG> RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v OG> retrieving revision 1.49.2.9 OG> diff -u -r1.49.2.9 config.h.in OG> --- config.h.in 1999/06/18 11:48:55 1.49.2.9 OG> +++ config.h.in 1999/06/23 22:01:06 OG> @@ -798,6 +798,11 @@ OG> #define MAIL_USE_LOCKF OG> #endif OG> +#undef PREFIX_USER_DEFINED OG> +#undef EXEC_PREFIX_USER_DEFINED OG> +#undef MODULEDIR_USER_DEFINED OG> +#undef SITEMODULEDIR_USER_DEFINED OG> +#undef DOCDIR_USER_DEFINED OG> #undef LISPDIR_USER_DEFINED OG> #undef PACKAGE_PATH_USER_DEFINED OG> #undef SITELISPDIR_USER_DEFINED Vin> Do any of these (specifically DOCDIR) need to be applied for 21.1? Vin> I've applied (but not committed) Michael's docdir patch for 21.1.4. Yes. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 6 03:34:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA28924 for xemacs-beta-out; Tue, 6 Jul 1999 03:34:37 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA28921 for ; Tue, 6 Jul 1999 03:34:35 -0400 Received: from metheny.enst.fr (4cQt6P0adk5jcmjaiHeOZJOJ7v8Z9osx@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id JAA11155; Tue, 6 Jul 1999 09:34:33 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id JAA19038; Tue, 6 Jul 1999 09:34:31 +0200 (MET DST) To: wmperry@aventail.com Cc: Xemacs Beta Testers Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.bp.aventail.com> <86pv27dtn5.fsf@kramer.bp.aventail.com> 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: wmperry@aventail.com's message of "05 Jul 1999 10:05:18 -0500" Mail-Copies-To: never 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: 25 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > Didier Verna writes: > > > wmperry@aventail.com (William M. Perry) writes: > > > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > > > it. :) > > > > So this is probably going to be a good test case ... > > Oh yea verily. It might actually help matters. Tables with colored cells > can lead to some weird stuff under both emacsen right now. Actually, I'm also beginning to think that move-to-column shouldn't use tabs at all when filling lines. Only spaces. The reason is that nothing prevents you from killing a rectangle in one buffer and yanking it at a different column, or in another buffer with different tab widths. There, you're screwed up. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 6 04:45:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA30828 for xemacs-beta-out; Tue, 6 Jul 1999 04:45:03 -0400 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 EAA30817 for ; Tue, 6 Jul 1999 04:45:01 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA11153 for ; Tue, 6 Jul 1999 10:45:00 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002iB; Tue Jul 6 10:44:57 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA06597; Tue, 6 Jul 1999 10:44:55 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.2.17 changed menubar font from 21.2.15 References: From: Jan Vroonhof Date: 06 Jul 1999 10:44:55 +0200 In-Reply-To: Matt Simmons's message of "05 Jul 1999 15:07:55 -0700" 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: Matt Simmons writes: > What happened? What can I do to return it to the earlier font? Probably something got mixed up in Andy's Widget work. First thing to do would be to check config.h (maybe compare with the result from b15) to see whether you are indeed still using Lucid menus. Jan From owner-xemacs-beta@xemacs.org Tue Jul 6 05:32:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA31985 for xemacs-beta-out; Tue, 6 Jul 1999 05:32:30 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA31980 for ; Tue, 6 Jul 1999 05:32:28 -0400 Received: from metheny.enst.fr (L012WyB30ZB7jzU6w5TEhgra8oDdqicL@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA15823 for ; Tue, 6 Jul 1999 11:32:25 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA19541; Tue, 6 Jul 1999 11:32:21 +0200 (MET DST) To: Xemacs Beta Testers Subject: [PB] Makefile 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 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: 9 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: For some reason, it seems that touching a .el in the core lisp directory and typing `make' doesn't rebuild the autoloads anymore. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 6 05:45:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA32361 for xemacs-beta-out; Tue, 6 Jul 1999 05:45:06 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA32350 for ; Tue, 6 Jul 1999 05:45:02 -0400 Received: from metheny.enst.fr (gt17iXWOyVNRkuHGxxEMRyqujF2jgGNO@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA16484; Tue, 6 Jul 1999 11:45:00 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA19546; Tue, 6 Jul 1999 11:44:56 +0200 (MET DST) To: wmperry@aventail.com Cc: Xemacs Beta Testers Subject: Re: [RFC] the rectangle functions References: <86btdrf3dl.fsf@kramer.bp.aventail.com> <86pv27dtn5.fsf@kramer.bp.aventail.com> 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: wmperry@aventail.com's message of "05 Jul 1999 10:05:18 -0500" 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: 38 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= wmperry@aventail.com (William M. Perry) writes: > Didier Verna writes: > > > wmperry@aventail.com (William M. Perry) writes: > > > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > > > it. :) > > > > So this is probably going to be a good test case ... > > Oh yea verily. It might actually help matters. Tables with colored cells > can lead to some weird stuff under both emacsen right now. OK. I'd like people to test this. Interface changes are the following: * apply-on-rectangle: new function. operate-on-rectangle is not used anymore, but since it is documented, I didn't touch it in case external code use it. * The following functions now have an optional prefix letting them intrusively insert spaces the old way: kill-rectangle, delete-rectangle, delete-extract-rectangle, open-rectangle, clear-rectangle. I'm aware that using the prefix that way, the default behavior changes. However, I'd like to see if it breaks something or not because for interactive use, which is I think the most important case, things are more logical in this sense. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=rect.el Content-Description: new rectangle lib ;;; rect.el --- rectangle functions for XEmacs. ;; Copyright (C) 1999 Didier Verna ;; Copyright (C) 1985, 1993, 1994 Free Software Foundation, Inc. ;; Maintainer: XEmacs Development Team ;; Keywords: internal ;; 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: Highly diverging from FSF 19.34. ;;; Commentary: ;; This package provides the operations on rectangles that are ocumented ;; in the XEmacs Reference Manual. ;; ### NOTE: this file has been completely rewritten Jul 99 ;; by Didier Verna ;;; Code: ;; ### NOTE: this function is not used anymore. `apply-on-rectangle' is used ;; instead. It's still there because it's documented so people might use it in ;; their code, so I've decided not to touch it. --dv ;; XEmacs: extra-args (defun operate-on-rectangle (function start end coerce-tabs &rest extra-args) "Call FUNCTION for each line of rectangle with corners at START, END. If COERCE-TABS is non-nil, convert multi-column characters that span the starting or ending columns on any line to multiple spaces before calling FUNCTION. FUNCTION is called with three arguments: position of start of segment of this line within the rectangle, number of columns that belong to rectangle but are before that position, number of columns that belong to rectangle but are after point. Point is at the end of the segment of this line within the rectangle." (let (startcol startlinepos endcol endlinepos) (save-excursion (goto-char start) (setq startcol (current-column)) (beginning-of-line) (setq startlinepos (point))) (save-excursion (goto-char end) (setq endcol (current-column)) (forward-line 1) (setq endlinepos (point-marker))) (if (< endcol startcol) ;; XEmacs (let ((tem startcol)) (setq startcol endcol endcol tem))) (save-excursion (goto-char startlinepos) (while (< (point) endlinepos) (let (startpos begextra endextra) (move-to-column startcol coerce-tabs) (setq begextra (- (current-column) startcol)) (setq startpos (point)) (move-to-column endcol coerce-tabs) (setq endextra (- endcol (current-column))) (if (< begextra 0) (setq endextra (+ endextra begextra) begextra 0)) (if (< endextra 0) (setq endextra 0)) (apply function startpos begextra endextra extra-args)) (forward-line 1))) (- endcol startcol))) ;; The replacement for `operate-on-rectangle' (defun apply-on-rectangle (function start end &rest args) "Call FUNCTION for each line of rectangle with corners at START, END. FUNCTION is called with two arguments: the start and end columns of the rectangle, plus ARGS extra arguments. Point is at the beginning of line when the function is called." (let (startcol startpt endcol endpt) (save-excursion (goto-char start) (setq startcol (current-column)) (beginning-of-line) (setq startpt (point)) (goto-char end) (setq endcol (current-column)) (forward-line 1) (setq endpt (point-marker)) ;; ensure the start column is the left one. (if (< endcol startcol) (let ((col startcol)) (setq startcol endcol endcol col))) ;; start looping over lines (goto-char startpt) (while (< (point) endpt) (apply function startcol endcol args) (forward-line 1))) )) ;; I love ascii art ;-) (defconst spaces-strings '["" " " " " " " " " " " " " " " " "]) (defun spaces-string (n) (if (<= n 8) (aref spaces-strings n) (let ((val "")) (while (> n 8) (setq val (concat " " val) n (- n 8))) (concat val (aref spaces-strings n))))) ;;;###autoload (defvar killed-rectangle nil "Rectangle for yank-rectangle to insert.") ;;;###autoload (defun kill-rectangle (start end &optional fill) "Delete the rectangle with corners at point and mark (START and END when called from a program) and save it as the last killed one. You might prefer to use `delete-extract-rectangle' from a program. With a prefix (or a FILL) argument, also fill lines where nothing has to be deleted." (interactive "r\nP") (when buffer-read-only (setq killed-rectangle (extract-rectangle start end)) (barf-if-buffer-read-only)) (setq killed-rectangle (delete-extract-rectangle start end fill))) ;;;###autoload (defun delete-rectangle (start end &optional fill) "Delete (don't save) text in rectangle with corners at point and mark (START and END when called from a program). The same range of columns is deleted in each line starting with the line where the region begins and ending with the line where the region ends. With a prefix (or a FILL) argument, also fill lines where nothing has to be deleted." (interactive "r\nP") (apply-on-rectangle 'delete-rectangle-line start end fill)) (defun delete-rectangle-line (startcol endcol fill) (let ((pt (point-at-eol))) (when (= (move-to-column startcol (or fill 'coerce)) startcol) (if (and (not fill) (<= pt endcol)) (delete-region (point) pt) ;; else (setq pt (point)) (move-to-column endcol t) (delete-region pt (point)))) )) ;;;###autoload (defun delete-extract-rectangle (start end &optional fill) "Delete the contents of the rectangle with corners at START and END, and return it as a list of strings, one for each line of the rectangle. With an optional FILL argument, also fill lines where nothing has to be deleted." (let ((lines (list nil))) (apply-on-rectangle 'delete-extract-rectangle-line start end lines fill) (nreverse (cdr lines)))) (defun delete-extract-rectangle-line (startcol endcol lines fill) (let ((pt (point-at-eol))) (if (< (move-to-column startcol (or fill 'coerce)) startcol) (setcdr lines (cons (spaces-string (- endcol startcol)) (cdr lines))) ;; else (setq pt (point)) (move-to-column endcol t) (setcdr lines (cons (buffer-substring pt (point)) (cdr lines))) (delete-region pt (point))) )) ;;;###autoload (defun extract-rectangle (start end) "Return the contents of the rectangle with corners at START and END, as a list of strings, one for each line of the rectangle." (let ((lines (list nil))) (apply-on-rectangle 'extract-rectangle-line start end lines) (nreverse (cdr lines)))) ;; 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) (let (start end begextra endextra line) (move-to-column startcol) (setq start (point) begextra (- (current-column) startcol)) (move-to-column endcol) (setq end (point) endextra (- endcol (current-column))) (setq line (buffer-substring start (point))) (if (< begextra 0) (setq endextra (+ endextra begextra) begextra 0)) (if (< endextra 0) (setq endextra 0)) (goto-char start) (while (search-forward "\t" end t) (let ((width (- (current-column) (save-excursion (forward-char -1) (current-column))))) (setq line (concat (substring line 0 (- (point) end 1)) (spaces-string width) (substring line (+ (length line) (- (point) end))))))) (if (or (> begextra 0) (> endextra 0)) (setq line (concat (spaces-string begextra) line (spaces-string endextra)))) (setcdr lines (cons line (cdr lines))))) ;; This one is untouched --dv ;;;###autoload (defun yank-rectangle () "Yank the last killed rectangle with upper left corner at point." (interactive) (insert-rectangle killed-rectangle)) ;; This one is untouched --dv ;;;###autoload (defun insert-rectangle (rectangle) "Insert text of RECTANGLE with upper left corner at point. RECTANGLE's first line is inserted at point, its second line is inserted at a point vertically under point, etc. RECTANGLE should be a list of strings. After this command, the mark is at the upper left corner and point is at the lower right corner." (let ((lines rectangle) (insertcolumn (current-column)) (first t)) (push-mark) (while lines (or first (progn (forward-line 1) (or (bolp) (insert ?\n)) (move-to-column insertcolumn t))) (setq first nil) (insert (car lines)) (setq lines (cdr lines))))) ;;;###autoload (defun open-rectangle (start end &optional fill) "Blank out rectangle with corners at point and mark (START and END when called from a program), shifting text right. The text previously in the region is not overwritten by the blanks, but instead winds up to the right of the rectangle. With a prefix (or a FILL) argument, fill with blanks even if there is no text on the right side of the rectangle." (interactive "r\nP") (apply-on-rectangle 'open-rectangle-line start end fill) (goto-char start)) (defun open-rectangle-line (startcol endcol fill) (let (spaces) (when (= (move-to-column startcol (or fill 'coerce)) startcol) (unless (and (not fill) (= (point) (point-at-eol))) (indent-to endcol))) )) ;;;###autoload (defun string-rectangle (start end string) "Insert STRING on each line of the rectangle with corners at point and mark (START and END when called from a program), shifting text right. The left edge of the rectangle specifies the column for insertion. This command does not delete or overwrite any existing text." (interactive "r\nsString rectangle: ") (apply-on-rectangle 'string-rectangle-line start end string)) (defun string-rectangle-line (startcol endcol string) (move-to-column startcol t) (insert string)) ;;;###autoload (defun clear-rectangle (start end &optional fill) "Blank out the rectangle with corners at point and mark (START and END when called from a program). The text previously in the region is overwritten with blanks. With a prefix (or a FILL) argument, also fill with blanks the parts of the rectangle which were empty." (interactive "r\nP") (apply-on-rectangle 'clear-rectangle-line start end fill)) (defun clear-rectangle-line (startcol endcol fill) (let ((pt (point-at-eol)) spaces) (when (= (move-to-column startcol (or fill 'coerce)) startcol) (if (and (not fill) (<= (save-excursion (goto-char pt) (current-column)) endcol)) (delete-region (point) pt) ;; else (setq pt (point)) (move-to-column endcol t) (setq spaces (- (point) pt)) (delete-region pt (point)) (indent-to (+ (current-column) spaces)))) )) (provide 'rect) ;;; rect.el ends here --=-=-= -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 --=-=-=-- From owner-xemacs-beta@xemacs.org Tue Jul 6 05:47:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA32428 for xemacs-beta-out; Tue, 6 Jul 1999 05:47:07 -0400 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 FAA32423 for ; Tue, 6 Jul 1999 05:47:04 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id SAA16209; Tue, 6 Jul 1999 18:52:50 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile References: X-Attribution: sb From: SL Baur In-Reply-To: Didier Verna's message of "06 Jul 1999 11:32:20 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 06 Jul 1999 18:52:49 +0900 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes in xemacs-beta@xemacs.org: > For some reason, it seems that touching a .el in the core lisp > directory and typing `make' doesn't rebuild the autoloads anymore. ???? You mean it does not rebuild auto-autoloads.elc? The core lisp part of the build process has never rebuilt auto-autoloads.el (or custom-load.el) as a routine part of the build. -- $BA1$O5^$2(B (strike while the iron is hot) From owner-xemacs-beta@xemacs.org Tue Jul 6 05:59:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA00365 for xemacs-beta-out; Tue, 6 Jul 1999 05:59:17 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA00362 for ; Tue, 6 Jul 1999 05:59:15 -0400 Received: from metheny.enst.fr (Vg5cXdTXveKK0OOlmwhhGQXJCKk0Y4S5@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA16939 for ; Tue, 6 Jul 1999 11:59:14 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA19562; Tue, 6 Jul 1999 11:59:10 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile 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 "06 Jul 1999 18:52:49 +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: 24 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > Didier Verna writes in xemacs-beta@xemacs.org: > > > For some reason, it seems that touching a .el in the core lisp > > directory and typing `make' doesn't rebuild the autoloads anymore. > > ???? > > You mean it does not rebuild auto-autoloads.elc? The core lisp > part of the build process has never rebuilt auto-autoloads.el (or > custom-load.el) as a routine part of the build. Are you sure? I remember having only to type `gmake' after modifying a core lisp file. So what's the target? Hmm, I'm really surprised. What if you change the doc string of an autoloaded function ? Even removing the DOC didn't lead to an autoloads rebuild. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 6 06:30:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA01686 for xemacs-beta-out; Tue, 6 Jul 1999 06:30:36 -0400 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 GAA01679 for ; Tue, 6 Jul 1999 06:30:34 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id TAA16199; Tue, 6 Jul 1999 19:36:22 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile References: X-Attribution: sb From: SL Baur In-Reply-To: Didier Verna's message of "06 Jul 1999 11:59:08 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 06 Jul 1999 19:36:22 +0900 Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes in xemacs-beta@xemacs.org: > SL Baur writes: >> The core lisp part of the build process has never rebuilt >> auto-autoloads.el (or custom-load.el) as a routine part of the >> build. > Are you sure? Positive. Someone, Karl Hegbloom, I think, posted a patch a couple years ago that went part-way, but it never made its way into the sources. There aren't supposed to be any autoloads in the core lisp area, however, it is appropriate to have a custom-load.el. To be done right, it would need to work without an existing auto-autoloads.el file, and that's fairly tricky to do since we would only have temacs at the point where it would need to be generated. It's not impossible, of course, it's just a lot of tedious work. autoload.el would probably have to be rewritten using more primitive functions, for example. -- $B6b$,$b$N$r8@$&(B (Money talks) From owner-xemacs-beta@xemacs.org Tue Jul 6 06:46:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA02281 for xemacs-beta-out; Tue, 6 Jul 1999 06:46:39 -0400 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 GAA02276 for ; Tue, 6 Jul 1999 06:46:38 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA18915; Tue, 6 Jul 1999 03:46:23 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-8.beasys.com [192.168.11.8]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id DAA12915; Tue, 6 Jul 1999 03:46:21 -0700 (PDT) Message-Id: <3.0.5.32.19990706114631.009bfdb0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 06 Jul 1999 11:46:31 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: 21.2.17 changed menubar font from 21.2.15 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 10:44 AM 7/6/99 +0200, Jan Vroonhof wrote: >Matt Simmons writes: > >> What happened? What can I do to return it to the earlier font? > >Probably something got mixed up in Andy's Widget work. First thing to This seems unlikely to me, unless I suppose motif stuff is getting mixed in, where it wasn't before. But I don't see how this could happen with the lucid menubar. And anyway, unless this is from CVS he won't have any of the X related changes.... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Jul 6 06:49:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA02374 for xemacs-beta-out; Tue, 6 Jul 1999 06:49:08 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA02370 for ; Tue, 6 Jul 1999 06:49:06 -0400 Received: from metheny.enst.fr (MmCCU6K4LLPF6qqbH6UUTxRh6YU0UKvd@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id MAA19297 for ; Tue, 6 Jul 1999 12:49:05 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id MAA19603; Tue, 6 Jul 1999 12:49:03 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile 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 "06 Jul 1999 19:36:22 +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: 15 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > There aren't supposed to be any autoloads in the core lisp area, however, it > is appropriate to have a custom-load.el. I'm completely lost. The core lisp soure is full of autoload cookies and there IS an auto-autoloads file in this directory. You can even retrieve it via cvs. Are we talking about the same things ?! -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 6 06:55:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA02586 for xemacs-beta-out; Tue, 6 Jul 1999 06:55:01 -0400 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 GAA02582 for ; Tue, 6 Jul 1999 06:54:59 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id UAA16192; Tue, 6 Jul 1999 20:00:47 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile References: X-Attribution: sb From: SL Baur In-Reply-To: Didier Verna's message of "06 Jul 1999 12:49:02 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 06 Jul 1999 20:00:46 +0900 Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes in xemacs-beta@xemacs.org: > SL Baur writes: >> There aren't supposed to be any autoloads in the core lisp area, >> however, it is appropriate to have a custom-load.el. > I'm completely lost. The core lisp soure is full of autoload cookies > and there IS an auto-autoloads file in this directory. You can even > retrieve it via cvs. Are we talking about the same things ?! Yes. The files with autoload cookies in them belong in xemacs-base, not the core. -- $BG=$"$kBk$OD^$r1#$9(B (A wise man keeps some of his talents in reserve) From owner-xemacs-beta@xemacs.org Tue Jul 6 07:22:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA03667 for xemacs-beta-out; Tue, 6 Jul 1999 07:22:00 -0400 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 HAA03664 for ; Tue, 6 Jul 1999 07:21:59 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id NAA21439 for ; Tue, 6 Jul 1999 13:21:49 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa005Er; Tue Jul 6 13:21:44 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id NAA08903; Tue, 6 Jul 1999 13:21:43 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.2.17 changed menubar font from 21.2.15 References: <3.0.5.32.19990706114631.009bfdb0@london.beasys.com> From: Jan Vroonhof Date: 06 Jul 1999 13:21:42 +0200 In-Reply-To: Andy Piper's message of "Tue, 06 Jul 1999 11:46:31 +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: Andy Piper writes: > >Probably something got mixed up in Andy's Widget work. First thing to > > This seems unlikely to me, unless I suppose motif stuff is getting mixed > in, where it wasn't before. That's what I mean. First he should check whether he really still has the lucid menus. Anyway: Is all the code now using gui.c and friends? No more code duplication in the X part? Or is there still some left? Jan From owner-xemacs-beta@xemacs.org Tue Jul 6 08:14:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA05717 for xemacs-beta-out; Tue, 6 Jul 1999 08:14:29 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA05714 for ; Tue, 6 Jul 1999 08:14:27 -0400 Received: from metheny.enst.fr (Mrblz8H3GxrSKp/07fjTT6Ia5htOQIvE@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id OAA22386 for ; Tue, 6 Jul 1999 14:14:26 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id OAA19678; Tue, 6 Jul 1999 14:14:23 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [PB] Makefile 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 "06 Jul 1999 20:00:46 +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: 19 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > > I'm completely lost. Even more. > The files with autoload cookies in them belong in xemacs-base, not the core. No, I'm talking about files like info.el and all the others that are under the CORE LISP directory. There IS an auto-autoload file under xemacs/lisp and it contains stuff for the core lisp (sounds, etags, rect etc) and if it doesn't exist, the make process barfs. The package xemacs-base has nothing to do with this. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 6 08:56:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA06970 for xemacs-beta-out; Tue, 6 Jul 1999 08:56:56 -0400 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 IAA06967 for ; Tue, 6 Jul 1999 08:56:55 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id FAA22384; Tue, 6 Jul 1999 05:56:36 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-213.beasys.com [192.168.11.213]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id FAA20060; Tue, 6 Jul 1999 05:56:33 -0700 (PDT) Message-Id: <3.0.5.32.19990706135637.009d2930@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 06 Jul 1999 13:56:37 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: 21.2.17 changed menubar font from 21.2.15 In-Reply-To: References: <3.0.5.32.19990706114631.009bfdb0@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 01:21 PM 7/6/99 +0200, Jan Vroonhof wrote: >Andy Piper writes: > >> >Probably something got mixed up in Andy's Widget work. First thing to >> >> This seems unlikely to me, unless I suppose motif stuff is getting mixed >> in, where it wasn't before. > >That's what I mean. First he should check whether he really still has >the lucid menus. > >Anyway: Is all the code now using gui.c and friends? No more code >duplication in the X part? Or is there still some left? Do you mean duplication in gui-x? or the duplication between gui-item and widget-values? The former has been mostly rationalised. The latter I didn't touch because it is very platform specific and I have no desire to break it. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Wed Jul 7 00:10:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA20541 for xemacs-beta-out; Wed, 7 Jul 1999 00:10:25 -0400 Received: from mithril.ne.mediaone.net (ethersoft.ne.mediaone.net [24.128.29.147]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA20537 for ; Wed, 7 Jul 1999 00:10:23 -0400 Received: by mithril.ne.mediaone.net (Postfix, from userid 500) id 4EDB2180E; Wed, 7 Jul 1999 00:16:39 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: XEmacs-21.1.4 Ready to Go From: Vin Shelton Organization: The XEmacs Development Team Date: 07 Jul 1999 00:16:39 -0400 Message-ID: Lines: 65 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have applied the following patches to the 21.1 tree: Subject: Re: Making docdir configurable From: sperber@Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) Message-ID: Subject: fiddly Martin-style comment patch From: SL Baur Message-ID: Subject: bug in report XEmacs bug From: SL Baur Message-ID: Subject: lisp/wid-edit.el: Speling error. From: karlheg Message-ID: <87zp1qib0t.fsf@bittersweet.sysc.pdx.edu> Subject: Re: zombies on Solaris 2.5[.1] with 21.1.3 From: Gunnar Evermann Message-ID: Subject: assemble-list, or: yet another lost patch From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Message-ID: Subject: Re: Add {q} command to completion-list-mode. From: SL Baur Message-ID: Subject: [Bob Weiner ] Patch to fix docstring for completion-list-mode. From: SL Baur Message-ID: Subject: [Bob Weiner ] Simple but important patch for comment auto-filling. From: SL Baur Message-ID: Plus, I reran 'make config' and I added #undef DOCDIR_USER_DEFINED to src/config.h.in. Olivier and Michael, please check the change I make to src/config.h.in. Marcus, if you want me to update config.guess, please send me a working patch against 21.1. I have not applied the following patches; should I? Subject: lisp/files.el: `interpreter-mode-alist' additions. From: karlheg Message-ID: <87u2rvolka.fsf@bittersweet.sysc.pdx.edu> Subject: tags-search and find-tag going compute-bound From: Steve Carney Message-ID: Subject: Re: Text cursor should be visible in list mode for visual orientation. From: SL Baur Message-ID: I hope to cut a 21.1.4 release tomorrow night. (If I don't do it tomorrow night, it won't be for another week or so, 'cause I'll be out of town.) If there's anything *you* want to see in 21.1.4 - now's the time to speak up. -vin From owner-xemacs-beta@xemacs.org Wed Jul 7 01:52:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA23377 for xemacs-beta-out; Wed, 7 Jul 1999 01:52:02 -0400 Received: from auckland.aotearoa.dom (ali-ca28-23.ix.netcom.com [209.110.230.215]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA23374 for ; Wed, 7 Jul 1999 01:51:59 -0400 Received: (from simmonmt@localhost) by auckland.aotearoa.dom (8.9.1b+Sun/8.9.0) id WAA16782; Tue, 6 Jul 1999 22:51:56 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: Re: 21.2.17 changed menubar font from 21.2.15 References: <3.0.5.32.19990706114631.009bfdb0@london.beasys.com> Reply-To: simmonmt@acm.org X-URL: http://www.netcom.com/~simmonmt X-Face: &|zdM~9cI7q1uq~\EW'*S*":rE7Ruf/U)m!9:^^H0f7)Sd(DIB-;rJf%8QtHy|50!A< >1B\_71-&^x{|ovY@mJ;{AeMFDL[Q*o[1@nd@mZLjJAyJ7Lx`T[Q!H3>!o7~bM0S(7r fhkrufL From: Matt Simmons Date: 06 Jul 1999 22:51:56 -0700 In-Reply-To: Andy Piper's message of "Tue, 06 Jul 1999 11:46:31 +0100" Message-ID: Lines: 29 User-Agent: Gnus/5.07009 (Pterodactyl Gnus v0.90) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oh, and did I mention that supercite seems to be broken too? sc-attrib-selection-list did not evaluate to a string or list! >At 10:44 AM 7/6/99 +0200, Jan Vroonhof wrote: >>Matt Simmons writes: >>> What happened? What can I do to return it to the earlier font? >> >>Probably something got mixed up in Andy's Widget work. First thing to (featurep 'lucid-menubars) => t >This seems unlikely to me, unless I suppose motif stuff is getting mixed >in, where it wasn't before. But I don't see how this could happen with the >lucid menubar. >And anyway, unless this is from CVS he won't have any of the X related >changes.... Yes, I built from the latest CVS bits. Thanks Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt Never hit a man with glasses. Hit him with a baseball bat. From owner-xemacs-beta@xemacs.org Wed Jul 7 04:21:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA26264 for xemacs-beta-out; Wed, 7 Jul 1999 04:21:42 -0400 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 EAA26254; Wed, 7 Jul 1999 04:21:34 -0400 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id KAA16433; Wed, 7 Jul 1999 10:21:32 +0200 To: xemacs-build-reports@xemacs.org, xemacs-beta@xemacs.org Subject: 21.1.3 build failure on RedHat 6.0 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_Wed_Jul__7_10:21:14_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 07 Jul 1999 10:21:31 +0200 Message-ID: Lines: 246 X-Mailer: Gnus v5.6.45/XEmacs 21.2(beta13) - "Demeter" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Wed_Jul__7_10:21:14_1999-1 Content-Type: text/plain; charset=US-ASCII I can't build XEmacs 21.1 on RedHat 6.0 at any level of optimization even when using all the compiler flags mentioned in PROBLEMS (-fno-schedule-insns -fno-strength-reduce -fno-caller-saves). Compilation stops with a temacs core dump (see below). The whole thing builds when optimization is disabled. Any help greatly appreciated. I updated the sources from CVS a few hours ago. Oscar gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) uname -a: Linux lsppc4.epfl.ch 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686 unknown ./configure '--cflags=-O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves' '--with-mule=yes' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena' '--error-checking=none' '--use-union-type' XEmacs 21.1.3 "Acadia" configured for `i686-pc-linux'. Where should the build process find the source code? /home/xemacs/src/xemacs-21.1 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 -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves 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 LDAP (UMich libs). 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 session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using the union type for Lisp_Objects. Using Lisp_Objects with minimal tagbits. cd ./lib-src && make CC='gcc' CFLAGS='-O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/xemacs/src/xemacs-21.1/lib-src' gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H /home/xemacs/src/xemacs-21.1/lib-src/make-path.c -o make-path gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H /home/xemacs/src/xemacs-21.1/lib-src/movemail.c /home/xemacs/src/xemacs-21.1/lib-src/pop.c \ getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o movemail gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H /home/xemacs/src/xemacs-21.1/lib-src/fakemail.c -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o fakemail gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H /home/xemacs/src/xemacs-21.1/lib-src/yow.c -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o yow gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/usr/X11R6/include /home/xemacs/src/xemacs-21.1/lib-src/gnuslib.c gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/usr/X11R6/include /home/xemacs/src/xemacs-21.1/lib-src/gnuserv.c gnuslib.o -L/usr/X11R6/lib -lXau -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o gnuserv gcc -I. -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/home/xemacs/src/xemacs-21.1/lib-src -I/home/xemacs/src/xemacs-21.1/lib-src/../src -DVERSION='"21.1.3"' /home/xemacs/src/xemacs-21.1/lib-src/etags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o etags gcc -DCTAGS -I. -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/home/xemacs/src/xemacs-21.1/lib-src -I/home/xemacs/src/xemacs-21.1/lib-src/../src -DVERSION='"21.1.3"' /home/xemacs/src/xemacs-21.1/lib-src/etags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o ctags gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H /home/xemacs/src/xemacs-21.1/lib-src/b2m.c -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o b2m gcc -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/usr/X11R6/include /home/xemacs/src/xemacs-21.1/lib-src/gnuclient.c gnuslib.o -L/usr/X11R6/lib -lXau -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o gnuclient gcc -I. -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I../src -DHAVE_CONFIG_H -I/home/xemacs/src/xemacs-21.1/lib-src -I/home/xemacs/src/xemacs-21.1/lib-src/../src -DVERSION='"21.1.3"' /home/xemacs/src/xemacs-21.1/lib-src/ootags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o -o ootags make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/lib-src' cd ./lwlib && make CC='gcc' CFLAGS='-O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/xemacs/src/xemacs-21.1/lwlib' gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lwlib.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lwlib-utils.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lwlib-config.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lwlib-Xaw.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include xlwmenu.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include xlwscrollbar.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lwlib-Xlw.c rm -f liblw.a ar cq liblw.a lwlib.o lwlib-utils.o lwlib-config.o lwlib-Xaw.o xlwmenu.o xlwscrollbar.o lwlib-Xlw.o make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/lwlib' cd ./src && make CC='gcc' CFLAGS='-O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/xemacs/src/xemacs-21.1/src' gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include abbrev.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include alloc.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include blocktype.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include buffer.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include bytecode.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include callint.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include callproc.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include casefiddle.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include casetab.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include chartab.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include cmdloop.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include cmds.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include console.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include console-stream.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include data.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include device.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dired.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include doc.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include doprnt.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dynarr.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include editfns.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include elhash.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include emacs.c emacs.c: In function `voodoo_free_hook': emacs.c:2146: warning: assignment from incompatible pointer type emacs.c: In function `Fkill_emacs': emacs.c:2205: warning: assignment from incompatible pointer type gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include eval.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include events.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include unexelf.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include eldap.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include menubar.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include scrollbar.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dialog.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include toolbar.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gui.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include menubar-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include scrollbar-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dialog-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include toolbar-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gui-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include mule.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include mule-ccl.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include mule-charset.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include mule-coding.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include file-coding.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include input-method-xlib.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include inline.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include linuxplay.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include console-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include device-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include event-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include frame-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include objects-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include redisplay-tty.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include cm.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include terminfo.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gpmevent.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include event-unixoid.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include database.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include sysdll.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dll.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include process-unix.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include event-stream.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include extents.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include faces.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include fileio.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include filemode.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include floatfns.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include fns.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include font-lock.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include frame.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include general.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include getloadavg.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include glyphs.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include glyphs-eimage.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include hash.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include imgproc.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include indent.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include insdel.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include intl.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include keymap.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include line-number.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lread.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include lstream.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include macros.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include marker.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include md5.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include minibuf.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include objects.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include opaque.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include print.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include process.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include profile.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include pure.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include rangetab.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include redisplay.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include redisplay-output.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include regex.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include search.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include signal.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include sound.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include specifier.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include strftime.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include symbols.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include syntax.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include sysdep.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include undo.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include balloon_help.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include balloon-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include console-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include device-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include event-Xt.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include frame-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include glyphs-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include objects-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include redisplay-x.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include xgccache.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include xselect.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include widget.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include window.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include vm-limit.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include ralloc.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include EmacsFrame.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include EmacsShell.c gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include -DDEFINE_TOP_LEVEL_EMACS_SHELL /home/xemacs/src/xemacs-21.1/src/EmacsShell-sub.c mv EmacsShell-sub.o TopLevelEmacsShell.o gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include -DDEFINE_TRANSIENT_EMACS_SHELL /home/xemacs/src/xemacs-21.1/src/EmacsShell-sub.c mv EmacsShell-sub.o TransientEmacsShell.o gcc -c -O -mpentiumpro -fno-schedule-insns -fno-strength-reduce -fno-caller-saves -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include EmacsManager.c gcc -nostdlib -L/usr/X11R6/lib -rdynamic -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o unexelf.o eldap.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o gui.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o mule-coding.o file-coding.o input-method-xlib.o inline.o linuxplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o gpmevent.o event-unixoid.o database.o sysdll.o dll.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o getloadavg.o glyphs.o glyphs-eimage.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o ! minibuf.o objects.o opaque.o print.o process.o profile.o pure.o rangetab.o redisplay.o redisplay-output.o regex.o search.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o xgccache.o xselect.o widget.o window.o lastfile.o vm-limit.o ralloc.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lXaw -lcompface -ltiff -lpng -ljpeg -lz -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -lldap -llber -lm -lgcc -lc -lgcc /usr/lib/crtn.o `gcc -print-libgcc-file-name` EMACSBOOTSTRAPLOADPATH="/home/xemacs/src/xemacs-21.1/src/../lisp/:/home/xemacs/src/xemacs-21.1" ./temacs -batch -l /home/xemacs/src/xemacs-21.1/src/../lisp/update-elc.el make[1]: *** [update-elc.stamp] Segmentation fault (core dumped) make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/src' make: *** [src] Error 2 Compilation exited abnormally with code 2 at Wed Jul 7 10:14:22 --pgp-sign-Multipart_Wed_Jul__7_10:21:14_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBN4MN/57CaiYEgqPZAQF48wH/QQPFE8zWpoXRbHb1Wqp4RY9nYhE7sKQ8 I49WkW5fSg5/q7byjBIXEK4mzktD7g4wWTyiXGxFvC66KjlkqfFdEg== =9Qn+ -----END PGP MESSAGE----- --pgp-sign-Multipart_Wed_Jul__7_10:21:14_1999-1-- From owner-xemacs-beta@xemacs.org Wed Jul 7 04:37:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA26866 for xemacs-beta-out; Wed, 7 Jul 1999 04:37:21 -0400 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 EAA26861 for ; Wed, 7 Jul 1999 04:37:18 -0400 Received: (from steve@localhost) by miho.m17n.org (8.9.3/8.9.3) id RAA29674; Wed, 7 Jul 1999 17:37:12 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 References: X-Attribution: sb From: SL Baur In-Reply-To: Oscar Figueiredo's message of "07 Jul 1999 10:21:31 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 07 Jul 1999 17:37:12 +0900 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oscar Figueiredo writes in xemacs-beta@xemacs.org: > I can't build XEmacs 21.1 on RedHat 6.0 at any level of optimization ... > EMACSBOOTSTRAPLOADPATH="/home/xemacs/src/xemacs-21.1/src/../lisp/:/home/xemacs/src/xemacs-21.1" ./temacs -batch -l /home/xemacs/src/xemacs-21.1/src/../lisp/update-elc.el > make[1]: *** [update-elc.stamp] Segmentation fault (core dumped) > make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/src' > make: *** [src] Error 2 Just for grins, please rm src/*.o and rebuild optimized. -- $B5c$-LL$KK*(B (When it rains, it pours) From owner-xemacs-beta@xemacs.org Wed Jul 7 05:49:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA29051 for xemacs-beta-out; Wed, 7 Jul 1999 05:49:20 -0400 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA29048 for ; Wed, 7 Jul 1999 05:49:18 -0400 Received: from dsl.eng.cam.ac.uk (via root@dsl.eng.cam.ac.uk [129.169.81.1]) by spanner.eng.cam.ac.uk with ESMTP id KAA03169 for ; Wed, 7 Jul 1999 10:49:12 +0100 (BST) Received: from sippi.eng.cam.ac.uk (via ge204@sippi.eng.cam.ac.uk [129.169.81.68]) by dsl.eng.cam.ac.uk with ESMTP id KAA14790 for ; Wed, 7 Jul 1999 10:49:10 +0100 Received: (via ge204@localhost) by sippi.eng.cam.ac.uk id KAA20565; Wed, 7 Jul 1999 10:49:09 +0100 To: XEmacs Developers Subject: [Richard.Zatorski@Eng.Sun.COM] gnuserv ports From: Gunnar Evermann Date: 07 Jul 1999 10:49:08 +0100 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= can anyone comment on this? --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=809.bin Content-Description: gnuserv on different ports From jason@tux.org Tue Jul 6 20:16:34 1999 Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) by camelot-soft.camelot-soft.com (8.9.3/8.9.3) with ESMTP id UAA27971 for ; Tue, 6 Jul 1999 20:16:34 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA18914 for ; Tue, 6 Jul 1999 23:16:32 -0400 From: Richard.Zatorski@Eng.Sun.COM Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26793 for ; Tue, 6 Jul 1999 20:16:31 -0700 (PDT) Received: from dazl.eng.sun.com (dazl.Eng.Sun.COM [129.146.48.172]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA00990 for ; Tue, 6 Jul 1999 20:16:30 -0700 (PDT) Received: from polka (polka [192.9.125.14]) by dazl.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id UAA02069 for ; Tue, 6 Jul 1999 20:16:28 -0700 (PDT) Date: Tue, 6 Jul 1999 20:16:27 -0700 (PDT) Reply-To: Subject: running gnuclient on different ports To: crashes@xemacs.org Message-ID: Content-Type: text X-Sun-Text-Type: ascii Looking at the gnuclient and associated utilities, has anyone verified that this works using different ports? I tried this several times, but it appears that I always seem to lose the initial gnuserv that I started up. Unfortunately, I've worked around this using a tool that allows me to share a tty session and then I fire up xemacs using the -nw flag. Having gnuclient work with different ports would be better. BTW, I'm using xemacs version 21.2 on top of solaris 2.7. Thanks, (RAZ) --=-=-= -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University --=-=-=-- From owner-xemacs-beta@xemacs.org Wed Jul 7 08:44:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA00310 for xemacs-beta-out; Wed, 7 Jul 1999 08:44:48 -0400 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 IAA00306 for ; Wed, 7 Jul 1999 08:44:44 -0400 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id OAA21610; Wed, 7 Jul 1999 14:44:42 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 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_Wed_Jul__7_14:44:13_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 07 Jul 1999 14:44:42 +0200 In-Reply-To: SL Baur's message of "07 Jul 1999 17:37:12 +0900" Message-ID: Lines: 53 X-Mailer: Gnus v5.6.45/XEmacs 21.2(beta13) - "Demeter" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Wed_Jul__7_14:44:13_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "sb" == SL Baur writes: sb> Oscar Figueiredo writes in xemacs-beta@xemacs.org: >> I can't build XEmacs 21.1 on RedHat 6.0 at any level of optimization sb> ... >> EMACSBOOTSTRAPLOADPATH="/home/xemacs/src/xemacs-21.1/src/../lisp/:/home/xemacs/src/xemacs-21.1" ./temacs -batch -l /home/xemacs/src/xemacs-21.1/src/../lisp/update-elc.el >> make[1]: *** [update-elc.stamp] Segmentation fault (core dumped) >> make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/src' >> make: *** [src] Error 2 sb> Just for grins, please rm src/*.o and rebuild optimized. Alas, same cause, same results. I even recompiled with -g (in addition to -O) which got me the following backtrace: Core was generated by `./temacs -batch -l /home/xemacs/src/xemacs-21.1/src/../lisp/update-elc.el'. Program terminated with signal 11, Segmentation fault. #0 0x4031e3e5 in ?? () (gdb) bt #0 0x4031e3e5 in ?? () #1 0x807f1bd in resize_string (s=0x82ee204, pos=128, delta=1) at alloc.c:2261 #2 0x807f2e6 in set_string_char (s=0x82ee204, i=128, c=128) at alloc.c:2340 #3 0x808e19f in complex_vars_of_casetab () at casetab.c:323 #4 0x80a4b2d in xemacs_21_1_3_i686_pc_linux (argc=4, argv=0xbffff7e4, envp=0xbffff7f8, restart=0) at emacs.c:1526 #5 0x80a5445 in main (argc=4, argv=0xbffff7e4, envp=0xbffff7f8) at emacs.c:2069 #6 0x402d7cb3 in ?? () (gdb) up #1 0x807f1bd in resize_string (s=0x82ee204, pos=128, delta=1) at alloc.c:2261 2261 memmove (addroff + delta, addroff, (gdb) print s $1 = (struct Lisp_String *) 0x82ee204 Oscar --pgp-sign-Multipart_Wed_Jul__7_14:44:13_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUAN4NLoZ7CaiYEgqPZAQFIQwIAh6ktAwtf+IunjNw55sLkdXybzndXwuAq YouJiO1G9d+V4ehf4ZZiMLFTGF6iIUCYaJtIcSvtyuFqOR+MPZC3Dw== =vvkR -----END PGP MESSAGE----- --pgp-sign-Multipart_Wed_Jul__7_14:44:13_1999-1-- From owner-xemacs-beta@xemacs.org Wed Jul 7 09:01:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA00996 for xemacs-beta-out; Wed, 7 Jul 1999 09:01:38 -0400 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 JAA00989 for ; Wed, 7 Jul 1999 09:01:33 -0400 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id PAA21631; Wed, 7 Jul 1999 15:01:30 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 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_Wed_Jul__7_15:00:18_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 07 Jul 1999 15:01:30 +0200 In-Reply-To: Oscar Figueiredo's message of "07 Jul 1999 10:21:31 +0200" Message-ID: Lines: 104 X-Mailer: Gnus v5.6.45/XEmacs 21.2(beta13) - "Demeter" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Wed_Jul__7_15:00:18_1999-1 Content-Type: multipart/mixed; boundary="Multipart_Wed_Jul__7_15:00:18_1999-1" Content-Transfer-Encoding: 7bit --Multipart_Wed_Jul__7_15:00:18_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Oscar" == Oscar Figueiredo writes: Oscar> I can't build XEmacs 21.1 on RedHat 6.0 at any level of optimization even when Oscar> using all the compiler flags mentioned in PROBLEMS (-fno-schedule-insns Oscar> -fno-strength-reduce -fno-caller-saves). Compilation stops with a temacs core Oscar> dump (see below). The whole thing builds when optimization is disabled. Any Oscar> help greatly appreciated. I updated the sources from CVS a few hours ago. Oscar> [...] Oscar> EMACSBOOTSTRAPLOADPATH="/home/xemacs/src/xemacs-21.1/src/../lisp/:/home/xemacs/src/xemacs-21.1" ./temacs -batch -l /home/xemacs/src/xemacs-21.1/src/../lisp/update-elc.el Oscar> make[1]: *** [update-elc.stamp] Segmentation fault (core dumped) Oscar> make[1]: Leaving directory `/home/xemacs/src/xemacs-21.1/src' Oscar> make: *** [src] Error 2 Oscar> Compilation exited abnormally with code 2 at Wed Jul 7 10:14:22 Here's a followup from Gunnar that might be of interest for the rest of the list, unfortunately this seems to be reproducible. Oscar --Multipart_Wed_Jul__7_15:00:18_1999-1 Content-Type: message/rfc822 From: Gunnar Evermann Subject: Re: 21.1.3 build failure on RedHat 6.0 To: Oscar Figueiredo Date: Wed, 7 Jul 1999 12:33:30 +0100 (BST) [...] OK, I have tried this on one of our RedHat6.0 machines with your flags and -g and indeed I get the same crash (this is from starting ./temacs without any arguments). note the len argument to memove! (this machine _does_ have 1GB of memory but not 4 :-( (gdb) bt #0 0x403033e5 in memmove (dest=0x836b949, src=0x836b948, len=4294967169) at ../sysdeps/generic/memmove.c:98 #1 0x807ed2d in resize_string (s=0x839906c, pos=128, delta=1) at /home/tigger3/ge204/src/xemacs-21.1.3/src/alloc.c:2261 #2 0x807ee56 in set_string_char (s=0x839906c, i=128, c=128) at /home/tigger3/ge204/src/xemacs-21.1.3/src/alloc.c:2340 #3 0x808dd0f in complex_vars_of_casetab () at /home/tigger3/ge204/src/xemacs-21.1.3/src/casetab.c:323 #4 0x80a4693 in xemacs_21_1_p3_i686_pc_linux (argc=1, argv=0xbffff5e4, envp=0xbffff5ec, restart=0) at /home/tigger3/ge204/src/xemacs-21.1.3/src/emacs.c:1526 #5 0x80a4fa5 in main (argc=1, argv=0xbffff5e4, envp=0xbffff5ec) at /home/tigger3/ge204/src/xemacs-21.1.3/src/emacs.c:2069 #6 0x402bccb3 in __libc_start_main (main=0x80a4f34
, argc=1, argv=0xbffff5e4, init=0x807a798 <_init>, fini=0x817cdd4 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff5dc) at ../sysdeps/generic/libc-start.c:78 what is weird is that if I go to frame #2 and print i, I get -129, which is definitely wrong (OK, I know you can't trust debug info in an optimized build, but still...). So I guess the standard excuse is an optimisation error in egcs. I had previously built with -O3, but without -mpentiumpro and did not have any problems. This is on a 550MHz dual i686 (A _very_ nice toy BTW, we just got a dozen of these :-) Linux hygiea 2.2.10-16smp #1 SMP Wed Jun 30 07:01:23 BST 1999 i686 unknown In my opinion life is too short to debug gcc optimisation bugs, but if you want to look into it, then you should probably start by building the latest egcs snapshot... maybe we should write this up for PROBLEMS. Sorry, I couldn't really help... Bye, Gunnar --Multipart_Wed_Jul__7_15:00:18_1999-1-- --pgp-sign-Multipart_Wed_Jul__7_15:00:18_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBN4NPY57CaiYEgqPZAQE/+AIAk5d06DEsiDnVKG77kU+ZaCWRoyFhGAAi f8fwDKc8mnk+fwJPZbKY6vKhZHuFbZc9iaxyUOOL4cbUP5Vgma4L/Q== =5oXJ -----END PGP MESSAGE----- --pgp-sign-Multipart_Wed_Jul__7_15:00:18_1999-1-- From owner-xemacs-beta@xemacs.org Wed Jul 7 10:01:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA03457 for xemacs-beta-out; Wed, 7 Jul 1999 10:01:46 -0400 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 KAA03452 for ; Wed, 7 Jul 1999 10:01:42 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA17554 for ; Wed, 7 Jul 1999 16:01:40 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004IF; Wed Jul 7 16:01:37 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA13052; Wed, 7 Jul 1999 16:01:37 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 References: From: Jan Vroonhof Date: 07 Jul 1999 16:01:35 +0200 In-Reply-To: Oscar Figueiredo's message of "07 Jul 1999 15:01:30 +0200" 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: Oscar Figueiredo writes: > #0 0x403033e5 in memmove (dest=0x836b949, src=0x836b948, len=4294967169) > at ../sysdeps/generic/memmove.c:98 Note that len=(unsigned int)-127 Note that this should be this call memmove (addroff + delta, addroff, /* +1 due to zero-termination. */ string_length (s) + 1 - pos); > #1 0x807ed2d in resize_string (s=0x839906c, pos=128, delta=1) > at /home/tigger3/ge204/src/xemacs-21.1.3/src/alloc.c:2261 -127 = 0 + 1 -128 so I'm not sure this an optimization bug. Question: Why is this case triggering anyway? 128*4 = 512 << 8192 - \epsilon Jan From owner-xemacs-beta@xemacs.org Wed Jul 7 10:35:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA04815 for xemacs-beta-out; Wed, 7 Jul 1999 10:35:55 -0400 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 KAA04812 for ; Wed, 7 Jul 1999 10:35:54 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id KAA01171 for xemacs-beta@xemacs.org; Wed, 7 Jul 1999 10:35:53 -0400 Date: Wed, 7 Jul 1999 10:35:53 -0400 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: XEmacs-21.1.4 Ready to Go Message-ID: <19990707103553.C962@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Vin Shelton on Wed, Jul 07, 1999 at 12:16:39AM -0400 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Jul 07, 1999 at 12:16:39AM -0400, Vin Shelton wrote: > Plus, I reran 'make config' and I added #undef DOCDIR_USER_DEFINED to > src/config.h.in. Olivier and Michael, please check the change I make > to src/config.h.in. Checked and approved. OG. From owner-xemacs-beta@xemacs.org Wed Jul 7 10:48:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05185 for xemacs-beta-out; Wed, 7 Jul 1999 10:48:54 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA05182 for ; Wed, 7 Jul 1999 10:48:52 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 111t07-00052m-00 for xemacs-beta@xemacs.org; Wed, 07 Jul 1999 15:48:43 +0100 Date: Wed, 7 Jul 1999 15:48:42 +0100 (BST) From: Gunnar Evermann To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have been building various configurations and I only get this problem if building with union type, -O (or higher) and pentiumpro (either just -mcpu or -march as well) This surprises me somewhat, I had thought that building with union-type was always a good idea... Incidentally I also noticed that the build process somtimes failed when I invoked make with -j2 or higher. It barfed on the puresize stuff and asked me to invoke make again (this should be automatic, shouldn't it?). I'm slightly reluctant to investigate this as puresize stuff is gone for 21.2 anyway. Gunnar From owner-xemacs-beta@xemacs.org Wed Jul 7 11:55:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA08001 for xemacs-beta-out; Wed, 7 Jul 1999 11:55:16 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA07997 for ; Wed, 7 Jul 1999 11:55:13 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 111u2R-0000rb-00 for xemacs-beta@xemacs.org; Wed, 07 Jul 1999 16:55:11 +0100 Date: Wed, 7 Jul 1999 16:55:11 +0100 (BST) From: Gunnar Evermann To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 7 Jul 1999, Jan Vroonhof wrote: > Oscar Figueiredo writes: > > > #0 0x403033e5 in memmove (dest=0x836b949, src=0x836b948, len=4294967169) > > at ../sysdeps/generic/memmove.c:98 > > Note that len=(unsigned int)-127 I know, but couldn't be bothered to investigate, as I had to do some other work :-) > Note that this should be this call > > memmove (addroff + delta, addroff, > /* +1 due to zero-termination. */ > string_length (s) + 1 - pos); > > > #1 0x807ed2d in resize_string (s=0x839906c, pos=128, delta=1) > > at /home/tigger3/ge204/src/xemacs-21.1.3/src/alloc.c:2261 > > > -127 = 0 + 1 -128 > > so I'm not sure this an optimization bug. Question: Why is this case > triggering anyway? 128*4 = 512 << 8192 - \epsilon dunno. well, (gdb) p oldfullsize $7 = 8 (gdb) p newfullsize $8 = -129 looks strange already -- I haven't really looked at the code to understand what's going on. I hate all those damned macros! I can have a look tomorrow afternoon... Gunnar From owner-xemacs-beta@xemacs.org Wed Jul 7 13:57:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA11935 for xemacs-beta-out; Wed, 7 Jul 1999 13:57:44 -0400 Received: from exchange1.primus.com (mail.primus.com [206.253.199.54]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA11932 for ; Wed, 7 Jul 1999 13:57:37 -0400 Received: by exchange1.primus.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jul 1999 10:55:25 -0700 Message-ID: <228F2F40E87CD211ABA20008C7B13C5A17DD46@exchange1.primus.com> From: Damon Lipparelli To: "'xemacs-beta@xemacs.org'" Subject: 21.2-b17: can't build from latest CVS source Date: Wed, 7 Jul 1999 10:55:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEC8A1.E3AA0394" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEC8A1.E3AA0394 Content-Type: text/plain; charset="iso-8859-1" I updated my CVS tree this morning and now I can't build with the following configuration: <> It looks like "console-x.h" only defines FRAME_X_XIC() when HAVE_XIM & XIM_XLIB are defined. But, "event-Xt.c" uses FRAME_X_XIC() in many places just protected by HAVE_XIM; should these also be protected by XIM_XLIB? -lipp ------_=_NextPart_000_01BEC8A1.E3AA0394 Content-Type: text/plain; name="ins-21.2-b17-nodebug.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ins-21.2-b17-nodebug.txt" uname -a: SunOS roy 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-1=0A= =0A= ./configure '--site-includes=3D/usr/local/include' = '--site-libraries=3D/usr/local/sun4/lib' = '--prefix=3D/users/lipp/xemacs-beta/21.2' '--with-sound=3Dnone' = '--with-workshop' '--with-mule' '--debug=3Dno' = '--error-checking=3Dnone'=0A= =0A= =0A= XEmacs 21.2-b17 "Chiyoda" configured for `sparc-sun-solaris2.5.1'.=0A= =0A= Where should the build process find the source code? = /users/lipp/src/xemacs-beta/xemacs-21.2=0A= What installation prefix should install use? = /users/lipp/xemacs-beta/21.2=0A= What operating system and machine description files should XEmacs = use?=0A= `s/sol2.h' and `m/sparc.h'=0A= What compiler should XEmacs be built with? gcc -g -O3 = -Wall -Wno-switch=0A= Should XEmacs use the GNU version of malloc? yes=0A= Should XEmacs use the relocating allocator for buffers? yes=0A= What window system should XEmacs use? x11=0A= Where do we find X Windows header files? = /usr/dt/include /usr/openwin/include=0A= Where do we find X Windows libraries? /usr/dt/lib = /usr/openwin/lib=0A= Additional header files: = /usr/local/include=0A= Additional libraries: = /usr/local/sun4/lib=0A= Runtime library search path: = /usr/local/sun4/lib:/usr/dt/lib:/usr/openwin/lib:/usr/local/sun4/sparc-s= un-solaris2.5.1/lib=0A= Compiling in support for XAUTH.=0A= Compiling in support for XPM images.=0A= Compiling in support for PNG image handling.=0A= Compiling in support for (builtin) GIF image handling.=0A= Compiling in support for JPEG image handling.=0A= Compiling in support for TIFF image handling.=0A= Compiling in support for X-Face message headers.=0A= Compiling in support for GNU DBM.=0A= Compiling in Mule (multi-lingual) support.=0A= Compiling in XIM (X11R5+ I18N input method) support.=0A= Using Motif to provide XIM support.=0A= Compiling in support for CDE.=0A= Compiling in support for ToolTalk.=0A= Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ).=0A= Compiling in support for Sun WorkShop.=0A= Compiling in support for proper WM_COMMAND handling.=0A= Using Lucid menubars.=0A= Using Lucid scrollbars.=0A= Using Motif dialog boxes.=0A= Compiling in DLL support.=0A= movemail will use "dot-locking" for locking mail spool files.=0A= =0A= ------_=_NextPart_000_01BEC8A1.E3AA0394-- From owner-xemacs-beta@xemacs.org Wed Jul 7 19:43:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA24533 for xemacs-beta-out; Wed, 7 Jul 1999 19:43:04 -0400 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 TAA24529 for ; Wed, 7 Jul 1999 19:42:56 -0400 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 TAA05028; Wed, 7 Jul 1999 19:48:37 -0400 (EDT) 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 BAA01620; Thu, 8 Jul 1999 01:41:46 +0200 (MET DST) To: XEmacs Beta List Cc: "J. Kean Johnston" Subject: batch-texinfo-format cannot handle emodules.texi 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 Jul 1999 01:37:39 +0200 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi All, except for the following problem I have succeeded to upgrade xemacs.mak to build all info files natively on Windows NT without makeinfo.exe. I somebody feeling like implementing @macro in texinfmt.el? Even a partial implementation without argument handling would suffice for the problem at hand. Regards, Adrian ..\src\xemacs.exe -no-site-file -no-init-file -batch -l texinfmt -f batch-texinfo-format ..\man\emodules.texi texinfo formatting e:\export\home\tmp\21.2\xemacs\man\emodules.texi... Formatting Info file... Formatting Info file: ../info/emodules.info Converting emodules.texi to Info format... Removing trailing whitespace from Info buffer... >> Error: (error "@macro is not handled by texinfo") >> point at >> emacs >> XEmacs@refill >> @end macro >> @clear EMACS >> @set HAVE_EMACS >> @end ifset >> @ifset EMACS >> @macro emacs >> E From owner-xemacs-beta@xemacs.org Wed Jul 7 23:01:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA29765 for xemacs-beta-out; Wed, 7 Jul 1999 23:01:25 -0400 Received: from smtp1.mindspring.com (smtp1.mindspring.com [207.69.200.31]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA29760 for ; Wed, 7 Jul 1999 23:01:23 -0400 Received: from ashanti.mastaler.com (pool-207-205-180-34.phnx.grid.net [207.205.180.34]) by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id XAA31577 for ; Wed, 7 Jul 1999 23:01:16 -0400 (EDT) Date: Wed, 7 Jul 1999 23:01:16 -0400 (EDT) Message-Id: <199907080301.XAA31577@smtp1.mindspring.com> Received: (qmail 5137 invoked from network); 8 Jul 1999 02:58:53 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 8 Jul 1999 02:58:53 -0000 From: Jason R Mastaler To: xemacs-beta@xemacs.org Subject: [mailcrypt problem] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-linux Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The build went fine, but for some reason 21.2-b17 doesn't like the mailcrypt stuff I have in my .emacs: ;;; Mailcrypt (load-library "mailcrypt") (mc-setversion "gpg") ; GNU Privacy Guard (autoload 'mc-install-write-mode "mailcrypt" nil t) (autoload 'mc-install-read-mode "mailcrypt" nil t) (add-hook 'mail-mode-hook 'mc-install-write-mode) If I comment out the (mc-setversion "gpg"), I have no problems, but with that line in I get the following error. FWIW, XEmacs 21.1.2 has no problem with this. Any idea what the problem is? Signaling: (void-function mc-setversion) (mc-setversion "gpg") ) (cond ((and running-xemacs ...) (load "gnus-setup" t t) (require ...) (load-library "mailcrypt") (mc-setversion "gpg") (autoload ... "mailcrypt" nil t) (autoload ... "mailcrypt" nil t) (add-hook ... ...) (require ...) (bbdb-initialize ... ...) (setq bbdb-default-area-code 505) (setq bbdb-notice-hook ...) (setq bbdb-auto-notes-alist ...))) ) load-internal("~/.emacs" t t t undecided) load("~/.emacs" t t t) load-user-init-file("") load-init-file() command-line() normal-top-level() > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /home/jason/xemacs/beta/build/Installation: > (Output from most recent run of ./configure) uname -a: Linux bodhi.mastaler.com 2.2.5-15 #1 Mon Apr 19 23:00:46 EDT 1999 i686 unknown /usr/local/src/xemacs-21.2/configure '--prefix=/home/jason/xemacs/beta/v21' '--package-path=/home/jason/xemacs/beta/packages' '--with-dialogs=athena3d' '--with-sound=native' '--mail-locking=flock' '--with-mule' '--error-checking=none' '--debug=no' XEmacs 21.2-b17 "Chiyoda" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.2 What installation prefix should install use? /home/jason/xemacs/beta/v21 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 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 dialog boxes. Compiling in DLL support. movemail will use "flock" for locking mail spool files. > /home/jason/xemacs/beta/build/beta.err does not exist! From owner-xemacs-beta@xemacs.org Wed Jul 7 23:55:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA31083 for xemacs-beta-out; Wed, 7 Jul 1999 23:55:45 -0400 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 XAA31079 for ; Wed, 7 Jul 1999 23:55:39 -0400 Received: from mithril (ethersoft.ne.mediaone.net [24.128.29.147]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id XAA06955 for ; Wed, 7 Jul 1999 23:55:25 -0400 (EDT) Date: Wed, 7 Jul 1999 23:55:25 -0400 (EDT) Message-Id: <199907080355.XAA06955@chmls05.mediaone.net> Mail-Copies-To: Never From: "XEmacs Build 'Bot" Subject: XEmacs Build Report for XEmacs-21.1.4 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.4 for distribution. I have tested the attached configuration. Have a great day! Sincerely, The XEmacs Build 'Bot (revision 2) -- uname -a: Linux mithril 2.2.10-ac8 #1 SMP Mon Jul 5 19:49:13 EDT 1999 i686 unknown ./configure '--prefix=/home/acs/cvsroot' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.1.4 "Arches" 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 GNU DBM. 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 Wed Jul 7 23:59:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA31339 for xemacs-beta-out; Wed, 7 Jul 1999 23:59:31 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA31336 for ; Wed, 7 Jul 1999 23:59:30 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id XAA29865 for ; Wed, 7 Jul 1999 23:59:01 -0400 (EDT) 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 UAA21202 for ; Wed, 7 Jul 1999 20:58:19 -0700 (PDT) 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 UAA08937 for ; Wed, 7 Jul 1999 20:59:26 -0700 (PDT) Message-Id: <199907080359.UAA08937@mina.sr.hp.com> To: xemacs-beta@xemacs.org Subject: HP-UX 10.20 build failure w/workaround Reply-To: Darryl Okahata Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 Jul 1999 20:59:25 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [ Note: I'm sending this message to get it into the archives, so that others will hopefully not waste hours tracking this down. ] [ Note^2: although I work for HP, the following is *UNOFFICIAL* and *UNSUPPORTED*. This merely reflects my own personal experiences in trying to get XEmacs working under HP-UX. ] ***** Problem: Under HP-UX 10.20, with native audio enabled, the undumped XEmacs binary core dumps when run (temacs runs fine). This, of course, causes the XEmacs build to fail. If GNU malloc is enabled, a stack trace will show XEmacs to have crashed in the first call to malloc(). This bug currently exists in all versions of XEmacs. ***** Cause: Recent versions of the HP-UX 10.20 audio shared library (in /opt/audio/lib), pulls in the libdce shared library, which pulls in a thread (libcma) library. This exposes a bug in the HP-UX undump() routine (in unexhp9k800.c). The result is that the libcma library truncates the data segment at startup (before main() is entered!), which quickly causes XEmacs to crash. [ The issue is that the libcma library is somehow computing an address just past the end of BSS, and this address is wrong, probably because unexhp9k800.c has not fixed up all of the necessary headers in the undumped executable. (Unfortunately, I've stared and stared at the headers, and I can't tell what needs to be fixed.) ] I believe versions of the audio library past December 1998 will trigger this problem, and I believe that you have to install audio library patches to encounter this. I'm not sure, but I think the audio patch PHSS_17121 (or a superceeding one, like PHSS_17554, PHSS_17971, or PHSS_18777, etc.) will trigger this. To check if your audio library will cause problems for XEmacs, run "chatr /opt/audio/lib/libAlib.sl". If "libdce" appears in the displayed shared library list, XEmacs will probably encounter problems if audio is enabled. ***** Workaround: Don't enable audio. Re-run configure without audio support. ***** Fix: Unfortunately, I don't have one, and I don't know if I ever will. Perhaps someone else will come up with one. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Thu Jul 8 01:06:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA00998 for xemacs-beta-out; Thu, 8 Jul 1999 01:06:30 -0400 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA00995 for ; Thu, 8 Jul 1999 01:06:28 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19990602200837) with ESMTP id OAA05271 for ; Thu, 8 Jul 1999 14:06:26 +0900 (JST) Received: from mule.m17n.org (steve@mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990514193409) with ESMTP id OAA13170 for ; Thu, 8 Jul 1999 14:06:24 +0900 (JST) Received: (from steve@localhost) by mule.m17n.org (8.9.2/3.7W-19990512194415) id OAA20966; Thu, 8 Jul 1999 14:06:23 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [mailcrypt problem] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-linux References: <199907080301.XAA31577@smtp1.mindspring.com> X-Attribution: sb From: SL Baur In-Reply-To: Jason R Mastaler's message of "Wed, 7 Jul 1999 23:01:16 -0400 (EDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 08 Jul 1999 14:06:23 +0900 Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jason R Mastaler writes in xemacs-beta@xemacs.org: > The build went fine, but for some reason 21.2-b17 doesn't like the > mailcrypt stuff I have in my .emacs: Uh oh. > ;;; Mailcrypt > (load-library "mailcrypt") > (mc-setversion "gpg") ; GNU Privacy Guard > (autoload 'mc-install-write-mode "mailcrypt" nil t) > (autoload 'mc-install-read-mode "mailcrypt" nil t) > (add-hook 'mail-mode-hook 'mc-install-write-mode) > If I comment out the (mc-setversion "gpg"), I have no problems, but > with that line in I get the following error. FWIW, XEmacs 21.1.2 has > no problem with this. Any idea what the problem is? No. It is possible that Gnus, etc. need rebuilding with the new mailcrypt in place, but if that was your problem, you would have the same behavior on 21.1 as 21.2. -- $BG=$"$kBk$OD^$r1#$9(B (A wise man keeps some of his talents in reserve) From owner-xemacs-beta@xemacs.org Thu Jul 8 02:48:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA03512 for xemacs-beta-out; Thu, 8 Jul 1999 02:48:09 -0400 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA00899 for xemacs-announce-out; Thu, 8 Jul 1999 01:02:17 -0400 To: xemacs-announce@xemacs.org Subject: XEmacs 21.1.4 (Arches) is released From: Vin Shelton Organization: The XEmacs Development Team Date: 08 Jul 1999 00:43:18 -0400 Message-ID: Lines: 60 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: I have uploaded XEmacs-21.1.4 to ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-elc.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-info.tar.gz Arches is an incredibly beautiful US National Park located in New Mexico. For more information see: http://www.nps.gov:80/arch. Here is the list of patches which have been applied since 21.1.3. Subject: Re: Making docdir configurable From: sperber@Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) Message-ID: Subject: fiddly Martin-style comment patch From: SL Baur Message-ID: Subject: bug in report XEmacs bug From: SL Baur Message-ID: Subject: lisp/wid-edit.el: Speling error. From: karlheg Message-ID: <87zp1qib0t.fsf@bittersweet.sysc.pdx.edu> Subject: Re: zombies on Solaris 2.5[.1] with 21.1.3 From: Gunnar Evermann Message-ID: Subject: assemble-list, or: yet another lost patch From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Message-ID: Subject: Re: Add {q} command to completion-list-mode. From: SL Baur Message-ID: Subject: [Bob Weiner ] Patch to fix docstring for completion-list-mode. From: SL Baur Message-ID: Subject: [Bob Weiner ] Simple but important patch for comment auto-filling. From: SL Baur Message-ID: Subject: Re: XEmacs-21.1.4 Ready to Go From: SL Baur Message-ID: In addition to those changes, I ran 'make config' to update our configuration files, and I made a minor patch to src/config.h.in, following the recommendation of Olivier Galibert. I hope this all works; I will be out of touch starting tomorrow afternoon until Tuesday evening. - vin From owner-xemacs-beta@xemacs.org Thu Jul 8 04:36:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA06050 for xemacs-beta-out; Thu, 8 Jul 1999 04:36:49 -0400 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 EAA06047 for ; Thu, 8 Jul 1999 04:36:48 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA01707 for ; Thu, 8 Jul 1999 10:36:47 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000Qd; Thu Jul 8 10:36:45 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA15372; Thu, 8 Jul 1999 10:36:44 +0200 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jan Vroonhof Date: 08 Jul 1999 10:36:42 +0200 In-Reply-To: Vin Shelton's message of "08 Jul 1999 00:43:18 -0400" 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: Vin Shelton writes: > I have uploaded XEmacs-21.1.4 to ftp.xemacs.org. Get it from: Will somebody be making usenet announcements, updating freshmeat and the website? Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 04:39:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA06112 for xemacs-beta-out; Thu, 8 Jul 1999 04:39:31 -0400 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 EAA06109 for ; Thu, 8 Jul 1999 04:39:29 -0400 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id KAA31343; Thu, 8 Jul 1999 10:39:27 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.1.3 build failure on RedHat 6.0 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_Thu_Jul__8_10:39:19_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 08 Jul 1999 10:39:26 +0200 In-Reply-To: Gunnar Evermann's message of "Wed, 7 Jul 1999 15:48:42 +0100 (BST)" Message-ID: Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 21.2(beta13) - "Demeter" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Thu_Jul__8_10:39:19_1999-1 Content-Type: text/plain; charset=US-ASCII >>>>> "Gunnar" == Gunnar Evermann writes: Gunnar> I have been building various configurations and I only get this problem if Gunnar> building with union type, -O (or higher) and pentiumpro (either just -mcpu Gunnar> or -march as well) It fails for me when building with bare '-g -O' flags (no -march nor -mcpu) Oscar --pgp-sign-Multipart_Thu_Jul__8_10:39:19_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBN4RjvJ7CaiYEgqPZAQGD4QIArDgYvTBDZkyLP61kbkNVgVg6E8MpvINr xUEYOadyBBbfMDhcqMn6TIvYwgzADCBeeMKXXSDW+D4l8gHE1VMveQ== =UmVM -----END PGP MESSAGE----- --pgp-sign-Multipart_Thu_Jul__8_10:39:19_1999-1-- From owner-xemacs-beta@xemacs.org Thu Jul 8 04:54:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA06499 for xemacs-beta-out; Thu, 8 Jul 1999 04:54:15 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA06496 for ; Thu, 8 Jul 1999 04:54:13 -0400 Received: from metheny.enst.fr (VIN0AneR1kSc5j09g9+OQn5TxRGjTVXV@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id KAA28798; Thu, 8 Jul 1999 10:54:12 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id KAA21710; Thu, 8 Jul 1999 10:54:09 +0200 (MET DST) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) 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: Jan Vroonhof's message of "08 Jul 1999 10:36:42 +0200" 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: 19 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > Vin Shelton writes: > > > I have uploaded XEmacs-21.1.4 to ftp.xemacs.org. Get it from: > > Will somebody be making usenet announcements, updating freshmeat and > the website? I haven't announced any patch level release on usenet and it was not my intention to do so. Do you think it's worth it ? I'm reluctant to spam usenet each time a new such release is done because they come rather quickly one after each other. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 8 05:15:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA07317 for xemacs-beta-out; Thu, 8 Jul 1999 05:15:52 -0400 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 FAA07314 for ; Thu, 8 Jul 1999 05:15:50 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA04479; Thu, 8 Jul 1999 11:15:49 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0015g; Thu Jul 8 11:15:45 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15686; Thu, 8 Jul 1999 11:15:44 +0200 To: xemacs-beta@xemacs.org Cc: never.$J=.i&Al'?@math.ethz.ch, "ax]MZd4tcm)_wF3$n*:f/lgS.;?Jr3T;Fl^q" Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jan Vroonhof Date: 08 Jul 1999 11:15:43 +0200 In-Reply-To: Didier Verna's message of "08 Jul 1999 10:54:08 +0200" 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: Didier Verna writes: > I haven't announced any patch level release on usenet and it was not > my intention to do so. Do you think it's worth it ? I'm reluctant to spam > usenet each time a new such release is done because they come rather quickly > one after each other. OK, agreed. Updates on the web site and Freshmeat would be nice though. Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 05:20:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA07553 for xemacs-beta-out; Thu, 8 Jul 1999 05:20:00 -0400 Received: from mail.rdc1.ct.home.com (ha1.rdc1.ct.home.com [24.2.0.66]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA07548; Thu, 8 Jul 1999 05:19:59 -0400 Received: from pobox.com ([24.228.14.150]) by mail.rdc1.ct.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990708091955.PXZS24824.mail.rdc1.ct.home.com@pobox.com>; Thu, 8 Jul 1999 02:19:55 -0700 Message-ID: <37846D3B.463125BC@pobox.com> Date: Thu, 08 Jul 1999 05:19:55 -0400 From: "John A. Turner" X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org CC: xemacs-announce@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin Shelton wrote: > > I have uploaded XEmacs-21.1.4 to ftp.xemacs.org. Get it from: > > ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4.tar.gz > ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-elc.tar.gz > ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-info.tar.gz > > Arches is an incredibly beautiful US National Park located in New > Mexico. For more information see: http://www.nps.gov:80/arch. Utah, actually... but still incredibly beautiful... -John From owner-xemacs-beta@xemacs.org Thu Jul 8 07:59:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA10978 for xemacs-beta-out; Thu, 8 Jul 1999 07:59:36 -0400 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 HAA10967 for ; Thu, 8 Jul 1999 07:58:21 -0400 Received: from brabantio.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 NAA19738; Thu, 8 Jul 1999 13:57:57 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id NAA26390; Thu, 8 Jul 1999 13:57:56 +0200 To: xemacs-beta@xemacs.org Cc: never.$J=.i&Al'?@informatik.uni-tuebingen.de, "ax]MZd4tcm)_wF3$n*":"f/lgS.;?Jr3T;Fl^q" Subject: Re: XEmacs 21.1.4 (Arches) is released 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: 08 Jul 1999 13:57:55 +0200 In-Reply-To: Didier Verna's message of "08 Jul 1999 10:54:08 +0200" Message-ID: Lines: 30 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 HAA10976 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> Jan Vroonhof writes: >> Vin Shelton writes: >> >> > I have uploaded XEmacs-21.1.4 to ftp.xemacs.org. Get it from: >> >> Will somebody be making usenet announcements, updating freshmeat and >> the website? dv> I haven't announced any patch level release on usenet and it was not dv> my intention to do so. Do you think it's worth it ? I'm reluctant to spam dv> usenet each time a new such release is done because they come rather quickly dv> one after each other. I think we should absolutely announce them, at least on comp.emacs.xemacs. Every idiot posts his questions on usenet. Especially since a lot of people have gotten the impression we're sitting on our asses over the 21.0 announcement disaster. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 8 08:20:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11356 for xemacs-beta-out; Thu, 8 Jul 1999 08:20:09 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11344; Thu, 8 Jul 1999 08:19:55 -0400 Received: from metheny.enst.fr (ercDgN5uAku3YNLaXUiHyB/Ish6UQvgL@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id OAA07601; Thu, 8 Jul 1999 14:19:54 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id OAA21823; Thu, 8 Jul 1999 14:19:51 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: acs@xemacs.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) 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: sperber@informatik.uni-tuebingen.de's message of "08 Jul 1999 13:57:55 +0200" 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: 20 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Chiyoda) 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: > I think we should absolutely announce them, at least on > comp.emacs.xemacs. Every idiot posts his questions on usenet. > Especially since a lot of people have gotten the impression we're > sitting on our asses over the 21.0 announcement disaster. That's ok with me. Perhaps we could make different annoucements for them. Shorter, saying to get it at the usual place and with a brief overview of what's changed. Vin, you're probably the guy who should care for it aren't you ? If you're not willing to post on usenet, I can forward your messages to xemacs-announce on the newsgroup. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 8 08:29:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11602 for xemacs-beta-out; Thu, 8 Jul 1999 08:29:40 -0400 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 IAA11599 for ; Thu, 8 Jul 1999 08:29:36 -0400 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 IAA10515 for ; Thu, 8 Jul 1999 08:35:21 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id OAA27408; Thu, 8 Jul 1999 14:29:27 +0200 (MET DST) To: XEmacs Beta List Subject: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 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 Jul 1999 14:24:04 +0200 Message-ID: Lines: 112 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Built from CVS on natively on Windows NT. Built info docs using my modifications to nt/xemacs.mak to generate info docs with XEmacs itself (no requirement to install texinfo). I believe a 21.2 bug which broke face specifiers has infiltrated 21.1.4. I cannot customize font-lock-comment-face to be bold after loading sample.emacs. Jan fixed this bug for 21.2-b17++. I'll see whether the fix works for 21.1.4 too. Regards, Adrian > XEmacs Build Report as generated with > M-x build-report RET > by build-report-version $Revision: 1.1.1.1 $ follows: > Contents of e:\export\home\tmp\21.1\xemacs\nt\Installation: > (Output from most recent run of ./configure) OS: Windows_NT XEmacs 21.1.4 \"Arches\" configured for `i386-pc-win32'. Where should the build process find the source code? e:\\export\\home\\tmp\\21.1\\xemacs\\nt What compiler should XEmacs be built with? @cl -nologo What window system should XEmacs use? MS Windows > Contents of e:\export\home\tmp\21.1\xemacs\nt\xemacs-make-install.err > keeping lines matching > "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" > and then deleting lines matching > "confl.*with.*auto-inlining" cd e:\export\home\tmp\21.1\xemacs\nt\ nmake /f xemacs.mak HAVE_XPM="1" HAVE_PNG="1" HAVE_TIFF="1" HAVE_JPEG="1" USE_UNION_TYPE="1" COMPFACE_DIR="e:\\export\\home\\tmp\\libs4xemacs\\compface" JPEG_DIR="e:\\export\\home\\tmp\\libs4xemacs\\jpeg-6b" TIFF_DIR="e:\\export\\home\\tmp\\libs4xemacs\\tiff-v3.4" ZLIB_DIR="e:\\export\\home\\tmp\\libs4xemacs\\zlib" PNG_DIR="e:\\export\\home\\tmp\\libs4xemacs\\libpng-1.0.2" XPM_DIR="e:\\export\\home\\tmp\\libs4xemacs\\xpm-3.4k" install Compilation started at Thu Jul 08 12:22:22 1999 Compiling in support for native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for native sounds. Compiling in fast dired implementation. Using union type for Lisp object storage. 1 file(s) copied. Using load-path (..\lisp) Note: Strange doc (not fboundp) for function make-symbolic-link @ 678272 Purespace usage: 637284 of 637284 (100%). Installing in c:\Program Files\XEmacs\XEmacs-21.1.4 ... 1 File(s) copied 1 File(s) copied 7 File(s) copied 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. 388 File(s) copied 127 File(s) copied 322 File(s) copied 1 File(s) copied 1 File(s) copied 1 File(s) copied Compilation finished at Thu Jul 08 12:24:55 > Contents of e:\export\home\tmp\21.1\xemacs\nt\xemacs-make-info.err > keeping lines matching > "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" > and then deleting lines matching > "confl.*with.*auto-inlining" cd e:\export\home\tmp\21.1\xemacs\nt\ nmake /d /f xemacs.mak info Compilation started at Thu Jul 08 12:13:17 1999 Compiling in support for native GUI. Compiling in support for GIF images. Compiling in support for dialogs. Compiling in support for native sounds. Compiling in fast dired implementation. Formatting: @code{@@error@{@}} (@error{}): Indicating an Error Message ... Formatting: Installing an Info File ... Formatting: Installing Info Directory Files ... Formatting: @code{makeinfo} Find Errors ... Formatting: Catching Errors with Info Formatting ... Formatting: Catching Errors with @TeX{} Formatting ... ..\man\lispref\errors.texi Sun Sep 06 05:11:15 1998 1 file(s) copied. Reading included file: e:\export\home\tmp\21.1\xemacs\man\lispref\errors.texi Formatting: Error Messages ... Formatting: Errors ... Formatting: How to Signal an Error ... Formatting: How XEmacs Processes Errors ... Formatting: Writing Code to Handle Errors ... Formatting: Error Symbols and Condition Names ... Formatting: Entering the Debugger on an Error ... Formatting: Trapping Errors ... Formatting: Warnings ... Formatting: Standard Errors ... 1 file(s) copied. Formatting: Pure Space ... Compilation finished at Thu Jul 08 12:15:33 From owner-xemacs-beta@xemacs.org Thu Jul 8 09:17:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA13366 for xemacs-beta-out; Thu, 8 Jul 1999 09:17:38 -0400 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA13362 for ; Thu, 8 Jul 1999 09:17:36 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id JAA23175 for ; Thu, 8 Jul 1999 09:17:18 -0400 (EDT) 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 GAA11989 for ; Thu, 8 Jul 1999 06:16:24 -0700 (PDT) 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 GAA00148 for ; Thu, 8 Jul 1999 06:17:31 -0700 (PDT) Message-Id: <199907081317.GAA00148@mina.sr.hp.com> To: xemacs-beta@xemacs.org Subject: HP-UX 10.20 build issues Reply-To: Darryl Okahata In-reply-to: Your message of "Wed, 07 Jul 1999 20:59:25 PDT." <199907080359.UAA08937@mina.sr.hp.com> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Jul 1999 06:17:30 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [ Note: I'm sending this message to get it into the archives, so that others will hopefully not waste hours tracking this down. ] [ Note^2: although I work for HP, the following is *UNOFFICIAL* and *UNSUPPORTED*. This merely reflects my own personal experiences in trying to get XEmacs working under HP-UX. ] OK, I've tracked down the exact cause of my recent build failures with HP-UX 10.20 and XEmacs, but I'm not sure what to do about it. The basic problem is that the undumped XEmacs binary immediately dumps core when run. The cause is, basically, due to recent versions of the audio shared library pulling in the libdce library, which pulls in the libcma threads library. The libcma threads library redefines _start and calls sbrk() (*before* main() is called!) before XEmacs has had a chance to properly adjust the brk() value (via Restore_Shared_Data() in src/unexhp9k800.c). The result is that the call to sbrk() truncates the data segment. To not crash, the undumped XEmacs binary needs to adjust the brk() value, but it's never getting a chance to do so, as libcma is calling sbrk() before main() is even entered. To encounter this crash, you must have enabled native sound in XEmacs and be using a recent version of the audio shared library. Older versions do not pull in the libdce library. I believe versions of the audio library past December 1998 will trigger this problem, and I believe that you have to install audio library patches to encounter this. I'm not sure, but I think the audio patch PHSS_17121 (or a superceeding one, like PHSS_17554, PHSS_17971, or PHSS_18777, etc.) will trigger this. To check if your audio library will cause problems for XEmacs, run "chatr /opt/audio/lib/libAlib.sl". If "libdce" appears in the displayed shared library list, XEmacs will probably encounter problems if audio is enabled. Disabling the use of shared libraries (i.e., use all archive libraries only) is an obvious solution, but the HP-UX audio library only comes in shared form; a static archive version is not available. Unfortunately, without resorting to some really ugly code, I think this means that XEmacs can no longer use recent/newer versions of the audio library under HP-UX 10.20; native audio can no longer be used. I guess the "fix" is to not enable native audio. I don't know if this issue exists under HP-UX 11.0. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Thu Jul 8 09:21:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA13520 for xemacs-beta-out; Thu, 8 Jul 1999 09:21:59 -0400 Received: from taurus.cus.cam.ac.uk (taurus.cus.cam.ac.uk [131.111.8.48]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA13517 for ; Thu, 8 Jul 1999 09:21:57 -0400 Received: from ge204 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 3.02 #4) id 112E7c-0001H2-00; Thu, 08 Jul 1999 14:21:52 +0100 Date: Thu, 8 Jul 1999 14:21:51 +0100 (BST) From: Gunnar Evermann To: xemacs-beta@xemacs.org cc: "G. Evermann" Subject: Re: XEmacs 21.1.4 (Arches) is released In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 8 Jul 1999, Michael Sperber [Mr. Preprocessor] wrote: > I think we should absolutely announce them, at least on > comp.emacs.xemacs. Every idiot posts his questions on usenet. > Especially since a lot of people have gotten the impression we're > sitting on our asses over the 21.0 announcement disaster. definitely! We really need to encourage people to upgrade to the latest version. We still get bug reports for stuff as old as 19.14. If one announcement about 21.1.x every other week helps to get rid of those I am all for posting it. In my opinion we should rethink our presence on c.e.x (or our PR in general). I makes me very sad if the public perception of the XEmacs team is a bunch of debian-bashing hackers who don't care about their user base. I do answer a lot of questions on c.e.x (either on the list or more often by email) and so do some others (especially Jan and Hrvoje come to mind). I suggest we adopt a slightly modified policy on this: - whenever possible send the first followup to a question to c.e.x and offer to sort out detailed problems via email (I think I'm currently helping three people through the XEmacs install process). This also avoids duplication of effort (e.g. if Jan already told someone to read README.packages then I don't have to repeat that). - always use a @xemacs.org address and an associated .sig (I think Ben suggested this a long time ago) - don't drag the XEmacs team into flamewars involving debian :-) (I am not saying that Per or Hrvoje did that, but some people got the impression that the XEmacs team has problems with Debian -- As far as I know we dont't, especially when Karl takes over xemacs21.deb) - Always keep the www and ftp sites up to date. It's really a shame if the message on the web site, the .message in on the FTP site and the README in the same directory all give different "current versions" -- this should really all be handled automatically. Any comments? Gunnar P.S.: who is the keeper of the @xemacs.org aliases/accounts? From owner-xemacs-beta@xemacs.org Thu Jul 8 09:52:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA14797 for xemacs-beta-out; Thu, 8 Jul 1999 09:52:15 -0400 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 JAA14793 for ; Thu, 8 Jul 1999 09:52:11 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA26214 for ; Thu, 8 Jul 1999 15:52:10 +0200 (MET DST) Received: from midget(129.132.145.4) via SMTP by frege, id smtpdAAAa006PZ; Thu Jul 8 15:52:07 1999 Received: (vroonhof@localhost) by midget (SMI-8.6/D-MATH-client) id PAA08499; Thu, 8 Jul 1999 15:52:07 +0200 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jan Vroonhof Date: 08 Jul 1999 15:52:06 +0200 In-Reply-To: Gunnar Evermann's message of "Thu, 8 Jul 1999 14:21:51 +0100 (BST)" Message-ID: Lines: 34 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: Gunnar Evermann writes: > - always use a @xemacs.org address and an associated .sig (I think Ben > suggested this a long time ago) I have a problem with that. The address I use on Usenet has a spam filter on it. I prefer not to post with official contact addresses. > - don't drag the XEmacs team into flamewars involving debian :-) Something went horribly wrong there. Imperfections of e-mail communication I guess. > (I am > not saying that Per or Hrvoje did that, but some people got the > impression that the XEmacs team has problems with Debian -- As far > as I know we dont't, In fact I have had a good relationship with the current maintainer. The main problem is that he has too little time, but don't we all. As for not forwarding bug reports. He knows I scan the debian bug archive from time to time so I think he is forgiven for not doing that. It used to be that the Debian bug tracking system was the only decent archive of XEmacs bugs there was. > especially when Karl takes over xemacs21.deb) I have more 'problems' with Karl :-) He has _too much_ time (Hi Karl!) . I send him a mail asking him to stay conservative with the changes. I do hope he implements that ~/.xemacs stuff, just that we put it into 21.2 first. Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 10:01:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA15198 for xemacs-beta-out; Thu, 8 Jul 1999 10:01:58 -0400 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 KAA15195 for ; Thu, 8 Jul 1999 10:01:55 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA27404 for ; Thu, 8 Jul 1999 16:01:52 +0200 (MET DST) Received: from midget(129.132.145.4) via SMTP by frege, id smtpdAAAa006g6; Thu Jul 8 16:01:49 1999 Received: (vroonhof@localhost) by midget (SMI-8.6/D-MATH-client) id QAA08534; Thu, 8 Jul 1999 16:01:48 +0200 To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 References: From: Jan Vroonhof Date: 08 Jul 1999 16:01:48 +0200 In-Reply-To: Adrian Aichner's message of "08 Jul 1999 14:24:04 +0200" 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: Adrian Aichner writes: > Built from CVS on natively on Windows NT. > Built info docs using my modifications to nt/xemacs.mak to generate > info docs with XEmacs itself (no requirement to install texinfo). > > I believe a 21.2 bug which broke face specifiers has infiltrated > 21.1.4. Are you sure you checked out 21.1.4? My specifier based custom stuff isn't in 21.1.x (I checked using cvsweb: faces.el has stayed the same all the time) > Jan fixed this bug for 21.2-b17++. I'll see whether the fix works for > 21.1.4 too. So it works for you, that is nice. Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 10:02:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA15217 for xemacs-beta-out; Thu, 8 Jul 1999 10:02:13 -0400 Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.10.126]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA15204; Thu, 8 Jul 1999 10:02:09 -0400 Received: from localhost.icd.teradyne.com (localhost.icd.teradyne.com) by ICD.Teradyne.COM (8.8.5/8.8.5) with SMTP id JAA16099; Thu, 8 Jul 1999 09:56:03 -0400 (EDT) Received: by dusk1.afive (SMI-8.6/SMI-SVR4) id KAA10167; Thu, 8 Jul 1999 10:01:15 -0400 To: xemacs-beta@xemacs.org, xemacs-announce@xemacs.org Newsgroups: comp.emacs.xemacs From: Vin Shelton Organization: The XEmacs Development Team Subject: XEmacs 21.1.4 (Arches) is Released Date: 08 Jul 1999 10:01:13 -0400 Message-ID: <5451zejz1ee.fsf@dusk1.icd.teradyne.com> Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: comp.emacs.xemacs Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. XEmacs-21.1.4 is available from ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-elc.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-info.tar.gz This is a bugfix release. Several miscellaneous bugs have been fixed. Probably the most significant is a fix Gunnar Everman made to prevent zombie processes when running XEmacs with tooltalk support; see http://www.xemacs.org/list-archives/xemacs-patches/9907/msg00006.html for more details. In addition, Michael Sperber submitted a patch to make docdir user-configurable. The 21.1.x series of releases is being named for US National Parks. Arches is an incredibly beautiful US National Park located in Utah. For more information see: http://www.nps.gov:80/arch. Vin Shelton From owner-xemacs-beta@xemacs.org Thu Jul 8 10:15:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA15923 for xemacs-beta-out; Thu, 8 Jul 1999 10:15:44 -0400 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA15910; Thu, 8 Jul 1999 10:15:39 -0400 Received: from ioka.cs.utah.edu (ioka.cs.utah.edu [155.99.212.84]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id IAA29981; Thu, 8 Jul 1999 08:15:38 -0600 (MDT) Received: (from eeide@localhost) by ioka.cs.utah.edu (8.9.1/8.9.1) id IAA09469; Thu, 8 Jul 1999 08:15:38 -0600 (MDT) (envelope-from eeide@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14212.45706.516029.277678@ioka.cs.utah.edu> Date: Thu, 8 Jul 1999 08:15:38 -0600 (MDT) From: Eric Eide To: xemacs-beta@xemacs.org, xemacs-announce@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released In-Reply-To: Vin Shelton's message of , July 8 1999 References: X-Mailer: VM 6.62 under 20.4 "Emerald" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Vin> Arches is an incredibly beautiful US National Park located in New Vin> Mexico. For more information see: http://www.nps.gov:80/arch. Sorry, I can't let this pass --- Arches National Park is here in *Utah*. -- ------------------------------------------------------------------------------- Eric Eide . University of Utah Dept. of Computer Science http://www.cs.utah.edu/~eeide . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX From owner-xemacs-beta@xemacs.org Thu Jul 8 10:50:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA17282 for xemacs-beta-out; Thu, 8 Jul 1999 10:50:41 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA17267; Thu, 8 Jul 1999 10:50:08 -0400 Received: from hpbbse.bbn.hp.com (root@hpbbse.bbn.hp.com [15.136.26.26]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id KAA12619; Thu, 8 Jul 1999 10:49:34 -0400 (EDT) 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 PAA10437; Thu, 8 Jul 1999 15:49:51 +0100 (MEZ) Received: (from thiessel@localhost) by bbn.hp.com (8.8.6 (PHNE_15509)/8.8.6) id QAA00637; Thu, 8 Jul 1999 16:49:51 +0200 (METDST) From: Marcus Thiessel Message-ID: <14212.47759.107261.502191@gargle.gargle.HOWL> Date: Thu, 8 Jul 1999 16:49:51 +0200 (METDST) To: XEmacs Developers Subject: Re: HP-UX 10.20 build issues In-Reply-To: <199907081317.GAA00148@mina.sr.hp.com> References: <199907080359.UAA08937@mina.sr.hp.com> <199907081317.GAA00148@mina.sr.hp.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) 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: Darryl Okahata writes: > I don't know if this issue exists under HP-UX 11.0. Well, I tried once to include sound support but wasn't too excited about the result. So I decided not to use it. --Marcus From owner-xemacs-beta@xemacs.org Thu Jul 8 11:39:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA19305 for xemacs-beta-out; Thu, 8 Jul 1999 11:39:08 -0400 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 LAA19301 for ; Thu, 8 Jul 1999 11:39:05 -0400 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 LAA23235 for ; Thu, 8 Jul 1999 11:44:40 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id RAA28802; Thu, 8 Jul 1999 17:38:47 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", 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: 08 Jul 1999 17:33:25 +0200 In-Reply-To: Jan Vroonhof's message of "08 Jul 1999 16:01:48 +0200" Message-ID: Lines: 28 User-Agent: Gnus/5.070085 (Pterodactyl Gnus v0.85) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Adrian Aichner writes: >> Built from CVS on natively on Windows NT. >> Built info docs using my modifications to nt/xemacs.mak to generate >> info docs with XEmacs itself (no requirement to install texinfo). >> >> I believe a 21.2 bug which broke face specifiers has infiltrated >> 21.1.4. Jan> Are you sure you checked out 21.1.4? My specifier based custom stuff Yes, I just checked with cvs-examine. I have re-build and still see the problem. Jan> isn't in 21.1.x (I checked using cvsweb: faces.el has stayed the same Jan> all the time) >> Jan fixed this bug for 21.2-b17++. I'll see whether the fix works for >> 21.1.4 too. Jan> So it works for you, that is nice. Yes, your frob-face-property patch against 21.2-b17++ applied OK and fixed the problem for system-configuration "i586-pc-win32". Thanks! I just wanted to give it some testing before I got back to you. Jan> Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 12:00:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA19973 for xemacs-beta-out; Thu, 8 Jul 1999 12:00:12 -0400 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 MAA19965 for ; Thu, 8 Jul 1999 12:00:06 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA09385 for ; Thu, 8 Jul 1999 18:00:04 +0200 (MET DST) Received: from midget(129.132.145.4) via SMTP by frege, id smtpdAAAa002I8; Thu Jul 8 18:00:00 1999 Received: (vroonhof@localhost) by midget (SMI-8.6/D-MATH-client) id SAA08881; Thu, 8 Jul 1999 18:00:00 +0200 To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 References: From: Jan Vroonhof Date: 08 Jul 1999 18:00:00 +0200 In-Reply-To: Adrian Aichner's message of "08 Jul 1999 17:33:25 +0200" 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: Adrian Aichner writes: > Yes, your frob-face-property patch against 21.2-b17++ applied OK and > fixed the problem for system-configuration "i586-pc-win32". Thanks! I > just wanted to give it some testing before I got back to you. Ok thanks, I created the bug in the first place :-). copy-specifier could do with a better interface though. Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 17:15:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA30374 for xemacs-beta-out; Thu, 8 Jul 1999 17:15:15 -0400 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 RAA30370 for ; Thu, 8 Jul 1999 17:15:12 -0400 Received: by crystal.WonderWorks.COM id QQgxaj16921; Thu, 8 Jul 1999 14:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14213.5337.99734.417601@crystal.WonderWorks.COM> Date: Thu, 8 Jul 1999 14:15:04 -0700 (PDT) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) In-Reply-To: References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.72 under 21.2 (beta16) "Sumida" 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: SL Baur writes: > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > ... > > Note that no editor on 32-bit systems can grok a >2G buffer because of > > limited pointer size. Thus a 1G limit is just one step below the > > "theoretical" limit. You can argue that being two steps below it is > > not much worse, but I am not really convinced. > > O.K. Since size matters to you, how about another alternative? What > would/could we gain or lose by using long long as EMACS_INTs on 32 bit > architectures? We don't really have to use long long, we can mandate use of the union type and put a 32-bit integer into the Lisp_Object union. Lisp_Objects will necessarily be 64-bit objects at this point. The same can be done to get 32-bit characters, and we can have 32-bit integers and 32-bit characters in the same XEmacs. However, half of each Lisp_Object will be wasted. From owner-xemacs-beta@xemacs.org Thu Jul 8 18:35:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA32089 for xemacs-beta-out; Thu, 8 Jul 1999 18:13:43 -0400 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 SAA32078 for ; Thu, 8 Jul 1999 18:13:24 -0400 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 SAA10787 for ; Thu, 8 Jul 1999 18:18:59 -0400 (EDT) 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 AAA29515; Fri, 9 Jul 1999 00:13:08 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", 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: 09 Jul 1999 00:07:18 +0200 In-Reply-To: Jan Vroonhof's message of "08 Jul 1999 16:01:48 +0200" Message-ID: Lines: 46 User-Agent: Gnus/5.070085 (Pterodactyl Gnus v0.85) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Adrian Aichner writes: >> Built from CVS on natively on Windows NT. >> Built info docs using my modifications to nt/xemacs.mak to generate >> info docs with XEmacs itself (no requirement to install texinfo). >> >> I believe a 21.2 bug which broke face specifiers has infiltrated >> 21.1.4. Jan> Are you sure you checked out 21.1.4? My specifier based custom stuff After time travelling all the way back to 21.1-b2 I was convinced that all those verions can't be broken. Here's the scoop, Jan: When the problem (http://www.xemacs.org/list-archives/xemacs-beta/9906/msg00235.html) first occured in 21.2-b16 I modified my .emacs like this: (custom-set-faces - '(default ((t (:family "Courier New" :bold nil :italic nil))) t) + '(default ((t (:background "white" :bold nil :italic nil))) t) '(gui-button-face ((t (:foreground "black" :background "white"))) t) This works fine with 21.2-b17+ with your frob-face-property patch applied. However, the new setting for face 'default does not work for 21.1-b2 21.1.3 21.1.4 Regards, Adrian Jan> isn't in 21.1.x (I checked using cvsweb: faces.el has stayed the same Jan> all the time) >> Jan fixed this bug for 21.2-b17++. I'll see whether the fix works for >> 21.1.4 too. Jan> So it works for you, that is nice. Jan> Jan From owner-xemacs-beta@xemacs.org Thu Jul 8 20:15:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA03060 for xemacs-beta-out; Thu, 8 Jul 1999 20:15:11 -0400 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA03057 for ; Thu, 8 Jul 1999 20:15:09 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19990602200837) with ESMTP id JAA06006 for ; Fri, 9 Jul 1999 09:15:08 +0900 (JST) Received: from mule.m17n.org (steve@mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990514193409) with ESMTP id JAA13970 for ; Fri, 9 Jul 1999 09:15:07 +0900 (JST) Received: (from steve@localhost) by mule.m17n.org (8.9.2/3.7W-19990512194415) id JAA09992; Fri, 9 Jul 1999 09:15:06 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: X-Attribution: sb From: SL Baur In-Reply-To: Gunnar Evermann's message of "Thu, 8 Jul 1999 14:21:51 +0100 (BST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 09 Jul 1999 09:15:06 +0900 Message-ID: Lines: 33 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Gunnar Evermann writes in xemacs-beta@xemacs.org: ... > In my opinion we should rethink our presence on c.e.x (or our PR in > general). I makes me very sad if the public perception of the XEmacs team > is a bunch of debian-bashing hackers who don't care about their user > base. "debian-bashing hackers"? I guess I've gotten very out of touch. > I do answer a lot of questions on c.e.x (either on the list or more often > by email) and so do some others (especially Jan and Hrvoje come to mind). > I suggest we adopt a slightly modified policy on this: > - whenever possible send the first followup to a question to c.e.x and > offer to sort out detailed problems via email (I think I'm currently > helping three people through the XEmacs install process). This also > avoids duplication of effort (e.g. if Jan already told someone to read > README.packages then I don't have to repeat that). If you're going to take this kind of time, it's probably a better idea to post it so it gets archived by dejanews. Otherwise you are going to be answering the same questions over and over and over again. > - always use a @xemacs.org address and an associated .sig (I think Ben > suggested this a long time ago) I don't think this is a good idea because of address harvesting. Perhaps a generic usenet posting address can be created that gets filtered to /dev/null. (I don't currently have access to Usenet). From owner-xemacs-beta@xemacs.org Thu Jul 8 21:01:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA04663 for xemacs-beta-out; Thu, 8 Jul 1999 21:01:19 -0400 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 VAA04641; Thu, 8 Jul 1999 21:00:41 -0400 Received: by crystal.WonderWorks.COM id QQgxay20185; Thu, 8 Jul 1999 18:00:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14213.18870.232249.861607@crystal.WonderWorks.COM> Date: Thu, 8 Jul 1999 18:00:38 -0700 (PDT) From: Kyle Jones To: Marcus Thiessel Cc: XEmacs Developers Subject: Re: HP-UX 10.20 build issues In-Reply-To: <14212.47759.107261.502191@gargle.gargle.HOWL> References: <199907080359.UAA08937@mina.sr.hp.com> <199907081317.GAA00148@mina.sr.hp.com> <14212.47759.107261.502191@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.2 (beta16) "Sumida" 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: Marcus Thiessel writes: > Darryl Okahata writes: > > > I don't know if this issue exists under HP-UX 11.0. > > Well, I tried once to include sound support but wasn't too excited > about the result. So I decided not to use it. Why weren't you excited? What would excite you? From owner-xemacs-beta@xemacs.org Thu Jul 8 22:17:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA06650 for xemacs-beta-out; Thu, 8 Jul 1999 22:17:26 -0400 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA03177 for xemacs-announce-out; Thu, 8 Jul 1999 20:20:04 -0400 To: xemacs-beta@xemacs.org, xemacs-announce@xemacs.org Newsgroups: comp.emacs.xemacs From: Vin Shelton Organization: The XEmacs Development Team Subject: XEmacs 21.1.4 (Arches) is Released Date: 08 Jul 1999 10:01:13 -0400 Message-ID: <5451zejz1ee.fsf@dusk1.icd.teradyne.com> Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: comp.emacs.xemacs Reply-To: xemacs-beta@xemacs.org X-Mailing-List: Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. XEmacs-21.1.4 is available from ftp.xemacs.org. Get it from: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-elc.tar.gz ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.1/xemacs-21.1.4-info.tar.gz This is a bugfix release. Several miscellaneous bugs have been fixed. Probably the most significant is a fix Gunnar Everman made to prevent zombie processes when running XEmacs with tooltalk support; see http://www.xemacs.org/list-archives/xemacs-patches/9907/msg00006.html for more details. In addition, Michael Sperber submitted a patch to make docdir user-configurable. The 21.1.x series of releases is being named for US National Parks. Arches is an incredibly beautiful US National Park located in Utah. For more information see: http://www.nps.gov:80/arch. Vin Shelton From owner-xemacs-beta@xemacs.org Thu Jul 8 22:22:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA06739 for xemacs-beta-out; Thu, 8 Jul 1999 22:22:53 -0400 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 WAA06736 for ; Thu, 8 Jul 1999 22:22:50 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id TAA30337; Thu, 8 Jul 1999 19:23:45 -0700 To: XEmacs Beta Subject: [Robert Kerr ] Strange xemacs warning 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: 51 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Thu_Jul__8_19:23:44_1999-1 Content-Type: text/plain; charset=US-ASCII Anyone know what causes this? --Multipart_Thu_Jul__8_19:23:44_1999-1 Content-Type: message/rfc822 Resent-Date: 6 Jul 1999 17:24:03 -0000 Resent-Cc: recipient list not shown: ; Date: Tue, 6 Jul 1999 09:53:06 -0600 (MDT) From: Robert Kerr To: Debian List Subject: Strange xemacs warning Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"SQXAlB.A.MqG.yujg3"@murphy> Resent-From: debian-user@lists.debian.org Resent-Sender: debian-user-request@lists.debian.org My xemacs gives me this statement in the bottom window. Can't instantiate image (probably cached) : [xbm :mask-file "/usr/include/X11/bitmaps/left_ptrmsk" ... this happens when the cursor goes over the button bar at the top. Any ideas? Thanks -- -bob The difference between Mechanical Engineers and Civil Engineers: Mechanical Engineers build weapons, Civil Engineers build targets. ********************************************************************** * Robert Kerr, The morphing guy. * 368 Clyde Building, BYU * * rakerr@sandia.gov * Provo, Utah 84602 * * Robert_Kerr@byu.edu * Phone: (801) 378-2029 * * http://www.et.byu.edu/~kerrr * Fax: (801) 378-4449 * ********************************************************************** -- Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null --Multipart_Thu_Jul__8_19:23:44_1999-1-- From owner-xemacs-beta@xemacs.org Thu Jul 8 22:53:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA07640 for xemacs-beta-out; Thu, 8 Jul 1999 22:53:26 -0400 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 WAA07634 for ; Thu, 8 Jul 1999 22:53:23 -0400 Received: by crystal.WonderWorks.COM id QQgxbf21835; Thu, 8 Jul 1999 19:53:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14213.25633.383389.145266@crystal.WonderWorks.COM> Date: Thu, 8 Jul 1999 19:53:21 -0700 (PDT) From: Kyle Jones To: XEmacs Beta Subject: [Robert Kerr ] Strange xemacs warning In-Reply-To: <87wvwar26n.fsf@bittersweet.sysc.pdx.edu> References: <87wvwar26n.fsf@bittersweet.sysc.pdx.edu> X-Mailer: VM 6.72 under 21.2 (beta16) "Sumida" 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: FAQ, question 2.1.11. Does anyone read the FAQ (not a rhetorical question)? Is it too big and foreboding now? What can we do to integrate the FAQ knowledge back into the binary so that the user can benefit from it without having to actually read it? ------------ Q2.1.11: `Can't instantiate image error...' in toolbar Dr. Ram Samudrala writes: I just installed the XEmacs (20.4-2) RPMS that I downloaded from http://www.xemacs.org/. Everything works fine, except that when I place my mouse over the toolbar, it beeps and gives me this message: Can't instantiate image (probably cached): [xbm :mask-file "/usr/include/X11/bitmaps/leftptrmsk :mask-data (16 16 ... Kyle Jones writes: This is a problem specific to some Chips and Technologies video chips, when running XFree86. Putting Option "sw_cursor" in `XF86Config' in the devices section gets rid of the problem. From owner-xemacs-beta@xemacs.org Thu Jul 8 23:53:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA09755 for xemacs-beta-out; Thu, 8 Jul 1999 23:53:09 -0400 Received: from smtp5.mindspring.com (smtp5.mindspring.com [207.69.200.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA09751 for ; Thu, 8 Jul 1999 23:53:08 -0400 Received: from ashanti.mastaler.com (pool-207-205-180-106.phnx.grid.net [207.205.180.106]) by smtp5.mindspring.com (8.8.5/8.8.5) with SMTP id XAA14784 for ; Thu, 8 Jul 1999 23:53:06 -0400 (EDT) Received: (qmail 6430 invoked from network); 9 Jul 1999 03:50:38 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 9 Jul 1999 03:50:38 -0000 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jason R Mastaler Date: 08 Jul 1999 21:52:53 -0600 In-Reply-To: Gunnar Evermann's message of "Thu, 8 Jul 1999 14:21:51 +0100 (BST)" Message-ID: Lines: 10 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) 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: > P.S.: who is the keeper of the @xemacs.org aliases/accounts? `postmaster@xemacs.org', or `list-manager@xemacs.org' for mailing list specific issues. These go to me, but always use the above aliases so someone can cover them when I go on vacation and stuff. From owner-xemacs-beta@xemacs.org Thu Jul 8 23:57:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA09861 for xemacs-beta-out; Thu, 8 Jul 1999 23:57:34 -0400 Received: from smtp1.mindspring.com (smtp1.mindspring.com [207.69.200.31]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA09857 for ; Thu, 8 Jul 1999 23:57:33 -0400 Received: from ashanti.mastaler.com (pool-207-205-180-106.phnx.grid.net [207.205.180.106]) by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id XAA32383 for ; Thu, 8 Jul 1999 23:57:31 -0400 (EDT) Received: (qmail 6437 invoked from network); 9 Jul 1999 03:55:03 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 9 Jul 1999 03:55:03 -0000 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jason R Mastaler Date: 08 Jul 1999 21:57:18 -0600 In-Reply-To: Jan Vroonhof's message of "08 Jul 1999 15:52:06 +0200" Message-ID: Lines: 12 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) 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: > > - always use a @xemacs.org address and an associated .sig (I think Ben > > suggested this a long time ago) > > I have a problem with that. The address I use on Usenet has a spam > filter on it. I prefer not to post with official contact addresses. Understandable, but I think the release announcements should be done with an @xemacs.org address. If it helps any, mail.xemacs.org is quite aggressive with its anti-spam precautions. From owner-xemacs-beta@xemacs.org Fri Jul 9 00:03:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA10124 for xemacs-beta-out; Fri, 9 Jul 1999 00:03:28 -0400 Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA10120 for ; Fri, 9 Jul 1999 00:03:26 -0400 Received: from ashanti.mastaler.com (pool-207-205-180-106.phnx.grid.net [207.205.180.106]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id AAA29376 for ; Fri, 9 Jul 1999 00:03:25 -0400 (EDT) Received: (qmail 6443 invoked from network); 9 Jul 1999 04:00:57 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 9 Jul 1999 04:00:57 -0000 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released References: From: Jason R Mastaler Date: 08 Jul 1999 22:03:12 -0600 In-Reply-To: SL Baur's message of "09 Jul 1999 09:15:06 +0900" Message-ID: Lines: 18 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) 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: > > - always use a @xemacs.org address and an associated .sig (I think Ben > > suggested this a long time ago) > > I don't think this is a good idea because of address harvesting. Perhaps > a generic usenet posting address can be created that gets filtered to > /dev/null. This is an option. Alternatively, someone whose @xemacs.org address has already been harvested (like me) or who isn't bothered much by spam could make the usenet announcements. > (I don't currently have access to Usenet). As a reminder, e-mail sent to `xemacs@xemacs.org' will get automatically posted to comp.emacs.xemacs. From owner-xemacs-beta@xemacs.org Fri Jul 9 01:08:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA12300 for xemacs-beta-out; Fri, 9 Jul 1999 01:08:37 -0400 Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA12293 for ; Fri, 9 Jul 1999 01:08:36 -0400 Received: from ashanti.mastaler.com (pool-207-205-180-106.phnx.grid.net [207.205.180.106]) by smtp4.mindspring.com (8.8.5/8.8.5) with SMTP id BAA06791 for ; Fri, 9 Jul 1999 01:08:33 -0400 (EDT) Received: (qmail 6514 invoked from network); 9 Jul 1999 05:06:06 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 9 Jul 1999 05:06:06 -0000 To: xemacs-beta@xemacs.org Cc: xemacs-binary-kits@xemacs.org Subject: IRIX binary-kit builder needed From: Jason R Mastaler Date: 08 Jul 1999 23:08:20 -0600 Message-ID: Lines: 13 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: We are in the process of preparing precompiled binary-kits for 21.1, but my regular IRIX binary-kit builder doesn't seem to be around these days. Is there anyone out there who compiles/uses XEmacs on IRIX fairly regularly and would like to help out the project with a binary-kit contribution? If so, please get in touch with me directly. If you want to know what you are getting into before committing, you can take a look at the instructions and materials for V21.1 binary-kit builders at: ftp://ftp.xemacs.org/pub/xemacs/beta/binary-kits/21.1/ Thanks. From owner-xemacs-beta@xemacs.org Fri Jul 9 03:05:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14841 for xemacs-beta-out; Fri, 9 Jul 1999 03:05:56 -0400 Received: from smtp5.mindspring.com (smtp5.mindspring.com [207.69.200.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14838 for ; Fri, 9 Jul 1999 03:05:54 -0400 Received: from sparrow.bear.com (user-2ive24s.dialup.mindspring.com [165.247.8.156]) by smtp5.mindspring.com (8.8.5/8.8.5) with ESMTP id DAA23780 for ; Fri, 9 Jul 1999 03:05:52 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.1/8.9.1) with SMTP id AAA18611 for ; Fri, 9 Jul 1999 00:04:21 -0400 Date: Fri, 9 Jul 1999 00:04:20 -0400 (EDT) From: Justin Vallon Reply-To: Justin Vallon To: XEmacs Beta Subject: "Stack overflow in regexp" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: All, In a couple of places (compilation-mode, message-headers), I get errors about stack overflow in regexp pattern matching. The first one was in compile mode, which builds a looking-at regexp from: mode1\|mode2\|mode3\|...\|mode99. When given a compile line that is very long (lots of -I, ~>1000 chars), I get the error. I had figured that maybe the union of the regexps was too complicated for the regexp engine. However, I got some almost-department-wide email addressed to lots of recipients (~300), and got the error. The header-highlighting was barfing on a find-the-header regexp: highlight-headers.el:215: (looking-at "^\\([^ \t\n:]+[ \t]*:\\) *\\(.*\\(\n[ \t].*\\)*\n\\)") header ws : space field (continued field)* The regexp isn't that complicated, but it caused the highlighting to barf. Questions: a) Is there anyway to make the regexp stack larger? b) Does a larger regexp stack hurt performance? (a little memory isn't that expensive, but I wouldn't want to slow things down) I imagine these might be GNU regexp questions. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Fri Jul 9 03:18:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA15151 for xemacs-beta-out; Fri, 9 Jul 1999 03:18:11 -0400 Received: from ivanova.zhar.net (snapuser80.pacificcrest.net [216.36.24.80]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA15143; Fri, 9 Jul 1999 03:18:08 -0400 Received: from shiva.zhar.net (zhar.net) [10.10.1.4] (jae) by ivanova.zhar.net with smtp (Exim 2.05 #1 (Debian)) id 112Uuz-0007zj-00; Fri, 9 Jul 1999 00:17:57 -0700 Received: by zhar.net (sSMTP sendmail emulation); Fri, 9 Jul 1999 00:18:01 -0700 Date: Fri, 9 Jul 1999 00:18:01 -0700 From: John Eikenberry To: xemacs-beta@xemacs.org, xemacs-announce@xemacs.org Message-ID: <19990709001801.A264@shiva.zhar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: unsubscribe -- John Eikenberry [jae@zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin From owner-xemacs-beta@xemacs.org Fri Jul 9 03:44:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16163 for xemacs-beta-out; Fri, 9 Jul 1999 03:44:33 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA16126; Fri, 9 Jul 1999 03:44:04 -0400 Received: from hpbbse.bbn.hp.com (root@hpbbse.bbn.hp.com [15.136.26.26]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id DAA17243; Fri, 9 Jul 1999 03:43:30 -0400 (EDT) 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 IAA20465; Fri, 9 Jul 1999 08:43:48 +0100 (MEZ) Received: (from thiessel@localhost) by bbn.hp.com (8.8.6 (PHNE_15509)/8.8.6) id JAA00922; Fri, 9 Jul 1999 09:43:48 +0200 (METDST) From: Marcus Thiessel Message-ID: <14213.43059.925880.151180@gargle.gargle.HOWL> Date: Fri, 9 Jul 1999 09:43:47 +0200 (METDST) To: kyle_jones@wonderworks.com CC: XEmacs Developers Subject: Re: HP-UX 10.20 build issues In-Reply-To: <14213.18870.232249.861607@crystal.WonderWorks.COM> References: <199907080359.UAA08937@mina.sr.hp.com> <199907081317.GAA00148@mina.sr.hp.com> <14212.47759.107261.502191@gargle.gargle.HOWL> <14213.18870.232249.861607@crystal.WonderWorks.COM> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) 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: Kyle Jones writes: > Marcus Thiessel writes: > > Well, I tried once to include sound support but wasn't too excited > > about the result. So I decided not to use it. > > Why weren't you excited? What would excite you? The reasons why I wasn't too excited were: -- volume not really adjustable and too low (build-in speakers) -- playing sounds blocks and freezes XEmacs completely (really annoying since you hardly hear that sounds are played) Don't get me wrong on Solaris the sound was quite a good feature and everything works as expected. I just don't like the behaviour on my C240. Since sound is not that important to me I didn't investigate any further. Could also be that something in the OS or hardware is broken. --Marcus From owner-xemacs-beta@xemacs.org Fri Jul 9 05:30:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19281 for xemacs-beta-out; Fri, 9 Jul 1999 05:30:34 -0400 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 FAA19277 for ; Fri, 9 Jul 1999 05:30:33 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA16259 for ; Fri, 9 Jul 1999 11:30:29 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003xg; Fri Jul 9 11:30:19 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA19663; Fri, 9 Jul 1999 11:30:18 +0200 To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", i386-pc-win32 References: From: Jan Vroonhof Date: 09 Jul 1999 11:30:18 +0200 In-Reply-To: Adrian Aichner's message of "09 Jul 1999 00:07:18 +0200" 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: Adrian Aichner writes: > (custom-set-faces > - '(default ((t (:family "Courier New" :bold nil :italic nil))) t) > + '(default ((t (:background "white" :bold nil :italic nil))) t) > '(gui-button-face ((t (:foreground "black" :background "white"))) t) > > This works fine with 21.2-b17+ with your frob-face-property patch applied. > > However, the new setting for face 'default does not work for > 21.1-b2 > 21.1.3 > 21.1.4 Please define 'does not work' more exactly. Note that the new customize specifier stuff is written to fix real problems that occur when mixing old and new ways of setting the fonts. So it is not in itself surprising that there are problems with the old method. However we need to check we didn't introduce any new ones by accident in the 21.1.x series. From owner-xemacs-beta@xemacs.org Fri Jul 9 05:34:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19362 for xemacs-beta-out; Fri, 9 Jul 1999 05:34:12 -0400 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 FAA19357 for ; Fri, 9 Jul 1999 05:34:09 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA16423 for ; Fri, 9 Jul 1999 11:34:09 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0040O; Fri Jul 9 11:33:59 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA19670; Fri, 9 Jul 1999 11:33:58 +0200 To: xemacs-beta@xemacs.org Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14213.5337.99734.417601@crystal.Wonder From: Jan Vroonhof Date: 09 Jul 1999 11:33:57 +0200 In-Reply-To: Kyle Jones's message of "Thu, 8 Jul 1999 14:15:04 -0700 (PDT)" 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: > We don't really have to use long long, we can mandate use of > the union type and put a 32-bit integer into the Lisp_Object > union. Lisp_Objects will necessarily be 64-bit objects at this If we go that far, just allowing a 'float' value for point on the lisp side would be another option. Jan From owner-xemacs-beta@xemacs.org Fri Jul 9 05:36:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19431 for xemacs-beta-out; Fri, 9 Jul 1999 05:36:01 -0400 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 FAA19427 for ; Fri, 9 Jul 1999 05:36:00 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA16601 for ; Fri, 9 Jul 1999 11:35:59 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0043L; Fri Jul 9 11:35:55 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA19752; Fri, 9 Jul 1999 11:35:54 +0200 To: xemacs-beta@xemacs.org Subject: Re: [Robert Kerr ] Strange xemacs warning References: <87wvwar26n.fsf@bittersweet.sysc.pdx.edu> <14213.25633.383389.145266@crystal.WonderWorks.COM> From: Jan Vroonhof Date: 09 Jul 1999 11:35:54 +0200 In-Reply-To: Kyle Jones's message of "Thu, 8 Jul 1999 19:53:21 -0700 (PDT)" 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: Kyle Jones writes: > Does anyone read the FAQ (not a rhetorical question)? Is it too > big and foreboding now? What can we do to integrate the FAQ > knowledge back into the binary so that the user can benefit from > it without having to actually read it? Simply putting the text into the warning doesn't help. c.f. the X modifier keys warnings. -- 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 Fri Jul 9 05:38:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19547 for xemacs-beta-out; Fri, 9 Jul 1999 05:38:42 -0400 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 FAA19543 for ; Fri, 9 Jul 1999 05:38:40 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA16715 for ; Fri, 9 Jul 1999 11:38:39 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0044z; Fri Jul 9 11:38:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA19754; Fri, 9 Jul 1999 11:38:32 +0200 To: xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" References: From: Jan Vroonhof Date: 09 Jul 1999 11:38:32 +0200 In-Reply-To: Justin Vallon's message of "Fri, 9 Jul 1999 00:04:20 -0400 (EDT)" 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: Justin Vallon writes: > a) Is there anyway to make the regexp stack larger? This is the process stack, use 'ulimit' from your shell. Are you on Digital Unix? > b) Does a larger regexp stack hurt performance? (a little memory isn't > that expensive, but I wouldn't want to slow things down) It shouldn't cost you at all on modern operating systems. Jan From owner-xemacs-beta@xemacs.org Fri Jul 9 05:52:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19882 for xemacs-beta-out; Fri, 9 Jul 1999 05:52:35 -0400 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 FAA19879 for ; Fri, 9 Jul 1999 05:52:33 -0400 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 FAA14948 for ; Fri, 9 Jul 1999 05:58:18 -0400 (EDT) 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 LAA24044; Fri, 9 Jul 1999 11:52:25 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: [Success] XEmacs 21.1.4 "Arches", 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: 09 Jul 1999 11:46:41 +0200 In-Reply-To: Jan Vroonhof's message of "09 Jul 1999 11:30:18 +0200" Message-ID: Lines: 42 User-Agent: Gnus/5.070085 (Pterodactyl Gnus v0.85) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Adrian Aichner writes: >> (custom-set-faces >> - '(default ((t (:family "Courier New" :bold nil :italic nil))) t) >> + '(default ((t (:background "white" :bold nil :italic nil))) t) >> '(gui-button-face ((t (:foreground "black" :background "white"))) t) >> >> This works fine with 21.2-b17+ with your frob-face-property patch applied. >> >> However, the new setting for face 'default does not work for >> 21.1-b2 >> 21.1.3 >> 21.1.4 Jan> Please define 'does not work' more exactly. Note that the new Please see: APA> When the problem APA> (http://www.xemacs.org/list-archives/xemacs-beta/9906/msg00235.html) APA> first occured in 21.2-b16 I modified my .emacs like this: Jan> customize specifier stuff is written to fix real problems Jan> that occur when mixing old and new ways of setting the Jan> fonts. So it is not in itself surprising that there are Jan> problems with the old method. However we need to check we Jan> didn't introduce any new ones by accident in the 21.1.x Jan> series. This is why I spent 1/4 of a night building 21.2-b2, 21.1.3, 21.1.4 again to track down the problem. The result is that '(default ((t (:background "white" :bold nil :italic nil))) t) exposes the same problem under 21.1.[2-4] as '(default ((t (:family "Courier New" :bold nil :italic nil))) t) did under 21.2-b1[67] until your frob-face-property patch came along. HTH, Adrian From owner-xemacs-beta@xemacs.org Fri Jul 9 10:29:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA26663 for xemacs-beta-out; Fri, 9 Jul 1999 10:29:18 -0400 Received: from ptavv.es.net (weather.llnl.gov [198.128.4.29]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA26657 for ; Fri, 9 Jul 1999 10:29:16 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.8.8/8.8.8) with ESMTP id HAA26560 for ; Fri, 9 Jul 1999 07:29:16 -0700 (PDT) Message-Id: <199907091429.HAA26560@ptavv.es.net> To: xemacs-beta@xemacs.org Subject: Updates to "Current version" messages at ftp.xemacs.org Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 09 Jul 1999 07:29:15 -0700 From: "Kevin Oberman" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I think either Steve or Jason needs to update the messages at ftp://ftp.xemacs.org/pub/xemacs. When you connect to the directory, you get: Current Version: 21.1.2 and the README file contains: Current Version: 20.4, released February 28, 1998 Current semi-experimental Version: 21.0.67, released March 25, 1999 Updating these should be part of the process of building a new kit. 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 Fri Jul 9 15:54:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05933 for xemacs-beta-out; Fri, 9 Jul 1999 15:54:41 -0400 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 PAA05930 for ; Fri, 9 Jul 1999 15:54:36 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id MAA26225; Fri, 9 Jul 1999 12:55:23 -0700 To: Gunnar Evermann Cc: XEmacs Beta Subject: Re: [crash] Opening frame across ssh from inside a screen. 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: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'll find the report in BTS, and if the crash happens again and I have time, I'll see about debugging it. >>>>> "Gunnar" == Gunnar Evermann writes: Gunnar> Why was there no stacktrace eye catcher in your backtrace, Gunnar> anyway? Overly aggressive inlining by egcs? I only mailed the top of the trace. It was long, and everything seemed likely normal up until it went to open the display across the ssh link. Gunnar> Still it would be great if you could figure this out! Yes, if and when I can. I am NOT expert with a debugger. I am still a C novice. I can read and understand much but not all, and have never written a program. I need to read my books rather than all this email. From owner-xemacs-beta@xemacs.org Fri Jul 9 22:10:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA15474 for xemacs-beta-out; Fri, 9 Jul 1999 22:10:16 -0400 Received: from wren.prod.itd.earthlink.net (wren.prod.itd.earthlink.net [207.217.120.64]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA15471 for ; Fri, 9 Jul 1999 22:10:14 -0400 Received: from tgoodman8 (dialup-209.244.224.59.Boston2.Level3.net [209.244.224.59]) by wren.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id TAA13503; Fri, 9 Jul 1999 19:10:05 -0700 (PDT) From: "Todd Goodman" To: "'Kyle Jones'" , "'XEmacs Beta'" Subject: RE: [Robert Kerr ] Strange xemacs warning Date: Fri, 9 Jul 1999 22:10:08 -0400 Message-ID: <004901beca79$5663b0a0$0301a8c0@tgoodman8> 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 8.5, Build 4.71.2173.0 In-Reply-To: <14213.25633.383389.145266@crystal.WonderWorks.COM> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I just read the entire FAQ today. I don't believe it's too large. > -----Original Message----- > From: owner-xemacs-beta@xemacs.org > [mailto:owner-xemacs-beta@xemacs.org]On Behalf Of Kyle Jones [SNIP] > Does anyone read the FAQ (not a rhetorical question)? Is it too > big and foreboding now? What can we do to integrate the FAQ > knowledge back into the binary so that the user can benefit from > it without having to actually read it? [SNIP] From owner-xemacs-beta@xemacs.org Sat Jul 10 00:51:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA19472 for xemacs-beta-out; Sat, 10 Jul 1999 00:51:15 -0400 Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA19469 for ; Sat, 10 Jul 1999 00:51:13 -0400 Received: from ashanti.mastaler.com (pool-207-205-182-229.phnx.grid.net [207.205.182.229]) by smtp4.mindspring.com (8.8.5/8.8.5) with SMTP id AAA29614 for ; Sat, 10 Jul 1999 00:51:11 -0400 (EDT) Received: (qmail 7543 invoked from network); 10 Jul 1999 04:48:39 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 10 Jul 1999 04:48:38 -0000 To: xemacs-beta@xemacs.org Subject: Re: Updates to "Current version" messages at ftp.xemacs.org References: <199907091429.HAA26560@ptavv.es.net> From: Jason R Mastaler Date: 09 Jul 1999 22:50:46 -0600 In-Reply-To: "Kevin Oberman"'s message of "Fri, 09 Jul 1999 07:29:15 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Kevin Oberman" writes: > I think either Steve or Jason needs to update the messages at > ftp://ftp.xemacs.org/pub/xemacs. When you connect to the directory, > you get: > Current Version: 21.1.2 > and the README file contains: > Current Version: 20.4, released February 28, 1998 > Current semi-experimental Version: 21.0.67, released March 25, 1999 These have now been updated. They now match the website as well. From owner-xemacs-beta@xemacs.org Sat Jul 10 01:19:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA20125 for xemacs-beta-out; Sat, 10 Jul 1999 01:19:23 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA20120 for ; Sat, 10 Jul 1999 01:19:19 -0400 Received: from sparrow.bear.com (user-2ive1io.dialup.mindspring.com [165.247.6.88]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id BAA08370; Sat, 10 Jul 1999 01:19:13 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.1/8.9.1) with SMTP id BAA22343; Sat, 10 Jul 1999 01:19:12 -0400 Date: Sat, 10 Jul 1999 01:19:11 -0400 (EDT) From: Justin Vallon To: Jan Vroonhof cc: xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 9 Jul 1999, Jan Vroonhof wrote: > Justin Vallon writes: > > > a) Is there anyway to make the regexp stack larger? > > This is the process stack, use 'ulimit' from your shell. > Are you on Digital Unix? > > > b) Does a larger regexp stack hurt performance? (a little memory isn't > > that expensive, but I wouldn't want to slow things down) > > It shouldn't cost you at all on modern operating systems. HPUX 10.20. Are you sure that the regexp engine is running out of process stack, and not running out of some sort of space in a 'RegExpState stack[256]' variable? Also, as far as I understand, I'd have to be root to increase a ulimit parameter. I'll try it, though. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sat Jul 10 10:37:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA26211 for xemacs-beta-out; Sat, 10 Jul 1999 10:37:44 -0400 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 KAA26208 for ; Sat, 10 Jul 1999 10:37:43 -0400 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 HAA25027; Sat, 10 Jul 1999 07:37:34 -0700 (PDT) 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 HAA07562; Sat, 10 Jul 1999 07:36:27 -0700 (PDT) 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 HAA27244; Sat, 10 Jul 1999 07:37:32 -0700 (PDT) Message-Id: <199907101437.HAA27244@mina.sr.hp.com> To: Justin Vallon cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" Reply-To: Darryl Okahata In-reply-to: Your message of "Sat, 10 Jul 1999 01:19:11 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 10 Jul 1999 07:37:32 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Justin Vallon wrote: > HPUX 10.20. Are you sure that the regexp engine is running out of process > stack, and not running out of some sort of space in a 'RegExpState > stack[256]' variable? With HP-UX, I always increase the regexp stack size (from 2000 to 20000). VM gets regexp stack overflows otherwise. Sample patch attached (relative to 21.1.4). [ Note: I've also built my kernel to bump up the HP-UX max process stack size from 2MB to 16MB. I'm not sure this is necessary if you use this patch, but the comment above the variable implies that this might be. ] -- 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 Hewlett-Packard, or of the little green men that have been following him all day. Index: regex.c =================================================================== retrieving revision 1.1.1.1 diff -c -r1.1.1.1 regex.c *** regex.c 1999/06/15 22:37:58 1.1.1.1 --- regex.c 1999/07/08 22:39:09 *************** *** 1118,1124 **** --- 1118,1128 ---- whose default stack limit is 2mb. */ int re_max_failures = 20000; #else + # if defined(__hpux) + int re_max_failures = 20000; + # else int re_max_failures = 2000; + # endif #endif union fail_stack_elt From owner-xemacs-beta@xemacs.org Sun Jul 11 03:05:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA10377 for xemacs-beta-out; Sun, 11 Jul 1999 03:05:52 -0400 Received: from smtp3.mindspring.com (smtp3.mindspring.com [207.69.200.33]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA10374 for ; Sun, 11 Jul 1999 03:05:50 -0400 Received: from sparrow.bear.com (user-2ive22k.dialup.mindspring.com [165.247.8.84]) by smtp3.mindspring.com (8.8.5/8.8.5) with ESMTP id DAA00576; Sun, 11 Jul 1999 03:05:47 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.1/8.9.1) with SMTP id UAA15814; Sat, 10 Jul 1999 20:55:48 -0400 Date: Sat, 10 Jul 1999 20:55:47 -0400 (EDT) From: Justin Vallon To: Darryl Okahata cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" In-Reply-To: <199907101437.HAA27244@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Sat, 10 Jul 1999, Darryl Okahata wrote: > Justin Vallon wrote: > > > HPUX 10.20. Are you sure that the regexp engine is running out of process > > stack, and not running out of some sort of space in a 'RegExpState > > stack[256]' variable? > > With HP-UX, I always increase the regexp stack size (from 2000 to > 20000). VM gets regexp stack overflows otherwise. Sample patch > attached (relative to 21.1.4). > > [ Note: I've also built my kernel to bump up the HP-UX max process > stack size from 2MB to 16MB. I'm not sure this is necessary if you > use this patch, but the comment above the variable implies that this > might be. ] Short version: Does this happen on other platforms? VM or compile would be likely candidates for large regexps or large patterns. I think the (regexp internal fail_stack) stack size can be increased on all platforms from 2000 to 20000 at the cost of 16000*4 ~= 64k. Long version: Well, my stack ulimit shows 80Mb, so that's good. I did some light reading of regex.c. Here is the full context of the patch: [21.1.2/src/regex.c:1112] /* Roughly the maximum number of failure points on the stack. Would be exactly that if always used MAX_FAILURE_SPACE each time we failed. This is a variable only so users of regex can assign to it; we never change it ourselves. */ #if defined (MATCH_MAY_ALLOCATE) /* 4400 was enough to cause a crash on Alpha OSF/1, whose default stack limit is 2mb. */ int re_max_failures = 20000; #else int re_max_failures = 2000; #endif That would lead me to believe that MATCH_MAY_ALLOCATE is not defined (though, I don't understand why, re line 1095), which agrees with line 1072 saying that (X)Emacs #undefs MATCH_MAY_ALLOCATE (something about receiving input in a signal handler, that could then call regexp's match, which should not malloc). Also: [:1795] #ifndef MATCH_MAY_ALLOCATE /* If we cannot allocate large objects within re_match_2_internal, we make the fail stack and register vectors global. The fail stack, we grow to the maximum size when a regexp is compiled. The register vectors, we adjust in size each time we compile a regexp, according to the number of registers it needs. */ Things may be different for different platforms. It appears that regexp can use alloca as well, if certain #defines are provided. It's unclear here whether this is ever the case for XEmacs. Also, I believe that it is the internal regexp stack (fail_stack) that is overflowing. The fail_stack seems to record backtracking points in case further matching fails. So, the patch is basically: If !defined(MATCH_MAY_ALLOCATE) && __hpux, increase the amount of space regexp_compile allocates up-front for the worst case (max allowed) stack size (via malloc not alloca). Discounting config.h features, every platform that hits this line would probably benefit from increasing the stack size. Each stack element takes: sizeof(fail_stack_elt_t) == sizeof(union {uchar*, int}) == 4. Increasing the stack from 2000 to 20000 would take an additional ~16k*4 = 64k. Interesting part of the original patch from Darryl Okahata : > #else > + # if defined(__hpux) > + int re_max_failures = 20000; > + # else > int re_max_failures = 2000; > + # endif > #endif -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sun Jul 11 10:24:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA15520 for xemacs-beta-out; Sun, 11 Jul 1999 10:24:52 -0400 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 KAA15517 for ; Sun, 11 Jul 1999 10:24:50 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA25619 for ; Sun, 11 Jul 1999 16:24:44 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006G9; Sun Jul 11 16:24:39 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA24437; Sun, 11 Jul 1999 16:24:38 +0200 To: xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" References: From: Jan Vroonhof Date: 11 Jul 1999 16:24:38 +0200 In-Reply-To: Justin Vallon's message of "Sat, 10 Jul 1999 20:55:47 -0400 (EDT)" 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: Justin Vallon writes: > I think the (regexp internal fail_stack) stack size can be increased on > all platforms from 2000 to 20000 at the cost of 16000*4 ~= 64k. I just had a glance at it too, but isn't the maximum (on a 32 bit machine). 2 * re_max_failures * MAX_FAILURE_ITEMS * 4 Where MAX_FAILURE_ITEMS = 5 * 3 + 5 = 19 thus the cost is about 38 times higher. And on a 64-bit machine it is about 80 times higher. Which more or less explains why DEC OSF's 2MB stack gives problems. Does anybody know why regexp lets its stack grow exponentially? Jan From owner-xemacs-beta@xemacs.org Sun Jul 11 23:30:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA28048 for xemacs-beta-out; Sun, 11 Jul 1999 23:30:56 -0400 Received: from mail.storm.ca (storm.ca [209.87.224.69]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA28042 for ; Sun, 11 Jul 1999 23:30:50 -0400 Received: from simon.storm.ca ([209.87.225.62]) by mail.storm.ca (8.8.8+Sun/8.8.8) with ESMTP id XAA10624 for ; Sun, 11 Jul 1999 23:30:25 -0400 (EDT) Received: by simon.storm.ca (Linux Smail3.2.0.101 #1) id m113Wnn-0001NbC; Sun, 11 Jul 1999 23:30:47 -0400 (EDT) From: Sean MacLennan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14217.24934.723006.454272@simon.storm.ca> Date: Sun, 11 Jul 1999 23:30:46 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: toolbars and compilation-height X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I don't like big compilation windows so I have always had (setq compilation-window-height 10) in my .emacs. At some point in time, this stopped working (i.e. the window is simply split in half). Having a little bit of time, I looked into it. It seems that if you have toolbars on the sides, rather than top or bottom (or none at all), compilation-window-height is ignored due to the following line from `compilation-set-window-height': (= (window-width window) (frame-width (window-frame window))) This is true for horizontal (or no) toolbars, and false for vertical toolbars since window-width will be < frame width. Why is this line needed? And how can I find out the toolbar width? The problem is in both 21.2-b17 and 21.0-b64. Thanks, Sean P.S. I noticed a typo in the documentation for `default-toolbar-position' (defcustom default-toolbar-position ;; added for the options menu - dverna (default-toolbar-position) "The location of the default toolbar. It can be 'top, 'bootom, 'left or 'right. This option can be customized through the options menu." Bootom should be bottom. -- Sean MacLennan Just crank that volume to the point of pain. Ottawa, Canada Why waste good music on a brain? http://www.storm.ca/~seanm (Spinal Tap) From owner-xemacs-beta@xemacs.org Mon Jul 12 02:35:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA31731 for xemacs-beta-out; Mon, 12 Jul 1999 02:35:12 -0400 Received: from smtp5.mindspring.com (smtp5.mindspring.com [207.69.200.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA31726 for ; Mon, 12 Jul 1999 02:35:10 -0400 Received: from sparrow.bear.com (user-2ive2l3.dialup.mindspring.com [165.247.10.163]) by smtp5.mindspring.com (8.8.5/8.8.5) with ESMTP id CAA25940; Mon, 12 Jul 1999 02:35:08 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id CAA06014; Mon, 12 Jul 1999 02:15:54 -0400 Date: Mon, 12 Jul 1999 06:15:54 +0000 ( ) From: Justin Vallon To: Jan Vroonhof cc: xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 11 Jul 1999, Jan Vroonhof wrote: > Justin Vallon writes: > > > I think the (regexp internal fail_stack) stack size can be increased on > > all platforms from 2000 to 20000 at the cost of 16000*4 ~= 64k. > > I just had a glance at it too, but isn't the maximum (on a 32 bit machine). > > 2 * re_max_failures * MAX_FAILURE_ITEMS * 4 > > Where MAX_FAILURE_ITEMS = 5 * 3 + 5 = 19 > > thus the cost is about 38 times higher. And on a 64-bit machine it is > about 80 times higher. Which more or less explains why DEC OSF's 2MB > stack gives problems. Yes. For 32-bit machine, 2000 => 2*2000*19*4 = 304e3. 20000 => 3040e3. Double for 64-bit ints/pointers. So cost = ~2.736e6 bytes, or ~5.472e6 bytes for 64-bit machine. If stack allocation is used, the maximum of 2* is typically never reached (most likely 1024), but the worst case would be 20000*19*4 => 1.52Mb. Although, that's probably wrong because you can't un-alloca, and the re-alloca just leaks the old memory, so it could potentially waste quite a bit of stack space. I'm still not clear on what the DEC OSF comment is all about, though: #if defined (MATCH_MAY_ALLOCATE) /* 4400 was enough to cause a crash on Alpha OSF/1, whose default stack limit is 2mb. */ int re_max_failures = 20000; #else int re_max_failures = 2000; #endif Does this apply to the !defined(MATCH_MAY_ALLOCATE) code? > Does anybody know why regexp lets its stack grow exponentially? Redoubling an array on an overflow yields O(n) behavior for append/push, at the expense of space. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Mon Jul 12 06:53:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA04140 for xemacs-beta-out; Mon, 12 Jul 1999 06:53:23 -0400 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 GAA04137 for ; Mon, 12 Jul 1999 06:53:22 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA08292 for ; Mon, 12 Jul 1999 12:53:21 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0021W; Mon Jul 12 12:53:20 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA26358; Mon, 12 Jul 1999 12:53:19 +0200 To: xemacs-beta@xemacs.org Subject: Re: toolbars and compilation-height References: <14217.24934.723006.454272@simon.storm.ca> From: Jan Vroonhof Date: 12 Jul 1999 12:53:19 +0200 In-Reply-To: Sean MacLennan's message of "Sun, 11 Jul 1999 23:30:46 -0400 (EDT)" 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: Sean MacLennan writes: > (= (window-width window) (frame-width (window-frame window))) > > This is true for horizontal (or no) toolbars, and false for vertical > toolbars since window-width will be < frame width. > > Why is this line needed? And how can I find out the toolbar width? The > problem is in both 21.2-b17 and 21.0-b64. The intention is probably to keep from resizing windows that are split vertically. The code comes straight from FSF emacs and that doesn't have toolbars. Could you make a patch that uses something like (and (window-leftmost-p (selected-window)) (window-rightmost-p (selected-window))) and send it to xemacs-patches@xemacs.org. Please label the change with an ;; XEmacs comment and include a Changelog entry. Jan From owner-xemacs-beta@xemacs.org Mon Jul 12 10:07:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA09464 for xemacs-beta-out; Mon, 12 Jul 1999 10:07:20 -0400 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 KAA09461 for ; Mon, 12 Jul 1999 10:07:19 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA27674; Mon, 12 Jul 1999 16:07:10 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006kO; Mon Jul 12 16:07:05 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA26902; Mon, 12 Jul 1999 16:07:05 +0200 To: karlheg@cathcart.sysc.pdx.edu Cc: debian-devel@lists.debian.org, xemacs-beta@xemacs.org Subject: Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) From: Jan Vroonhof Date: 12 Jul 1999 16:07:04 +0200 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: Karl, did you miss the whole "Debian packagers do their own thing flamefest? > I disagree, and will ship the package with the modification. Don't > bother filing a bug about it... This is a minor change, not a hairy > major code fork. It's not a meaningful political act, just part of > the job I'm doing. No. This is a MAJOR user interface change. And frankly, I think it is _not_ part of the job you are doing. If you want to help develop XEmacs thats more than OK with me. But please use the regular channels for that and not use your position as a Debian for that. > I will, after developing something that works and looks good, submit > patches "upstream", for certain. They will be reviewed, and perhaps > will become part of XEmacs 21.2 or 21.3, depending upon timeing and > whatever-it-takes. It's not a strange new idea. No it isn't. Including your experimental patches in a major distribution is. Even more if you are going to ignore bug reports about it. Distribution packages are not the right place to do beta testing. Note that the issues here are _not_ easy to solve (you do know that what you describe was in the XEmacs betas once and was taken out again, do you?). > At any rate... I really ought to be working on the thing instead of > inspiring flame wars over it and wasting our development/study time > on email. No you _need_ to spend time on email first. You _need_ to discuss the design. Jan (at) xemacs.org From owner-xemacs-beta@xemacs.org Mon Jul 12 11:08:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA12421 for xemacs-beta-out; Mon, 12 Jul 1999 11:08:02 -0400 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 LAA12399; Mon, 12 Jul 1999 11:07:48 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id IAA23188; Mon, 12 Jul 1999 08:07:29 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-169.beasys.com [192.168.11.169]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id IAA10252; Mon, 12 Jul 1999 08:07:04 -0700 (PDT) Message-Id: <3.0.5.32.19990712160715.009d0690@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 12 Jul 1999 16:07:15 +0100 To: xemacs-review@xemacs.org From: Andy Piper Subject: gutter implementation Cc: xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_931788435==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_931788435==_ Content-Type: text/plain; charset="us-ascii" This is the substance of a patch I want to apply later in the week. I'm posting it now to see if there are any vetos or suggestions. I think its pretty neat so I'm hoping that any vetos can be worked around. There are a number of display glitches and crashes in the current patch, so use at your own risk. The idea is that with widgets you often want to put them on some screen real estate that isn't a buffer, vis-a-vis menubars or toolbars. This patch allows you do to that, providing space below (or wherever depending on the gutter and toolbar orientation) the toolbar and allowing you to display anything you can display in a buffer. The patch uses all the generic redisplay routines so there are no device-dependencies, but I have had to cons up some new generation routines to cope with strings rather than buffers. Eventually I would like to use these routines in the modeline code as they eliminate a number of problems that the modeline has with non-printable characters, variable fonts and glyphs etc. Gutter specs are implemented as specifiers and so you can have global as well as buffer, window or otherwise specific ones. andy 1999-07-12 Andy Piper * gutter.c: new file - implements gutters. All new functions are semantically equivalent to the toolbar functions. (gutter_was_visible): new function. (get_gutter_coords): ditto. (output_gutter): ditto. (clear_gutter): ditto. (update_frame_gutters): ditto. (redraw_exposed_gutter): ditto. (redraw_exposed_gutters): ditto. (free_frame_gutters): ditto. (init_frame_gutters): ditto. (decode_gutter_position): ditto. (Fset_default_gutter_position): ditto. (Fset_default_gutter_position): ditto. (Fdefault_gutter_position): ditto. (gutter_after_change): ditto. (Fgutter_specifier_p): ditto. (recompute_overlaying_specifier): ditto. (gutter_specs_changed): ditto. (default_gutter_specs_changed): ditto. (gutter_geometry_changed_in_window): ditto. (default_gutter_size_changed_in_window): ditto. (default_gutter_border_width_changed_in_window): ditto. (default_gutter_visible_p_changed_in_window): ditto. (syms_of_gutter): ditto. (vars_of_gutter): ditto. (specifier_type_create_gutter): ditto. (specifier_vars_of_gutter): ditto. * gutter.h: new file. Contains gutter constants and sizing macros similar to those for the toolbar. * winslots.h: add gutter variables. * window.h: declare window_is_* functions. * window.c (window_is_lowest): make non-static. (window_is_highest): ditto. (window_top_toolbar_height): deleted. (window_bottom_toolbar_height): deleted. (window_left_toolbar_width): deleted. (window_right_toolbar_width): deleted. (window_top_gutter_height): add gutter sizing. (window_bottom_gutter_height): ditto. (window_left_gutter_width): ditto. (window_right_gutter_width): ditto. * symsinit.h: declarations for gutters vars etc. * search.c (bi_find_next_emchar_in_string): new function. * scrollbar.c (update_scrollbar_instance): remove reference to window_bottom_toolbar_height which did nothing. * redisplay.h (struct display_line): add face indices for overriding defaults in output_display_line. Add gutter_changed flags and declarations. * redisplay.c (create_string_text_block): new function, similar to create_text_block but for strings. Display tables etc are used from the currently selected window. (generate_string_display_line): ditto. Similar to generate_display_line. (generate_displayable_area): generate display lines for a given area on a frame. Input is the string, with associated extents, to display. (redisplay_frame): add gutter_changed check. (redisplay_device): ditto. (redisplay_without_hooks): ditto. * redisplay-x.c (bevel_modeline): moved to redisplay.c. (x_redraw_exposed_area): redraw exposed gutters. (x_bevel_area): new redisplay device method. (x_type_create_redisplay_mswindows): add bevel_area device method. (x_output_display_block): fiddly Martin-style cleanup. (x_output_vertical_divider): use bevel_area. * redisplay-output.c (output_display_line): check display_lines for face information before using defaults. (bevel_modeline): new function, calls bevel_area with appropriate values. * redisplay-msw.c (bevel_modeline): moved to redisplay.c. (mswindows_redraw_exposed_area): redraw exposed gutters. (mswindows_bevel_area): new redisplay device method. (console_type_create_redisplay_mswindows): add bevel_area device method. * indent.c (string_column_at_point): add column_at_point but for strings. * glyphs-x.c (image_instantiator_format_create_glyphs_x): only instantiate widgets that we have a toolkit for. * general.c: add Qgutter. * frame.h (struct frame): add display lines for gutters and visibility flags. * frame.c (set_frame_selected_window): mark gutters changed. * emacs.c (main_1): add gutter initialisation. * device.h (struct device): add gutter_changed flag and macros to manipulate it. * console.h (struct console_methods): new bevel area redisplay method. * buffer.h (REAL_INC_CHARBYTIND): new macro for strings as REAL_INC_BYTIND is for buffers. (INC_CHARPTR): ditto. * Makefile.in.in (objs): add gutter.o --=====================_931788435==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="gut.patch" Content-Transfer-Encoding: quoted-printable Index:= src/Makefile.in.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Makefile.in.in,v retrieving revision 1.81.2.13 diff -u -r1.81.2.13 Makefile.in.in --- src/Makefile.in.in 1999/05/24 00:32:43 1.81.2.13 +++ src/Makefile.in.in 1999/07/11 18:37:24 @@ -176,7 +176,7 @@ event-stream.o extents.o faces.o\ fileio.o $(LOCK_OBJ) filemode.o floatfns.o fns.o font-lock.o\ frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o\ - gui.o $(gui_objs) hash.o imgproc.o indent.o insdel.o intl.o\ + gui.o gutter.o $(gui_objs) hash.o imgproc.o indent.o insdel.o intl.o\ keymap.o $(RTC_patch_objs) line-number.o lread.o lstream.o\ macros.o marker.o md5.o minibuf.o objects.o opaque.o\ print.o process.o profile.o\ Index:= src/buffer.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/buffer.h,v retrieving revision 1.13.2.3 diff -u -r1.13.2.3 buffer.h --- src/buffer.h 1998/12/29 10:56:49 1.13.2.3 +++ src/buffer.h 1999/07/11 18:37:42 @@ -409,6 +409,9 @@ #define REAL_INC_CHARPTR(ptr) \ ((void) ((ptr) +=3D REP_BYTES_BY_FIRST_BYTE (* (unsigned char *)= (ptr)))) +#define REAL_INC_CHARBYTIND(ptr,pos) \ + (pos +=3D REP_BYTES_BY_FIRST_BYTE (* (unsigned char *) (ptr))) + #define REAL_DEC_CHARPTR(ptr) do { \ (ptr)--; \ } while (!VALID_CHARPTR_P (ptr)) @@ -417,6 +420,11 @@ #define INC_CHARPTR(ptr) do { \ ASSERT_VALID_CHARPTR (ptr); \ REAL_INC_CHARPTR (ptr); \ +} while (0) + +#define INC_CHARBYTIND(ptr,pos) do { \ + ASSERT_VALID_CHARPTR (ptr); \ + REAL_INC_CHARBYTIND (ptr,pos); \ } while (0) #define DEC_CHARPTR(ptr) do { \ Index:= src/console.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/console.h,v retrieving revision 1.22.2.7 diff -u -r1.22.2.7 console.h --- src/console.h 1999/07/05 07:28:21 1.22.2.7 +++ src/console.h 1999/07/11 18:37:42 @@ -155,6 +155,7 @@ int duration); void (*frame_redraw_cursor_method) (struct frame *f); void (*set_final_cursor_coords_method) (struct frame *, int, int); + void (*bevel_area_method) (struct window *, face_index, int, int, int,= int, int); /* color methods */ int (*initialize_color_instance_method) (struct Lisp_Color_Instance= *, Index:= src/device.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/device.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 device.h --- src/device.h 1998/12/18 05:42:03 1.8.2.2 +++ src/device.h 1999/07/11 18:37:49 @@ -173,6 +173,7 @@ unsigned int modeline_changed :1; unsigned int point_changed :1; unsigned int size_changed :1; + unsigned int gutter_changed :1; unsigned int toolbar_changed :1; unsigned int windows_changed :1; unsigned int windows_structure_changed :1; @@ -349,6 +350,9 @@ #define MARK_DEVICE_TOOLBARS_CHANGED(d) \ ((void) (toolbar_changed =3D (d)->toolbar_changed =3D 1)) + +#define MARK_DEVICE_GUTTERS_CHANGED(d) \ + ((void) (gutter_changed =3D (d)->gutter_changed =3D 1)) #define MARK_DEVICE_SIZE_CHANGED(d) \ ((void) (size_changed =3D (d)->size_changed =3D 1)) Index:= src/emacs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.82.2.20 diff -u -r1.82.2.20 emacs.c --- src/emacs.c 1999/07/05 07:28:22 1.82.2.20 +++ src/emacs.c 1999/07/11 18:38:07 @@ -943,6 +943,7 @@ #if defined (HAVE_MENUBARS) || defined (HAVE_SCROLLBARS) || defined= (HAVE_DIALOGS) || defined (HAVE_TOOLBARS) syms_of_gui (); #endif + syms_of_gutter (); syms_of_indent (); syms_of_intl (); syms_of_keymap (); @@ -1165,6 +1166,7 @@ specifier_type_create (); specifier_type_create_image (); + specifier_type_create_gutter (); specifier_type_create_objects (); #ifdef HAVE_TOOLBARS specifier_type_create_toolbar (); @@ -1338,6 +1340,7 @@ #if defined (HAVE_MENUBARS) || defined (HAVE_SCROLLBARS) || defined= (HAVE_DIALOGS) || defined (HAVE_TOOLBARS) vars_of_gui (); #endif + vars_of_gutter (); vars_of_indent (); vars_of_insdel (); vars_of_intl (); @@ -1490,6 +1493,7 @@ */ specifier_vars_of_glyphs (); + specifier_vars_of_gutter (); #ifdef HAVE_MENUBARS specifier_vars_of_menubar (); #endif Index:= src/frame.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.c,v retrieving revision 1.37.2.5 diff -u -r1.37.2.5 frame.c --- src/frame.c 1999/06/22 18:02:56 1.37.2.5 +++ src/frame.c 1999/07/11 18:38:29 @@ -34,6 +34,7 @@ #include "faces.h" #include "frame.h" #include "glyphs.h" +#include "gutter.h" #include "menubar.h" #include "redisplay.h" #include "scrollbar.h" @@ -893,7 +894,10 @@ { #ifdef HAVE_TOOLBARS if (!EQ (f->last_nonminibuf_window,= window)) - MARK_TOOLBAR_CHANGED; + { + MARK_TOOLBAR_CHANGED; + MARK_GUTTER_CHANGED; + } #endif f->last_nonminibuf_window =3D window; } @@ -1526,6 +1530,7 @@ #ifdef HAVE_TOOLBARS free_frame_toolbars (f); #endif + free_frame_gutters (f); /* This must be done before the window and window_mirror structures are freed. The scrollbar information is attached to them. */ Index:= src/frame.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.h,v retrieving revision 1.18.2.2 diff -u -r1.18.2.2 frame.h --- src/frame.h 1998/12/18 05:42:06 1.18.2.2 +++ src/frame.h 1999/07/11 18:38:34 @@ -33,6 +33,7 @@ #include "device.h" #include "glyphs.h" +#include "redisplay.h" #define FRAME_TYPE_NAME(f) ((f)->framemeths->name) #define FRAME_TYPE(f) ((f)->framemeths->symbol) @@ -108,7 +109,12 @@ in redisplay_frame. */ unsigned int current_toolbar_size[4]; #endif + unsigned int current_gutter_size[4]; + /* Dynamic array of display lines for gutters */ + display_line_dynarr *current_display_lines; + display_line_dynarr *desired_display_lines; + /* A structure of auxiliary data specific to the device type. struct x_frame is used for X window frames; defined in console-x.h */ void *frame_data; @@ -160,6 +166,11 @@ unsigned int bottom_toolbar_was_visible :1; unsigned int left_toolbar_was_visible :1; unsigned int right_toolbar_was_visible :1; + /* gutter visibility */ + unsigned int top_gutter_was_visible :1; + unsigned int bottom_gutter_was_visible :1; + unsigned int left_gutter_was_visible :1; + unsigned int right_gutter_was_visible :1; /* redisplay flags */ unsigned int buffers_changed :1; @@ -175,6 +186,7 @@ unsigned int point_changed :1; unsigned int size_changed :1; unsigned int toolbar_changed :1; + unsigned int gutter_changed :1; unsigned int windows_changed :1; unsigned int windows_structure_changed :1; unsigned int window_face_cache_reset :1; /* used by expose handler */ @@ -340,6 +352,19 @@ } \ else \ toolbar_changed =3D 1; \ +} while (0) + +#define MARK_FRAME_GUTTERS_CHANGED(f) do { \ + struct frame *mftc_f =3D (f); \ + mftc_f->gutter_changed =3D 1; \ + mftc_f->modiff++; \ + if (!NILP (mftc_f->device)) \ + { \ + struct device *mftc_d =3D XDEVICE (mftc_f->device); \ + MARK_DEVICE_GUTTERS_CHANGED (mftc_d); \ + } \ + else \ + gutter_changed =3D 1; \ } while (0) #define MARK_FRAME_SIZE_CHANGED(f) do { \ Index:= src/general.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/general.c,v retrieving revision 1.13.2.2 diff -u -r1.13.2.2 general.c --- src/general.c 1998/12/18 05:42:07 1.13.2.2 +++ src/general.c 1999/07/11 18:38:34 @@ -89,6 +89,7 @@ Lisp_Object Qgeneric; Lisp_Object Qgeometry; Lisp_Object Qglobal; +Lisp_Object Qgutter; Lisp_Object Qheight; Lisp_Object Qhighlight; Lisp_Object Qicon; @@ -245,6 +246,7 @@ defsymbol (&Qgeneric, "generic"); defsymbol (&Qgeometry, "geometry"); defsymbol (&Qglobal, "global"); + defsymbol (&Qgutter, "gutter"); defsymbol (&Qheight, "height"); defsymbol (&Qhighlight, "highlight"); defsymbol (&Qicon, "icon"); Index:= src/glyphs-x.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-x.c,v retrieving revision 1.49.2.12 diff -u -r1.49.2.12 glyphs-x.c --- src/glyphs-x.c 1999/07/05 07:28:24 1.49.2.12 +++ src/glyphs-x.c 1999/07/11 18:38:53 @@ -2453,7 +2453,7 @@ INITIALIZE_DEVICE_IIFORMAT (x, subwindow); IIFORMAT_HAS_DEVMETHOD (x, subwindow, instantiate); - +#ifdef LWLIB_USES_MOTIF /* button widget */ INITIALIZE_DEVICE_IIFORMAT (x, button); IIFORMAT_HAS_DEVMETHOD (x, button, property); @@ -2469,10 +2469,12 @@ /* text field */ INITIALIZE_DEVICE_IIFORMAT (x, edit_field); IIFORMAT_HAS_DEVMETHOD (x, edit_field, instantiate); +#if 0 /* XmVERSION > 1*/ /* combo box */ INITIALIZE_DEVICE_IIFORMAT (x, combo_box); IIFORMAT_HAS_DEVMETHOD (x, combo_box, instantiate); - +#endif +#endif INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (cursor_font, "cursor-font"); IIFORMAT_VALID_CONSOLE (x, cursor_font); Index:= src/indent.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/indent.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 indent.c --- src/indent.c 1999/06/04 12:53:47 1.9.2.1 +++ src/indent.c 1999/07/11 18:39:02 @@ -193,6 +193,53 @@ } int +string_column_at_point (struct Lisp_String* s, Bufpos init_pos, int= tab_width) +{ + int col; + int tab_seen; + int post_tab; + Bufpos pos =3D init_pos; + Emchar c; + + if (tab_width <=3D 0 || tab_width > 1000) tab_width =3D 8; + col =3D tab_seen =3D post_tab =3D 0; + + while (1) + { + if (pos <=3D 0) + break; + + pos--; + c =3D string_char (s, pos); + if (c =3D=3D '\t') + { + if (tab_seen) + col =3D ((col + tab_width) / tab_width) * tab_width; + + post_tab +=3D col; + col =3D 0; + tab_seen =3D 1; + } + else if (c =3D=3D '\n') + break; + else +#ifdef MULE + col +=3D XCHARSET_COLUMNS (CHAR_CHARSET (c)); +#else + col ++; +#endif /* MULE */ + } + + if (tab_seen) + { + col =3D ((col + tab_width) / tab_width) * tab_width; + col +=3D post_tab; + } + + return col; +} + +int current_column (struct buffer *buf) { if (buf =3D=3D last_known_column_buffer Index:= src/redisplay-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-msw.c,v retrieving revision 1.28.2.4 diff -u -r1.28.2.4 redisplay-msw.c --- src/redisplay-msw.c 1999/06/16 22:55:14 1.28.2.4 +++ src/redisplay-msw.c 1999/07/11 18:39:12 @@ -41,6 +41,7 @@ #include "faces.h" #include "frame.h" #include "glyphs-msw.h" +#include "gutter.h" #include "redisplay.h" #include "sysdep.h" #include "window.h" @@ -75,6 +76,7 @@ face_index findex, int cursor_start, int cursor_width, int cursor_height, int offset_bitmap); +void bevel_modeline (struct window *w, struct display_line *dl); typedef struct textual_run { @@ -965,6 +967,7 @@ redraw anyhow. */ MAYBE_FRAMEMETH (f, redraw_exposed_toolbars, (f, x, y, width, height)); #endif + redraw_exposed_gutters (f, x, y, width, height); if (!f->window_face_cache_reset) { @@ -977,38 +980,36 @@ = /**************************************************************************= *** - mswindows_bevel_modeline + mswindows_bevel_area - Draw a 3d border around the modeline on window W. + Draw a 3d border around the specified area on window W. = ***************************************************************************= */ static void -mswindows_bevel_modeline (struct window *w, struct display_line= *dl) +mswindows_bevel_area (struct window *w, face_index findex, int x, int y,= + int width, int height, int shadow_thickness) { struct frame *f =3D XFRAME (w->frame); - Lisp_Object color; - int shadow_width =3D MODELINE_SHADOW_THICKNESS (w); - RECT rect =3D { WINDOW_MODELINE_LEFT (w), - dl->ypos - dl->ascent - shadow_width, - WINDOW_MODELINE_RIGHT (w), - dl->ypos + dl->descent + shadow_width}; UINT edge; - color =3D WINDOW_FACE_CACHEL_BACKGROUND (w, MODELINE_INDEX); - mswindows_update_dc (FRAME_MSWINDOWS_DC (f), Qnil, Qnil, color,= Qnil); - - if (XINT (w->modeline_shadow_thickness) < 0) - shadow_width =3D -shadow_width; - - if (shadow_width < -1) + if (shadow_thickness < -1) edge =3D EDGE_SUNKEN; - else if (shadow_width < 0) + else if (shadow_thickness < 0) edge =3D BDR_SUNKENINNER; - else if (shadow_width =3D=3D 1) + else if (shadow_thickness =3D=3D 1) edge =3D BDR_RAISEDINNER; else edge =3D EDGE_RAISED; - - DrawEdge (FRAME_MSWINDOWS_DC (f), &rect, edge, BF_RECT); + + if (shadow_thickness < 0) + shadow_thickness =3D -shadow_thickness; + + { + RECT rect =3D { x, y, x + width, y + height }; + Lisp_Object color =3D WINDOW_FACE_CACHEL_BACKGROUND (w, findex); + mswindows_update_dc (FRAME_MSWINDOWS_DC (f), Qnil, Qnil, color,= Qnil); + + DrawEdge (FRAME_MSWINDOWS_DC (f), &rect, edge, BF_RECT); + } } =0C @@ -1110,18 +1111,14 @@ rb =3D Dynarr_atp (rba, start); if (!rb) - { /* Nothing to do so don't do anything. */ return; - } - else - { - findex =3D rb->findex; - xpos =3D rb->xpos; - width =3D 0; - if (rb->type =3D=3D RUNE_CHAR) - charset =3D CHAR_CHARSET (rb->object.chr.ch); - } + + findex =3D rb->findex; + xpos =3D rb->xpos; + width =3D 0; + if (rb->type =3D=3D RUNE_CHAR) + charset =3D CHAR_CHARSET (rb->object.chr.ch); if (end < 0) end =3D Dynarr_length (rba); @@ -1295,7 +1292,7 @@ && (f->clear || f->windows_structure_changed || w->shadow_thickness_changed)) - mswindows_bevel_modeline (w, dl); + bevel_modeline (w, dl); Dynarr_free (buf); } @@ -1500,4 +1497,5 @@ CONSOLE_HAS_METHOD (mswindows, output_end); CONSOLE_HAS_METHOD (mswindows, flash); CONSOLE_HAS_METHOD (mswindows, ring_bell); + CONSOLE_HAS_METHOD (mswindows, bevel_area); } Index:= src/redisplay-output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-output.c,v retrieving revision 1.11.2.5 diff -u -r1.11.2.5 redisplay-output.c --- src/redisplay-output.c 1999/01/13 03:50:57 1.11.2.5 +++ src/redisplay-output.c 1999/07/11 18:39:19 @@ -592,7 +592,7 @@ cdl->clip !=3D ddl->clip))) { int x, y, width, height; - Lisp_Object face; + face_index findex; must_sync =3D 1; x =3D start_pixpos; @@ -601,23 +601,33 @@ height =3D ddl->ascent + ddl->descent - ddl->clip; if (x < ddl->bounds.left_in) - face =3D Vleft_margin_face; + { + findex =3D ddl->left_margin_findex ? + ddl->left_margin_findex + : get_builtin_face_cache_index (w, Vleft_margin_face); + } else if (x < ddl->bounds.right_in) - face =3D Vdefault_face; + { + /* no check here because DEFAULT_INDEX =3D=3D 0 anyway */ + findex =3D ddl->default_findex; + } else if (x < ddl->bounds.right_out) - face =3D Vright_margin_face; + { + findex =3D ddl->right_margin_findex ? + ddl->right_margin_findex + : get_builtin_face_cache_index (w, Vright_margin_face); + } else - face =3D Qnil; + findex =3D (face_index) -1; - if (!NILP (face)) + if (findex !=3D (face_index) -1) { Lisp_Object window; XSETWINDOW (window, w); /* Clear the empty area. */ - redisplay_clear_region (window, get_builtin_face_cache_index (w,= face), - x, y, width, height); + redisplay_clear_region (window, findex, x, y, width, height); /* Mark that we should clear the border. This is necessary because italic fonts may leave @@ -1602,4 +1612,29 @@ #ifdef HAVE_SCROLLBARS update_window_scrollbars (w, NULL, !MINI_WINDOW_P (w), 0); = #endif +} + +/**************************************************************************= *** + bevel_modeline + + Draw a 3d border around the modeline on window W. += ***************************************************************************= */ +void +bevel_modeline (struct window *w, struct display_line *dl) +{ + struct frame *f =3D XFRAME (w->frame); + struct device *d =3D XDEVICE (f->device); + int x, y, width, height; + int shadow_thickness =3D MODELINE_SHADOW_THICKNESS (w); + + x =3D WINDOW_MODELINE_LEFT (w); + width =3D WINDOW_MODELINE_RIGHT (w) - x; + y =3D dl->ypos - dl->ascent - shadow_thickness; + height =3D dl->ascent + dl->descent + 2 * shadow_thickness; + + if (XINT (w->modeline_shadow_thickness) < 0) + shadow_thickness =3D - shadow_thickness; + + MAYBE_DEVMETH (d, bevel_area, + (w, MODELINE_INDEX, x, y, width, height, shadow_thickness)); } Index:= src/redisplay-x.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-x.c,v retrieving revision 1.23.2.4 diff -u -r1.23.2.4 redisplay-x.c --- src/redisplay-x.c 1999/06/16 13:23:46 1.23.2.4 +++ src/redisplay-x.c 1999/07/11 18:39:35 @@ -40,6 +40,7 @@ #include "debug.h" #include "faces.h" #include "frame.h" +#include "gutter.h" #include "redisplay.h" #include "sysdep.h" #include "window.h" @@ -78,7 +79,7 @@ int xpos, face_index findex); static void x_clear_frame (struct frame *f); static void x_clear_frame_windows (Lisp_Object window); -static void x_bevel_modeline (struct window *w, struct display_line= *dl); +void bevel_modeline (struct window *w, struct display_line *dl); /* Note: We do not use the Xmb*() functions and XFontSets. @@ -334,7 +335,7 @@ int elt =3D start; face_index findex; - int xpos, width; + int xpos, width =3D 0; Lisp_Object charset =3D Qunbound; /* Qnil is a valid charset when MULE is not defined */ @@ -342,19 +343,14 @@ rb =3D Dynarr_atp (rba, start); if (!rb) - { - /* Nothing to do so don't do anything. */ - return; - } - else - { - findex =3D rb->findex; - xpos =3D rb->xpos; - width =3D 0; - if (rb->type =3D=3D RUNE_CHAR) - charset =3D CHAR_CHARSET (rb->object.chr.ch); - } + /* Nothing to do so don't do anything. */ + return; + findex =3D rb->findex; + xpos =3D rb->xpos; + if (rb->type =3D=3D RUNE_CHAR) + charset =3D CHAR_CHARSET (rb->object.chr.ch); + if (end < 0) end =3D Dynarr_length (rba); Dynarr_reset (buf); @@ -522,38 +518,40 @@ && (f->clear || f->windows_structure_changed || w->shadow_thickness_changed)) - x_bevel_modeline (w, dl); + bevel_modeline (w, dl); Dynarr_free (buf); } = /**************************************************************************= *** - x_bevel_modeline + x_bevel_area - Draw a 3d border around the modeline on window W. + Draw a shadows for the given area in the given face. = ***************************************************************************= */ static void -x_bevel_modeline (struct window *w, struct display_line *dl) +x_bevel_area (struct window *w, face_index findex, + int x, int y, int width, int height, + int shadow_thickness) { struct frame *f =3D XFRAME (w->frame); struct device *d =3D XDEVICE (f->device); + + EmacsFrame ef =3D (EmacsFrame) FRAME_X_TEXT_WIDGET (f); Display *dpy =3D DEVICE_X_DISPLAY (d); Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f)); - EmacsFrame ef =3D (EmacsFrame) FRAME_X_TEXT_WIDGET (f); - GC top_shadow_gc, bottom_shadow_gc, background_gc; Pixel top_shadow_pixel, bottom_shadow_pixel, background_pixel; - XColor tmp_color; Lisp_Object tmp_pixel; - int x, y, width, height; + XColor tmp_color; XGCValues gcv; - unsigned long mask; + GC top_shadow_gc, bottom_shadow_gc, background_gc; + int use_pixmap =3D 0; int flip_gcs =3D 0; - int shadow_thickness; + unsigned long mask; memset (&gcv, ~0, sizeof (XGCValues)); - tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, MODELINE_INDEX); + tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, findex); tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); /* First, get the GC's. */ @@ -564,12 +562,14 @@ x_generate_shadow_pixels (f, &top_shadow_pixel, &bottom_shadow_pixel, background_pixel, ef->core.background_pixel); - tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, MODELINE_INDEX); + tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, findex); tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); gcv.background =3D tmp_color.pixel; gcv.graphics_exposures =3D False; mask =3D GCForeground | GCBackground | GCGraphicsExposures; + /* If we can't distinguish one of the shadows (the color is the same as= the + background), it's better to use a pixmap to generate a dithered gray.= */ if (top_shadow_pixel =3D=3D background_pixel || bottom_shadow_pixel =3D=3D background_pixel) use_pixmap =3D 1; @@ -583,15 +583,16 @@ gray_width, gray_height, 1, 0, 1); } - tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, MODELINE_INDEX); + tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, findex); tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); gcv.foreground =3D tmp_color.pixel; + /* this is needed because the GC draws with a pixmap here */ gcv.fill_style =3D FillOpaqueStippled; gcv.stipple =3D DEVICE_X_GRAY_PIXMAP (d); top_shadow_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, (mask | GCStipple | GCFillStyle)); - tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, MODELINE_INDEX); + tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, findex); tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); bottom_shadow_pixel =3D tmp_color.pixel; @@ -617,23 +618,23 @@ gcv.foreground =3D background_pixel; background_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, mask); - if (XINT (w->modeline_shadow_thickness) < 0) + /* possibly revert the GC's in case the shadow thickness is < 0. + This will give a depressed look to the divider */ + if (shadow_thickness < 0) { GC temp; temp =3D top_shadow_gc; top_shadow_gc =3D bottom_shadow_gc; bottom_shadow_gc =3D temp; - } - - shadow_thickness =3D MODELINE_SHADOW_THICKNESS (w); - x =3D WINDOW_MODELINE_LEFT (w); - width =3D WINDOW_MODELINE_RIGHT (w) - x; - y =3D dl->ypos - dl->ascent - shadow_thickness; - height =3D dl->ascent + dl->descent + 2 * shadow_thickness; + /* better avoid a Bad Address XLib error ;-) */ + shadow_thickness =3D - shadow_thickness; + } - x_output_shadows (f, x, y, width, height, top_shadow_gc,= bottom_shadow_gc, + /* Draw the shadows around the divider line */ + x_output_shadows (f, x, y, width, height, + top_shadow_gc, bottom_shadow_gc, background_gc, shadow_thickness); } @@ -1397,17 +1398,13 @@ struct frame *f =3D XFRAME (w->frame); struct device *d =3D XDEVICE (f->device); - EmacsFrame ef =3D (EmacsFrame) FRAME_X_TEXT_WIDGET (f); Display *dpy =3D DEVICE_X_DISPLAY (d); Window x_win =3D XtWindow (FRAME_X_TEXT_WIDGET (f)); - Pixel top_shadow_pixel, bottom_shadow_pixel, background_pixel; Lisp_Object tmp_pixel; XColor tmp_color; XGCValues gcv; - GC top_shadow_gc, bottom_shadow_gc, background_gc; + GC background_gc; - int use_pixmap =3D 0; - int flip_gcs =3D 0; unsigned long mask; int x, y1, y2, width, shadow_thickness, spacing, line_width; face_index div_face =3D get_builtin_face_cache_index (w,= Vvertical_divider_face); @@ -1426,83 +1423,12 @@ tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); /* First, get the GC's. */ - top_shadow_pixel =3D tmp_color.pixel; - bottom_shadow_pixel =3D tmp_color.pixel; - background_pixel =3D tmp_color.pixel; - - x_generate_shadow_pixels (f, &top_shadow_pixel,= &bottom_shadow_pixel, - background_pixel, ef->core.background_pixel); - - tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, div_face); - tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); gcv.background =3D tmp_color.pixel; + gcv.foreground =3D tmp_color.pixel; gcv.graphics_exposures =3D False; mask =3D GCForeground | GCBackground | GCGraphicsExposures; - - /* If we can't distinguish one of the shadows (the color is the same as= the - background), it's better to use a pixmap to generate a dithered gray.= */ - if (top_shadow_pixel =3D=3D background_pixel || - bottom_shadow_pixel =3D=3D background_pixel) - use_pixmap =3D 1; - - if (use_pixmap) - { - if (DEVICE_X_GRAY_PIXMAP (d) =3D=3D None) - { - DEVICE_X_GRAY_PIXMAP (d) =3D - XCreatePixmapFromBitmapData (dpy, x_win, (char *) gray_bits, - gray_width, gray_height, 1, 0, 1); - } - - tmp_pixel =3D WINDOW_FACE_CACHEL_BACKGROUND (w, div_face); - tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); - gcv.foreground =3D tmp_color.pixel; - /* this is needed because the GC draws with a pixmap here */ - gcv.fill_style =3D FillOpaqueStippled; - gcv.stipple =3D DEVICE_X_GRAY_PIXMAP (d); - top_shadow_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, - (mask | GCStipple | GCFillStyle)); - - tmp_pixel =3D WINDOW_FACE_CACHEL_FOREGROUND (w, div_face); - tmp_color =3D COLOR_INSTANCE_X_COLOR (XCOLOR_INSTANCE (tmp_pixel)); - bottom_shadow_pixel =3D tmp_color.pixel; - - flip_gcs =3D (bottom_shadow_pixel =3D=3D - WhitePixelOfScreen (DefaultScreenOfDisplay (dpy))); - } - else - { - gcv.foreground =3D top_shadow_pixel; - top_shadow_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv,= mask); - } - - gcv.foreground =3D bottom_shadow_pixel; - bottom_shadow_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv,= mask); - - if (use_pixmap && flip_gcs) - { - GC tmp_gc =3D bottom_shadow_gc; - bottom_shadow_gc =3D top_shadow_gc; - top_shadow_gc =3D tmp_gc; - } - - gcv.foreground =3D background_pixel; background_gc =3D gc_cache_lookup (DEVICE_X_GC_CACHE (d), &gcv, mask); - /* possibly revert the GC's in case the shadow thickness is < 0. - This will give a depressed look to the divider */ - if (shadow_thickness < 0) - { - GC temp; - - temp =3D top_shadow_gc; - top_shadow_gc =3D bottom_shadow_gc; - bottom_shadow_gc =3D temp; - - /* better avoid a Bad Address XLib error ;-) */ - shadow_thickness =3D - shadow_thickness; - } - /* Clear the divider area first. This needs to be done when a window split occurs. */ if (clear) @@ -1514,10 +1440,9 @@ line_width, y2 - y1); /* Draw the shadows around the divider line */ - x_output_shadows (f, x + spacing, y1, - width - 2 * spacing, y2 - y1, - top_shadow_gc, bottom_shadow_gc, - background_gc, shadow_thickness); + x_bevel_area (w, div_face, x + spacing, y1, + width - 2 * spacing, y2 - y1, + shadow_thickness); } = /**************************************************************************= *** @@ -1979,6 +1904,7 @@ redraw anyhow. */ MAYBE_FRAMEMETH (f, redraw_exposed_toolbars, (f, x, y, width, height)); #endif + redraw_exposed_gutters (f, x, y, width, height); if (!f->window_face_cache_reset) { @@ -2274,4 +2200,5 @@ CONSOLE_HAS_METHOD (x, output_end); CONSOLE_HAS_METHOD (x, flash); CONSOLE_HAS_METHOD (x, ring_bell); + CONSOLE_HAS_METHOD (x, bevel_area); } Index:= src/redisplay.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.7 diff -u -r1.55.2.7 redisplay.c --- src/redisplay.c 1999/05/12 14:36:15 1.55.2.7 +++ src/redisplay.c 1999/07/11 18:40:13 @@ -51,6 +51,7 @@ #include "faces.h" #include "frame.h" #include "glyphs.h" +#include "gutter.h" #include "insdel.h" #include "menubar.h" #include "objects.h" @@ -271,6 +272,9 @@ static void update_line_start_cache (struct window *w, Bufpos from, Bufpos= to, Bufpos point, int no_regen); static int point_visible (struct window *w, Bufpos point, int= type); +extern Bytind bi_find_next_emchar_in_string (struct Lisp_String* str,= Emchar target, + Bytind st, EMACS_INT count); +extern int string_column_at_point (struct Lisp_String* s, Bufpos init_pos,= int tab_width); /* This used to be 10 but 30 seems to give much better performance. */ #define INIT_MAX_PREEMPTS 30 @@ -401,6 +405,10 @@ int toolbar_changed; int toolbar_changed_set; +/* non-nil if any gutter has changed */ +int gutter_changed; +int gutter_changed_set; + /* non-nil if any window has changed since the last time redisplay= completed */ int windows_changed; @@ -4178,90 +4186,918 @@ =0C = /**************************************************************************= */ -/* */ -/* window-regeneration routines = */ -/* */ +/* */ +/* displayable string= routines */ +/* */ = /**************************************************************************= */ -/* For a given window and starting position in the buffer it contains, - ensure that the TYPE display lines accurately represent the - presentation of the window. We pass the buffer instead of getting - it from the window since redisplay_window may have temporarily - changed it to the echo area buffer. */ +/* Given a position for a string in a window, ensure that the given + display line DL accurately represents the text on a line starting + at the given position. -static void -regenerate_window (struct window *w, Bufpos start_pos, Bufpos point, int= type) + Yes, this is duplicating the code of create_text_block, but it + looked just too hard to change create_text_block to handle strings + *and* buffers. We already make a distinction between the two + elsewhere in the code so I think unifying them would require a + complete MULE rewrite. Besides, the other distinction is that these + functions cover text that the user *cannot edit* so we can remove + everything to do with cursors, minibuffers etc. Eventually the + modeline routines should be modified to use this code as it copes + with many more types of display situation. */ + +static Bufpos +create_string_text_block (struct window *w, Lisp_Object disp_string, + struct display_line *dl, + Bufpos start_pos, + prop_block_dynarr **prop, + face_index default_face) { struct frame *f =3D XFRAME (w->frame); + /* Note that a lot of the buffer controlled stuff has been left in + because you might well want to make use of it (selective display + etc), its just the buffer text that we do not use. */ struct buffer *b =3D XBUFFER (w->buffer); - int ypos =3D WINDOW_TEXT_TOP (w); - int yend; /* set farther down */ + struct device *d =3D XDEVICE (f->device); + struct Lisp_String* s =3D XSTRING (disp_string); - prop_block_dynarr *prop; - layout_bounds bounds; - display_line_dynarr *dla; - int need_modeline; + /* we're working with these a lot so precalculate them */ + Bytecount slen =3D XSTRING_LENGTH (disp_string); + Bytecount bi_string_zv =3D slen - 1; + Bytind bi_start_pos =3D charcount_to_bytecount (string_data (s),= start_pos); - /* The lines had better exist by this point. */ - if (!(dla =3D window_display_lines (w, type))) - abort (); - Dynarr_reset (dla); - w->max_line_len =3D 0; + pos_data data; - /* Normally these get updated in redisplay_window but it is possible - for this function to get called from some other points where that - update may not have occurred. This acts as a safety check. */ - if (!Dynarr_length (w->face_cachels)) - reset_face_cachels (w); - if (!Dynarr_length (w->glyph_cachels)) - reset_glyph_cachels (w); + int truncate_win =3D window_truncation_on (w); + int end_glyph_width; - Fset_marker (w->start[type], make_int (start_pos), w->buffer); - Fset_marker (w->pointm[type], make_int (point), w->buffer); - w->last_point_x[type] =3D -1; - w->last_point_y[type] =3D -1; + /* we're going to ditch selective display for static text, its an + FSF thing and invisble extents are the way to go + here. Implementing it also relies on a number of buffer-specific + functions that we don't have the luxury of being able to use + here. */ - /* Make sure a modeline is in the structs if needed. */ - need_modeline =3D ensure_modeline_generated (w, type); + /* The variable ctl-arrow allows the user to specify what characters + can actually be displayed and which octal should be used for. + #### This variable should probably have some rethought done to + it. - /* Wait until here to set this so that the structs have a modeline - generated in the case where one didn't exist. */ - yend =3D WINDOW_TEXT_BOTTOM (w); + #### It would also be really nice if you could specify that + the characters come out in hex instead of in octal. Mule + does that by adding a ctl-hexa variable similar to ctl-arrow, + but that's bogus -- we need a more general solution. I + think you need to extend the concept of display tables + into a more general conversion mechanism. Ideally you + could specify a Lisp function that converts characters, + but this violates the Second Golden Rule and besides would + make things way way way way slow. - bounds =3D calculate_display_line_boundaries (w, 0); + So instead, we extend the display-table concept, which was + historically limited to 256-byte vectors, to one of the + following: - /* 97/3/14 jhod: stuff added here to support pre-prompts (used for input= systems) */ - if (MINI_WINDOW_P (w) - && (!NILP (Vminibuf_prompt) || !NILP (Vminibuf_preprompt)) - && !echo_area_active (f) - && start_pos =3D=3D BUF_BEGV (b)) - { - struct prop_block pb; - Lisp_Object string; - prop =3D Dynarr_new (prop_block); + a) A 256-entry vector, for backward compatibility; + b) char-table, mapping characters to values; + c) range-table, mapping ranges of characters to values; + d) a list of the above. - string =3D concat2(Vminibuf_preprompt, Vminibuf_prompt); - pb.type =3D PROP_MINIBUF_PROMPT; - pb.data.p_string.str =3D XSTRING_DATA(string); - pb.data.p_string.len =3D XSTRING_LENGTH(string); - Dynarr_add (prop, pb); + The (d) option allows you to specify multiple display tables + instead of just one. Each display table can specify conversions + for some characters and leave others unchanged. The way the + character gets displayed is determined by the first display table + with a binding for that character. This way, you could call a + function `enable-hex-display' that adds a hex display-table to + the list of display tables for the current buffer. + + #### ...not yet implemented... Also, we extend the concept of + "mapping" to include a printf-like spec. Thus you can make all + extended characters show up as hex with a display table like + this: + + #s(range-table data ((256 524288) (format "%x"))) + + Since more than one display table is possible, you have + great flexibility in mapping ranges of characters. */ + Emchar printable_min =3D (CHAR_OR_CHAR_INTP (b->ctl_arrow) + ? XCHAR_OR_CHAR_INT (b->ctl_arrow) + : ((EQ (b->ctl_arrow, Qt) || EQ (b->ctl_arrow, Qnil)) + ? 255 : 160)); + + Lisp_Object face_dt, window_dt; + + /* The text display block for this display line. */ + struct display_block *db =3D get_display_block_from_line (dl, TEXT); + + /* The first time through the main loop we need to force the glyph + data to be updated. */ + int initial =3D 1; + + /* Apparently the new extent_fragment_update returns an end position + equal to the position passed in if there are no more runs to be + displayed. */ + int no_more_frags =3D 0; + + dl->used_prop_data =3D 0; + dl->num_chars =3D 0; + + /* set up faces to use for clearing areas, used by + output_display_line */ + dl->default_findex =3D default_face; + if (default_face) + { + dl->left_margin_findex =3D default_face; + dl->right_margin_findex =3D default_face; } else - prop =3D 0; + { + dl->left_margin_findex =3D + get_builtin_face_cache_index (w, Vleft_margin_face); + dl->right_margin_findex =3D + get_builtin_face_cache_index (w, Vright_margin_face); + } - while (ypos < yend) + xzero (data); + data.ef =3D extent_fragment_new (disp_string, f); + + /* These values are used by all of the rune addition routines. We add + them to this structure for ease of passing. */ + data.d =3D d; + XSETWINDOW (data.window, w); + data.db =3D db; + data.dl =3D dl; + + data.bi_bufpos =3D bi_start_pos; + data.pixpos =3D dl->bounds.left_in; + data.last_charset =3D Qunbound; + data.last_findex =3D default_face; + data.result_str =3D Qnil; + + /* Set the right boundary adjusting it to take into account any end + glyph. Save the width of the end glyph for later use. */ + data.max_pixpos =3D dl->bounds.right_in; + if (truncate_win) + end_glyph_width =3D GLYPH_CACHEL_WIDTH (w, TRUN_GLYPH_INDEX); + else + end_glyph_width =3D GLYPH_CACHEL_WIDTH (w, CONT_GLYPH_INDEX); + data.max_pixpos -=3D end_glyph_width; + + data.cursor_type =3D NO_CURSOR; + data.cursor_x =3D -1; + + data.start_col =3D 0; + /* I don't think we want this, string areas should not scroll with + the window + data.start_col =3D w->hscroll; + data.bi_start_col_enabled =3D (w->hscroll ? bi_start_pos : 0); + */ + data.bi_start_col_enabled =3D 0; + data.hscroll_glyph_width_adjust =3D 0; + + /* We regenerate the line from the very beginning. */ + Dynarr_reset (db->runes); + + /* Why is this less than or equal and not just less than? If the + starting position is already equal to the maximum we can't add + anything else, right? Wrong. We might still have a newline to + add. A newline can use the room allocated for an end glyph since + if we add it we know we aren't going to be adding any end + glyph. */ + + /* #### Chuck -- I think this condition should be while (1). + Otherwise if (e.g.) there is one begin-glyph and one end-glyph + and the begin-glyph ends exactly at the end of the window, the + end-glyph and text might not be displayed. while (1) ensures + that the loop terminates only when either (a) there is + propagation data or (b) the end-of-line or end-of-buffer is hit. + + #### Also I think you need to ensure that the operation + "add begin glyphs; add end glyphs; add text" is atomic and + can't get interrupted in the middle. If you run off the end + of the line during that operation, then you keep accumulating + propagation data until you're done. Otherwise, if the (e.g.) + there's a begin glyph at a particular position and attempting + to display that glyph results in window-end being hit and + propagation data being generated, then the character at that + position won't be displayed. + + #### See also the comment after the end of this loop, below. + */ + while (data.pixpos <=3D data.max_pixpos) { - struct display_line dl; - struct display_line *dlp; - int local; + /* #### This check probably should not be necessary. */ + if (data.bi_bufpos > bi_string_zv) + { + /* #### urk! More of this lossage! */ + data.bi_bufpos--; + goto done; + } - if (Dynarr_length (dla) < Dynarr_largest (dla)) + /* Check for face changes. */ + if (initial || (!no_more_frags && data.bi_bufpos =3D=3D= data.ef->end)) { - dlp =3D Dynarr_atp (dla, Dynarr_length (dla)); - local =3D 0; + /* Now compute the face and begin/end-glyph information. */ + data.findex =3D + /* Remember that the extent-fragment routines deal in Bytind's. */ + extent_fragment_update (w, data.ef, data.bi_bufpos); + /* This is somewhat cheesy but the alternative is to + propagate default_face into extent_fragment_update. */ + if (data.findex =3D=3D DEFAULT_INDEX) + data.findex =3D default_face; + + get_display_tables (w, data.findex, &face_dt, &window_dt); + + if (data.bi_bufpos =3D=3D data.ef->end) + no_more_frags =3D 1; } - else + initial =3D 0; + + /* Determine what is next to be displayed. We first handle any + glyphs returned by glyphs_at_bufpos. If there are no glyphs to + display then we determine what to do based on the character at= the + current buffer position. */ + + /* If the current position is covered by an invisible extent, do + nothing (except maybe add some ellipses). + + #### The behavior of begin and end-glyphs at the edge of an + invisible extent should be investigated further. This is + fairly low priority though. */ + if (data.ef->invisible) { + /* #### Chuck, perhaps you could look at this code? I don't + really know what I'm doing. */ + if (*prop) + { + Dynarr_free (*prop); + *prop =3D 0; + } + + /* The extent fragment code only sets this when we should + really display the ellipses. It makes sure the ellipses + don't get displayed more than once in a row. */ + if (data.ef->invisible_ellipses) + { + struct glyph_block gb; + + data.ef->invisible_ellipses_already_displayed =3D 1; + data.ef->invisible_ellipses =3D 0; + gb.extent =3D Qnil; + gb.glyph =3D Vinvisible_text_glyph; + *prop =3D add_glyph_rune (&data, &gb, BEGIN_GLYPHS, 0, + GLYPH_CACHEL (w, INVIS_GLYPH_INDEX)); + /* Perhaps they shouldn't propagate if the very next thing + is to display a newline (for compatibility with + selective-display-ellipses)? Maybe that's too + abstruse. */ + if (*prop) + goto done; + } + + /* #### What if we we're dealing with a display table? */ + if (data.start_col) + data.start_col--; + + if (data.bi_bufpos =3D=3D bi_string_zv) + goto done; + else + INC_CHARBYTIND (string_data (s), data.bi_bufpos); + } + + /* If there is propagation data, then it represents the current + buffer position being displayed. Add them and advance the + position counter. This might also add the minibuffer + prompt. */ + else if (*prop) + { + dl->used_prop_data =3D 1; + *prop =3D add_propagation_runes (prop, &data); + + if (*prop) + goto done; /* gee, a really narrow window */ + else if (data.bi_bufpos =3D=3D bi_string_zv) + goto done; + else if (data.bi_bufpos < 0) + /* #### urk urk urk! Aborts are not very fun! Fix this please! */ + data.bi_bufpos =3D 0; + else + INC_CHARBYTIND (string_data (s), data.bi_bufpos); + } + + /* If there are end glyphs, add them to the line. These are + the end glyphs for the previous run of text. We add them + here rather than doing them at the end of handling the + previous run so that glyphs at the beginning and end of + a line are handled correctly. */ + else if (Dynarr_length (data.ef->end_glyphs) > 0) + { + *prop =3D add_glyph_runes (&data, END_GLYPHS); + if (*prop) + goto done; + } + + /* If there are begin glyphs, add them to the line. */ + else if (Dynarr_length (data.ef->begin_glyphs) > 0) + { + *prop =3D add_glyph_runes (&data, BEGIN_GLYPHS); + if (*prop) + goto done; + } + + /* If at end-of-buffer, we've already processed begin and + end-glyphs at this point and there's no text to process, + so we're done. */ + else if (data.bi_bufpos =3D=3D bi_string_zv) + goto done; + + else + { + Lisp_Object entry =3D Qnil; + /* Get the character at the current buffer position. */ + data.ch =3D string_char (s, data.bi_bufpos); + if (!NILP (face_dt) || !NILP (window_dt)) + entry =3D display_table_entry (data.ch, face_dt, window_dt); + + /* If there is a display table entry for it, hand it off to + add_disp_table_entry_runes and let it worry about it. */ + if (!NILP (entry) && !EQ (entry, make_char (data.ch))) + { + *prop =3D add_disp_table_entry_runes (&data, entry); + + if (*prop) + goto done; + } + + /* Check if we have hit a newline character. If so, add a marker + to the line and end this loop. */ + else if (data.ch =3D=3D '\n') + { + /* We aren't going to be adding an end glyph so give its + space back in order to make sure that the cursor can + fit. */ + data.max_pixpos +=3D end_glyph_width; + goto done; + } + + /* If the current character is considered to be printable, then + just add it. */ + else if (data.ch >=3D printable_min) + { + *prop =3D add_emchar_rune (&data); + if (*prop) + goto done; + } + + /* If the current character is a tab, determine the next tab + starting position and add a blank rune which extends from= the + current pixel position to that starting position. */ + else if (data.ch =3D=3D '\t') + { + int tab_start_pixpos =3D data.pixpos; + int next_tab_start; + int char_tab_width; + int prop_width =3D 0; + + if (data.start_col > 1) + tab_start_pixpos -=3D (space_width (w) * (data.start_col - 1)); + + next_tab_start =3D + next_tab_position (w, tab_start_pixpos, + dl->bounds.left_in + + data.hscroll_glyph_width_adjust); + if (next_tab_start > data.max_pixpos) + { + prop_width =3D next_tab_start - data.max_pixpos; + next_tab_start =3D data.max_pixpos; + } + data.blank_width =3D next_tab_start - data.pixpos; + char_tab_width =3D + (next_tab_start - tab_start_pixpos) / space_width (w); + + *prop =3D add_blank_rune (&data, w, char_tab_width); + + /* add_blank_rune is only supposed to be called with + sizes guaranteed to fit in the available space. */ + assert (!(*prop)); + + if (prop_width) + { + struct prop_block pb; + *prop =3D Dynarr_new (prop_block); + + pb.type =3D PROP_BLANK; + pb.data.p_blank.width =3D prop_width; + pb.data.p_blank.findex =3D data.findex; + Dynarr_add (*prop, pb); + + goto done; + } + } + + /* If character is a control character, pass it off to + add_control_char_runes. + + The is_*() routines have undefined results on + arguments outside of the range [-1, 255]. (This + often bites people who carelessly use `char' instead + of `unsigned char'.) + */ + else if (data.ch < 0x100 && iscntrl ((Bufbyte) data.ch)) + { + *prop =3D add_control_char_runes (&data, b); + + if (*prop) + goto done; + } + + /* If the character is above the ASCII range and we have not + already handled it, then print it as an octal number. */ + else if (data.ch >=3D 0200) + { + *prop =3D add_octal_runes (&data); + + if (*prop) + goto done; + } + + /* Assume the current character is considered to be printable, + then just add it. */ + else + { + *prop =3D add_emchar_rune (&data); + if (*prop) + goto done; + } + + INC_CHARBYTIND (string_data (s), data.bi_bufpos); + } + } + +done: + + /* Determine the starting point of the next line if we did not hit the + end of the buffer. */ + if (data.bi_bufpos < bi_string_zv) + { + /* #### This check is not correct. If the line terminated + due to a begin-glyph or end-glyph hitting window-end, then + data.ch will not point to the character at data.bi_bufpos. If + you make the two changes mentioned at the top of this loop, + you should be able to say '(if (*prop))'. That should also + make it possible to eliminate the data.bi_bufpos < BI_BUF_ZV (b) + check. */ + + /* The common case is that the line ended because we hit a newline. + In that case, the next character is just the next buffer + position. */ + if (data.ch =3D=3D '\n') + { + INC_CHARBYTIND (string_data (s), data.bi_bufpos); + } + + /* Otherwise we have a buffer line which cannot fit on one display + line. */ + else + { + struct glyph_block gb; + struct glyph_cachel *cachel; + + /* If the line is to be truncated then we actually have to look + for the next newline. We also add the end-of-line glyph= which + we know will fit because we adjusted the right border before + we starting laying out the line. */ + data.max_pixpos +=3D end_glyph_width; + data.findex =3D default_face; + gb.extent =3D Qnil; + + if (truncate_win) + { + Bytind bi_pos; + + /* Now find the start of the next line. */ + bi_pos =3D bi_find_next_emchar_in_string (s, '\n', data.bi_bufpos,= 1); + + data.cursor_type =3D NO_CURSOR; + data.bi_bufpos =3D bi_pos; + gb.glyph =3D Vtruncation_glyph; + cachel =3D GLYPH_CACHEL (w, TRUN_GLYPH_INDEX); + } + else + { + /* The cursor can never be on the continuation glyph. */ + data.cursor_type =3D NO_CURSOR; + + /* data.bi_bufpos is already at the start of the next line. */ + + gb.glyph =3D Vcontinuation_glyph; + cachel =3D GLYPH_CACHEL (w, CONT_GLYPH_INDEX); + } + + add_glyph_rune (&data, &gb, BEGIN_GLYPHS, 1, cachel); + + if (truncate_win && data.bi_bufpos =3D=3D bi_string_zv) + { + CONST Bufbyte* endb =3D charptr_n_addr (string_data (s),= bi_string_zv); + DEC_CHARPTR (endb); + if (charptr_emchar (endb) !=3D '\n') + { + /* #### Damn this losing shit. */ + data.bi_bufpos++; + } + } + } + } + else if (data.bi_bufpos =3D=3D bi_string_zv) + { + /* We need to add a marker to the end of the line since there is no + newline character in order for the cursor to get drawn. We= label + it as a newline so that it gets handled correctly by the + whitespace routines below. */ + + data.ch =3D '\n'; + data.blank_width =3D DEVMETH (d, eol_cursor_width, ()); + data.findex =3D default_face; + data.start_col =3D 0; + data.bi_start_col_enabled =3D 0; + + data.max_pixpos +=3D data.blank_width; + add_emchar_rune (&data); + data.max_pixpos -=3D data.blank_width; + +=20 /* #### urk! Chuck, this shit is bad news. Going around + manipulating invalid positions is guaranteed to result in + trouble sooner or later. */ + data.bi_bufpos =3D bi_string_zv + 1; + } + + /* Calculate left whitespace boundary. */ + { + int elt =3D 0; + + /* Whitespace past a newline is considered right whitespace. */ + while (elt < Dynarr_length (db->runes)) + { + struct rune *rb =3D Dynarr_atp (db->runes, elt); + + if ((rb->type =3D=3D RUNE_CHAR && rb->object.chr.ch =3D=3D ' ') + || rb->type =3D=3D RUNE_BLANK) + { + dl->bounds.left_white +=3D rb->width; + elt++; + } + else + elt =3D Dynarr_length (db->runes); + } + } + + /* Calculate right whitespace boundary. */ + { + int elt =3D Dynarr_length (db->runes) - 1; + int done =3D 0; + + while (!done && elt >=3D 0) + { + struct rune *rb =3D Dynarr_atp (db->runes, elt); + + if (!(rb->type =3D=3D RUNE_CHAR && rb->object.chr.ch < 0x100 + && isspace (rb->object.chr.ch)) + && !rb->type =3D=3D RUNE_BLANK) + { + dl->bounds.right_white =3D rb->xpos + rb->width; + done =3D 1; + } + + elt--; + + } + + /* The line is blank so everything is considered to be right + whitespace. */ + if (!done) + dl->bounds.right_white =3D dl->bounds.left_in; + } + + /* Set the display blocks bounds. */ + db->start_pos =3D dl->bounds.left_in; + if (Dynarr_length (db->runes)) + { + struct rune *rb =3D Dynarr_atp (db->runes, Dynarr_length (db->runes)= - 1); + + db->end_pos =3D rb->xpos + rb->width; + } + else + db->end_pos =3D dl->bounds.right_white; + + /* update line height parameters */ + if (!data.new_ascent && !data.new_descent) + { + /* We've got a blank line so initialize these values from the= default + face. */ + default_face_font_info (data.window, &data.new_ascent, + &data.new_descent, 0, 0, 0); + } + + if (data.max_pixmap_height) + { + int height =3D data.new_ascent + data.new_descent; + int pix_ascent, pix_descent; + + pix_descent =3D data.max_pixmap_height * data.new_descent / height; + pix_ascent =3D data.max_pixmap_height - pix_descent; + + data.new_ascent =3D max (data.new_ascent, pix_ascent); + data.new_descent =3D max (data.new_descent, pix_descent); + } + + dl->ascent =3D data.new_ascent; + dl->descent =3D data.new_descent; + + { + unsigned short ascent =3D (unsigned short) XINT= (w->minimum_line_ascent); + + if (dl->ascent < ascent) + dl->ascent =3D ascent; + } + { + unsigned short descent =3D (unsigned short) XINT= (w->minimum_line_descent); + + if (dl->descent < descent) + dl->descent =3D descent; + } + + dl->cursor_elt =3D data.cursor_x; + /* #### lossage lossage lossage! Fix this shit! */ + if (data.bi_bufpos > bi_string_zv) + dl->end_bufpos =3D buffer_or_string_bytind_to_bufpos (disp_string,= bi_string_zv); + else + dl->end_bufpos =3D buffer_or_string_bytind_to_bufpos (disp_string,= data.bi_bufpos) - 1; + if (truncate_win) + data.dl->num_chars =3D + string_column_at_point (s, dl->end_bufpos, XINT (b->tab_width)); + else + /* This doesn't correctly take into account tabs and control + characters but if the window isn't being truncated then this + value isn't going to end up being used anyhow. */ + data.dl->num_chars =3D dl->end_bufpos - dl->bufpos; + + /* #### handle horizontally scrolled line with text none of which + was actually laid out. */ + + /* #### handle any remainder of overlay arrow */ + + if (*prop =3D=3D ADD_FAILED) + *prop =3D NULL; + + if (truncate_win && *prop) + { + Dynarr_free (*prop); + *prop =3D NULL; + } + + extent_fragment_delete (data.ef); + + /* #### If we started at EOB, then make sure we return a value past + it so that regenerate_window will exit properly. This is bogus. + The main loop should get fixed so that it isn't necessary to call + this function if we are already at EOB. */ + + if (data.bi_bufpos =3D=3D bi_string_zv && bi_start_pos =3D=3D= bi_string_zv) + return bytecount_to_charcount (string_data (s), data.bi_bufpos) + 1; /*= Yuck! */ + else + return bytecount_to_charcount (string_data (s),= data.bi_bufpos); +} + +/* Given a display line and a starting position, ensure that the + contents of the display line accurately represent the visual + representation of the buffer contents starting from the given + position when displayed in the given window. The display line ends + when the contents of the line reach the right boundary of the given + window. + + This is very similar to generate_display_line but with the same + limitations as create_string_text_block. I have taken the liberty + of fixing the bytind stuff though.*/ + +static Bufpos +generate_string_display_line (struct window *w, Lisp_Object= disp_string, + struct display_line *dl, + Bufpos start_pos, + prop_block_dynarr **prop, + face_index default_face) +{ + Bufpos ret_bufpos; + + /* you must set bounds before calling this. */ + + /* Reset what this line is using. */ + if (dl->display_blocks) + Dynarr_reset (dl->display_blocks); + if (dl->left_glyphs) + { + Dynarr_free (dl->left_glyphs); + dl->left_glyphs =3D 0; + } + if (dl->right_glyphs) + { + Dynarr_free (dl->right_glyphs); + dl->right_glyphs =3D 0; + } + + /* We aren't generating a modeline at the moment. */ + dl->modeline =3D 0; + + /* Create a display block for the text region of the line. */ + ret_bufpos =3D create_string_text_block (w, disp_string, dl,= start_pos, + prop, default_face); + dl->bufpos =3D start_pos; + if (dl->end_bufpos < dl->bufpos) + dl->end_bufpos =3D dl->bufpos; + + /* If there are left glyphs associated with any character in the + text block, then create a display block to handle them. */ + if (dl->left_glyphs !=3D NULL && Dynarr_length (dl->left_glyphs)) + create_left_glyph_block (w, dl, 0); + + /* If there are right glyphs associated with any character in the + text block, then create a display block to handle them. */ + if (dl->right_glyphs !=3D NULL && Dynarr_length (dl->right_glyphs)) + create_right_glyph_block (w, dl); + + return ret_bufpos; +} + +/* This is ripped off from regenerate_window. All we want to do is + loop through elements in the string creating display lines until we + have covered the provided area. Simple really. = */ +void +generate_displayable_area (struct window *w, Lisp_Object disp_string, + int xpos, int ypos, int width, int height, + display_line_dynarr* dla, + Bufpos start_pos, + face_index default_face) +{ + int yend =3D ypos + height; + + prop_block_dynarr *prop =3D 0; + layout_bounds bounds; + assert (dla); + + Dynarr_reset (dla); + /* if there's nothing to do then do nothing. code after this assumes + there is something to do. */ + if (NILP (disp_string)) + return; + + bounds.left_out =3D xpos; + bounds.right_out =3D xpos + width; + /* The inner boundaries mark where the glyph margins are located. */ + bounds.left_in =3D bounds.left_out + window_left_margin_width (w); + bounds.right_in =3D bounds.right_out - window_right_margin_width (w); + /* We cannot fully calculate the whitespace boundaries as they + depend on the contents of the line being displayed. */ + bounds.left_white =3D bounds.left_in; + bounds.right_white =3D bounds.right_in; + + while (ypos < yend) + { + struct display_line dl; + struct display_line *dlp; + int local; + + if (Dynarr_length (dla) < Dynarr_largest (dla)) + { + dlp =3D Dynarr_atp (dla, Dynarr_length (dla)); + local =3D 0; + } + else + { + + xzero (dl); + dlp =3D &dl; + local =3D 1; + } + + dlp->bounds =3D bounds; + dlp->offset =3D 0; + start_pos =3D generate_string_display_line (w, disp_string, dlp,= start_pos, + &prop, default_face); + dlp->ypos =3D ypos + dlp->ascent; + ypos =3D dlp->ypos + dlp->descent; + + if (ypos > yend) + { + int visible_height =3D dlp->ascent + dlp->descent; + + dlp->clip =3D (ypos - yend); + visible_height -=3D dlp->clip; + + if (visible_height < VERTICAL_CLIP (w, 1)) + { + if (local) + free_display_line (dlp); + break; + } + } + else + dlp->clip =3D 0; + + Dynarr_add (dla, *dlp); + + /* #### This type of check needs to be done down in the + generate_display_line call. */ + if (start_pos >=3D XSTRING_CHAR_LENGTH (disp_string)) + break; + } + + if (prop) + Dynarr_free= (prop); +} + +=0C +/**************************************************************************= */ +/* */ +/* window-regeneration routines = */ +/* = */ +/**************************************************************************= */ + +/* For a given window and starting position in the buffer it contains, + ensure that the TYPE display lines accurately represent the + presentation of the window. We pass the buffer instead of getting + it from the window since redisplay_window may have temporarily + changed it to the echo area buffer. */ + +static void +regenerate_window (struct window *w, Bufpos start_pos, Bufpos point, int= type) +{ + struct frame *f =3D XFRAME (w->frame); + struct buffer *b =3D XBUFFER (w->buffer); + int ypos =3D WINDOW_TEXT_TOP (w); + int yend; /* set farther down */ + + prop_block_dynarr *prop; + layout_bounds bounds; + display_line_dynarr *dla; + int need_modeline; + + /* The lines had better exist by this point. */ + if (!(dla =3D window_display_lines (w, type))) + abort (); + Dynarr_reset (dla); + w->max_line_len =3D 0; + + /* Normally these get updated in redisplay_window but it is possible + for this function to get called from some other points where that + update may not have occurred. This acts as a safety check. */ + if (!Dynarr_length (w->face_cachels)) + reset_face_cachels (w); + if (!Dynarr_length (w->glyph_cachels)) + reset_glyph_cachels (w); + + Fset_marker (w->start[type], make_int (start_pos), w->buffer); + Fset_marker (w->pointm[type], make_int (point), w->buffer); + w->last_point_x[type] =3D -1; + w->last_point_y[type] =3D -1; + + /* Make sure a modeline is in the structs if needed. */ + need_modeline =3D ensure_modeline_generated (w, type); + + /* Wait until here to set this so that the structs have a modeline + generated in the case where one didn't exist. */ + yend =3D WINDOW_TEXT_BOTTOM (w); + + bounds =3D calculate_display_line_boundaries (w, 0); + + /* 97/3/14 jhod: stuff added here to support pre-prompts (used for input= systems) */ + if (MINI_WINDOW_P (w) + && (!NILP (Vminibuf_prompt) || !NILP (Vminibuf_preprompt)) + && !echo_area_active (f) + && start_pos =3D=3D BUF_BEGV (b)) + { + struct prop_block pb; + Lisp_Object string; + prop =3D Dynarr_new (prop_block); + + string =3D concat2(Vminibuf_preprompt, Vminibuf_prompt); + pb.type =3D PROP_MINIBUF_PROMPT; + pb.data.p_string.str =3D XSTRING_DATA(string); + pb.data.p_string.len =3D XSTRING_LENGTH(string); + Dynarr_add (prop, pb); + } + else + prop =3D 0; + + while (ypos < yend) + { + struct display_line dl; + struct display_line *dlp; + int local; + + if (Dynarr_length (dla) < Dynarr_largest (dla)) + { + dlp =3D Dynarr_atp (dla, Dynarr_length (dla)); + local =3D 0; + } + else + { + xzero (dl); dlp =3D &dl; local =3D 1; @@ -5391,6 +6227,7 @@ being handled. */ update_frame_menubars (f); #endif /* HAVE_MENUBARS */ + update_frame_gutters (f); /* widgets are similar to menus in that they can call lisp to determine activation etc. Therefore update them before we get into redisplay. This is primarily for connected widgets such as @@ -5474,6 +6311,7 @@ f->modeline_changed =3D 0; f->point_changed =3D 0; f->toolbar_changed =3D 0; + f->gutter_changed =3D 0; f->windows_changed =3D 0; f->windows_structure_changed =3D 0; f->window_face_cache_reset =3D 0; @@ -5532,7 +6370,8 @@ f->faces_changed || f->frame_changed || f->menubar_changed || f->modeline_changed || f->point_changed || f->size_changed || f->toolbar_changed || f->windows_changed || f->size_slipped || - f->windows_structure_changed || f->glyphs_changed ||= f->subwindows_changed) + f->windows_structure_changed || f->glyphs_changed || + f->subwindows_changed || f->gutter_changed) { preempted =3D redisplay_frame (f, 0); } @@ -5566,7 +6405,7 @@ f->faces_changed || f->frame_changed || f->menubar_changed || f->modeline_changed || f->point_changed || f->size_changed || f->toolbar_changed || f->windows_changed || - f->windows_structure_changed || + f->windows_structure_changed || f->gutter_changed || f->glyphs_changed || f->subwindows_changed) { preempted =3D redisplay_frame (f, 0); @@ -5594,6 +6433,7 @@ d->modeline_changed =3D 0; d->point_changed =3D 0; d->toolbar_changed =3D 0; + d->gutter_changed =3D 0; d->windows_changed =3D 0; d->windows_structure_changed =3D 0; @@ -5635,8 +6475,8 @@ !menubar_changed && !modeline_changed && !point_changed && !size_changed && !toolbar_changed && !windows_changed && !glyphs_changed && !subwindows_changed && - !windows_structure_changed && !disable_preemption && - preemption_count < max_preempts) + !gutter_changed && !windows_structure_changed && + !disable_preemption && preemption_count < max_preempts) goto done; DEVICE_LOOP_NO_BREAK (devcons, concons) @@ -5648,7 +6488,7 @@ d->faces_changed || d->frame_changed || d->icon_changed || d->menubar_changed || d->modeline_changed || d->point_changed || d->size_changed || d->toolbar_changed || d->windows_changed || - d->windows_structure_changed || + d->windows_structure_changed || d->gutter_changed || d->glyphs_changed || d->subwindows_changed) { preempted =3D redisplay_device (d); @@ -5679,6 +6519,7 @@ modeline_changed =3D 0; point_changed =3D 0; toolbar_changed =3D 0; + gutter_changed =3D 0; windows_changed =3D 0; windows_structure_changed =3D 0; RESET_CHANGED_SET_FLAGS; Index:= src/redisplay.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.h,v retrieving revision 1.7.2.3 diff -u -r1.7.2.3 redisplay.h --- src/redisplay.h 1999/01/12 01:38:18 1.7.2.3 +++ src/redisplay.h 1999/07/11 18:40:16 @@ -233,6 +233,32 @@ Dynarr_declare (glyph_block); } glyph_block_dynarr; = +/*************************************************************************/ +/* display lines = */ +/*************************************************************************/ + +/* Modeline commentary: IMO the modeline is handled very badly, we + special case virtually *everything* in the redisplay routines for + the modeline. The fact that dl->bufpos can be either a buffer + position or a char count highlights this. There is no abstraction at + all that I can find and it means that the code is made very ugly as + a result. Either we should treat the modeline *entirely* separately, + or we should abstract to something that applies equally well to the + modeline and to buffer text, the things are not enormously different + after all and handling them identically at some level would + eliminate some bugs that still exist (mainly to do with modeline + handling). This problem doesn't help trying to implement gutters + which are somewhere in between buffer text and modeline text. + + Redisplay commentary: Everything in redisplay is tied very tightly + to the things that are being displayed, and the context, + e.g. buffers and windows. According to Chuck this is so that we can + get speed, which seems fine to me, however this usage is extended + too far down the redispay routines IMO. At some level there should + be functions that know how to display strings with extents and + faces, regardless of buffer etc. After all the window system does + not care. */ + typedef struct display_line display_line; struct display_line { @@ -268,6 +294,10 @@ /* Dynamic arrays of left and right glyph blocks */ glyph_block_dynarr *left_glyphs; glyph_block_dynarr *right_glyphs; + + face_index left_margin_findex; + face_index right_margin_findex; + face_index default_findex; }; #define DISPLAY_LINE_HEIGHT(dl) \ @@ -387,6 +417,10 @@ extern int toolbar_changed; extern int toolbar_changed_set; +/* non-nil if any gutter has changed */ +extern int gutter_changed; +extern int gutter_changed_set; + /* non-nil if any window has changed since the last time redisplay= completed */ extern int windows_changed; @@ -426,6 +460,7 @@ #define MARK_MODELINE_CHANGED MARK_TYPE_CHANGED (modeline) #define MARK_POINT_CHANGED MARK_TYPE_CHANGED (point) #define MARK_TOOLBAR_CHANGED MARK_TYPE_CHANGED (toolbar) +#define MARK_GUTTER_CHANGED MARK_TYPE_CHANGED (gutter) #define MARK_GLYPHS_CHANGED MARK_TYPE_CHANGED (glyphs) #define MARK_SUBWINDOWS_CHANGED MARK_TYPE_CHANGED (subwindows) @@ -441,6 +476,7 @@ modeline_changed_set =3D 0; \ point_changed_set =3D 0; \ toolbar_changed_set =3D 0; \ + gutter_changed_set =3D 0; \ glyphs_changed_set =3D 0; \ subwindows_changed_set =3D 0; \ } while (0) @@ -522,6 +558,10 @@ Bufbyte *generate_formatted_string (struct window *w, Lisp_Object= format_str, Lisp_Object result_str, face_index= findex, int type); +void generate_displayable_area (struct window *w, Lisp_Object= disp_string, + int xpos, int ypos, int width, int height, + display_line_dynarr* dl, + Bufpos start_pos, face_index default_face); int real_current_modeline_height (struct window *w); int pixel_to_glyph_translation (struct frame *f, int x_coord, int y_coord, int *col, int *row, Index:= src/scrollbar.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/scrollbar.c,v retrieving revision 1.17.2.1 diff -u -r1.17.2.1 scrollbar.c --- src/scrollbar.c 1998/12/05 16:56:26 1.17.2.1 +++ src/scrollbar.c 1999/07/11 18:40:19 @@ -468,7 +468,7 @@ y_offset =3D f->scrollbar_y_offset + (!NILP (w->scrollbar_on_top_p) ? WINDOW_TOP (w) - : WINDOW_TEXT_BOTTOM (w) + window_bottom_toolbar_height (w)); + : WINDOW_TEXT_BOTTOM (w) /* + window_bottom_toolbar_height (w)*/); } new_x =3D x_offset; Index:= src/search.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/search.c,v retrieving revision 1.14.2.2 diff -u -r1.14.2.2 search.c --- src/search.c 1999/01/18 22:00:18 1.14.2.2 +++ src/search.c 1999/07/11 18:40:26 @@ -700,6 +700,50 @@ return scan_buffer (buf, '\n', from, 0, count, 0, 1); } +Bytind +bi_find_next_emchar_in_string (struct Lisp_String* str, Emchar target,= Bytind st, + EMACS_INT count) +{ + /* This function has been Mule-ized. */ + Bytind lim =3D string_length (str) -1; + Bufbyte* s =3D string_data (str); + + assert (count >=3D 0); + +#ifdef MULE + /* Due to the Mule representation of characters in a buffer, + we can simply search for characters in the range 0 - 127 + directly. For other characters, we do it the "hard" way. + Note that this way works for all characters but the other + way is faster. */ + if (target >=3D 0200) + { + while (st < lim && count > 0) + { + if (string_char (str, st) =3D=3D target) + count--; + INC_CHARBYTIND (s, st); + } + } + else +#endif + { + while (st < lim && count > 0) + { + Bufbyte *bufptr =3D (Bufbyte *) memchr (charptr_n_addr (s,= st), + (int) target, lim - st); + if (bufptr) + { + count--; + st =3D (Bytind)(bufptr - s) + 1; + } + else + st =3D lim; + } + } + return st; +} + /* Like find_next_newline, but returns position before the newline, not after, and only search up to TO. This isn't just find_next_newline (...)-1, because you might hit TO. */ Index:= src/symsinit.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/symsinit.h,v retrieving revision 1.31.2.7 diff -u -r1.31.2.7 symsinit.h --- src/symsinit.h 1999/07/05 07:28:25 1.31.2.7 +++ src/symsinit.h 1999/07/11 18:40:26 @@ -97,6 +97,7 @@ void syms_of_glyphs (void); void syms_of_gui_x (void); void syms_of_gui (void); +void syms_of_gutter (void); void syms_of_indent (void); void syms_of_intl (void); void syms_of_keymap (void); @@ -182,6 +183,7 @@ void specifier_type_create (void); void specifier_type_create_image (void); +void specifier_type_create_gutter (void); void specifier_type_create_objects (void); void specifier_type_create_toolbar (void); @@ -273,6 +275,7 @@ void vars_of_glyphs (void); void vars_of_gui_x (void); void vars_of_gui (void); +void vars_of_gutter (void); void vars_of_input_method_motif (void); void vars_of_input_method_xlib (void); void vars_of_indent (void); @@ -327,6 +330,7 @@ /* Initialize specifier variables (dump-time only). */ void specifier_vars_of_glyphs (void); +void specifier_vars_of_gutter (void); void specifier_vars_of_menubar (void); void specifier_vars_of_redisplay (void); void specifier_vars_of_scrollbar (void); Index:= src/window.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.c,v retrieving revision 1.41.2.9 diff -u -r1.41.2.9 window.c --- src/window.c 1999/06/22 18:03:01 1.41.2.9 +++ src/window.c 1999/07/11 18:40:41 @@ -38,6 +38,7 @@ #include "window.h" #include "elhash.h" #include "commands.h" +#include "gutter.h" Lisp_Object Qwindowp, Qwindow_live_p, Qwindow_configurationp; Lisp_Object Qscroll_up, Qscroll_down, Qdisplay_buffer; @@ -641,7 +642,7 @@ return window_is_leftmost (w) && window_is_rightmost (w); } -static int +int window_is_highest (struct window *w) { Lisp_Object parent, current_ancestor, window; @@ -669,7 +670,7 @@ return 0; } -static int +int window_is_lowest (struct window *w) { Lisp_Object parent, current_ancestor, window; @@ -972,32 +973,6 @@ return margin_width_internal (w, 0); } -static int -window_top_toolbar_height (struct window *w) -{ - /* #### implement this shit. */ - return 0; -} - -/* #### Currently used in scrollbar.c. Does it actually need to be?= */ -int -window_bottom_toolbar_height (struct window *w) -{ - return 0; -} - -static int -window_left_toolbar_width (struct window *w) -{ - return 0; -} - -static int -window_right_toolbar_width (struct window *w) -{ - return 0; -} - = /**************************************************************************= *** Window Gutters @@ -1019,47 +994,45 @@ int window_top_gutter_height (struct window *w) { - int toolbar_height =3D window_top_toolbar_height (w); + int gutter =3D WINDOW_REAL_TOP_GUTTER_BOUNDS (w); if (!NILP (w->hchild) || !NILP (w->vchild)) return 0; #ifdef HAVE_SCROLLBARS if (!NILP (w->scrollbar_on_top_p)) - return window_scrollbar_height (w) + toolbar_height; + return window_scrollbar_height (w) + gutter; else #endif - return toolbar_height; + return gutter; } int window_bottom_gutter_height (struct window *w) { - int other_height; + int gutter =3D WINDOW_REAL_BOTTOM_GUTTER_BOUNDS (w); if (!NILP (w->hchild) || !NILP (w->vchild)) return 0; - else - other_height =3D - window_modeline_height (w) + window_bottom_toolbar_height (w); + + gutter +=3D window_modeline_height (w); #ifdef HAVE_SCROLLBARS if (NILP (w->scrollbar_on_top_p)) - return window_scrollbar_height (w) + other_height; + return window_scrollbar_height (w) + gutter; else #endif - return other_height; + return gutter; } int window_left_gutter_width (struct window *w, int modeline) { - int gutter =3D window_left_toolbar_width (w); + int gutter =3D WINDOW_REAL_LEFT_GUTTER_BOUNDS (w); if (!NILP (w->hchild) || !NILP (w->vchild)) return 0; - #ifdef HAVE_SCROLLBARS if (!modeline && !NILP (w->scrollbar_on_left_p)) gutter +=3D window_scrollbar_width (w); @@ -1071,7 +1044,7 @@ int window_right_gutter_width (struct window *w, int modeline) { - int gutter =3D window_right_toolbar_width (w); + int gutter =3D WINDOW_REAL_RIGHT_GUTTER_BOUNDS (w); if (!NILP (w->hchild) || !NILP (w->vchild)) return 0; Index:= src/window.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.h,v retrieving revision 1.13.2.2 diff -u -r1.13.2.2 window.h --- src/window.h 1998/12/18 05:42:16 1.13.2.2 +++ src/window.h 1999/07/11 18:40:44 @@ -329,6 +329,8 @@ int window_displayed_height (struct window *); int window_is_leftmost (struct window *w); int window_is_rightmost (struct window *w); +int window_is_lowest (struct window *w); +int window_is_highest (struct window *w); int window_truncation_on (struct window *w); int window_needs_vertical_divider (struct window *); int window_scrollbar_width (struct window *w); @@ -340,7 +342,6 @@ int window_bottom_gutter_height (struct window *w); int window_left_gutter_width (struct window *w, int modeline); int window_right_gutter_width (struct window *w, int modeline); -int window_bottom_toolbar_height (struct window *w); void delete_all_subwindows (struct window *w); void set_window_pixheight (Lisp_Object window, int pixheight, Index:= src/winslots.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/winslots.h,v retrieving revision 1.4 diff -u -r1.4 winslots.h --- src/winslots.h 1998/06/30 06:36:06 1.4 +++ src/winslots.h 1999/07/11 18:40:44 @@ -97,6 +97,25 @@ WINDOW_SLOT (default_toolbar_visible_p, EQ); WINDOW_SLOT (default_toolbar_border_width, EQ); #endif /* HAVE_TOOLBARS */ + + /* Gutter specification for each of the four positions. + This is not a size hog because the value here is not copied, + and will be shared with the specs in the specifier. */ + WINDOW_SLOT_ARRAY (gutter, 4, EQUAL_WRAPPED); + /* Gutter size for each of the four positions. */ + WINDOW_SLOT_ARRAY (gutter_size, 4, EQUAL_WRAPPED); + /* Gutter border width for each of the four positions. */ + WINDOW_SLOT_ARRAY (gutter_border_width, 4, EQUAL_WRAPPED); + /* Gutter visibility status for each of the four positions. */ + WINDOW_SLOT_ARRAY (gutter_visible_p, 4, EQUAL_WRAPPED); + /* The following five don't really need to be cached except + that we need to know when they've changed. */ + WINDOW_SLOT (default_gutter, EQUAL_WRAPPED); + WINDOW_SLOT (default_gutter_width, EQ); + WINDOW_SLOT (default_gutter_height, EQ); + WINDOW_SLOT (default_gutter_visible_p, EQ); + WINDOW_SLOT (default_gutter_border_width, EQ); +/* margins */ WINDOW_SLOT (left_margin_width, EQ); WINDOW_SLOT (right_margin_width, EQ); WINDOW_SLOT (minimum_line_ascent, EQ); Index:= tests/glyph-test.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/tests/Attic/glyph-test.el,v retrieving revision 1.1.2.8 diff -u -r1.1.2.8 glyph-test.el --- tests/glyph-test.el 1999/06/29 14:35:35 1.1.2.8 +++ tests/glyph-test.el 1999/07/11 18:40:44 @@ -1,6 +1,7 @@ +(setq str "Hello There") (set-extent-begin-glyph - (make-extent (point) (point)) - (setq icon (make-glyph [xpm :file "../etc/xemacs-icon.xpm"]))) + (make-extent 0 0 str) + (make-glyph [xpm :file "../etc/xemacs-icon.xpm"])) (defun foo () (interactive) Index:= src/gutter.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: gutter.h diff -N gutter.h --- /dev/null Sun Jul 11 03:13:12 1999 +++ src/gutter.h Sun Jul 11 11:43:43 1999 @@ -0,0 +1,121 @@ +/* Define general gutter support. + Copyright (C) 1999 Andy Piper. + +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. */ + +#ifndef _XEMACS_GUTTER_H_ +#define _XEMACS_GUTTER_H_ + +#include "specifier.h" + +#define DEVICE_SUPPORTS_GUTTERS_P(d) \ + (HAS_DEVMETH_P ((d), output_frame_gutters)) + +DECLARE_SPECIFIER_TYPE (gutter); +#define XGUTTER_SPECIFIER(x) XSPECIFIER_TYPE (x, gutter) +#define XSETGUTTER_SPECIFIER(x, p) XSETSPECIFIER_TYPE (x, p,= gutter) +#define GUTTER_SPECIFIERP(x) SPECIFIER_TYPEP (x, gutter) +#define CHECK_GUTTER_SPECIFIER(x) CHECK_SPECIFIER_TYPE (x, gutter) +#define CONCHECK_GUTTER_SPECIFIER(x) CONCHECK_SPECIFIER_TYPE (x,= gutter) + +#define DEFAULT_GUTTER_HEIGHT 0 +#define DEFAULT_GUTTER_WIDTH 0 +#define DEFAULT_GUTTER_BORDER_WIDTH 0 + +enum gutter_pos +{ + TOP_GUTTER, + BOTTOM_GUTTER, + LEFT_GUTTER, + RIGHT_GUTTER +}; + +extern Lisp_Object Qgutter; + +extern Lisp_Object Vgutter_size[4]; +extern Lisp_Object Vgutter_border_width[4]; +void update_frame_gutters (struct frame *f); +void init_frame_gutters (struct frame *f); +void init_device_gutters (struct device *d); +void init_global_gutters (struct device *d); +void free_frame_gutters (struct frame *f); +void redraw_exposed_gutters (struct frame *f, int x, int y, int width, + int height); + +#define WINDOW_GUTTER_BORDER_WIDTH(w, pos) \ +(NILP ((w)->gutter_border_width[pos]) ? 0 : XINT ((w)->gutter_border_width[= pos])) +#define WINDOW_GUTTER_SIZE(w, pos) \ +(NILP ((w)->gutter_size[pos]) ? 0 : XINT ((w)->gutter_size[pos])) +#define WINDOW_GUTTER_VISIBLE(w, pos)= \ +((w)->gutter_visible_p[pos]) +#define WINDOW_GUTTER(w, pos) \ +((w)->gutter[pos]) + +#define WINDOW_REAL_GUTTER_SIZE(w, pos) \ + (!NILP (WINDOW_GUTTER_VISIBLE (w, pos)) \ + ? WINDOW_GUTTER_SIZE (w, pos) \ + : 0) +#define WINDOW_REAL_GUTTER_VISIBLE(f, pos) \ + (WINDOW_REAL_GUTTER_SIZE (f, pos) > 0) +#define WINDOW_REAL_GUTTER_BORDER_WIDTH(f, pos) \ + (!NILP (WINDOW_GUTTER_VISIBLE (f, pos)) \ + ? WINDOW_GUTTER_BORDER_WIDTH (f, pos) \ + : 0) +#define WINDOW_REAL_GUTTER_BOUNDS(f, pos) \ + (WINDOW_REAL_GUTTER_SIZE (f,pos) + \ + 2 * WINDOW_REAL_GUTTER_BORDER_WIDTH (f,pos)) + +/* these macros predicate size on position and type of window */ +#define WINDOW_REAL_TOP_GUTTER_BOUNDS(w) \ + ((!MINI_WINDOW_P (w) && window_is_highest (w)) ? \ + WINDOW_REAL_GUTTER_BOUNDS (w,TOP_GUTTER) : 0) +#define WINDOW_REAL_BOTTOM_GUTTER_BOUNDS(w) \ + ((!MINI_WINDOW_P (w) && window_is_lowest (w)) ? \ + WINDOW_REAL_GUTTER_BOUNDS (w,BOTTOM_GUTTER) : 0) +#define WINDOW_REAL_LEFT_GUTTER_BOUNDS(w) \ + ((!MINI_WINDOW_P (w) && window_is_leftmost (w)) ? \ + WINDOW_REAL_GUTTER_BOUNDS (w,LEFT_GUTTER) : 0) +#define WINDOW_REAL_RIGHT_GUTTER_BOUNDS(w) \ + ((!MINI_WINDOW_P (w) && window_is_rightmost (w)) ? \ + WINDOW_REAL_GUTTER_BOUNDS (w,RIGHT_GUTTER) : 0) + +#define FRAME_GUTTER_VISIBLE(f, pos) \ + WINDOW_REAL_GUTTER_VISIBLE (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)),= pos) +#define FRAME_GUTTER_SIZE(f, pos) \ + WINDOW_REAL_GUTTER_SIZE (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)),= pos) +#define FRAME_GUTTER_BOUNDS(f, pos) \ + WINDOW_REAL_GUTTER_BOUNDS (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)),= pos) +#define FRAME_GUTTER_BORDER_WIDTH(f, pos) \ + WINDOW_REAL_GUTTER_BORDER_WIDTH (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW= (f)), pos) + +#define FRAME_GUTTER(f, pos) \ +WINDOW_GUTTER (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)), pos) + +/* these macros predicate size on position and type of window */ +#define FRAME_TOP_GUTTER_BOUNDS(f) \ + WINDOW_REAL_TOP_GUTTER_BOUNDS (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW= (f))) +#define FRAME_BOTTOM_GUTTER_BOUNDS(f) \ + WINDOW_REAL_BOTTOM_GUTTER_BOUNDS (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW= (f))) +#define FRAME_LEFT_GUTTER_BOUNDS(f) \ + WINDOW_REAL_LEFT_GUTTER_BOUNDS (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW= (f))) +#define FRAME_RIGHT_GUTTER_BOUNDS(f) \ + WINDOW_REAL_RIGHT_GUTTER_BOUNDS (XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW= (f))) + +#endif /* _XEMACS_GUTTER_H_ */ Index:= src/gutter.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: gutter.c diff -N gutter.c --- /dev/null Sun Jul 11 03:13:12 1999 +++ src/gutter.c Sun Jul 11 11:43:43 1999 @@ -0,0 +1,882 @@ +/* Gutter implementation. + Copyright (C) 1999 Andy Piper. + +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. */ + +/* Specifers ripped-off from toolbar.c */ + +#include +#include "lisp.h" + +#include "buffer.h" +#include "frame.h" +#include "device.h" +#include "faces.h" +#include "glyphs.h" +#include "redisplay.h" +#include "window.h" +#include "gutter.h" + +Lisp_Object Vgutter[4]; +Lisp_Object Vgutter_size[4]; +Lisp_Object Vgutter_visible_p[4]; +Lisp_Object Vgutter_border_width[4]; + +Lisp_Object Vdefault_gutter, Vdefault_gutter_visible_p; +Lisp_Object Vdefault_gutter_width, Vdefault_gutter_height; +Lisp_Object Vdefault_gutter_border_width; + +Lisp_Object Vdefault_gutter_position; + +#define SET_GUTTER_WAS_VISIBLE_FLAG(frame, pos, flag) \ + do { \ + switch (pos) \ + { \ + case TOP_GUTTER: \ + (frame)->top_gutter_was_visible =3D flag; \ + break; \ + case BOTTOM_GUTTER: \ + (frame)->bottom_gutter_was_visible =3D flag; \ + break; \ + case LEFT_GUTTER: \ + (frame)->left_gutter_was_visible =3D flag; \ + break; \ + case RIGHT_GUTTER: \ + (frame)->right_gutter_was_visible =3D flag; \ + break; \ + default: \ + abort (); \ + } \ + } while (0) + +static int gutter_was_visible (struct frame* frame, enum gutter_pos= pos) +{ + switch (pos) + { + case TOP_GUTTER: + return (frame)->top_gutter_was_visible; + case BOTTOM_GUTTER: + return (frame)->bottom_gutter_was_visible; + case LEFT_GUTTER: + return (frame)->left_gutter_was_visible; + case RIGHT_GUTTER: + return (frame)->right_gutter_was_visible; + default: + abort (); + } +} + +void +get_gutter_coords (struct frame *f, enum gutter_pos pos, int *x, int= *y, + int *width, int *height) +{ + struct window* w =3D XWINDOW (FRAME_ROOT_WINDOW (f)); + /* The top and bottom gutters take precedence over the left and + right. */ + + /* We adjust the width and height by one to give us a narrow border + at the outside edges. However, when we are simply determining + gutter location we don't want to do that. */ + + switch (pos) + { + case TOP_GUTTER: + *x =3D FRAME_LEFT_BORDER_END (f); + *y =3D FRAME_TOP_BORDER_END (f); + *width =3D FRAME_RIGHT_BORDER_START (f) + - FRAME_LEFT_BORDER_END (f); + *height =3D FRAME_TOP_GUTTER_BOUNDS (f); + break; + case BOTTOM_GUTTER: + *x =3D FRAME_LEFT_BORDER_END (f); + *y =3D FRAME_TOP_BORDER_END (f) + + w->pixel_height + - (window_modeline_height (w) + FRAME_BOTTOM_GUTTER_BOUNDS (f)); + *width =3D FRAME_RIGHT_BORDER_START (f) + - FRAME_LEFT_BORDER_END (f); + *height =3D FRAME_BOTTOM_GUTTER_BOUNDS (f); + break; + case LEFT_GUTTER: + *x =3D FRAME_LEFT_BORDER_END (f); + *y =3D FRAME_TOP_BORDER_END (f) + FRAME_TOP_GUTTER_BOUNDS (f); + *width =3D FRAME_LEFT_GUTTER_BOUNDS (f); + *height =3D FRAME_BOTTOM_BORDER_START (f) - + (FRAME_TOP_BORDER_END (f) + FRAME_TOP_GUTTER_BOUNDS (f) + + FRAME_BOTTOM_GUTTER_BOUNDS (f)); + break; + case RIGHT_GUTTER: + *x =3D WINDOW_TEXT_RIGHT (w); + *y =3D WINDOW_TEXT_TOP (w); + *width =3D FRAME_RIGHT_GUTTER_BOUNDS (f); + *height =3D FRAME_BOTTOM_BORDER_START (f) - + (FRAME_TOP_BORDER_END (f) + FRAME_TOP_GUTTER_BOUNDS (f) + + FRAME_BOTTOM_GUTTER_BOUNDS (f)); + break; + default: + abort (); + } +} + +static void +output_gutter (struct frame *f, enum gutter_pos pos) +{ + Lisp_Object frame; + Lisp_Object window =3D FRAME_LAST_NONMINIBUF_WINDOW (f); + struct device *d =3D XDEVICE (f->device); + struct window* w =3D XWINDOW (window); + int x, y, width, height; + int line; + int border_width =3D FRAME_GUTTER_BORDER_WIDTH (f, pos); + face_index findex =3D get_builtin_face_cache_index (w,= Vgui_element_face); + display_line_dynarr* ddla, *cdla; + + if (!f->current_display_lines) + f->current_display_lines =3D Dynarr_new (display_line); + if (!f->desired_display_lines) + f->desired_display_lines =3D Dynarr_new (display_line); + + ddla =3D f->desired_display_lines; + cdla =3D f->current_display_lines; + + XSETFRAME (frame, f); + + get_gutter_coords (f, pos, &x, &y, &width, &height); + /* clear out what we want to cover + redisplay_clear_region (window, findex, x, y, width, height); */ + /* generate some display lines */ + generate_displayable_area (w, Fspecifier_instance(Vgutter[pos],= window, + Qnil, Qnil), + x + border_width, y + border_width, + width - 2 * border_width, + height - 2 * border_width, ddla, 0, findex); + /* Output each line. */ + for (line =3D 0; line < Dynarr_length (ddla); line++) + { + output_display_line (w, 0, ddla, line, -1, -1); + } + + /* bevel the gutter area if so desired */ + if (border_width !=3D 0) + { + MAYBE_DEVMETH (d, bevel_area, + (w, findex, x, y, width, height, border_width)); + } +} + +static void +clear_gutter (struct frame *f, enum gutter_pos pos) +{ + Lisp_Object frame; + int x, y, width, height; + struct window* w =3D XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)); + face_index findex =3D get_builtin_face_cache_index (w,= Vgui_element_face); + get_gutter_coords (f, pos, &x, &y, &width, &height); + XSETFRAME (frame, f); + + SET_GUTTER_WAS_VISIBLE_FLAG (f, pos, 0); + + redisplay_clear_region (frame, findex, x, y, width,= height); +} + +void +update_frame_gutters (struct frame *f) +{ + if (f->gutter_changed || f->frame_changed || f->clear) + { + int pos; + for (pos =3D 0; pos < 4; pos++) + f->current_gutter_size[pos] =3D FRAME_GUTTER_SIZE (f, pos); + /* and output */ + + for (pos =3D 0; pos < 4; pos++) + { + if (FRAME_GUTTER_VISIBLE (f, pos)) + output_gutter (f, pos); + else if (gutter_was_visible (f, pos)) + clear_gutter (f, pos); + } + + } + f->gutter_changed =3D 0; +} + +static void +redraw_exposed_gutter (struct frame *f, enum toolbar_pos pos, int x, int= y, + int width, int height) +{ + int g_x, g_y, g_width, g_height; + + get_gutter_coords (f, pos, &g_x, &g_y, &g_width, &g_height); + + if (((y + height) < g_y) || (y > (g_y + g_height))) + return; + if (((x + width) < g_x) || (x > (g_x + g_width))) + return; + /* #### optimize this - redrawing hte whole gutter for every expose + is very expensive */ + + /* Even if none of the gutter is in the area, the blank region at + the very least must be because the first thing we did is verify + that some portion of the gutter is in the exposed region. */ + output_gutter (f, pos); +} + +void +redraw_exposed_gutters (struct frame *f, int x, int y, int width, + int height) +{ + int pos; + for (pos =3D 0; pos < 4; pos++) + { + if (FRAME_GUTTER_VISIBLE (f, pos)) + redraw_exposed_gutter (f, pos, x, y, width,= height); + } +} + +void +free_frame_gutters (struct frame *f) +{ + if (f->current_display_lines) + Dynarr_free (f->current_display_lines); + if (f->desired_display_lines) + Dynarr_free (f->desired_display_lines); +} + +void +init_frame_gutters (struct frame *f) +{ + int pos; + /* We are here as far in frame creation so cached specifiers are + already recomputed, and possibly modified by resource + initialization. Remember current gutter geometry so next + redisplay will not needlessly relayout gutters. */ + for (pos =3D 0; pos < 4; pos++) + f->current_gutter_size[pos] =3D FRAME_GUTTER_SIZE (f,= pos); +} + +static enum gutter_pos +decode_gutter_position (Lisp_Object position) +{ + if (EQ (position, Qtop)) return TOP_GUTTER; + if (EQ (position, Qbottom)) return BOTTOM_GUTTER; + if (EQ (position, Qleft)) return LEFT_GUTTER; + if (EQ (position, Qright)) return RIGHT_GUTTER; + signal_simple_error ("Invalid gutter position", position); + + return TOP_GUTTER; /* not reached */ +} + +DEFUN ("set-default-gutter-position", Fset_default_gutter_position, 1, 1,= 0, /* +Set the position that the `default-gutter' will be displayed at. +Valid positions are 'top, 'bottom, 'left and 'right. +See `default-gutter-position'. +*/ + (position)) +{ + enum gutter_pos cur =3D decode_gutter_position= (Vdefault_gutter_position); + enum gutter_pos new =3D decode_gutter_position (position); + + if (cur !=3D new) + { + /* The following calls will automatically cause the dirty + flags to be set; we delay frame size changes to avoid + lots of frame flickering. */ + /* #### I think this should be GC protected. -sb */ + hold_frame_size_changes (); + set_specifier_fallback (Vgutter[cur], list1 (Fcons (Qnil, Qnil))); + set_specifier_fallback (Vgutter[new], Vdefault_gutter); + set_specifier_fallback (Vgutter_size[cur], list1 (Fcons (Qnil,= Qzero))); + set_specifier_fallback (Vgutter_size[new], + new =3D=3D TOP_GUTTER || new =3D=3D BOTTOM_GUTTER + ? Vdefault_gutter_height + : Vdefault_gutter_width); + set_specifier_fallback (Vgutter_border_width[cur], + list1 (Fcons (Qnil, Qzero))); + set_specifier_fallback (Vgutter_border_width[new], + Vdefault_gutter_border_width); + set_specifier_fallback (Vgutter_visible_p[cur], + list1 (Fcons (Qnil, Qt))); + set_specifier_fallback (Vgutter_visible_p[new], + Vdefault_gutter_visible_p); + Vdefault_gutter_position =3D position; + unhold_frame_size_changes (); + } + + return position; +} + +DEFUN ("default-gutter-position", Fdefault_gutter_position, 0, 0, 0,= /* +Return the position that the `default-gutter' will be displayed at. +The `default-gutter' will only be displayed here if the= corresponding +position-specific gutter specifier does not provide a value. +*/ + ()) +{ + return Vdefault_gutter_position; +} + +DEFINE_SPECIFIER_TYPE (gutter); + +static void +gutter_after_change (Lisp_Object specifier, Lisp_Object locale) +{ + MARK_GUTTER_CHANGED; +} + +DEFUN ("gutter-specifier-p", Fgutter_specifier_p, 1, 1, 0, /* +Return non-nil if OBJECT is a gutter specifier. +Gutter specifiers are used to specify the format of a gutter. +The values of the variables `default-gutter', `top-gutter', +`left-gutter', `right-gutter', and `bottom-gutter' are always +gutter specifiers. + +Valid gutter instantiators are called "gutter descriptors" +and are lists of vectors. See `default-gutter' for a description +of the exact format. +*/ + (object)) +{ + return GUTTER_SPECIFIERP (object) ? Qt : Qnil; +} + +=0C +/* + Helper for invalidating the real specifier when default + specifier caching changes +*/ +static void +recompute_overlaying_specifier (Lisp_Object real_one[4]) +{ + enum gutter_pos pos =3D decode_gutter_position= (Vdefault_gutter_position); + Fset_specifier_dirty_flag (real_one[pos]); +} + +static void +gutter_specs_changed (Lisp_Object specifier, struct window *w, + Lisp_Object oldval) +{ + MARK_GUTTER_CHANGED; +} + +static void +default_gutter_specs_changed (Lisp_Object specifier, struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vgutter); +} + +static void +gutter_geometry_changed_in_window (Lisp_Object specifier, struct window= *w, + Lisp_Object oldval) +{ + MARK_GUTTER_CHANGED; + MARK_WINDOWS_CHANGED (w); +} + +static void +default_gutter_size_changed_in_window (Lisp_Object specifier, struct window= *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vgutter_size); +} + +static void +default_gutter_border_width_changed_in_window (Lisp_Object= specifier, + struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier (Vgutter_border_width); +} + +static void +default_gutter_visible_p_changed_in_window (Lisp_Object specifier, + struct window *w, + Lisp_Object oldval) +{ + recompute_overlaying_specifier= (Vgutter_visible_p); +} + +void +syms_of_gutter (void) +{ + DEFSUBR (Fgutter_specifier_p); + DEFSUBR (Fset_default_gutter_position); + DEFSUBR (Fdefault_gutter_position); +} + +void +vars_of_gutter (void) +{ + staticpro (&Vdefault_gutter_position); + Vdefault_gutter_position =3D Qtop; + + Fprovide (Qgutter); +} + +void +specifier_type_create_gutter (void) +{ + INITIALIZE_SPECIFIER_TYPE (gutter, "gutter", "gutter-specifier-p"); + + SPECIFIER_HAS_METHOD (gutter,= after_change); +} + +void +specifier_vars_of_gutter (void) +{ + Lisp_Object fb; + + DEFVAR_SPECIFIER ("default-gutter", &Vdefault_gutter /* +Specifier for a fallback gutter. +Use `set-specifier' to change this. + +The position of this gutter is specified in the= function +`default-gutter-position'. If the corresponding position-specific +gutter (e.g. `top-gutter' if `default-gutter-position' is 'top) +does not specify a gutter in a particular domain (usually a window), +then the value of `default-gutter' in that domain, if any, will be +used instead. + +Note that the gutter at any particular position will not be +displayed unless its visibility flag is true and its thickness +\(width or height, depending on orientation) is non-zero. The +visibility is controlled by the specifiers= `top-gutter-visible-p', +`bottom-gutter-visible-p', `left-gutter-visible-p',= and +`right-gutter-visible-p', and the thickness is controlled by= the +specifiers `top-gutter-height',= `bottom-gutter-height', +`left-gutter-width', and `right-gutter-width'. + +Note that one of the four visibility specifiers inherits= from +`default-gutter-visibility' and one of the four thickness +specifiers inherits from either `default-gutter-width'= or +`default-gutter-height' (depending on orientation), just +like for the gutter description specifiers (e.g. `top-gutter') +mentioned above. + +Therefore, if you are setting `default-gutter', you should control +the visibility and thickness using= `default-gutter-visible-p', +`default-gutter-width', and `default-gutter-height', rather than +using position-specific specifiers. That way, you will get sane +behavior if the user changes the default gutter position. + +*/ ); + + Vdefault_gutter =3D Fmake_specifier (Qgutter); + /* #### It would be even nicer if the specifier caching + automatically knew about specifier fallbacks, so we didn't + have to do it ourselves. */ + set_specifier_caching (Vdefault_gutter, + slot_offset (struct window, + default_gutter), + default_gutter_specs_changed, + 0, 0); + + DEFVAR_SPECIFIER ("top-gutter", + &Vgutter[TOP_GUTTER] /* +Specifier for the gutter at the top of the frame. +Use `set-specifier' to change this. +See `default-gutter' for a description of a valid gutter instantiator. +*/ ); + Vgutter[TOP_GUTTER] =3D Fmake_specifier (Qgutter); + set_specifier_caching (Vgutter[TOP_GUTTER], + slot_offset (struct window, + gutter[TOP_GUTTER]), + gutter_specs_changed, + 0, 0); + + DEFVAR_SPECIFIER ("bottom-gutter", + &Vgutter[BOTTOM_GUTTER] /* +Specifier for the gutter at the bottom of the frame. +Use `set-specifier' to change this. +See `default-gutter' for a description of a valid gutter= instantiator. + +Note that, unless the `default-gutter-position' is `bottom', by +default the height of the bottom gutter (controlled= by +`bottom-gutter-height') is 0; thus, a bottom gutter will not be +displayed even if you provide a value for `bottom-gutter'. +*/ ); + Vgutter[BOTTOM_GUTTER] =3D Fmake_specifier (Qgutter); + set_specifier_caching (Vgutter[BOTTOM_GUTTER], + slot_offset (struct window, + gutter[BOTTOM_GUTTER]), + gutter_specs_changed, + 0, 0); + + DEFVAR_SPECIFIER ("left-gutter", + &Vgutter[LEFT_GUTTER] /* +Specifier for the gutter at the left edge of the frame. +Use `set-specifier' to change this. +See `default-gutter' for a description of a valid gutter= instantiator. + +Note that, unless the `default-gutter-position' is `left', by +default the height of the left gutter (controlled by +`left-gutter-width') is 0; thus, a left gutter will not be +displayed even if you provide a value for `left-gutter'. +*/ ); + Vgutter[LEFT_GUTTER] =3D Fmake_specifier (Qgutter); + set_specifier_caching (Vgutter[LEFT_GUTTER], + slot_offset (struct window, + gutter[LEFT_GUTTER]), + gutter_specs_changed, + 0, 0); + + DEFVAR_SPECIFIER ("right-gutter", + &Vgutter[RIGHT_GUTTER] /* +Specifier for the gutter at the right edge of the frame. +Use `set-specifier' to change this. +See `default-gutter' for a description of a valid gutter= instantiator. + +Note that, unless the `default-gutter-position' is `right', by +default the height of the=20right gutter (controlled= by +`right-gutter-width') is 0; thus, a right gutter will not be +displayed even if you provide a value for `right-gutter'. +*/ ); + Vgutter[RIGHT_GUTTER] =3D Fmake_specifier (Qgutter); + set_specifier_caching (Vgutter[RIGHT_GUTTER], + slot_offset (struct window, + gutter[RIGHT_GUTTER]), + gutter_specs_changed, + 0, 0); + + /* initially, top inherits from default; this can be + changed with `set-default-gutter-position'. */ + fb =3D list1 (Fcons (Qnil, Qnil)); + set_specifier_fallback (Vdefault_gutter, fb); + set_specifier_fallback (Vgutter[TOP_GUTTER], Vdefault_gutter); + set_specifier_fallback (Vgutter[BOTTOM_GUTTER], fb); + set_specifier_fallback (Vgutter[LEFT_GUTTER], fb); + set_specifier_fallback (Vgutter[RIGHT_GUTTER], fb); + + DEFVAR_SPECIFIER ("default-gutter-height", &Vdefault_gutter_height= /* +*Height of the default gutter, if it's oriented horizontally. +This is a specifier; use `set-specifier' to change it. + +The position of the default gutter is specified by the= function +`set-default-gutter-position'. If the corresponding= position-specific +gutter thickness specifier (e.g. `top-gutter-height'= if +`default-gutter-position' is 'top) does not specify a thickness in= a +particular domain (a window or a frame), then the value= of +`default-gutter-height' or `default-gutter-width' (depending on the +gutter orientation) in that domain, if any, will be used instead. + +Note that `default-gutter-height' is only used= when +`default-gutter-position' is 'top or 'bottom, and= `default-gutter-width' +is only used when `default-gutter-position' is 'left or 'right. + +Note that all of the position-specific gutter thickness specifiers +have a fallback value of zero when they do not correspond to the +default gutter. Therefore, you will have to set a non-zero= thickness +value if you want a position-specific gutter to be displayed. +*/ ); + Vdefault_gutter_height =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vdefault_gutter_height, + slot_offset (struct window, + default_gutter_height), + default_gutter_size_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("default-gutter-width", &Vdefault_gutter_width= /* +*Width of the default gutter, if it's oriented vertically. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vdefault_gutter_width =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vdefault_gutter_width, + slot_offset (struct window, + default_gutter_width), + default_gutter_size_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("top-gutter-height", + &Vgutter_size[TOP_GUTTER] /* +*Height of the top gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_size[TOP_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_size[TOP_GUTTER], + slot_offset (struct window, + gutter_size[TOP_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("bottom-gutter-height", + &Vgutter_size[BOTTOM_GUTTER] /* +*Height of the bottom gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_size[BOTTOM_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_size[BOTTOM_GUTTER], + slot_offset (struct window, + gutter_size[BOTTOM_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("left-gutter-width", + &Vgutter_size[LEFT_GUTTER] /* +*Width of left gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_size[LEFT_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_size[LEFT_GUTTER], + slot_offset (struct window, + gutter_size[LEFT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("right-gutter-width", + &Vgutter_size[RIGHT_GUTTER] /* +*Width of right gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_size[RIGHT_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_size[RIGHT_GUTTER], + slot_offset (struct window, + gutter_size[RIGHT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + fb =3D Qnil; +#ifdef HAVE_TTY + fb =3D Fcons (Fcons (list1 (Qtty), Qzero), fb); +#endif +#ifdef HAVE_X_WINDOWS + fb =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_GUTTER_HEIGHT)),= fb); +#endif +#ifdef HAVE_MS_WINDOWS + fb =3D Fcons (Fcons (list1 (Qmswindows), + make_int (DEFAULT_GUTTER_HEIGHT)), fb); +#endif + if (!NILP (fb)) + set_specifier_fallback (Vdefault_gutter_height, fb); + + fb =3D Qnil; +#ifdef HAVE_TTY + fb =3D Fcons (Fcons (list1 (Qtty), Qzero), fb); +#endif +#ifdef HAVE_X_WINDOWS + fb =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_GUTTER_WIDTH)),= fb); +#endif +#ifdef HAVE_MS_WINDOWS + fb =3D Fcons (Fcons (list1 (Qmswindows), + make_int (DEFAULT_GUTTER_WIDTH)), fb); +#endif + if (!NILP (fb)) + set_specifier_fallback (Vdefault_gutter_width, fb); + + set_specifier_fallback (Vgutter_size[TOP_GUTTER],= Vdefault_gutter_height); + fb =3D list1 (Fcons (Qnil, Qzero)); + set_specifier_fallback (Vgutter_size[BOTTOM_GUTTER], fb); + set_specifier_fallback (Vgutter_size[LEFT_GUTTER], fb); + set_specifier_fallback (Vgutter_size[RIGHT_GUTTER], fb); + + DEFVAR_SPECIFIER ("default-gutter-border-width", + &Vdefault_gutter_border_width /* +*Width of the border around the default gutter. +This is a specifier; use `set-specifier' to change it. + +The position of the default gutter is specified by the= function +`set-default-gutter-position'. If the corresponding= position-specific +gutter border width specifier (e.g. `top-gutter-border-width'= if +`default-gutter-position' is 'top) does not specify a border width in= a +particular domain (a window or a frame), then the value= of +`default-gutter-border-width' in that domain, if any, will be= used +instead. + +*/ ); + Vdefault_gutter_border_width =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vdefault_gutter_border_width, + slot_offset (struct window, + default_gutter_border_width), + default_gutter_border_width_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("top-gutter-border-width", + &Vgutter_border_width[TOP_GUTTER] /* +*Border width of the top gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_border_width[TOP_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_border_width[TOP_GUTTER], + slot_offset (struct window, + gutter_border_width[TOP_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("bottom-gutter-border-width", + &Vgutter_border_width[BOTTOM_GUTTER] /* +*Border width of the bottom gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_border_width[BOTTOM_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_border_width[BOTTOM_GUTTER], + slot_offset (struct window, + gutter_border_width[BOTTOM_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("left-gutter-border-width", + &Vgutter_border_width[LEFT_GUTTER] /* +*Border width of left gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_border_width[LEFT_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_border_width[LEFT_GUTTER], + slot_offset (struct window, + gutter_border_width[LEFT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("right-gutter-border-width", + &Vgutter_border_width[RIGHT_GUTTER] /* +*Border width of right gutter. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-height' for more information. +*/ ); + Vgutter_border_width[RIGHT_GUTTER] =3D Fmake_specifier (Qnatnum); + set_specifier_caching (Vgutter_border_width[RIGHT_GUTTER], + slot_offset (struct window, + gutter_border_width[RIGHT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + fb =3D Qnil; +#ifdef HAVE_TTY + fb =3D Fcons (Fcons (list1 (Qtty), Qzero), fb); +#endif +#ifdef HAVE_X_WINDOWS + fb =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_GUTTER_BORDER_WIDTH)),= fb); +#endif +#ifdef HAVE_MS_WINDOWS + fb =3D Fcons (Fcons (list1 (Qmswindows), make_int= (DEFAULT_GUTTER_BORDER_WIDTH)), fb); +#endif + if (!NILP (fb)) + set_specifier_fallback (Vdefault_gutter_border_width, fb); + + set_specifier_fallback (Vgutter_border_width[TOP_GUTTER],= Vdefault_gutter_border_width); + fb =3D list1 (Fcons (Qnil, Qzero)); + set_specifier_fallback (Vgutter_border_width[BOTTOM_GUTTER], fb); + set_specifier_fallback (Vgutter_border_width[LEFT_GUTTER], fb); + set_specifier_fallback (Vgutter_border_width[RIGHT_GUTTER], fb); + + DEFVAR_SPECIFIER ("default-gutter-visible-p", &Vdefault_gutter_visible_p= /* +*Whether the default gutter is visible. +This is a specifier; use `set-specifier' to change it. + +The position of the default gutter is specified by the= function +`set-default-gutter-position'. If the corresponding= position-specific +gutter visibility specifier (e.g. `top-gutter-visible-p'= if +`default-gutter-position' is 'top) does not specify a visible-p value +in a particular domain (a window or a frame), then the value= of +`default-gutter-visible-p' in that domain, if any, will be= used +instead. + +`default-gutter-visible-p' and all of the position-specific= gutter +visibility specifiers have a fallback value of true. +*/ ); + Vdefault_gutter_visible_p =3D Fmake_specifier (Qboolean); + set_specifier_caching (Vdefault_gutter_visible_p, + slot_offset (struct window, + default_gutter_visible_p), + default_gutter_visible_p_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("top-gutter-visible-p", + &Vgutter_visible_p[TOP_GUTTER] /* +*Whether the top gutter is visible. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-visible-p' for more information. +*/ ); + Vgutter_visible_p[TOP_GUTTER] =3D Fmake_specifier (Qboolean); + set_specifier_caching (Vgutter_visible_p[TOP_GUTTER], + slot_offset (struct window, + gutter_visible_p[TOP_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("bottom-gutter-visible-p", + &Vgutter_visible_p[BOTTOM_GUTTER] /* +*Whether the bottom gutter is visible. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-visible-p' for more information. +*/ ); + Vgutter_visible_p[BOTTOM_GUTTER] =3D Fmake_specifier (Qboolean); + set_specifier_caching (Vgutter_visible_p[BOTTOM_GUTTER], + slot_offset (struct window, + gutter_visible_p[BOTTOM_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("left-gutter-visible-p", + &Vgutter_visible_p[LEFT_GUTTER] /* +*Whether the left gutter is visible. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-visible-p' for more information. +*/ ); + Vgutter_visible_p[LEFT_GUTTER] =3D Fmake_specifier (Qboolean); + set_specifier_caching (Vgutter_visible_p[LEFT_GUTTER], + slot_offset (struct window, + gutter_visible_p[LEFT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + DEFVAR_SPECIFIER ("right-gutter-visible-p", + &Vgutter_visible_p[RIGHT_GUTTER] /* +*Whether the right gutter is visible. +This is a specifier; use `set-specifier' to change it. + +See `default-gutter-visible-p' for more information. +*/ ); + Vgutter_visible_p[RIGHT_GUTTER] =3D Fmake_specifier (Qboolean); + set_specifier_caching (Vgutter_visible_p[RIGHT_GUTTER], + slot_offset (struct window, + gutter_visible_p[RIGHT_GUTTER]), + gutter_geometry_changed_in_window, + 0, 0); + + /* initially, top inherits from default; this can be + changed with `set-default-gutter-position'. */ + fb =3D list1 (Fcons (Qnil, Qt)); + set_specifier_fallback (Vdefault_gutter_visible_p, fb); + set_specifier_fallback (Vgutter_visible_p[TOP_GUTTER], + Vdefault_gutter_visible_p); + set_specifier_fallback (Vgutter_visible_p[BOTTOM_GUTTER], fb); + set_specifier_fallback (Vgutter_visible_p[LEFT_GUTTER], fb); + set_specifier_fallback (Vgutter_visible_p[RIGHT_GUTTER], fb); + +} --=====================_931788435==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_931788435==_-- From owner-xemacs-beta@xemacs.org Mon Jul 12 11:10:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA12586 for xemacs-beta-out; Mon, 12 Jul 1999 11:10:29 -0400 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 LAA12569 for ; Mon, 12 Jul 1999 11:10:19 -0400 Received: from brabantio.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 RAA18726 for ; Mon, 12 Jul 1999 17:09:44 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id RAA21562; Mon, 12 Jul 1999 17:09:42 +0200 To: xemacs-beta@xemacs.org Subject: New package system design draft Mime-Version: 1.0 (generated by tm-edit 1.4) Content-Type: multipart/mixed; boundary="Multipart_Mon_Jul_12_17:09:41_1999-1" Content-Transfer-Encoding: 7bit From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 12 Jul 1999 17:09:41 +0200 Message-ID: Lines: 170 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Mon_Jul_12_17:09:41_1999-1 Content-Type: text/plain; charset=US-ASCII Steve and I have been discussing a general overhaul of the package system which is necessary to solve some of the problems that have shown up over the past. Examples are Didier's gripes, Valdis's comments, the ps-print mess, different tracks of Gnus etc. etc. etc. which the current system does not handle gracefully. Here's the rough draft for a new package system design. I tried hard to address all reasonable issues posted over the past. I'd appreciate if people, before yelling at me because of problem X I've forgotten, would first ask me how to solve problem X in this framework. Chances are fair that I'll have an answer. Let me know what you think. --Multipart_Mon_Jul_12_17:09:41_1999-1 Content-Type: text/plain; charset=US-ASCII This is from scratch. Forget the current layout, forget about the current handling of auto-autoloads etc. etc. etc. A package is a collection of files constituting an extension to XEmacs that may be optionally installed or uninstalled as a unit. A package has the following properties: - a name (a symbol) - a description - a version (a string ".") - an author version (a string, free format) - a maintainer (a string) - a predicate indicating whether it can run in a given incarnation of Emacs - a list of package specifications (see below) which must be satisfied for the package to be able to compile - a list of package specifications (see below) which must be satisfied for the package to run (I did not worry about things like checksums, as I'm not an expert on that stuff, but they are supposed to be in there as well.) The following constraint must hold: Two different author versions of a package must have different versions as well. A package is distributed as a directory hierarchy; all files belonging to one package live under that directory, no other files do. The name of the directory uniquely identifies the name of the package as well as its version. Apart from that property, the name of the direcory is completely free-format. The layout of a package is essentially as before. The subdirectory names recognized by XEmacs are the following: etc info lib-src lisp man Moreover, it contains a file specifying the above attributes. An extension of the old package-info would do nicely. A package drops into a *package hierarchy* which is just a directory containing package directories. A package hierarchy has the following properties: - a predicate indicating whether its packages can run in a given incarnation of Emacs Installation happens simply via dropping a package into a package hierarchy, uninstallation happens via removing its directory. There are no associated database files which must be held consistent. >From within the package system, specific packages can be identified via *package specifications*. Here is the syntax for package specifications: -> | ( ?) -> (version ) | (at-least-version ) | (at-most-version ) | (and *) | (or *) | (not ) -> -> The semantics is mostly obvious, hopefully. Do note that the mantissa of version numbers is interpreted in a way different from that of floating point numbers, but rather in the way common in the software world. I.e., "1.10" denotes a later version than "1.2". Moreover, if several packages match a package specification, the specification identifies the one with the latest version. Examples for package specifications: gnus (gnus (at-least-version "1.12")) (efs (and (at-least-version "1.12") (at-most-version "1.15))) (gnus (not (version "0.84"))) API: These are all necessarily macros because they deal with package specifications. However, they transliterate trivially into function calls such that their definitions will not have to change ever. Maybe even the underlying functional interface can be exposed. (package-present-p ) This tests if a package matching the specification exists. It has no side effects. (use-package ) This indicates a preference for a package matching the specification to XEmacs. This means that, in the future, no other packages with the same name may be used in the running XEmacs. It also has the side-effect of making the package's autoloads available. (require-package-feature ) This is like `require', except that it doesn't require quoting and is relative to a package specification where the feature must reside. (provide-package-feature ) Like `provide', only relative to a given package. (locate-package-directory ) (locate-package-library &optional ...) (find-package-library &optional ...) (load-package-library ) (locate-package-data-directory ) (locate-package-data-file ) (locate-package-executable-directory ) (locate-package-executable ) (locate-package-info-directory ) (locate-package-info-file ) These are all like the equivalent existing functions, except that they are relative to a given package specification. The existing functions continue to exist, but change their behavior: Nothing related to packages shows up in the relevant ...-path and ...-directory-list variables. (I.e., package lisp subdirectories do not end up in `load-path.) However, the relevant functions which used to search in them still go through the package directories as a last resort. --Multipart_Mon_Jul_12_17:09:41_1999-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Mon_Jul_12_17:09:41_1999-1-- From owner-xemacs-beta@xemacs.org Mon Jul 12 11:19:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA13251 for xemacs-beta-out; Mon, 12 Jul 1999 11:19:57 -0400 Received: from piinbh1.ms.com (piinbh1.ms.com [199.89.64.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA13240 for ; Mon, 12 Jul 1999 11:19:53 -0400 Received: (from uucp@localhost) by piinbh1.ms.com (8.8.6/fw v1.22) id LAA21273 for ; Mon, 12 Jul 1999 11:19:46 -0400 (EDT) Received: from unknown(144.14.9.190) by piinbh1.ms.com via smap (4.1) id xma020817; Mon, 12 Jul 99 11:19:14 -0400 Received: from sag3 (sag3.morgan.com [144.14.8.198]) by safid1.morgan.com (8.8.5/hub+ldap v2.3) with ESMTP id LAA12365 for ; Mon, 12 Jul 1999 11:19:14 -0400 (EDT) Received: (craffert@localhost) by sag3 (980427.SGI.8.8.8/sendmail.cf.client v1.05) id LAA53468; Mon, 12 Jul 1999 11:19:14 -0400 (EDT) To: XEmacs Beta List Mail-Copies-To: never X-Attribution: > Subject: cvs.xemacs.org cvs port down? Keywords: cvs,xemacs,org,trying,rtelnet,connection,connect X-Face: ByE+UMAp1klWR3?\RNGx(A-~Ri!YT%C6M!sxoJL+.;9`Q/|+dj7[KR>gGMyV.2qZeot0NI`4\MA^_Qg`F9=+Ox&zaE?Y9dV%F~Xzf';Zyk2Aobs.uu^Ey0_C6^~q';G#$HkA!ZAHXPpG-"*|Dd*Z4U$4y{{aI0c%75}i~Of(jxYtI[uIpYF<*Zoe|\*/ufb X-Y-Zippy: CHUBBY CHECKER just had a CHICKEN SANDWICH in downtown DULUTH! From: Colin Rafferty Date: 12 Jul 1999 11:19:13 -0400 Message-ID: Lines: 28 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Sumida) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=-=-= I have been having problems trying to connect to cvs.xemacs.org. The regular telnet poort works, but not the cvs port. Is this intentional? --=-=-= Content-Transfer-Encoding: quoted-printable Content-Description: shell log hobbes $ cvs update cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused hobbes $ rtelnet cvs.xemacs.org 2410 Trying 208.25.65.6... telnet: Unable to connect to remote host: Connection refused hobbes $ rtelnet cvs.xemacs.org Trying 208.25.65.6... Connected to cvs.xemacs.org. Escape character is '^]'. BSDI BSD/OS 3.0 (camelot-soft.camelot-soft.com) (ttyp0) login: =1Dq rtelnet> Connection closed. hobbes $=20 --=-=-= -- Colin --=-=-=-- From owner-xemacs-beta@xemacs.org Mon Jul 12 13:33:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA19398 for xemacs-beta-out; Mon, 12 Jul 1999 13:33:04 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA19394 for ; Mon, 12 Jul 1999 13:33:02 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id NAA27404; Mon, 12 Jul 1999 13:32:16 -0400 (EDT) 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 KAA12872; Mon, 12 Jul 1999 10:31:35 -0700 (PDT) Received: from localhost (darrylo@localhost [127.0.0.1]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id KAA08530; Mon, 12 Jul 1999 10:32:38 -0700 (PDT) Message-Id: <199907121732.KAA08530@mina.sr.hp.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Justin Vallon cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" In-reply-to: Your message of "Sat, 10 Jul 1999 20:55:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 10:32:35 PDT From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Justin Vallon wrote: > So, the patch is basically: If !defined(MATCH_MAY_ALLOCATE) && __hpux, > increase the amount of space regexp_compile allocates up-front for the > worst case (max allowed) stack size (via malloc not alloca). Discounting > config.h features, every platform that hits this line would probably > benefit from increasing the stack size. Don't you mean: !defined(MATCH_MAY_ALLOCATE) || __hpux Anyway, I'd like to point out that the default max stack size under HP-UX is 2MB. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Mon Jul 12 23:09:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA05177 for xemacs-beta-out; Mon, 12 Jul 1999 23:09:56 -0400 Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA05174 for ; Mon, 12 Jul 1999 23:09:55 -0400 Received: from erols.com (209-122-237-118.s626.tnt1.nyw.ny.dialup.rcn.com [209.122.237.118]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id XAA28230; Mon, 12 Jul 1999 23:16:02 -0400 (EDT) Message-ID: <378AAE74.7B135933@erols.com> Date: Mon, 12 Jul 1999 23:11:48 -0400 From: "Matthew O. Persico" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael Sperber [Mr. Preprocessor]" CC: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: A lot of this looks suspiciously like perl. This is a GOOd thing. Larry and his crew have got packages down cold. Emulation can't but help. "Michael Sperber [Mr. Preprocessor]" wrote: > > The following constraint must hold: > > Two different author versions of a package must have different > versions as well. They better have completely different names, period. Suppose Dilbert writes package foo and gets to version 1.3. Ralph the Garbage Man picks though the dumpster, takes Dilbert's code, tightens it up to 12 lines from 1500 and submits it back. (Laugh - that was today's Desktop Dilbert cartoon.) If Dilbert is having a bad ego day and says "Screw you Ralph." what version number is Ralph going to put on his version of Foo? 1.0? 1.4? And if Dilbert upgrades his code, what does he use? 1.4, 1.5? I think that the multiple author problem needs to be solved at a more fundamental level, like DON'T DO THAT! > A package is distributed as a directory hierarchy; all files belonging > to one package live under that directory, no other files do. The name > of the directory uniquely identifies the name of the package as well > as its version. Apart from that property, the name of the direcory is > completely free-format. Hmm. Foo-1.4, Foo-1.5, etc. That may be fine for buildnig the package or even identifying it (a-la Perl modules), but what's going to be the mechanism for determining which installed Foo will be used? I say keep the version OUT of the final install directory structures. > Installation happens simply via dropping a package into a package > hierarchy, uninstallation happens via removing its directory. There > are no associated database files which must be held consistent. Think about a package framwork builder a-la h2xs -X from the Perl world. If you want people to use this, don't let them write 57 [sic] types of shell, perl, lisp scripts to copy stuff to the write directories; the anarchy will be bad news. There should be one sanctioned way to install files to the installation dir. And before anyone say TMTOWTDI vis-a-vis packages, even the docs say start with h2xs. From owner-xemacs-beta@xemacs.org Mon Jul 12 23:31:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA05738 for xemacs-beta-out; Mon, 12 Jul 1999 23:31:38 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA05734 for ; Mon, 12 Jul 1999 23:31:36 -0400 Received: from sparrow.bear.com (user-2ive3hr.dialup.mindspring.com [165.247.14.59]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA11931; Mon, 12 Jul 1999 23:31:31 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id XAA11133; Mon, 12 Jul 1999 23:31:36 -0400 Date: Tue, 13 Jul 1999 03:31:36 +0000 ( ) From: Justin Vallon To: Darryl Okahata cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" In-Reply-To: <199907121732.KAA08530@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, 12 Jul 1999, Darryl Okahata wrote: > Justin Vallon wrote: > > > So, the patch is basically: If !defined(MATCH_MAY_ALLOCATE) && __hpux, > > increase the amount of space regexp_compile allocates up-front for the > > worst case (max allowed) stack size (via malloc not alloca). Discounting > > config.h features, every platform that hits this line would probably > > benefit from increasing the stack size. > > Don't you mean: > > !defined(MATCH_MAY_ALLOCATE) || __hpux > > Anyway, I'd like to point out that the default max stack size under HP-UX is 2MB. No. It's actually defined(MATCH_MAY_ALLOCATE) || defined(__hpux). Your patch was in the !defined(MATCH_MAY_ALLOCATE) part, and if defined(__hpux), then increase the stack size... I haven't experimented, but I suspect that the actual "C" stack may not be used in this situation. I believe that the regex.c fail_stack is allocated up-front, and is not dynamic. I'm not sure about that, though. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Mon Jul 12 23:59:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA06418 for xemacs-beta-out; Mon, 12 Jul 1999 23:59:04 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA06415 for ; Mon, 12 Jul 1999 23:59:03 -0400 Received: from sparrow.bear.com (user-2ive3hr.dialup.mindspring.com [165.247.14.59]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA03501; Mon, 12 Jul 1999 23:59:00 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id XAA11152; Mon, 12 Jul 1999 23:59:05 -0400 Date: Tue, 13 Jul 1999 03:59:05 +0000 ( ) From: Justin Vallon To: "Matthew O. Persico" cc: XEmacs Beta Subject: Re: New package system design draft In-Reply-To: <378AAE74.7B135933@erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, 12 Jul 1999, Matthew O. Persico wrote: > "Michael Sperber [Mr. Preprocessor]" wrote: > > > > The following constraint must hold: > > > > Two different author versions of a package must have different > > versions as well. > > They better have completely different names, period. > > Suppose Dilbert writes package foo and gets to version 1.3. Ralph > the Garbage Man picks though the dumpster, takes Dilbert's code, > tightens > it up to 12 lines from 1500 and submits it back. (Laugh - that was > today's Desktop Dilbert cartoon.) > > If Dilbert is having a bad ego day and says "Screw you Ralph." what > version number is Ralph going to put on his version of Foo? 1.0? 1.4? > And if Dilbert upgrades his code, what does he use? 1.4, 1.5? > > I think that the multiple author problem needs to be solved at a more > fundamental level, like DON'T DO THAT! I've had the same thought with regard to rpms. I've built rpms (sendmail 8.9.1), giving them rev 1, but in 20/20 hindsight, that's not right because somebody else somewhere will most likely pick rev 1. So, I now tend toward 1jv. Extend this to globally unique names, and you might end up with Foo-Dilbert@AdamsSoftware.com-1.4 and Foo-Ralph@garbage.gov-1.4. > > A package is distributed as a directory hierarchy; all files belonging > > to one package live under that directory, no other files do. The name > > of the directory uniquely identifies the name of the package as well > > as its version. Apart from that property, the name of the direcory is > > completely free-format. > > Hmm. Foo-1.4, Foo-1.5, etc. That may be fine for buildnig the package or > even identifying it (a-la Perl modules), but what's going to be the > mechanism for determining which installed Foo will be used? I say keep > the version OUT of the final install directory structures. If we're speaking philisophically, definately not. You might only want to use Foo-1.5, but wouldn't it be nice if I could install Foo-1.6b1 along side Foo-1.5 (and Foo-1.6b2)? You might want to use Foo-1.5 as stable, but I test 1.6 as beta. Your question is still valid: Which version to use for (require 'Foo)? Further, Foo-1.6 might use Bar-1.4, but Foo-1.5 uses Bar-1.3. Transitive dependencies kill you if you can't have two versions co-exist. That is, updating one package may trigger a cascade of "you need Bar-1.4, not Bar-1.3". Worst, then imagine that Baz-1.0 can't use Bar-1.4. That means that I can't upgrade to Foo-1.5 because Baz-1.0 can't use Bar-1.4. I hope you get the idea. > > Installation happens simply via dropping a package into a package > > hierarchy, uninstallation happens via removing its directory. There > > are no associated database files which must be held consistent. > > Think about a package framwork builder a-la h2xs -X from the Perl world. > If you want people to use this, don't let them write 57 [sic] > types of shell, perl, lisp scripts to copy stuff to the write > directories; > the anarchy will be bad news. There should be one sanctioned way to > install > files to the installation dir. I don't know what h2xs is. However, I don't see why 'tar xf' can't be your sanctioned installation method, and 'rm -rf' is your sanctioned removal method. > And before anyone say TMTOWTDI vis-a-vis packages, even the docs say > start > with h2xs. TMTOWTDI? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Tue Jul 13 00:10:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA06777 for xemacs-beta-out; Tue, 13 Jul 1999 00:10:19 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA06773 for ; Tue, 13 Jul 1999 00:10:14 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA26175 for ; Tue, 13 Jul 1999 13:10:12 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: "Stack overflow in regexp" References: X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "09 Jul 1999 11:38:32 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 13 Jul 1999 13:10:09 +0900 Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: ... >> b) Does a larger regexp stack hurt performance? (a little memory isn't >> that expensive, but I wouldn't want to slow things down) We fiddled with regexp parameters some time back at William Perry's request. [... digging...] It was in May of 1998 and we tweaked the regexp cache size. There was an increase in memory usage with no perceptible change of performance. Richard backed out the change and I never put it into a released XEmacs. We can revisit this if people wish to experiment. -- $B3?$N;R$O3?(B (Like father, like son) From owner-xemacs-beta@xemacs.org Tue Jul 13 03:16:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA10303 for xemacs-beta-out; Tue, 13 Jul 1999 03:16:29 -0400 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 DAA10299 for ; Tue, 13 Jul 1999 03:16:24 -0400 Received: from brabantio.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 JAA15470 for ; Tue, 13 Jul 1999 09:16:19 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id JAA17362; Tue, 13 Jul 1999 09:16:16 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: <378AAE74.7B135933@erols.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: 13 Jul 1999 09:16:16 +0200 In-Reply-To: "Matthew O. Persico"'s message of "Mon, 12 Jul 1999 23:11:48 -0400" 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 DAA10301 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Matthew" == Matthew O Persico writes: Matthew> A lot of this looks suspiciously like perl. This is a GOOd thing. Matthew> Larry and his crew have got packages down cold. Emulation can't Matthew> but help. Oh god, what nonsense ... Matthew> "Michael Sperber [Mr. Preprocessor]" wrote: >> >> The following constraint must hold: >> >> Two different author versions of a package must have different >> versions as well. Matthew> They better have completely different names, period. You misunderstand the concept of "author version." Reread the draft. Matthew> Hmm. Foo-1.4, Foo-1.5, etc. That may be fine for buildnig the package or Matthew> even identifying it (a-la Perl modules), but what's going to be the Matthew> mechanism for determining which installed Foo will be used? I say keep Matthew> the version OUT of the final install directory structures. >From the draft: > (use-package ) > > This indicates a preference for a package matching the specification > to XEmacs. This means that, in the future, no other packages with the > same name may be used in the running XEmacs. It also has the > side-effect of making the package's autoloads available. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 04:30:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA11504 for xemacs-beta-out; Tue, 13 Jul 1999 04:30:28 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA11501 for ; Tue, 13 Jul 1999 04:30:25 -0400 Received: from metheny.enst.fr (52l6rYIvCDdUWFAAKLUyRuuO5Ky+HG+J@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id KAA24628; Tue, 13 Jul 1999 10:30:23 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id KAA02140; Tue, 13 Jul 1999 10:30:19 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "12 Jul 1999 17:09:41 +0200" 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: 65 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: You say this: > A package has the following properties: > [ ... ] > - a predicate indicating whether it can run in a given incarnation of > Emacs And then that: > A package drops into a *package hierarchy* which is just a directory > containing package directories. A package hierarchy has the > following properties: > > - a predicate indicating whether its packages can run in a given > incarnation of Emacs ... which I don't understand. 1/ Isn't this redundant ? 2/ What do you call an "Emacs incarnation" ? Is it the set of (GNU or X)-Emacs, (no)Mule and other compilation-time flags ? Is it a purely static thing, or does it include dynamic stuff, like "there's no reason to make package Foo available in the current XEmacs session, because it can only work under X and there're only tty frames right now" ? 3/ What do you call a package hierarchy exactly ? Can you have sub-hierarchies in there ? And what if a package has several of your predicates ? Where should it go ? To be more explicit, suppose package foo can't run under mule, package bar can only run under mule, and package baz can do both (it decides by himself). Where should they go ? > (use-package ) Why not \usepackage{specification} ? :-) > This indicates a preference for a package matching the specification > to XEmacs. This means that, in the future, no other packages with the > same name may be used in the running XEmacs. It also has the > side-effect of making the package's autoloads available. What happens if there's no match for this specification ? > (require-package-feature ) I understand that this is probably in case several packages provide the same feature at some point. But is it possible for a package to require another one ? Like, in gnus you would have (require-package w3 ; Tue, 13 Jul 1999 04:32:41 -0400 Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6D8WZ003886; Tue, 13 Jul 1999 04:32:35 -0400 Message-Id: <199907130832.d6D8WZ003886@black-ice.cc.vt.edu> To: Justin Vallon cc: XEmacs Beta Subject: Re: New package system design draft In-reply-to: Your message of "Tue, 13 Jul 1999 03:59:05 -0000." 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[ Date: Tue, 13 Jul 1999 04:32:35 -0400 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Tue, 13 Jul 1999 03:59:05 -0000, Justin Vallon said: > Further, Foo-1.6 might use Bar-1.4, but Foo-1.5 uses Bar-1.3. Transitive > dependencies kill you if you can't have two versions co-exist. That is, > updating one package may trigger a cascade of "you need Bar-1.4, not > Bar-1.3". Worst, then imagine that Baz-1.0 can't use Bar-1.4. That means > that I can't upgrade to Foo-1.5 because Baz-1.0 can't use Bar-1.4. Amen, brother.. ;) That was my biggest concern with the current package system - that it can't easily deal with this, especially in a multi-user environment where "install the ones you need yourself" isnt an option... > > the anarchy will be bad news. There should be one sanctioned way to > > install > > files to the installation dir. > > I don't know what h2xs is. However, I don't see why 'tar xf' can't be > your sanctioned installation method, and 'rm -rf' is your sanctioned > removal method. While we're here, let me remind everybody that "the directory you install into" isn't always the one you execute out of. For AFS or Depot installations, you need to be able to specify something like "installprefix=/path/to/use/instead/of/usr_local". For the base Xemacs, I can use 'make install prefix='. Perl allows a 'config.over' file that changes the various installdir values. For a Sumo tarball, I can 'cd $installpref; tar xvf' and then do the back-end magic to make things appear in /usr/local. But I haven't seen a way to do that function with the current package code (if I'm blind, somebody hand me a braille pointer to the incantation needed). Since I use Depot here, I've basically been stuck untarring Sumos and not using the fancy package-updater, since it insists on scribbling in /usr/local by default.. pui-package-install-dest-dir *almost* does the right thing, except it's in package-ui.el, it would be nice if the defcustom was actually in package-get.el, so jsut saying M-x package-get-update-all would Do The Right Thing. (Basically, from the menubar, pui-list-packages can *install* into a new target directory, but "Update installed packages" takes you to package-get-update-all which doesn't seem to know how to do it...) Enough 4AM rambling.. ;) /Valdis From owner-xemacs-beta@xemacs.org Tue Jul 13 04:46:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA11955 for xemacs-beta-out; Tue, 13 Jul 1999 04:46:24 -0400 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 EAA11949 for ; Tue, 13 Jul 1999 04:46:20 -0400 Received: from brabantio.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 KAA18692 for ; Tue, 13 Jul 1999 10:46:15 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id KAA21698; Tue, 13 Jul 1999 10:46:13 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 10:46:13 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 10:30:19 +0200" Message-ID: Lines: 129 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 EAA11953 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> You say this: >> A package has the following properties: >> [ ... ] >> - a predicate indicating whether it can run in a given incarnation of >> Emacs dv> And then that: >> A package drops into a *package hierarchy* which is just a directory >> containing package directories. A package hierarchy has the >> following properties: >> >> - a predicate indicating whether its packages can run in a given >> incarnation of Emacs dv> ... which I don't understand. dv> 1/ Isn't this redundant ? Absolutely. It's just an efficiency thing. dv> 2/ What do you call an "Emacs incarnation" ? dv> Is it the set of (GNU or X)-Emacs, (no)Mule and other compilation-time dv> flags ? Is it a purely static thing, or does it include dynamic stuff, like dv> "there's no reason to make package Foo available in the current XEmacs dv> session, because it can only work under X and there're only tty frames dv> right now" ? The former. These will be evaluated upon startup, mainly. dv> 3/ What do you call a package hierarchy exactly ? Can you have sub-hierarchies dv> in there ? No. dv> And what if a package has several of your predicates ? Huh? It has only one. dv> Where dv> should it go ? You must decide upon installation where it goes. This has nothing to do with predicates. dv> To be more explicit, suppose package foo can't run under mule, dv> package bar can only run under mule, and package baz can do dv> both (it decides by himself). Where should they go ? This isn't prescribed by the package system, and it shouldn't be. You'd probably have a default setup with a separate mule hierarchy in which you might put bar. The rest, you'd put in an unconditionalized hierarchy. The only thing you have to watch out for is that a package hierarchy predicate must not inadvertently "hide" packages inside, i.e. you don't want to put packages which run under no-Mule in a package hierarchy conditionalized on Mule. >> (use-package ) dv> Why not \usepackage{specification} ? :-) :-) >> This indicates a preference for a package matching the specification >> to XEmacs. This means that, in the future, no other packages with the >> same name may be used in the running XEmacs. It also has the >> side-effect of making the package's autoloads available. dv> What happens if there's no match for this specification ? You get an error. >> (require-package-feature ) dv> I understand that this is probably in case several packages provide dv> the same feature at some point. We have (or had?) this already with vc vs. vc-cc, didn't we? dv> But is it possible for a package to require dv> another one ? Like, in gnus you would have (require-package w3 Which brings us to another point. Suppose I have a use-package for w3 dv> and a certain spec, but gnus requires w3 with another spec. How will this be dv> solved ? This will also give an error. You can't solve this without a Lisp-level module system. dv> And a last question: what about the place of C modules in this package dv> layout ? I don't know enough about the C module system yet to make a definitive statement, but I've implemented at least two C module interfaces for Scheme engines, so I'm reasonably confident that the extension will be straightforward. Just add a directory to the package structure and extend the API. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 05:12:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA12673 for xemacs-beta-out; Tue, 13 Jul 1999 05:12:09 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA12669 for ; Tue, 13 Jul 1999 05:12:07 -0400 Received: from metheny.enst.fr (zHVDNbrTQU3cvqLv5Yt41uyOyV9Id1CU@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA26179; Tue, 13 Jul 1999 11:12:05 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA02166; Tue, 13 Jul 1999 11:12:03 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 10:46:13 +0200" 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: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > dv> But is it possible for a package to require > dv> another one ? Like, in gnus you would have (require-package w3 > I don't understand this. What's ") which, according to what you said, would give an error if I happen to have a use-package call for baz but with another baz specification. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 13 05:22:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA12916 for xemacs-beta-out; Tue, 13 Jul 1999 05:22:01 -0400 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 FAA12912 for ; Tue, 13 Jul 1999 05:21:56 -0400 Received: from brabantio.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 LAA18758 for ; Tue, 13 Jul 1999 11:21:55 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id LAA17194; Tue, 13 Jul 1999 11:21:53 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 11:21:53 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 11:11:57 +0200" Message-ID: Lines: 26 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 FAA12914 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> But is it possible for a package to require dv> another one ? Like, in gnus you would have (require-package w3 > >> I don't understand this. What's " Typo. I meant suppose that a package requires another package (not dv> only one feature of this package) with a particular specification, hence it dv> would be nice to have something similar to you require-package-feature, but dv> for the whole package itself: I still don't understand. What's the meaning of "to require another package (not only one feature of this package)" operationally? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 06:10:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA13990 for xemacs-beta-out; Tue, 13 Jul 1999 06:10:26 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA13987 for ; Tue, 13 Jul 1999 06:10:24 -0400 Received: from metheny.enst.fr (538JVGJduEiGmB0b/Dg7YxrMY/hgOfyv@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id MAA28897; Tue, 13 Jul 1999 12:10:20 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id MAA02254; Tue, 13 Jul 1999 12:10:16 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 11:21:53 +0200" 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: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > I still don't understand. What's the meaning of "to require another > package (not only one feature of this package)" operationally? Well, my idea was to require at once all the features a package can provide, in the case several of them would need to be require'd explicitely. However, I admit I have no pertinent example of this right now. In a similar vein, you might let the FEATURE argument in `require-package-feature' to be either a symbol, or a list of symbols. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 13 06:18:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA14115 for xemacs-beta-out; Tue, 13 Jul 1999 06:18:57 -0400 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 GAA14112 for ; Tue, 13 Jul 1999 06:18:55 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA19894 for ; Tue, 13 Jul 1999 12:18:53 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004qi; Tue Jul 13 12:18:45 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA28167; Tue, 13 Jul 1999 12:18:45 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: From: Jan Vroonhof Date: 13 Jul 1999 12:18:44 +0200 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "12 Jul 1999 17:09:41 +0200" Message-ID: Lines: 38 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: > - a name (a symbol) > - a description > - a version (a string ".") Are and supposed to be numbers? > - a list of package specifications (see below) which must be satisfied > for the package to be able to compile > - a list of package specifications (see below) which must be satisfied > for the package to run I would love to see (for the purposes of the install tool) the debian dpkg-style weaker dependencies. Also I would dearly love a list of features provided (or at least major and minor modes). > (use-package ) > > This indicates a preference for a package matching the specification > to XEmacs. This means that, in the future, no other packages with the > same name may be used in the running XEmacs. It also has the > side-effect of making the package's autoloads available. When exactly are the packages autoloads read? What happens to packages that are never '(use-package ..)'ed? Or more specifically: How do the major/minor modes, menu entries and user commands implemented by packages get advertised? > Nothing related to packages shows up in the relevant ...-path and > ...-directory-list variables. (I.e., package lisp subdirectories do > not end up in `load-path.) However, the relevant functions which used > to search in them still go through the package directories as a last > resort. Thus 'load-path''s standard value is "nil"? Per is going to love that. Jan From owner-xemacs-beta@xemacs.org Tue Jul 13 08:16:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA16216 for xemacs-beta-out; Tue, 13 Jul 1999 08:16:03 -0400 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 IAA16212 for ; Tue, 13 Jul 1999 08:15:48 -0400 Received: from brabantio.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 OAA15090 for ; Tue, 13 Jul 1999 14:15:38 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id OAA17604; Tue, 13 Jul 1999 14:15:36 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 14:15:36 +0200 In-Reply-To: Jan Vroonhof's message of "13 Jul 1999 12:18:44 +0200" Message-ID: Lines: 75 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 IAA16214 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: >> - a name (a symbol) >> - a description >> - a version (a string ".") Jan> Are and supposed to be numbers? Yes. >> - a list of package specifications (see below) which must be satisfied >> for the package to be able to compile >> - a list of package specifications (see below) which must be satisfied >> for the package to run Jan> I would love to see (for the purposes of the install tool) the debian Jan> dpkg-style weaker dependencies. Also I would dearly love a list of Jan> features provided (or at least major and minor modes). Could you elaborate? I know nothing about dpkg. >> (use-package ) >> >> This indicates a preference for a package matching the specification >> to XEmacs. This means that, in the future, no other packages with the >> same name may be used in the running XEmacs. It also has the >> side-effect of making the package's autoloads available. Jan> When exactly are the packages autoloads read? Upon `use-package.' Jan> What happens to packages Jan> that are never '(use-package ..)'ed? Nothing happens to them, nothing happens with them. Jan> Or more specifically: How do the major/minor modes, menu entries Jan> and user commands implemented by packages get advertised? Via `use-package.' There's no way around that if you want multiple-version coexistence. >> Nothing related to packages shows up in the relevant ...-path and >> ...-directory-list variables. (I.e., package lisp subdirectories do >> not end up in `load-path.) However, the relevant functions which used >> to search in them still go through the package directories as a last >> resort. Jan> Thus 'load-path''s standard value is "nil"? Absolutely. To be more precise, though, that's a different overhaul which ties in with this one. The whole concept of a `load-path' is fundamentally incompatible with a package system that manages metainformation. You want it only as a last resort for backwards compatibility. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 08:18:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA16249 for xemacs-beta-out; Tue, 13 Jul 1999 08:18:28 -0400 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 IAA16246 for ; Tue, 13 Jul 1999 08:18:26 -0400 Received: from brabantio.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 OAA14848 for ; Tue, 13 Jul 1999 14:18:15 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id OAA28362; Tue, 13 Jul 1999 14:18:13 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 14:18:13 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 12:10:15 +0200" 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 IAA16247 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> I still don't understand. What's the meaning of "to require another >> package (not only one feature of this package)" operationally? dv> Well, my idea was to require at once all the features a package can dv> provide, in the case several of them would need to be require'd dv> explicitely. I'm sure packages for which this makes sense already have a "super-feature" ('w3 probably is one) which, when require'd, requires the other ones or signs them up for autoload. I don't think it makes sense to do special API provision for this case. However, it would make plenty of sense to establish naming conventions for them. The mental step from "vc" to (require 'vc-hooks) is a big one. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 08:19:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA16269 for xemacs-beta-out; Tue, 13 Jul 1999 08:19:40 -0400 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 IAA16257 for ; Tue, 13 Jul 1999 08:19:04 -0400 Received: from brabantio.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 OAA18696 for ; Tue, 13 Jul 1999 14:19:00 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id OAA29648; Tue, 13 Jul 1999 14:18:58 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 14:18:58 +0200 In-Reply-To: Jan Vroonhof's message of "13 Jul 1999 12:18:44 +0200" Message-ID: Lines: 11 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 IAA16267 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Also I would dearly love a list of Jan> features provided (or at least major and minor modes). That makes sense. I'll keep it in mind. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 09:29:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA18572 for xemacs-beta-out; Tue, 13 Jul 1999 09:29:13 -0400 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 JAA18568 for ; Tue, 13 Jul 1999 09:29:11 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id PAA06929 for ; Tue, 13 Jul 1999 15:29:10 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001g8; Tue Jul 13 15:29:01 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id PAA29643; Tue, 13 Jul 1999 15:29:00 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: From: Jan Vroonhof Date: 13 Jul 1999 15:28:59 +0200 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 14:15:36 +0200" Message-ID: Lines: 45 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 would love to see (for the purposes of the install tool) the debian > Jan> dpkg-style weaker dependencies. Also I would dearly love a list of > Jan> features provided (or at least major and minor modes). > > Could you elaborate? I know nothing about dpkg. The debian package system has progressively weaker dependencies that are something like this depends: Technically required to run (typically needed libraries). recommends: Normal operation typically requires this to be intalled too. suggest: This might be useful if you are using this packages. Only "depends" is enforced by the low level package system. Recommends and suggests are used by the package installer UI. When you select a package you are shown all three dependencies with the Depends and Recommends default to selected. This makes it a lot easier to find your way around the packages. In our case for instance auctex would "suggest" reftex. Jan > Jan> Or more specifically: How do the major/minor modes, menu entries > Jan> and user commands implemented by packages get advertised? > > Via `use-package.' There's no way around that if you want > multiple-version coexistence. Aren't you throwing out the baby with the bath water then. One my reasons for using XEmacs was that there are lot more "third party" tools that you could use. Look how much simpler the installation instruction for X-symbol and Reftex have become with the current package system. "Untar, restart, M-x reftex-mode RET". How would something like "(auto-compression-mode 1)" work without it being autoloaded etc. This aspect worries me. I know the current scanning takes time but it _is_ mighty convenient. Jan From owner-xemacs-beta@xemacs.org Tue Jul 13 09:43:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA18880 for xemacs-beta-out; Tue, 13 Jul 1999 09:43:51 -0400 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 JAA18875 for ; Tue, 13 Jul 1999 09:43:43 -0400 Received: from brabantio.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 PAA15098 for ; Tue, 13 Jul 1999 15:43:42 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id PAA17518; Tue, 13 Jul 1999 15:43:40 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 15:43:39 +0200 In-Reply-To: Jan Vroonhof's message of "13 Jul 1999 15:28:59 +0200" Message-ID: Lines: 25 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 JAA18878 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Or more specifically: How do the major/minor modes, menu entries Jan> and user commands implemented by packages get advertised? >> >> Via `use-package.' There's no way around that if you want >> multiple-version coexistence. Jan> Aren't you throwing out the baby with the bath water then. One my Jan> reasons for using XEmacs was that there are lot more "third party" Jan> tools that you could use. Look how much simpler the installation Jan> instruction for X-symbol and Reftex have become with the current Jan> package system. "Untar, restart, M-x reftex-mode RET". It would be trivial enough to generally manage the `use-package' clauses via a user interface. We don't really have a choice. It was a mistake to make things implicit which should be explicit. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 10:00:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA19411 for xemacs-beta-out; Tue, 13 Jul 1999 10:00:33 -0400 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 KAA19407 for ; Tue, 13 Jul 1999 10:00:27 -0400 Received: from beta.cis.ohio-state.edu (ware@beta.cis.ohio-state.edu [164.107.112.14]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id KAA19045; Tue, 13 Jul 1999 10:00:23 -0400 (EDT) Received: (from ware@localhost) by beta.cis.ohio-state.edu (8.9.1/8.9.1) id KAA09439; Tue, 13 Jul 1999 10:00:23 -0400 (EDT) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: From: Pete Ware Date: 13 Jul 1999 10:00:23 -0400 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 14:15:36 +0200" Message-ID: Lines: 28 User-Agent: Gnus/5.070087 (Pterodactyl Gnus v0.87) XEmacs/21.2 (Sumida) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] writes: > > Jan> When exactly are the packages autoloads read? > > Upon `use-package.' > > Jan> What happens to packages > Jan> that are never '(use-package ..)'ed? > > Nothing happens to them, nothing happens with them. > > Jan> Or more specifically: How do the major/minor modes, menu entries > Jan> and user commands implemented by packages get advertised? > > Via `use-package.' There's no way around that if you want > multiple-version coexistence. Hmmm. I appreciate being able to choose multiple versions and the performance gain by not searching all the packages. Isn't Emacs starting up with a bunch of autoloads something we are pretty used to? Can one share package directories across machines and architectures (cf. etc/) --pete From owner-xemacs-beta@xemacs.org Tue Jul 13 10:18:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA20036 for xemacs-beta-out; Tue, 13 Jul 1999 10:18:27 -0400 Received: from boffi95.stru.polimi.it (boffi95.stru.polimi.it [131.175.24.94]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA20032 for ; Tue, 13 Jul 1999 10:18:23 -0400 Received: (from jim@localhost) by boffi95.stru.polimi.it (8.9.3/8.9.3) id SAA21435; Tue, 13 Jul 1999 18:16:24 +0200 From: giacomo boffi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14219.26191.759276.833435@boffi95.stru.polimi.it> Date: Tue, 13 Jul 1999 18:16:15 +0200 (CEST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft In-Reply-To: References: X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Reply-To: giacomo.boffi@polimi.it Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] writes: > >>>>> "Jan" == Jan Vroonhof writes: > > Jan> When exactly are the packages autoloads read? > > Upon `use-package.' so joe has to explicitly name every package that he's going to use, correct? it seems a bit overwhelming ... From owner-xemacs-beta@xemacs.org Tue Jul 13 10:33:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA20408 for xemacs-beta-out; Tue, 13 Jul 1999 10:33:22 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA20403 for ; Tue, 13 Jul 1999 10:33:20 -0400 Received: from metheny.enst.fr (sW1+K8KWuTRdPltpMJmkGwB32NThtl6Z@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id QAA09929; Tue, 13 Jul 1999 16:33:14 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id QAA02499; Tue, 13 Jul 1999 16:33:11 +0200 (MET DST) To: Pete Ware Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: Pete Ware's message of "13 Jul 1999 10:00:23 -0400" 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: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Pete Ware writes: > Can one share package directories across machines and architectures > (cf. etc/) That's a good point. Perhaps the most important argument against having all files related to a package under a single directory. There's already a problem with the lib-src subdir, and will be another one when we start having packages with C modules in them. It would really be a pity not to fix this problem in the Great Package Overhaul. The fact is that most of the packages subdir already exist in the GNU Coding Standards. - etc, info, man exist. - lisp should go under .../share - lib-src actually belongs to libexec. - lib could then be used for C modules. So I think instead of having a single directory for a particular package, we could replicate this hierarchy under all needed standard directories, with the same naming policy. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 13 10:54:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA21036 for xemacs-beta-out; Tue, 13 Jul 1999 10:54:14 -0400 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 KAA21032 for ; Tue, 13 Jul 1999 10:54:13 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id QAA12420 for ; Tue, 13 Jul 1999 16:54:07 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa00320; Tue Jul 13 16:53:59 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id QAA29863; Tue, 13 Jul 1999 16:53:59 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: From: Jan Vroonhof Date: 13 Jul 1999 16:53:58 +0200 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 15:43:39 +0200" 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: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > It would be trivial enough to generally manage the `use-package' > clauses via a user interface. Aha. OK. So the package system would still do what I want, but simply at a higher level? i.e. there is a list of packages to 'use' somewhere that is typically managed by the package installation interface? Jan From owner-xemacs-beta@xemacs.org Tue Jul 13 11:05:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA21437 for xemacs-beta-out; Tue, 13 Jul 1999 11:05:24 -0400 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 LAA21432 for ; Tue, 13 Jul 1999 11:05:22 -0400 Received: from brabantio.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 RAA19198 for ; Tue, 13 Jul 1999 17:05:17 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id RAA17354; Tue, 13 Jul 1999 17:05:15 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 17:05:14 +0200 In-Reply-To: Jan Vroonhof's message of "13 Jul 1999 16:53:58 +0200" Message-ID: Lines: 22 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 LAA21435 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: >> It would be trivial enough to generally manage the `use-package' >> clauses via a user interface. Jan> Aha. OK. So the package system would still do what I want, but simply Jan> at a higher level? i.e. there is a list of packages to 'use' somewhere Jan> that is typically managed by the package installation interface? You probably don't want it managed by *package installation* since the package users are typically not the package installers. But, in principle, yes. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 11:07:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA21526 for xemacs-beta-out; Tue, 13 Jul 1999 11:07:25 -0400 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 LAA21507 for ; Tue, 13 Jul 1999 11:07:08 -0400 Received: from brabantio.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 RAA18694 for ; Tue, 13 Jul 1999 17:07:07 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id RAA29648; Tue, 13 Jul 1999 17:07:05 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: <14219.26191.759276.833435@boffi95.stru.polimi.it> 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: 13 Jul 1999 17:07:04 +0200 In-Reply-To: giacomo boffi's message of "Tue, 13 Jul 1999 18:16:15 +0200 (CEST)" Message-ID: Lines: 22 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 LAA21522 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "GB" == giacomo boffi writes: GB> Michael Sperber [Mr. Preprocessor] writes: >> >>>>> "Jan" == Jan Vroonhof writes: >> Jan> When exactly are the packages autoloads read? >> >> Upon `use-package.' GB> so joe has to explicitly name every package that he's going to use, GB> correct? it seems a bit overwhelming ... Why? Most packages are non-sideeffecting upon autoload and load anyway, so you already need to be explicit about package use one way or another. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 11:16:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA21874 for xemacs-beta-out; Tue, 13 Jul 1999 11:16:02 -0400 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 LAA21861 for ; Tue, 13 Jul 1999 11:15:51 -0400 Received: from brabantio.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 RAA18718 for ; Tue, 13 Jul 1999 17:15:49 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id RAA17640; Tue, 13 Jul 1999 17:15:47 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 17:15:47 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 16:33:11 +0200" Message-ID: Lines: 53 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 LAA21872 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> Pete Ware writes: >> Can one share package directories across machines and architectures >> (cf. etc/) dv> That's a good point. Perhaps the most important argument against dv> having all files related to a package under a single directory. There's dv> already a problem with the lib-src subdir, and will be another one when we dv> start having packages with C modules in them. Yes. I'll consider this for the revision. dv> It would really be a pity not to fix this problem in the Great Package dv> Overhaul. The fact is that most of the packages subdir already exist in the dv> GNU Coding Standards. dv> - etc, info, man exist. dv> - lisp should go under .../share dv> - lib-src actually belongs to libexec. dv> - lib could then be used for C modules. dv> So I think instead of having a single directory for a particular dv> package, we could replicate this hierarchy under all needed standard dv> directories, with the same naming policy. This would destroy a large part of the rationale for the proposal. I think this high-level organizational question is better not touched upon by the package system at all. GNU Coding Standards are one thing, but few software packages adhere to them, and there are a gazillion other such standards. Few packaging problems are satisfactorily solved by directory organization alone, and the main thrust of the draft is to make things as independent as possible from it. You can mainly try to not let it get in the way too much. The approach of the GNU Standards seems to be to move architecture-specific stuff pretty deep into the hierarchy, across disjoint portions of it. Probably a workable approach is to distinguish architectures under , and let the high-level directory structure just do what it needs to do. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 11:52:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA23221 for xemacs-beta-out; Tue, 13 Jul 1999 11:52:20 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA23218 for ; Tue, 13 Jul 1999 11:52:18 -0400 Received: from metheny.enst.fr (TXKtyKOaOw5cMAi6AqOBMRrs3AFfZkk/@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id RAA12974; Tue, 13 Jul 1999 17:52:17 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id RAA02557; Tue, 13 Jul 1999 17:52:14 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 17:15:47 +0200" 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: 54 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > This would destroy a large part of the rationale for the proposal. I > think this high-level organizational question is better not touched > upon by the package system at all. GNU Coding Standards are one > thing, but few software packages adhere to them, and there are a > gazillion other such standards. Hmm, these are not really arguments, are they ? > Probably a workable approach is to distinguish architectures under the name of the directory>, and let the high-level directory structure just > do what it needs to do. You mean each package directory would have a ${arch}/lib-src subdir ? Well, we're talking about two different things here: first separating architecture-dependant stuff, and secondly /sharing/ what can be shared. If you distinguish architectures with different subdirs, that's all right, but that doesn't mean that you will actually share the lisp code, the etc stuff etc. This matter is also very important to me. I've got most of the packages installed and it's more than 22 Mo lisp code. Here, we have a /usr/local/share[1] directory which is automounted from a single machine onto the others. It's really comfortable to install stuff under it, knowing that all machines will immediately see it. From a sysadmin point of view, installing architecture independant stuff for XEmacs packages under this directory would be straightforward. However, imagine the pain it would be to update all machines on a site to make them mount /whatever/xemacs-packages/foo-1.32/lisp each time such a package is installed. If you're really against the split, I'd like to hear real arguments: how does it break the rationale, and why is it so bad to break it this way ? On the other hand, we could maybe reach an agreement on an intermediate solution, like having only one replication of the whole hierarchy. For instance: - put the original hierarchy under /usr/local/share/ organized in the way you described, with lisp, etc, info, man subdirs, but *not* lib-src, - put a clone of this organization under /usr/local/lib with lib-src stuff and possibly C modules Footnotes: [1] Reminder: Stallmacs installs its lisp code there. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 13 12:05:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA23822 for xemacs-beta-out; Tue, 13 Jul 1999 12:05:32 -0400 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 MAA23814 for ; Tue, 13 Jul 1999 12:05:21 -0400 Received: from brabantio.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 SAA19884 for ; Tue, 13 Jul 1999 18:05:17 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id SAA29624; Tue, 13 Jul 1999 18:05:15 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 13 Jul 1999 18:05:14 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 17:52:13 +0200" Message-ID: Lines: 91 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 MAA23820 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Probably a workable approach is to distinguish architectures under > the name of the directory>, and let the high-level directory structure just >> do what it needs to do. dv> You mean each package directory would have a ${arch}/lib-src subdir ? Actually, I was thinking of lib-src/${arch}, but that's not really important. dv> Well, we're talking about two different things here: first separating dv> architecture-dependant stuff, and secondly /sharing/ what can be dv> shared. Sure, but that's mostly a high-level organizational issue, and different systems address the issue in different ways. You cater to one, you hurt the others. dv> Here, we have a /usr/local/share[1] directory which is automounted dv> from a single machine onto the others. It's really comfortable to install dv> stuff under it, knowing that all machines will immediately see it. From a dv> sysadmin point of view, installing architecture independant stuff for XEmacs dv> packages under this directory would be straightforward. However, imagine the dv> pain it would be to update all machines on a site to make them mount dv> /whatever/xemacs-packages/foo-1.32/lisp each time such a package is installed. I'm afraid I don't understand the point you're making. If a package contains architecture-depdendent stuff, you obviously need to install at least parts of it somewhere other than /usr/local/share if you want to preserve the integrity of your setup. I don't know if that means requiring explicit mounts, but that doesn't really matter. Why not install the whole thing somewhere else then? If you want sharing in your setup, that's what symbolic links are for. They are trivially managed by a set of two shell scripts. For every organizational scheme you name, I'll name you a different one with exactly the reverse tradeoffs. The only way you can at least try to cater to all of them is to avoid being dependent on the tradeoffs. dv> If you're really against the split, I'd like to hear real arguments: dv> how does it break the rationale, and why is it so bad to break it this way ? With one package, one directory you still have the *choice* whether to replicate or not, and you can address the whole replication issue independently. You spread out a package over several directories, you don't have that choice anymore. dv> On the other hand, we could maybe reach an agreement on an dv> intermediate solution, like having only one replication of the whole dv> hierarchy. For instance: dv> - put the original hierarchy under /usr/local/share/ dv> organized in the way you described, with lisp, etc, info, man subdirs, but dv> *not* lib-src, dv> - put a clone of this organization under /usr/local/lib dv> with lib-src stuff and possibly C modules Again, I don't want to mess with the high-level directory organization. I don't particularly care one way or another, and I'll let someone else sort out that particular mess. dv> Footnotes: dv> [1] Reminder: Stallmacs installs its lisp code there. Not out here it doesn't. You mean Stallmacs installs there *by default*. So what? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Tue Jul 13 12:24:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA24583 for xemacs-beta-out; Tue, 13 Jul 1999 12:24:02 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA24580 for ; Tue, 13 Jul 1999 12:24:00 -0400 Received: from metheny.enst.fr (w3zbZ5qkJEjDhsEO94kTK2gmaaohSM1X@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id SAA14424; Tue, 13 Jul 1999 18:23:59 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id SAA02580; Tue, 13 Jul 1999 18:23:55 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "13 Jul 1999 18:05:14 +0200" 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: 23 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > Again, I don't want to mess with the high-level directory > organization. I don't particularly care one way or another, and I'll > let someone else sort out that particular mess. Yes please, people, speeeak! Mickael and I know pretty well now that we disagree on this. > dv> Footnotes: > dv> [1] Reminder: Stallmacs installs its lisp code there. > > Not out here it doesn't. You mean Stallmacs installs there *by > default*. So what? So, Stallmacs does the Right Thing by default :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 13 16:10:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA14724 for xemacs-beta-out; Tue, 13 Jul 1999 16:10:23 -0400 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 QAA14717 for ; Tue, 13 Jul 1999 16:10:20 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id NAA18042; Tue, 13 Jul 1999 13:11:19 -0700 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> 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: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I was going to demo the ispell completion the other day, and it blonked at me... the error happens when there's more than a certain number of completions, and in that code, it uses a char-to-int/int-to-char conversion... it increments a char var to form the keys you push to select which completion you want to use. To repeat: In a `message' buffer, (I think the ispell complete is on by default... or maybe I have it switched on someplace?), type `hel' and push `M-Tab'. It signals an error. But `hell' `M-Tab' displays a choice list in a window at the top of the frame. From owner-xemacs-beta@xemacs.org Tue Jul 13 16:24:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA15160 for xemacs-beta-out; Tue, 13 Jul 1999 16:24:12 -0400 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 QAA15155 for ; Tue, 13 Jul 1999 16:24:10 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id NAA18062; Tue, 13 Jul 1999 13:25:07 -0700 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 18 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I would like the package specs to have, in addition to the `description' field, a `long-description' field. The reason for this is that in a Debian `control' file, there is a Description: of <= 60 characters, and then a paragraph or so of long description that goes with it. In the `dselect' tool, you see the description to the right of the packages at the top, and the long description in a pane at the bottom. Imagine if you split your XEmacs with C-x 2, and in the top window is something like the [Options | Manage Packages | List & Install], and in the bottom, when your cursor is on a package's line, the full description appears there for you to read. I've written a few of them, but there are many more needing done. I can generate a patch for yous if you would like this to become part of the packageing system. I'm trying to cook up a way to use those package descriptions to autogen debian `control' files for the package lisp. From owner-xemacs-beta@xemacs.org Tue Jul 13 16:52:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA16118 for xemacs-beta-out; Tue, 13 Jul 1999 16:52:32 -0400 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 QAA16113 for ; Tue, 13 Jul 1999 16:52:30 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id NAA18276; Tue, 13 Jul 1999 13:53:41 -0700 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 32 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> I would love to see (for the purposes of the install tool) Jan> the debian dpkg-style weaker dependencies. Also I would Jan> dearly love a list of features provided (or at least major Jan> and minor modes). For those of you interested and with a little time to read about it, if you look at: , and follow the links under "Developers' Manuals", you can read about the Debian package system. The `control' file is documented in: Those of you in the XEmacs Beta list are welcome to browse my manuals through that interface. `man2html' is the CGI program, it's reading PATHINFO to know what manual you want... the clickers inside the page ought to work if they don't... let me know. See also: dpkg-deb, debhelper, and links within. `debian/rules' is a chmod +x makefile with a shebang line at the top. It's the starting point to initiate a package build, with standard targets. `debhelper' is a set of perl script utilities for use by `debian/rules' targets. There's a searchable via .../doc/HTML/ on the same host. (bittersweet) Please don't post this URL far and wide; I'm NOT a website. It's my workstation. I guess if it gets out of hand, I'll just password the web server. For now it's open to yous though, official business. From owner-xemacs-beta@xemacs.org Tue Jul 13 16:58:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA16375 for xemacs-beta-out; Tue, 13 Jul 1999 16:58:04 -0400 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 QAA16368 for ; Tue, 13 Jul 1999 16:58:02 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id NAA18293; Tue, 13 Jul 1999 13:59:15 -0700 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: may also be of interest. This is a pre-xemacs21 way of dealing with installing Lisp for multiple emacs versions. The lisp is byte-compiled at installation time. The source is available via debian.org... it's a 20 minute read at most; probably less time than that for most of you. From owner-xemacs-beta@xemacs.org Tue Jul 13 17:24:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA17662 for xemacs-beta-out; Tue, 13 Jul 1999 17:24:40 -0400 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 RAA17657 for ; Tue, 13 Jul 1999 17:24:36 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 114A1I-0000Co-00; Tue, 13 Jul 1999 23:23:20 +0200 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: XEmacs Beta List Subject: Re: Patch: Promoting characters to 31 bits (for discussion) References: <14191.16148.740594.317309@tanko.sk.tsukuba.ac.jp> <87wvwnw6ib.fsf@pc-hrvoje.srce.hr> <14201.45837.305452.547305@tanko.sk.tsukuba.ac.jp> <879092noe1.fsf@pc-hrvoje.srce.hr> <14201.56330.797473.453866@tanko.sk.tsukuba.ac.jp> <87zp1hluao.fsf@pc-hrvoje.srce.hr> <14202.53081.998606.713318@tanko.sk.tsukuba.ac.jp> <87pv2cvnmv.fsf@pc-hrvoje.srce.hr> <14204.13982.27835.884645@tanko.sk.tsukuba.ac.jp> <87k8sj58bj.fsf@pc-hrvoje.srce.hr> <14205.46482.241668.113128@tanko.sk.tsukuba.ac.jp> <87k8shuczz.fsf@pc-hrvoje.srce.hr> <87vhbo8g48.fsf@bittersweet.sysc.pdx.edu> 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: 13 Jul 1999 23:23:19 +0200 In-Reply-To: karlheg@cathcart.sysc.pdx.edu's message of "13 Jul 1999 13:11:19 -0700" Message-ID: <87iu7okzw8.fsf@pc-hrvoje.srce.hr> Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > I was going to demo the ispell completion the other day, and it > blonked at me... the error happens when there's more than a certain > number of completions, and in that code, it uses a > char-to-int/int-to-char conversion... it increments a char var to > form the keys you push to select which completion you want to use. I don't think this has anything to do with the subject of the message. > To repeat: In a `message' buffer, (I think the ispell complete is > on by default... or maybe I have it switched on someplace?), type > `hel' and push `M-Tab'. It signals an error. Yes, it's on by default, but no, it doesn't signal an error to me. I use "ispell.el 3.0 -- Fri Mar 20 13:25:59 PST 1998". From owner-xemacs-beta@xemacs.org Tue Jul 13 17:42:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA18426 for xemacs-beta-out; Tue, 13 Jul 1999 17:42:29 -0400 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 RAA18421 for ; Tue, 13 Jul 1999 17:42:24 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id OAA18396; Tue, 13 Jul 1999 14:43:25 -0700 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 76 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Sperber writes: >>>>> "dv" == Didier Verna writes: dv> Well, we're talking about two different things here: first dv> separating architecture-dependant stuff, and secondly dv> /sharing/ what can be shared. Michael> Sure, but that's mostly a high-level organizational Michael> issue, and different systems address the issue in Michael> different ways. You cater to one, you hurt the others. dv> Here, we have a /usr/local/share[1] directory which is dv> automounted from a single machine onto the others. It's really dv> comfortable to install stuff under it, knowing that all dv> machines will immediately see it. From a sysadmin point of dv> view, installing architecture independant stuff for XEmacs dv> packages under this directory would be dv> straightforward. However, imagine the pain it would be to dv> update all machines on a site to make them mount dv> /whatever/xemacs-packages/foo-1.32/lisp each time such a dv> package is installed. Michael> I'm afraid I don't understand the point you're making. Michael> If a package contains architecture-depdendent stuff, you Michael> obviously need to install at least parts of it somewhere Michael> other than /usr/local/share if you want to preserve the Michael> integrity of your setup. I don't know if that means Michael> requiring explicit mounts, but that doesn't really Michael> matter. Why not install the whole thing somewhere else Michael> then? If you want sharing in your setup, that's what Michael> symbolic links are for. They are trivially managed by a Michael> set of two shell scripts. I think it would work best to make each of the directories a configurable option, so that the site admin or package builder can decide where to install stuff. Isn't that how things are normally done anyhow? I'd put the cross architecture shareables under .../share/..., and the binary modules under .../lib/..., perhaps by using --switches to `configure' if that exists, (with a default that follows the LHS or GNU Coding Standards filesystem layout would be best). That's what Didier is talking about, I think. Here there's /usr/share/emacs/{20.{2,3},site-lisp}/, and /usr/lib/emacs/20.3/i386-debian-linux-gnu/ from the Emacs 20 (i386) Debian package. I suppose that on a server, there could be subdirs there in lib for other architectures, and that you'd have .../arch-bin directories that get mounted on the client hosts as just .../bin. So I think there needs to be a configurable way of installing. Perhaps as root, an XEmacs site admin could run the package installer thing, after having configured site directories using `customize' widgetry, have it fetch the tarfile for per architecture, and it would unpack it someplace temporary, then move the subdirs inside it into the set locations. To make a debian package of something, I build a sub-filesystem (rooted at "$(pwd)/debian", pretending to be "/") and move the stuff into it, as if ready to form a .tar, then let the packaging tools pack that up. When somebody installs it, everything will go where it belongs, since the tarfile inside the .deb will essentially be opened from "/". What about stuff that assumes something resides in a certain location? Usually that's solved by using --prefix, --libdir, --statedir, etc. with `configure', then installing to the pseudo-root with `make PREFIX=$(pwd)/debian/tmp ... install'. This way the insides have the actually after-actual-installation paths, but the install target puts things into your staging directory. (as designed.) I hope this proves I've learned something. From owner-xemacs-beta@xemacs.org Tue Jul 13 17:50:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA18865 for xemacs-beta-out; Tue, 13 Jul 1999 17:50:58 -0400 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 RAA18861 for ; Tue, 13 Jul 1999 17:50:56 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id OAA18422; Tue, 13 Jul 1999 14:52:07 -0700 To: Jan Vroonhof Cc: debian-devel@lists.debian.org, xemacs-beta@xemacs.org Subject: Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) 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: 58 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Karl, did you miss the whole "Debian packagers do their own Jan> thing flamefest? There's only so much time in a day. I've pile of books I want to read, exercises to do in them, and I've got to eat, which means doing a job as well. Reading a flamewar isn't a high priority, sorry. >> I disagree, and will ship the package with the modification. >> Don't bother filing a bug about it... This is a minor change, >> not a hairy major code fork. It's not a meaningful political >> act, just part of the job I'm doing. Jan> No. This is a MAJOR user interface change. And frankly, I Jan> think it is _not_ part of the job you are doing. If you want Jan> to help develop XEmacs thats more than OK with me. But please Jan> use the regular channels for that and not use your position Jan> as a Debian for that. I don't think it's a major change. It's a small patch. It's not complicated. It's not extensive. >> I will, after developing something that works and looks good, >> submit patches "upstream", for certain. They will be reviewed, >> and perhaps will become part of XEmacs 21.2 or 21.3, depending >> upon timeing and whatever-it-takes. It's not a strange new >> idea. Jan> No it isn't. Including your experimental patches in a major Jan> distribution is. Even more if you are going to ignore bug Jan> reports about it. Distribution packages are not the right Jan> place to do beta testing. It's silly to expect newbies (there will be many installing the package) to edit `~/.emacs/' codes, and to maintain two branches inside of it to cope with both GNU Emacs and XEmacs. Granted, they will likely stick to one or the other, but will try both to begin with. Jan> Note that the issues here are _not_ easy to solve (you do Jan> know that what you describe was in the XEmacs betas once and Jan> was taken out again, do you?). Yes... I missed the `why' part. Why was it taken out? (I will spend a few minutes looking for that in the archive... I WILL NOT work late today. My health is more GD important than sitting here working for no income. I have studies I want to complete also.) >> At any rate... I really ought to be working on the thing >> instead of inspiring flame wars over it and wasting our >> development/study time on email. Jan> No you _need_ to spend time on email first. You _need_ to Jan> discuss the design. I will send the patch for review (to xemacs-patches); I'll try and get to it today so yous can view it. From owner-xemacs-beta@xemacs.org Tue Jul 13 18:15:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA19914 for xemacs-beta-out; Tue, 13 Jul 1999 18:15:02 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA19911 for ; Tue, 13 Jul 1999 18:14:59 -0400 Received: from corpmail2.Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04554 for ; Tue, 13 Jul 1999 15:14:54 -0700 (PDT) Received: from einstein.Corp.Sun.COM (einstein.Corp.Sun.COM [129.145.208.63]) by corpmail2.Corp.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA08036 for ; Tue, 13 Jul 1999 15:14:54 -0700 (PDT) Received: (from rajesh@localhost) by einstein.Corp.Sun.COM (8.9.3+Sun/8.9.1) id PAA20149; Tue, 13 Jul 1999 15:14:54 -0700 (PDT) Newsgroups: sun.emacs To: xemacs-beta@xemacs.org Subject: xemacs 21.2.17 on Solaris 7 64bit hangs X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.123 From: Rajesh Godbole X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# Date: 13 Jul 1999 15:14:53 -0700 Message-ID: <8t6673ofb8i.fsf@Corp.Sun.COM> Lines: 73 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: sun.emacs Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The following message is a courtesy copy of an article that has been posted to sun.emacs as well. Compiled xemacs 21.2.17 on Solaris 7 in 64bit mode using Sun Workshop 5.0. Now it occasionally hangs while trying to load cus-edit.el, So I decided to re-compile lisp files. Compilation of lisp files hangs while compiling lisp/cus-edit.el: Checking for Mule support... Yes Compiling files without .elc... /usr/local/src/gnu/xemacs/xemacs-21.2.17/src/xemacs -batch -vanilla -f batch-byte-compile lisp/./cus-edit.el lisp/./cus-face.el lisp/./cus-load.el lisp/./custom-load.el lisp/./disass.el lisp/./disp-table.el lisp/./etags.el lisp/./files-nomule.el lisp/./finder-inf.el lisp/./finder.el lisp/./font-lock.el lisp/./font-menu.el lisp/./font.el lisp/./gnuserv.el lisp/./help-macro.el lisp/./help-nomule.el lisp/./hyper-apropos.el lisp/./info.el lisp/./ldap.el lisp/./lisp-mnt.el Compiling /home/rajesh/src/gnu/xemacs/xemacs-21.2.17/lisp/cus-edit.el... Loading customization dependencies... truss shows: 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: stat("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 0xFFFFFFFF7FFF8A40) = 0 20131/1: access("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 4) = 0 20131/1: getcontext(0xFFFFFFFF7FFF88E0) Installation: uname -a: SunOS einstein 5.7 Generic_107605-02 sun4u sparc SUNW,Ultra-5_10 ./configure 'sparc-sun-solaris2' '--verbose' '--site-includes=/usr/local/include' '--site-runtime-libraries=/usr/local/lib' '--with-site-lisp=yes' '--with-workshop=yes' '--with-mule=yes' '--with-ldap=yes' '--with-sound=no' '--x-libraries=/usr/openwin/lib/sparcv9' XEmacs 21.2-b17 "Chiyoda" configured for `sparc-sun-solaris2'. Where should the build process find the source code? /home/rajesh/src/gnu/xemacs/xemacs-21.2.17 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? cc -xO3 -xtarget=ultra2i -xcache=16/32/1:256/64/1 -xarch=v9 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/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib/sparcv9 Additional header files: /usr/local/include Runtime library search path: /usr/local/lib 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 Berkeley DB. Compiling in support for DBM. Compiling in support for LDAP. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for Sun WorkShop. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL 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: --------------------------------------------------------- Any ideas where to start poking? -rajesh From owner-xemacs-beta@xemacs.org Tue Jul 13 18:21:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA20222 for xemacs-beta-out; Tue, 13 Jul 1999 18:21:16 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA20207 for ; Tue, 13 Jul 1999 18:21:09 -0400 Received: from ebaymail2.Ebay.Sun.COM ([129.150.111.20]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06776 for ; Tue, 13 Jul 1999 15:21:04 -0700 (PDT) Received: from news2me.EBay.Sun.COM (news2me.EBay.Sun.COM [129.150.111.44]) by ebaymail2.Ebay.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA20912; Tue, 13 Jul 1999 15:21:03 -0700 (PDT) Received: (from news@localhost) by news2me.EBay.Sun.COM (8.9.1b+Sun/8.9.1) id PAA02808; Tue, 13 Jul 1999 15:21:58 -0700 (PDT) To: emacs@Sun.COM X-Reflected-By: news@news2me.EBay.Sun.COM Path: news2me.EBay.Sun.COM!corpnews1.Corp.Sun.COM!not-for-mail From: Rajesh Godbole Newsgroups: sun.emacs Subject: xemacs 21.2.17 on Solaris 7 64bit hangs Date: 13 Jul 1999 15:14:53 -0700 Organization: Sun Microsystems Inc., Mountain View, CA Lines: 73 Message-ID: <8t6673ofb8i.fsf@Corp.Sun.COM> NNTP-Posting-Host: einstein.corp.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: xemacs-beta@xemacs.org X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.123 X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) Xref: news2me.EBay.Sun.COM sun.emacs:1476 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Compiled xemacs 21.2.17 on Solaris 7 in 64bit mode using Sun Workshop 5.0. Now it occasionally hangs while trying to load cus-edit.el, So I decided to re-compile lisp files. Compilation of lisp files hangs while compiling lisp/cus-edit.el: Checking for Mule support... Yes Compiling files without .elc... /usr/local/src/gnu/xemacs/xemacs-21.2.17/src/xemacs -batch -vanilla -f batch-byte-compile lisp/./cus-edit.el lisp/./cus-face.el lisp/./cus-load.el lisp/./custom-load.el lisp/./disass.el lisp/./disp-table.el lisp/./etags.el lisp/./files-nomule.el lisp/./finder-inf.el lisp/./finder.el lisp/./font-lock.el lisp/./font-menu.el lisp/./font.el lisp/./gnuserv.el lisp/./help-macro.el lisp/./help-nomule.el lisp/./hyper-apropos.el lisp/./info.el lisp/./ldap.el lisp/./lisp-mnt.el Compiling /home/rajesh/src/gnu/xemacs/xemacs-21.2.17/lisp/cus-edit.el... Loading customization dependencies... truss shows: 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: stat("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 0xFFFFFFFF7FFF8A40) = 0 20131/1: access("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 4) = 0 20131/1: getcontext(0xFFFFFFFF7FFF88E0) Installation: uname -a: SunOS einstein 5.7 Generic_107605-02 sun4u sparc SUNW,Ultra-5_10 ./configure 'sparc-sun-solaris2' '--verbose' '--site-includes=/usr/local/include' '--site-runtime-libraries=/usr/local/lib' '--with-site-lisp=yes' '--with-workshop=yes' '--with-mule=yes' '--with-ldap=yes' '--with-sound=no' '--x-libraries=/usr/openwin/lib/sparcv9' XEmacs 21.2-b17 "Chiyoda" configured for `sparc-sun-solaris2'. Where should the build process find the source code? /home/rajesh/src/gnu/xemacs/xemacs-21.2.17 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? cc -xO3 -xtarget=ultra2i -xcache=16/32/1:256/64/1 -xarch=v9 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/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib/sparcv9 Additional header files: /usr/local/include Runtime library search path: /usr/local/lib 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 Berkeley DB. Compiling in support for DBM. Compiling in support for LDAP. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for Sun WorkShop. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL 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: --------------------------------------------------------- Any ideas where to start poking? -rajesh From owner-xemacs-beta@xemacs.org Tue Jul 13 18:31:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA20554 for xemacs-beta-out; Tue, 13 Jul 1999 18:31:03 -0400 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 SAA20350 for ; Tue, 13 Jul 1999 18:24:26 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 114Axb-0000Hh-00 for ; Wed, 14 Jul 1999 00:23:35 +0200 To: XEmacs Beta List Subject: Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) References: <87g12s8bg8.fsf@bittersweet.sysc.pdx.edu> 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: 14 Jul 1999 00:23:34 +0200 In-Reply-To: karlheg@cathcart.sysc.pdx.edu's message of "13 Jul 1999 14:52:07 -0700" Message-ID: <87zp10i3yx.fsf@pc-hrvoje.srce.hr> Lines: 50 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I missed the beginning of the thread, which apparently originated at debian-devel. I assume Karl wants to re-introduce ~/.xemacs/init.el and ~/.xemacs/options.el files in the Debian version of XEmacs. karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > >> I disagree, and will ship the package with the modification. > >> Don't bother filing a bug about it... This is a minor change, > >> not a hairy major code fork. It's not a meaningful political > >> act, just part of the job I'm doing. > > Jan> No. This is a MAJOR user interface change. And frankly, I > Jan> think it is _not_ part of the job you are doing. If you want > Jan> to help develop XEmacs thats more than OK with me. But please > Jan> use the regular channels for that and not use your position > Jan> as a Debian for that. > > I don't think it's a major change. It's a small patch. It's not > complicated. Has it occurred to you that you could be wrong? If a patch is "small", it doesn't mean that its effects are negligible. Either way, it's an important *interface* change. As a matter of principle, Debian maintainers should not indulge in such things. I was kind of hoping that having a familiar (your) face for the Debian maintainer would improve things, not make them worse. > It's silly to expect newbies (there will be many installing the > package) to edit `~/.emacs/' codes, and to maintain two branches > inside of it to cope with both GNU Emacs and XEmacs. Karl, just what are you talking about? The file is named `~/.emacs', and the newbies have edited it for ages, along with the experienced users. Since when has it become "silly"? Is it a new Debian fashion that the rest of us simply can't understand? > Jan> Note that the issues here are _not_ easy to solve (you do > Jan> know that what you describe was in the XEmacs betas once and > Jan> was taken out again, do you?). > > Yes... I missed the `why' part. Why was it taken out? Partly because noone could think of a good migration path. > (I will spend a few minutes looking for that in the > archive... I WILL NOT work late today. My health is more GD > important than sitting here working for no income. Of course it is. But: if you don't have time to do the work, don't take the responsibility. Sorry. From owner-xemacs-beta@xemacs.org Tue Jul 13 21:31:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA25089 for xemacs-beta-out; Tue, 13 Jul 1999 21:31:27 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA25082 for ; Tue, 13 Jul 1999 21:31:19 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id KAA12172 for ; Wed, 14 Jul 1999 10:31:10 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) References: <87g12s8bg8.fsf@bittersweet.sysc.pdx.edu> <87zp10i3yx.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "14 Jul 1999 00:23:34 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 14 Jul 1999 10:31:07 +0900 Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: ... >> I don't think it's a major change. It's a small patch. It's not >> complicated. > Has it occurred to you that you could be wrong? I will add that some of our most bitter flame wars have been over single line patches, for example, the single line patch to screw up the delete key. ... Jan> Note that the issues here are _not_ easy to solve (you do Jan> know that what you describe was in the XEmacs betas once and Jan> was taken out again, do you?). >> >> Yes... I missed the `why' part. Why was it taken out? > Partly because noone could think of a good migration path. Exactly. We have not figured out a way to not make it suck. If you put it into Debian-XEmacs we will have the situation we have been trying to avoid -- multiple highly incompatible flavors of XEmacs. I hope we can make it work as the current situation is suboptimal, but please reconsider your decision on this. -- $B3?$N;R$O3?(B (Like father, like son) From owner-xemacs-beta@xemacs.org Tue Jul 13 22:39:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA27129 for xemacs-beta-out; Tue, 13 Jul 1999 22:39:33 -0400 Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA27126 for ; Tue, 13 Jul 1999 22:39:32 -0400 Received: from erols.com (209-122-224-26.s280.tnt3.nyw.ny.dialup.rcn.com [209.122.224.26]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id WAA20591 for ; Tue, 13 Jul 1999 22:39:28 -0400 (EDT) Message-ID: <35AAC557.AB88DA71@erols.com> Date: Mon, 13 Jul 1998 22:41:27 -0400 From: "Matthew O. Persico" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: <378AAE74.7B135933@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Michael Sperber [Mr. Preprocessor]" wrote: > > >>>>> "Matthew" == Matthew O Persico writes: > > Matthew> A lot of this looks suspiciously like perl. This is a GOOd thing. > Matthew> Larry and his crew have got packages down cold. Emulation can't > Matthew> but help. > > Oh god, what nonsense ... And why is this nonsense? It is, of course my and I probably should have explicitly stated as such. I was not suggesting that you did slavishly emulate the Perl system, nor did I suggest that you should slavishly emulate the Perl system. I was, in actuality, complementing you on the fact that either by emulation or by your original creativity and talent, you had managed to include features that are also included in what is one of the more flexible, consistent and easy to use software packaging systems in existence today, as evidenced by my personal ease of use and, more importantly, the acceptance of the scheme by the Perl community at large. > Matthew> "Michael Sperber [Mr. Preprocessor]" wrote: > >> > >> The following constraint must hold: > >> > >> Two different author versions of a package must have different > >> versions as well. > [snip] > Matthew> Hmm. Foo-1.4, Foo-1.5, etc. That may be fine for buildnig the package or > Matthew> even identifying it (a-la Perl modules), but what's going to be the > Matthew> mechanism for determining which installed Foo will be used? I say keep > Matthew> the version OUT of the final install directory structures. > > >From the draft: > > > (use-package ) > > > > This indicates a preference for a package matching the specification > > to XEmacs. This means that, in the future, no other packages with the > > same name may be used in the running XEmacs. It also has the > > side-effect of making the package's autoloads available. > Others have commented subsequently. I will let their comments speak as I have nothing else of value to add to the subject at this time. From owner-xemacs-beta@xemacs.org Wed Jul 14 00:12:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA29896 for xemacs-beta-out; Wed, 14 Jul 1999 00:12:51 -0400 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA26772 for xemacs-announce-out; Tue, 13 Jul 1999 22:26:13 -0400 Mail-Copies-To: never To: xemacs-announce@xemacs.org Subject: XEmacs 21.2.18 -- =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= is released X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 14 Jul 1999 11:01:57 +0900 Message-ID: Lines: 50 X-Mailer: Gnus v5.6.45/InfoDock 4.0.7 Reply-To: xemacs-beta@xemacs.org X-Mailing-List: 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/ I am having connectivity problems again with cvs, hopefully it is just the Japanese phone company again and it will be fixed soon. New XEmacs lisp packages have been uploaded as well. The new Sumos are in: ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz New and highly-changed packages include lookup (a very cool Japanese dictionary front end), new mailcrypt with gpg support, ps-print-nomule (a forked old version of ps-print, but one that still works with XEmacs/noMule). egg-its has some major bug fixes. calendar now supports Japanese calendars. "Toshima" is a ward of Tokyo where the Sunshine Namjatown theme park is. The English descriptions of the rides were done by someone who does not speak English and some very interesting translations are made. For example, the Katori Daisakusen[1] ride has the description: "Save the district from huge mosquitoes that were bred in vast quantities! Ride an unglazed pig and kill mosquitoes with a spray gun." 21.2.19 "name TBD, maybe Shinjuku" is tentatively scheduled for Friday, but will probably end up being some time early next week. There is more InfoDock synchage to do, and 21.2.19 will definitely come after InfoDock 4.0.8. to 21.2.18 "Toshima" -- miscellaneous fixes from Steve Baur -- miscellaneous fixes from Didier Verna -- various bug fixes from Karl Hegbloom -- miscellaneous fixes from Bob Weiner -- fix for XIM server crashing and taking down XEmacs from Kazuyuki IENAGA -- valid-image-instantiator-format-p tightened up by Andy Piper. -- glyph widget support under X/Motif from Andy Piper -- Make docdir configurable, update package searching rules from Michael Sperber -- Fix for Japanese word/character movements from MORIOKA Tomohiko -- lrecord struct header size fix from Olivier Galibert Footnotes: [1] This is left untranslated in the English guide. -- $BU{$r$R$C$F?,:u$a(B (It's useless to close the barn door after the horse has left) From owner-xemacs-beta@xemacs.org Wed Jul 14 03:14:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA01822 for xemacs-beta-out; Wed, 14 Jul 1999 03:14:16 -0400 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 DAA01817 for ; Wed, 14 Jul 1999 03:14:13 -0400 Received: from brabantio.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 JAA14252 for ; Wed, 14 Jul 1999 09:14:12 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id JAA21684; Wed, 14 Jul 1999 09:14:09 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 14 Jul 1999 09:14:09 +0200 In-Reply-To: Didier Verna's message of "13 Jul 1999 18:23:55 +0200" Message-ID: Lines: 38 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 DAA01819 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Again, I don't want to mess with the high-level directory >> organization. I don't particularly care one way or another, and I'll >> let someone else sort out that particular mess. dv> Yes please, people, speeeak! Mickael and I know pretty well now that dv> we disagree on this. Didier, I think there's a big misunderstanding here: Sure, I disagree with you. But that's mainly because our software installation setup is different from yours, and the present scheme fits ours pretty well. I don't think that it makes much of a difference which setup we choose, which is why I believe we might just as well leave it unchanged. I won't change it. If you want to change it, go ahead. As long as it doesn't hurt anyone more than it does currently, I won't be in your way. The root of all evil here is, of course, once again, hierarchical file systems which hopefully will be among the first things against the wall when the revolution comes (along with syntax tables, read-time macros and a few other things). Given that noone really bothered since the days of Unix, we better use what we have. Please let me design the package system in such a way that it doesn't need to care about these issues. If you want granularity, put packages wherever your high-levels setup tells you to. If you get duplication that way but want sharing, use links. That's precisely what they've been designed for. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 14 05:07:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04638 for xemacs-beta-out; Wed, 14 Jul 1999 05:07:46 -0400 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 FAA04629 for ; Wed, 14 Jul 1999 05:07:29 -0400 Received: from brabantio.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 LAA19124 for ; Wed, 14 Jul 1999 11:07:11 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id LAA29586; Wed, 14 Jul 1999 11:07:09 +0200 To: xemacs-beta@xemacs.org Subject: 21.2.18 failure 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: 14 Jul 1999 11:07:08 +0200 Message-ID: Lines: 14 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 FAA04636 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Anyone else seeing this? Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/symbols.c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) This is AIX 4.2.1, egcs 1.1.2. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 14 05:12:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA04728 for xemacs-beta-out; Wed, 14 Jul 1999 05:12:35 -0400 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 FAA04723 for ; Wed, 14 Jul 1999 05:12:34 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA24698 for ; Wed, 14 Jul 1999 11:12:33 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0061s; Wed Jul 14 11:12:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA01671; Wed, 14 Jul 1999 11:12:30 +0200 To: xemacs-beta@xemacs.org Subject: Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) References: <87g12s8bg8.fsf@bittersweet.sysc.pdx.edu> <87zp10i3yx.fsf@pc-hrvoje.srce.hr> From: Jan Vroonhof Date: 14 Jul 1999 11:12:29 +0200 In-Reply-To: Hrvoje Niksic's message of "14 Jul 1999 00:23:34 +0200" 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: Hrvoje Niksic writes: > > Yes... I missed the `why' part. Why was it taken out? > > Partly because noone could think of a good migration path. ..in the time available for 21.0. I think I have a good way to solve the custom issues, it needs implementing _and testing_. Jan From owner-xemacs-beta@xemacs.org Wed Jul 14 05:50:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA05650 for xemacs-beta-out; Wed, 14 Jul 1999 05:50:39 -0400 Received: from smtp1.mindspring.com (smtp1.mindspring.com [207.69.200.31]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA05647 for ; Wed, 14 Jul 1999 05:50:38 -0400 Received: from sparrow.bear.com (user-2ive1cc.dialup.mindspring.com [165.247.5.140]) by smtp1.mindspring.com (8.8.5/8.8.5) with ESMTP id FAA28700; Wed, 14 Jul 1999 05:50:36 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id FAA22569; Wed, 14 Jul 1999 05:50:42 -0400 Date: Wed, 14 Jul 1999 09:50:42 +0000 ( ) From: Justin Vallon To: Didier Verna cc: XEmacs Beta Subject: Re: New package system design draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 13 Jul 1999, Didier Verna wrote: > Pete Ware writes: > > > Can one share package directories across machines and architectures > > (cf. etc/) > > That's a good point. Perhaps the most important argument against > having all files related to a package under a single directory. There's > already a problem with the lib-src subdir, and will be another one when we > start having packages with C modules in them. > > It would really be a pity not to fix this problem in the Great Package > Overhaul. The fact is that most of the packages subdir already exist in the > GNU Coding Standards. > > - etc, info, man exist. > - lisp should go under .../share > - lib-src actually belongs to libexec. > - lib could then be used for C modules. > > So I think instead of having a single directory for a particular > package, we could replicate this hierarchy under all needed standard > directories, with the same naming policy. Or, keep the package self-contained, and move the subdirectories into the package, ala /opt/foo/etc /opt/foo/lib /opt/foo/share. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Wed Jul 14 08:32:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA08993 for xemacs-beta-out; Wed, 14 Jul 1999 08:32:32 -0400 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 IAA08983 for ; Wed, 14 Jul 1999 08:32:02 -0400 Received: by avon.delcam.com; Wed, 14 Jul 1999 13:25:54 +0100 (BST) Received: by pat.delcam.com; Wed, 14 Jul 1999 13:32:45 +0100 (BST) Received: by dr2.delcam.com; Wed, 14 Jul 1999 13:32:47 +0100 From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14220.33647.174054.198020@pub.news.uk.psi.net> Date: Wed, 14 Jul 1999 13:32:47 +0100 (BST) To: xemacs-beta@xemacs.org Subject: Seg fault building 21.2 b18 on IRIX 6.2 X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid X-Face: "+N/{>9S5,OIk<0$%[)LGd} I CVS updated everything and got the following build error: EMACSBOOTSTRAPLOADPATH="/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/:/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k" EMACSBOOTSTRAPMODULEPATH="/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../modules/:/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k" ./temacs -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Segmentation fault make[1]: *** [update-elc.stamp] Error 139 make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 You have mail in /usr/mail/peb dr2% gdb src/temacs GNU gdb 19990519 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 "mips-sgi-irix6.2"... (gdb) run -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Starting program: /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src/temacs -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Program received signal SIGSEGV, Segmentation fault. strlen () at strlen.s:58 58 strlen.s: No such file or directory. Current language: auto; currently asm (gdb) bt #0 strlen () at strlen.s:58 #1 0x6ac134 in intern (str=0x0) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/symbols.c:585 #2 0x6b3f8c in defsubr (subr=0x100cd330) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/symbols.c:3404 #3 0x6933a4 in syms_of_select () at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/select.c:487 #4 0x4c3008 in xemacs_21_2_b18_mips_sgi_irix6_2 (argc=4, argv=0x7fff2f24, envp=0x7fff2f38, restart=0) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:2033 #5 0x4c4c74 in main (argc=4, argv=0x7fff2f24, envp=0x7fff2f38) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:2945 (gdb) quit The program is running. Exit anyway? (y or n) y -- 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 Jul 14 09:19:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA10494 for xemacs-beta-out; Wed, 14 Jul 1999 09:19:01 -0400 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 JAA10272 for ; Wed, 14 Jul 1999 09:15:17 -0400 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 PAA314564; Wed, 14 Jul 1999 15:12:03 +0200 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay01.de.ibm.com (8.8.7m1/NCO v2.03) with SMTP id PAA46514; Wed, 14 Jul 1999 15:13:26 +0200 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id C12567AE.0048A1FA ; Wed, 14 Jul 1999 15:13:20 +0200 X-Lotus-FromDomain: IBMDE To: sperber@informatik.uni-tuebingen.de, xemacs-beta@xemacs.org Message-ID: Date: Wed, 14 Jul 1999 15:12:58 +0200 Subject: Re: 21.2.18 failure Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=gDPQ3eFsr7G266ZXDsBHYe1Ld9VmjKWKFs83YLmmsS554w7s22uhYBX0" Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --0__=gDPQ3eFsr7G266ZXDsBHYe1Ld9VmjKWKFs83YLmmsS554w7s22uhYBX0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Not exactly the same, but something similar: Loading select.el...Fatal error: assertion failed, file symbols.c, line 1783, abort() make: The signal code from the last command is 6. Stop. Compilation exited abnormally with code 2 at Wed Jul 14 15:03:12 This is AIX 4.3.2 and IBM xlC 3.6.4. --- Markus Alt IBM Laboratory Boeblingen, Germany sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) on 07/14/99 11:07:08 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: 21.2.18 failure --0__=gDPQ3eFsr7G266ZXDsBHYe1Ld9VmjKWKFs83YLmmsS554w7s22uhYBX0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable Anyone else seeing this? Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/sym= bols .c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) This is AIX 4.2.1, egcs 1.1.2. -- Cheers =3D8-} Chipsy Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla = --0__=gDPQ3eFsr7G266ZXDsBHYe1Ld9VmjKWKFs83YLmmsS554w7s22uhYBX0-- From owner-xemacs-beta@xemacs.org Wed Jul 14 09:58:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA12423 for xemacs-beta-out; Wed, 14 Jul 1999 09:58:05 -0400 Received: from piinbh1.ms.com (piinbh1.ms.com [199.89.64.71]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA12420 for ; Wed, 14 Jul 1999 09:58:03 -0400 Received: (from uucp@localhost) by piinbh1.ms.com (8.8.6/fw v1.22) id JAA15954 for ; Wed, 14 Jul 1999 09:58:02 -0400 (EDT) Received: from unknown(144.14.9.190) by piinbh1.ms.com via smap (4.1) id xma015478; Wed, 14 Jul 99 09:57:28 -0400 Received: from sag3 (sag3.morgan.com [144.14.8.198]) by safid1.morgan.com (8.8.5/hub+ldap v2.3) with ESMTP id JAA07556 for ; Wed, 14 Jul 1999 09:57:28 -0400 (EDT) Received: (craffert@localhost) by sag3 (980427.SGI.8.8.8/sendmail.cf.client v1.05) id JAA37222; Wed, 14 Jul 1999 09:57:27 -0400 (EDT) To: XEmacs Beta List Subject: Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released Keywords: cvs,xemacs,org,hobbes,rtelnet,connection Mail-Copies-To: never X-Attribution: > References: X-Face: D>:hrrB{l6#\wU;)0R:OHSTA@ayd.Oq?s@Rrc;[+z0m+<-U"$G-J6L)F2QY`qK~uPu!s1(6{\#uy!Ag/D)?'L[}xErXvxoPn8T_hKi{M]/(`BF{e}X7;hby`p\.E$rJ}Aff#BT,rdDIw\y X-Y-Zippy: Half a mind is a terrible thing to waste! From: Colin Rafferty Date: 14 Jul 1999 09:57:27 -0400 In-Reply-To: SL Baur's message of "14 Jul 1999 11:01:57 +0900" Message-ID: Lines: 30 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id JAA12421 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > Get it from the usual places: > ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ > http://cvs.xemacs.org/ > I am having connectivity problems again with cvs, hopefully it is just > the Japanese phone company again and it will be fixed soon. Not just you. I've been getting this for a week: hobbes $ cvs update cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused hobbes $ rtelnet cvs.xemacs.org Trying 208.25.65.6... Connected to cvs.xemacs.org. Escape character is '^]'. BSDI BSD/OS 3.0 (camelot-soft.camelot-soft.com) (ttyp0) login: q rtelnet> Connection closed. hobbes $ rtelnet cvs.xemacs.org 2410 Trying 208.25.65.6... telnet: Unable to connect to remote host: Connection refused hobbes $ -- Colin From owner-xemacs-beta@xemacs.org Wed Jul 14 10:09:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA12801 for xemacs-beta-out; Wed, 14 Jul 1999 10:09:51 -0400 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 KAA12796 for ; Wed, 14 Jul 1999 10:09:48 -0400 Received: from brabantio.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 QAA14982 for ; Wed, 14 Jul 1999 16:09:46 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id QAA20262; Wed, 14 Jul 1999 16:09:42 +0200 To: XEmacs Beta List Subject: Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 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: 14 Jul 1999 16:09:42 +0200 In-Reply-To: Colin Rafferty's message of "14 Jul 1999 09:57:27 -0400" 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 KAA12797 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Colin" == Colin Rafferty writes: Colin> SL Baur writes: >> Get it from the usual places: >> ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ >> http://cvs.xemacs.org/ >> I am having connectivity problems again with cvs, hopefully it is just >> the Japanese phone company again and it will be fixed soon. Colin> Not just you. I've been getting this for a week: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused Seems to me your cvs pserver port is wrong; it's 2401, not 2410. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 14 10:15:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA13153 for xemacs-beta-out; Wed, 14 Jul 1999 10:15:55 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA13126 for ; Wed, 14 Jul 1999 10:15:43 -0400 Received: from metheny.enst.fr (ERUYL2S5UxxyhZXDKmvI+zCZwsjqObDf@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id QAA22775; Wed, 14 Jul 1999 16:15:41 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id QAA03463; Wed, 14 Jul 1999 16:15:39 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "14 Jul 1999 09:14:09 +0200" 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: 68 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > Didier, I think there's a big misunderstanding here: Sure, I disagree > with you. But that's mainly because our software installation setup > is different from yours, and the present scheme fits ours pretty well. I'd understood this. You'd understood that it doesn't fit mine. > I don't think that it makes much of a difference which setup we > choose, which is why I believe we might just as well leave it > unchanged. I beleive it makes a difference and that's why I'm arguing about this. > I won't change it. If you want to change it, go ahead. As long as it > doesn't hurt anyone more than it does currently, I won't be in your way. > [...] > Please let me design the package system in such a way that it doesn't > need to care about these issues. That's disapointing as well as worrying to hear that. It sounds like you're closed to any discussion on this just because it is a problem (or a feature) you just don't want to care about. But you're designing the whole thing again and it's gonna have a very important impact on the future of XEmacs. What I'm trying to do is only addressing a problem which I find important *before* the new design is actually implemented, even if I'm not the one who's implementing it. I don't feel like changing anything after you. I feel like designing things the Right Way before hacking them. Please note that I'm probably never going to use the package stuff as it will be designed (appart from at home which is a single machine anyway). I've got everything locally under my account on my site because I'm always up to date. So I'm not arguing for my personal taste. I just want all problems addressed. I can't understand how one can justify his choices in such an important redesign process with arguments like "because the present scheme fits our setup pretty well". Damn, you're working for everybody. > If you want granularity, put packages wherever your high-levels setup tells > you to. If you get duplication that way but want sharing, use links. That's > precisely what they've been designed for. Again, I'm sorry, but no way. This is like doing consciously something wrong first, and then reparing the damage afterwards. I'm not ready to make dozens of symlinks even if it's automatized in any fashion. Look, I don't think you've provided any concrete argument against mine yet: say we have here some share/ and lib/ directory. My share/ directory happens to be automounted on all machines. Not yours, perhaps you don't even have one. Now please, tell me /exactly/ how installing the packages, some part under share/, and some other under lib/ would break your setup ? What would it break appart from your personal taste ? I don't see how it could do any harm, but I see how it would simplify the life of many people. You know, I'm still open minded on this. We could find intermediate solutions. For example, it would be ok with me to have all stuff under /usr/local/xemacs, and then having /one/ share/ subdir under which all packages would put their sharable stuff. Doing one symlink, once for all, would be acceptable. But please, don't say things like "I won't change it". We're in the design phase. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Wed Jul 14 10:25:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA13712 for xemacs-beta-out; Wed, 14 Jul 1999 10:25:38 -0400 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 KAA13708 for ; Wed, 14 Jul 1999 10:25:36 -0400 Received: (from uucp@localhost) by hqinbh2.ms.com (8.8.6/fw v1.30) id KAA09108 for ; Wed, 14 Jul 1999 10:25:33 -0400 (EDT) Received: from unknown(144.14.9.190) by hqinbh2 via smap (4.1) id xma009037; Wed, 14 Jul 99 10:25:11 -0400 Received: from sag3 (sag3.morgan.com [144.14.8.198]) by safid1.morgan.com (8.8.5/hub+ldap v2.3) with ESMTP id KAA08861 for ; Wed, 14 Jul 1999 10:25:10 -0400 (EDT) Received: (craffert@localhost) by sag3 (980427.SGI.8.8.8/sendmail.cf.client v1.05) id KAA37211; Wed, 14 Jul 1999 10:25:08 -0400 (EDT) To: XEmacs Beta List Subject: Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released Keywords: cvs Mail-Copies-To: never X-Attribution: > References: X-Face: ""xJff%{>hr-{:QXl"Xk2O@@(+F]e{"%EYQiW@mUuvEsL>=mx96j12qW[%m;|:B^n{J8k?Mz[K1_+H;$v,nYx^1o_=4M,L+]FIU~[[`-w~~xsy-BX,?tAF_.8u&0y*@aCv;a}Y'{w@#*@iwAl?oZpvvv X-Y-Zippy: I think I'll do BOTH if I can get RESIDUALS!! From: Colin Rafferty Date: 14 Jul 1999 10:25:08 -0400 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "14 Jul 1999 16:09:42 +0200" Message-ID: Lines: 17 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber writes: >>>>>> "Colin" == Colin Rafferty writes: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused > Seems to me your cvs pserver port is wrong; it's 2401, not 2410. Good point. So I have no control over cvs at my job. Do you happen to know how I can change the port from the command line (or .cvsrc or .cvspass or ...)? Thanks. -- Colin From owner-xemacs-beta@xemacs.org Wed Jul 14 10:37:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA14127 for xemacs-beta-out; Wed, 14 Jul 1999 10:37:19 -0400 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 KAA14123 for ; Wed, 14 Jul 1999 10:37:12 -0400 Received: from brabantio.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 QAA14268 for ; Wed, 14 Jul 1999 16:37:08 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id QAA29734; Wed, 14 Jul 1999 16:37:05 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: 14 Jul 1999 16:37:05 +0200 In-Reply-To: Didier Verna's message of "14 Jul 1999 16:15:37 +0200" Message-ID: Lines: 77 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 KAA14125 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Didier, I think there's a big misunderstanding here: Sure, I disagree >> with you. But that's mainly because our software installation setup >> is different from yours, and the present scheme fits ours pretty well. dv> [...] You'd understood that it doesn't fit mine. Ah! No, I hadn't. Please explain why. dv> That's disapointing as well as worrying to hear that. It sounds like dv> you're closed to any discussion on this just because it is a problem (or a dv> feature) you just don't want to care about. I don't even see your problem yet. I think it's wrong to intermingle the design issues concerning the package layout with the global issues of XEmacs directory layout. If you make one depend on the other, it's much harder to make local changes. I want to be working on the package system, not the global directory layout. For the directory layout issues, I don't stand a chance against you, and I don't want to. Moreover (and please acknowledge this, Didier), there are software setups *other* than yours (notably, ours) where hard-wiring what you're suggesting is going to royally fuck things up. At the file system level, a package constitutes a collection of files that belong together. With hierarchical file systems, the *only* way to reflect "togetherness" (as well as "apartness" from other packages, say) is to put those files into a common subdirectory which is not a subdirectory containing other packages. This has a number of advantages, two being ease of installation and un-installation as well as an easy-to-satisfy integrity criterion. The latter point is especially important since I can check package integrity *locally*, and it's pretty hard to violate it without seeing what you're doing. Once the package is spread out as you suggest, installation is still easy enough, but suddenly, if I want to uninstall or move or ship a package, I have to remember where all its bits are. If I forget some of them, there's no guarantee the system will *ever* notice that fact. dv> Again, I'm sorry, but no way. This is like doing consciously something dv> wrong first, and then reparing the damage afterwards. I'm not ready to make dv> dozens of symlinks even if it's automatized in any fashion. Well, so there. I'm not ready to spread packages over disparate portions of the hierarchy. Seriously, links *are* Unix's native mechanism for expressing sharing. You may not like it, but it's the only thing there is. They're not exactly a neat design, but they're excruciatingly easy to manage automatically. Yet another solution for achieving maximum sharing without links is to factor the architecture-specific portions of a larger packages into packages of their own. This makes sense for staging reasons as well. Stick the architecture-independent bit into a shared package hierarchy, and the architecture-specific bit into one conditionalized on architecture. dv> But please, don't say things like "I won't change it". I never said that. How come you claim this? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 14 10:44:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA14533 for xemacs-beta-out; Wed, 14 Jul 1999 10:44:43 -0400 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 KAA14521 for ; Wed, 14 Jul 1999 10:44:41 -0400 Received: from brabantio.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 QAA20206 for ; Wed, 14 Jul 1999 16:44:37 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id QAA30434; Wed, 14 Jul 1999 16:44:35 +0200 To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 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: 14 Jul 1999 16:44:29 +0200 In-Reply-To: Colin Rafferty's message of "14 Jul 1999 10:25:08 -0400" 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 KAA14526 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Colin" == Colin Rafferty writes: Colin> Michael Sperber writes: >>>>>>> "Colin" == Colin Rafferty writes: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused >> Seems to me your cvs pserver port is wrong; it's 2401, not 2410. Colin> Good point. Colin> So I have no control over cvs at my job. More likely, it's the cvspserver entry in /etc/services or the services map. 2410 is definitely *wrong* and should be fixed. Colin> Do you happen to know how I can change the port from the Colin> command line (or .cvsrc or .cvspass or ...)? You can't. Your best bet is probably to recompile CVS yourself. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 14 10:52:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA14934 for xemacs-beta-out; Wed, 14 Jul 1999 10:52:55 -0400 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 KAA14929 for ; Wed, 14 Jul 1999 10:52:53 -0400 Received: (from karl@localhost) by beaver.jprc.com (8.8.7/8.8.7) id KAA22414; Wed, 14 Jul 1999 10:52:54 -0400 To: xemacs-beta@xemacs.org Subject: 21.2.18 SEGV failure -- null frame pointer 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: 14 Jul 1999 10:52:54 -0400 Message-ID: Lines: 101 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: 21.2.18 built and installed fine under Linux, but I've gotten a couple of these this morning already. I always attach gdb to my XEmacs which runs Gnus. I have the core, but the core's stack (being post- continuation after death-dealing signal) shows only the final __kill() and fatal_error_signal() stack frames. Thoughts on what might be wrong here? Program received signal SIGSEGV, Segmentation fault. x_to_emacs_keysym (event=0x7ffff528, simple_p=0) at frame.h:248 248 assert (EQ (FRAME_TYPE (f), sym)); (gdb) bt #0 x_to_emacs_keysym (event=0x7ffff528, simple_p=0) at frame.h:248 #1 0x81a9468 in x_event_to_emacs_event (x_event=0x7ffff528, emacs_event=0x8be9ad4) at event-Xt.c:999 #2 0x81ab6c7 in emacs_Xt_event_handler (wid=0x85a0718, closure=0x0, event=0x7ffff528, continue_to_dispatch=0x7ffff463 "\001pö1\b,") at event-Xt.c:2472 #3 0x2ab9cc9f in XtDispatchEventToWidget () #4 0x2ab9d6fd in _XtDefaultDispatcher () #5 0x2ab9d975 in XtDispatchEvent () #6 0x2aba83d5 in XtAppProcessEvent () #7 0x81abe33 in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:2628 #8 0x80d954d in detect_input_pending () at event-stream.c:945 #9 0x80dba9d in Fnext_event (event=142911672, prompt=137112340) at event-stream.c:2237 #10 0x807330e in Fcommand_loop_1 () at cmdloop.c:569 #11 0x807309d in command_loop_1 (dummy=137112340) at cmdloop.c:493 #12 0x8091741 in condition_case_1 (handlers=137112436, bfun=0x807304c , barg=137112340, hfun=0x80724d0 , harg=137112340) at eval.c:1640 #13 0x8073538 in command_loop_2 (dummy=137112340) at cmdloop.c:255 #14 0x809131c in internal_catch (tag=137186628, func=0x8073504 , arg=137112340, threw=0x0) at eval.c:1315 #15 0x8072937 in initial_command_loop (load_me=137112340) at cmdloop.c:304 #16 0x808cf5d in xemacs_21_2_b18_i686_pc_linux (argc=5, argv=0x7ffff9b4, envp=0x7ffff9cc, restart=0) at emacs.c:1759 #17 0x808d6e9 in main (argc=5, argv=0x7ffff9b4, envp=0x7ffff9cc) at emacs.c:2184 (gdb) list 243 INLINE struct frame * 244 error_check_frame_type (struct frame * f, Lisp_Object sym); 245 INLINE struct frame * 246 error_check_frame_type (struct frame * f, Lisp_Object sym) 247 { 248 assert (EQ (FRAME_TYPE (f), sym)); 249 return f; 250 } 251 # define FRAME_TYPE_DATA(f, type) \ 252 ((struct type##_frame *) (error_check_frame_type (f, Q##type))->frame_data) (gdb) p f $1 = (struct frame *) 0x0 System is RedHat 5.2. Installation file: uname -a: Linux beaver.jprc.com 2.2.10-ac10 #1 SMP Tue Jul 13 13:23:27 EDT 1999 i686 unknown ./configure '--with-pop' '--with-mule' '--with-png' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-linux'. Where should the build process find the source code? /home/karl/src/x/xemacs-21/xemacs-21.2.18 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 dialog boxes. Compiling in DLL 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 Jul 14 11:02:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA15386 for xemacs-beta-out; Wed, 14 Jul 1999 11:02:14 -0400 Received: from calvin.tor.onramp.ca (calvin.tor.onramp.ca [204.225.88.15]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA15378 for ; Wed, 14 Jul 1999 11:02:11 -0400 Received: (qmail 29793 invoked from network); 14 Jul 1999 15:02:03 -0000 Received: from imail.hgeng.com (HELO bart.hgeng.com) (199.246.72.233) by mail.onramp.ca with SMTP; 14 Jul 1999 15:02:03 -0000 Received: by BART with Internet Mail Service (5.5.2232.9) id <3VVHD9ZR>; Wed, 14 Jul 1999 10:30:24 -0400 Message-ID: From: Mike Hill To: "'xemacs-build-reports@xemacs.org'" , xemacs-beta@xemacs.org Subject: [Success] 21.2 (beta18) "Toshima" XEmacs Lucid on i686-pc-cygwin 32 Date: Wed, 14 Jul 1999 10:30:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >From CVS, edited event-msw.c to reflect Andy's cygwin b19 fix from b17. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /binary/xemacs-21.2/Installation: > (Output from most recent run of ./configure) uname -a: CYGWIN32_NT DILBERT 4.0 19.4 i686 unknown ./configure '--package-path=/binary/xemacs-20' '--site-includes=/usr/local/include' '--cflags=-O2' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-cygwin32'. Where should the build process find the source code? /binary/xemacs-21.2 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 -O2 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? default What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6.3/include Where do we find X Windows libraries? /usr/X11R6.3/lib Additional header files: /usr/local/include 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 GNU DBM. Compiling in support for ncurses. Compiling in File coding support. Compiling in EXPERIMENTAL support for Drag'n'Drop ( msw ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena 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: --------------------------------------------------------- > /binary/xemacs-21.2/beta.err does not exist! From owner-xemacs-beta@xemacs.org Wed Jul 14 11:15:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA15753 for xemacs-beta-out; Wed, 14 Jul 1999 11:15:17 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA15744 for ; Wed, 14 Jul 1999 11:15:08 -0400 Received: from metheny.enst.fr (+wMk5NhLlGhfFIkZRekrwwTaeSDfhTAK@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id RAA24841; Wed, 14 Jul 1999 17:15:06 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id RAA03512; Wed, 14 Jul 1999 17:15:04 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "14 Jul 1999 16:37:05 +0200" 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: 55 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > dv> [...] You'd understood that it doesn't fit mine. > > Ah! No, I hadn't. Please explain why. Because, as I've already explained, I already have network-ally shared standard directories, that your design won't use and it's a shame because I would have to make the concerned packages directories sharable by hand (or script) each time a new package appears. > I don't even see your problem yet. See above. > Moreover (and please acknowledge this, Didier), there are software yes > setups *other* than yours (notably, ours) where hard-wiring what > you're suggesting is going to royally fuck things up. Please explain precisely why and how. > Once the package is spread out as you suggest, installation is still > easy enough, but suddenly, if I want to uninstall or move or ship a > package, I have to remember where all its bits are. You told me to use scripts to make my links, so I tell you to use scripts to uninstall. Moreover, remembering to look in *two* places, like share/ and lib/, is not that much to remember I think. > Seriously, links *are* Unix's native mechanism for expressing sharing. > You may not like it, but it's the only thing there is. There are NFS, automount ... > dv> But please, don't say things like "I won't change it". > > I never said that. How come you claim this? First paragraph, 6th line of your message ;-) : . But I've just reread it, and I might have misinterpreted it: you were probably talking about your system setup, not the package design, sorry... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Wed Jul 14 11:21:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA16061 for xemacs-beta-out; Wed, 14 Jul 1999 11:21:13 -0400 Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA16057 for ; Wed, 14 Jul 1999 11:21:11 -0400 Received: (from tor@localhost) by pallas.spacetec.no (8.9.1a/8.9.1) id RAA16723 for xemacs-beta@xemacs.org; Wed, 14 Jul 1999 17:21:11 +0200 Message-Id: <199907141521.RAA16723@pallas.spacetec.no> From: tor@spacetec.no (Tor Arntsen) Date: Wed, 14 Jul 1999 17:21:11 +0200 In-Reply-To: Colin Rafferty "Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released" (Jul 14, 16:14) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: XEmacs Beta List Subject: Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Jul 14, 16:14, Colin Rafferty wrote: >Good point. > >So I have no control over cvs at my job. Do you happen to know how I >can change the port from the command line (or .cvsrc or .cvspass or ...)? You can't if you have a standard cvs, it's hardcoded (so somebody changed a #define and recompiled cvs if it's using 2410 instead of 2401). There are patches around which will let you define other ports as part of CVS/Root or -d strings, but that won't help you unless the cvs at your job are using those patches (the syntax also depends on exactly which patches are used). What you probably *could* do is to make a simple proxy (perlscript or something) that will accept 2410 on localhost and redirect to 2401 on cvs.xemacs.org, and then use cvs -d localhost:/ -Tor From owner-xemacs-beta@xemacs.org Wed Jul 14 11:30:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA16411 for xemacs-beta-out; Wed, 14 Jul 1999 11:30:14 -0400 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 LAA16407 for ; Wed, 14 Jul 1999 11:30:09 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA28447 for ; Wed, 14 Jul 1999 17:30:02 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006wP; Wed Jul 14 17:29:58 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA02779; Wed, 14 Jul 1999 17:29:58 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: Date: 14 Jul 1999 17:29:57 +0200 In-Reply-To: Didier Verna's message of "14 Jul 1999 17:15:03 +0200" 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: Didier Verna writes: > Because, as I've already explained, I already have network-ally shared > standard directories, that your design won't use and it's a shame because I > would have to make the concerned packages directories sharable by hand (or > script) each time a new package appears. Why are share/.../lib-src//.. directories not shareable. You need more space on the server and you cannot have your usr/share file system mounted noexec, but apart from that? Jan From owner-xemacs-beta@xemacs.org Wed Jul 14 13:09:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA19714 for xemacs-beta-out; Wed, 14 Jul 1999 13:09:31 -0400 Received: from hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA19711 for ; Wed, 14 Jul 1999 13:09:29 -0400 Received: from nbecker by hns.com with local (Exim 3.02 #1) id 114SX2-0000Hn-00 for xemacs-beta@xemacs.org; Wed, 14 Jul 1999 13:09:20 -0400 To: xemacs-beta@xemacs.org Subject: [success] 21.2.18 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 14 Jul 1999 13:09:20 -0400 Message-ID: Lines: 39 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I forget - how am I supposed to create and mail these reports? uname -a: Linux nbeckerpc.hns.com 2.2.10 #14 Wed Jul 7 08:45:55 EDT 1999 i686 unknown ../../xemacs-21/configure '--error-checking=none' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21 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 ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. From owner-xemacs-beta@xemacs.org Wed Jul 14 14:14:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA21619 for xemacs-beta-out; Wed, 14 Jul 1999 14:14:53 -0400 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 OAA21615 for ; Wed, 14 Jul 1999 14:14:51 -0400 Received: (from karl@localhost) by beaver.jprc.com (8.8.7/8.8.7) id OAA23008; Wed, 14 Jul 1999 14:14:51 -0400 To: xemacs-beta@xemacs.org Subject: Re: [success] 21.2.18 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: 14 Jul 1999 14:14:51 -0400 In-Reply-To: nbecker@fred.net's message of "14 Jul 1999 13:09:20 -0400" Message-ID: Lines: 5 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > I forget - how am I supposed to create and mail these reports? M-x load-library RET build-report RET M-x build-report RET From owner-xemacs-beta@xemacs.org Wed Jul 14 15:30:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA24023 for xemacs-beta-out; Wed, 14 Jul 1999 15:30:33 -0400 Received: from exchange1.primus.com (mail.primus.com [206.253.199.54]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA23852; Wed, 14 Jul 1999 15:26:49 -0400 Received: by exchange1.primus.com with Internet Mail Service (5.5.2448.0) id <3ZQ4XZ3A>; Wed, 14 Jul 1999 12:24:25 -0700 Message-ID: <228F2F40E87CD211ABA20008C7B13C5A17DD89@exchange1.primus.com> From: Damon Lipparelli To: "'xemacs-nt@xemacs.org'" , "'xemacs-beta@xemacs.org'" Subject: Packages under WinNT Date: Wed, 14 Jul 1999 12:24:23 -0700 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: I'm trying to figure out what should work with respect to updating packages under WinNT (native). Is this supposed to work? Without messing with efs-tmp-name-template, I'm able to update the package list. But, when a new package file is pulled down there appears to be a problem with how temporary file names are generated. For example, when I try to update APEL to version 1.13, the file apel-1.13-pkg.tar.gz is pulled down, but rather than being put into "C:\TEMP\apel-1.13-pkg.tar.gz", a file called "C:\TEMPapel-1.13-pkg.tar.gz" is created; package update fails pretty quickly with that. Is this a problem in EFS? A problem with how names are concatenated together under the native WinNT build? A problem in my configuration? Thanks for any info, -lipp From owner-xemacs-beta@xemacs.org Wed Jul 14 16:00:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA24931 for xemacs-beta-out; Wed, 14 Jul 1999 16:00:04 -0400 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 QAA24925 for ; Wed, 14 Jul 1999 16:00:01 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id NAA21354; Wed, 14 Jul 1999 13:01:16 -0700 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.1.4 (Arches) is released 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: 2 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: :-) From owner-xemacs-beta@xemacs.org Wed Jul 14 21:55:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA02114 for xemacs-beta-out; Wed, 14 Jul 1999 21:55:23 -0400 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 VAA02110 for ; Wed, 14 Jul 1999 21:55:19 -0400 Received: by crystal.WonderWorks.COM id QQgxxf11514; Wed, 14 Jul 1999 18:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14221.16256.59946.167193@crystal.WonderWorks.COM> Date: Wed, 14 Jul 1999 18:55:11 -0700 (PDT) From: Kyle Jones To: Bob Weiner , xemacs-beta@xemacs.org Subject: Re: Doc string patch for XEmacs/InfoDock. In-Reply-To: References: <199905122220.PAA04933@surf.altrasoft.com> X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: Seems to me all you need is a function that converts a float into the (high . low) form Emacs wants. Then feed that to format-time-string. Or format-time-string can be made to accept a float and do the conversion to time_t internally. Using floats to represent integral values seems to lose accuracy somewhere above 9e15 on my 486 box, which gives us 285 million more years before we need worry again. I will make a note to remind you then. SL Baur writes: > I agree. Comments? > > Bob Weiner writes: > > >> It would be really nice if format-time-string could take this format > >> (date in seconds since 1970) as an input and output a formatted date > >> from it. > > > Said another way, the emacs_strftime should be converted to a Lisp subr and > > the system type `time_t' should be made into a Lisp type with easy back and > > forth conversion operators where needed. Then we'd have pretty much native > > UNIX time handling. Right now, I can't see a clear way to convert a given > > UNIX time to a formatted date. > > > Bob > > > -- > $BF,1#$7$F?,1#$5$:(B From owner-xemacs-beta@xemacs.org Thu Jul 15 00:05:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA07459 for xemacs-beta-out; Thu, 15 Jul 1999 00:05:23 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA07456 for ; Thu, 15 Jul 1999 00:05:19 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA19190; Thu, 15 Jul 1999 13:05:10 +0900 (JST) To: "Robin S. Socha" Cc: xemacs-beta@xemacs.org Subject: Re: [OK] 21.2 (beta18) "Toshima" XEmacs Lucid on i386-unknown-freebsd3.2 References: <199907142137.VAA07462@hellfire.socha.net> X-Attribution: sb From: SL Baur In-Reply-To: "Robin S. Socha"'s message of "Wed, 14 Jul 1999 21:37:11 GMT" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 15 Jul 1999 13:05:06 +0900 Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Of the folks who are getting a coredump instead of a binary, only Paul Biblio has sent in his configuration (hint, hint). I have built about five or six different flavors of 21.2.18 on Solaris 2.6, DEC OSF 4.0 and TurboLinux without a problem, though I have not yet built without Mule. Robin S Socha writes on xemacs-build-reports: Thanks for the report, Robin. > Patched up from previous, got the following but no problems ;-) >> XEmacs Build Report as generated-------------------------- > |Index: XEmacs/xemacs/etc/TUTORIAL.ru > |diff -u XEmacs/xemacs/etc/TUTORIAL.ru:1.1 > XEmacs/xemacs/etc/TUTORIAL.ru:1.1.2.1 > |--- XEmacs/xemacs/etc/TUTORIAL.ru:1.1 Thu Jul 9 19:48:58 1998 > |+++ XEmacs/xemacs/etc/TUTORIAL.ru Tue Jul 6 00:33:00 1999 > -------------------------- > Patching file xemacs/etc/TUTORIAL.ru using Plan A... > patch: **** malformed patch at line 5654: \ No newline at end of file Sorry, unfortunately there is no good way to patch screwups like that. >> by build-report-version 1.35 follows: >> Contents of /usr/src/XEmacs/xemacs/Installation: >> (Output from most recent run of ./configure) > uname -a: FreeBSD hellfire.socha.net 3.2-RELEASE FreeBSD 3.2-RELEASE #1: Tue Jul 13 17:20:45 GMT 1999 root@hadschi.rhrz.uni-bonn.de:/usr/src/sys/compile/HELLFIRE i386 > ./configure '--site-libraries=/usr/local/lib' '--site-includes=/usr/local/include' '--with-xim=no' '--with-offix' Yours is the first Unix build report sans-Mule that is a success. -- $B?M4VK|;v:I2'$,GO(B (Inscrutable are the ways of heaven) From owner-xemacs-beta@xemacs.org Thu Jul 15 03:11:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA11079 for xemacs-beta-out; Thu, 15 Jul 1999 03:11:38 -0400 Received: from letterman.synergetic.de (letterman.synergetic.de [194.97.149.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA11074; Thu, 15 Jul 1999 03:11:28 -0400 Received: from zaphod.snafu.de (root@dpool150.webart.de [195.30.14.190]) by letterman.synergetic.de (8.8.8/8.8.7) with ESMTP id JAA02422; Thu, 15 Jul 1999 09:10:40 +0200 Received: (from khaberz@localhost) by zaphod.snafu.de (8.8.8/8.8.8) id JAA06021; Thu, 15 Jul 1999 09:08:34 +0200 To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: [OK] 21.2 (beta18) "Toshima" XEmacs Lucid on i386-unknown-freebsd3.2 References: <199907142137.VAA07462@hellfire.socha.net> From: Kai Haberzettl Date: 15 Jul 1999 09:08:33 +0200 In-Reply-To: SL Baur's message of "15 Jul 1999 13:05:06 +0900" Message-ID: Lines: 54 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: [...] > Yours is the first Unix build report sans-Mule that is a success. Here's another one. No problems. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) glibc 2.0.7pre6 uname -a: Linux zaphod 2.2.10 #19 Tue Jul 13 20:01:02 CEST 1999 i586 unknown ./configure '--cflags=-mpentium -O4' '--with-toolbars=no' '--with-mule=no' '--with-offix=yes' '--with-scrollbars=motif' '--with-dialogs=motif' '--prefix=/opt/xemacs' XEmacs 21.2-b18 "Toshima" configured for `i586-pc-linux'. Where should the build process find the source code? /home/khaberz/sources/xemacs/xemacs-beta/xemacs What installation prefix should install use? /opt/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 -mpentium -O4 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 OffiX. Compiling in EXPERIMENTAL support for Drag'n'Drop ( OffiX ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Motif scrollbars. Using Motif dialog boxes. Compiling in DLL 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 Thu Jul 15 03:33:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA11615 for xemacs-beta-out; Thu, 15 Jul 1999 03:33:24 -0400 Received: from smtp3.mindspring.com (smtp3.mindspring.com [207.69.200.33]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA11611 for ; Thu, 15 Jul 1999 03:33:22 -0400 Received: from sparrow.bear.com (user-2ive0ai.dialup.mindspring.com [165.247.1.82]) by smtp3.mindspring.com (8.8.5/8.8.5) with ESMTP id DAA23641; Thu, 15 Jul 1999 03:33:20 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id BAA02809; Thu, 15 Jul 1999 01:41:32 -0400 Date: Thu, 15 Jul 1999 05:41:31 +0000 ( ) From: Justin Vallon To: "Michael Sperber [Mr. Preprocessor]" cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 14 Jul 1999, Michael Sperber [Mr. Preprocessor] wrote: > Yet another solution for achieving maximum sharing without links is to > factor the architecture-specific portions of a larger packages into > packages of their own. This makes sense for staging reasons as well. > Stick the architecture-independent bit into a shared package > hierarchy, and the architecture-specific bit into one conditionalized > on architecture. Foo.noarch, Foo.ppc, Foo.i386, Foo.solaris. That sounds interesting. That also addresses the issue where I only have ppc, and I only want/need to install ppc+noarch. Or, globally share noarch, but arch-specific ppc and solaris sitting on two different NFS volumes, or locally. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Thu Jul 15 03:47:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA12003 for xemacs-beta-out; Thu, 15 Jul 1999 03:47:02 -0400 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 DAA12000 for ; Thu, 15 Jul 1999 03:46:57 -0400 Received: from brabantio.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 JAA13514 for ; Thu, 15 Jul 1999 09:46:53 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id JAA23440; Thu, 15 Jul 1999 09:46:51 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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 Jul 1999 09:46:51 +0200 In-Reply-To: Didier Verna's message of "14 Jul 1999 17:15:03 +0200" Message-ID: Lines: 97 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA12001 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> [...] You'd understood that it doesn't fit mine. >> >> Ah! No, I hadn't. Please explain why. dv> Because, as I've already explained, I already have network-ally shared dv> standard directories, that your design won't use and it's a shame because I dv> would have to make the concerned packages directories sharable by hand (or dv> script) each time a new package appears. That's not the case. You need (well, "may want" is probably a better term) to do this only when a package appears which has both an architecture-dependent portion and a sizeable architecture-independent portion. I believe the number of these so far is <5, a small percentage of the existing packages anyway. *You* don't necessarily need to do anything in that case, the package installer can take care of that transparently. Moreover, if we organize the packages right (namely by making packages fit tightly around their architecture-dependent portion, which makes sense in other ways as well), you kan keep the number of these packages close to zero. dv> Please explain precisely why and how. In a Unix software installation, you have several keys upon which to index them, among them: - architecture - package - package component (documentation, binaries, etc.) - version - availability ... Given a hierarchical file system, you need to assign these to depths in your installation hierarchy. This means that there's an ordering of these criteria. However, this ordering is not a natural property of these keys---you'd rather want a database where each of these have equal precedence. The GNU standards impose one such ordering by having (I may be wrong since we don't use it) a share/ hierarchy and a lib/ or libexec/ hierarchy, deep underneath which lie the architecture-dependent portions. At least emacs-20.3 has, by default, the following architecture-specific portions in its hierarchy: bin/ libexec/emacs/20.3/ This means that the architecture-specific parts of Emacs are spread over two different hierarchies. It would make plenty of sense, however, to mount the architecture-specific portions of a software package only on the machines of that particular architecture. (In fact, at least he popular AMD automounter has native support for that kind of thing.) The GNU standards make that next to impossible, requiring at least one additional mountpoint per package. We happen to have an installation where architecture is the primary key (i.e. it's at depth 0 in the hierarchy). Needless to say, packages using the GNU standard do not cooperate too well with it. >> Once the package is spread out as you suggest, installation is still >> easy enough, but suddenly, if I want to uninstall or move or ship a >> package, I have to remember where all its bits are. dv> You told me to use scripts to make my links, so I tell you to use dv> scripts to uninstall. Moreover, remembering to look in *two* places, like dv> share/ and lib/, is not that much to remember I think. There are more than two places: You get one additional place per architecture, if you do this right. >> Seriously, links *are* Unix's native mechanism for expressing sharing. >> You may not like it, but it's the only thing there is. dv> There are NFS, automount ... NFS is far from a "native mechanism" for Unix. It doesn't implement Unix filesystem semantics (or any semantics, for that matter), and automounting is far from standardized. It doesn't run on my Unix box, for instance. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 03:49:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA12128 for xemacs-beta-out; Thu, 15 Jul 1999 03:49:53 -0400 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 DAA12123 for ; Thu, 15 Jul 1999 03:49:48 -0400 Received: from brabantio.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 JAA15580 for ; Thu, 15 Jul 1999 09:49:32 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id JAA27030; Thu, 15 Jul 1999 09:49:31 +0200 To: xemacs-beta@xemacs.org Subject: Re: 21.2.18 failure 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 Jul 1999 09:49:30 +0200 In-Reply-To: sperber@Informatik.Uni-Tuebingen.De's message of "14 Jul 1999 11:07:08 +0200" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA12126 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Moiself" == Michael Sperber writes: Moiself> Anyone else seeing this? Moiself> Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/symbols.c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) Moiself> make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) Moiself> This is AIX 4.2.1, egcs 1.1.2. Hmm, this is some kind of dependency problem, it seems. After I recompiled from scratch (i.e., in a totally virgin compilation directory), things were fine. Sorry about that, and maybe a hint for others. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 04:11:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA13064 for xemacs-beta-out; Thu, 15 Jul 1999 04:11:34 -0400 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 EAA13049 for ; Thu, 15 Jul 1999 04:11:09 -0400 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 RAA09983; Thu, 15 Jul 1999 17:10:10 +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 RAA08417; Thu, 15 Jul 1999 17:10:09 +0900 (JST) Received: (from ienaga@localhost) by skywalk.jsys.co.jp (8.9.3/3.7W) id RAA16291; Thu, 15 Jul 1999 17:11:19 +0900 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: 21.2.18 failure References: MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII From: Kazuyuki IENAGA Date: 15 Jul 1999 17:11:19 +0900 In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "15 Jul 1999 09:49:30 +0200") Message-ID: Lines: 17 User-Agent: Semi-gnus/6.10.12 X-Face: 8USaCFc~lusX>!w&WSKn|Y>{Xn3WCwoV[9?YtJcat&+&H{7'`-2#q,@WbK$2h?^E~KEcxb2 ccau$twWn%fCVrpm7`eA > Moiself> Anyone else seeing this? > > Moiself> Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/symbols.c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) > Moiself> make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) > > Moiself> This is AIX 4.2.1, egcs 1.1.2. > > Hmm, this is some kind of dependency problem, it seems. After I > recompiled from scratch (i.e., in a totally virgin compilation > directory), things were fine. Sorry about that, and maybe a hint for > others. Yes, I got same problem when I was building 21.2.18 just typing `make'. After I did `make beta', I've been having no problem on my linux box. -- kazz From owner-xemacs-beta@xemacs.org Thu Jul 15 04:27:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA13648 for xemacs-beta-out; Thu, 15 Jul 1999 04:27:00 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA13637 for ; Thu, 15 Jul 1999 04:26:57 -0400 Received: from metheny.enst.fr (wifbb4Y6MDoYZom7VVbKEGxuSkEYAZpG@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id KAA23286; Thu, 15 Jul 1999 10:26:54 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id KAA04296; Thu, 15 Jul 1999 10:26:51 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "15 Jul 1999 09:46:51 +0200" 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: 36 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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 GNU standards impose one such ordering by having (I may be wrong since > we don't use it) a share/ hierarchy and a lib/ or libexec/ hierarchy, deep > underneath which lie the architecture-dependent portions. I think this is a misinterpretation (see below), but I also may be wrong. > At least emacs-20.3 has, by default, the following > architecture-specific portions in its hierarchy: > bin/ > libexec/emacs/20.3/ > This means that the architecture-specific parts of Emacs are spread > over two different hierarchies. It would make plenty of sense, > however, to mount the architecture-specific portions of a software > package only on the machines of that particular architecture. Sure. Actually, I'm surprised that GNU Emacs has this layout. What we do here is having /usr/local/bin and /usr/local/lib[exec] shared by all identical machines. emacs-20.3 would then install in /usr/local/bin and /usr/local/libexec/emacs/20.3/ and you're done for all these machines. If you want to compile it for other architectures, you just do it on another machine, or cross-compile and install through the /net filesystem. You see that I don't have to add any mountpoints or whatever. All directories needed to be shared are already there. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 15 05:05:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA14571 for xemacs-beta-out; Thu, 15 Jul 1999 05:05:39 -0400 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 FAA14566 for ; Thu, 15 Jul 1999 05:05:34 -0400 Received: from brabantio.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 LAA13410 for ; Thu, 15 Jul 1999 11:05:26 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id LAA23454; Thu, 15 Jul 1999 11:05:24 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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 Jul 1999 11:05:24 +0200 In-Reply-To: Didier Verna's message of "15 Jul 1999 10:26:50 +0200" Message-ID: Lines: 61 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA14569 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> At least emacs-20.3 has, by default, the following >> architecture-specific portions in its hierarchy: >> bin/ >> libexec/emacs/20.3/ >> This means that the architecture-specific parts of Emacs are spread >> over two different hierarchies. It would make plenty of sense, >> however, to mount the architecture-specific portions of a software >> package only on the machines of that particular architecture. dv> Sure. Actually, I'm surprised that GNU Emacs has this layout. What we dv> do here is having /usr/local/bin and /usr/local/lib[exec] shared by all dv> identical machines. emacs-20.3 would then install in /usr/local/bin and dv> /usr/local/libexec/emacs/20.3/ and you're done for all these dv> machines. If you want to compile it for other architectures, you just do it on dv> another machine, or cross-compile and install through the /net filesystem. dv> You see that I don't have to add any mountpoints or whatever. All dv> directories needed to be shared are already there. But now you're making the assumption that machines of different architectures see different contents in the same directory (or rather, a different directory of the same name). This suggests consistency where there is none. (At least the system can't enforce or even check it.) Moreover, with filesystems more modern than NFS, you typically don't even have that choice, because the filesystems guarantees (or can at least check) that different contents => different directory name. There's a difference between not seeing something not intended for you and seeing something else in its place. Note also that now uninstalling a package is a real bitch since there potentially isn't even a machine that sees all the bits of it, at least definitely not in the obvious places. Furthermore (getting to the package system question), the solution to use with this layout is to have one package hierarchy under share/ (or whatever), and one under libexec/, conditionalized on architecture. If you want sharing of architecture-independent portions of fundamentally architecture-dependent packages (as I argued, an unlikely and at least rare situation), well that's where links come in. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 05:25:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA15197 for xemacs-beta-out; Thu, 15 Jul 1999 05:25:01 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA15194 for ; Thu, 15 Jul 1999 05:24:58 -0400 Received: from metheny.enst.fr (JkrdHP0eVBdkntS5vNw92ZegmcGXhNUe@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA25588; Thu, 15 Jul 1999 11:24:57 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA04344; Thu, 15 Jul 1999 11:24:54 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "15 Jul 1999 11:05:24 +0200" 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: 34 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > But now you're making the assumption that machines of different > architectures see different contents in the same directory (or rather, > a different directory of the same name). yes. > This suggests consistency where there is none. (At least the system can't > enforce or even check it.) Actually, it can because for instance the other /usr/local/libexec directories are visible through an indirect path like /net/the_other_machine/usr/local/libexec. > Note also that now uninstalling a package is a real bitch since there > potentially isn't even a machine that sees all the bits of it, at > least definitely not in the obvious places. Not in the obvious places, right. However, when you install a package that needs compiling on different architectures, you'll make the compilation twice, once on each architecture. It's not much more difficult to uninstall twice. I admit you can reach an inconsistent state if for instance you uninstall only on one machine. In that case, you'll have removed the share/ part for all architectures, but not all the libexec/ parts. That's the sysadmin's fault though. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 15 05:29:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA15344 for xemacs-beta-out; Thu, 15 Jul 1999 05:29:37 -0400 Received: from hands.niss.ac.uk (hands.niss.ac.uk [138.38.32.116]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA15336; Thu, 15 Jul 1999 05:29:32 -0400 Received: from feet.niss.ac.uk ([193.63.76.162] helo=gristle.niss.ac.uk) by hands.niss.ac.uk with esmtp (Exim 2.12 #1) id 114hrg-0004xs-00; Thu, 15 Jul 1999 10:31:40 +0100 Received: from ccsnjd by gristle.niss.ac.uk with local (Exim 2.12 #1) id 114hq8-0005SZ-00; Thu, 15 Jul 1999 10:30:04 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14221.43548.584969.140831@gristle.niss.ac.uk> Date: Thu, 15 Jul 1999 10:30:04 +0100 (BST) To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: [OK] 21.2 (beta18) "Toshima" XEmacs Lucid on i386-unknown-freebsd3.2 In-Reply-To: References: <199907142137.VAA07462@hellfire.socha.net> X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Organisation: NISS X-URL: http://www.bath.ac.uk/~ccsnjd X-Cabaret-Voltaire-URL: http://www.brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote on 15-July-1999: ->Of the folks who are getting a coredump instead of a binary, only Paul ->Biblio has sent in his configuration (hint, hint). I have built about ->five or six different flavors of 21.2.18 on Solaris 2.6, DEC OSF 4.0 ->and TurboLinux without a problem, though I have not yet built without ->Mule. -> ->Thanks for the report, Robin. ->Yours is the first Unix build report sans-Mule that is a success. I just posted my RH5.2 one to xemacs-build-reports. I'd have done it sooner, but it appears that I no longer understand how packages work. nic -- Dr N.J.Doye, Systems Programmer, CHEST and NISS Centre, University of Bath, Claverton Down, Bath, Somerset. BA2 7AY. England From owner-xemacs-beta@xemacs.org Thu Jul 15 05:40:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA15806 for xemacs-beta-out; Thu, 15 Jul 1999 05:40:41 -0400 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 FAA15798 for ; Thu, 15 Jul 1999 05:40:35 -0400 Received: from brabantio.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 LAA13520 for ; Thu, 15 Jul 1999 11:40:33 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id LAA28182; Thu, 15 Jul 1999 11:40:31 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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 Jul 1999 11:40:31 +0200 In-Reply-To: Didier Verna's message of "15 Jul 1999 11:24:54 +0200" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA15803 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> [...] However, when you install a package dv> that needs compiling on different architectures, you'll make the compilation dv> twice, once on each architecture. It's not much more difficult to uninstall dv> twice. I admit you can reach an inconsistent state if for instance you dv> uninstall only on one machine. In that case, you'll have removed the share/ dv> part for all architectures, but not all the libexec/ parts. That's the dv> sysadmin's fault though. Well, sure. Sysadmins make mistakes. Have I addressed your problem? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 05:46:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA15985 for xemacs-beta-out; Thu, 15 Jul 1999 05:46:53 -0400 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 FAA15979 for ; Thu, 15 Jul 1999 05:46:19 -0400 From: ALTMARK@de.ibm.com Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA346594; Thu, 15 Jul 1999 11:45:18 +0200 Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1]) by d12relay02.de.ibm.com (8.8.8m2/NCO v2.03) with SMTP id LAA76048; Thu, 15 Jul 1999 11:46:15 +0200 Received: by d12mta09.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id C12567AF.0035AA43 ; Thu, 15 Jul 1999 11:46:09 +0200 X-Lotus-FromDomain: IBMDE To: sperber@informatik.uni-tuebingen.de, xemacs-beta@xemacs.org Message-ID: Date: Thu, 15 Jul 1999 11:45:23 +0200 Subject: Re: 21.2.18 failure Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=lUJc3iUKuGoG7iZkxVBbSjqAgrMqgE4f6OOdz0SZG2YWtcXPmwo6gtZa" Content-Disposition: inline Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --0__=lUJc3iUKuGoG7iZkxVBbSjqAgrMqgE4f6OOdz0SZG2YWtcXPmwo6gtZa Content-type: text/plain; charset=us-ascii Content-Disposition: inline You're right - after starting from scratch (unpacking distribution &applying patches), it worked fine. But I still wonder why I didn't see this problem with earlier versions. I unpacked the distribution for 21.2.15 and afterwards applied patches and built for 21.2.16, 21.2.17 and 21.2.18 resp. - for 16 and 17 it was ok, but not for 18 ... (?) --- Markus Alt IBM Laboratory Boeblingen, Germany sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) on 07/15/99 09:49:30 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: 21.2.18 failure --0__=lUJc3iUKuGoG7iZkxVBbSjqAgrMqgE4f6OOdz0SZG2YWtcXPmwo6gtZa Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable >>>>> "Moiself" =3D=3D Michael Sperber writes: Moiself> Anyone else seeing this? Moiself> Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/sym= bols .c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) Moiself> make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) Moiself> This is AIX 4.2.1, egcs 1.1.2. Hmm, this is some kind of dependency problem, it seems. After I recompiled from scratch (i.e., in a totally virgin compilation directory), things were fine. Sorry about that, and maybe a hint for others. -- Cheers =3D8-} Chipsy Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla = --0__=lUJc3iUKuGoG7iZkxVBbSjqAgrMqgE4f6OOdz0SZG2YWtcXPmwo6gtZa-- From owner-xemacs-beta@xemacs.org Thu Jul 15 05:51:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA16074 for xemacs-beta-out; Thu, 15 Jul 1999 05:51:53 -0400 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 FAA16071 for ; Thu, 15 Jul 1999 05:51:50 -0400 Received: by avon.delcam.com; Thu, 15 Jul 1999 10:45:48 +0100 (BST) Received: by pat.delcam.com; Thu, 15 Jul 1999 10:52:41 +0100 (BST) Received: by dr2.delcam.com; Thu, 15 Jul 1999 10:52:42 +0100 From: Paul Bibilo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14221.44906.434236.370754@pub.news.uk.psi.net> Date: Thu, 15 Jul 1999 10:52:42 +0100 (BST) To: xemacs-beta@xemacs.org Subject: Re: [OK] 21.2 (beta18) "Toshima" XEmacs Lucid on i386-unknown-freebsd3.2 In-Reply-To: nic@niss.ac.uk's messaage of Thursday 15 July 1999 10:30:04 References: <199907142137.VAA07462@hellfire.socha.net> <14221.43548.584969.140831@gristle.niss.ac.uk> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid X-Face: "+N/{>9S5,OIk<0$%[)LGd} > SL Baur wrote on 15-July-1999: > > ->Of the folks who are getting a coredump instead of a binary, only Paul > ->Biblio has sent in his configuration (hint, hint). I have built about > ->five or six different flavors of 21.2.18 on Solaris 2.6, DEC OSF 4.0 > ->and TurboLinux without a problem, though I have not yet built without > ->Mule. > -> > OK, I've rebuilt Toshima doing a make beta rather than just make, and it built just fine. I've sent a build report. Sorry if I wasted anybody's time yesterday. -- Paul From owner-xemacs-beta@xemacs.org Thu Jul 15 05:53:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA16115 for xemacs-beta-out; Thu, 15 Jul 1999 05:53:24 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA16111 for ; Thu, 15 Jul 1999 05:53:22 -0400 Received: from metheny.enst.fr (D2cpi2irJWV2nokhmSTOV3+Mn3TqEC2F@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA26642; Thu, 15 Jul 1999 11:53:21 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA04368; Thu, 15 Jul 1999 11:53:18 +0200 (MET DST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: New package system design draft 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: sperber@informatik.uni-tuebingen.de's message of "15 Jul 1999 11:40:31 +0200" 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: 11 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Chiyoda) 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: > Have I addressed your problem? Well, let's say that I understand your point of view better now. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 15 08:00:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18019 for xemacs-beta-out; Thu, 15 Jul 1999 08:00:06 -0400 Received: from hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA18013; Thu, 15 Jul 1999 08:00:01 -0400 Received: from nbecker by hns.com with local (Exim 3.02 #1) id 114kBD-0000eY-00; Thu, 15 Jul 1999 07:59:59 -0400 To: SL Baur Cc: "Robin S. Socha" , xemacs-beta@xemacs.org Subject: Re: [OK] 21.2 (beta18) "Toshima" XEmacs Lucid on i386-unknown-freebsd3.2 References: <199907142137.VAA07462@hellfire.socha.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 15 Jul 1999 07:59:56 -0400 In-Reply-To: SL Baur's message of "15 Jul 1999 13:05:06 +0900" Message-ID: Lines: 1 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I already reported a success on i686-pc-linux-gnu. I did make clean first. From owner-xemacs-beta@xemacs.org Thu Jul 15 08:18:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA18343 for xemacs-beta-out; Thu, 15 Jul 1999 08:18:01 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA18318; Thu, 15 Jul 1999 08:17:13 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 15 Jul 1999 13:15:25 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id <31H70HMC>; Thu, 15 Jul 1999 13:00:20 +0100 Message-Id: From: Ian MacKinnon To: "'Xemacs NT List'" , "'Xemacs Mailing List'" Subject: Failure with 21.2.18 cygnus Date: Thu, 15 Jul 1999 13:00:19 +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: Hi all I am having problems with my build of b18 this is on NT with cygwin b20 The configure/make/install process works OK, but then when I try and run xemacs can't find any packages (I have sumo installed in /usr/local/lib/xemacs/packages) I haven't changed anything else here (I think) Any one else seeing anything like this ie load-path contains `load-path' is a simple built-in variable. Value: ("/usr/xemacs-21.2.18/lisp/" "/usr/xemacs-21.2.18/lisp/mule/" "/usr/xemacs-21.2.18/lisp/term/") {early,late}-package-load-path are both nil Installation looks like :- uname -a: CYGWIN_NT-4.0 TECH007 21.0 (0.9/1/2) 1999-2-16 00:11:59 i686 unknown ./configure '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-cygwin32'. Where should the build process find the source code? /usr/xemacs-21.2.18 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? 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 support for GNU DBM. Compiling in support for ncurses. Compiling in File coding support. Compiling in EXPERIMENTAL support for Drag'n'Drop ( msw ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena 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: --------------------------------------------------------- --- Ian ************************************************************* 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 Thu Jul 15 08:53:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA19401 for xemacs-beta-out; Thu, 15 Jul 1999 08:53:27 -0400 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 IAA19368 for ; Thu, 15 Jul 1999 08:53:04 -0400 Received: from brabantio.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 OAA15582 for ; Thu, 15 Jul 1999 14:52:52 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id OAA28340; Thu, 15 Jul 1999 14:52:50 +0200 To: xemacs-beta@xemacs.org Subject: Re: Failure with 21.2.18 cygnus 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 Jul 1999 14:52:50 +0200 In-Reply-To: Ian MacKinnon's message of "Thu, 15 Jul 1999 13:00:19 +0100" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id IAA19398 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Ian" == Ian MacKinnon writes: Ian> Hi all Ian> I am having problems with my build of b18 Ian> this is on NT with cygwin b20 Ian> The configure/make/install process works OK, but then when I try and run Ian> xemacs can't find any packages Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) Ian> I haven't changed anything else here (I think) Ian> Any one else seeing anything like this Ian> ie load-path contains Ian> `load-path' is a simple built-in variable. Ian> Value: ("/usr/xemacs-21.2.18/lisp/" "/usr/xemacs-21.2.18/lisp/mule/" Ian> "/usr/xemacs-21.2.18/lisp/term/") Ian> {early,late}-package-load-path are both nil What's the value of `configure-prefix-directory'? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 09:33:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA20874 for xemacs-beta-out; Thu, 15 Jul 1999 09:33:01 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA20870 for ; Thu, 15 Jul 1999 09:32:59 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 15 Jul 1999 14:31:12 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id <31H70H3Z>; Thu, 15 Jul 1999 14:16:08 +0100 Message-Id: From: Ian MacKinnon To: xemacs-beta@xemacs.org Subject: RE: Failure with 21.2.18 cygnus Date: Thu, 15 Jul 1999 14:16:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.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 JAA20871 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > -----Original Message----- > From: sperber@informatik.uni-tuebingen.de > [mailto:sperber@informatik.uni-tuebingen.de] > Sent: 15 July 1999 13:53 > To: xemacs-beta@xemacs.org > Subject: Re: Failure with 21.2.18 cygnus > > > >>>>> "Ian" == Ian MacKinnon writes: > > Ian> Hi all > Ian> I am having problems with my build of b18 > Ian> this is on NT with cygwin b20 > Ian> The configure/make/install process works OK, but then > when I try and run > Ian> xemacs can't find any packages > Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) > Ian> I haven't changed anything else here (I think) > > Ian> Any one else seeing anything like this > > Ian> ie load-path contains > > Ian> `load-path' is a simple built-in variable. > > Ian> Value: ("/usr/xemacs-21.2.18/lisp/" > "/usr/xemacs-21.2.18/lisp/mule/" > Ian> "/usr/xemacs-21.2.18/lisp/term/") > > > > Ian> {early,late}-package-load-path are both nil > > What's the value of `configure-prefix-directory'? > `configure-prefix-directory' is a simple built-in variable. Value: "/usr/local/" > -- > Cheers =8-} Chipsy > Friede, Völkerverständigung und überhaupt blabla > -- Ian ************************************************************* 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 Thu Jul 15 10:34:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA22871 for xemacs-beta-out; Thu, 15 Jul 1999 10:34:02 -0400 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 KAA22806 for ; Thu, 15 Jul 1999 10:32:10 -0400 Received: from brabantio.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 QAA10522 for ; Thu, 15 Jul 1999 16:32:08 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id QAA23698; Thu, 15 Jul 1999 16:32:06 +0200 To: xemacs-beta@xemacs.org Subject: Re: Failure with 21.2.18 cygnus 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 Jul 1999 16:32:06 +0200 In-Reply-To: Ian MacKinnon's message of "Thu, 15 Jul 1999 14:16:07 +0100" Message-ID: Lines: 34 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA22868 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Forget what I wrote. >>>>> "Ian" == Ian MacKinnon writes: >> -----Original Message----- >> From: sperber@informatik.uni-tuebingen.de >> [mailto:sperber@informatik.uni-tuebingen.de] >> Sent: 15 July 1999 13:53 >> To: xemacs-beta@xemacs.org >> Subject: Re: Failure with 21.2.18 cygnus >> >> >> >>>>> "Ian" == Ian MacKinnon writes: >> Ian> Hi all Ian> I am having problems with my build of b18 Ian> this is on NT with cygwin b20 Ian> The configure/make/install process works OK, but then >> when I try and run Ian> xemacs can't find any packages Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) ^^^^^^^^ This is wrong. It's supposed to be `xemacs-packages.' -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 15 10:59:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA23665 for xemacs-beta-out; Thu, 15 Jul 1999 10:59:31 -0400 Received: from hands.niss.ac.uk (hands.niss.ac.uk [138.38.32.116]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA23662 for ; Thu, 15 Jul 1999 10:59:29 -0400 Received: from feet.niss.ac.uk ([193.63.76.162] helo=gristle.niss.ac.uk) by hands.niss.ac.uk with esmtp (Exim 2.12 #1) id 114n0v-00071F-00; Thu, 15 Jul 1999 16:01:33 +0100 Received: from ccsnjd by gristle.niss.ac.uk with local (Exim 2.12 #1) id 114mzO-0005WJ-00; Thu, 15 Jul 1999 15:59:58 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14221.63342.968365.70332@gristle.niss.ac.uk> Date: Thu, 15 Jul 1999 15:59:58 +0100 (BST) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org Subject: Re: Failure with 21.2.18 cygnus In-Reply-To: References: X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Organisation: NISS X-URL: http://www.bath.ac.uk/~ccsnjd X-Cabaret-Voltaire-URL: http://www.brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote on 15-July-1999: ->Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) -> ^^^^^^^^ -> ->This is wrong. It's supposed to be `xemacs-packages.' If anyone cares, this is the exact same problem I had when I upgraded from 21.2.17 to 21.2.18 - a close read of http://www.xemacs.org/packages/guide.html solved it for me. nic From owner-xemacs-beta@xemacs.org Thu Jul 15 11:29:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA25085 for xemacs-beta-out; Thu, 15 Jul 1999 11:29:57 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA25081 for ; Thu, 15 Jul 1999 11:29:55 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 15 Jul 1999 16:28:11 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id <31H70HT3>; Thu, 15 Jul 1999 16:13:06 +0100 Message-Id: From: Ian MacKinnon To: "'sperber@informatik.uni-tuebingen.de'" , xemacs-beta@xemacs.org Subject: RE: Failure with 21.2.18 cygnus Date: Thu, 15 Jul 1999 16:13:06 +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: > -----Original Message----- > From: sperber@informatik.uni-tuebingen.de > [mailto:sperber@informatik.uni-tuebingen.de] > Sent: 15 July 1999 15:32 > To: xemacs-beta@xemacs.org > Subject: Re: Failure with 21.2.18 cygnus > > > > Forget what I wrote. > > >>>>> "Ian" == Ian MacKinnon writes: > > >> -----Original Message----- > >> From: sperber@informatik.uni-tuebingen.de > >> [mailto:sperber@informatik.uni-tuebingen.de] > >> Sent: 15 July 1999 13:53 > >> To: xemacs-beta@xemacs.org > >> Subject: Re: Failure with 21.2.18 cygnus > >> > >> > >> >>>>> "Ian" == Ian MacKinnon writes: > >> > Ian> Hi all > Ian> I am having problems with my build of b18 > Ian> this is on NT with cygwin b20 > Ian> The configure/make/install process works OK, but then > >> when I try and run > Ian> xemacs can't find any packages > Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) > ^^^^^^^^ > > This is wrong. It's supposed to be `xemacs-packages.' > OK I've changed this to xemacs-packages, and it now works So the only question is why did it work before on previous betas thanks for your help -- Ian ************************************************************* 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 Thu Jul 15 12:09:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA26707 for xemacs-beta-out; Thu, 15 Jul 1999 12:09:35 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA26704 for ; Thu, 15 Jul 1999 12:09:32 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 15 Jul 1999 17:07:39 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id <31H70HVR>; Thu, 15 Jul 1999 16:52:35 +0100 Message-Id: From: Ian MacKinnon To: xemacs-beta@xemacs.org Subject: RE: Failure with 21.2.18 cygnus Date: Thu, 15 Jul 1999 16:52:34 +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: so I know have my packages in /usr/local/lib/xemacs/xemacs-packages why does it need to be xemacs twice ? Why did it change (I'm not arguing against it, just interested) --- Ian > -----Original Message----- > From: nic@niss.ac.uk [mailto:nic@niss.ac.uk] > Sent: 15 July 1999 16:00 > To: sperber@informatik.uni-tuebingen.de > Cc: xemacs-beta@xemacs.org > Subject: Re: Failure with 21.2.18 cygnus > > > Michael Sperber [Mr. Preprocessor] wrote on 15-July-1999: > > ->Ian> (I have sumo installed in /usr/local/lib/xemacs/packages) > -> ^^^^^^^^ > -> > ->This is wrong. It's supposed to be `xemacs-packages.' > > If anyone cares, this is the exact same problem I had when I upgraded > from 21.2.17 to 21.2.18 - a close read of > http://www.xemacs.org/packages/guide.html solved it for me. > > nic > ************************************************************* 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 Thu Jul 15 13:05:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA28847 for xemacs-beta-out; Thu, 15 Jul 1999 13:05:34 -0400 Received: from web804.mail.yahoo.com (web804.mail.yahoo.com [128.11.23.64]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA28844 for ; Thu, 15 Jul 1999 13:05:32 -0400 Message-ID: <19990715170857.23926.rocketmail@web804.mail.yahoo.com> Received: from [129.188.33.221] by web804.mail.yahoo.com; Thu, 15 Jul 1999 17:08:57 GMT Date: Thu, 15 Jul 1999 17:08:57 +0000 (GMT) From: Rick Rankin Subject: Re: Failure with 21.2.18 cygnus To: Ian MacKinnon , "'Xemacs NT List'" , "'Xemacs Mailing List'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I built b18 yesterday with cygwin b20.1, and I'm having no problems. Some time ago, I got in the habit of specifying --package-path=/usr/local/lib/xemacs/packages If you haven't been specifying this in the past, then perhaps something in the b18 configure is not properly initializing the default value. I had a similar problem with the --site-prefixes in b16 or b17 where I had to specify both --site-includes and --site-libraries instead of just --site-prefixes. Rick -- Rick Rankin rick_rankin@yahoo.com --- Ian MacKinnon wrote: > Hi all > I am having problems with my build of b18 > this is on NT with cygwin b20 > The configure/make/install process works OK, but then when I try and run > xemacs can't find any packages > (I have sumo installed in /usr/local/lib/xemacs/packages) > I haven't changed anything else here (I think) > > Any one else seeing anything like this > > ie load-path contains > > `load-path' is a simple built-in variable. > > Value: ("/usr/xemacs-21.2.18/lisp/" "/usr/xemacs-21.2.18/lisp/mule/" > "/usr/xemacs-21.2.18/lisp/term/") > > > > {early,late}-package-load-path are both nil > > Installation looks like :- > > > > > > > uname -a: CYGWIN_NT-4.0 TECH007 21.0 (0.9/1/2) 1999-2-16 00:11:59 i686 > unknown > > ./configure '--site-includes=/usr/local/include' > '--site-libraries=/usr/local/lib' > > > XEmacs 21.2-b18 "Toshima" configured for `i686-pc-cygwin32'. > > Where should the build process find the source code? > /usr/xemacs-21.2.18 > 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? 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 support for GNU DBM. > Compiling in support for ncurses. > Compiling in File coding support. > Compiling in EXPERIMENTAL support for Drag'n'Drop ( msw ). > Compiling in support for proper WM_COMMAND handling. > Using Lucid menubars. > Using Lucid scrollbars. > Using Athena 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: --------------------------------------------------------- > > --- > Ian > ************************************************************* > 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 > ************************************************************* > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-xemacs-beta@xemacs.org Thu Jul 15 23:25:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA13565 for xemacs-beta-out; Thu, 15 Jul 1999 23:25:18 -0400 Received: from smtp3.mindspring.com (smtp3.mindspring.com [207.69.200.33]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA13561 for ; Thu, 15 Jul 1999 23:25:16 -0400 Received: from ashanti.mastaler.com (pool-207-205-182-236.phnx.grid.net [207.205.182.236]) by smtp3.mindspring.com (8.8.5/8.8.5) with SMTP id XAA03665 for ; Thu, 15 Jul 1999 23:25:14 -0400 (EDT) Received: (qmail 4462 invoked from network); 16 Jul 1999 03:24:52 -0000 Received: from unknown (HELO bodhi.mastaler.com.mastaler.com) (172.18.3.15) by 172.18.3.10 with SMTP; 16 Jul 1999 03:24:52 -0000 X-Now-Reading: William H. Gass' _Cartesian Sonata_ To: xemacs-beta@xemacs.org Subject: Re: [mailcrypt problem] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-linux References: <199907080301.XAA31577@smtp1.mindspring.com> From: Jason R Mastaler Date: 15 Jul 1999 21:24:04 -0600 In-Reply-To: SL Baur's message of "08 Jul 1999 14:06:23 +0900" Message-ID: Lines: 14 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Toshima) 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: > > If I comment out the (mc-setversion "gpg"), I have no problems, but > > with that line in I get the following error. FWIW, XEmacs 21.1.2 has > > no problem with this. Any idea what the problem is? > > No. It is possible that Gnus, etc. need rebuilding with the new > mailcrypt in place, but if that was your problem, you would have the > same behavior on 21.1 as 21.2. After upgrading to the recently released SUMOs, I no longer have this problem. Thanks. From owner-xemacs-beta@xemacs.org Fri Jul 16 00:04:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA14674 for xemacs-beta-out; Fri, 16 Jul 1999 00:04:58 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA14668 for ; Fri, 16 Jul 1999 00:04:56 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA14562 for ; Fri, 16 Jul 1999 13:04:51 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Failure with 21.2.18 cygnus References: X-Attribution: sb From: SL Baur In-Reply-To: Ian MacKinnon's message of "Thu, 15 Jul 1999 16:52:34 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 16 Jul 1999 13:04:47 +0900 Message-ID: Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ian MacKinnon writes in xemacs-beta@xemacs.org: > so I know have my packages in /usr/local/lib/xemacs/xemacs-packages > why does it need to be xemacs twice ? For naming consistency with mule-packages, infodock-packages, -packages, ... > Why did it change > (I'm not arguing against it, just interested) It actually changed a long time ago -- late April 1998. The compatibility code was recently dropped and that's why you're noticing it now. -- $BMn2V;^$K5"$i$:GK6@:F$S>H$i$5$:(B (Don't cry over spilled milk) From owner-xemacs-beta@xemacs.org Fri Jul 16 03:42:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA18819 for xemacs-beta-out; Fri, 16 Jul 1999 03:42:39 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA18816 for ; Fri, 16 Jul 1999 03:42:37 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 16 Jul 1999 08:40:55 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id <30N506Q6>; Fri, 16 Jul 1999 08:25:52 +0100 Message-Id: From: Ian MacKinnon To: "'Xemacs Mailing List'" Subject: FW: Failure with 21.2.18 cygnus Date: Fri, 16 Jul 1999 08:25:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Sorry Steve, I meant to send this to the list, not you direct > -----Original Message----- > From: Ian MacKinnon > Sent: 16 July 1999 08:22 > To: 'SL Baur' > Subject: RE: Failure with 21.2.18 cygnus > > > > > -----Original Message----- > > From: SL Baur [mailto:steve@xemacs.org] > > Sent: 16 July 1999 05:05 > > To: xemacs-beta@xemacs.org > > Subject: Re: Failure with 21.2.18 cygnus > > > > > > Ian MacKinnon writes in > > xemacs-beta@xemacs.org: > > > > > so I know have my packages in > /usr/local/lib/xemacs/xemacs-packages > > > why does it need to be xemacs twice ? > > > > For naming consistency with mule-packages, infodock-packages, > > -packages, ... > good reason > > > > > Why did it change > > > (I'm not arguing against it, just interested) > > > > It actually changed a long time ago -- late April 1998. The > > compatibility > > code was recently dropped and that's why you're noticing it now. > > > That explains it > > Thanks all > > > --- > Ian > ************************************************************* 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 Jul 16 04:14:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA19636 for xemacs-beta-out; Fri, 16 Jul 1999 04:14:10 -0400 Received: from mail-gw2.uk.oracle.com (mail-gw2.uk.oracle.com [193.130.129.196]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA19633 for ; Fri, 16 Jul 1999 04:14:07 -0400 Received: from mail-gw3.uk.oracle.com (gatekeeper.oracle.co.uk [193.130.129.195]) by mail-gw2.uk.oracle.com (8.9.3/8.9.3) with ESMTP id JAA14966 for ; Fri, 16 Jul 1999 09:14:04 +0100 (BST) Received: from mailm1 (mailm1.de.oracle.com [140.84.4.204]) by mail-gw3.uk.oracle.com (8.9.3/8.9.3) with ESMTP id JAA04512 for ; Fri, 16 Jul 1999 09:14:03 +0100 (BST) Received: from vzell.de.oracle.com by mailm1 (8.8.8+Sun/SMI-SVR4) id KAA07024; Fri, 16 Jul 1999 10:13:30 +0200 (MET DST) X-Mailer: 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) (via feedmail 8 I) To: xemacs-beta@xemacs.org Subject: Shift Delete on Cygwin/Xemacs-21.1-p2 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Dr. Volker Zell" Date: 16 Jul 1999 10:16:07 +0200 Message-ID: Lines: 26 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi When I do C-h k and then Control Insert or Shift Insert I get: C-insert runs `copy-primary-selection' Sh-insert runs `yank-clipboard-selection' but C-h k and then pressing Shift Delete gives me: DEL runs `scroll-down' It seems that Sh-delete is not recognized on my system. Any hint ? System: WinNT 4.0/SP3 Cygwin B20.1 with egcs-1.1.2 - cygwin1.dll - cygwin1-19990610.dll.gz - everything mounted binary, - CYGWIN = tty title binmode ntea nontsec Software: Xemacs-21.1.2 - http://www.xemacs.org/ Ciao Volker From owner-xemacs-beta@xemacs.org Fri Jul 16 04:30:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA20097 for xemacs-beta-out; Fri, 16 Jul 1999 04:30:41 -0400 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 EAA20093 for ; Fri, 16 Jul 1999 04:30:39 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA11526 for ; Fri, 16 Jul 1999 10:30:38 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002o0; Fri Jul 16 10:30:30 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA06085; Fri, 16 Jul 1999 10:30:29 +0200 To: xemacs-beta@xemacs.org Subject: Subwindows are cool! From: Jan Vroonhof Date: 16 Jul 1999 10:30:29 +0200 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: I just played a bit with the subwindow support. I had one of the Tk 8.0 demos displaying inside an XEmacs buffer. very nice. Thanks andy! Unfortunately when thing were brought through their obvious conclusion and I tried displaying an XEmacs frame inside a subwindow the external widget XEmacs crashed :-( Jan From owner-xemacs-beta@xemacs.org Fri Jul 16 07:51:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA23952 for xemacs-beta-out; Fri, 16 Jul 1999 07:51:17 -0400 Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA23949 for ; Fri, 16 Jul 1999 07:51:15 -0400 Received: from cerise.sensei.co.uk (dialin.sensei.co.uk [193.132.124.190]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id MAA09673; Fri, 16 Jul 1999 12:56:01 +0100 Received: (from glynn@localhost) by cerise.sensei.co.uk (8.9.3/8.9.3) id MAA00733; Fri, 16 Jul 1999 12:04:09 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14223.4521.211361.240551@cerise.sensei.co.uk> Date: Fri, 16 Jul 1999 12:04:09 +0100 (BST) To: "Dr. Volker Zell" Cc: xemacs-beta@xemacs.org Subject: Re: Shift Delete on Cygwin/Xemacs-21.1-p2 In-Reply-To: References: X-Mailer: VM 6.67 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Dr. Volker Zell wrote: > Hi > > When I do C-h k and then Control Insert or Shift Insert I get: > > C-insert runs `copy-primary-selection' > Sh-insert runs `yank-clipboard-selection' > > but C-h k and then pressing Shift Delete gives me: > > DEL runs `scroll-down' > > > It seems that Sh-delete is not recognized on my system. > > Any hint ? x-init.el has: ;; Motif-ish bindings ;; The following two were generally unliked. ;;(define-key global-map '(shift delete) 'kill-primary-selection) ;;(define-key global-map '(control delete) 'delete-primary-selection) (define-key global-map '(shift insert) 'yank-clipboard-selection) (define-key global-map '(control insert) 'copy-primary-selection) I just added (define-key global-map '(shift delete) 'kill-primary-selection) (define-key global-map '(control delete) 'delete-primary-selection) to my ~/.emacs. -- Glynn Clements From owner-xemacs-beta@xemacs.org Fri Jul 16 08:04:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA24493 for xemacs-beta-out; Fri, 16 Jul 1999 08:04:51 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA24487 for ; Fri, 16 Jul 1999 08:04:49 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 1156jN-00017e-00 for xemacs-beta@xemacs.org; Fri, 16 Jul 1999 08:04:45 -0400 To: xemacs-beta@xemacs.org Subject: [gnu.emacs.sources] PCL-CVS 2.9.6 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: message/rfc822 From: nbecker@fred.net Date: 16 Jul 1999 08:04:45 -0400 Message-ID: Lines: 114 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: From: "Stefan Monnier " Newsgroups: gnu.emacs.sources Subject: PCL-CVS 2.9.6 Date: 09 Jul 1999 13:49:19 -0400 Organization: Yale University Message-ID: <5lhfndn274.fsf@tequila.cs.yale.edu> References: <5lk8t037kt.fsf@tequila.cs.yale.edu> A new release of my PCL-CVS mode can be found at ftp://rum.cs.yale.edu/pub/monnier/pcl-cvs PCL-CVS is a front-end to the CVS version control system. For people familiar to VC, it is somewhat like VC-dired: it presents the status of all the files in your working area and allows you to commit/update several of them at a time. Compared to VC-dired, it is considerably better and faster (but only for CVS). PCL-CVS was originally written by Per Cederqvist many years ago. This version derives from the XEmacs-21 version, itself based on the 2.0b2 version (last release from Per). It is a thorough rework with considerable improvements. Contrary to what you'd expect, pcl-cvs is not a replacement for VC but only for VC-dired. As such, I've tried to make pcl-cvs and VC interoperate seemlessly (I also use VC). This version should work with any recent Emacs or XEmacs and with any recent cvs version (1.9 or 1.10). Note that there are many changes between 2.9.5 and 2.9.6, and there has been very little testing of those changes, so bugs are likely to be lurking. Many thanks to "Masatake YAMATO" for his `cvstree'. Stefan Changes from 2.9.5: * the menubar code has been simplified. This might not work as well on older XEmacsen. Also the cvs-mode-motion-highlight-line has been dropped. Scream if you want it back in. * a new command cvs-more-idiff-other allows to run idiff on two different files. Ideally it should be possible to idiff between two files from two different *cvs* buffers, but not just now. * more commands understand the `b' prefix (cvs-mode-examine, cvs-checkout). Furthermore, `cvs-mode-update' now uses `-j' rather than `-r' with the branch prefix. A secondary `B' branch prefix has been introduced. It is only active when the primary prefix is active. It is used by cvs-mode-diff and cvs-mode-update. * all the cvs-edit stuff has moved to cvs-edit.el. cvs-mode-changelog-commit is now deprecated in favor of either manually calling `cvs-edit-insert-changelog' or by adding that same command to your cvs-edit-mode-hook. If VC is loaded, cvs-edit now takes advantage of VC's comment ring. Furthermore a new hook cvs-edit-done-hook allows you now to run some code just before commit for anything like cleaningup the format, enforcing conventions, synchronizing with your bugtrackingsystem, ... A cvs-edit-files function is provided so that those hooks can know what files are about to be committed. If you write such a hook I'd like to hear from you. * The command's flags have also been improved with multiple defaults. A positive numeric argument selects the corresponding default, while a negative one queries to change this default. C-u C-u behaves as before while is similar to a negative zero argument (but those don't exist). This way you can have `s' run status and `1s' run `status -v'. The cvs--flags variables have been considerably changed and setting them in your .emacs is not recommended any more (it should still mostly work, tho). Also the default from the 4th up are shared among all commands. This can be changed with `cvs-shared-(start|flags)'. * `cvs-commit-prompt-buffer' disappeared. Use `cvs-buffer-name-alist' instead. * digits can again be used as numeric arguments, which is very handy for selecting among several defaults. * The C-x v binding was moved to C-x c but is configurable with `cvs-minor-mode-prefix' and it is automatically available via the cvs-minor-mode in any *cvs-* buffer. * cvs-mode-find-file can now jump to the `active' area of the file (if it is locally modified). This `cvs-find-file-and-jump' is set by default. * prefix keys have been unified/improved: `b', `M-f' and `T' are now using the same code. This code provides for 4 different defaults and for persistent settings: `C-1 b' will chose the default nb 1, while `C-u C-u b' will set the branch prefix persistently for the following commandS until it is reset by toggling it back to the inactive state with `b'. Changing the default is currently done with `C-5 b' (to change the default nb 1). This is likely to be changed to `C-- C-1 b' instead. * integrated a derivative of cvstree.el (many thanks to "Masatake YAMATO" ). It is now called cvs-status.el and is used as the major mode for cvs-mode-status' output. The trees are not automatically drawn, but only upon request: press `t' or `C-u t' or `T' to rewrite the tags-lists into trees (assuming you passed "-v"). There is also `cvs-mode-tree', but it is incomplete (I intent for it to present a merged view of a single tree representing the tags of all the files). All cvs-mode operations can be done from cvs-status-mode and they operate on the currently pointed-to file as well as on the currently pointed-to tag (an active mark can be used to specify a second file and a second tag). * the backup file loaded for imerge sessions is now put in the correct major mode. It used to be put in nroff-mode (it is still put in nroff-mode at first, but fixed later). * pcl-cvs-startup.el is now partly auto-generated. That means it's uglier. From owner-xemacs-beta@xemacs.org Fri Jul 16 09:08:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26889 for xemacs-beta-out; Fri, 16 Jul 1999 09:08:30 -0400 Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA26886 for ; Fri, 16 Jul 1999 09:08:28 -0400 Received: from feller.dina.kvl.dk (feller.dina.kvl.dk [130.225.40.147]) by sheridan.dina.kvl.dk (8.9.0.Beta5/8.9.0.Beta5) with SMTP id PAA32616; Fri, 16 Jul 1999 15:08:45 +0200 Received: by feller.dina.kvl.dk (SMI-8.6/SMI-SVR4) id PAA15442; Fri, 16 Jul 1999 15:08:23 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: <378AAE74.7B135933@erols.com> Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 16 Jul 1999 15:08:22 +0200 In-Reply-To: "Matthew O. Persico"'s message of "Mon, 12 Jul 1999 23:11:48 -0400" Message-ID: Lines: 30 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: "Matthew O. Persico" writes: > "Michael Sperber [Mr. Preprocessor]" wrote: > > > > The following constraint must hold: > > > > Two different author versions of a package must have different > > versions as well. > > They better have completely different names, period. > > Suppose Dilbert writes package foo and gets to version 1.3. Ralph > the Garbage Man picks though the dumpster, takes Dilbert's code, > tightens it up to 12 lines from 1500 and submits it back. (Laugh - > that was today's Desktop Dilbert cartoon.) I believe you parsed the sentence in a way that wasn't intended. Two different author versions ... should be parsed as (Two different (author versions) ...) not (Two (different author) versions ...) I.e., Michael is talking about two different versions from the author, not two versions from different authors. From owner-xemacs-beta@xemacs.org Fri Jul 16 09:09:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26910 for xemacs-beta-out; Fri, 16 Jul 1999 09:09:10 -0400 Received: from sheridan.dina.kvl.dk (sheridan.dina.kvl.dk [130.225.40.227]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA26907 for ; Fri, 16 Jul 1999 09:09:09 -0400 Received: from feller.dina.kvl.dk (feller.dina.kvl.dk [130.225.40.147]) by sheridan.dina.kvl.dk (8.9.0.Beta5/8.9.0.Beta5) with SMTP id PAA32620; Fri, 16 Jul 1999 15:09:25 +0200 Received: by feller.dina.kvl.dk (SMI-8.6/SMI-SVR4) id PAA15444; Fri, 16 Jul 1999 15:09:03 +0200 To: xemacs-beta@xemacs.org Subject: Re: New package system design draft References: Organization: The Church of Emacs X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ From: Per Abrahamsen Date: 16 Jul 1999 15:09:02 +0200 In-Reply-To: Jan Vroonhof's message of "13 Jul 1999 12:18:44 +0200" Message-ID: Lines: 5 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.3 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: > Thus 'load-path''s standard value is "nil"? Per is going to love that. Yes! From owner-xemacs-beta@xemacs.org Fri Jul 16 13:39:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA03534 for xemacs-beta-out; Fri, 16 Jul 1999 13:39:37 -0400 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 NAA03530 for ; Fri, 16 Jul 1999 13:39:35 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id KAA19985; Fri, 16 Jul 1999 10:40:54 -0700 To: XEmacs Beta Subject: Logo in splash. 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: 3 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ok, you win Steve. I'll revert to the original; no Debian logo in the splash or `gc-pointer-glyph'. From owner-xemacs-beta@xemacs.org Fri Jul 16 13:53:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA04161 for xemacs-beta-out; Fri, 16 Jul 1999 13:53:16 -0400 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 NAA04154 for ; Fri, 16 Jul 1999 13:53:12 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id KAA20021; Fri, 16 Jul 1999 10:54:35 -0700 To: XEmacs Beta Subject: `xemacs-packages/{Makefile,[XL]*.rules}' 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: 20 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Shouldn't the configurables at the top of XEmacs.rules be pulled out and put into `Local.rules' as well? I've made a few modifications to `XEmacs.rules' to make it possible to run in place from a CVS checkout. I use `cp --recursive --symlink' as RCOPY, to make a symlink tree, have a switch to turn off creation of tarfiles in STAGING, and have made a few other changes (rooting paths at `/' so the `cp' works right). I believe it is still compatible with your version. (Yous require GNU make anyhow, right?) Would anyone like to have a copy of it to test? Should I submit a patch? Do you want to keep the commented off stuff in the targets near the bottom? (I've deleted it in my version.) The symlink tree starts in STAGING, and that's where I point the XEmacs' package-path when I build it. It works very well... I can use `find-library' or `find-function', and it asks whether to follow the symlink to the CVS controlled source. A `make in-place' at the top builds everything and creates the symlinks. I've been using it since about Feb. 1999. From owner-xemacs-beta@xemacs.org Sat Jul 17 01:52:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA22061 for xemacs-beta-out; Sat, 17 Jul 1999 01:52:57 -0400 Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA22057 for ; Sat, 17 Jul 1999 01:52:41 -0400 Received: from sparrow.bear.com (user-2ive093.dialup.mindspring.com [165.247.1.35]) by smtp0.mindspring.com (8.8.5/8.8.5) with ESMTP id BAA12416 for ; Sat, 17 Jul 1999 01:52:39 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id BAA06696 for ; Sat, 17 Jul 1999 01:52:46 -0400 Date: Sat, 17 Jul 1999 05:52:45 +0000 ( ) From: Justin Vallon To: XEmacs Beta Subject: Autoload error in: ...: Cannot open load file: mule Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm running 21.1.3 with the latest packages, and I get the following warning in the warnings window at startup, even with xemacs -vanilla: (1) (warning/warning) Autoload error in: /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads: Cannot open load file: mule /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads I don't see the string "mule" in the indicated file, but there are some weird control-character strings in there. This one says: (package-provide 'lookup :version 1.01 :type 'regular) Any ideas? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sat Jul 17 02:36:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA22690 for xemacs-beta-out; Sat, 17 Jul 1999 02:36:08 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA22687 for ; Sat, 17 Jul 1999 02:36:03 -0400 Received: from sparrow.bear.com (user-2ive093.dialup.mindspring.com [165.247.1.35]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id CAA22439 for ; Sat, 17 Jul 1999 02:35:58 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id CAA06801 for ; Sat, 17 Jul 1999 02:36:05 -0400 Date: Sat, 17 Jul 1999 06:36:04 +0000 ( ) From: Justin Vallon To: XEmacs Beta Subject: Re: Autoload error in: ...: Cannot open load file: mule In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Sat, 17 Jul 1999, Justin Vallon wrote: > I'm running 21.1.3 with the latest packages, and I get the following > warning in the warnings window at startup, even with xemacs -vanilla: > > (1) (warning/warning) Autoload error in: > /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads: > Cannot open load file: mule > > /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads > > I don't see the string "mule" in the indicated file, but there are some > weird control-character strings in there. This one says: > > (package-provide 'lookup :version 1.01 :type 'regular) > > Any ideas? More info: After the warning, sh-mode (and probably others) then didn't work, apparently because the autoloading stopped at that point. -debug-init didn't catch anything. Removing the lookup package got rid of the warning, and sh-mode was working again. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sat Jul 17 12:20:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA30506 for xemacs-beta-out; Sat, 17 Jul 1999 12:20:15 -0400 Received: from land.willinet.net (land.willinet.net [198.49.30.33]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id MAA30500 for ; Sat, 17 Jul 1999 12:20:14 -0400 Received: (qmail 29336 invoked from network); 17 Jul 1999 11:20:12 -0500 Received: from ps01alo.willinet.net (HELO mharnois.workgroup.net) (root@198.49.28.98) by land.willinet.net with SMTP; 17 Jul 1999 11:20:12 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian/GNU) id LAA12924; Sat, 17 Jul 1999 11:20:09 -0500 To: xemacs-beta@xemacs.org Cc: andy@xemacs.org Subject: redisplay.c is dead From: Michael Harnois Date: 17 Jul 1999 11:20:08 -0500 Message-ID: <87aesvxn7r.fsf@mharnois.workgroup.net> Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hier ist etwas ganz upgefukt: gcc -c -g -O2 -march=pentium -fno-exceptions -fno-omit-frame-pointer -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include /src/xemacs-21.2/src/redisplay.c /src/xemacs-21.2/src/redisplay.c: In function `add_emchar_rune': /src/xemacs-21.2/src/redisplay.c:923: invalid type argument of `->' make[1]: *** [redisplay.o] Error 1 make[1]: Leaving directory `/src/xemacs/src' make: *** [dump-elcs] Error 2 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org There can be no transforming of darkness into light and of apathy into movement without emotion. - Carl Jung From owner-xemacs-beta@xemacs.org Sat Jul 17 12:44:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA31170 for xemacs-beta-out; Sat, 17 Jul 1999 12:44:30 -0400 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 MAA31166 for ; Sat, 17 Jul 1999 12:44:29 -0400 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 MAA29430 for ; Sat, 17 Jul 1999 12:50:23 -0400 (EDT) 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 SAA00783; Sat, 17 Jul 1999 18:44:24 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: redisplay.c is dead References: <87aesvxn7r.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: 17 Jul 1999 18:43:43 +0200 In-Reply-To: Michael Harnois's message of "17 Jul 1999 11:20:08 -0500" Message-ID: Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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> Hier ist etwas ganz upgefukt: Hi Michael, you're not supposed to say things like that in German, say "abgefuckt" instead :-) Adrian Michael> -- Michael> Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA Michael> mharnois@willinet.net aa0bt@aa0bt.ampr.org Michael> There can be no transforming of darkness into light and Michael> of apathy into movement without emotion. - Carl Jung From owner-xemacs-beta@xemacs.org Sat Jul 17 13:07:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA31850 for xemacs-beta-out; Sat, 17 Jul 1999 13:07:02 -0400 Received: from land.willinet.net (land.willinet.net [198.49.30.33]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id NAA31846 for ; Sat, 17 Jul 1999 13:06:59 -0400 Received: (qmail 19527 invoked from network); 17 Jul 1999 12:06:58 -0500 Received: from ps01alo.willinet.net (HELO mharnois.workgroup.net) (root@198.49.28.98) by land.willinet.net with SMTP; 17 Jul 1999 12:06:58 -0500 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.9.3/8.9.3/Debian/GNU) id MAA13598; Sat, 17 Jul 1999 12:05:05 -0500 To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: redisplay.c is dead References: <87aesvxn7r.fsf@mharnois.workgroup.net> From: Michael Harnois Date: 17 Jul 1999 12:05:05 -0500 In-Reply-To: Adrian Aichner's message of "17 Jul 1999 18:43:43 +0200" Message-ID: <871ze7xl4u.fsf@mharnois.workgroup.net> Lines: 12 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 17 Jul 1999 18:43:43 +0200, Adrian Aichner said: > you're not supposed to say things like that in German, say > "abgefuckt" instead :-) Danke sehr! -- 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 Jul 17 13:25:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA32338 for xemacs-beta-out; Sat, 17 Jul 1999 13:25:14 -0400 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 NAA32333 for ; Sat, 17 Jul 1999 13:25:12 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA18312 for ; Sat, 17 Jul 1999 19:25:11 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004U3; Sat Jul 17 19:25:07 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA09374; Sat, 17 Jul 1999 19:25:06 +0200 To: xemacs-beta@xemacs.org Subject: Re: Autoload error in: ...: Cannot open load file: mule References: From: Jan Vroonhof Date: 17 Jul 1999 19:25:06 +0200 In-Reply-To: Justin Vallon's message of "Sat, 17 Jul 1999 05:52:45 +0000 ( )" 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: Justin Vallon writes: > (1) (warning/warning) Autoload error in: > /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads: > Cannot open load file: mule > > /usr/lib/xemacs/xemacs-packages/lisp/lookup/auto-autoloads > > I don't see the string "mule" in the indicated file, but there are some > weird control-character strings in there. This one says: > > (package-provide 'lookup :version 1.01 :type 'regular) The lookup package is a mule package. It needs to go into mule-packages. However it mistakingly does not depend on mule-base and thus the package tools get it wrong. Steve, could you make a new package-index with this corrected? How did you upgrade? Is it OK in the Sumo's? Jan From owner-xemacs-beta@xemacs.org Sat Jul 17 15:49:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA02752 for xemacs-beta-out; Sat, 17 Jul 1999 15:49:46 -0400 Received: from mauve.csi.cam.ac.uk (mauve.csi.cam.ac.uk [131.111.8.38]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA02749 for ; Sat, 17 Jul 1999 15:49:45 -0400 Received: from line112.slip.csx.cam.ac.uk ([131.111.99.112] helo=casablanca ident=mail) by mauve.csi.cam.ac.uk with esmtp (Exim 3.02 #1) id 115aSt-0002YR-00 for xemacs-beta@xemacs.org; Sat, 17 Jul 1999 20:49:43 +0100 Received: from gunnar by casablanca with local (Exim 2.05 #1 (Debian)) id 115aS3-0005bL-00; Sat, 17 Jul 1999 20:48:51 +0100 To: XEmacs Developers Subject: adjust gdbinit to current lrecord implementation From: Gunnar Evermann Date: 17 Jul 1999 19:45:09 +0100 Message-ID: <87g12n2k0a.fsf@eng.cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 218 User-Agent: Gnus/5.070085 (Pterodactyl Gnus v0.85) XEmacs/21.2 (Toshima) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This has been annoying me for quite some time now. Am I the only person who actually uses gdb or noticed Martin's testsuite at the end of gdbinit? :-) 1999-07-17 Gunnar Evermann * gdbinit (pobj): change lrecord_foo to &lrecord_foo to match Olivier's change to lrecord.h of 1999-04-22 --- src/gdbinit.orig Sat Jul 17 19:38:21 1999 +++ src/gdbinit Sat Jul 17 19:38:30 1999 @@ -228,151 +228,151 @@ printf "Char: %d\n", $val end else - if $type == Lisp_Type_String || $imp == lrecord_string + if $type == Lisp_Type_String || $imp == &lrecord_string pstruct Lisp_String else - if $type == Lisp_Type_Cons || $imp == lrecord_cons + if $type == Lisp_Type_Cons || $imp == &lrecord_cons pstruct Lisp_Cons else - if $type == Lisp_Type_Symbol || $imp == lrecord_symbol + if $type == Lisp_Type_Symbol || $imp == &lrecord_symbol pstruct Lisp_Symbol printf "Symbol name: %s\n", $xstruct->name->data else - if $type == Lisp_Type_Vector || $imp == lrecord_vector + if $type == Lisp_Type_Vector || $imp == &lrecord_vector pstruct Lisp_Vector printf "Vector of length %d\n", $xstruct->size #print *($xstruct->data) @ $xstruct->size else - if $imp == lrecord_bit_vector + if $imp == &lrecord_bit_vector pstruct Lisp_Bit_Vector else - if $imp == lrecord_buffer + if $imp == &lrecord_buffer pstruct buffer else - if $imp == lrecord_char_table + if $imp == &lrecord_char_table pstruct Lisp_Char_Table else - if $imp == lrecord_char_table_entry + if $imp == &lrecord_char_table_entry pstruct Lisp_Char_Table_Entry else - if $imp == lrecord_charset + if $imp == &lrecord_charset pstruct Lisp_Charset else - if $imp == lrecord_coding_system + if $imp == &lrecord_coding_system pstruct Lisp_Coding_System else - if $imp == lrecord_color_instance + if $imp == &lrecord_color_instance pstruct Lisp_Color_Instance else - if $imp == lrecord_command_builder + if $imp == &lrecord_command_builder pstruct command_builder else - if $imp == lrecord_compiled_function + if $imp == &lrecord_compiled_function pstruct Lisp_Compiled_Function else - if $imp == lrecord_console + if $imp == &lrecord_console pstruct console else - if $imp == lrecord_database + if $imp == &lrecord_database pstruct Lisp_Database else - if $imp == lrecord_device + if $imp == &lrecord_device pstruct device else - if $imp == lrecord_event + if $imp == &lrecord_event pstruct Lisp_Event else - if $imp == lrecord_extent + if $imp == &lrecord_extent pstruct extent else - if $imp == lrecord_extent_auxiliary + if $imp == &lrecord_extent_auxiliary pstruct extent_auxiliary else - if $imp == lrecord_extent_info + if $imp == &lrecord_extent_info pstruct extent_info else - if $imp == lrecord_face + if $imp == &lrecord_face pstruct Lisp_Face else - if $imp == lrecord_float + if $imp == &lrecord_float pstruct Lisp_Float else - if $imp == lrecord_font_instance + if $imp == &lrecord_font_instance pstruct Lisp_Font_Instance else - if $imp == lrecord_frame + if $imp == &lrecord_frame pstruct frame else - if $imp == lrecord_glyph + if $imp == &lrecord_glyph pstruct Lisp_Glyph else - if $imp == lrecord_hash_table + if $imp == &lrecord_hash_table pstruct Lisp_Hash_Table else - if $imp == lrecord_image_instance + if $imp == &lrecord_image_instance pstruct Lisp_Image_Instance else - if $imp == lrecord_keymap + if $imp == &lrecord_keymap pstruct Lisp_Keymap else - if $imp == lrecord_lcrecord_list + if $imp == &lrecord_lcrecord_list pstruct lcrecord_list else - if $imp == lrecord_lstream + if $imp == &lrecord_lstream pstruct lstream else - if $imp == lrecord_marker + if $imp == &lrecord_marker pstruct Lisp_Marker else - if $imp == lrecord_opaque + if $imp == &lrecord_opaque pstruct Lisp_Opaque else - if $imp == lrecord_opaque_list + if $imp == &lrecord_opaque_list pstruct Lisp_Opaque_List else - if $imp == lrecord_popup_data + if $imp == &lrecord_popup_data pstruct popup_data else - if $imp == lrecord_process + if $imp == &lrecord_process pstruct Lisp_Process else - if $imp == lrecord_range_table + if $imp == &lrecord_range_table pstruct Lisp_Range_Table else - if $imp == lrecord_specifier + if $imp == &lrecord_specifier pstruct Lisp_Specifier else - if $imp == lrecord_subr + if $imp == &lrecord_subr pstruct Lisp_Subr else - if $imp == lrecord_symbol_value_buffer_local + if $imp == &lrecord_symbol_value_buffer_local pstruct symbol_value_buffer_local else - if $imp == lrecord_symbol_value_forward + if $imp == &lrecord_symbol_value_forward pstruct symbol_value_forward else - if $imp == lrecord_symbol_value_lisp_magic + if $imp == &lrecord_symbol_value_lisp_magic pstruct symbol_value_lisp_magic else - if $imp == lrecord_symbol_value_varalias + if $imp == &lrecord_symbol_value_varalias pstruct symbol_value_varalias else - if $imp == lrecord_toolbar_button + if $imp == &lrecord_toolbar_button pstruct toolbar_button else - if $imp == lrecord_tooltalk_message + if $imp == &lrecord_tooltalk_message pstruct Lisp_Tooltalk_Message else - if $imp == lrecord_tooltalk_pattern + if $imp == &lrecord_tooltalk_pattern pstruct Lisp_Tooltalk_Pattern else - if $imp == lrecord_weak_list + if $imp == &lrecord_weak_list pstruct weak_list else - if $imp == lrecord_window + if $imp == &lrecord_window pstruct window else - if $imp == lrecord_window_configuration + if $imp == &lrecord_window_configuration pstruct window_config else echo Unknown Lisp Object type\n -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University From owner-xemacs-beta@xemacs.org Sun Jul 18 05:01:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA16579 for xemacs-beta-out; Sun, 18 Jul 1999 05:01:33 -0400 Received: from smtp1.mindspring.com (smtp1.mindspring.com [207.69.200.31]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA16576 for ; Sun, 18 Jul 1999 05:01:29 -0400 Received: from sparrow.bear.com (user-2ive2eo.dialup.mindspring.com [165.247.9.216]) by smtp1.mindspring.com (8.8.5/8.8.5) with ESMTP id FAA05632; Sun, 18 Jul 1999 05:01:27 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id FAA15570; Sun, 18 Jul 1999 05:01:34 -0400 Date: Sun, 18 Jul 1999 09:01:33 +0000 ( ) From: Justin Vallon To: Jan Vroonhof cc: xemacs-beta@xemacs.org Subject: Re: Autoload error in: ...: Cannot open load file: mule In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 17 Jul 1999, Jan Vroonhof wrote: > The lookup package is a mule package. It needs to go into > mule-packages. However it mistakingly does not depend on mule-base and > thus the package tools get it wrong. > > Steve, could you make a new package-index with this corrected? > > How did you upgrade? Is it OK in the Sumo's? I pulled in the individual package. I haven't used the Sumo package. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sun Jul 18 13:04:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA23583 for xemacs-beta-out; Sun, 18 Jul 1999 13:04:14 -0400 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 NAA23573; Sun, 18 Jul 1999 13:04:04 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id KAA09348; Sun, 18 Jul 1999 10:03:46 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-41.beasys.com [192.168.11.41]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id KAA12882; Sun, 18 Jul 1999 10:03:35 -0700 (PDT) Message-Id: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 18 Jul 1999 18:03:55 +0100 To: xemacs-patches@xemacs.org From: Andy Piper Subject: Putting it all together Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_932313835==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_932313835==_ Content-Type: text/plain; charset="us-ascii" This patch fixes a few errors in my gutter and widget support and combine everything to provide tabbed buffers on devices that support tabbed widgets (i.e. only mswindows currently). I will apply this to cvs once I have fixed the specifier caching bug that is currently eluding me. andy 1999-07-18 Andy Piper * glyphs-msw.c (console_type_create_glyphs_mswindows): add resize_subwindow. (mswindows_resize_subwindow): new function. * menubar-items.el (default-menubar): add gutter options. * gutter.c (redraw_exposed_gutter): only reset the current_display_lines if non-zero. (Fgutter_pixel_height): new function. (Fgutter_pixel_width): new function. * gutter-items.el: new file. (gutter): new group for custom. (gutter-visible-p): new variable. (default-gutter-position): ditto. (buffers-tab): new group for the buffers tab. (gutter-buffers-tab): widget to put in the gutter. (buffers-tab-max-size): max number of tabs. (buffers-tab-switch-to-buffer-function): function to call when a tab is pressed. (buffers-tab-omit-function): filter buffers with this function. (buffers-tab-format-buffer-line-function): format buffer names for inclusion in tabs. (buffers-tab-switch-to-buffer): like switch-to-buffer but without the record. (build-buffers-tab-internal): build a list of tab items. (buffers-tab-items): ditto. (add-tab-to-gutter): put a tab in the gutter area. (update-tab-in-gutter): reset the buffers in the tab. * dumped-lisp.el (preloaded-file-list): dump gutter-items. * buffer.el (switch-to-buffer): run switch-to-buffer-hooks. (switch-to-buffer-hooks): new hook. * event-msw.c (mswindows_wnd_proc): set the mask of the parameter we want to retrive from the tab control. 1999-07-17 Andy Piper * toolbar.el (default-toolbar-position): fix typo. * window.c (change_window_height): mark gutters changed when we're done. * gutter.c (specifier_vars_of_gutter): make defaults more sensible. * gutter.h (WINDOW_REAL_GUTTER_BORDER_WIDTH): adjust to be 0 for 0 height gutter. (DEFAULT_GUTTER_WIDTH): change. (DEFAULT_GUTTER_BORDER_WIDTH): change. --=====================_932313835==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="tabgut.patch" Content-Transfer-Encoding: quoted-printable Index:= lisp/buffer.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/buffer.el,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 buffer.el --- lisp/buffer.el 1999/01/18 22:04:11 1.3.2.1 +++ lisp/buffer.el 1999/07/18 17:01:34 @@ -32,6 +32,9 @@ ;;; Code: +(defvar switch-to-buffer-hooks nil + "Hooks to run after a recorded buffer switch.") + (defun switch-to-buffer (bufname &optional norecord) "Select buffer BUFNAME in the current window. BUFNAME may be a buffer or a buffer name and is created if it did not= exist. @@ -65,6 +68,8 @@ (next-window (minibuffer-window)) (selected-window)) buf) + ;; XEmacs change + (or norecord (run-hook-with-args 'switch-to-buffer-hooks buf)) buf)) (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) Index:= lisp/dumped-lisp.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/dumped-lisp.el,v retrieving revision 1.30.2.7 diff -u -r1.30.2.7 dumped-lisp.el --- lisp/dumped-lisp.el 1999/06/03 09:50:01 1.30.2.7 +++ lisp/dumped-lisp.el 1999/07/18 17:01:34 @@ -164,6 +164,7 @@ (when-feature (and (not infodock) (or x mswindows) menubar) "menubar-items") (when-feature (and infodock (or x mswindows) menubar)= "id-menus") + (when-feature gutter "gutter-items") (when-feature x "x-faces") (when-feature x "x-iso8859-1") (when-feature x "x-mouse") Index:= lisp/gutter-items.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: gutter-items.el diff -N gutter-items.el --- /dev/null Sun Jul 18 06:26:52 1999 +++ lisp/gutter-items.el Sun Jul 18 10:01:34 1999 @@ -0,0 +1,158 @@ +;;; gutter-items.el --- Gutter content for XEmacs. + +;; Copyright (C) 1999 Free Software Foundation, Inc. +;; Copyright (C) 1999 Andy Piper. + +;; Maintainer: XEmacs Development Team +;; Keywords: frames, extensions, internal, dumped + +;; 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 Xmacs; see the file COPYING. If not, write to the +;; Free Software Foundation, 59 Temple Place - Suite 330, +;; Boston, MA 02111-1307, USA. + +;; Some of this is taken from the buffer-menu stuff in menubar-items.el +;; and the custom specs in toolbar.el. + +(defgroup gutter nil + "Input from the gutters." + :group 'environment) + +(defcustom gutter-visible-p + (specifier-instance default-gutter-visible-p) + "Whether the default gutter is globally visible. This option can= be +customized through the options menu." + :group 'display + :type 'boolean + :set #'(lambda (var val) + (set-specifier default-gutter-visible-p val) + (setq gutter-visible-p val))) + +(defcustom default-gutter-position + (default-gutter-position) + "The location of the default gutter. It can be 'top, 'bottom, 'left= or +'right. This option can be customized through the options menu." + :group 'display + :type '(choice (const :tag "top" 'top) + (const :tag "bottom" 'bottom) + (const :tag "left" 'left) + (const :tag "right" 'right)) + :set #'(lambda (var val) + (set-default-gutter-position val) + (setq default-gutter-position val))) + +;;; The Buffers tab + +(defgroup buffers-tab nil + "Customization of `Buffers' tab." + :group 'gutter) + +(defvar gutter-buffers-tab nil + "A tab widget in the gutter for displaying buffers. +Do not set this. Use `glyph-image-instance'= and +`set-image-instance-property' to change the properties of the= tab.") + +(defcustom buffers-tab-max-size 6 + "*Maximum number of entries which may appear on the \"Buffers\" tab. +If this is 10, then only the ten most-recently-selected buffers will= be +shown. If this is nil, then all buffers will be shown. Setting this to +a large number or nil will slow down tab responsiveness." + :type '(choice (const :tag "Show all" nil) + (integer 10)) + :group 'buffers-tab) + +(defcustom buffers-tab-switch-to-buffer-function= 'buffers-tab-switch-to-buffer + "*The function to call to select a buffer from the buffers= tab. +`switch-to-buffer' is a good choice, as is `pop-to-buffer'." + :type '(radio (function-item switch-to-buffer) + (function-item pop-to-buffer) + (function :tag "Other")) + :group 'buffers-tab) + +(defcustom buffers-tab-omit-function 'buffers-menu-omit-invisible-buffers + "*If non-nil, a function specifying the buffers to omit from the buffers= menu. +This is passed a buffer and should return non-nil if the buffer should= be +omitted. The default value `buffers-tab-omit-invisible-buffers'= omits +buffers that are normally considered \"invisible\" (those whose= name +begins with a space)." + :type '(choice (const :tag "None" nil) + function) + :group 'buffers-tab) + +(defcustom buffers-tab-format-buffer-line-function= 'format-buffers-menu-line + "*The function to call to return a string to represent a buffer in= the +buffers menu. The function is passed a buffer and should return a= string. +The default value `format-buffers-menu-line' just returns the name of +the buffer. Also check out `slow-format-buffers-menu-line' which +returns a whole bunch of info about a buffer." + :type 'function + :group 'buffers-tab) + +(defun buffers-tab-switch-to-buffer (buffer) + "For use as a value for `buffers-tab-switch-to-buffer-function'." + (switch-to-buffer buffer t)) + +(defsubst build-buffers-tab-internal (buffers) + (let (line) + (mapcar + #'(lambda (buffer) + (setq line (funcall buffers-tab-format-buffer-line-function + buffer)) + (vector line (list buffers-tab-switch-to-buffer-function + (buffer-name buffer)))) + buffers))) + +(defun buffers-tab-items () + "This is the tab filter for the top-level buffers \"Buffers\" tab. +It dynamically creates a list of buffers to use as the contents of the= tab. +Only the most-recently-used few buffers will be listed on the tab,= for +efficiency reasons. You can control how many buffers will be shown= by +setting `buffers-tab-max-size'. You can control the text of the= menu +items by redefining the function `format-buffers-menu-line'." + (let ((buffers (delete-if buffers-tab-omit-function (buffer-list)))) + (and (integerp buffers-tab-max-size) + (> buffers-tab-max-size 1) + (> (length buffers) buffers-tab-max-size) + ;; shorten list of buffers (not with submenus!) + (setcdr (nthcdr buffers-tab-max-size buffers) nil)) + (setq buffers (build-buffers-tab-internal buffers)) + buffers)) + +(defun add-tab-to-gutter () + "Put a tab control in the gutter area to hold the most recent buffers." + (let ((gutter-string "")) + (set-extent-begin-glyph + (make-extent 0 0 gutter-string) + (setq gutter-buffers-tab + (make-glyph + (vector 'tab-control :descriptor "Buffers" + :properties (list :items (buffers-tab-items)))))) + ;; This looks better than a 3d border + (set-specifier default-gutter-border-width 0) + (set-specifier default-gutter gutter-string))) + +(defun update-tab-in-gutter (&optional notused) + "Update the tab control in the gutter area." + (set-image-instance-property (glyph-image-instance= gutter-buffers-tab) + :items + (buffers-tab-items)) + (resize-subwindow (glyph-image-instance gutter-buffers-tab) + (gutter-pixel-width) nil)) + +(add-tab-to-gutter) +(add-hook 'switch-to-buffer-hooks 'update-tab-in-gutter) + +(provide 'gutter-items) +;;; gutter-items.el ends here. Index:= lisp/menubar-items.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/menubar-items.el,v retrieving revision 1.6.2.10 diff -u -r1.6.2.10 menubar-items.el --- lisp/menubar-items.el 1999/07/05 02:21:04 1.6.2.10 +++ lisp/menubar-items.el 1999/07/18 17:01:41 @@ -737,6 +737,32 @@ :selected (eq default-toolbar-position 'right)] ) ))) + ,@(if (featurep 'gutter) + '(("Gutter Appearance" + ["Visible" + (customize-set-variable 'gutter-visible-p + (not gutter-visible-p)) + :style toggle + :selected gutter-visible-p] + ("Default Location" + ["Top" + (customize-set-variable 'default-gutter-position 'top) + :style radio + :selected (eq default-gutter-position 'top)] + ["Bottom" + (customize-set-variable 'default-gutter-position 'bottom) + :style radio + :selected (eq default-gutter-position 'bottom)] + ["Left" + (customize-set-variable 'default-gutter-position 'left) + :style radio + :selected (eq default-gutter-position 'left)] + ["Right" + (customize-set-variable 'default-gutter-position 'right) + :style radio + :selected (eq default-gutter-position 'right)] + ) + ))) ("Mouse" ["Avoid Text..." (customize-set-variable 'mouse-avoidance-mode Index:= lisp/toolbar.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/toolbar.el,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 toolbar.el --- lisp/toolbar.el 1998/12/05 16:54:52 1.8.2.1 +++ lisp/toolbar.el 1999/07/18 17:01:41 @@ -54,7 +54,7 @@ (defcustom default-toolbar-position ;; added for the options menu - dverna (default-toolbar-position) - "The location of the default toolbar. It can be 'top, 'bootom, 'left or + "The location of the default toolbar. It can be 'top, 'bottom, 'left or 'right. This option can be customized through the options menu." :group 'display :type '(choice (const :tag "top" 'top) Index: src/event-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.38.2.15 diff -u -r1.38.2.15 event-msw.c --- src/event-msw.c 1999/07/05 07:28:22 1.38.2.15 +++ src/event-msw.c 1999/07/18 17:01:51 @@ -1970,6 +1970,8 @@ TC_ITEM item; int index =3D SendMessage (nmhdr->hwndFrom, TCM_GETCURSEL, 0, 0); frame =3D XFRAME (mswindows_find_frame (hwnd)); + + item.mask =3D TCIF_PARAM; SendMessage (nmhdr->hwndFrom, TCM_GETITEM, (WPARAM)index, (LPARAM)&item); Index:= src/glyphs-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-msw.c,v retrieving revision 1.21.2.18 diff -u -r1.21.2.18 glyphs-msw.c --- src/glyphs-msw.c 1999/07/05 07:28:23 1.21.2.18 +++ src/glyphs-msw.c 1999/07/18 17:01:59 @@ -107,6 +107,7 @@ struct frame* f); COLORREF mswindows_string_to_color (CONST char *name); +void check_valid_item_list_1 (Lisp_Object items); #define BPLINE(width) ((int)(~3UL & (unsigned long)((width) +3))) @@ -2049,6 +2050,17 @@ | SWP_NOCOPYBITS | SWP_NOSENDCHANGING); } +/* resize the subwindow instance */ +static void +mswindows_resize_subwindow (struct Lisp_Image_Instance* ii, int w, int= h) +{ + SetWindowPos (WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii), + NULL, + 0, 0, w, h, + SWP_NOZORDER | SWP_NOMOVE + | SWP_NOCOPYBITS | SWP_NOSENDCHANGING); +} + /* when you click on a widget you may activate another widget this needs to be checked and all appropriate widgets updated */ static void @@ -2540,7 +2552,6 @@ WS_EX_CONTROLPARENT); wnd =3D WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii); - /* add items to the tab */ LIST_LOOP (rest, Fplist_get (IMAGE_INSTANCE_WIDGET_PROPS (ii), Q_items,= Qnil)) { @@ -2549,6 +2560,36 @@ } } +/* set the properties of a tab control */ +static Lisp_Object +mswindows_tab_control_set_property (Lisp_Object image_instance, Lisp_Object= prop, + Lisp_Object val) +{ + struct Lisp_Image_Instance *ii =3D XIMAGE_INSTANCE (image_instance); + + if (EQ (prop, Q_items)) + { + HWND wnd =3D WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii); + int index =3D 0; + Lisp_Object rest; + check_valid_item_list_1 (val); + + /* delete the pre-existing items */ + SendMessage (wnd, TCM_DELETEALLITEMS, 0, 0); + + /* add items to the tab */ + LIST_LOOP (rest, val) + { + add_tab_item (image_instance, wnd, XCAR (rest),= + IMAGE_INSTANCE_SUBWINDOW_FRAME (ii), index); + index++; + } + + return Qt; + } + return Qunbound; +} + /* instantiate a static control possible for putting other things in */ static void mswindows_label_instantiate (Lisp_Object image_instance, Lisp_Object= instantiator, @@ -2739,6 +2780,7 @@ CONSOLE_HAS_METHOD (mswindows, image_instance_hash); CONSOLE_HAS_METHOD (mswindows, init_image_instance_from_eimage); CONSOLE_HAS_METHOD (mswindows, locate_pixmap_file); + CONSOLE_HAS_METHOD (mswindows, resize_subwindow); } void @@ -2815,6 +2857,7 @@ /* tab control widget */ INITIALIZE_DEVICE_IIFORMAT (mswindows, tab_control); IIFORMAT_HAS_DEVMETHOD (mswindows, tab_control, instantiate); + IIFORMAT_HAS_DEVMETHOD (mswindows, tab_control, set_property); /* windows bitmap format */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (bmp, "bmp"); Index:= src/glyphs-widget.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/glyphs-widget.c,v retrieving revision 1.1.2.6 diff -u -r1.1.2.6 glyphs-widget.c --- src/glyphs-widget.c 1999/06/29 14:35:33 1.1.2.6 +++ src/glyphs-widget.c 1999/07/18 17:02:02 @@ -149,7 +149,7 @@ signal_simple_error (":descriptor must be a string or a vector", data); } -static void +void check_valid_item_list_1 (Lisp_Object items) { Lisp_Object rest; Index:= src/gutter.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/gutter.c,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 gutter.c --- src/gutter.c 1999/07/16 19:05:40 1.1.2.1 +++ src/gutter.c 1999/07/18 17:02:02 @@ -357,7 +357,8 @@ /* #### optimize this - redrawing the whole gutter for every expose is very expensive. We reset the current display lines because if they're being exposed they are no longer current. */ - Dynarr_reset (f->current_display_lines); + if (f->current_display_lines) + Dynarr_reset (f->current_display_lines); /* we have to do this in-case there were subwindows where we are redrawing, unfortunately sometimes this also generates expose events resulting in an endless cycle of redsplay. */ @@ -394,27 +395,6 @@ Dynarr_free (f->desired_display_lines); } -void -init_frame_gutters (struct frame *f) -{ - int pos; - struct window* w =3D XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)); - /* We are here as far in frame creation so cached specifiers are - already recomputed, and possibly modified by resource - initialization. We need to recalculate autodetected gutters. */ - for (pos =3D 0; pos< 4; pos++) - { - w->real_gutter_size[pos] =3D w->gutter_size[pos]; - if (EQ (w->gutter_size[pos], Qautodetect) - && !NILP (w->gutter_visible_p[pos])) - { - w->real_gutter_size [pos] =3D calculate_gutter_size (w, pos); - MARK_GUTTER_CHANGED; - MARK_WINDOWS_CHANGED (w); - } - } -} - static enum gutter_pos decode_gutter_position (Lisp_Object position) { @@ -476,6 +456,48 @@ return Vdefault_gutter_position; } +DEFUN ("gutter-pixel-width", Fgutter_pixel_width, 0, 2, 0, /* +Return the pixel width of the gutter at POS in LOCALE. +POS defaults to the default gutter position. LOCALE defaults to +the current window. +*/ + (pos, locale)) +{ + int x, y, width, height; + enum gutter_pos p =3D TOP_GUTTER; + struct frame *f =3D decode_frame (FW_FRAME (locale)); + + if (NILP (pos)) + pos =3D Vdefault_gutter_position; + p =3D decode_gutter_position (pos); + + get_gutter_coords (f, p, &x, &y, &width, &height); + width -=3D (FRAME_GUTTER_BORDER_WIDTH (f, p) * 2); + + return make_int (width); +} + +DEFUN ("gutter-pixel-height", Fgutter_pixel_height, 0, 2, 0, /* +Return the pixel height of the gutter at POS in LOCALE. +POS defaults to the default gutter position. LOCALE defaults to +the current window. +*/ + (pos, locale)) +{ + int x, y, width, height; + enum gutter_pos p =3D TOP_GUTTER; + struct frame *f =3D decode_frame (FW_FRAME (locale)); + + if (NILP (pos)) + pos =3D Vdefault_gutter_position; + p =3D decode_gutter_position (pos); + + get_gutter_coords (f, p, &x, &y, &width, &height); + height -=3D (FRAME_GUTTER_BORDER_WIDTH (f, p) * 2); + + return make_int (height); +} + DEFINE_SPECIFIER_TYPE (gutter); static void @@ -580,11 +602,35 @@ } void +init_frame_gutters (struct frame *f) +{ + int pos; + struct window* w =3D XWINDOW (FRAME_LAST_NONMINIBUF_WINDOW (f)); + /* We are here as far in frame creation so cached specifiers are + already recomputed, and possibly modified by resource + initialization. We need to recalculate autodetected gutters. */ + for (pos =3D 0; pos< 4; pos++) + { + w->real_gutter_size[pos] =3D w->gutter_size[pos]; + if (EQ (w->gutter_size[pos], Qautodetect) + && !NILP (w->gutter_visible_p[pos])) + { + Fset_specifier_dirty_flag (Vgutter[pos]); + w->real_gutter_size [pos] =3D calculate_gutter_size (w, pos); + MARK_GUTTER_CHANGED; + MARK_WINDOWS_CHANGED (w); + } + } +} + +void syms_of_gutter (void) { DEFSUBR (Fgutter_specifier_p); DEFSUBR (Fset_default_gutter_position); DEFSUBR (Fdefault_gutter_position); + DEFSUBR (Fgutter_pixel_height); + DEFSUBR (Fgutter_pixel_width); } void @@ -829,14 +875,13 @@ fb =3D Qnil; #ifdef HAVE_TTY - fb =3D Fcons (Fcons (list1 (Qtty), Qzero), fb); + fb =3D Fcons (Fcons (list1 (Qtty), Qautodetect), fb); #endif #ifdef HAVE_X_WINDOWS - fb =3D Fcons (Fcons (list1 (Qx), make_int (DEFAULT_GUTTER_HEIGHT)),= fb); + fb =3D Fcons (Fcons (list1 (Qx), Qautodetect), fb); #endif #ifdef HAVE_MS_WINDOWS - fb =3D Fcons (Fcons (list1 (Qmswindows), - make_int (DEFAULT_GUTTER_HEIGHT)), fb); + fb =3D Fcons (Fcons (list1 (Qmswindows), Qautodetect), fb); #endif if (!NILP (fb)) set_specifier_fallback (Vdefault_gutter_height, fb); Index:= src/gutter.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/gutter.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 gutter.h --- src/gutter.h 1999/07/16 19:05:41 1.1.2.1 +++ src/gutter.h 1999/07/18 17:02:02 @@ -35,9 +35,8 @@ #define CHECK_GUTTER_SPECIFIER(x) CHECK_SPECIFIER_TYPE (x, gutter) #define CONCHECK_GUTTER_SPECIFIER(x) CONCHECK_SPECIFIER_TYPE (x, gutter) -#define DEFAULT_GUTTER_HEIGHT 0 -#define DEFAULT_GUTTER_WIDTH 0 -#define DEFAULT_GUTTER_BORDER_WIDTH 0 +#define DEFAULT_GUTTER_WIDTH 40 +#define DEFAULT_GUTTER_BORDER_WIDTH 2 enum gutter_pos { @@ -77,7 +76,8 @@ #define WINDOW_REAL_GUTTER_VISIBLE(f, pos) \ (WINDOW_REAL_GUTTER_SIZE (f, pos) > 0) #define WINDOW_REAL_GUTTER_BORDER_WIDTH(f, pos) \ - (!NILP (WINDOW_GUTTER_VISIBLE (f, pos)) \ + ((!NILP (WINDOW_GUTTER_VISIBLE (f, pos)) \ + && WINDOW_GUTTER_SIZE_INTERNAL (f,pos) > 0) \ ? WINDOW_GUTTER_BORDER_WIDTH (f, pos) \ : 0) #define WINDOW_REAL_GUTTER_BOUNDS(f, pos) \ Index:= src/redisplay.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.8 diff -u -r1.55.2.8 redisplay.c --- src/redisplay.c 1999/07/16 19:05:42 1.55.2.8 +++ src/redisplay.c 1999/07/18 17:02:30 @@ -5868,7 +5868,7 @@ } Fset_marker (w->pointm[DESIRED_DISP], make_int (pointm), the_buffer); - /* If the buffer has changed we have to invalid all of our face + /* If the buffer has changed we have to invalidate all of our face cache elements. */ if ((!echo_active && b !=3D window_display_buffer (w)) || !Dynarr_length (w->face_cachels) Index:= src/window.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.c,v retrieving revision 1.41.2.10 diff -u -r1.41.2.10 window.c --- src/window.c 1999/07/16 19:05:44 1.41.2.10 +++ src/window.c 1999/07/18 17:02:44 @@ -3899,6 +3899,8 @@ SET_LAST_MODIFIED (w, 0); SET_LAST_FACECHANGE (w); MARK_FRAME_WINDOWS_STRUCTURE_CHANGED (f); + /* overkill maybe, but better to be correct */ + MARK_FRAME_GUTTERS_CHANGED (f); } #undef MINSIZE #undef CURBEG Index:= tests/glyph-test.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/tests/Attic/glyph-test.el,v retrieving revision 1.1.2.9 diff -u -r1.1.2.9 glyph-test.el --- tests/glyph-test.el 1999/07/16 19:05:47 1.1.2.9 +++ tests/glyph-test.el 1999/07/18 17:02:44 @@ -5,7 +5,8 @@ (defun foo () (interactive) - (setq ok-select (not ok-select))) + (ding)) +; (setq ok-select (not ok-select))) ;; button in a group (setq ok-select nil) Index:= tests/gutter-test.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/tests/Attic/gutter-test.el,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 gutter-test.el --- tests/gutter-test.el 1999/07/16 19:06:32 1.1.2.1 +++ tests/gutter-test.el 1999/07/18 17:02:44 @@ -14,4 +14,4 @@ (set-specifier default-gutter-width 40) (set-specifier default-gutter-border-width 2) (set-specifier default-gutter str) -(set-default-gutter-position 'top) +(set-default-gutter-position 'bottom) --=====================_932313835==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_932313835==_-- From owner-xemacs-beta@xemacs.org Sun Jul 18 13:22:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA23990 for xemacs-beta-out; Sun, 18 Jul 1999 13:22:35 -0400 Received: from corp-200.dfki.uni-sb.de (corp-200.dfki.uni-sb.de [134.96.188.10]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA23987 for ; Sun, 18 Jul 1999 13:22:32 -0400 Organization: DFKI Saarbruecken GmbH, D 66123 Saarbruecken Received: from master.ags.uni-sb.de (master.ags.uni-sb.de [134.96.236.2]) by corp-200.dfki.uni-sb.de (8.8.8/8.8.8) with ESMTP id TAA01303; Sun, 18 Jul 1999 19:22:30 +0200 (MET DST) Received: from turing.ags.uni-sb.de (pC19F4AD8.dip.t-dialin.net [193.159.74.216]) by master.ags.uni-sb.de (8.8.8/8.8.8) with SMTP id TAA19634; Sun, 18 Jul 1999 19:22:29 +0200 (MET DST) Date: Sun, 18 Jul 1999 19:15:16 +0200 Message-ID: <9438-Sun18Jul1999191516+0200-burt@dfki.de> X-Mailer: 21.0 "20 minutes to Nikko" XEmacs Lucid (beta65) (via feedmail 9-beta-4 I) From: Alastair Burt To: xemacs-beta@xemacs.org Subject: Problem with Coding System Detection Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In XEmacs 21.0 "20 minutes to Nikko" [Lucid] (i586-pc-linux, Mule) of Sun Jul 18 1999 on turing configured using `configure --error-checking=none --with-png=yes --with-mule=yes' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I cannot read files in /var/spool/mail. The reason is that find-file-coding-system-for-read-from-filename is picking up the function convert-mbox-coding-system from file-coding-system-alist and then calling it with the wrong arguments: ;; codesys set to convert-mbox-coding-system (funcall codesys 'insert-file-contents filename) -versus- (defun convert-mbox-coding-system (filename visit start end) -- Alastair From owner-xemacs-beta@xemacs.org Sun Jul 18 13:22:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA24003 for xemacs-beta-out; Sun, 18 Jul 1999 13:22:51 -0400 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 NAA23999 for ; Sun, 18 Jul 1999 13:22:50 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id TAA10780 for ; Sun, 18 Jul 1999 19:22:49 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002cQ; Sun Jul 18 19:22:42 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id TAA10864; Sun, 18 Jul 1999 19:22:42 +0200 To: xemacs-beta@xemacs.org Subject: Re: Putting it all together References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> From: Jan Vroonhof Date: 18 Jul 1999 19:22:41 +0200 In-Reply-To: Andy Piper's message of "Sun, 18 Jul 1999 18:03:55 +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: Andy Piper writes: > This patch fixes a few errors in my gutter and widget support and combine > everything to provide tabbed buffers on devices that support tabbed widgets > (i.e. only mswindows currently). I didn't look in depth at it yet, but the doc strings for the gutter tab items still contain references to the buffer menus. Jan P.S. Does anybody know a free Xt based toolkit that has all these modern widgets? From owner-xemacs-beta@xemacs.org Sun Jul 18 15:02:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA26122 for xemacs-beta-out; Sun, 18 Jul 1999 15:02:14 -0400 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 PAA26119 for ; Sun, 18 Jul 1999 15:02:13 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA10548; Sun, 18 Jul 1999 12:01:59 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-22.beasys.com [192.168.11.22]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA19881; Sun, 18 Jul 1999 12:01:55 -0700 (PDT) Message-Id: <3.0.5.32.19990718200214.00a4f290@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 18 Jul 1999 20:02:14 +0100 To: Michael Harnois , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: redisplay.c is dead In-Reply-To: <87aesvxn7r.fsf@mharnois.workgroup.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oops. Try this: Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.8 diff -u -r1.55.2.8 redisplay.c --- redisplay.c 1999/07/16 19:05:42 1.55.2.8 +++ redisplay.c 1999/07/18 19:00:52 @@ -920,7 +920,7 @@ data->bi_bufpos); else crb->bufpos = - bytecount_to_charcount (string_data (data->string), data->bi_bufpos); + bytecount_to_charcount (XSTRING_DATA (data->string), data->bi_bufpos); } else if (data->is_modeline) crb->bufpos = data->modeline_charpos; andy At 11:20 AM 7/17/99 -0500, Michael Harnois wrote: >Hier ist etwas ganz upgefukt: > >gcc -c -g -O2 -march=pentium -fno-exceptions -fno-omit-frame-pointer -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include /src/xemacs-21.2/src/redisplay.c >/src/xemacs-21.2/src/redisplay.c: In function `add_emchar_rune': >/src/xemacs-21.2/src/redisplay.c:923: invalid type argument of `->' >make[1]: *** [redisplay.o] Error 1 >make[1]: Leaving directory `/src/xemacs/src' >make: *** [dump-elcs] Error 2 > >-- >Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA >mharnois@willinet.net aa0bt@aa0bt.ampr.org > There can be no transforming of darkness into light and > of apathy into movement without emotion. - Carl Jung > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sun Jul 18 15:13:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA26336 for xemacs-beta-out; Sun, 18 Jul 1999 15:13:10 -0400 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 PAA26332 for ; Sun, 18 Jul 1999 15:13:08 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA10636; Sun, 18 Jul 1999 12:12:54 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-22.beasys.com [192.168.11.22]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA20948; Sun, 18 Jul 1999 12:12:51 -0700 (PDT) Message-Id: <3.0.5.32.19990718201310.00a43210@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 18 Jul 1999 20:13:10 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Putting it all together In-Reply-To: References: <3.0.5.32.19990718180355.00a254f0@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 07:22 PM 7/18/99 +0200, Jan Vroonhof wrote: >Andy Piper writes: > >> This patch fixes a few errors in my gutter and widget support and combine >> everything to provide tabbed buffers on devices that support tabbed widgets >> (i.e. only mswindows currently). > >I didn't look in depth at it yet, but the doc strings for the gutter >tab items still contain references to the buffer menus. Oops. I'll check. I thought I got most of them. >P.S. Does anybody know a free Xt based toolkit that has all these >modern widgets? Well LessTif has all but Tab control and Tree view. Ben thinks that I should write a tab control for lwlib but I'm not sure I am sufficiently motivated (or able). Doing the Motif stuff was bad enough without building my own toolkit. I have to address Steve's concerns still as well. So if anyone knows of one, I'm happy to try and support some of the more arcane widgets. I think Tk might do some of this but supporting it would be hard. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Sun Jul 18 15:24:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA26852 for xemacs-beta-out; Sun, 18 Jul 1999 15:24:15 -0400 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 PAA26844 for ; Sun, 18 Jul 1999 15:24:13 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA16497 for ; Sun, 18 Jul 1999 21:24:11 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0041j; Sun Jul 18 21:24:06 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA11016; Sun, 18 Jul 1999 21:24:06 +0200 To: xemacs-beta@xemacs.org Subject: Re: Putting it all together References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@london.beasys.com> From: Jan Vroonhof Date: 18 Jul 1999 21:24:05 +0200 In-Reply-To: Andy Piper's message of "Sun, 18 Jul 1999 20:13:10 +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: Andy Piper writes: > Well LessTif has all but Tab control and Tree view. Ben thinks that I > should write a tab control for lwlib but I'm not sure I am sufficiently > motivated (or able). Doing the Motif stuff was bad enough without building > my own toolkit. I have to address Steve's concerns still as well. There seem to be a pure Xt tab widget at http://www.best.com/~falconer/Widgets/ Jan From owner-xemacs-beta@xemacs.org Sun Jul 18 16:19:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA28038 for xemacs-beta-out; Sun, 18 Jul 1999 16:19:30 -0400 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 QAA28034 for ; Sun, 18 Jul 1999 16:19:27 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 115xP7-0007TM-00 for ; Sun, 18 Jul 1999 22:19:21 +0200 To: XEmacs Beta List Subject: Re: adjust gdbinit to current lrecord implementation References: <87g12n2k0a.fsf@eng.cam.ac.uk> 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 Jul 1999 22:19:20 +0200 In-Reply-To: Gunnar Evermann's message of "17 Jul 1999 19:45:09 +0100" Message-ID: <87yagdemnr.fsf@pc-hrvoje.srce.hr> Lines: 12 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > This has been annoying me for quite some time now. Am I the only > person who actually uses gdb You aren't! I was incredibly annoyed by `pobj' not working any longer, but I didn't know exactly when it broke nor did I have time to investigate. Thanks for fixing it! (You may wish to make a similar patch for .dbxrc if you are into dbx.) From owner-xemacs-beta@xemacs.org Sun Jul 18 16:24:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA28188 for xemacs-beta-out; Sun, 18 Jul 1999 16:24:59 -0400 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 QAA28180 for ; Sun, 18 Jul 1999 16:24:50 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 115xUL-0007Td-00 for ; Sun, 18 Jul 1999 22:24:45 +0200 To: XEmacs Beta List Subject: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again 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 Jul 1999 22:24:44 +0200 Message-ID: <87so6lemer.fsf@pc-hrvoje.srce.hr> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've just hit an old bug that I often saw reported but never experienced myself. I always start Gnus using the toolbar "news" button, which opens up a nice Gnus frame and removes it when you press `q' in Gnus Group buffer. Yesterday I switched to WindowMaker and configured it to automatically place the Gnus frame to a different workspace (I used to do this manually). Since then, `q' signals the "Attempt to delete the sole visible or iconified frame". The same error can be repeated by simply pressing `C-x 5 0' in the frame in another workspace. I remember that Jan did some work with this bug. Jan, I'll provide any data you might need to fix this. From owner-xemacs-beta@xemacs.org Sun Jul 18 21:59:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA02964 for xemacs-beta-out; Sun, 18 Jul 1999 21:59:12 -0400 Received: from nbecker.fred.net (nbecker.fred.net [208.238.64.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA02961 for ; Sun, 18 Jul 1999 21:59:10 -0400 Received: from neal by nbecker.fred.net with local (Exim 1.90 #3) for xemacs-beta@xemacs.org id 1162ge-0001Pp-00; Sun, 18 Jul 1999 21:57:48 -0400 To: xemacs-beta@xemacs.org Subject: buffer.h is screwed w/no error checking Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 18 Jul 1999 21:57:48 -0400 Message-ID: <87k8rxqu3n.fsf@nbecker.fred.net> Lines: 2 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: INC_CHARBYTIND is not defined if --error-checking=none in the latest CVS. From owner-xemacs-beta@xemacs.org Mon Jul 19 00:45:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA06962 for xemacs-beta-out; Mon, 19 Jul 1999 00:45:50 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA06958 for ; Mon, 19 Jul 1999 00:45:46 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA10515 for ; Mon, 19 Jul 1999 13:45:38 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "18 Jul 1999 22:24:44 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 19 Jul 1999 13:45:31 +0900 Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > I've just hit an old bug that I often saw reported but never > experienced myself. I always start Gnus using the toolbar "news" > button, which opens up a nice Gnus frame and removes it when you press > `q' in Gnus Group buffer. > Yesterday I switched to WindowMaker and configured it to automatically > place the Gnus frame to a different workspace (I used to do this > manually). Since then, `q' signals the "Attempt to delete the sole > visible or iconified frame". The same error can be repeated by simply > pressing `C-x 5 0' in the frame in another workspace. > I remember that Jan did some work with this bug. Jan, I'll provide > any data you might need to fix this. This is weird. When I run WindowMaker I *don't* experience this problem and when I'm in CDE I do. I am using both WindowMaker (run straight out of XDM on TurboLinux) and 0.60.0 running in the OpenWindows environment (selected via OW_WINDOW_MANAGER in .dtprofile) on Solaris. It is very easy to reproduce in CDE. Start XEmacs, create a second frame by any means, move it to another workspace via the WM frame menu, switch to the other workspace by clicking on the ugly box at the bottom of the screen and attempt to delete the XEmacs frame with `C-x 5 0'. -- $BMn2V;^$K5"$i$:GK6@:F$S>H$i$5$:(B (Don't cry over spilled milk) From owner-xemacs-beta@xemacs.org Mon Jul 19 00:57:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA07212 for xemacs-beta-out; Mon, 19 Jul 1999 00:57:05 -0400 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 AAA07209 for ; Mon, 19 Jul 1999 00:57:03 -0400 Received: by crystal.WonderWorks.COM id QQgyml09586; Sun, 18 Jul 1999 21:57:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14226.45085.210860.747591@crystal.WonderWorks.COM> Date: Sun, 18 Jul 1999 21:57:01 -0700 (PDT) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again In-Reply-To: References: <87so6lemer.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: Are you sure this is a bug? The point of the check, obviously, is to prevent you from being left with just unmapped frame and thus have no way to control the running XEmacs. We have a variable, allow-deletion-of-last-visible-frame, that lets you go ahead and delete the last visible frame. So far no one has mentioned this variable's value. From owner-xemacs-beta@xemacs.org Mon Jul 19 01:47:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA08644 for xemacs-beta-out; Mon, 19 Jul 1999 01:47:06 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA08636 for ; Mon, 19 Jul 1999 01:46:46 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id OAA13899 for ; Mon, 19 Jul 1999 14:46:41 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `xemacs-packages/{Makefile,[XL]*.rules}' References: <87zp0wwkdh.fsf@bittersweet.sysc.pdx.edu> X-Attribution: sb From: SL Baur In-Reply-To: karlheg@cathcart.sysc.pdx.edu's message of "16 Jul 1999 10:54:34 -0700" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 19 Jul 1999 14:46:34 +0900 Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Karl M Hegbloom writes in xemacs-beta@xemacs.org: > Shouldn't the configurables at the top of XEmacs.rules be pulled out > and put into `Local.rules' as well? XEmacs.rules isn't pulled into the toplevel Makefile or the first level Makefiles. There is a path problem as XEmacs.rules assumes it will only be included two directory levels down from the top. Yes, I agree that it should be possible to have a non-CVSed local file provide those defaults. > I've made a few modifications to `XEmacs.rules' to make it possible > to run in place from a CVS checkout. It is only an accident that this works. Count on it being broken by future updates to the installed packaging structure. -- $B6b$,$b$N$r8@$&(B (Money talks) From owner-xemacs-beta@xemacs.org Mon Jul 19 01:52:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA08776 for xemacs-beta-out; Mon, 19 Jul 1999 01:52:16 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA08771 for ; Mon, 19 Jul 1999 01:52:08 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id OAA13538 for ; Mon, 19 Jul 1999 14:40:12 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> X-Attribution: sb From: SL Baur In-Reply-To: Kyle Jones's message of "Sun, 18 Jul 1999 21:57:01 -0700 (PDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 19 Jul 1999 14:40:06 +0900 Message-ID: Lines: 30 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes in xemacs-beta@xemacs.org: > Are you sure this is a bug? I am sure it is a bug, though I don't understand why Hrvoje is seeing a situation reversed from what I see. I first experienced the problem with olvwm and it _was_ fixed by a patch. > The point of the check, obviously, is to prevent you from being left > with just unmapped frame and thus have no way to control the running > XEmacs. We have a variable, allow-deletion-of-last-visible-frame, > that lets you go ahead and delete the last visible frame. So far no > one has mentioned this variable's value. The situation I was referring to shouldn't involve this variable. I use virtual window managers and having a frame visible in an undisplayed workspace shouldn't trigger this message. In any event, I do not personally diddle with the value of `allow-deletion-of-last-visible-frame' and the XEmacs behavior is different between CDE and WindowMaker. `allow-deletion-of-last-visible-frame' is a built-in boolean variable. Value: t Documentation: *Non-nil means to assume the force option to delete-frame. -- $B6b$,$b$N$r8@$&(B (Money talks) From owner-xemacs-beta@xemacs.org Mon Jul 19 02:01:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA08973 for xemacs-beta-out; Mon, 19 Jul 1999 02:01:48 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA08970 for ; Mon, 19 Jul 1999 02:01:45 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA14784 for ; Mon, 19 Jul 1999 15:01:36 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Shift Delete on Cygwin/Xemacs-21.1-p2 References: <14223.4521.211361.240551@cerise.sensei.co.uk> X-Attribution: sb From: SL Baur In-Reply-To: Glynn Clements's message of "Fri, 16 Jul 1999 12:04:09 +0100 (BST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 19 Jul 1999 15:01:29 +0900 Message-ID: Lines: 33 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Glynn Clements writes in xemacs-beta@xemacs.org: > Dr. Volker Zell wrote: >> Hi >> >> When I do C-h k and then Control Insert or Shift Insert I get: >> >> C-insert runs `copy-primary-selection' >> Sh-insert runs `yank-clipboard-selection' >> >> but C-h k and then pressing Shift Delete gives me: >> >> DEL runs `scroll-down' I see the same thing on both Solaris and Linux. >> It seems that Sh-delete is not recognized on my system. >> >> Any hint ? ... > I just added > (define-key global-map '(shift delete) 'kill-primary-selection) > (define-key global-map '(control delete) 'delete-primary-selection) > to my ~/.emacs. But do they do anything? They don't do anything for me. I hit Shift-Delete and get Delete. -- $B1+9_$C$FCO8G$^$k(B (Adversity builds character) From owner-xemacs-beta@xemacs.org Mon Jul 19 02:02:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA08980 for xemacs-beta-out; Mon, 19 Jul 1999 02:02:01 -0400 Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA08977 for ; Mon, 19 Jul 1999 02:02:00 -0400 Received: from sparrow.bear.com (user-2ive0c4.dialup.mindspring.com [165.247.1.132]) by smtp0.mindspring.com (8.8.5/8.8.5) with ESMTP id CAA03864; Mon, 19 Jul 1999 02:01:55 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id CAA18088; Mon, 19 Jul 1999 02:02:02 -0400 Date: Mon, 19 Jul 1999 06:02:01 +0000 ( ) From: Justin Vallon To: Kyle Jones cc: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again In-Reply-To: <14226.45085.210860.747591@crystal.WonderWorks.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Sun, 18 Jul 1999, Kyle Jones wrote: > Are you sure this is a bug? The point of the check, obviously, is > to prevent you from being left with just unmapped frame and thus > have no way to control the running XEmacs. We have a variable, > allow-deletion-of-last-visible-frame, that lets you go ahead and > delete the last visible frame. So far no one has mentioned this > variable's value. Though barely X literately, I think I have seen this too. I would suppose that the "other workspaces" frames are being unmapped when the WM switches workspaces. XEmacs then incorrectly believes that there would be no way to get back to the other frames, though the "switch to the other workspace" button would re-map the frames. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Mon Jul 19 04:59:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA12357 for xemacs-beta-out; Mon, 19 Jul 1999 04:59:09 -0400 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 EAA12353 for ; Mon, 19 Jul 1999 04:59:08 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA06233 for ; Mon, 19 Jul 1999 10:59:07 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001XM; Mon Jul 19 10:59:01 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA12251; Mon, 19 Jul 1999 10:59:01 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: From: Jan Vroonhof Date: 19 Jul 1999 10:59:00 +0200 In-Reply-To: Justin Vallon's message of "Mon, 19 Jul 1999 06:02:01 +0000 ( )" 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: Justin Vallon writes: > On Sun, 18 Jul 1999, Kyle Jones wrote: > Though barely X literately, I think I have seen this too. I would suppose > that the "other workspaces" frames are being unmapped when the WM switches > workspaces. XEmacs then incorrectly believes that there would be no way > to get back to the other frames, though the "switch to the other > workspace" button would re-map the frames. Yes, i would consider this a window manager bug. It should use a state that maps more naturally on the Workspace concept. FVWM uses Invisible+Mapped which is OK (In fact XEmacs is optimized by that case). Telling the hidden frames they are iconified would also be fine. Jan From owner-xemacs-beta@xemacs.org Mon Jul 19 05:10:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA12690 for xemacs-beta-out; Mon, 19 Jul 1999 05:10:55 -0400 Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA12686; Mon, 19 Jul 1999 05:10:51 -0400 Received: from cerise.sensei.co.uk (dialin.sensei.co.uk [193.132.124.190]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id KAA17625; Mon, 19 Jul 1999 10:15:47 +0100 Received: (from glynn@localhost) by cerise.sensei.co.uk (8.9.3/8.9.3) id UAA01223; Sun, 18 Jul 1999 20:48:52 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14226.12196.351292.426762@cerise.sensei.co.uk> Date: Sun, 18 Jul 1999 20:48:52 +0100 (BST) To: Andy Piper Cc: Jan Vroonhof , xemacs-beta@xemacs.org Subject: Re: Putting it all together In-Reply-To: <3.0.5.32.19990718201310.00a43210@london.beasys.com> References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@london.beasys.com> X-Mailer: VM 6.67 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper wrote: > >> This patch fixes a few errors in my gutter and widget support and combine > >> everything to provide tabbed buffers on devices that support tabbed widgets > >> (i.e. only mswindows currently). > > > >I didn't look in depth at it yet, but the doc strings for the gutter > >tab items still contain references to the buffer menus. > > Oops. I'll check. I thought I got most of them. > > >P.S. Does anybody know a free Xt based toolkit that has all these > >modern widgets? > > Well LessTif has all but Tab control and Tree view. I have code for some Xt tree widgets. I won't know for a few weeks whether I'll have time to support it, but I'll email it to anyone who's interested. -- Glynn Clements From owner-xemacs-beta@xemacs.org Mon Jul 19 05:57:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA13651 for xemacs-beta-out; Mon, 19 Jul 1999 05:57:20 -0400 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 FAA13648 for ; Mon, 19 Jul 1999 05:57:18 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA03810; Mon, 19 Jul 1999 02:57:03 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-222.beasys.com [192.168.11.222]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA19903; Mon, 19 Jul 1999 02:57:00 -0700 (PDT) Message-Id: <3.0.5.32.19990719105713.00a44b80@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jul 1999 10:57:13 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Putting it all together In-Reply-To: References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@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: Got it. Looks like I am going to have to start work on the Athena support as it has most widgets that are necessary. Where can I get Xaw docs? I could not find them in the x distribution. andy At 09:24 PM 7/18/99 +0200, Jan Vroonhof wrote: >Andy Piper writes: > >> Well LessTif has all but Tab control and Tree view. Ben thinks that I >> should write a tab control for lwlib but I'm not sure I am sufficiently >> motivated (or able). Doing the Motif stuff was bad enough without building >> my own toolkit. I have to address Steve's concerns still as well. > >There seem to be a pure Xt tab widget at > >http://www.best.com/~falconer/Widgets/ > >Jan > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 19 05:58:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA13693 for xemacs-beta-out; Mon, 19 Jul 1999 05:58:55 -0400 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 FAA13689 for ; Mon, 19 Jul 1999 05:58:54 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA03855; Mon, 19 Jul 1999 02:58:40 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-221.beasys.com [192.168.11.221]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA20000; Mon, 19 Jul 1999 02:58:37 -0700 (PDT) Message-Id: <3.0.5.32.19990719105857.00a334c0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jul 1999 10:58:57 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Putting it all together In-Reply-To: References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@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: Cool, I'll check it out. andy At 09:24 PM 7/18/99 +0200, Jan Vroonhof wrote: >Andy Piper writes: > >> Well LessTif has all but Tab control and Tree view. Ben thinks that I >> should write a tab control for lwlib but I'm not sure I am sufficiently >> motivated (or able). Doing the Motif stuff was bad enough without building >> my own toolkit. I have to address Steve's concerns still as well. > >There seem to be a pure Xt tab widget at > >http://www.best.com/~falconer/Widgets/ > >Jan > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 19 06:03:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA13831 for xemacs-beta-out; Mon, 19 Jul 1999 06:03:49 -0400 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 GAA13824 for ; Mon, 19 Jul 1999 06:03:47 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA03958; Mon, 19 Jul 1999 03:03:31 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-221.beasys.com [192.168.11.221]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id DAA20296; Mon, 19 Jul 1999 03:03:24 -0700 (PDT) Message-Id: <3.0.5.32.19990719110344.00a59440@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jul 1999 11:03:44 +0100 To: Glynn Clements From: Andy Piper Subject: Re: Putting it all together Cc: Jan Vroonhof , xemacs-beta@xemacs.org In-Reply-To: <14226.12196.351292.426762@cerise.sensei.co.uk> References: <3.0.5.32.19990718201310.00a43210@london.beasys.com> <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@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 08:48 PM 7/18/99 +0100, Glynn Clements wrote: > >Andy Piper wrote: > >> >> This patch fixes a few errors in my gutter and widget support and combine >> >> everything to provide tabbed buffers on devices that support tabbed widgets >> >> (i.e. only mswindows currently). >> > >> >I didn't look in depth at it yet, but the doc strings for the gutter >> >tab items still contain references to the buffer menus. >> >> Oops. I'll check. I thought I got most of them. >> >> >P.S. Does anybody know a free Xt based toolkit that has all these >> >modern widgets? >> >> Well LessTif has all but Tab control and Tree view. > >I have code for some Xt tree widgets. I won't know for a few weeks >whether I'll have time to support it, but I'll email it to anyone >who's interested. Cool. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 19 06:50:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA14567 for xemacs-beta-out; Mon, 19 Jul 1999 06:50:52 -0400 Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA14563; Mon, 19 Jul 1999 06:50:47 -0400 Received: from cerise.sensei.co.uk (dialin.sensei.co.uk [193.132.124.190]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id LAA18303; Mon, 19 Jul 1999 11:55:43 +0100 Received: (from glynn@localhost) by cerise.sensei.co.uk (8.9.3/8.9.3) id LAA00695; Mon, 19 Jul 1999 11:00:29 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14226.63292.518348.167869@cerise.sensei.co.uk> Date: Mon, 19 Jul 1999 11:00:28 +0100 (BST) To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: Shift Delete on Cygwin/Xemacs-21.1-p2 In-Reply-To: References: <14223.4521.211361.240551@cerise.sensei.co.uk> X-Mailer: VM 6.67 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote: > > I just added > > > (define-key global-map '(shift delete) 'kill-primary-selection) > > (define-key global-map '(control delete) 'delete-primary-selection) > > > to my ~/.emacs. > > But do they do anything? They don't do anything for me. I hit > Shift-Delete and get Delete. They work fine for me (21.0-b66, Linux; I don't recall any problems with 21.1-p2 on Cygwin either, but I don't have that one available right now). -- Glynn Clements From owner-xemacs-beta@xemacs.org Mon Jul 19 06:57:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA14701 for xemacs-beta-out; Mon, 19 Jul 1999 06:57:40 -0400 Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA14697; Mon, 19 Jul 1999 06:57:37 -0400 Received: from cerise.sensei.co.uk (dialin.sensei.co.uk [193.132.124.190]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id MAA18349; Mon, 19 Jul 1999 12:02:37 +0100 Received: (from glynn@localhost) by cerise.sensei.co.uk (8.9.3/8.9.3) id LAA00839; Mon, 19 Jul 1999 11:53:37 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14227.944.937688.135869@cerise.sensei.co.uk> Date: Mon, 19 Jul 1999 11:53:36 +0100 (BST) To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Putting it all together In-Reply-To: <3.0.5.32.19990719105713.00a44b80@london.beasys.com> References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@london.beasys.com> <3.0.5.32.19990719105713.00a44b80@london.beasys.com> X-Mailer: VM 6.67 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper wrote: > Where can I get Xaw docs? I could not find them in the x > distribution. If you build from the XFree86 source distribution, they are in /xc/doc/hardcopy/Xaw/widgets.PS.Z The nroff sources are in /xc/doc/specs/Xaw/ Unfortunately they don't seem to be shipped with any of the XFree86 binary packages. NB: I have text versions of the documents in /xc/doc/specs if anyone wants them. -- Glynn Clements From owner-xemacs-beta@xemacs.org Mon Jul 19 07:50:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA15964 for xemacs-beta-out; Mon, 19 Jul 1999 07:50:47 -0400 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 HAA15960 for ; Mon, 19 Jul 1999 07:50:41 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id EAA06706; Mon, 19 Jul 1999 04:50:26 -0700 (PDT) Received: from andyppc (lhr-modem7.beasys.com [10.5.1.18]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id EAA26676; Mon, 19 Jul 1999 04:50:15 -0700 (PDT) Message-Id: <3.0.5.32.19990719125026.00a6f910@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jul 1999 12:50:26 +0100 To: Neal Becker , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: buffer.h is screwed w/no error checking In-Reply-To: <87k8rxqu3n.fsf@nbecker.fred.net> 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 PM 7/18/99 -0400, Neal Becker wrote: >INC_CHARBYTIND is not defined if --error-checking=none in the latest >CVS. Fixed, thanks. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 19 08:40:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA17024 for xemacs-beta-out; Mon, 19 Jul 1999 08:40:11 -0400 Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA17020; Mon, 19 Jul 1999 08:40:05 -0400 Received: from cerise.sensei.co.uk (dialin.sensei.co.uk [193.132.124.190]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id NAA18859; Mon, 19 Jul 1999 13:45:05 +0100 Received: (from glynn@localhost) by cerise.sensei.co.uk (8.9.3/8.9.3) id NAA02105; Mon, 19 Jul 1999 13:36:06 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14227.7093.854495.67453@cerise.sensei.co.uk> Date: Mon, 19 Jul 1999 13:36:05 +0100 (BST) To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Putting it all together In-Reply-To: <3.0.5.32.19990719110344.00a59440@london.beasys.com> References: <3.0.5.32.19990718201310.00a43210@london.beasys.com> <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990719110344.00a59440@london.beasys.com> X-Mailer: VM 6.67 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta66) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper wrote: > > I have code for some Xt tree widgets. I won't know for a few weeks > > whether I'll have time to support it, but I'll email it to anyone > > who's interested. > > Cool. Is that `Cool; I'll have a copy'? or just `Cool'? NB: The code should now be available from ftp://sensei.co.uk/misc/iWidget-0.1.20.tar.gz ftp://sensei.co.uk/misc/iWidget-0.1.20.tar.bz2 The tree widget is in ITree{.c,.h,P.h}. It currently inherits from the IPrimitive widget, but it should be straightforward to make it inherit from either Xt's coreWidgetClass class or Xaw's simpleWidgetClass instead. -- Glynn Clements From owner-xemacs-beta@xemacs.org Mon Jul 19 10:51:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA20990 for xemacs-beta-out; Mon, 19 Jul 1999 10:51:34 -0400 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 KAA20983 for ; Mon, 19 Jul 1999 10:51:30 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 116ElK-0000So-00 for ; Mon, 19 Jul 1999 16:51:26 +0200 To: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@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: 19 Jul 1999 16:51:25 +0200 In-Reply-To: Kyle Jones's message of "Sun, 18 Jul 1999 21:57:01 -0700 (PDT)" Message-ID: <87673gn15e.fsf@pc-hrvoje.srce.hr> Lines: 10 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Are you sure this is a bug? The point of the check, obviously, is > to prevent you from being left with just unmapped frame and thus > have no way to control the running XEmacs. It's a bug. I am not talking about the last XEmacs frame, but about the last frame on any one workspace. That means that if I configure Gnus or VM to start up in a separate frame on a different workspace, I can't exit it without the FORCE argument. From owner-xemacs-beta@xemacs.org Mon Jul 19 10:55:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA21159 for xemacs-beta-out; Mon, 19 Jul 1999 10:55:58 -0400 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 KAA21155 for ; Mon, 19 Jul 1999 10:55:55 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id HAA16476; Mon, 19 Jul 1999 07:55:37 -0700 (PDT) Received: from andyppc (lhr-modem3.beasys.com [10.5.1.14]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id HAA16943; Mon, 19 Jul 1999 07:55:32 -0700 (PDT) Message-Id: <3.0.5.32.19990719142318.00a56e10@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jul 1999 14:23:18 +0100 To: Glynn Clements From: Andy Piper Subject: Re: Putting it all together Cc: xemacs-beta@xemacs.org In-Reply-To: <14227.7093.854495.67453@cerise.sensei.co.uk> References: <3.0.5.32.19990719110344.00a59440@london.beasys.com> <3.0.5.32.19990718201310.00a43210@london.beasys.com> <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990719110344.00a59440@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 01:36 PM 7/19/99 +0100, Glynn Clements wrote: > >Andy Piper wrote: > >> > I have code for some Xt tree widgets. I won't know for a few weeks >> > whether I'll have time to support it, but I'll email it to anyone >> > who's interested. >> >> Cool. > >Is that `Cool; I'll have a copy'? or just `Cool'? Probably the latter. At the moment the pressure is for an X tab widget as I have put code in XEmacs that will use it if available. I can think of lots of cool uses for a tree widget but I probably won't be doing the coding and therefore don't feel the effort warrants the value at the moment. But who knows, the amount of time I'm spending in hotels at the moment I'll probably get around to it at some stage. >NB: The code should now be available from > > ftp://sensei.co.uk/misc/iWidget-0.1.20.tar.gz > ftp://sensei.co.uk/misc/iWidget-0.1.20.tar.bz2 > >The tree widget is in ITree{.c,.h,P.h}. It currently inherits from the >IPrimitive widget, but it should be straightforward to make it inherit >from either Xt's coreWidgetClass class or Xaw's simpleWidgetClass >instead. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 19 11:20:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA22163 for xemacs-beta-out; Mon, 19 Jul 1999 11:20:19 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA22159 for ; Mon, 19 Jul 1999 11:20:15 -0400 Received: from metheny.enst.fr (vs2OnnXFbxfnwvWQKf/KR4R89zsPmzJx@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id RAA26817; Mon, 19 Jul 1999 17:20:14 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id RAA00787; Mon, 19 Jul 1999 17:20:10 +0200 (MET DST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87673gn15e.fsf@pc-hrvoje.srce.hr> 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: Hrvoje Niksic's message of "19 Jul 1999 16:51:25 +0200" 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: 37 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > Kyle Jones writes: > > > Are you sure this is a bug? The point of the check, obviously, is > > to prevent you from being left with just unmapped frame and thus > > have no way to control the running XEmacs. > > It's a bug. I am not talking about the last XEmacs frame, but about > the last frame on any one workspace. That means that if I configure > Gnus or VM to start up in a separate frame on a different workspace, I > can't exit it without the FORCE argument. Still, it's not a bug in XEmacs, but rather a misconception of the X Windows' states[1] and the way window managers achieve their desired effect. Basically, what happens is that a window on another desktop is really unmapped in the X sense, and XEmacs has no way to know that this window can be visible again (thanks to a WM command). In the best situation, some window managers will supply more information through a specific communication protocol, which means that if we want to improve XEmacs' concept of window states, we'll have to write specific code for all window managers on earth. In the worst case, some window managers won't give you any information. For them, it will be impossible to fix the problem you describe. Footnotes: [1] To be honest, at the time X was written, there was probably no concept of workspace yet. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Mon Jul 19 11:31:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA22615 for xemacs-beta-out; Mon, 19 Jul 1999 11:31:24 -0400 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 LAA22612 for ; Mon, 19 Jul 1999 11:31:17 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA09715 for ; Mon, 19 Jul 1999 17:31:16 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002N.; Mon Jul 19 17:31:09 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA13711; Mon, 19 Jul 1999 17:31:09 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87673gn15e.fsf@pc-hrvoje.srce.hr> From: Jan Vroonhof Date: 19 Jul 1999 17:31:08 +0200 In-Reply-To: Hrvoje Niksic's message of "19 Jul 1999 16:51:25 +0200" 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: Hrvoje Niksic writes: > It's a bug. I am not talking about the last XEmacs frame, but about > the last frame on any one workspace. That means that if I configure > Gnus or VM to start up in a separate frame on a different workspace, I > can't exit it without the FORCE argument. It's a bug, but is in the window manager as far as I am concerned. Jan From owner-xemacs-beta@xemacs.org Mon Jul 19 11:45:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA23324 for xemacs-beta-out; Mon, 19 Jul 1999 11:45:36 -0400 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 LAA23319 for ; Mon, 19 Jul 1999 11:45:33 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id LAA12320 for xemacs-beta@xemacs.org; Mon, 19 Jul 1999 11:45:36 -0400 Date: Mon, 19 Jul 1999 11:45:36 -0400 From: Olivier Galibert To: XEmacs Developers Subject: Re: adjust gdbinit to current lrecord implementation Message-ID: <19990719114536.B12284@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Developers References: <87g12n2k0a.fsf@eng.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <87g12n2k0a.fsf@eng.cam.ac.uk>; from Gunnar Evermann on Sat, Jul 17, 1999 at 07:45:09PM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Sat, Jul 17, 1999 at 07:45:09PM +0100, Gunnar Evermann wrote: > This has been annoying me for quite some time now. Am I the only > person who actually uses gdb or noticed Martin's testsuite at the end > of gdbinit? :-) I used to use gdb, but without this gdbinit. Thanks for having pointed it to me :-) OG. PS: Next time, please send the patch to xemacs-patches@xemacs.org rather than xemacs-beta. I'm doing it for you this time. From owner-xemacs-beta@xemacs.org Mon Jul 19 11:48:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA23501 for xemacs-beta-out; Mon, 19 Jul 1999 11:48:25 -0400 Received: from home.plutonium.net (home.plutonium.net [208.244.78.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA23473; Mon, 19 Jul 1999 11:48:08 -0400 Received: from dogbert (skaro.plutonium.net [208.244.78.7]) by home.plutonium.net (8.8.7/8.8.6) with SMTP id KAA01542; Mon, 19 Jul 1999 10:50:31 -0500 Message-ID: <006301bed1fe$ea081850$074ef4d0@dogbert.plutonium.net> From: "James N. Potts" To: "XEmacs Beta List" Cc: Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again Date: Mon, 19 Jul 1999 10:53:58 -0500 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: This also arises under NT (with different circumstances): Start with a single frame. Press the news button. Minimize the original frame. Click the Exit Gnus button. The result: "Attempt to delete the sole visible or iconified frame" -Jim -----Original Message----- From: Hrvoje Niksic To: XEmacs Beta List Date: Monday, July 19, 1999 10:25 AM Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again >Kyle Jones writes: > >> Are you sure this is a bug? The point of the check, obviously, is >> to prevent you from being left with just unmapped frame and thus >> have no way to control the running XEmacs. > >It's a bug. I am not talking about the last XEmacs frame, but about >the last frame on any one workspace. That means that if I configure >Gnus or VM to start up in a separate frame on a different workspace, I >can't exit it without the FORCE argument. > From owner-xemacs-beta@xemacs.org Mon Jul 19 12:05:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA23997 for xemacs-beta-out; Mon, 19 Jul 1999 12:05:16 -0400 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 MAA23994 for ; Mon, 19 Jul 1999 12:05:14 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA12199 for ; Mon, 19 Jul 1999 18:05:10 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002yS; Mon Jul 19 18:05:02 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA13759; Mon, 19 Jul 1999 18:05:02 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <006301bed1fe$ea081850$074ef4d0@dogbert.plutonium.net> From: Jan Vroonhof Date: 19 Jul 1999 18:05:01 +0200 In-Reply-To: "James N. Potts"'s message of "Mon, 19 Jul 1999 10:53:58 -0500" 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: "James N. Potts" writes: > This also arises under NT (with different circumstances): > Start with a single frame. > Press the news button. > Minimize the original frame. > Click the Exit Gnus button. > > The result: "Attempt to delete the sole visible or iconified frame" Can you also reproduce this with frames created by C-x 5 2 ?, i.e. C-x 5 2 C-x 5 o (little ooo) minimize other frame C-x 5 0 (zero) Jan From owner-xemacs-beta@xemacs.org Mon Jul 19 13:19:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26679 for xemacs-beta-out; Mon, 19 Jul 1999 13:19:53 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26675 for ; Mon, 19 Jul 1999 13:19:51 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id MAA04303; Mon, 19 Jul 1999 12:19:46 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14227.24114.649062.933218@buffalo.fnal.gov> Date: Mon, 19 Jul 1999 12:19:46 -0500 (CDT) To: xemacs-beta@xemacs.org Subject: tshell doesn't like "!." X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I just discovered that if I do M-x tshell RET then type "!." at the shell prompt, XEmacs goes into an infloop that even C-g won't get me out of. Anybody else see this? 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Linux 2.2.10 SMP /lib/libc-2.1.1.so I'll try to work up a patch when I get enough time to study the problem. From owner-xemacs-beta@xemacs.org Mon Jul 19 13:38:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA27453 for xemacs-beta-out; Mon, 19 Jul 1999 13:38:37 -0400 Received: from home.plutonium.net (home.plutonium.net [208.244.78.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA27450 for ; Mon, 19 Jul 1999 13:38:36 -0400 Received: from dogbert (skaro.plutonium.net [208.244.78.7]) by home.plutonium.net (8.8.7/8.8.6) with SMTP id MAA05100; Mon, 19 Jul 1999 12:41:01 -0500 Message-ID: <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> From: "James N. Potts" To: "Jan Vroonhof" Cc: Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again Date: Mon, 19 Jul 1999 12:44:27 -0500 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: >"James N. Potts" writes: > >> This also arises under NT (with different circumstances): >> Start with a single frame. >> Press the news button. >> Minimize the original frame. >> Click the Exit Gnus button. >> >> The result: "Attempt to delete the sole visible or iconified frame" > >Can you also reproduce this with frames created by C-x 5 2 ?, i.e. > >C-x 5 2 >C-x 5 o (little ooo) >minimize other frame >C-x 5 0 (zero) Yes. -Jim From owner-xemacs-beta@xemacs.org Mon Jul 19 13:57:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA28286 for xemacs-beta-out; Mon, 19 Jul 1999 13:57:56 -0400 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 NAA28283; Mon, 19 Jul 1999 13:57:51 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id KAA05537; Mon, 19 Jul 1999 10:59:25 -0700 To: Andy Piper , xemacs-beta@xemacs.org Subject: Debian XBooks (Was: Re: Putting it all together) References: <3.0.5.32.19990718180355.00a254f0@london.beasys.com> <3.0.5.32.19990718201310.00a43210@london.beasys.com> <3.0.5.32.19990719105713.00a44b80@london.beasys.com> <14227.944.937688.135869@cerise.sensei.co.uk> 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" Date: 19 Jul 1999 10:59:25 -0700 In-Reply-To: Glynn Clements's message of "Mon, 19 Jul 1999 11:53:36 +0100 (BST)" Message-ID: <87k8rwbjwi.fsf_-_@bittersweet.sysc.pdx.edu> Lines: 223 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Those docs are in the Debian `xbooks' package. If you don't have a Debian box handy, you can unpack the .deb using `ar' and `tar'. There's a search clicker at ; look for "xbooks", and follow the link to download it. Here's the contents of the .list file showing what's inside the tar inside the deb. /. /usr /usr/doc /usr/doc/xbooks /usr/doc/xbooks/BDF /usr/doc/xbooks/BDF/bdf.ps.gz /usr/doc/xbooks/CTEXT /usr/doc/xbooks/CTEXT/ctext.ps.gz /usr/doc/xbooks/FSProtocol /usr/doc/xbooks/FSProtocol/fsproto.ps.gz /usr/doc/xbooks/ICCCM /usr/doc/xbooks/ICCCM/icccm.ps.gz /usr/doc/xbooks/ICCCM/icccm.idx.ps.gz /usr/doc/xbooks/ICE /usr/doc/xbooks/ICE/ice.ps.gz /usr/doc/xbooks/ICE/ICElib.ps.gz /usr/doc/xbooks/PEX5 /usr/doc/xbooks/PEX5/PEXlib /usr/doc/xbooks/PEX5/PEXlib/PEXlib.ps.gz /usr/doc/xbooks/PEX5/PEXlib/PEXlib.idx.ps.gz /usr/doc/xbooks/PEX5/Proto /usr/doc/xbooks/PEX5/Proto/encoding_doc.ps.gz /usr/doc/xbooks/PEX5/Proto/encoding_toc.ps.gz /usr/doc/xbooks/PEX5/Proto/protocol_doc.ps.gz /usr/doc/xbooks/PEX5/Proto/protocol_toc.ps.gz /usr/doc/xbooks/PEX5/SI /usr/doc/xbooks/PEX5/SI/Arch_Spec /usr/doc/xbooks/PEX5/SI/Arch_Spec/cover.ps.gz /usr/doc/xbooks/PEX5/SI/Arch_Spec/figures.ps.gz /usr/doc/xbooks/PEX5/SI/Arch_Spec/index.ps.gz /usr/doc/xbooks/PEX5/SI/Arch_Spec/tables.ps.gz /usr/doc/xbooks/PEX5/SI/Arch_Spec/contents.ps.gz /usr/doc/xbooks/PEX5/SI/Arch_Spec/doc.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide /usr/doc/xbooks/PEX5/SI/Portg_Guide/cover.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide/figures.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide/index.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide/tables.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide/contents.ps.gz /usr/doc/xbooks/PEX5/SI/Portg_Guide/doc.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide /usr/doc/xbooks/PEX5/SI/User_Guide/cover.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide/figures.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide/index.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide/tables.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide/contents.ps.gz /usr/doc/xbooks/PEX5/SI/User_Guide/doc.ps.gz /usr/doc/xbooks/RX /usr/doc/xbooks/RX/RX.ps.gz /usr/doc/xbooks/SM /usr/doc/xbooks/SM/SMlib.ps.gz /usr/doc/xbooks/SM/xsmp.ps.gz /usr/doc/xbooks/X11 /usr/doc/xbooks/X11/xlib.ps.gz /usr/doc/xbooks/X11/xlib.idx.ps.gz /usr/doc/xbooks/XDMCP /usr/doc/xbooks/XDMCP/xdmcp.ps.gz /usr/doc/xbooks/XIE /usr/doc/xbooks/XIE/SI /usr/doc/xbooks/XIE/SI/xieSIarch.ps.gz /usr/doc/xbooks/XIE/XIEProto /usr/doc/xbooks/XIE/XIEProto/apc_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch1_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch2_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch3_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch4_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch6_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch7_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch8_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch9_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/cmatch.ps.gz /usr/doc/xbooks/XIE/XIEProto/frnt_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/apa_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/apb_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/ch5_xie.ps.gz /usr/doc/xbooks/XIE/XIEProto/overview.ps.gz /usr/doc/xbooks/XIE/XIElib /usr/doc/xbooks/XIE/XIElib/xielib.ps.gz /usr/doc/xbooks/XIM /usr/doc/xbooks/XIM/xim.ps.gz /usr/doc/xbooks/XKB /usr/doc/xbooks/XKB/XKBlib.ps.gz /usr/doc/xbooks/XKB/XKBproto.ps.gz /usr/doc/xbooks/XLFD /usr/doc/xbooks/XLFD/xlfd.ps.gz /usr/doc/xbooks/XPRINT /usr/doc/xbooks/XPRINT/xp_proto.ps.gz /usr/doc/xbooks/XPRINT/xp_library.ps.gz /usr/doc/xbooks/XProtocol /usr/doc/xbooks/XProtocol/proto.ps.gz /usr/doc/xbooks/XProtocol/proto.idx.ps.gz /usr/doc/xbooks/Xaw /usr/doc/xbooks/Xaw/widg.idx.ps.gz /usr/doc/xbooks/Xaw/widgets.ps.gz /usr/doc/xbooks/Xext /usr/doc/xbooks/Xext/dbe.ps.gz /usr/doc/xbooks/Xext/buffer.ps.gz /usr/doc/xbooks/Xext/lbxalg.ps.gz /usr/doc/xbooks/Xext/mit-shm.ps.gz /usr/doc/xbooks/Xext/record.ps.gz /usr/doc/xbooks/Xext/recordlib.ps.gz /usr/doc/xbooks/Xext/security.ps.gz /usr/doc/xbooks/Xext/shape.ps.gz /usr/doc/xbooks/Xext/shapelib.ps.gz /usr/doc/xbooks/Xext/sync.ps.gz /usr/doc/xbooks/Xext/synclib.ps.gz /usr/doc/xbooks/Xext/xtestlib.ps.gz /usr/doc/xbooks/Xext/bigreq.ps.gz /usr/doc/xbooks/Xext/AppGroup.ps.gz /usr/doc/xbooks/Xext/dbelib.ps.gz /usr/doc/xbooks/Xext/lbx.ps.gz /usr/doc/xbooks/Xext/xtest.ps.gz /usr/doc/xbooks/Xext/xc-misc.ps.gz /usr/doc/xbooks/Xi /usr/doc/xbooks/Xi/lib.ps.gz /usr/doc/xbooks/Xi/proto.ps.gz /usr/doc/xbooks/Xi/port.ps.gz /usr/doc/xbooks/Xmu /usr/doc/xbooks/Xmu/xmu.ps.gz /usr/doc/xbooks/Xserver /usr/doc/xbooks/Xserver/ddx.ps.gz /usr/doc/xbooks/Xserver/secint.ps.gz /usr/doc/xbooks/Xserver/Xprt.ps.gz /usr/doc/xbooks/Xserver/analysis.ps.gz /usr/doc/xbooks/Xserver/appgroup.ps.gz /usr/doc/xbooks/Xserver/fontlib.ps.gz /usr/doc/xbooks/Xt /usr/doc/xbooks/Xt/intr.idx.ps.gz /usr/doc/xbooks/Xt/intrinsics.ps.gz /usr/doc/xbooks/i18n /usr/doc/xbooks/i18n/LocaleDB.ps.gz /usr/doc/xbooks/i18n/Trans.ps.gz /usr/doc/xbooks/i18n/Framework.ps.gz /usr/doc/xbooks/rstart /usr/doc/xbooks/rstart/rstart.ps.gz /usr/doc/xbooks/test /usr/doc/xbooks/test/xsuite /usr/doc/xbooks/test/xsuite/userguide.ps.gz /usr/doc/xbooks/xfs /usr/doc/xbooks/xfs/design.ps.gz /usr/doc/xbooks/xtrans /usr/doc/xbooks/xtrans/Xtrans.ps.gz /usr/doc/xbooks/DPMS /usr/doc/xbooks/DPMS/DPMS.ps.gz /usr/doc/xbooks/DPMS/DPMSLib.ps.gz /usr/doc/xbooks/copyright /usr/doc/xbooks/changelog.Debian.gz /usr/share /usr/share/doc-base /usr/share/doc-base/xbooks-Xserver-porting /usr/share/doc-base/xbooks-Xext-DBE-protocol /usr/share/doc-base/xbooks-PEX-SI-porting-guide /usr/share/doc-base/xbooks-Xext-LBX-algorithms /usr/share/doc-base/xbooks-Xext-SHAPE-library /usr/share/doc-base/xbooks-Xext-XC-MISC /usr/share/doc-base/xbooks-DPMSlib /usr/share/doc-base/xbooks-Xext-XTEST-protocol /usr/share/doc-base/xbooks-X-security-analysis /usr/share/doc-base/xbooks-Xext-buffering /usr/share/doc-base/xbooks-Xext-SECURITY /usr/share/doc-base/xbooks-Xext-XTEST-library /usr/share/doc-base/xbooks-XFS /usr/share/doc-base/xbooks-DPMS /usr/share/doc-base/xbooks-Xext-SYNC-library /usr/share/doc-base/xbooks-Xext-RECORD-library /usr/share/doc-base/xbooks-X-protocol /usr/share/doc-base/xbooks-Xilib /usr/share/doc-base/xbooks-XIElib /usr/share/doc-base/xbooks-PEX-encoding /usr/share/doc-base/xbooks-Xext-DBE-library /usr/share/doc-base/xbooks-XKB /usr/share/doc-base/xbooks-Xext-SHAPE-protocol /usr/share/doc-base/xbooks-XIM-transport /usr/share/doc-base/xbooks-ICElib /usr/share/doc-base/xbooks-BDF /usr/share/doc-base/xbooks-XLFD /usr/share/doc-base/xbooks-Xaw /usr/share/doc-base/xbooks-Xi-porting /usr/share/doc-base/xbooks-Xext-SYNC-protocol /usr/share/doc-base/xbooks-Xserver-security /usr/share/doc-base/xbooks-Xext-MIT-SHM /usr/share/doc-base/xbooks-XSM /usr/share/doc-base/xbooks-Xmu /usr/share/doc-base/xbooks-XDMCP /usr/share/doc-base/xbooks-ICCCM /usr/share/doc-base/xbooks-Xplib /usr/share/doc-base/xbooks-Xtrans /usr/share/doc-base/xbooks-X-i18n-framework /usr/share/doc-base/xbooks-Xi /usr/share/doc-base/xbooks-PEXlib /usr/share/doc-base/xbooks-X-i18n-locale-database /usr/share/doc-base/xbooks-X-test-suite-UG /usr/share/doc-base/xbooks-Xp /usr/share/doc-base/xbooks-Xext-XC-APPGROUP /usr/share/doc-base/xbooks-Xt /usr/share/doc-base/xbooks-ICE /usr/share/doc-base/xbooks-Xp-SI /usr/share/doc-base/xbooks-Xext-XC-APPGROUP-SI /usr/share/doc-base/xbooks-Xext-LBX /usr/share/doc-base/xbooks-PEX-SI-user-guide /usr/share/doc-base/xbooks-X-font-library /usr/share/doc-base/xbooks-XIE-SI-architecture /usr/share/doc-base/xbooks-rstart /usr/share/doc-base/xbooks-XIE /usr/share/doc-base/xbooks-PEX-SI-architecture /usr/share/doc-base/xbooks-CTEXT /usr/share/doc-base/xbooks-RX /usr/share/doc-base/xbooks-PEX /usr/share/doc-base/xbooks-XIM /usr/share/doc-base/xbooks-Xlib /usr/share/doc-base/xbooks-Xext-BIG-REQUESTS /usr/share/doc-base/xbooks-Xext-RECORD-protocol /usr/share/doc-base/xbooks-SMlib /usr/share/doc-base/xbooks-XFS-SI /usr/share/doc-base/xbooks-XKBlib From owner-xemacs-beta@xemacs.org Mon Jul 19 14:07:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA28692 for xemacs-beta-out; Mon, 19 Jul 1999 14:07:11 -0400 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 OAA28687 for ; Mon, 19 Jul 1999 14:07:09 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id LAA05559; Mon, 19 Jul 1999 11:08:32 -0700 To: Kyle Jones Cc: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.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" Date: 19 Jul 1999 11:08:32 -0700 In-Reply-To: Kyle Jones's message of "Sun, 18 Jul 1999 21:57:01 -0700 (PDT)" Message-ID: <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Kyle" == Kyle Jones writes: Kyle> Are you sure this is a bug? The point of the check, Kyle> obviously, is to prevent you from being left with just Kyle> unmapped frame and thus have no way to control the running Kyle> XEmacs. We have a variable, Kyle> allow-deletion-of-last-visible-frame, that lets you go ahead Kyle> and delete the last visible frame. So far no one has Kyle> mentioned this variable's value. It sure would be neat if the `gnuserv' functionality was part of XEmacs itself, so that a command could be sent to XEmacs to have it map a frame or run a command as with `gnuclient'. From owner-xemacs-beta@xemacs.org Mon Jul 19 14:16:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29101 for xemacs-beta-out; Mon, 19 Jul 1999 14:16:40 -0400 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 OAA29098 for ; Mon, 19 Jul 1999 14:16:38 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA19883 for ; Mon, 19 Jul 1999 20:16:37 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004q_; Mon Jul 19 20:16:33 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA14033; Mon, 19 Jul 1999 20:16:33 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> From: Jan Vroonhof Date: 19 Jul 1999 20:16:33 +0200 In-Reply-To: "James N. Potts"'s message of "Mon, 19 Jul 1999 12:44:27 -0500" 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: "James N. Potts" writes: > >Can you also reproduce this with frames created by C-x 5 2 ?, i.e. > > > >C-x 5 2 > >C-x 5 o (little ooo) > >minimize other frame > >C-x 5 0 (zero) > > > Yes. Well there is two options 1. The mimized state is considered a form of iconized (which I believe it is). Then this an XEmacs-NT bug. 2. The allow-deletion-of-last-visible-frame = nil feature doesn't work on NT and should be changed to t. Jan From owner-xemacs-beta@xemacs.org Mon Jul 19 14:21:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29219 for xemacs-beta-out; Mon, 19 Jul 1999 14:21:27 -0400 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 OAA29216 for ; Mon, 19 Jul 1999 14:21:25 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id LAA05593; Mon, 19 Jul 1999 11:22:59 -0700 To: xemacs-beta@xemacs.org Subject: Re: `xemacs-packages/{Makefile,[XL]*.rules}' References: <87zp0wwkdh.fsf@bittersweet.sysc.pdx.edu> 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" Date: 19 Jul 1999 11:22:59 -0700 In-Reply-To: SL Baur's message of "19 Jul 1999 14:46:34 +0900" Message-ID: <87btd8bit8.fsf@bittersweet.sysc.pdx.edu> Lines: 51 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Karl M Hegbloom writes in sb> xemacs-beta@xemacs.org: >> Shouldn't the configurables at the top of XEmacs.rules be >> pulled out and put into `Local.rules' as well? sb> XEmacs.rules isn't pulled into the toplevel Makefile or the sb> first level Makefiles. There is a path problem as sb> XEmacs.rules assumes it will only be included two directory sb> levels down from the top. Alright... so I guess there needs to be a `toplevel' variable, and then rather than doing: include ../.../Local.rules You could do: include ${toplevel}/Local.rules Or... MAKEFLAGS += -I ${toplevel} include Local.rules `toplevel' ought to resolve into an absolute path, but be formed at run-time. I'll try and look into doing this stuff soonish... I will be starting on the xemacs-packages for Debian in a week or so (eta). I'll do it then if ever. sb> Yes, I agree that it should be possible to have a non-CVSed sb> local file provide those defaults. >> I've made a few modifications to `XEmacs.rules' to make it >> possible to run in place from a CVS checkout. sb> It is only an accident that this works. Count on it being sb> broken by future updates to the installed packaging structure. Ok, so you plan to force me to learn more `make' tricks. :-) Why don't I get what I've done squared away and looking pretty, then send it in for yous to look over. Perhaps it can become part of whatever changes might break whatever? I'll show it to yous and let yous decide. (later today... I'm in a silly "teraterm" on an NT box at the library right now... It's difficult to work from.) Is it Ok to assume that GNU make will be used? Can we require that? (I hope so. It's the only one I know at all.) From owner-xemacs-beta@xemacs.org Mon Jul 19 14:22:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA29243 for xemacs-beta-out; Mon, 19 Jul 1999 14:22:06 -0400 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 OAA29239; Mon, 19 Jul 1999 14:21:59 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA20168; Mon, 19 Jul 1999 20:21:57 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004v3; Mon Jul 19 20:21:54 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA14047; Mon, 19 Jul 1999 20:21:54 +0200 To: xemacs-beta@xemacs.org Cc: xemacs-nt@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> From: Jan Vroonhof Date: 19 Jul 1999 20:21:53 +0200 In-Reply-To: "James N. Potts"'s message of "Mon, 19 Jul 1999 12:44:27 -0500" 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: "James N. Potts" writes: > >> This also arises under NT (with different circumstances): > >> Start with a single frame. > >> Press the news button. > >> Minimize the original frame. > >> Click the Exit Gnus button. > >> > >> The result: "Attempt to delete the sole visible or iconified frame" > > > >Can you also reproduce this with frames created by C-x 5 2 ?, i.e. > > Yes. Then this is probably an XEmacs-NT bug. The Minimized frames really should have an iconified status. Jan From owner-xemacs-beta@xemacs.org Mon Jul 19 15:40:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA32382 for xemacs-beta-out; Mon, 19 Jul 1999 15:40:41 -0400 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 PAA32378 for ; Mon, 19 Jul 1999 15:40:38 -0400 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 PAA05368 for ; Mon, 19 Jul 1999 15:46:28 -0400 (EDT) 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 VAA05292; Mon, 19 Jul 1999 21:40:26 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> 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 Jul 1999 21:38:29 +0200 In-Reply-To: karlheg's message of "19 Jul 1999 11:08:32 -0700" Message-ID: Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "karlheg" == karlheg writes: >>>>> "Kyle" == Kyle Jones writes: Kyle> Are you sure this is a bug? The point of the check, Kyle> obviously, is to prevent you from being left with just Kyle> unmapped frame and thus have no way to control the running Kyle> XEmacs. We have a variable, Kyle> allow-deletion-of-last-visible-frame, that lets you go ahead Kyle> and delete the last visible frame. So far no one has Kyle> mentioned this variable's value. karlheg> It sure would be neat if the `gnuserv' functionality was karlheg> part of XEmacs itself, so that a command could be sent karlheg> to XEmacs to have it map a frame or run a command as karlheg> with `gnuclient'. I miss gnu-serv/client dearly under Windows NT :-( Is anybody here working on it? Adrian From owner-xemacs-beta@xemacs.org Mon Jul 19 16:02:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA00638 for xemacs-beta-out; Mon, 19 Jul 1999 16:02:39 -0400 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 QAA00629 for ; Mon, 19 Jul 1999 16:02:33 -0400 Received: (from smikes@localhost) by klapaucius.hip.berkeley.edu (8.9.1/8.9.1) id KAA01606; Mon, 19 Jul 1999 10:22:42 -0700 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.72 under Emacs 19.34.1 Message-ID: <14227.24286.174318.826842@klapaucius.hip.berkeley.edu> Date: Mon, 19 Jul 1999 10:22:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Samuel Mikes To: Glynn Clements Cc: xemacs-beta@xemacs.org Subject: Re: Shift Delete on Cygwin/Xemacs-21.1-p2 In-Reply-To: <14226.63292.518348.167869@cerise.sensei.co.uk> References: <14223.4521.211361.240551@cerise.sensei.co.uk> <14226.63292.518348.167869@cerise.sensei.co.uk> Reply-To: Samuel Mikes X-Attribution: smikes Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >> "Glynn" == Glynn Clements writes: Glynn> SL Baur wrote: >> But do they do anything? They don't do anything for me. I hit >> Shift-Delete and get Delete. Glynn> They work fine for me (21.0-b66, Linux; I don't recall any Glynn> problems with 21.1-p2 on Cygwin either, but I don't have that Glynn> one available right now). Sh-delete works for me using 21.2-b16 on Cygwin 20.1, Windows NT, once I bind it. -- Sam Mikes smikes@alumni.hmc.edu From owner-xemacs-beta@xemacs.org Mon Jul 19 16:18:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA01201 for xemacs-beta-out; Mon, 19 Jul 1999 16:18:53 -0400 Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA01197 for ; Mon, 19 Jul 1999 16:18:51 -0400 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id PAA17642; Mon, 19 Jul 1999 15:18:48 -0500 (CDT) 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 PAA12311; Mon, 19 Jul 1999 15:18:54 -0500 (CDT) Received: from wcsdsp3 (wcsdsp3.rtp.ericsson.se [147.117.132.215]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id QAA29681; Mon, 19 Jul 1999 16:18:42 -0400 (EDT) Received: (toy@localhost) by wcsdsp3 (8.6.8/8.6.8) id QAA10584; Mon, 19 Jul 1999 16:19:56 -0400 To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> From: Raymond Toy Date: 19 Jul 1999 16:19:55 -0400 In-Reply-To: Adrian Aichner's message of "19 Jul 1999 21:38:29 +0200" Message-ID: <4nso6kgzo4.fsf@rtp.ericsson.se> Lines: 8 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> I miss gnu-serv/client dearly under Windows NT :-( I use gnuserv all the time when I'm on NT (which is a little as possible). Ray From owner-xemacs-beta@xemacs.org Mon Jul 19 16:44:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA02472 for xemacs-beta-out; Mon, 19 Jul 1999 16:44:29 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA02469 for ; Mon, 19 Jul 1999 16:44:27 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-45.kiva.net [206.97.75.110]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id NAA13855; Mon, 19 Jul 1999 13:44:19 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.8.7) id OAA09935; Mon, 19 Jul 1999 14:43:40 -0500 To: karlheg Cc: xemacs-beta@xemacs.org Subject: Re: `xemacs-packages/{Makefile,[XL]*.rules}' References: <87zp0wwkdh.fsf@bittersweet.sysc.pdx.edu> <87btd8bit8.fsf@bittersweet.sysc.pdx.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 10 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: karlheg writes: > Is it Ok to assume that GNU make will be used? Can we require that? no no no no no! Steve and I talked a bit in japan about using autoconf for all this, but I have had zero time since then to actually do it. :( Requiring GNU make just to build the packages is evil. :) -bp From owner-xemacs-beta@xemacs.org Mon Jul 19 16:50:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA02814 for xemacs-beta-out; Mon, 19 Jul 1999 16:50:32 -0400 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 QAA02807 for ; Mon, 19 Jul 1999 16:50:26 -0400 Received: by crystal.WonderWorks.COM id QQgyox24601; Mon, 19 Jul 1999 13:50:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14227.36750.708234.719126@crystal.WonderWorks.COM> Date: Mon, 19 Jul 1999 13:50:22 -0700 (PDT) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: > Justin Vallon writes: > > > On Sun, 18 Jul 1999, Kyle Jones wrote: > > Though barely X literately, I think I have seen this too. I would suppose > > that the "other workspaces" frames are being unmapped when the WM switches > > workspaces. XEmacs then incorrectly believes that there would be no way > > to get back to the other frames, though the "switch to the other > > workspace" button would re-map the frames. > > Yes, i would consider this a window manager bug. It should use a state > that maps more naturally on the Workspace concept. FVWM uses > Invisible+Mapped which is OK (In fact XEmacs is optimized by that > case). Telling the hidden frames they are iconified would also be > fine. Cool. The next thing to figure out now is why Steve can duplicate the problem even when allow-deletion-of-last-visible-frame is t. There must be some code path where this variable is ignored. From owner-xemacs-beta@xemacs.org Mon Jul 19 17:33:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA03042 for xemacs-beta-out; Mon, 19 Jul 1999 16:56:46 -0400 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 QAA02975 for ; Mon, 19 Jul 1999 16:56:05 -0400 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 RAA03843 for ; Mon, 19 Jul 1999 17:01:31 -0400 (EDT) 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 WAA05438; Mon, 19 Jul 1999 22:55:30 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> <4nso6kgzo4.fsf@rtp.ericsson.se> 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 Jul 1999 22:53:32 +0200 In-Reply-To: Raymond Toy's message of "19 Jul 1999 16:19:55 -0400" Message-ID: Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Raymond" == Raymond Toy writes: >>>>> "APA" == Adrian Aichner writes: APA> I miss gnu-serv/client dearly under Windows NT :-( Raymond> I use gnuserv all the time when I'm on NT (which is a Raymond> little as possible). You must be using a cygnus build then? I was referring to the Windows NT native build of XEmacs. Did anybody get gnuserv/gnuclient working there? Adrian Raymond> Ray From owner-xemacs-beta@xemacs.org Mon Jul 19 17:51:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA05191 for xemacs-beta-out; Mon, 19 Jul 1999 17:51:49 -0400 Received: from light.lbin.com (lbin.com [204.30.25.2]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id RAA05173; Mon, 19 Jul 1999 17:51:36 -0400 Received: by light.lbin.com (Smail-3.2.0.103 1998-Oct-9 #4) id ; Mon, 19 Jul 1999 14:51:02 -0700 (PDT) To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ian T Zimmerman Date: 19 Jul 1999 21:50:10 +0000 In-Reply-To: Jan Vroonhof's message of "19 Jul 1999 20:21:53 +0200" Message-ID: <87udq1mxjh.fsf@amazon.lbin.com> Lines: 32 X-Mailer: Gnus v5.6.45/XEmacs 21.0(beta67) - "20 minutes to Nikko" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> "James N. Potts" writes: >> >> This also arises under NT (with different circumstances): >> >> Start with a single frame. >> >> Press the news button. >> >> Minimize the original frame. >> >> Click the Exit Gnus button. >> >> >> >> The result: "Attempt to delete the sole visible or iconified frame" >> > >> >Can you also reproduce this with frames created by C-x 5 2 ?, i.e. >> >> Yes. Jan> Then this is probably an XEmacs-NT bug. The Minimized frames really Jan> should have an iconified status. I am not sure. In the Win95 GUI (now used also by NT), there seems to be no such thing as "iconified window". The only things that qualify as icons seem to be the stupid and useless bits on the desktop. :-) For example, setting frame-icon-title-format does nothing on NT. Instead one must set frame-title-format and decide if one's iconified by calling (frame-iconified-p). But then, maybe that's just another symptom of the same bug. -- Ian Zimmerman Lightbinders, Inc. 2325 3rd Street #324, San Francisco, California 94107 From owner-xemacs-beta@xemacs.org Tue Jul 20 01:29:40 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA15806 for xemacs-beta-out; Tue, 20 Jul 1999 01:29:40 -0400 Received: from mail.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA15803 for ; Tue, 20 Jul 1999 01:29:35 -0400 Received: by mail.eai-delta.de (Smail3.2.0.105/mail.eai-delta.de) via Delta-II from KEATS.eai-delta.de with smtp for mail.xemacs.org id m116SPy-001nt1C; Tue, 20 Jul 1999 07:26:18 +0200 (CEST) To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> <4nso6kgzo4.fsf@rtp.ericsson.se> Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R:lt{Y/s1g[= 5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 20 Jul 1999 07:26:17 +0200 In-Reply-To: Adrian Aichner's message of "19 Jul 1999 22:53:32 +0200" Message-ID: Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In message , Adrian Aichner wrote: > I was referring to the Windows NT native build of XEmacs. > Did anybody get gnuserv/gnuclient working there? Hi Adrian, I have a working gnuserv/gnuclient installation for native build. But I don't know where I got it from, damn. Hmm, you say, you have a cygwin installation. Couldn't you try to build the cygwin gnuserv/gnuclient and test them with your native build? I guess, I did exactly this ... HTH, norbert. From owner-xemacs-beta@xemacs.org Tue Jul 20 02:14:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA16601 for xemacs-beta-out; Tue, 20 Jul 1999 02:14:25 -0400 Received: from mail.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA16598; Tue, 20 Jul 1999 02:14:21 -0400 Received: by mail.eai-delta.de (Smail3.2.0.105/mail.eai-delta.de) via Delta-II from KEATS.eai-delta.de with smtp for mail.xemacs.org id m116TAN-001nt1C; Tue, 20 Jul 1999 08:14:15 +0200 (CEST) To: Andy Piper Cc: Neal Becker , xemacs-beta@xemacs.org Subject: Re: buffer.h is screwed w/no error checking References: <3.0.5.32.19990719125026.00a6f910@london.beasys.com> Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R:lt{Y/s1g[= 5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 20 Jul 1999 08:14:14 +0200 In-Reply-To: Andy Piper's message of "Mon, 19 Jul 1999 12:50:26 +0100" Message-ID: Lines: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In message <3.0.5.32.19990719125026.00a6f910@london.beasys.com>, Andy Piper wrote: > At 09:57 PM 7/18/99 -0400, Neal Becker wrote: > >INC_CHARBYTIND is not defined if --error-checking=none in the latest > >CVS. > > Fixed, thanks. Are you sure? Compiling redisplay.c natively on NT gives me the following errors: ..\src\redisplay.c(4484) : warning C4002: too many actual parameters for macro 'INC_CHARBYTIND' ..\src\redisplay.c(4484) : warning C4003: not enough actual parameters for macro 'REAL_INC_CHARBYTIND' ..\src\redisplay.c(4484) : error C2059: syntax error : '+=' This is with the latest CVS sources (21.2). Should I set error checking during the build? Thanks, norbert. From owner-xemacs-beta@xemacs.org Tue Jul 20 10:12:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA00361 for xemacs-beta-out; Tue, 20 Jul 1999 10:12:53 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA00357 for ; Tue, 20 Jul 1999 10:12:51 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 116YtD-0002dx-00 for xemacs-beta@xemacs.org; Tue, 20 Jul 1999 08:20:55 -0400 To: xemacs-beta@xemacs.org Subject: Image lib Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 20 Jul 1999 08:20:55 -0400 Message-ID: Lines: 3 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: An image lib with uniform interface for ppm, png, and gif: http://www.radix.net/~cknudsen/Ilib/ From owner-xemacs-beta@xemacs.org Tue Jul 20 10:22:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA00916 for xemacs-beta-out; Tue, 20 Jul 1999 10:22:29 -0400 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 KAA00909 for ; Tue, 20 Jul 1999 10:22:28 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id JAA04818 for ; Tue, 20 Jul 1999 09:49:03 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa001BG; Tue Jul 20 09:48:57 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id JAA14929; Tue, 20 Jul 1999 09:48:56 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> <87udq1mxjh.fsf@amazon.lbin.com> From: Jan Vroonhof Date: 20 Jul 1999 09:48:56 +0200 In-Reply-To: Ian T Zimmerman's message of "19 Jul 1999 21:50:10 +0000" 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: Ian T Zimmerman writes: > For example, setting frame-icon-title-format does nothing on NT. > Instead one must set frame-title-format and decide if one's iconified > by calling (frame-iconified-p). > > But then, maybe that's just another symptom of the same bug. Wait a second. A minimized frame _has_ (not (null (frame-iconified-p frame))) but you _still_ get the problem? Jan From owner-xemacs-beta@xemacs.org Tue Jul 20 10:22:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA00919 for xemacs-beta-out; Tue, 20 Jul 1999 10:22:30 -0400 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 KAA00915 for ; Tue, 20 Jul 1999 10:22:29 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id JAA04721 for ; Tue, 20 Jul 1999 09:47:23 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0019.; Tue Jul 20 09:47:15 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id JAA14927; Tue, 20 Jul 1999 09:47:14 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87emi4bjhb.fsf@bittersweet.sysc.pdx.edu> <4nso6kgzo4.fsf@rtp.ericsson.se> Date: 20 Jul 1999 09:47:13 +0200 In-Reply-To: Adrian Aichner's message of "19 Jul 1999 22:53:32 +0200" 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: > You must be using a cygnus build then? > > I was referring to the Windows NT native build of XEmacs. > > Did anybody get gnuserv/gnuclient working there? The FSF NT folk seem have a port of an older gnuclient. It shouldn't be that difficult to port that gnuserv 3 (our version). Jan From owner-xemacs-beta@xemacs.org Tue Jul 20 10:22:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA00932 for xemacs-beta-out; Tue, 20 Jul 1999 10:22:42 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA00927 for ; Tue, 20 Jul 1999 10:22:40 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA23148 for ; Tue, 20 Jul 1999 15:30:48 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `xemacs-packages/{Makefile,[XL]*.rules}' References: <87zp0wwkdh.fsf@bittersweet.sysc.pdx.edu> <87btd8bit8.fsf@bittersweet.sysc.pdx.edu> <861ze4ifwz.fsf@megalith.bp.aventail.com> X-Attribution: sb From: SL Baur In-Reply-To: wmperry@aventail.com's message of "19 Jul 1999 14:43:40 -0500" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 20 Jul 1999 15:30:40 +0900 Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry writes in xemacs-beta@xemacs.org: > karlheg writes: >> Is it Ok to assume that GNU make will be used? Can we require that? See below. > no no no no no! Steve and I talked a bit in japan about using > autoconf for all this, but I have had zero time since then to > actually do it. :( Please find the time ... > Requiring GNU make just to build the packages is evil. :) We currently require GNU make to build Lisp packages from source. As far as I am concerned, it will always be a requirement unless someone comes up with something better. I am less convinced than ever that we wish to use configure on my end. configure is inherently flawed with respect to building things for other systems. It tightly binds dependencies that should never escape into a distribution. If you can demonstrate otherwise, lead me. -- $B6}F~$l6}=P$7(B (Garbage in, Garbage out) From owner-xemacs-beta@xemacs.org Tue Jul 20 10:23:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA00988 for xemacs-beta-out; Tue, 20 Jul 1999 10:23:50 -0400 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 KAA00902 for ; Tue, 20 Jul 1999 10:22:26 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id LAA15715; Tue, 20 Jul 1999 11:36:31 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa003pT; Tue Jul 20 11:36:21 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id LAA15282; Tue, 20 Jul 1999 11:36:20 +0200 To: Marco Antoniotti , willd@pindar.com Cc: ilisp@naggum.no, xemacs-beta@xemacs.org Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 References: <379339E8.7CCEC054@pindar.com> From: Jan Vroonhof Date: 20 Jul 1999 11:36:18 +0200 In-Reply-To: Marco Antoniotti's message of "20 Jul 1999 10:08:52 +0200" Message-ID: Lines: 48 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: Marco Antoniotti writes: > > Having installed the inferior lisp package with xemacs 21.1-p3, I cannot get > > ilisp to work with CLISP. > > If anybody has any clue about what is happening with XEmacs/ILISP, > please let me know or write to ILISP mailing list. (for the time > being, but not much longer, ). Well. I am not sure whose problem this is exactly, but for me the problem seems to be with something (i.e. either XEmacs or Clisp[1]) not flushing pipe buffers correctly. The patch below "fixes" the problem for me. I can run Clisp now and evaluate "(+ 1 2)", define a function and have it complete the function name in a call. I have no idea where the concat problems come from, I did not see them. Jan P.S. I have the feeling ilisp could do with a few '(defstruct's. diff -u /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el~ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el --- /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el~ Tue Jul 20 11:31:11 1999 +++ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el Tue Jul 20 11:31:11 1999 @@ -110,7 +110,7 @@ (program ilisp-program) (args (lisp-command-args program)) ;; Use pipes so that strings can be long - (process-connection-type nil) + ;; (process-connection-type nil) (names (format "%s" name)) start) (apply 'make-comint name (car args) nil (cdr args)) Footnotes: [1] My guess would be XEmacs. It seems suspiciously like the process bug on NT that makes it fail to recognize the end of ftp transfers under efs. From owner-xemacs-beta@xemacs.org Tue Jul 20 10:44:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA02486 for xemacs-beta-out; Tue, 20 Jul 1999 10:44:06 -0400 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 KAA02465 for ; Tue, 20 Jul 1999 10:43:35 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 116b7E-000122-00 for ; Tue, 20 Jul 1999 16:43:32 +0200 To: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <87so6lemer.fsf@pc-hrvoje.srce.hr> <14226.45085.210860.747591@crystal.WonderWorks.COM> <87673gn15e.fsf@pc-hrvoje.srce.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: 20 Jul 1999 16:43:32 +0200 In-Reply-To: Didier Verna's message of "19 Jul 1999 17:20:09 +0200" Message-ID: <871ze3pejv.fsf@pc-hrvoje.srce.hr> Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Still, it's not a bug in XEmacs, but rather a misconception of the X > Windows' states[1] and the way window managers achieve their desired > effect. Well, I don't know about that. Maybe WindowMaker does provide some more hints and we don't know about them? Maybe I should bring the matter to the WindowMaker list? I don't particularly care about whose fault it is, I'd only like the problem to be fixed, one way or the other. For now, setting `allow-deletion-of-last-visible-frame' to t fixes the problem, but that's not a good long-term fix. From owner-xemacs-beta@xemacs.org Tue Jul 20 10:46:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA01737 for xemacs-beta-out; Tue, 20 Jul 1999 10:34:28 -0400 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 KAA01734 for ; Tue, 20 Jul 1999 10:34:25 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id DAA18000; Tue, 20 Jul 1999 03:53:06 -0700 (PDT) Received: from andyppc (lhr-modem7.beasys.com [10.5.1.18]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id DAA21839; Tue, 20 Jul 1999 03:52:15 -0700 (PDT) Message-Id: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Jul 1999 11:52:35 +0100 To: ben@666.com From: Andy Piper Subject: Tabs 'n widgets screenshot Cc: xemacs-beta@xemacs.org, wmperry@aventail.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_932464355==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_932464355==_ Content-Type: text/plain; charset="us-ascii" ... for anyone who's interested. andy --=====================_932464355==_ Content-Type: image/jpeg; name="Image2.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-Disposition: attachment; filename="Image2.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCAKXAqEDASIA AhEBAxEB/8QAHQABAAMBAQEBAQEAAAAAAAAAAAUGBwQDCAkCAf/EAFoQAAEDBAECAgUFCA0ICQQB BQIBAwQABQYREgcTFCEVFiIxUSMyUqTTFzdCVVZXlNQIGDNBYWJ0kZOVlrXRJDQ2VHaBtNI1Q3F1 hJKxs8MlY4KyJlM4c6FY/8QAGgEBAAMBAQEAAAAAAAAAAAAAAAIDBAEFBv/EADoRAQABAQQIBQEG BQQDAAAAAAABAgMEERMFFiExQVGR0RJSU2GhgQYUInHB8DJysdLhIzM0NUKy8f/aAAwDAQACEQMR AD8AunXrq250tdsjLOOxLmFwj79pW21BQbZVVVVaNS2ri/zVV8d675hf7Od3t3Ta0eABTQnpN5hR hRBTZF8q0Psp57L3eS+fkuqx+zv/AM7w7+TO/wDtRawzpdKBzMBs864SGIdxaWK683IMHGWy+eje l8iUdp5+WlXaEOwL6KbrYWWi7O85cVVTMxOM1c54RMclXima5jF9E5D+yRv2PjC9L9PLZHOaz32W kuUU3UDy8zAWVJv360aCu0JPeK6if22cn8goX6S1+r1885fZH8cyy7WSS7IfdhSzZ777Stm+Ar8m 5xVVVEMOJIm18iTSr712S6dIMIt2ARZEi/3g8llYYGUNhHjPPgPJVJGzZbjELbPFOCvnITR6JQQV RK9iw0bo+LCztLaz21+Wat3XhxVzXXjMRKxfts5P5BQv0lr9Xp+2zk/kFC/SWv1erBO/Y1dOjvz+ PwbhlTEor8VjYlPTY7jYH6J9IC+TaMCpCi6bVtDFVTz5J7qzewdGbPL6dTJd4mvWzJwxB7K4rITu +j0QXF7akykZAATBNeUkjFVElD3inLO7aFrjGLOeHGrdO6d+7YTNpHFaP22cn8goX6S1+r0/bZyf yChfpLX6vVR6k9K8YxzJbxh1shZ5cLrZJNrZk3SFDbmxX/FACmisijZMGpOIjQq65zVOCqm+SRvW zBsOwO6xkt8LKplvuEKSkJ+RKaBtXwd4ifc7KEpB816KbTTjTiKPNUVCW+z0bom0mmKbOfxbts8s efKcXJrrji0D9tnJ/IKF+ktfq9P22cn8goX6S1+r1kPRfDbXmFzyNy8vzAg2DHZt7dZiGLbsnsCO mhcISRvamiqSgfkiprz2m/WPAMOsvS3IbczOuUCwZTasOudwdnTWichhKuTouad7YAggCb5EOtoq r5eSV3q4aKu9XhmyxnGI31cZiOfvi7TVXPFX/wBtnJ/IKF+ktfq9P22cn8goX6S1+r1/V06B4JZ3 bgFymZIUi32XIbw9A8Yyy+TEGaLUMvaZVRB5rmvNRVCVNj5IqVJW3D8Owzot1CfmLfpOPX7GMavg xGpDSTGTeff4Md9W+BD3QHbnaRUAl0KqnnVN20RMRNFlM4zEb6uNURz+vvzMbTmi/wBtnJ/IKF+k tfq9P22cn8goX6S1+r1V5fS/H8P/AGScPFDyS23CLDye2sBa58Z4pMyO+cc9FxaVghQXlEuRjy4E vBNiK2SX0q6cXLIMsyO8SblaLYvUB3GoVugmqKCpsjVoWYjyuESrpthAbQUHirhLpasquWiYwnKm YmImNtXHdsxPFac3p+2zk/kFC/SWv1en7bOT+QUL9Ja/V6qLvSTHmOmuSXgTzCZd7VJnC0SWxIoG xHeFsZCRnkQ3Wd8xeMXEOMZAhtEKKSxv7Lu2WKzdfL7a8es7Npix24qGxHEAY5lHbJSbbABRsVQh 2ntKpIRb9riltlo3RVra5dFlz41cMPf3cmuuIxxaB+2zk/kFC/SWv1en7bOT+QUL9Ja/V67ovSDC ML6nWyJbL/eJuQY1kWP+J1GeeYd8Q8zz7vGMLcTamhN7fe5IKiuiXywfrf8Afpzj/aK4f8S5Ubto 3Rd5r8NFlOGGOMzVHL35TiTXXG+W1fts5P5BQv0lr9Xp+2zk/kFC/SWv1evmWlb9XtHen81d0c2v m+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9 Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2z k/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXz LSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6 S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d 6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7 bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m 18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyCh fpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv2 2cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6 +ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC /SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2 jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0 /bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3 M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+Q UL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6vXzLSmr2jvT+au5m18301 +2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8goX6S1+r0/bZyfyChfpLX6 vXzLSmr2jvT+au5m18301+2zk/kFC/SWv1en7bOT+QUL9Ja/V6+ZaU1e0d6fzV3M2vm+mv22cn8g oX6S1+r1pdqz3q1dLVCukLpDaTiTYzcqOZ5BbW1NpwEMC4kCEmxJF0qIvnXw1X3tYbzZ7H0zxCXe rrBtkc7Ba2xdlyAZAjWE0qCikqJvSKuv4Frw9OXG56Ps6KrKyicZ4zV+lULLOqqqdsuVzMusDYE4 50hsgAKKpEWTWtERE/fX2a57Rn3Vm62iDdoPSG0nDnRmpUYzyC2tqbTgIYFxIEJNiSLpURfOpw7z Z75jNxl2W6wbnHBl1snYkgHgE0DaiqiqpvSouv4UrPX8Rx7NIvSy15Lb/HQ2sGGQDfecb04jFsFF 2BIvuIvLevOvm/vVl6NPWv8AvXeGea3OZl1gbAnHOkNkABRVIiya1oiIn76+zUFgnV/qHnFjO94z 0qtkyAEgoyuuXmDH+UEQJRRHWxVdC4C7RNedcUTAcTwfOA9V7T6P8bjV08R/lDrvPg7D4/uhFrXM vdr31HfsTliD+x7nlPk+FhpeZqvv99WO034SJyLuIqKGk2vJFRU1vaarRZ2tjVZV1zY04xhxr4z/ ADOTE47199b+sf5n7N/aW1/8tQ1i6tX2+ZVkeEXfFINiuVttbsh42JceVxLTehQ2m0TenUXYltFT Xku9VLCL7e5eSWGNkl9vrOIq+SYzcX2ljOXtxF+SGY4J8vm7VsSFtJCJyJFX2FjMR/8A7lepH/dD /wD6RqhZV2NtTXGVEYRM4xNX61TBOMcXylSlK81N9q/susGyrNJeNerNr8csOMXf+Xbb4c2Y/H55 DvfEvd8KxJjpB1oYt8aAzZ3G40eSssGgnRhFXta7iojvmWvJFXaonkmvPf2xef8AOw/kzH/tBWc5 Jk1wYz9cajZLjNk5QYr0YLnGJ16W686+Cg2iSGt67QeSIS7P/sr0Y0jORTYV0RVFOOGPi4zjwqhD wbccXzVP6M9XrjOdn3Gwuy5byorrztxjKRaRERP3TyRERERE8kRERKkvub9efVr1Z7V49Bfiz061 4X5/c/cu9w+f7Xu9/n76+iIecRQvt0izZbUiJFBtI6xILxPuvFKmtG0LQ8zcUEieagPnwcPyH5tr tU+JdIDc6C73WHNoiqKiQkiqJCQqiKJCSKJCSIoqioqIqKlehZ/aO3s6KbOmzowjdsnZ8ozYxO3F 8sepn7I3xfi/G5J4jxPiu76xhz7/AGuz3eXe3z7XyfL38PZ93lXjDwL9kHDx8sehuX6PZibNore1 kDYRlA9qY9tHuPEuRbTWl2u/fX09m90kWPC75eogNHIt9ukSmhdRVAjbbIkQkRUXW0TelSozHMiA rNNvNwy3Hb5AaMWges0UkQXPJO3pHnlccJTbQQHRKpIiISkld1lvHp0dJ7mTHN83XTpv15ulli2S 5tXidaofDw0KRfWnGGOAqAcGyeUR4iqimk8kVUSvadgX7IOdNfnTnL9KlSIRW9997IGzcdikuyYI le2rSqqqoL7Kqvurbj6mtNSrk6bTpR41xbiMQytklqW60S24Sd4kPLYFNL5Pt8nEUOOtKpaRXdZr z6dHSe5kxzfJOCdNOrOI5AN7h4UzKlNtkDJHeVjqypeSmJxpTTiFx5D87SoRbRfLVkyu19e8pyD0 hfsWZm28oTEF6zLeSCHIZY5K0jyjKR54hcMnUJxwi5qq715VvWX3SRa7MRW8GnbpKMYtuacRSE5B +QqSIqErY+bh8fNGwMvwa4fXmxDAtcl0bmjtyYceaiM25+S+121AXQcBgT4E2ZiBIvuLae9KhV9o 7xXX46qKcfyn4/FsMqObGY8f9kOzn+U5yGOQxvWSW523PvBMZb8K0aNoJMcH0UDbRoEElUl9na8l 86p8/pv15uHpLx7V4l+le16R719aPxna12u7t75ThpOPLfHXlqvpuPmuNSLn4CPPdeXm034kIjxR OboAbQ+JQOzsxcb4pz81MUTakiV3WK/2m+d70ZL7/Z4qu2yDkBb4OhyRObRcS4uDsC4lxJdLSj7R W9E402dEbo3Tw3ceBlRPF8lXrpF1lvdzdud5tMy5TnuPdky7sw665oUFORk6qrpERE2vuREqYiYZ +yNiXObc4s3JI86f2/GSWsjAXZPbHiHcNHtnxRdJtV0nklfWFUb1lv8A2vT3ctnoj036J8B4U/Ef 594Lud/ucfnfK8e17vY3v26nP2mvMxhNnRh+U93MmOb52j9Let8fH5GPR4VyZs0pxHZFvC8sjGdN OKoRNo7xIvYDzVN+yPwSvaT0368ybadsktXh6C5GZinGcvrRNEwySky0oK9pQBVVRHWhVVVNbr6M vXUOxQrVeZUbxUh+2MTDEHYj8dmS7GFxXGW3zb7ZkitH5ApLoCXSoK66kzKztHI70uU+aPiDcSPa ZRSmh7DLqobQiTi6R4FU+IoPdAC0Xv7rPefJR0nuZMc3ze9gX7IN6FboLzl+ci2txp23sFkDatxD aTTZND3tNkCeQqOlRPdqoed0Y6uTpr86dYHpUqQ4Tr771zjm46ZLsiIlc2pKqqqqvmqrX1bHzbFp Nz9HRru1Ie5tNkTQGbQK6AGzydROAo4jgICqSIZKoipEiondYr/ab53vRkvv9niq7bIOQFvg6HJE 5tFxLi4OwLiXEl0tKftReqd1FEfSe5k0vj77h3VL8l/r8b7Sn3DuqX5L/X432lfalZ5i2bXC5ZV6 OO5WKdzus6E7bYbRDLt7TBviEh5e6WxLstj5tgnJ8NL7kKWtd88tPSe5kUvm77h3VL8l/r8b7Sn3 DuqX5L/X432lfUmVZ1bbfjMK52x7xLt0YZft/wDkrrnJl1+Oz3u2Kcz4+KaLtJxM/mppdqi1ZzCc jTX7iMoTG6zIUeLEt0h95QjOdonNNiSuDyRCVwRQAVwW1Xkmya13zy09J7mRS+W/uHdUvyX+vxvt KfcO6pfkv9fjfaV9ZrmuNKMkmZ7spI5st7ixHn+8brSPALPAF769pUcVG+XEfaLSedTsSRHmRWZc R9qRHfAXGnWjQgcAk2hCqeSoqKioqU1rvnlp6T3Mil8X/cO6pfkv9fjfaU+4d1S/Jf6/G+0r7Luo XByA4FrkxYsxddt2THJ9sfNN7ATBV8tp85NKqL560tYxPJ5PqBaMjymVFN+6sMyGGbbb3uXyrSOI 0DSE646QpzVVFPmiqqKIKrTWu+eWnpPcyKXy39w7ql+S/wBfjfaU+4d1S/Jf6/G+0r6zezXGmm2H SnukDoK4ZBEeNIoIRCpSFQF8MiEDgqrvDStuIuuBa5bBmcGSiRrpIaZmuXGZFAWmjVsAbmPR2VcP zFtXO0gjzUeZ8kDa+yjWu+eWnpPcyKXyt9w7ql+S/wBfjfaU+4d1S/Jf6/G+0r7Uql9QcokWO/2e 2jkGO2CPNiyn3Jd4aUwI2jYEWx+WaRFVHjX3r8z3e+mtd88tPSe5kUvl/wC4d1S/Jf6/G+0p9w7q l+S/1+N9pX1nOyu1WaU3abzMdO5BFaefKNbZCtLzUhHSihoCuG2Yg2pqRFoR5Eqb9ZOW2KPAiz3J Erwcnn8uMF8m2OC6PvkgKkfgu0Lu8OKiW9cS01rvnlp6T3Mil8j/AHDuqX5L/X432lPuHdUvyX+v xvtK+uCy7HgnvxHbh2Ox3EOQ8y43FUm0VXBGQQo0RAgmpCJKo9tzaJwLXLfcrYDAL/kdmXuP2yDJ eRmXHcaIHW2lcQHWjQXB2nFdKgqokip5Ki01rvnlp6T3Mil8o/cO6pfkv9fjfaU+4d1S/Jf6/G+0 r7Bv12iWk4JzbjFgsPPmBk+CqJiLDrpJz2iN6FtTUy2mgJPeSKkY5neOB4cUcubj7/d1GatEtyQH b7fPuMi0rjekdaX2xHaOCqbRUWmtd88tPSe5kUvlH7h3VL8l/r8b7Sn3DuqX5L/X432lfaESRHmR WZcR9qRHfAXGnWjQgcAk2hCqeSoqKioqV6U1rvnlp6T3Mil8V/cO6pfkv9fjfaU+4d1S/Jf6/G+0 r7UpTWu+eWnpPcyKXxX9w7ql+S/1+N9pT7h3VL8l/r8b7SvtSlNa755aek9zIpfFf3DuqX5L/X43 2lPuHdUvyX+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfkv8AX432lPuHdUvyX+vxvtK+1KU1rvnlp6T3 Mil8V/cO6pfkv9fjfaU+4d1S/Jf6/G+0r7UpTWu+eWnpPcyKXxX9w7ql+S/1+N9pT7h3VL8l/r8b 7SvtSlNa755aek9zIpfFf3DuqX5L/X432lPuHdUvyX+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfkv8A X432lPuHdUvyX+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfkv9fjfaU+4d1S/Jf6/G+0r7UpTWu+eWnp PcyKXxX9w7ql+S/1+N9pT7h3VL8l/r8b7SvtSlNa755aek9zIpfFf3DuqX5L/X432lPuHdUvyX+v xvtK+1KU1rvnlp6T3Mil8V/cO6pfkv8AX432lPuHdUvyX+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfk v9fjfaU+4d1S/Jf6/G+0r7UpTWu+eWnpPcyKXxX9w7ql+S/1+N9pT7h3VL8l/r8b7SvtSlNa755a ek9zIpfFf3DuqX5L/X432lPuHdUvyX+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfkv8AX432lPuHdUvy X+vxvtK+1KU1rvnlp6T3Mil8V/cO6pfkv9fjfaU+4d1S/Jf6/G+0r7UqDxu+eMx+Zdro5FiNRZ09 lxxS4Ng1HlPNIZKS+XsNopLvW9r5J5U1rvnlp6T3Mil8j/cO6pfkv9fjfaU+4d1S/Jf6/G+0r64j ZZZ5ECVLaS5r4Tgr0crVKGUgmuhJI6t90hVUJEJBVPZPz9ktQ+Z9QbVacRuF0tbrs2a1bn5TDQQJ DyNmCGgpIQB2wncAxXuKGlbcTyUC01rvnlp6T3Mil8v/AHDuqX5L/X432lPuHdUvyX+vxvtK+0Jc iPDivS5b7UeOwBOOuumgg2AptSJV8kRERVVVquuZ3jjbIG45cwdN8WAilaJaSiIgMxVGO13VFRad VD48V7ZpvYrprXfPLT0nuZFL5R+4d1S/Jf6/G+0rR5sPr1OsVusdwwHF59ut0aPHjsTGoz4ojLKN Aaobypz4p5qmvMl1pF1W4xstsUqBKmxJEqU1F4KYx4L7rhga6B1tsQU3Wi0vFwEICQSVCVBXXk9m uNNNsOlPdIHQVwyCI8aRQQiFSkKgL4ZEIHBVXeGlbcRdcC1kvenbW+RFNtZ0zEfzR/SpKmzindLF bZG6/Wq3PW21YJi9uhvqROsRGorIEpIgqqoDyeaoiJv3+SVzzLT1ynWm0Wu5dO8SuMa0QWYUNJrE V9QBtoGkXZvLoiRsVLWkVf3kTSJ9AW+/2mfdZFsiS+5KY5ckVshE+BILnbNUQXOBKgnwUuBKglpV 1UnWH71ZejT1r/vS8M83zVbLL1utTjzlq6bYbbnH2SYdciRIbJk2WtipA8i6XSeX8CV/PT+0fsgM HxVMcsWLWxInjHJhG++wbhGYNAqb76JxRGh0mt7VdqvlrVMo6k2+xxc2Zl3axRbrZufoyHJkiDkn /Imng2CmhHtwyH2dbRERPNFWrXJyazRrylpekupI5g0RpGdJhpw9cG3HkHttuFyDQESEvMNIvMdz pv1FNM0xY04Tv/j/ALnPD7sd9K/smfybsv8A5o/29eXTDE+oMPP8pzDNbMzBW42Z9sjZfaIFd+S0 iCLhKm0bVfh//pK0vC+oNqvNotHjnXWrlKixClKECQMRqQ+w26LXfUVbFV7oIIqe1UxHzJURbRfv +g5/8mc//Vaj98pimqKLKmMYwxjxfrVMO+H3fmxSlKwpP1AvP+dh/JmP/aCq/GtPZyqffPEcvFwY 0Ts8NcOyb58uW/Pff1rXlx9678ufqVKvi5bi1ksl1j2s7qhA9JeheKQAat5P+TfMNqva4/OT5379 cfoHMvzkwv7JJ+u0Fem9K48qRJkvToMwzlLKZYn21JEZDWRPdVHW1NO4iDPJE0Q6JsS8/MauuLWh qxWGNa2kioLXIlSLFCMyhESmSA2HkAopLpNqutciItksX6BzL85ML+ySfrtPQOZfnJhf2ST9doJT LLT6exW72PxHh/SMF6J3uHPt9wFDlx2m9b3rab+NRkqx3+6WiRCvd7tjzqPx5MNyHbDYFp1h0Xh7 gk+fcFTANiigukJNoqoo/wCegcy/OTC/skn67UXjrGa3dy9f/wA/gMNW27HbQL1WQidUI8d0jVPF px83+KJtfId7TekDnPp1cJd1k3i5ZBFduDr5SRWPbiaZF1Ct5NbAnSVRQrcHIeSKSOEiKGkWtDqs egcy/OTC/skn67T0DmX5yYX9kk/XaDrybG2Mgn25ydLlBDhd10WYz7kdxXyRAB1HmjEx4grwcUXR I6u/mpVYHDr/AGjKoDmM3KKzb2mLhxO4Rzl9jvnDNW1VXwccI3W33e4RLrkoqnzanPQOZfnJhf2S T9dqGzlMyxjDrvkKZ9Cllb4jkgWPVVAR0hFVQVLxi8UVdIq6XXv0vuoOfGsCucB+ZZ1ntM42xcbe /GbOPzlyEiRoaNn3kcQQRXIyIQq1tUEtKnIVS2YlY5dl8ckm6+NGS+roAMdGRFV+caiiqndNV5Go cAIvaRsCI1Lxl43msaU9Gc6kwFNoyAlHEk1tF15f5ZXl6BzL85ML+ySfrtBZ6p/qhcO56P8ATMX0 D6V9KeH8CXiu74rxfHv93hx7373a3w9ne/brp9A5l+cmF/ZJP12noHMvzkwv7JJ+u0FeiYFc7xbJ ltySe0xayuN2fjRosfjJFJRy20MnlcMCRWpJkgo2KoqhtfZJClAw+8R74/kUK+wQvMgzVw3raZxu DkeI24iNo8JIqlDAhXmukIhVCXRV4Kxmq5mzjrefwFQrS/cnHyxZE4o2/HaEEHxftbV9VVdprgnk u/KU9A5l+cmF/ZJP12g4rV0/j2ywOWWJcnVj+kbbMaJ1pCMQhhDFAJUVEJSSImyRE1z9y685jErH Lsvjkk3XxoyX1dABjoyIqvzjUUVU7pqvI1DgBF7SNgRGpcnoHMvzkwv7JJ+u09A5l+cmF/ZJP12g s9U+zYhcIl1juTLzFkW+FdZl0hsNQSaeF2QT+xccV0kMRGS4mkAFVUFd+SovT6BzL85ML+ySfrtR eJMZrfseYvBZ/AjA/IltNtpiyGvBmU9HQlXxaaUu1y1565a2utqHO103lo5ZQdyTuQ7IwxEgsJBQ dMMyoj4cy57J1UiIBF5CvIVEA4kh+t36bx5rERScs82RFlXF5sbtaUmRuEyT4gk7XcFUcFUAUPl7 ufs+0nGX9A5l+cmF/ZJP12noHMvzkwv7JJ+u0HF6inHsVxtcC6tNpLlMPt92CPbBGorDAiotE2oq isI6JMq0oGgcdIOiuERo2IrLLsh2SbYCJPOoKG4qJpSJBRB2vvXSInwRKrnoHMvzkwv7JJ+u1F5I xmtpbtvaz+BIdn3aFbQEsWQBFZEgGlNV8WvzUNS1rzVETab2gXuqo1iUiLieM2qDdGgn44DKRZT0 VTacMIxxyU2kMVVFBw1RENNFxXaoiovp6BzL85EL+ySfrtPQOZfnJhf2ST9doIh3p5I8FPiMXxoA vUV2LelOEpK6Dj0h41j6cTsrylvonPu6Tt73xJT7oWGy4dyhSmL5xbjzpkoxSIiOcZElx8mwPl5C XcEHENHEJGmyBGjFDTp9A5l+cmF/ZJP12noHMvzkwv7JJ+u0FnqvZJZLxMv9uvVlu0GDIhxZMUhl wDkg4DxsEqogutqKorCfvr85ahbaxms3J73Zxz+ADdqjwnSfXFk24chZHsoPi/JBSOi735qetJra ynoHMvzkwv7JJ+u0HncsSkXGc5Pl3RrxDwWlHe1FUQU4Us5KqKKaqiOKaiiKq8db2VV7JulXpi3T IfpK2O+L8anK42nxfhPESH3ucZO6PZdTv8SP2ufaaXQ8dLOXCFkdv8P4/qvaIniXxjsd/FwDuulv i2O5vtEul0Kea6rp9A5l+cmF/ZJP12g/23Y5doD0qNFyLw1qdflSWm2YQ+KF2QbjhcnTUgIRN0yE UaFfZbQlJEJD4XsBjy8LlWO4PQXphxZcaFLCAiBbQkNq2oRwIiMG0RfmdxfooogggPTLtGYRor0l zqREUGgIyQcRTaoib8v8trkxiDnF3xay3l/qBb4zlztsWcrAYt3Ea7zIO8OSyx5a563pN691B1v4 9kdyfgPXjI4POBKKTHct1rVgxUo0hhf3V50VVO+JIqiqexpULl5Q7GJ5Vbb3ZDtV1tgBFgz2nHXb cRRY4uuxSbYZYR9HAHTRKm3DQdKKIIq2AznoHMvzkwv7JJ+u09A5l+cmF/ZJP12gmcetcex2C3WW Ibpx7fFaitE6qKZA2CCikqIib0ib0iV3VWPQOZfnJhf2ST9dqLujGaxMhsFnaz+A6d3kPtK4WLIK Mg1FekKWvFryVe0gonl85V35aUL3Sqx6BzL85ML+ySfrtPQOZfnJhf2ST9doLPSqx6BzL85ML+yS frtPQOZfnJhf2ST9doLPSqJjrGa3dy9f/wA/gMNW27HbQL1WQidUI8d0jVPFpx83+KJtfId7Tekl PQOZfnJhf2ST9doLPSqx6BzL85ML+ySfrtPQOZfnJhf2ST9doLPSs/zlMyxjDrvkKZ9Cllb4jkgW PVVAR0hFVQVLxi8UVdIq6XXv0vuqel43msaU9Gc6kwFNoyAlHEk1tF15f5ZQWKlVj0DmX5yYX9kk /Xaegcy/OTC/skn67QWelVj0DmX5yYX9kk/Xai1YzVczZx1vP4CoVpfuTj5YsicUbfjtCCD4v2tq +qqu01wTyXfkF7pVY9A5l+cmF/ZJP12vOXasrhxXpcvqhbY8dkCcdddxQRBsBTakSrN0iIiKqqtB a6VWPQOZfnJhf2ST9dp6BzL85ML+ySfrtBZ6VRMSYzW/Y8xeCz+BGB+RLabbTFkNeDMp6OhKvi00 pdrlrz1y1tdbX+cjfu+PJGS7dWLew9LdFmJGDD1dkSjUhBAaZCYpuFyMU0IqqbSgvtKouMleMltQ XSwdXLRcYZ6TuMYqhcSUULiSeN2BIhJsSRFTfmiVJ+gcy/OTC/skn67QWelUTJGM1tLdt7WfwJDs +7QraAliyAIrIkA0pqvi1+ahqWteaoibTe0lPQOZfnIhf2ST9doLPSs8ul0ctU9yBdOueKwZjWu4 xJsTLbgbRFTYlORU2iov/YqVy+ssP/8A6Bwz+p4/6/QabSqfa4WR3WA3PtfVe0Tobu+2/GxcHGz0 qouiGaqLpUVP+1FrktrGazcnvdnHP4AN2qPCdJ9cWTbhyFkeyg+L8kFI6Lvfmp60mtqF7pVY9A5l +cmF/ZJP12noHMvzkwv7JJ+u0FnpVY9A5l+cmF/ZJP12vOXaMwjRXpLnUiIoNARkg4im1RE35f5b QWuqW3h94K2XbH5d9guWC6HcFdaatphLEJZumqC8rxBsVdXSq15onu/fqNxNvqPfsVtF89dLLH9I wWZfZ9X1Pt9wEPjy8Qm9b1vSb+FSfoXqP+Xll/s4v6zQeN0wa4XjxMy8Xa2TLg94cFbK1EtvdaZ7 ygD0YniV32pDh/uiIhAySJ7C8oxvphcImM3CzWu/WyH6VgvwZypZy7ItOPyXRSO2L49rj4twfaI0 VBDyTS7mfQvUf8vLL/Zxf1mnoXqP+Xll/s4v6zQWDJLT6ctU2zyZHbt8+C/Eko2Hy3ygoKEBquh0 Kn5KJbVRXaaVCrOPdPmrXcYNwQrFEdizkkk1aLIEFl0UjyGURUQyNS/ykl5KSpoERBFVIi9vQvUf 8vLL/Zxf1mnoXqP+Xll/s4v6zQR/3NNWqHD9KxZPhLVbrf2ZkDvRZHhBkDt5nuJ3BLxHJA5JxNps tlrVeuNYDc8cYQLPf4MM5AGzMVm06AW1kyHwSKCuqLKj4pwU5o6Psh7PkqF1+heo/wCXll/s4v6z T0L1H/Lyy/2cX9ZoJez2OXByS5XRy695iZpUjjHRtVLfkTqoujIRRGxIRBeCCLiuqIEM5VM9C9R/ y8sv9nF/Waeheo/5eWX+zi/rNB23PE/G2bMbd4/t+svc9vs78NzhtRvdy9vXa5fg+/X7214ZuAQ3 83cyNAs5K/KZmOuSLQ2/NBxoGwEWZBLptvTQbTgRIpOKJCpCof76F6j/AJeWX+zi/rNPQvUf8vLL /Zxf1mghsPwG925t+yzLnFSxx51ueb1DXxEsokWGguCfdUWxV2MiKBAS6EtF7QkmgX7/AKDn/wAm c/8A1Wqx6F6j/l5Zf7OL+s1NxLfeIuCXty/3ePdZiLxadYheGAG1ac2PDme12O97+CIieaqH5yUp Sg/RnOPvq4B/4v8AuaRUzUNnH31cA/8AF/3NIqZoPHpThGF5LdM4nZHiGP3mW3kDbIPz7azIcEEt sFUBCMVVB2RLr3bVfjUD1b6d3bCL7dOonTuzYta7DbrEDtxtzTpQkkJHKQ698i0wTZmTZggOKQkJ AiLsFISv3QX93zv/AGkD+7IFTPXb7yGef7N3H/hnKCmVWenX7ll/+10n/gYFWaqz06/csv8A9rpP /AwKCUjtX695oOL2mZarQpW4p7U2bHclq/wcFt1sWQNtB4dxklMnE33EQQL2iCuZncsuxO+Hi8h2 BNmtAsll+JGObJdhk66DLj7ZrEjtmSNry4PkvIS4tcF2E/f55Y/Jt2YtH2lskkXZjnnr0eZIMxDQ faMRaUnkBPe4w0uiUUFcmy6c91RvNyvMK3S77GnznXGTatIOgkJklbirHemKjAex7ZtrzNHH3/Yb XnxDqt+bZS9iciSF9sspqM68BS4LgXGXJ5mqtMt8AYaGQIk2A7bNHDIV4JviVk6oNXNjoDeWb1Ia k3RuxKM15pNA48jaIZCmk8lLap5J/wBiV/cHE8iuFwgyMgkWmJBiSgkHb4nckE+TfttEr5dvgiOI B8UbXfbRFJUJRTr64/egyn/u13/0oNAv3/Tk/wDlLn/7LWONwzvXW1LdOut9SE9kPgzjxrxKjt9l LL30FBacFB+VRC2mlVd7XSqlbHfv+nJ/8pc//ZawLMrotlzS73Nh+7sT2cmb8E5bQjk6ji2dsS2k hFb49tXPem961Qbv9y7FP/6uTf2puf6xWOfse5V0fOUlwuE+WDthtEwVlXF6UpOOjI7h6cVe2qkO uI+WhFf39JxWvqLn10vEK0Qbxnr02c4Tcdrw1iHmQtm4qbUERPYA181T3a9+qleh3gvSL/o7xHgv VmzeH8Rru9vczjz4+XLWt68t0Fua+/GP+yMv/j4NWGXIjw4r0uW+1HjsgTjrrpoINgKbUiVfJERE VVVarzX34x/2Rl/8fBrj6onaWkxpzIjuYWEL22U8oCyUNNMPeHVVjfKf5z4bjr8Ph/BQQHS3H8Ki HYnMrwaQMKNZIjcmKeCOSCdmDGaB1HR9D9z907p80lnskRdcSURhLNcsmwmaGJ2e+RrvYrRbY8t2 VfbDMtRtNadBWUWQ73ERVYQkc4GAo44iaRoGlv3prpR+Nupn6Tkv+NUPq1fOn7MrG5WNhll3vLU8 kGNdXLsaGwrReQpM2P8AnKQ19hCPkLfESLiihqGEX9vJ8Zi3puK7F7pOtuMuIqKDjbhNmntIJa5A WuQiWtbEV2icfSj72tp/lN0/vSXX9dMrVcbPhECJeO2lydV2XMBsUQWnn3TeNtNEW0AnFHe13x3+ /X89KPva2n+U3T+9JdBQbldbMd5y0eomZ3jHJ8czGBFZuTsBtqCnPsvxhbPUpw02RKqGqGnDgKCi FJ4J1UtjWLm3n892w3qABE8F2h+AemMoR9t9tlVXkpCHtC3vRoSImlHcZcrrZjvOWj1EzO8Y5Pjm YwIrNydgNtQU59l+MLZ6lOGmyJVQ1Q04cBQUQuvDsEuuU456Y6hX3I3rvLaJuGguejXIDCOo40XZ YLh3lIGXlQ+XEm2hVNt7UJC05tlWWsxJ+I4/4aE7wdRLxFea7jS6XZubEW+QoSgTCS0XkCmjX79j z791xT/a2zf8a1VctMPqZizMSB4pzMhHgz35LjLIkPknMy9lxjihbVf8sJ3gv7iq+djz791xT/a2 zf8AGtUFmWs/sGLNyLKl1HA8MkwHLldnLnfbxi8KaMfjdZgk4887PjuIDbQgqojZ6EfIl+aOgLWf 3q6MWDo7m0CZ05ubl5dtt/jDfWhgKPhJMiVIBFcV9Hu0iOiahw3tF0Kr7w4rbc8MwTN3rZauqWG3 LFrutwuDESK+y03aHPEtkDAmj5CgkEg0QEEB+Q5CKKpqum1GXq+Wu55FlWOZt1kx+Dj0tqfbzgN5 VbVebRzm12zaKA240QCRL5vmokAoXcTkq8OI2dcYueS4i1c51wg2S6BGguTO33AaOHGf7fyYAPET eNBRBRBHiKeQolB5Yv8AfDzr+TWX/wBJ9cfVJ+SLNht7MuVGZuN0WPJWM+TLhNjFkOoiOAqGPttA uxVFVEVF8lVF7MX++HnX8msv/pPqP6p/53iP/fZf8BLoKhCx+9xJExVu8K5svvqTY3YbhKJthURF jKXjRQ2T0iuNkig4uuYqggI+cKDecdSHOfyS5zZp3uI2KrOlkyLD8tpsmlaefdEtA4YoS7VE4rvm nNZ6LZhvedMsBjNsyOWzj856LDn2xic3z8XbxU0aeeZBSQCPzV0FRFXXL5pWyX0IfyrGrdKKBh+D XyJcm58V23YazHkMK2LwoLvZmug4ikTToojnFFbRDEtqIhJX3/oSf/JnP/1WuPAPvb4d/s1a/wDg 2a47LdJF86YQr1LBoJFwsrcp0WkVAE3GEJUFFVV1tV1tVrzsk+Va+jOOXCDapt3lx8UtpsQYbLjr shxITXEBEBIvNdIq8VQU2q+SLQTF5vdstBsNTZBeJk8vDRGGjfkyOOuXaZbQnHOKKilxFeKea6RN 1XM2PqS1bRnRsfes1rRtx2U8EuCc2MAIiqTivupHZTyJdoshFDe+0SJXkJYxi+H3zMMP6nw595jx o53Z2NJhPRrncFTtMLKIxccjtOOKgcBdbbbBS4q2iEddquXG+TGZ7UV67ymXBeZuuTRTZhxXBVCE odrRQJFA0cFHH1beBCRUdeHyUM2seV3qZKsw4Le7vcLfOmJGYK7ALsRfnK9onUGU6QALjibdEPYU UPaI0un3775WB/ym5f3XKr+sPw21Yzt5h6dcJ5iQuTp76uvHyLka/vCKkWlNREVcIUI+Re1X8377 5WB/ym5f3XKoPTqVIkRcCvL8V91h1IpIjjRq2Y78l4ue5ldKuni9lr90JFEFSvnLpvChTW2Ykxhl 5yTGjSI7MPEYE191+Qkl5wRFIbhqIi0SoieQCip5IiIn1XNxY8ztNyx1m4MQnpMNxWzc0elTSCqt bTughKHMV2BCvEtoXFfm7pdgk7J5D+MSrdLbmxLZa+9HOCy44y4KymyEwfbMQ0paVVRFRfLaeaKB 2yjGzq2WeZZGXIEu5W1l9idg8OA6DMiSLJIe4bbiIaC7xdbVNKijsSQVPb+k/wB6zEv+5IX/ALAV AwcTwHpfNiRJsoMlu868QI7MOIkWHGYmDKRGkddYabMiE9OKCCSija7HiXtWzCLit3w2y3ZI0aG3 NgMSGocZhtpmIBtiSMtiAj7A70m9rpE2q0HD06/csv8A9rpP/AwKrvWaPKyiK5hEK3Tp7LsVZFyS J2ebSEhjF2jzrSKneAndie/8mQSTi5urF06/csv/ANrpP/AwKs1B8zZHkTWVXfpr61P2KFcLc/d7 bfFvTASIbctlpoSVweTbZcl4EnEuIkYoirx0umQ7/lVuxPHbgysWVYYDEhL7dZQk88/GjuC2EppO 4Kl3mxN/ft+x5j3F4i5YrfeAebuebT5jsewRYrgxQ2RCrLRGTstUHyNHEEVb0h/JgJCqd4xTliXN OoFgZiHabxabTdYovmUplovHQzD2mxNpw0ZUkMEXno1Ej4IhIpth/XXH70GU/wDdrv8A6Vcc/uke xhkF6lg6ce3pJlOi0iKZA3yJUFFVE3pF1tUqndcfvQZT/wB2u/8ApU112/0Izz/u24/+05QQjdsl ZfmUa5TulL2TWuzMT7bKjHLs0zw80nIpcVFZaiJgLRoSKqEnNE15rr2zbpxHvGOuwbB0KmY3c+8w 9HucSHZgdYJt4HPZJqc2ackBR2JiqIS6Wtb613C/23FYz+OSLmxLKcAGUBg3XFDg4qoqBAmrx2g+ faFN69tPmlGdIoud3DhfcmyW9eC8/DwX1Y+X+eBd5s7VEfa4qgkOl9r3/N+cGUWXLL5Zhbx/MrU8 d9hvMx55szrZ3QB6Q2zHfdjNSzcb5d5hS4ioornl7Oql2vvxj/sjL/4+DU31s6d2m2yrt1EZuFzO 43K52dhyK4bfhm0K42wCIEQEPkqRGfeap87SJuoRr78Y/wCyMv8A4+DQWasb/ZX2RMgwu3wQyWz2 qQzKKU3FuU5qMEzg2SKgEabVxFMUT2hH5ReX4KpslYH+zVt1v9QbZdvAxfSHpRqP4rtD3u12ny7f PW+PLz471vzoL9+x+sZ470rtlsO+Qb0gG+QSID4vRkRXSXi2aCKkiLtV5bVCUk3pERL9WZfsXPvE 47/4r/ina02grPSj72tp/lN0/vSXWa/skMau026xLyDdwm2p2ENtcai7IozrkltAVG0cQnEeUxAh bFTVGxRF8/LSulH3tbT/ACm6f3pLqG63XCPCsduRbrCYllPBWLbKB15u68ts9g2GXAceaQnmzMRR zaDpW3N8VCqdGrfnmMzb5dLnhN7i43KchCovE67MaXwyr3higjhuqu2GzUdEOh5Iqtu8NZx+8wr3 EeehnpyNIciTGCIVciyGy4uMucVVEIV+CqippRVRVFWkxbpjj1kzafFyCBf279d5Vpt96Ziy5EuB LUhkJ2AaZLudlsRMDBfNYEf5bgrQxJfp8T10ul+ytmQ36IvEjuWyOxGfjsEyhuGkkQeNVQ3UdHuK jbSEYESIaEjhh1Z9+64p/tbZv+NaqzLVZz791xT/AGts3/GtVZloMrxj9jT05zxZ+W5FkV+gzL5k NyaixY8uO2im0+8JAPNolcJew87pNcQ8tLwUy5rV0b/Y/XC5QcTsnU/JX7pNtLdwhwVfjibkV0DM fnRU0atyHD7aqjiAXLjxRFSu9T+rR4XjNvxdmXei8VJu0uRDbbjJHMVvU0ANt5QV9iUCiToPCRC2 cdn5M+ZKNi/Yg9L7jaBtObXS52y7tSrR3LS4MV2Y3DjkRd1hmR3RCNIF50u42TRbRXEbNVV/gEx0 VsTOLvZfj7EuTLGPfFeN9/ihOE8wy7vQiiJoTAV/eVRUk4oXEZ/F/vh51/JrL/6T658J/wBM87/7 2j/8BFroxf74edfyay/+k+gq8bPLve8sdZtU+z2jHStJToEydb3XH5pI048PsuPRwZbMGJfE3DQf 8mUiIRdbVYxjNL+cxAvuaYP6O9GRZiHjWR2tiYko3GRfiF4x51pe0BvntEQXO03pwFNRSrWCHdcC uTdkjyYrV2xggkwpPEmWXYqmKo8aIqudkHnBV5wjQUamXJptFQN1LXfqRltk6kOenL7eA6bS7YJN y3pkgZEEZJoLHdRmWLxSY70Xw7jQOI4bcWWfBTcecILBZblc5DLSh1Rtr0mEzIG4SH8gsZ20TBhn sy3FaDvtxHZZqwjaJ3VAxMjZJEA7qF2C74xdHew5FfjpJiyY7hCpsvNKbbgKoqqLxMCHYqoqorpV TSrnHVzqHGkXDKWrDmWZ2prD7lHFyIEp5e4xFkR4MwTILij73dV+OYkSMovYc4kjjj7i83SS732Y F2i5IT719CwsreTflNPPLKQpLSE7wMibdSPHiNG27wcQ2yUx5EpGGldJvvV4l/3JC/8AYCrNVZ6T ferxL/uSF/7AVZqBSlKBSlKBSlKBSlKBSlKBS8f6EXn/APH/ANp6lLx/oRef/wAf/aeoPzMpSlB+ jOcffVwD/wAX/c0ipmoXPDBvqlgTjhCACktSIl0iIllkea12+lrV+M4X9OP+NBCQoeM3W9Xc7Pkl yGckgVubFoyaUwgPICNIrjTDwiJ8WUHzRFXh/BXRPxKBPgyIM675bKiSWiZfYeym5G26BJogIVf0 QqiqiovkqLWb3nGZz+N2m2OHjdwCxRYttjMFcUULiyMyEbjj6GCIynbibUE72+ZIm+KIa8YVOlRV bYym3CDtnnwRhjcUbjQlfSSoNCnaInGR77LekVlESK0SiXEAANoqs9Ov3LL/APa6T/wMCv4xJm1W E7tGjzrTHtr05HrfFjPCLcZrsMiQICaENui6eh8lU1X3qteWAToTMbK3HpkdsHMskq2RuIiGngYH mm/f70/noJ+93m0WOKMu9XWDbI5mjYuy5AMgRqiqgopKib0irr+Ba9YU+JN4lDd77RsNyG3mxUmX Gz3xUHNcD3xVdCqqiKKrpCHdbzR05b9inWWZZJEi2XEpRMy7h2AcAoz7KohiBqioryL8395fdVPj 4VHfv8WbdbtZH4RSklzYwzC81I7o4bPuTuNoU9sPa0jgifIUReChql2nxLVapd0nu9mHDYOQ+5xU uDYCpEukRVXSIvkibqrdcfvQZT/3a7/6VQZuBzncLkWSRfbJfHiCYyCXW5orXcebaEJwoLPybwk2 4XDRkpSHSV9SIlK69arhAf6S5Q0xOjOuFbXtCDoqq+z8EWg0m/f9OT/5S5/+y1mWd4piGQ5TDiSc kcs98cXxQRIcpgXpai2baOq04BqSo33B5CibEdEqo2PHQsiudtbyC4tuXCIBjKdQhJ4UVFQ18l86 zLJrS/Mu19kWS42S3pcYrwuOv3Y5LU5wovZAXYZgrLaISNKrg8yUWUFUVDJEDptfS1i13iFd4OZZ MzNguE5Hd4wi4ETZtquljKi+wZp5ovv379VMYDhEHD+94S6XOfziRoYeMVpe0yx3O2I9tsP/AOqW 1Lar5edVDF8UehuMsXXJLS5DTwamrckSdEYspyWw0GgABFDf7fkKIjcceID3dMWHpfCHF7A/bbrk ce4PLKJxJBzwc7qKAIp8eAdtTISMh24vIyInDIlWgkmvvxj/ALIy/wDj4NS+QsWyVYLjGvRNDa3o rrc1XXe2CMqCofI9pxTjva7TXv3UAxOhF1b8SMyOrAYnLQnEcTii+PgeSr7v30/nrpzcoV8wu+WW JdbcEi4W6RFaJ2QiAJuNkKKSptdbVN6RaCAjYzEl2Zbxb+o2Q3CAgG4L0JuDJRxB2hcEbikprtFT Q7Xaa1uuyHiFhxSfOze83W43ORDgruXPFsvCsto4REAMtgnLRmnLipaVRRUQlRa9mOC2q8MykG/Q p8iTa7i07IuEwRJ6a+EYGHDBoRbUQGOPkg+Sg2aCppyTyuWEQpFpvsRqbjYneIt5GSquoiSJEiUj 0F132faVkeScl2oKq8N73Qa9VZ6Ufe1tP8pun96S6lIk6xw4rMSJMt0eOyAttNNOAINgKaQRRPJE RERERKg+mM6FG6c2huTMjsmsi5qguOIK69KTPPzoLTLkR4cV6XLfajx2QJx1100EGwFNqRKvkiIi KqqteVruNvusBufa50WdDd3234zouNnpVRdEKqi6VFT/ALUWoTMChXex+FiXW3DIalRpjSOyEQDN h9t5AIk2ooStoKkiFx5b0WtLVL7Zpd5uVsvLs3FoUwJzZy47EtVHtDJhPKfd4orzuoIimwbTTgpv 5PZho1snxLlGORCd7rQPvRyLio6cacJtxPNE9xgSb9y62m086g8+/dcU/wBrbN/xrVc/T+BY8Wsc i3R37JGR24zJXGIYAHBx8ybRURE8xaVsP4OCIm0RKZrOhSZGKtxpkd40yyzKotuISonjmfPyoLct VnJXbfl2K5RjVjvFsk3AoMiC8ASRPwzrgGAo6g7UPaRd7Tfsr5eVTPpa1fjOF/Tj/jWeMWaWuJxM ekTcW7VpgsQor/i1Ny4NNuMqbbqqKdhp4GODjad5FRzz2jejDXfuj59+QuM/2of/AFGq7Zxu797y O93qHBhSLxcQlDGiSzkg0ARI7CIrhNtqqqrCl83y2nvrMbbi7zOWxpJv4+20wxEJq4jNFXbeITZU g4cYePJWu043HVVVpO3rQqiK2lm6ZwItjgC/cLrCF/wMe3R4/eDkxDjq74cXVQlQ3+LpdwgVA35C mk5EEvi/3w86/k1l/wDSfX9dQI+Jv2yKeX3Bi3xWZSOR33LkUHi92zFOLgmC7UCcTW/NN+XlXLjM 6EOdZxJKZHRk49lQXFcTiq6uHki+795f5qZpHZvj9iKDk0e2Lb7iUp2Qy8yrogsZ9rQI4Jgqqro7 5J83lrz1QczWGxrJkjVxtmNW7J4D1tkQZ9uyK9SXWj5vRnWzFHW5CeyUddpxHzUV2vFKlMfukSz5 QXoHol0ztt7gMBI70O4Ky6y293WxUXBtya5dt0VRF3pF35Km8/l4i9Fu93Wzzsf9CyILNujQPSYx lVgGmREnjRhxXSbJkhQXu8Jg8QqgihC75ZB0/ZkODKtt+sjE1u3W6KciIbMF2UbAvg4vIWnBZT24 zgcQPiUZtB4KAGIaHZbXIsfTCFZZZtHIt9lbiuk0qqBG2wgqoqqIutoutolTXSKcFtwzCZptk4je M272UXW1WA2if/7WuK9XO2uWea23cIhmUdxBEXhVVVRXyTzrkwe4QGOnmINPzozTg41a9ibooqf5 Ez+8q0FhyO8WrI7vb7nM9FPPxpD8e1mqNm4y5ohebbP53PTRoaIu/YLaIiKic92nxLVapd0nu9mH DYOQ+5xUuDYCpEukRVXSIvkibrMMlxuXdbJNsDV3x9uGL91mRJZTl7jrsxqWKNONcNNiKzC9tDNV RtPZTnoeXMMKanW27221ScWctr/iW7bbJElGosHvRo4JIARAhB1t1p8kERTfiDLmKqSEGx1Wb998 rA/5Tcv7rlVEYzbWrZmE27P3i0q074rk83JRXp/eeFxrvoqJrw4CrLftHsCXXbT2V77xOhPdRsHc ZmR3AakXJXCFxFQE9Fy/Nfh7loLFdo85+Ju13Jy13FkxdiTAbFxWXBXaKol5EKpsSHy5ARJtN7r+ p+Z+sMa8wcPk4/a8pXtxr5dYwNyD9hSEAUW3BdFdd1PlCRW15IHJfbT+PS1q/GcL+nH/ABrJJWNP jBs0FIWNzrXDuLZhY5t+OZEZbCJKbVxXn21NEVXGRRoWyEVaQk1zJRD1v3TaelyhXjIc2ijFanQm 2giWp5gmv8oaQGmTCQpNKbiBtxNkiqi7RAHjqGJ+ifVW0+gP+iPAs+A+d+4cE7fz/a+br53n8fOs 0axGczd23380j3UEC1oT0q4IPJYr8Qz5N8CIlXw7zgkruhJ9xEBOZuFecIKFY8Lsdll3W3HIt9uj xXSakIoEbbYiqiq6XW0XW0Sg/wA6dfuWX/7XSf8AgYFRmY2i19TrJbhsWWxUiwLoL70iArUsXBRo wcYXzUPaB5UVCQkVF0QkharrwCdCZjZW49Mjtg5lklWyNxEQ08DA8037/en89UH1FuIYrDto5jCO VGg25knQuAMGaxwkCrAuIyQg02TwOtOK0bvMVVSRUbMA0rNIkd7Ap1luN1dbS4RUtXjnWUM1dkaj gZACCiqpuDtEQR8/wU93N04t2T2ewWuy3pmzsx7ZbmYYlEkuPnIMAEUNVJttG0RBX2dHvmnmPH2q Pa8XeKbLlk/j9q5XtyWatzRJy4t+l25YOv8AEURCBpohbRVNdPKiq35orCMWuNm9Epebji11YiPq +sNZQNx4rp9lFeYbBgWxJtWCMEQAVVluopIoqbwXDrj96DKf+7Xf/Srjn9rj3wMgsss3Qj3BJMV0 mlRDEHOQqoqqKm9KutotY1eraePdBsvtE6/NXWUceQ4DyzRdJ5O2KKfFADtqZCThD8ovIiInDIiK tpyK521vILi25cIgGMp1CEnhRUVDXyXzoKtkFy6pQrjbxtnUeZLZkI60bM5y3Q3Te0hh2iG3OoWg B5SHjvSIqLoV3wlkfV7wD85rKZEhhjuIaxrvCeLk2qiYoIWRVIkISHiiKu0VNb8q5+qttayqzw41 svFpZlRH3pDLj8lB7bqw5DTLgqKKqEDrrRoSeY8dp5oiLRrvgNxUJkey3nFocMoNxix2G3wZRQlP zFRoyFlT7QBJZNAQuCGxrgvJHADR7N625bjrSZTn90uLTV1I3obDMNGFOJNUm21cSG04XEmQQiTg hKJKmhVK6Wvvxj/sjL/4+DX+4gUKz2l+JJutuM3LjOlIrchFTg/KdeBPPXmguIi/w79/vrmYnQi6 t+JGZHVgMTloTiOJxRfHwPJV9376fz0FurMusfT6X1TgQ4UXL4tvtER8zNpqAkgnJIKbZKrncHXD 2h4IiaXly2ukHQPS1q/GcL+nH/Gszh4i0zfJV4W6Y/47xzL0OSkhO8w16WlSnwE+Ox7keQjaoi6J eQr7PmoTfQ/G5GI4vIx1Mmav0CDKcajmNuWP2T5KTrfPmSOohkvmnzSQxVVUeIX6shsuEQrTdGXY E3G4rPpEpQOMOo25BBJzr+mRQdKr7BNRnPMOINCnygogpqPpa1fjOF/Tj/jQQPTORHh9K7dLlvtR 47D11cdddNBBsBucxVIlXyRERFVVWs066WSZlUiHk1hclZBYH7aUIytR+IGOSSB2Yi25twHPmOI2 KkiM+9P3rhYWWp3R20Qhnwo8tu5SprISXkAXCYvkh4QVfNREla48kQuO1XRa0vLk1ml5Aykh+bi0 OY93xJtmWpDDdcBkGp4OqKK9KZRleC8GlRHOKGPDkYcPQjBigT7ll16sHgZkvw4W4JzQnLYaBnSu KamZAR9xQIfZLTackVVWtPut2g2smUnOOtI+YNgaMGQczdbaAVIUVBVTdBERVTfmvuElTGL7gLwe sdxtc/H/ABlzYniaMShbeki96TIWyJURF2smDtCLW2Pf8mCrMDiRlOgymrhjdtjsykfS2xZm48ME l211W2V4CioSQnnF9gPlHtaXzOgvGffuuKf7W2b/AI1qpy63G32qC7Puk6LBhta7j8l0W2w2qImy JURNqqJ/2qlZhZLU9YLRjlpmXwLtJ9d7Q6j/AIwXlcHxccVc4oAdtTJCMh24vMyInDIlWrhnTjV1 x9I1ruNpOW1Ohy2wkzEbbPsSmnlFSFCUdo2qb4r5qnlQVO6YbCyd22XS3QMGyW2wpUiVbZkuE9JN VdlHIdbcNmW02+2LxucQIFEUVRXaqalbMYyjqS5jLLlhkYaNsuJOXJokssrbiyXCkGftztpyNwi0 utctIiIiIlUkWCdMyKFkL2Q26I6V4SfLt8S6IjQJ2orSKLpNKrioEYkUUBpSGQ4HNB5dyuh0+ljg aWli5Ytb5jUEIoxY81fCyHfByorsszRsVF00lISpwJV8OAqa8tgGp4VZ7jbnbtPu7zDs+5yQkSFY a7bfIWgaTgCkainBsPeRKq8l8kVET+MX++HnX8msv/pPqtY9a2YPViffVlW7wSRZLaTHeykmUch1 l1BV0XSJ1trtk2KGDfAeAj3E2STuMzoQ51nEkpkdGTj2VBcVxOKrq4eSL7v3l/moP46k4XYctjtR bjcZNqlSkWK2/EdBt58eDiq17Qry9hXfcnJAJ5EVBccQqoPSeLdpIzpeSy7sLayY5KjzLaqhuSu+ 13WGgcQVclyeYIaISrxJFQBFLTn9ttWVN2iMd4hMsRJxyHXAkiLze4r7QOMrpUR0HHWzEl+ao7Tz REWns4Q9JmCl6y2E7DlMXOPNCDNGOIDKelmpgBg4pc0kN7DmKCTDaqr3AOITcPo5ijFymXMmHHpl wQvHlJkvyBlqRo4XdRxxUd2YiftovtCJe9EVLMzYLZYMYmxLZGZjMjFcQW2mhbANoSrxEURE2qqq 1nzmHPSbFcWJd4x8rjc32ldNJYnGYHk9IcPsuNmL+pMuRxacREVtGV5A4HOtLvVztrlnmtt3CIZl HcQRF4VVVUV8k86Di6TferxL/uSF/wCwFWaqz0m+9XiX/ckL/wBgKs1ApSlApSlApSlApSlApSlA peP9CLz/APj/AO09Sl4/0IvP/wCP/tPUH5mUpSg/QPrLbrfdc7wGBdIMWdDdkl3GJLQuNnq2OKmx JFRdKiL/ANqJU0/056YxH3Ir+AWJ51olAzCBGAVJF0ukVpfLf8Pn7/L3JH9UfvldPP5Sf91u1bso KQNxuhRGmnZCPPK0264rYEe10hEgkooq62qCuvgvuoK96g9LPzdWX9EjfY09Qeln5urL+iRvsar/ AE4m5jeLlOu99OKzb+/LiNRI0wXG23GZJM+QrGBz3Nl7SuqiqqrwHaCExhd0udyfvrN3jNRpUC4j GVpmV4hoUWMw6nA+02WvldqhIq8lLz1pEDo9Qeln5urL+iRvsaeoPSz83Vl/RI32NREG/v2qLnU+ 7y5U6HYpzjraI22jgMJCYkK2PFBQtK4aCpeetbJffTCcvuV8ursC445Kt+mFeB8WJiM+yQooEUiM xol5IooPPaCe+Ok5BL+oPSz83Vl/RI32NPUHpZ+bqy/okb7Goi2ZRLi2bLrpkUPslYHzJ9iJJSSK NhDZfVGiVtpV2h+403yVfa46RO+03u8en2rLf7TBhSJMV2VGKFPOUBA0bQuIam02ort5vWkLftb4 6TkHR6g9LPzdWX9EjfY09Qeln5urL+iRvsa68hukex2C43qWDpx7fFdlOi0iKZA2CkqCiqib0i62 qVw2a4ZM7dUh3jG4sNjsG6syJckkMoSECA3ogbc5KiuEq8OKII6IlJUEIq0Yp0znZNf7WfTqwNBa UiGKJAjkrwSAc4ry7ScVQmXtpxXyQPP2l4THqD0s/N1Zf0SN9jXFi/3xM6/k1l/9J9et2v1zav7t ps9mauJw4rUyYjkzsH23TdEBZRQUXHF7LnkZNinse15qoh0eoPSz83Vl/RI32NPUHpZ+bqy/okb7 GoTG8wvF4bsirYoLB3qwO3eKnpIyQTEmeLRr2U0ijIaVTRF0vNOK6RS5Y2YZPdJWLlZbFZ3I97sB XUm5dycaNs0WPsEIWTRURH08+PtbX5nHRhZfUHpZ+bqy/okb7GnqD0s/N1Zf0SN9jUbkl7yeJmlu stltNnmR5VukyiKXPcjnzacYFURRaNEREeT95eW1+bx9vmzPN5dlv6WW2WN25SAitynyVuWoADhu CCIsaM+u9tHvmgfva5e1xCb9Qeln5urL+iRvsaeoPSz83Vl/RI32NREvK72d1s0C14v3Cu9qOe0k +YsU4xATXNuQHbNQ0jwJsOa8/ZUUHZpKXDJY9q8OxdoVzSY4wLjg2+1y5zIEu0UUdaZVF0qL70Fd aVRTaUH9+oPSz83Vl/RI32NPUHpZ+bqy/okb7Goi85FkiZVaLdYLRbJUO4Wp+du4SnobyE2bA6Ue yahpHk9kh2qqu+HDR+eZ5vLst/Sy2yxu3KQEVuU+Sty1AAcNwQRFjRn13to980D97XL2uITfqD0s /N1Zf0SN9jT1B6Wfm6sv6JG+xqEyLM7tBi2uTb8TnPBOijIJJTMoTZUkRe0QRo75C4O/aQ0BPNEF T0fHyLKcqlXXHWLTY7E81drI5cXBfu5J23BKOiiLrTTgGKd9NEiKh72iigpzCweoPSz83Vl/RI32 NPUHpZ+bqy/okb7GpmqXmeby7Lf0stssbtykBFblPkrctQAHDcEERY0Z9d7aPfNA/e1y9riE36g9 LPzdWX9EjfY17Q+nfS194gHp3YkIWnHE5wo5CqgClpURpF0uteSpUPlN2nFillvVvcnWo5FxtiuR 32AR1WpElps2XRJC4rxdXfFUJCFPP3ot4s3+dn/Jn/8A2joKz6n4T+QWGf2dh/ZU9T8J/ILDP7Ow /sq9ssmXC34rd59pi+LuEaC89EY7ZH3XRBVAOI+ZbJETSea78qpWM3t2b1Dt1rtefu5HaPR0uW+Y MRjQ3gOOAtk+y2IKgo6pcAQTFVRTIhMBQLf6n4T+QWGf2dh/ZU9T8J/ILDP7Ow/sqqvTq6Y3cr1n Fux2/WxHZV1WU0ttfZM0EoUUTkAPtCXyqlslFUU972u0ryw1zK7tcWIM3Jbw0drtzsa9EsSKIuTy cIQNpex7hESdRF47bOISiXM9hb/U/CfyCwz+zsP7KnqfhP5BYZ/Z2H9lVC6cZSV+tUEr5k1syCDM x05V/RW2Ej25xBZRG3EH5nMDfU0dVUJWiUUbFCBOXpLkj8a1YfZGcjtl1fuWLFIjwTdbZFl2OLLb bQKCE4m076OKXcXkwaiIIJBQaP6n4T+QWGf2dh/ZU9T8J/ILDP7Ow/sq/i3uZVM8RHu0C2Wlo2CF uVb7mUl4HF0iKgOxgDy2q7Xkm0RFFUVapWD36dF6bSFjZHOyfKYlgSQ7bZIA+cOW2z5sOdkBcRwn F48HSVwuBa8xNaC8ep+E/kFhn9nYf2VPU/CfyCwz+zsP7KqFiGV3IfTD87PMZuUOJan5Zk1dGrk9 GJviqO9qPGjqrSIpc0VSVV4IKj579enl2vd4v8mE5mzV1jlbnvlLZNh3AIzvNtAMnAiMo05pT4AQ uC5o1XXb0QXj1Pwn8gsM/s7D+yp6n4T+QWGf2dh/ZVWujdyR6wQYMzLJ18vI25grhFk9oztzwgiO NOE22JA5yVU4vEpr2y1tRNamJuVsTsVyefia+lLhZfFxex4dxdzWQ32eOkU/aUU9n378loO31Pwn 8gsM/s7D+yp6n4T+QWGf2dh/ZVUOl99utxv78SVmWO32P4UnFai3qPNktmhggkKMxWEFvREhKXPz 7euPny6ul95xiZkmZRLFdbPIV+8eMBqFIbLuAUOIjjyIC+aK6pIpfS3td7oP4yjHcNjZtiEM8GxQ oVxkSo0llqxxGlJEjG8JoQtbQkJpE89poz8t8VG0eoPSz83Vl/RI32NQucf6f4B/3lL/AOBkV/fV OdlVvtUR/Fj+V7/J8BtRTDJtsVeJERHB48gaNtE0qmbjYoTarzQJf1B6Wfm6sv6JG+xp6g9LPzdW X9EjfY1EZbk19x7wMdqxelnXGEJ+U2zLFknE8lQAjsSTH46c4pohQSNUPiiZZdrh4MLXYIsp/wBF RbnOaS6D7AP8+IRzEVbfLbLibImwX2F5aJVEJf1B6Wfm6sv6JG+xp6g9LPzdWX9EjfY1ES8myZq6 2a0tYpFWdc7Uc0gduqCMR1smkdacIWy2Kd4UQwQ1IvLiI7NPPK8yu1llRYDFgamzSig/LBp2U8DK kqogj4eM6etgeicBpC17PJUNACb9Qeln5urL+iRvsaeoPSz83Vl/RI32NV8svv8Acbrjvq1ZrZJt 96sjl0D0hOOM8Oij6FeDTiJoXx8vPaqvmPD25i7X65tX9202ezNXE4cVqZMRyZ2D7bpuiAsooKLj i9lzyMmxT2Pa81UQ6PUHpZ+bqy/okb7GnqD0s/N1Zf0SN9jVfuF5yxrKsfajW7b9zskh6VaX5bQx 4j7ZxlUifFsnF0jxt+whoS8F4inI08sxyLI5mF2PIsL7oBPBuYTRWlZbys9vxCjoXRQVVts29e1y NwBQm980DpzvHOl2N4lcL8PTWyOjBBHnRWJG320JO4op2U2SDyVEVURVREVURdp3/c8wD8h8Z/ql j/lqN6zjIHorkgy3WnZCWlxHXGm1bAj4+aiKkSiirvSKS6+K++rxQVn7nmAfkPjP9Usf8tPueYB+ Q+M/1Sx/y1ZqUFZ+55gH5D4z/VLH/LT7nmAfkPjP9Usf8tWalBWfueYB+Q+M/wBUsf8ALT7nmAfk PjP9Usf8tWalBWfueYB+Q+M/1Sx/y0+55gH5D4z/AFSx/wAtWalBWfueYB+Q+M/1Sx/y0+55gH5D 4z/VLH/LVmpQVn7nmAfkPjP9Usf8tPueYB+Q+M/1Sx/y1ZqUFZ+55gH5D4z/AFSx/wAtPueYB+Q+ M/1Sx/y1ZqUFZ+55gH5D4z/VLH/LT7nmAfkPjP8AVLH/AC1ZqUFZ+55gH5D4z/VLH/LT7nmAfkPj P9Usf8tWalB5xI8eHFZiRGGo8dgBbaaaBBBsBTSCKJ5IiIiIiJXpSlApSlApSlApSlApSlApSlAp eP8AQi8//j/7T1KXj/Qi8/8A4/8AtPUH5mUpSg/RjOoJ3Lq104hNmIG5Ie4kSeW0tLy+f81aJfcK n3N+eiyGQZlk55g+404gmq+4gRCEtL7xVFRfctUm9/fx6Y/yl/8Auh+rzbbxKG+9RbvImMg1ZHWY EdmZNWPBbBqC1LV1wlQu0RHMMXHURU7bTXsqoLyCuY30fbx55x21yXx7nNSB+8TJDakZ8zLg6RCh KW1Utb2pefmu2PdH27DPkzrdJf78rzfWTeJkkXC0I8lF0iRS4gA8tbRBRN68q5WeoXUGwempeaWm E2zAxu4XmPCOAEORLKL2lVAcZmzAQERxBLnwJFNtQRxOfCwYPd+qk+dOg5HYWbc0cFw4lyegMMts SEUUACZZuMgnhLkRL7TPFGtbVTRQCFtPRaJbHJ5skUhLiBNzG511ly2pCEIgvMHiISXiAjtU3xTj vXlXTZOk7lnlFJiXCW4ZArapLvc2UGlVF8geIhRfJPNE37035rX84bm2SWvog3muX3my3yeeIpf4 0GNEWDIeFqMLr3MldcQ/acaFTBsBFST2faEUk7bf80jdWbVhN4vGJTmnrRLu0o4UF5iTwBxlltvs k+faFTdIkdUjQ+BggAoKZBC2notEtjk82SKQlxAm5jc66y5bUhCEQXmDxEJLxAR2qb4px3ryrpsn Sb0RKKXFfJ6QQK2js25ypZgCqikIK8pqCKoiqoOuXEd74pq/Z3ffVfB79k3hfF+iLbIneH7nDu9p oj4ctLx3x1vS637lqvw5eShlTeG5ZcbZcmrxaJkpqTaIj9scjowcdox34h0lIvFIomBNqCtrrkpI ohA2vpHGtkW7RIkW3JHvEp6XcGnXHHQkOvIiOKSGipokREUU9n+Clk6TeiJRS4r5PSCBW0dm3OVL MAVUUhBXlNQRVEVVB1y4jvfFNRXQTLM9v2M2+ROJl2DbMftzh2+VE5Xi5m5CQu+D5S+0rTppsHTR FIkebNGyaI10BnLbscG5SZ2F3PHmocF2Uku+T4LURVBN8TcYfeJsfeqmoKgiJL5rpFCqWbptfIWV ZJdXZduVi6M24GBFw+QrHSVz5expN98NaVfcW9eW4zOOj17v8qPJh3GyRTEFalJJblOBLb3sW3Aa eZFxtNuew6jg/KEiInIuXoz1C6g2D01LzS0wm2YGN3C8x4RwAhyJZRe0qoDjM2YCAiOIJc+BIptq COJz4WbpxeepUy+PRMxxvwsBYxONzfCx4nB0SFEa7bc+WrnMSIuXyaB29e3zTiFfb6LxvQFossnw 8qPaooRGCckOCbjIgIq26oCKONmgDzbJFA+KbFdJoHRaI3ZrfaWSJiPbgVqIbF1ltvtNrrbaPCSO dvyH2FLj7AeXsDqUh397FbV1evZrNubNguT86PFkznD0I2qJJJkDPkrYK4bioKJxHmuh15VxQ826 lWOx5Je8xxDcC02SVc23ezHg8nWB5IxpudMUu4PJeegQO37j5pxD+rl0kanRYcYkjxAhB2oqwJj8 M2W9InbE2eBI2vENhvivAV17Ka8rh0djzPD64QfDsDHb9G3GTB+SHfBtewochHZcRXaDyLWuS7tM BzPmL4toul8wx7v22S/FfZhvsyFfEmRBfCE8fNlvmqmaPIpK62KI3rkfF0SvOSXTB8dn5fkdluM+ 82SLcYzMaAsSRxVptXjNFeNHdE60ikANiKknspyFECv3LowxcJUOXJly0kQ4vhGHWb7OaNGtoqoq gaKSkoipEWyLiO1XSasPqVdf9Yhf+cv+WrzPGUcGQEF5liWTRIw680rrYHr2SIEIVIUXSqKEKqnl tPfWc9Kc1yq++qpZNHsoes+Nle47duB0fCdrwiEJEZL3O54sTREEO1xUNvfulB433pad67JTXgB1 jkjb8SfIivCJa5D3GuJ8V4iqjvSqIqqbFNctw6Ox5nh9cIPh2Bjt+jbjJg/JDvg2vYUOQjsuIrtB 5FrXJd2nplNvcifl8K/y4Uybbr2EZX4bLzLTgrAhupxaded7eu7pUAkFVRS1yIlV04J4cj6gRDmT ZDMbJESOMmU4/wBkXLdCeIAUyVRDuOuEgJoR5KiIieVBUp3RhiZKbluS5bcgIrUTux77OZNxptSU ENQNFcVFM15FsvaXa103LpI1Oiw4xJHiBCDtRVgTH4Zst6RO2Js8CRteIbDfFeArr2U1a+kcuVKw ZlmZJelu26dOtQyX3FN58Icx6KDrpL850gZEjLyRSUlRERdJbKDKLp0jjXOLaYkuLblj2eUzLt7T TjjQR3WUVG1FARE0KKqIK+z/AAUvfSb0vKGXKfJmQII2rsK5yohmCKqiJqyoKaIpEqIW+PIta5Lv V6UGR3vo+3eoEKDcJL7jELgrKN3iY0SkCiQEZASK4QkAkhGpKiptF2qrVgsmFT7aAMjIZNpuMbAK b7jhrttQRSI0UiXzTaqqqvmq7Wr5SgoHqVdf9Yhf+cv+WoeydJvREopcV8npBAraOzbnKlmAKqKQ grymoIqiKqg65cR3vimtXpQUD1Kuv+sQv/OX/LUPaek3ou3T4MJ8hC4GTkl1y5ynXzNWxb5d41Vw VQAFEVCTXFNarV6UGZY/00esNmi2e2OR24UQO2w25KedUAT3DyPZaT3Iir5IiImkREru9Srr/rEL /wA5f8tX+lBQPUq6/wCsQv8Azl/y09Srr/rEL/zl/wAtX+lBQPUq6/6xC/8AOX/LT1Kuv+sQv/OX /LV/pQUD1Kuv+sQv/OX/AC09Srr/AKxC/wDOX/LV/pQUD1Kuv+sQv/OX/LT1Kuv+sQv/ADl/y1f6 UGQZH0vv9yyfF7oxMtgs2mW+++JuGhEJxnWkQdAqKvI0XzVPLf8A2VYPUq6/6xC/85f8tX+lBkd5 6Pt3W6rdJMl9mYTARzch3iZE5tgRkKEjJChaVw9Kqb9paXDo7HmeH1wg+HYGO36NuMmD8kO+Da9h Q5COy4iu0HkWtcl3rlKDH7l0WiTpUOSRFEOFF8HFSBdZcMGWdovAQZIBRF4hvy8+Ap+Cmum99JGr zKGTcEjmaAjTiNzH2gkNoqqjbwBoXm/aL2HEIfbNNe0W9XpQY+HRaI3ZrfaWSJiPbgVqIbF1ltvt NrrbaPCSOdvyH2FLj7AeXsDr0uHR2PM8PrhB8OwMdv0bcZMH5Id8G17ChyEdlxFdoPIta5LvXKUG Ryejsd6fFmjwjOw4JwIwxLjJjtssGmiAW21EB9w+aJtFAFRUUB134/00esNmi2e2OR24UQO2w25K edUAT3DyPZaT3Iir5IiImkRErTaUGQdR+l9/yTBL1YYMy2NyZ8Q2GiecNAQiTyUlQFXX/Yi1Geqf Wj8XdP8A+uJn6rW5UoMN9U+tH4u6f/1xM/VaeqfWj8XdP/64mfqtblSgw31T60fi7p//AFxM/Vae qfWj8XdP/wCuJn6rW5UoMN9U+tH4u6f/ANcTP1Wnqn1o/F3T/wDriZ+q1uVKDDfVPrR+Lun/APXE z9Vp6p9aPxd0/wD64mfqtblSgw31T60fi7p//XEz9Vp6p9aPxd0//riZ+q1uVKDDfVPrR+Lun/8A XEz9Vp6p9aPxd0//AK4mfqtblSgw31T60fi7p/8A1xM/VaeqfWj8XdP/AOuJn6rW5UoMN9U+tH4u 6f8A9cTP1Wnqn1o/F3T/APriZ+q1uVKDDfVPrR+Lun/9cTP1Wnqn1o/F3T/+uJn6rW5UoMN9U+tH 4u6f/wBcTP1Wnqn1o/F3T/8AriZ+q1uVKDDfVPrR+Lun/wDXEz9Vp6p9aPxd0/8A64mfqtblSgw3 1T60fi7p/wD1xM/VaeqfWj8XdP8A+uJn6rW5UoMN9U+tH4u6f/1xM/VaeqfWj8XdP/64mfqtblSg w31T60fi7p//AFxM/VaeqfWj8XdP/wCuJn6rW5UoMN9U+tH4u6f/ANcTP1Wo+4WjrFCfVpy04EWh ElL05IAU5KWk2cdPP2Vr6CqkdTHwixZMl0XSBkGXCRponDVESQq8QFFIl+CIiqvuRKDK/C9XPxV0 /wD7ROfY13W+8ndcGymNJaaan2qUMKcjDncZ76RScLtGqIpB8oibVE80X97SrT+nHUW+ZJlFwtd6 wLIrBFI1K1ypVveEDbQfMXiUeIOLpSTz4+fHe0RTlcL/ANH+qX+0i/3e3Qfn/SlKD9Jr39/Hpj/K X/7ofrWVxm1FdL1MeZ77N7jNR58F0RKK9wEwVwm1TRGbZi2alvkDLQ+4ErJr39/Hpj/KX/7ofq82 28ShvvUW7yJjINWR1mBHZmTVjwWwagtS1dcJULtERzDFx1EVO2017KqC8gsGMYniuL+I9Wcastk8 Tx8R6OgtR+7x3x5cBTlrkWt+7a/GvDG8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2i fCs5Z6hdQbB6al5paYTbMDG7heY8I4AQ5EsovaVUBxmbMBARHEEufAkU21BHE58LBg936qT506Dk dhZtzRwXDiXJ6Awy2xIRRQAJlm4yCeEuREvtM8Ua1tVNFALnZ8esFmnXCdaLHbLdLuTvenvxYgNO Sj2S83SFEUy2ZLstrsl+K1X7V03x6y5fb8gx0fQLMKNIj+ibZDisQnu+rauuOCLPNTVWI/mhp+4g nuUkKM6QX/KJnTqyXfKbxbL7dLpj7F0hwIEEYct5OyBO77j6tuEpOtDyRGQEiTfFCRB7bvnl2tmK 5Dfp3T7ILa1ZrRJuSLPlQUbkKyCn2UVh94hItL5qGkRF/f0ihear9nwjC7NBuEG0Yhj9uiXJrsz2 IttZablBok4OiIohjoyTRbTRL8Vqs4Pd+qk+dOg5HYWbc0cFw4lyegMMtsSEUUACZZuMgnhLkRL7 TPFGtbVTRQ8emWY5VmvpD5Wy27wNtaY9uC6fipxc/wDL4/yydy2Hx+RLyJ3i57QcPMLmzieKsXS3 3RnGrK1PtkZIkCUEFpHYjCCQo00aDsAQSJOIqiaJU15rUnPiRZ8GRBnRmZUSS0TL7DzaG26BJogI V8iFUVUVF8lRayzDc2yS19EG81y+82W+TzxFL/GgxoiwZDwtRhde5krriH7TjQqYNgIqSez7Qikn g936qT506DkdhZtzRwXDiXJ6Awy2xIRRQAJlm4yCeEuREvtM8Ua1tVNFALbjGJ4ri/iPVnGrLZPE 8fEejoLUfu8d8eXAU5a5Frfu2vxrwxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17ton wqmdOMzzTIIOOpdxx+LLynFnL1AWLHeNuCbaRR+V5OIr4mssT4j21bQFDm5tHa7ekF/yiZ06sl3y m8Wy+3S6Y+xdIcCBBGHLeTsgTu+4+rbhKTrQ8kRkBIk3xQkQQs2N4RheNTjnY5iGP2aW40rJvwLa zHcIFVFUFIBRVHYiuvdtE+FMbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde7aJ8KpnVD Ib5cek2bK7ieW4q7Dx+ZNjXBy4RWiF5ltTbQDiSjcQuSIvuQVQSQlVF4quPUC/45Bl3S7lj98iPY tcclgDaFNtsAiIwXZ8QRGkgXEkjxeFtpNNqXbXmiAF6xjE8VxfxHqzjVlsniePiPR0FqP3eO+PLg Kctci1v3bX417WfHrBZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitZzDzbqVY7Hkl7 zHENwLTZJVzbd7MeDydYHkjGm50xS7g8l56BA7fuPmnGTtt/zSN1ZtWE3i8YlOaetEu7SjhQXmJP AHGWW2+yT59oVN0iR1SND4GCACgpkGgT4kWfBkQZ0ZmVEktEy+w82htugSaICFfIhVFVFRfJUWoW 2YRhdrnQJ1sxDH4Uu3NEzBfj21ltyKBKakDZCKKAqrjiqg6RVMvpLUNgEvJZa5vb7jcbY7eLfd0i szGoj4xtlb4joEsdyQaiKK7pQBwELSl7JERLC9OM8y66wcdl5BbLZKdyLFnL9Fh2gSBxpWUiorXN 5xBcJ3xQkO+2jSioKTqfKUFzxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwpjeE YXjU452OYhj9mluNKyb8C2sx3CBVRVBSAUVR2Irr3bRPhUNd88u1sxXIb9O6fZBbWrNaJNyRZ8qC jchWQU+yisPvEJFpfNQ0iIv7+kXitt/zSN1ZtWE3i8YlOaetEu7SjhQXmJPAHGWW2+yT59oVN0iR 1SND4GCACgpkFzxWyRccx2FZYbjzzUVriT76oT0g18zedJETm64akZnrZEREvmtSdUbB0uK3XqPB iXJ5XWMgUYBT3XZbcZXLbCe0gk4hdpHXTLtiQoiEqDxTWq/gmW59k1wtlvS44y1Jaskh7IAGzvr4 C4pIdjtMiqytOAjrMgSUeXLwZqhCj7aiGs0rLOnGWZLlUHHYuWM2xprLsWcuzQ2g32HIaAkUTTvc +Sk54tDFQRtWVBRQnV05Xj0MybKpFjwa25M9Cmem8RG5x3mydOQ32BiASvumvyxveKFxVQQ7aiQ7 d33KDWaUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKU pQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKzLq4GdO3ZtnFrfjT8NY7ZvOXK4vMudwVd 0iCDJog6XfJV8/PyRAJa02oDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tBjJW3q8m//pWC+W/fd5Se 7l8Y3l839/WvPeuJ8f5sOOX7HsLzV3IktozLtc/Ho3BecdbAfCq1rk42C720S615bRF80VE1X5v8 Xj/u1r+bWuP8XXD8Hh8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64CH5c0pSg/RzMJrVu6xdNZj4m Tbcl3aAiKvnaXk/f/wC2r4twxUrpepj0Ka+ze4zUefBdaaKK9wEwVwm1XRGbZi2alvkDLQ+4ErLe sD/hc8wSTw59l11zjvW9Wp1dbqw9Nullmy7p9Z8tyS7X6XfLzCC5R5TFxdjpbhfFHWmmmm1Ro+1z T2nAPmqKpJxVAELjjEnAMX8R6s4lCsniePiPR1uYj93jvjy4a5a5Frfu2vxrxxsem2NTjnY5hFss 0txpWTfgWqPHcIFVFUFINKo7EV17tonwqJn2sbQEWCkp6UrTCNE89ruOk2qtkZaRE5EoKa6RERS0 iaSqLfsvuEA77LiWaLJtWP79JvOziaf9lgJB9lpGiFzTbg65GGy2i6REJQ12z3TC7NOuE60Y2zbp dyd709+LBZaclHsl5ukKoplsyXZbXZL8VqT9drV/q83/AMg/81fPl/yu92fqPJsMBr0w7cGIBwIU k1jsskay0fVHwZLWgjo5wcXaoLnDaogLfohSCislLaaakKAq6204rgCevNBJRFSRF3pVRN/BPdQT 9qhdLLT4v0X0/s0DxkY4krw1njN99g9c2j465AWk2K7RdJtKk4F0wuBOjzoONsxZcaCNuYfZgsg4 1FFdjHEkXYtIqIqAnsoqe6qlSgu2Jv4hHvssrDjsW2T7s6r02QxCaZKUaci5ukHmZbI12u12S/Fa 6rV09wG0+L9F4PjMDxkY4krw1qYb77B65tHxFOQFpNiu0XSbSqxhH+k8P/8AP/8AQq02gr9swjC7 XOgTrZiGPwpduaJmC/HtrLbkUCU1IGyEUUBVXHFVB0iqZfSWu2z49YLNOuE60WO2W6Xcne9PfixA aclHsl5ukKIplsyXZbXZL8VqGued2y1PZTKuTTzVlxlpjx09ppx8heMO642rLYKfFtk4ziuIijp5 fNO2ekLqVgUt4mmMqtmwaceMjd4A2AArnMiLQiJtCbzaqqI60But8mxIkCfvdptV8tb1rvdshXOA /wAe7FmMC805xJCTkBIqLokRU2nvRFrxs+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W 12S/FajLVmduvni4dkZmjdm4xvxod4t8u1+I46TYq+yhECEQIZgJ8OYbTZCiwuIdWMZvlvtxzPG2 ubIska9TAdgyViQmHo6voTkxWkYQEQXE5qQopNkPzkUUCwY3hGF41OOdjmIY/ZpbjSsm/AtrMdwg VUVQUgFFUdiK6920T4VDdO+mFiwmcsyBJekui060wKwoURthHVaV5UCIwyJEfYY2RoSojQoKiilu ZxvMbHf5xwYS3OPLFpXhYuVplQHHQRUQjbGQ2CuCKkCEobQVMOWuQ7mp8uLAgyJ06SzFiRmieffe cQG2gFNkZEvkIoiKqqvkiJQV+1dPcBtPi/ReD4zA8ZGOJK8NamG++weubR8RTkBaTYrtF0m0r2tm EYXa50CdbMQx+FLtzRMwX49tZbcigSmpA2QiigKq44qoOkVTL6S142rOsfuXixYG9MvRYxyljS7H NiyHmg1zJlp1oTf4qooqNiSopgi+ZiirbnmM3Lj6OlTZnOyNX4fD22S5yhO8u0acW12Z8D4tfuhc S0K6Wgs1Ubp30wsWEzlmQJL0l0WnWmBWFCiNsI6rSvKgRGGRIj7DGyNCVEaFBUUUt9uFdQsdyvFV yWKlztluCC3Oeeu9uehNtMmCny7roo24IiiqRNkYoml5aVFX2tWdY/cvFiwN6ZeixjlLGl2ObFkP NBrmTLTrQm/xVRRUbElRTBF8zFFD2xvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17ton wrxxnEjsdvvjQZLeps+9SVlSLnJGN4ht3w7TAkAgyLScQZb0itqm0XfLeq8cb6j4fkcE5tjub09h IKz2iZgSFWSyiIpqwnDb5ApCBg1yJsyEDQTVBr26d5vaM6sbF3s8W9R2XozMlEuNrfi+y6PIeJuC gO+XvVojH3LtUUVUOLp70yw/CcQLGbbaIUiM/GSLOekQYwu3BpEJBGQrTYC9oTIdkKqqKqltVJVk 7ZhGF2udAnWzEMfhS7c0TMF+PbWW3IoEpqQNkIooCquOKqDpFUy+ktWCq/HyZt285HFGG8cGwNMp IksibrhyCbV5xgWRFTIgZKMaKKFzV/iPtASUFgpVTxvqRhGQwTn2u/slBGCtwSW+05HYOOKIrjgO OiImLfIRd4qvaJUFzgXlXZjeY2O/zjgwluceWLSvCxcrTKgOOgiohG2MhsFcEVIEJQ2gqYctch2F gpVZxnM7dfbffLjHZmjGtElWHGyt8sJfsx2nlQozjIOoao77IAJ8hUFRVUlEfHG+o+H5HBObY7m9 PYSCs9omYEhVksoiKasJw2+QKQgYNcibMhA0E1QaC2Uqs9O83tGdWNi72eLeo7L0ZmSiXG1vxfZd HkPE3BQHfL3q0Rj7l2qKKr24TffWTGIl2OL4OSfNmZE7nc8LKaMmpDHPSIfbdBwOaJxLjtNoqLQT NKVX4+TNu3nI4ow3jg2BplJElkTdcOQTavOMCyIqZEDJRjRRQuav8R9oCSgsFKqeN9SMIyGCc+13 9koIwVuCS32nI7BxxRFccBx0RExb5CLvFV7RKgucC8q7MbzGx3+ccGEtzjyxaV4WLlaZUBx0EVEI 2xkNgrgipAhKG0FTDlrkOwsFKrOM5nbr7b75cY7M0Y1okqw42VvlhL9mO08qFGcZB1DVHfZABPkK gqKqkoj4431Hw/I4JzbHc3p7CQVntEzAkKsllERTVhOG3yBSEDBrkTZkIGgmqDQWylVnp3m9ozqx sXezxb1HZejMyUS42t+L7Lo8h4m4KA75e9WiMfcu1RRVe3Cb76yYxEuxxfByT5szInc7nhZTRk1I Y56RD7boOBzROJcdptFRaCZpUNhN99ZMYiXY4vg5J82ZkTudzwspoyakMc9Ih9t0HA5onEuO02io tTNApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlA pSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UBka6nB7WuLSL7/d5qvx8vm7/AAfm737P NoIz5v8AF4/7ta/m1rj/ABdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgNg+b/F4/7ta/m1 rj/F1w/B4fIV/O01it29nXyQJ7te4H0+Ce7Wv4Na0OuAh+XNKUoP0M6pffJ6efyk/wC63avOP3Rq xWQLTbIfhIzfJRajmggpEqkRKiopciJSIlEh2qqvkqqq13ImWn+tnTJp9oHWykvbExRUX/6Q9+8t bR6JtX4shf0A/wCFBlcp85D6umgoukFEH3CKIiIif9iIiefnVdumJWK5z3JktiUpPa8Qy1OfaYk6 RB+WZA0bd2KIK8xLYogrsURK1ebe8LgTryzc27Zb4lmajFOuMsWWojRvqSCyrpLoXURGyUC0qC+y vnzSpOL6qypAR43oV95zv8G2+0RF2HEae0iea9twkAvokqIulXVBitzxKxXJ64vTGJRu3Hw3iDGc +BJ4c+bPbUTTtcTVS9jjtVVV2qrUxEYCLFZjNk6QMgLYq66ThqiJpORkqkS/FVVVX3qtX+z3zBb/ AAbhIxORj+TuwWubse0SIr7m1QlAN80ESPiqDzIU2i7VERVTixPMem2SjaWYM/H27pdYLM1i0PPR 0niDrCPihMoSkhdskJdbTXntU86CpUrQMYu2AZR4j1ZueM3vw3HxHo59iR2uW+PLgq8d8S1v36X4 VM+ibV+LIX9AP+FBn+Ef6Tw//wA//wBCrTaq1gyfp3cpcNLBkOLTJEt11mJ4Kaw4bxtghug3wVVI hAxIkTzQSRV8lrptGWW6aOSHLZetDWOTnIk92ebQNogsNv8AeQxMhRpWngLZKKom+SCqKlBWcgwu 83aJ1Kx2PJZgRMtaadaubrPfFpXYgQ32UZRwSUgbjAaGpIirIROK9suXjM6Y3W5XKbLuOXdnxlyS 5k5a4RRZDL5WY7Y6rThPHw+cDwLpVBRUVU9oQ2ZvqFgLnY7ecYyfiIzktjjdWF7rDfPuOj7XmA9p 3kSeSds9r7K67YmT2S5R5xWC4wr/ACYcZuScS3TGXHSF1vuM+80Ee6PmCmQiSLvevOgz/Feks/G8 vaymzz8MtU0bbLt7ke1YiMOK4LqtG24ohI7imLjQqXJwhIPZEWiUnCYx0b9X8TkYXb73Cj4vdLIN vvcVi1duRJleFWM7NZd7qiybgoypCTbg7a384zJbzg+Y2DMbTGnWWey467BizXoSvAsmIElpHWke bEl7ZEC7Tfkul0qp51YKDOcH6ZRbFOnHOs3Tkok2C5Dfas+Hpb3HgNR5A4ayHUNpURUVtR0q6Xfl pZOT0twH0HerXa8Usti9M21+2SpVpt7EaR2Hh4miGIf9i6VFTYoqouq8ZHUiOziWUZSWLZAVrx12 UDjiLE5TEjPOtSDZHv74tqyar3O2pJrihKuqsEbLMVk+l/DZLZXvQnL0t25zReA48uXf0XyWuB75 a1wL4LQVLB+ncrFp06dBjdOYEt6C5HYfs+GrBcA1UVFXCSUSuNIooqtpxUlRPaHVdvTXA5WEzpZs XtmVEubSS7s0sJQclXcl/wAonofcVGxdTiisIPAVAVBR9pCsHrZiv5S2X/o30t/nzX+Y/wCtfO/c f/ufN/hrixjqDg+TWORe7FltlnQIkYZUx1uYH+SNEKkhPoqorPsiSqjiCqcS3rS6CFtXT2eGDy8E u2TeJxr0IdihMRIIsSAjE0jSG86ZOI48LYoiEAtBsjVWy2CB44P07lYtOnToMbpzAlvQXI7D9nw1 YLgGqioq4SSiVxpFFFVtOKkqJ7Q6qzYVm2I5rBWZieR2y8tC0266MWQJuMo4iqCOh85sl0vsmiLs VRU2i0s+b4XeYNwnWjL8fuMS2td6e/FuTLrcUNEvN0hJUAdAS7LSaFfgtBWcJ6f3/HZ2Fm/k9smR MZx92xk0FnNpyUBqzpxDWQSASJFjpriSKqOr5cxRua6fYvecXgw7PIyJmbZbVBCBa4rVv7LiMggi BSHFM+66gAKcm0ZFVJxVBdhwmbLkNgvbzzNlvlsuTrDTLzwRJYPE2Dwc2jJBVdCYe0Kr5Enmm0qT oFVOzQbnYslzWaNtenxLi6xdopMuNi488kUIxxREyROSJEaNDMhFVkcfLtkSz9qu1qu3i/RdzhT/ AAck4krwz4udh8Nc2j4qvEx2mxXSptNpUBYeoWNX/KmLFYJrN4afgvy27lAlsSIm2TZB1lSBxSR0 fEMlpRROJppVXaIFF6b9Nb7cumlrtfUKR4N5jEX8YCFDjAy7FYeBlt5TdR98Hj1GaUDFAREUlINl xC9WHHL+mVMZHlN9tlxlw4L8KGFttZwmxB82TdVxHH3lMtx2uOlBETntC2nGTxjLMVyjxHqzktlv fhuPiPR05qR2uW+PLgS8d8S1v36X4V4Y3m+F5LOODjmX4/eZbbSvGxAuTMhwQRURTUQJVQdkKb92 1T40ENiOL5pZrjks6ZlOPzHb26ssUasDzIsSkjsRwJdyz5tIEcVVv2SVVXRinlXFhPT+/wCOzsLN /J7ZMiYzj7tjJoLObTkoDVnTiGsgkAkSLHTXEkVUdXy5ijdmtub4Xc4L0625fj82Iy0886/HuTLj bYMoCvGRCSoggjrakq+Qo4O9ck372jLMVvF0W12jJbLcJ4xglrFizmnXUYMQIHeAkq8CFxtULWlQ xVF80oIzp9i95xeDDs8jImZtltUEIFritW/suIyCCIFIcUz7rqAApybRkVUnFUF2HD26YWufacMj tXRjws+ZJl3OVF5ifhXZcl2SbHMVVD7ZPK3zTyLhyRE3pPaxZljV7tNzvVuvVskWe2ukD1xauDDs bQtA4Zq42ZIAih6XnxVOKrriokXvEyzFZkedIiZLZZDNvjNy5rjU5ohjMON91t1xULQATaKaEukU fNF150EzVTs0G52LJc1mjbXp8S4usXaKTLjYuPPJFCMcURMkTkiRGjQzIRVZHHy7ZEvZhWbYjmsF ZmJ5HbLy0LTbroxZAm4yjiKoI6HzmyXS+yaIuxVFTaLSz5vhd5g3CdaMvx+4xLa13p78W5MutxQ0 S83SElQB0BLstJoV+C0Gc9N+mt9uXTS12vqFI8G8xiL+MBChxgZdisPAy28puo++Dx6jNKBigIiK SkGy4herDjl/TKmMjym+2y4y4cF+FDC22s4TYg+bJuq4jj7ymW47XHSgiJz2hbTjJ2jLMVvF0W12 jJbLcJ4xglrFizmnXUYMQIHeAkq8CFxtULWlQxVF80qZoKNiOL5pZrjks6ZlOPzHb26ssUasDzIs SkjsRwJdyz5tIEcVVv2SVVXRinlXFhPT+/47Ows38ntkyJjOPu2Mmgs5tOSgNWdOIayCQCRIsdNc SRVR1fLmKN2bDsnHJiuZx7Lc4USDOfhNypSsduWbD7rDqtIDhGgibRJ8oIKqKioi+eq/036q2rOr hBh27HcmgeMsg3sXrhCFtttg5DjLQmQmWjc7RuAnmhNpyRfeiBKdPsXvOLwYdnkZEzNstqghAtcV q39lxGQQRApDimfddQAFOTaMiqk4qguw4e3TC1z7Thkdq6MeFnzJMu5yovMT8K7LkuyTY5iqofbJ 5W+aeRcOSIm9J7WfMsav8G4SMTvVsyd2C1zdj2i4MPubVCUA3zQRI+KoPMhTaLtURFVOPE+o+F5K NpZg5FbG7pdYLM1i0PTWUniDrCPihMoakhdskJdbTXntU86D26YWufacMjtXRjws+ZJl3OVF5ifh XZcl2SbHMVVD7ZPK3zTyLhyRE3pLNSlApSlApSs/6b9VbVnVwgw7djuTQPGWQb2L1whC222wchxl oTITLRudo3ATzQm05IvvRA0ClKjIN7izciudljtvG7bWmCkPoiKyhu81Rnki/uogIGQKiKgvNF5o aUEnSq/jeb4Xks44OOZfj95lttK8bEC5MyHBBFRFNRAlVB2Qpv3bVPjSz5vhd5g3CdaMvx+4xLa1 3p78W5MutxQ0S83SElQB0BLstJoV+C0FgpVfwrNsRzWCszE8jtl5aFpt10YsgTcZRxFUEdD5zZLp fZNEXYqiptFpZ83wu8vRGbPl+P3F2Y66zFCLcmXSfNoBNwAQSXkQAQkSJtUQkVdIqUFgpSq/Z8yx q/wbhIxO9WzJ3YLXN2PaLgw+5tUJQDfNBEj4qg8yFNou1REVUCwUqp4n1HwvJRtLMHIrY3dLrBZm sWh6ayk8QdYR8UJlDUkLtkhLraa89qnnVsoFKr+N5vheSzjg45l+P3mW20rxsQLkzIcEEVEU1ECV UHZCm/dtU+Ne+MZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjviWt+/S/CgmaVDYzkLN8mXyIECbC estyW3yBk9v5Quy08LgKBkigTbzZJvReaooiqapjGWYrlHiPVnJbLe/DcfEejpzUjtct8eXAl474 lrfv0vwoJmlV+25vhdzgvTrbl+PzYjLTzzr8e5MuNtgygK8ZEJKiCCOtqSr5Cjg71yTbCs2xHNYK zMTyO2XloWm3XRiyBNxlHEVQR0PnNkul9k0RdiqKm0WgsFK8Z8uLAgyJ06SzFiRmieffecQG2gFN kZEvkIoiKqqvkiJULhWbYjmsFZmJ5HbLy0LTbroxZAm4yjiKoI6HzmyXS+yaIuxVFTaLQWClRmK3 uLkeOwr1DbeZalNciYfRBejmnkbLooq8HWzQgMN7EhIV80qToFKUoFKUoFKUoFKUoFKUoFKUoFKU oFKUoFVnKn1ancicZbbbaDROGae0SmqIiCK/vgi7TXu+KCo2aqb1B/6z/wAP/wDPQcXpCMnzZkJN e7zdTXw9zafAPdr3eWtN8KZKyVrIsfzVlmL2As9wS3c+aKj/ABiq5zROI8U+V4on8Xy4oqAPbVMw v/R/ql/tIv8Ad7dB+f8ASlKD9Jr39/Hpj/KX/wC6H63KsNvf38emP8pf/uh+tyoMsyfG7/crZ1ax e2Q2Vl5M0D8GVLM2oiBIgNwiFXBAlV1tYrjigIqnFxn2k5rxhpPSS8zLhcjZt+JWFqbObkA5Gb8W jDPoB22pHVk2AB1pl5zkAEqCYGexBfZLbKUGQYxhGcWbPYuVBDtitNWidbygS8wudxJDcJh1twX5 LZcRI2EAgFsVFPb5OrpseLFulGS2XBZuCLItj9uveLNWq4XV+4PyJcGQkRxgwjgbfykRDVHG2lca 4E6+qIiEIptlKDM8Jwe4R75JmX2x+E7ltfghMaz263SQ2DpNqYNpIbDs8u2K9xskNFAdfFJO79M7 TJxXIbLBuuQNO3q0SbYr0++Tri2yjwKPNGn3yFSTyXaaXW02iKtXmlBkGAyr7lfWGNl8/GWbS1Dx +XbXzSBNacVXJEVxlFelx45Oivbf0ANqjSiSkaq8IpZunVtzSBkuTTcjtWPxYl6nDcAKBd3pLjRj FixkbUTjNIoqkcj58topIPFfnVeaUGTdI4YRfSN6kM3pLPjEZ2zY8zJssmNIGB7Eg1BkwR532fCx U2JkSwFMVUnjGozoFj2SsYViN2exu2WN2xYs/bIdtJx9hyVIeKObpyRcjAUYu7F2qiL3NXiNFVER XNspQZN0wwXKsWkYBGeteMxoGP43KtM8oU91ScfecYNXm21jihciiiZciFeT5+/giuazSlBkEK3X e/8AR/PsGtlvejXqVOvsYfS0aTDjcJk+WoOg8rJC6Pac5p2+SfNRVHltLNiuN39nKrZcrvDx+3RL FaJFpgNWgz7ckHjjF3OyQCkURSIKC0JvJpxU5+wineaUGWYHhmaWDIsPSYWPvWXG8fkY+JNSHkku gvhVCUqK3x5H4UUVjem9qqOu74jYOl9myrHLHbMZug2VLTZLa1bosiM+67IndoQAHjEgAY/sgqq2 ivbVxNGiB8pc6UGZ2rCsqe6WS+ml0kWWFaWsbOwRZ8Y3ZMiTthGAkm2QtizoUUlaQneSmiI4KBty Th23NJuVN5Td7Vj8KXbLRMhQIcW7vSG5RyDjubddKM2rIisUU9kHFVHFXScEQ7zSgybphguVYtIw CM9a8ZjQMfxuVaZ5Qp7qk4+84wavNtrHFC5FFEy5EK8nz9/BFc1mlKDP28MutywfPsZukbGbL6xy biEWRZIhJyYkNcAkSRLj3JXmqmqLotDpagMpwPNMxyKTcLxBxKytXHFrnjUpyFKelSWgk9om3u4T LXeETAkRlUbQORkjhqaiOv0oMms+C39n0xJk4xZSnu2SXAhHdMzul9jmT3Bey6zJaFBZMmw5qK8l QETS78vGN0yvtzg3+HdSZszVzx+bZwJchm5A5uSgJ3UOYDZMCHDzbbXTykKmqK0Fa/SgplqhZU9f JeR3TE8MhXZq2nEiuxpzsmRJ2SGDRyijNkyyhIqqKA7yU0JEFQ0549EbBf8AEsCteJ3qz4/b2rTB YjMu2mcbwyjQV7rpgTDXbIj9tdKaqpkqrtNleaUGf4TGzCx3fLrzlNosseBc5PpT/wCk3GTPkNk3 EjR+0jXhQVzYxyPY7LZIKAvvqs/sc8cvbeMYVdLpYYWOM2TG3bW1CbR4ZD7r5xifdfadYZVg0ciq qoncRxXiJD0iEezUoMztWFZU90sl9NLpIssK0tY2dgiz4xuyZEnbCMBJNshbFnQopK0hO8lNERwU DbknDtuaTcqbym72rH4Uu2WiZCgQ4t3ekNyjkHHc266UZtWRFYop7IOKqOKuk4Ih3mlBRuiNgv8A iWBWvE71Z8ft7VpgsRmXbTON4ZRoK910wJhrtkR+2ulNVUyVV2myvNKUFG6OSCC1Xq0SINziS4eQ XZ5xJVvfYbMH7lKdaNpwwQHRICEttqSIhJvW0qTynDLVdsHvmM26NCs/pSyHZRkR4g/IMdpwGhQR 47BvumohtETkWtbWrNXFartart4v0Xc4U/wck4krwz4udh8Nc2j4qvEx2mxXSptNpQVOHbc0m5U3 lN3tWPwpdstEyFAhxbu9IblHIOO5t10ozasiKxRT2QcVUcVdJwRDhejeC5L09G3WpQtlytzlogs3 Ca/dH3JcaQwwQGzHQ2l5xOaIbbam32yefVE0QglttXULAbt4v0XnGMz/AAcY5crw11Yc7DAa5unx JeIDtNkukTabWmMdQcHyaxyL3Ystss6BEjDKmOtzA/yRohUkJ9FVFZ9kSVUcQVTiW9aXQWalV+2Z vhd0nQINsy/H5su4tE9BYj3JlxyUAqaEbYiSqYorbiKo7RFAvorXvjOQs3yZfIgQJsJ6y3JbfIGT 2/lC7LTwuAoGSKBNvNkm9F5qiiKpqgmaVDYxlmK5R4j1ZyWy3vw3HxHo6c1I7XLfHlwJeO+Ja379 L8Kk58uLAgyJ06SzFiRmieffecQG2gFNkZEvkIoiKqqvkiJQe1cVttNqtvH0dbIUPhGaiD4dgW+L DXLtNJxRNAHM+I+4eRaRNrXHaMsxW8XRbXaMlstwnjGCWsWLOaddRgxAgd4CSrwIXG1QtaVDFUXz SmMZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjviWt+/S/Cgmaz8LTdUn9TbWzbIUp689u4QCuTBH bn+7AbiIw9pNlpyGSuAKLpt1tdqpKiSlh6hY1f8AKmLFYJrN4afgvy27lAlsSIm2TZB1lSBxSR0f EMlpRROJppVXaJJ4nk9kyqPMl2C4wrlCjSfDJKhzGZDTpdsDXiTRlrXPiqHxLaKuuKiRBnMbplfb nBv8O6kzZmrnj82zgS5DNyBzclATuocwGyYEOHm22unlIVNUVoKmeneIXS1ZUt4u9hZjOhBdjMyl ze5XpwUcNoibRuW0IgJdoVUhXewFNKirq24xlmK5R4j1ZyWy3vw3HxHo6c1I7XLfHlwJeO+Ja379 L8KmaDM7VhWVPdLJfTS6SLLCtLWNnYIs+MbsmRJ2wjASTbIWxZ0KKStITvJTREcFA25xW9chL9kH ZbjkWNwoDzmNzoXftUaVNaTciM60L04mGwTaNSOLSinBRVeSq+Ipplqu1qu3i/RdzhT/AAck4krw z4udh8Nc2j4qvEx2mxXSptNpUZjeb4Xks44OOZfj95lttK8bEC5MyHBBFRFNRAlVB2Qpv3bVPjQe +d2L1owe/Yz4rwnpe2yIPiO3z7XdaIOfHactct62m9e9Kr8O25pNypvKbvasfhS7ZaJkKBDi3d6Q 3KOQcdzbrpRm1ZEViinsg4qo4q6TgiHYMYyzFco8R6s5LZb34bj4j0dOakdrlvjy4EvHfEtb9+l+ FMZyFm+TL5ECBNhPWW5Lb5Aye38oXZaeFwFAyRQJt5sk3ovNUURVNUGf9KeneQ4Vb42PP+CuFpmW SHEuc9b1KSfFfajk2bUUu3y8Ly0bYo40rROvkKIiiKWaTgsS32O9DYim3CfMtr8VmNkV8n3GA4Rj 7IvNPOmnBSREJRHlxUkT3qizWMZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjviWt+/S/CvC25vhd zgvTrbl+PzYjLTzzr8e5MuNtgygK8ZEJKiCCOtqSr5Cjg71yTYUCN0yvtzg3+HdSZszVzx+bZwJc hm5A5uSgJ3UOYDZMCHDzbbXTykKmqK0FTPTvELpasqW8XewsxnQguxmZS5vcr04KOG0RNo3LaEQE u0KqQrvYCmlRV1ZsKzbEc1grMxPI7ZeWhabddGLIE3GUcRVBHQ+c2S6X2TRF2KoqbRa98YyzFco8 R6s5LZb34bj4j0dOakdrlvjy4EvHfEtb9+l+FBRYuIZpebZ1Es2RxMftMTMWnlCTAub01yKZwI8N BVs47KGOmSc5c0XaoOvwq443TO6XODf4N3tbNrduePzbOzclzO5X1yOklAQkRmW2AoK8BJVEkVVb FPcqqlzsPULGr/lTFisE1m8NPwX5bdygS2JETbJsg6ypA4pI6PiGS0oonE00qrtEtlBU8bt9/k5U eQZHjOJWuWEFYYSYEk5st4FNDQFfNhlW2hVCXt6NCI0XYcPb8Ol9myrHLHbMZug2VLTZLa1bosiM +67IndoQAHjEgAY/sgqq2ivbVxNGiB8pJ2fMsav8G4SMTvVsyd2C1zdj2i4MPubVCUA3zQRI+KoP MhTaLtURFVOPE+o+F5KNpZg5FbG7pdYLM1i0PTWUniDrCPihMoakhdskJdbTXntU86C2VTOl9myr HLHbMZug2VLTZLa1bosiM+67IndoQAHjEgAY/sgqq2ivbVxNGiB8pc6r+N5vheSzjg45l+P3mW20 rxsQLkzIcEEVEU1ECVUHZCm/dtU+NBx9I4kqLgzL0yM9EduM6ddRjPtqDzATJj0oGnRX5rog8ImP miEhIiqibW2VDYxlmK5R4j1ZyWy3vw3HxHo6c1I7XLfHlwJeO+Ja379L8KYzkLN8mXyIECbCesty W3yBk9v5Quy08LgKBkigTbzZJvReaooiqaoJmlQ2MZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjv iWt+/S/CvC25vhdzgvTrbl+PzYjLTzzr8e5MuNtgygK8ZEJKiCCOtqSr5Cjg71yTYWClVnGM8xXL LHIumG3iFkvYjDIKLbpLRSE5ipNtkBkPaMuKoiOqGlRUXWl17Y1k43/Enb/DstzbdadlsFbXVYST 3ozzjJtIqOK1yU2iRF7nHzRVJE9wWClQ2F5CzlFgG7swJtv/AMpkxXY0zt91p2O+4w4JdszBdG0W lElRU0te2K3uLkeOwr1DbeZalNciYfRBejmnkbLooq8HWzQgMN7EhIV80oJOlRmK3uLkeOwr1Dbe ZalNciYfRBejmnkbLooq8HWzQgMN7EhIV80qToFKUoFKUoFKUoFKUoFU3qD/ANZ/4f8A+erlVN6g /wDWf+H/APnoKZVMwv8A0f6pf7SL/d7dXOqZhf8Ao/1S/wBpF/u9ug/P+lKUH6TXv7+PTH+Uv/3Q /W5Vht7+/j0x/lL/APdD9bLartart4v0Xc4U/wAHJOJK8M+LnYfDXNo+KrxMdpsV0qbTaUHbSuK1 Xa1Xbxfou5wp/g5JxJXhnxc7D4a5tHxVeJjtNiulTabSuPOchZxPELrk0mBNnxrXGOVIZh9vuq0C bMhRwwFeIopKnJFVBVE2ukUJmlQ0bLMVk+l/DZLZXvQnL0t25zReA48uXf0XyWuB75a1wL4LT1sx X8pbL/0b6W/z5r/Mf9a+d+4//c+b/DQTNKrOMdQcHyaxyL3Ystss6BEjDKmOtzA/yRohUkJ9FVFZ 9kSVUcQVTiW9aXXthWbYjmsFZmJ5HbLy0LTbroxZAm4yjiKoI6HzmyXS+yaIuxVFTaLQWClV+z5v hd5g3CdaMvx+4xLa13p78W5MutxQ0S83SElQB0BLstJoV+C122XIbBe3nmbLfLZcnWGmXngiSweJ sHg5tGSCq6Ew9oVXyJPNNpQSdKVX7FmWNXu03O9W69WyRZ7a6QPXFq4MOxtC0DhmrjZkgCKHpefF U4quuKiRBYKVGWXIbBe3nmbLfLZcnWGmXngiSweJsHg5tGSCq6Ew9oVXyJPNNpUnQKVDYxlmK5R4 j1ZyWy3vw3HxHo6c1I7XLfHlwJeO+Ja379L8KmaBSqzF6hYDKjhIjZxjL7Lnf4ON3VghLsNo69pU LS9tskMvoiqKukXddtoyzFbxdFtdoyWy3CeMYJaxYs5p11GDECB3gJKvAhcbVC1pUMVRfNKCZpVf s+b4XeYNwnWjL8fuMS2td6e/FuTLrcUNEvN0hJUAdAS7LSaFfgte/rZiv5S2X/o30t/nzX+Y/wCt fO/cf/ufN/hoJmlRllyGwXt55my3y2XJ1hpl54IksHibB4ObRkgquhMPaFV8iTzTaVJ0ClKUClKU ClKUClKUClKUClKUCqNbcev7OK5tBeseDNy7rOnvW5iPENIkwHQRGjuAqm3HTXydUdoQ+7dXmlBn PTvD77asqW9XWOzBabguxQZXJZt9cdVw2i5I7MbEo4j2tKDe0dUxU/NkKk+l9myrHLHbMZug2VLT ZLa1bosiM+67IndoQAHjEgAY/sgqq2ivbVxNGiB8pc6UGWdFLURzpM4m7mFrx9o7Fjbc+1vwXAhE rb5KgPCLhCg+FjcjQlVYCuIW3jSkXEM0vNs6iWbI4mP2mJmLTyhJgXN6a5FM4EeGgq2cdlDHTJOc uaLtUHX4VanSgznp3iF0tWVLeLvYWYzoQXYzMpc3uV6cFHDaIm0bltCICXaFVIV3sBTSoq60CeUo IMg4LLL8sWiVhp51WmzPXsiRoJKIqukUkElRPPS+6valBmfT3DMktvRgunV0t+M2bsWRLZGl29xZ 7TzpNEDr7sd1hoF2a9xQVTQ1MkJf3yrDvSnLbndJhS3IVugXPG7pYJIO5Pcr07F8ULKjJbKUiIXt NIKtIjWkTkrjm0ANzpQZzbbBmknqzas2vFnxKC0zaJdplBCnPPyeBuMvNud4mA7oobRCjSiCBzM0 M1NQHii4hml5tnUSzZHEx+0xMxaeUJMC5vTXIpnAjw0FWzjsoY6ZJzlzRdqg6/CrU6UFMslryq4Z xDybJoFltfo62yoMePbrk7N7/iHYxkZEbDPb4eFFEREPl3F8x4+1c6UoKNbcev7OK5tBeseDNy7r OnvW5iPENIkwHQRGjuAqm3HTXydUdoQ+7dVmN0yvtzg3+HdSZszVzx+bZwJchm5A5uSgJ3UOYDZM CHDzbbXTykKmqK0Fa/Sgznp3iF0tWVLeLvYWYzoQXYzMpc3uV6cFHDaIm0bltCICXaFVIV3sBTSo q64ouIZpebZ1Es2RxMftMTMWnlCTAub01yKZwI8NBVs47KGOmSc5c0XaoOvwq1OlBkEbpndLnBv8 G72tm1u3PH5tnZuS5ncr65HSSgISIzLbAUFeAkqiSKqtinuVVS543b7/ACcqPIMjxnErXLCCsMJM CSc2W8CmhoCvmwyrbQqhL29GhEaLsOHt2ylBmdqwrKnulkvppdJFlhWlrGzsEWfGN2TIk7YRgJJt kLYs6FFJWkJ3kpoiOCgbcjI3TO6XODf4N3tbNrduePzbOzclzO5X1yOklAQkRmW2AoK8BJVEkVVb FPcqqmv0oM5ttgzST1ZtWbXiz4lBaZtEu0yghTnn5PA3GXm3O8TAd0UNohRpRBA5maGamoDbc7sX rRg9+xnxXhPS9tkQfEdvn2u60Qc+O05a5b1tN696VM0oKNDtuaTcqbym72rH4Uu2WiZCgQ4t3ekN yjkHHc266UZtWRFYop7IOKqOKuk4Ih1/pT07yHCrfGx5/wAFcLTMskOJc563qUk+K+1HJs2opdvl 4Xlo2xRxpWidfIURFEU1mlBTJOCxLfY70NiKbcJ8y2vxWY2RXyfcYDhGPsi8086acFJEQlEeXFSR PeqLU43TK+3ODf4d1JmzNXPH5tnAlyGbkDm5KAndQ5gNkwIcPNttdPKQqaorQVr9KDOeneIXS1ZU t4u9hZjOhBdjMylze5XpwUcNoibRuW0IgJdoVUhXewFNKirrii4hml5tnUSzZHEx+0xMxaeUJMC5 vTXIpnAjw0FWzjsoY6ZJzlzRdqg6/CrU6UGQRumd0ucG/wAG72tm1u3PH5tnZuS5ncr65HSSgISI zLbAUFeAkqiSKqtinuVVS543b7/Jyo8gyPGcStcsIKwwkwJJzZbwKaGgK+bDKttCqEvb0aERouw4 e3bKUFG6fQMlw/FYdlvTVsWy45aAhsPQFfly56MgIi6rSNj2i4NqvZDvqROIiGnD5R0okFC6dzLn Mg3OM0V3vU8WXbe+ElWXLjKdBUjqHd5EBCSBx5LyTSbXVXmlBTOjIvepLrz0ObE8Te7xKaamRXI7 vaduUlxsibcETHkBiSISIulSvfpHElRcGZemRnojtxnTrqMZ9tQeYCZMelA06K/NdEHhEx80QkJE VUTa2ylBU+kcSVFwZl6ZGeiO3GdOuoxn21B5gJkx6UDTor810QeETHzRCQkRVRNrbKUoFKUoFKUo FKUoFKUoFU3qD/1n/h//AJ6uVU3qD/1n/h//AJ6CmVTML/0f6pf7SL/d7dXOqZhf+j/VL/aRf7vb oPz/AKUpQfpNe/v49Mf5S/8A3Q/WjdK7feYeOyJmQ2HH7DdLrOduEiBaGdCyrmtI+6i6kSNInN5E FCXyRFREIs5vf38emP8AKX/7ofrX4N7izciudljtvG7bWmCkPoiKyhu81Rnki/uogIGQKiKgvNF5 oaUEN0rt95h47ImZDYcfsN0us524SIFoZ0LKua0j7qLqRI0ic3kQUJfJEVEQi9uq1muuRdNMkx2y DCKfdba/BaWY+TTQd4FbUyIQNfZElJEQfNURNpvae2N5vheSzjg45l+P3mW20rxsQLkzIcEEVEU1 ECVUHZCm/dtU+NLPm+F3mDcJ1oy/H7jEtrXenvxbky63FDRLzdISVAHQEuy0mhX4LQQ2K43f2cqt lyu8PH7dEsVokWmA1aDPtyQeOMXc7JAKRRFIgoLQm8mnFTn7CKcLgeGZpYMiw9JhY+9Zcbx+Rj4k 1IeSS6C+FUJSorfHkfhRRWN6b2qo67viNzwrNsRzWCszE8jtl5aFpt10YsgTcZRxFUEdD5zZLpfZ NEXYqiptFqwUFM6X2bKscsdsxm6DZUtNktrVuiyIz7rsid2hAAeMSABj+yCqraK9tXE0aIHykNas Kyp7pZL6aXSRZYVpaxs7BFnxjdkyJO2EYCSbZC2LOhRSVpCd5KaIjgoG3LZZ83wu8wbhOtGX4/cY lta709+LcmXW4oaJebpCSoA6Al2Wk0K/Ba9/WzFfylsv/Rvpb/Pmv8x/1r537j/9z5v8NBX4dtzS blTeU3e1Y/Cl2y0TIUCHFu70huUcg47m3XSjNqyIrFFPZBxVRxV0nBEOv9MMFyrFpGARnrXjMaBj +NyrTPKFPdUnH3nGDV5ttY4oXIoomXIhXk+fv4Irl5wrNsRzWCszE8jtl5aFpt10YsgTcZRxFUEd D5zZLpfZNEXYqiptFpZ83wu8wbhOtGX4/cYlta709+LcmXW4oaJebpCSoA6Al2Wk0K/BaCwVn+E2 /Prbd8uuF0smMh6Yk+kYoRr4+7xfGJGjgyalEHQF4dSVxNqPJEQC1urPEyzFZkedIiZLZZDNvjNy 5rjU5ohjMON91t1xULQATaKaEukUfNF1514YVm2I5rBWZieR2y8tC0266MWQJuMo4iqCOh85sl0v smiLsVRU2i0FG6YYLlWLSMAjPWvGY0DH8blWmeUKe6pOPvOMGrzbaxxQuRRRMuRCvJ8/fwRXNGyy 1uXvFbtZWZDMZ2fBeig89FCS22rgKKETR+y4Kb2oF5EnkvkteOc5CzieIXXJpMCbPjWuMcqQzD7f dVoE2ZCjhgK8RRSVOSKqCqJtdIvtZ8hsF5nXCDaL5bLjLtrvZnsRZYOuRT2ScHRFVUC2BJotLsV+ C0Gc4TguW2nqXbcnlswmYDdtmW6TFdyu5XZ1runHcF5tyUOl2TCAraC3pPaU3NoAaBndi9aMHv2M +K8J6XtsiD4jt8+13WiDnx2nLXLetpvXvSmMZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjviWt+/ S/CvCz5vhd5eiM2fL8fuLsx11mKEW5Muk+bQCbgAgkvIgAhIkTaohIq6RUoM5w+bk+UdU0zJcThQ HoONzbdxdizovcdN+M7HByTKismYErb3stsmjOiJSJXhFJPDMDv7XQqV0uvUHH7I16vraGZlplHK F03GTbdkG0TLPElMu4qIRKSmWyRfNbnYsyxq92m53q3Xq2SLPbXSB64tXBh2NoWgcM1cbMkARQ9L z4qnFV1xUSLtsuQ2C9vPM2W+Wy5OsNMvPBElg8TYPBzaMkFV0Jh7QqvkSeabSgr9kteVXDOIeTZN Astr9HW2VBjx7dcnZvf8Q7GMjIjYZ7fDwooiIh8u4vmPH2qziWK5hid0xaXckssiwYpjcqxr4MpL s15pBikEoWhaXkZ+EEVjDtQ2qi68qoKazVfs+b4XeXojNny/H7i7MddZihFuTLpPm0Am4AIJLyIA ISJE2qISKukVKDOf2OeOXtvGMKul0sMLHGbJjbtrahNo8Mh9184xPuvtOsMqwaORVVUTuI4rxEh6 RCPZqr9oyy3TRyQ5bL1oaxyc5EnuzzaBtEFht/vIYmQo0rTwFslFUTfJBVFSvFvqFgLnY7ecYyfi IzktjjdWF7rDfPuOj7XmA9p3kSeSds9r7K6CzUqGiZPZLlHnFYLjCv8AJhxm5JxLdMZcdIXW+4z7 zQR7o+YKZCJIu96868MHzGwZjaY06yz2XHXYMWa9CV4FkxAktI60jzYkvbIgXab8l0ulVPOgsFKU oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKU oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFU3qD/1n/h//nq5VTeoP/Wf+H/+egplUzC/9H+qX+0i /wB3t1c6pmF/6P8AVL/aRf7vboPz/pSlB+k17+/j0x/lL/8AdD9XILTdUn9TbWzbIUp689u4QCuT BHbn+7AbiIw9pNlpyGSuAKLpt1tdqpKiU29/fx6Y/wApf/uh+tyoMgjdMr7c4N/h3UmbM1c8fm2c CXIZuQObkoCd1DmA2TAhw822108pCpqitBUz07xC6WrKlvF3sLMZ0ILsZmUub3K9OCjhtETaNy2h EBLtCqkK72AppUVdaNSgo3T7HcltOKw8NvXoxuy2u0BamJMCa/4uagALQvqqC34QuAKvECdXk4mn B7ezXfpnaZOK5DZYN1yBp29WiTbFen3ydcW2UeBR5o0++QqSeS7TS62m0RVq80oMzwnEr/Z75Jvc nG4Qz2ra/HhOyM8ul12Rk2XaVJLGmgMmgUnBQiTgPslXt0jwy/4bOkhOK2SolwgsPPutyDJyDKFS 5QYoK2iDbW0JVYBSQm1VxNFz2OjUoMztWFZU90sl9NLpIssK0tY2dgiz4xuyZEnbCMBJNshbFnQo pK0hO8lNERwUDbjCcSv9nvkm9ycbhDPatr8eE7Izy6XXZGTZdpUksaaAyaBScFCJOA+yVaZSgybp hguVYtIwCM9a8ZjQMfxuVaZ5Qp7qk4+84wavNtrHFC5FFEy5EK8nz9/BFcsHT7HcltOKw8NvXoxu y2u0BamJMCa/4uagALQvqqC34QuAKvECdXk4mnB7ezvNKDOcz6cIeBZPasWk3N+6Xi0SLY2l7ya4 SIwI8PAjVHTeRCFFUkVA2uuOxQlWuK49P7/kcGXa7uOP2OIzi1xxqAVoQ3GzCWjA97w5CCRxbSMP FkXHU04o9xOCKep0oMgjdM7pc4N/g3e1s2t254/Ns7NyXM7lfXI6SUBCRGZbYCgrwElUSRVVsU9y qqMBlX3K+sMbL5+Ms2lqHj8u2vmkCa04quSIrjKK9LjxydFe2/oAbVGlElI1V4RTX6UGf4Tb8+tt 3y64XSyYyHpiT6RihGvj7vF8YkaODJqUQdAXh1JXE2o8kRALW6gOn/TzJbGzhFqmW3H4lrs2LTLJ cjtd2faeJ6QbBE+zxYbVCJYompcwJCfNUVVbQnNfpQUa79M7TJxXIbLBuuQNO3q0SbYr0++Tri2y jwKPNGn3yFSTyXaaXW02iKtVnAZV9yvrDGy+fjLNpah4/Ltr5pAmtOKrkiK4yivS48cnRXtv6AG1 RpRJSNVeEU1+lBRunVtzSBkuTTcjtWPxYl6nDcAKBd3pLjRjFixkbUTjNIoqkcj58topIPFfnVX+ kcMIvpG9SGb0lnxiM7ZseZk2WTGkDA9iQagyYI877PhYqbEyJYCmKqTxjWs1E5g86xjkp1h02nB4 aICVFT2x/fSgynoFj2SsYViN2exu2WN2xYs/bIdtJx9hyVIeKObpyRcjAUYu7F2qiL3NXiNFVERX JPphguVYtIwCM9a8ZjQMfxuVaZ5Qp7qk4+84wavNtrHFC5FFEy5EK8nz9/BFcrUHOMuu8Z66Y3jW V3qxxnnWZFxYeFtOTRKLvaZcMXX+PFf3MS5KiiOyRUSwx71dnokeQs25sJIYbfFt4zBwRMEMUIVX Ylok2i+aL5L50Gu0rPMPuNwfyOK0/OlOtlz2JukqL7BfvKtaHQKUpQKUpQKUpQKUpQKUpQKUpQKU pQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKU pQKUpQKpvUH/AKz/AMP/APPVyqm9Qf8ArP8Aw/8A89BTKpmF/wCj/VL/AGkX+726udUzC/8AR/ql /tIv93t0H5/0pSg/Sa9/fx6Y/wApf/uh+tyrDb39/Hpj/KX/AO6H63KgxnObzJs+PdactZvnoe7W jtQrfP8AkfYBi3sSY7HF0SbLnImPj5ipl3+KLtA4xidSMoi3icxEye2ZKkWccRmPbrYL7skHbI5d GpINA8hOCrrfZYATFCbFxDcdcVHQ2xm1wGb5KvbbHGfLjMxX3eZe20yTpNjrek0T7q7RNry896TX bQYBgHUA5OXu4xmmZ4zkOOXOyTn3ZJ3eNOi8mFa7jHdbhRWV+RddNxte6SAIkqNj5uQvSnKsmtmB xm3co7F7g4RDmYzhorGkBdwG2krbwqjIST5m2SEwB82zZNeZNuN19M0oMZ6R5Tk1zvlxhjnmGZdx trr7UNnKI0yQj4kCNruNAY7TK8iQzIXV2rfFE0SHbbve+pMHFchuT2JY+MuFaJMm3NQLtIuDkiUA KTTSsrGZVRJU17J8lXSInntLzSgxPplll2uE68R7r1WxK4W5u0PyHpELJYM+XAUFBEkCjcGO220I kamToupyRryFOSF29I8nvmWTpMG85c9Elrj7B2thluKjlyimpIF/EVbVWydXSJGLYsqPygl3A1r9 KDE+muT3OD0ellDy655pm0DFklP2eW23Jct85qP5xXkjtg6LpOrw7b5q6atnrai4tOmWWXa4TrxH uvVbErhbm7Q/IekQslgz5cBQUESQKNwY7bbQiRqZOi6nJGvIU5IW2UoMM6S53cb56nWu69R4VxuW X4i9cD8MERtyFKa7AD4dtBXZrylK4jiOCrkY1EGwE20sH7Hq8DIxW2Wy4Z3c8lyELRFK6wZasOOW iQACLrLxNNCbbqmSjwkEThK0etqDi1qdKBVGxZly55h1HfKW9GnBOjWePLZQO5Hjhb2JDaCJCQKQ vTZJopCW1PRbERFLzUZJsNsfnXKcTTzcu5QW4Ep9mS404rLauqCCQEitkKvuqhhotl7/ACHQYn0+ 6jZZcsHbu9qyWFnV4PCJF1mxIkVowt9zaaYWNGVuP7Ym8rj/ADAyVTNklaRoUUEufT7I25ucN2ux 9RPX60uW2RInSu5Ce9Hvg6wLDfOG02Id0XJC6cQlLsbDSCe7zithtmMY7Cx+ytPM26C12YzTslx8 mwT3AhuERKKe5EVdIiIiaRERJOgyDpZl2OTV6g2xvqdbLk7FnFJG8NyLcklIqW+HylmrTYtGLZkQ d0wUU7YgW0HVRfSXO7jfPU613XqPCuNyy/EXrgfhgiNuQpTXYAfDtoK7NeUpXEcRwVcjGog2Am2m 50oMs/Y9XgZGK2y2XDO7nkuQhaIpXWDLVhxy0SAARdZeJpoTbdUyUeEgicJWj1tQcWmOMd7oZPsw H240GdcbPDTW+zFjXB6NHD4lwaabHaqpFx2qqqqq6nUE7jsWJhcfGLI0EWHDjMxYjZmRI201xQR5 Lsl0Iom12q/v0GLWTpW7cpvS3KbnlN5tcnBba3CKBb3FdjyRaFBE0cTQsE6KCj4ly2Gm9ogo4Vyy GUEqfsOOgRdqJbTkRkaoi/v6U1HaeS63+/Up6k3X/WIX/nL/AJaepN1/1iF/5y/5aCh9PLSTPWsr lcMb9IOyHyct950wfo9hIaNqxszR0NuC8XFsVH5barsj1vlU/HcXuFuvLEx96KTbfLaARKvmKp++ n8NXCgo2LMuXPMOo75S3o04J0azx5bKB3I8cLexIbQRISBSF6bJNFIS2p6LYiIpnPT7qNllywdu7 2rJYWdXg8IkXWbEiRWjC33NpphY0ZW4/tibyuP8AMDJVM2SVpGhRQTbJNhtj865Tiaebl3KC3AlP syXGnFZbV1QQSAkVshV91UMNFsvf5DpithtmMY7Cx+ytPM26C12YzTslx8mwT3AhuERKKe5EVdIi IiaRERAo3T7I25ucN2ux9RPX60uW2RInSu5Ce9Hvg6wLDfOG02Id0XJC6cQlLsbDSCe4zpZl2OTV 6g2xvqdbLk7FnFJG8NyLcklIqW+HylmrTYtGLZkQd0wUU7YgW0HVa/SgwzpLndxvnqda7r1HhXG5 ZfiL1wPwwRG3IUprsAPh20FdmvKUriOI4KuRjUQbATbSwfserwMjFbZbLhndzyXIQtEUrrBlqw45 aJAAIusvE00JtuqZKPCQROErR62oOLWp0oKZ0X+TwFu3h5RrXcrla4Yf/wBKLFnPx47e/evFppse S7JeO1VVVVV0X+TwFu3h5RrXcrla4Yf/ANKLFnPx47e/evFppseS7JeO1VVVVWzWK1wLHY4FktbH h4FvjNxYrXMi7bTYoIDslVV0KIm1VV+NLFa4FjscCyWtjw8C3xm4sVrmRdtpsUEB2Sqq6FETaqq/ Gg7aUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQK UpQKUpQKUpQKUpQKUpQKpvUH/rP/AA//AM9XKqb1B/6z/wAP/wDPQUyqZhf+j/VL/aRf7vbq51TM L/0f6pf7SL/d7dB+f9KUoP0mvf38emP8pf8A7ofrcqw29/fx6Y/yl/8Auh+tyoMsyfJL/bbZ1ayi 2TGUl4y0DEGLLA3YihHgNzSJWxMVR1xZTjamJInFtn2V4Ly47j1QyWwzbj6w2zH2oltnSIEhxqU/ x7w2krohKqNESNNtijKkgGTqkriA1xRk7/Nw6wT515eucBm4RLy1GGdbpbIOxHTYUlF5WiHROqit ipltVFhlPLgle9txPFbbMGZbsassOSHa4vR4LTZj2mSZa0QiipwaM2x+iBEKaRVSgz/Ccvyy75xJ 6f5xbfBvTbI/PAo4NQJDTQutsrpI8+Uac1eXi5yaUVaLjzXat1nph1CzhOl7+TXQ4TltxrEYtweg XCMfpW5klvV1X0kpIMOy6Y7F5W1IlR5sgE2lJdZi9PcBixwjxsHxlhlvv8G27UwIj320ae0iDpO4 2KAX0hREXaJqu1nE8VYulvujONWVqfbIyRIEoILSOxGEEhRpo0HYAgkScRVE0SprzWgqWD3/AKnO TpwZXh7xRG4Lj7DrMaJDcJ4FHjHEEuElDJxCJUIiaEFb0qlz2Hbd88u1sxXIb9O6fZBbWrNaJNyR Z8qCjchWQU+yisPvEJFpfNQ0iIv7+kWZxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17 tonwqwUGc22/5pG6s2rCbxeMSnNPWiXdpRwoLzEngDjLLbfZJ8+0Km6RI6pGh8DBABQUy7cHS4rd eo8GJcnldYyBRgFPddltxlctsJ7SCTiF2kddMu2JCiISoPFNadO+mFiwmcsyBJekui060wKwoURt hHVaV5UCIwyJEfYY2RoSojQoKiiluZxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17to nwoKNgmW59k1wtlvS44y1Jaskh7IAGzvr4C4pIdjtMiqytOAjrMgSUeXLwZqhCj7aj7dOMsyXKoO OxcsZtjTWXYs5dmhtBvsOQ0BIomne58lJzxaGKgjasqCihOrpyrbjOJHY7ffGgyW9TZ96krKkXOS MbxDbvh2mBIBBkWk4gy3pFbVNou+W9VxdPemWH4TiBYzbbRCkRn4yRZz0iDGF24NIhIIyFabAXtC ZDshVVRVUtqpKoVnoZk2VSLHg1tyZ6FM9N4iNzjvNk6chvsDEAlfdNflje8ULiqgh21Eh27vuVrN V+2YRhdrnQJ1sxDH4Uu3NEzBfj21ltyKBKakDZCKKAqrjiqg6RVMvpLVgoMTuLMhOgfU3IRvOQDd FdyF1uQl6loUdYc2YkdGU7mmRFGwRRbQUJBRCQk8qtlkyHKpN8h2uTcsZlen7JKutplW6M65Hh9o owiJGrv+WAXiwVHBSPtG1XincThKWnArRFt15tFzfeyCy3Wc9NK13aPGejMG7IckmgIjQkQq65yT uKapxHSprzmbPj1gs064TrRY7Zbpdyd709+LEBpyUeyXm6QoimWzJdltdkvxWgz/AA3PL/kc7EoI TsfYl5Bgi351hIpm5DlbjIDij3kUo5LINEBeJKrJacXz49vSC75dd+nVkmZBlWPyr1e8fYuFvELU TLgKrIK446CSPlxE3meXbRlEVdezzHjbYuJ4rFugXSNjVlYntyX5YSm4LQui++KC86hoO0NwRRCL eyRERVXVe1nx6wWadcJ1osdst0u5O96e/FiA05KPZLzdIURTLZkuy2uyX4rQZzhubZJa+iDea5fe bLfJ54il/jQY0RYMh4WowuvcyV1xD9pxoVMGwEVJPZ9oRSwQ7lmkLKm8Wu91x+bLudomTYEyLaHo 7cU45x29OtFJcV4SWUK+ybaojapteaKFms+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2 W12S/Fa4rPhGF2aDcINoxDH7dEuTXZnsRbay03KDRJwdERRDHRkmi2miX4rQVPpTmuVX31VLJo9l D1nxsr3HbtwOj4TteEQhIjJe53PFiaIgh2uKht790rTKr9swjC7XOgTrZiGPwpduaJmC/HtrLbkU CU1IGyEUUBVXHFVB0iqZfSWrBQZ+3md1tuD59k10k4zevVyTcTix7JLJeLEdrmEeSRcu3K8lQ0RN DsdJVTyPJclw7qLNn3+72y9u23BLtd3INtffhNuow9GVruRDdeFsv3YRkIqqaGYqKI0nLX7VabVa fF+i7ZCgeMknLleGYFvvvnrm6fFE5GWk2S7VdJtajLPhGF2Z6I9Z8Qx+3Ow3XXopxbay0TBugIOG CiKcSMBESVNKqCiLtESgqeK5N1KZ9KvZjj0KDAjW16W3PmpHtkdp1vSo24rc2YvAhUiJ3Qo2jS+T nJEGFZ6hdQbB6al5paYTbMDG7heY8I4AQ5EsovaVUBxmbMBARHEEufAkU21BHE58NAtXT3AbT4v0 Xg+MwPGRjiSvDWphvvsHrm0fEU5AWk2K7RdJtK7cYxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4CnLX Itb921+NBCwHM+Yvi2i6XzDHu/bZL8V9mG+zIV8SZEF8ITx82W+aqZo8ikrrYojeuR+PSC7Zpk2K 2TK8jk4+zEu9oYlhb4EN7uNG4AEhK+buiFUUl7faRRUkHmfDmczZ8IwuzQbhBtGIY/bolya7M9iL bWWm5QaJODoiKIY6Mk0W00S/Fa98YxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4CnLXItb921+NBX8A l5LLXN7fcbjbHbxb7ukVmY1EfGNsrfEdAljuSDURRXdKAOAhaUvZIiJYXpxmeaZBBx1LuOPxZeU4 s5eoCxY7xtwTbSKPyvJxFfE1lifEe2raAoc3No7VttWA4fY/FvYtjdlxqfJjHG8fabZGYkNiWl8l 7aouiQS0SEOxTaLrVePS/p7jXTrHWrPj0JkSFoGn5qxGGpMtA5cFeJlsEcIUJUQlTa+aqqkpKoVL Dc2yS19EG81y+82W+TzxFL/GgxoiwZDwtRhde5krriH7TjQqYNgIqSez7Qilgh3LNIWVN4td7rj8 2Xc7RMmwJkW0PR24pxzjt6daKS4rwksoV9k21RG1Ta80ULNZ8esFmnXCdaLHbLdLuTvenvxYgNOS j2S83SFEUy2ZLstrsl+K1xWfCMLs0G4QbRiGP26JcmuzPYi21lpuUGiTg6IiiGOjJNFtNEvxWghu kF2zTJsVsmV5HJx9mJd7QxLC3wIb3caNwAJCV83dEKopL2+0iipIPM+HM7zUNjGJ4ri/iPVnGrLZ PE8fEejoLUfu8d8eXAU5a5Frfu2vxqZoKN0cjkdqvV3kTrnLlzMguzLiyrg++2AMXKU00DTZmoNC ICI6bQUVBTe9JVSsGO5V0vxidmWR5Xesm9X8IVHYUi8Outy5wHIlSnC5h/8A4mmnFRSRtCQkXSVo 2HYwOMlcwj3q5zYk6c/NbiykY7cQ333X3UaUGxNRI3SX5QjVERERU892Cgo0OXkoZU3huWXG2XJq 8WiZKak2iI/bHI6MHHaMd+IdJSLxSKJgTagra65KSKNS/Y65LnGT2e0elJsKPbYNktivR7hCM7rN J2GhLKR9JJArJn7QuqHIlF5shA2lJdGs+EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdGSaL aaJfite7OJ4qxdLfdGcasrU+2RkiQJQQWkdiMIJCjTRoOwBBIk4iqJolTXmtBTOkuAZVi9wt8zI8 1vV78NjbFvdZkXR2Q27OKQ89KfITFOWuTTbRr7SNoQknki1plKUFGtt4lDfeot3kTGQasjrMCOzM mrHgtg1Balq64SoXaIjmGLjqIqdtpr2VUF5VJnqF1BsHpqXmlphNswMbuF5jwjgBDkSyi9pVQHGZ swEBEcQS58CRTbUEcTnw01cZtRXS9THme+ze4zUefBdESivcBMFcJtU0Rm2Ytmpb5Ay0PuBKYxie K4v4j1Zxqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8aCpYPd+qk+dOg5HYWbc0cFw4lyegMMtsSEUU ACZZuMgnhLkRL7TPFGtbVTRQjMNzbJLX0QbzXL7zZb5PPEUv8aDGiLBkPC1GF17mSuuIftONCpg2 AipJ7PtCKXnG8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2ifCu2z49YLNOuE60WO2W 6Xcne9PfixAaclHsl5ukKIplsyXZbXZL8VoKZbb/AJpG6s2rCbxeMSnNPWiXdpRwoLzEngDjLLbf ZJ8+0Km6RI6pGh8DBABQUytud331Xwe/ZN4Xxfoi2yJ3h+5w7vaaI+HLS8d8db0ut+5ahbV03x6y 5fb8gx0fQLMKNIj+ibZDisQnu+rauuOCLPNTVWI/mhp+4gnuUkK50FGhy8lDKm8Nyy42y5NXi0TJ TUm0RH7Y5HRg47RjvxDpKReKRRMCbUFbXXJSRRpnQTLM9v2M2+ROJl2DbMftzh2+VE5Xi5m5CQu+ D5S+0rTppsHTRFIkebNGyaI10yz4Rhdmg3CDaMQx+3RLk12Z7EW2stNyg0ScHREUQx0ZJotpol+K 17s4nirF0t90ZxqytT7ZGSJAlBBaR2IwgkKNNGg7AEEiTiKomiVNea0EYzlt2ODcpM7C7njzUOC7 KSXfJ8FqIqgm+JuMPvE2PvVTUFQREl810i0VnqF1BsHpqXmlphNswMbuF5jwjgBDkSyi9pVQHGZs wEBEcQS58CRTbUEcTnw2CfEiz4MiDOjMyoklomX2Hm0Nt0CTRAQr5EKoqoqL5Ki1GYxieK4v4j1Z xqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8aCsdOLz1KmXx6JmON+FgLGJxub4WPE4OiQojXbbny1c 5iRFy+TQO3r2+aceOHf3sVtXV69ms25s2C5Pzo8WTOcPQjaokkmQM+StgrhuKgonEea6HXlVsxvC MLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwpjeEYXjU452OYhj9mluNKyb8C2sx3CB VRVBSAUVR2Irr3bRPhQUaHm3Uqx2PJL3mOIbgWmySrm272Y8Hk6wPJGNNzpil3B5Lz0CB2/cfNON mgOZ8xfFtF0vmGPd+2yX4r7MN9mQr4kyIL4Qnj5st81UzR5FJXWxRG9cjk8bwjC8anHOxzEMfs0t xpWTfgW1mO4QKqKoKQCiqOxFde7aJ8K98YxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4CnLXItb921+ NBWOiV5yS6YPjs/L8jstxn3myRbjGZjQFiSOKtNq8Zorxo7onWkUgBsRUk9lOQol6njKODICC8yx LJokYdeaV1sD17JECEKkKLpVFCFVTy2nvris+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbM l2W12S/Fa7Z8SLPgyIM6MzKiSWiZfYebQ23QJNEBCvkQqiqiovkqLQZz0pzXKr76qlk0eyh6z42V 7jt24HR8J2vCIQkRkvc7nixNEQQ7XFQ29+6VM9Mpt7kT8vhX+XCmTbdewjK/DZeZacFYEN1OLTrz vb13dKgEgqqKWuREqydswjC7XOgTrZiGPwpduaJmC/HtrLbkUCU1IGyEUUBVXHFVB0iqZfSWmN4R heNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FBGdOCeHI+oEQ5k2QzGyREjjJlOP9kXL dCeIAUyVRDuOuEgJoR5KiIieVe/SOXKlYMyzMkvS3bdOnWoZL7im8+EOY9FB10l+c6QMiRl5IpKS oiIuk7MbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde7aJ8K7cVskXHMdhWWG4881Fa4k ++qE9INfM3nSRE5uuGpGZ62RERL5rQSdUzHsjup2PL7jdLthkv0RcprcUoNwII8ZhoUIG5zpIXZe Hz7qoKoKKioK+6rnUYzj1gZg3KCzY7Y3Eurrr1xYCICNzDdTTpuiiacI08iUtqSe/dBn+GZF1LmZ U5YclZtlpdk2iVJgJJs6NuE82bAI4iMXCSJtB3k5iRskqkHBSTmodvSC75dd+nVkmZBlWPyr1e8f YuFvELUTLgKrIK446CSPlxE3meXbRlEVdezzHjbcYxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4CnLX Itb921+Ne1nx6wWadcJ1osdst0u5O96e/FiA05KPZLzdIURTLZkuy2uyX4rQZ/02y/NMjv1lhTZe PkLFoefyePHtjzbkOakl2OEdtwpBCo9xmSCkguIqwyLaC83x94d/exW1dXr2azbmzYLk/OjxZM5w 9CNqiSSZAz5K2CuG4qCicR5rodeVWzC8YHGhupnerneZd1nJNlSp6MI4Row0wiIjLbYIKAwCeQ73 tVVd0xvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwoK/04vPUqZfHomY434WAsYn G5vhY8Tg6JCiNdtufLVzmJEXL5NA7evb5pxvU8ZRwZAQXmWJZNEjDrzSutgevZIgQhUhRdKooQqq eW099QuN4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FTU+JFnwZEGdGZlRJLRMvs PNobboEmiAhXyIVRVRUXyVFoM5w3Lcwf6WN9ScplYyxAdxtLt4CNFkj2S7Au8zk8jXgooSqAsEQc kFFd4cnK/G6q5hYZ1/g5nYWSl27FpuRMsI1HhOKEZQTgotTZi8XFNUQy7aCrZaRza8NTxjE8Vxfx HqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX414WfCMLsz0R6z4hj9udhuuvRTi21lomDdAQcMFEU 4kYCIkqaVUFEXaIlBTLPIyWN19t1pv8AkNsuDrmLTZLjNtN+M3oZUQWichG86IknJ5BfQtmhGCoi NIpe9tyq94/i3U28X9YV3m4vJeeXwYvRWpIt2uLJQRB117s758V4Lx2inx5EW7ZZ8IwuzPRHrPiG P252G669FOLbWWiYN0BBwwURTiRgIiSppVQURdoiUxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgp AKKo7EV17tonwoIyyXTKrfnEPGcmn2W6ekbbKnR5FutrsLseHdjAQEJvvdzn4oVRUUOPbXyLl7Nz qGxjE8VxfxHqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX41M0ClKUClKUClKUCqb1B/6z/w//wA9 XKqb1B/6z/w//wA9BTKpmF/6P9Uv9pF/u9urnVMwv/R/ql/tIv8Ad7dB+f8ASlKD9Jr39/Hpj/KX /wC6H63KsNvf38emP8pf/uh+tyoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFUzHsjup2PL7jdLthkv0RcprcUoNwII8ZhoUIG5zpIXZeHz7qoKoKKioK+6rn UYzj1gZg3KCzY7Y3Eurrr1xYCICNzDdTTpuiiacI08iUtqSe/dBljPULqDYPTUvNLTCbZgY3cLzH hHACHIllF7SqgOMzZgICI4glz4Eim2oI4nPhZunF56lTL49EzHG/CwFjE43N8LHicHRIURrttz5a ucxIi5fJoHb17fNONnxjE8VxfxHqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX414Y3hGF41OOdjm IY/ZpbjSsm/AtrMdwgVUVQUgFFUdiK6920T4UFTh397FbV1evZrNubNguT86PFkznD0I2qJJJkDP krYK4bioKJxHmuh15VxQ826lWOx5Je8xxDcC02SVc23ezHg8nWB5IxpudMUu4PJeegQO37j5pxvO N4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FMbwjC8anHOxzEMfs0txpWTfgW1mO 4QKqKoKQCiqOxFde7aJ8KCMgOZ8xfFtF0vmGPd+2yX4r7MN9mQr4kyIL4Qnj5st81UzR5FJXWxRG 9cjrOG5tklr6IN5rl95st8nniKX+NBjRFgyHhajC69zJXXEP2nGhUwbARUk9n2hFNAxjE8VxfxHq zjVlsniePiPR0FqP3eO+PLgKctci1v3bX417WfHrBZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMt mS7La7JfitBnMPNupVjseSXvMcQ3AtNklXNt3sx4PJ1geSMabnTFLuDyXnoEDt+4+acfazyMljdf bdab/kNsuDrmLTZLjNtN+M3oZUQWichG86IknJ5BfQtmhGCoiNIpXPG8IwvGpxzscxDH7NLcaVk3 4FtZjuECqiqCkAoqjsRXXu2ifClnwjC7M9Ees+IY/bnYbrr0U4ttZaJg3QEHDBRFOJGAiJKmlVBR F2iJQWCqZj0m63TK8+Nm4dl6BJj2mA26JOxWeMJqSjxNIQqRq5NJD4kPIGmh8lFSW51DLjNqK6Xq Y8z32b3Gajz4LoiUV7gJgrhNqmiM2zFs1LfIGWh9wJQZlZOqWVRMHh5Rk1tssn0hhErKY8S3K612 fCtRiJonDUufd8SJJoB7XFR298+rbDuWaQsqbxa73XH5su52iZNgTItoejtxTjnHb060UlxXhJZQ r7JtqiNqm15ooTNswjC7XOgTrZiGPwpduaJmC/HtrLbkUCU1IGyEUUBVXHFVB0iqZfSWvfGMTxXF /EerONWWyeJ4+I9HQWo/d4748uApy1yLW/dtfjQVjoleckumD47Py/I7LcZ95skW4xmY0BYkjirT avGaK8aO6J1pFIAbEVJPZTkKJZ87vvqvg9+ybwvi/RFtkTvD9zh3e00R8OWl47463pdb9y17WfHr BZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitSdBRocvJQypvDcsuNsuTV4tEyU1JtE R+2OR0YOO0Y78Q6SkXikUTAm1BW11yUkUaZ0EyzPb9jNvkTiZdg2zH7c4dvlROV4uZuQkLvg+Uvt K06abB00RSJHmzRsmiNdMs+EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdGSaLaaJfite7OJ 4qxdLfdGcasrU+2RkiQJQQWkdiMIJCjTRoOwBBIk4iqJolTXmtBGM5bdjg3KTOwu5481Dguykl3y fBaiKoJvibjD7xNj71U1BUERJfNdItFZ6hdQbB6al5paYTbMDG7heY8I4AQ5EsovaVUBxmbMBARH EEufAkU21BHE58NgnxIs+DIgzozMqJJaJl9h5tDbdAk0QEK+RCqKqKi+SotRmMYniuL+I9Wcastk 8Tx8R6OgtR+7x3x5cBTlrkWt+7a/GgrHTi89Spl8eiZjjfhYCxicbm+FjxODokKI12258tXOYkRc vk0Dt69vmnHjh397FbV1evZrNubNguT86PFkznD0I2qJJJkDPkrYK4bioKJxHmuh15VbMbwjC8an HOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde7aJ8KY3hGF41OOdjmIY/ZpbjSsm/AtrMdwgVUVQU gFFUdiK6920T4UFGh5t1KsdjyS95jiG4Fpskq5tu9mPB5OsDyRjTc6YpdweS89Agdv3HzTjZoDmf MXxbRdL5hj3ftsl+K+zDfZkK+JMiC+EJ4+bLfNVM0eRSV1sURvXI5PG8IwvGpxzscxDH7NLcaVk3 4FtZjuECqiqCkAoqjsRXXu2ifCvfGMTxXF/EerONWWyeJ4+I9HQWo/d4748uApy1yLW/dtfjQVjo leckumD47Py/I7LcZ95skW4xmY0BYkjirTavGaK8aO6J1pFIAbEVJPZTkKJ29Mieu/Tlbbcpk2T4 WTcLKspZTgynmosp6IDpvCSH3iBoSJwVFeaqQ8fJEsFnx6wWadcJ1osdst0u5O96e/FiA05KPZLz dIURTLZkuy2uyX4rXjZMeZsuIM45bZ81ntRiaSevbOUTpIqnJNSBQN4jUnCIhVCMlUkXapQV/pRH Kb07mWyZOuclobveoAvO3B85KMt3GU0CJIU+7yEBEUPlyTiml2m69ujJPepLrL0ybL8Ne7xFadmS nJDvaauUltsSccIjLiACKKSqukSpPGsYGwYk7YId6ubjrrst8rk6jCye9JeceN1ERtGuSG6Sonb4 +SIoqnv98Lx5nF7ANoZnzbh/lMmU7JmdvuuuyH3H3CLtgAJs3S0giiImkoIzpHLlSsGZZmSXpbtu nTrUMl9xTefCHMeig66S/OdIGRIy8kUlJUREXSOkcuVKwZlmZJelu26dOtQyX3FN58Icx6KDrpL8 50gZEjLyRSUlRERdJM4rZIuOY7CssNx55qK1xJ99UJ6Qa+ZvOkiJzdcNSMz1siIiXzWmK2SLjmOw rLDceeaitcSffVCekGvmbzpIic3XDUjM9bIiIl81oJOlKUClKUClKUClKUClKUClKUClKUClKUCq b1B/6z/w/wD89XKqL1LnQoh9uVMjsG4jCgLjiCpIne2qbXz1tP50oKpVMwv/AEf6pf7SL/d7dWf0 tavxnC/px/xqrYQYOY31QcbITAsj2JCu0VFt7fmlB8A0pSg/Sa9/fx6Y/wApf/uh+tMwC7XW7esH pS54zP8AB3uTEi+hHyc7DAceDUnkq8ZQ7XmKaRNjpKzO9/fx6Y/yl/8Auh+tfxWwWbFsdhY9j1uZ t1rgtdqPHaT2QT3qqqvmRKqqqkqqpKqqqqqqtBGYBdrrdvWD0pc8Zn+DvcmJF9CPk52GA48GpPJV 4yh2vMU0ibHSVYJ4yjgyAgvMsSyaJGHXmldbA9eyRAhCpCi6VRQhVU8tp764sVsFmxbHYWPY9bmb da4LXajx2k9kE96qqr5kSqqqpKqqSqqqqqqrUnQZNhubZJa+iDea5febLfJ54il/jQY0RYMh4Wow uvcyV1xD9pxoVMGwEVJPZ9oRTtyDMcqwf0l6zO2XIOzjdzvsf0dBdt/HwPY5NFzef5dzxA6JOPDg vkfL2bzZ8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEUy2ZLstrsl+K144xieK4v4j1Zxqy2TxP HxHo6C1H7vHfHlwFOWuRa37tr8aDOcpzzNMOyKTb7xOxK9NW7FrnkspuFFeiyXQjdoW2e2TzvZEj MlR5VcQ+JijYKCkUzbb/AJpG6s2rCbxeMSnNPWiXdpRwoLzEngDjLLbfZJ8+0Km6RI6pGh8DBABQ Uy7enfTCxYTOWZAkvSXRadaYFYUKI2wjqtK8qBEYZEiPsMbI0JURoUFRRS26d9MLFhM5ZkCS9JdF p1pgVhQojbCOq0ryoERhkSI+wxsjQlRGhQVFFLYRkO/vYraur17NZtzZsFyfnR4smc4ehG1RJJMg Z8lbBXDcVBROI810OvKuzpxeepUy+PRMxxvwsBYxONzfCx4nB0SFEa7bc+WrnMSIuXyaB29e3zTj YMbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde7aJ8KY3hGF41OOdjmIY/ZpbjSsm/Atr MdwgVUVQUgFFUdiK6920T4UEZ10J5voxmcmNMmw5MWyS5UeRDlOR3WnWmicAhNskJNEKbTelTaLt FVF4rJkOVSb5Dtcm5YzK9P2SVdbTKt0Z1yPD7RRhESNXf8sAvFgqOCkfaNqvFO4nC53u02q+Wt61 3u2QrnAf492LMYF5pziSEnICRUXRIiptPeiLXjZ8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEU y2ZLstrsl+K0Gf4bnl/yOdiUEJ2PsS8gwRb86wkUzchytxkBxR7yKUclkGiAvElVktOL58e3pBd8 uu/TqyTMgyrH5V6vePsXC3iFqJlwFVkFccdBJHy4ibzPLtoyiKuvZ5jxtsXE8Vi3QLpGxqysT25L 8sJTcFoXRffFBedQ0HaG4IohFvZIiIqrqvaz49YLNOuE60WO2W6Xcne9PfixAaclHsl5ukKIplsy XZbXZL8VoM5w3NsktfRBvNcvvNlvk88RS/xoMaIsGQ8LUYXXuZK64h+040KmDYCKkns+0IpYIdyz SFlTeLXe64/Nl3O0TJsCZFtD0duKcc47enWikuK8JLKFfZNtURtU2vNFCzWfHrBZp1wnWix2y3S7 k73p78WIDTko9kvN0hRFMtmS7La7JfitcVnwjC7NBuEG0Yhj9uiXJrsz2IttZablBok4OiIohjoy TRbTRL8VoKn0pzXKr76qlk0eyh6z42V7jt24HR8J2vCIQkRkvc7nixNEQQ7XFQ29+6VplV+2YRhd rnQJ1sxDH4Uu3NEzBfj21ltyKBKakDZCKKAqrjiqg6RVMvpLVgoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFUPqHh+IZBem5t/xaxXaSEYWkenQGnjEEU1QeRptB8zXWxTzJd+Sm 3fKgMjXU4Pa1xaRff7vNV+Pl83f4Pzd79nm0Gfl0x6befLp7iSe/e7NHT6W/wE1+F9HWl+bxXsfx fbFZcewq8wrFZrfaYx6dNmFFBgCNW3kUlEBFFL2URV1vy1odcBuHzf4vH/drX82tcf4uuH4PD5Cv 52msVu3s6+SBPdr3A+nwT3a1/BrWh1wEPy5pSlB+k17+/j0x/lL/APdD9Xm23iUN96i3eRMZBqyO swI7MyaseC2DUFqWrrhKhdoiOYYuOoip22mvZVQXlRr39/Hpj/KX/wC6H61lcZtRXS9THme+ze4z UefBdESivcBMFcJtU0Rm2Ytmpb5Ay0PuBKDMmeoXUGwempeaWmE2zAxu4XmPCOAEORLKL2lVAcZm zAQERxBLnwJFNtQRxOfCwYPd+qk+dOg5HYWbc0cFw4lyegMMtsSEUUACZZuMgnhLkRL7TPFGtbVT RQtuMYniuL+I9Wcastk8Tx8R6OgtR+7x3x5cBTlrkWt+7a/GvDG8IwvGpxzscxDH7NLcaVk34FtZ juECqiqCkAoqjsRXXu2ifCgrPSC/5RM6dWS75TeLZfbpdMfYukOBAgjDlvJ2QJ3fcfVtwlJ1oeSI yAkSb4oSIPbd88u1sxXIb9O6fZBbWrNaJNyRZ8qCjchWQU+yisPvEJFpfNQ0iIv7+kWzWfHrBZp1 wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitSdBnOD3fqpPnToOR2Fm3NHBcOJcnoDDLbE hFFAAmWbjIJ4S5ES+0zxRrW1U0UPHplmOVZr6Q+Vstu8DbWmPbgun4qcXP8Ay+P8sncth8fkS8id 4ue0HDzs1q6e4DafF+i8HxmB4yMcSV4a1MN99g9c2j4inIC0mxXaLpNpUnAx6wQJ0edBsdsiy40E bcw+zEAHGoorsY4kibFpFRFQE9lFT3UGc4bm2SWvog3muX3my3yeeIpf40GNEWDIeFqMLr3MldcQ /acaFTBsBFST2faEUk8Hu/VSfOnQcjsLNuaOC4cS5PQGGW2JCKKABMs3GQTwlyIl9pnijWtqpooX Oz49YLNOuE60WO2W6Xcne9PfixAaclHsl5ukKIplsyXZbXZL8VqMtXT3AbT4v0Xg+MwPGRjiSvDW phvvsHrm0fEU5AWk2K7RdJtKCpdOMzzTIIOOpdxx+LLynFnL1AWLHeNuCbaRR+V5OIr4mssT4j21 bQFDm5tHa7ekF/yiZ06sl3ym8Wy+3S6Y+xdIcCBBGHLeTsgTu+4+rbhKTrQ8kRkBIk3xQkQbNbMI wu1zoE62Yhj8KXbmiZgvx7ay25FAlNSBshFFAVVxxVQdIqmX0lrts+PWCzTrhOtFjtlul3J3vT34 sQGnJR7JebpCiKZbMl2W12S/FaDP+qGQ3y49Js2V3E8txV2Hj8ybGuDlwitELzLam2gHElG4hckR fcgqgkhKqLxVceoF/wAcgy7pdyx++RHsWuOSwBtCm22AREYLs+IIjSQLiSR4vC20mm1LtrzRA0a9 2m1Xy1vWu92yFc4D/HuxZjAvNOcSQk5ASKi6JEVNp70RajwteN4ql0vdusNvgPznUeuD0KI227LN SXRuEiIplsyXZKq+0XxWgocPNupVjseSXvMcQ3AtNklXNt3sx4PJ1geSMabnTFLuDyXnoEDt+4+a cZO23/NI3Vm1YTeLxiU5p60S7tKOFBeYk8AcZZbb7JPn2hU3SJHVI0PgYIAKCmTGx6bY1OOdjmEW yzS3GlZN+Bao8dwgVUVQUg0qjsRXXu2ifCoXp3ZsNwmcsyAtzkui060wK2+BEbYR1WleVAiNMiRH 2GNkaEqI0KCoopbCz4BLyWWub2+43G2O3i33dIrMxqI+MbZW+I6BLHckGoiiu6UAcBC0peyRESwv TjPMuusHHZeQWy2SncixZy/RYdoEgcaVlIqK1zecQXCd8UJDvto0oqCk6nylSGLWXpi1Peh2TAbF bnLhGciSVZs8ZpH2CTZtOcU9oC4psV2i6TaVY7ZhGF2udAnWzEMfhS7c0TMF+PbWW3IoEpqQNkIo oCquOKqDpFUy+ktBDXfPLtbMVyG/Tun2QW1qzWiTckWfKgo3IVkFPsorD7xCRaXzUNIiL+/pF4rb f80jdWbVhN4vGJTmnrRLu0o4UF5iTwBxlltvsk+faFTdIkdUjQ+BggAoKZaNVG6d9MLFhM5ZkCS9 JdFp1pgVhQojbCOq0ryoERhkSI+wxsjQlRGhQVFFLYMHS4rdeo8GJcnldYyBRgFPddltxlctsJ7S CTiF2kddMu2JCiISoPFNar+CZbn2TXC2W9LjjLUlqySHsgAbO+vgLikh2O0yKrK04COsyBJR5cvB mqEKPtqN5xvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwrxxnEjsdvvjQZLeps+9 SVlSLnJGN4ht3w7TAkAgyLScQZb0itqm0XfLeqCpdOMsyXKoOOxcsZtjTWXYs5dmhtBvsOQ0BIom ne58lJzxaGKgjasqCihOrpyvHoZk2VSLHg1tyZ6FM9N4iNzjvNk6chvsDEAlfdNflje8ULiqgh21 Eh27vuVZunvTLD8JxAsZttohSIz8ZIs56RBjC7cGkQkEZCtNgL2hMh2QqqoqqW1UlWTtmEYXa50C dbMQx+FLtzRMwX49tZbcigSmpA2QiigKq44qoOkVTL6S0FgpSlApSlApSlApSlApSlApSlApSlAp SlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlAp SlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UBka6nB7WuLSL7/d5qvx8vm7/B+bvfs82g jPm/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgNg+b/F4/wC7Wv5ta4/x dcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgIflzSlKD9Jr39/Hpj/KX/wC6H63KsNvf38em P8pf/uh+tyoKnc87tlqeymVcmnmrLjLTHjp7TTj5C8Yd1xtWWwU+LbJxnFcRFHTy+ads9IXUrApb xNMZVbNg048ZG7wBsABXOZEWhETaE3m1VUR1oDdb5NiRJC5Bhd5u0TqVjseSzAiZa0061c3We+LS uxAhvsoyjgkpA3GA0NSRFWQicV7ZcvGZ0xutyuU2Xccu7PjLklzJy1wiiyGXysx2x1WnCePh84Hg XSqCioqp7QhCzWrM7dfPFw7IzNG7NxjfjQ7xb5dr8Rx0mxV9lCIEIgQzAT4cw2myFFhcQ6sYzfLf bjmeNtc2RZI16mA7BkrEhMPR1fQnJitIwgIguJzUhRSbIfnIopDYr0ln43l7WU2efhlqmjbZdvcj 2rERhxXBdVo23FEJHcUxcaFS5OEJB7Ii0Sk4TGOjfq/icjC7fe4UfF7pZBt97isWrtyJMrwqxnZr LvdUWTcFGVISbcHbW/nGZKF5xvMbHf5xwYS3OPLFpXhYuVplQHHQRUQjbGQ2CuCKkCEobQVMOWuQ 7mp8uLAgyJ06SzFiRmieffecQG2gFNkZEvkIoiKqqvkiJWf4P0yi2KdOOdZunJRJsFyG+1Z8PS3u PAajyBw1kOobSoiorajpV0u/LSycnpbgPoO9Wu14pZbF6Ztr9slSrTb2I0jsPDxNEMQ/7F0qKmxR VRdUHbas6x+5eLFgb0y9FjHKWNLsc2LIeaDXMmWnWhN/iqiio2JKimCL5mKKtueYzcuPo6VNmc7I 1fh8PbZLnKE7y7RpxbXZnwPi1+6FxLQrpar+D9O5WLTp06DG6cwJb0FyOw/Z8NWC4BqoqKuEkolc aRRRVbTipKie0Oq7emuBysJnSzYvbMqJc2kl3ZpYSg5Ku5L/AJRPQ+4qNi6nFFYQeAqAqCj7SEHb hXULHcrxVclipc7ZbggtznnrvbnoTbTJgp8u66KNuCIoqkTZGKJpeWlRV9rVnWP3LxYsDemXosY5 SxpdjmxZDzQa5ky060Jv8VUUVGxJUUwRfMxRYW1dPZ4YPLwS7ZN4nGvQh2KExEgixICMTSNIbzpk 4jjwtiiIQC0GyNVbLYIHjg/TuVi06dOgxunMCW9BcjsP2fDVguAaqKirhJKJXGkUUVW04qSontDq gmsb6j4fkcE5tjub09hIKz2iZgSFWSyiIpqwnDb5ApCBg1yJsyEDQTVBrPOrmeW3Mv2MmVX6wM32 Ei2ZqW2U22SIZD3OJgoOGKA4qa+c0Rinku9KKracJ6f3/HZ2Fm/k9smRMZx92xk0FnNpyUBqzpxD WQSASJFjpriSKqOr5cxRuOvnTuYHSqbhF5yonMZZtjVphNQraLcgI4k2Ik84bhI68gAIoQI0GzcV Wy2CAGO5xK6NMsycdwHHcgyLP3LvKskOxLkNyEm5DBqJvvL4nQx0ROaFyTkm02HF1W9hu1th2dmD are0TUSIybLIE4Rkgi+6ibIlUiX4kSqqr5qqrXZEfxuJl87L41qhNX+fGbiyp421EddaBdiKr3v+ xFX3qgNou0AEHlvsxqbIbcaU10JclIEDZE4ZrpNr5e18aCM6eXm4TuppW+Hboq2+3PlGmSXZZA8j qxUeTttI2qGPF1tNqYrvl5eynLaax/CLFbU6iw722MpqYvNXEamOtsul2SDk4yJI24XHSciFV0Ip v2R1sFBX4+TNu3nI4ow3jg2BplJElkTdcOQTavOMCyIqZEDJRjRRQuav8R9oCSuPG+pGEZDBOfa7 +yUEYK3BJb7Tkdg44oiuOA46IiYt8hF3iq9olQXOBeVLNBudiyXNZo216fEuLrF2iky42LjzyRQj HFETJE5IkRo0MyEVWRx8u2RLRem/TW+3Lppa7X1CkeDeYxF/GAhQ4wMuxWHgZbeU3UffB49RmlAx QERFJSDZcQDRsbzGx3+ccGEtzjyxaV4WLlaZUBx0EVEI2xkNgrgipAhKG0FTDlrkO/HGczt19t98 uMdmaMa0SVYcbK3ywl+zHaeVCjOMg6hqjvsgAnyFQVFVSUR8bDjl/TKmMjym+2y4y4cF+FDC22s4 TYg+bJuq4jj7ymW47XHSgiJz2hbTjxYji+aWa45LOmZTj8x29urLFGrA8yLEpI7EcCXcs+bSBHFV b9klVV0Yp5UHbjfUfD8jgnNsdzensJBWe0TMCQqyWURFNWE4bfIFIQMGuRNmQgaCaoNe3TvN7RnV jYu9ni3qOy9GZkolxtb8X2XR5DxNwUB3y96tEY+5dqiiq1/Cen9/x2dhZv5PbJkTGcfdsZNBZzac lAas6cQ1kEgEiRY6a4kiqjq+XMUbmun2L3nF4MOzyMiZm2W1QQgWuK1b+y4jIIIgUhxTPuuoACnJ tGRVScVQXYcAk8JvvrJjES7HF8HJPmzMidzueFlNGTUhjnpEPtug4HNE4lx2m0VFqZqs9MLXPtOG R2rox4WfMky7nKi8xPwrsuS7JNjmKqh9snlb5p5Fw5Iib0lmoK/HyZt285HFGG8cGwNMpIksibrh yCbV5xgWRFTIgZKMaKKFzV/iPtASVx431IwjIYJz7Xf2SgjBW4JLfacjsHHFEVxwHHRETFvkIu8V XtEqC5wLypZoNzsWS5rNG2vT4lxdYu0UmXGxceeSKEY4oiZInJEiNGhmQiqyOPl2yJaL036a325d NLXa+oUjwbzGIv4wEKHGBl2Kw8DLbym6j74PHqM0oGKAiIpKQbLiAaNjeY2O/wA44MJbnHli0rws XK0yoDjoIqIRtjIbBXBFSBCUNoKmHLXId+OM5nbr7b75cY7M0Y1okqw42VvlhL9mO08qFGcZB1DV HfZABPkKgqKqkoj42HHL+mVMZHlN9tlxlw4L8KGFttZwmxB82TdVxHH3lMtx2uOlBETntC2nHixH F80s1xyWdMynH5jt7dWWKNWB5kWJSR2I4Eu5Z82kCOKq37JKqroxTyoO3G+o+H5HBObY7m9PYSCs 9omYEhVksoiKasJw2+QKQgYNcibMhA0E1Qa9uneb2jOrGxd7PFvUdl6MzJRLja34vsujyHibgoDv l71aIx9y7VFFVr+E9P7/AI7Ows38ntkyJjOPu2Mmgs5tOSgNWdOIayCQCRIsdNcSRVR1fLmKNzXT 7F7zi8GHZ5GRMzbLaoIQLXFat/ZcRkEEQKQ4pn3XUABTk2jIqpOKoLsOASeE331kxiJdji+DknzZ mRO53PCymjJqQxz0iH23QcDmicS47TaKi0wm++smMRLscXwck+bMyJ3O54WU0ZNSGOekQ+26Dgc0 TiXHabRUWuLpha59pwyO1dGPCz5kmXc5UXmJ+FdlyXZJscxVUPtk8rfNPIuHJETekdMLXPtOGR2r ox4WfMky7nKi8xPwrsuS7JNjmKqh9snlb5p5Fw5Iib0gWalKUClKUClKUClKUClKUClKUClKUClK UClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCoDI11OD2tcWkX3 +7zVfj5fN3+D83e/Z5tT9QGRrqcHta4tIvv93mq/Hy+bv8H5u9+zzaCM+b/F4/7ta/m1rj/F1w/B 4fIV/O01it29nXyQJ7te4H0+Ce7Wv4Na0OuA2D5v8Xj/ALta/m1rj/F1w/B4fIV/O01it29nXyQJ 7te4H0+Ce7Wv4Na0OuAh+XNKUoP0mvf38emP8pf/ALofrcqw29/fx6Y/yl/+6H63KgjIN7izciud ljtvG7bWmCkPoiKyhu81Rnki/uogIGQKiKgvNF5oaVxY3m+F5LOODjmX4/eZbbSvGxAuTMhwQRUR TUQJVQdkKb921T41XwtN1Sf1NtbNshSnrz27hAK5MEduf7sBuIjD2k2WnIZK4Aoum3W12qkqJARu mV9ucG/w7qTNmauePzbOBLkM3IHNyUBO6hzAbJgQ4ebba6eUhU1RWgoL/Z83wu8wbhOtGX4/cYlt a709+LcmXW4oaJebpCSoA6Al2Wk0K/BaYVm2I5rBWZieR2y8tC0266MWQJuMo4iqCOh85sl0vsmi LsVRU2i1WeneIXS1ZUt4u9hZjOhBdjMylze5XpwUcNoibRuW0IgJdoVUhXewFNKirrxtWFZU90sl 9NLpIssK0tY2dgiz4xuyZEnbCMBJNshbFnQopK0hO8lNERwUDbgWyz5vhd5eiM2fL8fuLsx11mKE W5Muk+bQCbgAgkvIgAhIkTaohIq6RUqany4sCDInTpLMWJGaJ5995xAbaAU2RkS+QiiIqqq+SIlZ Zb1yEv2QdluORY3CgPOY3Ohd+1RpU1pNyIzrQvTiYbBNo1I4tKKcFFV5Kr4ims0FGPqvhcnArrme O3RnJ4NpgjPmR7TIZOSyyoqezbcMO2SAJkoGol7BIiKScasEbLMVk+l/DZLZXvQnL0t25zReA48u Xf0XyWuB75a1wL4LWfvYdn33GLh04Zaxnss42tggSTnP8pm2hYSS7pnUfi2hH2hR7kRIPcBAUjsG K43f2cqtlyu8PH7dEsVokWmA1aDPtyQeOMXc7JAKRRFIgoLQm8mnFTn7CKYWD1sxX8pbL/0b6W/z 5r/Mf9a+d+4//c+b/DXFjHUHB8msci92LLbLOgRIwypjrcwP8kaIVJCfRVRWfZElVHEFU4lvWl1U sDwzNLBkWHpMLH3rLjePyMfEmpDySXQXwqhKVFb48j8KKKxvTe1VHXd8RsHS+zZVjljtmM3QbKlp sltat0WRGfddkTu0IADxiQAMf2QVVbRXtq4mjRA+UCTwrNsRzWCszE8jtl5aFpt10YsgTcZRxFUE dD5zZLpfZNEXYqiptFr+LdmWDZBbLjJt2VY5doFvaR64OsXBl9qMGiJDdVCVAHQEuy0nsqv7y1Vr VhWVPdLJfTS6SLLCtLWNnYIs+MbsmRJ2wjASTbIWxZ0KKStITvJTREcFA25Jw7bmk3Km8pu9qx+F LtlomQoEOLd3pDco5Bx3NuulGbVkRWKKeyDiqjirpOCIYTNll4Xe3nmbLJx+5OsNMvPBEcZeJsHg 5tGSDvQmHtCq+RJ5ptKk/RNq/FkL+gH/AArM+mGC5Vi0jAIz1rxmNAx/G5VpnlCnuqTj7zjBq822 scULkUUTLkQryfP38EVzWaDmYt1vYdR1iDFacH3EDQoqf70SumlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBUBka6nB7WuLSL7/AHear8fL5u/wfm737PNqfqAyNdTg9rXFpF9/ u81X4+Xzd/g/N3v2ebQRnzf4vH/drX82tcf4uuH4PD5Cv52msVu3s6+SBPdr3A+nwT3a1/BrWh1w GwfN/i8f92tfza1x/i64fg8PkK/naaxW7ezr5IE92vcD6fBPdrX8GtaHXAQ/LmlKUH6TXv7+PTH+ Uv8A90P1uVYbe/v49Mf5S/8A3Q/W5UClKUClKUClKUFfm5jYIE68s3Oezb4lmajFOuMt4GojRvqS CyrpFoXURGyUC0qC+yvnzSpOLdrVKkBHjXOE+853+Dbb4kRdhxGntIi7XtuEgF9ElRF0q6rOcnxu /wBytnVrF7ZDZWXkzQPwZUszaiIEiA3CIVcECVXW1iuOKAiqcXGfaTmvGGk9JLzMuFyNm34lYWps 5uQDkZvxaMM+gHbakdWTYAHWmXnOQASoJgZ7EF9kg0yz5ljV/g3CRid6tmTuwWubse0XBh9zaoSg G+aCJHxVB5kKbRdqiIqpx4n1HwvJRtLMHIrY3dLrBZmsWh6ayk8QdYR8UJlDUkLtkhLraa89qnnV MxjCM4s2excqCHbFaatE63lAl5hc7iSG4TDrbgvyWy4iRsIBALYqKe3ydXTY8WLdKMlsuCzcEWRb H7de8WatVwur9wfkS4MhIjjBhHA2/lIiGqONtK41wJ19UREIRQNTxjLMVyjxHqzktlvfhuPiPR05 qR2uW+PLgS8d8S1v36X4VM1meE4PcI98kzL7Y/Cdy2vwQmNZ7dbpIbB0m1MG0kNh2eXbFe42SGig Oviknd+mdpk4rkNlg3XIGnb1aJNsV6ffJ1xbZR4FHmjT75CpJ5LtNLrabRFWgmbPm+F3l6IzZ8vx +4uzHXWYoRbky6T5tAJuACCS8iACEiRNqiEirpFSloyy3TRyQ5bL1oaxyc5EnuzzaBtEFht/vIYm Qo0rTwFslFUTfJBVFSqBgMq+5X1hjZfPxlm0tQ8fl2180gTWnFVyRFcZRXpceOTor239ADao0okp GqvCKWbp1bc0gZLk03I7Vj8WJepw3ACgXd6S40YxYsZG1E4zSKKpHI+fLaKSDxX51BJt9QsBc7Hb zjGT8RGclscbqwvdYb59x0fa8wHtO8iTyTtntfZXXbEyeyXKPOKwXGFf5MOM3JOJbpjLjpC633Gf eaCPdHzBTIRJF3vXnWf9I4YRfSN6kM3pLPjEZ2zY8zJssmNIGB7Eg1BkwR532fCxU2JkSwFMVUnj GozoFj2SsYViN2exu2WN2xYs/bIdtJx9hyVIeKObpyRcjAUYu7F2qiL3NXiNFVERXA0zB8xsGY2m NOss9lx12DFmvQleBZMQJLSOtI82JL2yIF2m/JdLpVTzqwVk3TDBcqxaRgEZ614zGgY/jcq0zyhT 3VJx95xg1ebbWOKFyKKJlyIV5Pn7+CK5rNBRpHUiOziWUZSWLZAVrx12UDjiLE5TEjPOtSDZHv74 tqyar3O2pJrihKuqsEbLMVk+l/DZLZXvQnL0t25zReA48uXf0XyWuB75a1wL4LWcwrdd7/0fz7Br Zb3o16lTr7GH0tGkw43CZPlqDoPKyQuj2nOadvknzUVR5bSzYrjd/Zyq2XK7w8ft0SxWiRaYDVoM +3JB44xdzskApFEUiCgtCbyacVOfsIphYPWzFfylsv8A0b6W/wA+a/zH/WvnfuP/ANz5v8NcWMdQ cHyaxyL3Ystss6BEjDKmOtzA/wAkaIVJCfRVRWfZElVHEFU4lvWl1UsDwzNLBkWHpMLH3rLjePyM fEmpDySXQXwqhKVFb48j8KKKxvTe1VHXd8RsHS+zZVjljtmM3QbKlpsltat0WRGfddkTu0IADxiQ AMf2QVVbRXtq4mjRA+UCTwrNsRzWCszE8jtl5aFpt10YsgTcZRxFUEdD5zZLpfZNEXYqiptFpZ83 wu8wbhOtGX4/cYlta709+LcmXW4oaJebpCSoA6Al2Wk0K/BaqdqwrKnulkvppdJFlhWlrGzsEWfG N2TIk7YRgJJtkLYs6FFJWkJ3kpoiOCgbck4dtzSblTeU3e1Y/Cl2y0TIUCHFu70huUcg47m3XSjN qyIrFFPZBxVRxV0nBEMLNZchsF7eeZst8tlydYaZeeCJLB4mweDm0ZIKroTD2hVfIk802lSdZN0w wXKsWkYBGeteMxoGP43KtM8oU91ScfecYNXm21jihciiiZciFeT5+/giuazQcVqu1qu3i/RdzhT/ AAck4krwz4udh8Nc2j4qvEx2mxXSptNpUBYeoWNX/KmLFYJrN4afgvy27lAlsSIm2TZB1lSBxSR0 fEMlpRROJppVXaJFt4Zdblg+fYzdI2M2X1jk3EIsiyRCTkxIa4BIkiXHuSvNVNUXRaHS1AZTgeaZ jkUm4XiDiVlauOLXPGpTkKU9KktBJ7RNvdwmWu8ImBIjKo2gcjJHDU1EQ0bGMsxXKPEerOS2W9+G 4+I9HTmpHa5b48uBLx3xLW/fpfhXhjeb4Xks44OOZfj95lttK8bEC5MyHBBFRFNRAlVB2Qpv3bVP jVGs+C39n0xJk4xZSnu2SXAhHdMzul9jmT3Bey6zJaFBZMmw5qK8lQETS78vGN0yvtzg3+HdSZsz Vzx+bZwJchm5A5uSgJ3UOYDZMCHDzbbXTykKmqK0FBf7bm+F3OC9OtuX4/NiMtPPOvx7ky422DKA rxkQkqIII62pKvkKODvXJN+9oyzFbxdFtdoyWy3CeMYJaxYs5p11GDECB3gJKvAhcbVC1pUMVRfN KhbVCyp6+S8jumJ4ZCuzVtOJFdjTnZMiTskMGjlFGbJllCRVUUB3kpoSIKhpzx6I2C/4lgVrxO9W fH7e1aYLEZl20zjeGUaCvddMCYa7ZEftrpTVVMlVdpsgmbFmWNXu03O9W69WyRZ7a6QPXFq4MOxt C0DhmrjZkgCKHpefFU4quuKiRe8TLMVmR50iJktlkM2+M3LmuNTmiGMw433W3XFQtABNopoS6RR8 0XXnVYwmNmFju+XXnKbRZY8C5yfSn/0m4yZ8hsm4kaP2ka8KCubGOR7HZbJBQF99Vn9jnjl7bxjC rpdLDCxxmyY27a2oTaPDIfdfOMT7r7TrDKsGjkVVVE7iOK8RIekQjDRsKzbEc1grMxPI7ZeWhabd dGLIE3GUcRVBHQ+c2S6X2TRF2KoqbRaWfN8LvMG4TrRl+P3GJbWu9Pfi3Jl1uKGiXm6QkqAOgJdl pNCvwWqnasKyp7pZL6aXSRZYVpaxs7BFnxjdkyJO2EYCSbZC2LOhRSVpCd5KaIjgoG3JOHbc0m5U 3lN3tWPwpdstEyFAhxbu9IblHIOO5t10ozasiKxRT2QcVUcVdJwRDCwWjLMVvF0W12jJbLcJ4xgl rFizmnXUYMQIHeAkq8CFxtULWlQxVF80qZqjdEbBf8SwK14nerPj9vatMFiMy7aZxvDKNBXuumBM NdsiP210pqqmSqu02V5oK/h2TjkxXM49lucKJBnPwm5UpWO3LNh91h1WkBwjQRNok+UEFVFRURfP Vf6b9VbVnVwgw7djuTQPGWQb2L1whC222wchxloTITLRudo3ATzQm05IvvRPfo5IILVerRIg3OJL h5BdnnElW99hswfuUp1o2nDBAdEgIS22pIiEm9bSpPKcMtV2we+Yzbo0Kz+lLIdlGRHiD8gx2nAa FBHjsG+6aiG0RORa1taD2s+ZY1f4NwkYnerZk7sFrm7HtFwYfc2qEoBvmgiR8VQeZCm0XaoiKqce J9R8LyUbSzByK2N3S6wWZrFoemspPEHWEfFCZQ1JC7ZIS62mvPap51xQ7bmk3Km8pu9qx+FLtlom QoEOLd3pDco5Bx3NuulGbVkRWKKeyDiqjirpOCIcL0bwXJeno261KFsuVuctEFm4TX7o+5LjSGGC A2Y6G0vOJzRDbbU2+2Tz6omiEECT6b9VbVnVwgw7djuTQPGWQb2L1whC222wchxloTITLRudo3AT zQm05IvvRNArittptVt4+jrZCh8IzUQfDsC3xYa5dppOKJoA5nxH3DyLSJta7aCMg3uLNyK52WO2 8bttaYKQ+iIrKG7zVGeSL+6iAgZAqIqC80XmhpXFjeb4Xks44OOZfj95lttK8bEC5MyHBBFRFNRA lVB2Qpv3bVPjVfC03VJ/U21s2yFKevPbuEArkwR25/uwG4iMPaTZachkrgCi6bdbXaqSokBG6ZX2 5wb/AA7qTNmauePzbOBLkM3IHNyUBO6hzAbJgQ4ebba6eUhU1RWgoL/Z83wu8wbhOtGX4/cYlta7 09+LcmXW4oaJebpCSoA6Al2Wk0K/BaYVm2I5rBWZieR2y8tC0266MWQJuMo4iqCOh85sl0vsmiLs VRU2i1WeneIXS1ZUt4u9hZjOhBdjMylze5XpwUcNoibRuW0IgJdoVUhXewFNKirrxtWFZU90sl9N LpIssK0tY2dgiz4xuyZEnbCMBJNshbFnQopK0hO8lNERwUDbgWyz5vhd5eiM2fL8fuLsx11mKEW5 Muk+bQCbgAgkvIgAhIkTaohIq6RUqwVk1vXIS/ZB2W45FjcKA85jc6F37VGlTWk3IjOtC9OJhsE2 jUji0opwUVXkqviKaBndi9aMHv2M+K8J6XtsiD4jt8+13WiDnx2nLXLetpvXvSg8LPmWNX+DcJGJ 3q2ZO7Ba5ux7RcGH3NqhKAb5oIkfFUHmQptF2qIiqnHifUfC8lG0swcitjd0usFmaxaHprKTxB1h HxQmUNSQu2SEutprz2qedcUO25pNypvKbvasfhS7ZaJkKBDi3d6Q3KOQcdzbrpRm1ZEViinsg4qo 4q6TgiHX+lPTvIcKt8bHn/BXC0zLJDiXOet6lJPivtRybNqKXb5eF5aNsUcaVonXyFERRFA1mq/j eb4Xks44OOZfj95lttK8bEC5MyHBBFRFNRAlVB2Qpv3bVPjUZJwWJb7HehsRTbhPmW1+KzGyK+T7 jAcIx9kXmnnTTgpIiEojy4qSJ71RanG6ZX25wb/DupM2Zq54/Ns4EuQzcgc3JQE7qHMBsmBDh5tt rp5SFTVFaCg0bGMsxXKPEerOS2W9+G4+I9HTmpHa5b48uBLx3xLW/fpfhTGchZvky+RAgTYT1luS 2+QMnt/KF2WnhcBQMkUCbebJN6LzVFEVTVVLp3iF0tWVLeLvYWYzoQXYzMpc3uV6cFHDaIm0bltC ICXaFVIV3sBTSoq64ouIZpebZ1Es2RxMftMTMWnlCTAub01yKZwI8NBVs47KGOmSc5c0XaoOvwqC 9YxlmK5R4j1ZyWy3vw3HxHo6c1I7XLfHlwJeO+Ja379L8K8Lbm+F3OC9OtuX4/NiMtPPOvx7ky42 2DKArxkQkqIII62pKvkKODvXJN0CN0zulzg3+Dd7Wza3bnj82zs3JczuV9cjpJQEJEZltgKCvASV RJFVWxT3Kqpc8bt9/k5UeQZHjOJWuWEFYYSYEk5st4FNDQFfNhlW2hVCXt6NCI0XYcPbDswrNsRz WCszE8jtl5aFpt10YsgTcZRxFUEdD5zZLpfZNEXYqiptFqany4sCDInTpLMWJGaJ5995xAbaAU2R kS+QiiIqqq+SIlVLpfZsqxyx2zGboNlS02S2tW6LIjPuuyJ3aEAB4xIAGP7IKqtor21cTRogfKW2 eUoIMg4LLL8sWiVhp51WmzPXsiRoJKIqukUkElRPPS+6g4rLkNgvbzzNlvlsuTrDTLzwRJYPE2Dw c2jJBVdCYe0Kr5Enmm0rxxPJ7JlUeZLsFxhXKFGk+GSVDmMyGnS7YGvEmjLWufFUPiW0VdcVEiz/ AKYYLlWLSMAjPWvGY0DH8blWmeUKe6pOPvOMGrzbaxxQuRRRMuRCvJ8/fwRXLB06tuaQMlyabkdq x+LEvU4bgBQLu9JcaMYsWMjaicZpFFUjkfPltFJB4r86gsGM5CzfJl8iBAmwnrLclt8gZPb+ULst PC4CgZIoE282Sb0XmqKIqmq9sVvcXI8dhXqG28y1Ka5Ew+iC9HNPI2XRRV4OtmhAYb2JCQr5pVZ6 dW3NIGS5NNyO1Y/FiXqcNwAoF3ekuNGMWLGRtROM0iiqRyPny2ikg8V+dXb0jiSouDMvTIz0R24z p11GM+2oPMBMmPSgadFfmuiDwiY+aISEiKqJtQtlKUoFKUoFKUoFKUoFKUoFKUoFKUoFQGRrqcHt a4tIvv8Ad5qvx8vm7/B+bvfs82p+oDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tBGfN/i8f92tfza1 x/i64fg8PkK/naaxW7ezr5IE92vcD6fBPdrX8GtaHXAbB83+Lx/3a1/NrXH+Lrh+Dw+Qr+dprFbt 7OvkgT3a9wPp8E92tfwa1odcBD8uaUpQfpNe/v49Mf5S/wD3Q/W5Vht7+/j0x/lL/wDdD9blQKUp QKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQK4r VdrVdvF+i7nCn+DknEleGfFzsPhrm0fFV4mO02K6VNptK7ao1tx6/s4rm0F6x4M3Lus6e9bmI8Q0 iTAdBEaO4CqbcdNfJ1R2hD7t0EnauoWA3bxfovOMZn+DjHLleGurDnYYDXN0+JLxAdpsl0ibTa0x jqDg+TWORe7FltlnQIkYZUx1uYH+SNEKkhPoqorPsiSqjiCqcS3rS6r/AE7w++2rKlvV1jswWm4L sUGVyWbfXHVcNouSOzGxKOI9rSg3tHVMVPzZCpPpfZsqxyx2zGboNlS02S2tW6LIjPuuyJ3aEAB4 xIAGP7IKqtor21cTRogfKBJ2zN8Luk6BBtmX4/Nl3FonoLEe5MuOSgFTQjbESVTFFbcRVHaIoF9F a98ZyFm+TL5ECBNhPWW5Lb5Aye38oXZaeFwFAyRQJt5sk3ovNUURVNVReilqI50mcTdzC14+0dix tufa34LgQiVt8lQHhFwhQfCxuRoSqsBXELbxpSLiGaXm2dRLNkcTH7TEzFp5QkwLm9NcimcCPDQV bOOyhjpknOXNF2qDr8KgvWMZZiuUeI9Wclst78Nx8R6OnNSO1y3x5cCXjviWt+/S/CpOfLiwIMid OksxYkZonn33nEBtoBTZGRL5CKIiqqr5IiVn/TvELpasqW8XewsxnQguxmZS5vcr04KOG0RNo3La EQEu0KqQrvYCmlRV1o1BX8KzbEc1grMxPI7ZeWhabddGLIE3GUcRVBHQ+c2S6X2TRF2KoqbRa98Y yzFco8R6s5LZb34bj4j0dOakdrlvjy4EvHfEtb9+l+FUy1YVlT3SyX00ukiywrS1jZ2CLPjG7JkS dsIwEk2yFsWdCikrSE7yU0RHBQNuMgw7Ks49JeszVlx/vY3c7FH9HTnbhy8d2OTpc2WOPb8OOhTl z5r5hx9oLZZ83wu8vRGbPl+P3F2Y66zFCLcmXSfNoBNwAQSXkQAQkSJtUQkVdIqUs+b4XeXojNny /H7i7MddZihFuTLpPm0Am4AIJLyIAISJE2qISKukVKyYLbfeqeVXWTPsbOOtSsNuePvy0tk0XG1k nHVklclsRifH2X1RoA02okpHt4USawGVfcr6wxsvn4yzaWoePy7a+aQJrTiq5IiuMor0uPHJ0V7b +gBtUaUSUjVXhFA0bGchZvky+RAgTYT1luS2+QMnt/KF2WnhcBQMkUCbebJN6LzVFEVTVMYyzFco 8R6s5LZb34bj4j0dOakdrlvjy4EvHfEtb9+l+FUWLiGaXm2dRLNkcTH7TEzFp5QkwLm9NcimcCPD QVbOOyhjpknOXNF2qDr8Ku3p3iF0tWVLeLvYWYzoQXYzMpc3uV6cFHDaIm0bltCICXaFVIV3sBTS oq6DRqUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKgMjXU4Pa1xaRff7vNV +Pl83f4Pzd79nm1P1AZGupwe1ri0i+/3ear8fL5u/wAH5u9+zzaCM+b/ABeP+7Wv5ta4/wAXXD8H h8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64DYPm/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7 XuB9Pgnu1r+DWtDrgIflzSlKD9Jr39/Hpj/KX/7ofrcqw29/fx6Y/wApf/uh+tyoFKUoFKUoFKUo FKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFcVqu1qu3i/R dzhT/ByTiSvDPi52Hw1zaPiq8THabFdKm02ldtUa249f2cVzaC9Y8Gbl3WdPetzEeIaRJgOgiNHc BVNuOmvk6o7Qh926CZxvN8LyWccHHMvx+8y22leNiBcmZDggioimogSqg7IU37tqnxr3xjLMVyjx HqzktlvfhuPiPR05qR2uW+PLgS8d8S1v36X4VnMbplfbnBv8O6kzZmrnj82zgS5DNyBzclATuocw GyYEOHm22unlIVNUVoKmeneIXS1ZUt4u9hZjOhBdjMylze5XpwUcNoibRuW0IgJdoVUhXewFNKir oLbjOQs3yZfIgQJsJ6y3JbfIGT2/lC7LTwuAoGSKBNvNkm9F5qiiKpqmMZZiuUeI9Wclst78Nx8R 6OnNSO1y3x5cCXjviWt+/S/CqLFxDNLzbOolmyOJj9piZi08oSYFzemuRTOBHhoKtnHZQx0yTnLm i7VB1+FXHG6Z3S5wb/Bu9rZtbtzx+bZ2bkuZ3K+uR0koCEiMy2wFBXgJKokiqrYp7lVUC/23N8Lu cF6dbcvx+bEZaeedfj3JlxtsGUBXjIhJUQQR1tSVfIUcHeuSbYVm2I5rBWZieR2y8tC0266MWQJu Mo4iqCOh85sl0vsmiLsVRU2i1x43b7/Jyo8gyPGcStcsIKwwkwJJzZbwKaGgK+bDKttCqEvb0aER ouw4e3X7VhWVPdLJfTS6SLLCtLWNnYIs+MbsmRJ2wjASTbIWxZ0KKStITvJTREcFA24FzxjLMVyj xHqzktlvfhuPiPR05qR2uW+PLgS8d8S1v36X4VGWHqFjV/ypixWCazeGn4L8tu5QJbEiJtk2QdZU gcUkdHxDJaUUTiaaVV2iUyN0zulzg3+Dd7Wza3bnj82zs3JczuV9cjpJQEJEZltgKCvASVRJFVWx T3KqpM22wZpJ6s2rNrxZ8SgtM2iXaZQQpzz8ngbjLzbneJgO6KG0Qo0oggczNDNTUBDRqhlya1Dd L1Dee7DNkjNSJ850hGKzzEzVsnFXQmDYC4aFriDzRe40qZqmY9GutryvPgZt/eenyY92gOOkTUV7 lCajIyTqCSiaOQiU+IlxB1ovNSUUCwWXIbBe3nmbLfLZcnWGmXngiSweJsHg5tGSCq6Ew9oVXyJP NNpXFZ83wu8wbhOtGX4/cYlta709+LcmXW4oaJebpCSoA6Al2Wk0K/Bayy19KMqTEMexB6LjNrgR cIueNT5MKY64Qvy0aRZLbKsAjmyji4SEYKpPn5rwQnNAslryq4ZxDybJoFltfo62yoMePbrk7N7/ AIh2MZGRGwz2+HhRRERD5dxfMePtBJ4Vm2I5rBWZieR2y8tC0266MWQJuMo4iqCOh85sl0vsmiLs VRU2i1YKpnS+zZVjljtmM3QbKlpsltat0WRGfddkTu0IADxiQAMf2QVVbRXtq4mjRA+Ums7sXrRg 9+xnxXhPS9tkQfEdvn2u60Qc+O05a5b1tN696UHhZ8yxq/wbhIxO9WzJ3YLXN2PaLgw+5tUJQDfN BEj4qg8yFNou1REVU48T6j4Xko2lmDkVsbul1gszWLQ9NZSeIOsI+KEyhqSF2yQl1tNee1Tzrih2 3NJuVN5Td7Vj8KXbLRMhQIcW7vSG5RyDjubddKM2rIisUU9kHFVHFXScEQ6/0p6d5DhVvjY8/wCC uFpmWSHEuc9b1KSfFfajk2bUUu3y8Ly0bYo40rROvkKIiiKBrNV/G83wvJZxwccy/H7zLbaV42IF yZkOCCKiKaiBKqDshTfu2qfGoyTgsS32O9DYim3CfMtr8VmNkV8n3GA4Rj7IvNPOmnBSREJRHlxU kT3qi1ON0yvtzg3+HdSZszVzx+bZwJchm5A5uSgJ3UOYDZMCHDzbbXTykKmqK0FBo2MZZiuUeI9W clst78Nx8R6OnNSO1y3x5cCXjviWt+/S/CmM5CzfJl8iBAmwnrLclt8gZPb+ULstPC4CgZIoE282 Sb0XmqKIqmqqXTvELpasqW8XewsxnQguxmZS5vcr04KOG0RNo3LaEQEu0KqQrvYCmlRV1xRcQzS8 2zqJZsjiY/aYmYtPKEmBc3prkUzgR4aCrZx2UMdMk5y5ou1QdfhUF6xjLMVyjxHqzktlvfhuPiPR 05qR2uW+PLgS8d8S1v36X4V4W3N8LucF6dbcvx+bEZaeedfj3JlxtsGUBXjIhJUQQR1tSVfIUcHe uSboEbpndLnBv8G72tm1u3PH5tnZuS5ncr65HSSgISIzLbAUFeAkqiSKqtinuVVS543b7/Jyo8gy PGcStcsIKwwkwJJzZbwKaGgK+bDKttCqEvb0aERouw4e2HZhWbYjmsFZmJ5HbLy0LTbroxZAm4yj iKoI6HzmyXS+yaIuxVFTaLXvZMhZvWIM5HbYE17uxidSAvbCULooqHGNCNAB4TQmyEiRBMVQlTSr UL0vs2VY5Y7ZjN0GypabJbWrdFkRn3XZE7tCAA8YkADH9kFVW0V7auJo0QPlHTIXrR05W5XKHNje Kk3C9LFWK4UplqVKelg0bIip94QdESbFCXmiiPLyVQk8aycb/iTt/h2W5tutOy2CtrqsJJ70Z5xk 2kVHFa5KbRIi9zj5oqkie73wvIWcosA3dmBNt/8AlMmK7GmdvutOx33GHBLtmYLo2i0okqKmlqv9 KJBQuncy5zINzjNFd71PFl23vhJVly4ynQVI6h3eRAQkgceS8k0m11Xt0ZF71JdeehzYnib3eJTT UyK5Hd7TtykuNkTbgiY8gMSRCRF0qUFgxW9xcjx2FeobbzLUprkTD6IL0c08jZdFFXg62aEBhvYk JCvmlMVvcXI8dhXqG28y1Ka5Ew+iC9HNPI2XRRV4OtmhAYb2JCQr5pUN0jiSouDMvTIz0R24zp11 GM+2oPMBMmPSgadFfmuiDwiY+aISEiKqJtXSOJKi4My9MjPRHbjOnXUYz7ag8wEyY9KBp0V+a6IP CJj5ohISIqom1CZxW9xcjx2FeobbzLUprkTD6IL0c08jZdFFXg62aEBhvYkJCvmlSdVPpHElRcGZ emRnojtxnTrqMZ9tQeYCZMelA06K/NdEHhEx80QkJEVUTa2ygUpSgUpSgUpSgUpSgVAZGupwe1ri 0i+/3ear8fL5u/wfm737PNqfqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebQRnzf4vH/drX82tcf4u uH4PD5Cv52msVu3s6+SBPdr3A+nwT3a1/BrWh1wGwfN/i8f92tfza1x/i64fg8PkK/naaxW7ezr5 IE92vcD6fBPdrX8GtaHXAQ/LmlKUH6TXv7+PTH+Uv/3Q/W5Vht7+/j0x/lL/APdD9WyHcm4F16rZ PNmsw3bS63EGa9HN5uNEj21mWPJptRJwQdlyTVEVDJD48tIPENGpWAYlmeal6xS7dl8LN3oONzpc SFbJ0W8R/GB21YF1yLDim0ZrzEGvb7qd1UUFa9uZ6R5DkF/vlxtD/U3Gb2y7bXSRbZkMK5T4jqEA g62DUCOAgiGXJXBdRS7SIiJyQw2alZN0JvUl3B4lvLNZuWZY1ZI5zrbcnmf/AKXLBpEOPIdZY7jJ q4SiqSO46vaNUQlByrBd731Jg4rkNyexLHxlwrRJk25qBdpFwckSgBSaaVlYzKqJKmvZPkq6RE89 oF5pWJ9Mssu1wnXiPdeq2JXC3N2h+Q9IhZLBny4CgoIkgUbgx222hEjUydF1OSNeQpyQu3pHk98y ydJg3nLnoktcfYO1sMtxUcuUU1JAv4iraq2Tq6RIxbFlR+UEu4Gg1+lYn01ye5wej0soeXXPNM2g Yskp+zy225LlvnNR/OK8kdsHRdJ1eHbfNXTVs9bUXFp0yyy7XCdeI916rYlcLc3aH5D0iFksGfLg KCgiSBRuDHbbaESNTJ0XU5I15CnJCDbKVhnSXO7jfPU613XqPCuNyy/EXrgfhgiNuQpTXYAfDtoK 7NeUpXEcRwVcjGog2Am2k10JvUl3B4lvLNZuWZY1ZI5zrbcnmf8A6XLBpEOPIdZY7jJq4SiqSO46 vaNUQlByg1mlZB1rl39/olngZ3YMSt1rTH5SsutXs5arK4/5OPB2K0KF3OKiSEpc0BETaoqeDOa3 1r00eL5P69zWcbuFxkQ/AAPo25M9rw0Tw7Ii+z3VN9OxII3vkOKFyBxSDZqVg2H5vmCwcnet+a4l m0uHj8ubDt0K+x7tLKU0gqygtRIcVe0SqonvmSkrSCoefKawzJH7j1ZtFlsvVR7L7D6Inz5Jtxob gnIbcitC0clhoWyERfU+02guCqiThEDjYoGv0rIOlmXY5NXqDbG+p1suTsWcUkbw3ItySUipb4fK WatNi0YtmRB3TBRTtiBbQdVF9Jeol3uHqdGm5tZckvGUYi9dEhOOMRQbmMdgQaDtCRjzUpXdUkc9 uO4rYNiBNoG50qjXe99SYOK5DcnsSx8ZcK0SZNuagXaRcHJEoAUmmlZWMyqiSpr2T5KukRPPaVnD MkfuPVm0WWy9VHsvsPoifPkm3GhuCchtyK0LRyWGhbIRF9T7TaC4KqJOEQONiga/Ssm6R3vD7xkf Uq0Ylk9lF6deymsLaJMZxxBO3QRclAGiEvl1PZqJCrm0La7SvHp47nN9u0W23HMcgZdstofh5Eaw YQA9dCdMGzYXw3zRATeES47acgGokjjnINfpWGdIM3PKLHbCyXMrLldsuGIuTspQmoyRLQ6Ix0Rl 1A8m+427JVwXiVCJg1AWgEgTx/Y85aMaD04xh/NbZdRvWG+JbgirALEOKkdptplBXuESisnudwjV TjOKCNCJggab1hyH1T6aXvJFF4ht7CPkLJ8TUUMdoK/HW6zj0v1h/Nrk39fwP1mrZ+ydjyJnQPL4 kRh2RIfgdtppoFI3DIxRBFE81VVVEREq9+lrV+M4X9OP+NBmY3DIWoMNy4SJ0KW+ypvRSl8yYJDI VBSElElTj5qKqm/cqp5rK4fcbg/kcVp+dKdbLnsTdJUX2C/eVa5MrMHJrTjZCYEjqiQrtFRZDvml VHp5aSZ61lcrhjfpB2Q+TlvvOmD9HsJDRtWNmaOhtwXi4tio/LbVdkeg3ylKUClKUClKUClKUClK UClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClK UClKUClKUCoDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tT9QGRrqcHta4tIvv93mq/Hy+bv8H5u9+z zaCM+b/F4/7ta/m1rj/F1w/B4fIV/O01it29nXyQJ7te4H0+Ce7Wv4Na0OuA2D5v8Xj/ALta/m1r j/F1w/B4fIV/O01it29nXyQJ7te4H0+Ce7Wv4Na0OuAh+XNKUoP0mvf38emP8pf/ALofrZWbXAZv kq9tscZ8uMzFfd5l7bTJOk2Ot6TRPurtE2vLz3pNY1e/v49Mf5S//dD9blQKVlmT5Jf7bbOrWUWy YykvGWgYgxZYG7EUI8BuaRK2JiqOuLKcbUxJE4ts+yvBeXHceqGS2GbcfWG2Y+1Ets6RAkONSn+P eG0ldEJVRoiRptsUZUkAydUlcQGuKMmGv0rJsJy/LLvnEnp/nFt8G9Nsj88Cjg1AkNNC62yukjz5 RpzV5eLnJpRVouPNdq3WemHULOE6Xv5NdDhOW3GsRi3B6BcIx+lbmSW9XVfSSkgw7LpjsXlbUiVH myATaUlDf6VnOD3/AKnOTpwZXh7xRG4Lj7DrMaJDcJ4FHjHEEuElDJxCJUIiaEFb0qlz2Hbd88u1 sxXIb9O6fZBbWrNaJNyRZ8qCjchWQU+yisPvEJFpfNQ0iIv7+kULzSs5we79VJ86dByOws25o4Lh xLk9AYZbYkIooAEyzcZBPCXIiX2meKNa2qmih49MsxyrNfSHytlt3gba0x7cF0/FTi5/5fH+WTuW w+PyJeRO8XPaDh5hplKybDc2yS19EG81y+82W+TzxFL/ABoMaIsGQ8LUYXXuZK64h+040KmDYCKk ns+0IpJ4Pd+qk+dOg5HYWbc0cFw4lyegMMtsSEUUACZZuMgnhLkRL7TPFGtbVTRQDRqVlnTjM80y CDjqXccfiy8pxZy9QFix3jbgm2kUfleTiK+JrLE+I9tW0BQ5ubR2pPoleckumD47Py/I7LcZ95sk W4xmY0BYkjirTavGaK8aO6J1pFIAbEVJPZTkKIGgVX8bw6x2Ccc6ElzkSyaVkX7ldpU9xoFVFIGy kOGrYkogpIGkJQDlviOrBVMx6TdbplefGzcOy9Akx7TAbdEnYrPGE1JR4mkIVI1cmkh8SHkDTQ+S ipKFzpWM2TqllUTB4eUZNbbLJ9IYRKymPEtyutdnwrUYiaJw1Ln3fEiSaAe1xUdvfPq52S6ZVb84 h4zk0+y3T0jbZU6PIt1tdhdjw7sYCAhN97uc/FCqKihx7a+RcvZC51X8bw6x2Ccc6ElzkSyaVkX7 ldpU9xoFVFIGykOGrYkogpIGkJQDlviOobAJeSy1ze33G42x28W+7pFZmNRHxjbK3xHQJY7kg1EU V3SgDgIWlL2SIiWF6cZnmmQQcdS7jj8WXlOLOXqAsWO8bcE20ij8rycRXxNZYnxHtq2gKHNzaO0G p1X7Fh1jslpudstyXMWrq6T0x527SnpLhk0DXNJDjhOiSA2AookijxTWl86r/RK85JdMHx2fl+R2 W4z7zZItxjMxoCxJHFWm1eM0V40d0TrSKQA2IqSeynIUSU6Ry5UrBmWZkl6W7bp061DJfcU3nwhz HooOukvznSBkSMvJFJSVERF0gTOK2G2YxjsLH7K08zboLXZjNOyXHybBPcCG4REop7kRV0iIiJpE REk6VTMek3W6ZXnxs3DsvQJMe0wG3RJ2KzxhNSUeJpCFSNXJpIfEh5A00PkoqShZr3HlSrW8xCf7 EguPBzmo60SKvmnn7t1WfQGVfjv607/hVMsnVLKomDw8oya22WT6QwiVlMeJblda7PhWoxE0ThqX Pu+JEk0A9rio7e+fVzsl0yq35xDxnJp9lunpG2yp0eRbra7C7Hh3YwEBCb73c5+KFUVFDj218i5e yHPJxK+yXEckz47xomkJx4yVE+HmNdeO4vcLdeWJj70Um2+W0AiVfMVT99P4a5sAl5LLXN7fcbjb Hbxb7ukVmY1EfGNsrfEdAljuSDURRXdKAOAhaUvZIiJYXpxmeaZBBx1LuOPxZeU4s5eoCxY7xtwT bSKPyvJxFfE1lifEe2raAoc3No7QanSs/wCiV5yS6YPjs/L8jstxn3myRbjGZjQFiSOKtNq8Zorx o7onWkUgBsRUk9lOQokp0jlypWDMszJL0t23Tp1qGS+4pvPhDmPRQddJfnOkDIkZeSKSkqIiLpAt lKqfSOXKlYMyzMkvS3bdOnWoZL7im8+EOY9FB10l+c6QMiRl5IpKSoiIuktlApSlApSlApSlApSl ApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSl ApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UBka6nB7WuLSL7/d5qvx8vm7/B+bvfs82gjP m/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgNg+b/ABeP+7Wv5ta4/wAX XD8Hh8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64CH5c0pSg/Sa9/fx6Y/wApf/uh+tyrDb39/Hpj /KX/AO6H63Kgr83DrBPnXl65wGbhEvLUYZ1ulsg7EdNhSUXlaIdE6qK2KmW1UWGU8uCV723E8Vts wZluxqyw5Idri9HgtNmPaZJlrRCKKnBozbH6IEQppFVKouT5Jf7bbOrWUWyYykvGWgYgxZYG7EUI 8BuaRK2JiqOuLKcbUxJE4ts+yvBeXHceqGS2GbcfWG2Y+1Ets6RAkONSn+PeG0ldEJVRoiRptsUZ UkAydUlcQGuKMmF5i9PcBixwjxsHxlhlvv8ABtu1MCI99tGntIg6TuNigF9IURF2iartZxPFWLpb 7ozjVlan2yMkSBKCC0jsRhBIUaaNB2AIJEnEVRNEqa81rP8ACcvyy75xJ6f5xbfBvTbI/PAo4NQJ DTQutsrpI8+Uac1eXi5yaUVaLjzXat1nph1CzhOl7+TXQ4TltxrEYtwegXCMfpW5klvV1X0kpIMO y6Y7F5W1IlR5sgE2lJQ1/G8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2ifCrBWc4Pf +pzk6cGV4e8URuC4+w6zGiQ3CeBR4xxBLhJQycQiVCImhBW9Kpc9h23fPLtbMVyG/Tun2QW1qzWi TckWfKgo3IVkFPsorD7xCRaXzUNIiL+/pFCTtXT3AbT4v0Xg+MwPGRjiSvDWphvvsHrm0fEU5AWk 2K7RdJtKk4GPWCBOjzoNjtkWXGgjbmH2YgA41FFdjHEkTYtIqIqAnsoqe6qZbb/mkbqzasJvF4xK c09aJd2lHCgvMSeAOMstt9knz7QqbpEjqkaHwMEAFBTLtwdLit16jwYlyeV1jIFGAU912W3GVy2w ntIJOIXaR10y7YkKIhKg8U1oLNZ8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEUy2ZLstrsl+K1 GWrp7gNp8X6LwfGYHjIxxJXhrUw332D1zaPiKcgLSbFdouk2lUzBMtz7JrhbLelxxlqS1ZJD2QAN nfXwFxSQ7HaZFVlacBHWZAko8uXgzVCFH21H26cZZkuVQcdi5YzbGmsuxZy7NDaDfYchoCRRNO9z 5KTni0MVBG1ZUFFCdXTlBc7ZhGF2udAnWzEMfhS7c0TMF+PbWW3IoEpqQNkIooCquOKqDpFUy+kt dtnx6wWadcJ1osdst0u5O96e/FiA05KPZLzdIURTLZkuy2uyX4rWc9DMmyqRY8GtuTPQpnpvERuc d5snTkN9gYgEr7pr8sb3ihcVUEO2okO3d9ytZoFQy48y3dL1coM+bAk3eM006rHb4tOtiYpJACBR V5RIBUjQkUWGRVNBpcsuLMhOgfU3IRvOQDdFdyF1uQl6loUdYc2YkdGU7mmRFGwRRbQUJBRCQk8q tlkyHKpN8h2uTcsZlen7JKutplW6M65Hh9oowiJGrv8AlgF4sFRwUj7RtV4p3E4BKdL+nuNdOsda s+PQmRIWgafmrEYaky0DlwV4mWwRwhQlRCVNr5qqqSkqyeMYniuL+I9Wcastk8Tx8R6OgtR+7x3x 5cBTlrkWt+7a/GqLhueX/I52JQQnY+xLyDBFvzrCRTNyHK3GQHFHvIpRyWQaIC8SVWS04vnx7ekF 3y679OrJMyDKsflXq94+xcLeIWomXAVWQVxx0EkfLiJvM8u2jKIq69nmPELBaunuA2nxfovB8Zge MjHEleGtTDffYPXNo+IpyAtJsV2i6TaV7WzCMLtc6BOtmIY/Cl25omYL8e2stuRQJTUgbIRRQFVc cVUHSKpl9Jao2G5tklr6IN5rl95st8nniKX+NBjRFgyHhajC69zJXXEP2nGhUwbARUk9n2hFLBDu WaQsqbxa73XH5su52iZNgTItoejtxTjnHb060UlxXhJZQr7JtqiNqm15ooBZrPj1gs064TrRY7Zb pdyd709+LEBpyUeyXm6QoimWzJdltdkvxWmK2SLjmOwrLDceeaitcSffVCekGvmbzpIic3XDUjM9 bIiIl81qjdKc1yq++qpZNHsoes+Nle47duB0fCdrwiEJEZL3O54sTREEO1xUNvfulaZQKhlx5lu6 Xq5QZ82BJu8Zpp1WO3xadbExSSAECiryiQCpGhIosMiqaDS1hvM7rbcHz7JrpJxm9erkm4nFj2SW S8WI7XMI8ki5duV5KhoiaHY6SqnkeS5Lh3UWbPv93tl7dtuCXa7uQba+/CbdRh6MrXciG68LZfuw jIRVU0MxUURpOQaB0v6e4106x1qz49CZEhaBp+asRhqTLQOXBXiZbBHCFCVEJU2vmqqpKSrJ4xie K4v4j1Zxqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8apmK5N1KZ9KvZjj0KDAjW16W3PmpHtkdp1vS o24rc2YvAhUiJ3Qo2jS+TnJEGFZ6hdQbB6al5paYTbMDG7heY8I4AQ5EsovaVUBxmbMBARHEEufA kU21BHE58A0C1dPcBtPi/ReD4zA8ZGOJK8NamG++weubR8RTkBaTYrtF0m0r2tmEYXa50CdbMQx+ FLtzRMwX49tZbcigSmpA2QiigKq44qoOkVTL6S1GQHM+Yvi2i6XzDHu/bZL8V9mG+zIV8SZEF8IT x82W+aqZo8ikrrYojeuR+PSC7Zpk2K2TK8jk4+zEu9oYlhb4EN7uNG4AEhK+buiFUUl7faRRUkHm fDmYWaz49YLNOuE60WO2W6Xcne9PfixAaclHsl5ukKIplsyXZbXZL8Vpitki45jsKyw3HnmorXEn 31QnpBr5m86SInN1w1IzPWyIiJfNarOAS8llrm9vuNxtjt4t93SKzMaiPjG2VviOgSx3JBqIorul AHAQtKXskREsL04zPNMgg46l3HH4svKcWcvUBYsd424JtpFH5Xk4iviayxPiPbVtAUObm0doNAxW yRccx2FZYbjzzUVriT76oT0g18zedJETm64akZnrZEREvmtSdZNhubZJa+iDea5febLfJ54il/jQ Y0RYMh4WowuvcyV1xD9pxoVMGwEVJPZ9oRSwQ7lmkLKm8Wu91x+bLudomTYEyLaHo7cU45x29OtF JcV4SWUK+ybaojapteaKAXmlUbpBds0ybFbJleRycfZiXe0MSwt8CG93GjcACQlfN3RCqKS9vtIo qSDzPhzO80ClUbo5HI7VervInXOXLmZBdmXFlXB99sAYuUppoGmzNQaEQER02goqCm96SqlYMdyr pfjE7Msjyu9ZN6v4QqOwpF4ddblzgORKlOFzD/8AxNNOKikjaEhIukoNmpVGhy8lDKm8Nyy42y5N Xi0TJTUm0RH7Y5HRg47RjvxDpKReKRRMCbUFbXXJSRRqX7HXJc4yez2j0pNhR7bBslsV6PcIRndZ pOw0JZSPpJIFZM/aF1Q5EovNkIG0pKGzUrM+kuAZVi9wt8zI81vV78NjbFvdZkXR2Q27OKQ89KfI TFOWuTTbRr7SNoQknki1plApVMx7I7qdjy+43S7YZL9EXKa3FKDcCCPGYaFCBuc6SF2Xh8+6qCqC ioqCvuqv4ZkXUuZlTlhyVm2Wl2TaJUmAkmzo24TzZsAjiIxcJIm0HeTmJGySqQcFJOagGp0rOekF 3y679OrJMyDKsflXq94+xcLeIWomXAVWQVxx0EkfLiJvM8u2jKIq69nmPHi6bZfmmR36ywpsvHyF i0PP5PHj2x5tyHNSS7HCO24UghUe4zJBSQXEVYZFtBeb4hqdKzOHf3sVtXV69ms25s2C5Pzo8WTO cPQjaokkmQM+StgrhuKgonEea6HXlXZ04vPUqZfHomY434WAsYnG5vhY8Tg6JCiNdtufLVzmJEXL 5NA7evb5pxDQKV4zxlHBkBBeZYlk0SMOvNK62B69kiBCFSFF0qihCqp5bT31lmG5tklr6IN5rl95 st8nniKX+NBjRFgyHhajC69zJXXEP2nGhUwbARUk9n2hFA1mlZnkGY5Vg/pL1mdsuQdnG7nfY/o6 C7b+PgexyaLm8/y7niB0SceHBfI+XsxmU55mmHZFJt94nYlemrdi1zyWU3CivRZLoRu0LbPbJ53s iRmSo8quIfExRsFBSINfpWc22/5pG6s2rCbxeMSnNPWiXdpRwoLzEngDjLLbfZJ8+0Km6RI6pGh8 DBABQUy8Yd/exW1dXr2azbmzYLk/OjxZM5w9CNqiSSZAz5K2CuG4qCicR5rodeVBplKz/pxeepUy +PRMxxvwsBYxONzfCx4nB0SFEa7bc+WrnMSIuXyaB29e3zTjoFApSlApSlApSlApSlApSlApSlAp SlApSlApSlApSlApSlApSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UBka6nB7WuLSL7 /d5qvx8vm7/B+bvfs82gjPm/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDr gNg+b/F4/wC7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgIflzSlKD9Jr39/Hp j/KX/wC6H63KsNvf38emP8pf/uh+tyoK/Nw6wT515eucBm4RLy1GGdbpbIOxHTYUlF5WiHROqiti pltVFhlPLgle9txPFbbMGZbsassOSHa4vR4LTZj2mSZa0QiipwaM2x+iBEKaRVSpmlBWYvT3AYsc I8bB8ZYZb7/Btu1MCI99tGntIg6TuNigF9IURF2iartZxPFWLpb7ozjVlan2yMkSBKCC0jsRhBIU aaNB2AIJEnEVRNEqa81qZpQV/G8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2ifCrBS lBRunfTCxYTOWZAkvSXRadaYFYUKI2wjqtK8qBEYZEiPsMbI0JURoUFRRS3M43hGF41OOdjmIY/Z pbjSsm/AtrMdwgVUVQUgFFUdiK6920T4VYKUFZxnEjsdvvjQZLeps+9SVlSLnJGN4ht3w7TAkAgy LScQZb0itqm0XfLeq4unvTLD8JxAsZttohSIz8ZIs56RBjC7cGkQkEZCtNgL2hMh2QqqoqqW1UlW 50oK/bMIwu1zoE62Yhj8KXbmiZgvx7ay25FAlNSBshFFAVVxxVQdIqmX0lqwUpQVO04FaItuvNou b72QWW6znppWu7R4z0Zg3ZDkk0BEaEiFXXOSdxTVOI6VNeczZ8esFmnXCdaLHbLdLuTvenvxYgNO Sj2S83SFEUy2ZLstrsl+K1J0oIaLieKxboF0jY1ZWJ7cl+WEpuC0LovvigvOoaDtDcEUQi3skREV V1XtZ8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEUy2ZLstrsl+K1J0oIyz49YLNOuE60WO2W6X cne9PfixAaclHsl5ukKIplsyXZbXZL8Vris+EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdG SaLaaJfitWClBX7ZhGF2udAnWzEMfhS7c0TMF+PbWW3IoEpqQNkIooCquOKqDpFUy+ktWClKDitV ptVp8X6LtkKB4yScuV4ZgW+++eubp8UTkZaTZLtV0m1qMs+EYXZnoj1nxDH7c7DddeinFtrLRMG6 Ag4YKIpxIwERJU0qoKIu0RKsFKCs2rp7gNp8X6LwfGYHjIxxJXhrUw332D1zaPiKcgLSbFdouk2l duMYniuL+I9Wcastk8Tx8R6OgtR+7x3x5cBTlrkWt+7a/GpmlBX7PhGF2aDcINoxDH7dEuTXZnsR bay03KDRJwdERRDHRkmi2miX4rXvjGJ4ri/iPVnGrLZPE8fEejoLUfu8d8eXAU5a5Frfu2vxqZpQ Vm1YDh9j8W9i2N2XGp8mMcbx9ptkZiQ2JaXyXtqi6JBLRIQ7FNoutV49L+nuNdOsdas+PQmRIWga fmrEYaky0DlwV4mWwRwhQlRCVNr5qqqSkq2ylBGWfHrBZp1wnWix2y3S7k73p78WIDTko9kvN0hR FMtmS7La7JfitcVnwjC7NBuEG0Yhj9uiXJrsz2IttZablBok4OiIohjoyTRbTRL8VqwUoIbGMTxX F/EerONWWyeJ4+I9HQWo/d4748uApy1yLW/dtfjUzSlBX8OxgcZK5hHvVzmxJ05+a3FlIx24hvvu vuo0oNiaiRukvyhGqIiIip57sFKz9vM7rbcHz7JrpJxm9erkm4nFj2SWS8WI7XMI8ki5duV5Khoi aHY6SgsFnwjC7NBuEG0Yhj9uiXJrsz2IttZablBok4OiIohjoyTRbTRL8Vr3ZxPFWLpb7ozjVlan 2yMkSBKCC0jsRhBIUaaNB2AIJEnEVRNEqa81qsT77mGLekJOU3fDJkCHZJtz5stSYUhwme0uuzyk KjICpc3RUy262iNpx+UjOnecZhK6irheZ2tmLLetDt0ZVI0eK42DbzTXm21OlqQmrq6IlbRFaJE7 m14BqdKpnTgnhyPqBEOZNkMxskRI4yZTj/ZFy3QniAFMlUQ7jrhICaEeSoiInlVMy05jHTvrkLN3 vTR2yTJkwHQukhHYhpaYkpEacQ+YAjxEXbFUDRKOuKqNBqbOPWBmDcoLNjtjcS6uuvXFgIgI3MN1 NOm6KJpwjTyJS2pJ79144xieK4v4j1Zxqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8aph51e7LzmX2 bjNwgS8bnZDDetyPBHjNRfDqoE+iurJAhkiqPNtAum1VGi5oI1+N1VzCwzr/AAczsLJS7di03ImW EajwnFCMoJwUWpsxeLimqIZdtBVstI5teAazZ8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEUy2 ZLstrsl+K1xYXjA40N1M71c7zLus5JsqVPRhHCNGGmEREZbbBBQGATyHe9qqruoyAGYHfFx/Kbxj MuBNtsk+5bEk26eZITIfJt95xRABMuTwu8uTrSIIceR0z9jrkucZPZ7R6Umwo9tg2S2K9HuEIzus 0nYaEspH0kkCsmftC6ociUXmyEDaUlDRsbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde 7aJ8KY3hGF41OOdjmIY/ZpbjSsm/AtrMdwgVUVQUgFFUdiK6920T4VYKUCoyz49YLNOuE60WO2W6 Xcne9PfixAaclHsl5ukKIplsyXZbXZL8VqTpQQ2MYniuL+I9Wcastk8Tx8R6OgtR+7x3x5cBTlrk Wt+7a/Gq/wBO+mFiwmcsyBJekui060wKwoURthHVaV5UCIwyJEfYY2RoSojQoKiilu80oKN076YW LCZyzIEl6S6LTrTArChRG2EdVpXlQIjDIkR9hjZGhKiNCgqKKW5nG8IwvGpxzscxDH7NLcaVk34F tZjuECqiqCkAoqjsRXXu2ifCrBSgr+N4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE +FWClKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBUBka6nB7WuLSL7/d5 qvx8vm7/AAfm737PNqfqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebQRnzf4vH/drX82tcf4uuH4PD 5Cv52msVu3s6+SBPdr3A+nwT3a1/BrWh1wGwfN/i8f8AdrX82tcf4uuH4PD5Cv52msVu3s6+SBPd r3A+nwT3a1/BrWh1wEPy5pSlB+k17+/j0x/lL/8AdD9blWG3v7+PTH+Uv/3Q/W5UClKUClKUClKU ClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCuK1Wm1Wnxfou2QoHjJJy5Xh mBb77565unxRORlpNku1XSbWu2qNbbxKG+9RbvImMg1ZHWYEdmZNWPBbBqC1LV1wlQu0RHMMXHUR U7bTXsqoLyCwYxieK4v4j1Zxqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8a8LPhGF2Z6I9Z8Qx+3Ow 3XXopxbay0TBugIOGCiKcSMBESVNKqCiLtESs5Z6hdQbB6al5paYTbMDG7heY8I4AQ5EsovaVUBx mbMBARHEEufAkU21BHE58LBg936qT506DkdhZtzRwXDiXJ6Awy2xIRRQAJlm4yCeEuREvtM8Ua1t VNFALNjeEYXjU452OYhj9mluNKyb8C2sx3CBVRVBSAUVR2Irr3bRPhXHH6ZdNozMlmP09xJlqU0j MgG7NHEXgQxNANED2h5gBaXy2Ir70SqlhubZJa+iDea5febLfJ54il/jQY0RYMh4WowuvcyV1xD9 pxoVMGwEVJPZ9oRSTtt/zSN1ZtWE3i8YlOaetEu7SjhQXmJPAHGWW2+yT59oVN0iR1SND4GCACgp kFzs+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W12S/Fa4rPhGF2Z6I9Z8Qx+3Ow3XXo pxbay0TBugIOGCiKcSMBESVNKqCiLtESvfO776r4Pfsm8L4v0RbZE7w/c4d3tNEfDlpeO+Ot6XW/ ctV+HLyUMqbw3LLjbLk1eLRMlNSbREftjkdGDjtGO/EOkpF4pFEwJtQVtdclJFEJmz4Rhdmg3CDa MQx+3RLk12Z7EW2stNyg0ScHREUQx0ZJotpol+K17s4nirF0t90ZxqytT7ZGSJAlBBaR2IwgkKNN Gg7AEEiTiKomiVNea1lnQTLM9v2M2+ROJl2DbMftzh2+VE5Xi5m5CQu+D5S+0rTppsHTRFIkebNG yaI10BnLbscG5SZ2F3PHmocF2Uku+T4LURVBN8TcYfeJsfeqmoKgiJL5rpFC2UrGWeoXUGwempea WmE2zAxu4XmPCOAEORLKL2lVAcZmzAQERxBLnwJFNtQRxOfCzdOLz1KmXx6JmON+FgLGJxub4WPE 4OiQojXbbny1c5iRFy+TQO3r2+acQ0ClZnDv72K2rq9ezWbc2bBcn50eLJnOHoRtUSSTIGfJWwVw 3FQUTiPNdDryrih5t1KsdjyS95jiG4Fpskq5tu9mPB5OsDyRjTc6YpdweS89Agdv3HzTiGs0qmQH M+Yvi2i6XzDHu/bZL8V9mG+zIV8SZEF8ITx82W+aqZo8ikrrYojeuR8XRK85JdMHx2fl+R2W4z7z ZItxjMxoCxJHFWm1eM0V40d0TrSKQA2IqSeynIUQNApSqZj0m63TK8+Nm4dl6BJj2mA26JOxWeMJ qSjxNIQqRq5NJD4kPIGmh8lFSULnSsZsnVLKomDw8oya22WT6QwiVlMeJblda7PhWoxE0ThqXPu+ JEk0A9rio7e+fVth3LNIWVN4td7rj82Xc7RMmwJkW0PR24pxzjt6daKS4rwksoV9k21RG1Ta80UA vNKz/oleckumD47Py/I7LcZ95skW4xmY0BYkjirTavGaK8aO6J1pFIAbEVJPZTkKJZ87vvqvg9+y bwvi/RFtkTvD9zh3e00R8OWl47463pdb9y0EzSqNDl5KGVN4bllxtlyavFomSmpNoiP2xyOjBx2j HfiHSUi8UiiYE2oK2uuSkijTOgmWZ7fsZt8icTLsG2Y/bnDt8qJyvFzNyEhd8Hyl9pWnTTYOmiKR I82aNk0RqG2Uqps5bdjg3KTOwu5481Dguykl3yfBaiKoJvibjD7xNj71U1BUERJfNdItFZ6hdQbB 6al5paYTbMDG7heY8I4AQ5EsovaVUBxmbMBARHEEufAkU21BHE58A2alZ/04vPUqZfHomY434WAs YnG5vhY8Tg6JCiNdtufLVzmJEXL5NA7evb5px44d/exW1dXr2azbmzYLk/OjxZM5w9CNqiSSZAz5 K2CuG4qCicR5rodeVBplKyaHm3Uqx2PJL3mOIbgWmySrm272Y8Hk6wPJGNNzpil3B5Lz0CB2/cfN ONmgOZ8xfFtF0vmGPd+2yX4r7MN9mQr4kyIL4Qnj5st81UzR5FJXWxRG9cjC50rP+iV5yS6YPjs/ L8jstxn3myRbjGZjQFiSOKtNq8Zorxo7onWkUgBsRUk9lOQokp0jlypWDMszJL0t23Tp1qGS+4pv PhDmPRQddJfnOkDIkZeSKSkqIiLpAtlKqfSOXKlYMyzMkvS3bdOnWoZL7im8+EOY9FB10l+c6QMi Rl5IpKSoiIuktlApSlApSlApSlApSlApSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UB ka6nB7WuLSL7/d5qvx8vm7/B+bvfs82gjPm/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9 Pgnu1r+DWtDrgNg+b/F4/wC7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgIflz SlKD9Jr39/Hpj/KX/wC6H63KsNvf38emP8pf/uh+tyoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFQy4zaiul6mPM99m9xmo8+C6IlFe4CYK4TapojNsxbNS3 yBlofcCVM1TMeyO6nY8vuN0u2GS/RFymtxSg3AgjxmGhQgbnOkhdl4fPuqgqgoqKgr7qCaxjE8Vx fxHqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX414Y3hGF41OOdjmIY/ZpbjSsm/AtrMdwgVUVQUg FFUdiK6920T4VnLPULqDYPTUvNLTCbZgY3cLzHhHACHIllF7SqgOMzZgICI4glz4Eim2oI4nPhZu nF56lTL49EzHG/CwFjE43N8LHicHRIURrttz5aucxIi5fJoHb17fNOIW2z49YLNOuE60WO2W6Xcn e9PfixAaclHsl5ukKIplsyXZbXZL8Vqv2rpvj1ly+35Bjo+gWYUaRH9E2yHFYhPd9W1dccEWeamq sR/NDT9xBPcpIUNDv72K2rq9ezWbc2bBcn50eLJnOHoRtUSSTIGfJWwVw3FQUTiPNdDryrih5t1K sdjyS95jiG4Fpskq5tu9mPB5OsDyRjTc6YpdweS89Agdv3HzTiGs1X7PhGF2aDcINoxDH7dEuTXZ nsRbay03KDRJwdERRDHRkmi2miX4rUZAcz5i+LaLpfMMe79tkvxX2Yb7MhXxJkQXwhPHzZb5qpmj yKSutiiN65HWcNzbJLX0QbzXL7zZb5PPEUv8aDGiLBkPC1GF17mSuuIftONCpg2AipJ7PtCKBoDO J4qxdLfdGcasrU+2RkiQJQQWkdiMIJCjTRoOwBBIk4iqJolTXmtSc+JFnwZEGdGZlRJLRMvsPNob boEmiAhXyIVRVRUXyVFrLIebdSrHY8kveY4huBabJKubbvZjweTrA8kY03OmKXcHkvPQIHb9x804 +1nkZLG6+2603/IbZcHXMWmyXGbab8ZvQyogtE5CN50RJOTyC+hbNCMFREaRSC9YxieK4v4j1Zxq y2TxPHxHo6C1H7vHfHlwFOWuRa37tr8a8MbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFd e7aJ8K987vvqvg9+ybwvi/RFtkTvD9zh3e00R8OWl47463pdb9y1X4cvJQypvDcsuNsuTV4tEyU1 JtER+2OR0YOO0Y78Q6SkXikUTAm1BW11yUkUQmcbwjC8anHOxzEMfs0txpWTfgW1mO4QKqKoKQCi qOxFde7aJ8KY3hGF41OOdjmIY/ZpbjSsm/AtrMdwgVUVQUgFFUdiK6920T4VmfQTLM9v2M2+ROJl 2DbMftzh2+VE5Xi5m5CQu+D5S+0rTppsHTRFIkebNGyaI10BnLbscG5SZ2F3PHmocF2Uku+T4LUR VBN8TcYfeJsfeqmoKgiJL5rpFCTxjE8VxfxHqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX417WfH rBZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitZYz1C6g2D01LzS0wm2YGN3C8x4RwA hyJZRe0qoDjM2YCAiOIJc+BIptqCOJz4WbpxeepUy+PRMxxvwsBYxONzfCx4nB0SFEa7bc+WrnMS IuXyaB29e3zTiGgVDLjNqK6XqY8z32b3Gajz4LoiUV7gJgrhNqmiM2zFs1LfIGWh9wJVMh397FbV 1evZrNubNguT86PFkznD0I2qJJJkDPkrYK4bioKJxHmuh15VxQ826lWOx5Je8xxDcC02SVc23ezH g8nWB5IxpudMUu4PJeegQO37j5pxC82zCMLtc6BOtmIY/Cl25omYL8e2stuRQJTUgbIRRQFVccVU HSKpl9Ja98YxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4CnLXItb921+NQsBzPmL4toul8wx7v22S/F fZhvsyFfEmRBfCE8fNlvmqmaPIpK62KI3rkcZ0guF/yHp1ZDzXJrZPl5Dj7ExlqBGO3y0AmQ75qY PqpEivNJ3GhaQCJFRE5CiBc7Pj1gs064TrRY7Zbpdyd709+LEBpyUeyXm6QoimWzJdltdkvxWpOq N0ojlN6dzLZMnXOS0N3vUAXnbg+clGW7jKaBEkKfd5CAiKHy5JxTS7Tde3RknvUl1l6ZNl+Gvd4i tOzJTkh3tNXKS22JOOERlxABFFJVXSJQSdnwjC7NBuEG0Yhj9uiXJrsz2IttZablBok4OiIohjoy TRbTRL8Vr3ZxPFWLpb7ozjVlan2yMkSBKCC0jsRhBIUaaNB2AIJEnEVRNEqa81qM6Ry5UrBmWZkl 6W7bp061DJfcU3nwhzHooOukvznSBkSMvJFJSVERF0jpHLlSsGZZmSXpbtunTrUMl9xTefCHMeig 66S/OdIGRIy8kUlJUREXSBZp8SLPgyIM6MzKiSWiZfYebQ23QJNEBCvkQqiqiovkqLUZjGJ4ri/i PVnGrLZPE8fEejoLUfu8d8eXAU5a5Frfu2vxqZpQV/G8IwvGpxzscxDH7NLcaVk34FtZjuECqiqC kAoqjsRXXu2ifCmN4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FWClBX8bwjC8an HOxzEMfs0txpWTfgW1mO4QKqKoKQCiqOxFde7aJ8K98YxPFcX8R6s41ZbJ4nj4j0dBaj93jvjy4C nLXItb921+NTNKCMs+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W12S/FaYrZIuOY7Cs sNx55qK1xJ99UJ6Qa+ZvOkiJzdcNSMz1siIiXzWpOlBGYrZIuOY7CssNx55qK1xJ99UJ6Qa+ZvOk iJzdcNSMz1siIiXzWpOlKBSlKBSlKBSlKBSlKBSlKBSlKBUBka6nB7WuLSL7/d5qvx8vm7/B+bvf s82p+oDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tBGfN/i8f8AdrX82tcf4uuH4PD5Cv52msVu3s6+ SBPdr3A+nwT3a1/BrWh1wGwfN/i8f92tfza1x/i64fg8PkK/naaxW7ezr5IE92vcD6fBPdrX8Gta HXAQ/LmlKUH6TXv7+PTH+Uv/AN0P1uVYbe/v49Mf5S//AHQ/W5UClKUClKUClKUClKUClKUClKUC lKUClKUClKUClKUClKUClKUClKUClKUClKUClKUCoxnHrAzBuUFmx2xuJdXXXriwEQEbmG6mnTdF E04Rp5EpbUk9+6k6UENjGJ4ri/iPVnGrLZPE8fEejoLUfu8d8eXAU5a5Frfu2vxrwxvCMLxqcc7H MQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwqwUoK/jeEYXjU452OYhj9mluNKyb8C2sx3CBVRV BSAUVR2Irr3bRPhTG8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2ifCrBSghsYxPFcX 8R6s41ZbJ4nj4j0dBaj93jvjy4CnLXItb921+Ne1nx6wWadcJ1osdst0u5O96e/FiA05KPZLzdIU RTLZkuy2uyX4rUnSgr+N4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FLPhGF2Z6I 9Z8Qx+3Ow3XXopxbay0TBugIOGCiKcSMBESVNKqCiLtESrBSgVX7PhGF2aDcINoxDH7dEuTXZnsR bay03KDRJwdERRDHRkmi2miX4rVgpQQzOJ4qxdLfdGcasrU+2RkiQJQQWkdiMIJCjTRoOwBBIk4i qJolTXmtSc+JFnwZEGdGZlRJLRMvsPNobboEmiAhXyIVRVRUXyVFr2pQQ2MYniuL+I9Wcastk8Tx 8R6OgtR+7x3x5cBTlrkWt+7a/GvDG8IwvGpxzscxDH7NLcaVk34FtZjuECqiqCkAoqjsRXXu2ifC rBSgr+N4RheNTjnY5iGP2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FMbwjC8anHOxzEMfs0txpWT fgW1mO4QKqKoKQCiqOxFde7aJ8KsFKCGxjE8VxfxHqzjVlsniePiPR0FqP3eO+PLgKctci1v3bX4 0jYxZLf6XesVuhWKfd+RTJ9uhstyHHV5KjpKoKjhoRkSK4hJtV2i7VFmaUFfxrGBsGJO2CHerm46 67LfK5OowsnvSXnHjdREbRrkhukqJ2+PkiKKp7/fC8eZxewDaGZ824f5TJlOyZnb7rrsh9x9wi7Y ACbN0tIIoiJpKmaUEZitki45jsKyw3HnmorXEn31QnpBr5m86SInN1w1IzPWyIiJfNaYrZIuOY7C ssNx55qK1xJ99UJ6Qa+ZvOkiJzdcNSMz1siIiXzWpOlApSlApSlApSlApSlApSlApSlApSlApSlA pSlApSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/UBka6nB7WuLSL7/d5qvx8vm7/AAfm 737PNoIz5v8AF4/7ta/m1rj/ABdcPweHyFfztNYrdvZ18kCe7XuB9Pgnu1r+DWtDrgNg+b/F4/7t a/m1rj/F1w/B4fIV/O01it29nXyQJ7te4H0+Ce7Wv4Na0OuAh+XNKUoP0mvf38emP8pf/uh+tyrD b39/Hpj/ACl/+6H60zALtdbt6welLnjM/wAHe5MSL6EfJzsMBx4NSeSrxlDteYppE2OkoLNSqzgF 2ut29YPSlzxmf4O9yYkX0I+TnYYDjwak8lXjKHa8xTSJsdJVgnjKODICC8yxLJokYdeaV1sD17JE CEKkKLpVFCFVTy2nvoPalYzZOqWVRMHh5Rk1tssn0hhErKY8S3K612fCtRiJonDUufd8SJJoB7XF R298+rbDuWaQsqbxa73XH5su52iZNgTItoejtxTjnHb060UlxXhJZQr7JtqiNqm15ooBeaVkEfL+ pJ9CpPU2RLxKO6uLJeo9ubtkh0RMWReXm6sgeQmCH7KAitq4Kc3EbVXFx6oZLYZtx9YbZj7US2zp ECQ41Kf494bSV0QlVGiJGm2xRlSQDJ1SVxAa4oyYa/Sss6d5xmErqKuF5na2Yst60O3RlUjR4rjY NvNNebbU6WpCauroiVtEVokTubXhYOnBPDkfUCIcybIZjZIiRxkynH+yLluhPEAKZKoh3HXCQE0I 8lRERPKgudK8Z4yjgyAgvMsSyaJGHXmldbA9eyRAhCpCi6VRQhVU8tp76zLpxmeaZBBx1LuOPxZe U4s5eoCxY7xtwTbSKPyvJxFfE1lifEe2raAoc3No7QanSsmxzqXdZ3qy9Ml4yHpTp+eTTIzrhRvC vj4ZUNx5TPtxT77ibVtVHskvI9KKe2GXvPbtlTmMZ1FZtsSfaJTzTbcLwEtxQNhsjadjT5KCIo/7 SqTRoRtqHLRqAanSvnP1nzA/2PjMa+XH/Kbh02k32BOt8yS1NjOwo8ZUN2QhoTxuk+Di6QEHiTZd 5CU60yyZDlUm+Q7XJuWMyvT9klXW0yrdGdcjw+0UYREjV3/LALxYKjgpH2jarxTuJwDQKVlmG55f 8jnYlBCdj7EvIMEW/OsJFM3IcrcZAcUe8ilHJZBogLxJVZLTi+fHt6QXfLrv06skzIMqx+Ver3j7 Fwt4haiZcBVZBXHHQSR8uIm8zy7aMoirr2eY8Q0alZNhubZJa+iDea5febLfJ54il/jQY0RYMh4W owuvcyV1xD9pxoVMGwEVJPZ9oRSwQ7lmkLKm8Wu91x+bLudomTYEyLaHo7cU45x29OtFJcV4SWUK +ybaojapteaKAXmlZn0pzXKr76qlk0eyh6z42V7jt24HR8J2vCIQkRkvc7nixNEQQ7XFQ29+6Vpl ApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSl ApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU/ UBka6nB7WuLSL7/d5qvx8vm7/B+bvfs82gjPm/xeP+7Wv5ta4/xdcPweHyFfztNYrdvZ18kCe7Xu B9Pgnu1r+DWtDrgNg+b/ABeP+7Wv5ta4/wAXXD8Hh8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64C H5c0pSg/Sa9/fx6Y/wApf/uh+tfxWwWbFsdhY9j1uZt1rgtdqPHaT2QT3qqqvmRKqqqkqqpKqqqq qqtZBe/v49Mf5S//AHQ/W5UEZitgs2LY7Cx7HrczbrXBa7UeO0nsgnvVVVfMiVVVVJVVSVVVVVVV a7Z8SLPgyIM6MzKiSWiZfYebQ23QJNEBCvkQqiqiovkqLXtSgr9swjC7XOgTrZiGPwpduaJmC/Ht rLbkUCU1IGyEUUBVXHFVB0iqZfSWlnwjC7NBuEG0Yhj9uiXJrsz2IttZablBok4OiIohjoyTRbTR L8VqwUoKzE6e4DDtc61xMHxmPAuHb8bFatTAtSe2XJvuAg6PiSqqbRdL5pXbbcTxW2zBmW7GrLDk h2uL0eC02Y9pkmWtEIoqcGjNsfogRCmkVUqZpQV+z4RhdmeiPWfEMftzsN116KcW2stEwboCDhgo inEjARElTSqgoi7REpjeEYXjU452OYhj9mluNKyb8C2sx3CBVRVBSAUVR2Irr3bRPhVgpQeM9lyT BkR2Zb0N11ogCQygK4yqppDFDEhUk96chJNp5oqeVVnpf09xrp1jrVnx6EyJC0DT81YjDUmWgcuC vEy2COEKEqISptfNVVSUlW2UoK+7hGFuvOPO4hj7jrrsl5wytrKkZyQQJBqvHzJ0EQTX3miaLaUs +EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdGSaLaaJfitWClBU5HTLptJZjMyOnuJPNRWlZ jg5Zo5CyCmRqAIoeyPMzLSeWyJfeq1M2fHrBZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La 7JfitSdKCGi4nisW6BdI2NWVie3JflhKbgtC6L74oLzqGg7Q3BFEIt7JERFVdV7WfHrBZp1wnWix 2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitSdKCMs+PWCzTrhOtFjtlul3J3vT34sQGnJR7Jeb pCiKZbMl2W12S/Fa4rPhGF2aDcINoxDH7dEuTXZnsRbay03KDRJwdERRDHRkmi2miX4rVgpQV+2Y RhdrnQJ1sxDH4Uu3NEzBfj21ltyKBKakDZCKKAqrjiqg6RVMvpLVgpSgUpSghs0yFnF7AV3egTbh /lMaK1Gh9vuuuyH22GxHuGAJs3R2pEiIm1qs/dInfm5yb+sbP+vV2dZP9EYP+0li/vaJVNoLN90i d+bnJv6xs/69T7pE783OTf1jZ/16qzSgs33SJ35ucm/rGz/r1PukTvzc5N/WNn/XqrNKCzfdInfm 5yb+sbP+vU+6RO/Nzk39Y2f9eqs0oLN90id+bnJv6xs/69T7pE783OTf1jZ/16qzSgs33SJ35ucm /rGz/r1VnL/2QuP4hcrdAyXEcogPXFHFjILlukckbRFJV7Ms1H3pret+et6XSvnH9ld98HDf5NK/ 9Eqq3rmizqqjfES3aMu9F5vtjY1/w1VUxP5TMRL7I6XZ7Z+omPv3uyRp8eOxKKKQzAATUxACVUQS JNaNP3/jVrrC/wBhN96q5/8Afjv/ALDFbpUbtaTaWVNdW+V+nLpZ3PSFrYWX8NM4QUpSr3lFKUoF KUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoF QGRrqcHta4tIvv8Ad5qvx8vm7/B+bvfs82p+oDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tBGfN/i8 f92tfza1x/i64fg8PkK/naaxW7ezr5IE92vcD6fBPdrX8GtaHXAbB83+Lx/3a1/NrXH+Lrh+Dw+Q r+dprFbt7OvkgT3a9wPp8E92tfwa1odcBD8uaUpQfpNe/v49Mf5S/wD3Q/W5Vht7+/j0x/lL/wDd D9aZb8kekX/LBcZ/+k4/2YxdqO47Kck9hJL3EA5KYdp+MgII81NHU0qcNhZqVmeK9acYv3pV4YU2 LAtFteuU6eEyDOjsNNaUhNYUh9QNRUiESRFNG3OO+KpXtg/WDHMwnTrZZ4jz10jQXJrUFm5W6W5J AFESQSjSXG2y5G2Kd4m0VT8lVBNRDRqVTOnednk+DsZZeMdm4tActrNxWRcZcYo5NG13CMTbcVUA R81J0W10qLxT2kH3Z6mdPJMG5TIObY/cWrXBduE0YE9uU4zHaTbjig0pEop5e5F81RPeqUFspWc4 P1gxzMJ062WeI89dI0Fya1BZuVuluSQBREkEo0lxtsuRtineJtFU/JVQTUZPGOoUPJfEeg7Depnh baMuTrw49iUu921zk6nCaOvbbLQt7HmQ8h2FzpVGwrqIN66dLnF+xu54xa27Q3dnHpTrEhs2SZV0 ya7Bm4QiKb9sAJUVNDvaJxYP1gxzMJ062WeI89dI0Fya1BZuVuluSQBREkEo0lxtsuRtineJtFU/ JVQTUQ0alUbEOpduyiDGlW7H8gaW4WgrtamZTDTLlxZBG+4jSE57JCbzQbdVsTU0Jsjb2ae3TvOz yfB2MsvGOzcWgOW1m4rIuMuMUcmja7hGJtuKqAI+ak6La6VF4p7SCFzpWc5n1QsB4Fk9zwHMcSvF 6s1okXQY7csJoqDI8y5ttOiSCvzOW0QVMV8/mrJh1FtTHjXL5ar1j8aPbZF2ZfuMcU8VCj8O88Lb ZG6HBHGlVt0G3PlEThsTQQudKzPFet2E330rykeB9F2166SP8uhzv8lZ13nP8iff48eQeyfEi5ew hcS4zNqz05eX2/FZuG5NablNjSJieMCMrTUdlWxVwnWnzAtm6AIAKRoqopiAEJEFzpVTxHK5t7iZ K+7YLnGl2ecsZLU6EcZO/CMPo2hhINkyLvIqFzBE5IJInFSLixDqhYMigxrg5DudjgTLQV4iSru2 Edt+K2jffc+eqgLSvNoROIAkhITauB7dBeaVU2epnTyTBuUyDm2P3Fq1wXbhNGBPblOMx2k244oN KRKKeXuRfNUT3qleFqz05eX2/FZuG5NablNjSJieMCMrTUdlWxVwnWnzAtm6AIAKRoqopiAEJEFz pVTxe/3mVJzVidGZuDtiu5RoTUBnsuPsrDjSW217rqirvy6hyUgFVRF0CKuoux9Tm7z6v+AwvJj9 P2R69weRQh2w3x9ktyfIy7sfinu+XDko8XOAaBSqNiHUOLmkGMlmgXOzv3e0FcrM/d4SduQCI2hn 2gdQ1Fo32UJCVtHEJFaIw9tPDpH1F9cbHj5XK1TbdcrrZG7m2bkftR5fEWUkqwKkTgg2482KK6g8 0MSbVwPboO3rJ/ojB/2ksX97RKptXLrJ/ojB/wBpLF/e0SqbQKUpQKh73ktqtEoYkrxz0ggRxWoV vkSzAFVUEjRkDUEVRJEUtcuJa3xXUxVeu1kvHp929WC7QYUiTFaiyRmwDlAQNG6TaggOtqK7ec3t S37OuOl5By3vNoNnuLDkoWnLE9Z3roNyimcheDTjIl8m2Bbb4vgfcQl8kJVRETlVitU5i5QG5scJ QNOb4jJiuR3E0qp5tuCJj7v30TaaVPJUqlXXprHlt2WO1cGhZx+z+Cs5vxEdfjSkJkm5anyQSUPD t+wgohbNFVRLjV1tQXBuA2F0kxZUxN9x2NHJhsvNdaAjNU8tJ85dqir5b0gdNKUoFfOP7K774OG/ yaV/6JX0dXzj+yu++Dhv8mlf+iVRev8AYr/Kf6PU0H/2d2/no/8AaG//ALCb71Vz/wC/Hf8A2GK3 SsL/AGE33qrn/wB+O/8AsMVulQuP/Ho/Jr+1H/b3j+YpSlangFKUoFKUoFKUoFKUoFKUoFKUoFKU oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFQGRrqcHta4tIvv93mq/Hy+ bv8AB+bvfs82p+oDI11OD2tcWkX3+7zVfj5fN3+D83e/Z5tBGfN/i8f92tfza1x/i64fg8PkK/na axW7ezr5IE92vcD6fBPdrX8GtaHXAbB83+Lx/wB2tfza1x/i64fg8PkK/naaxW7ezr5IE92vcD6f BPdrX8GtaHXAQ/LmlKUH6TXv7+PTH+Uv/wB0P1oyYrKW45oyNxeh27JWm3kkw31bnRpSx/Cum2XH iAo0zFJtfaJHO6q+XFEzm9/fx6Y/yl/+6H63KgpgdPYcvxvrRfr1lXi7bItf/wBR8Oz2osjh4hsf CtM/unba2RbJOCcVHZcpPG7BdrVOOROzfIL80TSgkeezBBsV2i80ViM2XJNKnmSpol8t6VLBSgrO G4czi/bZi3y9S4ESMkO2wJLrfh4EdOKI2CNgKuaEAFDeV00QV0Sc3FOZv1rgXyxz7JdGPEQLhGci ymuZD3GnBUTHYqipsVVNoqL8K7aUFZtWM3qH4vxHULJrj34xst+Jj24fDmWtPB24obMdeSHyDzXY r5V44VgduxGcsi03O59p2C3HmR3SaVubIBVUp7yo2hHLc3px3knNEHkiqIqlspQUy1dOrVEscvHp d1vVzsDttO0x7VJkCEeJCMUBWQ7IgZ+wIijjpOOCgro0UzUu21Yzeofi/EdQsmuPfjGy34mPbh8O Za08Hbihsx15IfIPNdivlVmpQUbFOm8fHZ2LyI2U5BJaxu0OWeJHkJEVt2OagunFFgSUk7LCIokP kyO9qTinJ4bhzOL9tmLfL1LgRIyQ7bAkut+HgR04ojYI2Aq5oQAUN5XTRBXRJzcU7NSghs5x5nLM QuuMyZ82BGukY4sh6H2+6jRpoxFXAMU5Cqiq8VVEJVTS6VIUOnVqf8a3fLresgjSLbItLLFxkCvh YUjh3mRcbEHT5o20iuOm458mi89kalc6UFTZwt9+DcrZkeYZBk1ruUF2FJgz24bTag4nElQo0dpx C48h+drRL5b0qV/p9h+ZR84byrM7p4qTFtsi3sJ6USX3AedYcX2QiRWmuCx/ejZm53faNEaBK0yl BTMZwWXY5l8lhneTTXr1tyQUlqB8nI7LTIyAQIwohi2y2KCuw8lVQJV3XjinTePjs7F5EbKcgktY 3aHLPEjyEiK27HNQXTiiwJKSdlhEUSHyZHe1JxTvNKDiv1rgXyxz7JdGPEQLhGciymuZD3GnBUTH YqipsVVNoqL8KoHT7D8yj5w3lWZ3TxUmLbZFvYT0okvuA86w4vshEitNcFj+9GzNzu+0aI0CVplK Cp4Xhb+NXm63M8wyC8ldXUflMz24aNk8jbTSOp2Y7ZISNsAGkXjraqKku6i+neLXvH/Wq9S7TZWL xdJJuQoca6PPRwa9t5GjeNkSTlLkTXVJGiUUfQU5CACmgUoMz6TdObvjuIWhjIsjmyL/AG6yLZor 0d1hxq2tKjaEsdfDN8+XYYL5cHVFW0HZJzU5PFOm8fHZ2LyI2U5BJaxu0OWeJHkJEVt2OagunFFg SUk7LCIokPkyO9qTineaUFM6yf6Iwf8AaSxf3tEqm1eerlkv9/wZ6DizlsbvTU6DNhrclNI3ONMZ kac7aKXFe0qeXn5+9PemJ/c+/ZN/j7pl9b+yoLnSqZ9z79k3+PumX1v7Kn3Pv2Tf4+6ZfW/sqC50 qmfc+/ZN/j7pl9b+yp9z79k3+PumX1v7KgudKpn3Pv2Tf4+6ZfW/sqfc+/ZN/j7pl9b+yoLnSqZ9 z79k3+PumX1v7Kn3Pv2Tf4+6ZfW/sqC5184/srvvg4b/ACaV/wCiVrf3Pv2Tf4+6ZfW/sqq+V/se +t2Y361XPJr3gS+jhdBvwj0oFVDT99FZ0vmifD9+qbxTNVlVEb5if6PR0Ra0WN/sLSucKYrpmZ5R Exi0z9hN96q5/wDfjv8A7DFbpWbfseMCvHTvCplkvcmBIkP3E5QlDMyBAJtsURVIRXewX974VpNR ulE0WNNNW9o+0N4s7xpO2tbKcaZnZJSlK0PGKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQ KUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKgMjXU4Pa1xaRff7vNV+Pl83f4Pzd79nm1P1 AZGupwe1ri0i+/3ear8fL5u/wfm737PNoIz5v8Xj/u1r+bWuP8XXD8Hh8hX87TWK3b2dfJAnu17g fT4J7ta/g1rQ64DYPm/xeP8Au1r+bWuP8XXD8Hh8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64CH5 c0pSg/Sa9/fx6Y/yl/8Auh+tyrDb39/Hpj/KX/7ofrcqDLMnyS/222dWsotkxlJeMtAxBiywN2Io R4Dc0iVsTFUdcWU42piSJxbZ9leC8uO49UMlsM24+sNsx9qJbZ0iBIcalP8AHvDaSuiEqo0RI022 KMqSAZOqSuIDXFGTv83DrBPnXl65wGbhEvLUYZ1ulsg7EdNhSUXlaIdE6qK2KmW1UWGU8uCV723E 8VtswZluxqyw5Idri9HgtNmPaZJlrRCKKnBozbH6IEQppFVKDP8ACcvyy75xJ6f5xbfBvTbI/PAo 4NQJDTQutsrpI8+Uac1eXi5yaUVaLjzXat1nph1CzhOl7+TXQ4TltxrEYtwegXCMfpW5klvV1X0k pIMOy6Y7F5W1IlR5sgE2lJdZi9PcBixwjxsHxlhlvv8ABtu1MCI99tGntIg6TuNigF9IURF2iart ZxPFWLpb7ozjVlan2yMkSBKCC0jsRhBIUaaNB2AIJEnEVRNEqa81oKlg9/6nOTpwZXh7xRG4Lj7D rMaJDcJ4FHjHEEuElDJxCJUIiaEFb0qlz2Hbd88u1sxXIb9O6fZBbWrNaJNyRZ8qCjchWQU+yisP vEJFpfNQ0iIv7+kWZxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwqwUGc4Pd+qk +dOg5HYWbc0cFw4lyegMMtsSEUUACZZuMgnhLkRL7TPFGtbVTRQ8emWY5VmvpD5Wy27wNtaY9uC6 fipxc/8AL4/yydy2Hx+RLyJ3i57QcPOzWrp7gNp8X6LwfGYHjIxxJXhrUw332D1zaPiKcgLSbFdo uk2lScDHrBAnR50Gx2yLLjQRtzD7MQAcaiiuxjiSJsWkVEVAT2UVPdQZzhubZJa+iDea5febLfJ5 4il/jQY0RYMh4WowuvcyV1xD9pxoVMGwEVJPZ9oRSTwe79VJ86dByOws25o4LhxLk9AYZbYkIooA EyzcZBPCXIiX2meKNa2qmihc7Pj1gs064TrRY7Zbpdyd709+LEBpyUeyXm6QoimWzJdltdkvxWoy 1dPcBtPi/ReD4zA8ZGOJK8NamG++weubR8RTkBaTYrtF0m0oKl04zPNMgg46l3HH4svKcWcvUBYs d424JtpFH5Xk4iviayxPiPbVtAUObm0dqT6JXnJLpg+Oz8vyOy3GfebJFuMZmNAWJI4q02rxmivG juidaRSAGxFST2U5CiWC2YRhdrnQJ1sxDH4Uu3NEzBfj21ltyKBKakDZCKKAqrjiqg6RVMvpLXbZ 8esFmnXCdaLHbLdLuTvenvxYgNOSj2S83SFEUy2ZLstrsl+K0EnVMx6TdbplefGzcOy9Akx7TAbd EnYrPGE1JR4mkIVI1cmkh8SHkDTQ+SipLc6hlx5lu6Xq5QZ82BJu8Zpp1WO3xadbExSSAECiryiQ CpGhIosMiqaDShmVk6pZVEweHlGTW2yyfSGESspjxLcrrXZ8K1GImicNS593xIkmgHtcVHb3z6ud kumVW/OIeM5NPst09I22VOjyLdbXYXY8O7GAgITfe7nPxQqiooce2vkXL2ffpf09xrp1jrVnx6Ey JC0DT81YjDUmWgcuCvEy2COEKEqISptfNVVSUlWTxjE8VxfxHqzjVlsniePiPR0FqP3eO+PLgKct ci1v3bX40FfwCXkstc3t9xuNsdvFvu6RWZjUR8Y2yt8R0CWO5INRFFd0oA4CFpS9kiIlhenGZ5pk EHHUu44/Fl5Tizl6gLFjvG3BNtIo/K8nEV8TWWJ8R7atoChzc2jtW21dPcBtPi/ReD4zA8ZGOJK8 NamG++weubR8RTkBaTYrtF0m0r2tmEYXa50CdbMQx+FLtzRMwX49tZbcigSmpA2QiigKq44qoOkV TL6S0Ff6JXnJLpg+Oz8vyOy3GfebJFuMZmNAWJI4q02rxmivGjuidaRSAGxFST2U5CiSnSOXKlYM yzMkvS3bdOnWoZL7im8+EOY9FB10l+c6QMiRl5IpKSoiIukmbPj1gs064TrRY7Zbpdyd709+LEBp yUeyXm6QoimWzJdltdkvxWmK2SLjmOwrLDceeaitcSffVCekGvmbzpIic3XDUjM9bIiIl81oJOqZ j0m63TK8+Nm4dl6BJj2mA26JOxWeMJqSjxNIQqRq5NJD4kPIGmh8lFSW51DLjzLd0vVygz5sCTd4 zTTqsdvi062JikkAIFFXlEgFSNCRRYZFU0GlDMrJ1SyqJg8PKMmttlk+kMIlZTHiW5XWuz4VqMRN E4alz7viRJNAPa4qO3vn1c7JdMqt+cQ8ZyafZbp6RtsqdHkW62uwux4d2MBAQm+93OfihVFRQ49t fIuXs+/S/p7jXTrHWrPj0JkSFoGn5qxGGpMtA5cFeJlsEcIUJUQlTa+aqqkpKsnjGJ4ri/iPVnGr LZPE8fEejoLUfu8d8eXAU5a5Frfu2vxoK/gEvJZa5vb7jcbY7eLfd0iszGoj4xtlb4joEsdyQaiK K7pQBwELSl7JERLC9OMzzTIIOOpdxx+LLynFnL1AWLHeNuCbaRR+V5OIr4mssT4j21bQFDm5tHat tq6e4DafF+i8HxmB4yMcSV4a1MN99g9c2j4inIC0mxXaLpNpXtbMIwu1zoE62Yhj8KXbmiZgvx7a y25FAlNSBshFFAVVxxVQdIqmX0loK/0SvOSXTB8dn5fkdluM+82SLcYzMaAsSRxVptXjNFeNHdE6 0ikANiKknspyFElOkcuVKwZlmZJelu26dOtQyX3FN58Icx6KDrpL850gZEjLyRSUlRERdJM2fHrB Zp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitMVskXHMdhWWG4881Fa4k++qE9INfM3n SRE5uuGpGZ62RERL5rQQ3SOXKlYMyzMkvS3bdOnWoZL7im8+EOY9FB10l+c6QMiRl5IpKSoiIukt lRmK2SLjmOwrLDceeaitcSffVCekGvmbzpIic3XDUjM9bIiIl81qToFKUoFKUoFKUoFKUoFKUoFK UoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFQ GRrqcHta4tIvv93mq/Hy+bv8H5u9+zzan6gMjXU4Pa1xaRff7vNV+Pl83f4Pzd79nm0EZ83+Lx/3 a1/NrXH+Lrh+Dw+Qr+dprFbt7OvkgT3a9wPp8E92tfwa1odcBsHzf4vH/drX82tcf4uuH4PD5Cv5 2msVu3s6+SBPdr3A+nwT3a1/BrWh1wEPy5pSlB+k17+/j0x/lL/90P1uVYbe/v49Mf5S/wD3Q/W5 UFGtt4lDfeot3kTGQasjrMCOzMmrHgtg1Balq64SoXaIjmGLjqIqdtpr2VUF5VJnqF1BsHpqXmlp hNswMbuF5jwjgBDkSyi9pVQHGZswEBEcQS58CRTbUEcTnw01cZtRXS9THme+ze4zUefBdESivcBM FcJtU0Rm2Ytmpb5Ay0PuBKYxieK4v4j1Zxqy2TxPHxHo6C1H7vHfHlwFOWuRa37tr8aCpYPd+qk+ dOg5HYWbc0cFw4lyegMMtsSEUUACZZuMgnhLkRL7TPFGtbVTRQjMNzbJLX0QbzXL7zZb5PPEUv8A GgxoiwZDwtRhde5krriH7TjQqYNgIqSez7Qil5xvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKK o7EV17tonwrts+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W12S/FaCmW2/5pG6s2rCb xeMSnNPWiXdpRwoLzEngDjLLbfZJ8+0Km6RI6pGh8DBABQUy0CeMo4MgILzLEsmiRh15pXWwPXsk QIQqQoulUUIVVPLae+qlaum+PWXL7fkGOj6BZhRpEf0TbIcViE931bV1xwRZ5qaqxH80NP3EE9yk hW2ey5JgyI7Mt6G660QBIZQFcZVU0hihiQqSe9OQkm080VPKgwa/ZvmF56MSZl8chQJN86fzclgO WN+TGdgOxWo5pt5D5HzKQB8UQEBAJslfRVNb/ZMhyqTfIdrk3LGZXp+ySrraZVujOuR4faKMIiRq 7/lgF4sFRwUj7RtV4p3E4e+FdJ8FxbClxNnH7ZcYLrTbUw5ttiq5PRolJpZHbaAXSDfkRCq7Taqp KpLZrPj1gs064TrRY7Zbpdyd709+LEBpyUeyXm6QoimWzJdltdkvxWgz/Dc8v+RzsSghOx9iXkGC LfnWEimbkOVuMgOKPeRSjksg0QF4kqslpxfPj29ILvl136dWSZkGVY/KvV7x9i4W8QtRMuAqsgrj joJI+XETeZ5dtGURV17PMeNti4nisW6BdI2NWVie3JflhKbgtC6L74oLzqGg7Q3BFEIt7JERFVdV 7WfHrBZp1wnWix2y3S7k73p78WIDTko9kvN0hRFMtmS7La7JfitBnOG5tklr6IN5rl95st8nniKX +NBjRFgyHhajC69zJXXEP2nGhUwbARUk9n2hFLBDuWaQsqbxa73XH5su52iZNgTItoejtxTjnHb0 60UlxXhJZQr7JtqiNqm15ooWaz49YLNOuE60WO2W6Xcne9PfixAaclHsl5ukKIplsyXZbXZL8Vri s+EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdGSaLaaJfitBU+lOa5VffVUsmj2UPWfGyvcd u3A6PhO14RCEiMl7nc8WJoiCHa4qG3v3StMqv2zCMLtc6BOtmIY/Cl25omYL8e2stuRQJTUgbIRR QFVccVUHSKpl9JasFBlmT5Jf7bbOrWUWyYykvGWgYgxZYG7EUI8BuaRK2JiqOuLKcbUxJE4ts+yv BeXHceqGS2GbcfWG2Y+1Ets6RAkONSn+PeG0ldEJVRoiRptsUZUkAydUlcQGuKMnf5uHWCfOvL1z gM3CJeWowzrdLZB2I6bCkovK0Q6J1UVsVMtqosMp5cEr3tuJ4rbZgzLdjVlhyQ7XF6PBabMe0yTL WiEUVODRm2P0QIhTSKqUGf4Tl+WXfOJPT/OLb4N6bZH54FHBqBIaaF1tldJHnyjTmry8XOTSirRc ea7Vus9MOoWcJ0vfya6HCctuNYjFuD0C4Rj9K3Mkt6uq+klJBh2XTHYvK2pEqPNkAm0pLrMXp7gM WOEeNg+MsMt9/g23amBEe+2jT2kQdJ3GxQC+kKIi7RNV2s4nirF0t90ZxqytT7ZGSJAlBBaR2Iwg kKNNGg7AEEiTiKomiVNea0FSwe/9TnJ04Mrw94ojcFx9h1mNEhuE8CjxjiCXCShk4hEqERNCCt6V S57Dtu+eXa2YrkN+ndPsgtrVmtEm5Is+VBRuQrIKfZRWH3iEi0vmoaREX9/SLM43hGF41OOdjmIY /ZpbjSsm/AtrMdwgVUVQUgFFUdiK6920T4VYKDObbf8ANI3Vm1YTeLxiU5p60S7tKOFBeYk8AcZZ bb7JPn2hU3SJHVI0PgYIAKCmXbg6XFbr1HgxLk8rrGQKMAp7rstuMrlthPaQScQu0jrpl2xIURCV B4prTp30wsWEzlmQJL0l0WnWmBWFCiNsI6rSvKgRGGRIj7DGyNCVEaFBUUUtzON4RheNTjnY5iGP 2aW40rJvwLazHcIFVFUFIBRVHYiuvdtE+FBRsEy3PsmuFst6XHGWpLVkkPZAA2d9fAXFJDsdpkVW VpwEdZkCSjy5eDNUIUfbUfbpxlmS5VBx2LljNsaay7FnLs0NoN9hyGgJFE073PkpOeLQxUEbVlQU UJ1dOVbcZxI7Hb740GS3qbPvUlZUi5yRjeIbd8O0wJAIMi0nEGW9IraptF3y3quLp70yw/CcQLGb baIUiM/GSLOekQYwu3BpEJBGQrTYC9oTIdkKqqKqltVJVCs9DMmyqRY8GtuTPQpnpvERucd5snTk N9gYgEr7pr8sb3ihcVUEO2okO3d9ytZqv2zCMLtc6BOtmIY/Cl25omYL8e2stuRQJTUgbIRRQFVc cVUHSKpl9JasFApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlApS lApSlApSlApSlApSlApSlApSlApSlApSlApSlApSlAqAyNdTg9rXFpF9/u81X4+Xzd/g/N3v2ebU /UBka6nB7WuLSL7/AHear8fL5u/wfm737PNoIz5v8Xj/ALta/m1rj/F1w/B4fIV/O01it29nXyQJ 7te4H0+Ce7Wv4Na0OuA2D5v8Xj/u1r+bWuP8XXD8Hh8hX87TWK3b2dfJAnu17gfT4J7ta/g1rQ64 CH5c0pSg/Sa9/fx6Y/yl/wDuh+tyrDb39/Hpj/KX/wC6H63KgUpSgUpSgUpSgUpSgUpSgUpSgUpS gVidxZkJ0D6m5CN5yAboruQutyEvUtCjrDmzEjoync0yIo2CKLaChIKISEnlW2VU7TgVoi2682i5 vvZBZbrOemla7tHjPRmDdkOSTQERoSIVdc5J3FNU4jpU15hF2TIcqk3yHa5NyxmV6fskq62mVboz rkeH2ijCIkau/wCWAXiwVHBSPtG1XincThGYbnl/yOdiUEJ2PsS8gwRb86wkUzchytxkBxR7yKUc lkGiAvElVktOL58dAs+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W12S/Fa8YuJ4rFug XSNjVlYntyX5YSm4LQui++KC86hoO0NwRRCLeyRERVXVBUukF3y679OrJMyDKsflXq94+xcLeIWo mXAVWQVxx0EkfLiJvM8u2jKIq69nmPGMw3NsktfRBvNcvvNlvk88RS/xoMaIsGQ8LUYXXuZK64h+ 040KmDYCKkns+0Ipo1nx6wWadcJ1osdst0u5O96e/FiA05KPZLzdIURTLZkuy2uyX4rSz49YLNOu E60WO2W6Xcne9PfixAaclHsl5ukKIplsyXZbXZL8VoKzDuWaQsqbxa73XH5su52iZNgTItoejtxT jnHb060UlxXhJZQr7JtqiNqm15ooRnSnNcqvvqqWTR7KHrPjZXuO3bgdHwna8IhCRGS9zueLE0RB DtcVDb37pVss+EYXZoNwg2jEMft0S5NdmexFtrLTcoNEnB0RFEMdGSaLaaJfitLZhGF2udAnWzEM fhS7c0TMF+PbWW3IoEpqQNkIooCquOKqDpFUy+ktBYKqeH3S/wB5g5OD15xKRLiXeXDtztrI5LcU BQe0EwFMV8QKrtxsSFNaRFTe6tlcVqtNqtPi/RdshQPGSTlyvDMC333z1zdPiicjLSbJdquk2tBk 3STqTlWY3/GYcp+ygzKsjk67A1anWy7/AGIEgAYNZJIgdu6MIqkKqpMOaREMeE1bcqveP4t1NvF/ WFd5uLyXnl8GL0VqSLdriyUEQdde7O+fFeC8dop8eRFu/wAC02q3yH5EC2Qoj0jfecYYECc2446v JUTa/KPOn5/hOGvvJVWMxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwoKNGezBn rfGs1wyiyyZ72Iz3wGIElqOBJJiCw49bykGnskT2nRcEnEIw9ntISyfSC4X/ACHp1ZDzXJrZPl5D j7ExlqBGO3y0AmQ75qYPqpEivNJ3GhaQCJFRE5CiWaz4RhdmeiPWfEMftzsN116KcW2stEwboCDh goinEjARElTSqgoi7REr3jYnisb0v4bGrKz6b5elu3BaHx/Lly7+h+V3zPfLe+ZfFaDP+hmTZVIs eDW3JnoUz03iI3OO82TpyG+wMQCV901+WN7xQuKqCHbUSHbu+5Ws1X7ZhGF2udAnWzEMfhS7c0TM F+PbWW3IoEpqQNkIooCquOKqDpFUy+ktWCgyA7nkWN4B1lkpk9zutxsLsl23zp4sk40o2aI+CIAN i0goZKvFARFVVVUVVJVn7VbgxfqnabJa7henYFzslwlSmrjd5M/bsd+ELRCshw1b0Mh5FQFFC5Jy 3xHVgxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwr3xjE8VxfxHqzjVlsniePiP R0FqP3eO+PLgKctci1v3bX40EzVTw+bccjg5PDvV1x+Y01d5dvYLHprqOR46IKC2+aEhNSx5Ly4K PFVFU0tWyoxnHrAzBuUFmx2xuJdXXXriwEQEbmG6mnTdFE04Rp5EpbUk9+6DH8H6h5Vj/SyyXTJm oV37nT97IY4tvOpIXwTEXkj758u6b/iBNSQB7SoQ/Lb51c+nF56lTL49EzHG/CwFjE43N8LHicHR IURrttz5aucxIi5fJoHb17fNONgtmEYXa50CdbMQx+FLtzRMwX49tZbcigSmpA2QiigKq44qoOkV TL6S0xvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwoKnbcqveP4t1NvF/WFd5uLy Xnl8GL0VqSLdriyUEQdde7O+fFeC8dop8eRFs3dswc6lwunt+vWMzI02yTbjNdtkeTDmo0JssNgI pJIo/tOkSPoZKXAhEW1DmVsxvCMLxqcc7HMQx+zS3GlZN+BbWY7hAqoqgpAKKo7EV17tonwqv4T0 lxjGPEin/wBTZfjPxfDSLdBjxxaf7fiBVqLHZBzuIwyhK4JrpoUTSKSEEB0byTNJeK4darvMtjsu +Yb6SgSyB6Q4wbARA5ySIxWSTqyhcVB7SgokHJzaOJP9Erzkl0wfHZ+X5HZbjPvNki3GMzGgLEkc VabV4zRXjR3ROtIpADYipJ7KchRLBbMIwu1zoE62Yhj8KXbmiZgvx7ay25FAlNSBshFFAVVxxVQd IqmX0lrts+PWCzTrhOtFjtlul3J3vT34sQGnJR7JebpCiKZbMl2W12S/FaD2vzrLFjnvSLp6IZbj OE5P5Nj4QUFVV3biKCcU9rZoo+XmiptKqfS+OUaddUZnXNq3vNR3oVqu1wflz2QVXU8W6sgyeZF/ joWSXQowqqguG62FznxIs+DIgzozMqJJaJl9h5tDbdAk0QEK+RCqKqKi+SotRmMYniuL+I9Wcast k8Tx8R6OgtR+7x3x5cBTlrkWt+7a/GgmaUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQKUpQ KUpQKUpQKUpQKUpQKUpQKUpQKUpQKgMjXU4Pa1xaRff7vNV+Pl83f4Pzd79nm1P1XcmdUbgKa8ga BVInRBBVSXXmRp5+yq+Wvmp574kAR/zf4vH/AHa1/NrXH+Lrh+Dw+Qr+dprFbt7OvkgT3a9wPp8E 92tfwa1odcBmhkCmvNkda90tjy+b8DT3a/e181NcfY7VNu+QQL7juXMQW3RK0ygt8hSQeJOpGJxe Cj7xRHRHfl5iukQeKIH5o0pSg/Sa9/fx6Y/yl/8Auh+tyrB8okDF609MXibNz/LHAQQ1tVK1PCnv VE96p+/Wv+scP6H1qP8AaUEzSob1jh/Q+tR/tKescP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2 lBM0qG9Y4f0PrUf7SnrHD+h9aj/aUEzSob1jh/Q+tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/tKes cP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2lBM0qG9Y4f0PrUf7SnrHD+h9aj/aUEzSob1jh/Q+ tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/tKescP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2lBM0 qG9Y4f0PrUf7SnrHD+h9aj/aUEzVTw+6X+8wcnB684lIlxLvLh2521kcluKAoPaCYCmK+IFV242J CmtIipvdSfrHD+h9aj/aVGMribMG5QWbBbG4l1ddeuLAJERuYbqadN0UPThGnkSltST37oKLgL2T 2u0ZX1KyvKIVyCF6ZZOPwnRo4JDlutiXBJDzTYIEbXycZXdL5k4XNXPGN1VzCwzr/BzOwslLt2LT ciZYRqPCcUIygnBRamzF4uKaohl20FWy0jm14XPG7V0/xqcc7HMNx+zS3GlZN+BHgx3CBVRVBSAk VR2Irr3bRPhSz2rp/Znoj1nw3H7c7DddeinFjwWiYN0BBwwUSTiRgIiSppVQURdoiUHFfckzTDYN 3uWRzMSvMS3Y/PuwNQgegS5Jx0bJGxZM3kRoUUkN3mS8nmk4Dx257dOLz1KmXx6JmON+FgLGJxub 4WPE4OiQojXbbny1c5iRFy+TQO3r2+ace3GIuE4v4j1Zxay2TxPHxHo5qHH7vHfHlwNOWuRa37tr 8a8cbtXT/Gpxzscw3H7NLcaVk34EeDHcIFVFUFICRVHYiuvdtE+FBJ9Vrzdcd6aZJkVkKEM+1W1+ c0kxgnWj7IK4oEImC+0IqKKheSqi6XWlz/IOq+VYyl4kXuw2V9m0SZUN1uHMdQnnwtB3VEEiDQgD YIwpKiq6Rq7xZQO0egXuZj18tb1rvdphXOA/x7sWYcV5pziSEnICNUXRIiptPeiLXFbYuE22YMy3 YtZYckO1xejtQ2zHtMky1ohNFTg0Ztj9ECIU0iqlBDZBmOVYP6S9ZnbLkHZxu532P6Ogu2/j4Hsc mi5vP8u54gdEnHhwXyPl7NfyPJclw7qLNn3+72y9u23BLtd3INtffhNuow9GVruRDdeFsv3YRkIq qaGYqKI0nK84xFwnF/EerOLWWyeJ4+I9HNQ4/d4748uBpy1yLW/dtfjXjZ7V0/sz0R6z4bj9udhu uvRTix4LRMG6Ag4YKJJxIwERJU0qoKIu0RKDw6cXnqVMvj0TMcb8LAWMTjc3wseJwdEhRGu23Plq 5zEiLl8mgdvXt8049vTgnhyPqBEOZNkMxskRI4yZTj/ZFy3QniAFMlUQ7jrhICaEeSoiInlXjjdq 6f41OOdjmG4/ZpbjSsm/AjwY7hAqoqgpASKo7EV17tonwpjdq6f41OOdjmG4/ZpbjSsm/AjwY7hA qoqgpASKo7EV17tonwoGAS8llrm9vuNxtjt4t93SKzMaiPjG2VviOgSx3JBqIorulAHAQtKXskRE tSsnVLKomDw8oya22WT6QwiVlMeJblda7PhWoxE0ThqXPu+JEk0A9rio7e+fVntWP9NLT4v0XgmM wPGRjiSvDQ4DffYPXNo+JJyAtJsV2i6TaV7Wy1dP7XOgTrZhuPwpduaJmC/HjwW3IoEpqQNkJIoC quOKqDpFUy+ktBxYPf8Aqc5OnBleHvFEbguPsOsxokNwngUeMcQS4SUMnEIlQiJoQVvSqXPYMzzj KoWBZPeoeFXOwS7RaJFyYfvaQ5EZ1WR5qyoRZZOciFCRF8kH3rvSCXbjdq6f41OOdjmG4/ZpbjSs m/AjwY7hAqoqgpASKo7EV17tonwqTvczHr5a3rXe7TCucB/j3Ysw4rzTnEkJOQEaouiRFTae9EWg z/IOq+VYyl4kXuw2V9m0SZUN1uHMdQnnwtB3VEEiDQgDYIwpKiq6Rq7xZQO0dth3LNIWVN4td7rj 82Xc7RMmwJkW0PR24pxzjt6daKS4rwksoV9k21RG1Ta80UPa2xcJtswZluxayw5Idri9HahtmPaZ JlrRCaKnBozbH6IEQppFVKYxFwnF/EerOLWWyeJ4+I9HNQ4/d4748uBpy1yLW/dtfjQVnHOpd1ne rL0yXjIelOn55NMjOuFG8K+PhlQ3HlM+3FPvuJtW1UeyS8j0op42rO89tM65nnUS2W6JFx+ddmmp Nu8I46sZWeRIcaXOTtCjuj2ImimCgLvtoNmdtXT915x53DcfcdddkvOGUeCpGckECQary8ydBEE1 95omi2le2MRcJxfxHqzi1lsniePiPRzUOP3eO+PLgactci1v3bX40GWZfnWbvY7mmKZTHetN0aw2 4X6DIhK3bpMZY3BALUa4STUSM00qk0nyRjpxCJA03Fckv72VWy23eZj9xiX20SLtAdtAH24wMnGH t94jJJQkksVF0QZTTarw9tEDiPFOlRwWoJ9OsSKIy6bzTCwLerYGaChmg70hEjYIqp5qgDv3JU1Z 1xOzTrhOtFgtlul3J3vT34qRGnJR7JebpCaKZbMl2W12S/FaCvw7+9itq6vXs1m3NmwXJ+dHiyZz h6EbVEkkyBnyVsFcNxUFE4jzXQ68q7OnF56lTL49EzHG/CwFjE43N8LHicHRIURrttz5aucxIi5f JoHb17fNOPvjdq6f41OOdjmG4/ZpbjSsm/AjwY7hAqoqgpASKo7EV17tonwpjdq6f41OOdjmG4/Z pbjSsm/AjwY7hAqoqgpASKo7EV17tonwoLzSob1jh/Q+tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/ tKescP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2lBM0qG9Y4f0PrUf7SnrHD+h9aj/aUEzSob1j h/Q+tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/tKescP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2 lBM0qG9Y4f0PrUf7SnrHD+h9aj/aUEzSob1jh/Q+tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/tKes cP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2lBM0qG9Y4f0PrUf7SnrHD+h9aj/aUEzSob1jh/Q+ tR/tKescP6H1qP8AaUEzSob1jh/Q+tR/tKescP6H1qP9pQTNKhvWOH9D61H+0p6xw/ofWo/2lBM0 qG9Y4f0PrUf7SnrHD+h9aj/aUEzVI6mDIKLJGI601IUGUacdbVwBPUjSkKEKkiLraISb+Ke+p71j h/Q+tR/tKz7qdOzW43FocSt+LvQVZBXnLpekZd7gq55CLYmnHR+9S2q/vJrahlnTi6dXbjlFwjZn acdtlpt5q13YrLqnNNR2KsqTqp29KiqSj/F1y5cJXC/9H+qX+0i/3e3Xb4bq5+Kun/8AaJz7Gozp 6NwHE+pg3UIQTkyL5cYb5PMoXo9vaCZCKkn8Ov8As2nmofAtKUoP0ZzT78vS3/vJP7tcqoeul3Yz e42Z67Y9JOLeGITNoajGE9+O8DBq+iq+Xk0LxESo2qKjBr7G1UbZnbzUfq90xffdBppu4czMyQRE UtriqqqvuRE/fqIbsdhSTd5LmUvuv3GcM9pwn44lBfFtGhNhRBFT5MRBUPmhCKoSEhmhB/MnqVj0 XLkxuSjrD5SgiI45IjiqumqCCdhXfEaIiRELtcVRUPfbXnS49Q4sKVcIh4/eHJEK4tW/tA5EQ3zc VpBNtCfRVb3IjIqrrXfDaJ7XHnumMWGcDjAZncIUNZyXBiLGlx0bYlI+j6upybUj25yLg4phs10K cQ49U/HsQm5J6deuYI+r7cg2hlgjZuArSoq/v+ZRohKiKibjhrSE6jgWL09Y/GeC9M27xXc7XZ8U HPnvXHjve9+WvjT09Y/GeC9M27xXc7XZ8UHPnvXHjve9+WvjXp6WtX4zhf04/wCNPS1q/GcL+nH/ ABqOFXNb4rLyz1/w8/T1j8Z4L0zbvFdztdnxQc+e9ceO9735a+NPT1j8Z4L0zbvFdztdnxQc+e9c eO9735a+Nenpa1fjOF/Tj/jT0tavxnC/px/xphVzPFZeWev+Hn6esfjPBembd4rudrs+KDnz3rjx 3ve/LXxqt3O45q1kLlljP2XvSnkft7hwHCbGEGkfV35dFVwFNpEQURCUg15Eas2j0tavxnC/px/x qpz8ftEubLnFm05qW/Naltvg9E7kbtIaC00StKot6MkUV3tFPa/KOc9d1qppmcyY+sY/v9wrtPDO Hgiev+Ic0XJcol9RbhjLEq06hyeaC5anxQ4gpFM/l+8o91BlaREBU2CKSAhjXa11Is/h3HZVsvUN WvEq6LsTlwSM4oSSUgIhUWvZJSRVQuSCCm5sE/0LPbwu8ue3ntyaCZcG58iM3IiC2ZB20ENo13ED i0AKiF5ii7Vdqq8S4jjxwnIkjMZz4Os3Fh0jkRUIwnKJPIvFpET5QeYqmlRVVPMfZrZNV0qw8fKN 2zht4c//AKr/ABJGT1EsMbKkx6QjjL6yQio44/HFVcJUEU7KueI0pKiIXa0qKh74e3Xb62NlL7bF jvUmIs3wQTWGAcaJ1He04ioh9wBAkc5GYCOm10q7DlE3PHbFNFxkMwnQ4izUnsxo8uOjbEnvo+ri bBSPbnIuDimGy8hTiHHujW+0xp6ux8tkswVknKW3NymBZVwjVwl5oHe0riqaj3NLtR1w9mqqvuvh iad/1/eM9N/tJ+J5SeoNraypMcCBNflrJCNpt2MhoqqiKfYJ1H+A7UlLt64IppsNEs96V/8A5N6D 9G3L/MvF+O7H+S/P4drub/dPwuOvm+e6gfRdscl8pmazpsJJvjBgPyYytCaO94EQ0bR3iBoKiPPS IKCux8lkv/pXrN6c9ZXf8y8J4Hxw+F+fz7vb/wD6n4PLfzfLVV2n3f8A8eXvv7/Hu7GKeqp3POI8 IXHgsN6mREmpAZkx22lbfk99GFbTbiEGnOQ83EANj5EvIOU/6WtX4zhf04/41QrjZnJN+Fhi+QmM fC5tXIG/S4rxdF8ZDi9lGUIubncTRvkI8+SDsQEY3WmyqqnM/ccfr+mPHAqx4LhIuM5rOYNp5Rig SrZJka7Rd0XWnWB+fy0oqj3u47RR3td6SNnZsMX0lvG7076PubFtPgsb5R17h21DbyeyvdZ810qd 0fLyPj/s2Db5OVR8gTNJLJxwJpuK27E7KNkrauB7TSno1aBVXltPPio1zPMRpXUVm+yJFlCDFjKL Tg3FSedeRFFsib4oIIAvyx8iLl3UVU2I8bLPIwjxYTs/Lbju4b42bMeZOLsDNInpeXb3rTdmEh3B uBJkuNB2W3He32F5IaqSOK6CIgopDyRXEBFRV54OXPsX+72u7RXHGYl2ahhNjRlBloX22CYFxSNV M1N7gqtouvIiFsSRajrfa/EZRe596v0ILZJubE6NBjT2jbcJkGhA3eTIuCSEw2ehcUVX2VRURVPo nY/aJXpLebTmvSFzYuR8HonybrPDtoG2l9lO0z5LtV7Q+fmfKzC60zhPGI5zt2Y/WPxe27ftc2p/ 1uxT0n6L9Z7L4/veH8L49ru93lx4cOW+W/LWt78q5rLksy45Hc7SuNXJhmBNWKU1Xo5NL8iDqEoo 5zTkjiaRBLyUVXivIRlvS1q/GcL+nH/GoU4dm9Nu3JjJnYzch4JEqGzLaFqQ6AiImRa7iey22iiJ iJIGlFUI+WaiqxwmJjhx27fphwx3pTi4fumY16zegu78p43wPd8VG/d+fb4dnu9/909nfb1+Fvh7 desnqDa2sqTHAgTX5ayQjabdjIaKqoin2CdR/gO1JS7euCKabDRL6xoNviT1egZpJhwyknJKA27E JkiM1ccTkbROaMyJV9vy5Kg8URETy9F2xyXymZrOmwkm+MGA/JjK0Jo73gRDRtHeIGgqI89IgoK7 HyW/G6Y44bMOc9t/tjh7o/idtlyWZccjudpXGrkwzAmrFKar0cml+RB1CUUc5pyRxNIgl5KKrxXk I2OqwcOzem3bkxkzsZuQ8EiVDZltC1IdARETItdxPZbbRRExEkDSiqEfLp/+les3pz1ld/zLwngf HD4X5/Pu9v8A/qfg8t/N8tVntMqqYmnZs99/19/olGKI+6ZjXrN6C7vynjfA93xUb9359vh2e73/ AN09nfb1+Fvh7dTci4zms5g2nlGKBKtkmRrtF3RdadYH5/LSiqPe7jtFHe13pI6NBt8Ser0DNJMO GUk5JQG3YhMkRmrjicjaJzRmRKvt+XJUHiiIiJsG3ycqj5AmaSWTjgTTcVt2J2UbJW1cD2mlPRq0 CqvLaefFRq6r7v4vw7IwnnO3hw2T+Wz9ebVrpXF6WtX4zhf04/409LWr8Zwv6cf8awpO2lcXpa1f jOF/Tj/jT0tavxnC/px/xoO2lcXpa1fjOF/Tj/jT0tavxnC/px/xoOS53SQzlFmssUGlWUEiVJJx F8o7IiKoCov7orr7HvTXFHPcvHcYxeL0/lsuzNPwdR3uSCUFxEJhEYIvle5ruIj2kRBXzHa8UJK9 rmUJ7KLNeot1tyLFCRFki5ITzjvCJKoIn/WI6wx711xVz3rx1/gx7aM9+UGXPgMiUMl1kZEcQIh4 og7QOXHiAiqcvNE897XddcTOGDXda7OnxePDdsx59J4Y8vzegZfb+0ZvQ7jHUO9zQ2N8UZLi8uxV U0Hkqqi6XaIPItin9PZZbGb2lqdQ23FeFhCJ1pFUyVEFO3z7ulVURF4aVF5b4+1XB6JsRRiYdyd1 0TbltGpPx0UhkqhOJ5An4Sck17l8vNPKvaZAssgTbHJnY7HiElNstSmUFt7udxTTYqpbPa8TUh9r yRNDqH+q04XHHjx57NuzDZvw4T77d0JL06Cv8WrZcXmFkeGGQ00JApo5wLyQuQoKoWyIUH2V0q7H fM9lUIL2loGLJdfV4WdC4zyRVVEUu2riO8U3tV4a4pyTY+df4yFqZlKbWSE3GV4n1iDJaRtTIlMl 5a7mlNVJU5aXetcfZr+O1bDf5SMpdkxvEeISK7IYUEJHO4KckFD0JaVE5fgonmnlUp8aqmbrEzjG z6/vH490n6esfjPBembd4rudrs+KDnz3rjx3ve/LXxr+LLKnSLjd2ZTkYmospGWEaaIC4q2DntKp LtflETyRPmqv7+k9/S1q/GcL+nH/ABqDchWlyY8+eVOq2/MbmOMd6PwI21BQTfDkiJ2wT5373mu1 ValPi2KrObGYqidmzjt24xuwjlimPSLnrEFsKM82BR3HRcIRUXeKtovFUPaa56VCHz35L5efA9lU IL2loGLJdfV4WdC4zyRVVEUu2riO8U3tV4a4pyTY+df5IS2vXtq6+tBNk0KgDAux+2gEoKQ+YKWi VsdrvafvKlfx2rYb/KRlLsmN4jxCRXZDCghI53BTkgoehLSonL8FE808qjPj4LKPu8RE1bdnvv6b Z+uHvg6hyJjx78RyDOaSPKGK88QD2xI+PbXaEu0PmKJpFUd+0gppa/q2XSQ9lF5ssoGkWKEeVGJt F847wkKIaqv7ojrD/uTXFW/evLUREZYdvVxlXG9QhhPTG5LMZmY2QmrYggkewQkVFaAtCev3l2iL y6rYUJnKLzepV1tyrKCPFjC3ITyjsiRIpov/AFiuvv8AuXXFG/cvLcqJqnHFVeabKnwxRvwjHpHz jj7YYccXR65Yh6V9E+tVi9Id/wAP4X0g13u7y49vhy3y5eXHW9+VPXLEPSvon1qsXpDv+H8L6Qa7 3d5ce3w5b5cvLjre/KpD0tavxnC/px/xp6WtX4zhf04/41NmR/rliHpX0T61WL0h3/D+F9INd7u8 uPb4ct8uXlx1vflT1yxD0r6J9arF6Q7/AIfwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/ABp6 WtX4zhf04/40HbVKu03N7bcYHduGPOBPvAxY8Fu3Pd0o6uEZL31fQUcGMDji7DXIFFN7Hdo9LWr8 Zwv6cf8AGuF8rG9f4l6K6x0kRYr8VsUkBwUHjZIlVPftFYDXn++vv8tBH49loXDKLpZHnYLxsSiZ Y9HuFJ7SCK7SQQIosr7K67itqpdwEEu2jjnd65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb3 5V/EhrH38ki347uCSorBsgAzURtRJfPY7/nRNISoCkhK20oSfpa1fjOF/Tj/AI0Ef65Yh6V9E+tV i9Id/wAP4X0g13u7y49vhy3y5eXHW9+VPXLEPSvon1qsXpDv+H8L6Qa73d5ce3w5b5cvLjre/KpD 0tavxnC/px/xp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb35U9csQ9K +ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/jQR/rliHpX0T61 WL0h3/D+F9INd7u8uPb4ct8uXlx1vflT1yxD0r6J9arF6Q7/AIfwvpBrvd3lx7fDlvly8uOt78qk PS1q/GcL+nH/ABp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb35U9csQ 9K+ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/AI0Ef65Yh6V9 E+tVi9Id/wAP4X0g13u7y49vhy3y5eXHW9+VPXLEPSvon1qsXpDv+H8L6Qa73d5ce3w5b5cvLjre /KpD0tavxnC/px/xp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb35U9c sQ9K+ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/jQR/rliHpX 0T61WL0h3/D+F9INd7u8uPb4ct8uXlx1vflT1yxD0r6J9arF6Q7/AIfwvpBrvd3lx7fDlvly8uOt 78qkPS1q/GcL+nH/ABp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb35U 9csQ9K+ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/AI0Ef65Y h6V9E+tVi9Id/wAP4X0g13u7y49vhy3y5eXHW9+VPXLEPSvon1qsXpDv+H8L6Qa73d5ce3w5b5cv Ljre/KpD0tavxnC/px/xp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cdb3 5U9csQ9K+ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/jQR/rl iHpX0T61WL0h3/D+F9INd7u8uPb4ct8uXlx1vflT1yxD0r6J9arF6Q7/AIfwvpBrvd3lx7fDlvly 8uOt78qkPS1q/GcL+nH/ABp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5cd b35U9csQ9K+ifWqxekO/4fwvpBrvd3lx7fDlvly8uOt78qkPS1q/GcL+nH/Gnpa1fjOF/Tj/AI0E f65Yh6V9E+tVi9Id/wAP4X0g13u7y49vhy3y5eXHW9+VPXLEPSvon1qsXpDv+H8L6Qa73d5ce3w5 b5cvLjre/KpD0tavxnC/px/xp6WtX4zhf04/40Ef65Yh6V9E+tVi9Id/w/hfSDXe7vLj2+HLfLl5 cdb35VFYX/o91S/2kX+726svpa1fjOF/Tj/jVYwcwcxvqg42QmBZHsSFdoqLb2/NKD4BpSlB+ifU WJYJvU/p8zlMa2SbKLr70wLk2BxkBu0PHzcRz2eI8ULa+Scd/vV2dNz6GZ5fmbVYunnTmURQZM95 Y8WE64yyMlGoqk2jaFyeb5OEHkTC8QcRCMd8fUcrmHUfBzsrLz90FuasJpl1tpw3vQkjtiJuiTYk paRCMSFF81RU2lWzpJ0yu+MTLrGvOTXqfAbskHHIiKrEfvx47Kkkhs44i6zxOQ80AqamPAjI3OTa thJx8G6Jycik49FwXBpF0iNI7Ljs2OM4UVF4qKPKLao0RIaKAmqKaISiioJKnFZ8e/Y8Xl6IzZ7H 0suLsx11mKEWJAdJ82gE3ABBReRABCRIm1RCRV0ipUnLwW6uYhkeCtXSEmPXe2zY0WQcclmwnJCF yV1eWpeydcLuF23PYTmrxuG6kBgMq+5X1hjZfPxlm0tQ8fl2180gTWnFVyRFcZRXpceOTor239AD ao0okpGqvCKB2WjE+jc0ckOX0uxK0NY5OciT3Z9mgg2iCw2/3kMeQo0rTwFslFUTfJBVFSvFu0/s bXOx27Z0mPxEZyWxxYt691hvn3HR8vMB7TvIk8k7Z7X2V1YOnVtzSBkuTTcjtWPxYl6nDcAKBd3p LjRjFixkbUTjNIoqkcj58topIPFfnVX+kcMIvpG9SGb0lnxiM7ZseZk2WTGkDA9iQagyYI877PhY qbEyJYCmKqTxjQdsTDuiNyjzisGC9P7/ACYcZuScS3W6A46Qut9xn36Ee6PmCmQiSLvevOvDB8X6 GZjaY06y4HgzjrsGLNehLaISyYgSWkdaR5sUXtkQLtN+S6XSqnnUN0Cx7JWMKxG7PY3bLG7YsWft kO2k4+w5KkPFHN05IuRgKMXdi7VRF7mrxGiqiIrkn0wwXKsWkYBGeteMxoGP43KtM8oU91ScfecY NXm21jihciiiZciFeT5+/giuBZvuT9LPzaYZ/UUb/kqp5XYujdgg5RMXpDj9yaxmC3NuCwrDBVNE hmbYqfEe620COmCqi8HWlTkpii6/WWZPjd/uVs6tYvbIbKy8maB+DKlmbURAkQG4RCrggSq62sVx xQEVTi4z7Sc14h7xsT6BSfS/hsa6ZPehOXpbtwYJeA48uXf0PyWuB75a1wL4LT1T6Bfk10y/6N9L f5jB/wAx/wBa+b+4/wD3Pm/w1J4rjd/Zyq2XK7w8ft0SxWiRaYDVoM+3JB44xdzskApFEUiCgtCb yacVOfsIp1/EsOz7HbpixC1jM2BjONyrBGBZz7Tsn2YqtSTLskgdwooCTSIvaRVJHHtoCBC4q9+x 2ya+XWBacJ6fvQrXGelP3Pwtp8P22SQXD4IaviAqq/KG0LaoPJCUSBS98Ha6AZrlU6xY1gGDXAYj TjnjGYVqcbdRsxbLi0JrIQeRaQyaECRNiSiQKVs6cW/PrDaLlb7pZMZ9uTcrjFONfH3Ob8mW7IBk 0KIPAE7yiricl9lFQF3pIyyYhmk3p9lGD5HEx+2xL21eFCfAub0xxo58h51BVk47SKIJIJOXPZKC eScvZBZ8e/Y8XmDcJ1osfSy4xLa13p78WJAdbihol5ukKKgDoCXZaTQr8Fr3tGJ9ArxdFtdoxrpl cJ4xglrFiwYLrqMGIEDvARVeBC42qFrSoYqi+aUwnEr/AGe+Sb3JxuEM9q2vx4TsjPLpddkZNl2l SSxpoDJoFJwUIk4D7JVJ9EbBf8SwK14nerPj9vatMFiMy7aZxvDKNBXuumBMNdsiP210pqqmSqu0 2QcWK4D0hyPHYV6h9MMSZalNciYfsMUXo5p5Gy6KCvB1s0IDDexISFfNK7Z/TLpDAgyJ07p7g0WJ GaJ5996zRQbaAU2RkShoRREVVVfJESu3pHElRcGZemRnojtxnTrqMZ9tQeYCZMelA06K/NdEHhEx 80QkJEVUTazOWFcwxW7HZWXn7oMF5YTTLrbThvcF7Yibok2JKWkQjEhRfNUVNpQYz03PoZnl+ZtV i6edOZRFBkz3ljxYTrjLIyUaiqTaNoXJ5vk4QeRMLxBxEIx3c4+DdE5ORScei4Lg0i6RGkdlx2bH GcKKi8VFHlFtUaIkNFATVFNEJRRUElSM6SdMrvjEy6xrzk16nwG7JBxyIiqxH78eOypJIbOOIus8 TkPNAKmpjwIyNzk2rdzw+xXXG5DtralQpePfKuxebZBNYcNzmQuubVJPIjcXukgOJxRTV83DcQKZ brJ+x8nWO5X9rGOmSWO3yUjO3Tw1tKIpKLa/ugqqD7Toho+Jcv3tKJFMxenvReVICPGwfp++853+ DbdqhkRdhxGntIg7XtuEgF9ElRF0q6qAuOK9SbnjPUq1SLPiUZ3L2nVjm3fpDgxzchR4Sie4Y7FA ZNzknmq8Q0iKppxSekl5mXC5Gzb8SsLU2c3IByM34tGGfQDttSOrJsADrTLznIAJUEwM9iC+yQWD GMT6BZR4j1Zxrple/DcfEejoMGR2uW+PLgK8d8S1v36X4V4WfHv2PF5eiM2ex9LLi7MddZihFiQH SfNoBNwAQUXkQAQkSJtUQkVdIqVX3elOW3O6TCluQrdAueN3SwSQdye5Xp2L4oWVGS2UpEQvaaQV aRGtInJXHNoAeIW2+9U8qusmfY2cdalYbc8fflpbJouNrJOOrJK5LYjE+PsvqjQBptRJSPbwogW3 GMT6BZR4j1Zxrple/DcfEejoMGR2uW+PLgK8d8S1v36X4VM/cn6Wfm0wz+oo3/JUNhOD3CPfJMy+ 2Pwnctr8EJjWe3W6SGwdJtTBtJDYdnl2xXuNkhooDr4pMycFiW+x3obEU24T5ltfisxsivk+4wHC MfZF5p5004KSIhKI8uKkie9UUKzarT+xtu3i/Rds6TT/AAcY5crwzFvc7DAa5unxReIDtNkukTab WpOy4R0MvbzzNlxDpzcnWGmXngiW2E8TYPBzaMkEV0Jh7QqvkSeabSvHCcYvGO3yTk17ieEjRLa+ 14dq/XDIpD3ImzUmyktI6zxRlU7TKF3lMeSbab3TOl3T+95J0gtFtulshYiy3hE3HGmW2nlkE7MR hH5D7DrLCtGLkdSUUU0cV0iQ9IhGFzxjE+gWUeI9Wca6ZXvw3HxHo6DBkdrlvjy4CvHfEtb9+l+F MexPoFkXH1fxrpld+Xc4+BgwX99vt9zXAV+b3Wt/DuBv5ybjI3TO6XODf4N3tbNrduePzbOzclzO 5X1yOklAQkRmW2AoK8BJVEkVVbFPcqqlzxu33+TlR5BkeM4la5YQVhhJgSTmy3gU0NAV82GVbaFU Je3o0IjRdhw9sKxYsZ6DXu03O9W7DunMiz210geuLUK3OxtC0DhmrjfJAEUPS8+KpxVdcVEihsHa 6AZrlU6xY1gGDXAYjTjnjGYVqcbdRsxbLi0JrIQeRaQyaECRNiSiQKVswm359bbvl1wulkxkPTEn 0jFCNfH3eL4xI0cGTUog6AvDqSuJtR5IiAWt179KbbmlkjSrZkdqx9iI7OuFwCRAu70lznJmOSEb Vs4zaIIo8Q8+Sqqgnspy9kIzE8O6I5VHmS7BgvT+5Qo0nwySodugSGnS7YGvEmuWtc+KofEtoq64 qJF4WfHv2PF5g3CdaLH0suMS2td6e/FiQHW4oaJebpCioA6Al2Wk0K/BaRcQzS82zqJZsjiY/aYm YtPKEmBc3prkUzgR4aCrZx2UMdMk5y5ou1QdfhV74TiV/s98k3uTjcIZ7VtfjwnZGeXS67IybLtK kljTQGTQKTgoRJwH2SoFoxPoFeLotrtGNdMrhPGMEtYsWDBddRgxAgd4CKrwIXG1QtaVDFUXzSpn 7k/Sz82mGf1FG/5K8eiNgv8AiWBWvE71Z8ft7VpgsRmXbTON4ZRoK910wJhrtkR+2ulNVUyVV2my sGd2L1owe/Yz4rwnpe2yIPiO3z7XdaIOfHactct62m9e9KCi2fHv2PF5eiM2ex9LLi7MddZihFiQ HSfNoBNwAQUXkQAQkSJtUQkVdIqV74zhHSa+TL5EDpLjMJ6y3JbfIGTYoXyhdlp4XAUEJFAm3myT ei81RRFU1UZgMq+5X1hjZfPxlm0tQ8fl2180gTWnFVyRFcZRXpceOTor239ADao0okpGqvCKdkXE M0vNs6iWbI4mP2mJmLTyhJgXN6a5FM4EeGgq2cdlDHTJOcuaLtUHX4VBGXKJ+x8bxC+5NY8L6f5V GsUbxU9mxwLbJdaaRFVSVFVBTQiZaUkVUAkHa6RbBZ8I6GXmdcINoxDpzcZdtd7M9iLbYTrkU9kn B0RFVAtgSaLS7FfgtRmd4ln2ZWu8OS7djNsnuY3cbFCYavD8hpzxxMdx1xxYoK32xjoqCgHzU9Kr etr2nhGSXbnHuLeM2VmDjc7H7ctuYWTHdGT4dEeKI6Ag0AJFDUfk8Ko4oqeg2YMYxPoFlHiPVnGu mV78Nx8R6OgwZHa5b48uArx3xLW/fpfhXhaMT6NzRyQ5fS7ErQ1jk5yJPdn2aCDaILDb/eQx5CjS tPAWyUVRN8kFUVK8cJwXLbT1LtuTy2YTMBu2zLdJiu5Xcrs613TjuC825KHS7JhAVtBb0ntKbm0A JnCbJmA3fLlym2WWFAyGT4vnab7JckMl4SNF7aL4dlR9lgj7omhCpIiJ5cqCMxvHv2PGSzjg45Y+ ll5lttK8bECJAkOCCKiKaiCKqDshTfu2qfGu2DgPSGbkVzssfphiRu21pgpD6WGKrKG7zVGeSD+6 iAgZAqIqC80XmhpVmxvELTYJxzIMvIHnTaVpRn5BOmt6VUXaA+8YoXkntIm9bTelXfHh8SVbs5zZ mRGe7VxnRbrHko2vZIDhtRVa5L73ROGZEKbRBdaXeyVECFg4D0hm5Fc7LH6YYkbttaYKQ+lhiqyh u81Rnkg/uogIGQKiKgvNF5oaVxTcX6GQJ15ZueB4Nb4lmajFOuMu0QmojRvqSCyrpJoXURGyUC0q C+yvnzSrPh8SVbs5zZmRGe7VxnRbrHko2vZIDhtRVa5L73ROGZEKbRBdaXeyVErGT43f7lbOrWL2 yGysvJmgfgypZm1EQJEBuEQq4IEqutrFccUBFU4uM+0nNeIScXp70XlSAjxsH6fvvOd/g23aoZEX YcRp7SIO17bhIBfRJURdKuqhrVaf2Nt28X6LtnSaf4OMcuV4Zi3udhgNc3T4ovEB2myXSJtNrUZJ 6W39bhcp0HHsGik9ObmMRnDN2OQDYHbcMJ0EYDlHbeNFFE8lbcc9kC9krN07w++2rKlvV1jswWm4 LsUGVyWbfXHVcNouSOzGxKOI9rSg3tHVMVPzZCg4rZj37Hi6ToEG2WPpZNl3FonoLEeJAcclAKmh G2IoqmKK24iqO0RQL6K0sWM9Br3abnerdh3TmRZ7a6QPXFqFbnY2haBwzVxvkgCKHpefFU4quuKi ROk/Ti/4pebdIu97ZnRLRaDtcAAMyXgrcFnyEvJodW4XuIqSc5bo/wDVI49J4Tb8+tt3y64XSyYy HpiT6RihGvj7vF8YkaODJqUQdAXh1JXE2o8kRALW6DxsuEdDL288zZcQ6c3J1hpl54IlthPE2Dwc 2jJBFdCYe0Kr5Enmm0qGsNp6DX/KmLFYMBwa8NPwX5bdygW23SIm2TZB1lSBVJHR8QyWlFE4mmlV dokXa+lGVJiGPYg9Fxm1wIuEXPGp8mFMdcIX5aNIsltlWARzZRxcJCMFUnz814ITkplOB5pmORSb heIOJWVq44tc8alOQpT0qS0EntE293CZa7wiYEiMqjaByMkcNTURDss+PfseLzBuE60WPpZcYlta 709+LEgOtxQ0S83SFFQB0BLstJoV+C0tmPfseLpOgQbZY+lk2XcWiegsR4kBxyUAqaEbYiiqYorb iKo7RFAvorVgslryq4ZxDybJoFltfo62yoMePbrk7N7/AIh2MZGRGwz2+HhRRERD5dxfMePtUzE+ luVWO3vMyblZbx4HG5NltMW4I67Ed5x4TAi82qewyXo4HTAeWymPB59tHHgk8bx79jxks44OOWPp ZeZbbSvGxAiQJDggioimogiqg7IU37tqnxrtxXAekOR47CvUPphiTLUprkTD9hii9HNPI2XRQV4O tmhAYb2JCQr5pTp3h99tWVLerrHZgtNwXYoMrks2+uOq4bRckdmNiUcR7WlBvaOqYqfmyFTXSOJK i4My9MjPRHbjOnXUYz7ag8wEyY9KBp0V+a6IPCJj5ohISIqom1Dw+5P0s/Nphn9RRv8Akp9yfpZ+ bTDP6ijf8lXOobFfWr/6r60+hf8ApJ70X6N7v+Y+Xa73c/6753Lj7Pu1QQv3J+ln5tMM/qKN/wAl UaRb+kjOJZRlJdC7YVrx12UDjiWO18piRnnWpBsj3N8W1ZNV7nbUk1xQlXVbZWQQrdd7/wBH8+wa 2W96NepU6+xh9LRpMONwmT5ag6DyskLo9pzmnb5J81FUeW0CTjYn0Ck+l/DY10ye9CcvS3bgwS8B x5cu/ofktcD3y1rgXwWnqn0C/Jrpl/0b6W/zGD/mP+tfN/cf/ufN/hqTxXG7+zlVsuV3h4/bolit Ei0wGrQZ9uSDxxi7nZIBSKIpEFBaE3k04qc/YRThcDwzNLBkWHpMLH3rLjePyMfEmpDySXQXwqhK VFb48j8KKKxvTe1VHXd8RDxxiz/sc8msci92Kw9Mp0CJGGVMdbt0P/JGiFSQn0UUVn2RJVRxBVOJ b1pde2FY5+x+zWCszE8X6c3loWm3XRi2qIbjKOIqgjocOTZLpfZNEXYqiptFqwdL7NlWOWO2YzdB sqWmyW1q3RZEZ912RO7QgAPGJAAx/ZBVVtFe2riaNED5SGtWFZU90sl9NLpIssK0tY2dgiz4xuyZ EnbCMBJNshbFnQopK0hO8lNERwUDbgeFnx79jxeYNwnWix9LLjEtrXenvxYkB1uKGiXm6QoqAOgJ dlpNCvwWu2y4R0MvbzzNlxDpzcnWGmXngiW2E8TYPBzaMkEV0Jh7QqvkSeabSu2Hbc0m5U3lN3tW PwpdstEyFAhxbu9IblHIOO5t10ozasiKxRT2QcVUcVdJwRDr/TDBcqxaRgEZ614zGgY/jcq0zyhT 3VJx95xg1ebbWOKFyKKJlyIV5Pn7+CK4Fm+5P0s/Nphn9RRv+SoxnCOhj0G5TmcQ6cuRLU66zcXw tsJW4ZtJt0HSQdNkCeZIWlFPfqtGqs4BabrafWD0pbMZgeMvcmXF9CME332D48HZPJE5Si0vMk2i 6HS0FStmPfseLpOgQbZY+lk2XcWiegsR4kBxyUAqaEbYiiqYorbiKo7RFAvorXvieHdEcqjzJdgw Xp/coUaT4ZJUO3QJDTpdsDXiTXLWufFUPiW0VdcVEi8Ok/Ti/wCKXm3SLve2Z0S0Wg7XAADMl4K3 BZ8hLyaHVuF7iKknOW6P/VI48i4hml5tnUSzZHEx+0xMxaeUJMC5vTXIpnAjw0FWzjsoY6ZJzlzR dqg6/CoIyBE/Y+XC+LBt+F9P5sAbbJuB3mNAtrsBsYxMo+2bgqqgYDIZNeQoPE0Xl5KiduMWLoFl ljkXTDcM6f5L2IwyCi262QSkJzFSbbIDQe0ZcVREdUNKioutLqTttgzST1ZtWbXiz4lBaZtEu0yg hTnn5PA3GXm3O8TAd0UNohRpRBA5maGamoD29PrTmmM4rDxx6Nj70SxWgLfbjCY93LkbQCDTjqq0 iRRVA9oBSQu3PIvk/lAhcHxfoZmNpjTrLgeDOOuwYs16EtohLJiBJaR1pHmxRe2RAu035LpdKqed WD7k/Sz82mGf1FG/5KrPTDBcqxaRgEZ614zGgY/jcq0zyhT3VJx95xg1ebbWOKFyKKJlyIV5Pn7+ CK5rNBkFotHQq42HJL8vTPH4Fuxx1wLg5PxIIzgoEZuSZoybSO8UB1PeCKqoukVFFV9sexTpdcb4 NkunQ+y47PdjOSorVxstsPxLTZNi6QrHN1E4E8yioaiq9xOPLRcfaLiGaXm2dRLNkcTH7TEzFp5Q kwLm9NcimcCPDQVbOOyhjpknOXNF2qDr8KrBZLXlVwziHk2TQLLa/R1tlQY8e3XJ2b3/ABDsYyMi Nhnt8PCiiIiHy7i+Y8faB9yfpZ+bTDP6ijf8lRjOB9G5sG5SLL08wa9u2512O/HgWuCbiSG02UdV VEEHfNE4mQ6VU2qJ51o1VPD7Xf7NByc3rNiUeXLu8uZbmrWJxm5QEg9o5hqBL4glTTjgiSa0qIut UFYwfF+hmY2mNOsuB4M467BizXoS2iEsmIElpHWkebFF7ZEC7Tfkul0qp5174xifQLKPEerONdMr 34bj4j0dBgyO1y3x5cBXjviWt+/S/Cqxa+lGVJiGPYg9Fxm1wIuEXPGp8mFMdcIX5aNIsltlWARz ZRxcJCMFUnz814ITlt6d4hdLVlS3i72FmM6EF2MzKXN7lenBRw2iJtG5bQiAl2hVSFd7AU0qKug8 cTw7ojlUeZLsGC9P7lCjSfDJKh26BIadLtga8Sa5a1z4qh8S2irriokXhZ8e/Y8Xl6IzZ7H0suLs x11mKEWJAdJ82gE3ABBReRABCRIm1RCRV0ipSLiGaXm2dRLNkcTH7TEzFp5QkwLm9NcimcCPDQVb OOyhjpknOXNF2qDr8KozD1vGcdU0yO6436GjNY3NtEp2PGuESR8q/GNrUqQxFdPyB9RFoPkVEiVz bwogUbqsz0MHObDi9ut2DYzMgXdHZk+VZoQQ3QWHcR7ZdxBR9oZDANuoKogmQgjgOpsJrEbHbrD0 XuUe2R2Rjvzp8huQ1HaZSayUucjEjTQC2QmwjKiQCgqHDiiDxSrZPwXMr/rArzdIUDp9BjRmlK1x 0Yl3phO8JRHFbIRigIiwLiNN6cFS4E0Jk03KdT4kWBisuDBjMxYkaCyywwy2gNtAISEEBFPIRRER ERPJESg/KylKUH6evuwju8S6Lb2X5UNsBivOqaGwXaRsyBRJNKqck37+KqnkiqiyHrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKesUz6H1qR9pSlA9Ypn0PrUj7SnrFM+h9akfaU pQPWKZ9D61I+0p6xTPofWpH2lKUD1imfQ+tSPtKjcjnSbtZ5UHttAb4KiGTjhLviSCiqRFpPbX3U pQfG/wC1ez/8b4z+kv8A2NKUoP/Z --=====================_932464355==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_932464355==_-- From owner-xemacs-beta@xemacs.org Tue Jul 20 10:45:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA02544 for xemacs-beta-out; Tue, 20 Jul 1999 10:45:03 -0400 Received: from mail-york.pindar.co.uk (mail.alphagraphics.co.uk [195.92.54.18]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA02535 for ; Tue, 20 Jul 1999 10:44:59 -0400 Received: from mimesweeper.pindar.co.uk by mail-york.pindar.co.uk via smtpd (for gwyn.tux.org [207.96.122.8]) with SMTP; 20 Jul 1999 14:41:00 UT Received: from firewall.pindar.co.uk (firewall.pindar.co.uk) by mimesweeper.pindar.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Tue, 20 Jul 1999 15:43:57 +0100 Received: from mail-pindarset.pindar.com by firewall.pindar.co.uk via smtpd (for mimesweeper.pindar.co.uk [195.92.54.26]) with SMTP; 20 Jul 1999 14:40:52 UT Received: from pindar.com ([193.16.17.120]) by pokie.pindarset.pindar.com (Netscape Messaging Server 3.01) with ESMTP id AAA1084; Tue, 20 Jul 1999 15:49:11 +0100 Message-Id: <37948B8D.43BE3589@pindar.com> Date: Tue, 20 Jul 1999 15:45:33 +0100 From: William Deakin Reply-To: w.deakin@pindar.com X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en-GB,en MIME-Version: 1.0 To: Jan Vroonhof Cc: ilisp@naggum.no, xemacs-beta@xemacs.org Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 References: <379339E8.7CCEC054@pindar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Dear Jan, Thank you for you interest and help. Jan Vroonhof wrote: > > If anybody has any clue about what is happening with XEmacs/ILISP, > > please let me know or write to ILISP mailing list. (for the time > > being, but not much longer, ). > > Well. I am not sure whose problem this is exactly, but for me the problem seems to be with something (i.e. either XEmacs or Clisp[1]) not flushing pipe > buffers correctly. The patch below "fixes" the problem > for me. I can run Clisp now and evaluate "(+ 1 2)", define a function and have it complete the function name in a call. This works with the Allegro common lisp under solaris, but unfortunately no such luck with clisp :-( I have included the bulk of my posting to comp.emacs.xemacs and gnu.emacs.help at the end of this message. But, please ignore it (or not as you see fit) as you seem unable to repeat these problems. > P.S. I have the feeling ilisp could do with a few '(defstruct's. I wholeheartedly agree. Best Regards, :-) will Having installed the inferior lisp package with xemacs 21.1-p3, I cannot get ilisp to work with CLISP. Using the following procedure: 1) typing esc-x load-library returns the Load Library: prompt 2) typing ilisp at this prompt load the ilisp library 3) typing esc-x return the Dialect: prompt 4) typing clisp-hs loads the CLISP dialect and starts the *clisp-hs* and *ilisp-hs* I have define the clisp-hs program to run clisp -I -a The clisp-hs processes to runs anything I type in that buffer. If I then open up a text file, and set this as a lisp-mode buffer using 'lisp-mode'; or try to set the lisp package using 'set-package-lisp' the bottom bar; the *clisp-hs* buffer bomb out with the prompt (ILISP :run) changing to (ILISP :interrupt). When 'esc-x set-package-lisp' is typed the prompt Package [nil]: is returned. Ilisp seems to not think there is a package set. I have tried this on Solaris 2.6 and Linux 2.2.10. I have followed the advice in the postings given in the thread 'ILISP 5.8-a04 installation and configuration' on gnu.emacs.help and recompiled the code. I have also tried to subscribe to the ilisp bugs page but to no avail. Also, when running under debug I have got the a message like "concat is no longer supported with compiled code after version 20.3." I am running ilisp compiled and there 129 concat's in the lisp. Could this be the problem. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. The views expressed in the email and files transmitted with it are those of the individual not the company. If you have received this email in error please notify. postmaster@pindar.com http://www.pindar.com ********************************************************************** From owner-xemacs-beta@xemacs.org Tue Jul 20 10:51:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA02875 for xemacs-beta-out; Tue, 20 Jul 1999 10:51:20 -0400 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 KAA02836 for ; Tue, 20 Jul 1999 10:50:48 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 116bE7-00012l-00 for ; Tue, 20 Jul 1999 16:50:39 +0200 To: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@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: 20 Jul 1999 16:50:39 +0200 In-Reply-To: Kyle Jones's message of "Mon, 19 Jul 1999 13:50:22 -0700 (PDT)" Message-ID: <87k8rvnznk.fsf@pc-hrvoje.srce.hr> Lines: 7 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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 next thing to figure out now is why Steve can duplicate the > problem even when allow-deletion-of-last-visible-frame is t. Note that this doesn't apply for me. When I set a-d-o-l-v-f (sic!) to t, I don't see the problem. From owner-xemacs-beta@xemacs.org Tue Jul 20 11:03:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA03387 for xemacs-beta-out; Tue, 20 Jul 1999 11:03:29 -0400 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 LAA03380 for ; Tue, 20 Jul 1999 11:03:26 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA08179; Tue, 20 Jul 1999 01:01:27 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-249.beasys.com [192.168.11.249]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA08360; Tue, 20 Jul 1999 01:01:24 -0700 (PDT) Message-Id: <3.0.5.32.19990720090144.00a38440@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Jul 1999 09:01:44 +0100 To: Norbert Koch From: Andy Piper Subject: Re: buffer.h is screwed w/no error checking Cc: Neal Becker , xemacs-beta@xemacs.org In-Reply-To: References: <3.0.5.32.19990719125026.00a6f910@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: Oops. Take 2..... I find it difficult compiling in my head. andy At 08:14 AM 7/20/99 +0200, Norbert Koch wrote: >In message <3.0.5.32.19990719125026.00a6f910@london.beasys.com>, >Andy Piper wrote: > >> At 09:57 PM 7/18/99 -0400, Neal Becker wrote: >> >INC_CHARBYTIND is not defined if --error-checking=none in the latest >> >CVS. >> >> Fixed, thanks. > >Are you sure? Compiling redisplay.c natively on NT gives me the >following errors: > >..\src\redisplay.c(4484) : warning C4002: > too many actual parameters for macro 'INC_CHARBYTIND' > >..\src\redisplay.c(4484) : warning C4003: > not enough actual parameters for macro 'REAL_INC_CHARBYTIND' > >..\src\redisplay.c(4484) : error C2059: > syntax error : '+=' > >This is with the latest CVS sources (21.2). Should I set error >checking during the build? > >Thanks, norbert. > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Jul 20 11:03:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA03384 for xemacs-beta-out; Tue, 20 Jul 1999 11:03:28 -0400 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 LAA03375 for ; Tue, 20 Jul 1999 11:03:24 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id AAA07941; Tue, 20 Jul 1999 00:57:16 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-249.beasys.com [192.168.11.249]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id AAA07836; Tue, 20 Jul 1999 00:57:14 -0700 (PDT) Message-Id: <3.0.5.32.19990720085734.00a8ad90@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Jul 1999 08:57:34 +0100 To: Jan Vroonhof , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again In-Reply-To: References: <"James N. Potts"'s message of "Mon, 19 Jul 1999 12:44:27 -0500"> <007c01bed20e$593fa170$074ef4d0@dogbert.plutonium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 08:16 PM 7/19/99 +0200, Jan Vroonhof wrote: >"James N. Potts" writes: > >> >Can you also reproduce this with frames created by C-x 5 2 ?, i.e. >> > >> >C-x 5 2 >> >C-x 5 o (little ooo) >> >minimize other frame >> >C-x 5 0 (zero) >> >> >> Yes. > >Well there is two options > 1. The mimized state is considered a form of iconized (which I > believe it is). Then this an XEmacs-NT bug. > 2. The allow-deletion-of-last-visible-frame = nil feature doesn't > work on NT and should be changed to t. There are some iconic bugs in 21.1 that Phil Aston fixed in 21.2. I don't know i fthey affect this behaviour. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Tue Jul 20 11:51:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA05797 for xemacs-beta-out; Tue, 20 Jul 1999 11:51:00 -0400 Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA05793 for ; Tue, 20 Jul 1999 11:50:56 -0400 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id KAA20678; Tue, 20 Jul 1999 10:48:06 -0500 (CDT) 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 KAA24435; Tue, 20 Jul 1999 10:48:13 -0500 (CDT) Received: from wcsdsp3 (wcsdsp3.rtp.ericsson.se [147.117.132.215]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id LAA29552; Tue, 20 Jul 1999 11:48:02 -0400 (EDT) Received: (toy@localhost) by wcsdsp3 (8.6.8/8.6.8) id LAA11364; Tue, 20 Jul 1999 11:49:15 -0400 To: Jan Vroonhof Cc: Marco Antoniotti , willd@pindar.com, ilisp@naggum.no, xemacs-beta@xemacs.org Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 References: <379339E8.7CCEC054@pindar.com> From: Raymond Toy Date: 20 Jul 1999 11:49:15 -0400 In-Reply-To: Jan Vroonhof's message of "20 Jul 1999 11:36:18 +0200" Message-ID: <4npv1ngw3o.fsf@rtp.ericsson.se> Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Marco Antoniotti writes: >> > Having installed the inferior lisp package with xemacs 21.1-p3, I cannot get >> > ilisp to work with CLISP. >> >> If anybody has any clue about what is happening with XEmacs/ILISP, >> please let me know or write to ILISP mailing list. (for the time >> being, but not much longer, ). Jan> Well. I am not sure whose problem this is exactly, but for me the Jan> problem seems to be with something (i.e. either XEmacs or Clisp[1]) not Jan> flushing pipe buffers correctly. The patch below "fixes" the problem Jan> for me. I can run Clisp now and evaluate "(+ 1 2)", define a function Jan> and have it complete the function name in a call. One other thing: I think you're supposed to use the -I option when running clisp with ilisp. I'm vaguely remember the -I option being added exactly for this purpose. I causes clisp to flush it's buffers at the right time, or something like that. Clisp works fine for me, without Jan's patch. (Well, except it can't autoload clisp-hs from ilisp-chs.el, but that's a different issue.) Ray From owner-xemacs-beta@xemacs.org Tue Jul 20 11:53:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA05870 for xemacs-beta-out; Tue, 20 Jul 1999 11:53:41 -0400 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 LAA05867 for ; Tue, 20 Jul 1999 11:53:39 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA18773; Tue, 20 Jul 1999 17:53:34 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004.4; Tue Jul 20 17:53:27 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA16425; Tue, 20 Jul 1999 17:53:27 +0200 To: w.deakin@pindar.com Cc: ilisp@naggum.no, xemacs-beta@xemacs.org Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 References: <379339E8.7CCEC054@pindar.com> <37948B8D.43BE3589@pindar.com> From: Jan Vroonhof Date: 20 Jul 1999 17:53:26 +0200 In-Reply-To: William Deakin's message of "Tue, 20 Jul 1999 15:45:33 +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: William Deakin writes: > Also, when running under debug I have got the a message like "concat is > no longer supported with compiled code after version 20.3." I am running > ilisp compiled and there 129 concat's in the lisp. Could this be the > problem. Could mail a backtrace. i.e. 1. load all the ilisp files as uncompiled lisp by using M-x load-file RET "filename.el" RET (or simply remove the .elc's and restart XEmacs). 2. set debug-on-error to t and reproduce. Then mail the complete contents of the *Backtrace* buffer, not just the error. Jan From owner-xemacs-beta@xemacs.org Tue Jul 20 12:23:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA07368 for xemacs-beta-out; Tue, 20 Jul 1999 12:23:50 -0400 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 MAA07363 for ; Tue, 20 Jul 1999 12:23:48 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id SAA20852; Tue, 20 Jul 1999 18:23:26 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0055Y; Tue Jul 20 18:23:19 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id SAA16476; Tue, 20 Jul 1999 18:23:19 +0200 To: Raymond Toy Cc: Marco Antoniotti , willd@pindar.com, ilisp@naggum.no, xemacs-beta@xemacs.org Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 References: <379339E8.7CCEC054@pindar.com> <4npv1ngw3o.fsf@rtp.ericsson.se> From: Jan Vroonhof Date: 20 Jul 1999 18:23:18 +0200 In-Reply-To: Raymond Toy's message of "20 Jul 1999 11:49:15 -0400" 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: Raymond Toy writes: > One other thing: I think you're supposed to use the -I option when > running clisp with ilisp. I'm vaguely remember the -I option being > added exactly for this purpose. I causes clisp to flush it's buffers > at the right time, or something like that. Aha.. That's it. Would be nice if the clisp-hs-program had this as a default. Jan From owner-xemacs-beta@xemacs.org Tue Jul 20 12:41:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA08385 for xemacs-beta-out; Tue, 20 Jul 1999 12:41:16 -0400 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 MAA08380 for ; Tue, 20 Jul 1999 12:41:11 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.8.8/8.8.8) with ESMTP id JAA22124 for ; Tue, 20 Jul 1999 09:41:09 -0700 (PDT) Message-Id: <199907201641.JAA22124@ptavv.es.net> To: xemacs-beta@xemacs.org Subject: Undesirable behavior by new mailcrypt package Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Jul 1999 09:41:09 -0700 From: "Kevin Oberman" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I pulled in the new gpg friendly mailcrypt 2.00 and hit a big snag. It now pops up a window reporting that the signature was OK for each signed message. The window titled "Question" just sits there until it's acked with a click or a RET.. This is probably OK for mail, but for network news and NoCeM it's a royal pain. Hitting the OK for a few thousand signed messages. I looked for some way to turn this off, but I have not found any. Is there a way to get rid of these annoying messages? It may be worse than getting all of the spam in net news! 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 Tue Jul 20 13:07:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA09506 for xemacs-beta-out; Tue, 20 Jul 1999 13:07:23 -0400 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 NAA09503 for ; Tue, 20 Jul 1999 13:07:21 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id NAA09483 for xemacs-beta@xemacs.org; Tue, 20 Jul 1999 13:07:19 -0400 Date: Tue, 20 Jul 1999 13:07:19 -0400 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: Tabs 'n widgets screenshot Message-ID: <19990720130719.A9441@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: <3.0.5.32.19990720115235.00a98db0@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.19990720115235.00a98db0@london.beasys.com>; from Andy Piper on Tue, Jul 20, 1999 at 11:52:35AM +0100 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Tue, Jul 20, 1999 at 11:52:35AM +0100, Andy Piper wrote: > ... for anyone who's interested. That's completely insane. I like it :-) OG. From owner-xemacs-beta@xemacs.org Tue Jul 20 13:16:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA09756 for xemacs-beta-out; Tue, 20 Jul 1999 13:16:23 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA09752 for ; Tue, 20 Jul 1999 13:16:21 -0400 Received: from corpmail2.Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12269; Tue, 20 Jul 1999 10:16:16 -0700 (PDT) Received: from einstein.Corp.Sun.COM (einstein.Corp.Sun.COM [129.145.208.63]) by corpmail2.Corp.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA07632; Tue, 20 Jul 1999 10:16:15 -0700 (PDT) Received: (from rajesh@localhost) by einstein.Corp.Sun.COM (8.9.3+Sun/8.9.1) id KAA00649; Tue, 20 Jul 1999 10:16:15 -0700 (PDT) To: "(ding)" , xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.126 From: Rajesh Godbole In-Reply-To: Stainless Steel Rat's message of "19 Jul 1999 20:19:19 -0400" X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# Date: 20 Jul 1999 10:16:15 -0700 Message-ID: <8t6btd7ckdc.fsf@Corp.Sun.COM> Lines: 8 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Is threading on the roadmap/TODO list? Is someone actively working on this? IMHO it would be a very desirable feature. >>>>> Stainless Steel Rat writes: SSR> Emacs is not threaded (and it probably will never be, at SSR> least not in its current incarnation). From owner-xemacs-beta@xemacs.org Tue Jul 20 13:34:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA10422 for xemacs-beta-out; Tue, 20 Jul 1999 13:34:23 -0400 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 NAA10419 for ; Tue, 20 Jul 1999 13:34:21 -0400 Received: (from karl@localhost) by beaver.jprc.com (8.8.7/8.8.7) id NAA30590; Tue, 20 Jul 1999 13:34:20 -0400 To: xemacs-beta@xemacs.org Subject: assertion failed, insdel.c (21.2.18, linux) 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: 20 Jul 1999 13:34:19 -0400 Message-ID: Lines: 147 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: This is one I've never seen before. At the time, I was editing a Gnus score expression in the minibuf. Fatal error: assertion failed, file insdel.c, line 607, ( newmin) > BI_BUF_BEG (buf) && newmin <= BI_BUF_Z (buf) #0 0x2ad2a811 in __kill () #1 0x2ad2a63f in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x2ad2b84f in abort () at ../sysdeps/generic/abort.c:83 #3 0x808e0ab in assert_failed (file=0x8216430 "insdel.c", line=607, expr=0x82164b3 "( newmin) > BI_BUF_BEG (buf) && newmin <= BI_BUF_Z (buf)") at emacs.c:2668 #4 0x812d9ff in bufpos_to_bytind_func (buf=0x830a1e0, x=0) at insdel.c:607 #5 0x812e3b3 in bufpos_to_bytind (buf=0x830a1e0, x=0) at buffer.h:977 #6 0x819699c in scan_words (buf=0x830a1e0, from=1, count=-1) at syntax.c:427 #7 0x8196cd2 in Fforward_word (count=-1, buffer=137112340) at syntax.c:476 #8 0x8094c2f in Ffuncall (nargs=3, args=0x7fffe8d4) at eval.c:3189 #9 0x8063404 in execute_optimized_program ( program=0x8a4ec24 "À\t[\n\"\207¨\b", stack_depth=3, constants_data=0x83d38a0) at bytecode.c:747 #10 0x8062d15 in funcall_compiled_function (fun=138225500, nargs=1, args=0x7fffe9e0) at bytecode.c:523 #11 0x8094d89 in Ffuncall (nargs=2, args=0x7fffe9dc) at eval.c:3221 #12 0x8069a1a in Fcall_interactively (function=138210068, record_flag=137112340, keys=137112340) at callint.c:949 #13 0x8093413 in Fcommand_execute (cmd=138210068, record=137112340, keys=137112340) at eval.c:2623 #14 0x80e02a2 in execute_command_event (command_builder=0x83531d0, event=146245096) at event-stream.c:4345 #15 0x80e10de in Fdispatch_event (event=146245096) at event-stream.c:4684 #16 0x8073320 in Fcommand_loop_1 () at cmdloop.c:578 #17 0x807309d in command_loop_1 (dummy=137112340) at cmdloop.c:493 #18 0x8091741 in condition_case_1 (handlers=137112436, bfun=0x807304c , barg=137112340, hfun=0x80724d0 , harg=137112340) at eval.c:1640 #19 0x8072994 in call_command_loop (catch_errors=137112364) at cmdloop.c:255 #20 0x814b0b8 in Fread_minibuffer_internal (prompt=145592476) at minibuf.c:188 #21 0x8094c1c in Ffuncall (nargs=2, args=0x7fffed4c) at eval.c:3189 #22 0x8063404 in execute_optimized_program ( program=0x7fffed98 "À Á V«\013Â\211\e\034Å\016\006!*\207Å\016\006!\207Ô*ÌfÚ* $Ú*\234\226#\b \204¬\b\b\013$\b8$Ú*\024+,\b\"", stack_depth=2, constants_data=0x83f1bd8) at bytecode.c:747 #23 0x806748c in Fbyte_code (instructions=138302212, constants=138353608, stack_depth=5) at bytecode.c:2406 #24 0x80941f6 in Feval (form=138353008) at eval.c:2986 #25 0x809131c in internal_catch (tag=137200580, func=0x809393c , arg=138353008, threw=0x0) at eval.c:1315 #26 0x8063f34 in execute_rare_opcode (stack_ptr=0x7fffefc8, program_ptr=0x8a45244 "æa«\f\201H", opcode=Bcatch) at bytecode.c:1253 #27 0x80631a8 in execute_optimized_program ( program=0x8a450d4 "\b¬\022Á ÂV«\fÃ Ä a«\005ÅÆ!\210\016\a«\021\016\aÂV«\013Á \016\aY«\004È \210\016\t«\"\016\t9«\017Ê\016\t!¬\027ÅË\016\t\"\210ª\017Ê\016\t@!¬\bÅË\016\t@\"\210Ì «\tÍÎÏ\016\020!\"\210\016\021\036\022à \036\023Ô \036\025Ä \036\026Á Âa«\a×\016\026!ª\bØÙÚÁ \"!\036\eÜ\016\026!\211\036\035Ô a?­\005Þ\016\035!\036\037Þ \036 \016\t\036!â\216ã\016\e!q\210\016\022\026\021äå!\210æ\026%äç!\210äè!\210äé!\210ê\026'ë\026(\016,«\025äí!\210\016-"..., stack_depth=6, constants_data=0x83f4490) at bytecode.c:657 #28 0x8062d15 in funcall_compiled_function (fun=138289016, nargs=5, args=0x7ffff0d8) at bytecode.c:523 #29 0x8094d89 in Ffuncall (nargs=6, args=0x7ffff0d4) at eval.c:3221 #30 0x8063404 in execute_optimized_program ( program=0x8a2472c "À\031Â\013\f\rÀ\016\006%)\207(", stack_depth=6, constants_data=0x83f3b10) at bytecode.c:747 #31 0x8062d15 in funcall_compiled_function (fun=138359588, nargs=2, args=0x7ffff1e8) at bytecode.c:523 #32 0x8094d89 in Ffuncall (nargs=3, args=0x7ffff1e4) at eval.c:3221 #33 0x8063404 in execute_optimized_program ( program=0x8ab96c4 "\bÁa«\003Â\020\bÂa¬\013\bÃa¬\006\bÄa«\037\r«\030\r\036\006ÇÈ\016\006\"«\t\016\006É\225ÄOª\003\016\006)ª\002Ê\025ª\n\bËa«\005Ì\r!\025Í\016\016!ÏÐ\016\021\227\"Ä\036\022\036\021\036\016\016\023«/ÔÏÕ\016\026×a«\004ت\n\016\026;«\004Ùª\002Ú\016\021\016\016ÉW«\004Ûª\002Ü$\r§«\006Ý\r!ª\002\r\"\025ÏÐ\r\"\025Þß\016\021\016 \"8áa«\005â\r!\025\016\026×a\204æ", stack_depth=7, constants_data=0x8a2c590) at bytecode.c:747 #34 0x8062d15 in funcall_compiled_function (fun=143570136, nargs=8, args=0x7ffff2fc) at bytecode.c:523 #35 0x8094d89 in Ffuncall (nargs=9, args=0x7ffff2f8) at eval.c:3221 #36 0x8063404 in execute_optimized_program ( program=0x8d0c51c "À\t!\211\032ÃW«\004Ī\002Å\036\006\nÃV\036\aÈ\036\tÊ\036\013\016\f\036\rÎÏ ÐEÑÒE\036\023\016\024\036\025\016\026­\a×\016\026!ÃH\036\030\016\031­\a×\016\031!ÃH\036\032\016\e­\a×\016\e!ÃH\036\034Ý\036\036Ý\036\037Ý\036 Ý\036!Ý\036\"ã\216\016\030¬>\016\025«\räå!\210æç\016\006\"\210ª\023æè\016\a«\004éª\002êëì\016\tí##\210î \211\026\030ïU¬\a\016\030ðU«ÌÝ\026\030ñò\016\tå#\210ªÀó \210\016\030\227\016\t·\211\026\036¬\023\016\025«\013ôõ\016\006\016\030#\210ª\005ôö!\210\016\030\227\016\030U"..., stack_depth=10, constants_data=0x8a2c228) at bytecode.c:747 #37 0x8062d15 in funcall_compiled_function (fun=143569996, nargs=2, args=0x7ffff41c) at bytecode.c:523 #38 0x8094d89 in Ffuncall (nargs=3, args=0x7ffff418) at eval.c:3221 #39 0x8063404 in execute_optimized_program ( program=0x8d2a41c "ÀÁ\n![\013\"\207\t ", stack_depth=3, constants_data=0x8a2a148) at bytecode.c:747 #40 0x8062d15 in funcall_compiled_function (fun=143569800, nargs=2, args=0x7ffff51c) at bytecode.c:523 #41 0x8094d89 in Ffuncall (nargs=3, args=0x7ffff518) at eval.c:3221 #42 0x809546a in Fapply (nargs=2, args=0x7ffff560) at eval.c:3456 #43 0x8095c8e in apply1 (fn=143569800, arg=146722424) at eval.c:3808 #44 0x8067ee4 in Fcall_interactively (function=141483844, record_flag=137112340, keys=137112340) at callint.c:397 #45 0x8093413 in Fcommand_execute (cmd=141483844, record=137112340, keys=137112340) at eval.c:2623 #46 0x80e02a2 in execute_command_event (command_builder=0x83531d0, event=144459644) at event-stream.c:4345 #47 0x80e10de in Fdispatch_event (event=144459644) at event-stream.c:4684 #48 0x8073320 in Fcommand_loop_1 () at cmdloop.c:578 #49 0x807309d in command_loop_1 (dummy=137112340) at cmdloop.c:493 #50 0x8091741 in condition_case_1 (handlers=137112436, bfun=0x807304c , barg=137112340, hfun=0x80724d0 , harg=137112340) at eval.c:1640 #51 0x8073538 in command_loop_2 (dummy=137112340) at cmdloop.c:255 #52 0x809131c in internal_catch (tag=137186628, func=0x8073504 , arg=137112340, threw=0x0) at eval.c:1315 #53 0x8072937 in initial_command_loop (load_me=137112340) at cmdloop.c:304 #54 0x808cf5d in xemacs_21_2_b18_i686_pc_linux (argc=5, argv=0x7ffff9d4, envp=0x7ffff9ec, restart=0) at emacs.c:1759 #55 0x808d6e9 in main (argc=5, argv=0x7ffff9d4, envp=0x7ffff9ec) at emacs.c:2184 uname -a: Linux beaver.jprc.com 2.2.10-ac10 #1 SMP Tue Jul 13 13:23:27 EDT 1999 i686 unknown ./configure '--with-pop' '--with-mule' '--with-png' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-linux'. Where should the build process find the source code? /home/karl/src/x/xemacs-21/xemacs-21.2.18 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 dialog boxes. Compiling in DLL 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 Jul 20 15:07:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAB13853 for xemacs-beta-out; Tue, 20 Jul 1999 15:07:38 -0400 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 PAA13850 for ; Tue, 20 Jul 1999 15:07:37 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id PAA09878; Tue, 20 Jul 1999 15:07:25 -0400 Date: Tue, 20 Jul 1999 15:07:25 -0400 From: Olivier Galibert To: Rajesh Godbole Cc: "(ding)" , xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail Message-ID: <19990720150725.A9869@nemesis.ncsl.nist.gov> Mail-Followup-To: Rajesh Godbole , "(ding)" , xemacs-beta@xemacs.org References: <8t6btd7ckdc.fsf@Corp.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <8t6btd7ckdc.fsf@Corp.Sun.COM>; from Rajesh Godbole on Tue, Jul 20, 1999 at 10:16:15AM -0700 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Tue, Jul 20, 1999 at 10:16:15AM -0700, Rajesh Godbole wrote: > > Is threading on the roadmap/TODO list? Is someone actively working on > this? IMHO it would be a very desirable feature. What for ? Most people don't care about multithreading, they only want xemacs to stop blocking while gnus reads the active file. Implementing a fully-fledged multithreading for _that_ is way overkill. OG. From owner-xemacs-beta@xemacs.org Tue Jul 20 15:16:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA14403 for xemacs-beta-out; Tue, 20 Jul 1999 15:16:34 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA14399 for ; Tue, 20 Jul 1999 15:16:32 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 116fNN-00033I-00 for xemacs-beta@xemacs.org; Tue, 20 Jul 1999 15:16:29 -0400 To: xemacs-beta@xemacs.org Subject: completions vs. space in dir name Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 20 Jul 1999 15:16:28 -0400 Message-ID: Lines: 1 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: It seems that completions won't work if a dir has a space in the name. From owner-xemacs-beta@xemacs.org Tue Jul 20 17:04:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA17965 for xemacs-beta-out; Tue, 20 Jul 1999 17:04:17 -0400 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 RAA17961 for ; Tue, 20 Jul 1999 17:04:15 -0400 Received: from btm16s.se.bel.alcatel.be (root@btm16s.se.bel.alcatel.be [138.203.33.210]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id XAA22434 for ; Tue, 20 Jul 1999 23:04:02 +0200 (MET DST) Received: from advalvas.be ([138.203.253.199]) by btm16s.se.bel.alcatel.be (8.8.8+Sun/8.8.8+SUN) with ESMTP id XAA06567; Tue, 20 Jul 1999 23:03:57 +0200 (MET DST) Message-ID: <3794E441.E4EA0112@advalvas.be> Date: Tue, 20 Jul 1999 23:04:01 +0200 From: Guido Van Hoecke X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-Beta Subject: crypt++.el and folding.el Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This error only occurs with xemacs: - XEmacs 21.2 (beta18) "Toshima" [Lucid] (i586-pc-win32) of Thu Jul 15 1999 on NEVERYON) - crypt++.el v2.87 (from ftp://ftp.cs.umb.edu/pub/misc/crypt++.el) - folding.el v2.61 (from ftp://ftp.csd.uu.se/pub/users/andersl/beta/folding.el). When I find an encrypted file that uses folding mode, I get following error: Signaling: (error "Cannot fold whole buffer -- extraneous end-fold mark") signal(error ("Cannot fold whole buffer -- extraneous end-fold mark")) byte-code("..." [kill-buffer buf signal data] 3) find-file-noselect("c:\\notes") ad-Orig-find-file("c:\\notes" nil) (setq ad-return-value (ad-Orig-find-file filename codesys)) ) (let (ad-return-value) (setq ad-return-value (ad-Orig-find-file filename codesys)) ad-return-value) ) find-file("c:\\notes") #() call-interactively(find-file-at-point) This problem does not occur with emacs (neither on unix nor on nt, using the same crypt++.el and folding.el). If I open a non-encrypted version of the file, folding occurs correctly. Guido. From owner-xemacs-beta@xemacs.org Tue Jul 20 18:03:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA19724 for xemacs-beta-out; Tue, 20 Jul 1999 18:03:56 -0400 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 SAA19721 for ; Tue, 20 Jul 1999 18:03:55 -0400 Received: (from uucp@localhost) by hqinbh2.ms.com (8.8.6/fw v1.30) id SAA19667 for ; Tue, 20 Jul 1999 18:03:53 -0400 (EDT) Received: from unknown(144.14.9.190) by hqinbh2 via smap (4.1) id xma018772; Tue, 20 Jul 99 18:03:08 -0400 Received: from sag3 (sag3.morgan.com [144.14.8.198]) by safid1.morgan.com (8.8.5/hub+ldap v2.3) with ESMTP id SAA23680 for ; Tue, 20 Jul 1999 18:03:07 -0400 (EDT) Received: (craffert@localhost) by sag3 (980427.SGI.8.8.8/sendmail.cf.client v1.05) id SAA39758; Tue, 20 Jul 1999 18:03:07 -0400 (EDT) To: XEmacs Beta List Mail-Copies-To: never X-Attribution: > Subject: [offtopic] CLI, Emacs, or IDE? X-Face: ""xJff%{>hr-{:QXl"Xk2O@@(+F]e{"%EYQiW@mUuvEsL>=mx96j12qW[%m;|:B^n{J8k?Mz[K1_+H;$v,nYx^1o_=4M,L+]FIU~[[`-w~~xsy-BX,?tAF_.8u&0y*@aCv;a}Y'{w@#*@iwAl?oZpvvv X-Y-Zippy: So this is what it feels like to be potato salad From: Colin Rafferty Date: 20 Jul 1999 18:03:06 -0400 Message-ID: Lines: 4 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Chiyoda) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Linux development: CLI, Emacs, or IDE? LinuxWorld columnist Joe Barr gets few equivocal answers from leading developers http://www.software.ibm.com/developer/library/dev-linux.html From owner-xemacs-beta@xemacs.org Tue Jul 20 19:21:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA21967 for xemacs-beta-out; Tue, 20 Jul 1999 19:21:10 -0400 Received: from cosrel2.hp.com (cosrel2.hp.com [156.153.255.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA21964 for ; Tue, 20 Jul 1999 19:21:08 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by cosrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA08517 for ; Tue, 20 Jul 1999 17:20:58 -0600 (MDT) 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 QAA06455 for ; Tue, 20 Jul 1999 16:20:07 -0700 (PDT) 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 QAA00128 for ; Tue, 20 Jul 1999 16:21:05 -0700 (PDT) Message-Id: <199907202321.QAA00128@mina.sr.hp.com> To: XEmacs Beta List Subject: tar-mode and crypt revisted Reply-To: Darryl Okahata Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Jul 1999 16:21:04 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Back in February, nbecker@fred.net had a problem where tar-mode.el and crypt.el didn't work together. Well, I'm running into the same situation (w/XEmacs 21.1.4), and, after a little debugging, I don't see how tar-mode can exist with any mode that handles compression. I must be missing something, as few people seem to have problems with tar-mode. Here's what I'm seeing when compressed tar files are read: * find-file-noselect gets called (of course) as part of the find-file process. * find-file-noselect calls "normal-mode" before running the find-file-hooks: (unless nomodes (normal-mode t) (run-hooks 'find-file-hooks)) * When tar-mode.el is loaded, it overrides the definition of "normal-mode" with it's own definition. Basically, when normal-mode is called, if the current buffer's filename matches a regexp for "tar filenames", the buffer is immediately placed into "tar-mode". In other words, "normal-mode" is turned into "tar-mode". * "tar-mode" treats the current buffer as containing a tar file, and tries to parse the current buffer. * Unfortunately, the current buffer contains compressed information, and tar-mode tries to parse the compressed file as a tar file. * An error is generated because tar-mode parses garbage (i.e., you get the "#$%^&* has size -59888002 - corrupted" message). * The find-file-hooks, which handle auto-uncompression, are never called. What am I missing, or is this a bug? -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Tue Jul 20 19:31:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA22447 for xemacs-beta-out; Tue, 20 Jul 1999 19:31:56 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA22444 for ; Tue, 20 Jul 1999 19:31:54 -0400 Received: from corpmail2.Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14060; Tue, 20 Jul 1999 16:31:50 -0700 (PDT) Received: from einstein.Corp.Sun.COM (einstein.Corp.Sun.COM [129.145.208.63]) by corpmail2.Corp.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA28767; Tue, 20 Jul 1999 16:31:50 -0700 (PDT) Received: (from rajesh@localhost) by einstein.Corp.Sun.COM (8.9.3+Sun/8.9.1) id QAA01617; Tue, 20 Jul 1999 16:31:49 -0700 (PDT) To: "(ding)" , xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <19990720150725.A9869@nemesis.ncsl.nist.gov> X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.126 From: Rajesh Godbole In-Reply-To: Olivier Galibert's message of "Tue, 20 Jul 1999 15:07:25 -0400" X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# Date: 20 Jul 1999 16:31:49 -0700 Message-ID: <8t6673eq4nu.fsf@Corp.Sun.COM> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: OG> What for ? Most people don't care about multithreading, they OG> only want xemacs to stop blocking while gnus reads the active OG> file. Implementing a fully-fledged multithreading for _that_ OG> is way overkill. if the feature becomes available, apps can be written to it, like parallel fetches with nntp/nnimap/nnml backends in gnus. multiple non-blocking apps in different frames. You build it, they'll come. From owner-xemacs-beta@xemacs.org Tue Jul 20 20:19:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA23762 for xemacs-beta-out; Tue, 20 Jul 1999 20:19:42 -0400 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 UAA23757 for ; Tue, 20 Jul 1999 20:19:39 -0400 Received: by crystal.WonderWorks.COM id QQgytd24320; Tue, 20 Jul 1999 17:19:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14229.4630.800418.663817@crystal.WonderWorks.COM> Date: Tue, 20 Jul 1999 17:19:34 -0700 (PDT) From: Kyle Jones To: Rajesh Godbole , xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail In-Reply-To: <8t6btd7ckdc.fsf@Corp.Sun.COM> References: <8t6btd7ckdc.fsf@Corp.Sun.COM> X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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've dropped the ding list dropped from this thread. Rajesh Godbole writes: > Is threading on the roadmap/TODO list? Is someone actively working on > this? IMHO it would be a very desirable feature. For my purposes, running multiple XEmacs processes works just as well. From owner-xemacs-beta@xemacs.org Tue Jul 20 20:37:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA24186 for xemacs-beta-out; Tue, 20 Jul 1999 20:37:36 -0400 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA24183 for ; Tue, 20 Jul 1999 20:37:33 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id UAA02748; Tue, 20 Jul 1999 20:37:08 -0400 (EDT) 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 RAA12091; Tue, 20 Jul 1999 17:36:21 -0700 (PDT) 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 RAA00606; Tue, 20 Jul 1999 17:37:13 -0700 (PDT) Message-Id: <199907210037.RAA00606@mina.sr.hp.com> To: XEmacs Beta List , xemacs-patches@xemacs-org Subject: Re: tar-mode and crypt revisted [ patch included ] Reply-To: Darryl Okahata In-reply-to: Your message of "Tue, 20 Jul 1999 16:21:04 PDT." <199907202321.QAA00128@mina.sr.hp.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Tue_Jul_20_17:37:12_1999-1" Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 1999 17:37:12 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Tue_Jul_20_17:37:12_1999-1 Content-Type: text/plain; charset=US-ASCII I wrote: > Back in February, nbecker@fred.net had a problem where tar-mode.el > and crypt.el didn't work together. Well, I'm running into the same > situation (w/XEmacs 21.1.4), and, after a little debugging, I don't see > how tar-mode can exist with any mode that handles compression. OK, after more digging, I think I've found the problem, and it's a bug in tar-mode. I don't understand why more people aren't encountering this problem, though. In a nutshell: Basically, with compressed tarballs, tar-mode is being called before the tarball is uncompressed. This appears to be caused by `tar-regexp' matching compressed file names; tar-regexp should only match uncompressed file names. Unabridged version: The twisty path is convoluted, but here's what should be happening (this is for crypt.el, but the proposed fix also works for jka-compr.el): * find-file-noselect gets called (of course) as part of the find-file process. * find-file-noselect calls "normal-mode" before running the find-file-hooks: (unless nomodes (normal-mode t) (run-hooks 'find-file-hooks)) * When tar-mode.el is loaded, it overrides the definition of "normal-mode" with it's own definition: tar-normal-mode. Basically, when tar-normal-mode is called, if the current buffer's filename matches a regexp ("tar-regexp") for tar filenames, the buffer is immediately placed into "tar-mode". In other words, "normal-mode" is turned into "tar-mode". ***** This is where the error is occurring ***** The compressed buffer should not be placed into tar-mode at this time. This error is occurring because tar-regexp will match the names of compressed files; tar-regexp should only match the names of uncompressed tar files. * At this point, tar-normal-mode should think that the current buffer is not a tarball, and should call the old definition of normal mode. * The find-file-hooks are then called. Eventually, the buffer gets uncompressed, and the uncompression code calls set-auto-mode, which calls tar-mode and parses the just-uncompressed tarball correctly. It's interesting to note that tar-regexp isn't required for either crypt.el or jka-compr.el to work; for both of these compression modules, the only important thing is that tar-regexp NOT match the compressed file name. In the case of crypt.el, tar-mode is set via set-auto-mode when the crypt-find-file hook is called. In the case of jka-compr.el, tar-mode is also set via set-auto-mode, but from the call to the old normal-mode function. A valid setting for tar-regexp is only required if you load uncompressed tarballs. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. --Multipart_Tue_Jul_20_17:37:12_1999-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="ChangeLog" Content-Transfer-Encoding: quoted-printable 1999-07-20 Darryl Okahata * tar-mode.el: `tar-regexp' must only match the names of uncompressed tar files. If it matches the names of compressed tar files, tar-mode will attempt to parse the compressed tar file as an uncompressed tar file, causing an error. Note that this will not affect either crypt.el nor jka-compr.el, as they will properly uncompress a buffer before entering tar-mode. --Multipart_Tue_Jul_20_17:37:12_1999-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Tue_Jul_20_17:37:12_1999-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="diffs" Content-Transfer-Encoding: quoted-printable *** tar-mode.el.orig Tue Jul 20 16:49:51 1999 --- tar-mode.el Tue Jul 20 16:40:49 1999 *************** *** 1310,1317 ;;; Patch it in. = ;;;###autoload ! (defvar tar-regexp "\\.\\(tar\\|tgz\\|tar\\.gz\\)\\'" ! "The regular expression used to identify tar file names.") = ;;;###autoload (setq auto-mode-alist --- 1310,1322 ----- ;;; Patch it in. = ;;;###autoload ! (defvar tar-regexp "\\.tar$" ! "The regular expression used to identify tar file names. ! Note that this regular expression must not match compressed tar file ! names; if it does, tar-mode will attempt to parse the compressed tar ! file as an uncompressed tar file, which will generate an error. This ! is not a problem, as other modules that handle compression will ! uncompress the buffer and call `tar-mode' appropriately.") = ;;;###autoload (setq auto-mode-alist --Multipart_Tue_Jul_20_17:37:12_1999-1-- From owner-xemacs-beta@xemacs.org Wed Jul 21 00:25:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA30817 for xemacs-beta-out; Wed, 21 Jul 1999 00:25:50 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA30811 for ; Wed, 21 Jul 1999 00:25:45 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA29567 for ; Wed, 21 Jul 1999 13:25:43 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@crystal.WonderWorks.COM> X-Attribution: sb From: SL Baur In-Reply-To: Kyle Jones's message of "Mon, 19 Jul 1999 13:50:22 -0700 (PDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 21 Jul 1999 13:25:34 +0900 Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Kyle Jones writes in xemacs-beta@xemacs.org: ... > Cool. The next thing to figure out now is why Steve can duplicate > the problem even when allow-deletion-of-last-visible-frame is t. I can't. What I cannot duplicate is Hrvoje's results with WindowMaker. Regardless of the value of `allow-deletion-of-last-visible-frame', I can C-x 5 0 a frame when another frame is open in another workspace, i.e. WindowMaker always does the Right Thing. I just retested with CDE and if I manually set the value to t, then everything works as expected. -- $B5c$-LL$KK*(B (When it rains, it pours) From owner-xemacs-beta@xemacs.org Wed Jul 21 02:19:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA01151 for xemacs-beta-out; Wed, 21 Jul 1999 02:19:05 -0400 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 CAA01148 for ; Wed, 21 Jul 1999 02:19:02 -0400 Received: from brabantio.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 IAA13478; Wed, 21 Jul 1999 08:19:00 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id IAA29908; Wed, 21 Jul 1999 08:18:52 +0200 To: "(ding)" Cc: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.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: 21 Jul 1999 08:18:52 +0200 In-Reply-To: Rajesh Godbole's message of "20 Jul 1999 10:16:15 -0700" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA01149 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "argv" == Rajesh Godbole writes: argv> Is threading on the roadmap/TODO list? Is someone actively working on argv> this? IMHO it would be a very desirable feature. This is not a feature at all: it would constitute an overhaul affecting just about every part oft the current system. As far as I know, no. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 21 03:13:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA02828 for xemacs-beta-out; Wed, 21 Jul 1999 03:13:35 -0400 Received: from leonardo (leonardo.parades.rm.cnr.it [150.146.37.11]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id DAA02824 for ; Wed, 21 Jul 1999 03:13:29 -0400 Received: from copernico.parades.rm.cnr.it by leonardo (SMI-8.6/SMI-SVR4) id JAA12111; Wed, 21 Jul 1999 09:08:37 +0200 Received: by copernico.parades.rm.cnr.it (SMI-8.6/SMI-SVR4) id JAA00828; Wed, 21 Jul 1999 09:10:19 +0200 Date: Wed, 21 Jul 1999 09:10:19 +0200 Message-Id: <199907210710.JAA00828@copernico.parades.rm.cnr.it> From: Marco Antoniotti To: vroonhof@math.ethz.ch CC: willd@pindar.com, ilisp@naggum.no, xemacs-beta@xemacs.org In-reply-to: (message from Jan Vroonhof on 20 Jul 1999 11:36:18 +0200) Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 Reply-to: marcoxa@parades.rm.cnr.it References: <379339E8.7CCEC054@pindar.com> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Delivery-Date: Tue, 20 Jul 1999 17:03:43 +0200 > Sender: vroonhof@math.ethz.ch > Cc: ilisp@naggum.no, xemacs-beta@xemacs.org > From: Jan Vroonhof > Date: 20 Jul 1999 11:36:18 +0200 > User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) > Content-Type: text/plain; charset=us-ascii > content-length: 1683 > > Marco Antoniotti writes: > > > > Having installed the inferior lisp package with xemacs 21.1-p3, I cannot get > > > ilisp to work with CLISP. > > > > > If anybody has any clue about what is happening with XEmacs/ILISP, > > please let me know or write to ILISP mailing list. (for the time > > being, but not much longer, ). > > Well. I am not sure whose problem this is exactly, but for me the > problem seems to be with something (i.e. either XEmacs or Clisp[1]) not > flushing pipe buffers correctly. The patch below "fixes" the problem > for me. I can run Clisp now and evaluate "(+ 1 2)", define a function > and have it complete the function name in a call. Thanks. I will put it in with a conditional. > > I have no idea where the concat problems come from, I did not see > them. Ok. > > Jan > > P.S. I have the feeling ilisp could do with a few '(defstruct's. You are *RIGHT*! Most Elisp packages could use more DEFSTRUCTs. And ILISP is no exception. As you may noticed I slipped in a "(require 'cl)" in the package :) Apart from that, a rewriting of a lot of ILISP is quite an undertaking and I do not have that much time to tackle it. Here is one thing that I'd like to see. Actually, let's have a REQUEST FOR IMPLEMENTATION for it. :) Next message. > > Footnotes: > [1] My guess would be XEmacs. It seems suspiciously like the process > bug on NT that makes it fail to recognize the end of ftp transfers > under efs. I wouldn't be surprised. Marco -- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa From owner-xemacs-beta@xemacs.org Wed Jul 21 03:20:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA03093 for xemacs-beta-out; Wed, 21 Jul 1999 03:20:35 -0400 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 DAA03089 for ; Wed, 21 Jul 1999 03:20:33 -0400 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 DAA28714 for ; Wed, 21 Jul 1999 03:26:25 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id JAA27961; Wed, 21 Jul 1999 09:20:25 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: completions vs. space in dir name 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: 21 Jul 1999 09:18:22 +0200 In-Reply-To: nbecker@fred.net's message of "20 Jul 1999 15:16:28 -0400" Message-ID: Lines: 19 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "nbecker" == nbecker writes: nbecker> It seems that completions won't work if a dir has a space nbecker> in the name. For which (emacs-version)? Works fine for me in "XEmacs 21.2 (beta18) \"Toshima\" [Lucid] (i586-pc-win32) of Thu Jul 15 1999 on ZJ75T" Completing with c:\prog SPACE SPACE mi SPACE SPACE leads c:\Program Files\Microsoft Office\ for me (shudder!). Adrian From owner-xemacs-beta@xemacs.org Wed Jul 21 03:28:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA03492 for xemacs-beta-out; Wed, 21 Jul 1999 03:28:11 -0400 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 DAA03489 for ; Wed, 21 Jul 1999 03:28:10 -0400 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 DAA29064; Wed, 21 Jul 1999 03:33:57 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id JAA27984; Wed, 21 Jul 1999 09:27:57 +0200 (MET DST) To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: XEmacs Beta List Subject: Re: [patch] "config.values" belongs in --docdir References: <873dyidaym.fsf@bittersweet.sysc.pdx.edu> 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 Jul 1999 09:25:54 +0200 In-Reply-To: karlheg@cathcart.sysc.pdx.edu's message of "20 Jul 1999 18:54:09 -0700" Message-ID: Lines: 20 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Karl" == Karl M Hegbloom writes: Karl> Against XEmacs 21.1.4. I have applied this patch to the Debian Karl> package I am creating... I discovered the inconsistency while Karl> setting up the rule command set that stages the editor-binary Karl> packages prior to packing. Karl> I imagine it's good for 21.2 as well... real tough hand edit if the Karl> patch doesn't apply. ;-) Hello Karl, can you please send me a note in case you get this patch approved? I will have to make some adjustments for the Windows NT native build then. Thanks, Adrian From owner-xemacs-beta@xemacs.org Wed Jul 21 03:39:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA04021 for xemacs-beta-out; Wed, 21 Jul 1999 03:39:24 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA04017 for ; Wed, 21 Jul 1999 03:39:21 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id QAA14079 for ; Wed, 21 Jul 1999 16:39:19 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: package standards version 1.1 X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 21 Jul 1999 16:39:09 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In order to fix the hierarchy installation problem exhibited by the lookup package, I'm fixing all the `distribution' headers to read either `xemacs' or `mule'. This will necessitate a global update and a standards version change to let the package UI stuffs know whether or not that field is reliable. If there's anything else that someone needs changed regarding info in the package-info.in files, now would be a good time to request it ... -- $B2LJs$O?2$FBT$F(B (All things come to those who wait) From owner-xemacs-beta@xemacs.org Wed Jul 21 03:47:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA04333 for xemacs-beta-out; Wed, 21 Jul 1999 03:47:07 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA04329 for ; Wed, 21 Jul 1999 03:47:04 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id QAA14604 for ; Wed, 21 Jul 1999 16:47:02 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: [patch] "config.values" belongs in --docdir References: <873dyidaym.fsf@bittersweet.sysc.pdx.edu> X-Attribution: sb From: SL Baur In-Reply-To: Adrian Aichner's message of "21 Jul 1999 09:25:54 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 21 Jul 1999 16:46:53 +0900 Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes in xemacs-beta@xemacs.org: >>>>>> "Karl" == Karl M Hegbloom writes: Karl> Against XEmacs 21.1.4. I have applied this patch to the Debian Karl> package I am creating... I discovered the inconsistency while Karl> setting up the rule command set that stages the editor-binary Karl> packages prior to packing. Karl> I imagine it's good for 21.2 as well... real tough hand edit if the Karl> patch doesn't apply. ;-) > Hello Karl, > can you please send me a note in case you get this patch approved? > I will have to make some adjustments for the Windows NT native build > then. Go ahead. The patch has been approved. -- $B6}F~$l6}=P$7(B (Garbage in, Garbage out) From owner-xemacs-beta@xemacs.org Wed Jul 21 03:55:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA04595 for xemacs-beta-out; Wed, 21 Jul 1999 03:55:18 -0400 Received: from leonardo (leonardo.parades.rm.cnr.it [150.146.37.11]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id DAA04592 for ; Wed, 21 Jul 1999 03:55:16 -0400 Received: from copernico.parades.rm.cnr.it by leonardo (SMI-8.6/SMI-SVR4) id JAA12168; Wed, 21 Jul 1999 09:50:16 +0200 Received: by copernico.parades.rm.cnr.it (SMI-8.6/SMI-SVR4) id JAA00857; Wed, 21 Jul 1999 09:51:56 +0200 Date: Wed, 21 Jul 1999 09:51:56 +0200 Message-Id: <199907210751.JAA00857@copernico.parades.rm.cnr.it> From: Marco Antoniotti To: vroonhof@math.ethz.ch CC: toy@rtp.ericsson.se, willd@pindar.com, ilisp@naggum.no, xemacs-beta@xemacs.org In-reply-to: (message from Jan Vroonhof on 20 Jul 1999 18:23:18 +0200) Subject: Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 Reply-to: marcoxa@parades.rm.cnr.it References: <379339E8.7CCEC054@pindar.com> <4npv1ngw3o.fsf@rtp.ericsson.se> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Delivery-Date: Tue, 20 Jul 1999 18:20:46 +0200 > Cc: Marco Antoniotti , willd@pindar.com, > ilisp@naggum.no, xemacs-beta@xemacs.org > From: Jan Vroonhof > Date: 20 Jul 1999 18:23:18 +0200 > User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/21.1 (Acadia) > Content-Type: text/plain; charset=us-ascii > content-length: 384 > > Raymond Toy writes: > > > One other thing: I think you're supposed to use the -I option when > > running clisp with ilisp. I'm vaguely remember the -I option being > > added exactly for this purpose. I causes clisp to flush it's buffers > > at the right time, or something like that. > > Aha.. That's it. Would be nice if the clisp-hs-program had this as a > default. It does now. Cheers -- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa From owner-xemacs-beta@xemacs.org Wed Jul 21 04:41:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA06262 for xemacs-beta-out; Wed, 21 Jul 1999 04:41:36 -0400 Received: from mail.rhein-zeitung.de (mail.rhein-zeitung.DE [195.189.135.96]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA06259 for ; Wed, 21 Jul 1999 04:41:34 -0400 Received: from stargate.rhein-zeitung.de (stargate.rhein-zeitung.DE [195.189.135.111]) by mail.rhein-zeitung.de (8.9.2/8.9.2) with ESMTP id KAA21390 for ; Wed, 21 Jul 1999 10:40:31 +0200 (CEST) Received: (from ograf@localhost) by stargate.rhein-zeitung.de (8.8.8/8.8.8) id KAA01199; Wed, 21 Jul 1999 10:43:40 +0200 To: xemacs-beta@xemacs.org Subject: whoops... sparc64-unknown-linux failes X-Face: [8r}|"6`WFUT0kiC9dBT%edO~lI5Gwog0Z@Cl=Inx|2F=+DjY#0nGtclM)9lU c/8JJ%b&&^:&pWh&nYlQbGSk=WdL^%f!<6a:?n)V_snw7Zc+AW10az=||e8Kv 1PV49Qe64*68G2`)M8O$mlLQ\!O}$d8]T\L?i@$;=WA~0B[k)O.^T'x?O^=EX %=gt6(:hG!-|%$EZGq-Dn6r%N6xqOC4voztttHxOMp!2$o+qPAcT2k&dgO~`% kVcW7C<3hK[g9vVpk'#B2(f"pN,jBh` Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Oliver Graf Date: 21 Jul 1999 10:43:39 +0200 Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.2(beta13) - "Demeter" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi there! Just converted my ultrasparc to a linux box and started to recompile all the things I need to work (i.e. XEmacs), but configure tells me it can not build it on this architecture. true? do I have to reinstall slowlaris? ;-) Regards, Oliver. From owner-xemacs-beta@xemacs.org Wed Jul 21 04:57:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA06497 for xemacs-beta-out; Wed, 21 Jul 1999 04:57:43 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA06494 for ; Wed, 21 Jul 1999 04:57:40 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id RAA20338 for ; Wed, 21 Jul 1999 17:57:37 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: whoops... sparc64-unknown-linux failes References: X-Attribution: sb From: SL Baur In-Reply-To: Oliver Graf's message of "21 Jul 1999 10:43:39 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 21 Jul 1999 17:57:28 +0900 Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Oliver Graf writes in xemacs-beta@xemacs.org: > Hi there! > Just converted my ultrasparc to a linux box and started to recompile > all the things I need to work (i.e. XEmacs), but configure tells me > it can not build it on this architecture. true? No. Stephen Turnbull has built a Sparc Linux XEmacs, I believe. > do I have to reinstall slowlaris? ;-) The likeliest cause is that a regexp is failing in configure. Maybe this one: dnl Straightforward machine determination case "$canonical" in sparc-*-* ) machine=sparc ;; try changing it sparc*-*-* and see if that helps. You may need to do some s & m tweaking, but it should work, I think. Be sure to send us patches when you get everything sorted out ... :-) -- $B1+9_$C$FCO8G$^$k(B (Adversity builds character) From owner-xemacs-beta@xemacs.org Wed Jul 21 05:47:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA07381 for xemacs-beta-out; Wed, 21 Jul 1999 05:47:52 -0400 Received: from mail-gw3.pacbell.net (mail-gw3.pacbell.net [206.13.28.55]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA07377; Wed, 21 Jul 1999 05:47:46 -0400 Received: from 666.com (adsl-63-193-114-238.dsl.snfc21.pacbell.net [63.193.114.238]) by mail-gw3.pacbell.net (8.9.3/8.9.3) with ESMTP id CAA29716; Wed, 21 Jul 1999 02:47:39 -0700 (PDT) Message-ID: <37959663.6FD09689@666.com> Date: Wed, 21 Jul 1999 02:44:03 -0700 From: Ben Wing X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 To: Andy Piper CC: xemacs-beta@xemacs.org, wmperry@aventail.com Subject: Re: Tabs 'n widgets screenshot References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> Content-Type: multipart/mixed; boundary="------------48BFC390E180756CEFC37DD6" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This is a multi-part message in MIME format. --------------48BFC390E180756CEFC37DD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is real cool, but looking at this, it's clear that it doesn't look the way tab widgets are supposed to work. In particular, of course, they should have the proper borders around the stuff displayed. I've attached a screen shot of a typical Windows dialog box with a tab widget in it. The problem lies with this "expanded gutter" concept. Tabs are *NOT* extra graphical junk placed in the gutters of a buffer but are GUI objects with *children* inside of them. This is the right way to do things, and you would need no extra gutter functionality at all for this. You just need to implement the concept of GUI objects containing other GUI objects within them. One such GUI object needs to be a "Emacs-text" GUI object, which is an Emacs window and contains a buffer within it. At this level, you need not be concerned with the complexities of geometry layout. The only change that needs to be made in the overall strategy of frames, windows, etc. is that windows need not be exactly contiguous and tiled, as long as they are contained within a frame. Or more specifically: Given that you could always split a window contained inside a GUI object, we just need to expand things so that each frame has *multiple* hierarchies of windows in it, rather than just one. A hierarchy of windows can nest inside of another window -- e.g. I put a tab widget or a text widget inside of a buffer. This should be easy to implement -- just change things so there are multiple hierarchies of windows where there are one, each (except the top-level one) being rooted inside some other window. Anyone willing to implement this? Andy? Andy Piper wrote: > ... for anyone who's interested. > > andy > > ------------------------------------------------------------------------ > > Name: Image2.jpg > Image2.jpg Type: JPEG Image (image/jpeg) > Encoding: base64 > > ------------------------------------------------------------------------ > > -------------------------------------------------------------- > Dr Andy Piper > Senior Consultant Architect, BEA Systems Ltd --------------48BFC390E180756CEFC37DD6 Content-Type: image/jpeg; name="Internet-Properties.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Internet-Properties.jpg" /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CAHEAZYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDpPj78XPiJ4R+Klj4M8DaFp+rvdaXDdR2/ 9mPc3DuQ5faEIJAVC3Q45PTp5KP2sPiZ/wBA7wt/4Lm/+Lr17xB/yf14G/7ALf8ApLd1wHwl +Hfw617wl8KtK1bwp5+qeNf7aW81dNQuElt1tBNsMcYby9+fK5ZSuEIKtuyPssJTwNPDxdal f3U79ftt9VsoHNJyb0f9aGCP2r/iWf8AmH+Fv/Bc3/xdPH7VvxLI/wCQf4W/8Fzf/F12k3h3 wt411L4fHW9N/tGztPhUJtPNoZZG1O/tl2tZqqSp5zw/O5hiaOTcSHbbgDnvF3gPwHpvgj4h a3a+DLyx1HStG0SWCz1O5ZGsbi7kkjlcQxXMjx5Ty5FiuHd0Y8gqQD2Qhljai6Gun4y5e66/ 1czftO5nD9qv4lEf8g/wv/4Lm/8Ai6UftVfEk/8AMP8AC/8A4Lm/+LrtfHXwu+FMniHxnolt oP8Awi9n4V1Hw9FLqUeqys0kd9MFuGkM7NGiLHICOMho9xYqSo3vCfhTwR4M+OHhe5sfDOo+ GJ08S6jpltc3p+zW99B9klRAiT3Us0x3mILOixxv5u3aGKisnLLORyjQ1te3/bqkur3TXcVq t/iPOtF/aU+LetalFpuj+H9D1G+mz5VtaaRJLK+AWO1VYk4AJOB0BNXfEPx/+Nvhwwf8JF4O 0/R/tG7yPt+hTQebtxu272Gcblzjpketcv8AsqxzQ/tS6HDcab/ZcyXF+sljtkX7KwtZwYsS EuNp+XDEtxySa2fgfqfhLxrr/hn4Qf8ACK3aeGLnWLvWL1b/AFUzzzTLYSJGqvDHDsQbMkYJ JxyACDvXwmEpVJWoJxjFSfe3vef935+Rmpza+LV6fkRD9qX4j/8APh4Y/wDBcf8A4ulH7Ufx HP8Ay4eGf/Bef/i61/hd8PfA/iTw14T1K88OQvYa5JrT+I9Uhu7gJ4dECFrdFfzPLhAXaw+0 iQtuySQRU+q/DPwjF4ES9m8Kf2dZH4bwa6PEH2i5XdqxK7bfe8hg/eZA8oJuO/5SOMTKGVxn yOjre3Tu138vUm9dq/MYY/ah+Ix/5cfDP/gvP/xdWLL9pb4n3t5BZ2ek+H7m5uJFihhi0xne R2OFVVD5JJIAA611viH4XfDWz1iy0yy8MatNpx1fQ7az1rzfLttSjuGjEq+c90RdeYjO2bWG MxleflyaWHR/D154W1LwVaaBaSaVa/F6CyubKGe4ZrOzIS3WZm8wuvmFGj3uSpaRwoBC7cv+ EyUU4UP6+/z2E/bp6yOTvP2lfidZXk1ne6T4ftrmCRopoZdMZHjdThlZS2QQQQQelRj9p34i H/lx8Nf+C8//ABddkvwv+G1vazEeGNW1aJ9X162v5rGXd/ZMdtK6wq1xJcxQ222MJIDcLKZM noCM8B4m8GaDafs+6V4ptfDf2a/k8gS38mrBmld3l+ZMFoZkYKVMCiOeBosvvUlq1pU8sqNJ Ud2l0318/IznLER15i+P2m/iIf8Alx8N/wDgvP8A8XTh+0z8Qz/y5eG//Bef/i68QWpFr0/7 GwP/AD6RyfW638x7aP2mPiF/z5eG/wDwXn/4unD9pb4hH/ly8Of+C8//ABVeJinrS/sfA/8A PpEPGV/5j2sftKfEH/ny8Of+C8//ABVOH7SXxA/58/Dv/gvP/wAVXiop4o/sfA/8+kQ8bX/m Z7SP2kfiAf8Alz8O/wDgAf8A4qnD9o/x+f8Alz8O/wDgAf8A4qvGFp60v7HwP/PpEPHYj+dn sw/aO8fn/lz8Pf8AgB/9lTh+0Z4+P/Lp4e/8AP8A7KvGlp60f2Pgf+fSIeOxH87PZB+0V49/ 59PD/wD4Af8A2VOH7RPj0/8ALp4f/wDAD/7KvHBT1o/sfA/8+0Q8wxP87PYh+0P48P8Ay6eH /wDwA/8AsqcP2hfHf/ProH/gB/8AZV48tPFL+x8D/wA+0R/aGJ/nZ7AP2hPHZH/HroH/AIAf /ZU4ftBeOj/y66D/AOAH/wBlXkC9KkWj+x8D/wA+0R/aOK/nZ66P2gPHJ/5ddB/8AP8A7KnD 4/8Ajkn/AI9tB/8AAH/7KvI1p69aP7HwX/PtEPMsV/Oz1sfH3xx/z7aF/wCAP/2VOHx78b/8 +2hf+AP/ANlXkwp4pf2Rgv8An2iXmeL/AOfjPVx8evG5/wCXbQv/AAB/+vTx8ePGxH/Hvof/ AIA//XrydakXpR/ZGC/59oz/ALUxf/Pxnqw+O3jUj/j30P8A8AR/jSj46+NT/wAu+if+AI/x rytelPWj+yMF/wA+0Q81xn/Pxnqg+OfjQ/8ALvon/gCP8acPjj4zJ/1Gif8AgCP8a8sWpF60 v7IwX/PtEPNsZ/z8Z6iPjh4z/wCeGi/+AI/xpR8bvGR/5YaL/wCAI/xrzAU9aP7IwX/PtEPN 8b/z8Z6cPjb4yP8Ayw0b/wAAh/jTh8a/GP8Azw0b/wAAh/jXmS08Uv7IwX/PtEPOMd/z8Z6Y PjT4wP8Ayx0b/wAAh/jV7Q/ix421fWbLSrePQ0mvLiO3jaSzAUM7BQTjJxk+hryha6H4b/8A JQvDn/YWtf8A0atZ1sqwcKcpKmtEyqWbY2dSMXVerR7Nruv+MNBthc654x+G2lwNJ5QkvGaF S+CduWQDOATj2NZXi/xz4w8N+FovEcut+C9Rsp5beK3/ALPgeUzec6qjKSgUr8wbOcYHGTgH G+PkVrp2iXPjOK4sdP1vQzKum6leiZ4rM3DrDIxjiDbyVOBlGAbBIxmub+KHhzTPCPwa0nw5 o6yrZWWq2KxmV97sTdKzMx9WZmJxgc8ADAr4ijiVKpGLpx1a6H3dbCuFOUlUlon1PWrC++JF 3ptnfHVfBMC3dtHcJHNBIHCuoYZxGRnB7E065vviFbW0txNr3gRY4kLuRBKcADJ4EeT+Fcj8 WLW0vfhbodvNomp6veNpmn/2bHpuUuIbvyl8qZJgCLfYeTK3yqMg7s7W5TwFpet6dceJD45t Lq+8XPp5zriqZLO4tNvywwMERYdrZ3xEBmb958wI2lbEqNSUVCOjfQKOFc6cZOpLVLqeeftN +OdT8dfBnw7qt75UcUurb44oohGMG33KWAJyw3kdTjJx1OSuT+Jf/JunhL/r/j/9I0orHGxj GvJRVl/wDbAylLDxcnd/8E9t/ai+EXiTx98SYNY0e90mC3h0u3tmW7lkVyw3MSAqMMYcd/Wv Kx+zZ45/6Cvhz/wIm/8AjVfYXif/AJDMn/XKL/0WtUba3uLlzHbQSzOBkrGhYgevFehh8/xm HpKlBqy8jaVKMndnyaP2bvHI/wCYr4c/8CJv/jVOH7N/jgD/AJCvh3/wIm/+NV9cf2Tqv/QM vf8Avw3+FH9k6r/0DL3/AL8N/hW3+s2O7r7ifq8D5JH7OPjcD/kK+Hf/AAIm/wDjVOH7Ofjc f8xTw7/4ETf/ABqvrT+ydV/6Bl7/AN+G/wAKP7J1X/oGXv8A34b/AAo/1lx3dfcL6tTPk0fs 6eNh/wAxTw9/4ETf/GqcP2dvGoP/ACFPD3/gRN/8ar6w/snVf+gZe/8Afhv8Kh+yXX2r7L9m m+0f88vLO/pnp16c0f6y47uvuF9UpnyuP2ePGv8A0FPD/wD4ETf/ABqtjxH8Hfid4j/sz+2f EHh+6/svT4tNs/ndPKtos7E+WEZxuPJyTnkmvpb+ydV/6Bl7/wB+G/wo/snVf+gZe/8Afhv8 Kl8R41tN2uvIX1OnsfKo/Z78aD/mJ+H/APv/ADf/ABqlH7PnjP8A6Cegf9/5v/jVfVP9k6r/ ANAy9/78N/hR/ZOq/wDQMvf+/Df4U/8AWXHd19wvqNI+WR+z94yH/MT0D/v/ADf/ABqlHwA8 ZD/mJ6D/AN/5f/jVfUv9k6r/ANAy9/78N/hTo9Ivi2biFrOIDmW5VkQfjjk+w/xo/wBZcd3X 3E/UKJ8tD4A+MR/zEtB/7/y//GqePgH4wH/MS0H/AL/y/wDxuvqb+yY/+gxpn/fx/wD4mj+y Y/8AoMaZ/wB/H/8AiaP9Zcd3X3C/s+ifLQ+AvjD/AKCWhf8Af+X/AON08fAfxeP+YloX/f8A l/8AjdfUX9kx/wDQY0z/AL+P/wDE0f2TH/0GNM/7+P8A/E0f6y47uvuF/ZtA+Xh8CPF3/QR0 P/v/AC//ABunD4FeLv8AoI6H/wB/5f8A43X0/wD2TH/0GNM/7+P/APE1W1S2tdO0y61CfVrJ 4bWF5pFhEkjlVUsQqqhLHA4A5NH+smO7r7hf2ZQ8/vPmsfAvxaP+Yjof/f6X/wCN04fA3xYP +Yjon/f6X/43X0fYWl1f2NvfWNtNdWlzEs0E8MZeOVGGVdWHDKQQQRwQam/snVf+gZe/9+G/ wo/1kx3dfcL+y8P2f3nzYPgf4sH/ADENE/7/AEv/AMbpw+CHisf8xDRf+/0v/wAbr6R/snVf +gZe/wDfhv8ACj+ydV/6Bl7/AN+G/wAKX+smO7r7hf2Th+z+8+cB8EvFX/QQ0X/v9L/8bpw+ Cniof8xDRf8Av9L/APG6+jf7J1X/AKBl7/34b/Cj+ydV/wCgZe/9+G/wo/1kx3dfcT/ZGG7P 7z50HwV8Uj/l/wBG/wC/0v8A8bpw+C/in/n/ANG/7/Sf/G6+if7J1X/oGXv/AH4b/Cj+ydV/ 6Bl7/wB+G/wo/wBY8d3X3C/sfDdn9588D4MeKAP+P/Rv+/0n/wAbpw+DXicf8v8Ao/8A3+k/ +N17/dWl1a7ftNtNBuzt8yMrnHXGam/snVf+gZe/9+G/wo/1jx3dfcL+xcL2f3nz4Pg54nH/ AC/aP/3+k/8AjdOHwd8TA/8AH9pH/f2T/wCN19A/2Tqv/QMvf+/Df4Uf2Tqv/QMvf+/Df4Uf 6x43uvuF/YmF7P7zwAfCDxL/AM/2kf8Af2T/AOIpw+EPiX/n+0n/AL+yf/EV77/ZOq/9Ay9/ 78N/hR/ZOq/9Ay9/78N/hR/rHje6+4X9h4Ts/vPBB8IvEg/5fdJ/7+yf/EU4fCTxGB/x+6T/ AN/ZP/iK95/snVf+gZe/9+G/wqG6tLq12/abaaDdnb5kZXOOuM0f6x43uvuF/YOE7P7zw4fC bxGB/wAfulf9/ZP/AIinD4T+Ih/y+6V/39k/+Ir3X+ydV/6Bl7/34b/Cj+ydV/6Bl7/34b/C j/WPG919xP8AYGD7P7zwwfCnxEP+X3Sv+/sn/wARTh8K/EIP/H5pf/f2T/4ivcf7J1X/AKBl 7/34b/Cj+ydV/wCgZe/9+G/wpf6x43uvuF/q9g+z+88QHws8Qf8AP5pf/f2T/wCIpw+F3iAf 8vmmf9/X/wDiK9t/snVf+gZe/wDfhv8ACj+ydV/6Bl7/AN+G/wAKP9Ysb3X3C/1dwXZ/eeKD 4Ya+P+XzTP8Av4//AMRSj4Y69/z96Z/38f8A+Ir2r+ydV/6Bl7/34b/CqkiPG7RyKyOpIZWG CCOxo/1ixvdfcL/VvA9n955GPhnrw/5e9N/7+P8A/EVNZfD7xPY3cN5Y6pYWt3BIssE6MWaJ 1OVYBoypIIBwQRxyDXqlFKXEOMkrNr7gXDmCTuk/vPK28EfEtmLN8SNSJJySZouf/JeqmpfD XxvqkMdvq3je5v7ZJ45/Imlj2M0bh1ziAHqo6EV6/RXBHGuLuoR+49CWBUk06kvvPL7rwb8S p5FI+IV5BHHGkUMMTxKkUaKFRFH2foAAOck9SSSTUEngT4jyI0cnxFv3RgQytJEQQex/0evV 6KJY1yd3CP3BHAqKSVSX3nyv+0d4Zm8I/B/w9os00coh1TEbIxbKC32jJIHPy+lFdR+25/yI +hf9hI/+imormrVZVZuct2dNGjGjBQjsj6T8T/8AIZk/65Rf+i1pyO8PhlJImaN3vGDMpwSA i4B+mT+Zpvif/kMyf9cov/Ra0P8A8itF/wBfr/8AoC1manGXHirxLNq+pW2i6Ul/a6XOtvdt LqbQzvIYo5iIY/LKP8kqAF5IwWyDtA3HYm8SWUGswaLNr1vHqlwhkhsnvAJ5EG7LLGTuI+Vu QP4T6GvP/H3gjWNcsfE+lWll4du7fXHN3FdakXZ7G4FoluNkQjIJxECJQ6lPMJ2Nsw9rUPBF 3P43udU2xT2V5qNtqLvJqt3GIHgSFQn2SMiKY5t1YSOwwXGVYRgMAdjbeLNKuYbqa38S2U0V nAlxdPHfKywROm9JHIb5VZPmDHgjkcUWfizSr37B9j8S2Vx/aPmfYfKvlf7V5f8ArPLw3z7c HO3OO9edzfDO8PhTwvpED2NudG0cW8628skAmuVubK4JV0UMgdrWTMo+dTIGCscir2ieCdZs r+TUbe5tdJvJ7HUIjKt5calJBPMLNYpDJcczbRa5IIQAbECnBcgHUL45srufRxour2+sW+o6 i9g1xaXwkSF1tpZzkqSCcRAbcj74PsU8GTzL4++Ie2aRc2ujSnDH77/alZvqVhiBPcRoP4Rj j/D3gfXbfxra69dpa20EM9u5ibXbvUpCsdvfxkiSdARlruPCDjCuepwes8H/API/fEL/AK8d E/8AQr2gCXVvFOuxa/LpOj6edReztYry8El+YH8uV5VRYQVKySHyZOHaNR8nzckrpzeJLKDW YNFm163j1S4QyQ2T3gE8iDdlljJ3EfK3IH8J9DXL/EPw5qHiHZBbafoU2YHjttQuty3ekytw biAhG3MPkYKDEQ0Q+c7gUo6h4Iu5/G9zqm2KeyvNRttRd5NVu4xA8CQqE+yRkRTHNurCR2GC 4yrCMBgDsbbxZpVzNdQ2/iWymls50t7pI75WaCV32JG4DfKzP8oU8k8Dmo9Y8XWWnrcQN4h0 2O/RJjHb3WpCHLxxCVgx5KhUZHY7TtVg2MYzxtt4Q1//AIRnTdEnh0If2DBaRafdCR3mvPs0 9vKA5KD7Msn2ZQyr53LKcnywHo3/AID8T6lP4mvL250dLjWdO1K3jSF5NkT3NtYRRqSVyQpt XDPgbvlYKu4ooB3eleONK1C2vZl1tLf7DPeQ3KT3Sq0X2WTZM7Dd8qjKNk4wsiE43CustpZZ fD2pebK74lgxuYnH368Y1jwpeT6jH4ciaUi8fVYry6W2kMSaZqEjTykMQEW4EqxxKodyFPmF CCVT2Sx/5F7U/wDrrB/7PQBxfjS7vo59C0uxvpbA6rqLWst1CiNLEi208+U8xWTJMKqdyt8r NjBwRFJqV74e+z6TO2p+KdQuPNmtkiit4rgwJ5YdpGZooTteRR8oU4dRtba7nT8Q6NFrENt/ pd1Y3VpP9otbq22GSCTY0ZIDqyHKSOuGUjDEjBAIzJPCLN9nuV8Ta6mqw+av9p7oGmaOTy98 exojCqnyYjhI1OUznLOWAKun/EPRNQuR9itdTmsRPawPqP2cLbq11HC9vyxDtv8APjXCqShO XCKVY4dp8X9GsvDfh+88Sx/Yb7UNKh1G7jE9vGsEbggSqrzb5FbY7KkXmSAABlDMqnprLwPo ljpUul2f2qCze+srxYxIG8trRbZYkUsCduLWPOSSctyMjEUHgaztI7aHTtY1jT4orVLGRbeW MGa0jZzDAXKF0EYkdVeNkkw2WdmAYAGZ4i+JFvaaBrV7Y6ZfRyWaajBa3F3ABbTXlok7NEMP vYEQO+8DZgFd4fKDrdTlefwzczS28ts8lk7NDKVLxkoSVYqSuR0OCR6E1lXvgfRL7SotLvPt U9ml9e3jRmQL5jXa3KyoxUA7cXUmMEEYXk4OdXU4ng8M3MMtxLcvHZOrTShQ8hCEFmCgLk9T gAegFAHOeDNfudD+CXhO7TzZ3OlaXawRecUVpZlhhjDNztTfIuSASBkgMRg71t4l1WxsLq78 Xmy0KC32N9qXVvMtSrHaAZJFjKsGwCCuPnTDMSwXl/C+l3Gr/BDwla2jxLcRadpN5EJSQjvA YJwjMASoYxhSwDbd2cNjBvajYeL9SfT9TuLTQoLzSr4XNrYx3srxzZgnhffcGIFeJ8hRE2DH gk7/AN2AdG3izSl+y7vEtkv2vyfs2b5R53nbvJ2fN82/Y+3H3trYzg1LbeJLK61E6dba9bz3 qo8ht47wNKESQxu20HOFkUoT2YEHkYrztfh1qB07xWZG0w6hreiXFlBJlj9nluLi9uJI9+3P lBrmIbgAW8rcUXAFSav8ObjUPDT6Ok1jZvdaxq17d3EaFiyXcN7FG2MDfIq3EIIJHCEBuBkA 7eHxpoU+jT61D4s02TS7dxHNepqKGCNztwrSBtoPzLwT/EPUVVfxzZPq40q01e3e4a1s72J5 b4JFPb3E5iDRMCxc5AwAMM0kS7hvyOSsPBetWt7Dr0NnYpqlrdRSx21xr17eidEhuYsNdTqW jA+1uwVYjyhyT5mY7V34O1i4vGvANHge8fTprqG33xxwvbak12wX5T5pdZpQXITLoG2jzCIw DsbbxZpVzNdQ2/iWymls50t7pI75WaCV32JG4DfKzP8AKFPJPA5oi8WaVLYWd/F4lsns76cW 9pOt8pjuJSSBHG27DsSrDaMnIPpXncvw81i/0nRNH1NNHey0O1ttOjBleUahbpdWcsjyo0YE ZMdnjywZATKQWAXLaet+DtYudW1W8tBo7jUNRMgNzvJS3e1tYJFddpWWNvIcPbkAOGjYSRPG pAB0WpTzH4tfD5zNIWa61CJm3HJT7BPJtPtviifH96ND1UYm8XeJNa0p9JttLt0vrzU742ka XN89vGmIJpixZUkPSEjG3qRyKq6j/wAlX+Hn/X9qH/psuqTxp4at/Es+hRX1pY3thY6i11dW 93GJElT7NPGoCkEEh5UbnHQnqACATaB4za7vZdI1a7t9N1uG6a1NmuoeYJ3WGOcmEsEaQCOa Mt8g2ncOgDG1D400KfRp9ah8WabJpdu4jmvU1FDBG524VpA20H5l4J/iHqK5zxH4Et76Mabp Mdjo+ltoGp6UI7eAKIXu2gIdY1AUgeXISMjJI9SRj+JbHXbTV4PG+o2VquoW89vHBptj9rvY 5VjivU3PLFbGSPIvHP8AqWAMSjd+8+UA7u28aaFdRmW28WabOi2r3haPUUYC3RirzZDf6tWU qW6AggnihPGmhPHp8qeLNNZNTcx2DDUUIu3DBSsR3fOQxC4XPJArz/wd4Y8Tvo+samxi0u71 dA0cAmkR9v8AaV7ctGX2K8QkiuUQSbRJHuLbFZQtVYfhx4hkt/ERlext31XTtTtYY31W5vjG 9zb2MUZeaVA7DNrITkHaGUDPYA9Oi8WaVLYWd/F4lsns76cW9pOt8pjuJSSBHG27DsSrDaMn IPpVDUp5j8Wvh85mkLNdahEzbjkp9gnk2n23xRPj+9Gh6qMc7rfg7WLnVtVvLQaO41DUTIDc 7yUt3tbWCRXXaVljbyHD25ADho2EkTxqRvaj/wAlX+Hn/X9qH/psuqANPxT4hutE0G51FTNc zrtitrfzinnzyMI4Yt3IXfIyLuPC7sngGo5fGejwaBY6/d+JLey0u/SOS1ubu6+zpIHTemPM I5K5ODzweOKz/Fmg32uanpDQapLplvp7y3QuLUIblbgp5SBRIjxmMxy3G7K5z5eO9YWn+FfE eg6jDfaZLY6ubR76OBb+5NvJNHeSQXEssrxwsokE8coCLGFKOvIKkMAdR4W8Yw634V07XH1B LT7XBavLCbwN5Es6RukLNx8x82MAEAtuXA+YVZtvFmlXM11Db+JbKaWznS3ukjvlZoJXfYkb gN8rM/yhTyTwOa47wv4DuNMXw3FdXMRt7HTrVdRt4nPlXF7bRCOGUKVAYYZmLNht1vaEY8vF YV38OPEOqapbvrL2N7DGkcV3Ldarc3Iv8X1nPI32aRPKtwyW0n7qMlcuq/dUEAHpU3jTQoNG g1qbxZpsel3DmOG9fUUEEjjdlVkLbSflbgH+E+hqzN4ksoNZg0WbXrePVLhDJDZPeATyIN2W WMncR8rcgfwn0NcdJ4a1+w8a6h4p0uPTL2W4nmWO1ubp7dfKlt7FC5dY3wweyPy7SCJAdwI2 mhB8PruDxEs/lWMtlJdWV45iv7u1gt3t4oECR2EbeU4zbqVZ3+TcAQ4jAcA6228c2V740Twx pur299cLa3M939nvg72rwyQx+W6KSVJMrdcY8sjB7ZXw1kkbUvGkLSMY4fEkwiQn5U328EjY HbLu7nHVnY9SareDPDWv6Vqugx38emDT9B0SXSYJ4Lp3mutzW22RozGoi+W3JKh3wWxk4yZv hp/yF/HP/Yyv/wCklrQB2dFFFABRRRQAUUUUAfP/AO25/wAiPoX/AGEj/wCimoo/bc/5EfQv +wkf/RTUUAfSfif/AJDMn/XKL/0WtXdR1F7KG0tIrWyaI20UpElurfOyDJ6dT61S8T/8hmT/ AK5Rf+i1o8Q/66z/AOvKD/0AUAH9syf8+Gmf+Aif4Uf2zJ/z4aZ/4CJ/hWZRQBp/2zJ/z4aZ /wCAif4Uf2zJ/wA+Gmf+Aif4VmUUAaf9syf8+Gmf+Aif4VHDqSw3FxcQ6VpEc10qLcSJYxhp Qm7YGIGWC7mxnpuOOpqhRQBp/wBsyf8APhpn/gIn+FH9syf8+Gmf+Aif4VmUUAaf9syf8+Gm f+Aif4Uf2zJ/z4aZ/wCAif4VmUUAaf8AbMn/AD4aZ/4CJ/hUd3qlxcW7W/lW0MTEF1hgVNxH TOB25/OqFFABRRRQAUUUUAFMnijngkglXdHIpRhnGQRg0+igCfQ5oNF0Wx0fT9M0+OzsbaO2 t0a3DlY0UKoLNkscAckknvVz+2ZP+fDTP/ARP8KzKKANP+2ZP+fDTP8AwET/AAo/tmT/AJ8N M/8AARP8KzKKANP+2ZP+fDTP/ARP8KP7Zk/58NM/8BE/wrMooA0/7Zk/58NM/wDARP8ACj+2 ZP8Anw0z/wABE/wrMooAvtqStd2922laQ1zaszW8xsY98RZSjFWxlSVZlOOoJHQ1J/bMn/Ph pn/gIn+FZlFAGn/bMn/Phpn/AICJ/hR/bMn/AD4aZ/4CJ/hWZRQBp/2zJ/z4aZ/4CJ/hR/bM n/Phpn/gIn+FZlFAGn/bMn/Phpn/AICJ/hUbakrXdvdtpWkNc2rM1vMbGPfEWUoxVsZUlWZT jqCR0NUKKANP+2ZP+fDTP/ARP8KP7Zk/58NM/wDARP8ACsyigDT/ALZk/wCfDTP/AAET/Cj+ 2ZP+fDTP/ARP8KzKKANP+2ZP+fDTP/ARP8KP7Zk/58NM/wDARP8ACsyigDT/ALZk/wCfDTP/ AAET/Coba+htXne20bRoGuJfOnMdhGplfAXe2By2FUZPOAPSqVFAGn/bMn/Phpn/AICJ/hR/ bMn/AD4aZ/4CJ/hWZRQBp/2zJ/z4aZ/4CJ/hR/bMn/Phpn/gIn+FZlFAGn/bMn/Phpn/AICJ /hXFazrN9dfGDStOLxw2Q0C8mNvBGI0aT7RbKHYD7xAJAJ6ZbGMnPRVxl5/yXDS/+xavf/Sm 1oA8y/bc/wCRH0L/ALCR/wDRTUUftuf8iPoX/YSP/opqKAPpPxP/AMhmT/rlF/6LWjxD/rrP /ryg/wDQBR4n/wCQzJ/1yi/9FrR4h/11n/15Qf8AoAoAzKZbR3slpb3Mj6ZEs8Ec4j+0SmQK 6BwP9Tt3YI43Yz3p9EX/ACDtM/7Btp/6Tx0AcDDo/hzVde8Zan4ls7GY6bqKRw39yAstjCth ayny5jhoQrPJICrLtZmYEEk1R8S+O9f0rRL7X4o9Mks2n1WytLRoH8yKWziu2EskvmYkVzZt 8gRCBIPmOzLdzqHh7QNQ1W31a/0PTLvULbb5F3PaI80W1iy7XIyuGJIweCc0S+HtAlv7y/l0 PTHvL6A293O1ohkuIiADHI2MupCqNpyMAelAHFalrfif/hOdA8P3dzY29wNRt7qU2qyGJrea 11DNswLgyFTakiU7QWKN5Q2YbMsPiH40n0m01KTw/YwpqyWc+mpdSRwjZNdW0WzKTyySDZcj 975UewqpMZ3hB6lPp2n3EzTT2NrLK/lbneJWZvKcvFkkc7HJZf7pJIwaq23h7QLaa6mt9D0y GW8nS4unjtEVp5UfekjkD5mV/mDHkHkc0Acfo+s6/efFC00a8vrX/iWwahDfGCF44bzCadLG 6xmRvLZftIXLNJwr4xv+Wjr3iUxePX1kfbvs+k3UemqU0+V7R7V9v22ZrsIYowkhjLhmyh09 lyvmtj0j+ztP+0/afsNr5/n/AGjzPKXd5vl+V5mcZ3eX8m7rt46cUNp2ntYT2DWNqbO48zz4 DEvly+YSZNy4wdxZi2epY560Aeb67qPifWNW0HUdPn0eNF1/UrPTrSe2kytxBa6hCryzCT5o 2aMsVWMEBgMnblrN342uLy503VItKsYNL+1eVC+sKYJYLhdPu55yZPmWIJiOBmAJRlulIOBX a/8ACPaB/b39v/2Hpn9r/wDP/wDZE+0fd2f6zG77vy9enHSrSadp6eVssbVfJne4ixEo2Svv 3yLxwzeZJlhyd7Z6mgDitN8R+J9SurLQorjR7TVnS6muZ5rGRvK8g24ML2wmBjkJuQQwmkVl RXUssq7b3wx8Tan4wtb/AFKSPT7O2/0T7JA3mZj82yguX8yUbt/M+0bY1+7znPGxN4V8MT6N Bos3hzR5NLt3MkNk9lGYI3O7LLGV2g/M3IH8R9TWpDb28Ek8sMEUb3DiSZkQAyOFVQzEdTtV VyeygdhQBJ9nvP8An50b/wACLj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n50b/wIuP/AIxR 9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wACLj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n5 0b/wIuP/AIxR9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wACLj/4xR9nvP8An50b/wACLj/4 xRRQAfZ7z/n50b/wIuP/AIxR9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wACLj/4xR9nvP8A n50b/wACLj/4xRRQAfZ7z/n50b/wIuP/AIxR9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wAC Lj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n50b/wIuP/AIxR9nvP+fnRv/Ai4/8AjFFFAB9n vP8An50b/wACLj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n50b/wIuP/AIxR9nvP+fnRv/Ai 4/8AjFFFAB9nvP8An50b/wACLj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n50b/wIuP/AIxR 9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wACLj/4xR9nvP8An50b/wACLj/4xRRQAfZ7z/n5 0b/wIuP/AIxR9nvP+fnRv/Ai4/8AjFFFAB9nvP8An50b/wACLj/4xRCkp+1CV7Vmg8k5t3d1 YSeb3dEII8r0P3utFFn/AMxT/tz/APbqgArjLz/kuGl/9i1e/wDpTa12dcZef8lw0v8A7Fq9 /wDSm1oA8y/bc/5EfQv+wkf/AEU1FH7bn/Ij6F/2Ej/6KaigD6T8T/8AIZk/65Rf+i1o8Q/6 6z/68oP/AEAUeJ/+QzJ/1yi/9FrR4h/11n/15Qf+gCgDMoi/5B2mf9g20/8ASeOiiL/kHaZ/ 2DbT/wBJ46AEdgi5IY5IUBVLFiTgAAckkkAAcknFYOveJ7PR4BNdS2kAMQlEc9wUlKMCUbaq tjeASoJDHB+UDBOT8RPENzp2o2em2FvNLfSoZoPKJYjBO9iihmZRGJA2VZArMWDkLFL84fFf xAuveL5Ld9RlitmbfdPIpcCduXOQzFxkLzlh2DOqox9XLuHswzWtCGHcYws5SlrOUYR0bVOP vSbd1FL4mrHz+YZrWhiVhcOle122m7LyStrtu+q3Pe9O+M/hF9UGn6tM2lF2IhuJTuhYZUAs 2AUySxywCgKSWHSvRbaaK5toriFt0UqB0bBGVIyDzXhXwt+B+p6v4u8P6/qFtpf/AAjNttlu ZYNTW4luZQvmbX2srKWZlHAyoK5B5x698Q9YufBVxqmq3mh311oZf7W1/HdWcUcTysd8ZE08 bElzuGAc+YFHSvnMdnmTUMThsBRruVWUG5OXLHXm91JJtXcbNJOV/JppezgKeJlh+estfl+l 0bdcf8T9Uu9Nj0CO21PU9OivdVNvcy6bZC6uDGLW4kASMxS5+eNMkISAD0GTXReH9RfVtGtd Sk02+0w3CeYLW+RUnjB6b1VmCkjBxnIzggHIBqel2+oXul3czyq+mXTXUIQgBnMMsJDZHI2z MeMcge4PcbnKaN4sbTvCut6rql1dX9npt8sEM155FldSRskJ/fLL5CRMHlcAOIyUEZAbcGer Z/EW21bUCbJbr+yGg02SO7tRC7JPPqEtq8LksyspaMDdGGG1ZWV8mMndvPDWl3eo3/2fVbq1 1V76PVhJBJE01pIbf7Irqjqy7WjikX51YElyMEDbVsvh9pdtEqnUdTmlaeO4uZpGi3XMkd8b 5C4VAoxK8owgUFZGByQhUAj074kaPeaZa6h/ZmsW0d/ax3OmrcQIj3294otiDf8AKRLPCmZN ineGVmTLiSPx7bb3gn8P67b3kV81nLatHC8iFYEnZh5cjLJiORWEcZaVgH2o2xsR6x4Gt18O 6VaaWJbi60XTksNO+0XYhA2y20iys4if94jWsbj5CpIIZSDxQ0rwZOLORPFfiO6Goarqv2lk hu4/3xWGICEMIYwzBbRZBJHHHLHtOxhhnYA2PFHiC+0nxpo1hbWV9qMV5p17IbO0iQvJLHJa hWLuVVAqyS8s6qcgcsUBop8VfCEuvWOlQXnm/bfswjm82JMNcKjwr5LuJ23CSL5ljZRv+Yja +3q59Lt5tftNaZ5RcWlrPaxqCNhSZ4WYkYzkGBMc9z14xhaD4Gs9DWzg03WNYgsoEtxNaLLG EungijiSSRgnmA7IYgVRlRtmCpDOGAMfwH8QWv8Aw9pD6pp2pyMYNPt77VtsAt/tdzbwOo2K /mfM1xGuVj2gv2UEjp9W8UafpupT2E8N00sH2DcUVSp+2XLW8WMkdHQlvQYxk8VzHhrwFbaP qL6XceILp9P8+1urHSvMh/fpZ29pEk0h8sSbllhjY7HCf6vI+ZlOxLoqaz49bVLr7CbXSkEH kwXTO9xN+7mia5jAVVMOWaNWMn+v8wbDjIBFB8QdLkS0lk07U4INQ8h9NlkWIrewyzwwiZAr kqoa5gJEgR8PwpIYDYfxHpkNvr9zctLb2+gOVvpXTIAW3juGZQuSQElHbOQQB0zjw/D7S0to 7d9R1OaKzgS30pXaIf2ZGkkUiCLCDfteCAgzeYT5QByGcNf07whpltpGt6ZdXF9qcOuO8moN dz5eUvAkL4KhdoKxg4XAXJChVCqACKTxc0MKJdeGddttQmnWC1sJFgMlyxR3+SRZTBwkUrEN ICAnI+dN1GT4kaOrXAGmaw4srX7XqLrAhSxiWWeKYyNvwTG9vICqFmbGYxIAxF6Twi00KPde JtdudQhnWe1v5GgElswR0+SNYhByksqktGSQ/J+RNsSeA9HXTNZsPtN8w1nTmsL2Uum9tz3E kko+XAkZ7qVjgbRwFVQMUAUdN+IMSJP/AG3p11bpFPrDvdRKhhS0sJ/LaZhvMhyGRcBSxcMd oXBqWfxbdXHiTQdJFjfaNdS6iFvbO7ELu9u9nePGwaJ5FAMlsejBv3ZyACN16TwPoks1z5/2 qa1uYL+3e1aQCMR3rxyXABAD/M8ZYHdkGRwMDaFLPwbbR6va6zfavqep6lbTrKtzc+SrMqRX ESRlYo0Tav2qZshQxLDLEAAAGFrPjTVrXxWbBdPupLW28RJpyi0hV2vEfSnuBFy2VYTFCXOx ApXLYEhEusfFrwnpLW6X0ksDsjyXUcs0Eb2gSWSJ9yvIDKVkhmUiASk+XwDuTd0UnhfT28QJ rKzXSSrfLfmJWXy2nFq9qXOQW5idQQCBmNCACX3UI/A1nb3Es1hrGsWBunlN79nljU3SSXE0 /llihaMK1xMFaIo4D/eJVSAA8X+I38P6/DNcNK2l2+ganqV1DEil3Nu9qVKk45CySADIB3c9 BitdeOXbXNG0y00e+jmvNRjhmguoljlNpLBdPHcKC42AtbMSr4kCo4MYYqDseKPC+n+IfO+2 zXUfm6VeaW3ksoxFc+X5jDIPzDylwenJyD2L/wAL6feeJE8QPNdR30X2bymRl2p5JuBwCDne l1MjZzwwK7WAagDmLH4v+FtQSb+zY7q/lHlG2htp7aSS6WSeKBWCib91880Xyz+U2GPGVYLp /wDCw9Ej+0z3lrqdlp9vPeWzX09uPJaa180yooUl2+SCRwwUoQu3dvygltfA1nDZQae2saxN YWb2xsLR5YxFaJbzRyxxqFQFxmGNd0pdwoOGBZi0t74H0S+0qLS7z7VPZpfXt40ZkC+Y12ty sqMVAO3F1JjBBGF5ODkAwtO+J9jreo6TaaHa+fLPqqWl7ALm2naOF7e5kWVZIZmiGGtySpYv tVvkyyZ6fWfEsWn6qdOh0rU9SlhgS5vDZxo32WF2dUdlZg8mfLlwsSu/yH5clQ0UHhYeZbXN /r2sale2t0lzb3Nw8SmLaroUEccaxYZJZVY7NxD/AHspGUl1nw1FqGqnUYdV1PTZZoEtrwWc iL9qhRnZEZmUvHjzJcNEyP8AOfmyFKgGXqvxB0vTYb27udO1P+z7b7Wkd6qxGO5mtkleaGNd /mBgIJxl1VCYzhjld0d145dtc0bTLTR76Oa81GOGaC6iWOU2ksF08dwoLjYC1sxKviQKjgxh ioMmq/D7S9ShvbS51HU/7Puftbx2StEI7aa5SVJpo22eYWInnOHZkBkOFGF26l/4X0+88SJ4 gea6jvovs3lMjLtTyTcDgEHO9LqZGznhgV2sA1AHMWPxh8IXqTPbNdTqnlNELYxXMk8ck8UA kEUMjyJhpojskVJCGICFlZRp6f4ynv8Axlp2hxaRdW/mQXn9owz+X51lLCLV49zLIUZWS5U/ IXOXT7uHxLa+BrOGyg09tY1iaws3tjYWjyxiK0S3mjljjUKgLjMMa7pS7hQcMCzFr9v4X0+3 8TTeIoZrpb6aeSWQ7lKlXggiaPGPun7NA+fvbk+9tLKQDmNZ8aata+KzYLp91Ja23iJNOUWk Ku14j6U9wIuWyrCYoS52IFK5bAkIv658S/D2i6ZYalqIlt7e6eeOXzbi2je2eB/LmVkeUNKU bcCIBLnb8u7cu7Yk8L6e3iBNZWa6SVb5b8xKy+W04tXtS5yC3MTqCAQMxoQAS+7H1P4c6dd2 Wo2ltrOsacmqJcRagbcwMbmKaaeYxnzIm2hWuZgpTa2H5LYBABe0DxR53hnWdc1uH7Da6Xfa hFJMFyrwW08ieYqqWY/KmCCASythcFcl54vTT9Bv9V1bQtT0v7F5ZeG8ltYt6u2xWWYzeR1z lTIGGBkfMm68nhzTP7G1XRZVlm03U3uGnt3fAUXGTMqsuGAZnkfkkguQCFChaMnhFpoUe68T a7c6hDOs9rfyNAJLZgjp8kaxCDlJZVJaMkh+T8ibQDMt/ihoFzbNdWdnqd1aw2Iv7u4gjR4b WASTRyO0gfa3ltbyZEZcuOYxIASL3ijXtV0vxpo1jY6Xfarb3WnXss1raG3V98clqEkLTOgw BI4wG53jg4yIrL4faXb6RrenSajqdz/bVjJZ3k8rRCQrJLcys67UChi13L/DjAXjg51PEPh1 tV1Wx1S21zU9IvLOCa3SSzWBt8crRMwYTRSDrCmCAD19aAMJPir4Ql16x0qC8837b9mEc3mx JhrhUeFfJdxO24SRfMsbKN/zEbX29zXM6Z4L0/SrmEaRqGp6fp8fkl9OgmXyZmhjSKNmcqZu EiiUqJArBMMG3Pu6agAooooAKLP/AJin/bn/AO3VFFn/AMxT/tz/APbqgArjLz/kuGl/9i1e /wDpTa12dcZef8lw0v8A7Fq9/wDSm1oA8y/bc/5EfQv+wkf/AEU1FH7bn/Ij6F/2Ej/6Kaig D6T8T/8AIZk/65Rf+i1o8Q/66z/68oP/AEAUeJ/+QzJ/1yi/9FrR4h/11n/15Qf+gCgDMoi/ 5B2mf9g20/8ASeOiiL/kHaZ/2DbT/wBJ46AOO8caveeF9RGtwiAxXdsLTzZGCtbujNIpRuTl sk9ODErAFxHj5a+KcujrrU0kTNJqF0TO7IQVB3AMD8x+U54xnkEAtjc32ZrGnWWr6ZcaZqMA ntblDHKhJXIPoRgqR1BBBBAIIIrw3xR+zVp2oaxLeaN4ru9Pt5SWaC7tvtbK2Twsm9DtC7VA bc3HLHPGnD8ZZZnkcyVaUI21UW/e2fK9fhbSbWt7bHz1XI3LMHjFN2a2/rp1Lfwc+KEXgn4R 3Xi/xQ8s0km3SdDsFu03ak8XzO7E8oIy6KZG+VEYgbiwB6keNrnxLc+B/FOsWb6XK58qXT5D 59uYbpdkGoW7LzkyNBCdw3RC6KuqiRXbB8Dfs9eGdHuI7vxJfz+JZoDi3ilj8m2jUMGAMYZi 3zb8gsUIc5TPNeu6hp2n6h9n+32Nrd/Zp1uIPPiV/KlXO2Rcj5WGThhyM14uN4ey+WayzLD3 U+ZtdlFt+7a/ZvXe/krP38OvY0lRj8Pbzet/vLNYfja/u9H0qLW4Zdtnp04uNSj2g+ZabWWU 5IJHlhvOwoLN5Owffrcor1ijx/xB4m8b6dN9ju9RtdOeaCyuLuW5mhgj0pZ31FyhuPKljG0w 21vvZGDkDAVpNwtWfiLx5Klrb2xtdTubuxW6s2tpEEdwltPcGciSSNN3nIbCHzAqpm5MsS7F NerUUAeLal4y8YvJbT2utaZZW1zBJfaS15OsH9ppLdXBgiWIW8sk+IFtcxRGKUecASXddun/ AGu2o/ETw5Ff+JP+JlD4ivozoGYF+zwR218kU+zZ543xiN9zOVPm5AAKgerUUAeeaz4i1KDx lcWia15F5Fqtna2Oh7Yv9Os5BB51ztK+c2zzLk70YIv2f5gdr5PhtrHiG5/4RZta1j+0m17w 62pzA20cSwSR/ZQojCjPzC4YvuLAsoKCNfkr0OigDx/w7p+pTeNLWxtteutOnE/iR59sETTW 0bajayIkYdSF3q0UuZFkJSU4wGQrHpfjzXtR0W31S71qLTjPdWpWKGzVtxl06ymESBgfNHmz yMYFZZ5F3eU+Y9j+yUUAcf4+1drDVdLtLvxJ/wAIxpU8FxJNqeYE/fo0Iig3zo0Y3q8zbcbj 5WQQFYHDfxRq39vJHJruzUBfWEFpo32Rbf8AtC1lW3M915EoNyNnm3J4cKn2fDg7JN3plFAH j/hnxL4oGnaPe3fiG6vmksdBvJkmt7dVlbUrgwSodkakLGE3R7SDuY7y64UVvDnjXWJvD+i3 9p4v/t3z7GyvNdlKWrrpTfarMSo3kxqIlMMt2W83JAgLArsY17TVbSbC00rSrTS7CLybOzgS 3gj3FtkaKFUZJJOAByTmgDyS+8Tanf8AjPU9f0W5lvY9MtdWg0eNbbMV7J9i06eO3HyhpA7C aVdhDOqZVig5s+F/EXiW91bSLJvFljqNlcaxFG91p91Del1FrdzSQNMtrFEATBD8qqZFDMSw Dpj1uigCO0uLe8tYbu0niuLedFkilicMkiMMhlI4IIIIIqSueu/HXgizuprS78Y+Hbe4gdo5 YpdThV43U4KsC2QQQQQai/4WH4A/6Hjwz/4NoP8A4qgDpqK5n/hYfgD/AKHjwz/4NoP/AIqj /hYfgD/oePDP/g2g/wDiqAOmormf+Fh+AP8AoePDP/g2g/8AiqP+Fh+AP+h48M/+DaD/AOKo A6aiuZ/4WH4A/wCh48M/+DaD/wCKo/4WH4A/6Hjwz/4NoP8A4qgDpqK5n/hYfgD/AKHjwz/4 NoP/AIqj/hYfgD/oePDP/g2g/wDiqAOmorH0TxV4Y1y6a00XxHo+p3CIZGitL2OZ1QEAsQrE 4yQM+4roLaxvblDJbWdxMgOC0cZYA+nFAFeirv8AZOq/9Ay9/wC/Df4Uf2Tqv/QMvf8Avw3+ FAFKirv9k6r/ANAy9/78N/hR/ZOq/wDQMvf+/Df4UAUqKu/2Tqv/AEDL3/vw3+FH9k6r/wBA y9/78N/hQBSoq7/ZOq/9Ay9/78N/hR/ZOq/9Ay9/78N/hQBSoq7/AGTqv/QMvf8Avw3+FV9Q t7jTrb7VqEEtpBvSPzZ0KJvdgiLk8ZZmVQO5IA5NAEVFn/zFP+3P/wBuqKLP/mKf9uf/ALdU AFcZef8AJcNL/wCxavf/AEpta7OuMvP+S4aX/wBi1e/+lNrQB5l+25/yI+hf9hI/+imoo/bc /wCRH0L/ALCR/wDRTUUAfSfif/kMyf8AXKL/ANFrR4h/11n/ANeUH/oAo8T/APIZk/65Rf8A otaPEP8ArrP/AK8oP/QBQBmURf8AIO0z/sG2n/pPHRRF/wAg7TP+wbaf+k8dABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBkeD9Y1rTPA2jwaPcCH7V4i1lJ3aOR 1SNdTvHY4UYBITYGZlUFgcsQsb68OseOB5fneI7J8bPM22Dru/1W7H744zifHXHmR9fLbzOZ 0CPf4V8Mt5W/y/Euutu8vds/03UBnPltt64zuj643nPlv01AFHXPFnjDQtAvda1HxBbzW+nW rXVysGnsHdI0jaQIDNgEhJ8ZPHmR5z5beZF4c8V/EXUN39otNpXleXn7VaRfvv8AV79nlXcu 37s33unmxfe8tt+Z8VzF/wAKy8TRS3Nrb+fpVxbo9zOkMfmSRsiAu5CrlmUZJAyRXFWGo6H4 x8N3Hhnw6980y6jYXksdx4mhvLkwpeQNM6SR3cskYREz95cEjbljQB63DrHjgeX53iOyfGzz Ntg67v8AVbsfvjjOJ8dceZH18tvMo6N4s8YX97qFoPEFuX0u6jtbo/2eyiRzDazMU/fHAKyS gZ6F0+95ZMvm/iHwdfmO+0mLw75vhkaqbizstPttPkeIfZbdVMUV2DBHF5n2wuAA+9lI4Zya PhTwl4gingk1TwvKPEL3WlXD+IpZbZ3jjhtrNbqJpRIZyXMNxGQFKt5nJ2sxoA9W8MeLPGGt 6BpWtReILcW9/awXQVtPZH2OkLEY85gpI87u2N6fe8s+Zeh1jxwPL87xHZPjZ5m2wdd3+q3Y /fHGcT4648yPr5beZ4t4S8A6/Z6joE+qWmp/bLSDTRFPBNYiGyiht4EmgaZka5XLxz5jhPlu JcFl8yRh63HfXTRo7aNfIWSBijPDlTI2HU4kxmMfM2CQQfkLnigC9DrHjgeX53iOyfGzzNtg 67v9Vux++OM4nx1x5kfXy28wh1jxwPL87xHZPjZ5m2wdd3+q3Y/fHGcT4648yPr5beYUUAeP +G9Zv9e/aYGp6jefa5pvAsL71ZSmGmiY7AruoXLEgK7jnhm6n3YSSReGImjdkP21xlTj+BK+ ffAUnnftExTeb52/wJbt5nmeZvzLCc7vMk3Z9fMkz/fb7x9/f/kVov8Ar9f/ANAWgCn9ruv+ fmb/AL7NRzX91GgImuZGZlRERiWdmIVVHPUkgfjTKjut/kkxxtI6kMoV9jAgg5VuzDGQcjkD kdQAWxc6gFJla5iIYocyhhkAHhlJVuGHQnGcHnIqP+0LjzDGLi5Zg0SELvPzSMVQcdyQRj2q tdaduS2FxC6qbtnNnFcwzERCMBAXlMkZzLuY72bC+mAKb5GmxXT2psrSeZRayzwNPbzyCKO5 eSSLgKg3K8QCRjZhcEgDkAvi6vNis08y7s4Hm5OASMnBOM4zg84Io+13X/PzN/32aoXmmKNK v52tbR9RaFkgKuh2SNcXjb1CnaGAaLDY+UMMEU54tPm157OwtLKd4Z9QMk6TRNI37q58v5gx mVVUxLnAUMoxzgkAu/a7r/n5m/77NH2u6/5+Zv8Avs1Ssrea10xA1pCjBWkCRSRhtoCKoKq2 xWPJwvfczbc1YZHQuHVRtcoCHVt2AMkYJ45xnvg4oAl+13X/AD8zf99muJ+ME80ujaEsk0jj /hJdKOGYn/l7jrr64z4uf8gjQ/8AsZdK/wDSuOgDs6LP/mKf9uf/ALdUUWf/ADFP+3P/ANuq ACuMvP8AkuGl/wDYtXv/AKU2tdnXGXn/ACXDS/8AsWr3/wBKbWgDzL9tz/kR9C/7CR/9FNRR +25/yI+hf9hI/wDopqKAPpPxP/yGZP8ArlF/6LWjxD/rrP8A68oP/QBR4n/5DMn/AFyi/wDR a0eIf9dZ/wDXlB/6AKAMyiL/AJB2mf8AYNtP/SeOihbe8W3toftOjfuLaGDP2i4+by41TP8A qOM7c496ACij7Pef8/Ojf+BFx/8AGKPs95/z86N/4EXH/wAYoAKKPs95/wA/Ojf+BFx/8Yo+ z3n/AD86N/4EXH/xigAoo+z3n/Pzo3/gRcf/ABij7Pef8/Ojf+BFx/8AGKACij7Pef8APzo3 /gRcf/GKPs95/wA/Ojf+BFx/8YoAKKPs95/z86N/4EXH/wAYo+z3n/Pzo3/gRcf/ABigAoo+ z3n/AD86N/4EXH/xij7Pef8APzo3/gRcf/GKACij7Pef8/Ojf+BFx/8AGKPs95/z86N/4EXH /wAYoAKKPs95/wA/Ojf+BFx/8Yo+z3n/AD86N/4EXH/xigAoo+z3n/Pzo3/gRcf/ABij7Pef 8/Ojf+BFx/8AGKACij7Pef8APzo3/gRcf/GKPs95/wA/Ojf+BFx/8YoA8g1O/wDijaRpolj8 K7bU7HTdXvr2xv21yGKSQy3s86yKAwZBsm2Fc/MpcNw5WqUOpfGGLy9vwqmPl7Nu7xgWzt8r Gczc/wCpTOc5zJnPmSbvbPs95/z86N/4EXH/AMYo+z3n/Pzo3/gRcf8AxigDxOHUvjDF5e34 VTHy9m3d4wLZ2+VjOZuf9Smc5zmTOfMk3EOpfGGLy9vwqmPl7Nu7xgWzt8rGczc/6lM5znMm c+ZJu9s+z3n/AD86N/4EXH/xij7Pef8APzo3/gRcf/GKAPE4dS+MMXl7fhVMfL2bd3jAtnb5 WM5m5/1KZznOZM58yTcQ6l8YYvL2/CqY+Xs27vGBbO3ysZzNz/qUznOcyZz5km72z7Pef8/O jf8AgRcf/GKPs95/z86N/wCBFx/8YoA8Th1L4wxeXt+FUx8vZt3eMC2dvlYzmbn/AFKZznOZ M58yTcQ6l8YYvL2/CqY+Xs27vGBbO3ysZzNz/qUznOcyZz5km72z7Pef8/Ojf+BFx/8AGKPs 95/z86N/4EXH/wAYoA8Th1L4wxeXt+FUx8vZt3eMC2dvlYzmbn/UpnOc5kznzJNxDqXxhi8v b8Kpj5ezbu8YFs7fKxnM3P8AqUznOcyZz5km72z7Pef8/Ojf+BFx/wDGKPs95/z86N/4EXH/ AMYoA8b+F+ieOZPi/N4q8T+FG0O0Hh4abHu1RLxndZY2XLb2ckqDktnJGScmvUfE/iTWNOsr fTNK8G6nrY8xp5LiC6tYo0yAoTEsqsW+Uk8YwRgk5A0/s95/z86N/wCBFx/8Yo+z3n/Pzo3/ AIEXH/xigDjP+Eq8X/8ARMNa/wDBlY//AB6j/hKvF/8A0TDWv/BlY/8Ax6uz+z3n/Pzo3/gR cf8Axij7Pef8/Ojf+BFx/wDGKAOM/wCEq8X/APRMNa/8GVj/APHqlXxl43W3a2X4b68IHOWj Gq2O0njkjz8dh+Vdd9nvP+fnRv8AwIuP/jFH2e8/5+dG/wDAi4/+MUAcZ/wlXi//AKJhrX/g ysf/AI9U/wDwmvjn7L9l/wCFc+IPs/8Azy/tay2dc9PPx15rrPs95/z86N/4EXH/AMYo+z3n /Pzo3/gRcf8AxigDjP8AhKvF/wD0TDWv/BlY/wDx6j/hKvF//RMNa/8ABlY//Hq7P7Pef8/O jf8AgRcf/GKPs95/z86N/wCBFx/8YoA4z/hKvF//AETDWv8AwZWP/wAerJ8TXPi7xKNIsW8A 6np0cOs2N3LcTX9m6JHFcI7khJS33QegJ9q9J+z3n/Pzo3/gRcf/ABij7Pef8/Ojf+BFx/8A GKACiz/5in/bn/7dUfZ7z/n50b/wIuP/AIxT4IXggvHnubKSSdrcIlu0jYEYmySXjT/noOme 9ADK4y8/5Lhpf/YtXv8A6U2tdnXGXn/JcNL/AOxavf8A0ptaAPMv23P+RH0L/sJH/wBFNRR+ 25/yI+hf9hI/+imooA+k/E//ACGZP+uUX/otaPEP+us/+vKD/wBAFHif/kMyf9cov/Ra0eIf 9dZ/9eUH/oAoAzKqR6npskixx6haO7EBVWZSST2HNW6sW99epo2m2yXlwsB0y0HliQhcG3TI x070AcY2o+J9S1zWItFn0eC30i6S1a3u7aR3u3MEU5ImWQCEETBP9XJt2lvmztFq98a+GrKS 9W6v5Yks0meWc2k3kN5Ks0qRy7NkkiBHzGjMw8t+PkbEVxoGtw6vqVzouvWtha6pOtxdrLp5 mnSQRRwkwyeYET5IkIDxyANkncDtHO6h8KrO5k1sQy6PbjUkvyt0NFja/WS7WUP5lwWy8amZ 8Kqo2FRS5AbeAWtZ+I9rZ2et3KW8sR0h22Q3FrMhvx/ZpvRGGKgQSYDbgwYqI8FQZFxp2fjH T7e3ddRv5b27V0jMFlot0J0P2eGR90ADyADzkYkgBPNRGO4Zaj4w+H39vjVI49X+yxahPJcu GtvMZJZNOlsGwdw+XY0ThcZyj8kONlm48IahD4mvfEmj6za2+oXM8jAXdi08KRSQWkbptWVC W3WcbBtwADMCp4YAGxL4m0aO6sYDcysl+kcltdJbSvaSCQ4j/wBICmIFjgKCwLFlAB3LnH0T 4h6Fe+G9H1e8+1WTahYx3ksX2SeRbNGH35nEeI4sh8SybEYIzAlQSKOt/Dt9S1+01SXU7G6e G6srlrrUNLWe+U27xMUhnV0WGN/KyUEZG6WUj72BVufhVZyx6dE8uj3YtNOh0rzNR0WO7lS2 haTyjCXbbHNtkId2V0dlU+WoBUgHaWfiLRrvUbrT4L1TPahzJuRlRgh2yFHICybGIV9hOxiF baTirH9raV/0E7L/AL/r/jVDQ9GvtN8T6jrB1dnjuiGSGOARNuB4eRgcO6ABFZVRtiqJDKVR l6j+1tV/6Cd7/wB/2/xoAxv7W0r/AKCdl/3/AF/xo/tbSv8AoJ2X/f8AX/Gtn+1tV/6Cd7/3 /b/Gj+1tV/6Cd7/3/b/GgDG/tbSv+gnZf9/1/wAaP7W0r/oJ2X/f9f8AGtn+1tV/6Cd7/wB/ 2/xo/tbVf+gne/8Af9v8aAMb+1tK/wCgnZf9/wBf8aP7W0r/AKCdl/3/AF/xrZ/tbVf+gne/ 9/2/xo/tbVf+gne/9/2/xoAxv7W0r/oJ2X/f9f8AGj+1tK/6Cdl/3/X/ABrZ/tbVf+gne/8A f9v8aP7W1X/oJ3v/AH/b/GgDG/tbSv8AoJ2X/f8AX/Gj+1tK/wCgnZf9/wBf8a2f7W1X/oJ3 v/f9v8aP7W1X/oJ3v/f9v8aAMb+1tK/6Cdl/3/X/ABo/tbSv+gnZf9/1/wAa2f7W1X/oJ3v/ AH/b/Gj+1tV/6Cd7/wB/2/xoAxv7W0r/AKCdl/3/AF/xo/tbSv8AoJ2X/f8AX/Gtn+1tV/6C d7/3/b/Gj+1tV/6Cd7/3/b/GgDG/tbSv+gnZf9/1/wAaP7W0r/oJ2X/f9f8AGtn+1tV/6Cd7 /wB/2/xo/tbVf+gne/8Af9v8aAMb+1tK/wCgnZf9/wBf8aP7W0r/AKCdl/3/AF/xrZ/tbVf+ gne/9/2/xo/tbVf+gne/9/2/xoAxv7W0r/oJ2X/f9f8AGj+1tK/6Cdl/3/X/ABrZ/tbVf+gn e/8Af9v8aP7W1X/oJ3v/AH/b/GgDG/tbSv8AoJ2X/f8AX/Gj+1tK/wCgnZf9/wBf8a2f7W1X /oJ3v/f9v8aP7W1X/oJ3v/f9v8aAMb+1tK/6Cdl/3/X/ABo/tbSv+gnZf9/1/wAa2f7W1X/o J3v/AH/b/Gj+1tV/6Cd7/wB/2/xoAxv7W0r/AKCdl/3/AF/xo/tbSv8AoJ2X/f8AX/Gtn+1t V/6Cd7/3/b/Gj+1tV/6Cd7/3/b/GgDG/tbSv+gnZf9/1/wAaP7W0r/oJ2X/f9f8AGtn+1tV/ 6Cd7/wB/2/xo/tbVf+gne/8Af9v8aAMb+1tK/wCgnZf9/wBf8aP7W0r/AKCdl/3/AF/xrZ/t bVf+gne/9/2/xo/tbVf+gne/9/2/xoAxv7W0r/oJ2X/f9f8AGj+1tK/6Cdl/3/X/ABrZ/tbV f+gne/8Af9v8aP7W1X/oJ3v/AH/b/GgDG/tbSv8AoJ2X/f8AX/Gj+1tK/wCgnZf9/wBf8a2f 7W1X/oJ3v/f9v8aP7W1X/oJ3v/f9v8aAMb+1tK/6Cdl/3/X/ABqxa3Fvdo8lrPFOkZAdo3DB Sc4Bx0zg/ka0f7W1X/oJ3v8A3/b/ABqulxcXMmpyXM8szgWQDSOWIH+lcc0ARVxl5/yXDS/+ xavf/Sm1rs64y8/5Lhpf/YtXv/pTa0AeZftuf8iPoX/YSP8A6Kaij9tz/kR9C/7CR/8ARTUU AfSfif8A5DMn/XKL/wBFrR4h/wBdZ/8AXlB/6AKPE/8AyGZP+uUX/otaPEP+us/+vKD/ANAF AGZRF/yDtM/7Btp/6Tx0URf8g7TP+wbaf+k8dAGNqvirw9pV61nqOqwW1woBKPnOCMg9Kqf8 J34Q/wCg9afr/hW78MNIsLn4oeKNbl01L7UNOs7NbINt+QyCTcRu4VvkUbuoG4Drg+ox6prb W4lbwxcI+xiYjdwltwzhRhsHOBzkYz7VjF1JXei1/rqc8JVZ3d0ld9L7fNHiP/Cd+EP+g9af r/hR/wAJ34Q/6D1p+v8AhXtY1XxAJpUk8KSlFQsjx30R3nHC4JGCT+GOc9q574uabbeIvhX4 j/tzQ/JksrCe6tWlaN2SSOMsHRlJK8rjtlTg9SAqjqxg5JrTy/4IqrrQg5Jp2XZ/5nIaTf2m q6VaapYS+dZ3kCXEEm0rvjdQynBAIyCOCM1LNcW8EkEU08Ub3DmOFXcAyOFZiqg9TtVmwOyk 9jXO/Cb/AJJX4S/7All/6ISoviBcW9hqHhXVL6eK1sLLWHkurqZwkUCNZXUas7nhQXdFBJGW dR1Irc6Tp4bi3nknihnike3cRzKjgmNyqsFYDodrK2D2YHuKkry661sQaX4q1/S9citdOvNf ieLUYGiMc8K2Nsj+VPIGgQ743QNJ8hdTFuRmDrF/wlHiqTx3bWbavplvF59nHFYz7raa+gki iaadbNoHuDgvMA3nIsZi/eDEchYA9WorhvGOuT2fip7K48T/APCPQRWMM+nL5Ecv9p3DPKJI fLZTJNtCQ/u4Ckh87GcsmOP13xl4xtrnxPNHrWmW8tlBqpTTfPWS4tooI5jbz/Zxb7493lwv 5kszRsJOFzJGqgHss1xbwSQRTTxRvcOY4VdwDI4VmKqD1O1WbA7KT2NRadqOn6lCZtOvrW8i G3LwSrIo3IrryCeqOjD1DKehFeK/EObUtH07xtYHVrqX+0J5o54p44g08A8PSkT/ACoCN81u QWXC5gZVC4cHor7xDqFr4kv9G1jxlLoukWl08I1eVbWJzIlnYOkLPJGYsyGe5kI2hjs+XCqV oA9RorynX/GurWnirRootWtYN0+n2k9heSLZvffaHjV54bOSFpyoExGfPXY8Thlby2387puv eKdF8L+F9JsNdsbIWugWpiXUbhIXurwNIktn5S20jzmExxxmKIxzDdtZmdwVAPeKK4/wvrF3 d+Oda02bWPtSQbmFqtsFW3UMFQHgSRMRuJEu8TApLCwUOi8pp+pS6SH07UfFkvhvT5tY1qa4 vJPs0Ztpvtga3tt00bIBLFM84DAuwwytsGKAPW6K888ReItSi8JeCb7Wda/4RGXVZ4l1afbF F9nZrGeVo/8ASVdU/eoi4YZ7Zyawrzxlrq6dcTS+IPsk9tYyzaCnlwD/AISOVbi6SNMMhMu+ OG1bFvsJ+05XAePaAeuXNxb2sYluZ4oEZ0jDSOFBd2CouT3ZmCgdyQB1oW4t2upLRZ4muI0W SSION6oxYKxHUAlHAPfafQ15vqPijVoNf1K1g13zWi1WwhNutou23ikv4ISpyN8LMjSZ83eJ gySwMqh0XH8D61rOieF9MVtTlm07w/oGlXOp20sUQeNC15DdoxVQymDy0Ypgufsuz7zsSAey VHbXFvdRmW2ninRXeMtG4YB0Yq65HdWUqR2IIPSvI/EviPx5p15Z29xqmmaTdPYrexQXlykf 2i4lmmP2JVS3la78lRDGRAY5G3A5JkXbL4b1bXrW/m0exklxf6xPJYxpArgpFrlz/aLM2CEA geEZcjJYBMucUAerrcW7XUlos8TXEaLJJEHG9UYsFYjqASjgHvtPoaLa4t7qMy208U6K7xlo 3DAOjFXXI7qylSOxBB6VwHjXxFqVj4yl0t9a/sfRjBYtdX+2IfYVkGoEyb5VZF3vb20WXBHz 4UBmBrhtM8TeIbKxjt9E8SaYtn59/c2N1eXcaf2xO+pXgKqiW0hueEiJjt/Kb98AD86bQD3y q39o6f8Aafs32618/wA/7P5fmru83y/N8vGc7vL+fb1289Oa8k8Xah4pvfBeq7tRl1Iaxda9 osGnRWaDbHFHfmIrtG95s26IDnaVONhf5yXF94g1XxnfDQNdlv7zT9H1OPR50FsRdFrLSZI9 zbAhDSzeZkbRnAzs+WgD2SiuLs9W17XvBvifWPD0kshu0kk8MSSQLEXQ2kflttkAODP5pBkH IIPKFTWFN4tur69S9ufFEvhzwnqTzXGmatJFDbl0WGzEcWbmMgCR3vHAZd7CMMp2DkA9Rory my8da2ulRw61N/Z+v3mq6MIrD7KVeK2nWxFwdjAssXmSXMfmP0f5N24KKl8N+I9Ze18CNf8A iaWWfVtOt7maJrOLfcyTDe/yqi+ZGqkrmEq0HyPMJI3JUA9Nubi3tYxLczxQIzpGGkcKC7sF RcnuzMFA7kgDrRbXFvdRmW2ninRXeMtG4YB0Yq65HdWUqR2IIPSvENP8R+JtasbYa1qmmXHm X2kz3ljBciabTrj+0rT9yyJbx/Z8bpFMc0kshKYBOyQn0P4PyRW/wy8H2U1/511LokE8aSsg kMYjjztVQMqnmIucZwV3Ek5IB2FFeZz+KNWj/tye0137T4htf7REPhj7Is2Eh877M+yMCdPM CQvvdyj+btUAyR7aHhfxF4lvdW0iybxZY6jZXGsRRvdafdQ3pdRa3c0kDTLaxRAEwQ/KqmRQ zEsA6YAPUp9R0+3maGe+tYpU8rcjyqrL5rlIsgnje4Kr/eIIGTUtpcW95aw3dpPFcW86LJFL E4ZJEYZDKRwQQQQRXiHg2bUmu/h14fl1a68vT4NNkZTHEJIZ/smrJPA3ycY8hYWUjcoQ8h8t W74D8V6lqsekS614t+xalNBp5t9L+zRN/acUtrBJLP5YXzT+8knXzI2WNPKyykRyAgHq1R21 xb3UZltp4p0V3jLRuGAdGKuuR3VlKkdiCD0rwvV/Feq63eT6a2txLZTvb6m8Yu7ea90RINSs ifOjFugtzHHJIXWUzYMJy2EYvsX/AIy11ItWkm8QfYbqz+3Notr5cA/tm4jvr2JbTDoWl2rB bJthKyfvuWJZSAD2CivPNA1jxCdV0y7vdY+1W2o+ItT0lbT7NGiRQQtetG+4De0o+zKu7IXY cFC/7w+h0AFFFFABRZ/8xT/tz/8Abqiiz/5in/bn/wC3VABXGXn/ACXDS/8AsWr3/wBKbWuz rjLz/kuGl/8AYtXv/pTa0AeZftuf8iPoX/YSP/opqKP23P8AkR9C/wCwkf8A0U1FAH0n4n/5 DMn/AFyi/wDRa0eIf9dZ/wDXlB/6AKPE/wDyGZP+uUX/AKLWjxD/AK6z/wCvKD/0AUAZlEX/ ACDtM/7Btp/6Tx0URf8AIO0z/sG2n/pPHQBf+C//ACP/AI0/699O/lPVr+yvFP8Az66z/wCB Mv8A8s68wsviBe+BviprPmeFfEeraPqFrBFcyadplxIyOikq0bqm1sB2BAYcnqCuK6UfG3w+ LcofCXxaaYzmYXDaA7OpLA4UH5FXA24Cj5S3diTz06ijdNPd9H3OWlVUU4tPd9H3v2OlvbPx DZWc15eLqltbQRtLNNLeSIkaKMszMdUwAACST0qo3jbQde+E/ijRbe9vF1i38P3txLZ6haXF tcGIrIPMCzszOoOAWV3C7lB25C1xPxR+Nmhap4Ck0Sz8L+OdOvTLbyafLq2iyJDJPbypOkck juDhvJwzEkgEtg4wfmPRta1mfxZa6gbO7W/kiuUitzbS3Vxerc2sqSOojDZHlSF9xOSGVgGU kjHE15rSMW07/lsl1PcpZfRr5TiMXOUlKK91KEnzbJ62tpddd2j6j+E3/JK/CX/YEsv/AEQl buq6jp+lWEl/ql9a2NnFjzJ7mVY40yQBlmIAySB9SKx/hjb3Fn8NvC9pdwS29xBo9pHLFKhV 43WFAVYHkEEEEGpfG2napqelRQaXPtZJw80H22Wz+0x7WGz7REDJFhij5QEt5ew/K5Ndx5pe XWdHa1ku11Wxa3jtVvJJRcJsW3YMVmJzgRkI5DdDtPPBrnYviHoD6l5Et3a2lnF/aCXd1dXS RrbS2lzBAUfnA3mdWXJBwU4+bjlIvh74stvCmt6XZTaOlxrunXNlcNcXk84tQ1zeTJh2QPOW F5sZ32lSu/EudtdPong64s/FljqV0LG4t9PfV5LaQ5Moe9uYpwwUrhCo8+MkMcrg/wAbKoB0 02s6PBrMGizarYx6pcIZIbJ7hBPIg3ZZYydxHytyB/CfQ1jv430AX+mxxarpl1Z6pPFbWlzb XySAyuLgjeOgUm3ZFYFiz5XA25PM+GvAmv6VoljoEsmmSWbT6Ve3d2s7+ZFLZxWimKOLy8SK 5s1+cuhAkPynZhpPD/gPWNNvfDV7Jc2Mj6Np2l2rxq74leCG9gmIbbwNt4HXj5im07M7gAdh p/iPR55NNsptY0ddU1C1S5htIL9JTMhUsXiztaSP5Ww4UZCk4HOL+n6jp+ofaPsF9a3f2adr efyJVfypVxujbB+VhkZU8jNeZeF/hpqWlPpkF2bW7ij/ALOnuJRq94kcUtrBbx7VtE2xTZa2 DLI5UguMowjCt03hXSdb0DzEbTtMmE08NtCLVyq29sm5mbcw3pENzmO2HmeWz7RJ5bZiAOi1 LWdH0y6s7TUtVsbK4vn8u0iuLhI3uHyBtQMQWOWUYGeo9aLbWdHutROnW2q2M96qPIbeO4Rp QiSGN22g5wsilCezAg8jFcf8V/CniHxNa3lpps8Utvdac9pHFLq9zYpbSsHDSsIVYXIYMgMc mFXyuM+Y2Kur/Dm41Dw0+jpNY2b3Wsate3dxGhYsl3DexRtjA3yKtxCCCRwhAbgZAOn8N+L9 H8Ra/qOm6LfWOo29ja207XdpdpMheV51MZ25AKiEHrzvHAxzZ0vxV4Y1SOWXTPEej3yQvHHI 1vexyBHkbbGpKscFm+VR3PAqj4ZsNf8A+Eq1XXNctNMs/tVjaWkMNnevc/6l7h2ZmaKPGfPA AAP3TzXFeGfCXifVfB3hWbUrSx0u40XR7SO0tmuJHe4dJrO42zholNuc2aoQBLjzGPOzDgHV +KvFHhWw8WaPY67f6ZbfZ/tN1FdXOoLCttcxxxR+WQSAWaG8ZsE8DBwcgi/a+KLd9c1mxu2s bK30p5FlmnvArsiQWsxlCFQBGouSGYt8u1Ou/wCXmLHw543sPGNx4pW38O3txdPdGS2N9Nbp EksOnooD+S5cqbN1Jwu7IbC5KLR0f4ZappTmNbjTL+CCx+zQ+cZYmlZYNLjRspzC26wkIkVm MZaNwHIIoA7WPxfo5186bLfWMVvJa2U9ldtdpsvHunuFjjj7MSIMjBO7dwOOb0viHQIr+8sJ dc0xLyxgNxdwNdoJLeIAEySLnKKAynccDBHrXFTeAdTudM8Rm5/sc6pqvhk6VFOkezZM73ck pZlQcM08Rd1Vd7KzeWnCijrHw01K7h1uziNqy3P9qT2l1Pq94yiW8S4AX7J/qYdv2llMg3kh WOwNJlAD0i01nR7y6htLTVbG4uJ7VbyKKK4Rnkt2OBMoByYySAGHHvRDpNjFrM+sCOV72ZBG ZJZ3kEafLlY1YlYg21SwQLuKqWyQDWFd6JrCeMZtYsrbR5LfY06rKzo0twIfKTcNjBJACwNy pyY28ton2o69XQAUUUUAFVtVsYNSsJLK4e6SKTG5ra6kt5Bgg8SRsrr07EZGQeCas0UAUbnS bGfRho6Ry2lkqJHHHYzvamNExtVGiKsgGAMKRxx04q1aW9vZ2sNpaQRW9vAixxRRIFSNFGAq gcAAAAAVJRQAUUUUAFRrb263Ul2sES3EiLHJKEG9kUsVUnqQC7kDtuPqakooAKKKKACiiigA ooooAKKKKACiiigAos/+Yp/25/8At1RRZ/8AMU/7c/8A26oAK4y8/wCS4aX/ANi1e/8ApTa1 2dcZef8AJcNL/wCxavf/AEptaAPMv23P+RH0L/sJH/0U1FH7bn/Ij6F/2Ej/AOimooA+k/E/ /IZk/wCuUX/otaPEP+us/wDryg/9AFHif/kMyf8AXKL/ANFrR4h/11n/ANeUH/oAoAzKIv8A kHaZ/wBg20/9J46KIv8AkHaZ/wBg20/9J46ACiiigDzT4rfDzUvFOrWN3Z63qOya4jt7qBpY khtLMqTK8OI94lJVcElssVyNqjbF8QPhZba74n0O400yaTp6ARXjac0cEtt5KE28kPyEKQQq EjJAEYUAKSPUKKznSjP4vL8Nf69T0KWaYqlGMIzdkpRS8pb/AH/oiO0ieC1hhluJbl40VWml Ch5CBgswUBcnqcAD0AqSiitDzwooooAKKKKACiiigAooooAKKKKACiiigAooooAKK271tNsl to20mKZntopGczSAksoJ6HHWq/2/TP8AoBw/+BEn+NAGZRWn9v0z/oBw/wDgRJ/jR9v0z/oB w/8AgRJ/jQBmUVp/b9M/6AcP/gRJ/jR9v0z/AKAcP/gRJ/jQBmUVp/b9M/6AcP8A4ESf40fb 9M/6AcP/AIESf40AZlFaf2/TP+gHD/4ESf40fb9M/wCgHD/4ESf40AZlFYer67NJ8UtM0K1t obTT30S7u5Y0JYySrPbopLMSQArvgDH3jnOBjsrQWUGiLdz2CXMjXLR/NI64AVSOh9zQBk0V p/b9M/6AcP8A4ESf40fb9M/6AcP/AIESf40AZlFaf2/TP+gHD/4ESf40fb9M/wCgHD/4ESf4 0AZlFaf2/TP+gHD/AOBEn+NH2/TP+gHD/wCBEn+NAGZRWn9v0z/oBw/+BEn+NH2/TP8AoBw/ +BEn+NAGZRWn9v0z/oBw/wDgRJ/jXK/E7xCdN0bTW0nT4LOe61vT7SSXe0hEUlzGsgAYkZKk rnBwCcYOCADXos/+Yp/25/8At1RRZ/8AMU/7c/8A26oAK4y8/wCS4aX/ANi1e/8ApTa12dcZ ef8AJcNL/wCxavf/AEptaAPMv23P+RH0L/sJH/0U1FH7bn/Ij6F/2Ej/AOimooA+k/E//IZk /wCuUX/otaPEP+us/wDryg/9AFHif/kMyf8AXKL/ANFrR4h/11n/ANeUH/oAoAzKIv8AkHaZ /wBg20/9J46KIv8AkHaZ/wBg20/9J46ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigDT8Q/66z/68oP8A0AVwPxAt7e/1Dwrpd9BFdWF7rDx3VrMgeKdFsrqRVdDw wDojAEHDIp6gV2nifUtOhu7WGa/tY5EsoAyPMoZf3YPIzxwQfxrjfGVlo/iawWwuPEyWtmc+ dBGtnPHccqV3rcRSD5SuRjHJ5zgYAMXXdQn8NX9p4X+Huj2rSzfaLm4gto45Y7Pyhb5QQNcQ JHu+0Rv8rjkltjGQuKNj4o8R6/rehypcWOn251+2g+zwEzho20Z7uVHlSQJMCZAEZQFBRXw/ Are0rw74NtvDcfh/UbnSdb0+GczwQX1tZCOFiD9yOKJIxyznO3OXbnmt15vDT+bvl0lvOnS4 ly0Z3yps2SN6svlx4Y8jYuOgoA8d8PeLLjTNEfxdNpGj3CF7dobRLYxm0SLw6bsxQOWby49z MqqF+QSzfe8w49E1bW/EekWsumz3+j6jrtw8S6dHZWJDuWErsr28lwoA8uCZhIZ1DbWAGUAf ZtE8J2awraLoluIHWSIRCJfLdYvJDLjoREBGCP4fl6cVWh0zwHBo0+iw6f4aj0u4cSTWSQwC CRxtwzRgbSflXkj+EegoA4Oy8ceJnn1fV/smZ4rGxsP7MZQcXr6pd2XmqPO8teU3NHvO7CL5 wC7zsL4x8Uw6cBqNto9heWl1It79pdM+SkcTh3ihnlNvHmZFeUvL5QMcjRlJCY+ogtPBdvYL YQW3h+KzSCW3WBI4VjWKUgyxhRwFcgFl6MQM5oitPBcVhZ2EVt4fSzsZxcWkCxwiO3lBJEka 9EYFmO4YOSfWgDoKKxJE8JyRvFIuiOkiTxurCIhknbdMpHcSMAzD+I8nNX/7W0r/AKCdl/3/ AF/xoA5i8/5Lhpf/AGLV7/6U2tejP/yK0X/X6/8A6AteaPcW9z8bNMktp4pkHhy9BaNwwB+0 2vHFeiXt5Z2vhi3W6u4IC97IVEkgXdhEzjPXGR+dAFOvJPCHhe41C8n1G28P+HbF18TX0512 OU/2iyR6lKzx7RCOHVTCf333GOQfuH0/+1tK/wCgnZf9/wBf8aitr7QrWMxW15psCM7yFY5E UF3Ys7YB6szFie5JJ60AeYeKPF+oa34c8H2Uc2mQ6hq9jpmrzr5bP5Ep1HThG3l7wfKLSy8E 5bZgMMGjXde1AePNPt9Ut9MvrzTJzp0kgtmWGXzbzRHEqxM7FGQXA2/O3zxhu+0db4i8O+Dd XsJrSO50nTvtE7z3MlvbWUjTs5Vn3iaKRW3NHExOMkxIc8VL4b0bwpo2mQWDahpuoJbOWtWu IbOP7OC6SbUWGONVHmRpJ93O4A54GADl73XNf1nVPDSJJoRvhrfmW2xnMccUthfbZOCftEWw b0lRkEp3IVgZGwXnxC8WNJcR6bolrc/2RBLLqcv7pIZfLurq3J3y3Ef2ZW+yO+7E+0PyDszJ 3dsnhO1kMtsuiQO1094WjESk3DqVebI/5aMrFS3UgkE81Fc2ngu5mtZri28PzS2c73Fq8kcL NBK773kQn7rM/wAxYck8nmgDnJfF+vppxvTNoUaDVdRRvNjdfKtbW4aAFwHJClgvmXIDLF5i ExFdzr6HWJMnhOeOCKZdEkS3ujeQq4iIjuCzMZlB6SbmZtw5yxOeTRInhOSN4pF0R0kSeN1Y REMk7bplI7iRgGYfxHk5oA264z4uf8gjQ/8AsZdK/wDSuOun/tbSv+gnZf8Af9f8a5D4p31l c6XocdteW8zjxHpRKxyBiB9rj54NAHd0Wf8AzFP+3P8A9uqKLP8A5in/AG5/+3VABXGXn/Jc NL/7Fq9/9KbWuzrjLz/kuGl/9i1e/wDpTa0AeZftuf8AIj6F/wBhI/8AopqKP23P+RH0L/sJ H/0U1FAH0n4n/wCQzJ/1yi/9FrR4h/11n/15Qf8AoAo8T/8AIZk/65Rf+i1o8Q/66z/68oP/ AEAUAZlUo9W0oWOnqdTstyafaow89cqwgQEHnqCCCPartXf7W1X/AKCd7/3/AG/xoAxv7W0r /oJ2X/f9f8aP7W0r/oJ2X/f9f8a2f7W1X/oJ3v8A3/b/ABo/tbVf+gne/wDf9v8AGgDG/tbS v+gnZf8Af9f8aP7W0r/oJ2X/AH/X/Gtn+1tV/wCgne/9/wBv8aP7W1X/AKCd7/3/AG/xoAxv 7W0r/oJ2X/f9f8aP7W0r/oJ2X/f9f8a2f7W1X/oJ3v8A3/b/ABo/tbVf+gne/wDf9v8AGgDG /tbSv+gnZf8Af9f8aP7W0r/oJ2X/AH/X/Gtn+1tV/wCgne/9/wBv8aP7W1X/AKCd7/3/AG/x oAxv7W0r/oJ2X/f9f8aP7W0r/oJ2X/f9f8a2f7W1X/oJ3v8A3/b/ABo/tbVf+gne/wDf9v8A GgDG/tbSv+gnZf8Af9f8aP7W0r/oJ2X/AH/X/Gtn+1tV/wCgne/9/wBv8aP7W1X/AKCd7/3/ AG/xoAxv7W0r/oJ2X/f9f8aP7W0r/oJ2X/f9f8a2f7W1X/oJ3v8A3/b/ABo/tbVf+gne/wDf 9v8AGgDG/tbSv+gnZf8Af9f8aP7W0r/oJ2X/AH/X/Gtn+1tV/wCgne/9/wBv8aP7W1X/AKCd 7/3/AG/xoAxv7W0r/oJ2X/f9f8aP7W0r/oJ2X/f9f8a2f7W1X/oJ3v8A3/b/ABo/tbVf+gne /wDf9v8AGgDG/tbSv+gnZf8Af9f8aP7W0r/oJ2X/AH/X/Gtn+1tV/wCgne/9/wBv8aP7W1X/ AKCd7/3/AG/xoA4S78N/DO8upru70DwjcXE7tJLLLZ27PI7HJZiRkkkkkmov+ET+Ff8A0LPg z/wBtv8A4mvQP7W1X/oJ3v8A3/b/ABo/tbVf+gne/wDf9v8AGgDz/wD4RP4V/wDQs+DP/AG2 /wDiaP8AhE/hX/0LPgz/AMAbb/4mvQP7W1X/AKCd7/3/AG/xo/tbVf8AoJ3v/f8Ab/GgDz// AIRP4V/9Cz4M/wDAG2/+Jo/4RP4V/wDQs+DP/AG2/wDia9A/tbVf+gne/wDf9v8AGj+1tV/6 Cd7/AN/2/wAaAPP/APhE/hX/ANCz4M/8Abb/AOJo/wCET+Ff/Qs+DP8AwBtv/ia9A/tbVf8A oJ3v/f8Ab/Gj+1tV/wCgne/9/wBv8aAPP/8AhE/hX/0LPgz/AMAbb/4mj/hE/hX/ANCz4M/8 Abb/AOJr0D+1tV/6Cd7/AN/2/wAaP7W1X/oJ3v8A3/b/ABoA47RNM8B6HdNd6Lp/hrTLh0Mb S2kMELshIJUlQDjIBx7CjW9M8B65dLd61p/hrU7hEEay3cMEzqgJIUFgTjJJx7mux/tbVf8A oJ3v/f8Ab/Gj+1tV/wCgne/9/wBv8aAPP/8AhE/hX/0LPgz/AMAbb/4mj/hE/hX/ANCz4M/8 Abb/AOJr0D+1tV/6Cd7/AN/2/wAaP7W1X/oJ3v8A3/b/ABoA8/8A+ET+Ff8A0LPgz/wBtv8A 4mj/AIRP4V/9Cz4M/wDAG2/+Jr0D+1tV/wCgne/9/wBv8aP7W1X/AKCd7/3/AG/xoA8//wCE T+Ff/Qs+DP8AwBtv/iaP+ET+Ff8A0LPgz/wBtv8A4mvQP7W1X/oJ3v8A3/b/ABo/tbVf+gne /wDf9v8AGgDz/wD4RP4V/wDQs+DP/AG2/wDiaP8AhE/hX/0LPgz/AMAbb/4mvQP7W1X/AKCd 7/3/AG/xo/tbVf8AoJ3v/f8Ab/GgDz//AIRP4V/9Cz4M/wDAG2/+JqW08N/DOzuobu00Dwjb 3EDrJFLFZ26vG6nIZSBkEEAgiu7/ALW1X/oJ3v8A3/b/ABo/tbVf+gne/wDf9v8AGgDG/tbS v+gnZf8Af9f8an0q4t7lNVktp4pkBswWjcMAf9J44rS/tbVf+gne/wDf9v8AGorm+vblBHc3 lxMgOQskhYA+vNAFeuMvP+S4aX/2LV7/AOlNrXZ1xl5/yXDS/wDsWr3/ANKbWgDzL9tz/kR9 C/7CR/8ARTUUftuf8iPoX/YSP/opqKAPpPxP/wAhmT/rlF/6LWjxD/rrP/ryg/8AQBR4n/5D Mn/XKL/0WtHiH/XWf/XlB/6AKAMymW0d7JaW9zI+mRLPBHOI/tEpkCugcD/U7d2CON2M96fR F/yDtM/7Btp/6Tx0AeSX3he48QeLfG32Tw/4da4fUY4ItduZSL7T3On2uJIVELEmMkOuJU+b PK/eqXWPiF4stIdb1SLRLVdKtv7UgtJJ/KVTLZpcENu+0eZNua2bMYhQgMx3kR7n9Sht7eCS eWGCKN7hxJMyIAZHCqoZiOp2qq5PZQOwqhL4e0CW/vL+XQ9Me8voDb3c7WiGS4iIAMcjYy6k Ko2nIwB6UAcp4h8Y6x4en1GS9Oj3lvp2nSyMkW+Jrm4itjO6q+5xFJgKRbspPlv5qyPtdFi1 DxL4vsPE1n4U8zQrzULmeD/TPsssEKRTQXzf6rzHJZGst33wHD7P3f8ArK7r+ztP/tX+1vsN r/aHkfZ/tflL53lbt3l78Z27uducZ5qrpXh7QNKhjh0vQ9MsYopzcRpbWiRqkpQoZAFAwxQl d3XBI6UAcDrfxC1610Oa+07T4r640ZLuXWoYrVdjRQXE0KyK73CGISG1nICrcMncNgeZe0y8 +w+Anm+y2tzu8YTQ7LiPeo8zXWTeB/eXduU9mVT2rq9U8K+GNUjii1Pw5o98kLySRrcWUcgR 5G3SMAynBZvmY9zyav8A9naf9m+zfYbXyPP+0eX5S7fN8zzfMxjG7zPn3dd3PXmgDyTWPE/i fWvBmgwamNHhfxPa2F3GsEMjxQob2wikjmDOPOjlW6+ZBs2qGjLSZ31seJfHev6Vol9r8Uem SWbT6rZWlo0D+ZFLZxXbCWSXzMSK5s2+QIhAkHzHZlu+OjaOY7SI6VY7LNFjtV+zpiBFZGVU GPlAaKJgBjBjQ/wjEUvh7QJb+8v5dD0x7y+gNvdztaIZLiIgAxyNjLqQqjacjAHpQBx7+IvF 58Ry6Ol7oQzqqaRFKdNlO2Uacl687D7R8ynEiCMEFdysXbaQ1aD4iatff2Hq2naV5mkXX9nQ 6knlKfss955JC+e0ysdq3MLfLbuDnG5ST5fof9naf9p+0/YbXz/P+0eZ5S7vN8vyvMzjO7y/ k3ddvHTiqEvhXwxLdWN3L4c0d7jT0jjspWsoy9skZzGsZ25QKeQBjHagDzfwR4l1/wCx+GdL 8zTJdX1bRNK/4m1xavI/7yG/n/fDzA02Ftto+dfnld+h2Vffx54nMGu3UVto/wBn8O6dJeXp ZJN908FzewSJGu7EYkFpuDEv5WcES5yvfXPh7QLm2uba50PTJoLvH2mOS0RlmxI0o3gjDfvH d+f4mY9STUq6No62sloulWK28lqtnJELdNjW6hgsJGMGMB3AXoNx45NAF7ybl/mjn0xVPQTT TK/4hYWH5E/0o+z3n/Pzo3/gRcf/ABiiigA+z3n/AD86N/4EXH/xij7Pef8APzo3/gRcf/GK KKAD7Pef8/Ojf+BFx/8AGKPs95/z86N/4EXH/wAYoooAPs95/wA/Ojf+BFx/8Yo+z3n/AD86 N/4EXH/xiiigA+z3n/Pzo3/gRcf/ABij7Pef8/Ojf+BFx/8AGKKKAD7Pef8APzo3/gRcf/GK Ps95/wA/Ojf+BFx/8YoooAPs95/z86N/4EXH/wAYo+z3n/Pzo3/gRcf/ABiiigA+z3n/AD86 N/4EXH/xij7Pef8APzo3/gRcf/GKKKAD7Pef8/Ojf+BFx/8AGKPs95/z86N/4EXH/wAYoooA Ps95/wA/Ojf+BFx/8Yo+z3n/AD86N/4EXH/xiiigA+z3n/Pzo3/gRcf/ABij7Pef8/Ojf+BF x/8AGKKKAD7Pef8APzo3/gRcf/GKPs95/wA/Ojf+BFx/8YoooAPs95/z86N/4EXH/wAYo+z3 n/Pzo3/gRcf/ABiiigA+z3n/AD86N/4EXH/xij7Pef8APzo3/gRcf/GKKKAD7Pef8/Ojf+BF x/8AGKPs95/z86N/4EXH/wAYoooAPs95/wA/Ojf+BFx/8YohSU/ahK9qzQeSc27u6sJPN7ui EEeV6H73Wiiz/wCYp/25/wDt1QAVxl5/yXDS/wDsWr3/ANKbWuzrjLz/AJLhpf8A2LV7/wCl NrQB5l+25/yI+hf9hI/+imoo/bc/5EfQv+wkf/RTUUAfSfif/kMyf9cov/Ra0eIf9dZ/9eUH /oAo8T/8hmT/AK5Rf+i1o8Q/66z/AOvKD/0AUAZlEX/IO0z/ALBtp/6Tx0URf8g7TP8AsG2n /pPHQAUVoeGvD+oa+l7NBqdrZx21z5AR7NpSf3aPnIkX+/jGO1a3/CA6r/0MNl/4LW/+PUAc zRWVrmo3Hh3xhJoWsxr9jeZLa01VEKQyXDIj+Q6knYxEi7TuIYkr8rbA+rQAUUVwPxVvzPdW Hh+K4vrcFHv5rmy0yXUHgljI+yb4olZlBm/fBjhW+yMhyGbAB31Feb3fxGuI/C+va20NjYnT /DNtqUcFy5PlXsjXSNbSHK5KywJHtwrbtw64APDWr+J7iVdGtNSsRcXeo65cRXV7aSXHlW9t fiEQlRMhY5lBDBlCqgTYfvUAekUV5d4MXw54zs9b8X+JdLsUIe2nhublgZdNhbTbScrHcEBo gjSSOGUrhizDBJNS+JfHev6Vol9r8UemSWbT6rZWlo0D+ZFLZxXbCWSXzMSK5s2+QIhAkHzH ZlgD0yivLvEfjnxP4fs9YkuTo96+nPc2Q8u0khD3Caa+oJNgytiPaBEY+pOXDjOwVfHfifWN B1iyXWhY6ncaG7auslpC9okyNpuq4iKs8pBBtj8+453j5RtywB63RXl0Gv8AjS68SeH9K1eK LS7gaxEznZHH9ot3s75mjeCK6mIGYMrIz4LYOw+Ud2n8NfF3iXxDdWsusaPFY2GqacdRsSTC jqmY8IAtxI8wxKuZDHDtwMrmQBQDvqK8z8XeI9flN5Y2uoaZZsdVso7CSLezbRqNvC5LK4E6 5Z0ljBiaIjy2DrIkhPEvjvX9K0S+1+KPTJLNp9VsrS0aB/Mils4rthLJL5mJFc2bfIEQgSD5 jsywB6ZRXnkvizxZF4sk09dLtbjTdPvrTTb+7CRQxySzRwM0ivJch48faF2xCKUsVCh8v8m7 4F1zUNY+2DUZNMZ02TRLaM3EUm4oQSSJomVQUnUqHyymONo2WgDpqK8ph8b+L08P+Hrm4l0K S88R2Npd2rx2EqR2fm3VlC6upnJm4vcgho8GPkHd8t628XeNNQ1m6h0/R7GGynur/TtOmvDG kQuLfzlVy4uDLKGeA5jWBCqsx3ER5cA9Iory7xF8QbiOzh8SRaBFJpds7mGK+hMd0txFpt5c ThWyyoV2xwEgEq4uUI4FbEfiXX7Dxrp/hbVJNMvZbieFpLq2tXt18qW3vnCBGkfDB7IfNuII kI2gjcQDuaK880TxzqGq3VhPb3GhNps19cQNKjs4kT7bNbwHerHyt6Rbkcq6TOGjBiJQtL48 8XeJdK1+5stC0eK7t9N06PUb2SUwqjI7zAI0klxEIABA2ZNs2N2So24cA76ivJPGXjHxPH4L 1q9lNjbW9w+t6ZZG08xLmJ7aO9aO4Mm7CnFrt2AdSHDj/Vi14l8Zaxos19d6naaPqaaNqLwR qlq8Um+PRZbySRHZ32F2OwcHahYEvuyAD1GivN4PFXjSK1u7PU7Cxs9SR4GhaSCMytE4mLlL KG7leUqIGbiVWZfM2KzRbZOi1/X7uHwrp91pZtZ9V1Ty0sY7VReQzSFDKwRmkgV18tJGDs8Y IUHkkIQDpqK8ptviD4quNO1jUP7O0y1i0HSnvr+KdWM00kNxewyQqEcpHv8AsmQ26QRk4xMD uW9NqOsax4r8LajNPYx6Wvia/s4bRLZ/PV4La/hLtMZNrBvLZtojGNwGTtJYA9Iq7ZaXe3kB ngjQx7imWlReQAT1I9RVKtN/+RWi/wCv1/8A0BaAD+wtT/55Q/8AgTH/APFUf2Fqf/PKH/wJ j/8Aiq4vRvFumahda7G8sVrDpDkvPLJtRoVLo8rFgAgWaC5jIJ/5Y7vuspNnWvEuj6Rqem6d e3cSXGoXSWsa+Yg2PIkzRlwSCA5gdF67mwB3wAdX/YWp/wDPKH/wJj/+Ko/sLU/+eUP/AIEx /wDxVcXqvi/R4LK9bTL6x1W9tLqCyktYLtCYbiaYQRrNt3GMeY3zEqSArYViMGW21q7sbC6u /F9vpmhQW+xvtS6kJLUqx2gGSRIyrBsAgrj50wzEsFAOv/sLU/8AnlD/AOBMf/xVH9han/zy h/8AAmP/AOKrlJvFXhiCSCKbxHo8b3FqbyFXvYwZLcKzGZQW5j2qzbhxhSc8GiXxV4YiurG0 l8R6OlxqCRyWUTXsYe5SQ4jaMbsuGPAIzntQB1f9han/AM8of/AmP/4qj+wtT/55Q/8AgTH/ APFVxel+L9HnghOpX1jpdxdajd2Fpb3F2ivcvBcvB8gbBYsVU7QDjeBz1Jb+NfDDaZcajd6z Y6db22oz6bK17dRxbbiJ2UoSWwCQhcA8lSDgZoA7T+wtT/55Q/8AgTH/APFVn+IFGgWMd7q0 sFtBJcw2sZ85XLyyyLHGoVSSSWYduBknABIZXGfFz/kEaH/2Mulf+lcdAHZ0Wf8AzFP+3P8A 9uqKLP8A5in/AG5/+3VABXGXn/JcNL/7Fq9/9KbWuzrjLz/kuGl/9i1e/wDpTa0AeZftuf8A Ij6F/wBhI/8AopqKP23P+RH0L/sJH/0U1FAH0n4n/wCQzJ/1yi/9FrR4h/11n/15Qf8AoAo8 T/8AIZk/65Rf+i1o8Q/66z/68oP/AEAUAZlEX/IO0z/sG2n/AKTx0URf8g7TP+wbaf8ApPHQ BLDoWj+I/C1zpetG7EMniKMRG30eHUMSG1jUF1lt5kjTDHMpVQvdwCQcmy8HfD7w94lguVTx RJdaZeLIPJ+HUBRnjfPyywaWCRleHjceqt0NdF4fnt4NPj+0XNpB5niq3SP7Rrcunb3NvFhE 8sH7Q57W7YV+54rnfE+saJF4l1SKXxD4XikS8mV45vi/qNm6kOchoETbCR3jXhfujgV9bksq 8qPso83K0/h5O9vtamFS17/5nln7R3xp+Dn9oappdtoXirxTqV2+zU7Y63qOlWULqhhZXgLA eavloCvkgEE5bcCK4XwT+07b2OnaVpWv+Gr6dLW1jgudQjvxNPM6R48zY6rkswycvxknJxz4 l4E0S4+IPxJ0/RtS8QRWdzrV6ftGpahIXJdsszEsfnkc5ChmG52UFlyWH2FqXwwtfhd8Hb7S 9Gv9GSxmtGPiS71EeRcavJvjCWyTNIiW0Ug86L5txTeCAZA7R/KNJyfLt5/56f8ABNz0DSb+ 01XSrTVLCXzrO8gS4gk2ld8bqGU4IBGQRwRmpVt7dbqS7WCJbiRFjklCDeyKWKqT1IBdyB23 H1NRaSLRdKtFsLb7LZiBBBB5Bg8qPaNq+WQCmBgbSARjGBiuY+JWj3erf2W1ro/9ptBOSoNy I1iY4AdgSCmBuIuIj50LBSiyK0iGQN268PaBd7PtWh6ZP5fn7PMtEbb5+fPxkceZubf/AHsn Oc0ar4e0DVYZIdU0PTL6KWcXEiXNokivKECCQhgcsEAXd1wAOleb+KND8UrpDabbQRaZDY6j rGotrkuoJDFCLmC/aGRcEuAhuUDsQpVgCodcsvMpeeEZNTvdcsfD+j6b4UR7CK9sDc6cltqU ipqGYwUmNtJIrS28pR3DARhsZCbgD27UPD2gahqtvq1/oemXeoW23yLue0R5otrFl2uRlcMS Rg8E5qtrGm+FbKa61jUtI0xZ9R8rT7q5ayV5LlZnSFIpGCksrMY1weMYzwOPH9K8G3+taXaX 9npWpwafN9q/seCybT4105m1C7kWbzJVkMKtHJblZbTeSI9w3bYs9Xrvg++1C+1/PhuKWC4u ra6lM1wj/wBoJFdxTGEZI84GKIqq3AXyWZo0doXzGAdz4h8NaPrmkajp13aRINQSVZZ4o0Eq vJAYDKrEH955RKBjn5eOnFS6V4e0DSoY4dL0PTLGKKc3EaW1okapKUKGQBQMMUJXd1wSOlYX hfR7uy8c61qEmj/Zobncxu2uQ7TsWG0Ag7pVCgYEygwEukTPE42cfqPgDUjaapPaaDarqFxB r9zHMhiWRr57vfp02/OfNWNpNkhOYwzDK5IIB6JLpvhXwx4bvJV0jTNN0i0zqFwkFkqxq0QD +bsReWXy1IIBOVXHIFXtN0bR9Mury703SrGyuL5/Mu5be3SN7h8k7nKgFjlmOTnqfWvKfGPg vxNrfiTUpLfTpba61FL+0uL5FsorKS2ks54rdWdR9schjbb1fcgdWKjCx46HT/D7ReJhdSeC NzST2sum3nnQRf2PapBCrWu5HMiYZJj5UQaJ/N2ltryEAHT6BFoGv6INft9HtRF4isYZrrzr ZPMuYmi+RJsZ34RtuCSACQOKsy+HtAlv7y/l0PTHvL6A293O1ohkuIiADHI2MupCqNpyMAel eXJ8PdZtPB2hadpllLZztoEcOvGKeJpbmWOayYwsZCySnyku4kD7olVih2xtirMHgzULfQLK 3t/D19Oiai81va3t5ax/ZNyRruMduqRW4ysriW3ZpomIdQ/mzR0Ad/qMWgDxlpUk+j2txr0s Extrv7Mhmt4IwA7eY3IXdMqbVJJMvTG8jT0/TtP0/wC0fYLG1tPtM7XE/kRKnmytjdI2B8zH Ayx5OK5T4geHNT1vWYLnTFiiuINA1W2s7532m0vJ/s6xOrDLqcLL86jIGR3AOFYeEZZ/Fek3 9p4Oi0LQrfUbe4bTJFtlEc0VtfA3Xlwu0eS81qoYHfmIEgBFNAHYeFfBXhjw1o0Gl6Zo1iiR pbrJKbWMS3DwYMcspVRvkDDduxw2SMVLZRaAPHOpfZ9HtYtcSxt5rq/W2RZJYpWkREMg+dsf ZuQeMBMZ7YXjHwnq2seKnnsb/wCxWt3Yw+bceSsnkT2jyyW3ylgW/fXKzccf6JsbIlOOY/4Q HVp9O8Q6jcaT/wATe60RrjTENwp+yalLcX9ztQ7tvmwtcRqs/HVipUMwoA9N1MaJo2lTapeW 1rb2em+dqDSCAHyW2u0sqhQTuIeTJAyd7dcnMUPhXwxBo0+iw+HNHj0u4cSTWSWUYgkcbcM0 YXaT8q8kfwj0FeZ+MfBfibW/EmpSW+nS211qKX9pcXyLZRWUltJZzxW6s6j7Y5DG23q+5A6s VGFjx1fjOaKws/CB02ytbbUrW+ifTtCklSFpFaFrZ0Hl79qwpc+Y5jVwqxHsdwAOrGjaOLq2 uxpViLi0eaS2l+zpvheYkyshxlS5JLEfeyc5o1LRtH1O6s7vUtKsb24sX8y0luLdJHt3yDuQ sCVOVU5GOg9K830zwPqWkXNhpyaZ9vvLOfTRY+IcRJ9ls7eO2SaDJfzo/M8m5/dorIftHzN8 z40/Aej+IbHVfDFvqGj/AGWz0Hw7NpMl0bmN/Pn3WY3oikkRMIWKs2G4YMiYXcAd0mnaenlb LG1XyZ3uIsRKNkr798i8cM3mSZYcne2epqK00bR7NYVtNKsbcQOskQit0Xy3WLyQy4HBEQEY I/h+XpxXknjzwh4q1TWtXurLRro317BqFvNcW4sIbW4t3sp47eMyZF07bjbblkJjDqxGFVCN i78EXi/EZNQgsr5beK6tX02a0NlFbWNpFHErW5dozcxglJv3UOI2EoUld8hAB2Fpovg1Y77w jbaDo6W+yK8u9OTT0WBhIzCN2XbsYkwH1I2DOOK2NV07T9VsJLDVLG1vrOXHmQXMSyRvggjK sCDggH6gV558ULCKx1m/8S3EVq0r2OnpppLIJp7mzvHu/sSZO/dcfu1UIH5jYkZVA3O33hS6 PiPXdLHh6LUtdudHS4s9Si8kpo1zdXuozB1lkZZQEeRcSRIXPlbtoO1aAPVtK0LQ4NMmsrfw 1Y6fayo9pJai1hVJIQ8mFKplTG293Cn/AJ6nIBLCpf8AhHtA/t7+3/7D0z+1/wDn/wDsifaP u7P9Zjd935evTjpXmUngHVpovF95NpO/UJLG7OhsbhfkumvtSmilQbsJKqzwMshwyb2AZfnF VrSfTf8AhZVjDaaRa6x4jsNb1K7vdQsbizmne3MN4I4HPmiZNnmQQ4lVI1ZFXdjYSAe01a1n +0P+EBm/sn7L/aHnzfZPtW7yfN8pdm/bzt3YzjnGcVVrK8Tah4zW3t9P8N6XoFxaq7TSzahq E0TlyANoRIWGAFzktznGBjJAOD8Q+AX0rw0ltF4j1i8sIdHuNCK3Fkt1Ja2c8IQGGK1hWSWQ SRW2dxI2CQ8Hmjw/a614m8bjxXPDFaPZPZFbOSyvbcBES/icebcQx+Ydt2ZAVQcqI2C8Stvf afip/wBAbwZ/4Nrn/wCR6PtPxU/6A3gz/wAG1z/8j0AY0XgTX307RbOeTTI/+EbsYLTT2Sd2 +3+VcWkwaUGMfZ932JVIXzceaTk7AH3NRsPF+pPp+p3FpoUF5pV8Lm1sY72V45swTwvvuDEC vE+QoibBjwSd/wC7Z9p+Kn/QG8Gf+Da5/wDkej7T8VP+gN4M/wDBtc//ACPQBlWXgPWInvJp Lmx33l1p946q7kRvFq1xfzIDt+YBZwitgbiuSEzWZ/wiXic6p4s0CG0sTZa5p0kM1/LcSIIE uL7UpAY1ERE0iR3ClkLJg7RuwwYdR9p+Kn/QG8Gf+Da5/wDkej7T8VP+gN4M/wDBtc//ACPQ Bzl78NNSmur9nNrdxap9pgnQ6veWscMUl7dzqzRwbftWUu8NG7IAUID4ckXtT8C6t9ot7m2M V2bS61Noo01m600yR3twlyWaWBSwKMpj8v5lcYclSNg1ftPxU/6A3gz/AMG1z/8AI9H2n4qf 9AbwZ/4Nrn/5HoA2/D1jeaPpGnaPFa2ItbJIrVWimkX9ykAAZUYMQfMG0IXb5fmLk/LXP/FF rhvDvh1ruKKK4PiHSTLHFIZEV/tUWQrFVLAHOCVGfQdKl+0/FT/oDeDP/Btc/wDyPWfrWl/E TxA2mW2qWHhW1tLbVbO9lkttSuHk2wzpIQFaAAkhSOSOSOaAPQ6LP/mKf9uf/t1RRZ/8xT/t z/8AbqgArjLz/kuGl/8AYtXv/pTa12dcZef8lw0v/sWr3/0ptaAPMv23P+RH0L/sJH/0U1FH 7bn/ACI+hf8AYSP/AKKaigD6T8T/APIZk/65Rf8AotaPEP8ArrP/AK8oP/QBR4n/AOQzJ/1y i/8ARa0eIf8AXWf/AF5Qf+gCgDMoi/5B2mf9g20/9J46KIv+Qdpn/YNtP/SeOgCPQ/HvgjQZ L/S9b+Imn+G76DV47mW3a6t1kmi+zxfu3EqsQjdyu1uBhh3de/ET4fXF5PPF+0WbSOSRnSCG 40opECchFL2rNgdBuJPHJJ5p1Fb0sROl8KXzjF/mmJq58yXmj/BGb9p6a+vvFt5q2hNIt5c3 eoxQzWep6hMzO4MsBRYoVaSNjuQIWSVGZFwa9X1LxJqHib4it4N1bxP4bfRzJa6xo62Nvme9 ijl8+JVl80r8qxwFj5Y8xN4VV8slNPxJ8LvAHiG6+16l4Ys/tDO8kktqz2ryu5yzSGJlMhzz ls4ycdTmHw38Jfh34e1NdS0vwzAt0jB43nmluNjhgwdRKzBXBUYcAMOx5Nb1pYScVKPMpW1W lr+VrWXlbTa4lzI7eiiiuEoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKLP8A5in/AG5/+3VFFn/zFP8A tz/9uqACuMvP+S4aX/2LV7/6U2tdnXGXn/JcNL/7Fq9/9KbWgDzL9tz/AJEfQv8AsJH/ANFN RR+25/yI+hf9hI/+imooA+k/E/8AyGZP+uUX/otaPEP+us/+vKD/ANAFHif/AJDMn/XKL/0W tHiH/XWf/XlB/wCgCgDMoi/5B2mf9g20/wDSeOiiL/kHaZ/2DbT/ANJ46ACiiigAooooAKw/ FniW08OXOhJer+61fVU0xZMn93JJHI0ZwAc5dFTsBvyTgVuVz3jbw4niU6TbXKxSWEF1M19E 7splhks7m3ZVK85JnHccZIOcZAIk8X2k3irWtAtvsol0f+z1uZbi4MK+ZdOwEYyhywQIVAJD tIqZU5NXn8VeGEj1CV/EejqmmOI79jexgWjlioWU7vkJYFcNjkEVykXgHULYyCK9tZ2l/siW edwyNPPb6jLeXUpQAhPMMrFVBwCSvyqAaLTwhr//AAj+jaHcQ6EsWhf2fBa3iyPJPcxW91bS Oxyg8jcltkxgyBmKZcBMsAdrDrOjz6zPosOq2MmqW6CSayS4QzxoduGaMHcB8y8kfxD1FVZv FXhiDRoNam8R6PHpdw5jhvXvYxBI43ZVZC20n5W4B/hPoa5l/B2sTyJpsw0dtLtdR1DUoZ59 85uHulugYZbYqq+Wv2tskSneIwMLvOw03w54n026stbgt9HudSiS6t5LWa+kGYpTb7We78kv PIgtUQM0QYqyhmZoy8gBpy+O9Hg8VzaDcyRQvHqMGmBmnQN9oltnuE3ISNsbKoRGyS8m5Qo2 7jfl8S2lnc+IE1VfsUWiwJeSSZMm+0aMt52FHHzxzps5b91nGGWuY8LeAdQ0CDTokvbW6/s3 VbW5iJDR+dEmlx2D7uDsbiSQKNwO1VJG4su74t8L/wBtarY3Mc3lQPi31WMNtF3ahvNWNhgh /wB4gTa3y+VPcjq+aAL13r1vba/Npsoijt7TTmv7+7lmEaWqF9sW7PBDBLglgfl8nn7y1j61 480+1utGGli11ez1T/V3dtdq0Y/020tTgqGDYN0T16xle+RHYeE9YsvC+o2yavLPrNy6R/a5 rlzJLawsEihMwXfGZIlJd1BKSzzSIMkCuYsfhx4h/tcahO9jbg6it0Ym1W5vnVFn0p8edMgd yRYTdem5FHGSoB3Wq+NfDGnWV7dvrNjcJp91Ba34guo2Nm8swhBm+b92AxJbdjAVuuMVsahq On6f9n+331rafaZ1t4PPlVPNlbO2Ncn5mODhRycV5lo3w01Kx061ts2pn0mC2isp5tXvLn7V 5Fxbz4Mcn7uzVzaoCsay43DBxHtk7Dx1oeoax9jOnR6Yzpvhla7VuIpNocEAETRMqkPAwUPl WEkbRq1AGxDrOjz6zPosOq2MmqW6CSayS4QzxoduGaMHcB8y8kfxD1FRaV4h0DVYY5tL1zTL 6KWc28b212kivKELmMFScsEBbb1wCelcDe/DK7vpNVsZpYktbp9Smhvn1O7mKPeLOpC2RZYI yguWG8M24KflUyEpu32keJ9QvbPXptN8O2+qafdJLDbRXcjC4QQ3EREl0YQygfamZVETYKty fMJQA6FvEOgLNPC2uaYJbeCS4nQ3abooo3KSSMM8Krqysx4BUg8iqK+L9Hm1fSra0vrG6sNS tbieK/iu0aIvHPbwiNSMhiz3AUYP3lxgk8cfbfDrXG03WodQv7GW4vXgnRrWSa3EkkWq3d9t 3DLwhhNGu5WdkO4jdtBahrng7UtNtk1WOy3ag3nyW1pb3N5qLSX/AJljLaiWeUEmItYAPI3l Kisq5GPMIB6u2o6ethPftfWos7fzPPnMq+XF5ZIk3NnA2lWDZ6FTnpWZH4t0B9VuLD+0rVfJ 0qLV/PadBC9q7SDzVbdyq+Xlm+6A6c81Vbw1LB4Kn0WJrW+upZ5LxzOHijeeS4Nw+woS8Pzs 3luCzRHY3zlfmwj4K1sxPO0+mPeTQWMswUGJTc2l892oJVAG80yuryhEww3iI79iAHYWfiHQ L37B9j1zTLj+0fM+w+Vdo/2ry/8AWeXg/Ptwc7c471FD4q8MT6NPrUPiPR5NLt3Ec16l7GYI 3O3CtIG2g/MvBP8AEPUVx914D1jV73Wr3UrmxsX1zTtRtbiO3d7gWr3ENlAhVmVPMAW0ZzkJ guFGcbqIPBetR2t3fQ2djb6s7weQZNevbyVPKE210u51YxEGdvk8l1K+Yj71mOwA7rW9Z0fQ 7VbvWtVsdMt3cRrLd3CQozkEhQWIGcAnHsaq3HiPR91vFaaxo81xcJBcRRPfonmW8sqxiVcZ LAlgEwMOxVcjdkYfiqw1izi8ExaLpljeXGnajhokD2lpGgsLqMn5VlMMeWAUYbkquec1l2Xg PWInvJpLmx33l1p946q7kRvFq1xfzIDt+YBZwitgbiuSEzQB3Tazo62sd22q2K28lq15HKbh NjW6hS0wOcGMB0JboNw55FUbfxboFzquk2FnqVrd/wBrwXM1jPBOjwzeQyCRFYN8zfOThc8I +cbawo/BeoWltq66fqHludtvpCGZlFvZeYJpbdWVc2+9meHdFnZFFbEAtEM4Vl8NtZlj1r7Z Pa2f9rwahZMn9o3GoNBFc2tpGJfOmVXlZXtB8jbRtk4YbArAHpGiazo+uWrXei6rY6nbo5ja W0uEmRXABKkqSM4IOPcVerlPAfh670i61C/vrWK3uLtIYdo1i71JykZkIJmuMEDMrYRUGOSW bdheroAK1rQWUGiLdz2CXMjXLR/NI64AVSOh9zWTWm//ACK0X/X6/wD6AtAB9v0z/oBw/wDg RJ/jR9v0z/oBw/8AgRJ/jWZRQBp/b9M/6AcP/gRJ/jR9v0z/AKAcP/gRJ/jXkmr6nqfha61T RdNs76Z5tRTVrGO0tvO3WZPn3sYzy0jSR3C9wrXlsoZd42S/2tdrDqniXTF87UNdvo7DQVNu JTNbQI7AbTLFGVYrezo5lG5JEOT8sdAHq32/TP8AoBw/+BEn+NH2/TP+gHD/AOBEn+NfOGo+ L7v/AISaDxZf6ZsvNMg3T2m8JvktIPECMMguE3GInAZwu7G58bj1cGv+NLrxJ4f0rV4otLuB rETOdkcf2i3ezvmaN4IrqYgZgysjPgtg7D5R3AHsn2/TP+gHD/4ESf40fb9M/wCgHD/4ESf4 1mUUAaf2/TP+gHD/AOBEn+Ncr8TvEJ03RtNbSdPgs57rW9PtJJd7SERSXMayABiRkqSucHAJ xg4I164z4uf8gjQ/+xl0r/0rjoA7Oiz/AOYp/wBuf/t1RRZ/8xT/ALc//bqgArjLz/kuGl/9 i1e/+lNrXZ1xl5/yXDS/+xavf/Sm1oA8y/bc/wCRH0L/ALCR/wDRTUUftuf8iPoX/YSP/opq KAPpPxP/AMhmT/rlF/6LWjxD/rrP/ryg/wDQBR4n/wCQzJ/1yi/9FrR4h/11n/15Qf8AoAoA zKIv+Qdpn/YNtP8A0njooi/5B2mf9g20/wDSeOgAooooAKKKKACuU+JniRPCul2mqPYy3hR7 mRI0u2hGYrG5n+bAIcERFcMCAWDYyorq6zPEegaT4hs1s9YtPtMC+ZhfMZMeZDJC/KkHmOWR f+BZHIBABx+r+JtbuvE2haBJpv8AZtzLqttNcQC/Pz2bwXkiB5EX5ZVe0JaNSyNtVPMZHbBJ 8RdQXTtPvF8P2p/tqCC50ZTqLDzIpbi2hH2g+V+5Yfa4m2p5o4cZ4BbsLjQNJuNeh1ya03ah D5flzeYwxsWdF+XOOFuZx0/j9lxRt/BXhqBspYSsFeJ4Uku5nS28uVJUSFWciGMPHGfLjCqf LQEEKAADnbr4i6hbJe3M3h+1+x2v9pXAdNRYyPa2E5huH2mIASklCke4qwLbnTA3VvH/AMRr nSo9dsbC127LG9XT9TgSaRVuobWWYhi8Ag+UwyKQssjblwUHz7OwuPCPh64tpreXT90U8F7b yL50g3R3kgkuR97je4Bz1XouBxUVx4K8NXGp/b7iwlmO+WT7M93M1pvlR0lb7MX8nLrJJuOz kuxOSxNAGPbeKdUfxBfaDp+h2smtCdnnS41eUWoWO1smkKP5TFcNdRqEEahtrudrHBi0f4jP qqjULbQJU0QXVhbNdS3SiUm8itnh2xAHJVrpA4LKAuCpkOVXdl8F+H5FY+TfRzM4ka5h1K5j uWIijiOZlkEhBSGLcC2GMaswLDNWYvDGgw2stpBpsUNvLdW920URZEEtuIRCVAIChRbwgKML 8nIOTkA57X/EGoaX481H919qs7bStPjtoTdNEoury8lgXcoUgqSke5zlowh2K29gbOj+L9Qv fFkPhq40a1gvIvtX9oOl8zxw+VHauvlExAy7heRZ3CPaQ/3sDdu6hoGk3815Nd2nmS3kEMEz iRlbbC7vEVII2MjyMyuuGBwQcqMRaT4Z0bS7qK8tLaX7VEksf2ia5lmlcSmIvvd2LSE+TEAW JIWNVBAGKAOZbxJqem+IdYs7axl1aa88TJp1pC935aW4/smK4zlgdsYZGLBRn52YBm+VqP8A wsTUIdQ1m9l0/wAyxsrG1hNpG7Oyag2oXVmwTZEXkiZ4h82N4VFKxFmKjuf7A0n+0f7R+yf6 V9u+37/Mb/X/AGf7NvxnH+p+XHTvjPNVm8I+Hik6jT9v2jzDKUmkVmZ5zcbshs7lmZnRusZZ thXJyAcnN8StRh06a5m8KSwva6dqV/crcSz24ZLSOFh5IlgR3DmdFLMibSsmN+Buta18QrzS JGsLzw3KurSvAbW1jlknBjmW4dfNMEUjrIBaTbljSVQdmHKlmXd/4Qrw0bWa2ksJZhPa3NpP JNdzSSzRXAjEoeRnLuSIolDMSyqihSAMVZ1bwzo2qXUt5d20v2qVIo/tENzLDKgiMpTY6MGj I86UEqQSsjKSQcUAYfgvxNrGveLLqKfT5bGwTR7adre5R4pYbhrm7jYqrxq7RuIQwL7CFVDs BdgtDxr4p1ZIr+0g0m6gex1XTBH9nvFFxMjX0C7WRioVZlLhGDujBZFkMbKyV2GlaBpOlzRz WFp5EqQGAuJGLSqXLkyEn9428u299zZkkOcu+6s/hHw895Ldvp+ZZZ0uOZpNscizJPmNd22P dLGkjhABIygvuNAGPD4w1i51NvD9roVi2vwPMLmKTUnW0VI0tnJSYQl2JF5BwYl58zn5VL1d H+IdxqijVLfQ4l0A3Vha/aHvSLvfeRWzxHyBGUwDdxhv3vADEZwAei1DwloV9cz3UlvdQ3Vx OZ5Li0vp7aYsY44yPMidWClYYsoDtJjUkEgGqGleA9GstcvdTKyuk11DPbWSTSx2luIoIYo1 +zh/KYqYQ6sUyp24+4poAwrbx9eXek6FcaxoEVoNcSyvbBbLVpHIje6tIz5reVGVKm6iOwb1 cB1Ygfel0/4kXc2kaXf3vhv7G+t2MNzpcP24OXaSW3gxMQmI18y7hIZd5KbmKqw8s6fhb4ea Foug6dp1x9q1KeygtYxcXN3O+GgaORTEryMIVMkUbGNMKdigghRVrV/B2mz6Da6dpkFray2F iLDT5LhZZlt4d0LYAWVH3DyIirhw6sisDkHIBa8I6zqGqvq1tqmnWtjeaZfC0kS2u2uI3zBD MGDNHGekwGNvUHk1uVzPgXwkvhuG4kn1G6v766neeeVp5zGWZIo+FllkY4WCPBd3IJfaVVto 6agAooooAKKKKACrl7eWdr4Yt1uruCAveyFRJIF3YRM4z1xkfnVOsfW/CvhjXLpbvWvDmj6n cIgjWW7so5nVASQoLKTjJJx7mgC5/a2lf9BOy/7/AK/40f2tpX/QTsv+/wCv+NYv/CvPAH/Q j+Gf/BTB/wDE0f8ACvPAH/Qj+Gf/AAUwf/E0AUr3TIbnVW1FfiNqFvKPMWERrpp8iN2DNGjN bl9vypwWJOxckkZqXS9J0CDRpdF1XX7fX9LZI447LUIrLyIUj+6qxxRIuOF4IONq4x3sf8K8 8Af9CP4Z/wDBTB/8TR/wrzwB/wBCP4Z/8FMH/wATQBNp9p4L07yP7PtvD9n9nx5HkRwx+Vjz MbcdP9dN0/56v/eOTTrTwXptgbDTrbw/Z2ZnW4MEEcMcZlUqVk2jA3AohDdQVX0FQ/8ACvPA H/Qj+Gf/AAUwf/E0f8K88Af9CP4Z/wDBTB/8TQBbjTwnHGkUa6IiRpBGiqIgFSBt0KgdhGxL KP4TyMVf/tbSv+gnZf8Af9f8axf+FeeAP+hH8M/+CmD/AOJo/wCFeeAP+hH8M/8Agpg/+JoA 2v7W0r/oJ2X/AH/X/GuQ+Kd9ZXOl6HHbXlvM48R6USscgYgfa4+eDWr/AMK88Af9CP4Z/wDB TB/8TUtp4F8EWd1Dd2ng7w7b3EDrJFLFpkKvG6nIZSFyCCAQRQB0NFn/AMxT/tz/APbqiiz/ AOYp/wBuf/t1QAVxl5/yXDS/+xavf/Sm1rs64y8/5Lhpf/YtXv8A6U2tAHmX7bn/ACI+hf8A YSP/AKKaij9tz/kR9C/7CR/9FNRQB9J+J/8AkMyf9cov/Ra0eIf9dZ/9eUH/AKAKPE//ACGZ P+uUX/otaPEP+us/+vKD/wBAFAGZRF/yDtM/7Btp/wCk8dFEX/IO0z/sG2n/AKTx0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFn/zFP+3P/wBuqKLP/mKf9uf/ALdUAFcZef8A JcNL/wCxavf/AEpta7OuMvP+S4aX/wBi1e/+lNrQB5l+25/yI+hf9hI/+imoo/bc/wCRH0L/ ALCR/wDRTUUAfSfif/kMyf8AXKL/ANFrR4h/11n/ANeUH/oAo8T/APIZk/65Rf8AotaPEP8A rrP/AK8oP/QBQBmURf8AIO0z/sG2n/pPHRRF/wAg7TP+wbaf+k8dABRRRQAUUUUAFcz498Uf 8Is+gzSw77O+1UWd24XJgiMEzmXOQFVDGrOxyFQOccV01Y/iTQbfXZ9KN2Ynt7G6knlt5YRI lwj208BjYHjBE5JyDnGMc5ABhxeNkuPFmvaUkkVrZaW+mwJdyW7SLcTXFzJFIiFG5G5Vh3cb JBJuBCkVefx54XS2luGvbryk2GNhp9wftKvIkatb/J/pCl5Ixui3j94hzhlJop8P7eAbLbUp QmzSlLSxB5ZHsryS6eWRgRukmaQ7mwPmJY7s4otPBepxaHY6DN4hifS9LexFhFHYbX8u1uIZ V85y58yQrCE3II1G9yUb5QoBsN4u8PJfz2kuoeR5HmB7iaGSO1LRgmRVuGURMyBXLKrEr5cm QNjYibxp4fFrHOJr6R3do/ssem3L3aFQpbfbrGZUADxnLKBiSM5+dc0IvBt2l/GBrnlafa31 3qNksNoBdQ3NyJw7NK7NG6qbmYqvlDGI8ltrb47HwfrGnR6fc6frtjFqNklxbxCTTXeyit5m iYxRQiYOgUwR7cysFBdQAuxYwCKH4gQS+KTp8MH2qxl1W2023ntopJFbzbFrsTiRQUdT8ibV +4AZGbawAi8X+L7jTPGk+it4s8KeHLeLTre6jbWIS73DySTqwU/aIhhREnY/f7cVa0H4f2+i RWcVjqUrCw1G3vLXzog2EjsI7FkfBG4tErsGG3DMpwQpVuhttJ8nxVf659o3fa7G2tPJ2Y2e S877t2ec+fjGONvU54AMfSvHWlXGkLc6hBfWN/Glst3YfYriWWK4mgWb7OgWPMsiodzKgJVQ SwUVWfxxa3HiMWNpdxQWS2tnMZ5bGaTfJcXptvJbG3yZA0bIVf5t0mSAIZA1m+8JXD6hd6pY 6pFBfvrC6ratNamWKJ/sS2bI6B1LgoHYEMmGZeoUhqNp8PvJNxI2r7pbqexuZyLbC+bBqM1/ JtG7hXedkVSSUAGS5oAs+EfHWm6nomgyahN5eoahY2ktwYbWU2sM88SOImmwY42Yuu1HcMd8 eM71za8W+KP7F1Wxto4fNgTFxqsgXcLS1LeUsjHICfvHD7m+XyoLk9UxXO+H/hVZ6Re6ZOJd HuzapZmW5uNFjkvTJbQxRL5MzMRDGRAhK7WYFpCrqSpXd1fwLpWuanql7rk99dC+RLYRW97c WiLaqmPIcQyKJRved8uCf3pXoBQBp3fifQbPU5tOu9Sit5YEZ5XlDLDHtTzCjSkeWJBGDIYy 27Z8+NvNUf8AhNNCM0Un9p+TF5E7SWk1hOl1vR4FC7GAdW/fxgRFN8nnRlOPvRWnhjWU1OG/ uvFUrzjTltZ7iCxiimmkCbdx6x+WH3SqjRsyO7gP5bNGaMHgO7W2gWTWrVmhsbyzSAaaDaLH PJbv5Swu7EQAW5QxlydsrBGiVUVQDT0/xnpt9rd7YW8N1LBbaVHqPnxW0rsQZZ43iaMJlZUa HHln5ySyhco1EnjzwvH9nR726FzceaIrP+z7j7UzR+WXXyNnmhgssb7SuSjbwNgLCjL4GuJb KaKbXpbia506CzunnhMiy+RM8sSkF9zQnzZY5EdnaSMqDJu3O8XgbwB/wjWvPq32vTF3/av9 E03TPsdunnLZr8ieY+3H2PJ5+YyE8Y5AN3wz4ltNf1HWbWzXfFp08KR3MZLw3MctvFMro+Nh /wBYRhSxACscB1qhN480Zr3SbfT2lvRqGorZFkhlBVXhmkjnRdmZIWMJAlX92RubfhGqX4fe E/8AhEdNNhHf/a4mgtVctDsYyw20duzj5jhWSGIheSp3/MwYBaun+Dbu2uYLmbXPPltdVGoW 6i0CRZMckUpdA3+tkSaRmZPLTzNriMEyCQAtP488LpbS3DXt15SbDGw0+4P2lXkSNWt/k/0h S8kY3Rbx+8Q5wyk2m8XeHkv57SXUPI8jzA9xNDJHalowTIq3DKImZArllViV8uTIGxsc7B8P LjyNJtbnXIpLfQ0trfSxHZFHW3iubWcrMxkIkkYWcS71EYGXO05AWXTvh3bWHiS61a1m0y2a We6uYruHR4f7SWW4MhbdcvuDKplfaojU4WNWLKGDgHQxeJtGfQL7XTcyxWWnpJJeedbSxS24 RN7b4mUSKdmGAK5KspAIYEx6h4t0KxuZ7WS4uprq3nMElvaWM9zMGEcchPlxIzFQs0WXA2gy KCQSBVCLQn0zwFfaJf2sviCGdJIWsNPRbZBDJ8hhgEkv7uMKSQDKdvITaoRFo6T4N1uyh0/W E1y1/wCEq8h11S8urQ3EFzJKluJCscbQ7cfZYVQjA2qdyszFgAdDF4n0Ga1lu4NSimt4rq3t GliDOhluBCYQpAIYMLiEhhlfn5IwcWvD+rWOvaNa6xpkkslldp5kEkkDxF0PRtrgNg9QSOQQ RkEGuPt/hy9ja22l6Xr8sGkQ3WnXkkMtqsk00lmLdFVpMgCNo7WPIVAwf5t23MZ6vwnpP9g+ FdI0P7R9o/s6xhtPO2bPM8tAm7bk4zjOMnHrQBp0UUUAFbNpMtp4fS4W2tZZGu3QmaFX42Ke 4+v51jVpv/yK0X/X6/8A6AtAB/bMn/Phpn/gIn+FRQ+IY55J4obfR5Ht3EcypbRkxuVVgrAd DtZWwezA9xVGvKXs9fk8ceMYdIurpLXWtVh026dJHBsNthaObiIrxExhNwu85zKLUYxuoA9k tPEMd5aw3dpb6PcW86LJFLFbRskiMMhlI4IIIIIrM1v4heHNDultNa1Twpplw6CRYrtoIXZC SAwDEHGQRn2NeU+DtW1618O+DdHsZJcX+gaHJYxpArgpFKv9oszYIQCB4RlyMlgEy5xXRXcG vzfFTWP7D1PTLHGiad532zT3ud/7++27ds0e3HOc5zkdMcgHpn9syf8APhpn/gIn+FVrzxTa Wc0UN2NDt5Zv9UksMSs/zonyg9fnkjXju6jqRXj8F1e+G4LnQ18S3WnaDpmq2mii+mW3H9nW selxyrIZHj2BpJmRC0gZfnCqFJBqjpmtay2vXmtLqcpcpo1isgii2Xts+t3UCXB+XBMkA3Bk 2ofOLKPubQD3K08Qx3lrDd2lvo9xbzoskUsVtGySIwyGUjgggggipf7Zk/58NM/8BE/wr55+ HniPxMkfhXTItU0y0tYrHSoLfTp7kCa9t3tbdpZltxbvLJgvMBIsqRqYsuMRyFvZY9Z0eSNJ Y9VsXSRIJEZbhCGSdtsLA55EjAqp/iPAzQB0P9syf8+Gmf8AgIn+Fcf8Wdfv4tD0mO0FtZmf X9Mhle2gWN2ja7jDJuAyAw4IHUEg8Eg7tcZ8XP8AkEaH/wBjLpX/AKVx0AdnRZ/8xT/tz/8A bqiiz/5in/bn/wC3VABXGXn/ACXDS/8AsWr3/wBKbWuzrjLz/kuGl/8AYtXv/pTa0AeZftuf 8iPoX/YSP/opqKP23P8AkR9C/wCwkf8A0U1FAH0n4n/5DMn/AFyi/wDRa0eIf9dZ/wDXlB/6 AKPE/wDyGZP+uUX/AKLWjxD/AK6z/wCvKD/0AUAZlEX/ACDtM/7Btp/6Tx0URf8AIO0z/sG2 n/pPHQAUUUUAFFFFABXPeNNR1izn0Kx0Wext7jVNRa1aa7tnnSNFtp5iQiyISSYQPvdz1roa x/E/hrR/Eq6fFrVpFe29jdfalt5o0kilfypIwHVgQQBKWHT5gp7YIBwN58QvFjSXEem6Ja3P 9kQSy6nL+6SGXy7q6tyd8txH9mVvsjvuxPtD8g7Myacvi/X0043pm0KNBquoo3mxuvlWtrcN AC4DkhSwXzLkBli8xCYiu517Cfw9oE/9nefoemS/2Xj+z99oh+yY248rI/d42rjbj7o9BUs2 jaPPHBFNpVjIlvdG8hV7dCI7gszGZQRxJuZm3DnLE55NAHA+JfHev6Vol9r8UemSWbT6rZWl o0D+ZFLZxXbCWSXzMSK5s2+QIhAkHzHZlr2peKvEdhdXuhTxWMmuyJazaclpbGVGMxuGaAiS aIOUjtJm80vEGyMICArdXL4e0CW/vL+XQ9Me8voDb3c7WiGS4iIAMcjYy6kKo2nIwB6VLqWj aPqcdxFqWlWN6lykcdwtxbpIJURiyKwYHcFZmYA9CSR1oA4r4Zazd694t1jUL+0+yXi6VaW0 8XAxJBfalCxwGYLkxk7QzgZxubG45ngnxpr9z4estR/s/QrTSLafSLH7LawujN9st7LhPm2x LE11kcPvUBMIV3t6RpGjaPo8Yi0nSrHT0CCMLa26RDYGdguFA4DSSNj1dj3NFvo2j29r9kt9 KsYbffFJ5SW6Km+IIImwBjKCOMKe2xcY2igDy3wp4l1/SvhxaXEEmmSf2R4Wt/EGoGS1cvqH nieQoGEg8uU+QxeZhJveQvsGCpv6l458T2sFzfKdHa3tE129khNpJvkt9OuY4VhD+bhZHBcm TaQMj5Dg576fw9oE/wDZ3n6Hpkv9l4/s/faIfsmNuPKyP3eNq424+6PQVLJo2jyRvFJpVi6S JPG6tboQyTtumUjHIkYBmH8R5OaAOKvPFfiZXutAsY7W98R2d80TG208NHcQLBbyvII5bqIR 7TdwpgzOSckLgnZzNt4+1BNOuvGFxZWt5ZyXyXdrYzlnks8eHvtbrFMThdx+XIQYDykg78L6 tqvh7QNVhkh1TQ9MvopZxcSJc2iSK8oQIJCGBywQBd3XAA6VLBo2jwSW0sGlWMT2qJHbslui mFEV1RUIHyhVkkUAdA7AfeOQDitQ8S+L7DxNZ+FPM0K81C5ng/0z7LLBCkU0F83+q8xyWRrL d98Bw+z93/rK6vwdqlxq+h/artIluIrq6s5TECEd4LiSAuqkkqGMZYKS23djLYyZdK8PaBpU McOl6HpljFFObiNLa0SNUlKFDIAoGGKEru64JHSrVnp2n2c0s1pY2tvLN/rXiiVWf53f5iBz 88kjc93Y9SaALNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFUfE/jjwf4b0e203XvEmmadey3D zpbz3CrIY9qqH29QpIIB7kHHQ1eooA4z/havw4/6HTRf/AkUf8LV+HH/AEOmi/8AgSK7OigD z6Hx/wDCmLWZ9YHjDSnvZkEZkl1BpBGny5WNWYrEG2qWCBdxVS2SAavf8LV+HH/Q6aL/AOBI rs6KAPPtN+IHwu0+6vLmDxzaO94/mSi41eWdFOSfkSR2WMfMeECjoMcDF7/havw4/wCh00X/ AMCRXZ0UAcZ/wtX4cf8AQ6aL/wCBIo/4Wr8OP+h00X/wJFdnRQBxn/C1fhx/0Omi/wDgSK5z x7478G6/DoOnaL4l0y+vG8RaY6wwzguQLuPOB3xXq1FABRZ/8xT/ALc//bqiiz/5in/bn/7d UAFcZef8lw0v/sWr3/0pta7OuMvP+S4aX/2LV7/6U2tAHmX7bn/Ij6F/2Ej/AOimoo/bc/5E fQv+wkf/AEU1FAH0n4n/AOQzJ/1yi/8ARa0eIf8AXWf/AF5Qf+gCjxP/AMhmT/rlF/6LWjxD /rrP/ryg/wDQBQBmURf8g7TP+wbaf+k8dFAt7MRxRi61nbFEkSD7Rb8KihVH+o7AAUAFFH2e z/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDA i3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ 7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ /wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQA UUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61 n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/ AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2e z/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDA i3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ/wDAi3/+MUfZ 7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQAUUfZ7P8A5+tZ /wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61n/wIt/8A4xQA UUfZ7P8A5+tZ/wDAi3/+MUfZ7P8A5+tZ/wDAi3/+MUAFFH2ez/5+tZ/8CLf/AOMUfZ7P/n61 n/wIt/8A4xQAUWf/ADFP+3P/ANuqPs9n/wA/Ws/+BFv/APGKfEtrBBcJCb2SSdoi73E0bYEY kwAEjT/noeuaAGVxl5/yXDS/+xavf/Sm1rs64y8/5Lhpf/YtXv8A6U2tAHmX7bn/ACI+hf8A YSP/AKKaij9tz/kR9C/7CR/9FNRQB9J+J/8AkMyf9cov/Ra0eIf9dZ/9eUH/AKAKPE//ACGZ P+uUX/ota4rxDqfxIutTY6donhMWUSLDbmfVbgSMiDAZgLfAJxnAJxnGTjJAOiorjPtPxU/6 A3gz/wAG1z/8j0fafip/0BvBn/g2uf8A5HoA7OiuM+0/FT/oDeDP/Btc/wDyPR9p+Kn/AEBv Bn/g2uf/AJHoA7OiuM+0/FT/AKA3gz/wbXP/AMj0fafip/0BvBn/AINrn/5HoA7OiuM+0/FT /oDeDP8AwbXP/wAj0fafip/0BvBn/g2uf/kegDs6K4z7T8VP+gN4M/8ABtc//I9H2n4qf9Ab wZ/4Nrn/AOR6AOzorjPtPxU/6A3gz/wbXP8A8j0fafip/wBAbwZ/4Nrn/wCR6AOzorjPtPxU /wCgN4M/8G1z/wDI9H2n4qf9AbwZ/wCDa5/+R6AOzorjPtPxU/6A3gz/AMG1z/8AI9H2n4qf 9AbwZ/4Nrn/5HoA7OiuM+0/FT/oDeDP/AAbXP/yPR9p+Kn/QG8Gf+Da5/wDkegDs6K4z7T8V P+gN4M/8G1z/API9H2n4qf8AQG8Gf+Da5/8AkegDs6K4z7T8VP8AoDeDP/Btc/8AyPR9p+Kn /QG8Gf8Ag2uf/kegDs6K4z7T8VP+gN4M/wDBtc//ACPR9p+Kn/QG8Gf+Da5/+R6AOzorjPtP xU/6A3gz/wAG1z/8j0fafip/0BvBn/g2uf8A5HoA7OiuM+0/FT/oDeDP/Btc/wDyPR9p+Kn/ AEBvBn/g2uf/AJHoA7OiuM+0/FT/AKA3gz/wbXP/AMj0fafip/0BvBn/AINrn/5HoA7OiuM+ 0/FT/oDeDP8AwbXP/wAj0fafip/0BvBn/g2uf/kegDs6K4z7T8VP+gN4M/8ABtc//I9H2n4q f9AbwZ/4Nrn/AOR6AOzorjPtPxU/6A3gz/wbXP8A8j0fafip/wBAbwZ/4Nrn/wCR6AOzorjP tPxU/wCgN4M/8G1z/wDI9H2n4qf9AbwZ/wCDa5/+R6AOzorjPtPxU/6A3gz/AMG1z/8AI9H2 n4qf9AbwZ/4Nrn/5HoA7OiuM+0/FT/oDeDP/AAbXP/yPR9p+Kn/QG8Gf+Da5/wDkegDs6K4z 7T8VP+gN4M/8G1z/API9H2n4qf8AQG8Gf+Da5/8AkegDs6K4z7T8VP8AoDeDP/Btc/8AyPR9 p+Kn/QG8Gf8Ag2uf/kegDs64y8/5Lhpf/YtXv/pTa0fafip/0BvBn/g2uf8A5Hpmg6T4vuPH 8HiPxHbaFaxW+lT2SJYXkszM0ksLgkPEmABE3c9RxQB5r+25/wAiPoX/AGEj/wCimoo/bc/5 EfQv+wkf/RTUUAfSfif/AJDMn/XKL/0WtZlafif/AJDMn/XKL/0WtZlABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAG3qNvodlfTWjx6izRNtJEqYP/jtV92gf88dT/wC/ qf8AxNHin/kYb3/rqazKANPdoH/PHU/+/qf/ABNG7QP+eOp/9/U/+JrMrD+Id/d6V4A8RapY S+TeWelXNxBJtDbJEiZlOCCDggcEYoA6/doH/PHU/wDv6n/xNG7QP+eOp/8Af1P/AImvG/H0 U3ha11e20XU9YjS48JaveMbjVLi5dJoBbiJ0eV2aMr50n3CM5BOdq47DwPcXGoWtxqeoTyrq cjiK8sC52ac6jItwvQkB8mX/AJa7g4PlmJVAO03aB/zx1P8A7+p/8TRu0D/njqf/AH9T/wCJ rMooA092gf8APHU/+/qf/E1yXhzXDrOreJYVtxBbaXqxsbcFtzsgt4JCzngElpG6AYGByQSd quM+Gn/IX8c/9jK//pJa0AemXFvo9otutwl+8kkEcpKSoB8yg91qHdoH/PHU/wDv6n/xNHiH /XWf/XlB/wCgCsygDT3aB/zx1P8A7+p/8TRu0D/njqf/AH9T/wCJrkPiHf3eleAPEWqWEvk3 lnpVzcQSbQ2yRImZTggg4IHBGKqy6fZeEbC81a11DU3VYCottQ1S4uo5pSQIgDJ5sisWOwCI EsZMbHYIAAdzu0D/AJ46n/39T/4mjdoH/PHU/wDv6n/xNeU6P8Q9U1i/h0jTvC27VD9qWdLm 5ltoYGhFq+SZYFm2sl2nPlZ3gDaUPmDT8N+MrvxK8V7omh+dpH+jLcSzXYjuo2mginBWLaUZ VSeMsfNB4k2qxC7wD0PdoH/PHU/+/qf/ABNG7QP+eOp/9/U/+JrxY/EK+8RaXayWujanplrc 32lz2t4I7lFeB9QtlMcjPDGgZ0l+7E8qsBJ82AC3q1AGnu0D/njqf/f1P/ia5SDXFvPiBrmg 2tsYrLTbGymR5H3SO8zT78kAAKBGgAxn7xycgDYrjPDv/JX/ABh/2DdL/nd0Aekrb6VBp1nP dpevJcKzfupFAGHK9CvsKZu0D/njqf8A39T/AOJo1P8A5A2k/wDXKT/0Y1ZlAGnu0D/njqf/ AH9T/wCJo3aB/wA8dT/7+p/8TWZWff31tbXLPc3kMCWsQmaN2+efcxXai7huIQSNzxuEYJ5o A6PdoH/PHU/+/qf/ABNG7QP+eOp/9/U/+JrLeO9S4ljeK3UR362ATzj5ryny+g27cAyryXHQ 9ehitBcXE+kpcJCFvGtLlkgnclIXmgBDkquCRMowpbqemOQDZ3aB/wA8dT/7+p/8TRu0D/nj qf8A39T/AOJrJtDLND5rIiL9mtZzhyT+/R3UdB0Ccn3p9AGnu0D/AJ46n/39T/4muX1bXYV+ Imn+G9PtpFtZtJub6aWdwzl0mgRFXAAAxI5Oc5+XGMHOrXGXn/JcNL/7Fq9/9KbWgDzL9tz/ AJEfQv8AsJH/ANFNRR+25/yI+hf9hI/+imooA+k/E/8AyGZP+uUX/otazK0/E/8AyGZP+uUX /otazKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANPxT/AMjDe/8AXU1m Vx8/w28K3E8k8412WWRi7u/iG/ZmYnJJJm5JPemf8Kw8If8APHWv/B/ff/HqAOzqO7t7e8tZ rS7giuLedGjlilQMkiMMFWB4IIJBBrkP+FYeEP8AnjrX/g/vv/j1H/CsPCH/ADx1r/wf33/x 6gDSi8F+H1tb62mhvrxL61ks5je6lc3TiGQYkRHlkZow2BnYVztUn7q42PsFp/av9qCLbeGD 7O0isRvj3bgGAOG2ndtJBK73xje2eV/4Vh4Q/wCeOtf+D++/+PUf8Kw8If8APHWv/B/ff/Hq AOzorjP+FYeEP+eOtf8Ag/vv/j1H/CsPCH/PHWv/AAf33/x6gDs64z4af8hfxz/2Mr/+klrR /wAKw8If88da/wDB/ff/AB6t3wv4c0jw1aXFro8E0UdxObiYzXUs7vJsVMlpGZvuooxnHFAH U+If9dZ/9eUH/oArMrltV8AeG9U1GfUL7+2pbidtzsNdvVHsAolAVQMAKAAAAAABVX/hWHhD /njrX/g/vv8A49QB193b295azWl3BFcW86NHLFKgZJEYYKsDwQQSCDWFD4L8PxxzpJDfXZmQ R+Ze6lc3MsQDK/7p5ZGaI7kRsoVO6NGzlFIzf+FYeEP+eOtf+D++/wDj1H/CsPCH/PHWv/B/ ff8Ax6gDX0LwloWi35v7G3ujeN5u6e5vp7iRvMEIfLSuxORbwjnoEGMZOYrLwV4aspLJrWwl iSzSFIoBdzeQ3kqqxPJFv2SSIETEjqzDy05+RcZv/CsPCH/PHWv/AAf33/x6j/hWHhD/AJ46 1/4P77/49QBpW/grw1A2UsJWCvE8KSXczpbeXKkqJCrORDGHjjPlxhVPloCCFAHQ1xn/AArD wh/zx1r/AMH99/8AHqP+FYeEP+eOtf8Ag/vv/j1AHZ1xnh3/AJK/4w/7Bul/zu6P+FYeEP8A njrX/g/vv/j1a/hfwloXhqe7n0i3uklu1jSeS4vp7lmWMuUGZXbABd+BjrQB1+p/8gbSf+uU n/oxqzK5zxB4K0HXtRN/qf8Aa0kxUIBHrN3EiKOyokoVR1OABkkk8kms/wD4Vh4Q/wCeOtf+ D++/+PUAdnUtjJc2qzC11U6f5s3mP5Nmzs/yKo3N5y5xt4GOMn1NcP8A8Kw8If8APHWv/B/f f/HqP+FYeEP+eOtf+D++/wDj1AHbWcNhYeW9vF50sUqPCzeZHHGUhiRWEQkZC26MsSwbnb6U lotvYW1sllCrTwQ26me4eWQs0WxgNpkIVPMjU7V28Ko6VxX/AArDwh/zx1r/AMH99/8AHqP+ FYeEP+eOtf8Ag/vv/j1AHbKsFtZJZWnMYZpZpPKWNp5WZmLsAT03bRktgDryaZXGf8Kw8If8 8da/8H99/wDHqP8AhWHhD/njrX/g/vv/AI9QB2dcZef8lw0v/sWr3/0ptaP+FYeEP+eOtf8A g/vv/j1aHh3wR4c0DVTqmm296LzyGtxJcajcXO2NmVmAEsjAZKJyBngUAeRftuf8iPoX/YSP /opqKP23P+RH0L/sJH/0U1FAHnV/+098S727kuZU0NWcj5Vs2woAwAMvnAAA5yfXNQf8NKfE f00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wAB D/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8 NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/w EP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFU f8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH 9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8A FUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfE f00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wAB D/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8 NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/w EP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH9NF/8BD/APFU f8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8AFUUUAH/DSnxH 9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfEf00X/wABD/8A FUUUAH/DSnxH9NF/8BD/APFUf8NKfEf00X/wEP8A8VRRQAf8NKfEf00X/wABD/8AFUf8NKfE f00X/wABD/8AFUUUAcr8Sfiv4p8f6Vbabr6af5VtP58Zt4SjBtpXH3jxg/pRRRQB/9k= --------------48BFC390E180756CEFC37DD6-- From owner-xemacs-beta@xemacs.org Wed Jul 21 05:54:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA07450 for xemacs-beta-out; Wed, 21 Jul 1999 05:54:06 -0400 Received: from matrix.rhein-zeitung.de (matrix.rhein-zeitung.DE [195.189.135.200]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA07446 for ; Wed, 21 Jul 1999 05:54:03 -0400 Received: (from ograf@localhost) by matrix.rhein-zeitung.de (8.9.3/8.9.3) id JAA01238; Wed, 21 Jul 1999 09:54:02 +0200 To: xemacs-beta@xemacs.org Subject: Re: whoops... sparc64-unknown-linux failes References: X-Face: [8r}|"6`WFUT0kiC9dBT%edO~lI5Gwog0Z@Cl=Inx|2F=+DjY#0nGtclM)9lU c/8JJ%b&&^:&pWh&nYlQbGSk=WdL^%f!<6a:?n)V_snw7Zc+AW10az=||e8Kv 1PV49Qe64*68G2`)M8O$mlLQ\!O}$d8]T\L?i@$;=WA~0B[k)O.^T'x?O^=EX %=gt6(:hG!-|%$EZGq-Dn6r%N6xqOC4voztttHxOMp!2$o+qPAcT2k&dgO~`% kVcW7C<3hK[g9vVpk'#B2(f"pN,jBh` Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Oliver Graf Date: 21 Jul 1999 09:54:01 +0200 In-Reply-To: SL Baur's message of "21 Jul 1999 17:57:28 +0900" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > > do I have to reinstall slowlaris? ;-) > > The likeliest cause is that a regexp is failing in configure. Maybe > this one: > > dnl Straightforward machine determination > case "$canonical" in > sparc-*-* ) machine=sparc ;; > > try changing it sparc*-*-* and see if that helps. I started configure with sparc-unknown-linux and it compiled. The configure change works also. Regards, Oliver. From owner-xemacs-beta@xemacs.org Wed Jul 21 06:26:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08165 for xemacs-beta-out; Wed, 21 Jul 1999 06:26:11 -0400 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 GAA08162 for ; Wed, 21 Jul 1999 06:26:09 -0400 Received: (from figueire@localhost) by lsppc4.epfl.ch (8.9.3/8.9.3) id MAA10170; Wed, 21 Jul 1999 12:26:07 +0200 To: xemacs-beta@xemacs.org Subject: EUDC 1.29 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_Wed_Jul_21_12:25:27_1999-1"; micalg=pgp-md5 Content-Transfer-Encoding: 7bit From: Oscar Figueiredo Date: 21 Jul 1999 12:26:07 +0200 Message-ID: Lines: 46 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --pgp-sign-Multipart_Wed_Jul_21_12:25:27_1999-1 Content-Type: text/plain; charset=US-ASCII I just committed EUDC 1.29 to the CVS package tree. This release which is on the main trunk is also tagged as `r1-29' and as `current'. The NEWS file says: * Release 1.29 ------------ ** Support for non-textual values Right mouse button pops-up a contextual menu of functions to handle those values. Note: internal support for LDAP binary values in XEmacs 21.1 is corrupted *** Images can be displayed inline or as buttons (jpegPhoto LDAP attribute) *** Sound can be played (audio LDAP attribute) *** URLs are clickable (needs browse-url) ** Code has been splitted across several files to make loading faster ** Selecting an LDAP server with an empty search base asks for configuration ** You can import a batch of directory entries into BBDB in a single operation See `eudc-batch-export-records-to-bbdb' ** Miscellaneous bug fixes Oscar --pgp-sign-Multipart_Wed_Jul_21_12:25:27_1999-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBN5WgOJ7CaiYEgqPZAQFnfgIA33tDlGwuL3duN6dviLyVs3Fp5qWNANUo jaVxCiEvm9yfLPAKjcsatVQsO5m6wT2GkRmfO2DN03sPOCkMoJR9xQ== =dNkv -----END PGP MESSAGE----- --pgp-sign-Multipart_Wed_Jul_21_12:25:27_1999-1-- From owner-xemacs-beta@xemacs.org Wed Jul 21 06:39:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08607 for xemacs-beta-out; Wed, 21 Jul 1999 06:39:13 -0400 Received: from hands.niss.ac.uk (hands.niss.ac.uk [138.38.32.116]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA08602; Wed, 21 Jul 1999 06:39:08 -0400 Received: from feet.niss.ac.uk ([193.63.76.162] helo=gristle.niss.ac.uk) by hands.niss.ac.uk with esmtp (Exim 2.12 #1) id 116toK-0002jc-00; Wed, 21 Jul 1999 11:41:16 +0100 Received: from ccsnjd by gristle.niss.ac.uk with local (Exim 2.12 #1) id 116tmn-0000Zh-00; Wed, 21 Jul 1999 11:39:41 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14229.41837.672349.429465@gristle.niss.ac.uk> Date: Wed, 21 Jul 1999 11:39:41 +0100 (BST) To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again In-Reply-To: References: <14227.36750.708234.719126@crystal.WonderWorks.COM> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Organisation: NISS X-URL: http://www.bath.ac.uk/~ccsnjd X-Cabaret-Voltaire-URL: http://www.brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote on 21-July-1999: ->Kyle Jones writes in xemacs-beta@xemacs.org: -> ... ->> Cool. The next thing to figure out now is why Steve can duplicate ->> the problem even when allow-deletion-of-last-visible-frame is t. -> ->I can't. What I cannot duplicate is Hrvoje's results with WindowMaker. ->Regardless of the value of `allow-deletion-of-last-visible-frame', I ->can C-x 5 0 a frame when another frame is open in another workspace, ->i.e. WindowMaker always does the Right Thing. -> ->I just retested with CDE and if I manually set the value to t, then ->everything works as expected. OK, here's another viewpoint/statistic: allow-deletion-of-last-visible-frame t C-x 5 0 works when another frame is open in another workspace allow-deletion-of-last-visible-frame nil C-x 5 0 _fails_ when another frame is open in another workspace (Attempt to delete last or iconified frame) The "X" (kill/close thing) button in the window title bar works I think I'm agreeing with what Hrjove sees. ------------------------------------------------------------------------ Some sysinfo gristle $ cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) gristle $ uname -a Linux gristle.niss.ac.uk 2.2.10 #2 Thu Jun 17 11:36:26 BST 1999 i686 unknown gristle $ rpm -q WindowMaker WindowMaker-0.60.0-4 gristle $ rpm -q gnome-core gnome-core-1.0.4-13rh gristle $ xemacs --version XEmacs 21.2 (beta18) "Toshima" [Lucid] (i686-pc-linux) of Wed Jul 14 1999 on gristle.niss.ac.uk Build report: http://www.xemacs.org/list-archives/xemacs-build-reports/9907/msg00021.html Any other info you need? nic From owner-xemacs-beta@xemacs.org Wed Jul 21 06:41:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08651 for xemacs-beta-out; Wed, 21 Jul 1999 06:41:07 -0400 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 GAA08648 for ; Wed, 21 Jul 1999 06:41:05 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA26170 for ; Wed, 21 Jul 1999 12:41:04 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006Oh; Wed Jul 21 12:41:00 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA18301; Wed, 21 Jul 1999 12:41:00 +0200 To: xemacs-beta@xemacs.org Subject: Re: package standards version 1.1 References: From: Jan Vroonhof Date: 21 Jul 1999 12:40:59 +0200 In-Reply-To: SL Baur's message of "21 Jul 1999 16:39:09 +0900" 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: SL Baur writes: > If there's anything else that someone needs changed regarding info in > the package-info.in files, now would be a good time to request it ... Well, weak and strong runtime dependencies would be nice. A mechanism to automatically determine the provides line (such that all modes are included etc) would nice. A conflicts entry would be cool too. Jan From owner-xemacs-beta@xemacs.org Wed Jul 21 06:48:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08858 for xemacs-beta-out; Wed, 21 Jul 1999 06:48:08 -0400 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 GAA08854 for ; Wed, 21 Jul 1999 06:48:06 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA26589; Wed, 21 Jul 1999 12:48:04 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006VQ; Wed Jul 21 12:48:02 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA18320; Wed, 21 Jul 1999 12:48:01 +0200 To: xemacs-beta@xemacs.org, Ben Wing Subject: Re: Tabs 'n widgets screenshot References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> From: Jan Vroonhof Date: 21 Jul 1999 12:48:01 +0200 In-Reply-To: Ben Wing's message of "Wed, 21 Jul 1999 02:44:03 -0700" 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: Ben Wing writes: > This is real cool, but looking at this, it's clear that it doesn't look the > way tab widgets are supposed to work. In particular, of course, they should > have the proper borders around the stuff displayed. I've attached a screen > shot of a typical Windows dialog box with a tab widget in it. The problem > lies with this "expanded gutter" concept. Tabs are *NOT* extra > graphical I think in this case the extra border would just be wasted space. The buffer tabs are more like the tabs used to select between various sheets in modern spreadsheets. They also do not use extra borders. Anyone remember the text base DOS IDE's that did MDI in text mode, wasting a character on every side of the text window, so that you actaully had a 50x10 window to edit in? Jan From owner-xemacs-beta@xemacs.org Wed Jul 21 06:53:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA08913 for xemacs-beta-out; Wed, 21 Jul 1999 06:53:18 -0400 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 GAA08910 for ; Wed, 21 Jul 1999 06:53:16 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id MAA26845 for ; Wed, 21 Jul 1999 12:53:15 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006ZC; Wed Jul 21 12:53:05 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id MAA18326; Wed, 21 Jul 1999 12:53:04 +0200 To: xemacs-beta@xemacs.org Subject: Re: tar-mode and crypt revisted [ patch included ] References: <199907210037.RAA00606@mina.sr.hp.com> From: Jan Vroonhof Date: 21 Jul 1999 12:53:04 +0200 In-Reply-To: Darryl Okahata's message of "Tue, 20 Jul 1999 17:37:12 -0700" 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: Darryl Okahata writes: > > * When tar-mode.el is loaded, it overrides the definition of > "normal-mode" with it's own definition: tar-normal-mode. Ouch. The best fix would probably to get rid of this. Overriding basic XEmacs functions is always bad. If there is some functionality missing built it into to XEmacs proper. Jan From owner-xemacs-beta@xemacs.org Wed Jul 21 07:30:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA09973 for xemacs-beta-out; Wed, 21 Jul 1999 07:30:44 -0400 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 HAA09968 for ; Wed, 21 Jul 1999 07:30:40 -0400 Received: from brabantio.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 NAA12956 for ; Wed, 21 Jul 1999 13:30:34 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id NAA28604; Wed, 21 Jul 1999 13:30:26 +0200 To: xemacs-beta@xemacs.org Subject: Re: package standards version 1.1 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: 21 Jul 1999 13:30:26 +0200 In-Reply-To: Jan Vroonhof's message of "21 Jul 1999 12:40:59 +0200" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id HAA09970 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> SL Baur writes: >> If there's anything else that someone needs changed regarding info in >> the package-info.in files, now would be a good time to request it ... Jan> Well, weak and strong runtime dependencies would be nice. A mechanism Jan> to automatically determine the provides line (such that all modes are Jan> included etc) would nice. A conflicts entry would be cool too. Let's save this for the big overhaul---we don't have any code to *use* this information yet. All of these things are sensible, noted and on the list. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Wed Jul 21 07:39:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA10138 for xemacs-beta-out; Wed, 21 Jul 1999 07:39:21 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA10134 for ; Wed, 21 Jul 1999 07:39:19 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-43.kiva.net [206.97.75.108]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id EAA25425; Wed, 21 Jul 1999 04:38:01 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id GAA26460; Wed, 21 Jul 1999 06:38:48 -0500 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org, Ben Wing Subject: Re: Tabs 'n widgets screenshot References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 41 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > > > This is real cool, but looking at this, it's clear that it doesn't look the > > way tab widgets are supposed to work. In particular, of course, they should > > have the proper borders around the stuff displayed. I've attached a screen > > shot of a typical Windows dialog box with a tab widget in it. The problem > > lies with this "expanded gutter" concept. Tabs are *NOT* extra > > graphical > > I think in this case the extra border would just be wasted space. The > buffer tabs are more like the tabs used to select between various sheets > in modern spreadsheets. They also do not use extra borders. But they are themselves much different visually than the tabs that were used in the screenshot, and oriented differently. :) For the typical 'property sheet' type of widgets that andy is using, a border around them to show the area of control of the tab widget is normal and desired. If you do not, then the tab widget is really no different than a row of buttons placed on top of an arbitrary screen area. Now, if there was some way to use the smaller, triangular, bottom-oriented tab widgets, then I would agree that the extra border space is not needed _as much_. I'd still like to be able to see it as an option though. >From a gut reaction to thee screenshot, I'd say cool concept but no way in #%!@! I'd use it on a daily basis. I would hope you could turn it off. I typically have so many buffers open that it would quickly get pretty nasty with the large tabs. Using the smaller ones typically seen in spreadsheets, etc, would be better, but could still get pretty cluttered. > Anyone remember the text base DOS IDE's that did MDI in text mode, > wasting a character on every side of the text window, so that you > actaully had a 50x10 window to edit in? Well, this isn't text mode though. It would only take a few pixels. And doesn't everyone run in 32bit 1600x1200 ? :) -bp From owner-xemacs-beta@xemacs.org Wed Jul 21 08:07:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11209 for xemacs-beta-out; Wed, 21 Jul 1999 08:07:21 -0400 Received: from max3p138.smart.net (max3p114.smart.net [216.84.81.114]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11190 for ; Wed, 21 Jul 1999 08:07:11 -0400 Received: (from jmiller@localhost) by max3p138.smart.net (8.9.3/8.9.3) id IAA03399; Wed, 21 Jul 1999 08:03:05 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14229.46837.769148.564352@max3p138.smart.net.> Date: Wed, 21 Jul 1999 08:03:01 -0400 (EDT) To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: completions vs. space in dir name In-Reply-To: References: X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: >>>>> "nbecker" == nbecker writes: nbecker> It seems that completions won't work if a dir has a space nbecker> in the name. APA> For which APA> (emacs-version)? APA> Works fine for me in APA> "XEmacs 21.2 (beta18) \"Toshima\" [Lucid] (i586-pc-win32) of Thu Jul APA> 15 1999 on ZJ75T" I'm willing to be that he has the completer package loaded and you don't. I created some test directories with spaces in the dir name. completion worked with them until i loaded completer. jeff From owner-xemacs-beta@xemacs.org Wed Jul 21 08:16:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11581 for xemacs-beta-out; Wed, 21 Jul 1999 08:16:49 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11577 for ; Wed, 21 Jul 1999 08:16:47 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 116v5x-0003IN-00; Wed, 21 Jul 1999 08:03:33 -0400 To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: completions vs. space in dir name References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 21 Jul 1999 08:03:33 -0400 In-Reply-To: Adrian Aichner's message of "21 Jul 1999 09:18:22 +0200" Message-ID: Lines: 1 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hmmm... Can't seem to reproduce it. From owner-xemacs-beta@xemacs.org Wed Jul 21 08:25:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA11766 for xemacs-beta-out; Wed, 21 Jul 1999 08:25:28 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA11763 for ; Wed, 21 Jul 1999 08:25:26 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 116v12-0003I5-00; Wed, 21 Jul 1999 07:58:28 -0400 To: Darryl Okahata Cc: XEmacs Beta List Subject: Re: tar-mode and crypt revisted References: <199907202321.QAA00128@mina.sr.hp.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 21 Jul 1999 07:58:28 -0400 In-Reply-To: Darryl Okahata's message of "Tue, 20 Jul 1999 16:21:04 -0700" Message-ID: Lines: 3 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Actually, it's stranger than that. When I visit a .tar.gz, it sometimes works correctly and sometimes doesn't. It seems to depend on the loading of other packages - but I haven't isolated it further. From owner-xemacs-beta@xemacs.org Wed Jul 21 10:51:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA17674 for xemacs-beta-out; Wed, 21 Jul 1999 10:51:38 -0400 Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA17670 for ; Wed, 21 Jul 1999 10:51:36 -0400 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 HAA14778 for ; Wed, 21 Jul 1999 07:47:15 -0700 (PDT) Received: from mailhost.corpemea.BayNetworks.COM (mailhost.corpemea.baynetworks.com [141.251.211.40]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA02462 for ; Wed, 21 Jul 1999 10:48:15 -0400 (EDT) Received: from vb-mail1.corpemea.BayNetworks.com (vb-mail1.corpemea.baynetworks.com [141.251.211.10]) by mailhost.corpemea.BayNetworks.COM (8.8.8+Sun/BNET-97/05/05-S) with ESMTP id QAA13747; Wed, 21 Jul 1999 16:53:01 +0200 (MET DST) for Received: from ltrpluim.corpemea.baynetworks.com.corpemea.baynetworks.com ([141.251.166.11]) by vb-mail1.corpemea.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for ; Wed, 21 Jul 1999 16:52:57 +0200 X-Mailer: 21.2 (beta17) "Chiyoda" XEmacs Lucid (via feedmail 8 I); VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14229.56948.202054.513725@ltrpluim.corpemea.baynetworks.com> Date: Wed, 21 Jul 1999 16:51:32 +0200 (CEST) To: xemacs-beta@xemacs.org Subject: Re: Tabs 'n widgets screenshot In-Reply-To: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> X-Attribution: Robert From: Robert Pluim Reply-To: Robert Pluim Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hmm, if you have lots of buffers open, do you get those funky < > and << >> arrows to the {left, right} of the tabs for skipping to the next tab and the next "page" of tabs? Robert -- The above are my opinions, and my opinions only. From owner-xemacs-beta@xemacs.org Wed Jul 21 11:05:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA18565 for xemacs-beta-out; Wed, 21 Jul 1999 11:05:11 -0400 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 LAA18557 for ; Wed, 21 Jul 1999 11:05:06 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id IAA07297; Wed, 21 Jul 1999 08:04:53 -0700 To: Adrian Aichner Cc: XEmacs Beta List Subject: Re: [patch] "config.values" belongs in --docdir References: <873dyidaym.fsf@bittersweet.sysc.pdx.edu> 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: 16 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: APA> can you please send me a note in case you get this patch APA> approved? APA> I will have to make some adjustments for the Windows NT APA> native build then. Well, ok. Here's a note, even though you've already heard from Steven. :-) +- | O| From owner-xemacs-beta@xemacs.org Wed Jul 21 11:07:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA18727 for xemacs-beta-out; Wed, 21 Jul 1999 11:07:18 -0400 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 LAA18723 for ; Wed, 21 Jul 1999 11:07:14 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id IAA08995; Wed, 21 Jul 1999 08:06:56 -0700 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: "(ding)" , xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.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: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Michael" == Michael Sperber writes: >>>>> "argv" == Rajesh Godbole writes: argv> Is threading on the roadmap/TODO list? Is someone actively argv> working on this? IMHO it would be a very desirable feature. Michael> This is not a feature at all: it would constitute an Michael> overhaul affecting just about every part oft the current Michael> system. As far as I know, no. I guess if someone wanted to research it and learn how it might be done, Guile Scheme might be a good place to look. Certainly there are other schemes and lisps with threading... guile, rscheme, ecolisp, scheme48 I'm a few years away from that study, I've found. I tried... and am actually on the track, but it's a tall pile of books. From owner-xemacs-beta@xemacs.org Wed Jul 21 11:12:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA19060 for xemacs-beta-out; Wed, 21 Jul 1999 11:12:02 -0400 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 LAA19055 for ; Wed, 21 Jul 1999 11:11:59 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id IAA29494; Wed, 21 Jul 1999 08:11:13 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-75.beasys.com [192.168.11.75]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id IAA11222; Wed, 21 Jul 1999 08:11:09 -0700 (PDT) Message-Id: <3.0.5.32.19990721161133.00980d40@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jul 1999 16:11:33 +0100 To: wmperry@aventail.com, Jan Vroonhof From: Andy Piper Subject: Re: Tabs 'n widgets screenshot Cc: xemacs-beta@xemacs.org, Ben Wing In-Reply-To: <86r9m2dygn.fsf@megalith.bp.aventail.com> References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> 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 AM 7/21/99 -0500, wmperry@aventail.com wrote: >For the typical 'property sheet' type of widgets that andy is using, a >border around them to show the area of control of the tab widget is normal >and desired. If you do not, then the tab widget is really no different >than a row of buttons placed on top of an arbitrary screen area. Visually different I think :) >Now, if there was some way to use the smaller, triangular, bottom-oriented >tab widgets, then I would agree that the extra border space is not needed >_as much_. I'd still like to be able to see it as an option though. > >From a gut reaction to thee screenshot, I'd say cool concept but no way in >#%!@! I'd use it on a daily basis. I would hope you could turn it off. I Of course. >typically have so many buffers open that it would quickly get pretty nasty >with the large tabs. Using the smaller ones typically seen in Like the buffer menu, only the last few recently used buffers are shown. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Wed Jul 21 11:13:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA19135 for xemacs-beta-out; Wed, 21 Jul 1999 11:13:13 -0400 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 LAA19125 for ; Wed, 21 Jul 1999 11:13:08 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id IAA16748; Wed, 21 Jul 1999 08:14:49 -0700 To: xemacs-beta@xemacs.org Subject: Re: package standards version 1.1 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: 28 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> If there's anything else that someone needs changed regarding sb> info in the package-info.in files, now would be a good time to sb> request it ... A `long-description' field would be nice, with a paragraph or more describing the package. I want to try and auto-generate the debian control file information from the package-info stuff. We use a description field, with one ~65 char line then a paragraph or so... You can read about it here: I have begun to write a few of them, and can send patches... but I am not satisfied with it the way I've got it now. I just added a `long-description' key and a one-long-line inside quotes. But the Debian descriptions can be several paragraphs, and it is often useful to have them contain bulletted lists and suchlike. We can't just use HTML since W3 is unbundled, right? Any Ideas? (I need to have a look at what other things I might need for the autogen of control files too... I'll spend a little time on that today.) From owner-xemacs-beta@xemacs.org Wed Jul 21 11:44:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA21628 for xemacs-beta-out; Wed, 21 Jul 1999 11:44:58 -0400 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 LAA21622 for ; Wed, 21 Jul 1999 11:44:56 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id IAA24545; Wed, 21 Jul 1999 08:46:35 -0700 To: wmperry@aventail.com Cc: Jan Vroonhof , xemacs-beta@xemacs.org, Ben Wing Subject: Re: Tabs 'n widgets screenshot References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> <86r9m2dygn.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: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "wmperry" == wmperry writes: wmperry> I typically have so many buffers open that it would wmperry> quickly get pretty nasty with the large tabs. Using the wmperry> smaller ones typically seen in spreadsheets, etc, would wmperry> be better, but could still get pretty cluttered. Maybe if the tabs where on window configurations, rather than on buffers... Isn't that what Ben's way of doing it would provide? Each tab's area could be like a frame is now, with its own window config stack and window stacking order. It would be another thing on the list of `console', `device', `frame', `window', `buffer'. ^ `tab' You could put other things besides text windows inside the tab's area then also, I suppose. An `xdvi' subwindow might be neat... The tabs need to have keyboard accelerators too obviously. I imagine that's either already there or planned. From owner-xemacs-beta@xemacs.org Wed Jul 21 12:06:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA22867 for xemacs-beta-out; Wed, 21 Jul 1999 12:06:05 -0400 Received: from mail.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA22840; Wed, 21 Jul 1999 12:05:56 -0400 Received: by mail.eai-delta.de (Smail3.2.0.105/mail.eai-delta.de) via Delta-II from KEATS.eai-delta.de with smtp for mail.xemacs.org id m116ysS-001nt2C; Wed, 21 Jul 1999 18:05:52 +0200 (CEST) To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Tabs 'n widgets screenshot References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> <3.0.5.32.19990721161133.00980d40@london.beasys.com> Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R:lt{Y/s1g[= 5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 21 Jul 1999 18:05:53 +0200 In-Reply-To: Andy Piper's message of "Wed, 21 Jul 1999 16:11:33 +0100" Message-ID: Lines: 11 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: In message <3.0.5.32.19990721161133.00980d40@london.beasys.com>, Andy Piper wrote: > Like the buffer menu, only the last few recently used buffers are shown. Is it possible to configure the list of shown buffers, or more to the point set up an alist of buffer(-names) I don't want to see? Eg, I don't need to have the "trace of POP session ..." and things alike at hand all the time. Norbert. From owner-xemacs-beta@xemacs.org Wed Jul 21 13:00:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA26940 for xemacs-beta-out; Wed, 21 Jul 1999 13:00:48 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA26936 for ; Wed, 21 Jul 1999 13:00:47 -0400 Received: from corpmail2.Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20957 for ; Wed, 21 Jul 1999 10:00:45 -0700 (PDT) Received: from einstein.Corp.Sun.COM (einstein.Corp.Sun.COM [129.145.208.63]) by corpmail2.Corp.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA17335 for ; Wed, 21 Jul 1999 10:00:43 -0700 (PDT) Received: (from rajesh@localhost) by einstein.Corp.Sun.COM (8.9.3+Sun/8.9.1) id KAA28734; Wed, 21 Jul 1999 10:00:43 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.126 From: Rajesh Godbole In-Reply-To: Didier Verna's message of "21 Jul 1999 13:35:41 +0200" X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# Date: 21 Jul 1999 10:00:43 -0700 Message-ID: <8t6hfmylyys.fsf@Corp.Sun.COM> Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: DV> Last time I checked, it wasn't, but this might have DV> changed. However, getting multithreading "for free" is a bit DV> optimistic. You get multithreading at the langage level, DV> yes. But that's probably not the most difficult thing to DV> achieve. The major part of the work is properly designing the DV> way you'll use multithreading: how many threads ? To do what ? DV> Threads for user commands ? and so on, with all the non DV> obvious problems it brings, like synchronisation, mutual DV> exclusion, resources protection etc. There's also a libgthread that's part of glib. If [x]emacs were to be based on glib/gtk, "free" threading could become available. FAQ: http://www.serpentine.com/~bos/threads-faq/ is also quite useful. From owner-xemacs-beta@xemacs.org Wed Jul 21 14:10:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA32126 for xemacs-beta-out; Wed, 21 Jul 1999 14:10:15 -0400 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 OAA32117 for ; Wed, 21 Jul 1999 14:10:13 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id OAA18357 for xemacs-beta@xemacs.org; Wed, 21 Jul 1999 14:10:20 -0400 Date: Wed, 21 Jul 1999 14:10:20 -0400 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail Message-ID: <19990721141020.A18339@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <8t6hfmylyys.fsf@Corp.Sun.COM>; from Rajesh Godbole on Wed, Jul 21, 1999 at 10:00:43AM -0700 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Jul 21, 1999 at 10:00:43AM -0700, Rajesh Godbole wrote: > There's also a libgthread that's part of glib. If [x]emacs were to > be based on glib/gtk, "free" threading could become available. Oh yeah ? I'm really interesting in how using gtk/glib will make our _LISP_ code thread-safe. Do your homework before spitting such nonsense damnit. OG. From owner-xemacs-beta@xemacs.org Wed Jul 21 15:44:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA06812 for xemacs-beta-out; Wed, 21 Jul 1999 15:44:20 -0400 Received: from swp5.gs.com (swp5.gs.com [192.246.9.39]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA06808 for ; Wed, 21 Jul 1999 15:44:16 -0400 Received: from swp5.gs.com (root@localhost) by swp5.gs.com with ESMTP id PAA00663 for ; Wed, 21 Jul 1999 15:44:14 -0400 (EDT) Received: from nbcppsh02.wan.gs.com ([199.29.246.34]) by swp5.gs.com with ESMTP id PAA00650 for ; Wed, 21 Jul 1999 15:44:13 -0400 (EDT) Received: from nbcppsh01.wan.gs.com (nbcppsh01.wan.gs.com [138.8.220.34]) by nbcppsh02.wan.gs.com (8.9.1a/8.9.0/dmzpo1) with ESMTP id PAA28822 for ; Wed, 21 Jul 1999 15:44:12 -0400 (EDT) Received: from gsny26e.et.gs.com (gsny26e.et.gs.com [148.86.93.28]) by nbcppsh01.wan.gs.com (8.9.1a/8.9.0/postoffice1) with ESMTP id PAA13633 for ; Wed, 21 Jul 1999 15:44:12 -0400 (EDT) Received: by gsny26e.et.gs.com with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jul 1999 15:44:12 -0400 Message-ID: <851279708234D3118C7400902762C5A629251D@gsny26e.et.gs.com> From: "Blob, Dave" To: "'xemacs-beta@xemacs.org'" Subject: JDE & EFS... Date: Wed, 21 Jul 1999 15:44:11 -0400 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: Hi, I downloaded 21.1.3 and the sumo tarball and had problems editing remote java files. It looks to be a problem with JDE - specifically where it tries to find the project file (jde-find-project-file or jde-root-dir). I think adding successive ../'s is never giving a final root directory, but this is just a guess. In the meantime, since I don't really need it, I disabled jde. I don't need any resolution - I just thought I'd point it out. Thanks, Dave From owner-xemacs-beta@xemacs.org Wed Jul 21 16:03:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA08481 for xemacs-beta-out; Wed, 21 Jul 1999 16:03:51 -0400 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 QAA08295; Wed, 21 Jul 1999 16:02:26 -0400 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 QAA17039; Wed, 21 Jul 1999 16:08:17 -0400 (EDT) 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 WAA00933; Wed, 21 Jul 1999 22:02:16 +0200 (MET DST) To: xemacs-beta@xemacs.org Cc: XEmacs NT List Subject: Re: [patch] "config.values" belongs in --docdir References: <873dyidaym.fsf@bittersweet.sysc.pdx.edu> 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 Jul 1999 22:00:18 +0200 In-Reply-To: SL Baur's message of "21 Jul 1999 16:46:53 +0900" Message-ID: Lines: 27 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id QAA08301 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Adrian Aichner writes in xemacs-beta@xemacs.org: >> I will have to make some adjustments for the Windows NT native build >> then. sb> Go ahead. The patch has been approved. Steven, I have come to the conclusion that xemacs.mak does not need to change after all. I have synched xemacs95.mak with xemacs.mak along the way to build the info target on Windows 95 as well. Will provide a patch for xemacs95.mak against 21.1.4. Regards, Adrian sb> -- sb> $B6}F~$l6}=P$7(B (Garbage in, Garbage out) From owner-xemacs-beta@xemacs.org Wed Jul 21 16:29:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA10076 for xemacs-beta-out; Wed, 21 Jul 1999 16:29:48 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA10070 for ; Wed, 21 Jul 1999 16:29:36 -0400 Received: from corpmail2.Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28749; Wed, 21 Jul 1999 13:29:34 -0700 (PDT) Received: from einstein.Corp.Sun.COM (einstein.Corp.Sun.COM [129.145.208.63]) by corpmail2.Corp.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA14226; Wed, 21 Jul 1999 13:29:34 -0700 (PDT) Received: (from rajesh@localhost) by einstein.Corp.Sun.COM (8.9.3+Sun/8.9.1) id NAA01385; Wed, 21 Jul 1999 13:29:34 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> X-Attribution: argv Mail-Copies-To: never X-nnimap-version: nnimap 0.126 From: Rajesh Godbole In-Reply-To: Olivier Galibert's message of "Wed, 21 Jul 1999 14:10:20 -0400" X-Face: #9'hMEg!Tzyt&;9v5bMUa^|u2i\Jta'Pm60L(<|c%i0x?1&OW51STz)74QB0ks*D:qvSNEx QE_,L\P{k`yh,JX5V#4h)I/2d|"6AtrXP#$hI=T-|FAV'{57HHC+4Ny[:.vej<,?~wfZ0:c!|C_+L; d|xN[$L:;.br(DGXU?EF#%=6@RZI#zLLzi(R=s-@|uXAuo)bb%"kUW')G*s:lj2BMPI^Vb# Date: 21 Jul 1999 13:29:33 -0700 Message-ID: <8t6emi1u4pe.fsf@Corp.Sun.COM> Lines: 57 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > Oh yeah ? I'm really interesting in how using gtk/glib will > make our _LISP_ code thread-safe. Why do I get the feeling that I've opened a can of worms. Okay, here's my $0.02. In order for threading to work with emacs-lisp the following things need to happen. (We're talking relatively long term here, hence the word roadmap.) o The OS First off, the OS itself needs to "support" threads. Most industrial strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, Sun. o [x]emacs [x]emacs would need to use a threaded library in order to support multiple threads of execution within the same process. gtk/glib would be _one_ solution. Its used extensively in gnome and mozilla. xemacs code would need to be made mt-safe by mutex-locking out critical sections of the code. gtk/glib could provide a new widget set to replace existing ones, but that's another debate. o emacs-lisp the base emacs-lisp would need to provide extended lisp functionality to interface with the low-level threads library. This would probably be a package that provides mutex o emacs-lisp applications Applications like gnus, w3 which can potentially do multiple asynchronous fetches in the background would, probably benefit from an mt emacs-lisp. Issues like how many threads (eg. 1 per newsgroup?) synchronization, mutual exclusion etc would probably be counter-balanced by improvement in performance and functionality. A context switch between two threads in a single process is considerably cheaper than a context switch between two processes. Also, all data except for stack and registers are shared between threads. This makes threading interesting for such apps. _LISP_ code wouldn't magically become mt-safe, it would need to be modified to make it so. One would, of course, have the option to use only a single thread of execution, so existing apps should work with even with mt emacs-lisp. > Do your homework before > spitting such nonsense damnit. Now now, there's no need for foul language. Go stand in the corner. From owner-xemacs-beta@xemacs.org Wed Jul 21 17:34:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA12553 for xemacs-beta-out; Wed, 21 Jul 1999 17:34:07 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA12548 for ; Wed, 21 Jul 1999 17:34:06 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-35.kiva.net [206.97.75.100]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id OAA02783 for ; Wed, 21 Jul 1999 14:32:48 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id QAA01438; Wed, 21 Jul 1999 16:33:38 -0500 To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.COM> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 38 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Rajesh Godbole writes: > >>>>> Olivier Galibert writes: > > > Oh yeah ? I'm really interesting in how using gtk/glib will > > make our _LISP_ code thread-safe. > > Why do I get the feeling that I've opened a can of worms. > > Okay, here's my $0.02. In order for threading to work with emacs-lisp > the following things need to happen. (We're talking relatively long > term here, hence the word roadmap.) > > o The OS > First off, the OS itself needs to "support" threads. Most industrial > strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, > Sun. > > o [x]emacs > [x]emacs would need to use a threaded library in order to support > multiple threads of execution within the same process. gtk/glib > would be _one_ solution. Its used extensively in gnome and mozilla. > > xemacs code would need to be made mt-safe by mutex-locking out > critical sections of the code. > > gtk/glib could provide a new widget set to replace existing ones, > but that's another debate. > > o emacs-lisp > the base emacs-lisp would need to provide extended lisp > functionality to interface with the low-level threads library. > This would probably be a package that provides mutex The _real_ problem is making the interpreter thread safe, not just adding the primitives to make the actual lisp _programs_ thread safe. -bp From owner-xemacs-beta@xemacs.org Wed Jul 21 17:50:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA13116 for xemacs-beta-out; Wed, 21 Jul 1999 17:50:04 -0400 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 RAA13102 for ; Wed, 21 Jul 1999 17:49:57 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id OAA26141; Wed, 21 Jul 1999 14:51:34 -0700 To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.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: 16 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "argv" == Rajesh Godbole writes: >>>>> Olivier Galibert writes: argv> Why do I get the feeling that I've opened a can of worms. Trolling? argv> o The OS argv> First off, the OS itself needs to "support" threads. Most argv> industrial strength OSes do so. Examples, DG/UX, HP/UX, argv> AIX, Linux, Windoze, Sun. Guile uses a user space thread library that doesn't require OS threads. It only works on systems for which the assembler part has been written. It does stack-switching. From owner-xemacs-beta@xemacs.org Wed Jul 21 17:53:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA13249 for xemacs-beta-out; Wed, 21 Jul 1999 17:53:36 -0400 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 RAA13245 for ; Wed, 21 Jul 1999 17:53:34 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id RAA19083 for xemacs-beta@xemacs.org; Wed, 21 Jul 1999 17:53:42 -0400 Date: Wed, 21 Jul 1999 17:53:42 -0400 From: Olivier Galibert To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail Message-ID: <19990721175342.A18941@nemesis.ncsl.nist.gov> Mail-Followup-To: xemacs-beta@xemacs.org References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <8t6emi1u4pe.fsf@Corp.Sun.COM>; from Rajesh Godbole on Wed, Jul 21, 1999 at 01:29:33PM -0700 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, Jul 21, 1999 at 01:29:33PM -0700, Rajesh Godbole wrote: > > >>>>> Olivier Galibert writes: > > > Oh yeah ? I'm really interesting in how using gtk/glib will > > make our _LISP_ code thread-safe. > > Why do I get the feeling that I've opened a can of worms. I tend to get a bit fed up with the "oh, add that because it's cool" attitude. I've seen it repeated a lot on different projects I'm working on lately, I just happen to be the one that pushed me over the edge. Tough luck. > Okay, here's my $0.02. In order for threading to work with emacs-lisp > the following things need to happen. (We're talking relatively long > term here, hence the word roadmap.) > > o The OS > First off, the OS itself needs to "support" threads. Most industrial > strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, ^^^^^^^ > Sun. We call this system "Windows" on this mailing-list. We decided a long time ago the 31337 h@x0R attitude had nothing to do here. I don't mean you have it, it's just that it's a bad habit to take. AFAIK, all systems but MacOs XEmacs has been ported to have a decent thread support. > o [x]emacs > [x]emacs would need to use a threaded library in order to support > multiple threads of execution within the same process. gtk/glib > would be _one_ solution. Its used extensively in gnome and mozilla. gtk is not thread safe, not at all. Additionally, gtk documentation is inexistant at best. You don't want to see the stunts I had to make to show live video in a widget. > xemacs code would need to be made mt-safe by mutex-locking out > critical sections of the code. Nice joke. Please define "critical sections of the code" in the case of XEmacs in a way that doesn't involve 95% of the C code. I'm waiting. > o emacs-lisp > the base emacs-lisp would need to provide extended lisp > functionality to interface with the low-level threads library. > This would probably be a package that provides mutex Hint: XEmacs is written in lisp, not in C. The C part is only the lisp engine, the basic functionalities needed to write an editor, and the rewriting of some specific code too slow in lisp. Try again. > o emacs-lisp applications > Applications like gnus, w3 which can potentially do multiple > asynchronous fetches in the background would, probably benefit > from an mt emacs-lisp. Issues like how many threads (eg. 1 > per newsgroup?) synchronization, mutual exclusion etc would > probably be counter-balanced by improvement in performance and > functionality. If what you need is asynchronous I/O, add asynchronous I/O. It will be even more performant because you will avoid all mutex funkiness. > A context switch between two threads in a single process is > considerably cheaper than a context switch between two processes. > Also, all data except for stack and registers are shared between > threads. This makes threading interesting for such apps. kernel threads, or lisp threads ? OG. From owner-xemacs-beta@xemacs.org Wed Jul 21 18:26:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA14589 for xemacs-beta-out; Wed, 21 Jul 1999 18:26:03 -0400 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 SAA14582 for ; Wed, 21 Jul 1999 18:25:59 -0400 Received: by crystal.WonderWorks.COM id QQgywn16939; Wed, 21 Jul 1999 15:25:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.18669.388312.541056@crystal.WonderWorks.COM> Date: Wed, 21 Jul 1999 15:25:49 -0700 (PDT) From: Kyle Jones To: Rajesh Godbole Cc: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail In-Reply-To: <8t6emi1u4pe.fsf@Corp.Sun.COM> References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.COM> X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: Rajesh Godbole writes: > > >>>>> Olivier Galibert writes: > > > Oh yeah ? I'm really interesting in how using gtk/glib will > > make our _LISP_ code thread-safe. > > Why do I get the feeling that I've opened a can of worms. :) There is still the question for which I still have not heard a good answer--- Why do this? Threading doesn't give you very many benefits that simple multiprocessing doesn't give you. But with threading, you are enormously multiplying the complexity and sources of bugs, both in the core system and the applications that run on it. I agree that we could save some memory with threading vs. multiple processes, but memory is much cheaper than man hours. We'd have to overhaul the Lisp system and all the applications to make them mt-safe, and all without funding? I can't imagine it happening. From owner-xemacs-beta@xemacs.org Wed Jul 21 18:36:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA15009 for xemacs-beta-out; Wed, 21 Jul 1999 18:36:15 -0400 Received: from alpha1.ebi.ac.uk (alpha1.ebi.ac.uk [193.62.196.122]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA15005 for ; Wed, 21 Jul 1999 18:36:12 -0400 Received: from BRYCE.ebi.ac.uk (bryce.ebi.ac.uk [193.62.196.60]) by alpha1.ebi.ac.uk (8.8.7/8.8.7) with ESMTP id XAA32013; Wed, 21 Jul 1999 23:36:09 +0100 (BST) Date: Wed, 21 Jul 1999 23:36:08 +0100 X-Mailer: emacs 20.3.11b.1 (via feedmail 9-beta-7 I); VM 6.72 under Emacs 20.3.11b.1 From: David Starks-Browning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.19284.231000.563252@bryce.ebi.ac.uk> To: "Blob, Dave" CC: xemacs-beta@xemacs.org Subject: JDE & EFS... In-Reply-To: <851279708234D3118C7400902762C5A629251D@gsny26e.et.gs.com> References: <851279708234D3118C7400902762C5A629251D@gsny26e.et.gs.com> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: This came up on the jde@sunsite.auc.dk mailing list (11 May 99 to be precise). I don't know whether it has been fixed. One workaround is to create a prj.el file on the remote filesystem. (In case disabling JDE isn't satisfactory.) Regards, David ------------------------------------------------------------------- David Starks-Browning | starksb@ebi.ac.uk EMBL Outstation -- | The European Bioinformatics Institute | Wellcome Trust Genome Campus | tel: +44 (1223) 494 616 Hinxton, Cambridge, CB10 1SD, UK | fax: +44 (1223) 494 468 ------------------------------------------------------------------- On Wednesday 21 Jul 99, Blob, Dave writes: > Hi, > > I downloaded 21.1.3 and the sumo tarball and had problems editing remote > java files. It looks to be a problem with JDE - specifically where it > tries to find the project file (jde-find-project-file or jde-root-dir). I > think adding successive ../'s is never giving a final root directory, but > this is just a guess. In the meantime, since I don't really need it, I > disabled jde. I don't need any resolution - I just thought I'd point it > out. > > Thanks, > Dave From owner-xemacs-beta@xemacs.org Thu Jul 22 00:21:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA23489 for xemacs-beta-out; Thu, 22 Jul 1999 00:21:57 -0400 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 AAA23486 for ; Thu, 22 Jul 1999 00:21:56 -0400 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 VAA28736; Wed, 21 Jul 1999 21:21:51 -0700 (PDT) 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 VAA19738; Wed, 21 Jul 1999 21:20:52 -0700 (PDT) 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 VAA14023; Wed, 21 Jul 1999 21:21:49 -0700 (PDT) Message-Id: <199907220421.VAA14023@mina.sr.hp.com> To: nbecker@fred.net cc: XEmacs Beta List Subject: Re: tar-mode and crypt revisted Reply-To: Darryl Okahata In-reply-to: Your message of "21 Jul 1999 07:58:28 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 21 Jul 1999 21:21:48 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net wrote: > Actually, it's stranger than that. When I visit a .tar.gz, it > sometimes works correctly and sometimes doesn't. It seems to depend > on the loading of other packages - but I haven't isolated it further. As a test, try adding the following to your ~/.emacs file: (setq tar-regexp "\\.\\(tar\\)$") This is, basically, what the patch does. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Thu Jul 22 00:38:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA24389 for xemacs-beta-out; Thu, 22 Jul 1999 00:38:57 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA24380; Thu, 22 Jul 1999 00:38:54 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA03700; Thu, 22 Jul 1999 13:38:52 +0900 (JST) Mail-Copies-To: never To: xemacs-review@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: XEmacs - Autoload error - cannot open load file: mule References: <14223.57449.767317.210412@fileserver.cs.nwu.edu> X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "19 Jul 1999 10:48:57 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-2022-JP Date: 22 Jul 1999 13:38:43 +0900 Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-review@xemacs.org: > Yes. But the package tools use > (or (eq package 'mule-base) (memq 'mule-base this-requires) > I am not sure why, but there was a good reason for that at the time. O.K. I've made the necessary changes for `distribution' to work. I will start committing changes after I clear out the incoming package patch queue. You will need to check that standards-version is >= 1.1 and then use the value of the distribution field + "-packages" to determine the hierarchy. I.e. `distribution xemacs', use xemacs-packages/, `distribution mule', use mule-packages/, `distribution infodock', use infodock-packages/, `distribution foo' use foo-packages/, etc. If there are any objections to the following statement, please make them now. `standards-version' numbers are floating point numbers of the form X.Y where X is the major version and Y is a single digit minor version. Increments of the minor version indicates small changes or corrections to the format of the package-info.in file. Increments to the major version indicate probably backwards-incompatible changes. I expect to go to version 2.0 when Michael completes his work. -- $B1+9_$C$FCO8G$^$k(B (Adversity builds character) From owner-xemacs-beta@xemacs.org Thu Jul 22 02:04:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA26407 for xemacs-beta-out; Thu, 22 Jul 1999 02:04:57 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA26403 for ; Thu, 22 Jul 1999 02:04:48 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA08492 for ; Thu, 22 Jul 1999 15:04:41 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: gutter-items.el bombs in the latest 21.2 CVS X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 22 Jul 1999 15:04:32 +0900 Message-ID: Lines: 39 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Why is gutter-items.el being dumped with an X-less XEmacs? Loading gutter-items.el...*** Error in XEmacs initialization (void-function buffers-menu-omit-invisible-buffers) *** Backtrace really-early-error-handler((void-function buffers-menu-omit-invisible-buffers)) There needs to be some kind of guard on this line here: (add-tab-to-gutter) I'm commenting it out for the time being. uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ./configure '--prefix=/usr/local/devel' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.2-b18 "Toshima" 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/devel 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/lib 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 DLL support. movemail will use "dot-locking" for locking mail spool files. From owner-xemacs-beta@xemacs.org Thu Jul 22 02:20:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA26891 for xemacs-beta-out; Thu, 22 Jul 1999 02:20:52 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA26884 for ; Thu, 22 Jul 1999 02:20:49 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA09469 for ; Thu, 22 Jul 1999 15:20:40 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Autoload error in: ...: Cannot open load file: mule References: X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "17 Jul 1999 19:25:06 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 22 Jul 1999 15:20:32 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: ... > How did you upgrade? Is it OK in the Sumo's? None of the new packages are in the Sumos. I don't put packages into the Sumos until they are in the CVS tree[1]. Footnotes: [1] Hello Jareth! :-) From owner-xemacs-beta@xemacs.org Thu Jul 22 02:25:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA27054 for xemacs-beta-out; Thu, 22 Jul 1999 02:25:21 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA27050 for ; Thu, 22 Jul 1999 02:25:18 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA09735 for ; Thu, 22 Jul 1999 15:25:16 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Discrepancy between Installation and configure X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 22 Jul 1999 15:25:07 +0900 Message-ID: Lines: 5 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Installation sez: Compiling in DLL support. but the configure option is --with-shlib/--without-shlib. These need to match. Which one is the preferred name? From owner-xemacs-beta@xemacs.org Thu Jul 22 02:28:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA27151 for xemacs-beta-out; Thu, 22 Jul 1999 02:28:16 -0400 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 CAA27148 for ; Thu, 22 Jul 1999 02:28:12 -0400 Received: from brabantio.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 IAA15082; Thu, 22 Jul 1999 08:27:52 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id IAA22966; Thu, 22 Jul 1999 08:27:45 +0200 To: xemacs-beta@xemacs.org Cc: Rajesh Godbole Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.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: 22 Jul 1999 08:27:44 +0200 In-Reply-To: Rajesh Godbole's message of "21 Jul 1999 13:29:33 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA27149 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "argv" == Rajesh Godbole writes: >>>>> Olivier Galibert writes: >> Oh yeah ? I'm really interesting in how using gtk/glib will >> make our _LISP_ code thread-safe. argv> Why do I get the feeling that I've opened a can of worms. argv> Okay, here's my $0.02. In order for threading to work with emacs-lisp argv> the following things need to happen. (We're talking relatively long argv> term here, hence the word roadmap.) argv> o The OS argv> First off, the OS itself needs to "support" threads. [...] Please stop wasting bandwidth. You don't have a clue what you're talking about. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Thu Jul 22 03:45:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA29412 for xemacs-beta-out; Thu, 22 Jul 1999 03:45:56 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA29409 for ; Thu, 22 Jul 1999 03:45:53 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id QAA14511 for ; Thu, 22 Jul 1999 16:45:50 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Upcoming Sumo/21.2 schedule X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 22 Jul 1999 16:45:41 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have drained the incoming patch queue except for about a half dozen InfoDock synch patches. If you have an outstanding patch that hasn't received an ACK or NACK, I don't have it. I plan on making new Sumos tomorrow, along with a total XEmacs Lisp package rebuild of the world. 21.2.19 won't make it this week, but it sounds like several people have patches that need committing, so a few extra days for them won't hurt. Please try to get those patches committed as soon as possible so people can test. I will try to make 21.2.19 on Monday afternoon (JST). From owner-xemacs-beta@xemacs.org Thu Jul 22 04:29:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA30670 for xemacs-beta-out; Thu, 22 Jul 1999 04:29:34 -0400 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 EAA30667 for ; Thu, 22 Jul 1999 04:29:33 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA15832; Thu, 22 Jul 1999 01:29:17 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-44.beasys.com [192.168.11.44]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA11973; Thu, 22 Jul 1999 01:29:14 -0700 (PDT) Message-Id: <3.0.5.32.19990722092938.00a27210@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:29:38 +0100 To: Robert Pluim , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Tabs 'n widgets screenshot In-Reply-To: <14229.56948.202054.513725@ltrpluim.corpemea.baynetworks.co m> References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <3.0.5.32.19990720115235.00a98db0@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 04:51 PM 7/21/99 +0200, Robert Pluim wrote: > >Hmm, if you have lots of buffers open, do you get those funky < > and ><< >> arrows to the {left, right} of the tabs for skipping to the next >tab and the next "page" of tabs? Yes, but only under windows and only if you have the max tabs set to more than you can see. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 22 04:34:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA30837 for xemacs-beta-out; Thu, 22 Jul 1999 04:34:33 -0400 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 EAA30833 for ; Thu, 22 Jul 1999 04:34:31 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA18475; Thu, 22 Jul 1999 01:34:14 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-44.beasys.com [192.168.11.44]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA12174; Thu, 22 Jul 1999 01:34:12 -0700 (PDT) Message-Id: <3.0.5.32.19990722093436.00a25a80@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:34:36 +0100 To: Norbert Koch From: Andy Piper Subject: Re: Tabs 'n widgets screenshot Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> <3.0.5.32.19990721161133.00980d40@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 06:05 PM 7/21/99 +0200, Norbert Koch wrote: >In message <3.0.5.32.19990721161133.00980d40@london.beasys.com>, >Andy Piper wrote: > >> Like the buffer menu, only the last few recently used buffers are shown. > >Is it possible to configure the list of shown buffers, or more to the >point set up an alist of buffer(-names) I don't want to see? Eg, I don't >need to have the "trace of POP session ..." and things alike at hand >all the time. Yes. The implementation was a first pass :) I think buffers-tab-omit-function should be set to something cleverer than buffers-menu-omit-invisible-buffers. If anyone wants to code this, be my guest. I'd really like to try and focus on the C display code as there are still a few bugs (+ X support in the works). gutter-items.el is just lisp which most people can hack :) I would guess you probably want to group buffers like the buffer menu does and then show the group of the most recently selected buffer. i.e. so if you are working with C files you see all the .h and .c files, lisp files and you see all the .el's etc. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 22 04:41:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA31085 for xemacs-beta-out; Thu, 22 Jul 1999 04:41:41 -0400 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 EAA31081 for ; Thu, 22 Jul 1999 04:41:39 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA19352; Thu, 22 Jul 1999 01:40:50 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-44.beasys.com [192.168.11.44]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA12614; Thu, 22 Jul 1999 01:40:46 -0700 (PDT) Message-Id: <3.0.5.32.19990722094110.00a26c30@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:41:10 +0100 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom), wmperry@aventail.com From: Andy Piper Subject: Re: Tabs 'n widgets screenshot Cc: Jan Vroonhof , xemacs-beta@xemacs.org, Ben Wing In-Reply-To: <873dyiatus.fsf@bittersweet.sysc.pdx.edu> References: <3.0.5.32.19990720115235.00a98db0@london.beasys.com> <37959663.6FD09689@666.com> <86r9m2dygn.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 08:46 AM 7/21/99 -0700, Karl M. Hegbloom wrote: > Maybe if the tabs where on window configurations, rather than on > buffers... Isn't that what Ben's way of doing it would provide? > Each tab's area could be like a frame is now, with its own window > config stack and window stacking order. It would be another thing on > the list of `console', `device', `frame', `window', `buffer'. > ^ > `tab' I think this would be way ugly and an even worse visual metphor than Ben and Bill are complaining about. Redisplay currently considers toolbar + window + modeline + minibuffer as a whole from the toolkit perspective. So tabbing this would mean you would get the toolbar etc inside the tabs - very wierd IMHO. Also what do you do with split windows - again this breaks the metaphor. If you tab on a per-window basis, a) you have to change redisplay a lot b) what do you do about split windows. I think leaving the tab area of control slightly ambiguous actualy *helps* in our rather strange XEmacs environment. > You could put other things besides text windows inside the tab's area > then also, I suppose. An `xdvi' subwindow might be neat... This will be doable eventually anyway. You will eventually be able to embed image instances inside others so that you could put subwindows inside tabs, or anything you like. > The tabs need to have keyboard accelerators too obviously. I imagine > that's either already there or planned. Sure. The code is semi-there its a matter of wiring it all up. I'm hoping that as a we approach crtical mass, others will tweak the X-side to get it looking and behaving correctly. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 22 04:46:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA31216 for xemacs-beta-out; Thu, 22 Jul 1999 04:46:29 -0400 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 EAA31205; Thu, 22 Jul 1999 04:46:24 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA19533; Thu, 22 Jul 1999 01:46:08 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-44.beasys.com [192.168.11.44]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA12791; Thu, 22 Jul 1999 01:46:05 -0700 (PDT) Message-Id: <3.0.5.32.19990722094629.00a293a0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:46:29 +0100 To: SL Baur , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: gutter-items.el bombs in the latest 21.2 CVS 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: Oops, sorry. Gutter support exists in an X-less XEmacs, but gutter-items is only useful in a windowing environment. I'll fix it. andy At 03:04 PM 7/22/99 +0900, SL Baur wrote: >Why is gutter-items.el being dumped with an X-less XEmacs? > > >Loading gutter-items.el...*** Error in XEmacs initialization >(void-function buffers-menu-omit-invisible-buffers) >*** Backtrace > really-early-error-handler((void-function buffers-menu-omit-invisible-buffers)) > >There needs to be some kind of guard on this line here: > >(add-tab-to-gutter) This is already done with specifiers. I think the problem is that gutter-items.el uses some of the menubar code which doesn't exist with an X-less XEmacs. >I'm commenting it out for the time being. I'll fix it quick. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 22 04:56:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA31490 for xemacs-beta-out; Thu, 22 Jul 1999 04:56:36 -0400 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 EAA31482; Thu, 22 Jul 1999 04:56:31 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id BAA19796; Thu, 22 Jul 1999 01:56:10 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-82.beasys.com [192.168.11.82]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id BAA13201; Thu, 22 Jul 1999 01:56:07 -0700 (PDT) Message-Id: <3.0.5.32.19990722095630.00a239a0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:56:30 +0100 To: SL Baur , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: gutter-items.el bombs in the latest 21.2 CVS Cc: xemacs-review@xemacs.org 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 03:04 PM 7/22/99 +0900, SL Baur wrote: >Why is gutter-items.el being dumped with an X-less XEmacs? I've fixed this now. andy 1999-07-22 Andy Piper * dumped-lisp.el (preloaded-file-list): guard against putting gutter-items in a less than functional XEmacs. * gutter-items.el: put call to `add-tab-to-gutter' back in. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 22 05:06:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA31684 for xemacs-beta-out; Thu, 22 Jul 1999 05:06:00 -0400 Received: from jschoi.ne.mediaone.net (philg.ne.mediaone.net [24.128.172.89]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id FAA31676 for ; Thu, 22 Jul 1999 05:05:55 -0400 Received: (qmail 1486 invoked by uid 500); 22 Jul 1999 09:07:03 -0000 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.57143.803620.827830@jschoi.ne.mediaone.net> Date: Thu, 22 Jul 1999 05:07:03 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: reproducible crash in 21.1.4 in tcl-mode X-Mailer: VM 6.71 under 21.0 "20 minutes to Nikko" XEmacs Lucid (beta67) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've got a reproducible crash running XEmacs 21.1.4 under Solaris 2.6 compiled with gcc. tcl-mode version is 1.50. Recipe: * xemacs -vanilla * M-x tcl-mode * \[ \] Lisp backtrace: skip-syntax-backward("/\\") # (unwind-protect ...) blink-matching-open() self-insert-command(1) # bind (arg) tcl-electric-char(1) # bind (command-debug-status) call-interactively(tcl-electric-char) # (condition-case ... . error) # (catch top-level ...) I don't have gdb or any other debugger installed right now, or I'd send in a C backtrace... sorry. -Jin From owner-xemacs-beta@xemacs.org Thu Jul 22 05:13:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA31881 for xemacs-beta-out; Thu, 22 Jul 1999 05:13:44 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA31878 for ; Thu, 22 Jul 1999 05:13:41 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id SAA21115 for ; Thu, 22 Jul 1999 18:13:39 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: gutter-items.el bombs in the latest 21.2 CVS References: <3.0.5.32.19990722095630.00a239a0@london.beasys.com> X-Attribution: sb From: SL Baur In-Reply-To: Andy Piper's message of "Thu, 22 Jul 1999 09:56:30 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 22 Jul 1999 18:13:30 +0900 Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes in xemacs-beta@xemacs.org: > At 03:04 PM 7/22/99 +0900, SL Baur wrote: >> Why is gutter-items.el being dumped with an X-less XEmacs? > I've fixed this now. > andy > 1999-07-22 Andy Piper > * dumped-lisp.el (preloaded-file-list): guard against putting > gutter-items in a less than functional XEmacs. > * gutter-items.el: put call to `add-tab-to-gutter' back in. Cool, thanks. Works for me: Compiling /usr/local/devel/xemacs-21.2/lisp/gutter-items.el... Wrote /usr/local/devel/xemacs-21.2/lisp/gutter-items.elc From owner-xemacs-beta@xemacs.org Thu Jul 22 05:14:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA31896 for xemacs-beta-out; Thu, 22 Jul 1999 05:14:53 -0400 Received: from hands.niss.ac.uk (hands.niss.ac.uk [138.38.32.116]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA31893 for ; Thu, 22 Jul 1999 05:14:52 -0400 Received: from feet.niss.ac.uk ([193.63.76.162] helo=gristle.niss.ac.uk) by hands.niss.ac.uk with esmtp (Exim 2.12 #1) id 117EyN-0000Gx-00 for xemacs-beta@xemacs.org; Thu, 22 Jul 1999 10:17:03 +0100 Received: from ccsnjd by gristle.niss.ac.uk with local (Exim 2.12 #1) id 117Ewp-0000oa-00 for xemacs-beta@xemacs.org; Thu, 22 Jul 1999 10:15:27 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.57647.116360.518229@gristle.niss.ac.uk> Date: Thu, 22 Jul 1999 10:15:27 +0100 (BST) To: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail In-Reply-To: References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.COM> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Organisation: NISS X-URL: http://www.bath.ac.uk/~ccsnjd X-Cabaret-Voltaire-URL: http://www.brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Michael Sperber [Mr. Preprocessor] wrote on 22-July-1999: ->You don't have a clue what you're ->talking about. And on that subject... I once spent a bit of time trying to add support for (Posix) threads in XEmacs. However I found my competency to complexity-of-task ratio far too low. ;-) I may look back at it again in the winter. I've also looked at using different scheme/lisp substrates which already have thread support - with the view to shoving them under XEmacs. This may be a "better" long term solution - but this really is too hard for little me. [Please let's not get into the discussion over which language to put under XEmacs... we've been there too many times before. See Michael's page for details.[1]] Someone else lacking in cluons, nic Footnotes: [1] http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/language.html From owner-xemacs-beta@xemacs.org Thu Jul 22 05:37:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA32429 for xemacs-beta-out; Thu, 22 Jul 1999 05:37:51 -0400 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 FAA32423 for ; Thu, 22 Jul 1999 05:37:46 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 117FIF-0000QR-00 for ; Thu, 22 Jul 1999 11:37:35 +0200 To: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@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: 22 Jul 1999 11:37:35 +0200 In-Reply-To: SL Baur's message of "21 Jul 1999 13:25:34 +0900" Message-ID: <87g12hauu8.fsf@pc-hrvoje.srce.hr> Lines: 11 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > I can't. What I cannot duplicate is Hrvoje's results with > WindowMaker. Regardless of the value of > `allow-deletion-of-last-visible-frame', I can C-x 5 0 a frame when > another frame is open in another workspace, i.e. WindowMaker always > does the Right Thing. NB: What version of WindowMaker do you use? I use version 0.60.0, the one from Debian (0.60.0-4). From owner-xemacs-beta@xemacs.org Thu Jul 22 05:38:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA32455 for xemacs-beta-out; Thu, 22 Jul 1999 05:38:22 -0400 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 FAA32451 for ; Thu, 22 Jul 1999 05:38:20 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 117FIt-0000QY-00 for ; Thu, 22 Jul 1999 11:38:15 +0200 To: XEmacs Beta List Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@crystal.WonderWorks.COM> <14229.41837.672349.429465@gristle.niss.ac.uk> 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 Jul 1999 11:38:15 +0200 In-Reply-To: 's message of "Wed, 21 Jul 1999 11:39:41 +0100 (BST)" Message-ID: <87btd5aut4.fsf@pc-hrvoje.srce.hr> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: writes: > allow-deletion-of-last-visible-frame t > C-x 5 0 works when another frame is open in another workspace > > allow-deletion-of-last-visible-frame nil > C-x 5 0 _fails_ when another frame is open in another workspace > (Attempt to delete last or iconified frame) > The "X" (kill/close thing) button in the window title bar works Note that "X" will always work because it invokes the FORCE argument in delete-frame. Try pressing `C-h c' followed by the click on that "X". From owner-xemacs-beta@xemacs.org Thu Jul 22 05:55:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA00810 for xemacs-beta-out; Thu, 22 Jul 1999 05:55:45 -0400 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 FAA00807 for ; Thu, 22 Jul 1999 05:55:42 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 117FZZ-0000Rk-00 for ; Thu, 22 Jul 1999 11:55:29 +0200 To: XEmacs Beta List Subject: Re: tar-mode and crypt revisted References: <199907202321.QAA00128@mina.sr.hp.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: 22 Jul 1999 11:55:26 +0200 In-Reply-To: Darryl Okahata's message of "Tue, 20 Jul 1999 16:21:04 -0700" Message-ID: <873dyhau0h.fsf@pc-hrvoje.srce.hr> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Darryl Okahata writes: [...] > * When tar-mode.el is loaded, it overrides the definition of > "normal-mode" with it's own definition. I don't know if this will fix the bug, but I'm pretty sure the redefinition of normal-mode for tar purposes is no longer necessary. IIRC it redefined normal mode to catch tar files containing the -*- lines and prevent tar files being thrown to the wrong mode. This is now handled with the `inhibit-first-line-modes-regexps' variable. So: try removing the code in tar-mode that overrides the `normal-mode' and see whether things work out for you. From owner-xemacs-beta@xemacs.org Thu Jul 22 05:56:30 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA00851 for xemacs-beta-out; Thu, 22 Jul 1999 05:56:30 -0400 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 FAA00843 for ; Thu, 22 Jul 1999 05:56:26 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 117FaS-0000Ro-00 for ; Thu, 22 Jul 1999 11:56:24 +0200 To: XEmacs Beta List Subject: Re: tar-mode and crypt revisted [ patch included ] References: <199907210037.RAA00606@mina.sr.hp.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: 22 Jul 1999 11:56:21 +0200 In-Reply-To: Jan Vroonhof's message of "21 Jul 1999 12:53:04 +0200" Message-ID: <87yag99fei.fsf@pc-hrvoje.srce.hr> Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Darryl Okahata writes: > > > > > * When tar-mode.el is loaded, it overrides the definition of > > "normal-mode" with it's own definition: tar-normal-mode. > > Ouch. The best fix would probably to get rid of this. Overriding basic > XEmacs functions is always bad. Yes. See my mail in the thread. > If there is some functionality missing built it into to XEmacs > proper. Except that it's not missing. :-) From owner-xemacs-beta@xemacs.org Thu Jul 22 06:45:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA02815 for xemacs-beta-out; Thu, 22 Jul 1999 06:45:38 -0400 Received: from ursa.cus.cam.ac.uk (ursa.cus.cam.ac.uk [131.111.8.6]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA02810 for ; Thu, 22 Jul 1999 06:45:37 -0400 Received: from ge204 (helo=localhost) by ursa.cus.cam.ac.uk with local-smtp (Exim 3.023 #2) id 117GM3-00079A-00; Thu, 22 Jul 1999 11:45:35 +0100 Date: Thu, 22 Jul 1999 11:45:35 +0100 (BST) From: Gunnar Evermann To: jsc@arsdigita.com cc: xemacs-beta@xemacs.org Subject: Re: reproducible crash in 21.1.4 in tcl-mode In-Reply-To: <14230.57143.803620.827830@jschoi.ne.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Thu, 22 Jul 1999 jsc@arsdigita.com wrote: > I've got a reproducible crash running XEmacs 21.1.4 under Solaris 2.6 > compiled with gcc. tcl-mode version is 1.50. [snip] > Lisp backtrace: > skip-syntax-backward("/\\") from the PROBLEMS file: ----- *** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures without also using `-fno-schedule-insns'. gcc will generate incorrect code otherwise, typically resulting in crashes in the function skip-syntax-backward. ----- we thought we had a workaround for this in 21.1. but obviously that does not always work. I think version of egcs starting with 1.1 are OK. So the best solution is to upgrade to gcc2.95 (is that officially out yet?) and to rebuild. Gunnar From owner-xemacs-beta@xemacs.org Thu Jul 22 10:07:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA08540 for xemacs-beta-out; Thu, 22 Jul 1999 10:07:31 -0400 Received: from kanatek.ca (kan-ott.kanatek.ca [209.167.117.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA08536 for ; Thu, 22 Jul 1999 10:07:30 -0400 Received: (from sam@localhost) by kanatek.ca (8.8.7/8.8.7) id KAA01216; Thu, 22 Jul 1999 10:06:05 -0400 From: Sean MacLennan Message-ID: <14231.9549.367531.194191@gargle.gargle.HOWL> Date: Thu, 22 Jul 1999 10:06:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: xemacs-beta@xemacs.org Subject: Re: Icons In-Reply-To: <006d01bed340$07b01320$fb702299@trcinc.com> References: <006d01bed340$07b01320$fb702299@trcinc.com> X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Ben, I *really* thought this was added to the packages :-< The color and next icons are uncaptioned. Therefore you must turn off captioning to see them. The following line does this: (set-specifier toolbar-buttons-captioned-p nil) You should set this just before calling init-fancy-toolbar. I do not know why they would come on in a new frame. Sean -- |-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-| PIKA Technologies Inc. http://www.pika.ca 155 Terence Matthews Cr e-mail Sean.MacLennan@pika.ca Kanata, Ont, K2M 2A8 Phone (613) 591 1555 Canada Fax (613) 591 9295 |-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-| From owner-xemacs-beta@xemacs.org Thu Jul 22 12:02:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA14189 for xemacs-beta-out; Thu, 22 Jul 1999 12:02:51 -0400 Received: from mail.eai-delta.de (mail.delta-ii.de [195.180.229.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA14186 for ; Thu, 22 Jul 1999 12:02:47 -0400 Received: by mail.eai-delta.de (Smail3.2.0.105/mail.eai-delta.de) via Delta-II from KEATS.eai-delta.de with smtp for mail.xemacs.org id m117LIz-001nt1C; Thu, 22 Jul 1999 18:02:45 +0200 (CEST) To: XEmacs Beta List Subject: Pb: latest CVS sources on NT w/ Mule Mail-Copies-To: never X-Attribution: lykos X-URL: http://www.eai-delta.de X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R:lt{Y/s1g[= 5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 22 Jul 1999 18:02:48 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi, I guess this has got something to do with the changes Steve made today ... I get the following error mule-ccl.obj : error LNK2005: _Qccl_program already defined in mule-charset.obj norbert. From owner-xemacs-beta@xemacs.org Thu Jul 22 16:12:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA25499 for xemacs-beta-out; Thu, 22 Jul 1999 16:12:29 -0400 Received: from www.sejong.org ([168.126.160.2]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id QAA25485; Thu, 22 Jul 1999 16:12:06 -0400 From: superalliance@mailman.zzn.com Received: from bulkserver by www.sejong.org (SMI-8.6/SMI-SVR4) id FAA03443; Fri, 23 Jul 1999 05:04:20 +0900 Date: Fri, 23 Jul 1999 05:04:20 +0900 Message-Id: <199907222004.FAA03443@www.sejong.org> To: superalliance@mailman.zzn.com Subject: MULTIPLE INCOME SOURCES! Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Looking for an outstanding business opportunity? Call 1-800-204-9616 Do you qualify? Is this for you? Can you afford it? This 15 minute pre-recorded message will tell you. Then - you decide. Low cost! Minimal time required! Call 1-800-204-9616 to see if you qualify. This is a 15 minute - no obligation recorded message. From owner-xemacs-beta@xemacs.org Thu Jul 22 16:56:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA27077 for xemacs-beta-out; Thu, 22 Jul 1999 16:56:32 -0400 Received: from www.sejong.org ([168.126.160.2]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id QAA27066; Thu, 22 Jul 1999 16:56:25 -0400 From: mailmachine@stones.com Received: from bulkserver by www.sejong.org (SMI-8.6/SMI-SVR4) id FAA04502; Fri, 23 Jul 1999 05:52:13 +0900 Date: Fri, 23 Jul 1999 05:52:13 +0900 Message-Id: <199907222052.FAA04502@www.sejong.org> To: mailmachine@stones.com Subject: Bulk Email WITHOUT The Spam!! Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: ADVERTISE YOUR PRODUCT TO THOUSANDS! NO SPECIAL BULK EMAIL SOFTWARE REQUIRED! SEND EMAIL TO ONE ADDRESS, IT GETS SENT TO THOUSANDS OF OPT-IN SUBSCRIBERS! What does this mean to you? Simple. No more spending HUNDREDS of dollars on expensive software, and no more getting shut down by your ISP for "spamming"! Send your ad to our daily updated list of over 1000 opt-in subscribers! Opt-in means the people on our lists have REQUESTED to get email ads from people just like you! These are EAGER recipients to your ad!! You also recieve OVER $500 in FREE bonuses!! Bulk email software, search engine and FFA submission software, free faxing, free classified ad submission software, and SO MUCH MORE we cant even mention it all here!! ITS AWESOME!! Membership is JUST $39 A YEAR...NO EXTRA FEES EVER!!! (Yes, we are for real. We have been in business since October 1997 with a very satisfied customer base growing daily!) For more information, reply to this email with "INFO" in the subject and we will send you all the details! From owner-xemacs-beta@xemacs.org Thu Jul 22 17:31:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA28993 for xemacs-beta-out; Thu, 22 Jul 1999 17:31:54 -0400 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 RAA28990 for ; Thu, 22 Jul 1999 17:31:53 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id OAA22084; Thu, 22 Jul 1999 14:33:39 -0700 To: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure 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: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Installation sez: sb> Compiling in DLL support. sb> but the configure option is --with-shlib/--without-shlib. sb> These need to match. Which one is the preferred name? I like `shlib' since I use Linux. `DLL' is a "Windows" term, isn't it? Or call it `dlopen', but maybe that's only the name of the lib that does that on Linux. From owner-xemacs-beta@xemacs.org Thu Jul 22 17:52:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA29634 for xemacs-beta-out; Thu, 22 Jul 1999 17:52:29 -0400 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 RAA29627 for ; Thu, 22 Jul 1999 17:52:25 -0400 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 RAA02976; Thu, 22 Jul 1999 17:58:18 -0400 (EDT) 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 XAA01489; Thu, 22 Jul 1999 23:52:17 +0200 (MET DST) To: xemacs-beta@xemacs.org, Jan Vroonhof Subject: Re: hm--html-menu fix for "fixed" psgml. 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 Jul 1999 23:50:06 +0200 In-Reply-To: Jan Vroonhof's message of "22 Jul 1999 21:09:00 +0200" Message-ID: Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> The latest XEmacs psgml package broke the hooking hack used by Jan> hm--html-minor-mode. This adds another hack that should also work in Jan> that case. Oops, I wasn't aware that hm--html-minor-mode hooks into PSGML. Thanks for the fix. broken-out-of-ignorance-ly yours, Adrian From owner-xemacs-beta@xemacs.org Thu Jul 22 18:23:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA30664 for xemacs-beta-out; Thu, 22 Jul 1999 18:23:01 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA30660 for ; Thu, 22 Jul 1999 18:22:59 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-40.kiva.net [206.97.75.105]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id PAA16948; Thu, 22 Jul 1999 15:21:41 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id RAA13795; Thu, 22 Jul 1999 17:22:30 -0500 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 19 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > >>>>> "sb" == SL Baur writes: > > sb> Installation sez: > sb> Compiling in DLL support. > > sb> but the configure option is --with-shlib/--without-shlib. > sb> These need to match. Which one is the preferred name? > > I like `shlib' since I use Linux. `DLL' is a "Windows" term, isn't > it? Or call it `dlopen', but maybe that's only the name of the lib > that does that on Linux. How about `DSO' like apache uses? Dynamic-Shared-Object Or go whole hog and spell the #%!@#%! thing out. :) -bp From owner-xemacs-beta@xemacs.org Fri Jul 23 00:44:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA20923 for xemacs-beta-out; Fri, 23 Jul 1999 00:44:01 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA20920 for ; Fri, 23 Jul 1999 00:43:58 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA29371 for ; Fri, 23 Jul 1999 13:43:55 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: reproducible crash in 21.1.4 in tcl-mode References: X-Attribution: sb From: SL Baur In-Reply-To: Gunnar Evermann's message of "Thu, 22 Jul 1999 11:45:35 +0100 (BST)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 23 Jul 1999 13:43:45 +0900 Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Gunnar Evermann writes in xemacs-beta@xemacs.org: > On Thu, 22 Jul 1999 jsc@arsdigita.com wrote: >> I've got a reproducible crash running XEmacs 21.1.4 under Solaris 2.6 >> compiled with gcc. tcl-mode version is 1.50. > [snip] >> Lisp backtrace: >> skip-syntax-backward("/\\") > from the PROBLEMS file: > ----- > *** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures > without also using `-fno-schedule-insns'. > gcc will generate incorrect code otherwise, typically resulting in > crashes in the function skip-syntax-backward. > ----- > we thought we had a workaround for this in 21.1. but obviously that does > not always work. > I think version of egcs starting with 1.1 are OK. So the best > solution is to upgrade to gcc2.95 (is that officially out yet?) > and to rebuild. egcs-1.1.2 (2.91.66) has this bug fixed. From owner-xemacs-beta@xemacs.org Fri Jul 23 00:48:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA21102 for xemacs-beta-out; Fri, 23 Jul 1999 00:48:28 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA21096 for ; Fri, 23 Jul 1999 00:48:24 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA29614 for ; Fri, 23 Jul 1999 13:48:21 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@crystal.WonderWorks.COM> <87g12hauu8.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "22 Jul 1999 11:37:35 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 23 Jul 1999 13:48:11 +0900 Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > SL Baur writes: >> I can't. What I cannot duplicate is Hrvoje's results with >> WindowMaker. Regardless of the value of >> `allow-deletion-of-last-visible-frame', I can C-x 5 0 a frame when >> another frame is open in another workspace, i.e. WindowMaker always >> does the Right Thing. > NB: What version of WindowMaker do you use? I posted one of the versions earlier. Both 0.60.0 on Solaris (compiled and linked against XFree86) and 0.20.1 on TurboLinux (how do I ask for the RPM version number?) are O.K. for me. > I use version 0.60.0, the one from Debian (0.60.0-4). Hmm. From owner-xemacs-beta@xemacs.org Fri Jul 23 04:37:07 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA27327 for xemacs-beta-out; Fri, 23 Jul 1999 04:37:07 -0400 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 EAA27323 for ; Fri, 23 Jul 1999 04:37:03 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA03658 for ; Fri, 23 Jul 1999 10:37:02 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000t1; Fri Jul 23 10:36:53 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA22088; Fri, 23 Jul 1999 10:36:52 +0200 To: xemacs-beta@xemacs.org Subject: Re: hm--html-menu fix for "fixed" psgml. References: From: Jan Vroonhof Date: 23 Jul 1999 10:36:51 +0200 In-Reply-To: Adrian Aichner's message of "22 Jul 1999 23:50:06 +0200" 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: Adrian Aichner writes: > Oops, I wasn't aware that hm--html-minor-mode hooks into PSGML. > > Thanks for the fix. > > broken-out-of-ignorance-ly yours, bad boy! Go add hm--html-minor-mode to your html-mode hook now :-) Jan From owner-xemacs-beta@xemacs.org Fri Jul 23 04:50:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA27898 for xemacs-beta-out; Fri, 23 Jul 1999 04:50:55 -0400 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 EAA27895 for ; Fri, 23 Jul 1999 04:50:54 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA04396 for ; Fri, 23 Jul 1999 10:50:53 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa0014Z; Fri Jul 23 10:50:44 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA22104; Fri, 23 Jul 1999 10:50:44 +0200 To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@crystal.WonderWorks.COM> <87g12hauu8.fsf@pc-hrvoje.srce.hr> From: Jan Vroonhof Date: 23 Jul 1999 10:50:44 +0200 In-Reply-To: SL Baur's message of "23 Jul 1999 13:48:11 +0900" 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: SL Baur writes: > > > I use version 0.60.0, the one from Debian (0.60.0-4). > FWIW I now use 0.60.0 just updated by source from the debian source package, and I see it too. Jan From owner-xemacs-beta@xemacs.org Fri Jul 23 05:04:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA28318 for xemacs-beta-out; Fri, 23 Jul 1999 05:04:22 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA28315 for ; Fri, 23 Jul 1999 05:04:16 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id SAA17576 for ; Fri, 23 Jul 1999 18:04:13 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: The plague is back: "Attempt to delete the sole visible or iconified frame" strikes again References: <14227.36750.708234.719126@crystal.WonderWorks.COM> <87g12hauu8.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "23 Jul 1999 10:50:44 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 23 Jul 1999 18:04:03 +0900 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: > SL Baur writes: >> >> > I use version 0.60.0, the one from Debian (0.60.0-4). >> > FWIW I now use 0.60.0 just updated by source from the debian source > package, and I see it too. O.K. I tried again with a build from the current XEmacs CVS and I now see the problem. As soon as I get the sources copied, I will try them against the older Linux version and try again. From owner-xemacs-beta@xemacs.org Fri Jul 23 05:38:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA29386 for xemacs-beta-out; Fri, 23 Jul 1999 05:38:02 -0400 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 FAA29383 for ; Fri, 23 Jul 1999 05:38:00 -0400 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 FAA06191 for ; Fri, 23 Jul 1999 05:43:55 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id LAA27088; Fri, 23 Jul 1999 11:37:54 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: M-x hm--html-minor-mode fails in 21.1.4, "i386-pc-win32" 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: 23 Jul 1999 11:35:40 +0200 Message-ID: Lines: 28 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Here's the backtrace. When I try loading hm--html-mode.el to get a better backtrace, that errs too. Regards, Adrian Signaling: (error "Invalid image-instantiator format" autodetect) check-valid-instantiator([autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"] image) canonicalize-spec-list([autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"] image) set-specifier(# fallback=((nil . ...)) 0x420c> [autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"] nil nil nil) set-glyph-property(# fallback=(...) 0x420c>0x420b> image [autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"] nil nil nil) set-glyph-image(# fallback=(...) 0x420c>0x420b> [autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"]) make-glyph([autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"] pointer) make-pointer-glyph([autodetect :data "c:\\Program Files\\XEmacs\\XEmacs-21.1.4\\etc\\idd\\drop"]) idd-make-drag-and-drop-pointer-glyph() command-execute(hm--html-minor-mode t) execute-extended-command(nil) call-interactively(execute-extended-command) -- Windows NT File Manager Help: To make sure that your files are secure, you should check their ownership regularly. From owner-xemacs-beta@xemacs.org Fri Jul 23 09:33:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA02858 for xemacs-beta-out; Fri, 23 Jul 1999 09:33:41 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA02853 for ; Fri, 23 Jul 1999 09:33:38 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 117fS7-0005q0-00 for xemacs-beta@xemacs.org; Fri, 23 Jul 1999 09:33:31 -0400 To: xemacs-beta@xemacs.org Subject: feature request Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 23 Jul 1999 09:33:31 -0400 Message-ID: Lines: 5 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: How many times has this happened to you? You notice you buffer is modified. Did you do it accidentally or was it intended (after all, xemacs has been running for the last month, so you don't remember). Wouldn't it be nice to be able to use ediff to show you what's changed? From owner-xemacs-beta@xemacs.org Fri Jul 23 09:56:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA03688 for xemacs-beta-out; Fri, 23 Jul 1999 09:56:21 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA03683 for ; Fri, 23 Jul 1999 09:56:18 -0400 Received: from metheny.enst.fr (Wu5tj2ISRRahOGiHaH/UrwmV6nR5Clba@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id PAA19432; Fri, 23 Jul 1999 15:56:17 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id PAA14013; Fri, 23 Jul 1999 15:56:13 +0200 (MET DST) To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: feature request 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: nbecker@fred.net's message of "23 Jul 1999 09:33:31 -0400" 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: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > Wouldn't it be nice to be able to use ediff to show you what's > changed? From when ? Last time it was saved ? You can diff the buffer yourself then. Or do you mean you'd like a visual history of what's changed since the last saving ? I guess you could do this by copying the buffer in several others with different degrees of undo's. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 23 10:15:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA04460 for xemacs-beta-out; Fri, 23 Jul 1999 10:15:34 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA04457 for ; Fri, 23 Jul 1999 10:15:33 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 117g6m-0005sr-00 for xemacs-beta@xemacs.org; Fri, 23 Jul 1999 10:15:32 -0400 To: xemacs-beta@xemacs.org Subject: Re: feature request References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 23 Jul 1999 10:15:32 -0400 In-Reply-To: Didier Verna's message of "23 Jul 1999 15:56:12 +0200" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> nbecker@fred.net writes: >> Wouldn't it be nice to be able to use ediff to show you what's >> changed? dv> From when ? Last time it was saved ? You can diff the buffer yourself dv> then. Or do you mean you'd like a visual history of what's changed since the dv> last saving ? I guess you could do this by copying the buffer in several dv> others with different degrees of undo's. I mean diff the buffer against the last saved version. Is there any convenient way to do this? From owner-xemacs-beta@xemacs.org Fri Jul 23 10:34:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05222 for xemacs-beta-out; Fri, 23 Jul 1999 10:34:56 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA05219 for ; Fri, 23 Jul 1999 10:34:54 -0400 Received: from metheny.enst.fr (h3fTfcz+fEQ1qOTkU7aFXnjbjjwtf4++@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id QAA21217; Fri, 23 Jul 1999 16:34:53 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id QAA14140; Fri, 23 Jul 1999 16:34:51 +0200 (MET DST) To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: feature request 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: nbecker@fred.net's message of "23 Jul 1999 10:15:32 -0400" 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: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > I mean diff the buffer against the last saved version. Is there any > convenient way to do this? It seems that you'd need to save the buffer first. The ability to diff directly the buffer against its file would probably be nice indeed. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 23 10:40:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05425 for xemacs-beta-out; Fri, 23 Jul 1999 10:40:14 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA05422 for ; Fri, 23 Jul 1999 10:40:12 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 117gUd-0005ui-00 for xemacs-beta@xemacs.org; Fri, 23 Jul 1999 10:40:11 -0400 To: xemacs-beta@xemacs.org Subject: Re: feature request References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 23 Jul 1999 10:40:11 -0400 In-Reply-To: Didier Verna's message of "23 Jul 1999 16:34:51 +0200" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> nbecker@fred.net writes: >> I mean diff the buffer against the last saved version. Is there any >> convenient way to do this? dv> It seems that you'd need to save the buffer first. The ability to diff dv> directly the buffer against its file would probably be nice indeed. Yes, but that's the problem. I don't want to save the file because I don't know if it's trashed. From owner-xemacs-beta@xemacs.org Fri Jul 23 10:57:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA06351 for xemacs-beta-out; Fri, 23 Jul 1999 10:57:49 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA06346 for ; Fri, 23 Jul 1999 10:57:46 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-33.kiva.net [206.97.75.98]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id HAA24114; Fri, 23 Jul 1999 07:56:29 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id JAA04420; Fri, 23 Jul 1999 09:57:19 -0500 To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: feature request References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 17 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > >>>>> "dv" == Didier Verna writes: > > dv> nbecker@fred.net writes: > >> I mean diff the buffer against the last saved version. Is there any > >> convenient way to do this? > > dv> It seems that you'd need to save the buffer first. The ability to diff > dv> directly the buffer against its file would probably be nice indeed. > > Yes, but that's the problem. I don't want to save the file because I > don't know if it's trashed. You could save it to a temp file and then diff the two with ediff. -Bill P. From owner-xemacs-beta@xemacs.org Fri Jul 23 11:11:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA06990 for xemacs-beta-out; Fri, 23 Jul 1999 11:11:27 -0400 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 LAA06981 for ; Fri, 23 Jul 1999 11:11:24 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA03799 for ; Fri, 23 Jul 1999 17:11:20 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000vL; Fri Jul 23 17:11:12 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA23127; Fri, 23 Jul 1999 17:11:12 +0200 To: xemacs-beta@xemacs.org Subject: Re: feature request References: From: Jan Vroonhof Date: 23 Jul 1999 17:11:11 +0200 In-Reply-To: nbecker@fred.net's message of "23 Jul 1999 10:40:11 -0400" 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: nbecker@fred.net writes: > Yes, but that's the problem. I don't want to save the file because I > don't know if it's trashed. Something like? C-x b file.orig RET C-x i file-name.orig RET M-x ediff-buffers RET Jan From owner-xemacs-beta@xemacs.org Fri Jul 23 11:25:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA07815 for xemacs-beta-out; Fri, 23 Jul 1999 11:25:52 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA07806 for ; Fri, 23 Jul 1999 11:25:46 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id KAA31483; Fri, 23 Jul 1999 10:25:40 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14232.35187.953884.719550@buffalo.fnal.gov> Date: Fri, 23 Jul 1999 10:25:39 -0500 (CDT) To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: feature request In-Reply-To: References: X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > >>>>> "dv" == Didier Verna writes: > > dv> nbecker@fred.net writes: > >> I mean diff the buffer against the last saved version. Is there any > >> convenient way to do this? > > dv> It seems that you'd need to save the buffer first. The ability to diff > dv> directly the buffer against its file would probably be nice indeed. > > Yes, but that's the problem. I don't want to save the file because I > don't know if it's trashed. I agree that this would be an excellent feature. I see 3 (well 4) ways of implementing such a thing: 1) Save the current buffer to some temp file, then use the ordinary diff tools. 2) Even though I don't see it in "man diff", it looks like diff will treat a file arg of "-" as meaning standard input. One could devise a way to get XEmacs to feed the contents of the current buffer to a diff subprocess. 3) Load the file into another window and use the "compare-windows" function. 4) Wait until one of the wizards on the list says, "You dummy, just type M-C-*&^ with a prefix arg..." ;-) From owner-xemacs-beta@xemacs.org Fri Jul 23 11:33:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA08249 for xemacs-beta-out; Fri, 23 Jul 1999 11:33:41 -0400 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 LAA08246 for ; Fri, 23 Jul 1999 11:33:39 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id IAA24938; Fri, 23 Jul 1999 08:35:26 -0700 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.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: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "wmperry" == wmperry writes: wmperry> karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: >> >>>>> "sb" == SL Baur writes: >> sb> Installation sez: Compiling in DLL support. >> sb> but the configure option is --with-shlib/--without-shlib. sb> These need to match. Which one is the preferred name? >> >> I like `shlib' since I use Linux. `DLL' is a "Windows" term, >> isn't it? Or call it `dlopen', but maybe that's only the name >> of the lib that does that on Linux. wmperry> How about `DSO' like apache uses? Dynamic-Shared-Object That's not bad. The "shared object" extension of `.so' could become `.dso' then, on Linux. Perhaps on 95/98/NT and other Unices as well? wmperry> Or go whole hog and spell the #%!@#%! thing out. :) I suppose for the `configure' switch, that would be appropriate. It makes it readable, like long lisp variable names. From owner-xemacs-beta@xemacs.org Fri Jul 23 12:14:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA10553 for xemacs-beta-out; Fri, 23 Jul 1999 12:14:54 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA10549 for ; Fri, 23 Jul 1999 12:14:53 -0400 Received: from metheny.enst.fr (AP/LxLcskgatNxkbGuraegiABW4Z+FF5@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id SAA25937 for ; Fri, 23 Jul 1999 18:14:52 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id SAA14384; Fri, 23 Jul 1999 18:14:48 +0200 (MET DST) To: XEmacs beta list Subject: GNU Emacs' rect.el 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 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: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm merging my changes into GNU Emacs' rect.el, and I found a function they use that we don't have: it's called `move-to-column-force' and it replaces multicolumn characters by spaces in order to move to the exact required column. Is it something that we want to do? If we don't, rectangles might get fucked up. If we do, we might loose characters. I'm personally not very much for that change, but I'd like to hear what you guys think. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 23 13:04:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA13241 for xemacs-beta-out; Fri, 23 Jul 1999 13:04:58 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA13237 for ; Fri, 23 Jul 1999 13:04:56 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-26.kiva.net [206.97.75.91]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id KAA26566; Fri, 23 Jul 1999 10:03:39 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id MAA00712; Fri, 23 Jul 1999 12:04:26 -0500 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.fsf@megalith.bp.aventail.com> <87so6f751f.fsf@bittersweet.sysc.pdx.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 36 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > >>>>> "wmperry" == wmperry writes: > > wmperry> karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > >> >>>>> "sb" == SL Baur writes: > >> > sb> Installation sez: Compiling in DLL support. > >> > sb> but the configure option is --with-shlib/--without-shlib. > sb> These need to match. Which one is the preferred name? > >> > >> I like `shlib' since I use Linux. `DLL' is a "Windows" term, > >> isn't it? Or call it `dlopen', but maybe that's only the name > >> of the lib that does that on Linux. > > wmperry> How about `DSO' like apache uses? Dynamic-Shared-Object > > That's not bad. The "shared object" extension of `.so' could become > `.dso' then, on Linux. Perhaps on 95/98/NT and other Unices as well? Yup - the extension doesn't matter at all. To make life easy for us here when we auto-discover modules, we use different extensions on all of our platforms for various types of shared objects. .cfm .mod .uga all work just dandy (even on windows :) > wmperry> Or go whole hog and spell the #%!@#%! thing out. :) > > I suppose for the `configure' switch, that would be appropriate. It > makes it readable, like long lisp variable names. --with-really-spiffy-but-dangerous-dyanmic-loaading-code=yes :) -bp From owner-xemacs-beta@xemacs.org Fri Jul 23 13:26:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA14103 for xemacs-beta-out; Fri, 23 Jul 1999 13:26:15 -0400 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 NAA14099 for ; Fri, 23 Jul 1999 13:26:13 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id KAA25359; Fri, 23 Jul 1999 10:28:00 -0700 To: wmperry@aventail.com Cc: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.fsf@megalith.bp.aventail.com> <87so6f751f.fsf@bittersweet.sysc.pdx.edu> <861zdz8fhh.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: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "wmperry" == wmperry writes: wmperry> --with-really-spiffy-but-dangerous-dyanmic-loaading-code=yes ^^ wmperry> :) Does the double `a' indicate that it's to be read like a boxing announcer doing the "in this corner" thing? From owner-xemacs-beta@xemacs.org Fri Jul 23 13:43:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA14715 for xemacs-beta-out; Fri, 23 Jul 1999 13:43:58 -0400 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 NAA14710 for ; Fri, 23 Jul 1999 13:43:55 -0400 Received: by crystal.WonderWorks.COM id QQgzde27467; Fri, 23 Jul 1999 10:43:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14232.43478.130482.377531@crystal.WonderWorks.COM> Date: Fri, 23 Jul 1999 10:43:49 -0700 (PDT) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: feature request In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: nbecker@fred.net writes: > How many times has this happened to you? You notice you buffer is > modified. Did you do it accidentally or was it intended (after all, > xemacs has been running for the last month, so you don't remember). > Wouldn't it be nice to be able to use ediff to show you what's > changed? Use C-x h to mark the buffer. Use ESC | diff - filename to show you the differences. I've never had to do this. I just use undo a couple of times, which is invariably enough to jog my memory. From owner-xemacs-beta@xemacs.org Fri Jul 23 13:48:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA14870 for xemacs-beta-out; Fri, 23 Jul 1999 13:48:48 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA14867 for ; Fri, 23 Jul 1999 13:48:46 -0400 From: wmperry@aventail.com Received: from megalith.bp.aventail.com (usrpri2-4.kiva.net [206.97.75.69]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id KAA27596; Fri, 23 Jul 1999 10:47:28 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id MAA01327; Fri, 23 Jul 1999 12:48:19 -0500 To: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) Cc: xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.fsf@megalith.bp.aventail.com> <87so6f751f.fsf@bittersweet.sysc.pdx.edu> <861zdz8fhh.fsf@megalith.bp.aventail.com> <87vhbb5l9b.fsf@bittersweet.sysc.pdx.edu> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 15 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > >>>>> "wmperry" == wmperry writes: > > wmperry> --with-really-spiffy-but-dangerous-dyanmic-loaading-code=yes > ^^ > wmperry> :) > > Does the double `a' indicate that it's to be read like a boxing > announcer doing the "in this corner" thing? Sure... we should ship a 'letsgetreadytorumble.(au|wav)' that we play when we finish running the configure script. :) -bp From owner-xemacs-beta@xemacs.org Fri Jul 23 14:01:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA15432 for xemacs-beta-out; Fri, 23 Jul 1999 14:01:52 -0400 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 OAA15427 for ; Fri, 23 Jul 1999 14:01:42 -0400 Received: by crystal.WonderWorks.COM id QQgzdg27779; Fri, 23 Jul 1999 11:01:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14232.44535.83734.769380@crystal.WonderWorks.COM> Date: Fri, 23 Jul 1999 11:01:26 -0700 (PDT) From: Kyle Jones To: XEmacs beta list Subject: GNU Emacs' rect.el In-Reply-To: References: X-Mailer: VM 6.72 under 21.2 (beta17) "Chiyoda" 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: Didier Verna writes: > > I'm merging my changes into GNU Emacs' rect.el, and I found a > function they use that we don't have: it's called > `move-to-column-force' and it replaces multicolumn characters > by spaces in order to move to the exact required column. > > Is it something that we want to do? Sounds like total crock to me. Rectangles are hopelessly broken across variable glyph sizes. I don't see how blowing away wide characters is a fix, unless you consider a lathe to be an acceptable solution for putting a square peg into a round hole. From owner-xemacs-beta@xemacs.org Fri Jul 23 14:32:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA16481 for xemacs-beta-out; Fri, 23 Jul 1999 14:32:34 -0400 Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA16473 for ; Fri, 23 Jul 1999 14:32:26 -0400 Received: from joplin.cs.ucsb.edu (joplin [128.111.49.134]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id LAA22606 for ; Fri, 23 Jul 1999 11:32:25 -0700 (PDT) Received: by joplin.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id LAA03318 for ; Fri, 23 Jul 1999 11:32:24 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: Re: hm--html-menu fix for "fixed" psgml. References: Reply-To: jerry@cs.ucsb.edu (Jerry James) Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: jerry@cs.ucsb.edu (Jerry James) Date: 23 Jul 1999 11:32:24 -0700 Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" X-Face: +5(Pfr,;N>q#6NT,Qi5^TQh-MaUnz#kGN~OW[CQj~RS+sIor( '_8K^f9u^Y#.N`>9oKN$\JpI Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof wrote: > Go add hm--html-minor-mode to your html-mode hook now :-) Would now be a good time to remind someone that html-mode-hook is not defvar'd anywhere, so that it has no docstring and isn't located by apropos unless you have already set it to something? I first reported this as a bug against 20.4, well over a year ago, and reported it again a couple of months ago. I would submit a patch, only I don't know which file to put the hook in. On the one hand, the run-hooks for html-mode-hook is located in sgml/sgml-mode.el, so it would make sense to put it there. On the other hand: - sgml/sgml-mode.el hasn't been customized; - sgml/sgml-mode.el also has the run-hooks for sgml-mode-hook, but that hook is defined in psgml/psgml.el. So, to follow form, maybe it ought to be in psgml/psgml-html.el. But on the gripping hand, I think the current situation with sgml-mode-hook is confusing and would hate to see html-mode-hook follow suit. -- Jerry James Email: jerry@cs.ucsb.edu WWW: http://www.cs.ucsb.edu/~jerry/ From owner-xemacs-beta@xemacs.org Fri Jul 23 14:55:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA17411 for xemacs-beta-out; Fri, 23 Jul 1999 14:55:56 -0400 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 OAA17401 for ; Fri, 23 Jul 1999 14:55:42 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 117kTq-00007Q-00 for ; Fri, 23 Jul 1999 20:55:38 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs' rect.el 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: 23 Jul 1999 20:55:37 +0200 In-Reply-To: Didier Verna's message of "23 Jul 1999 18:14:48 +0200" Message-ID: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> Lines: 9 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > I'm merging my changes into GNU Emacs' rect.el, and I found a > function they use that we don't have: it's called > `move-to-column-force' and it replaces multicolumn characters I've never really grokked the concept of "multicolumn characters". We already support proportional fonts. Shouldn't Japanese be treated the same as anything else? From owner-xemacs-beta@xemacs.org Fri Jul 23 15:23:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA18629 for xemacs-beta-out; Fri, 23 Jul 1999 15:23:02 -0400 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 PAA18623 for ; Fri, 23 Jul 1999 15:22:58 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id VAA19342 for ; Fri, 23 Jul 1999 21:22:52 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa004iC; Fri Jul 23 21:22:52 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id VAA23502; Fri, 23 Jul 1999 21:22:51 +0200 To: xemacs-beta@xemacs.org Subject: Re: hm--html-menu fix for "fixed" psgml. References: From: Jan Vroonhof Date: 23 Jul 1999 21:22:51 +0200 In-Reply-To: jerry@cs.ucsb.edu's message of "23 Jul 1999 11:32:24 -0700" 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: jerry@cs.ucsb.edu (Jerry James) writes: > a couple of months ago. I would submit a patch, only I don't know which > file to put the hook in. Good question. psgml-html defines the html-mode command. So that would still be the best place. Jan From owner-xemacs-beta@xemacs.org Sat Jul 24 10:37:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA11861 for xemacs-beta-out; Sat, 24 Jul 1999 10:37:58 -0400 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 KAA11857 for ; Sat, 24 Jul 1999 10:37:57 -0400 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 KAA29310 for ; Sat, 24 Jul 1999 10:43:53 -0400 (EDT) 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 QAA28221; Sat, 24 Jul 1999 16:37:49 +0200 (MET DST) To: XEmacs Beta List Subject: vc-revert-buffer1 sacrifices fontification preserving minor modes 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 Jul 1999 16:35:14 +0200 Message-ID: Lines: 49 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Both for RCS and CVS I use vc.el to perform version-control from within source buffers directly. Whenever I RCS-checkin or CVS-commit a file using C-x v v (vc-next-action) I loose fontification of that buffer. This also happens for C-x v u (vc-revert-buffer) I have (emacs-version) "XEmacs 21.1 (patch 4) \"Arches\" [Lucid] (i386-pc-win32) of Thu Jul 08 1999 on ZJ75T" and vc 1.18 Version Control for Free systems. I tracked this down to a specific argument `vc-revert-buffer1' supplies in its call to `revert-buffer'. It is true that it preserves minor modes (like footnote-mode) that way, but fontification is lost, although the modeline still says font-lock-mode is on. Only newly entered text is fontified. I tried calling (revert-buffer arg no-confirm nil) instead and this restores the fontification but looses the minor mode. To me this still seems the better alternative. --------------------------------- What is the correct fix for this? --------------------------------- Thanks, Adrian (defun vc-revert-buffer1 (&optional arg no-confirm) ;; Revert buffer, try to keep point and mark where user expects them in spite ;; of changes because of expanded version-control key words. ;; This is quite important since otherwise typeahead won't work as expected. (interactive "P") (widen) (let ((context (vc-buffer-context))) ;; t means don't call normal-mode; that's to preserve various minor modes. (revert-buffer arg no-confirm t) (vc-restore-buffer-context context))) -- NON DISPERDERE IL VETRO NELL'AMBIENTE From owner-xemacs-beta@xemacs.org Sat Jul 24 10:52:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA12218 for xemacs-beta-out; Sat, 24 Jul 1999 10:52:08 -0400 Received: from xiphias.pdc.kth.se (xiphias.pdc.kth.se [130.237.221.226]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA12212 for ; Sat, 24 Jul 1999 10:52:02 -0400 Received: (from jas@localhost) by xiphias.pdc.kth.se (8.8.5/8.8.5) id QAA20260; Sat, 24 Jul 1999 16:51:55 +0200 (METDST) To: Kyle Jones Cc: xemacs-beta@xemacs.org Subject: Re: pgnus commandeers emacs to check mail References: <8t6btd7ckdc.fsf@Corp.Sun.COM> <873dyii8do.fsf@pc-hrvoje.srce.hr> <8t6hfmylyys.fsf@Corp.Sun.COM> <19990721141020.A18339@nemesis.ncsl.nist.gov> <8t6emi1u4pe.fsf@Corp.Sun.COM> <14230.18669.388312.541056@crystal.WonderWorks.COM> In-Reply-To: Kyle Jones's message of "Wed, 21 Jul 1999 15:25:49 -0700 (PDT)" From: Simon Josefsson Mail-Copies-To: never Date: 24 Jul 1999 16:51:53 +0200 Message-ID: Lines: 32 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) 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: Kyle Jones writes: [threads in emacs] > :) There is still the question for which I still have not heard > a good answer--- Why do this? As this discussion came from the ding list, I take the natural example. Emacs lock up for a long time when Gnus enters a huge folder. If there were support at the language level to start a truly asynchronous thread Gnus could build the summary buffer in background and present it to the user when it's finished. Using callbacks in the "asynchronous" process filters a'la M-x man as has been suggested won't buy us nothing -- the elisp interpreter is still synchronous. I also agree with the opinion that adding thread support at the language level is easier than making applications take advantage of threads. But that's a poor excuse for not implementing threads at the language level. > I agree that we could save some memory with threading vs. multiple > processes, but memory is much cheaper than man hours. We'd have to > overhaul the Lisp system and all the applications to make them > mt-safe, and all without funding? I can't imagine it happening. Neither do I. The only chance I see this happening is a project re-targeting Emacs under Guile or some other language that already have thread support. I think thread support in itself has to little momentum to gather enough interest. From owner-xemacs-beta@xemacs.org Sat Jul 24 16:18:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA16827 for xemacs-beta-out; Sat, 24 Jul 1999 16:18:14 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA16823 for ; Sat, 24 Jul 1999 16:18:10 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id FAA21691 for ; Sun, 25 Jul 1999 05:18:07 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: GNU Emacs' rect.el References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "23 Jul 1999 20:55:37 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 25 Jul 1999 05:17:55 +0900 Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > I've never really grokked the concept of "multicolumn characters". We > already support proportional fonts. Shouldn't Japanese be treated the > same as anything else? It's not the same thing. Under normal settings, Japanese characters display twice as wide as Latin characters. This means that using a computation like (- (point) (point-at-bol)) to determine indentation is broken. From owner-xemacs-beta@xemacs.org Sun Jul 25 03:05:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA26844 for xemacs-beta-out; Sun, 25 Jul 1999 03:05:46 -0400 Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA26841 for ; Sun, 25 Jul 1999 03:05:44 -0400 Received: from sparrow.bear.com (user-2ive0fm.dialup.mindspring.com [165.247.1.246]) by smtp4.mindspring.com (8.8.5/8.8.5) with ESMTP id DAA09795; Sun, 25 Jul 1999 03:05:39 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id XAA09452; Sat, 24 Jul 1999 23:29:19 -0400 Date: Sun, 25 Jul 1999 03:29:19 +0000 ( ) From: Justin Vallon To: "Karl M. Hegbloom" cc: XEmacs Beta Subject: Re: Discrepancy between Installation and configure In-Reply-To: <87vhbb5l9b.fsf@bittersweet.sysc.pdx.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 23 Jul 1999, Karl M. Hegbloom wrote: > >>>>> "wmperry" == wmperry writes: > > wmperry> --with-really-spiffy-but-dangerous-dyanmic-loaading-code=yes > ^^ > wmperry> :) > > Does the double `a' indicate that it's to be read like a boxing > announcer doing the "in this corner" thing? No, this implies that you are allowed to double characters in long options, unless it conflicts with another option, in which case the doubling is illegal. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Sun Jul 25 09:22:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA31174 for xemacs-beta-out; Sun, 25 Jul 1999 09:22:50 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA31171 for ; Sun, 25 Jul 1999 09:22:48 -0400 Received: from metheny.enst.fr (u0gADd2O75Ey0Oh8gP4bAwlS0NkJkswM@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id PAA09547; Sun, 25 Jul 1999 15:22:05 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id PAA20127; Sun, 25 Jul 1999 15:21:59 +0200 (MET DST) To: Kyle Jones Cc: XEmacs beta list Subject: Re: GNU Emacs' rect.el References: <14232.44535.83734.769380@crystal.WonderWorks.COM> 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: Kyle Jones's message of "Fri, 23 Jul 1999 11:01:26 -0700 (PDT)" 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: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > Sounds like total crock to me. Rectangles are hopelessly broken > across variable glyph sizes. I don't see how blowing away > wide characters is a fix, unless you consider a lathe to be an > acceptable solution for putting a square peg into a round hole. In genuine english words, this pretty much summarizes my feeling too :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Sun Jul 25 22:41:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA12230 for xemacs-beta-out; Sun, 25 Jul 1999 22:41:48 -0400 Received: from nbecker.fred.net (nbecker.fred.net [208.238.64.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA12227 for ; Sun, 25 Jul 1999 22:41:46 -0400 Received: from neal by nbecker.fred.net with local (Exim 1.90 #3) for xemacs-beta@xemacs.org id 118agr-0001Rx-00; Sun, 25 Jul 1999 22:40:33 -0400 To: xemacs-beta@xemacs.org Subject: patch very preliminary support for /dev/pts/ Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 25 Jul 1999 22:40:33 -0400 Message-ID: <87pv1gcevy.fsf@nbecker.fred.net> Lines: 43 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Here is a very quick patch that seems to work to support the new /dev/pts on linux glibc2.1. Obviously, better integration is needed. I suppose HAVE_GETPT needs to be added to autoconf. retrieving revision 1.11.2.5 diff -u -r1.11.2.5 process-unix.c --- process-unix.c 1998/12/29 10:54:27 1.11.2.5 +++ process-unix.c 1999/07/26 02:39:07 @@ -216,6 +216,23 @@ int fd; int c; +#ifdef LINUX +#define HAVE_GETPT +#endif + +#ifdef HAVE_GETPT +#define PTY_ITERATION +#define PTY_OPEN \ + { \ + int e; \ + fd = getpt(); \ + if (fd < 0) return fd; \ + if ((e = grantpt (fd)) < 0) return e; \ + if ((e = unlockpt (fd)) < 0) return e; \ + } +#define PTY_TTY_NAME_SPRINTF ptsname_r (fd, pty_name, sizeof (pty_name)); +#endif + #ifdef PTY_ITERATION PTY_ITERATION #else @@ -265,7 +282,7 @@ if (access (pty_name, 6) != 0) { close (fd); -#if !defined(IRIS) && !defined(__sgi) +#if !defined(IRIS) && !defined(__sgi) && !defined (HAVE_GETPT) continue; #else return -1; From owner-xemacs-beta@xemacs.org Mon Jul 26 00:40:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA14573 for xemacs-beta-out; Mon, 26 Jul 1999 00:40:21 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA14569 for ; Mon, 26 Jul 1999 00:40:18 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA28267 for ; Mon, 26 Jul 1999 13:40:10 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: hm--html-menu fix for "fixed" psgml. References: X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "23 Jul 1999 21:22:51 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 26 Jul 1999 13:39:57 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: > jerry@cs.ucsb.edu (Jerry James) writes: >> a couple of months ago. I would submit a patch, only I don't know which >> file to put the hook in. > Good question. psgml-html defines the html-mode command. So that > would still be the best place. sgml-mode-hook is defcustom'ed in psgml.el. psgml-html.el is probably O.K. Shouldn't psgml be running that hook? From owner-xemacs-beta@xemacs.org Mon Jul 26 00:55:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA14877 for xemacs-beta-out; Mon, 26 Jul 1999 00:55:36 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA14873 for ; Mon, 26 Jul 1999 00:55:32 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA27952 for ; Mon, 26 Jul 1999 13:33:48 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: patch very preliminary support for /dev/pts/ References: <87pv1gcevy.fsf@nbecker.fred.net> X-Attribution: sb From: SL Baur In-Reply-To: Neal Becker's message of "25 Jul 1999 22:40:33 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 26 Jul 1999 13:33:35 +0900 Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Neal Becker writes in xemacs-beta@xemacs.org: > Here is a very quick patch that seems to work to support the new > /dev/pts on linux glibc2.1. > Obviously, better integration is needed. I suppose HAVE_GETPT needs > to be added to autoconf. ... > +#ifdef LINUX > +#define HAVE_GETPT > +#endif Um, it's going to have be a tad smarter than this to get put in. Doesn't pts support require glibc 2.1 *and* a 2.2 kernel *and* being configured in? From owner-xemacs-beta@xemacs.org Mon Jul 26 00:57:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA14948 for xemacs-beta-out; Mon, 26 Jul 1999 00:57:27 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA14940; Mon, 26 Jul 1999 00:57:23 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA29264; Mon, 26 Jul 1999 13:57:19 +0900 (JST) Mail-Copies-To: never To: wmperry@aventail.com, xemacs-patches@xemacs.org Cc: karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom), xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.fsf@megalith.bp.aventail.com> <87so6f751f.fsf@bittersweet.sysc.pdx.edu> <861zdz8fhh.fsf@megalith.bp.aventail.com> X-Attribution: sb From: SL Baur In-Reply-To: wmperry@aventail.com's message of "23 Jul 1999 12:04:26 -0500" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 26 Jul 1999 13:57:06 +0900 Message-ID: Lines: 121 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: wmperry writes in xemacs-beta@xemacs.org: wmperry> How about `DSO' like apache uses? Dynamic-Shared-Object > karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: >> That's not bad. The "shared object" extension of `.so' could become >> `.dso' then, on Linux. Perhaps on 95/98/NT and other Unices as well? > Yup - the extension doesn't matter at all. To make life easy for us here > when we auto-discover modules, we use different extensions on all of our > platforms for various types of shared objects. .cfm .mod .uga all work > just dandy (even on windows :) wmperry> Or go whole hog and spell the #%!@#%! thing out. :) >> >> I suppose for the `configure' switch, that would be appropriate. It >> makes it readable, like long lisp variable names. > --with-really-spiffy-but-dangerous-dyanmic-loaading-code=yes On closer inspection, this option is also referred to in two other places by the name `modules' via --site-modules and --moduledir. Of the suggestions I like the DSO one the best, but since we're already using the modules name in installed directories [whacks the top of the computer monitor with a beer[1]] let's do both ... :-) 1999-07-26 SL Baur * configure.in: Rename --with-shlib to --with-modules for consistency with the other two options that use that name. * configure.usage (--with-modules): Document it. Index: configure.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v retrieving revision 1.111.2.36 diff -u -r1.111.2.36 configure.in --- configure.in 1999/07/22 07:32:39 1.111.2.36 +++ configure.in 1999/07/26 04:55:45 @@ -520,7 +520,7 @@ use_assertions | \ memory_usage_stats | \ with_clash_detection | \ - with_shlib | \ + with_modules | \ no_doc_file ) dnl Make sure the value given was either "yes" or "no". case "$val" in @@ -3616,12 +3616,12 @@ dnl autodetect dll support AC_CHECK_HEADERS(dlfcn.h, [have_dlfcn=yes AC_DEFINE(HAVE_DLFCN_H)]) -test -z "$with_shlib" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(dl, dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=dl; with_shlib=yes]) } -test -z "$with_shlib" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(c, _dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=; with_shlib=yes]) } -test -z "$with_shlib" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(c, dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=; with_shlib=yes]) } -test -z "$with_shlib" && { AC_CHECK_LIB(dld, shl_load, [ AC_DEFINE(HAVE_SHL_LOAD) DLL_LIB=dld; with_shlib=yes]) } -test -z "$with_shlib" && { AC_CHECK_LIB(dld, dld_init, [ AC_DEFINE(HAVE_DLD_INIT) DLL_LIB=dld; with_shlib=yes]) } -if test "$with_shlib" = "yes"; then +test -z "$with_modules" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(dl, dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=dl; with_modules=yes]) } +test -z "$with_modules" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(c, _dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=; with_modules=yes]) } +test -z "$with_modules" && test ! -z "$have_dlfcn" && { AC_CHECK_LIB(c, dlopen, [ AC_DEFINE(HAVE_DLOPEN) DLL_LIB=; with_modules=yes]) } +test -z "$with_modules" && { AC_CHECK_LIB(dld, shl_load, [ AC_DEFINE(HAVE_SHL_LOAD) DLL_LIB=dld; with_modules=yes]) } +test -z "$with_modules" && { AC_CHECK_LIB(dld, dld_init, [ AC_DEFINE(HAVE_DLD_INIT) DLL_LIB=dld; with_modules=yes]) } +if test "$with_modules" = "yes"; then XE_SHLIB_STUFF if test "$can_build_shared" = "yes"; then AC_DEFINE(HAVE_SHLIB) @@ -3632,7 +3632,7 @@ AC_CHECK_FUNCS(dlerror _dlerror) else AC_MSG_WARN(disabling shared library support) - with_shlib=no + with_modules=no fi fi @@ -4147,7 +4147,7 @@ athena ) echo " Using Athena dialog boxes." ;; athena3d ) echo " Using Athena-3d dialog boxes." ;; esac -test "$with_shlib" = "yes" && echo " Compiling in DLL support." +test "$with_modules" = "yes" && echo " Compiling in DSO module support." test "$with_clash_detection" = yes && \ echo " Clash detection will use \"$lockdir\" for locking files." echo " movemail will use \"$mail_locking\" for locking mail spool files." @@ -4190,7 +4190,7 @@ ac_output_files="${ac_output_files+$ac_output_files }$file" done ac_output_files="$ac_output_files src/paths.h lib-src/config.values" -if test "$with_shlib" = "yes"; then +if test "$with_modules" = "yes"; then ac_output_files="$ac_output_files lib-src/ellcc.h" fi Index: configure.usage =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/configure.usage,v retrieving revision 1.17.2.9 diff -u -r1.17.2.9 configure.usage --- configure.usage 1999/07/05 08:20:29 1.17.2.9 +++ configure.usage 1999/07/26 04:55:21 @@ -136,6 +136,8 @@ --mail-locking=TYPE (*) Specify the locking to be used by movemail to prevent concurrent updates of mail spool files. Valid types are `lockf', `flock', and `file'. +--with-modules Compile in experimental support for dynamically + loaded libraries (Dynamic Shared Objects). --with-site-lisp=yes Allow for a site-lisp directory in the XEmacs hierarchy searched before the installation packages. --with-site-modules=no Disable site-modules directory in the XEmacs hierarchy, Footnotes: [1] For those not acquainted with American television, there was a series of beer commercials in the early 90's that featured people at a bar arguing over which sport to watch on T.V. The dispute was resolved by someone hitting the top of the T.V. with a bottle of beer whereby the sports were combined. My favorite was Football/Golf -- sink your putt and race to the tee before you get tackled ... :-) From owner-xemacs-beta@xemacs.org Mon Jul 26 04:55:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA21134 for xemacs-beta-out; Mon, 26 Jul 1999 04:55:28 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA21128 for ; Mon, 26 Jul 1999 04:55:17 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id RAA13945 for ; Mon, 26 Jul 1999 17:40:11 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: gutter-items loses again X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 26 Jul 1999 17:39:56 +0900 Message-ID: Lines: 153 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: gutter-items.el is initializing itself too early. This code probably belongs on the `window-setup-hook', it definitely should not be executed when dumping. A proposed patch is attached. (The void function problem is a totally separate issue and unrelated to gutter-items.el itself). Loading gutter-items.el...*** Error in XEmacs initialization (void-function buffers-menu-omit-invisible-buffers) *** Backtrace really-early-error-handler((void-function buffers-menu-omit-invisible-buffers)) buffers-menu-omit-invisible-buffers(#) funcall(buffers-menu-omit-invisible-buffers #) (not (funcall cl-if (cl-check-key ...))) ) (eq (not (funcall cl-if ...)) cl-if-not) ) (cond (cl-test (eq ... cl-test-not)) (cl-if (eq ... cl-if-not)) (t (if ... ... ...))) ) (cl-check-test-nokey cl-item (cl-check-key (car cl-seq))) ) (cl-check-test cl-item (car cl-seq)) ) (and cl-seq (> cl-end 0) (cl-check-test cl-item (car cl-seq)) (setq cl-end (1- cl-end) cl-seq (cdr cl-seq)) (> (setq cl-count ...) 0)) ) (while (and cl-seq (> cl-end 0) (cl-check-test cl-item ...) (setq cl-end ... cl-seq ...) (> ... 0))) ) (progn (while (and cl-seq ... ... ... ...)) (setq cl-end (1- cl-end))) ) (if (= cl-start 0) (progn (while ...) (setq cl-end ...)) (setq cl-start (1- cl-start))) ) (if (and cl-from-end (< cl-count 4000000)) (let (cl-i) (while ... ... ...) cl-seq) (setq cl-end (- ... cl-start)) (if (= cl-start 0) (progn ... ...) (setq cl-start ...)) (if (and ... ...) (let ... ...)) cl-seq) ) (if (listp cl-seq) (if (and cl-from-end ...) (let ... ... cl-seq) (setq cl-end ...) (if ... ... ...) (if ... ...) cl-seq) (apply (quote remove*) cl-item cl-seq cl-keys)) ) (if (<= (or cl-count ...) 0) cl-seq (if (listp cl-seq) (if ... ... ... ... ... cl-seq) (apply ... cl-item cl-seq cl-keys))) ) # bind (cl-end cl-start cl-from-end cl-count cl-if-not cl-if cl-key cl-test-not cl-test) (let* ((cl-test ...) (cl-test-not ...) (cl-key ...) (cl-if ...) (cl-if-not ...) (cl-count ...) (cl-from-end ...) (cl-start ...) (cl-end ...)) (let (...) (while cl-keys-temp ... ...)) (if (<= ... 0) cl-seq (if ... ... ...))) ) (cl-parsing-keywords (:test :test-not :key :if :if-not :count :from-end (:start 0) :end) nil (if (<= ... 0) cl-seq (if ... ... ...))) ) # bind (cl-keys cl-seq cl-item) delete*(nil (# # # # #) :if buffers-menu-omit-invisible-buffers) apply(delete* nil (# # # # #) :if buffers-menu-omit-invisible-buffers nil) # bind (cl-keys cl-list cl-pred) delete-if(buffers-menu-omit-invisible-buffers (# # # # #)) (let ((buffers ...)) (and (integerp buffers-tab-max-size) (> buffers-tab-max-size 1) (> ... buffers-tab-max-size) (setcdr ... nil)) (setq buffers (build-buffers-tab-internal buffers)) buffers) ) buffers-tab-items() (list :items (buffers-tab-items)) ) (vector (quote tab-control) :descriptor "Buffers" :properties (list :items (buffers-tab-items))) ) (make-glyph (vector (quote tab-control) :descriptor "Buffers" :properties (list :items ...))) ) (setq gutter-buffers-tab (make-glyph (vector ... :descriptor "Buffers" :properties ...))) ) (set-extent-begin-glyph (make-extent 0 0 gutter-string) (setq gutter-buffers-tab (make-glyph ...))) ) # bind (gutter-string) (let ((gutter-string "")) (set-extent-begin-glyph (make-extent 0 0 gutter-string) (setq gutter-buffers-tab ...)) (set-specifier default-gutter-border-width 0 (quote global) (quote mswindows)) (set-specifier default-gutter gutter-string (quote global) (quote mswindows))) ) add-tab-to-gutter() # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("/usr/local/infodock/infodock/build/sparc-sun-solaris/lisp/gutter-items.el" nil nil nil undecided) (if (or (<= ... 0) (null ...)) (and (null noerror) (signal ... ...)) (load-internal file noerror nomessage nosuffix (let ... ...))) ) (if handler (funcall handler (quote load) filename noerror nomessage nosuffix) (if (or ... ...) (and ... ...) (load-internal file noerror nomessage nosuffix ...))) ) # bind (path handler filename) (let* ((filename ...) (handler ...) (path nil)) (if handler (funcall handler ... filename noerror nomessage nosuffix) (if ... ... ...))) ) # bind (nosuffix nomessage noerror file) load("/usr/local/infodock/infodock/build/sparc-sun-solaris/lisp/gutter-items.el") (prog1 (load full-path) (garbage-collect)) ) (if full-path (prog1 (load full-path) (garbage-collect)) (external-debugging-output (format "\nLoad file %s: not found\n" file)) nil) ) # bind (full-path) (let ((full-path ...)) (if full-path (prog1 ... ...) (external-debugging-output ...) nil)) ) # bind (file) pureload("gutter-items") (if (pureload file) nil (external-debugging-output "Fatal error during load, aborting") (kill-emacs 1)) ) (unless (pureload file) (external-debugging-output "Fatal error during load, aborting") (kill-emacs 1)) ) (while (setq file (car files)) (unless (pureload file) (external-debugging-output "Fatal error during load, aborting") (kill-emacs 1)) (setq files (cdr files))) ) # bind (file files) (let ((files preloaded-file-list) file) (while (setq file ...) (unless ... ... ...) (setq files ...)) (when (not ...) (defun toolbar-button-p ... "No toolbar support." nil) (defun toolbar-specifier-p ... "No toolbar support." nil)) (fmakunbound (quote pureload))) ) (lambda nil (setq Installation-string (save-current-buffer ... ... ... ... ...)) (setq load-path (split-path ...)) (setq module-load-path (split-path ...)) (external-debugging-output (format "\nUsing load-path %s" load-path)) (external-debugging-output (format "\nUsing module-load-path %s" module-load-path)) (buffer-disable-undo (get-buffer "*scratch*")) (load "very-early-lisp" nil t) (let (...) (setq load-path ...)) (setq load-warn-when-source-newer t load-warn-when-source-only t) (defun pureload (file) (let ... ...)) (load (expand-file-name "../lisp/dumped-lisp.el")) (let (... file) (while ... ... ...) (when ... ... ...) (fmakunbound ...)) (packages-load-package-dumped-lisps late-package-load-path))() # (unwind-protect ...) call-with-condition-handler(really-early-error-handler (lambda nil (setq Installation-string (save-current-buffer ... ... ... ... ...)) (setq load-path (split-path ...)) (setq module-load-path (split-path ...)) (external-debugging-output (format "\nUsing load-path %s" load-path)) (external-debugging-output (format "\nUsing module-load-path %s" module-load-path)) (buffer-disable-undo (get-buffer "*scratch*")) (load "very-early-lisp" nil t) (let (...) (setq load-path ...)) (setq load-warn-when-source-newer t load-warn-when-source-only t) (defun pureload (file) (let ... ...)) (load (expand-file-name "../lisp/dumped-lisp.el")) (let (... file) (while ... ... ...) (when ... ... ...) (fmakunbound ...)) (packages-load-package-dumped-lisps late-package-load-path))) # bind (gc-cons-threshold) (let ((gc-cons-threshold 30000)) (call-with-condition-handler (quote really-early-error-handler) (function ...)) (setq preloaded-file-list (mapcar ... preloaded-file-list)) (setq load-warn-when-source-newer t load-warn-when-source-only nil) (setq debugger (quote debug)) (when (member "no-site-file" command-line-args) (setq site-start-file nil)) (when (load "site-load" t) (garbage-collect)) (when purify-flag (message "Finding pointers to doc strings...") (Snarf-documentation "DOC") (message "Finding pointers to doc strings...done") (Verify-documentation)) (when (stringp site-start-file) (load "site-init" t)) (setq current-load-list nil) (garbage-collect) (buffer-enable-undo "*scratch*")) ) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load("loadup.el") # bind (purify-flag load-ignore-elc-files) (let ((load-ignore-elc-files t) (purify-flag nil)) (load "loadup.el")) ) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load("loadup-el.el") (progn (setq command-line-args (append ... update-elc-files-to-compile)) (load "loadup-el.el")) ) (if update-elc-files-to-compile (progn (setq command-line-args ...) (load "loadup-el.el")) ( script done on Mon Jul 26 16:46:17 1999 1999-07-26 SL Baur * gutter-items.el (window-setup-hook): Move initialization here. Index: lisp/gutter-items.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/Attic/gutter-items.el,v retrieving revision 1.1.2.4 diff -u -r1.1.2.4 gutter-items.el --- lisp/gutter-items.el 1999/07/25 19:16:44 1.1.2.4 +++ lisp/gutter-items.el 1999/07/26 08:38:32 @@ -152,7 +152,7 @@ (resize-subwindow (glyph-image-instance gutter-buffers-tab) (gutter-pixel-width) nil))) -(add-tab-to-gutter) +(add-hook 'window-setup-hook 'add-tab-to-gutter) (add-hook 'switch-to-buffer-hooks 'update-tab-in-gutter) (add-hook 'create-frame-hook 'update-tab-in-gutter) From owner-xemacs-beta@xemacs.org Mon Jul 26 10:28:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA28421 for xemacs-beta-out; Mon, 26 Jul 1999 10:28:42 -0400 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 KAA28417 for ; Mon, 26 Jul 1999 10:28:39 -0400 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 KAA12055 for ; Mon, 26 Jul 1999 10:34:32 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id QAA19364; Mon, 26 Jul 1999 16:28:28 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 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: 26 Jul 1999 16:24:10 +0200 In-Reply-To: Didier Verna's message of "26 Jul 1999 16:02:25 +0200" Message-ID: Lines: 44 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "dv" == Didier Verna writes: dv> Adrian Aichner writes: >> How about this patch against >> xemacs-packages\prog\vc\vc.el? >> >> It preserves minor modes AND does not lose fontification of buffer. dv> (I don't use vc) It seems that you blindly call The good thing about vc.el is that I have one frontend for both RCS and CVS. For CVS I don't need to run cvs-examine to get a *cvs* buffer to commit changes from there. dv> font-lock-fontify-buffer. But what makes you think dv> people always have (and will want) fontification ? Currently vc-revert-buffer1 is plain broken, because it looses fontification of font-locked buffers. How about this patch instead? Index: vc.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-packages/prog/vc/vc.el,v retrieving revision 1.8 diff -u -u -r1.8 vc.el --- vc.el 1999/07/09 07:51:48 1.8 +++ vc.el 1999/07/26 14:25:03 @@ -718,6 +718,10 @@ (let ((context (vc-buffer-context))) ;; t means don't call normal-mode; that's to preserve various minor modes. (revert-buffer arg no-confirm t) + ;; Since we preserve-modes above, we have to fontify the buffer + ;; ourselves, when font-lock-mode is on. + (if font-lock-mode + (font-lock-fontify-buffer)) (vc-restore-buffer-context context))) Regards, Adrian From owner-xemacs-beta@xemacs.org Mon Jul 26 11:34:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA31407 for xemacs-beta-out; Mon, 26 Jul 1999 11:34:02 -0400 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 LAA31401 for ; Mon, 26 Jul 1999 11:34:00 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA09048 for ; Mon, 26 Jul 1999 17:33:56 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002DM; Mon Jul 26 17:33:48 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA29018; Mon, 26 Jul 1999 17:33:48 +0200 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: From: Jan Vroonhof Date: 26 Jul 1999 17:33:48 +0200 In-Reply-To: Adrian Aichner's message of "26 Jul 1999 16:24:10 +0200" 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: Adrian Aichner writes: > Currently vc-revert-buffer1 is plain broken, because it looses > fontification of font-locked buffers. No it isn't :-) Something is wrong with font-lock and insert-file-contents on your side. Jan From owner-xemacs-beta@xemacs.org Mon Jul 26 11:54:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA00366 for xemacs-beta-out; Mon, 26 Jul 1999 11:54:39 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA00362 for ; Mon, 26 Jul 1999 11:54:36 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 118n5C-0002Mr-00 for xemacs-beta@xemacs.org; Mon, 26 Jul 1999 11:54:30 -0400 To: xemacs-beta@xemacs.org Subject: Re: patch very preliminary support for /dev/pts/ References: <87pv1gcevy.fsf@nbecker.fred.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 26 Jul 1999 11:54:30 -0400 In-Reply-To: SL Baur's message of "26 Jul 1999 13:33:35 +0900" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: News flash! It seems only checking for glibc-2.1 is needed. According to another email I received the code I contributed will work on any glibc-2.1, regardless of kernel support for pty98. Maybe someone who has non-pty98 system can check that my patch is OK? > >>>>> "Franz" == Franz Sirl writes: [...] > Yes, I just checked the code. If it cannot open /dev/ptmx it falls back > back to the old /dev/ptyXY stuff. From owner-xemacs-beta@xemacs.org Mon Jul 26 11:55:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA00410 for xemacs-beta-out; Mon, 26 Jul 1999 11:55:27 -0400 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 LAA00404; Mon, 26 Jul 1999 11:55:22 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id IAA00709; Mon, 26 Jul 1999 08:55:05 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-209.beasys.com [192.168.11.209]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id IAA18948; Mon, 26 Jul 1999 08:55:02 -0700 (PDT) Message-Id: <3.0.5.32.19990726165530.00a1a4f0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 26 Jul 1999 16:55:30 +0100 To: SL Baur , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: gutter-items loses again 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: Oops. At 05:39 PM 7/26/99 +0900, SL Baur wrote: >gutter-items.el is initializing itself too early. This code probably >belongs on the `window-setup-hook', it definitely should not be >executed when dumping. A proposed patch is attached. (The void I'd like to undestand why this is the case, although for the sake of 21.2.19 you probably better just go ahead and commit it. What specifically in gutter initialisation is too early? It works for me :) >function problem is a totally separate issue and unrelated to >gutter-items.el itself). > >-(add-tab-to-gutter) >+(add-hook 'window-setup-hook 'add-tab-to-gutter) > (add-hook 'switch-to-buffer-hooks 'update-tab-in-gutter) > (add-hook 'create-frame-hook 'update-tab-in-gutter) I don't have a problem with this - I think this is the same stage that the toolbar gets initialized. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Mon Jul 26 12:52:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA03822 for xemacs-beta-out; Mon, 26 Jul 1999 12:52:05 -0400 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 MAA03816 for ; Mon, 26 Jul 1999 12:52:02 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 118nyl-00008h-00 for ; Mon, 26 Jul 1999 18:51:55 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs' rect.el References: <87u2qvmc0m.fsf@pc-hrvoje.srce.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: 26 Jul 1999 18:51:55 +0200 In-Reply-To: SL Baur's message of "25 Jul 1999 05:17:55 +0900" Message-ID: <87wvvngxqs.fsf@pc-hrvoje.srce.hr> Lines: 23 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > > > I've never really grokked the concept of "multicolumn characters". We > > already support proportional fonts. Shouldn't Japanese be treated the > > same as anything else? > > It's not the same thing. Under normal settings, Japanese characters > display twice as wide as Latin characters. The question is: which Latin characters? What are "normal settings" to you? Does this mean that when I change my font (as I do, because the default one is awful), the twice-as-wide relationship gets lost? I still see no reason to treat the Japanese glyphs as any different than other variable-width glyphs. > This means that using a computation like (- (point) (point-at-bol)) > to determine indentation is broken. That computation is broken in the world of variable-width characters anyway. From owner-xemacs-beta@xemacs.org Mon Jul 26 15:00:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA08616 for xemacs-beta-out; Mon, 26 Jul 1999 15:00:29 -0400 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 PAA08611 for ; Mon, 26 Jul 1999 15:00:24 -0400 Received: (from galibert@localhost) by nemesis.ncsl.nist.gov (8.9.3/8.8.7) id PAA21807 for xemacs-beta@xemacs.org; Mon, 26 Jul 1999 15:00:19 -0400 Date: Mon, 26 Jul 1999 15:00:19 -0400 From: Olivier Galibert To: XEmacs Beta List Subject: Re: GNU Emacs' rect.el Message-ID: <19990726150019.A21791@nemesis.ncsl.nist.gov> Mail-Followup-To: XEmacs Beta List References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> <87wvvngxqs.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: <87wvvngxqs.fsf@pc-hrvoje.srce.hr>; from Hrvoje Niksic on Mon, Jul 26, 1999 at 06:51:55PM +0200 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Mon, Jul 26, 1999 at 06:51:55PM +0200, Hrvoje Niksic wrote: > That computation is broken in the world of variable-width characters > anyway. That computation is valid in the fixed-width characters, tty world, and nowhere else. OG. From owner-xemacs-beta@xemacs.org Mon Jul 26 15:02:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA08722 for xemacs-beta-out; Mon, 26 Jul 1999 15:02:42 -0400 Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA08713; Mon, 26 Jul 1999 15:02:40 -0400 Received: from amazon.cs.ucsb.edu (amazon [128.111.44.158]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with SMTP id MAA29026; Mon, 26 Jul 1999 12:02:38 -0700 (PDT) Received: by amazon.cs.ucsb.edu (950413.SGI.8.6.12/951211.SGI) id MAA04055; Mon, 26 Jul 1999 12:02:33 -0700 To: xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: Re: hm--html-menu fix for "fixed" psgml. References: Reply-To: jerry@cs.ucsb.edu (Jerry James) Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: jerry@cs.ucsb.edu (Jerry James) Date: 26 Jul 1999 12:02:32 -0700 Message-ID: Lines: 42 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" X-Face: +5(Pfr,;N>q#6NT,Qi5^TQh-MaUnz#kGN~OW[CQj~RS+sIor( '_8K^f9u^Y#.N`>9oKN$\JpI Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote: > Jan Vroonhof writes in xemacs-beta@xemacs.org: > > > jerry@cs.ucsb.edu (Jerry James) writes: > >> a couple of months ago. I would submit a patch, only I don't know which > >> file to put the hook in. > > > Good question. psgml-html defines the html-mode command. So that > > would still be the best place. > > sgml-mode-hook is defcustom'ed in psgml.el. psgml-html.el is probably > O.K. Shouldn't psgml be running that hook? Oops, my mistake. The sgml-mode-hook is also run by sgml-mode in psgml.el. So here's a patch against psgml-html.el. Note, however, that there is no run-hooks for html-mode-hook in the psgml package. There is one in sgml/sgml-mode.el, which seems odd to me, but maybe that's just me. 1999-07-26 Jerry James * psgml-html.el: Define html-mode-hook. --- psgml/psgml-html.el.ORIG Mon Jul 12 22:16:58 1999 +++ psgml/psgml-html.el Mon Jul 26 11:55:47 1999 @@ -56,6 +56,11 @@ :group 'html :group 'psgml) +(defcustom html-mode-hook nil + "A hook or list of hooks to be run when entering html-mode" + :type 'hook + :group 'html) + ;; Set this to be whatever signature you want on the bottom of your pages. (defcustom html-helper-address-string (concat "" -- Jerry James Email: jerry@cs.ucsb.edu WWW: http://www.cs.ucsb.edu/~jerry/ From owner-xemacs-beta@xemacs.org Mon Jul 26 15:23:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA09608 for xemacs-beta-out; Mon, 26 Jul 1999 15:23:44 -0400 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 PAA09598; Mon, 26 Jul 1999 15:23:42 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id MAA20996; Mon, 26 Jul 1999 12:25:34 -0700 To: wmperry@aventail.com Cc: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Discrepancy between Installation and configure References: <87lnc8e5e4.fsf@bittersweet.sysc.pdx.edu> <86pv1kiau1.fsf@megalith.bp.aventail.com> <87so6f751f.fsf@bittersweet.sysc.pdx.edu> <861zdz8fhh.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: 33 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Chiyoda" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> wmperry writes in sb> xemacs-beta@xemacs.org: wmperry> How about `DSO' like apache uses? Dynamic-Shared-Object >> [...] sb> On closer inspection, this option is also referred to in two sb> other places by the name `modules' via --site-modules and sb> --moduledir. Of the suggestions I like the DSO one the best, sb> but since we're already using the modules name in installed sb> directories [whacks the top of the computer monitor with a sb> beer[1]] let's do both ... :-) Sounds great, says Karl. [Karl, who is learning to integrate debian packaging scripts with upstream sources using CVS, toasts toward computer monitor with coffee mug, then gets out of Gnus mode to go back to tapping out the CVS release management plan and some `make' files to do the work, with a texinfo document to boot from.)] sb> Footnotes: sb> [1] For those not acquainted with American television, there sb> was a sb> series of beer commercials in the early 90's that featured sb> people at a bar arguing over which sport to watch on T.V. The sb> dispute was resolved by someone hitting the top of the sb> T.V. with a bottle of beer whereby the sports were combined. sb> My favorite was Football/Golf -- sink your putt and race to sb> the tee before you get tackled ... :-) This is what I miss by not watching the right programs? (or maybe I'm not watching them right?) Hmmm. From owner-xemacs-beta@xemacs.org Mon Jul 26 19:19:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id TAA16332 for xemacs-beta-out; Mon, 26 Jul 1999 19:19:48 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id TAA16329 for ; Mon, 26 Jul 1999 19:19:45 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id TAA20147 for ; Mon, 26 Jul 1999 19:19:10 -0400 (EDT) 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 QAA08884 for ; Mon, 26 Jul 1999 16:18:45 -0700 (PDT) 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 QAA06594 for ; Mon, 26 Jul 1999 16:19:38 -0700 (PDT) Message-Id: <199907262319.QAA06594@mina.sr.hp.com> To: XEmacs Beta List Subject: GNU Emacs new isearch feature Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Mon_Jul_26_16:19:38_1999-1" Content-Transfer-Encoding: 7bit Date: Mon, 26 Jul 1999 16:19:38 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Mon_Jul_26_16:19:38_1999-1 Content-Type: text/plain; charset=US-ASCII Just FYI, The following just appeared via gnu-emacs-sources. It looks useful; anyone want to try adding this feature to XEmacs (if someone isn't already doing 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 Hewlett-Packard, or of the little green men that have been following him all day. --Multipart_Mon_Jul_26_16:19:38_1999-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="msg1" Content-Transfer-Encoding: quoted-printable From gnu-emacs-sources-request@gnu.org Mon Jul 26 15:36:22 1999 From: Bob Glickstein Date: Mon, 26 Jul 1999 15:17:24 -0700 (PDT) To: ehud@unix.simonwiesel.co.il Cc: gnu-emacs-sources@gnu.org, Dave Love , Martin Elh=F8j Andersen Subject: isearch-lazy-highlight (was Re: Himark - highlight all occurrenc= es of a regexp) X-Mailer: VM 6.72a under Emacs 20.4.1 Reply-To: Bob Glickstein Organization: Zanshin Inc., Marin County, CA > > could anyone please tell me if it is possible (and if so, how) to > > highlight all occurrences of a specific pattern in a buffer? I've written a patch for isearch.el that will become standard in the next release of GNU Emacs. It's called isearch-lazy-highlight (and is based on an older package of mine called ishl). Here's the NEWS blurb that will appear, followed by the patch itself. Enjoy! ** New feature in incremental search: "lazy highlighting," controlled by the variable `isearch-lazy-highlight'. When active, *every* match for the current search string is highlighted: the current one using the normal isearch match color and all the others using the unobtrusive `secondary-selection' color. The extra highlighting makes it easier to anticipate where the cursor will land each time you press C-s or C-r to repeat a pending search. Highlighting of these additional matches happens in a deferred fashion using "idle timers," so the cycles needed do not rob isearch of its usual snappy response. New default keybinding: M-C for clearing the extra highlighting (which normally happens automatically unless you turn off `isearch-lazy-highlight-cleanup'). *** isearch.el.orig Mon Jul 26 11:17:10 1999 --- isearch.el Mon Jul 26 15:05:47 1999 *************** *** 612,617 **** --- 612,618 ---- (setq ;; quit-flag nil not for isearch-mode isearch-adjusted nil isearch-yank-flag nil) + (isearch-lazy-highlight-new-loop) ) = (defun isearch-done (&optional nopush edit) *************** *** 621,626 **** --- 622,628 ---- (setq overriding-terminal-local-map nil) ;; (setq pre-command-hook isearch-old-pre-command-hook) ; for lemacs (isearch-dehighlight t) + (isearch-lazy-highlight-cleanup) (let ((found-start (window-start (selected-window))) (found-point (point))) (if isearch-window-configuration *************** *** 1740,1744 **** --- 1742,1921 ---- (defun isearch-last-command-char () ;; General function to return the last command character. last-command-char) + = + =0C + ;;; isearch-lazy-highlight feature + ;;; (formerly "ishl") + ;;; by Bob Glickstein + = + ;;; When active, *every* match for the current search string is + ;;; highlighted: the current one using the normal isearch match color + ;;; and all the others using the unobtrusive `secondary-selection' + ;;; color. The extra highlighting makes it easier to anticipate where + ;;; the cursor will land each time you press C-s or C-r to repeat a + ;;; pending search. Highlighting of these additional matches happens + ;;; in a deferred fashion using "idle timers," so the cycles needed do + ;;; not rob isearch of its usual snappy response. + = + ;;; IMPLEMENTATION NOTE: This depends on some isearch internals. + ;;; Specifically: + ;;; - `isearch-update' is expected to be called (at least) every time + ;;; the search string changes; + ;;; - `isearch-string' is expected to contain the current search + ;;; string as entered by the user; + ;;; - `isearch-overlay' is expected to contain the overlay used for + ;;; primary isearch match-highlighting; + ;;; - `isearch-opoint' is expected to contain the location where the + ;;; current search began; + ;;; - the type of the current search is expected to be given by + ;;; `isearch-word' and `isearch-regexp'; + ;;; - the direction of the current search is expected to be given by + ;;; `isearch-forward'; + ;;; - the variable `isearch-invalid-regexp' is expected to be true + ;;; iff `isearch-string' is an invalid regexp. + = + (require 'timer) + = + (defgroup isearch-lazy-highlight nil + "Lazy highlighting feature for incremental search." + :prefix "isearch-lazy-highlight-" + :group 'isearch) + = + (defcustom isearch-lazy-highlight t + "*Controls the lazy-highlight behavior of incremental search. + When non-nil, all text in the buffer matching the current search + string is highlighted lazily (see + `isearch-lazy-highlight-initial-delay' and + `isearch-lazy-highlight-interval')." + :type 'boolean + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-cleanup t + "*Controls whether to remove extra highlighting after a search. + If this is nil, extra highlighting can be \"manually\" removed with + \\[isearch-lazy-highlight-cleanup]." + :type 'boolean + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-initial-delay 0.25 + "*Seconds to wait before beginning to lazily highlight all matches." + :type 'number + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-interval 0.0625 + "*Seconds between lazily highlighting successive matches." + :type 'number + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-face 'secondary-selection + "*Face to use for lazily highlighting all matches." + :type 'face + :group 'isearch-lazy-highlight) + = + (defvar isearch-lazy-highlight-overlays nil) + (defvar isearch-lazy-highlight-wrapped nil) + (defvar isearch-lazy-highlight-start nil) + (defvar isearch-lazy-highlight-end nil) + (defvar isearch-lazy-highlight-timer nil) + (defvar isearch-lazy-highlight-last-string nil) + = + (defun isearch-lazy-highlight-cleanup (&optional force) + "Stop lazily highlighting and remove extra highlighting from buffer. + This happens automatically when exiting an incremental search if + `isearch-lazy-highlight-cleanup' is non-nil." + (interactive '(t)) + (if (or force isearch-lazy-highlight-cleanup) + (isearch-lazy-highlight-remove-overlays)) + (if isearch-lazy-highlight-timer + (progn + (cancel-timer isearch-lazy-highlight-timer) + (setq isearch-lazy-highlight-timer nil)))) + = + (defun isearch-lazy-highlight-remove-overlays () + "Remove lazy highlight overlays from the buffer." + (while isearch-lazy-highlight-overlays + (delete-overlay (car isearch-lazy-highlight-overlays)) + (setq isearch-lazy-highlight-overlays + (cdr isearch-lazy-highlight-overlays)))) + = + (defun isearch-lazy-highlight-new-loop () + "Cleanup any previous isearch-lazy-highlight loop and begin a new one= =2E + This happens when `isearch-update' is invoked (which can cause the + search string to change." + (if (and isearch-lazy-highlight + (not (equal isearch-string isearch-lazy-highlight-last-strin= g))) + ;; the search string did indeed change + (progn + (isearch-lazy-highlight-cleanup t) ;kill old loop & remove over= lays + (if (and isearch-overlay + (not (overlay-get isearch-overlay 'priority))) + ;; make sure the isearch-overlay takes priority + (overlay-put isearch-overlay 'priority 1)) + (setq isearch-lazy-highlight-start isearch-opoint + isearch-lazy-highlight-end isearch-opoint + isearch-lazy-highlight-last-string isearch-string + isearch-lazy-highlight-wrapped nil) + (setq isearch-lazy-highlight-timer + (run-with-idle-timer isearch-lazy-highlight-initial-delay= nil + 'isearch-lazy-highlight-update))))) + = + (defun isearch-lazy-highlight-search () + "Search ahead for the next or previous match, for lazy highlighting. + Attempt to do the search exactly the way the pending isearch would." + (let ((case-fold-search isearch-case-fold-search)) + (funcall (cond (isearch-word (if isearch-forward + 'word-search-forward + 'word-search-backward)) + (isearch-regexp (if isearch-forward + 're-search-forward + 're-search-backward)) + (t (if isearch-forward + 'search-forward + 'search-backward))) + isearch-string + (if isearch-forward + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-start + nil) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-end + nil)) + t))) + = + (defun isearch-lazy-highlight-update () + "Find and highlight the next match in the lazy highlighting loop." + (when (not isearch-invalid-regexp) + (save-excursion + (save-match-data + (goto-char (if isearch-forward + isearch-lazy-highlight-end + isearch-lazy-highlight-start)) + (let ((found (isearch-lazy-highlight-search))) ;do search + (if found + ;; found the next match + (let ((ov (make-overlay (match-beginning 0) + (match-end 0)))) + (overlay-put ov 'face isearch-lazy-highlight-face) + (overlay-put ov 'priority 0) + (setq isearch-lazy-highlight-overlays + (cons ov isearch-lazy-highlight-overlays)) + (setq isearch-lazy-highlight-timer + (run-at-time isearch-lazy-highlight-interval nil + 'isearch-lazy-highlight-update)) + (if isearch-forward + (setq isearch-lazy-highlight-end (point)) + (setq isearch-lazy-highlight-start (point)))) + ;; found no next match + (when (not isearch-lazy-highlight-wrapped) + ;; let's try wrapping around the end of the buffer + (setq isearch-lazy-highlight-wrapped t) + (setq isearch-lazy-highlight-timer + (run-at-time isearch-lazy-highlight-interval nil + 'isearch-lazy-highlight-update)) + (if isearch-forward + (setq isearch-lazy-highlight-end (point-min)) + (setq isearch-lazy-highlight-start (point-max))))))))))= + = + (define-key esc-map "C" 'isearch-lazy-highlight-cleanup) = ;;; isearch.el ends here --Multipart_Mon_Jul_26_16:19:38_1999-1-- From owner-xemacs-beta@xemacs.org Mon Jul 26 23:41:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA21991 for xemacs-beta-out; Mon, 26 Jul 1999 23:41:09 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA21988 for ; Mon, 26 Jul 1999 23:41:07 -0400 Received: from sparrow.bear.com (user-2ive3h6.dialup.mindspring.com [165.247.14.38]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA26236 for ; Mon, 26 Jul 1999 23:41:05 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id EAA16698 for ; Mon, 26 Jul 1999 04:19:05 -0700 Date: Mon, 26 Jul 1999 11:19:05 +0000 ( ) From: Justin Vallon To: XEmacs Beta Subject: Re: patch very preliminary support for /dev/pts/ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 26 Jul 1999, SL Baur wrote: > Neal Becker writes in xemacs-beta@xemacs.org: > > > Here is a very quick patch that seems to work to support the new > > /dev/pts on linux glibc2.1. > > > Obviously, better integration is needed. I suppose HAVE_GETPT needs > > to be added to autoconf. > > ... > > +#ifdef LINUX > > +#define HAVE_GETPT > > +#endif > > Um, it's going to have be a tad smarter than this to get put in. > Doesn't pts support require glibc 2.1 *and* a 2.2 kernel *and* being > configured in? I'm running glibc 2.1 on a 2.0.37 kernel, so minimally, yes. -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Tue Jul 27 00:38:23 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA23836 for xemacs-beta-out; Tue, 27 Jul 1999 00:38:23 -0400 Received: from max3p137.smart.net (max3p137.smart.net [216.84.81.137]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA23832 for ; Tue, 27 Jul 1999 00:38:19 -0400 Received: (from jmiller@localhost) by max3p137.smart.net (8.9.3/8.9.3) id AAA04060; Tue, 27 Jul 1999 00:38:45 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14237.14292.931093.161172@max3p136.smart.net.> Date: Tue, 27 Jul 1999 00:38:44 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: maybe a menubar bug in 21.1.4 X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm kinda confused on this one, so I'd like to see if anyone can duplicate it. On my Linux box here at home I can build xemacs 21.1.4 without menubars without a problem. I tried the same thing on my Solaris workstation at work today. The compile goes ok until the final link when it bitches about a missing external reference to menubar_show_keybindings in gui.c. If I add a "#ifdef HAVE_MENUBARS" wrapper around that little "if" statement in gui.c, xemacs compiles and dumps fine. has anyone else seen this or even begin to have a clue why? From owner-xemacs-beta@xemacs.org Tue Jul 27 00:46:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA24044 for xemacs-beta-out; Tue, 27 Jul 1999 00:46:56 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA24039 for ; Tue, 27 Jul 1999 00:46:51 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA23051 for ; Tue, 27 Jul 1999 13:46:49 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: GNU Emacs' rect.el References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> <87wvvngxqs.fsf@pc-hrvoje.srce.hr> <19990726150019.A21791@nemesis.ncsl.nist.gov> X-Attribution: sb From: SL Baur In-Reply-To: Olivier Galibert's message of "Mon, 26 Jul 1999 15:00:19 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 27 Jul 1999 13:46:34 +0900 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/InfoDock 4.0.8 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Olivier Galibert writes in xemacs-beta@xemacs.org: > On Mon, Jul 26, 1999 at 06:51:55PM +0200, Hrvoje Niksic wrote: >> That computation is broken in the world of variable-width characters >> anyway. O.K. I believe that I am starting to agree with you. > That computation is valid in the fixed-width characters, tty world, > and nowhere else. That proves not to be the case. What about characters that display as control characters `^M', or octal sequences `\210'? From owner-xemacs-beta@xemacs.org Tue Jul 27 02:12:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA25637 for xemacs-beta-out; Tue, 27 Jul 1999 02:12:15 -0400 Received: from oxe.cs.umu.se (oxe.cs.umu.se [130.239.40.14]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA25633 for ; Tue, 27 Jul 1999 02:12:13 -0400 Received: from kronborg.cs.umu.se (rfc1413 says torkel@kronborg.cs.umu.se [130.239.40.137]) by oxe.cs.umu.se (8.8.8/8.8.8) with ESMTP id IAA21150; Tue, 27 Jul 1999 08:12:11 +0200 (MET DST) Received: (rfc1413 says from torkel@localhost) by kronborg.cs.umu.se (8.8.8/8.8.8) id IAA22702; Tue, 27 Jul 1999 08:12:10 +0200 (MET DST) To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: Image lib References: From: torkel@hpc2n.umu.se (Björn Torkelsson) Date: 27 Jul 1999 08:12:09 +0200 In-Reply-To: nbecker@fred.net's message of "20 Jul 1999 08:20:55 -0400" Message-ID: <3wn1wipqo6.fsf@kronborg.cs.umu.se> Lines: 15 X-Mailer: Gnus v5.6.44/XEmacs 19.15 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > An image lib with uniform interface for ppm, png, and gif: > > http://www.radix.net/~cknudsen/Ilib/ Probably been discussed before, but why not Imlib? http://www.labs.redhat.com/imlib/tut/ (to be http://www.rasterman.com/imlib/) And yes, I know that Imlib depends on a lot of others libraries, but so does Ilib... /torkel From owner-xemacs-beta@xemacs.org Tue Jul 27 02:55:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA26524 for xemacs-beta-out; Tue, 27 Jul 1999 02:55:29 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA26520 for ; Tue, 27 Jul 1999 02:55:26 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id PAA00826 for ; Tue, 27 Jul 1999 15:55:18 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> X-Attribution: sb From: SL Baur In-Reply-To: torkel@hpc2n.umu.se's message of "27 Jul 1999 08:12:09 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: 27 Jul 1999 15:55:03 +0900 Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Björn Torkelsson writes in xemacs-beta@xemacs.org: > nbecker@fred.net writes: >> An image lib with uniform interface for ppm, png, and gif: >> >> http://www.radix.net/~cknudsen/Ilib/ > Probably been discussed before, but why not Imlib? > http://www.labs.redhat.com/imlib/tut/ > (to be http://www.rasterman.com/imlib/) > And yes, I know that Imlib depends on a lot of others libraries, but so > does Ilib... I must ask the three letter w-word here. We went through the exercise of using the ImageMagick graphics library some time back and it was so successful that we ripped it out and put the old code back in. What would using an image library buy us? Do the above libraries work with Microsoft Windows? From owner-xemacs-beta@xemacs.org Tue Jul 27 03:48:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA27997 for xemacs-beta-out; Tue, 27 Jul 1999 03:48:22 -0400 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 DAA27994 for ; Tue, 27 Jul 1999 03:48:20 -0400 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 DAA15675 for ; Tue, 27 Jul 1999 03:54:17 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id JAA16392; Tue, 27 Jul 1999 09:48:13 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 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: 27 Jul 1999 09:43:41 +0200 In-Reply-To: Jan Vroonhof's message of "26 Jul 1999 17:33:48 +0200" Message-ID: Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> Adrian Aichner writes: >> Currently vc-revert-buffer1 is plain broken, because it looses >> fontification of font-locked buffers. Jan> No it isn't :-) Something is wrong with font-lock and Jan> insert-file-contents on your side. OK. I'll dig into this. May have to do with the fact that I'm on Windows NT native. Please ignore my patch (not that I think that you wouldn't otherwise :-). Adrian Jan> Jan From owner-xemacs-beta@xemacs.org Tue Jul 27 04:02:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA28499 for xemacs-beta-out; Tue, 27 Jul 1999 04:02:58 -0400 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 EAA28494 for ; Tue, 27 Jul 1999 04:02:55 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id KAA02691 for ; Tue, 27 Jul 1999 10:02:54 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa000e1; Tue Jul 27 10:02:44 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id KAA00135; Tue, 27 Jul 1999 10:02:43 +0200 To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 References: <14237.14292.931093.161172@max3p136.smart.net.> From: Jan Vroonhof Date: 27 Jul 1999 10:02:43 +0200 In-Reply-To: Jeff Miller's message of "Tue, 27 Jul 1999 00:38:44 -0400 (EDT)" 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: Jeff Miller writes: > > has anyone else seen this or even begin to have a clue why? > Maybe some issue with Motif vs non-Motif? Jan From owner-xemacs-beta@xemacs.org Tue Jul 27 04:04:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA28551 for xemacs-beta-out; Tue, 27 Jul 1999 04:04:08 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA28542 for ; Tue, 27 Jul 1999 04:04:00 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id RAA04731 for ; Tue, 27 Jul 1999 17:03:56 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 References: <14237.14292.931093.161172@max3p136.smart.net.> X-Attribution: sb From: SL Baur In-Reply-To: Jeff Miller's message of "Tue, 27 Jul 1999 00:38:44 -0400 (EDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 27 Jul 1999 17:03:41 +0900 Message-ID: Lines: 36 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jeff Miller writes in xemacs-beta@xemacs.org: > I'm kinda confused on this one, so I'd like to see if anyone can > duplicate it. > On my Linux box here at home I can build xemacs 21.1.4 without > menubars without a problem. I tried the same thing on my Solaris > workstation at work today. The compile goes ok until the final link > when it bitches about a missing external reference to > menubar_show_keybindings in gui.c. If I add a "#ifdef HAVE_MENUBARS" > wrapper around that little "if" statement in gui.c, xemacs compiles and > dumps fine. > has anyone else seen this or even begin to have a clue why? Possibly differences in the linker. I don't know. Have you tried it on Solaris with a full GNU toolset (ie. with gas and gnuld)? I just tried a build with X without menubars with 21.2 and it bombs out here: gcc -c -g -O3 -Demacs -I. -DHAVE_CONFIG_H -I/usr/lib/locale/ja/wnn/demo/include -I/usr/local/include -I/usr/local/canna/include -I/usr/dt/include -I/usr/local/X11R6/include /usr/local/devel/xemacs-21.2/src/scrollbar-x.c /usr/local/devel/xemacs-21.2/src/scrollbar-x.c: In function `update_one_scrollbar_bs': /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: `XtNuseBackingStore' undeclared (first use in this function) /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: (Each undeclared identifier is reported only once /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: for each function it appears in.) make[1]: *** [scrollbar-x.o] Error 1 make[1]: Leaving directory `/usr/local/devel/miho-test/src' make: *** [src] Error 2 and I see your problem with a build against 21.1: Undefined first referenced symbol in file menubar_show_keybindings gui.o ld: fatal: Symbol referencing errors. No output written to temacs collect2: ld returned 1 exit status From owner-xemacs-beta@xemacs.org Tue Jul 27 04:06:36 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA28688 for xemacs-beta-out; Tue, 27 Jul 1999 04:06:36 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA28678 for ; Tue, 27 Jul 1999 04:06:30 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id RAA04899 for ; Tue, 27 Jul 1999 17:06:08 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 References: <14237.14292.931093.161172@max3p136.smart.net.> X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "27 Jul 1999 10:02:43 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 27 Jul 1999 17:05:53 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: > Jeff Miller writes: >> >> has anyone else seen this or even begin to have a clue why? >> > Maybe some issue with Motif vs non-Motif? None of the relevant code is guarded with anything remotely that. I believe that Jeff's recommended fix is the correct one. From owner-xemacs-beta@xemacs.org Tue Jul 27 04:11:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA28813 for xemacs-beta-out; Tue, 27 Jul 1999 04:11:04 -0400 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 EAA28810 for ; Tue, 27 Jul 1999 04:11:00 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 1192K9-0001pO-00 for ; Tue, 27 Jul 1999 10:10:57 +0200 To: XEmacs Beta List Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> 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: 27 Jul 1999 10:10:54 +0200 In-Reply-To: SL Baur's message of "27 Jul 1999 15:55:03 +0900" Message-ID: <87k8rmtsvl.fsf@pc-hrvoje.srce.hr> Lines: 7 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > We went through the exercise of using the ImageMagick graphics > library some time back and it was so successful that we ripped it > out and put the old code back in. I'm afraid Imlib sucks much worse than ImageMagick. From owner-xemacs-beta@xemacs.org Tue Jul 27 04:23:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA29285 for xemacs-beta-out; Tue, 27 Jul 1999 04:23:56 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA29282 for ; Tue, 27 Jul 1999 04:23:54 -0400 Received: from metheny.enst.fr (Qem4be/4HS5wTbN8VDrRv8Q8QQgqil+B@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id KAA23258; Tue, 27 Jul 1999 10:23:53 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id KAA26482; Tue, 27 Jul 1999 10:23:49 +0200 (MET DST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <87k8rmtsvl.fsf@pc-hrvoje.srce.hr> 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: Hrvoje Niksic's message of "27 Jul 1999 10:10:54 +0200" 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: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > SL Baur writes: > > > We went through the exercise of using the ImageMagick graphics > > library some time back and it was so successful that we ripped it > > out and put the old code back in. > > I'm afraid Imlib sucks much worse than ImageMagick. It looks rather powerfull (there is a caching mechanism directly implemented in it etc) but the latest version has a bug which makes all applications crash on TrueColor displays. It's been a while that this bug has been identified. As always, the problem is to get the balance right between reinventing the wheel and getting hooked on some external work that we don't have control on. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Tue Jul 27 06:46:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA31388 for xemacs-beta-out; Tue, 27 Jul 1999 06:46:25 -0400 Received: from max3p137.smart.net (max3p137.smart.net [216.84.81.137]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA31385 for ; Tue, 27 Jul 1999 06:46:22 -0400 Received: (from jmiller@localhost) by max3p137.smart.net (8.9.3/8.9.3) id GAA24037; Tue, 27 Jul 1999 06:46:47 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14237.36374.730282.203802@max3p136.smart.net.> Date: Tue, 27 Jul 1999 06:46:46 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 In-Reply-To: References: <14237.14292.931093.161172@max3p136.smart.net.> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "JV" == Jan Vroonhof writes: JV> Jeff Miller writes: >> >> has anyone else seen this or even begin to have a clue why? >> JV> Maybe some issue with Motif vs non-Motif? I thought about that, but i have lesstif installed at home, and I think that usually is enough to fool configure into thinking i have Motif. hmm, looking at my 21.1.4 here, i see that gui-x.c and gui.c aren't even compiled on my linux version, which seems right for this configuration. I'll try to look more at what configure is finding at work. JV> Jan From owner-xemacs-beta@xemacs.org Tue Jul 27 06:51:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA31512 for xemacs-beta-out; Tue, 27 Jul 1999 06:51:43 -0400 Received: from max3p137.smart.net (max3p137.smart.net [216.84.81.137]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA31508 for ; Tue, 27 Jul 1999 06:51:41 -0400 Received: (from jmiller@localhost) by max3p137.smart.net (8.9.3/8.9.3) id GAA24050; Tue, 27 Jul 1999 06:52:09 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14237.36697.140434.139552@max3p136.smart.net.> Date: Tue, 27 Jul 1999 06:52:09 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 In-Reply-To: References: <14237.14292.931093.161172@max3p136.smart.net.> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: >> has anyone else seen this or even begin to have a clue why? sb> Possibly differences in the linker. I don't know. Have you tried it sb> on Solaris with a full GNU toolset (ie. with gas and gnuld)? mm, don't think so. i'm using gcc and whatever it's picking up by default. sb> I just tried a build with X without menubars with 21.2 and it bombs sb> out here: sb> gcc -c -g -O3 -Demacs -I. -DHAVE_CONFIG_H -I/usr/lib/locale/ja/wnn/demo/include -I/usr/local/include -I/usr/local/canna/include -I/usr/dt/include -I/usr/local/X11R6/include /usr/local/devel/xemacs-21.2/src/scrollbar-x.c sb> /usr/local/devel/xemacs-21.2/src/scrollbar-x.c: In function `update_one_scrollbar_bs': sb> /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: `XtNuseBackingStore' undeclared (first use in this function) sb> /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: (Each undeclared identifier is reported only once sb> /usr/local/devel/xemacs-21.2/src/scrollbar-x.c:189: for each function it appears in.) sb> make[1]: *** [scrollbar-x.o] Error 1 sb> make[1]: Leaving directory `/usr/local/devel/miho-test/src' sb> make: *** [src] Error 2 I get this exact error on Linux with this configuration: ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2' '--with-dialogs=motif' '--with-menubars=motif' '--package-path=/usr/local/lib/xemacs/packages-21.0' '--with-scrollbars=motif' i think the trigger here is specifying scrollbars=motif. i can build 21.2 on linux without X. ./configure '--prefix=/usr/local' '--cflags=-g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2' '--package-path=/usr/local/lib/xemacs/packages-21.0' '--with-x11=no' the above compiles for me. sb> and I see your problem with a build against 21.1: sb> Undefined first referenced sb> symbol in file sb> menubar_show_keybindings gui.o sb> ld: fatal: Symbol referencing errors. No output written to temacs sb> collect2: ld returned 1 exit status ok, well, i'm not going crazy then. :-) as i mentioned in a previous msg, i'll try and see if i can figure out why gui.c is being compiled at all. jeff From owner-xemacs-beta@xemacs.org Tue Jul 27 08:12:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA01067 for xemacs-beta-out; Tue, 27 Jul 1999 08:12:42 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA01064 for ; Tue, 27 Jul 1999 08:12:40 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11965x-0002wy-00; Tue, 27 Jul 1999 08:12:33 -0400 To: Justin Vallon Cc: XEmacs Beta Subject: Re: patch very preliminary support for /dev/pts/ References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 27 Jul 1999 08:12:33 -0400 In-Reply-To: Justin Vallon's message of "Mon, 26 Jul 1999 11:19:05 +0000 ( )" Message-ID: Lines: 2 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I don't know if you saw my other post, but I'm told that this code should work on *any* glibc2.1 system. Could you try it? From owner-xemacs-beta@xemacs.org Tue Jul 27 08:24:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA01483 for xemacs-beta-out; Tue, 27 Jul 1999 08:24:15 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA01480 for ; Tue, 27 Jul 1999 08:24:13 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 1196HE-0002yX-00 for xemacs-beta@xemacs.org; Tue, 27 Jul 1999 08:24:12 -0400 From: Neal Becker To: xemacs-beta@xemacs.org Subject: FYI mailcrypt-3.5.4 Date: Tue, 27 Jul 1999 08:23:29 -0400 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99072708241200.11440@rpppc2.hns.com> Content-Transfer-Encoding: 8bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: http://freshmeat.net/news/1999/07/26/933042852.html From owner-xemacs-beta@xemacs.org Tue Jul 27 08:50:57 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA02460 for xemacs-beta-out; Tue, 27 Jul 1999 08:50:57 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA02455 for ; Tue, 27 Jul 1999 08:50:54 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 1196h2-0002zr-00 for xemacs-beta@xemacs.org; Tue, 27 Jul 1999 08:50:52 -0400 To: xemacs-beta@xemacs.org Subject: image mode broken? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 27 Jul 1999 08:50:52 -0400 Message-ID: Lines: 43 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Has anyone else seen this? Recently (last beta or two), visiting an image file no longer works. For example, find-file on junk.png doesn't show an image. It asks for an encryption key instead (this is from crypt). I haven't changed my config. My installation has all the image libs: uname -a: Linux nbeckerpc.hns.com 2.2.10 #14 Wed Jul 7 08:45:55 EDT 1999 i686 unknown ../../xemacs-21/configure '--error-checking=none' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21 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 ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. From owner-xemacs-beta@xemacs.org Tue Jul 27 09:54:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA05043 for xemacs-beta-out; Tue, 27 Jul 1999 09:54:14 -0400 Received: from boffi95.stru.polimi.it (boffi95.stru.polimi.it [131.175.24.94]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA05034 for ; Tue, 27 Jul 1999 09:54:07 -0400 Received: (from jim@localhost) by boffi95.stru.polimi.it (8.9.3/8.9.3) id PAA02745; Tue, 27 Jul 1999 15:51:30 +0200 From: giacomo boffi Message-ID: <14237.47456.397900.133456@boffi95.stru.polimi.it> Date: Tue, 27 Jul 1999 15:51:28 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: image mode broken? In-Reply-To: References: X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Reply-To: giacomo.boffi@polimi.it Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by gwyn.tux.org id JAA05038 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: nbecker@fred.net writes: > Has anyone else seen this? Recently (last beta or two), visiting an > image file no longer works. For example, find-file on junk.png > doesn't show an image. It asks for an encryption key instead (this is > from crypt). I haven't changed my config. My installation has all > the image libs: from the */lisp CHANGELOG 1999-04-19 Hrvoje Niksic * format.el (format-alist): Disable image stuff. what follows (from a 20.4 that survives on some HP's) works for me (setq format-alist '((image/jpeg "JPEG image" "ÿØÿàJFIF" image-decode-jpeg nil t image-mode) (image/gif "GIF image" "GIF8[79]" image-decode-gif nil t image-mode) (image/png "Portable Network Graphics" "‰PNG" image-decode-png nil t image-mode) (image/x-xpm "XPM image" "/\\* XPM \\*/" image-decode-xpm nil t image-mode) (image/tiff "TIFF image" "II\\*" image-decode-tiff nil t image-mode) (image/tiff "TIFF image" "MM\\*" image-decode-tiff nil t image-mode) (text/enriched "Extended MIME text/enriched format." "Content-[Tt]ype:[ ]*text/enriched" enriched-decode enriched-encode t enriched-mode) (text/richtext "Extended MIME obsolete text/richtext format." "Content-[Tt]ype:[ ]*text/richtext" richtext-decode richtext-encode t enriched-mode) (plain "ISO 8859-1 standard format, no text properties." nil nil nil nil nil))) From owner-xemacs-beta@xemacs.org Tue Jul 27 10:18:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA05945 for xemacs-beta-out; Tue, 27 Jul 1999 10:18:44 -0400 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 KAA05941 for ; Tue, 27 Jul 1999 10:18:43 -0400 Received: (from karl@localhost) by beaver.jprc.com (8.8.7/8.8.7) id KAA13920; Tue, 27 Jul 1999 10:18:40 -0400 To: xemacs-beta@xemacs.org Subject: Re: image mode broken? 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: 27 Jul 1999 10:18:39 -0400 In-Reply-To: nbecker@fred.net's message of "27 Jul 1999 08:50:52 -0400" Message-ID: Lines: 4 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have no idea why you're being asked for an encryption key, but it's been a while since image auto-decoding was disabled during find-file. You have to do something like (image-decode-png (point-min) (point-max)) to render the image. From owner-xemacs-beta@xemacs.org Tue Jul 27 10:27:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA06666 for xemacs-beta-out; Tue, 27 Jul 1999 10:27:56 -0400 Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA06656 for ; Tue, 27 Jul 1999 10:27:52 -0400 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA09503; Tue, 27 Jul 1999 09:27:51 -0500 (CDT) 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 JAA18618; Tue, 27 Jul 1999 09:28:05 -0500 (CDT) 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 KAA22134; Tue, 27 Jul 1999 10:27:49 -0400 (EDT) Received: (toy@localhost) by edgedsp4 (8.6.8/8.6.8) id KAA06064; Tue, 27 Jul 1999 10:28:04 -0400 To: Adrian Aichner Cc: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: From: Raymond Toy Date: 27 Jul 1999 10:28:04 -0400 In-Reply-To: Adrian Aichner's message of "27 Jul 1999 09:43:41 +0200" Message-ID: <4noggyf9qj.fsf@rtp.ericsson.se> Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "APA" == Adrian Aichner writes: >>>>> "Jan" == Jan Vroonhof writes: Jan> Adrian Aichner writes: >>> Currently vc-revert-buffer1 is plain broken, because it looses >>> fontification of font-locked buffers. Jan> No it isn't :-) Something is wrong with font-lock and Jan> insert-file-contents on your side. APA> OK. I'll dig into this. May have to do with the fact that I'm on APA> Windows NT native. No, it's not Window NT native. I've seen exactly the same things (except with vc-cc) on Solaris. This happened right after some changes that were made in revert-buffer or something like that. I vaguely remember someone complaining that font-lock appeared to get run twice on revert-buffer. Now it does't even get run once. :-( (This might not be quite right. My mail archives do go back far enough.) I think my font-lock and insert-file-contents are ok, since I don't think I've done anything special to them. Ray From owner-xemacs-beta@xemacs.org Tue Jul 27 11:10:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA09458 for xemacs-beta-out; Tue, 27 Jul 1999 11:10:26 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA09449 for ; Tue, 27 Jul 1999 11:10:17 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id KAA26952; Tue, 27 Jul 1999 10:10:12 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14237.52179.890200.770992@buffalo.fnal.gov> Date: Tue, 27 Jul 1999 10:10:11 -0500 (CDT) To: torkel@hpc2n.umu.se (=?UNKNOWN?Q?Bj=F6rn?= Torkelsson) Cc: xemacs-beta@xemacs.org Subject: Re: Image lib In-Reply-To: <3wn1wipqo6.fsf@kronborg.cs.umu.se> References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: =?UNKNOWN?Q?Bj=F6rn?= Torkelsson writes: > Probably been discussed before, but why not Imlib? > > http://www.labs.redhat.com/imlib/tut/ > (to be http://www.rasterman.com/imlib/) Have you ever tried reading any of "rasterman"'s code? From owner-xemacs-beta@xemacs.org Tue Jul 27 11:19:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA09961 for xemacs-beta-out; Tue, 27 Jul 1999 11:19:59 -0400 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 LAA09953 for ; Tue, 27 Jul 1999 11:19:57 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id RAA10770 for ; Tue, 27 Jul 1999 17:19:56 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa002c6; Tue Jul 27 17:19:46 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id RAA00950; Tue, 27 Jul 1999 17:19:46 +0200 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> From: Jan Vroonhof Date: 27 Jul 1999 17:19:46 +0200 In-Reply-To: Raymond Toy's message of "27 Jul 1999 10:28:04 -0400" Message-ID: Lines: 37 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: Raymond Toy writes: > No, it's not Window NT native. I've seen exactly the same things > (except with vc-cc) on Solaris. This happened right after some > changes that were made in revert-buffer or something like that. I > vaguely remember someone complaining that font-lock appeared to get > run twice on revert-buffer. Now it does't even get run once. :-( Can one of you guess step through that code and see where the font-locking gets lost? > (This might not be quite right. My mail archives do go back far > enough.) I see what you mean now. I think you mean this stuff from font-lock.el ;; If the buffer is about to be reverted, it won't be fontified afterward. (defun font-lock-revert-setup () (setq font-lock-fontified nil)) ;; If the buffer has just been reverted, normally that turns off ;; Font Lock mode. So turn the mode back on if necessary. ;; sb 1999-03-03 -- The above comment no longer appears to be operative as ;; the first call to normal-mode *will* restore the font-lock state and ;; this call forces a second font-locking to occur when reverting a buffer, ;; which is wasteful at best. ;(defalias 'font-lock-revert-cleanup 'turn-on-font-lock) (defun font-lock-revert-cleanup ()) a. Does undoing Steve's change help for your guys? b. Why _does_ the font-lock-ing work for me? I am using lazy-shot.el, are you? Jan P.S. I am using lazy-shot.el that sim From owner-xemacs-beta@xemacs.org Tue Jul 27 11:59:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA11537 for xemacs-beta-out; Tue, 27 Jul 1999 11:59:49 -0400 Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA11531 for ; Tue, 27 Jul 1999 11:59:47 -0400 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA15726; Tue, 27 Jul 1999 10:59:50 -0500 (CDT) 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 KAA05181; Tue, 27 Jul 1999 10:59:58 -0500 (CDT) 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 LAA25813; Tue, 27 Jul 1999 11:59:43 -0400 (EDT) Received: (toy@localhost) by edgedsp4 (8.6.8/8.6.8) id LAA06414; Tue, 27 Jul 1999 11:59:58 -0400 To: Jan Vroonhof Cc: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> From: Raymond Toy Date: 27 Jul 1999 11:59:57 -0400 In-Reply-To: Jan Vroonhof's message of "27 Jul 1999 17:19:46 +0200" Message-ID: <4niu76f5he.fsf@rtp.ericsson.se> Lines: 36 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Jan" == Jan Vroonhof writes: Jan> ;; If the buffer is about to be reverted, it won't be fontified afterward. Jan> (defun font-lock-revert-setup () Jan> (setq font-lock-fontified nil)) Jan> ;; If the buffer has just been reverted, normally that turns off Jan> ;; Font Lock mode. So turn the mode back on if necessary. Jan> ;; sb 1999-03-03 -- The above comment no longer appears to be operative as Jan> ;; the first call to normal-mode *will* restore the font-lock state and Jan> ;; this call forces a second font-locking to occur when reverting a buffer, Jan> ;; which is wasteful at best. Jan> ;(defalias 'font-lock-revert-cleanup 'turn-on-font-lock) Jan> (defun font-lock-revert-cleanup ()) Jan> a. Does undoing Steve's change help for your guys? Jan> b. Why _does_ the font-lock-ing work for me? I am using lazy-shot.el, Jan> are you? I'll give this a try soon. The problem is that sometimes font-lock goes away and sometimes it doesn't, and when it does goes away, I'm busy doing something else (real code!) so I don't bother to find out why. There does seem to be some correlation between the buffer size, though. Large buffers don't seem to get font-lock'ed again, but this is pure speculation. Jan> P.S. I am using lazy-shot.el that sim What? You mean Simon's version? I'm also using lazy-shot that comes in the sumo packages. Ray From owner-xemacs-beta@xemacs.org Tue Jul 27 15:32:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA19323 for xemacs-beta-out; Tue, 27 Jul 1999 15:32:37 -0400 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 PAA19296 for ; Tue, 27 Jul 1999 15:32:01 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119Cx7-0002Tm-00 for ; Tue, 27 Jul 1999 21:31:53 +0200 To: XEmacs Beta List Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <14237.52179.890200.770992@buffalo.fnal.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: 27 Jul 1999 21:31:50 +0200 In-Reply-To: Charles G Waldman's message of "Tue, 27 Jul 1999 10:10:11 -0500 (CDT)" Message-ID: <87n1whris9.fsf@pc-hrvoje.srce.hr> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Charles G Waldman writes: > =?UNKNOWN?Q?Bj=F6rn?= Torkelsson writes: > > > Probably been discussed before, but why not Imlib? > > > > http://www.labs.redhat.com/imlib/tut/ > > (to be http://www.rasterman.com/imlib/) > > Have you ever tried reading any of "rasterman"'s code? Or, even worse, using the programs that try to make use of his libraries? Absolutely horrible. From owner-xemacs-beta@xemacs.org Tue Jul 27 18:15:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA26447 for xemacs-beta-out; Tue, 27 Jul 1999 18:15:21 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA26444 for ; Tue, 27 Jul 1999 18:15:18 -0400 Received: from megalith.bp.aventail.com (usrpri2-61.kiva.net [206.97.75.126]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id PAA27691; Tue, 27 Jul 1999 15:14:00 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id RAA06191; Tue, 27 Jul 1999 17:14:56 -0500 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <14237.52179.890200.770992@buffalo.fnal.gov> <87n1whris9.fsf@pc-hrvoje.srce.hr> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 24 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > Charles G Waldman writes: > > > =?UNKNOWN?Q?Bj=F6rn?= Torkelsson writes: > > > > > Probably been discussed before, but why not Imlib? > > > > > > http://www.labs.redhat.com/imlib/tut/ > > > (to be http://www.rasterman.com/imlib/) > > > > Have you ever tried reading any of "rasterman"'s code? > > Or, even worse, using the programs that try to make use of his libraries? > Absolutely horrible. Not to mention that I cannot seem to find any API for loading images from data already in memory. Those who remember the ImageMagick integration I did, it was _painful_ to write every single image out to disk to a temp file and then read it back in. ImageMagick has the same features as ImLib, but it just wasn't worth it. -Bill P. From owner-xemacs-beta@xemacs.org Tue Jul 27 20:31:28 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA30675 for xemacs-beta-out; Tue, 27 Jul 1999 20:31:28 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA30672 for ; Tue, 27 Jul 1999 20:31:27 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id UAA10561 for ; Tue, 27 Jul 1999 20:30:50 -0400 (EDT) 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 RAA00173 for ; Tue, 27 Jul 1999 17:30:26 -0700 (PDT) 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 RAA01874 for ; Tue, 27 Jul 1999 17:31:18 -0700 (PDT) Message-Id: <199907280031.RAA01874@mina.sr.hp.com> To: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature Reply-To: Darryl Okahata In-reply-to: Your message of "Mon, 26 Jul 1999 16:19:38 PDT." <199907262319.QAA06594@mina.sr.hp.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Tue_Jul_27_17:31:18_1999-1" Content-Transfer-Encoding: 7bit Date: Tue, 27 Jul 1999 17:31:18 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Tue_Jul_27_17:31:18_1999-1 Content-Type: text/plain; charset=US-ASCII I wrote: > The following just appeared via gnu-emacs-sources. It looks > useful; anyone want to try adding this feature to XEmacs (if someone > isn't already doing so)? Well, thanks to Jan Vroonhof, who pointed out that the XEmacs isearch-mode.el isn't all that different from GNU Emacs' isearch.el, I took a stab at porting this, and it wasn't very hard. Patch follows. I haven't cc'd xemacs-patches, as I'd like people to try this out, and see what they think. If everything's fine, I'll send it to xemacs-patches next week. The patch is relative to the 21.1.4 isearch-mode.el. -- 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 Hewlett-Packard, or of the little green men that have been following him all day. --Multipart_Tue_Jul_27_17:31:18_1999-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="diffs" Content-Transfer-Encoding: quoted-printable *** ~//xemacs-21.1/lisp/isearch-mode.el Tue Jun 15 15:37:30 1999 --- isearch-mode.el Tue Jul 27 17:21:29 1999 *************** *** 70,75 **** --- 70,94 ---- ;;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ;;; Change History: = + ;; 27-Jul-99 (Darryl Okahata ) Merged Bob Glickstein= 's + ;; GNU Emacs isearch enhancements. From his release= + ;; message: + ;; + ;; ** New feature in incremental search: "lazy highlighting," control= led + ;; by the variable `isearch-lazy-highlight'. When active, *every* + ;; match for the current search string is highlighted: the current one + ;; using the normal isearch match color and all the others using the + ;; unobtrusive `secondary-selection' color. The extra highlighting + ;; makes it easier to anticipate where the cursor will land each time + ;; you press C-s or C-r to repeat a pending search. Highlighting of + ;; these additional matches happens in a deferred fashion using "idle + ;; timers," so the cycles needed do not rob isearch of its usual + ;; snappy response. New default keybinding: M-C for clearing the + ;; extra highlighting (which normally happens automatically unless you + ;; turn off `isearch-lazy-highlight-cleanup'). + ;; + ;; Bob's code was modified to use extents instead of overlays. + = ;; Header: /import/kaplan/kaplan/liberte/Isearch/RCS/isearch-mode.el,v = 1.3 92/06/29 13:10:08 liberte Exp Locker: liberte = ;; Log: isearch-mode.el,v = ;; *************** *** 528,533 **** --- 547,553 ---- (setq ;; quit-flag nil not for isearch-mode isearch-adjusted nil isearch-yank-flag nil) + (isearch-lazy-highlight-new-loop) ) = = *************** *** 551,557 **** (set-keymap-parents isearch-mode-map nil) (setq isearch-mode nil) (set-buffer-modified-p (buffer-modified-p));; update modeline ! (isearch-dehighlight t))) = ;; it's not critical that this be inside inhibit-quit, but leaving ;; things in small-window-mode would be bad. --- 571,579 ---- (set-keymap-parents isearch-mode-map nil) (setq isearch-mode nil) (set-buffer-modified-p (buffer-modified-p));; update modeline ! (isearch-dehighlight t) ! (isearch-lazy-highlight-cleanup) ! )) = ;; it's not critical that this be inside inhibit-quit, but leaving ;; things in small-window-mode would be bad. *************** *** 1622,1626 **** --- 1644,1825 ---- ,@body)) (put 'with-caps-disable-folding 'lisp-indent-function 1) (put 'with-caps-disable-folding 'edebug-form-spec '(form body)) + = + =0C + ;;; isearch-lazy-highlight feature + ;;; (formerly "ishl") + ;;; by Bob Glickstein + = + ;;; When active, *every* match for the current search string is + ;;; highlighted: the current one using the normal isearch match color + ;;; and all the others using the unobtrusive `secondary-selection' + ;;; color. The extra highlighting makes it easier to anticipate where + ;;; the cursor will land each time you press C-s or C-r to repeat a + ;;; pending search. Highlighting of these additional matches happens + ;;; in a deferred fashion using "idle timers," so the cycles needed do + ;;; not rob isearch of its usual snappy response. + = + ;;; IMPLEMENTATION NOTE: This depends on some isearch internals. + ;;; Specifically: + ;;; - `isearch-update' is expected to be called (at least) every time + ;;; the search string changes; + ;;; - `isearch-string' is expected to contain the current search + ;;; string as entered by the user; + ;;; - `isearch-extent' is expected to contain the extent used for + ;;; primary isearch match-highlighting; + ;;; - `isearch-opoint' is expected to contain the location where the + ;;; current search began; + ;;; - the type of the current search is expected to be given by + ;;; `isearch-word' and `isearch-regexp'; + ;;; - the direction of the current search is expected to be given by + ;;; `isearch-forward'; + ;;; - the variable `isearch-invalid-regexp' is expected to be true + ;;; iff `isearch-string' is an invalid regexp. + = + (require 'timer) + = + (defgroup isearch-lazy-highlight nil + "Lazy highlighting feature for incremental search." + :prefix "isearch-lazy-highlight-" + :group 'isearch) + = + (defcustom isearch-lazy-highlight t + "*Controls the lazy-highlight behavior of incremental search. + When non-nil, all text in the buffer matching the current search + string is highlighted lazily (see + `isearch-lazy-highlight-initial-delay' and + `isearch-lazy-highlight-interval')." + :type 'boolean + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-cleanup t + "*Controls whether to remove extra highlighting after a search. + If this is nil, extra highlighting can be \"manually\" removed with + \\[isearch-lazy-highlight-cleanup]." + :type 'boolean + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-initial-delay 0.25 + "*Seconds to wait before beginning to lazily highlight all matches." + :type 'number + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-interval 0.0625 + "*Seconds between lazily highlighting successive matches." + :type 'number + :group 'isearch-lazy-highlight) + = + (defcustom isearch-lazy-highlight-face 'secondary-selection + "*Face to use for lazily highlighting all matches." + :type 'face + :group 'isearch-lazy-highlight) + = + (defvar isearch-lazy-highlight-extents nil) + (defvar isearch-lazy-highlight-wrapped nil) + (defvar isearch-lazy-highlight-start nil) + (defvar isearch-lazy-highlight-end nil) + (defvar isearch-lazy-highlight-timer nil) + (defvar isearch-lazy-highlight-last-string nil) + = + (defun isearch-lazy-highlight-cleanup (&optional force) + "Stop lazily highlighting and remove extra highlighting from buffer. + This happens automatically when exiting an incremental search if + `isearch-lazy-highlight-cleanup' is non-nil." + (interactive '(t)) + (if (or force isearch-lazy-highlight-cleanup) + (isearch-lazy-highlight-remove-extents)) + (if isearch-lazy-highlight-timer + (progn + (cancel-timer isearch-lazy-highlight-timer) + (setq isearch-lazy-highlight-timer nil)))) + = + (defun isearch-lazy-highlight-remove-extents () + "Remove lazy highlight extents from the buffer." + (while isearch-lazy-highlight-extents + (delete-extent (car isearch-lazy-highlight-extents)) + (setq isearch-lazy-highlight-extents + (cdr isearch-lazy-highlight-extents)))) + = + (defun isearch-lazy-highlight-new-loop () + "Cleanup any previous isearch-lazy-highlight loop and begin a new one= =2E + This happens when `isearch-update' is invoked (which can cause the + search string to change." + (if (and isearch-lazy-highlight + (not (equal isearch-string isearch-lazy-highlight-last-strin= g))) + ;; the search string did indeed change + (progn + (isearch-lazy-highlight-cleanup t) ;kill old loop & remove exte= nts + (if (and isearch-extent + (not (extent-property isearch-extent 'priority))) + ;; make sure the isearch-extent takes priority + (set-extent-priority isearch-extent '(priority 1))) + (setq isearch-lazy-highlight-start isearch-opoint + isearch-lazy-highlight-end isearch-opoint + isearch-lazy-highlight-last-string isearch-string + isearch-lazy-highlight-wrapped nil) + (setq isearch-lazy-highlight-timer + (run-with-idle-timer isearch-lazy-highlight-initial-delay= nil + 'isearch-lazy-highlight-update))))) + = + (defun isearch-lazy-highlight-search () + "Search ahead for the next or previous match, for lazy highlighting. + Attempt to do the search exactly the way the pending isearch would." + (let ((case-fold-search isearch-case-fold-search)) + (funcall (cond (isearch-word (if isearch-forward + 'word-search-forward + 'word-search-backward)) + (isearch-regexp (if isearch-forward + 're-search-forward + 're-search-backward)) + (t (if isearch-forward + 'search-forward + 'search-backward))) + isearch-string + (if isearch-forward + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-start + nil) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-end + nil)) + t))) + = + (defun isearch-lazy-highlight-update () + "Find and highlight the next match in the lazy highlighting loop." + (when (not isearch-invalid-regexp) + (save-excursion + (save-match-data + (goto-char (if isearch-forward + isearch-lazy-highlight-end + isearch-lazy-highlight-start)) + (let ((found (isearch-lazy-highlight-search))) ;do search + (if found + ;; found the next match + (let ((ext (make-extent (match-beginning 0) + (match-end 0)))) + (set-extent-properties ext + (list + 'face isearch-lazy-highlight-face + 'priority 0)) + (setq isearch-lazy-highlight-extents + (cons ext isearch-lazy-highlight-extents)) + (setq isearch-lazy-highlight-timer + (run-at-time isearch-lazy-highlight-interval nil + 'isearch-lazy-highlight-update)) + (if isearch-forward + (setq isearch-lazy-highlight-end (point)) + (setq isearch-lazy-highlight-start (point)))) + ;; found no next match + (when (not isearch-lazy-highlight-wrapped) + ;; let's try wrapping around the end of the buffer + (setq isearch-lazy-highlight-wrapped t) + (setq isearch-lazy-highlight-timer + (run-at-time isearch-lazy-highlight-interval nil + 'isearch-lazy-highlight-update)) + (if isearch-forward + (setq isearch-lazy-highlight-end (point-min)) + (setq isearch-lazy-highlight-start (point-max))))))))))= + = + (define-key esc-map "C" 'isearch-lazy-highlight-cleanup) = ;;; isearch-mode.el ends here --Multipart_Tue_Jul_27_17:31:18_1999-1-- From owner-xemacs-beta@xemacs.org Tue Jul 27 21:23:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA32266 for xemacs-beta-out; Tue, 27 Jul 1999 21:23:15 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA32263 for ; Tue, 27 Jul 1999 21:23:13 -0400 Received: from megalith.bp.aventail.com (usrpri2-56.kiva.net [206.97.75.121]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id SAA02190; Tue, 27 Jul 1999 18:21:55 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id UAA01220; Tue, 27 Jul 1999 20:22:51 -0500 To: Darryl Okahata Cc: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 21 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Darryl Okahata writes: > I wrote: > > > The following just appeared via gnu-emacs-sources. It looks > > useful; anyone want to try adding this feature to XEmacs (if someone > > isn't already doing so)? > > Well, thanks to Jan Vroonhof, who pointed out that the XEmacs > isearch-mode.el isn't all that different from GNU Emacs' isearch.el, I > took a stab at porting this, and it wasn't very hard. Patch follows. > I haven't cc'd xemacs-patches, as I'd like people to try this out, and > see what they think. If everything's fine, I'll send it to > xemacs-patches next week. > > The patch is relative to the 21.1.4 isearch-mode.el. Works great here on XEmacs 21.2.18 - just a few offsets/fuzzes when patching. -bp From owner-xemacs-beta@xemacs.org Tue Jul 27 22:05:18 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA00949 for xemacs-beta-out; Tue, 27 Jul 1999 22:05:18 -0400 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 WAA00946 for ; Tue, 27 Jul 1999 22:05:15 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119J5h-0000IP-00 for ; Wed, 28 Jul 1999 04:05:09 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.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: 28 Jul 1999 04:05:08 +0200 In-Reply-To: Darryl Okahata's message of "Tue, 27 Jul 1999 17:31:18 -0700" Message-ID: <87r9ltjzqj.fsf@pc-hrvoje.srce.hr> Lines: 6 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Darryl Okahata writes: > + ;; Bob's code was modified to use extents instead of overlays. Cool. Now if only it used itimers instead of timer.el so it can be used... itimer.el is always available in XEmacs, timer.el is not. From owner-xemacs-beta@xemacs.org Tue Jul 27 22:19:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA01446 for xemacs-beta-out; Tue, 27 Jul 1999 22:19:25 -0400 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 WAA01441 for ; Tue, 27 Jul 1999 22:19:23 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119JJQ-0000JE-00 for ; Wed, 28 Jul 1999 04:19:20 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.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: 28 Jul 1999 04:19:20 +0200 In-Reply-To: Darryl Okahata's message of "Tue, 27 Jul 1999 17:31:18 -0700" Message-ID: <87n1whjz2v.fsf@pc-hrvoje.srce.hr> Lines: 66 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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 patch for it to work with itimers. It could probably be coded better (e.g. using the RESTART feature of itimers), but this should do for starters. The feature could probably be improved (more about that later), but it's quite nice even as it is. --- isearch-mode.el.orig Wed Jul 28 04:15:59 1999 +++ isearch-mode.el Wed Jul 28 04:16:03 1999 @@ -1677,8 +1677,6 @@ ;;; - the variable `isearch-invalid-regexp' is expected to be true ;;; iff `isearch-string' is an invalid regexp. -(require 'timer) - (defgroup isearch-lazy-highlight nil "Lazy highlighting feature for incremental search." :prefix "isearch-lazy-highlight-" @@ -1731,7 +1729,7 @@ (isearch-lazy-highlight-remove-extents)) (if isearch-lazy-highlight-timer (progn - (cancel-timer isearch-lazy-highlight-timer) + (delete-itimer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil)))) (defun isearch-lazy-highlight-remove-extents () @@ -1759,8 +1757,10 @@ isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-wrapped nil) (setq isearch-lazy-highlight-timer - (run-with-idle-timer isearch-lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-update))))) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-initial-delay + nil t))))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. @@ -1805,8 +1805,10 @@ (setq isearch-lazy-highlight-extents (cons ext isearch-lazy-highlight-extents)) (setq isearch-lazy-highlight-timer - (run-at-time isearch-lazy-highlight-interval nil - 'isearch-lazy-highlight-update)) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-interval + nil t)) (if isearch-forward (setq isearch-lazy-highlight-end (point)) (setq isearch-lazy-highlight-start (point)))) @@ -1815,8 +1817,10 @@ ;; let's try wrapping around the end of the buffer (setq isearch-lazy-highlight-wrapped t) (setq isearch-lazy-highlight-timer - (run-at-time isearch-lazy-highlight-interval nil - 'isearch-lazy-highlight-update)) + (start-itimer "Lazy highlight" + 'isearch-lazy-highlight-update + isearch-lazy-highlight-interval + nil t)) (if isearch-forward (setq isearch-lazy-highlight-end (point-min)) (setq isearch-lazy-highlight-start (point-max)))))))))) From owner-xemacs-beta@xemacs.org Tue Jul 27 22:30:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA02033 for xemacs-beta-out; Tue, 27 Jul 1999 22:30:15 -0400 Received: from max3p155.smart.net (max3p155.smart.net [216.84.81.155]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA02030 for ; Tue, 27 Jul 1999 22:30:11 -0400 Received: (from jmiller@localhost) by max3p155.smart.net (8.9.3/8.9.3) id WAA29656; Tue, 27 Jul 1999 22:30:28 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14238.27459.718351.202257@max3p136.smart.net.> Date: Tue, 27 Jul 1999 22:30:27 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: Re: maybe a menubar bug in 21.1.4 In-Reply-To: References: <14237.14292.931093.161172@max3p136.smart.net.> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Jan Vroonhof writes in xemacs-beta@xemacs.org: >> Jeff Miller writes: >>> >>> has anyone else seen this or even begin to have a clue why? >>> >> Maybe some issue with Motif vs non-Motif? sb> None of the relevant code is guarded with anything remotely that. I sb> believe that Jeff's recommended fix is the correct one. well, i realized what happened. Turns out the minimal build I was attempting on Solaris was not as minimal as I thought. I had forgotten to add "--with-dialogs=none", and that's why gui.c was getting compiled. If I leave that out of my Linux minimal build, I get the same result, why makes me happy. So it turns out it was just dumb luck finding it. Guess I'll add some more permutations to my script that does test compiles of off-beat configs. I will send a patch in to add the #ifdef guard to gui.c. Jeff From owner-xemacs-beta@xemacs.org Tue Jul 27 23:49:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA04606 for xemacs-beta-out; Tue, 27 Jul 1999 23:49:48 -0400 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.74]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA04602 for ; Tue, 27 Jul 1999 23:49:47 -0400 Received: from sparrow.bear.com (user-2ive1ca.dialup.mindspring.com [165.247.5.138]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA18947; Tue, 27 Jul 1999 23:49:50 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id XAA29087; Tue, 27 Jul 1999 23:49:54 -0400 Date: Wed, 28 Jul 1999 03:49:53 +0000 ( ) From: Justin Vallon To: nbecker@fred.net cc: XEmacs Beta Subject: Re: patch very preliminary support for /dev/pts/ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On 27 Jul 1999 nbecker@fred.net wrote: > I don't know if you saw my other post, but I'm told that this code > should work on *any* glibc2.1 system. Could you try it? I'll get the patch, but what do I try? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Wed Jul 28 00:11:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA05214 for xemacs-beta-out; Wed, 28 Jul 1999 00:11:27 -0400 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 AAA05211 for ; Wed, 28 Jul 1999 00:11:24 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id VAA31241; Tue, 27 Jul 1999 21:13:30 -0700 To: XEmacs Beta Subject: `revert-buffer' is broken. 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" Date: 27 Jul 1999 21:13:29 -0700 Message-ID: <87vhb55s46.fsf@bittersweet.sysc.pdx.edu> Lines: 3 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm seeing double after a CVS update. The file is inserted rather than reverted. From owner-xemacs-beta@xemacs.org Wed Jul 28 00:55:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA06799 for xemacs-beta-out; Wed, 28 Jul 1999 00:55:01 -0400 Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA06796 for ; Wed, 28 Jul 1999 00:54:46 -0400 Received: from miho (miho.etl.go.jp [150.29.201.195]) by mail1-im.etl.go.jp (8.9.1a/3.7W-98082521) with SMTP id NAA06276 for ; Wed, 28 Jul 1999 13:21:24 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> X-Attribution: sb From: SL Baur In-Reply-To: Jan Vroonhof's message of "27 Jul 1999 17:19:46 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Date: 28 Jul 1999 13:21:10 +0900 Message-ID: Lines: 55 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jan Vroonhof writes in xemacs-beta@xemacs.org: > Raymond Toy writes: >> No, it's not Window NT native. I've seen exactly the same things >> (except with vc-cc) on Solaris. This happened right after some >> changes that were made in revert-buffer or something like that. I >> vaguely remember someone complaining that font-lock appeared to get >> run twice on revert-buffer. That would be me. >> Now it does't even get run once. :-( This isn't true. I revert buffers every day (usually ChangeLogs) and they get re-font-locked. > Can one of you guess step through that code and see where the > font-locking gets lost? Yes, please do this. The code that handles buffer mode initialization is extremely complex and I wouldn't be surprised if you are doing something subtle in vc.el to break it. If someone wishes to take on a smallish project that we will love you for years for doing, cleaning up buffer initialization is the project. ... > I see what you mean now. I think you mean this stuff from font-lock.el > ;; If the buffer is about to be reverted, it won't be fontified afterward. > (defun font-lock-revert-setup () > (setq font-lock-fontified nil)) > ;; If the buffer has just been reverted, normally that turns off > ;; Font Lock mode. So turn the mode back on if necessary. > ;; sb 1999-03-03 -- The above comment no longer appears to be operative as > ;; the first call to normal-mode *will* restore the font-lock state and > ;; this call forces a second font-locking to occur when reverting a buffer, > ;; which is wasteful at best. > ;(defalias 'font-lock-revert-cleanup 'turn-on-font-lock) > (defun font-lock-revert-cleanup ()) > a. Does undoing Steve's change help for your guys? Undoing my patch is not the correct thing to do, but it would be interesting to see if it has any effect. Once it is undone, also try doing a `M-x revert-buffer' on a large ChangeLog file. > b. Why _does_ the font-lock-ing work for me? I am using lazy-shot.el, > are you? Because normal-mode restores the font lock state. > P.S. I am using lazy-shot.el that sim I am using fast-lock. From owner-xemacs-beta@xemacs.org Wed Jul 28 01:07:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA07051 for xemacs-beta-out; Wed, 28 Jul 1999 01:07:21 -0400 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 BAA07048 for ; Wed, 28 Jul 1999 01:07:19 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id WAA31414; Tue, 27 Jul 1999 22:09:25 -0700 To: XEmacs Beta Subject: Menu hotkeys broken? 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" Date: 27 Jul 1999 22:09:24 -0700 Message-ID: <87so695piz.fsf@bittersweet.sysc.pdx.edu> Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I have several of my menus renamed like `%_File' and keys bound so that I can use `A-f' to get the file menu. When I push `A-f' then down arrow, I get an error message: Signaling: (wrong-type-argument characterp "Open...") I have NOT tried to investigate; I'll make a todo entry and just report it to yous for now. From owner-xemacs-beta@xemacs.org Wed Jul 28 01:41:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA08026 for xemacs-beta-out; Wed, 28 Jul 1999 01:41:19 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA08020 for ; Wed, 28 Jul 1999 01:40:44 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id OAA10321; Wed, 28 Jul 1999 14:40:30 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `revert-buffer' is broken. References: <87vhb55s46.fsf@bittersweet.sysc.pdx.edu> X-Attribution: sb From: SL Baur In-Reply-To: karlheg's message of "27 Jul 1999 21:13:29 -0700" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 28 Jul 1999 14:40:30 +0900 Message-ID: Lines: 6 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: karlheg writes in xemacs-beta@xemacs.org: > I'm seeing double after a CVS update. The file is inserted rather > than reverted. Aiieee! I see it too. ++ungood. From owner-xemacs-beta@xemacs.org Wed Jul 28 02:29:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA09963 for xemacs-beta-out; Wed, 28 Jul 1999 02:29:22 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA09919 for ; Wed, 28 Jul 1999 02:29:05 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id PAA18546; Wed, 28 Jul 1999 15:28:50 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: `revert-buffer' is broken. References: <87vhb55s46.fsf@bittersweet.sysc.pdx.edu> X-Attribution: sb From: SL Baur In-Reply-To: SL Baur's message of "28 Jul 1999 14:40:30 +0900" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 28 Jul 1999 15:28:49 +0900 Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: karlheg writes in xemacs-beta@xemacs.org: > I'm seeing double after a CVS update. The file is inserted rather > than reverted. Update: I see this only in 21.2, not 21.1. The code to `revert-buffer' hasn't changed so I presume the difference must be a side effect of some other change. Ugh. From owner-xemacs-beta@xemacs.org Wed Jul 28 02:37:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA10812 for xemacs-beta-out; Wed, 28 Jul 1999 02:37:43 -0400 Received: from oxe.cs.umu.se (oxe.cs.umu.se [130.239.40.14]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA10798 for ; Wed, 28 Jul 1999 02:37:36 -0400 Received: from kronborg.cs.umu.se (rfc1413 says torkel@kronborg.cs.umu.se [130.239.40.137]) by oxe.cs.umu.se (8.8.8/8.8.8) with ESMTP id IAA18275 for ; Wed, 28 Jul 1999 08:37:35 +0200 (MET DST) Received: (rfc1413 says from torkel@localhost) by kronborg.cs.umu.se (8.8.8/8.8.8) id IAA00689; Wed, 28 Jul 1999 08:37:34 +0200 (MET DST) To: XEmacs Beta List Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <14237.52179.890200.770992@buffalo.fnal.gov> From: torkel@hpc2n.umu.se (Björn Torkelsson) Date: 28 Jul 1999 08:37:33 +0200 In-Reply-To: Hrvoje Niksic's message of "27 Jul 1999 21:31:50 +0200" Message-ID: <3wiu75p9ea.fsf@kronborg.cs.umu.se> Lines: 18 X-Mailer: Gnus v5.6.44/XEmacs 19.15 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Charles G Waldman writes: > =?UNKNOWN?Q?Bj=F6rn?= Torkelsson writes: > > > Probably been discussed before, but why not Imlib? > > > > http://www.labs.redhat.com/imlib/tut/ > > (to be http://www.rasterman.com/imlib/) > > Have you ever tried reading any of "rasterman"'s code? No I haven't read his code and I haven't used Imlib. I just thought I should ask: 'why not Imlib'. And I got answers... :-) /torkel From owner-xemacs-beta@xemacs.org Wed Jul 28 03:12:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14400 for xemacs-beta-out; Wed, 28 Jul 1999 03:12:11 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14386 for ; Wed, 28 Jul 1999 03:12:08 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id QAA18598; Wed, 28 Jul 1999 16:11:52 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: insert-file-contents is broken X-Attribution: sb From: SL Baur Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 28 Jul 1999 16:11:51 +0900 Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: [The replace flag is used by `revert-buffer' and its not working is what Karl found wrt revert-buffer not working.] Does the following comment apply to XEmacsen with file coding and no Mule? `insert-file-contents' is a compiled Lisp function -- loaded from "/usr/local/devel/miho-21.1-optimized/lisp/code-files.elc" (insert-file-contents FILENAME &optional VISIT BEG END REPLACE) ... NOTE: When Mule support is enabled, the REPLACE argument is currently ignored. ... A quick test is xemacs -vanilla M-: (insert-file-contents "/etc/hosts" nil nil nil t) The contents of *scratch* are either replaced by the specified file or appended to. I've tested both 21.1 and 21.2 with Mule, and in 21.1 the comment is clearly wrong. The replace flag works in Mule. It doesn't in 21.2. Who was the last person to be diddling with `insert-file-contents'? From owner-xemacs-beta@xemacs.org Wed Jul 28 03:17:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA14796 for xemacs-beta-out; Wed, 28 Jul 1999 03:17:58 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA14786 for ; Wed, 28 Jul 1999 03:17:52 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id QAA18601; Wed, 28 Jul 1999 16:17:25 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <87k8rmtsvl.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Didier Verna's message of "27 Jul 1999 10:23:48 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 28 Jul 1999 16:17:25 +0900 Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes in xemacs-beta@xemacs.org: > Hrvoje Niksic writes: >> I'm afraid Imlib sucks much worse than ImageMagick. > It looks rather powerfull (there is a caching mechanism directly > implemented in it etc) Yes, but I believe we already do caching. > but the latest version has a bug which makes all applications crash > on TrueColor displays. It's been a while that this bug has been > identified. Ugh. And double ugh. > As always, the problem is to get the balance right between reinventing > the wheel and getting hooked on some external work that we don't have > control on. Maybe we should just write somewhere that we have nothing against unified interface graphics libraries, but until one gets written that doesn't suck we roll our own. From owner-xemacs-beta@xemacs.org Wed Jul 28 05:17:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA18119 for xemacs-beta-out; Wed, 28 Jul 1999 05:17:44 -0400 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 FAA18115 for ; Wed, 28 Jul 1999 05:17:42 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA28185 for ; Wed, 28 Jul 1999 02:17:25 -0700 (PDT) Received: from andyppc (lhr-modem2.beasys.com [10.5.1.13]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA08410; Wed, 28 Jul 1999 02:17:22 -0700 (PDT) Message-Id: <3.0.5.32.19990728101750.00a32760@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 28 Jul 1999 10:17:50 +0100 To: xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Image lib Cc: xemacs-beta@xemacs.org In-Reply-To: <14237.52179.890200.770992@buffalo.fnal.gov> References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <3wn1wipqo6.fsf@kronborg.cs.umu.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Why are we going round this loop again? The image code is nicely modularised now. I cannot conceive of any earthly reason why we would want to change it now. If it ain't broke .... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Wed Jul 28 05:26:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA18939 for xemacs-beta-out; Wed, 28 Jul 1999 05:26:56 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA18894 for ; Wed, 28 Jul 1999 05:26:22 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id SAA18768; Wed, 28 Jul 1999 18:25:57 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <3wn1wipqo6.fsf@kronborg.cs.umu.se> <3.0.5.32.19990728101750.00a32760@london.beasys.com> X-Attribution: sb From: SL Baur In-Reply-To: Andy Piper's message of "Wed, 28 Jul 1999 10:17:50 +0100" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 28 Jul 1999 18:25:57 +0900 Message-ID: Lines: 7 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Andy Piper writes in xemacs-beta@xemacs.org: > Why are we going round this loop again? The image code is nicely > modularised now. I cannot conceive of any earthly reason why we would want > to change it now. I want BMP, PPM/PNM etc., postscript, animated GIF, etc. support. From owner-xemacs-beta@xemacs.org Wed Jul 28 06:33:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA20931 for xemacs-beta-out; Wed, 28 Jul 1999 06:33:44 -0400 Received: from boffi95.stru.polimi.it (boffi95.stru.polimi.it [131.175.24.94]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA20927 for ; Wed, 28 Jul 1999 06:33:40 -0400 Received: (from jim@localhost) by boffi95.stru.polimi.it (8.9.3/8.9.3) id MAA06259; Wed, 28 Jul 1999 12:31:58 +0200 From: giacomo boffi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14238.56345.137128.965524@boffi95.stru.polimi.it> Date: Wed, 28 Jul 1999 12:31:53 +0200 (CEST) To: xemacs-beta@xemacs.org Subject: Re: Image lib In-Reply-To: References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <3.0.5.32.19990728101750.00a32760@london.beasys.com> X-Mailer: VM 6.71 under 21.2 (beta17) "Chiyoda" XEmacs Lucid Reply-To: giacomo.boffi@polimi.it Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur writes: > Andy Piper writes in xemacs-beta@xemacs.org: > > > Why are we going round this loop again? The image code is nicely > > modularised now. I cannot conceive of any earthly reason why we would want > > to change it now. > > I want BMP, PPM/PNM etc., postscript, animated GIF, etc. support. you forgot to mention mpgs 8-) From owner-xemacs-beta@xemacs.org Wed Jul 28 07:55:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id HAA23799 for xemacs-beta-out; Wed, 28 Jul 1999 07:55:52 -0400 Received: from rpppc2.hns.com (rpppc2.hns.com [139.85.24.127]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id HAA23796 for ; Wed, 28 Jul 1999 07:55:50 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 119SJJ-0003lM-00; Wed, 28 Jul 1999 07:55:49 -0400 To: Justin Vallon Cc: XEmacs Beta Subject: Re: patch very preliminary support for /dev/pts/ References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 28 Jul 1999 07:55:49 -0400 In-Reply-To: Justin Vallon's message of "Wed, 28 Jul 1999 03:49:53 +0000 ( )" Message-ID: Lines: 5 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Just try M-x shell, for example, and see if it works OK. From within the shell mode, type 'tty' to see what pty it's using. If it doesn't work, it'll probably complain about not being able to get a pty or something like that. From owner-xemacs-beta@xemacs.org Wed Jul 28 08:01:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA23930 for xemacs-beta-out; Wed, 28 Jul 1999 08:01:15 -0400 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 IAA23922; Wed, 28 Jul 1999 08:01:10 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id FAA02751; Wed, 28 Jul 1999 05:00:54 -0700 (PDT) Received: from andyppc (lhr-modem2.beasys.com [10.5.1.13]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id FAA14149; Wed, 28 Jul 1999 05:00:14 -0700 (PDT) Message-Id: <3.0.5.32.19990728130044.009744a0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 28 Jul 1999 13:00:44 +0100 To: xemacs-patches@xemacs.org From: Andy Piper Subject: X tabs patch Cc: xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_933159644==_" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --=====================_933159644==_ Content-Type: text/plain; charset="us-ascii" This is the substance of a patch I propose to apply tomorrow. It implements tab widget and athena widget support under X. andy 1999-07-28 Andy Piper * redisplay-output.c (redisplay_clear_bottom_of_window): remove unneeded device. * gutter.c (redraw_exposed_gutter): unmap subwindows from the whole gutter. * gui.h: declare parse_gui_item_tree_list and parse_gui_item_tree_children. * gui.c (parse_gui_item_tree_item): new function for parsing item lists into gui-item trees. (parse_gui_item_tree_children): ditto. (parse_gui_item_tree_list): ditto. * gui-x.h: declare gui_items_to_widget_values. * gui-x.c (gui_items_to_widget_values_1): new function for recursively parsing gui-items into widget_values. (gui_item_children_to_widget_values): ditto. (gui_items_to_widget_values): ditto. (sanity_check_lwlib): add widgets macrolets. * glyphs.h (IMAGE_INSTANCE_WIDGET_ITEMS): rename from *ITEM. (XIMAGE_INSTANCE_WIDGET_ITEMS): ditto. (IMAGE_INSTANCE_WIDGET_ITEM): rename from *SINGLE_ITEM. (XIMAGE_INSTANCE_WIDGET_ITEM): ditto. (struct expose_ignore): new structure for storing ignorable expose events. * glyphs.c (valid_image_instantiator_format_p): fix so that using a console-type as a locale works. (mark_image_instance): ITEM->ITEMS. (image_instance_equal): ditto. (image_instance_hash): ditto. (struct expose_ignore_blocktype): new blocktype. (check_for_ignored_expose): new function. checks frame exposure list for events to ignore. (register_ignored_expose): new function. registers an expose event as ignorable. (unmap_subwindow): register the expose event as ignorable. (vars_of_glyphs): initialise the exposure blocktype. * glyphs-x.c (x_finalize_image_instance): use lw_destroy_widget. (x_update_subwindow): modify all widgets using widget_value tree rather than just a single widget value. (x_widget_instantiate): LWLIB_USES_MOTIF -> LWLIB_WIDGETS_MOTIF. make sure widgets don't resize themselves. (x_tab_control_instantiate): new function. use lwlib tab functions. (x_tab_control_set_property): new function. (image_instantiator_format_create_glyphs_x): add tab_control. * glyphs-widget.c (widget_text_to_pixel_conversion): calculate slightly more sensibly. (initialize_widget_image_instance): ITEM->ITEMS. (widget_instantiate_1): parse gui items generically into the ITEMS entry. * glyphs-msw.c (mswindows_update_subwindow): replace SINGLE_ITEM->ITEM. (mswindows_register_widget_instance): ditto. (add_tree_item): modify to use new pre-initialised gui-item structure. (add_tab_item): ditto. (mswindows_tab_control_instantiate): ditto. (mswindows_tab_control_set_property): ditto. (image_instantiator_format_create_glyphs_mswindows): predicate existance of widgets on HAVE_WIDGETS. * frame.h (struct frame): add subwindow_exposures variables. * frame.c (allocate_frame_core): reset subwindow_exposures links. * event-msw.c (mswindows_wnd_proc): check for ignored expose events before redrawing. * event-Xt.c (emacs_Xt_handle_magic_event): check for ignored expose events before redrawing. * config.h.in: add new LWLIB defines. * internals.texi (Glyphs): add some glyph documentation. 1999-07-28 Andy Piper * xlwtabs.c: new lucid tabs widget from Ed Falk. * xlwtabs.h: ditto. * xlwtabsP.h: ditto. * xlwgcs.c: GC manipulation for tab widgets. * xlwgcs.h: ditto. * xlwgauge.c: new athena gauge widget from Ed Falk. * xlwgauge.h: ditto. * xlwgaugeP.h: ditto. * xlwradio.c: new athena radio widget from Ed Falk. * xlwradio.h: ditto. * xlwradioP.h: ditto. * xlwcheckbox.c: new athena checkbox widget from Ed Falk. * xlwcheckbox.h: ditto. * xlwcheckboxP.h: ditto. * lwlib-utils.c (destroy_all_children): moved from lwlib-Xm.c. * lwlib-internal.h: declare destroy_all_children. * lwlib-config.c: add widget checks. * lwlib-Xm.h: declare xm_create_label; * lwlib-Xm.c (destroy_all_children): move to lwlib-utils.c. (xm_update_label): enable for widgets. (xm_update_one_widget): ditto. (xm_create_button): rename in line with lwlib-Xaw.c (xm_create_progress): ditto. (xm_create_text_field): ditto. (xm_create_combo_box): ditto. (xm_create_label): new function. (xm_creation_table): rename widget creation functions. (xm_destroy_instance): enable for widgets. (xm_generic_callback): ditto. (xm_generic_callback): ditto. * lwlib-Xlw.c (xlw_tab_control_callback): new function. a special callback that calls the correct function depending on what tab is selected. (xlw_create_tab_control): new function. (build_tabs_in_widget): new function. puts tabs in a tab widget, uses Xaw or Xm depending on how XEmacs was compiled. (xlw_update_tab_control): update the resources for each tab. optionally rebuild the contents of the tab widget. (xlw_creation_table): add tab widget creation function. (lw_lucid_widget_p): add tab widget. (xlw_update_one_widget): ditto. * lwlib-Xaw.h: declare xaw_create_label; * lwlib-Xaw.c (lw_xaw_widget_p): add widgets classes. (xaw_update_one_widget): ditto. (xaw_update_one_value): add code from the Xm version. (xaw_generic_callback): add Xm hack for setting command states. beef up lookup of call data. (xaw_create_button): new function. (xaw_create_label): new function for use by tab widget. (xaw_create_progress): new function. (xaw_create_text_field): new function. (xaw_creation_table): add new widget type creation functions. * Makefile.in.in: add dependencies for new lw widgets. * gutter-items.el (add-tab-to-gutter): put in specifier specs for all devices that support tab controls. (remove-buffer-from-gutter-tab): new function. to be used as a value for kill-buffer-hook. * configure.in: fix definitions of widget defines with various toolkit options. --=====================_933159644==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="xgut.patch" Content-Transfer-Encoding: quoted-printable Index:= configure.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v retrieving revision 1.111.2.36 diff -u -r1.111.2.36 configure.in --- configure.in 1999/07/22 07:32:39 1.111.2.36 +++ configure.in 1999/07/28 08:33:38 @@ -2886,8 +2886,9 @@ case "$with_scrollbars" in "" | "yes" ) with_scrollbars=3D"lucid" ;; esac -case "$with_widgets" in "" | "yes" ) +case "$with_widgets" in "" | "yes" | "lucid") if test "$have_motif" =3D "yes"; then with_widgets=3D"motif" + elif test "$have_xaw" =3D "yes"; then with_widgets=3D"athena" else with_widgets=3Dno fi ;; esac @@ -2911,6 +2912,10 @@ test "$with_menubars" =3D "lucid" && XE_APPEND(xlwmenu.o, lwlib_objs) test "$with_menubars" =3D "motif" && XE_APPEND(xlwmenu.o, lwlib_objs) test "$with_scrollbars" =3D "lucid" && XE_APPEND(xlwscrollbar.o,= lwlib_objs) +test "$with_widgets" !=3D "no" && XE_APPEND(xlwtabs.o xlwgcs.o,= lwlib_objs) +case "$with_widgets" in athena* ) + XE_APPEND(xlwradio.o xlwcheckbox.o xlwgauge.o, lwlib_objs);; +esac case "$all_widgets" in *lucid* ) AC_DEFINE(NEED_LUCID) XE_APPEND(lwlib-Xlw.o, lwlib_objs) ;; @@ -2922,11 +2927,14 @@ case "$with_dialogs" in athena* ) AC_DEFINE(LWLIB_DIALOGS_ATHENA) ;;= esac test "$with_scrollbars" =3D "athena3d" &&= AC_DEFINE(LWLIB_SCROLLBARS_ATHENA3D) test "$with_dialogs" =3D "athena3d" &&= AC_DEFINE(LWLIB_DIALOGS_ATHENA3D) +case "$with_widgets" in athena* ) AC_DEFINE(LWLIB_WIDGETS_ATHENA);;= esac +test "$with_widgets" !=3D "no" && AC_DEFINE(LWLIB_TABS_LUCID) test "$with_menubars" !=3D "no" && AC_DEFINE(HAVE_MENUBARS) test "$with_scrollbars" !=3D "no" && AC_DEFINE(HAVE_SCROLLBARS) test "$with_dialogs" !=3D "no" && AC_DEFINE(HAVE_DIALOGS) test "$with_toolbars" !=3D "no" && AC_DEFINE(HAVE_TOOLBARS) +test "$with_widgets" !=3D "no" && AC_DEFINE(HAVE_WIDGETS) test "$with_menubars" =3D "lucid" && AC_DEFINE(LWLIB_MENUBARS_LUCID) test "$with_scrollbars" =3D "lucid" &&= AC_DEFINE(LWLIB_SCROLLBARS_LUCID) @@ -2934,6 +2942,7 @@ test "$with_menubars" =3D "motif" && AC_DEFINE(LWLIB_MENUBARS_MOTIF) test "$with_scrollbars" =3D "motif" && AC_DEFINE(LWLIB_SCROLLBARS_MOTIF) test "$with_dialogs" =3D "motif" &&= AC_DEFINE(LWLIB_DIALOGS_MOTIF) +test "$with_widgets" =3D "motif" && AC_DEFINE(LWLIB_WIDGETS_MOTIF) test "$with_menubars" !=3D "no" && XE_ADD_OBJS(menubar.o) test "$with_scrollbars" !=3D "no" && XE_ADD_OBJS(scrollbar.o) Index:= lisp/gutter-items.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/Attic/gutter-items.el,v retrieving revision 1.1.2.4 diff -u -r1.1.2.4 gutter-items.el --- lisp/gutter-items.el 1999/07/25 19:16:44 1.1.2.4 +++ lisp/gutter-items.el 1999/07/28 08:33:40 @@ -140,8 +140,11 @@ (vector 'tab-control :descriptor "Buffers" :properties (list :items (buffers-tab-items)))))) ;; This looks better than a 3d border - (set-specifier default-gutter-border-width 0 'global 'mswindows) - (set-specifier default-gutter gutter-string 'global 'mswindows))) + (mapcar '(lambda (x) + (when (valid-image-instantiator-format-p 'tab-control x) + (set-specifier default-gutter-border-width 0 'global x) + (set-specifier default-gutter gutter-string 'global x))) + (console-type-list)))) (defun update-tab-in-gutter (&optional notused) "Update the tab control in the gutter area." @@ -152,8 +155,18 @@ (resize-subwindow (glyph-image-instance gutter-buffers-tab) (gutter-pixel-width) nil))) +(defun remove-buffer-from-gutter-tab () + "Remove the current buffer from the tab control in the gutter area." + (when (valid-image-instantiator-format-p 'tab-control) + (set-image-instance-property (glyph-image-instance= gutter-buffers-tab) + :items + (cdr (buffers-tab-items))) + (resize-subwindow (glyph-image-instance gutter-buffers-tab) + (gutter-pixel-width) nil))) + (add-tab-to-gutter) (add-hook 'switch-to-buffer-hooks 'update-tab-in-gutter) +(add-hook 'kill-buffer-hook 'remove-buffer-from-gutter-tab) (add-hook 'create-frame-hook 'update-tab-in-gutter) (provide 'gutter-items) Index:= lwlib/Makefile.in.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Makefile.in.in,v retrieving revision 1.14.2.2 diff -u -r1.14.2.2 Makefile.in.in --- lwlib/Makefile.in.in 1998/12/14 13:20:37 1.14.2.2 +++ lwlib/Makefile.in.in 1999/07/28 08:33:40 @@ -95,11 +95,18 @@ ## Following correct as of 19980312 -lwlib-Xaw.o: $(CONFIG_H) lwlib-Xaw.h lwlib-internal.h lwlib.h= xlwmenu.h -lwlib-Xlw.o: $(CONFIG_H) lwlib-Xlw.h lwlib-internal.h lwlib.h xlwmenu.h= xlwscrollbar.h +lwlib-Xaw.o: $(CONFIG_H) lwlib-Xaw.h lwlib-internal.h lwlib.h xlwmenu.h= xlwradio.h \ +xlwgauge.h xlwcheckbox.h +lwlib-Xlw.o: $(CONFIG_H) lwlib-Xlw.h lwlib-internal.h lwlib.h xlwmenu.h= xlwscrollbar.h \ +xlwtabs.h xlwgcs.h lwlib-Xm.o: $(CONFIG_H) lwlib-Xm.h lwlib-internal.h lwlib-utils.h lwlib.h= xlwmenu.h lwlib-config.o: $(CONFIG_H) lwlib.h xlwmenu.h lwlib-utils.o: $(CONFIG_H) lwlib-utils.h lwlib.o: $(CONFIG_H) lwlib-Xaw.h lwlib-Xlw.h lwlib-Xm.h lwlib-internal.h= lwlib-utils.h lwlib.h xlwmenu.h xlwmenu.o: $(CONFIG_H) lwlib.h xlwmenu.h xlwmenuP.h xlwscrollbar.o: $(CONFIG_H) xlwscrollbar.h= xlwscrollbarP.h +xlwtabs.o: $(CONFIG_H) xlwtabs.h xlwtabsP.h +xlwradio.o: $(CONFIG_H) xlwradio.h xlwradioP.h +xlwcheckbox.o: $(CONFIG_H) xlwcheckbox.h= xlwcheckboxP.h +xlwgauge.o: $(CONFIG_H) xlwgauge.h xlwgaugeP.h +xlwgcs.o: $(CONFIG_H) xlwgcs.h Index:= lwlib/lwlib-Xaw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xaw.c,v retrieving revision 1.9 diff -u -r1.9 lwlib-Xaw.c --- lwlib/lwlib-Xaw.c 1998/01/19 01:57:47 1.9 +++ lwlib/lwlib-Xaw.c 1999/07/28 08:33:43 @@ -41,7 +41,15 @@ #include #include #endif - +#ifdef LWLIB_WIDGETS_ATHENA +#include +#include "xlwradio.h" +#include "xlwcheckbox.h" +#include "xlwgauge.h" +#if 0 +#include +#endif +#endif #include static void xaw_generic_callback (Widget, XtPointer, XtPointer); @@ -57,6 +65,14 @@ #ifdef LWLIB_DIALOGS_ATHENA || XtIsSubclass (widget, dialogWidgetClass) #endif +#ifdef LWLIB_WIDGETS_ATHENA + || XtIsSubclass (widget, labelWidgetClass) + || XtIsSubclass (widget, toggleWidgetClass) + || XtIsSubclass (widget, gaugeWidgetClass) +#if 0 + || XtIsSubclass (widget, textWidgetClass) +#endif +#endif ); } @@ -125,6 +141,16 @@ XtSetArg (al [0], XtNlabel, val->contents->value); XtSetValues (widget, al, 1); } +#endif /* LWLIB_DIALOGS_ATHENA */ +#ifdef LWLIB_WIDGETS_ATHENA + else if (XtClass (widget) =3D=3D labelWidgetClass) + { + Arg al [1]; + XtSetArg (al [0], XtNlabel, val->contents->value); + XtSetValues (widget, al, 1); + } +#endif /* LWLIB_WIDGETS_ATHENA */ +#if defined (LWLIB_DIALOGS_ATHENA) || defined (LWLIB_WIDGETS_ATHENA) else if (XtIsSubclass (widget, commandWidgetClass)) { Dimension bw =3D 0; @@ -154,6 +180,14 @@ XtRemoveAllCallbacks (widget, XtNcallback); XtAddCallback (widget, XtNcallback, xaw_generic_callback,= instance); +#ifdef LWLIB_WIDGETS_ATHENA + /* set the selected state */ + if (XtIsSubclass (widget, toggleWidgetClass)) + { + XtSetArg (al [0], XtNstate, val->selected); + XtSetValues (widget, al, 1); + } +#endif /* LWLIB_WIDGETS_ATHENA */ } #endif /* LWLIB_DIALOGS_ATHENA */ } @@ -162,9 +196,34 @@ xaw_update_one_value (widget_instance *instance, Widget widget, widget_value *val) { - /* This function is not used by the scrollbars and those are the only - Athena widget implemented at the moment so do nothing. */ - return; +#ifdef LWLIB_WIDGETS_ATHENA + widget_value *old_wv; + + /* copy the call_data slot into the "return" widget_value */ + for (old_wv =3D instance->info->val->contents; old_wv; old_wv =3D= old_wv->next) + if (!strcmp (val->name, old_wv->name)) + { + val->call_data =3D old_wv->call_data; + break; + } + + if (XtIsSubclass (widget, toggleWidgetClass)) + { + Arg al [1]; + XtSetArg (al [0], XtNstate, &val->selected); + XtGetValues (widget, al, 1); + val->edited =3D True; + } +#if 0 + else if (XtIsSubclass (widget, asciiTextWidgetClass)) + { + if (val->value) + free (val->value); + val->value =3D XawTextGetString (widget); + val->edited =3D True; + } +#endif +#endif /* LWLIB_WIDGETS_ATHENA */ } void @@ -440,7 +499,21 @@ Widget instance_widget; LWLIB_ID id; XtPointer user_data; +#ifdef LWLIB_WIDGETS_ATHENA + /* We want the selected status to change only when we decide it + should change. Yuck but correct. */ + if (XtIsSubclass (widget, toggleWidgetClass)) + { + Boolean check; + Arg al [1]; + + XtSetArg (al [0], XtNstate, &check); + XtGetValues (widget, al, 1); + XtSetArg (al [0], XtNstate, !check); + XtSetValues (widget, al, 1); + } +#endif /* LWLIB_WIDGETS_ATHENA */ lw_internal_update_other_instances (widget, closure, call_data); if (! instance) @@ -464,17 +537,26 @@ #else /* Damn! Athena doesn't give us a way to hang our own data on the buttons, so we have to go find it... I guess this assumes that - all instances of a button have the same call data. */ + all instances of a button have the same call data. + + ... Which is a totally bogus assumption --andyp */ { - widget_value *val =3D instance->info->val->contents; - char *name =3D XtName (widget); - while (val) + widget_value *val =3D instance->info->val; + /* If the widget is a buffer/gutter widget then we already have + the one we are looking for, so don't try and descend the widget + tree. */ + if (val->contents) { - if (val->name && !strcmp (val->name, name)) - break; - val =3D val->next; + char *name =3D XtName (widget); + val =3D val->contents; + while (val) + { + if (val->name && !strcmp (val->name, name)) + break; + val =3D val->next; + } + if (! val) abort (); } - if (! val) abort (); user_data =3D val->call_data; } #endif @@ -614,12 +696,151 @@ } #endif /* LWLIB_SCROLLBARS_ATHENA */ +#ifdef LWLIB_WIDGETS_ATHENA +/* glyph widgets */ +static Widget +xaw_create_button (widget_instance *instance) +{ + Arg al[20]; + int ac =3D 0; + Widget button =3D 0; + widget_value* val =3D instance->info->val; + + XtSetArg (al [ac], XtNsensitive, val->enabled); ac++; + XtSetArg (al [ac], XtNmappedWhenManaged, FALSE); ac++; + XtSetArg (al [ac], XtNjustify, XtJustifyCenter); ac++; + /* The highlight doesn't appear to be dynamically set which makes it + look ugly. I think this may be a LessTif bug but for now we just + get rid of it. */ + XtSetArg (al [ac], XtNhighlightThickness, (Dimension)0);ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + if (!val->call_data) + button =3D XtCreateManagedWidget (val->name, labelWidgetClass, + instance->parent, al, ac); + + else + { + if (val->type =3D=3D TOGGLE_TYPE || val->type =3D=3D= RADIO_TYPE) + { + XtSetArg (al [ac], XtNstate, val->selected); ac++; + button =3D XtCreateManagedWidget + (val->name, + val->type =3D=3D TOGGLE_TYPE ? checkboxWidgetClass := radioWidgetClass, + instance->parent, al, ac); + } + else + { + button =3D XtCreateManagedWidget (val->name, commandWidgetClass, + instance->parent, al, ac); + } + XtRemoveAllCallbacks (button, XtNcallback); + XtAddCallback (button, XtNcallback, xaw_generic_callback,= (XtPointer)instance); + } + + XtManageChild (button); + + return button; +} + +Widget +xaw_create_label (Widget parent, widget_value* val) +{ + Arg al[20]; + int ac =3D 0; + Widget label =3D 0; + + XtSetArg (al [ac], XtNsensitive, val->enabled); ac++; + XtSetArg (al [ac], XtNmappedWhenManaged, FALSE); ac++; + XtSetArg (al [ac], XtNjustify, XtJustifyCenter); ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + label =3D XtCreateManagedWidget (val->name, labelWidgetClass, + parent, al, ac); + + return label; +} + +static Widget +xaw_create_progress (widget_instance *instance) +{ + Arg al[20]; + int ac =3D 0; + Widget scale =3D 0; + widget_value* val =3D instance->info->val; + + if (!val->call_data) + { + XtSetArg (al [ac], XtNsensitive, False); ac++; + } + else + { + XtSetArg (al [ac], XtNsensitive, val->enabled); ac++; + } + XtSetArg (al [ac], XtNmappedWhenManaged, FALSE); ac++; + XtSetArg (al [ac], XtNorientation, XtorientHorizontal); ac++; + XtSetArg (al [ac], XtNhighlightThickness, (Dimension)0);ac++; + XtSetArg (al [ac], XtNntics, (Cardinal)10);ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + scale =3D XtCreateManagedWidget (val->name, gaugeWidgetClass, + instance->parent, al, ac); + /* add the callback */ + if (val->call_data) + XtAddCallback (scale, XtNgetValue, xaw_generic_callback,= (XtPointer)instance); + + XtManageChild (scale); + + return scale; +} + +#if 0 +static Widget +xaw_create_text_field (widget_instance *instance) +{ + Arg al[20]; + int ac =3D 0; + Widget text =3D 0; + widget_value* val =3D instance->info->val; + + XtSetArg (al [ac], XtNsensitive, val->enabled &&= val->call_data); ac++; + XtSetArg (al [ac], XtNmappedWhenManaged, FALSE); ac++; + XtSetArg (al [ac], XtNhighlightThickness, (Dimension)0); ac++; + XtSetArg (al [ac], XtNtype, XawAsciiString); ac++; + XtSetArg (al [ac], XtNeditType, XawtextEdit); ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + text =3D XtCreateManagedWidget (val->name, asciiTextWidgetClass, + instance->parent, al, ac); + XtManageChild (text); + + return text; +} +#endif +#endif /* LWLIB_WIDGETS_ATHENA */ + widget_creation_entry xaw_creation_table [] =3D { #ifdef LWLIB_SCROLLBARS_ATHENA - {"vertical-scrollbar", xaw_create_vertical_scrollbar}, - {"horizontal-scrollbar", xaw_create_horizontal_scrollbar}, + {"vertical-scrollbar", xaw_create_vertical_scrollbar }, + = {"horizontal-scrollbar", xaw_create_horizontal_scrollbar }, +#endif +#ifdef LWLIB_WIDGETS_ATHENA + {"button", xaw_create_button }, +#if 0 + {"text-field", xaw_create_text_field }, #endif + {"progress", xaw_create_progress }, +#endif {NULL, NULL} }; + Index:= lwlib/lwlib-Xaw.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xaw.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 lwlib-Xaw.h --- lwlib/lwlib-Xaw.h 1996/12/18 22:43:40 1.1.1.1 +++ lwlib/lwlib-Xaw.h 1999/07/28 08:33:43 @@ -8,6 +8,9 @@ Widget xaw_create_dialog (widget_instance* instance); +Widget +xaw_create_label (Widget parent, widget_value* val); + Boolean lw_xaw_widget_p (Widget widget); Index:= lwlib/lwlib-Xlw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xlw.c,v retrieving revision 1.7 diff -u -r1.7 lwlib-Xlw.c --- lwlib/lwlib-Xlw.c 1998/01/19 01:57:48 1.7 +++ lwlib/lwlib-Xlw.c 1999/07/28 08:33:43 @@ -23,6 +23,7 @@ #include #include "lwlib-Xlw.h" +#include "lwlib-utils.h" #include #include #include @@ -34,6 +35,15 @@ #ifdef LWLIB_SCROLLBARS_LUCID #include "xlwscrollbar.h" #endif +#ifdef LWLIB_TABS_LUCID +#ifdef NEED_MOTIF +#include "lwlib-Xm.h" +#endif +#ifdef NEED_ATHENA +#include "lwlib-Xaw.h" +#endif +#include "xlwtabs.h" +#endif =0C @@ -301,6 +311,144 @@ #endif /* LWLIB_SCROLLBARS_LUCID */ +#ifdef LWLIB_TABS_LUCID +/* tab control + + lwlib is such an incredible hairy crock. I just cannot believe + it! There are random dependencies between functions, there is a + total lack of genericity, even though it initially appears to be + generic. It should all be junked and begun again. Building tabs are + an example - in theory we should be able to reuse a lot of the + general stuff because we want to put labels of whatever toolkit we + are using in the tab. Instead we have to hack it by hand. */ +static void +xlw_tab_control_callback (Widget w, XtPointer client_data, XtPointer= call_data) +{ + /* call data is the topmost widget */ + widget_instance* instance =3D (widget_instance*)client_data; + Widget top =3D (Widget)call_data; + char *name =3D XtName (top); + widget_value* widget_val; + XtPointer widget_arg; + LWLIB_ID id; + lw_callback post_activate_cb; + + if (w->core.being_destroyed) + return; + + /* Grab these values before running any functions, in case running + the selection_cb causes the widget to be destroyed. */ + id =3D instance->info->id; + post_activate_cb =3D instance->info->post_activate_cb; + + /* search for the widget_val for the selected tab */ + for (widget_val =3D instance->info->val->contents; widget_val; + widget_val =3D widget_val->next) + { + if (!strcmp (widget_val->name, name)) + break; + } + + widget_arg =3D widget_val ? widget_val->call_data : NULL; + + if (instance->info->selection_cb && + widget_val && + widget_val->enabled && + !widget_val->contents) + instance->info->selection_cb (w, id, widget_arg); + + if (post_activate_cb) + post_activate_cb (w, id, widget_arg); +} + +static Widget +xlw_create_tab_control (widget_instance *instance) +{ + Arg al[20]; + int ac =3D 0; + Widget tab =3D 0; + widget_value* val =3D instance->info->val; + + XtSetArg (al [ac], XtNsensitive, val->enabled); ac++; + XtSetArg (al [ac], XtNmappedWhenManaged, FALSE); ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + tab =3D XtCreateManagedWidget (val->name, tabsWidgetClass, + instance->parent, al, ac); + XtRemoveAllCallbacks (tab, XtNcallback); + XtAddCallback (tab, XtNcallback, xlw_tab_control_callback,= (XtPointer)instance); + + XtManageChild (tab); + + return tab; +} + +static void build_tabs_in_widget (widget_instance* instance, Widget widget,= + widget_value* val) +{ + widget_value* cur =3D val; + for (cur =3D val; cur; cur =3D cur->next) + { + if (cur->value) + { +#ifdef LWLIB_WIDGETS_MOTIF + xm_create_label (widget, cur); +#else + xaw_create_label (widget, cur); +#endif + } + cur->change =3D NO_CHANGE; + } +} + +static void +xlw_update_tab_control (widget_instance* instance, Widget widget,= widget_value* val) +{ + Widget* children; + unsigned int num_children; + int i; + widget_value *cur =3D 0; + + XtRemoveAllCallbacks (widget, XtNcallback); + XtAddCallback (widget, XtNcallback, xlw_tab_control_callback,= (XtPointer)instance); + + if (val->change =3D=3D STRUCTURAL_CHANGE + || + (val->contents && val->contents->change =3D=3D STRUCTURAL_CHANGE)) + { + destroy_all_children (widget); + build_tabs_in_widget (instance, widget, val->contents); + } + + children =3D XtCompositeChildren (widget, &num_children); + if (children) + { + for (i =3D 0, cur =3D val->contents; i < num_children; i++) + { + if (!cur) + abort (); + if (children [i]->core.being_destroyed + || strcmp (XtName (children [i]), cur->name)) + continue; +#ifdef NEED_MOTIF + if (lw_motif_widget_p (children [i])) + xm_update_one_widget (instance, children [i], val,= False); +#endif +#ifdef NEED_ATHENA + if (lw_xaw_widget_p (children [i])) + xaw_update_one_widget (instance, children [i], val, False); +#endif + cur =3D cur->next; + } + XtFree ((char *) children); + } + if (cur) + abort (); +} +#endif /* LWLIB_TABS_LUCID */ + widget_creation_entry xlw_creation_table [] =3D { @@ -312,6 +460,9 @@ {"vertical-scrollbar", xlw_create_vertical_scrollbar}, {"horizontal-scrollbar", xlw_create_horizontal_scrollbar}, #endif +#ifdef LWLIB_TABS_LUCID + {"tab-control", xlw_create_tab_control}, +#endif {NULL, NULL} }; @@ -327,6 +478,10 @@ if (the_class =3D=3D xlwScrollBarWidgetClass) return True; #endif +#ifdef LWLIB_TABS_LUCID + if (the_class =3D=3D tabsWidgetClass) + return True; +#endif #ifdef LWLIB_MENUBARS_LUCID if (the_class =3D=3D overrideShellWidgetClass) return @@ -340,10 +495,8 @@ xlw_update_one_widget (widget_instance* instance, Widget widget, widget_value* val, Boolean deep_p) { - WidgetClass class; + WidgetClass class =3D XtClass (widget); - class =3D XtClass (widget); - if (0) ; #ifdef LWLIB_MENUBARS_LUCID @@ -363,6 +516,12 @@ else if (class =3D=3D xlwScrollBarWidgetClass) { xlw_update_scrollbar (instance, widget, val); + } +#endif +#ifdef LWLIB_TABS_LUCID + else if (class =3D=3D tabsWidgetClass) + { + xlw_update_tab_control (instance, widget, val); } #endif } Index:= lwlib/lwlib-Xm.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xm.c,v retrieving revision 1.11.2.3 diff -u -r1.11.2.3 lwlib-Xm.c --- lwlib/lwlib-Xm.c 1999/07/05 16:35:14 1.11.2.3 +++ lwlib/lwlib-Xm.c 1999/07/28 08:33:47 @@ -60,10 +60,12 @@ #include #include #include +#ifdef LWLIB_WIDGETS_MOTIF #include #if XmVERSION > 1 #include #endif +#endif #ifdef LWLIB_MENUBARS_MOTIF static void xm_pull_down_callback (Widget, XtPointer, XtPointer); @@ -171,35 +173,6 @@ return result; } -#ifdef LWLIB_MENUBARS_MOTIF - -static void -destroy_all_children (Widget widget) -{ - Widget* children; - unsigned int number; - int i; - - children =3D XtCompositeChildren (widget, &number); - if (children) - { - /* Unmanage all children and destroy them. They will only be - * really destroyed when we get out of DispatchEvent. */ - for (i =3D 0; i < number; i++) - { - Widget child =3D children [i]; - if (!child->core.being_destroyed) - { - XtUnmanageChild (child); - XtDestroyWidget (child); - } - } - XtFree ((char *) children); - } -} - -#endif /* LWLIB_MENUBARS_MOTIF */ - =0C #ifdef LWLIB_DIALOGS_MOTIF @@ -221,7 +194,7 @@ #endif /* LWLIB_DIALOGS_MOTIF */ -#if defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_MENUBARS_MOTIF) +#if defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_MENUBARS_MOTIF) ||= defined (LWLIB_WIDGETS_MOTIF) /* update the label of anything subclass of a label */ static void @@ -777,12 +750,11 @@ XtSetArg (al [1], XmNuserData, val->call_data); XtSetValues (widget, al, 2); -#if defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_MENUBARS_MOTIF) +#if defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_MENUBARS_MOTIF) ||= defined (LWLIB_WIDGETS_MOTIF) /* Common to all label like widgets */ if (XtIsSubclass (widget, xmLabelWidgetClass)) xm_update_label (instance, widget, val); -#endif /* defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_MENUBARS_MOTIF)= */ - +#endif class =3D XtClass (widget); /* Class specific things */ if (class =3D=3D xmPushButtonWidgetClass || @@ -1566,9 +1538,10 @@ #endif /* LWLIB_SCROLLBARS_MOTIF */ +#ifdef LWLIB_WIDGETS_MOTIF /* glyph widgets */ static Widget -make_button (widget_instance *instance) +xm_create_button (widget_instance *instance) { Arg al[20]; int ac =3D 0; @@ -1615,14 +1588,21 @@ } static Widget -make_progress (widget_instance *instance) +xm_create_progress (widget_instance *instance) { Arg al[20]; int ac =3D 0; Widget scale =3D 0; widget_value* val =3D instance->info->val; - XtSetArg (al [ac], XmNsensitive, val->enabled); ac++; + if (!val->call_data) + { + XtSetArg (al [ac], XmNsensitive, False); ac++; + } + else + { + XtSetArg (al [ac], XmNsensitive, val->enabled); ac++; + } XtSetArg (al [ac], XmNalignment, XmALIGNMENT_BEGINNING); ac++; XtSetArg (al [ac], XmNuserData, val->call_data); ac++; XtSetArg (al [ac], XmNmappedWhenManaged, FALSE); ac++; @@ -1631,9 +1611,6 @@ look ugly. I think this may be a LessTif bug but for now we just get rid of it. */ XtSetArg (al [ac], XmNhighlightThickness, (Dimension)0);ac++; - if (!val->call_data) - XtSetArg (al [ac], XmNsensitive, False); ac++; - /* add any args the user supplied for creation time */ lw_add_value_args_to_args (val, al, &ac); @@ -1648,7 +1625,7 @@ } static Widget -make_text_field (widget_instance *instance) +xm_create_text_field (widget_instance *instance) { Arg al[20]; int ac =3D 0; @@ -1677,9 +1654,34 @@ return text; } +Widget +xm_create_label (Widget parent, widget_value* val) +{ + Arg al[20]; + int ac =3D 0; + Widget label =3D 0; + + XtSetArg (al [ac], XmNsensitive, val->enabled); ac++; + XtSetArg (al [ac], XmNalignment, XmALIGNMENT_BEGINNING); ac++; + XtSetArg (al [ac], XmNmappedWhenManaged, FALSE); ac++; + /* The highlight doesn't appear to be dynamically set which makes it + look ugly. I think this may be a LessTif bug but for now we just + get rid of it. */ + XtSetArg (al [ac], XmNhighlightThickness, (Dimension)0);ac++; + + /* add any args the user supplied for creation time */ + lw_add_value_args_to_args (val, al, &ac); + + label =3D XmCreateLabel (parent, val->name, al, ac); + + XtManageChild (label); + + return label; +} + #if XmVERSION > 1 static Widget -make_combo_box (widget_instance *instance) +xm_create_combo_box (widget_instance *instance) { Arg al[20]; int ac =3D 0; @@ -1708,6 +1710,7 @@ return combo; } #endif +#endif /* LWLIB_WIDGETS_MOTIF */ =0C /* Table of functions to create widgets */ @@ -1723,12 +1726,14 @@ {"vertical-scrollbar", make_vertical_scrollbar}, {"horizontal-scrollbar", make_horizontal_scrollbar}, #endif - {"button", make_button}, - {"progress", make_progress}, - {"text-field", make_text_field}, +#ifdef LWLIB_WIDGETS_MOTIF + {"button", xm_create_button}, + {"progress", xm_create_progress}, + {"text-field", xm_create_text_field}, #if XmVERSION > 1 - {"combo-box", make_combo_box}, + {"combo-box", xm_create_combo_box}, #endif +#endif {NULL, NULL} }; @@ -1736,7 +1741,7 @@ void xm_destroy_instance (widget_instance* instance) { -#ifdef LWLIB_DIALOGS_MOTIF +#if defined (LWLIB_DIALOGS_MOTIF) || defined (LWLIB_WIDGETS_MOTIF) /* It appears that this is used only for dialog boxes. */ Widget widget =3D instance->widget; /* recycle the dialog boxes */ @@ -1767,7 +1772,7 @@ XtDestroyWidget (instance->widget); } -#endif /* LWLIB_DIALOGS_MOTIF */ +#endif /* LWLIB_DIALOGS_MOTIF || LWLIB_WIDGETS_MOTIF */ } =0C/* popup utility */ @@ -1920,7 +1925,7 @@ static void xm_generic_callback (Widget widget, XtPointer closure, XtPointer= call_data) { -#if (defined (LWLIB_MENUBARS_MOTIF) || defined (LWLIB_DIALOGS_MOTIF)) +#if (defined (LWLIB_MENUBARS_MOTIF) || defined (LWLIB_DIALOGS_MOTIF) ||= defined (LWLIB_WIDGETS_MOTIF)) /* We want the selected status to change only when we decide it should change. Yuck but correct. */ if (XtClass (widget) =3D=3D xmToggleButtonWidgetClass Index:= lwlib/lwlib-Xm.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xm.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 lwlib-Xm.h --- lwlib/lwlib-Xm.h 1996/12/18 22:43:39 1.1.1.1 +++ lwlib/lwlib-Xm.h 1999/07/28 08:33:47 @@ -8,6 +8,9 @@ Widget xm_create_dialog (widget_instance* instance); +Widget +xm_create_label (Widget parent, widget_value* val); + Boolean lw_motif_widget_p (Widget widget); Index:= lwlib/lwlib-config.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-config.c,v retrieving revision 1.6 diff -u -r1.6 lwlib-config.c --- lwlib/lwlib-config.c 1998/01/19 01:57:48 1.6 +++ lwlib/lwlib-config.c 1999/07/28 08:33:47 @@ -88,3 +88,13 @@ int lwlib_does_not_support_dialogs; # endif #endif + +#ifdef LWLIB_WIDGETS_MOTIF +int lwlib_widgets_motif; +#else +# ifdef LWLIB_WIDGETS_ATHENA +int lwlib_widgets_athena; +# else +int lwlib_does_not_support_widgets; +# endif +#endif Index:= lwlib/lwlib-internal.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-internal.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 lwlib-internal.h --- lwlib/lwlib-internal.h 1996/12/18 22:43:40 1.1.1.1 +++ lwlib/lwlib-internal.h 1999/07/28 08:33:47 @@ -52,6 +52,7 @@ /* get the widget_value for a widget in a given instance */ widget_value* lw_get_widget_value_for_widget (widget_instance* instance, Widget w); +void destroy_all_children (Widget widget); widget_info *lw_get_widget_info (LWLIB_ID id); Index:= lwlib/lwlib-utils.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-utils.c,v retrieving revision 1.5 diff -u -r1.5 lwlib-utils.c --- lwlib/lwlib-utils.c 1997/06/26 02:31:59 1.5 +++ lwlib/lwlib-utils.c 1999/07/28 08:33:47 @@ -31,6 +31,31 @@ #include #include "lwlib-utils.h" +void +destroy_all_children (Widget widget) +{ + Widget* children; + unsigned int number; + int i; + + children =3D XtCompositeChildren (widget, &number); + if (children) + { + /* Unmanage all children and destroy them. They will only be + * really destroyed when we get out of DispatchEvent. */ + for (i =3D 0; i < number; i++) + { + Widget child =3D children [i]; + if (!child->core.being_destroyed) + { + XtUnmanageChild (child); + XtDestroyWidget (child); + } + } + XtFree ((char *) children); + } +} + /* Redisplay the contents of the widget, without first clearing it. */ void XtNoClearRefreshWidget (Widget widget) Index:= lwlib/lwlib.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib.c,v retrieving revision 1.13.2.1 diff -u -r1.13.2.1 lwlib.c --- lwlib/lwlib.c 1999/06/25 14:16:43 1.13.2.1 +++ lwlib/lwlib.c 1999/07/28 08:33:50 @@ -1326,3 +1326,4 @@ *offset +=3D wv->nargs; } } + Index:= lwlib/xlwcheckbox.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwcheckbox.c diff -N xlwcheckbox.c --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwcheckbox.c Wed Jul 28 01:33:52 1999 @@ -0,0 +1,420 @@ +/* Checkbox Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Checkbox.c 1.1 */ + +/* + * Checkbox.c - Checkbox button widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: June 30, 1997 + * + * Overview: This widget is identical to the Radio widget in behavior, + * except that the button is square and has a check mark. + */ + + +#include + +#include +#include +#include +#include +#include +#include "xlwcheckboxP.h" + + +/* by using the same size for the checkbox as for the diamond box, + * we can let the Radio widget do the vast majority of the work. + */ + +#define BOX_SIZE 8 +#define DRAW_CHECK 0 /* don't draw the check mark= */ + +#define= cclass(w)= ((CheckboxWidgetClass)((w)->core.widget_class)) + +#ifdef= _ThreeDP_h +#define= swid(cw)= ((cw)->threeD.shadow_width) +#else +#define= swid(cw)= ((cw)->core.border_width) +#endif + +#define= bsize(cw) (cclass(cw)->radio_class.dsize) +#define bs(cw) (bsize(cw) + 2*swid(cw)) + + +#if DRAW_CHECK +#define check_width 14 +#define check_height 14 +static u_char check_bits[] =3D { + 0x00, 0x00, 0x00, 0x20, 0x00, 0x18, 0x00, 0x0c, 0x00, 0x06, 0x00,= 0x03, + 0x8c, 0x03, 0xde, 0x01, 0xff, 0x01, 0xfe, 0x00, 0xfc, 0x00, 0x78,= 0x00, + 0x70, 0x00, 0x20,= 0x00}; +#endif + + +/**************************************************************** + * + * Full class record constant + * + ****************************************************************/ + + +#if DRAW_CHECK +static char defaultTranslations[] =3D + ": highlight()\n\ + : unpress(draw) unhighlight()\n\ + : press()\n\ + ,: unpress(nodraw) toggle()= notify()"; +#endif + + + +#define offset(field) XtOffsetOf(CheckboxRec,= field) +static XtResource resources[] =3D { + {XtNtristate, XtCTristate, XtRBoolean, sizeof(Boolean), + offset(checkbox.tristate), XtRImmediate, (XtPointer)FALSE}, +} ; +#undef offset + + /* Member functions */ + +static void CheckboxClassInit() ; +static void CheckboxInit(); +#if DRAW_CHECK +static void CheckboxRealize() ; +#endif +static void DrawCheck() ; + + + /* Action procs */ +#if DRAW_CHECK +static void CheckboxPress(), CheckboxUnpress()= ; +#endif +extern void RadioSet(), RadioUnset() ; + + + /* internal privates */ + +#if DRAW_CHECK +static XtActionsRec actionsList[] =3D +{ + {"press", CheckboxPress}, + {"unpress", CheckboxUnpress}, +} ; +#endif + +#define SuperClass ((RadioWidgetClass)&radioClassRec) + +CheckboxClassRec checkboxClassRec =3D { + { + (WidgetClass) SuperClass, /* superclass */ + "Checkbox", /* class_name */ + sizeof(CheckboxRec), /* size */ + CheckboxClassInit, /* class_initialize */ + NULL, /* class_part_initialize */ + FALSE, /* class_inited */ + CheckboxInit, /* initialize */ + NULL, /* initialize_hook */ +#if DRAW_CHECK + CheckboxRealize, /* realize */ + actionsList, /* actions */ + XtNumber(actionsList), /* num_actions */ +#else + XtInheritRealize, /* realize */ + NULL, /* actions */ + 0, /* num_actions */ +#endif + resources, /* resources */ + XtNumber(resources), /* resource_count */ + NULLQUARK, /* xrm_class */ + TRUE, /* compress_motion */ + TRUE, /* compress_exposure */ + TRUE, /* compress_enterleave */ + FALSE, /* visible_interest */ + NULL, /* destroy */ + XtInheritResize, /* resize */ + XtInheritExpose, /* expose */ + NULL, /* set_values */ + NULL, /* set_values_hook */ + XtInheritSetValuesAlmost, /* set_values_almost */ + NULL, /* get_values_hook */ + NULL, /* accept_focus */ + XtVersion, /* version */ + NULL, /* callback_private */ +#if DRAW_CHECK + defaultTranslations, /* tm_table */ +#else + XtInheritTranslations, /* tm_table */ +#endif + XtInheritQueryGeometry, /* query_geometry */ + XtInheritDisplayAccelerator, /* display_accelerator */ + NULL /* extension */ + }, /* CoreClass fields initialization */ + { + XtInheritChangeSensitive /* change_sensitive */ + }, /* SimpleClass fields initialization */ +#ifdef _ThreeDP_h + { + XtInheritXaw3dShadowDraw /* field not used */ + }, /* ThreeDClass fields initialization */ +#endif + { + 0 /* field not used */ + }, /* LabelClass fields initialization */ + { + 0 /* field not used */ + }, /* CommandClass fields initialization */ + { + RadioSet, /* Set Procedure. */ + RadioUnset, /* Unset Procedure. */ + NULL /* extension. */ + }, /* ToggleClass fields initialization */ + { + BOX_SIZE, + DrawCheck, /* draw procedure */ + NULL /* extension. */ + }, /* RadioClass fields initialization */ + { + NULL /* extension. */ + }, /* CheckboxClass fields initialization */ +}; + + /* for public consumption */ +WidgetClass checkboxWidgetClass =3D (WidgetClass)= &checkboxClassRec; + + + +=0C + + +/**************************************************************** + * + * Class Methods + * += ****************************************************************/ + +static void +CheckboxClassInit() +{ + XawInitializeWidgetSet(); +} + + +/*ARGSUSED*/ +static void +CheckboxInit(request, new, args, num_args) + Widget request, new; + ArgList args; + Cardinal *num_args; +{ +#if DRAW_CHECK + CheckboxWidget cw =3D (CheckboxWidget) new; + cw->checkbox.checkmark =3D None ; + cw->checkbox.checkmark_GC =3D None ; +#endif +} + + +#if DRAW_CHECK +static void +CheckboxRealize(w, valueMask, attributes) + Widget w ; + Mask *valueMask ; + XSetWindowAttributes *attributes ; +{ + CheckboxWidget cw =3D (CheckboxWidget) w; + XtGCMask value_mask, dynamic_mask, dontcare_mask ; + XGCValues values ; + + /* first, call superclass realize */ + (*checkboxWidgetClass->core_class.superclass->core_class.realize) + (w, valueMask, attributes); + + /* TODO: cache this via xmu */ + if( cw->checkbox.checkmark =3D=3D None ) + cw->checkbox.checkmark =3D + XCreateBitmapFromData( XtDisplay(w),= XtWindow(w), + check_bits,check_width,check_height); + + values.fill_style =3D FillStippled ; + values.stipple =3D cw->checkbox.checkmark ; + values.foreground =3D cw->label.foreground ; + value_mask =3D GCFillStyle | GCStipple | GCForeground ; + dynamic_mask =3D GCTileStipXOrigin | GCTileStipYOrigin ; + dontcare_mask =3D GCLineWidth | GCLineStyle | GCCapStyle | GCJoinStyle= | + GCFont | GCSubwindowMode | GCGraphicsExposures | + GCDashOffset | GCDashList | GCArcMode ; + cw->checkbox.checkmark_GC =3D + XtAllocateGC(w, 0, value_mask, &values, dynamic_mask, dontcare_mask)= ; +} +#endif + + +/* Function Name: CheckboxDestroy + * Description: Destroy Callback for checkbox widget. + * Arguments: w - the checkbox widget that is being destroyed. + * junk, grabage - not used. + * Returns: none. + */ + +/* ARGSUSED */ +static void +CheckboxDestroy(w, junk, garbage) +Widget w; +XtPointer junk, garbage; +{ +#if DRAW_CHECK + CheckboxWidget cw =3D (CheckboxWidget) w; + + /* TODO: cache this via xmu */ + if( cw->checkbox.checkmark !=3D None ) + XFreePixmap( XtDisplay(w), cw->checkbox.checkmark ) ; + if( cw->checkbox.checkmark_GC !=3D None ) + XtReleaseGC(w, cw->checkbox.checkmark_GC) ; +#endif +} + +=0C + +#if= DRAW_CHECK +/************************************************************ + * + * Actions Procedures + * + ************************************************************/ + +/* ARGSUSED */ +static void +CheckboxPress(w,event,params,num_params) + Widget w; + XEvent *event; + String *params; /* unused */ + Cardinal *num_params; /* unused */ +{ + CheckboxWidget cw =3D (CheckboxWidget) w ; + if( !cw->checkbox.pressed ) { + cw->checkbox.pressed =3D TRUE ; + = ((CheckboxWidgetClass)(w->core.widget_class))->radio_class.drawDiamond(w)= ; + } +} + +static void +CheckboxUnpress(w,event,params,num_params) + Widget w; + XEvent *event; + String *params; /* unused */ + Cardinal *num_params; /* unused */ +{ + CheckboxWidget cw =3D (CheckboxWidget) w ; + int i ; + + if( cw->checkbox.pressed ) { + cw->checkbox.pressed =3D FALSE ; + if( *num_params > 0 && **params =3D=3D 'd' ) + = ((CheckboxWidgetClass)(w->core.widget_class))->radio_class.drawDiamond(w); + = } +} +#endif + + + +=0C + +/************************************************************ + * + * Internal Procedures + * += ************************************************************/ + +static void +DrawCheck(w) + Widget w ; +{ + CheckboxWidget cw =3D (CheckboxWidget) w ; + Display *dpy =3D XtDisplay(w) ; + Window win =3D XtWindow(w) ; + GC gc ; + +#ifdef _ThreeDP_h + XPoint pts[6] ; +#endif + Dimension s =3D swid(cw); + Dimension bsz =3D bsize(cw); + Position bx,by ; /* Check upper-left */ + Dimension bw,bh ; +#ifdef _ThreeDP_h + GC top, bot; +#endif + GC ctr ; + + /* foreground GC */ + gc =3D XtIsSensitive(w) ? cw->command.normal_GC : cw->label.gray_GC= ; + + bw =3D bh =3D bs(cw) ; + bx =3D cw->label.internal_width ; + by =3D cw->core.height/2 - bh/2 ; + +#ifdef _ThreeDP_h + if( !cw->command.set ) { + top =3D cw->threeD.top_shadow_GC ; + bot =3D cw->threeD.bot_shadow_GC ; + } else { + top =3D cw->threeD.bot_shadow_GC ; + bot =3D cw->threeD.top_shadow_GC ; + } + ctr =3D cw->command.inverse_GC ; +#else + ctr =3D cw->command.set ? cw->command.normal_GC : cw->command.inverse_GC= ; +#endif + + XFillRectangle(dpy,win,ctr, bx+s,by+s, bsz,bsz)= ; + +#ifdef _ThreeDP_h + /* top-left shadow */ + pts[0].x =3D bx ; pts[0].y =3D by ; + pts[1].x =3D bw ; pts[1].y =3D 0 ; + pts[2].x =3D -s ; pts[2].y =3D s ; + pts[3].x =3D -bsz ; pts[3].y =3D 0 ; + pts[4].x =3D 0 ; pts[4].y =3D bsz ; + pts[5].x =3D -s ; pts[5].y =3D s ; + XFillPolygon(dpy,win,top, pts,6, Nonconvex,CoordModePrevious) ; + /* bottom-right shadow */ + pts[0].x =3D bx+bw ; pts[0].y =3D by+bh ; + pts[1].x =3D -bw ; pts[1].y =3D 0 ; + pts[2].x =3D s ; pts[2].y =3D -s ; + pts[3].x =3D bsz ; pts[3].y =3D 0 ; + pts[4].x =3D 0 ; pts[4].y =3D -bsz ; + pts[5].x =3D s ; pts[5].y =3D -s ; + XFillPolygon(dpy,win,bot, pts,6, Nonconvex,CoordModePrevious)= ; +#else + XDrawRectangle(dpy,win,gc, bx+s,by+s, bsz,bsz) ; +#endif + +#if DRAW_CHECK + if( cw->command.set && cw->checkbox.checkmark_GC !=3D None ) { + XSetTSOrigin(dpy,cw->checkbox.checkmark_GC, bx+s, by+s) ; + XFillRectangle(dpy,win,cw->checkbox.checkmark_GC, + bx+s, by+s, check_width,check_height) ; + } +#endif +} Index:= lwlib/xlwcheckbox.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwcheckbox.h diff -N xlwcheckbox.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwcheckbox.h Wed Jul 28 01:33:52 1999 @@ -0,0 +1,103 @@ +/* Checkbox Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Checkbox.h 1.1 */ + +/* + * Checkbox.h - Checkbox widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: June 30, 1997 + */ + +#ifndef _XawCheckbox_h +#define= _XawCheckbox_h + +/*********************************************************************** + * + * Checkbox Widget + * + * The Checkbox widget is identical to the Radio widget in behavior but + * not in appearance. The Checkbox widget looks like a small diamond + * shaped button to the left of the label. + * += ***********************************************************************/ + +#include "xlwradio.h" + +/* Resources: + + Name Class RepType Default Value + ---- ----- ------- ------------- + tristate Tristate Boolean FALSE + + radioGroup RadioGroup Widget NULL + radioData RadioData Pointer (XPointer) Widget + state State Boolean Off + background Background Pixel XtDefaultBackground + bitmap Pixmap Pixmap None + border BorderColor Pixel XtDefaultForeground + borderWidth BorderWidth Dimension 1 + callback Callback Pointer NULL + cursor Cursor Cursor None + destroyCallback Callback Pointer NULL + font Font XFontStructx* XtDefaultFont + foreground Foreground Pixel XtDefaultForeground + height Height Dimension text height + highlightThickness Thickness Dimension 2 + insensitiveBorder sensitive Pixmap Gray + internalHeight Height Dimension 2 + internalWidth Width Dimension 4 + justify Justify XtJustify XtJustifyCenter + label Label String NULL + mappedWhenManaged MappedWhenManaged Boolean True + resize Resize Boolean True + sensitive Sensitive Boolean True + width Width Dimension text width + x Position Position 0 + y Position Position 0 + +*/ + +/* + * These should be in StringDefs.h but aren't so we will define + * them here if they are needed. += */ + + +#define XtCTristate "Tristate" + +#define XtNtristate "tristate" + +extern WidgetClass checkboxWidgetClass; + +typedef struct _CheckboxClassRec *CheckboxWidgetClass; +typedef struct _CheckboxRec = *CheckboxWidget; + + +/************************************************************ + * + * Public Functions + * + ************************************************************/ + +#endif /* _XawCheckbox_h */ Index:= lwlib/xlwcheckboxP.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwcheckboxP.h diff -N xlwcheckboxP.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwcheckboxP.h Wed Jul 28 01:33:52 1999 @@ -0,0 +1,95 @@ +/* Checkbox Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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. */ + +/* + * CheckboxP.h - Private definitions for Checkbox widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: June 30, 1997 + */ + +#ifndef _XawCheckboxP_h +#define _XawCheckboxP_h + +#include "xlwcheckbox.h" +#include "xlwradioP.h" + +/************************************ + * + * Class structure + * + ***********************************/ + + /* New fields for the Checkbox widget class record */ +typedef struct _CheckboxClass { + XtPointer extension; +} CheckboxClassPart; + + /* Full class record declaration */ +typedef struct _CheckboxClassRec { + CoreClassPart core_class; + SimpleClassPart simple_class; +#ifdef _ThreeDP_h + ThreeDClassPart threeD_class; +#endif + LabelClassPart label_class; + CommandClassPart command_class; + ToggleClassPart toggle_class; + RadioClassPart radio_class; + CheckboxClassPart checkbox_class; +} CheckboxClassRec; + +extern CheckboxClassRec= checkboxClassRec; + +/*************************************** + * + * Instance (widget) structure + * + **************************************/ + + /* New fields for the Checkbox widget record */ +typedef struct { + /* resources */ + Boolean tristate ; + + /* private data */ + Boolean pressed ; + Pixmap checkmark ; /* TODO: share these via xmu? */ + GC checkmark_GC ; + XtPointer extension; +} CheckboxPart; + + /* Full widget declaration */ +typedef struct _CheckboxRec { + CorePart core; + SimplePart simple; +#ifdef _ThreeDP_h + ThreeDPart threeD; +#endif + LabelPart label; + CommandPart command; + TogglePart toggle; + RadioPart radio; + CheckboxPart checkbox; +} CheckboxRec; + +#endif /* _XawCheckboxP_h */ Index:= lwlib/xlwgauge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwgauge.c diff -N xlwgauge.c --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwgauge.c Wed Jul 28 01:33:55 1999 @@ -0,0 +1,1125 @@ +/* Gauge Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Gauge.c 1.2 */ + +/* + * Gauge.c - Gauge widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: July 9, 1997 + * + * Note: for fun and demonstration purposes, I have added selection + * capabilities to this widget. If you select the widget, you create + * a primary selection containing the current value of the widget in + * both integer and string form. If you copy into the widget, the + * primary selection is converted to an integer value and the gauge is + * set to that value. + */ + +/* TODO: display time instead of value + */ + +#define DEF_LEN 50 /* default width (or height for vertical gauge)= */ +#define MIN_LEN 10 /* minimum reasonable width (height)= */ +#define TIC_LEN 6 /* length of tic marks */ +#define GA_WID 3 /* width of gauge */ +#define MS_PER_SEC 1000 + +#include +#include +#include +#include +#include +#include "xlwgaugeP.h" + +#include +#include +#include +#include + +#include +#include + + + +/**************************************************************** + * + * Gauge resources + * += ****************************************************************/ + + +static char defaultTranslations[] =3D + ": select()\n\ + F1: select(CLIPBOARD)\n\ + : paste()\n\ + F2: paste(CLIPBOARD)" ; + + + +#define offset(field) XtOffsetOf(GaugeRec, field) +static XtResource resources[] =3D { + {XtNvalue, XtCValue, XtRInt, sizeof(int), + offset(gauge.value), XtRImmediate, (XtPointer)0}, + {XtNminValue, XtCMinValue, XtRInt, sizeof(int), + offset(gauge.v0), XtRImmediate, (XtPointer)0}, + {XtNmaxValue, XtCMaxValue, XtRInt, sizeof(int), + offset(gauge.v1), XtRImmediate, (XtPointer)100}, + {XtNntics, XtCNTics, XtRInt, sizeof(int), + offset(gauge.ntics), XtRImmediate, (XtPointer) 0}, + {XtNnlabels, XtCNLabels, XtRInt, sizeof(int), + offset(gauge.nlabels), XtRImmediate, (XtPointer) 0}, + {XtNlabels, XtCLabels, XtRStringArray, sizeof(String= *), + offset(gauge.labels), XtRStringArray, NULL}, + {XtNautoScaleUp, XtCAutoScaleUp, XtRBoolean,= sizeof(Boolean), + offset(gauge.autoScaleUp), XtRImmediate, FALSE}, + {XtNautoScaleDown, XtCAutoScaleDown, XtRBoolean,= sizeof(Boolean), + offset(gauge.autoScaleDown), XtRImmediate, FALSE}, + {XtNorientation, XtCOrientation, XtROrientation,= sizeof(XtOrientation), + offset(gauge.orientation), XtRImmediate, (XtPointer)XtorientHorizontal}, + {XtNupdate, XtCInterval, XtRInt, sizeof(int), + offset(gauge.update), XtRImmediate, (XtPointer)0}, + {XtNgetValue, XtCCallback, XtRCallback,= sizeof(XtPointer), + offset(gauge.getValue), XtRImmediate, (XtPointer)NULL}, +}; +#undef offset + + + + /* member functions */ + +static void GaugeClassInit(), GaugeInit() ; +static void GaugeResize(), GaugeExpose(), GaugeDestroy()= ; +static Boolean GaugeSetValues()= ; +static XtGeometryResult GaugeQueryGeometry() ; + + /* action procs */ + +static void GaugeSelect() ; +static void GaugePaste() ; + + /* internal privates */ + +static void GaugeSize() ; /* return preferred gauge size= */ +static void AutoScale() ; /* re compute v0,v1 */ +static void MaxLabel() ; /* find max label size= */ +static void EnableUpdate(), DisableUpdate() ; +static void GaugeGetValue() ; +static void GaugeMercury() ; + +static Boolean GaugeConvert() ; +static void GaugeLoseSel() ; +static void GaugeDoneSel() ; +static void GaugeGetSelCB() ; + +static GC Get_GC() ; + + +static XtActionsRec actionsList[] =3D +{ + {"select", GaugeSelect}, + {"paste", GaugePaste}, +}= ; + + + +/**************************************************************** + * + * Full class record constant + * += ****************************************************************/ + +GaugeClassRec gaugeClassRec =3D { + { +/* core_class fields */ + /* superclass */ (WidgetClass) &labelClassRec, + /* class_name */ "Gauge", + /* widget_size */ sizeof(GaugeRec), + /* class_initialize */ GaugeClassInit, + /* class_part_initialize */ NULL, + /* class_inited */ FALSE, + /* initialize */ GaugeInit, + /* initialize_hook */ NULL, + /* realize */ XtInheritRealize, /* TODO? */ + /* actions */ actionsList, + /* num_actions */ XtNumber(actionsList), + /* resources */ resources, + /* num_resources */ XtNumber(resources), + /* xrm_class */ NULLQUARK, + /* compress_motion */ TRUE, + /* compress_exposure */ TRUE, + /* compress_enterleave */ TRUE, + /* visible_interest */ FALSE, + /* destroy */ GaugeDestroy, + /* resize */ GaugeResize, + /* expose */ GaugeExpose, + /* set_values */ GaugeSetValues, + /* set_values_hook */ NULL, + /* set_values_almost */ XtInheritSetValuesAlmost, + /* get_values_hook */ NULL, + /* accept_focus */ NULL, + /* version */ XtVersion, + /* callback_private */ NULL, + /* tm_table */ defaultTranslations, + /* query_geometry */ GaugeQueryGeometry, + /* display_accelerator */ XtInheritDisplayAccelerator, + /* extension */ NULL + }, +/* Simple class fields initialization */ + { + /* change_sensitive */ XtInheritChangeSensitive + }, +#ifdef _ThreeDP_h +/* ThreeD class fields initialization */ + { + XtInheritXaw3dShadowDraw /* shadowdraw */ + }, +#endif +/* Label class fields initialization */ + { + /* ignore */ 0 + }, +/* Gauge class fields initialization */ + { + /* extension */ NULL + }, +}; + +WidgetClass gaugeWidgetClass =3D= (WidgetClass)&gaugeClassRec; + + +=0C + +/**************************************************************** + * + * Member Procedures + * += ****************************************************************/ + +static void +GaugeClassInit() +{ + XawInitializeWidgetSet(); + XtAddConverter(XtRString, XtROrientation, XmuCvtStringToOrientation, + NULL, 0) ; +} + + + +/* ARGSUSED */ +static void +GaugeInit(request, new, args, num_args) + Widget request, new; + ArgList args; + Cardinal *num_args; +{ + GaugeWidget gw =3D (GaugeWidget) new; + + if( gw->gauge.v0 =3D=3D 0 && gw->gauge.v1 =3D=3D 0 ) { + gw->gauge.autoScaleUp =3D gw->gauge.autoScaleDown =3D TRUE ; + AutoScale(gw) ; + } + + /* If size not explicitly set, set it to our preferred size now. = */ + + if( request->core.width =3D=3D 0 || request->core.height =3D=3D 0 ) + { + Dimension w,h ; + GaugeSize(gw, &w,&h, DEF_LEN) ; + if( request->core.width =3D=3D 0 ) + new->core.width =3D w ; + if( request->core.height =3D=3D 0 ) + new->core.height =3D h ; + gw->core.widget_class->core_class.resize(new) ; + } + + gw->gauge.selected =3D None ; + gw->gauge.selstr =3D NULL ; + + if( gw->gauge.update > 0 ) + EnableUpdate(gw) ; + + gw->gauge.inverse_GC =3D Get_GC(gw, gw->core.background_pixel)= ; +} + +static void +GaugeDestroy(w) + Widget w; +{ + GaugeWidget gw =3D (GaugeWidget)w; + + if( gw->gauge.selstr !=3D NULL ) + XtFree(gw->gauge.selstr) ; + + if( gw->gauge.selected !=3D None ) + XtDisownSelection(w, gw->gauge.selected, CurrentTime)= ; + + XtReleaseGC(w, gw->gauge.inverse_GC) ; + + if( gw->gauge.update > 0 ) + DisableUpdate(gw) ; +} + + +/* React to size change from manager. Label widget will compute some + * internal stuff, but we need to override. + */ + +static void +GaugeResize(w) + Widget w; +{ + GaugeWidget gw =3D (GaugeWidget)w; + int size ; /* height (width) of gauge */ + int vmargin ; /* vertical (horizontal) margin */ + int hmargin ; /* horizontal (vertical) margin */ + + vmargin =3D gw->gauge.orientation =3D=3D XtorientHorizontal ? + gw->label.internal_height : gw->label.internal_width ; + hmargin =3D gw->gauge.orientation =3D=3D XtorientHorizontal ? + gw->label.internal_width : gw->label.internal_height ; + + /* TODO: need to call parent resize proc? I don't think so since + * we're recomputing everything from scratch anyway. + */ + + /* find total height (width) of contents */ + + size =3D GA_WID+2 ; /* gauge itself + edges */ + + if( gw->gauge.ntics > 1 ) /* tic marks */ + size +=3D vmargin + TIC_LEN ; + + if( gw->gauge.nlabels > 1 ) + { + Dimension lwm, lw0, lw1 ; /* width of max, left, right labels */ + Dimension lh ; + + MaxLabel(gw,&lwm,&lh, &lw0,&lw1) ; + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + { + gw->gauge.margin0 =3D lw0 / 2 ; + gw->gauge.margin1 =3D lw1 / 2 ; + size +=3D lh + vmargin ; + } + else + { + gw->gauge.margin0 =3D + gw->gauge.margin1 =3D lh / 2 ; + size +=3D lwm + vmargin ; + } + } + else + gw->gauge.margin0 =3D gw->gauge.margin1 =3D 0 ; + + gw->gauge.margin0 +=3D hmargin ; + gw->gauge.margin1 +=3D hmargin ; + + /* Now distribute height (width) over components */ + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + gw->gauge.gmargin =3D (gw->core.height-size)/2 ; + else + gw->gauge.gmargin =3D (gw->core.width-size)/2 ; + + gw->gauge.tmargin =3D gw->gauge.gmargin + GA_WID+2 + vmargin ; + if( gw->gauge.ntics > 1 ) + gw->gauge.lmargin =3D gw->gauge.tmargin + TIC_LEN + vmargin ; + else + gw->gauge.lmargin =3D gw->gauge.tmargin ; +} + +/* + * Repaint the widget window + */ + +/* ARGSUSED */ +static void +GaugeExpose(w, event, region) + Widget w; + XEvent *event; + Region region; +{ + GaugeWidget gw =3D (GaugeWidget) w; +register Display *dpy =3D XtDisplay(w) ; +register Window win =3D XtWindow(w) ; + GC gc; /* foreground, background */ + GC gctop, gcbot ; /* dark, light shadows */ + + int len ; /* length (width or height) of widget */ + int hgt ; /* height (width) of widget */ + int e0,e1 ; /* ends of the gauge */ + int x ; + int y ; /* vertical (horizontal) position */ + int i ; + int v0 =3D gw->gauge.v0 ; + int v1 =3D gw->gauge.v1 ; + int value =3D gw->gauge.value ; + + gc =3D XtIsSensitive(w) ? gw->label.normal_GC : gw->label.gray_GC= ; + + +#ifdef _ThreeDP_h + gctop =3D gw->threeD.bot_shadow_GC ; + gcbot =3D gw->threeD.top_shadow_GC ; +#else + gctop =3D gcbot =3D gc ; +#endif + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) { + len =3D gw->core.width ; + hgt =3D gw->core.height ; + } else { + len =3D gw->core.height ; + hgt =3D gw->core.width ; + } + + /* if the gauge is selected, signify by drawing the background + * in a constrasting color. + */ + + if( gw->gauge.selected ) + { + XFillRectangle(dpy,win, gc, 0,0, w->core.width,w->core.height) ; + gc =3D gw->gauge.inverse_GC ; + } + + e0 =3D gw->gauge.margin0 ; /* left (top) end */ + e1 =3D len - gw->gauge.margin1 -1 ; /* right (bottom) end */ + + /* Draw the Gauge itself */ + + y =3D gw->gauge.gmargin ; + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) /* horizontal= */ + { + XDrawLine(dpy,win,gctop, e0+1,y, e1-1,y) ; + XDrawLine(dpy,win,gctop, e0,y+1, e0,y+GA_WID) ; + XDrawLine(dpy,win,gcbot, e0+1, y+GA_WID+1, e1-1, y+GA_WID+1) ; + XDrawLine(dpy,win,gcbot, e1,y+1, e1,y+GA_WID) ; + } + else /* vertical */ + { + XDrawLine(dpy,win,gctop, y,e0+1, y,e1-1) ; + XDrawLine(dpy,win,gctop, y+1,e0, y+GA_WID,e0) ; + XDrawLine(dpy,win,gcbot, y+GA_WID+1,e0+1, y+GA_WID+1, e1-1) ; + XDrawLine(dpy,win,gcbot, y+1,e1,=20y+GA_WID,e1) ; + } + + + /* draw the mercury */ + + GaugeMercury(dpy, win, gc, gw, 0,value) ; + + + if( gw->gauge.ntics > 1 ) + { + y =3D gw->gauge.tmargin ; + for(i=3D0; igauge.ntics; ++i) + { + x =3D e0 + i*(e1-e0-1)/(gw->gauge.ntics-1) ; + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) { + XDrawLine(dpy,win,gcbot, x,y+1, x,y+TIC_LEN-2) ; + XDrawLine(dpy,win,gcbot, x,y, x+1,y) ; + XDrawLine(dpy,win,gctop, x+1,y+1, x+1,y+TIC_LEN-2) ; + XDrawLine(dpy,win,gctop, x,y+TIC_LEN-1, x+1,y+TIC_LEN-1) ; + } + else { + XDrawLine(dpy,win,gcbot, y+1,x, y+TIC_LEN-2,x) ; + XDrawLine(dpy,win,gcbot, y,x, y,x+1) ; + XDrawLine(dpy,win,gctop, y+1,x+1, y+TIC_LEN-2,x+1) ; + XDrawLine(dpy,win,gctop, y+TIC_LEN-1,x, y+TIC_LEN-1,x+1) ; + } + } + } + + /* draw labels */ + if( gw->gauge.nlabels > 1 ) + { + char label[20], *s =3D label ; + int len, w,h =3D0 ; + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + y =3D gw->gauge.lmargin + gw->label.font->max_bounds.ascent - 1 ; + else { + y =3D gw->gauge.lmargin ; + h =3D gw->label.font->max_bounds.ascent / 2 ; + } + + for(i=3D0; igauge.nlabels; ++i) + { + if( gw->gauge.labels =3D=3D NULL ) + sprintf(label, "%d", v0+i*(v1 - v0)/(gw->gauge.nlabels - 1)) ; + else + s =3D gw->gauge.labels[i] ; + if( s !=3D NULL ) { + x =3D e0 + i*(e1-e0-1)/(gw->gauge.nlabels-1) ; + len =3D strlen(s) ; + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) { + w =3D XTextWidth(gw->label.font, s, len) ; + XDrawString(dpy,win,gc, x-w/2,y, s,len) ; + } + else { + XDrawString(dpy,win,gc, y,x+h, s,len) ; + } + } + } + } +} + + +/* + * Set specified arguments into widget + */ + +static Boolean +GaugeSetValues(old, request, new, args, num_args) + Widget old, request, new; + ArgList args; + Cardinal *num_args; +{ + GaugeWidget oldgw =3D (GaugeWidget) old; + GaugeWidget gw =3D (GaugeWidget) new; + Boolean was_resized =3D False; + + if( gw->gauge.selected !=3D None ) { + XtDisownSelection(new, gw->gauge.selected, CurrentTime) ; + gw->gauge.selected =3D None ; + } + + /* Changes to v0,v1,labels, ntics, nlabels require resize & redraw.= */ + /* Change to value requires redraw and possible resize if autoscale= */ + + was_resized =3D + gw->gauge.v0 !=3D oldgw->gauge.v0 || + gw->gauge.v1 !=3D oldgw->gauge.v1 || + gw->gauge.ntics !=3D oldgw->gauge.ntics || + gw->gauge.nlabels !=3D oldgw->gauge.nlabels || + gw->gauge.labels !=3D oldgw->gauge.labels ; + + if( (gw->gauge.autoScaleUp && gw->gauge.value > gw->gauge.v1) || + (gw->gauge.autoScaleDown && gw->gauge.value < gw->gauge.v1/3 )) + { + AutoScale(gw) ; + was_resized =3D TRUE ; + } + + if( was_resized ) { + if( gw->label.resize ) + GaugeSize(gw, &gw->core.width, &gw->core.height, DEF_LEN) ; + else + GaugeResize(new) ; + } + + if( gw->gauge.update !=3D oldgw->gauge.update ) + { + if( gw->gauge.update > 0 ) + EnableUpdate(gw) ; + else + DisableUpdate(gw) ; + } + + if( gw->core.background_pixel !=3D oldgw->core.background_pixel ) + { + XtReleaseGC(new, gw->gauge.inverse_GC) ; + gw->gauge.inverse_GC =3D Get_GC(gw, gw->core.background_pixel)= ; + } + + return was_resized || gw->gauge.value !=3D oldgw->gauge.value || + XtIsSensitive(old) !=3D XtIsSensitive(new); +} + + +static XtGeometryResult +GaugeQueryGeometry(w, intended, preferred) + Widget w; + XtWidgetGeometry *intended, *preferred; +{ + register GaugeWidget gw =3D (GaugeWidget)w; + + if( intended->width =3D=3D w->core.width && + intended->height =3D=3D w->core.height ) + return XtGeometryNo ; + + preferred->request_mode =3D CWWidth | CWHeight; + GaugeSize(gw, &preferred->width, &preferred->height, DEF_LEN) ; + + if( (!(intended->request_mode & CWWidth) || + intended->width >=3D preferred->width) && + (!(intended->request_mode & CWHeight) || + intended->height >=3D preferred->height) ) + return XtGeometryYes; + else + return= XtGeometryAlmost; +} + + +=0C + +/**************************************************************** + * + * Action Procedures + * += ****************************************************************/ + +static void +GaugeSelect(w,event,params,num_params) + Widget w ; + XEvent *event ; + String *params ; + Cardinal *num_params ; +{ + GaugeWidget gw =3D (GaugeWidget)w ; + Atom seln =3D XA_PRIMARY ; + + if( gw->gauge.selected !=3D None ) { + XtDisownSelection(w, gw->gauge.selected, CurrentTime) ; + gw->gauge.selected =3D None ; + } + + if( *num_params > 0 ) { + seln =3D XInternAtom(XtDisplay(w), params[0], False) ; + printf("atom %s is %ld\n", params[0], seln) ; + } + + if( ! XtOwnSelection(w, seln, event->xbutton.time,= GaugeConvert, + GaugeLoseSel, GaugeDoneSel) ) + { + /* in real code, this error message would be replaced by + * something more elegant, or at least deleted + */ + + fprintf(stderr, "Gauge failed to get selection, try again\n")= ; + } + else + { + gw->gauge.selected =3D TRUE ; + gw->gauge.selstr =3D (String)XtMalloc(4*sizeof(int)) ; + sprintf(gw->gauge.selstr, "%d", gw->gauge.value) ; + GaugeExpose(w) ; + } +} + + +static Boolean +GaugeConvert(w, selection, target, type, value, length, format) + Widget w ; + Atom *selection ; /* usually XA_PRIMARY */ + Atom *target ; /* requested target */ + Atom *type ; /* returned type */ + XPointer *value ; /* returned value */ + u_long *length ; /* returned length */ + int *format ; /* returned format */ +{ + GaugeWidget gw =3D (GaugeWidget)w ; + XSelectionRequestEvent *req ; + + printf( "requesting selection %s:%s\n", + XGetAtomName(XtDisplay(w),*selection), + XGetAtomName(XtDisplay(w),*target)); + + if( *target =3D=3D XA_TARGETS(XtDisplay(w)) ) + { + Atom *rval, *stdTargets ; + u_long stdLength ; + + /* XmuConvertStandardSelection can handle this. This function + * will return a list of standard targets. We prepend TEXT, + * STRING and INTEGER to the list and return it. + */ + + req =3D XtGetSelectionRequest(w, *selection, NULL) ; + XmuConvertStandardSelection(w, req->time, selection, target, + type, (XPointer*)&stdTargets, &stdLength, format) ; + + *type =3D XA_ATOM ; /* TODO: needed? */ + *length =3D stdLength + 3 ; + rval =3D (Atom *) XtMalloc(sizeof(Atom)*(stdLength+3)) ; + *value =3D (XtPointer) rval ; + *rval++ =3D XA_INTEGER ; + *rval++ =3D XA_STRING ; + *rval++ =3D XA_TEXT(XtDisplay(w)) ; + bcopy((char *)stdTargets, (char *)rval, stdLength*sizeof(Atom)) ; + XtFree((char*) stdTargets) ; + *format =3D 8*sizeof(Atom) ; /* TODO: needed? */ + return True ; + } + + else if( *target =3D=3D XA_INTEGER ) + { + *type =3D XA_INTEGER ; + *length =3D 1 ; + *value =3D (XtPointer) &gw->gauge.value ; + *format =3D 8*sizeof(int) ; + return True ; + } + + else if( *target =3D=3D XA_STRING || + *target =3D=3D XA_TEXT(XtDisplay(w)) ) + { + *type =3D *target ; + *length =3D strlen(gw->gauge.selstr)*sizeof(char) ; + *value =3D (XtPointer) gw->gauge.selstr ; + *format =3D 8 ; + return True ; + } + + else + { + /* anything else, we just give it to XmuConvertStandardSelection()= */ + + req =3D XtGetSelectionRequest(w, *selection, NULL) ; + if( XmuConvertStandardSelection(w, req->time, selection, target, + type, value, length, format) ) + return True ; + else { + printf( + "Gauge: requestor is requesting unsupported selection %s:%s\n", + = = XGetAtomName(XtDisplay(w),*selection), + XGetAtomName(XtDisplay(w),*target)); + return False ; + } + } +} + + + +static void +GaugeLoseSel(w, selection) + Widget w ; + Atom *selection ; /* usually XA_PRIMARY */ +{ + GaugeWidget gw =3D (GaugeWidget)w ; + Display *dpy =3D XtDisplay(w) ; + Window win =3D XtWindow(w) ; + + if( gw->gauge.selstr !=3D NULL ) { + XtFree(gw->gauge.selstr) ; + gw->gauge.selstr =3D NULL ; + } + + gw->gauge.selected =3D False ; + XClearWindow(dpy,win) ; + GaugeExpose(w) ; +} + + +static void +GaugeDoneSel(w, selection, target) + Widget w ; + Atom *selection ; /* usually XA_PRIMARY */ + Atom *target ; /* requested target */ +{ + /* selection done, anything to do? */ +} + + +static void +GaugePaste(w,event,params,num_params) + Widget w ; + XEvent *event ; + String *params ; + Cardinal *num_params ; +{ + Atom seln =3D XA_PRIMARY ; + + if( *num_params > 0 ) { + seln =3D XInternAtom(XtDisplay(w), params[0], False) ; + printf("atom %s is %ld\n", params[0], seln) ; + } + + /* try for integer value first */ + XtGetSelectionValue(w, seln, XA_INTEGER, + GaugeGetSelCB, (XtPointer)XA_INTEGER, + event->xbutton.time) ; +} + +static void +GaugeGetSelCB(w, client, selection, type, value, length, format) + Widget w ; + XtPointer client ; + Atom *selection ; + Atom *type ; + XtPointer value ; + u_long *length ; + int *format ; +{ + Display *dpy =3D XtDisplay(w) ; + Atom target =3D (Atom)client ; + int *iptr ; + char *cptr ; + + if( *type =3D=3D XA_INTEGER ) { + iptr =3D (int *)value ; + XawGaugeSetValue(w, *iptr) ; + } + + else if( *type =3D=3D XA_STRING || *type =3D=3D XA_TEXT(dpy) ) { + cptr =3D (char *)value ; + XawGaugeSetValue(w, atoi(cptr)) ; + } + + /* failed, try string */ + else if( *type =3D=3D None && target =3D=3D XA_INTEGER ) + XtGetSelectionValue(w, *selection, XA_STRING, + GaugeGetSelCB, (XtPointer)XA_STRING, + CurrentTime)= ; +} + +=0C + +/**************************************************************** + * + * Public Procedures + * + ****************************************************************/ + + + /* Change gauge value. Only undraw or draw what needs to be + * changed. + */ + +void +XawGaugeSetValue(w, value) + Widget w ; + Cardinal value ; +{ + GaugeWidget gw =3D (GaugeWidget)w ; + int oldvalue ; + GC gc ; + + if( gw->gauge.selected !=3D None ) { + XtDisownSelection(w, gw->gauge.selected, CurrentTime) ; + gw->gauge.selected =3D None ; + } + + if( !XtIsRealized(w) ) { + gw->gauge.value =3D value ; + return ; + } + + /* need to rescale? */ + if(( gw->gauge.autoScaleUp && value > gw->gauge.v1) || + (gw->gauge.autoScaleDown && value < gw->gauge.v1/3 )) + { + XtVaSetValues(w, XtNvalue, value, 0) ; + return ; + } + + oldvalue =3D gw->gauge.value ; + gw->gauge.value =3D value ; + + gc =3D XtIsSensitive(w) ? gw->label.normal_GC : gw->label.gray_GC= ; + GaugeMercury(XtDisplay(w), XtWindow(w), gc, gw, oldvalue,value)= ; +} + + +Cardinal +XawGaugeGetValue(w) + Widget w ; +{ + GaugeWidget gw =3D (GaugeWidget)w ; + return gw->gauge.value= ; +} + + +=0C + +/**************************************************************** + * + * Private Procedures + * + ****************************************************************/ + + /* draw the mercury over a specific region= */ + +static void +GaugeMercury(dpy,win,gc, gw, val0,val1) + Display *dpy ; + Window win ; + GC gc ; + GaugeWidget gw ; + Cardinal val0,val1 ; +{ + int v0 =3D gw->gauge.v0 ; + int v1 =3D gw->gauge.v1 ; + int vd =3D v1 - v0 ; + Dimension len ; /* length (width or height) of gauge */ + Position e0, e1 ; /* gauge ends */ + Position p0, p1 ; /* mercury ends */ + int y ; /* vertical (horizontal) position */ + Boolean undraw =3D FALSE ; + + len =3D gw->gauge.orientation =3D=3D XtorientHorizontal ? + gw->core.width : gw->core.height ; + + e0 =3D gw->gauge.margin0 ; /* left (top) end */ + e1 =3D len - gw->gauge.margin1 -1 ; /* right (bottom) end */ + + if( vd <=3D 0 ) vd =3D 1 ; + + if( val0 < v0 ) val0 =3D v0 ; + else if( val0 > v1 ) val0 =3D v1 ; + if( val1 < v0 ) val1 =3D v0 ; + else if( val1 > v1 ) val1 =3D v1 ; + + p0 =3D (val0-v0)*(e1-e0-1)/vd ; + p1 =3D (val1-v0)*(e1-e0-1)/vd ; + + if( p1 =3D=3D p0 ) + return ; + + y =3D gw->gauge.gmargin ; + + if( p1 < p0 ) + { + Position tmp =3D p0 ; + p0 =3D p1 ; + p1 =3D tmp ; + gc =3D gw->label.normal_GC ; + XSetForeground(dpy,gc, gw->core.background_pixel) ; + undraw =3D TRUE ; + } + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + XFillRectangle(dpy,win,gc, e0+p0+1,y+1, p1-p0,GA_WID) ; + else + XFillRectangle(dpy,win,gc, y+1,e1-p1, GA_WID,p1-p0) ; + + if( undraw ) + XSetForeground(dpy,gc, gw->label.foreground) ; +} + + + +/* Search the labels, find the largest one. */ +/* TODO: handle vertical fonts? */ + +static void +MaxLabel(gw,wid,hgt, w0,w1) + GaugeWidget gw; + Dimension *wid, *hgt ; /* max label size */ + Dimension *w0,*w1 ; /* width of first, last labels */ +{ + char lstr[80], *lbl ; + int w ; + XFontStruct *font =3D gw->label.font ; + int i ; + int lw =3D 0; + int v0 =3D gw->gauge.v0 ; + int dv =3D gw->gauge.v1 - v0 ; + int n =3D gw->gauge.nlabels ; + + if( n > 0 ) + { + if( --n <=3D 0 ) {n =3D 1 ; v0 +=3D dv/2 ;} + + /* loop through all labels, figure out how much room they + * need. + */ + w =3D 0 ; + for(i=3D0; igauge.nlabels; ++i) + { + if( gw->gauge.labels =3D=3D NULL ) /* numeric labels */ + sprintf(lbl =3D lstr,"%d", v0 + i*dv/n) ; + else + lbl =3D gw->gauge.labels[i] ; + + if( lbl !=3D NULL ) { + lw =3D XTextWidth(font, lbl, strlen(lbl)) ; + w =3D Max( w, lw ) ; + } + else + lw =3D 0 ; + + if( i =3D=3D 0 && w0 !=3D NULL ) *w0 =3D lw ; + } + if( w1 !=3D NULL ) *w1 =3D lw ; + + *wid =3D w ; + *hgt =3D font->max_bounds.ascent + font->max_bounds.descent= ; + } + else + *wid =3D *hgt =3D 0 ; +} + + +/* Determine the preferred size for this widget. choose 100x100 for + * debugging. + */ + +static void +GaugeSize(gw,wid,hgt, min_len) + GaugeWidget gw; + Dimension *wid, *hgt, min_len ; +{ + int w,h ; /* width, height of gauge */ + int vmargin ; /* vertical margin */ + int hmargin ; /* horizontal margin */ + + hmargin =3D gw->label.internal_width ; + vmargin =3D gw->label.internal_height ; + + /* find total height (width) of contents */ + + + /* find minimum size for undecorated gauge */ + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + { + w =3D min_len ; + h =3D GA_WID+2 ; /* gauge itself + edges */ + } + else + { + w =3D GA_WID+2 ; + h =3D min_len ; + } + + if( gw->gauge.ntics > 0 ) + { + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + { + w =3D Max(w, gw->gauge.ntics*3) ; + h +=3D vmargin + TIC_LEN ; + } + else + { + w +=3D hmargin + TIC_LEN ; + h =3D Max(h, gw->gauge.ntics*3) ; + } + } + + + /* If labels are requested, this gets a little interesting. + * We want the end labels centered on the ends of the gauge and + * the centers of the labels evenly spaced. The labels at the ends + * will not be the same width, meaning that the gauge itself need + * not be centered in the widget. + * + * First, determine the spacing. This is the width of the widest + * label, plus the internal margin. Total length of the gauge is + * spacing * (nlabels-1). To this, we add half the width of the + * left-most label and half the width of the right-most label + * to get the entire desired width of the widget. + */ + if( gw->gauge.nlabels > 0 ) + { + Dimension lwm, lw0, lw1 ; /* width of max, left, right labels */ + Dimension lh ; + + MaxLabel(gw,&lwm,&lh, &lw0,&lw1) ; + + if( gw->gauge.orientation =3D=3D XtorientHorizontal ) + { + lwm =3D (lwm+hmargin) * (gw->gauge.nlabels-1) + (lw0+lw1)/2 ; + w =3D Max(w, lwm) ; + h +=3D lh + vmargin ; + } + else + { + lh =3D lh*gw->gauge.nlabels + (gw->gauge.nlabels - 1)*vmargin ; + h =3D Max(h, lh) ; + w +=3D lwm + hmargin ; + } + } + + w +=3D hmargin*2 ; + h +=3D vmargin*2 ; + + *wid =3D w ; + *hgt =3D h ; +} + + + +static void +AutoScale(gw) + GaugeWidget gw; +{ + static int scales[3] =3D {1,2,5} ; + int sptr =3D 0, smult=3D1 ; + + if( gw->gauge.autoScaleDown ) + gw->gauge.v1 =3D 0 ; + while( gw->gauge.value > gw->gauge.v1 ) + { + if( ++sptr > 2 ) { + sptr =3D 0 ; + smult *=3D 10 ; + } + gw->gauge.v1 =3D scales[sptr] * smult= ; + } +} + +static void +EnableUpdate(gw) + GaugeWidget gw ; +{ + gw->gauge.intervalId =3D + XtAppAddTimeOut(XtWidgetToApplicationContext((Widget)gw), + gw->gauge.update * MS_PER_SEC, GaugeGetValue, + (XtPointer)gw) ; +} + +static void +DisableUpdate(gw) + GaugeWidget gw ; +{ + XtRemoveTimeOut(gw->gauge.intervalId)= ; +} + +static void +GaugeGetValue(clientData, intervalId) + XtPointer clientData ; + XtIntervalId intervalId ; +{ + GaugeWidget gw =3D (GaugeWidget)clientData ; + Cardinal value ; + + if( gw->gauge.update > 0 ) + EnableUpdate(gw) ; + + if( gw->gauge.getValue !=3D NULL ) + { + XtCallCallbackList((Widget)gw, gw->gauge.getValue,= (XtPointer)&value); + XawGaugeSetValue((Widget)gw, value) ; + } +} + + +static GC +Get_GC(gw, fg) + GaugeWidget gw ; + Pixel fg ; +{ + XGCValues values= ; +#define= vmask= GCForeground +#define= umask= (GCBackground|GCSubwindowMode|GCGraphicsExposures|GCDashOffset\ + |GCFont|GCDashList|GCArcMode) + + values.foreground =3D fg ; + + return XtAllocateGC((Widget)gw, 0, vmask, &values, 0L, umask) ; +} Index:= lwlib/xlwgauge.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwgauge.h diff -N xlwgauge.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwgauge.h Wed Jul 28 01:33:55 1999 @@ -0,0 +1,184 @@ +/* Gauge Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Gauge.h 1.1 */ + +/* + * Gauge.h - Gauge widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: July 8, 1997 + */ + +#ifndef _XawGauge_h +#define= _XawGauge_h + +/*********************************************************************** + * + * Gauge Widget + * + * The Gauge widget looks something like a thermometer. Application + * defines the values at the ends of the range and the current value + * and Gauge draws accordingly. Gauge does not accept input. + * += ***********************************************************************/ + +#include + +/* Resources: + + Name Class RepType Default Value + ---- ----- ------- ------------- + value Value Cardinal 0 + minValue MinValue Cardinal 0 + maxValue MaxValue Cardinal 100 + ntics NTics Cardinal 0 + + nlabels NLabels Cardinal 0 ++ + labels Labels String * NULL +++ + orientation Orientation XtOrientation horizontal + autoScaleUp AutoScaleUp Boolean FALSE ++++ + autoScaleDown AutoScaleDown Boolean FALSE ++++ + getValue Callback XtCallbackList NULL +++++ + update Interval int 0 (seconds) =3D disabled + + encoding Encoding unsigned char XawTextEncoding8bit + font Font XFontStruct* XtDefaultFont + foreground Foreground Pixel XtDefaultForeground + internalHeight Height Dimension 2 + internalWidth Width Dimension 4 + resize Resize Boolean True + background Background Pixel XtDefaultBackground + bitmap Pixmap Pixmap None + border BorderColor Pixel XtDefaultForeground + borderWidth BorderWidth Dimension 1 + cursor Cursor Cursor None + cursorName Cursor String NULL + destroyCallback Callback XtCallbackList NULL + height Height Dimension varies + insensitiveBorder Insensitive Pixmap Gray + mappedWhenManaged MappedWhenManaged Boolean True + pointerColor Foreground Pixel XtDefaultForeground + pointerColorBackground Background Pixel XtDefaultBackground + sensitive Sensitive Boolean True + width Width Dimension text width + x Position Position 0 + y Position Position 0 + + + Ntics sets the number of tic marks next to the gauge. If 0, no + tic marks will be drawn. + ++ Nlabels sets the number of labels next to the gauge. + +++ Labels is an array of nul-terminated strings to be used as labels. + If this field is NULL but nlabels is > 0, then numeric labels will= be + provided. NOTE: the labels are not copied to any internal memory;= they + must be stored in static memory provided by the appliction. + ++++ AutoScale allows the gauge to set its own value limits. Default is + False unless upper & lower limits are both 0. + + +++++ The GetValue() callback proc is called with these arguments: + static void + myGetValue(gauge, client, rval) + Widget gauge ; + XtPointer client ; + XtPointer rval ; + { + *(Cardinal *)rval =3D value ; + } + +*/ + +/* + * Resource names not provided in StringDefs.h += */ + +#ifndef= XtNvalue +#define= XtNvalue= "value" +#define= XtCValue= "Value" +#endif + +#ifndef= XtNorientation +#define= XtNorientation= "orientation" +#define= XtCOrientation= "Orientation" +#endif + +#define= XtNntics= "ntics" +#define= XtCNTics= "NTics" + +#ifndef= XtNnlabels +#define= XtNnlabels= "nlabels" +#define= XtCNLabels= "NLabels" +#endif +#ifndef= XtNlabels +#define= XtNlabels= "labels" +#define= XtCLabels= "Labels" +#endif + +#ifndef= XtNminValue +#define= XtNminValue= "minValue" +#define= XtCMinValue= "MinValue" +#endif +#ifndef= XtNmaxValue +#define= XtNmaxValue= "maxValue" +#define= XtCMaxValue= "MaxValue" +#endif + +#ifndef= XtNautoScaleUp +#define= XtNautoScaleUp= = "autoScaleUp" +#define= XtCAutoScaleUp= = "AutoScaleUp" +#define= XtNautoScaleDown= "autoScaleDown" +#define= XtCAutoScaleDown= "AutoScaleDown" +#endif + +#ifndef= XtNupdate +#define= XtNupdate= "update" +#endif + +#ifndef XtNgetValue +#define XtNgetValue "getValue" +#endif + + +/* Class record constants */ + +extern WidgetClass gaugeWidgetClass; + +typedef struct _GaugeClassRec *GaugeWidgetClass; +typedef struct _GaugeRec = *GaugeWidget; + + +_XFUNCPROTOBEGIN + +extern void XawGaugeSetValue( +#if NeedFunctionPrototypes + Widget gauge, + Cardinal value +#endif +); + +extern Cardinal XawGaugeGetValue( +#if= NeedFunctionPrototypes + Widget gauge +#endif +); + +_XFUNCPROTOEND + +#endif /* _XawGauge_h */ Index:= lwlib/xlwgaugeP.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwgaugeP.h diff -N xlwgaugeP.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwgaugeP.h Wed Jul 28 01:33:55 1999 @@ -0,0 +1,103 @@ +/* Gauge Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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. */ + +/* + * GaugeP.h - Gauge widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: July 9, 1997 + */ + +#ifndef _XawGaugeP_h +#define= _XawGaugeP_h + +/*********************************************************************** + * + * Gauge Widget Private Data + * + * Gauge has little in common with the label widget, but can make use + * of some label resources, so is subclassed from label. + * += ***********************************************************************/ + +#include "xlwgauge.h" +#include + +/* New fields for the Gauge widget class record */ + +typedef struct {XtPointer extension;} GaugeClassPart; + +/* Full class record declaration */ +typedef struct _GaugeClassRec { + CoreClassPart core_class; + SimpleClassPart simple_class; +#ifdef _ThreeDP_h + ThreeDClassPart threeD_class; +#endif + LabelClassPart label_class; + GaugeClassPart gauge_class; +} GaugeClassRec; + +extern GaugeClassRec gaugeClassRec; + +/* New fields for the Gauge widget record */ +typedef struct { + /* resources */ + int value, v0,v1 ; + int ntics, nlabels ; + String *labels ; + XtOrientation orientation ; + Boolean autoScaleUp ; /* scales automatically */ + Boolean autoScaleDown ; /* scales automatically */ + int update ; /* update interval */ + XtCallbackList getValue ; /* proc to call to fetch a point */ + + /* private state */ + Dimension gmargin ; /* edges <-> gauge */ + Dimension tmargin ; /* top (left) edge <-> tic marks */ + Dimension lmargin ; /* tic marks <-> labels */ + Dimension margin0 ; /* left/bottom margin */ + Dimension margin1 ; /* right/top margin */ + XtIntervalId intervalId ; + Atom selected ; + String selstr ; /* selection string, if any */ + GC inverse_GC ; +}= GaugePart; + + +/**************************************************************** + * + * Full instance record declaration + * += ****************************************************************/ + +typedef struct _GaugeRec { + CorePart core; + SimplePart simple; +#ifdef _ThreeDP_h + ThreeDPart threeD; +#endif + LabelPart label; + GaugePart gauge; +} GaugeRec; + +#endif /* _XawGaugeP_h */ Index:= lwlib/xlwgcs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwgcs.c diff -N xlwgcs.c --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwgcs.c Wed Jul 28 01:33:55 1999 @@ -0,0 +1,483 @@ +/* Tabs Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Gcs.c 1.3 */ + +/* #### This code is duplicated many times within lwlib and XEmacs. It + should be modularised. */ +/* + * Gcs.c - Utility functions to allocate GCs. + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: Sept 29, 1998 + */ + +/* Functions: + * + * GC AllocFgGC(w, fg, font) + * Return a GC with foreground set as specified. + * If font is None, then the returned GC is allocated with font specified + * as a "don't care" value. + * + * GC + * AllocBackgroundGC(w, font) + * Return a GC with the foreground set to the widget's background color. + * + * GC + * AllocGreyGC(w, fg, font, contrast, gp, be_nice_to_cmap) + * Widget w ; + * Pixel fg ; + * Font font ; + * int contrast ; + * Pixmap *gp ; + * int be_nice_to_cmap ; + * + * Return a GC suitable for rendering a widget in its "inactive" color. + * Normally returns a GC with a color somewhere between the widget's + * background color and the specified foreground. If font is None, then + * the returned GC is allocated with font specified as "don't care". + * If be_nice_to_cmap is True, the returned GC is created using a 50% + * dither instead of a new color. + * + * The 'gp' argument is a pointer to a Pixmap value, used to cache the + * 50% dither pattern. If *gp points to a Pixmap value, it will be used + * as the source of the 50% dither pattern. If *gp is None, then a + * dither pattern will be created and stored in gp. If gp is NULL, then + * a dither pattern will be created but not returned. + * + * GC + * AllocTopShadowGC(w, contrast, be_nice_to_cmap) + * Return a GC suitable for rendering the "top shadow" decorations of + * a widget. Returns a GC with foreground computed from widget's + * background color and contrast. If be_nice_to_cmap is True, the + * returned GC will use a foreground color of white. If widget depth + * is 1, this function will use a foreground color of black. + * + * GC + * AllocBotShadowGC(w, contrast, be_nice_to_cmap) + * Return a GC suitable for rendering the "bottom shadow" decorations + * of a widget. Returns a GC with foreground computed from widget's + * background color and contrast. If be_nice_to_cmap is True, the + * returned GC will use a foreground color of black. + * + * GC + * AllocArmGC(w, contrast, gp, be_nice_to_cmap) + * Return a GC suitable for rendering the "armed" decorations of a + * widget. This GC would typically be used to fill in the widget's + * background. Returns a GC with foreground computed from widget's + * background color and contrast. If be_nice_to_cmap is True, the + * returned GC will use a foreground color of black and a 50% dither. + * + * The 'gp' argument is as described above. + * + * void + * Draw3dBox(w, x,y,wid,hgt,s, topgc, botgc) + * Utility function. Draws a raised shadow box with outside dimensions + * as specified by x,y,wid,hgt and shadow width specified by s. + * A lowered shadow box may be generated by swapping topgc and botgc. + * += */ + +#include= + +#include= +#include= +#include= +#include= +#include + +#include "xlwgcs.h" + + /* Color & GC allocation. + * + * Frame widgets use the following graphics contexts: + * + * Foreground tab label text drawn this way + * Insensitive Fg foreground color greyed out. + * Background frame background color + * Top shadow upper-left highlight around widget + * Bottom shadow lower-right highlight around widget + * Arm shadow button pressed and ready to be released + * + * + * GC's are defined as follows, depending on attributes and + * window depth: + * + * Monochrome: + * Foreground =3D foreground color attribute or BlackPixel() + * Grey =3D Foreground color + 50% dither + * Background =3D background color attribute or WhitePixel() + * top shadow =3D foreground + * bottom shadow =3D foreground + * arm shadow =3D (what?) + * + * Color, beNiceToColormap=3Dtrue: + * Foreground =3D foreground color attribute or BlackPixel() + * Grey =3D Foreground color + 50% dither + * Background =3D background color attribute or WhitePixel() + * top shadow =3D white + * bottom shadow =3D black + * arm shadow =3D (what?) + * + * Color, beNiceToColormap=3Dfalse: + * Foreground =3D foreground color attribute or BlackPixel() + * Grey =3D (foreground color + background color)/2 + * Background =3D background color attribute or WhitePixel() + * top shadow =3D background * 1.2 + * bottom shadow =3D background * .6 + * arm shadow =3D background * .8 + * + * Special cases: + * If background is white, ?? + * if background is black, ?? + * + * + * If the widget's background is solid white or solid black, + * this code just picks some numbers. (The choice is designed + * to be compatibile with ThreeD interface.) + */ + + + +#if XtSpecificationRelease < 5 + +static GC XtAllocateGC(Widget, int, u_long, XGCValues *, u_long, u_long)= ; + +#endif + + + /* return a GC with the specified foreground and optional font= */ + +GC +AllocFgGC(w, fg, font) + Widget w; + Pixel fg ; + Font font ; +{ + XGCValues values ; + u_long vmask, dcmask ; + + values.foreground =3D fg ; + values.font =3D font ; + + if( font !=3D None ) { + vmask =3D GCForeground|GCFont ; + dcmask =3D= GCSubwindowMode|GCDashOffset| + GCDashList|GCArcMode|GCBackground|GCGraphicsExposures ; + } else { + vmask =3D GCForeground ; + dcmask =3D= GCFont|GCSubwindowMode|GCDashOffset| + GCDashList|GCArcMode|GCBackground|GCGraphicsExposures ; + } + + return XtAllocateGC(w, w->core.depth, vmask, &values, 0L, dcmask)= ; +} + + + /* return gc with widget background color as the foreground= */ + +GC +AllocBackgroundGC(w, font) + Widget w; + Font font ; +{ + return AllocFgGC(w, w->core.background_pixel, font) ; +} + + + /* Allocate an "inactive" GC. Color is grey (possibly via + * dither pattern). This function optionally returns the + * grey pixmap so the caller may cache it. + */ + +GC +AllocGreyGC(w, fg, font, contrast, be_nice_to_cmap) + Widget w ; + Pixel fg ; + Font font ; + int contrast ; + int be_nice_to_cmap ; +{ + XGCValues values ; + u_long vmask, dcmask ; + + values.foreground =3D fg ; + values.background =3D w->core.background_pixel ; + values.font =3D font ; + + if( font !=3D None ) { + vmask =3D GCForeground|GCFont ; + dcmask =3D= GCSubwindowMode|GCDashOffset| + GCDashList|GCArcMode|GCGraphicsExposures ; + } else { + vmask =3D GCForeground; + dcmask =3D= GCFont|GCSubwindowMode|GCDashOffset| + GCDashList|GCArcMode|GCGraphicsExposures ; + } + + if( be_nice_to_cmap || w->core.depth =3D=3D 1) + { + values.fill_style =3D FillStippled ; + values.stipple =3D XmuCreateStippledPixmap(XtScreen(w), 1L, 0L, 1)= ; + + vmask |=3D GCBackground|GCStipple|GCFillStyle ; + return XtAllocateGC(w, w->core.depth, vmask, &values, 0L, dcmask)= ; + } + else + { + values.foreground =3D + AllocGreyPixel(w, fg, values.background, contrast) ; + dcmask |=3D GCBackground ; + return XtAllocateGC(w, w->core.depth, vmask, &values, 0L, dcmask)= ; + } +} + + /* return top-shadow gc. */ + +GC +AllocTopShadowGC(w, contrast, be_nice_to_cmap) + Widget w; + int contrast ; + int be_nice_to_cmap ; +{ + Screen *scr =3D XtScreen (w); + XGCValues values ; + + if( w->core.depth =3D=3D 1 ) + values.foreground =3D BlackPixelOfScreen(scr) ; + else if( be_nice_to_cmap ) + values.foreground =3D WhitePixelOfScreen(scr) ; + else + values.foreground =3D AllocShadowPixel(w, 100+contrast) ; + + return XtAllocateGC(w, w->core.depth, + GCForeground, &values, + 0L, + = GCBackground|GCFont|GCSubwindowMode|GCGraphicsExposures| + GCDashOffset|GCDashList|GCArcMode) ; +} + + /* return bottom-shadow gc. */ + +GC +AllocBotShadowGC(w, contrast, be_nice_to_cmap) + Widget w ; + int contrast ; + int be_nice_to_cmap ; +{ + Screen *scr =3D XtScreen (w); + XGCValues values ; + + if( w->core.depth =3D=3D 1 || be_nice_to_cmap ) + values.foreground =3D BlackPixelOfScreen(scr) ; + else + values.foreground =3D AllocShadowPixel(w, 100-contrast) ; + + return XtAllocateGC(w, w->core.depth, + GCForeground, &values, + 0L, + = GCBackground|GCFont|GCSubwindowMode|GCGraphicsExposures| + GCDashOffset|GCDashList|GCArcMode) ; +} + + /* return arm-shadow gc. */ + +GC +AllocArmGC(w, contrast, be_nice_to_cmap) + Widget w; + int contrast ; + int be_nice_to_cmap ; +{ + Screen *scr =3D XtScreen (w); + XGCValues values ; + + /* Not clear exactly what we should do here. Take a look at + * Xaw3d to see what they do. + */ + + if( w->core.depth =3D=3D 1 || be_nice_to_cmap ) + { + values.background =3D w->core.background_pixel ; + if( values.background =3D=3D BlackPixelOfScreen(scr) ) + values.foreground =3D WhitePixelOfScreen(scr) ; + else + values.foreground =3D BlackPixelOfScreen(scr) ; + values.fill_style =3D FillStippled ; + values.stipple =3D XmuCreateStippledPixmap(XtScreen(w), 1L, 0L, 1)= ; + + return XtAllocateGC(w, w->core.depth, + GCForeground|GCBackground|GCStipple|GCFillStyle, + &values, 0L, + GCFont|GCSubwindowMode|GCGraphicsExposures| + GCDashOffset|GCDashList|GCArcMode) ; + } + else { + values.foreground =3D AllocShadowPixel(w, 100-contrast) ; + return XtAllocateGC(w, w->core.depth, + GCForeground, &values, + 0L, + GCBackground|GCFont|GCSubwindowMode|GCGraphicsExposures| + GCDashOffset|GCDashList|GCArcMode)= ; + } +} + + +Pixel +AllocShadowPixel(w, scale) + Widget w; + int scale ; +{ + XColor get_c, set_c ; + Display *dpy =3D XtDisplay(w) ; + Screen *scr =3D XtScreen(w) ; + Colormap cmap ; + Pixel maxColor ; + + cmap =3D w->core.colormap ; + + get_c.pixel =3D w->core.background_pixel ; + if( get_c.pixel =3D=3D WhitePixelOfScreen(scr) || + get_c.pixel =3D=3D BlackPixelOfScreen(scr) ) + { + /* what we *ought* to do is choose gray75 as the base color, + * or perhaps gray83. Instead, we choose colors that are + * the same as ThreeD would choose. + */ + if( scale > 100 ) scale =3D 200 - scale ; + set_c.red =3D set_c.green =3D set_c.blue =3D 65535*scale/100= ; + } + else + { + XQueryColor(dpy, cmap, &get_c) ; + /* adjust scale so that brightest component does not + * exceed 65535; otherwise hue would change. + */ + if( scale > 100 ) { + maxColor =3D Max(get_c.red, Max(get_c.green, get_c.blue)) ; + if( scale*maxColor > 65535*100 ) + scale =3D 65535*100/maxColor ; + } + set_c.red =3D scale * get_c.red / 100 ; + set_c.green =3D scale * get_c.green / 100 ; + set_c.blue =3D scale * get_c.blue / 100 ; + } + if( XAllocColor(dpy, cmap, &set_c) ) + return set_c.pixel ; + else if( scale > 100 ) + return WhitePixelOfScreen(scr) ; + else + return BlackPixelOfScreen(scr) ; +} + + + /* Allocate a pixel halfway between foreground and background= */ + +Pixel +AllocGreyPixel(w, fg, bg, cnt) + Widget w ; + Pixel fg, bg ; + int cnt ; +{ + XColor get_cf, get_cb, set_c ; + Display *dpy =3D XtDisplay(w) ; + Colormap cmap ; + + cmap =3D w->core.colormap ; + + get_cf.pixel =3D fg ; + get_cb.pixel =3D bg ; + + XQueryColor(dpy, cmap, &get_cf) ; + XQueryColor(dpy, cmap, &get_cb) ; + + set_c.red =3D (get_cf.red * cnt + get_cb.red * (100-cnt)) / 100= ; + set_c.green =3D (get_cf.green * cnt + get_cb.green * (100-cnt)) / 100= ; + set_c.blue =3D (get_cf.blue * cnt + get_cb.blue * (100-cnt)) / 100= ; + + (void)XAllocColor(dpy, cmap, &set_c) ; + return set_c.pixel ; +} + + + + + + + + + /* draw a 3-d box */ + +void +Draw3dBox(w, x,y,wid,hgt,s, topgc, botgc) + Widget w ; + int x,y ; /* position */ + int wid,hgt,s ; /* outside dimensions, shadow wid */ + GC topgc ; + GC botgc ; +{ + Display *dpy =3D XtDisplay(w) ; + Window win =3D XtWindow(w) ; + + if( s =3D=3D 0 ) return ; + + if( s =3D=3D 1 ) { + XDrawLine(dpy,win,botgc, x,y+hgt-1, x+wid-1,y+hgt-1) ; + XDrawLine(dpy,win,botgc, x+wid-1,y, x+wid-1,y+hgt-1) ; + XDrawLine(dpy,win,topgc, x,y, x,y+hgt-1) ; + XDrawLine(dpy,win,topgc, x,y, x+wid-1,y) ; + } + else + { + XPoint pts[6] ; + + /* bottom-right shadow */ + pts[0].x =3D x ; pts[0].y =3D y + hgt ; + pts[1].x =3D s ; pts[1].y =3D -s ; + pts[2].x =3D wid-2*s ; pts[2].y =3D 0 ; + pts[3].x =3D 0 ; pts[3].y =3D -(hgt-2*s) ; + pts[4].x =3D s ; pts[4].y =3D -s ; + pts[5].x =3D 0 ; pts[5].y =3D hgt ; + XFillPolygon(dpy,win,botgc, pts,6, Nonconvex,CoordModePrevious) ; + + /* top-left shadow */ + pts[0].x =3D x ; pts[0].y =3D y ; + pts[1].x =3D wid ; pts[1].y =3D 0 ; + pts[2].x =3D -s ; pts[2].y =3D s ; + pts[3].x =3D -wid+2*s ; pts[3].y =3D 0 ; + pts[4].x =3D 0 ; pts[4].y =3D hgt-2*s ; + pts[5].x =3D -s ; pts[5].y =3D s ; + XFillPolygon(dpy,win,topgc, pts,6, Nonconvex,CoordModePrevious)= ; + } +} + +#if XtSpecificationRelease < 5 + +static GC +XtAllocateGC(w, depth, mask, values, dynamic, dontcare) + Widget w ; + int depth ; + unsigned long mask, dynamic, dontcare ; + XGCValues *values ; +{ + return XtGetGC(w, mask, values) ; +} +#endif Index:= lwlib/xlwgcs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwgcs.h diff -N xlwgcs.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwgcs.h Wed Jul 28 01:33:55 1999 @@ -0,0 +1,53 @@ +/* Tabs Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Gcs 1.3= */ + +#ifndef Gcs_h + +#ifdef __STDC__ + +extern GC AllocFgGC( Widget w, Pixel fg, Font font)= ; +extern GC AllocBackgroundGC( Widget w, Font font) ; +extern GC AllocGreyGC( Widget w, Pixel fg, Font, int, int )= ; +extern GC AllocTopShadowGC( Widget w, int contrast, int )= ; +extern GC AllocBotShadowGC( Widget w, int contrast, int )= ; +extern GC AllocArmGC( Widget w, int contrast, int)= ; +extern Pixel AllocShadowPixel(Widget, int scale)= ; +extern Pixel AllocGreyPixel(Widget, Pixel fg, Pixel bg, int contrast)= ; +extern void Draw3dBox(Widget w, int x, int y, int wid, int hgt, int= s, + GC topgc, GC botgc) ; + +#else + +extern GC AllocFgGC() ; +extern GC AllocBackgroundGC() ; +extern GC AllocGreyGC() ; +extern GC AllocTopShadowGC() ; +extern GC AllocBotShadowGC() ; +extern GC AllocArmGC() ; +extern Pixel AllocShadowPixel() ; +extern Pixel AllocGreyPixel() ; +extern void Draw3dBox() ; + +#endif + +#define Gcs_h +#endif Index:= lwlib/xlwradio.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwradio.c diff -N xlwradio.c --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwradio.c Wed Jul 28 01:33:56 1999 @@ -0,0 +1,596 @@ +/* Radio Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Radio.c 1.1 */ + +/* + * Radio.c - Radio button widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: June 30, 1997 + * + * + * Overview: This widget is identical to the Toggle widget in behavior, + * but completely different in appearance. This widget looks like a= small + * diamond-shaped button with a label to the right. + * + * To make this work, we subclass the Toggle widget to inherit its= behavior + * and to inherit the label-drawing function from which Toggle is + * subclassed. We then completely replace the Expose, Set, Unset + * and Highlight member functions. + * + * The Set and Unset actions are slightly unorthodox. In Toggle's + * ClassInit function, Toggle searches the Command actions list and + * "steals" the Set and Unset functions, caching pointers to them in its + * class record. It then calls these functions from its own ToggleSet + * and Toggle actions. + * + * We, in turn, override the Set() and Unset() actions in our own= ClassRec. + */ + + +#include + +#include +#include +#include +#include +#include +#include= "xlwradioP.h" + +#define= BOX_SIZE= 13 + +#define= rclass(w)= ((RadioWidgetClass)((w)->core.widget_class)) + + +#ifdef= _ThreeDP_h +#define= swid(rw)= ((rw)->threeD.shadow_width) +#else +#define= swid(rw)= ((rw)->core.border_width) +#endif + +#define= bsize(rw) (rclass(rw)->radio_class.dsize) +#define bs(rw) (bsize(rw) += 2*swid(rw)) + + + +/**************************************************************** + * + * Full class record constant + * + ****************************************************************/ + + /* The translations table from Toggle do not need to be + * overridden by Radio + */ + + + /* Member functions */ + +static void RadioInit() ; +static void RadioExpose(), RadioResize() ; +static void RadioDestroy(), RadioClassInit(), RadioClassPartInit()= ; +static Boolean RadioSetValues(); +static void DrawDiamond()= ; +static XtGeometryResult RadioQueryGeometry(); + + + /* Action procs */ + + void RadioSet(), RadioUnset() ; +static void RadioHighlight(), RadioUnhighlight(); + + + /* internal privates */ + +static void RadioSize() ; /* find ideal size for widget */ + + /* The actions table from Toggle is almost perfect, but we need + * to override Highlight, Set, and Unset. + */ + +static XtActionsRec actionsList[] =3D +{ + {"highlight", RadioHighlight}, + {"unhighlight", RadioUnhighlight}, +}; + +#define SuperClass ((ToggleWidgetClass)&toggleClassRec) + +RadioClassRec radioClassRec =3D { + { + (WidgetClass) SuperClass, /* superclass */ + "Radio", /* class_name */ + sizeof(RadioRec), /* size */ + RadioClassInit, /* class_initialize */ + RadioClassPartInit, /* class_part_initialize */ + FALSE, /* class_inited */ + RadioInit, /* initialize */ + NULL, /* initialize_hook */ + XtInheritRealize, /* realize */ + actionsList, /* actions */ + XtNumber(actionsList), /* num_actions */ + NULL, /* resources */ + 0, /* resource_count */ + NULLQUARK, /* xrm_class */ + TRUE, /* compress_motion */ + TRUE, /* compress_exposure */ + TRUE, /* compress_enterleave */ + FALSE, /* visible_interest */ + NULL, /* destroy */ + RadioResize, /* resize */ + RadioExpose, /* expose */ + RadioSetValues, /* set_values */ + NULL, /* set_values_hook */ + XtInheritSetValuesAlmost, /* set_values_almost */ + NULL, /* get_values_hook */ + NULL, /* accept_focus */ + XtVersion, /* version */ + NULL, /* callback_private */ + XtInheritTranslations, /* tm_table */ + RadioQueryGeometry, /* query_geometry */ + XtInheritDisplayAccelerator, /* display_accelerator */ + NULL /* extension */ + }, /* CoreClass fields initialization */ + { + XtInheritChangeSensitive /* change_sensitive */ + }, /* SimpleClass fields initialization */ +#ifdef _ThreeDP_h + { + XtInheritXaw3dShadowDraw /* field not used */ + }, /* ThreeDClass fields initialization */ +#endif + { + 0 /* field not used */ + }, /* LabelClass fields initialization */ + { + 0 /* field not used */ + }, /* CommandClass fields initialization */ + { + RadioSet, /* Set Procedure. */ + RadioUnset, /* Unset Procedure. */ + NULL /* extension. */ + }, /* ToggleClass fields initialization */ + { + BOX_SIZE, + DrawDiamond, /* draw procedure */ + NULL /* extension. */ + } /* RadioClass fields initialization */ +}; + + /* for public consumption */ +WidgetClass radioWidgetClass =3D (WidgetClass)= &radioClassRec; + + + +=0C + + +/**************************************************************** + * + * Class Methods + * += ****************************************************************/ + +static void +RadioClassInit() +{ + XawInitializeWidgetSet(); +} + +static void +RadioClassPartInit(class) + WidgetClass class ; +{ + RadioWidgetClass c =3D (RadioWidgetClass) class ; + RadioWidgetClass super =3D (RadioWidgetClass)c->core_class.superclass= ; + + if( c->radio_class.drawDiamond =3D=3D NULL || + c->radio_class.drawDiamond =3D=3D XtInheritDrawDiamond ) + { + c->radio_class.drawDiamond =3D super->radio_class.drawDiamond ; + } +} + + + + +/*ARGSUSED*/ +static void +RadioInit(request, new, args, num_args) + Widget request, new; + ArgList args; + Cardinal *num_args; +{ + RadioWidget rw =3D (RadioWidget) new; + RadioWidget rw_req =3D (RadioWidget) request; + Dimension w,h ; + + /* Select initial size for the widget */ + if( rw_req->core.width =3D=3D 0 || rw_req->core.height =3D=3D 0 ) + { + RadioSize(rw, &w,&h) ; + if( rw_req->core.width =3D=3D 0 ) + rw->core.width =3D w ; + if( rw_req->core.height =3D=3D 0 ) + rw->core.height =3D h ; + rw->core.widget_class->core_class.resize(new) ; + } +} + +/* Function Name: RadioDestroy + * Description: Destroy Callback for radio widget. + * Arguments: w - the radio widget that is being destroyed. + * junk, grabage - not used. + * Returns: none. + */ + +/* ARGSUSED */ +static void +RadioDestroy(w, junk, garbage) +Widget w; +XtPointer junk, garbage; +{ + /* TODO: get rid of this */ +} + + +/* React to size change from manager. Label widget will compute some= internal + * stuff, but we need to override. This code requires knowledge of the + * internals of the Label widget. + */ + +static void +RadioResize(w) + Widget w ; +{ + RadioWidget rw =3D (RadioWidget)w ; + + /* call parent resize proc */ + SuperClass->core_class.resize(w) ; + + /* override label offset */ + + switch( rw->label.justify ) { + case XtJustifyLeft: + rw->label.label_x +=3D bs(rw) + rw->label.internal_width ; + break ; + case XtJustifyRight: + break ; + case XtJustifyCenter: + default: + rw->label.label_x +=3D (bs(rw) + rw->label.internal_width)/2 ; + break ; + } +} + + +/* + * Repaint the widget window. + */ + +static void +RadioExpose(w, event, region) + Widget w ; + XEvent *event ; + Region region ; +{ + RadioWidget rw =3D (RadioWidget) w ; + Display *dpy =3D XtDisplay(w) ; + Window win =3D XtWindow(w) ; + GC gc ; + Pixmap left_bitmap ; + extern WidgetClass labelWidgetClass ; + + /* Note: the Label widget examines the region to decide if anything + * needs to be drawn. I'm not sure that this is worth the effort, + * but it bears thinking on. + */ + + /* Command widget may sometimes override the label GC in order + * to draw inverse video. We don't use inverse video, so we need + * to restore the label's normal GC. + */ + rw->label.normal_GC =3D rw->command.normal_GC ; + + + /* Let label widget draw the label. If there was an lbm_x + * field, we could let Label draw the bitmap too. But there + * isn't, so we need to temporarily remove the bitmap and + * draw it ourself later. + */ + left_bitmap =3D rw->label.left_bitmap ; + rw->label.left_bitmap =3D None= ; + labelWidgetClass->core_class.expose(w,event,region)= ; + rw->label.left_bitmap =3D left_bitmap ; + + /* now manually draw the left bitmap. TODO: 3-d look, xaw-xpm */ + gc =3D XtIsSensitive(w) ? rw->label.normal_GC : rw->label.gray_GC ; + if( left_bitmap !=3D None && rw->label.lbm_width > 0 ) + { + /* TODO: handle pixmaps */ + XCopyPlane(dpy, left_bitmap, win, gc, + 0,0, rw->label.lbm_width, rw->label.lbm_height, + (int) rw->label.internal_width*2 + bs(rw), + (int) rw->label.internal_height + rw->label.lbm_y, + (u_long) 1L) ; + } + + /* Finally, the button itself= */ + ((RadioWidgetClass)(w->core.widget_class))->radio_class.drawDiamond(w)= ; +} + + + + +/************************************************************ + * + * Set specified arguments into widget + * + ***********************************************************/ + + +/* ARGSUSED */ +static Boolean +RadioSetValues(current, request, new, args, num_args) + Widget current, request, new; + ArgList args; + Cardinal *num_args; +{ + RadioWidget oldrw =3D (RadioWidget) current; + RadioWidget newrw =3D (RadioWidget) new; + + /* Need to find out if the size of the widget changed. Set new size + * if it did and resize is permitted. One way to determine of the + * widget changed size would be to scan the args list. Another way + * is to compare the old and new widgets and see if any of several + * size-related fields have been changed. The Label widget chose the + * former method, but I choose the latter. + */ + + if( newrw->label.resize && + ( newrw->core.width !=3D oldrw->core.width || + newrw->core.height !=3D oldrw->core.height || + newrw->core.border_width !=3D oldrw->core.border_width ) ) + { + RadioSize(newrw, &newrw->core.width, &newrw->core.height) ; + } + + return FALSE ; +} + +static XtGeometryResult +RadioQueryGeometry(w, intended, preferred) + Widget w ; + XtWidgetGeometry *intended, *preferred ; +{ + RadioWidget rw =3D (RadioWidget) w; + + preferred->request_mode =3D CWWidth | CWHeight; + RadioSize(rw, &preferred->width, &preferred->height) ; + + if ( ((intended->request_mode & (CWWidth | CWHeight)) + =3D=3D (CWWidth | CWHeight)) && + intended->width =3D=3D preferred->width && + intended->height =3D=3D preferred->height) + return XtGeometryYes; + else if (preferred->width =3D=3D w->core.width && + preferred->height =3D=3D w->core.height) + return XtGeometryNo; + else + return= XtGeometryAlmost; +} + + + +=0C + +/************************************************************ + * + * Action Procedures + * + ************************************************************/ + +/* + * Draw the highlight border around the widget. The Command widget + * did this by drawing through a mask. We do it by just drawing the + * border. + */ + +static void +DrawHighlight(w,gc) + Widget w; + GC gc ; +{ + RadioWidget rw =3D (RadioWidget)w; + XRectangle rects[4] ; + Dimension ht =3D rw->command.highlight_thickness ; + + if( ht <=3D 0 || + ht > rw->core.width/2 || + ht > rw->core.height/2 ) + return ; + + if( ! XtIsRealized(w) ) + return ; + + rects[0].x =3D 0 ; rects[0].y =3D 0 ; + rects[0].width =3D rw->core.width ; rects[0].height =3D ht ; + rects[1].x =3D 0 ; rects[1].y =3D rw->core.height - ht ; + rects[1].width =3D rw->core.width ; rects[1].height =3D ht ; + rects[2].x =3D 0 ; rects[2].y =3D ht ; + rects[2].width =3D ht ; rects[2].height =3D rw->core.height - ht*2= ; + rects[3].x =3D rw->core.width - ht ; rects[3].y =3D ht ; + rects[3].width =3D ht ; rects[3].height =3D rw->core.height - ht*2= ; + XFillRectangles( XtDisplay(w), XtWindow(w), gc, rects, 4)= ; +} + +static void +RadioHighlight(w,event,params,num_params) + Widget w ; + XEvent *event ; + String *params ; + Cardinal *num_params ; +{ + RadioWidget rw =3D (RadioWidget)w; + DrawHighlight(w, rw->command.normal_GC)= ; +} + + +static void +RadioUnhighlight(w,event,params,num_params) + Widget w ; + XEvent *event ; + String *params ; + Cardinal *num_params ; +{ + RadioWidget rw =3D (RadioWidget)w; + DrawHighlight(w, rw->command.inverse_GC) ; +} + + +/* ARGSUSED */ +void +RadioSet(w,event,params,num_params) +Widget w; +XEvent *event; +String *params; /* unused */ +Cardinal *num_params; /* unused */ +{ + RadioWidget rw =3D (RadioWidget)w; + RadioWidgetClass class =3D (RadioWidgetClass) w->core.widget_class= ; + + if( rw->command.set ) + return ; + + rw->command.set =3D TRUE ; + if( XtIsRealized(w) ) + class->radio_class.drawDiamond(w) ; +} + + +/* ARGSUSED */ +void +RadioUnset(w,event,params,num_params) +Widget w; +XEvent *event; +String *params; /* unused */ +Cardinal *num_params; /* unused */ +{ + RadioWidget rw =3D (RadioWidget)w; + RadioWidgetClass class =3D (RadioWidgetClass) w->core.widget_class= ; + + if( ! rw->command.set ) + return ; + + rw->command.set =3D FALSE ; + if( XtIsRealized(w) ) + class->radio_class.drawDiamond(w)= ; +} + + +=0C + +/************************************************************ + * + * Internal Procedures + * + ************************************************************/ + + +/* Size of widget. Width is size of box plus width of border around + * box plus width of label plus three margins plus the size of the left + * bitmap, if any. Height is max(box,bitmap,label) plus two margins. + */ + +static void +RadioSize(rw, w,h) + RadioWidget rw ; + Dimension *w, *h ; +{ + *w =3D rw->label.label_width + bs(rw) + LEFT_OFFSET(rw) + + 3 * rw->label.internal_width ; + *h =3D Max( rw->label.label_height, bs(rw) ) + + 2 * rw->label.internal_width ; +} + + +static void +DrawDiamond(w) + Widget w ; +{ + RadioWidget rw =3D (RadioWidget) w ; + Display *dpy =3D XtDisplay(w) ; + Window win =3D XtWindow(w) ; + GC gc, gci ; + + XPoint pts[5] ; + Dimension del =3D bsize(rw)/2 ; + Position x,y ; /* diamond center */ +#ifdef _ThreeDP_h + int i=3D0; + Dimension s =3D swid(rw) ; + GC top, bot, ctr ; +#endif + gc =3D XtIsSensitive(w) ? rw->command.normal_GC : rw->label.gray_GC= ; + + gci =3D rw->command.set ? rw->command.normal_GC : rw->command.inverse_GC= ; + + x =3D rw->label.internal_width + bs(rw)/2 ; + y =3D rw->core.height/2 ; + +#ifdef _ThreeDP_h + if( ! rw->command.set ) { + top =3D rw->threeD.top_shadow_GC ; + bot =3D rw->threeD.bot_shadow_GC ; + ctr =3D gc ; /* TODO */ + } else { + top =3D rw->threeD.bot_shadow_GC ; + bot =3D rw->threeD.top_shadow_GC ; + ctr =3D gc ; /* TODO */ + } +#endif + + pts[0].x =3D x - del ; + pts[0].y =3D y ; + pts[1].x =3D x ; + pts[1].y =3D y - del ; + pts[2].x =3D x + del ; + pts[2].y =3D y ; + pts[3].x =3D x ; + pts[3].y =3D y + del ; + pts[4] =3D pts[0] ; + XFillPolygon(dpy,win,gci, pts,4, Convex, CoordModeOrigin)= ; + +#ifdef _ThreeDP_h + for(i=3D0; i + +/* Resources: + + Name Class RepType Default Value + ---- ----- ------- ------------- + radioGroup RadioGroup Widget NULL + radioData RadioData Pointer (XPointer) Widget + state State Boolean Off + background Background Pixel XtDefaultBackground + bitmap Pixmap Pixmap None + border BorderColor Pixel XtDefaultForeground + borderWidth BorderWidth Dimension 1 + callback Callback Pointer NULL + cursor Cursor Cursor None + destroyCallback Callback Pointer NULL + font Font XFontStructx* XtDefaultFont + foreground Foreground Pixel XtDefaultForeground + height Height Dimension text height + highlightThickness Thickness Dimension 2 + insensitiveBorder sensitive Pixmap Gray + internalHeight Height Dimension 2 + internalWidth Width Dimension 4 + justify Justify XtJustify XtJustifyCenter + label Label String NULL + mappedWhenManaged MappedWhenManaged Boolean True + resize Resize Boolean True + sensitive Sensitive Boolean True + width Width Dimension text width + x Position Position 0 + y Position Position 0 + +*/ + +/* + * These should be in StringDefs.h but aren't so we will define + * them here if they are needed. + */ + + +extern WidgetClass radioWidgetClass; + +typedef=20struct _RadioClassRec *RadioWidgetClass; +typedef struct _RadioRec = *RadioWidget; + + +/************************************************************ + * + * Public Functions + * + ************************************************************/ + +#endif /* _XawRadio_h */ Index:= lwlib/xlwradioP.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwradioP.h diff -N xlwradioP.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwradioP.h Wed Jul 28 01:33:56 1999 @@ -0,0 +1,106 @@ +/* Radio Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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. */ + +/* + * RadioP.h - Private definitions for Radio widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: June 30, 1997 + * + */ + +#ifndef _XawRadioP_h +#define _XawRadioP_h + +#include "xlwradio.h" +#include= + +/*********************************************************************** + * + * Radio Widget Private Data + * += ***********************************************************************/ + +#define streq(a, b) ( strcmp((a), (b)) =3D=3D 0= ) + +typedef void (*XawDiamondProc)()= ; + +/************************************ + * + * Class structure + * + ***********************************/ + + /* New fields for the Radio widget class record */ +typedef struct _RadioClass { + Dimension dsize ; /* diamond size */ + XawDiamondProc drawDiamond ; + /* TODO: 3-d and xaw-xpm features? */ + XtPointer extension; +}= RadioClassPart; + +#define XtInheritDrawDiamond ((XawDiamondProc)_XtInherit) + + /* Full class record declaration */ +typedef struct _RadioClassRec { + CoreClassPart core_class; + SimpleClassPart simple_class; +#ifdef _ThreeDP_h + ThreeDClassPart threeD_class; +#endif + LabelClassPart label_class; + CommandClassPart command_class; + ToggleClassPart toggle_class; + RadioClassPart radio_class; +} RadioClassRec; + +extern RadioClassRec= radioClassRec; + +/*************************************** + * + * Instance (widget) structure + * + **************************************/ + + /* New fields for the Radio widget record */ +typedef struct { + /* resources */ + /* TODO: 3-d and xaw-xpm features? */ + + /* private data */ + XtPointer extension; +} RadioPart; + + /* Full widget declaration */ +typedef struct _RadioRec { + CorePart core; + SimplePart simple; +#ifdef _ThreeDP_h + ThreeDPart threeD; +#endif + LabelPart label; + CommandPart command; + TogglePart toggle; + RadioPart radio; +} RadioRec; + +#endif /* _XawRadioP_h */ Index:= lwlib/xlwtabs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwtabs.c diff -N xlwtabs.c --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwtabs.c Wed Jul 28 01:33:59 1999 @@ -0,0 +1,1663 @@ +/* Tabs Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: Tabs.c 1.16 */ + +/* + * Tabs.c - Index Tabs composite widget + * + * Author: Edward A. Falk + * falk@falconer.vip.best.com + * + * Date: July 29, 1997 + * + * + * Overall layout of this widget is as follows: + * + * ________ ,---------. _________ + * | label || Label || Label | \ tabs + * |________|| ||_________| / + * |+----------------------------+| \ + * || || | + * || child widget window || > frame + * |+----------------------------+| | + * +------------------------------+ / + * + * The height of the tabs includes the shadow width, top and bottom + * margins, and the height of the text. + * + * The height of the frame includes the top and bottom shadow width and= the + * size of the child widget window. + * + * The tabs overlap the frame and each other vertically by the shadow + * width, so that when the topmost tab is drawn, it obliterates part of + * the frame. + */ + +/* TODO: min child height =3D tab height + * += */ + +#include= + +#include= +#include= +#include= +#include= + +#include= "xlwtabsP.h" +#include= "xlwgcs.h" + +#define MIN_WID 10 +#define MIN_HGT 10 +#define INDENT 3 /* tabs indented from edge by this much= */ +#define SPACING 0 /* distance between tabs */ +#define SHADWID 1 /* default shadow width */ +#define TABDELTA 2 /* top tab grows this many pixels when on top= */ + + +/**************************************************************** + * + * IndexTabs Resources + * += ****************************************************************/ + +static char defaultTranslations[] =3D + ": select()" ; + +#define offset(field) XtOffsetOf(TabsRec, tabs.field) +static XtResource resources[] =3D { + + {XtNselectInsensitive, XtCSelectInsensitive, XtRBoolean,= sizeof(Boolean), + offset(selectInsensitive), XtRImmediate, (XtPointer) True}, + { XtNfont, XtCFont, XtRFontStruct, sizeof(XFontStruct *), + offset(font), XtRString, XtDefaultFont}, + { XtNinternalWidth, XtCWidth, XtRDimension,= sizeof(Dimension), + offset(internalWidth), XtRImmediate, (XtPointer)4 }, + { XtNinternalHeight, XtCHeight, XtRDimension,= sizeof(Dimension), + offset(internalHeight), XtRImmediate, (XtPointer)4 }, + { XtNborderWidth, XtCBorderWidth, XtRDimension, sizeof(Dimension), + XtOffsetOf(RectObjRec,rectangle.border_width), XtRImmediate, + (XtPointer)0}, + { XtNtopWidget, XtCTopWidget, XtRWidget, sizeof(Widget), + offset(topWidget), XtRImmediate, NULL}, + { XtNcallback, XtCCallback, XtRCallback, sizeof(XtPointer), + offset(callbacks), XtRCallback, NULL}, + { XtNpopdownCallback, XtCCallback, XtRCallback, sizeof(XtPointer), + offset(popdownCallbacks), XtRCallback, NULL}, + {XtNbeNiceToColormap, XtCBeNiceToColormap, XtRBoolean, sizeof(Boolean), + offset(be_nice_to_cmap), XtRImmediate, (XtPointer) True}, + {XtNtopShadowContrast, XtCTopShadowContrast, XtRInt, sizeof(int), + offset(top_shadow_contrast), XtRImmediate, (XtPointer) 20}, + {XtNbottomShadowContrast, XtCBottomShadowContrast, XtRInt, sizeof(int), + offset(bot_shadow_contrast), XtRImmediate, (XtPointer) 40}, + {XtNinsensitiveContrast, XtCInsensitiveContrast, XtRInt, sizeof(int), + offset(insensitive_contrast), XtRImmediate, (XtPointer)= 33}, +}; +#undef offset + + + + /* constraint resources= */ + +#define offset(field) XtOffsetOf(TabsConstraintsRec, tabs.field) +static XtResource tabsConstraintResources[] =3D { + {XtNtabLabel, XtCLabel, XtRString, sizeof(String), + offset(label), XtRString, NULL}, + {XtNtabLeftBitmap, XtCLeftBitmap, XtRBitmap,= sizeof(Pixmap), + offset(left_bitmap), XtRImmediate, None}, + {XtNtabForeground, XtCForeground, XtRPixel,= sizeof(Pixel), + offset(foreground), XtRString, XtDefaultForeground}, + {XtNresizable, XtCResizable, XtRBoolean,= sizeof(Boolean), + offset(resizable), XtRImmediate, (XtPointer) True}, +} ; +#undef offset + + + + +#ifndef __STDC__ + + /* FORWARD REFERENCES: */ + + /* member functions= */ + +static= void= TabsClassInit(); +static= void= TabsInit(); +static= void= TabsResize(); +static= void= TabsExpose(); +static= void= TabsDestroy(); +static= void= TabsRealize(); +static= Boolean= TabsSetValues(); +static= XtGeometryResult= TabsQueryGeometry(); +static= XtGeometryResult= TabsGeometryManager(); +static void TabsChangeManaged(); +static void TabsConstraintInitialize()= ; +static Boolean TabsConstraintSetValues() ; + + /* action procs */ + +static void TabsSelect() ; + + /* internal privates */ + +static void TabsAllocGCs() ; /* get rendering GCs= */ +static void TabsFreeGCs() ; /* return rendering GCs= */ +static void DrawTabs() ; /* draw all tabs */ +static void DrawTab() ; /* draw one index tab */ +static void DrawFrame() ; /* draw frame around contents= */ +static void DrawTrim() ; /* draw trim around a tab= */ +static void DrawBorder() ; /* draw border */ +static void TabWidth() ; /* recompute tab size */ +static void MaxChild() ; +static int PreferredSize() ; /* compute preferred size= */ +static int PreferredSize2() ; /* compute preferred size= */ +static int PreferredSize3() ; /* compute preferred size= */ +static void MakeSizeRequest() ; /* try to change size= */ +static void getBitmapInfo() ; +static int TabLayout() ; /* lay out tabs */ +static void TabsShuffleRows() ; /* bring current tab to bottom row= */ + +static void TabsAllocFgGC() ; +static void TabsAllocGreyGC() ; + +#else + +static void TabsClassInit() ; +static void TabsInit( Widget req, Widget new, ArgList, Cardinal *nargs)= ; +static void TabsConstraintInitialize(Widget, Widget, ArgList, Cardinal *) ; +static void TabsRealize(Widget, Mask *, XSetWindowAttributes *)= ; +static void TabsDestroy( Widget w) ; +static void TabsResize( Widget w) ; +static void TabsExpose( Widget w, XEvent *event, Region region)= ; +static Boolean TabsSetValues(Widget, Widget, Widget, ArgList, Cardinal *)= ; +static Boolean TabsConstraintSetValues(Widget, Widget, Widget, + ArgList, Cardinal *) ; +static XtGeometryResult TabsQueryGeometry(Widget, + XtWidgetGeometry *, XtWidgetGeometry *) ; +static XtGeometryResult TabsGeometryManager(Widget, + XtWidgetGeometry *, XtWidgetGeometry *)= ; +static void TabsChangeManaged( Widget w)= ; + +static void TabsSelect(Widget, XEvent *, String *, Cardinal *)= ; + +static void DrawTabs( TabsWidget tw, int labels) ; +static void DrawTab( TabsWidget tw, Widget child, int labels)= ; +static void DrawFrame( TabsWidget tw) ; +static void DrawTrim( TabsWidget, int x, int y, + int wid, int hgt, int bottom, int undraw) ; +static void DrawBorder( TabsWidget tw, Widget child, int undraw)= ; + +static void TabWidth( Widget w) ; +static int TabLayout( TabsWidget, int wid, Dimension *r_hgt, + int query_only) ; +static void MaxChild( TabsWidget, Dimension *, Dimension *, Widget)= ; +static void TabsShuffleRows( TabsWidget tw) ; +static int PreferredSize( TabsWidget, + Dimension *reply_width, Dimension *reply_height, + Dimension *reply_cw, Dimension *reply_ch) ; +static int PreferredSize2( TabsWidget, int cw, int ch, + Dimension *rw, Dimension *rh) ; +static int PreferredSize3( TabsWidget, int wid, int hgt, + Dimension *rw, Dimension *rh) ; +static void MakeSizeRequest(TabsWidget)= ; + +static void TabsAllocGCs(TabsWidget) ; +static void TabsFreeGCs(TabsWidget) ; +static void getBitmapInfo( TabsWidget tw, TabsConstraints tab)= ; +static void TabsAllocFgGC( TabsWidget tw) ; +static void TabsAllocGreyGC( TabsWidget tw) ; + +#endif + +#if XtSpecificationRelease < 5 +static GC XtAllocateGC() ; +#endif + +#define AddRect(i,xx,yy,w,h) \ + do{rects[(i)].x=3D(xx); rects[i].y=3D(yy); \ + rects[i].width=3D(w);= rects[i].height=3D(h);}while(0) + +static XtActionsRec actionsList[] =3D + { + {"select", TabsSelect}, + }= ; + + +/**************************************************************** +* +* Full class record= constant +* +****************************************************************/ + +TabsClassRec tabsClassRec =3D { + { +/* core_class fields */ + /* superclass */ (WidgetClass) &constraintClassRec, + /* class_name */ "Tabs", + /* widget_size */ sizeof(TabsRec), + /* class_initialize */ TabsClassInit, + /* class_part_init */ NULL, /* TODO? */ + /* class_inited */ FALSE, + /* initialize */ TabsInit, + /* initialize_hook */ NULL, + /* realize */ TabsRealize, + /* actions */ actionsList, + /* num_actions */ XtNumber(actionsList), + /* resources */ resources, + /* num_resources */ XtNumber(resources), + /* xrm_class */ NULLQUARK, + /* compress_motion */ TRUE, + /* compress_exposure */ TRUE, + /* compress_enterleave*/ TRUE, + /* visible_interest */ FALSE, + /* destroy */ TabsDestroy, + /* resize */ TabsResize, + /* expose */ TabsExpose, + /* set_values */ TabsSetValues, + /* set_values_hook */ NULL, + /* set_values_almost */ XtInheritSetValuesAlmost, + /* get_values_hook */ NULL, + /* accept_focus */ NULL, + /* version */ XtVersion, + /* callback_private */ NULL, + /* tm_table */ defaultTranslations, + /* query_geometry */ TabsQueryGeometry, + /* display_accelerator*/ XtInheritDisplayAccelerator, + /* extension */ NULL + }, + { +/* composite_class fields */ + /* geometry_manager */ TabsGeometryManager, + /* change_managed */ TabsChangeManaged, + /* insert_child */ XtInheritInsertChild, /* TODO? */ + /* delete_child */ XtInheritDeleteChild, /* TODO? */ + /* extension */ NULL + }, + { +/* constraint_class fields */ + /* subresources */ tabsConstraintResources, + /* subresource_count */ XtNumber(tabsConstraintResources), + /* constraint_size */ sizeof(TabsConstraintsRec), + /* initialize */ TabsConstraintInitialize, + /* destroy */ NULL, + /* set_values */ TabsConstraintSetValues, + /* extension */ NULL, + }, + { +/* Tabs class fields */ + /* extension */ NULL, + } +}; + +WidgetClass tabsWidgetClass =3D= (WidgetClass)&tabsClassRec; + + + +#ifdef DEBUG +#ifdef __STDC__ +#define assert(e) \ + ((e) || fprintf(stderr,"yak! %s at= %s:%d\n",#e,__FILE__,__LINE__)) +#else +#define assert(e) \ + ((e) || fprintf(stderr,"yak! e at= %s:%d\n",__FILE__,__LINE__)) +#endif +#else +#define= assert(e) +#endif + + +=0C + +/**************************************************************** + * + * Member Procedures + * += ****************************************************************/ + +static void +TabsClassInit() +{ + /* TODO: register converter for labels? */ +} + + + + /* Init a newly created tabs widget. Compute height of tabs + * and optionally compute size of widget. */ + +/* ARGSUSED */ + +static void +TabsInit(request, new, args, num_args) + Widget request, new; + ArgList args; + Cardinal *num_args; +{ + TabsWidget newTw =3D (TabsWidget)new; + + newTw->tabs.numRows =3D 0 ; + + /* height is easy, it's the same for all tabs: + * TODO: font height + height of tallest bitmap. + */ + newTw->tabs.tab_height =3D 2 * newTw->tabs.internalHeight + SHADWID= ; + + if( newTw->tabs.font !=3D NULL ) + newTw->tabs.tab_height +=3D newTw->tabs.font->max_bounds.ascent= + + newTw->tabs.font->max_bounds.descent ; + + /* GC allocation is deferred until XtRealize() */ + + /* if size not explicitly set, set it to our preferred size now. */ + + if( request->core.width =3D=3D 0 || request->core.height =3D=3D 0 ) + { + Dimension w,h ; + PreferredSize(newTw, &w, &h, NULL,NULL) ; + if( request->core.width =3D=3D 0 ) new->core.width =3D w ; + if( request->core.height =3D=3D 0 ) new->core.height =3D h ; + XtClass(new)->core_class.resize(new) ; + } + + /* defer GC allocation, etc., until Realize() time. */ + newTw->tabs.foregroundGC =3D + newTw->tabs.backgroundGC =3D + newTw->tabs.greyGC =3D + newTw->tabs.topGC =3D + newTw->tabs.botGC =3D None ; + + newTw->tabs.grey50 =3D None ; + + newTw->tabs.needs_layout =3D False ; +} + + + /* Init the constraint part of a new tab child. Compute the + * size of the tab. + */ +/* ARGSUSED */ +static void +TabsConstraintInitialize(request, new, args, num_args) + Widget request, new ; + ArgList args ; + Cardinal *num_args; +{ + TabsConstraints tab =3D (TabsConstraints) new->core.constraints= ; + tab->tabs.greyAlloc =3D False ; /* defer allocation of pixel= */ + + getBitmapInfo((TabsWidget)XtParent(new), tab) ; + TabWidth(new) ; +} + + + + /* Called when tabs widget first realized. Create the window + * and allocate the GCs + */ + +static void +TabsRealize(w, valueMask, attributes) + Widget w; + Mask *valueMask; + XSetWindowAttributes *attributes; +{ + TabsWidget tw =3D (TabsWidget) w; + + attributes->bit_gravity =3D NorthWestGravity; + *valueMask |=3D CWBitGravity; + + /* TODO: shouldn't this chain to the parent's realize instead?= */ + XtCreateWindow( w, (unsigned)InputOutput, (Visual= *)CopyFromParent, + *valueMask, attributes); + + TabsAllocGCs(tw) ; +} + + + +static void +TabsDestroy(w) + Widget w ; +{ + TabsFreeGCs((TabsWidget)w) ; +} + + + /* Parent has resized us. This will require that the tabs be + * laid out again. + */ + +static void +TabsResize(w) + Widget w; +{ + TabsWidget tw =3D (TabsWidget) w; + int i ; + int num_children =3D tw->composite.num_children ; + Widget *childP ; + TabsConstraints tab ; + Dimension cw,ch,bw ; + + + /* Our size has now been dictated by the parent. Lay out the + * tabs, lay out the frame, lay out the children. Remember + * that the tabs overlap each other and the frame by shadowWidth. + * Also, the top tab is larger than the others, so if there's only + * one row, the widget must be made taller to accomodate this. + * + * Once the tabs are laid out, if there is more than one + * row, we may need to shuffle the rows to bring the top tab + * to the bottom row. + */ + + if( num_children > 0 && tw->composite.children !=3D NULL ) + { + /* Loop through the tabs and assign rows & x positions */ + (void) TabLayout(tw, tw->core.width, NULL, False) ; + + /* assign a top widget, bring it to bottom row. */ + TabsShuffleRows(tw) ; + + /* now assign child positions & sizes. Positions are all the + * same: just inside the frame. Sizes are also all the same. + */ + + tw->tabs.child_width =3D cw =3D tw->core.width - 2 * SHADWID ; + tw->tabs.child_height =3D ch =3D + tw->core.height - tw->tabs.tab_total - 2 * SHADWID ; + + + for(i=3D0, childP=3Dtw->composite.children; + i < num_children; + ++i, ++childP) + { + tab =3D (TabsConstraints) (*childP)->core.constraints ; + bw =3D tab->tabs.bwid ; + XtConfigureWidget(*childP, SHADWID,tw->tabs.tab_total+SHADWID, + cw-bw*2,ch-bw*2, bw) ; + } + } + + tw->tabs.needs_layout =3D False ; +} /* Resize */ + + + + /* Redraw entire Tabs widget */ + +/* ARGSUSED */ +static void +TabsExpose(w, event, region) + Widget w ; + XEvent *event ; + Region region ; +{ + TabsWidget tw =3D (TabsWidget) w; + + if( tw->tabs.needs_layout ) + XtClass(w)->core_class.resize(w) ; + + DrawTabs(tw, True) ; +} + + + /* Called when any Tabs widget resources are changed. */ + +/* ARGSUSED */ +static Boolean +TabsSetValues(current, request, new, args, num_args) + Widget current, request, new; + ArgList args; + Cardinal *num_args; +{ + TabsWidget curtw =3D (TabsWidget) current ; + TabsWidget tw =3D (TabsWidget) new ; + Boolean needRedraw =3D False ; + Widget *childP ; + int i ; + + + if( tw->tabs.font !=3D curtw->tabs.font || + tw->tabs.internalWidth !=3D curtw->tabs.internalWidth || + tw->tabs.internalHeight !=3D curtw->tabs.internalHeight ) + { + tw->tabs.tab_height =3D 2 * tw->tabs.internalHeight + SHADWID ; + + if( tw->tabs.font !=3D NULL ) + tw->tabs.tab_height +=3D tw->tabs.font->max_bounds.ascent + + tw->tabs.font->max_bounds.descent ; + + /* Tab size has changed. Resize all tabs and request a new size */ + for(i=3D0, childP=3Dtw->composite.children; + i < tw->composite.num_children; + ++i, ++childP) + TabWidth(*childP) ; + PreferredSize(tw, &tw->core.width, &tw->core.height, NULL,NULL) ; + needRedraw =3D True ; + tw->tabs.needs_layout =3D True ; + } + + /* TODO: if any color changes, need to recompute GCs and redraw */ + + if( tw->core.background_pixel !=3D curtw->core.background_pixel || + tw->core.background_pixmap !=3D curtw->core.background_pixmap ) + { + TabsFreeGCs(tw) ; + TabsAllocGCs(tw) ; + needRedraw =3D True ; + } + + if( tw->core.sensitive !=3D curtw->core.sensitive ) + needRedraw =3D True ; + + /* If top widget changes, need to change stacking order, redraw tabs. + * Window system will handle the redraws. + */ + + if( tw->tabs.topWidget !=3D curtw->tabs.topWidget ) + { + Widget w =3D curtw->tabs.topWidget ; + TabsConstraints tab =3D (TabsConstraints) w->core.constraints ; + + XRaiseWindow(XtDisplay(w), XtWindow(w)) ; + + if( tab->tabs.row !=3D tw->tabs.numRows-1 ) + TabsShuffleRows(tw) ; + + needRedraw =3D True ; + } + + return needRedraw ; +} + + + /* Called when any child constraint resources change. */ + +/* ARGSUSED */ +static Boolean +TabsConstraintSetValues(current, request, new, args, num_args) + Widget current, request, new; + ArgList args; + Cardinal *num_args; +{ + TabsWidget tw =3D (TabsWidget) XtParent(new) ; + TabsConstraints ctab =3D (TabsConstraints) current->core.constraints= ; + TabsConstraints tab =3D (TabsConstraints) new->core.constraints ; + + + /* if label changes, need to re-layout the entire widget */ + /* if foreground changes, need to redraw tab label */ + + /* TODO: only need resize of new bitmap has different dimensions + * from old bitmap. + */ + + if( tab->tabs.label !=3D ctab->tabs.label || /* Tab size has changed.= */ + tab->tabs.left_bitmap !=3D ctab->tabs.left_bitmap ) + { + TabWidth(new) ; + tw->tabs.needs_layout =3D True ; + + if( tab->tabs.left_bitmap !=3D ctab->tabs.left_bitmap ) + getBitmapInfo(tw, tab) ; + + /* If there are no subclass ConstraintSetValues procedures remaining + * to be invoked, and if the preferred size has changed, ask + * for a resize. + */ + if( XtClass((Widget)tw) =3D=3D tabsWidgetClass ) + MakeSizeRequest(tw) ; + } + + + /* The child widget itself never needs a redisplay, but the parent + * Tabs widget might. + */ + + if( tw->tabs.needs_layout ) { + XClearWindow(XtDisplay((Widget)tw), XtWindow((Widget)tw)) ; + XtClass(tw)->core_class.expose((Widget)tw,NULL,None) ; + } + + else if( tab->tabs.foreground !=3D ctab->tabs.foreground ) + DrawTab(tw, new, True) ; + + return False ; +} + + + +/* + * Return preferred size. + */ + +static XtGeometryResult +TabsQueryGeometry(w, intended, preferred) + Widget w; + XtWidgetGeometry *intended, *preferred; +{ +register TabsWidget tw =3D (TabsWidget)w ; + + preferred->request_mode =3D CWWidth | CWHeight ; + PreferredSize(tw, &preferred->width, &preferred->height, NULL,NULL)= ; + + if( intended->width =3D=3D w->core.width && + intended->height =3D=3D w->core.height ) + return XtGeometryNo ; + + if( (!(intended->request_mode & CWWidth) || + intended->width >=3D preferred->width) && + (!(intended->request_mode & CWHeight) || + intended->height >=3D preferred->height) ) + return XtGeometryYes; + else + return XtGeometryAlmost; +} + + + +/* + * Geometry Manager; called when a child wants to be resized. + */ + +static XtGeometryResult +TabsGeometryManager(w, req, reply) + Widget w; + XtWidgetGeometry *req; + XtWidgetGeometry *reply; /* RETURN */ + +{ + TabsWidget tw =3D (TabsWidget) XtParent(w); + Dimension s =3D SHADWID ; + TabsConstraints tab =3D= (TabsConstraints)w->core.constraints; + XtGeometryResult result ; + + /* Position request always denied */ + + if( ((req->request_mode & CWX) && req->x !=3D w->core.x) || + ((req->request_mode & CWY) && req->y !=3D w->core.y) || + !tab->tabs.resizable ) + return XtGeometryNo ; + + /* Make all three fields in the request valid */ + if( !(req->request_mode & CWWidth) ) + req->width =3D w->core.width; + if( !(req->request_mode & CWHeight) ) + req->height =3D w->core.height; + if( !(req->request_mode & CWBorderWidth) ) + req->border_width =3D w->core.border_width; + + if( req->width =3D=3D w->core.width && + req->height =3D=3D w->core.height && + req->border_width =3D=3D w->core.border_width ) + return XtGeometryNo ; + + /* Size changes must see if the new size can be accomodated. + * The Tabs widget keeps all of its children the same + * size. A request to shrink will be accepted only if the + * new size is still big enough for all other children. A + * request to shrink that is not big enough for all children + * returns an "almost" response with the new proposed size. + * A request to grow will be accepted only if the Tabs parent can + * grow to accomodate. + */ + + if (req->request_mode & (CWWidth | CWHeight | CWBorderWidth)) + { + Dimension rw,rh ; /* requested size, including borders */ + Dimension cw,ch ; /* other children's preferred size */ + Dimension mw,mh ; /* max of above; this is our target */ + Dimension aw,ah ; /* available size we can give child */ + Dimension th ; /* space used by tabs */ + Dimension wid,hgt ; /* Tabs widget size */ + + rw =3D req->width + 2*req->border_width ; + rh =3D req->height + 2*req->border_width ; + + /* find out what the resulting preferred size would be */ + + MaxChild(tw, &cw, &ch, w) ; + mw =3D Max(cw, rw) ; + mh =3D Max(ch, rh) ; + PreferredSize2(tw, mw,mh, &wid, &hgt) ; + + /* Ask to be resized to accomodate. */ + + if( wid !=3D tw->core.width || hgt !=3D tw->core.height ) + { + Dimension oldWid =3D tw->core.width, oldHgt =3D tw->core.height ; + XtWidgetGeometry myrequest, myreply ; + + myrequest.width =3D wid ; + myrequest.height =3D hgt ; + myrequest.request_mode =3D CWWidth | CWHeight ; + + /* If child is only querying, or if we're going to have to + * offer the child a compromise, then make this a query only. + */ + + if( (req->request_mode & XtCWQueryOnly) || rw < mw || rh < mh ) + myrequest.request_mode |=3D XtCWQueryOnly ; + + result =3D XtMakeGeometryRequest((Widget)tw, &myrequest, &myreply)= ; + + /* !$@# Box widget changes the core size even if QueryOnly + * is set. I'm convinced this is a bug. At any rate, to work + * around the bug, we need to restore the core size after every + * query geometry request. This is only partly effective, + * as there may be other boxes further up the tree. + */ + if( myrequest.request_mode & XtCWQueryOnly ) { + tw->core.width =3D oldWid ; + tw->core.height =3D oldHgt ; + } + + /* based on the parent's response, determine what the + * resulting Tabs widget size would be. + */ + + switch( result ) { + case XtGeometryYes: + break ; + + case XtGeometryNo: + wid =3D tw->core.width ; + hgt =3D tw->core.height ; + break ; + + case XtGeometryAlmost: + wid =3D myreply.width ; + hgt =3D myreply.height ; + } + } + + /* Within the constraints imposed by the parent, what is + * the max size we can give the child? + */ + (void) TabLayout(tw, wid, &th, True) ; + aw =3D wid - 2*s ; + ah =3D hgt - th - 2*s ; + + /* OK, make our decision. If requested size is >=3D max sibling + * preferred size, AND requested size <=3D available size, then + * we accept. Otherwise, we offer a compromise. + */ + + if( rw =3D=3D aw && rh =3D=3D ah ) + { + /* Acceptable. If this wasn't a query, change *all* children + * to this size. + */ + if( req->request_mode & XtCWQueryOnly ) + return XtGeometryYes ; + else + { + Widget *childP ; + int i,bw ; + w->core.border_width =3D req->border_width ; + for(i=3Dtw->composite.num_children,= childP=3Dtw->composite.children; + --i >=3D 0; ++childP) + { + bw =3D (*childP)->core.border_width ; + XtConfigureWidget(*childP, s,tw->tabs.tab_total+s, + rw-2*bw,rh-2*bw, bw) ; + } +#ifdef COMMENT + /* TODO: under what conditions will we need to redraw? */ + XClearWindow(XtDisplay((Widget)tw), XtWindow((Widget)tw)) ; + XtClass(tw)->core_class.expose((Widget)tw,NULL,NULL) ; +#endif /* COMMENT */ + return XtGeometryDone ; + } + } + + /* Cannot accede to child's request. Describe what we *can* do + * and return counter-offer. + */ + reply->width =3D aw - 2*req->border_width ; + reply->height =3D ah - 2*req->border_width ; + reply->border_width =3D req->border_width ; + reply->request_mode =3D CWWidth | CWHeight | CWBorderWidth ; + return XtGeometryAlmost ; + } + + return XtGeometryYes ; +} + + + + + /* The number of children we manage has changed; recompute + * size from scratch. + */ + +static void +TabsChangeManaged(w) + Widget w; +{ + TabsWidget tw =3D (TabsWidget)w ; + Widget *childP ; + int i ; + int n =3D tw->composite.num_children ; + + MakeSizeRequest(tw) ; + + XtClass(w)->core_class.resize(w) ; + if( XtIsRealized(w) ) + { + Display *dpy =3D XtDisplay(w) ; + XClearWindow(dpy, XtWindow(w)) ; + XtClass(w)->core_class.expose(w,NULL,NULL) ; + + /* make sure the top widget stays on top. This requires + * making sure that all new children are realized first. + */ + if( tw->tabs.topWidget !=3D NULL ) { + for(i=3D0, childP=3Dtw->composite.children; i < n; ++i, ++childP) + if( !XtIsRealized(*childP) ) + XtRealizeWidget(*childP) ; + XRaiseWindow(dpy, XtWindow(tw->tabs.topWidget)) ; + = } += } +} + + +=0C + +/**************************************************************** + * + * Action Procedures + * + ****************************************************************/ + + /* User clicks on a tab, figure out which one it was. */ + +/* ARGSUSED */ +static void +TabsSelect(w, event, params, num_params) + Widget w ; + XEvent *event ; + String *params ; + Cardinal *num_params ; +{ + TabsWidget tw =3D (TabsWidget) w ; + Widget *childP ; + Position x,y ; + Dimension h =3D tw->tabs.tab_height ; + int i ; + + /* TODO: is there an Xmu function or something to do this instead?= */ + switch( event->type ) { + case ButtonPress: + case ButtonRelease: + x =3D event->xbutton.x ; y =3D event->xbutton.y ; break ; + case KeyPress: + case KeyRelease: + x =3D event->xkey.x ; y =3D event->xkey.y ; break ; + default: + return ; + } + + /* TODO: determine which tab was clicked, if any. Set that + * widget to be top of stacking order with XawTabsSetTop(). + */ + for(i=3D0, childP=3Dtw->composite.children; + i < tw->composite.num_children; + ++i, ++childP) + { + TabsConstraints tab =3D (TabsConstraints)(*childP)->core.constraints; + if( x > tab->tabs.x && x < tab->tabs.x + tab->tabs.width && + y > tab->tabs.y && y < tab->tabs.y + h ) + { + if( *childP !=3D tw->tabs.topWidget && + (XtIsSensitive(*childP) || tw->tabs.selectInsensitive) ) + XawTabsSetTop(*childP, True) ; + break ; + = } += } +} + + + +=0C + +/**************************************************************** + * + * Public Procedures + * + ****************************************************************/ + + + /* Set the top tab, optionally call all callbacks.= */ +void +XawTabsSetTop(w, callCallbacks) + Widget w ; + int callCallbacks ; +{ + TabsWidget tw =3D (TabsWidget)w->core.parent ; + TabsConstraints tab ; + + if( !XtIsSubclass(w->core.parent, tabsWidgetClass) ) + { + char line[1024] ; + sprintf(line, "XawTabsSetTop: widget \"%s\" is not the child of a tabs= widget.", XtName(w)) ; + XtAppWarning(XtWidgetToApplicationContext(w), line) ; + return ; + } + + if( callCallbacks ) + XtCallCallbackList(w, tw->tabs.popdownCallbacks, + (XtPointer)tw->tabs.topWidget) ; + + XRaiseWindow(XtDisplay(w), XtWindow(w)) ; + + tab =3D (TabsConstraints) w->core.constraints ; + if( tab->tabs.row =3D=3D 0 ) + { + /* Easy case; undraw current top, undraw new top, assign new + * top, redraw all borders. + * We *could* just erase and execute a full redraw, but I like to + * reduce screen flicker. + */ + DrawBorder(tw, tw->tabs.topWidget, True) ; + DrawBorder(tw, w, True) ; + tw->tabs.topWidget =3D w ; + DrawTabs(tw, False) ; + } + else + { + tw->tabs.topWidget =3D w ; + TabsShuffleRows(tw) ; + XClearWindow(XtDisplay((Widget)tw), XtWindow((Widget)tw)) ; + XtClass(tw)->core_class.expose((Widget)tw,NULL,None) ; + } + + if( callCallbacks ) + XtCallCallbackList(w, tw->tabs.callbacks, (XtPointer)w)= ; +} + + +=0C + +/**************************************************************** + * + * Private Procedures + * += ****************************************************************/ + + +static void +TabsAllocGCs(tw) + TabsWidget tw ; +{ + TabsAllocFgGC(tw) ; + TabsAllocGreyGC(tw) ; + tw->tabs.backgroundGC =3D AllocBackgroundGC((Widget)tw, None)= ; + tw->tabs.topGC =3D= AllocTopShadowGC((Widget)tw, + tw->tabs.top_shadow_contrast, tw->tabs.be_nice_to_cmap)= ; + tw->tabs.botGC =3D= AllocBotShadowGC((Widget)tw, + tw->tabs.bot_shadow_contrast, tw->tabs.be_nice_to_cmap)= ; +} + + +static void +TabsFreeGCs(tw) + TabsWidget tw ; +{ + Widget w =3D (Widget) tw; + + XtReleaseGC(w, tw->tabs.foregroundGC) ; + XtReleaseGC(w, tw->tabs.greyGC) ; + XtReleaseGC(w, tw->tabs.backgroundGC) ; + XtReleaseGC(w, tw->tabs.topGC) ; + XtReleaseGC(w, tw->tabs.botGC) ; + XmuReleaseStippledPixmap(XtScreen(w), tw->tabs.grey50) ; +} + + + + + + /* Redraw entire Tabs widget */ + +static void +DrawTabs(tw, labels) + TabsWidget tw ; + int labels ; /* draw labels? */ +{ + Widget *childP ; + int i,j ; + Dimension s =3D SHADWID ; + Dimension th =3D tw->tabs.tab_height ; + Position y ; + TabsConstraints tab ; + + /* draw tabs and frames by row except for the top tab, which + * is drawn last. (This is inefficiently written, but should not + * be too slow as long as there are not a lot of rows.) + */ + + y =3D tw->tabs.numRows =3D=3D 1 ? TABDELTA : 0 ; + for(i=3D0; itabs.numRows; ++i, y +=3D th) + { + for(j=3D0, childP=3Dtw->composite.children; + j < tw->composite.num_children; + ++j, ++childP) + { + tab =3D (TabsConstraints)(*childP)->core.constraints; + if( tab->tabs.row =3D=3D i && *childP !=3D tw->tabs.topWidget ) + DrawTab(tw, *childP, labels) ; + } + if( i !=3D tw->tabs.numRows -1 ) + DrawTrim(tw, 0,y+th, tw->core.width, th+s, False,False)= ; + } + + DrawFrame(tw) ; + + /* and now the top tab */ + if( tw->tabs.topWidget !=3D NULL ) + DrawTab(tw, tw->tabs.topWidget, labels) ; +} + + + +/* Draw one tab. Corners are rounded very slightly.= */ + +static void +DrawTab(tw, child, labels) + TabsWidget tw ; + Widget child ; + int labels ; /* draw label too? */ +{ + GC gc ; + + DrawBorder(tw, child, False) ; + + if( labels ) + { + TabsConstraints tab =3D (TabsConstraints)child->core.constraints; + Display *dpy =3D XtDisplay((Widget)tw) ; + Window win =3D XtWindow((Widget)tw) ; + String lbl =3D tab->tabs.label !=3D NULL ? + tab->tabs.label : XtName(child) ; + + if( XtIsSensitive(child) ) + { + gc =3D tw->tabs.foregroundGC ; + XSetForeground(dpy, gc, tab->tabs.foreground) ; + } + else + { + /* grey pixel allocation deferred until now */ + if( !tab->tabs.greyAlloc ) + { + if( tw->tabs.be_nice_to_cmap || tw->core.depth =3D=3D 1= ) + tab->tabs.grey =3D tab->tabs.foreground ; + else + tab->tabs.grey =3D= AllocGreyPixel((Widget)tw, += = = = = tab->tabs.foreground, + tw->core.background_pixel, + tw->tabs.insensitive_contrast ) ; + tab->tabs.greyAlloc =3D True ; + } + gc =3D tw->tabs.greyGC ; + XSetForeground(dpy, gc, tab->tabs.grey) ; + } + + if( tab->tabs.left_bitmap !=3D None && tab->tabs.lbm_width > 0 ) + { + if( tab->tabs.lbm_depth =3D=3D 1 ) + XCopyPlane(dpy, tab->tabs.left_bitmap, win,gc, + 0,0, tab->tabs.lbm_width,= tab->tabs.lbm_height, + tab->tabs.x+tab->tabs.lbm_x, tab->tabs.y+tab->tabs.lbm_y, 1L) ; + else + XCopyArea(dpy, tab->tabs.left_bitmap, win,gc, + 0,0, tab->tabs.lbm_width,= tab->tabs.lbm_height, + tab->tabs.x+tab->tabs.lbm_x, tab->tabs.y+tab->tabs.lbm_y) ; + } + + if( lbl !=3D NULL && tw->tabs.font !=3D NULL ) + XDrawString(dpy,win,gc, + tab->tabs.x+tab->tabs.l_x, tab->tabs.y+tab->tabs.l_y, + lbl,strlen(lbl)) ; + } +} + + + /* draw frame all the way around the child windows.= */ + +static void +DrawFrame(tw) + TabsWidget tw ; +{ + GC topgc =3D tw->tabs.topGC ; + GC botgc =3D tw->tabs.botGC ; + Dimension s =3D SHADWID ; + Dimension ch =3D tw->tabs.child_height ; + + Draw3dBox((Widget)tw, 0,tw->tabs.tab_total, + tw->core.width, ch+2*s, s, topgc, botgc) ; +} + + + /* draw trim around a tab or underneath a row of tabs= */ + +static void +DrawTrim(tw, x,y,wid,hgt, bottom, undraw) + TabsWidget tw ; /* widget */ + Position x,y ; /* upper-left corner */ + int wid,hgt ; /* total size */ + int bottom ; /* draw bottom? */ + int undraw ; /* undraw all */ +{ + Display *dpy =3D XtDisplay((Widget)tw) ; + Window win =3D XtWindow((Widget)tw) ; + GC bggc =3D tw->tabs.backgroundGC ; + GC topgc =3D undraw ? bggc : tw->tabs.topGC ; + GC botgc =3D undraw ? bggc : tw->tabs.botGC ; + + if( bottom ) + XDrawLine(dpy,win,bggc, x,y+hgt-1, x+wid-1,y+hgt-1) ; /* bottom= */ + XDrawLine(dpy,win,topgc, x,y+2, x,y+hgt-2) ; /* left= */ + XDrawPoint(dpy,win,topgc, x+1,y+1) ; /* corner= */ + XDrawLine(dpy,win,topgc, x+2,y, x+wid-3,y) ; /* top= */ + XDrawLine(dpy,win,botgc, x+wid-2,y+1, x+wid-2,y+hgt-2) ; /* right= */ + XDrawLine(dpy,win,botgc, x+wid-1,y+2, x+wid-1,y+hgt-2) ; /* right= */ +} + + +/* Draw one tab border. */ + +static void +DrawBorder(tw, child, undraw) + TabsWidget tw ; + Widget child ; + int undraw ; +{ + TabsConstraints tab =3D= (TabsConstraints)child->core.constraints; + Position x =3D tab->tabs.x ; + Position y =3D tab->tabs.y ; + Dimension twid =3D tab->tabs.width ; + Dimension thgt =3D tw->tabs.tab_height ; + + /* top tab requires a little special attention; it overlaps + * neighboring tabs slightly, so the background must be cleared + * in the region of the overlap to partially erase those neighbors. + * TODO: is this worth doing with regions instead? + */ + if( child =3D=3D tw->tabs.topWidget ) + { + Display *dpy =3D XtDisplay((Widget)tw) ; + Window win =3D XtWindow((Widget)tw) ; + GC bggc =3D tw->tabs.backgroundGC ; + XRectangle rects[3] ; + x -=3D TABDELTA ; + y -=3D TABDELTA ; + twid +=3D TABDELTA*2 ; + thgt +=3D TABDELTA ; + AddRect(0, x,y+1,twid,TABDELTA) ; + AddRect(1, x+1,y,TABDELTA,thgt) ; + AddRect(2, x+twid-TABDELTA-1,y,TABDELTA,thgt) ; + XFillRectangles(dpy,win,bggc, rects, 3) ; + } + + DrawTrim(tw, x,y,twid,thgt+1, child =3D=3D tw->tabs.topWidget, undraw)= ; +} + + + + +=0C + /* GEOMETRY UTILITIES */ + + + /* Compute the size of a child's tab. Positions will be computed + * elsewhere. + * + * height: font height + vertical_space*2 + shadowWid*2 + * width: string width + horizontal_space*2 + shadowWid*2 + * + * All tabs are the same height, so this is computed elsewhere. + */ + +static void +TabWidth(w) + Widget w ; +{ + TabsConstraints tab =3D (TabsConstraints) w->core.constraints= ; + TabsWidget tw =3D (TabsWidget)XtParent(w) ; + String lbl =3D tab->tabs.label !=3D NULL ? + tab->tabs.label : XtName(w) ; + XFontStruct *font =3D tw->tabs.font ; + int iw =3D tw->tabs.internalWidth ; + + tab->tabs.width =3D iw + SHADWID*2 ; + tab->tabs.l_x =3D tab->tabs.lbm_x =3D SHADWID + iw ; + + if( tab->tabs.left_bitmap !=3D None ) + { + tab->tabs.width +=3D tab->tabs.lbm_width + iw ; + tab->tabs.l_x +=3D tab->tabs.lbm_width + iw ; + tab->tabs.lbm_y =3D (tw->tabs.tab_height - tab->tabs.lbm_height)/2= ; + } + + if( lbl !=3D NULL && font !=3D NULL ) + { + tab->tabs.width +=3D XTextWidth(font, lbl, strlen(lbl)) + iw ; + tab->tabs.l_y =3D (tw->tabs.tab_height + + tw->tabs.font->max_bounds.ascent - + tw->tabs.font->max_bounds.descent)/2 ; + } +} + + + + /* Lay out tabs to fit in given width. Compute x,y position and + * row number for each tab. Return number of rows and total height + * required by all tabs. If there is only one row, add TABDELTA + * height to the total. Rows are assigned bottom to top. + * + * Tabs are indented from the edges by INDENT. + * + * TODO: if they require more than two rows and the total height:width + * ratio is more than 2:1, then try something else. + */ + +static int +TabLayout(tw, wid, reply_height, query_only) + TabsWidget tw; + int wid ; /* amount of width to work with.= */ + Dimension *reply_height; /* total height of tabs, may be NULL= */ + int query_only ; /* just want #rows & total height */ +{ + int i, row ; + int num_children =3D tw->composite.num_children ; + Widget *childP ; + Dimension w ; + Position x,y ; + TabsConstraints tab ; + + /* Algorithm: loop through children, assign X positions. If a tab + * would extend beyond the right edge, start a new row. After all + * rows are assigned, make a second pass and assign Y positions. + */ + + if( num_children > 0 ) + { + /* Loop through the tabs and see how much space they need. */ + + row =3D 0 ; + x =3D INDENT ; + y =3D 0 ; + wid -=3D INDENT ; + for(i=3Dnum_children, childP=3Dtw->composite.children; --i >=3D 0;= ++childP) + { + tab =3D (TabsConstraints) (*childP)->core.constraints ; + w =3D tab->tabs.width ; + if( x + w > wid ) { /* new row */ + ++row ; + x =3D INDENT ; + y +=3D tw->tabs.tab_height ; + } + if( !query_only ) { + tab->tabs.x =3D x ; + tab->tabs.y =3D y ; + tab->tabs.row =3D row ; + } + x +=3D w + SPACING ; + } + /* If there was only one row, increse the height by TABDELTA */ + if( ++row =3D=3D 1 ) + { + y =3D TABDELTA ; + if( !query_only ) + for(i=3Dnum_children, childP=3Dtw->composite.children; + --i >=3D 0 ; ++childP) + { + tab =3D (TabsConstraints) (*childP)->core.constraints ; + tab->tabs.y =3D y ; + } + } + y +=3D tw->tabs.tab_height ; + } + else + row =3D y =3D 0 ; + + if( !query_only ) { + tw->tabs.tab_total =3D y ; + tw->tabs.numRows =3D row ; + } + + if( reply_height !=3D NULL ) + *reply_height =3D y ; + + return row ; +} + + + + /* Find max preferred child size. Returned sizes include child + * border widths. */ + +static void +MaxChild(tw, reply_cw, reply_ch,= except) + TabsWidget tw; + Dimension *reply_cw, *reply_ch; /* child widget size */ + Widget except ; /* ignore this child */ +{ + XtWidgetGeometry preferred ; + Dimension cw,ch ; /* child width, height */ + int i ; + int num_children =3D tw->composite.num_children ; + Widget *childP ; + TabsConstraints tab ; + + + cw =3D ch =3D 0 ; + + for(i=3D0, childP=3Dtw->composite.children; i < num_children; ++i,= ++childP) + { + tab =3D (TabsConstraints) (*childP)->core.constraints ; + if( *childP !=3D except ) + { + (void) XtQueryGeometry(*childP, NULL, &preferred) ; + tab->tabs.bwid =3D preferred.border_width ; + + cw =3D Max(cw, preferred.width + 2*preferred.border_width) ; + ch =3D Max(ch, preferred.height + 2*preferred.border_width) ; + } + } + + *reply_cw =3D cw ; + *reply_ch =3D ch ; +} + + + + /* rotate row numbers to bring current widget to bottom row, + * compute y positions for all tabs + = */ + +static void +TabsShuffleRows(tw) + TabsWidget tw; +{ + TabsConstraints tab ; + int move ; + int nrows ; + Widget *childP ; + Dimension th =3D tw->tabs.tab_height ; + Position bottom ; + int i ; + + /* There must be a top widget. If not, assign one. */ + if( tw->tabs.topWidget =3D=3D NULL && tw->composite.children !=3D NULL= ) + tw->tabs.topWidget =3D *tw->composite.children ; + + if( tw->tabs.topWidget !=3D NULL ) + { + nrows =3D tw->tabs.numRows ; + assert( nrows > 0 ) ; + + if( nrows > 1 ) + { + tab =3D (TabsConstraints) tw->tabs.topWidget->core.constraints ; + assert( tab !=3D NULL ) ; + + /* how far to move top row */ + move =3D nrows - tab->tabs.row ; + bottom =3D tw->tabs.tab_total - th ; + + for(i=3Dtw->composite.num_children, childP=3Dtw->composite.children; + --i >=3D 0; + ++childP) + { + tab =3D (TabsConstraints) (*childP)->core.constraints ; + tab->tabs.row =3D (tab->tabs.row + move) % nrows ; + tab->tabs.y =3D bottom - tab->tabs.row * th ; + } + } + } +} + + + /* find preferred size. Ask children, find size of largest, + * add room for tabs & return. This can get a little involved, + * as we don't want to have too many rows of tabs; we may widen + * the widget to reduce # of rows. + */ + +static int +PreferredSize(tw, reply_width, reply_height, reply_cw,= reply_ch) + TabsWidget tw; + Dimension *reply_width, *reply_height; /* total widget size= */ + Dimension *reply_cw, *reply_ch; /* child widget size= */ +{ + Dimension cw,ch ; /* child width, height */ + Dimension wid,hgt ; + Dimension rwid,rhgt ; + int nrow ; + + + /* find max desired child height */ + MaxChild(tw, &cw, &ch, NULL) ; + + wid =3D cw ; + hgt =3D ch ; + + for(;;) { + nrow =3D PreferredSize2(tw, wid,hgt, &rwid, &rhgt) ; + + /* Check for absurd results (more than 2 rows, high aspect + * ratio). Try wider size if needed. + * TODO: make sure this terminates. + * TODO: compute width a little more conservatively. + */ + + if( nrow > 2 && rhgt*2 > rwid*3 ) + wid =3D Max(wid*3/2, wid+20) ; + else + break ; + } + + *reply_width =3D rwid ; + *reply_height =3D rhgt ; + if( reply_cw !=3D NULL ) *reply_cw =3D cw ; + if( reply_ch !=3D NULL ) *reply_ch =3D ch ; + return nrow ; +} + + + /* Find preferred size, given size of children.= */ + +static int +PreferredSize2(tw, cw,ch, reply_width,= reply_height) + TabsWidget tw; + int cw,ch ; /* child width, height */ + Dimension *reply_width, *reply_height; /* total widget size= */ +{ + Dimension s =3D SHADWID ; + + /* make room for shadow frame */ + cw +=3D s*2 ; + ch +=3D s*2 ; + + return PreferredSize3(tw, cw, ch, reply_width, reply_height) ; +} + + + /* Find preferred size, given size of children+shadow.= */ + +static int +PreferredSize3(tw, wid,hgt, reply_width,= reply_height) + TabsWidget tw; + Dimension wid,hgt ; /* child width, height */ + Dimension *reply_width, *reply_height; /* total widget size= */ +{ + Dimension th ; /* space used by tabs */ + int nrows ; + + if( tw->composite.num_children > 0 ) + nrows =3D TabLayout(tw, wid, &th, True) ; + else { + th =3D 0 ; + nrows =3D 0 ; + } + + *reply_width =3D Max(wid, MIN_WID) ; + *reply_height =3D Max(th+hgt, MIN_HGT) ; + + return nrows ; +} + + +static void +MakeSizeRequest(tw) + TabsWidget tw ; +{ + Widget w =3D (Widget)tw ; + XtWidgetGeometry request, reply ; + XtGeometryResult result ; + Dimension cw,ch ; + + request.request_mode =3D CWWidth | CWHeight ; + PreferredSize(tw, &request.width, &request.height, &cw, &ch) ; + + if( request.width =3D=3D tw->core.width && + request.height =3D=3D tw->core.height ) + return ; + + result =3D XtMakeGeometryRequest(w, &request, &reply) ; + + if( result =3D=3D XtGeometryAlmost ) + { + /* Bugger. Didn't get what we want, but were offered a + * compromise. If the width was too small, recompute + * based on the too-small width and try again. + * If the height was too small, make a wild-ass guess + * at a wider width and try again. + */ + + if( reply.width < request.width && reply.height >=3D request.height ) + { + Dimension s =3D SHADWID ; + ch +=3D s*2 ; + PreferredSize3(tw, reply.width,ch, &request.width,= &request.height); + result =3D XtMakeGeometryRequest(w, &request, &reply) ; + if( result =3D=3D XtGeometryAlmost ) { + (void) XtMakeGeometryRequest(w, &reply, NULL) ; + } + } + + else + (void) XtMakeGeometryRequest(w, &reply, NULL)= ; + } +} + + +static void +getBitmapInfo(tw, tab) + TabsWidget tw ; + TabsConstraints tab ; +{ + Window root ; + int x,y ; + unsigned int bw ; + + if( tab->tabs.left_bitmap =3D=3D None || + !XGetGeometry(XtDisplay(tw), tab->tabs.left_bitmap, &root, &x, &y, + &tab->tabs.lbm_width, &tab->tabs.lbm_height, + &bw, &tab->tabs.lbm_depth) ) + tab->tabs.lbm_width =3D tab->tabs.lbm_height =3D 0 ; +} + +=0C + + + /* Code copied & modified from Gcs.c. This version has dynamic + * foreground. + */ + +static void +TabsAllocFgGC(tw) + TabsWidget tw; +{ + Widget w =3D (Widget) tw; + XGCValues values ; + + values.background =3D tw->core.background_pixel ; + values.font =3D tw->tabs.font->fid ; + + tw->tabs.foregroundGC =3D + XtAllocateGC(w, w->core.depth, + GCBackground|GCFont, &values, + GCForeground, + = GCSubwindowMode|GCDashOffset|GCGraphicsExposures| + GCDashList|GCArcMode)= ; +} + +static void +TabsAllocGreyGC(tw) + TabsWidget tw; +{ + Widget w =3D (Widget) tw; + XGCValues values ; + + values.background =3D tw->core.background_pixel ; + values.font =3D tw->tabs.font->fid ; + + if( tw->tabs.be_nice_to_cmap || w->core.depth =3D=3D 1) + { + values.fill_style =3D FillStippled ; + tw->tabs.grey50 =3D + values.stipple =3D XmuCreateStippledPixmap(XtScreen(w), 1L, 0L, 1)= ; + + tw->tabs.greyGC =3D + XtAllocateGC(w, w->core.depth, + GCBackground|GCFont|GCStipple|GCFillStyle, &values, + GCForeground, + GCSubwindowMode|GCDashOffset|GCGraphicsExposures| + GCDashList|GCArcMode) ; + } + else + { + tw->tabs.greyGC =3D + XtAllocateGC(w, w->core.depth, + GCFont, &values, + GCForeground, + GCBackground|GCSubwindowMode|GCDashOffset| + GCDashList|GCArcMode|GCGraphicsExposures) ; + } +} + +#if XtSpecificationRelease < 5 + +static GC +XtAllocateGC(w, depth, mask, values, dynamic, dontcare) + Widget w ; + int depth ; + unsigned long mask, dynamic, dontcare ; + XGCValues *values ; +{ + return XtGetGC(w, mask, values) ; +} + +#endif Index: lwlib/xlwtabs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwtabs.h diff -N xlwtabs.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwtabs.h Wed Jul 28 01:34:02 1999 @@ -0,0 +1,197 @@ +/* Tabs Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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. */ + +/* $Id: Tabs.h,v 1.4 1999/06/23 18:19:12 falk Exp $ + * + * This widget manages one or more child widgets, exactly one of which is + * visible. Above the child widgets is a graphic that looks like index + * tabs from file folders. Each tab corresponds to one of the child= widgets. + * By clicking on a tab, the user can bring the corresponding widget to + * the top of the stack. + */ + + +#ifndef _Tabs_h +#define _Tabs_h + +#include= + + +/*********************************************************************** + * + * Tabs Widget (subclass of CompositeClass) + * += ***********************************************************************/ + +/* Parameters: + + Name Class RepType Default Value + ---- ----- ------- ------------- + font Font XFontStruct* XtDefaultFont + internalWidth Width Dimension 4 *1 + internalHeight Height Dimension 2 *1 + topWidget TopWidget Widget *2 + callback Callback XtCallbackList NULL *3 + popdownCallback Callback XtCallbackList NULL *4 + selectInsensitive SelectInsensitive Boolean True *5 + beNiceToColormap BeNiceToColormap Boolean False *6 + topShadowContrast TopShadowContrast int 20 + bottomShadowContrast BottomShadowContrast int 40 + insensitiveContrast InsensitiveContrast int 33 *7 + + background Background Pixel XtDefaultBackground + border BorderColor Pixel XtDefaultForeground + borderWidth BorderWidth Dimension 1 + destroyCallback Callback Pointer NULL + hSpace HSpace Dimension 4 + height Height Dimension 0 + mappedWhenManaged MappedWhenManaged Boolean True + orientation Orientation XtOrientation vertical + vSpace VSpace Dimension 4 + width Width Dimension 0 + x Position Position 0 + y Position Position 0 + + Notes: + + 1 internalWidth, internalHeight specify the margins around the text + in the tabs. + 2 topWidget identifies the widget which is currently visible. + 3 callbacks are called whenever the user selects a tab. Call_data is + the new top widget. + 4 popdownCallbacks are called whenever the user selects a tab. Call_data= is + the old (no longer visible) top widget. Note that popdownCallbacks + are called before callbacks. + 5 SelectInsensitive determines whether or not insensitive children may + be selected anyway. + 6 BeNiceToColormap causes the Tabs widget to use fewer colors. + 7 InsensitiveContrast sets the contrast used for labels of insensitive= widgets. + +*/ + +/* Constraint parameters: + Name Class RepType Default Value + ---- ----- ------- ------------- + tabLabel Label String widget name + tabLeftBitmap LeftBitmap Pixmap None + tabForeground Foreground Pixel XtDefaultForeground + resizable Resizable Boolean False +*/ + +/* New fields= */ + +#ifndef= XtNtabLabel +#define= XtNtabLabel= = "tabLabel" +#define= XtNtabForeground= "tabForeground" +#endif + +#ifndef= XtNtabLeftBitmap +#define= XtNtabLeftBitmap= "tabLeftBitmap" +#endif + +#ifndef= XtCLeftBitmap +#define= XtCLeftBitmap= "LeftBitmap" +#endif + +#ifndef= XtCResizable +#define= XtCResizable= "Resizable" +#endif + +#ifndef= XtNselectInsensitive +#define= XtNselectInsensitive= "selectInsensitive" +#define= XtCSelectInsensitive= "SelectInsensitive" +#endif + +#ifndef= XtNnlabels +#define= XtNnlabels= "nlabels" +#define= XtCNLabels= "NLabels" +#endif +#ifndef= XtNlabels +#define= XtNlabels= "labels" +#define= XtCLabels= "Labels" +#endif + +#ifndef= XtNtopWidget +#define= XtNtopWidget= "topWidget" +#define= XtCTopWidget= "TopWidget" +#endif + +#ifndef= XtNhSpace +#define= XtNhSpace= "hSpace" +#define= XtCHSpace= "HSpace" +#define= XtNvSpace= "vSpace" +#define= XtCVSpace= "VSpace" +#endif + +#ifndef= XtNresizable +#define= XtNresizable= "resizable" +#endif + +#ifndef= XtNinsensitiveContrast +#define= XtNinsensitiveContrast= "insensitiveContrast" +#define= XtCInsensitiveContrast= "InsensitiveContrast" +#endif + +#ifndef XtNshadowWidth +#define XtNshadowWidth "shadowWidth" +#define XtCShadowWidth "ShadowWidth" +#define XtNtopShadowPixel "topShadowPixel" +#define XtCTopShadowPixel "TopShadowPixel" +#define XtNbottomShadowPixel "bottomShadowPixel" +#define XtCBottomShadowPixel "BottomShadowPixel" +#define XtNtopShadowContrast "topShadowContrast" +#define XtCTopShadowContrast "TopShadowContrast" +#define XtNbottomShadowContrast "bottomShadowContrast" +#define XtCBottomShadowContrast= "BottomShadowContrast" +#endif + +#ifndef= XtNtopShadowPixmap +#define= XtNtopShadowPixmap= "topShadowPixmap" +#define= XtCTopShadowPixmap= "TopShadowPixmap" +#define= XtNbottomShadowPixmap= "bottomShadowPixmap" +#define= XtCBottomShadowPixmap= "BottomShadowPixmap" +#endif + +#ifndef XtNbeNiceToColormap +#define XtNbeNiceToColormap "beNiceToColormap" +#define XtCBeNiceToColormap "BeNiceToColormap" +#define XtNbeNiceToColourmap "beNiceToColormap" +#define XtCBeNiceToColourmap "BeNiceToColormap" +#endif + +/* Class record constants */ + +extern WidgetClass tabsWidgetClass; + +typedef struct _TabsClassRec *TabsWidgetClass; +typedef struct _TabsRec = *TabsWidget; + +_XFUNCPROTOBEGIN +extern void +XawTabsSetTop( +#if NeedFunctionPrototypes + Widget w, + int callCallbacks +#endif +) ; + +_XFUNCPROTOEND + +#endif /* _Tabs_h */ Index:= lwlib/xlwtabsP.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: xlwtabsP.h diff -N xlwtabsP.h --- /dev/null Tue Jul 27 14:08:36 1999 +++ lwlib/xlwtabsP.h Wed Jul 28 01:34:02 1999 @@ -0,0 +1,131 @@ +/* Tabs Widget for XEmacs. + Copyright (C) 1999 Edward A. Falk + +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: TabsP.h 1.4 */ + +/* + * TabsP.h - Private definitions for Index Tabs widget + */ + +#ifndef _TabsP_h +#define= _TabsP_h + +/*********************************************************************** + * + * Tabs Widget Private Data + * += ***********************************************************************/ + +#include +#include "xlwtabs.h" + +/* New fields for the Tabs widget class record */ +typedef struct {XtPointer extension;} TabsClassPart; + +/* Full class record declaration */ +typedef struct _TabsClassRec { + CoreClassPart core_class; + CompositeClassPart composite_class; + ConstraintClassPart constraint_class; + TabsClassPart tabs_class; +} TabsClassRec; + +extern TabsClassRec= tabsClassRec; + + + +/**************************************************************** + * + * instance record declaration + * + ****************************************************************/ + +/* New fields for the Tabs widget record */ +typedef struct { + /* resources */ + XFontStruct *font ; + Dimension internalHeight, internalWidth ; + Widget topWidget ; + XtCallbackList callbacks ; + XtCallbackList popdownCallbacks ; + Boolean selectInsensitive ; + Boolean be_nice_to_cmap ; + int top_shadow_contrast ; + int bot_shadow_contrast ; + int insensitive_contrast ; + + /* private state */ + GC foregroundGC ; + GC backgroundGC ; + GC greyGC ; + GC topGC ; + GC botGC ; + Dimension tab_height ; /* height of tabs (all the same) */ + /* Note: includes top shadow only */ + Dimension tab_total ; /* total height of all tabs */ + Dimension child_width, child_height; /* child size, including borders= */ + Cardinal numRows ; + XtGeometryMask last_query_mode; + Boolean needs_layout ; + Pixmap grey50 ; /* TODO: cache this elsewhere */ +} TabsPart; + + +typedef struct _TabsRec { + CorePart core; + CompositePart composite; + ConstraintPart constraint; + TabsPart tabs; +}= TabsRec; + + + + +/**************************************************************** + * + * constraint record declaration + * += ****************************************************************/ + +typedef struct _TabsConstraintsPart { + /* resources */ + String label ; + Pixmap left_bitmap ; + Pixel foreground ; + Boolean resizable ; + + /* private state */ + Pixel grey ; + Boolean greyAlloc ; + Dimension width ; /* tab width */ + Position x,y ; /* tab base position */ + short row ; /* tab row */ + Dimension bwid ; /* desired border width */ + Position l_x, l_y ; /* label position */ + Position lbm_x, lbm_y ; /* bitmap position */ + unsigned int lbm_width, lbm_height, lbm_depth ; +} TabsConstraintsPart ; + +typedef struct _TabsConstraintsRec { + TabsConstraintsPart tabs ; +} TabsConstraintsRec, *TabsConstraints ; + + +#endif /* _TabsP_h */ Index:= man/internals/internals.texi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file:= /usr/CVSroot/XEmacs/xemacs/man/internals/internals.texi,v retrieving revision 1.17.2.6 diff -u -r1.17.2.6 internals.texi --- man/internals/internals.texi 1999/05/21 05:25:24 1.17.2.6 +++ man/internals/internals.texi 1999/07/28 08:34:33 @@ -7785,10 +7785,74 @@ stack-of-extents code, which does the heavy-duty algorithmic work of determining which extents overly a particular position. -@node Faces and Glyphs, Specifiers, Extents, Top -@chapter Faces and Glyphs +@node Faces, Glyphs, Extents, Top +@chapter Faces Not yet documented. + +@node Glyphs, Specifiers, Faces, Top +@chapter Glyphs + +Glyphs are graphical elements that can be displayed in XEmacs buffers= or +gutters. We use the term graphical element here in the broadest= possible +sense since glyphs can be as mundane as text to as arcane as a native +tab widget. + +In XEmacs, glyphs represent the uninstantiated state of= graphical +elements, i.e. they hold all the information necessary to produce an +image on-screen but the image does not exist at this stage. + +Glyphs are lazily instantiated by calling one of the glyph +functions. This usually occurs within redisplay when +@code{Fglyph_height} is called. Instantiation causes an image-instance +to be created and cached. This cache is on a device basis for all= glyphs +except glyph-widgets, and on a window basis for glyph widgets. = The +caching is done by @code{image_instantiate} and is necessary because it +is generally possible to display an image-instance in multiple +domains. For instance if we create a Pixmap, we can actually display +this on multiple windows - even though we only need a single= Pixmap +instance to do this. If caching wasn't done then it would be necessary +to create image-instances for every displayable occurrance of a glyph= - +and every usage - and this would be extremely memory and cpu= intensive. + +Widget-glyphs (a.k.a native widgets) are not cached in this way. This= is +because widget-glyph image-instances on screen are toolkit windows,= and +thus cannot be reused in multiple XEmacs domains. Thus widget-glyphs= are +cached on a window basis. + +Any action on a glyph first consults the cache before= actually +instantiating a widget. + +@node Widget-Glyphs in the MS-WIndows Environment +@section Widget-Glyphs in the MS-WIndows Environment + +To Do + +@node Widget-Glyphs in the X Environment +@section Widget-Glyphs in the X Environment + +Widget-glyphs under X make heavy use of lwlib for manipulating the +native toolkit objects. This is primarily so that different toolkits= can +be supported for widget-glyphs, just as they are supported for= features +such as menubars etc. + +Lwlib is extremely poorly documented and quite hairy so here is= my +understanding of what goes on. + +Lwlib maintains a set of widget_instances which mirror the= hierarchical +state of Xt widgets. I think this is so that widgets can be updated= and +manipulated generically by the lwlib library. For= instance +update_one_widget_instance can cope with multiple types of widget= and +multiple types of toolkit. Each element in the widet hierarchy is= updated +from its corresponding widget_instance by walking the widget_instance +tree recursively. + +This has desirable properties such as lw_modify_all_widgets which= is +called from glyphs-x.c and updates all the properties of a widget +without having to know what the widget is or what toolkit it is= from. +Unfortunately this also has hairy properrties such as making the= lwlib +code quite complex. And of course lwlib has to know at some level what +the widget is and how to set its properties. @node Specifiers, Menus, Faces and Glyphs, Top @chapter Specifiers Index:= src/config.h.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v retrieving revision 1.49.2.10 diff -u -r1.49.2.10 config.h.in --- src/config.h.in 1999/06/23 22:05:21 1.49.2.10 +++ src/config.h.in 1999/07/28 08:34:37 @@ -597,12 +597,16 @@ #undef LWLIB_DIALOGS_MOTIF #undef LWLIB_DIALOGS_ATHENA #undef LWLIB_DIALOGS_ATHENA3D +#undef LWLIB_TABS_LUCID +#undef LWLIB_WIDGETS_MOTIF +#undef LWLIB_WIDGETS_ATHENA /* Other things that can be disabled by configure. */ #undef HAVE_MENUBARS #undef HAVE_SCROLLBARS #undef HAVE_DIALOGS #undef HAVE_TOOLBARS +#undef HAVE_WIDGETS #if defined (HAVE_MENUBARS) || defined (HAVE_DIALOGS) Index:= src/event-Xt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.10 diff -u -r1.41.2.10 event-Xt.c --- src/event-Xt.c 1999/07/22 06:19:55 1.41.2.10 +++ src/event-Xt.c 1999/07/28 08:34:44 @@ -1569,8 +1569,10 @@ break; case Expose: - x_redraw_exposed_area (f, event->xexpose.x, event->xexpose.y, - event->xexpose.width, event->xexpose.height); + if (!check_for_ignored_expose (f, event->xexpose.x,= event->xexpose.y, + event->xexpose.width,= event->xexpose.height)) + x_redraw_exposed_area (f, event->xexpose.x, event->xexpose.y, + event->xexpose.width, event->xexpose.height); break; case GraphicsExpose: /* This occurs when an XCopyArea's source area= was Index:= src/event-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.38.2.16 diff -u -r1.38.2.16 event-msw.c --- src/event-msw.c 1999/07/19 11:04:11 1.38.2.16 +++ src/event-msw.c 1999/07/28 08:34:51 @@ -1983,13 +1983,19 @@ case WM_PAINT: { PAINTSTRUCT paintStruct; + int x, y, width, height; frame =3D XFRAME (mswindows_find_frame (hwnd)); BeginPaint (hwnd, &paintStruct); - mswindows_redraw_exposed_area (frame, - paintStruct.rcPaint.left,= paintStruct.rcPaint.top, - paintStruct.rcPaint.right, paintStruct.rcPaint.bottom); + x =3D paintStruct.rcPaint.left; + y =3D paintStruct.rcPaint.top; + width =3D paintStruct.rcPaint.right - paintStruct.rcPaint.left; + height =3D paintStruct.rcPaint.bottom - paintStruct.rcPaint.top; + + if (!check_for_ignored_expose (frame, x, y, width,= height)) + mswindows_redraw_exposed_area (frame, x, y, width, height); + EndPaint (hwnd, &paintStruct); } break; Index:= src/frame.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.c,v retrieving revision 1.37.2.6 diff -u -r1.37.2.6 frame.c --- src/frame.c 1999/07/16 19:05:39 1.37.2.6 +++ src/frame.c 1999/07/28 08:34:59 @@ -209,6 +209,10 @@ /* cache of subwindows visible on frame */ f->subwindow_cachels =3D Dynarr_new (subwindow_cachel); + /* associated exposure ignore list */ + f->subwindow_exposures =3D 0; + f->subwindow_exposures_tail =3D 0; + /* Choose a buffer for the frame's root window. */ XWINDOW (root_window)->buffer =3D Qt; { Index:= src/frame.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.h,v retrieving revision 1.18.2.3 diff -u -r1.18.2.3 frame.h --- src/frame.h 1999/07/16 19:05:39 1.18.2.3 +++ src/frame.h 1999/07/28 08:35:03 @@ -94,6 +94,9 @@ /* subwindow cache elements for this frame */ subwindow_cachel_dynarr *subwindow_cachels; + struct expose_ignore* subwindow_exposures; + struct expose_ignore* subwindow_exposures_tail; + #ifdef HAVE_SCROLLBARS /* frame-local scrollbar information. See scrollbar.c. */ int scrollbar_y_offset; Index:= src/glyphs-msw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-msw.c,v retrieving revision 1.21.2.19 diff -u -r1.21.2.19 glyphs-msw.c --- src/glyphs-msw.c 1999/07/19 11:04:12 1.21.2.19 +++ src/glyphs-msw.c 1999/07/28 08:35:08 @@ -1,5 +1,5 @@ /* mswindows-specific glyph objects. - Copyright (C) 1998, 99 Andy Piper. + Copyright (C) 1998, 1999 Andy Piper. This file is part of XEmacs. @@ -2071,7 +2071,7 @@ /* buttons checked or otherwise */ if ( EQ (IMAGE_INSTANCE_WIDGET_TYPE (p), Qbutton)) { - if (gui_item_selected_p (IMAGE_INSTANCE_WIDGET_SINGLE_ITEM (p))) + if (gui_item_selected_p (IMAGE_INSTANCE_WIDGET_ITEM (p))) SendMessage (WIDGET_INSTANCE_MSWINDOWS_HANDLE (p), BM_SETCHECK, (WPARAM)BST_CHECKED, 0); else @@ -2101,7 +2101,7 @@ static int mswindows_register_widget_instance (Lisp_Object instance, Lisp_Object= domain) { - return mswindows_register_gui_item (XIMAGE_INSTANCE_WIDGET_SINGLE_ITEM= (instance), + return mswindows_register_gui_item (XIMAGE_INSTANCE_WIDGET_ITEM= (instance), domain); } @@ -2198,6 +2198,8 @@ } =0C +#ifdef HAVE_WIDGETS + /************************************************************************/ /* widgets */ = /************************************************************************/ @@ -2392,7 +2394,7 @@ /* instantiate a tree view widget */ static HTREEITEM add_tree_item (Lisp_Object image_instance, - HWND wnd, HTREEITEM parent, Lisp_Object entry, + HWND wnd, HTREEITEM parent, Lisp_Object item, int children, Lisp_Object domain) { TV_INSERTSTRUCT tvitem; @@ -2403,39 +2405,21 @@ tvitem.item.mask =3D TVIF_TEXT | TVIF_CHILDREN; tvitem.item.cChildren =3D children; - if (VECTORP (entry)) + if (GUI_ITEMP (item)) { - /* we always maintain the real gui item at the head of the - list. We have to put them in the list in the first place - because the whole model assumes that the glyph instances have - references to all the associated data. If we didn't do this - GC would bite us badly. */ - Lisp_Object gui =3D gui_parse_item_keywords_no_errors (entry); - =20 if (CONSP (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance))) - { - Lisp_Object rest =3D - Fcons (gui, XCDR (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance))); - Fsetcdr (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance), rest); - } - else - { - XIMAGE_INSTANCE_WIDGET_ITEM (image_instance) =3D - Fcons (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance), gui); - } - - tvitem.item.lParam =3D mswindows_register_gui_item (gui, domain); + tvitem.item.lParam =3D mswindows_register_gui_item (item, domain); tvitem.item.mask |=3D TVIF_PARAM; - GET_C_STRING_OS_DATA_ALLOCA (XGUI_ITEM (gui)->name, + GET_C_STRING_OS_DATA_ALLOCA (XGUI_ITEM (item)->name, tvitem.item.pszText); } else - GET_C_STRING_OS_DATA_ALLOCA (entry, tvitem.item.pszText); + GET_C_STRING_OS_DATA_ALLOCA (item, tvitem.item.pszText); tvitem.item.cchTextMax =3D strlen (tvitem.item.pszText); if ((ret =3D (HTREEITEM)SendMessage (wnd, TVM_INSERTITEM, 0, (LPARAM)&tvitem)) =3D=3D 0) - signal_simple_error ("error adding tree view entry", entry); + signal_simple_error ("error adding tree view entry", item); return ret; } @@ -2492,46 +2476,31 @@ /* instantiate a tab control */ static TC_ITEM* add_tab_item (Lisp_Object image_instance, - HWND wnd, Lisp_Object entry, + HWND wnd, Lisp_Object item, Lisp_Object domain, int index) { TC_ITEM tvitem, *ret; tvitem.mask =3D TCIF_TEXT; - if (VECTORP (entry)) + if (GUI_ITEMP (item)) { - /* we always maintain the real gui item at the head of the - list. We have to put them in the list in the first place - because the whole model assumes that the glyph instances have - references to all the associated data. If we didn't do this - GC would bite us badly. */ - Lisp_Object gui =3D gui_parse_item_keywords_no_errors (entry); - if (CONSP (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance))) - { - Lisp_Object rest =3D - Fcons (gui, XCDR (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance))); - Fsetcdr (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance), rest); - } - else - { - XIMAGE_INSTANCE_WIDGET_ITEM (image_instance) =3D - Fcons (XIMAGE_INSTANCE_WIDGET_ITEM (image_instance), gui); - } - - tvitem.lParam =3D mswindows_register_gui_item (gui, domain); + tvitem.lParam =3D mswindows_register_gui_item (item, domain); tvitem.mask |=3D TCIF_PARAM; - GET_C_STRING_OS_DATA_ALLOCA (XGUI_ITEM (gui)->name, + GET_C_STRING_OS_DATA_ALLOCA (XGUI_ITEM (item)->name, tvitem.pszText); } else - GET_C_STRING_OS_DATA_ALLOCA (entry, tvitem.pszText); + { + CHECK_STRING (item); + GET_C_STRING_OS_DATA_ALLOCA (item, tvitem.pszText); + } tvitem.cchTextMax =3D strlen (tvitem.pszText); if ((ret =3D (TC_ITEM*)SendMessage (wnd, TCM_INSERTITEM, index, (LPARAM)&tvitem)) < 0) - signal_simple_error ("error adding tab entry", entry); + signal_simple_error ("error adding tab entry", item); return ret; } @@ -2553,7 +2522,7 @@ wnd =3D WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii); /* add items to the tab */ - LIST_LOOP (rest, Fplist_get (IMAGE_INSTANCE_WIDGET_PROPS (ii), Q_items,= Qnil)) + LIST_LOOP (rest, XCDR (IMAGE_INSTANCE_WIDGET_ITEMS (ii))) { add_tab_item (image_instance, wnd, XCAR (rest), domain, index); index++; @@ -2577,8 +2546,12 @@ /* delete the pre-existing items */ SendMessage (wnd, TCM_DELETEALLITEMS, 0, 0); + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D + Fcons (XCAR (IMAGE_INSTANCE_WIDGET_ITEMS (ii)), + parse_gui_item_tree_children (val)); + /* add items to the tab */ - LIST_LOOP (rest, val) + LIST_LOOP (rest, XCDR (IMAGE_INSTANCE_WIDGET_ITEMS (ii))) { add_tab_item (image_instance, wnd, XCAR (rest), IMAGE_INSTANCE_SUBWINDOW_FRAME (ii), index); @@ -2753,6 +2726,7 @@ } return Qunbound; } +#endif /* HAVE_WIDGETS */ =0C = /************************************************************************/ @@ -2813,6 +2787,7 @@ #ifdef HAVE_GIF IIFORMAT_VALID_CONSOLE (mswindows, gif); #endif +#ifdef HAVE_WIDGETS /* button widget */ INITIALIZE_DEVICE_IIFORMAT (mswindows, button); IIFORMAT_HAS_DEVMETHOD (mswindows, button, property); @@ -2858,7 +2833,7 @@ INITIALIZE_DEVICE_IIFORMAT (mswindows, tab_control); IIFORMAT_HAS_DEVMETHOD (mswindows, tab_control, instantiate); IIFORMAT_HAS_DEVMETHOD (mswindows, tab_control, set_property); - +#endif /* windows bitmap format */ INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (bmp, "bmp"); IIFORMAT_HAS_METHOD (bmp, validate); Index:= src/glyphs-widget.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/glyphs-widget.c,v retrieving revision 1.1.2.7 diff -u -r1.1.2.7 glyphs-widget.c --- src/glyphs-widget.c 1999/07/19 11:04:12 1.1.2.7 +++ src/glyphs-widget.c 1999/07/28 08:35:09 @@ -1,5 +1,5 @@ /* Widget-specific glyph objects. - Copyright (C) 1998 Andy Piper + Copyright (C) 1998, 1999 Andy Piper. This file is part of XEmacs. @@ -61,7 +61,7 @@ Lisp_Object Q_descriptor, Q_height, Q_width, Q_properties, Q_items; Lisp_Object Q_image, Q_text, Q_percent; -#define WIDGET_BORDER_HEIGHT 2 +#define WIDGET_BORDER_HEIGHT 4 #define WIDGET_BORDER_WIDTH 4 /* TODO: @@ -96,7 +96,7 @@ int ch=3D0, cw=3D0; widget_face_font_info (domain, face, &ch, &cw); if (height) - *height =3D th * (ch + 2 * WIDGET_BORDER_HEIGHT); + *height =3D th * ch + 2 * WIDGET_BORDER_HEIGHT; if (width) *width =3D tw * cw + 2 * WIDGET_BORDER_WIDTH; } @@ -318,7 +318,7 @@ IMAGE_INSTANCE_WIDGET_TYPE (ii) =3D type; IMAGE_INSTANCE_WIDGET_PROPS (ii) =3D Qnil; IMAGE_INSTANCE_WIDGET_FACE (ii) =3D Vwidget_face; - IMAGE_INSTANCE_WIDGET_ITEM (ii) =3D allocate_gui_item (); + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D allocate_gui_item (); } /* Instantiate a button widget. Unfortunately instantiated widgets are @@ -341,6 +341,7 @@ Lisp_Object pixheight =3D find_keyword_in_vector (instantiator,= Q_pixel_height); Lisp_Object desc =3D find_keyword_in_vector (instantiator,= Q_descriptor); Lisp_Object glyph =3D find_keyword_in_vector (instantiator, Q_image); + Lisp_Object props =3D find_keyword_in_vector (instantiator,= Q_properties); int pw=3D0, ph=3D0, tw=3D0, th=3D0; /* this just does pixel type sizing */ @@ -357,8 +358,7 @@ IMAGE_INSTANCE_WIDGET_FACE (ii) =3D Fget_face (face); /* data items for some widgets */ - IMAGE_INSTANCE_WIDGET_PROPS (ii) =3D - find_keyword_in_vector (instantiator, Q_properties); + IMAGE_INSTANCE_WIDGET_PROPS (ii) =3D props; /* retrieve the gui item information. This is easy if we have been provided with a vector, more difficult if we have just been given @@ -366,13 +366,23 @@ if (STRINGP (desc) || NILP (desc)) { /* big cheat - we rely on the fact that a gui item looks like an= instantiator */ - IMAGE_INSTANCE_WIDGET_ITEM (ii) =3D + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D gui_parse_item_keywords_no_errors (instantiator); IMAGE_INSTANCE_WIDGET_TEXT (ii) =3D desc; } else - IMAGE_INSTANCE_WIDGET_ITEM (ii) =3D + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D gui_parse_item_keywords_no_errors (desc); + + /* parse more gui items out of the properties */ + if (!NILP (props)) + { + Lisp_Object items =3D Fplist_get (props, Q_items, Qnil); + if (!NILP (items)) + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D + Fcons (IMAGE_INSTANCE_WIDGET_ITEMS (ii), + parse_gui_item_tree_children (items)); + } /* normalize size information */ if (!NILP (width)) Index:= src/glyphs-x.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs-x.c,v retrieving revision 1.49.2.14 diff -u -r1.49.2.14 glyphs-x.c --- src/glyphs-x.c 1999/07/19 11:04:13 1.49.2.14 +++ src/glyphs-x.c 1999/07/28 08:35:15 @@ -73,7 +73,7 @@ #include "file-coding.h" #endif -#ifdef LWLIB_USES_MOTIF +#ifdef LWLIB_WIDGETS_MOTIF #include #endif #include @@ -122,12 +122,16 @@ DEFINE_IMAGE_INSTANTIATOR_FORMAT (autodetect); +#ifdef HAVE_WIDGETS DEFINE_DEVICE_IIFORMAT (x, widget); DEFINE_DEVICE_IIFORMAT (x, button); DEFINE_DEVICE_IIFORMAT (x, progress_gauge); DEFINE_DEVICE_IIFORMAT (x, edit_field); DEFINE_DEVICE_IIFORMAT (x, combo_box); +DEFINE_DEVICE_IIFORMAT (x, tab_control); +#endif +void check_valid_item_list_1 (Lisp_Object items); static void cursor_font_instantiate (Lisp_Object image_instance, Lisp_Object instantiator, Lisp_Object pointer_fg, @@ -371,8 +375,7 @@ { if (IMAGE_INSTANCE_SUBWINDOW_ID (p)) { - XtUnmanageChild (IMAGE_INSTANCE_X_WIDGET_ID (p)); - XtDestroyWidget (IMAGE_INSTANCE_X_WIDGET_ID (p)); + lw_destroy_widget (IMAGE_INSTANCE_X_WIDGET_ID (p)); IMAGE_INSTANCE_SUBWINDOW_ID (p) =3D 0; } } @@ -2045,11 +2048,11 @@ { if (IMAGE_INSTANCE_TYPE (p) =3D=3D IMAGE_WIDGET) { - widget_value* wv =3D xmalloc_widget_value (); - button_item_to_widget_value (IMAGE_INSTANCE_WIDGET_SINGLE_ITEM= (p), - wv, 1, 1); + widget_value* wv =3D gui_items_to_widget_values= + (IMAGE_INSTANCE_WIDGET_ITEMS (p)); lw_modify_all_widgets (IMAGE_INSTANCE_X_WIDGET_LWID (p), - wv, 1); + wv, True); + free_widget_value (wv); } } @@ -2147,6 +2150,9 @@ } } +=0C +#ifdef HAVE_WIDGETS + /************************************************************************/ /* widgets */ = /************************************************************************/ @@ -2168,12 +2174,12 @@ Arg al [32]; int ac =3D 0; int id =3D new_lwlib_id (); -#ifdef LWLIB_USES_MOTIF +#ifdef LWLIB_WIDGETS_MOTIF XmFontList fontList; #endif if (!DEVICE_X_P (d)) - signal_simple_error ("Not an mswindows device", device); + signal_simple_error ("Not an X device", device); /* have to set the type this late in case there is no device instantiation for a widget. But we can go ahead and do it without @@ -2201,7 +2207,7 @@ XtSetArg (al [ac], XtNbackground, bcolor.pixel); ac++; XtSetArg (al [ac], XtNforeground, fcolor.pixel); ac++; -#ifdef LWLIB_USES_MOTIF +#ifdef LWLIB_WIDGETS_MOTIF fontList =3D XmFontListCreate ((void*)FONT_INSTANCE_X_FONT (XFONT_INSTANCE (widget_face_font_info @@ -2215,6 +2221,8 @@ IMAGE_INSTANCE_WIDGET_FACE (ii), 0, 0)))); ac++; #endif + /* we cannot allow widgets to resize themselves */ + XtSetArg (al [ac], XtNresize, False); ac++; wv->nargs =3D ac; wv->args =3D al; @@ -2223,7 +2231,7 @@ False, 0, popup_selection_callback, 0); IMAGE_INSTANCE_X_WIDGET_LWID (ii) =3D id; -#ifdef LWLIB_USES_MOTIF +#ifdef LWLIB_WIDGETS_MOTIF XmFontListFree (fontList); #endif /* because the EmacsManager is the widgets parent we have to @@ -2311,7 +2319,7 @@ { Arg al [2]; int ac =3D0; -#ifdef LWLIB_USES_MOTIF +#ifdef LWLIB_WIDGETS_MOTIF XtSetArg (al [ac], XmNlabelType, XmPIXMAP); ac++; XtSetArg (al [ac], XmNlabelPixmap, XIMAGE_INSTANCE_X_PIXMAP= (glyph));ac++; #else @@ -2418,6 +2426,47 @@ } } +static void +x_tab_control_instantiate (Lisp_Object image_instance, Lisp_Object= instantiator, + Lisp_Object pointer_fg, Lisp_Object pointer_bg, + int dest_mask, Lisp_Object domain) +{ + struct Lisp_Image_Instance *ii =3D XIMAGE_INSTANCE (image_instance); + + widget_value * wv =3D + gui_items_to_widget_values (IMAGE_INSTANCE_WIDGET_ITEMS (ii)); + + x_widget_instantiate (image_instance, instantiator,= pointer_fg, + pointer_bg, dest_mask, domain, "tab-control", wv); +} + +/* set the properties of a tab control */ +static Lisp_Object +x_tab_control_set_property (Lisp_Object image_instance, Lisp_Object= prop, + Lisp_Object val) +{ + struct Lisp_Image_Instance *ii =3D XIMAGE_INSTANCE (image_instance); + + if (EQ (prop, Q_items)) + { + widget_value * wv =3D 0; + check_valid_item_list_1 (val); + + IMAGE_INSTANCE_WIDGET_ITEMS (ii) =3D + Fcons (XCAR (IMAGE_INSTANCE_WIDGET_ITEMS (ii)), + parse_gui_item_tree_children (val)); + + wv =3D gui_items_to_widget_values (IMAGE_INSTANCE_WIDGET_ITEMS= (ii)); + + lw_modify_all_widgets (IMAGE_INSTANCE_X_WIDGET_LWID (ii), wv,= True); + + free_widget_value (wv); + return Qt; + } + return Qunbound; +} +#endif /* HAVE_WIDGETS */ + =0C /************************************************************************/ /* initialization = */ @@ -2477,7 +2526,7 @@ INITIALIZE_DEVICE_IIFORMAT (x, subwindow); IIFORMAT_HAS_DEVMETHOD (x, subwindow, instantiate); -#ifdef LWLIB_USES_MOTIF +#ifdef HAVE_WIDGETS /* button widget */ INITIALIZE_DEVICE_IIFORMAT (x, button); IIFORMAT_HAS_DEVMETHOD (x, button, property); @@ -2498,6 +2547,10 @@ INITIALIZE_DEVICE_IIFORMAT (x, combo_box); IIFORMAT_HAS_DEVMETHOD (x, combo_box, instantiate); #endif + /* tab control widget */ + INITIALIZE_DEVICE_IIFORMAT (x, tab_control); + IIFORMAT_HAS_DEVMETHOD (x, tab_control, instantiate); + IIFORMAT_HAS_DEVMETHOD (x, tab_control, set_property); #endif INITIALIZE_IMAGE_INSTANTIATOR_FORMAT (cursor_font, "cursor-font"); IIFORMAT_VALID_CONSOLE (x, cursor_font); Index:= src/glyphs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v retrieving revision 1.23.2.15 diff -u -r1.23.2.15 glyphs.c --- src/glyphs.c 1999/07/05 07:28:24 1.23.2.15 +++ src/glyphs.c 1999/07/28 08:35:26 @@ -42,6 +42,7 @@ #include "frame.h" #include "chartab.h" #include "rangetab.h" +#include "blocktype.h" #ifdef HAVE_XPM #include @@ -122,6 +123,8 @@ static void glyph_property_was_changed (Lisp_Object glyph, Lisp_Object property, Lisp_Object locale); +static void register_ignored_expose (struct frame* f, int x, int y, int= width, int height); + EXFUN (Fimage_instance_type, 1); EXFUN (Fglyph_type, 1); @@ -179,13 +182,20 @@ int i; struct image_instantiator_methods* meths =3D decode_image_instantiator_format (format, ERROR_ME_NOT); - struct console* console =3D decode_console (locale); - Lisp_Object contype =3D console ? CONSOLE_TYPE (console) : locale; + Lisp_Object contype =3D Qnil; + /* mess with the locale */ + if (!NILP (locale) && SYMBOLP (locale)) + contype =3D locale; + else + { + struct console* console =3D decode_console (locale); + contype =3D console ? CONSOLE_TYPE (console) : locale; + } /* nothing is valid in all locales */ if (EQ (format, Qnothing)) return 1; /* reject unknown formats */ - else if (!console || !meths) + else if (NILP (contype) || !meths) return 0; for (i =3D 0; i < Dynarr_length (meths->consoles); i++) @@ -622,7 +632,7 @@ markobj (IMAGE_INSTANCE_WIDGET_TYPE (i)); markobj (IMAGE_INSTANCE_WIDGET_PROPS (i)); markobj (IMAGE_INSTANCE_WIDGET_FACE (i)); - markobj (IMAGE_INSTANCE_WIDGET_ITEM (i)); + markobj (IMAGE_INSTANCE_WIDGET_ITEMS (i)); case IMAGE_SUBWINDOW: markobj (IMAGE_INSTANCE_SUBWINDOW_FRAME (i)); break; @@ -859,8 +869,8 @@ case IMAGE_WIDGET: if (!(EQ (IMAGE_INSTANCE_WIDGET_TYPE (i1), IMAGE_INSTANCE_WIDGET_TYPE (i2)) - && internal_equal (IMAGE_INSTANCE_WIDGET_ITEM (i1), - IMAGE_INSTANCE_WIDGET_ITEM (i2), + && internal_equal (IMAGE_INSTANCE_WIDGET_ITEMS (i1), + IMAGE_INSTANCE_WIDGET_ITEMS (i2), depth + 1) && internal_equal (IMAGE_INSTANCE_WIDGET_PROPS (i1), IMAGE_INSTANCE_WIDGET_PROPS (i2), @@ -915,7 +925,7 @@ hash =3D HASH4 (hash, internal_hash (IMAGE_INSTANCE_WIDGET_TYPE (i), depth + 1), internal_hash (IMAGE_INSTANCE_WIDGET_PROPS (i), depth + 1), - internal_hash (IMAGE_INSTANCE_WIDGET_ITEM (i), depth + 1)); + internal_hash (IMAGE_INSTANCE_WIDGET_ITEMS (i), depth + 1)); case IMAGE_SUBWINDOW: hash =3D HASH4 (hash, IMAGE_INSTANCE_SUBWINDOW_WIDTH (i), IMAGE_INSTANCE_SUBWINDOW_HEIGHT (i), @@ -3678,8 +3688,71 @@ Dynarr_atp (f->subwindow_cachels, elt)->updated =3D 0; } + =0C = /**************************************************************************= *** + * subwindow exposure ignorance = * += ***************************************************************************= **/ +/* when we unmap subwindows the associated window system will generate + expose events. This we do not want as redisplay already copes with + the repainting necessary. Worse, we can get in an endless cycle of + redisplay if we are not careful. Thus we keep a per-frame list of + expose events that are going to come and ignore them as + required. */ + +struct expose_ignore_blocktype +{ + Blocktype_declare (struct expose_ignore); +} *the_expose_ignore_blocktype; + +int +check_for_ignored_expose (struct frame* f, int x, int y, int width, int= height) +{ + struct expose_ignore *ei, *prev; + /* the ignore list is FIFO so we should generally get a match with + the first element in the list */ + for (ei =3D f->subwindow_exposures, prev =3D 0; ei; ei =3D ei->next) + { + if (ei->x =3D=3D x && ei->y =3D=3D y && ei->width =3D=3D width &&= ei->height =3D=3D height) + { + if (!prev) + f->subwindow_exposures =3D ei->next; + else + prev->next =3D ei->next; + + if (ei =3D=3D f->subwindow_exposures_tail) + f->subwindow_exposures_tail =3D prev; + + Blocktype_free (the_expose_ignore_blocktype, ei); + return 1; + } + prev =3D ei; + } + return 0; +} + +static void +register_ignored_expose (struct frame* f, int x, int y, int width, int= height) +{ + struct expose_ignore *ei; + + ei =3D Blocktype_alloc (the_expose_ignore_blocktype); + + ei->next =3D NULL; + ei->x =3D x; + ei->y =3D y; + ei->width =3D width; + ei->height =3D height; + + if (f->subwindow_exposures_tail) + { + f->subwindow_exposures_tail->next =3D ei; + } + f->subwindow_exposures =3D= ei; +} + +=0C +/**************************************************************************= *** * subwindow functions = * = ***************************************************************************= **/ @@ -3734,6 +3807,8 @@ elt =3D get_subwindow_cachel_index (f, subwindow); cachel =3D Dynarr_atp (f->subwindow_cachels, elt); + /* make sure we don't get expose events */ + register_ignored_expose (f, cachel->x, cachel->y, cachel->width,= cachel->height); cachel->x =3D -1; cachel->y =3D -1; cachel->being_displayed =3D 0; @@ -4195,6 +4270,9 @@ list6 (Qtext, Qmono_pixmap, Qcolor_pixmap, Qpointer, Qsubwindow, Qwidget)); staticpro (&Vimage_instance_type_list); + + the_expose_ignore_blocktype =3D + Blocktype_new (struct expose_ignore_blocktype); /* glyphs */ Index:= src/glyphs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.h,v retrieving revision 1.18.2.13 diff -u -r1.18.2.13 glyphs.h --- src/glyphs.h 1999/07/05 07:28:25 1.18.2.13 +++ src/glyphs.h 1999/07/28 08:35:26 @@ -493,11 +493,11 @@ #define IMAGE_INSTANCE_WIDGET_TYPE(i) ((i)->u.subwindow.widget.type) #define IMAGE_INSTANCE_WIDGET_PROPS(i) ((i)->u.subwindow.widget.props) #define IMAGE_INSTANCE_WIDGET_FACE(i)= ((i)->u.subwindow.widget.face) -#define IMAGE_INSTANCE_WIDGET_ITEM(i)= ((i)->u.subwindow.widget.gui_item) -#define IMAGE_INSTANCE_WIDGET_SINGLE_ITEM(i) \ -(CONSP (IMAGE_INSTANCE_WIDGET_ITEM (i)) ? \ -XCAR (IMAGE_INSTANCE_WIDGET_ITEM (i)) : \ - IMAGE_INSTANCE_WIDGET_ITEM (i)) +#define IMAGE_INSTANCE_WIDGET_ITEMS(i)= ((i)->u.subwindow.widget.gui_item) +#define IMAGE_INSTANCE_WIDGET_ITEM(i) \ +(CONSP (IMAGE_INSTANCE_WIDGET_ITEMS (i)) ? \ +XCAR (IMAGE_INSTANCE_WIDGET_ITEMS (i)) : \ + IMAGE_INSTANCE_WIDGET_ITEMS (i)) #define IMAGE_INSTANCE_WIDGET_TEXT(i) XGUI_ITEM (IMAGE_INSTANCE_WIDGET_ITEM= (i))->name #define XIMAGE_INSTANCE_DEVICE(i) \ @@ -541,8 +541,8 @@ IMAGE_INSTANCE_WIDGET_FACE (XIMAGE_INSTANCE (i)) #define XIMAGE_INSTANCE_WIDGET_ITEM(i) \ IMAGE_INSTANCE_WIDGET_ITEM (XIMAGE_INSTANCE (i)) -#define XIMAGE_INSTANCE_WIDGET_SINGLE_ITEM(i) \ - IMAGE_INSTANCE_WIDGET_SINGLE_ITEM (XIMAGE_INSTANCE (i)) +#define XIMAGE_INSTANCE_WIDGET_ITEMS(i) \ + IMAGE_INSTANCE_WIDGET_ITEMS (XIMAGE_INSTANCE (i)) #define XIMAGE_INSTANCE_WIDGET_TEXT(i) \ IMAGE_INSTANCE_WIDGET_TEXT (XIMAGE_INSTANCE (i)) @@ -768,5 +768,16 @@ void unmap_subwindow (Lisp_Object subwindow); void map_subwindow (Lisp_Object subwindow, int x, int y); void update_frame_subwindows (struct frame *f); + +struct expose_ignore +{ + int x; + int y; + int width; + int height; + struct expose_ignore *next; +}; + +int check_for_ignored_expose (struct frame* f, int x, int y, int width, int= height); #endif /* _XEMACS_GLYPHS_H_ */ Index:= src/gui-x.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/gui-x.c,v retrieving revision 1.14.2.6 diff -u -r1.14.2.6 gui-x.c --- src/gui-x.c 1999/06/28 16:15:57 1.14.2.6 +++ src/gui-x.c 1999/07/28 08:35:29 @@ -448,7 +448,113 @@ return 1; } +/* parse tree's of gui items into widget_value hierarchies */ +static void gui_item_children_to_widget_values (Lisp_Object items,= widget_value* parent); +static widget_value * +gui_items_to_widget_values_1 (Lisp_Object items, widget_value* parent, + widget_value* prev) +{ + widget_value* wv =3D 0; + Lisp_Object rest; + + assert ((parent || prev) && !(parent && prev)); + /* now walk the tree creating widget_values as appropriate */ + if (!CONSP (items)) + { + wv =3D xmalloc_widget_value(); + if (parent) + parent->contents =3D wv; + else + prev->next =3D wv; + if (!button_item_to_widget_value (items, wv, 0, 1)) + { + free_widget_value (wv); + if (parent) + parent->contents =3D 0; + else + prev->next =3D 0; + } + else + { + wv->value =3D xstrdup (wv->name); /* what a mess... */ + } + } + else + { + /* first one is the parent */ + if (CONSP (XCAR (items))) + signal_simple_error ("parent item must not be a list", XCAR (items)); + + if (parent) + wv =3D gui_items_to_widget_values_1 (XCAR (items), parent, 0); + else + wv =3D gui_items_to_widget_values_1 (XCAR (items), 0, prev); + /* the rest are the children */ + gui_item_children_to_widget_values (XCDR (items), wv); + } + return wv; +} + +static void +gui_item_children_to_widget_values (Lisp_Object items, widget_value*= parent) +{ + widget_value* wv =3D 0, *prev =3D 0; + Lisp_Object rest; + CHECK_CONS (items); + + /* first one is master */ + prev =3D gui_items_to_widget_values_1 (XCAR (items), parent, 0); + /* the rest are the children */ + LIST_LOOP (rest, XCDR (items)) + { + Lisp_Object tab =3D XCAR (rest); + wv =3D gui_items_to_widget_values_1 (tab, 0, prev); + prev =3D wv; + } +} + +widget_value * +gui_items_to_widget_values (Lisp_Object items) +{ + /* !!#### This function has not been Mule-ized */ + /* This function can GC */ + widget_value *control =3D 0, *tmp =3D 0; + int count =3D specpdl_depth (); + Lisp_Object wv_closure, rest; + + if (NILP (items)) + signal_simple_error ("must have some items", items); + + /* Inhibit GC during this conversion. The reasons for this are + the same as in menu_item_descriptor_to_widget_value(); see + the large comment above that function. */ + record_unwind_protect (restore_gc_inhibit, + make_int (gc_currently_forbidden)); + gc_currently_forbidden =3D 1; + + /* Also make sure that we free the partially-created widget_value + tree on Lisp error. */ + control =3D xmalloc_widget_value(); + wv_closure =3D make_opaque_ptr (control); + record_unwind_protect (widget_value_unwind, wv_closure); + + gui_items_to_widget_values_1 (items, control, 0); + + /* mess about getting the data we really want */ + tmp =3D control; + control =3D control->contents; + tmp->next =3D 0; + tmp->contents =3D 0; + free_widget_value (tmp); + + /* No more need to free the half-filled-in structures. */ + set_opaque_ptr (wv_closure, 0); + unbind_to (count, Qnil); + + return control; +} + /* This is a kludge to make sure emacs can only link against a version of lwlib that was compiled in the right way. Emacs references symbols= which correspond to the way it thinks lwlib was compiled, and if lwlib= wasn't @@ -497,6 +603,11 @@ MACROLET (lwlib_dialogs_motif); #elif defined (HAVE_DIALOGS) MACROLET (lwlib_dialogs_athena); +#endif +#ifdef LWLIB_WIDGETS_MOTIF + MACROLET (lwlib_widgets_motif); +#elif defined (HAVE_WIDGETS) + MACROLET (lwlib_widgets_athena); #endif #undef MACROLET Index:= src/gui-x.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/gui-x.h,v retrieving revision 1.5 diff -u -r1.5 gui-x.h --- src/gui-x.h 1998/03/31 20:11:48 1.5 +++ src/gui-x.h 1999/07/28 08:35:29 @@ -73,6 +73,7 @@ XtPointer client_data); int button_item_to_widget_value (Lisp_Object desc, widget_value *wv, int allow_text_field_p, int no_keys_p); +widget_value * gui_items_to_widget_values (Lisp_Object items); Lisp_Object menu_name_to_accelerator (char *name); char *menu_separator_style (CONST char *s); Lisp_Object widget_value_unwind (Lisp_Object closure); Index:= src/gui.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/gui.c,v retrieving revision 1.10.2.8 diff -u -r1.10.2.8 gui.c --- src/gui.c 1999/06/25 14:16:47 1.10.2.8 +++ src/gui.c 1999/07/28 08:35:29 @@ -561,6 +561,56 @@ write_c_string (buf, printcharfun); } +/* parse a glyph descriptor into a tree of gui items. + + The gui_item slot of an image instance can be a single item or an + arbitrarily nested hierarchy of item lists. */ + +static Lisp_Object parse_gui_item_tree_item (Lisp_Object entry) +{ + Lisp_Object ret =3D entry; + if (VECTORP (entry)) + { + ret =3D gui_parse_item_keywords_no_errors (entry); + } + else if (STRINGP (entry)) + { + CHECK_STRING (entry); + } + else + signal_simple_error ("item must be a vector or a string", entry); + + return ret; +} + +Lisp_Object parse_gui_item_tree_children (Lisp_Object list) +{ + Lisp_Object rest, ret =3D Qnil; + CHECK_CONS (list); + /* recursively add items to the tree view */ + LIST_LOOP (rest, list) + { + Lisp_Object sub; + if (CONSP (XCAR (rest))) + sub =3D parse_gui_item_tree_list (XCAR (rest)); + else + sub =3D parse_gui_item_tree_item (XCAR (rest)); + + ret =3D Fcons (sub, ret); + } + /* make the order the same as the items we have parsed */ + return Fnreverse (ret); +} + +Lisp_Object parse_gui_item_tree_list (Lisp_Object list) +{ + Lisp_Object ret; + CHECK_CONS (list); + /* first one can never be a list */ + ret =3D parse_gui_item_tree_item (XCAR (list)); + return Fcons (ret, parse_gui_item_tree_children (XCDR (list))); +} + DEFINE_LRECORD_IMPLEMENTATION ("gui-item", gui_item, mark_gui_item, print_gui_item, 0, gui_item_equal, Index:= src/gui.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/gui.h,v retrieving revision 1.6.2.5 diff -u -r1.6.2.5 gui.h --- src/gui.h 1999/06/25 14:16:47 1.6.2.5 +++ src/gui.h 1999/07/28 08:35:29 @@ -85,6 +85,8 @@ Lisp_Object allocate_gui_item (); void gui_item_init (Lisp_Object gui_item); +Lisp_Object parse_gui_item_tree_list (Lisp_Object list); +Lisp_Object parse_gui_item_tree_children (Lisp_Object list); /* this is mswindows biased but reasonably safe I think */ #define GUI_ITEM_ID_SLOTS 8 Index:= src/gutter.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/Attic/gutter.c,v retrieving revision 1.1.2.3 diff -u -r1.1.2.3 gutter.c --- src/gutter.c 1999/07/21 07:42:16 1.1.2.3 +++ src/gutter.c 1999/07/28 08:35:32 @@ -20,7 +20,8 @@ /* Synched up with: Not in FSF. */ -/* Specifers ripped-off from toolbar.c */ +/* written by Andy Piper with specifiers partially + ripped-off from toolbar.c */ #include #include "lisp.h" @@ -345,7 +346,6 @@ int width, int height) { int g_x, g_y, g_width, g_height; - int newx, newy; get_gutter_coords (f, pos, &g_x, &g_y, &g_width, &g_height); @@ -360,13 +360,16 @@ if (f->current_display_lines) Dynarr_reset (f->current_display_lines); /* we have to do this in-case there were subwindows where we are - redrawing, unfortunately sometimes this also generates expose - events resulting in an endless cycle of redsplay. */ + redrawing, unfortunately this also generates expose events - + unless we are careful to ignore them - resulting in an endless + cycle of redsplay. */ +#if 0 newx =3D max (x, g_x); newy =3D max (y, g_y); width =3D min (x + width - newx, g_x + g_width - newx); height =3D min (y + height - newy, g_y + g_height - newy); - redisplay_unmap_subwindows_maybe (f, newx, newy, width,= height); +#endif + redisplay_unmap_subwindows_maybe (f, g_x, g_y, g_width, g_height); /* Even if none of the gutter is in the area, the blank region at the very least must be because the first thing we did is verify Index:= src/redisplay-output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-output.c,v retrieving revision 1.11.2.6 diff -u -r1.11.2.6 redisplay-output.c --- src/redisplay-output.c 1999/07/16 19:05:41 1.11.2.6 +++ src/redisplay-output.c 1999/07/28 08:35:36 @@ -1332,7 +1332,6 @@ int min_start, int max_end) { struct frame *f =3D XFRAME (w->frame); - struct device *d =3D XDEVICE (f->device); int ypos1, ypos2; int ddla_len =3D Dynarr_length (ddla); Index:= tests/glyph-test.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVSroot/XEmacs/xemacs/tests/Attic/glyph-test.el,v retrieving revision 1.1.2.10 diff -u -r1.1.2.10 glyph-test.el --- tests/glyph-test.el 1999/07/19 11:04:15 1.1.2.10 +++ tests/glyph-test.el 1999/07/28 08:35:36 @@ -8,6 +8,8 @@ (ding)) ; (setq ok-select (not ok-select))) +(defun fee () (interactive) (message "hello")) + ;; button in a group (setq ok-select nil) (set-extent-begin-glyph @@ -60,7 +62,7 @@ [tab-control :descriptor "My Tab" :face default :properties (:items (["One" foo] - ["Two" foo] + ["Two" fee] ["Three" foo]))]))) ;; progress gauge --=====================_933159644==_ Content-Type: text/plain; charset="us-ascii" -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd --=====================_933159644==_-- From owner-xemacs-beta@xemacs.org Wed Jul 28 08:31:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA24801 for xemacs-beta-out; Wed, 28 Jul 1999 08:31:50 -0400 Received: from tweed.ppllc.com (mail1.ppllc.com [209.208.206.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA24797 for ; Wed, 28 Jul 1999 08:31:49 -0400 Received: (from colman@localhost) by tweed.ppllc.com (8.9.0/8.9.0) id IAA07967; Wed, 28 Jul 1999 08:42:05 -0400 (EDT) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> X-Attribution: Jake X-URL: http://www.ppllc.com From: Jake Colman Date: 28 Jul 1999 08:42:03 -0400 In-Reply-To: Hrvoje Niksic's message of "28 Jul 1999 04:19:20 +0200" Message-ID: <767lnl9c9w.fsf@ppllc.com> Lines: 20 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) 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> Here is the patch for it to work with itimers. It could probably Hrvoje> be coded better (e.g. using the RESTART feature of itimers), but Hrvoje> this should do for starters. Any chance that the new portions of FSF Emacs 20.4 be made available in a 21.1.5 release? Or is the 21.1 series frozen (except for bug fixes) and all new stuff is in 21.2? -- 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 From owner-xemacs-beta@xemacs.org Wed Jul 28 09:30:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26992 for xemacs-beta-out; Wed, 28 Jul 1999 09:30:59 -0400 Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA26988 for ; Wed, 28 Jul 1999 09:30:58 -0400 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id IAA28506 for ; Wed, 28 Jul 1999 08:30:10 -0500 (CDT) 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 IAA09390 for ; Wed, 28 Jul 1999 08:30:19 -0500 (CDT) Received: from wcsdsp3 (wcsdsp3.rtp.ericsson.se [147.117.125.240]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id JAA27329 for ; Wed, 28 Jul 1999 09:30:03 -0400 (EDT) Received: (toy@localhost) by wcsdsp3 (8.6.8/8.6.8) id JAA01164; Wed, 28 Jul 1999 09:30:18 -0400 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> From: Raymond Toy Date: 28 Jul 1999 09:30:18 -0400 In-Reply-To: SL Baur's message of "28 Jul 1999 13:21:10 +0900" Message-ID: <4n6734x5p1.fsf@rtp.ericsson.se> Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Because normal-mode restores the font lock state. >> P.S. I am using lazy-shot.el that sim sb> I am using fast-lock. Could this be the key? I've noticed that after revert-buffer on large files lazy-shot doesn't fontify anything. Only new stuff is fontified. Existing stuff that hasn't been changed isn't fontified. So perhaps lazy-shot is getting confused after revert-buffer about what has been fontified and what has not? Ray From owner-xemacs-beta@xemacs.org Wed Jul 28 10:03:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA28052 for xemacs-beta-out; Wed, 28 Jul 1999 10:03:51 -0400 Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA28047 for ; Wed, 28 Jul 1999 10:03:49 -0400 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA28587 for ; Wed, 28 Jul 1999 09:03:45 -0500 (CDT) 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 JAA11383 for ; Wed, 28 Jul 1999 09:03:20 -0500 (CDT) Received: from wcsdsp3 (wcsdsp3.rtp.ericsson.se [147.117.125.240]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id KAA28645 for ; Wed, 28 Jul 1999 10:03:42 -0400 (EDT) Received: (toy@localhost) by wcsdsp3 (8.6.8/8.6.8) id KAA01190; Wed, 28 Jul 1999 10:03:57 -0400 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4n6734x5p1.fsf@rtp.ericsson.se> From: Raymond Toy Date: 28 Jul 1999 10:03:57 -0400 In-Reply-To: Raymond Toy's message of "28 Jul 1999 09:30:18 -0400" Message-ID: <4n3dy8x44y.fsf@rtp.ericsson.se> Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Raymond" == Raymond Toy writes: >>>>> "sb" == SL Baur writes: sb> Because normal-mode restores the font lock state. >>> P.S. I am using lazy-shot.el that sim sb> I am using fast-lock. Raymond> Could this be the key? I've noticed that after Raymond> revert-buffer on large files lazy-shot doesn't fontify Raymond> anything. Only new stuff is fontified. Existing stuff Raymond> that hasn't been changed isn't fontified. So perhaps Raymond> lazy-shot is getting confused after revert-buffer about Raymond> what has been fontified and what has not? lazy-shot is part of the problem. When I turn off lazy-shot and use the default font-lock, my test case gets correctly fontified on revert-buffer. This always failed with lazy-shot. Ray From owner-xemacs-beta@xemacs.org Wed Jul 28 10:11:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA28339 for xemacs-beta-out; Wed, 28 Jul 1999 10:11:04 -0400 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA28335 for ; Wed, 28 Jul 1999 10:11:03 -0400 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA40342 for ; Wed, 28 Jul 1999 10:10:41 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id KAA78932 for ; Wed, 28 Jul 1999 10:10:55 -0400 Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 2695 ; Wed, 28 Jul 1999 08:10:17 MDT Received: by FISHKILL (XAGENTA 4.0) id 2370; Wed, 28 Jul 1999 10:10:24 -0400 Received: from sstpok-11.pok.ibm.com by edamail.fishkill.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA45702; Wed, 28 Jul 1999 10:10:48 -0400 From: "Charles Hines" Message-Id: <14239.3944.586604.150418@sstpok-11.pok.ibm.com> Date: Wed, 28 Jul 1999 10:10:48 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: Speaking of isearch-mode.el... X-Mailer: VM 6.71 under 21.1 (patch 3) "Acadia" XEmacs Lucid X-Face: 'pn"gAx+&w4-=-}\z>*.Y*@(lC;t1J[a,/Q.Yv0^Wwc6_"H]}}-"?%)ETS`1v[]P`w4,E.9Bgf*XI4 Since there seems to be an interest in isearch-mode.el right now, I'll ask a question I asked a long time ago - anybody know why using history with isearch is broken? For example, try this: run xemacs -q clear scratch buffer with C-_ enter 'a b c a b c a b c ' isearch for a from beginning of buffer (M-< C-s a) stop isearch, then isearch for b (M-< C-s b) stop isearch, then isearch for c (M-< C-s c) stop isearch, then isearch for c again, using M-p to recall it, search for it twice, second time it starts looking for b instead of c (M-< C-s M-p M-p M-p C-s C-s) I've tried a couple of times (half-heartedly, I admit) to debug it, but haven't had much success other than it looks like the search-ring and search-ring-yank-pointer get out of sync at some point... The vanilla Emacs 20.4 isearch.el doesn't suffer from this, I noted, but they were enough different that it didn't really help me figure it out. Anyone have any ideas? Chuck -- Charles K. Hines IBM Logic Synthesis Developer [BooleDozer (TM)] Martial Arts Instructor [Modern Arnis and Balintawak Escrima] "Go back to sleep, Chuck. You're just havin' a nightmare -- of course, we ARE still in Hell." (Gary Larson) From owner-xemacs-beta@xemacs.org Wed Jul 28 10:20:54 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA28920 for xemacs-beta-out; Wed, 28 Jul 1999 10:20:54 -0400 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 KAA28915 for ; Wed, 28 Jul 1999 10:20:51 -0400 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 KAA01238 for ; Wed, 28 Jul 1999 10:26:47 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id QAA15574; Wed, 28 Jul 1999 16:20:40 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4n6734x5p1.fsf@rtp.ericsson.se> 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: 28 Jul 1999 16:20:46 +0200 In-Reply-To: Raymond Toy's message of "28 Jul 1999 09:30:18 -0400" Message-ID: Lines: 44 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Raymond" == Raymond Toy writes: >>>>> "sb" == SL Baur writes: sb> Because normal-mode restores the font lock state. >>> P.S. I am using lazy-shot.el that sim sb> I am using fast-lock. Raymond> Could this be the key? I've noticed that after Right on: With an unpatched vc.elc? fontification survives vc-revert-buffer when I have this in my .emacs: (setq font-lock-support-mode 'fast-lock-mode) Fontification is lost when I use any of these: (setq font-lock-support-mode 'font-lock-mode) (setq font-lock-support-mode 'lazy-lock-mode) For font-lock-mode fontification is lost after `revert-buffer' calls `insert-file-contents'. All of this in 21.1.4 WindowsNT4sp4 native. BTW: Although font-lock-support-mode is documented, it does not seem to be defined anywhere. Is this intentinal? Seem to me it should be defcustomed to take on any of the three choices above. Regards, Adrian Raymond> revert-buffer on large files lazy-shot doesn't fontify Raymond> anything. Only new stuff is fontified. Existing stuff Raymond> that hasn't been changed isn't fontified. So perhaps Raymond> lazy-shot is getting confused after revert-buffer about Raymond> what has been fontified and what has not? Raymond> Ray From owner-xemacs-beta@xemacs.org Wed Jul 28 10:45:58 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA30069 for xemacs-beta-out; Wed, 28 Jul 1999 10:45:58 -0400 Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.10.126]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA30064 for ; Wed, 28 Jul 1999 10:45:56 -0400 Received: from localhost.icd.teradyne.com (localhost.icd.teradyne.com) by ICD.Teradyne.COM (8.8.5/8.8.5) with SMTP id KAA08599; Wed, 28 Jul 1999 10:39:19 -0400 (EDT) Received: by dusk1.afive (SMI-8.6/SMI-SVR4) id KAA22677; Wed, 28 Jul 1999 10:45:00 -0400 To: Jake Colman Cc: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature From: Vin Shelton Organization: The XEmacs Development Team References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> Date: 28 Jul 1999 10:45:00 -0400 In-Reply-To: Jake Colman's message of "28 Jul 1999 08:42:03 -0400" Message-ID: <545zp0ghlzn.fsf@dusk1.icd.teradyne.com> Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On 28 Jul 1999, Jake Colman said: Jake> Any chance that the new portions of FSF Emacs 20.4 be made available in a Jake> 21.1.5 release? Or is the 21.1 series frozen (except for bug fixes) and all Jake> new stuff is in 21.2? The 21.1.x series is reserved for bug fixes, so any new stuff which comes in from FSF Emacs 20.4 will only be in 21.2.x. - vin -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot From owner-xemacs-beta@xemacs.org Wed Jul 28 10:47:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA30146 for xemacs-beta-out; Wed, 28 Jul 1999 10:47:25 -0400 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 KAA30142 for ; Wed, 28 Jul 1999 10:47:22 -0400 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 KAA03555 for ; Wed, 28 Jul 1999 10:53:21 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id QAA15625; Wed, 28 Jul 1999 16:47:15 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4n6734x5p1.fsf@rtp.ericsson.se> 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: 28 Jul 1999 16:47:21 +0200 In-Reply-To: Adrian Aichner's message of "28 Jul 1999 16:20:46 +0200" Message-ID: Lines: 47 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) 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> Right on: APA> With an unpatched vc.elc? fontification survives APA> vc-revert-buffer APA> when I have this in my .emacs: APA> (setq font-lock-support-mode 'fast-lock-mode) Oops, I tested this incorrectly. Fontification is lost for me in fast-lock-mode too! APA> Fontification is lost when I use any of these: APA> (setq font-lock-support-mode 'font-lock-mode) APA> (setq font-lock-support-mode 'lazy-lock-mode) APA> For font-lock-mode fontification is lost after `revert-buffer' calls APA> `insert-file-contents'. This is still true. Actually it happens when `insert-file-contents' calls `insert-file-contents-internal'. I don't understand yet why insert-file-contents get called twice for find-file and for vc-revert-buffer. vc-revert-buffer calls insert-file-contents with a t REPLACE argument. Adrian find-file: ====================================================================== 1 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=nil | 2 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=nil | 2 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13338) 1 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13338) vc-revert-buffer: ====================================================================== 1 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=t | 2 -> insert-file-contents: filename="e:\\tmp\\RFID\\4W1H926668975.pl" visit=t beg=nil end=nil replace=t | 2 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13328) 1 <- insert-file-contents: ("e:\\tmp\\RFID\\4W1H926668975.pl" 13328) APA> All of this in 21.1.4 WindowsNT4sp4 native. From owner-xemacs-beta@xemacs.org Wed Jul 28 10:55:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA30469 for xemacs-beta-out; Wed, 28 Jul 1999 10:55:20 -0400 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 KAA30465; Wed, 28 Jul 1999 10:55:17 -0400 Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6SEtG025734; Wed, 28 Jul 1999 10:55:16 -0400 Message-Id: <199907281455.d6SEtG025734@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: Image lib In-Reply-To: Your message of "28 Jul 1999 16:17:25 +0900." 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[ <3wn1wipqo6.fsf@kronborg.cs.umu.se> <87k8rmtsvl.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1201963014P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 1999 10:55:15 -0400 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --==_Exmh_-1201963014P Content-Type: text/plain; charset=us-ascii On 28 Jul 1999 16:17:25 +0900, SL Baur said: > Didier Verna writes in xemacs-beta@xemacs.org: > > but the latest version has a bug which makes all applications crash > > on TrueColor displays. It's been a while that this bug has been > > identified. > > Ugh. And double ugh. I was trying to port Enlightenment to AIX, and having a hell of a time with what *looked* like linker/shared lib issues. Upgrading to Imlib 1.9.5 solved it - am running just fine on a 24-bit TrueColor as I type this. BTW Didier: Your posting probably saved me another week of fumbling. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1201963014P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN58Z0tQBOOoptg9JAQFXGQQAqc4Vts0oPOVgB8nizrqxZKhjrRn0S4nV FEuywh95yL4JE0TKjgMnKxDBoyHfqT+aIhEvfipPykBWjklQnhCuYoCOzX+4UyxM yH/tDdb0w8H5WYghi5hjlH7MMPFR642FZOgnuXjNiJXFBxIEaELKAH+RQADZ0aXV 2xM78DMfYZc= =nywe -----END PGP MESSAGE----- --==_Exmh_-1201963014P-- From owner-xemacs-beta@xemacs.org Wed Jul 28 11:07:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA31086 for xemacs-beta-out; Wed, 28 Jul 1999 11:07:29 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA31082; Wed, 28 Jul 1999 11:07:24 -0400 Received: from metheny.enst.fr (8YjCJ0Peyr+02ib6ztwk6tPCecvU54uE@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id RAA00626; Wed, 28 Jul 1999 17:07:23 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id RAA10725; Wed, 28 Jul 1999 17:07:18 +0200 (MET DST) To: Valdis.Kletnieks@vt.edu Cc: SL Baur , xemacs-beta@xemacs.org Subject: Re: Image lib References: <3wn1wipqo6.fsf@kronborg.cs.umu.se> <87k8rmtsvl.fsf@pc-hrvoje.srce.hr> <199907281455.d6SEtG025734@black-ice.cc.vt.edu> 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: Valdis.Kletnieks@vt.edu's message of "Wed, 28 Jul 1999 10:55:15 -0400" 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: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > I was trying to port Enlightenment to AIX, and having a hell of a time > with what *looked* like linker/shared lib issues. 'better change the machine :-) > Upgrading to Imlib 1.9.5 > solved it - am running just fine on a 24-bit > TrueColor as I type this. I didn't know 1.9.5 was out. My "last version" was 1.9.4. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Wed Jul 28 11:25:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA32053 for xemacs-beta-out; Wed, 28 Jul 1999 11:25:21 -0400 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA32050 for ; Wed, 28 Jul 1999 11:25:20 -0400 Received: from postal.sr.hp.com (root@postal.sr.hp.com [15.4.46.173]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA05190 for ; Wed, 28 Jul 1999 11:24:39 -0400 (EDT) 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 IAA26149 for ; Wed, 28 Jul 1999 08:24:11 -0700 (PDT) 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 IAA21422 for ; Wed, 28 Jul 1999 08:25:04 -0700 (PDT) Message-Id: <199907281525.IAA21422@mina.sr.hp.com> To: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature Reply-To: Darryl Okahata In-reply-to: Your message of "28 Jul 1999 04:19:20 +0200." <87n1whjz2v.fsf@pc-hrvoje.srce.hr> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Jul 1999 08:25:03 -0700 From: Darryl Okahata Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic wrote: > Here is the patch for it to work with itimers. It could probably be > coded better (e.g. using the RESTART feature of itimers), but this > should do for starters. Thanks. I'll merge the patches and post a combined one to xemacs-patches next week (relative to 21.2.X, not 21.1.X). -- 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 Hewlett-Packard, or of the little green men that have been following him all day. From owner-xemacs-beta@xemacs.org Wed Jul 28 11:25:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA32044 for xemacs-beta-out; Wed, 28 Jul 1999 11:25:16 -0400 Received: from hdqmail (tlfa.com [207.211.203.2]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id LAA32032; Wed, 28 Jul 1999 11:25:11 -0400 Received: from HDQGATE-Message_Server by hdqmail with Novell_GroupWise; Wed, 28 Jul 1999 10:28:06 -0500 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 28 Jul 1999 10:27:51 -0500 From: "Rodney Stromlund" To: , Subject: Shell trouble - third post (was Shell trouble - second post, please read) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id LAA32035 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Surely someone somewhere has had this problem. I am on a HP-UX 10.20 PA2.0. I have tried switching my stty settings to just about everything possible and I always have the same problem. I have not gotten a single email on this. Please just email me and tell me to shut up! Please read on : ** Previous post ** When I enter shell mode (I'm using ksh) if I start a program that has lots of output, I can't break it or move my cursor around until the program ends. Its almost like xemacs is waiting for the shell to take a breath before it will interrupt it. ie. If I pull a Homer and do "tar x" instead of a "tar t", I can press ^C^C and the screen freezes and I won't see anything until the find command finishes. But, when the screen finally refreshes, the find command was allowed to run to completion. Depending on the tarball, this could be a very bad thing! Then the ^C^C goes thru and I see a two command lines. That's just a little too late! This is happens with the latest release xemacs (21.1) and all betas I've used. This never happened on 20.4. Or: If I do a "tar t" and I want to start scrolling thru the output before the command finishes; as soon as I press a key the output freezes until the find finishes. And (say I pressed page up) the page up takes place from the bottom of the output and not where I actually pressed the key. This problem isn't there in telnet or rsh. It is there in rlogin and shell. If this is a FAQ or documented somewhere, just let me know. Otherwise HELP!!!!!!!!!!!!!!!! Thx in advance, ================================ Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu@wnco.com (214) 792-6484 ================================ From owner-xemacs-beta@xemacs.org Wed Jul 28 13:20:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA07302 for xemacs-beta-out; Wed, 28 Jul 1999 13:20:49 -0400 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 NAA07284; Wed, 28 Jul 1999 13:20:41 -0400 Received: (from karlheg@localhost) by bittersweet.sysc.pdx.edu (8.9.3/8.9.3/Debian/GNU) id KAA05062; Wed, 28 Jul 1999 10:22:38 -0700 To: "Rodney Stromlund" Cc: , Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) 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: 2 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've seen this sort of thing also. C-c C-c, and it hangs for a long time, flashing the gc cursor now and again. From owner-xemacs-beta@xemacs.org Wed Jul 28 15:30:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA12919 for xemacs-beta-out; Wed, 28 Jul 1999 15:30:49 -0400 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 PAA12909 for ; Wed, 28 Jul 1999 15:30:47 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119ZMU-0000bW-00; Wed, 28 Jul 1999 21:27:34 +0200 To: Jake Colman Cc: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.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: 28 Jul 1999 21:27:33 +0200 In-Reply-To: Jake Colman's message of "28 Jul 1999 08:42:03 -0400" Message-ID: <87r9lsval6.fsf@pc-hrvoje.srce.hr> Lines: 20 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Here is the patch for it to work with itimers. It could > Hrvoje> probably be coded better (e.g. using the RESTART feature > Hrvoje> of itimers), but this should do for starters. > > Any chance that the new portions of FSF Emacs 20.4 be made available > in a 21.1.5 release? No. > Or is the 21.1 series frozen (except for bug fixes) and all new > stuff is in 21.2? 21.1 is deeply frozen, sorry. However, 21.2 happens to be quite stable, so xemacs-beta regulars should not hesitate to try it out. From owner-xemacs-beta@xemacs.org Wed Jul 28 16:12:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA14226 for xemacs-beta-out; Wed, 28 Jul 1999 16:12:45 -0400 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 QAA14223 for ; Wed, 28 Jul 1999 16:12:42 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119a47-0000de-00 for ; Wed, 28 Jul 1999 22:12:39 +0200 To: XEmacs Beta List Subject: Re: insert-file-contents is broken 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: 28 Jul 1999 22:12:36 +0200 In-Reply-To: SL Baur's message of "28 Jul 1999 16:11:51 +0900" Message-ID: <87hfmov8i3.fsf@pc-hrvoje.srce.hr> Lines: 40 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > `insert-file-contents' is a compiled Lisp function > -- loaded from "/usr/local/devel/miho-21.1-optimized/lisp/code-files.elc" > (insert-file-contents FILENAME &optional VISIT BEG END REPLACE) > ... > NOTE: When Mule support is enabled, the REPLACE argument is > currently ignored. > ... REPLACE is hosed because insert-file-contents, for reasons unknown, narrows the buffer between (point) and (point) just before calling insert-file-contents-internal. OTOH, the relevant code in Finsert_file_contents_internal() looks like this: if (!NILP (replace)) { buffer_delete_range (buf, BUF_BEG (buf), BUF_Z (buf), !NILP (visit) ? INSDEL_NO_LOCKING : 0); } Obviously, if the buffer is narrowed to zero characters' length, the above code is no-op. If you call the -internal function directly, you'll see that it works 100% right under Mule. The person who introduced the narrowing should explain its purpose. I cannot and I think it should be removed, pronto. Oh, and insert-file-contents also "documents" REPLACE not to work with Mule, but I don't see any reason why it shouldn't. The only thing that really doesn't work with Mule is the FSFMACS_SPEEDY_INSERT stuff, but that's only an internal optimization. -- Sam, is "pronto" a real word? Ceterum censeo Mule esse delendam! --me, after reading the code for insert-file-contents. From owner-xemacs-beta@xemacs.org Wed Jul 28 21:52:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA22040 for xemacs-beta-out; Wed, 28 Jul 1999 21:52:02 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA22034 for ; Wed, 28 Jul 1999 21:51:51 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id KAA18854; Thu, 29 Jul 1999 10:51:24 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) References: X-Attribution: sb From: SL Baur In-Reply-To: "Rodney Stromlund"'s message of "Wed, 28 Jul 1999 10:27:51 -0500" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 10:51:24 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Rodney Stromlund writes in xemacs-beta@xemacs.org: ... > When I enter shell mode (I'm using ksh) if I start a > program that has lots of output, I can't break it > or move my cursor around until the program ends. ... > Please just email me and tell me to shut up! Don't use shell mode. Use an xterm instead. Modern shells have *much* better editing capabilities than shell mode. From owner-xemacs-beta@xemacs.org Wed Jul 28 22:09:43 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA22444 for xemacs-beta-out; Wed, 28 Jul 1999 22:09:43 -0400 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 WAA22441 for ; Wed, 28 Jul 1999 22:09:40 -0400 Received: from as303.ecc.u-tokyo.ac.jp (as303.ecc.u-tokyo.ac.jp [133.11.171.228]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id LAA02450 for ; Thu, 29 Jul 1999 11:09:38 +0900 (JST) To: xemacs-beta@xemacs.org Subject: minibuffer-local-ns-map? From: Yoshiki Hayashi MIME-Version: 1.0 (generated by REMI 1.13.0 - "Saigata") Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 11:09:37 +0900 Message-ID: <1ziaesgnr4u.fsf@as303.ecc.u-tokyo.ac.jp> Lines: 10 User-Agent: ET-gnus/6.11.08 (based on Pterodactyl Gnus v0.95) REMI/1.13.0 (Saigata) FLIM/1.13.0 (Iwami) Emacs/20.2 (sparc-sun-solaris2.6) MULE/3.0 (MOMIJINOGA) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Lispref(Node: Text from Minibuffer) says XEmacs has minibuffer-local-ns-map but it's defined nowhere. Its definition is commented out at xemacs-21.2.18/lisp/minibuf.el L143 with comment `;; Historical crock.' So this must be a document bug. -- Yoshiki Hayashi From owner-xemacs-beta@xemacs.org Wed Jul 28 22:14:50 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA22527 for xemacs-beta-out; Wed, 28 Jul 1999 22:14:50 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA22514 for ; Wed, 28 Jul 1999 22:14:26 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id LAA18873; Thu, 29 Jul 1999 11:14:01 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4n6734x5p1.fsf@rtp.ericsson.se> X-Attribution: sb From: SL Baur In-Reply-To: Adrian Aichner's message of "28 Jul 1999 16:47:21 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 11:14:00 +0900 Message-ID: Lines: 71 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Adrian Aichner writes in xemacs-beta@xemacs.org: >>>>>> "APA" == Adrian Aichner writes: APA> Right on: APA> With an unpatched vc.elc? fontification survives APA> vc-revert-buffer APA> when I have this in my .emacs: APA> (setq font-lock-support-mode 'fast-lock-mode) > Oops, I tested this incorrectly. Fontification is lost for me in > fast-lock-mode too! Then there must be something else involved. APA> Fontification is lost when I use any of these: APA> (setq font-lock-support-mode 'font-lock-mode) APA> (setq font-lock-support-mode 'lazy-lock-mode) Oh. The infamous lazy-good-for-nothing-lock-mode. That's a pissing contest between Ben Wing and Simon Marshall. I very nearly gave up XEmacs until I learned how to turn it off. For what it's worth, font-lock-mode works for me. Enabling lazy-lock-mode and doing a revert-buffer gives me a bomb: Signaling: (args-out-of-range # 1 105913) lazy-lock-put-text-property(1 105913 fontified nil) lazy-lock-after-change-function(1 105913 52956) insert-file-contents-internal("/usr/users/steve/.emacs" t nil nil t undecided used-codesys) byte-code("..." [run-hook-with-args insert-file-contents-access-hook filename visit coding-system-for-read run-hook-with-args-until-success insert-file-contents-pre-hook find-file-coding-system-for-read-from-filename buffer-file-coding-system-for-read raw-text coding-system return-val find-coding-system message "Invalid coding-system (%s), using 'undecided" undecided insert-file-contents-internal beg end replace used-codesys find-coding-system-magic-cookie cs] 9) insert-file-contents("/usr/users/steve/.emacs" t nil nil t) #(t) call-interactively(revert-buffer) command-execute(revert-buffer t) execute-extended-command(nil) call-interactively(execute-extended-command) I tested both of those in an XEmacs/Mule by: xemacs -vanilla (font-lock-mode) C-x C-f ~/.emacs M-x revert-buffer and xemacs -vanilla (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) (font-lock-mode) C-x C-f ~/.emacs M-x revert-buffer I have no idea what `font-lock-support-mode' is. It is unbound in this instance of XEmacs. APA> For font-lock-mode fontification is lost after `revert-buffer' calls APA> `insert-file-contents'. > This is still true. Actually it happens when `insert-file-contents' > calls `insert-file-contents-internal'. > I don't understand yet why insert-file-contents get called twice for > find-file and for vc-revert-buffer. This is probably due to coding system detection. > vc-revert-buffer calls insert-file-contents with a t REPLACE argument. Right. From owner-xemacs-beta@xemacs.org Wed Jul 28 22:20:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA22778 for xemacs-beta-out; Wed, 28 Jul 1999 22:20:49 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA22754 for ; Wed, 28 Jul 1999 22:20:31 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id LAA18888; Thu, 29 Jul 1999 11:19:49 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4niu76f5he.fsf@rtp.ericsson.se> X-Attribution: sb From: SL Baur In-Reply-To: Raymond Toy's message of "27 Jul 1999 11:59:57 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 11:19:49 +0900 Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Raymond Toy writes in xemacs-beta@xemacs.org: > Large buffers don't seem to get font-lock'ed again, but this > is pure speculation. Check the *Message-Log* buffer for messages. If you are running up against the soft font-lock limit, there will be a message telling you about it. What is your value of font-lock-maximum size? Size does matter. I crank the size up in my .emacs, I don't know what the default is. It's small enough to be annoying (IMO). C-h v font-lock-maximum-size `font-lock-maximum-size' is a variable declared in Lisp. -- loaded from "font-lock" Value: 1024000 Documentation: *If non-nil, the maximum size for buffers for fontifying. Only buffers less than this can be fontified when Font Lock mode is turned on. If nil, means size is irrelevant. If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE), where MAJOR-MODE is a symbol or t (meaning the default). For example: ((c++-mode . 256000) (c-mode . 256000) (rmail-mode . 1048576)) means that the maximum size is 250K for buffers in `c++-mode' or `c-mode', one megabyte for buffers in `rmail-mode', and size is irrelevant otherwise. From owner-xemacs-beta@xemacs.org Wed Jul 28 22:25:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA22944 for xemacs-beta-out; Wed, 28 Jul 1999 22:25:02 -0400 Received: from nbecker.fred.net (nbecker.fred.net [208.238.64.4]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA22938 for ; Wed, 28 Jul 1999 22:24:59 -0400 Received: from neal by nbecker.fred.net with local (Exim 1.90 #3) for xemacs-beta@xemacs.org id 119fr9-0000Go-00; Wed, 28 Jul 1999 22:23:39 -0400 To: xemacs-beta@xemacs.org Subject: [patch] pty98 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 28 Jul 1999 22:23:38 -0400 Message-ID: <87wvvkkxcl.fsf@nbecker.fred.net> Lines: 67 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I think this is a clean patch. It should work on any glibc2.1 system AFAIK. I can only test it on glibc2.1 w/pty98 support. It seems OK: The conditional code is moved to process.h. I suppose that's where it should go(?) 1. M-x shell 2. tty > /dev/pts/1 (good) 3. C-x k 4. M-x shell 5. tty > /dev/pts/1 (good) 6. M-x rename buffer *shell2* 7. M-x shell 8. tty > /dev/pts/2 (good) Index: process.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process.h,v retrieving revision 1.8 diff -u -r1.8 process.h --- process.h 1998/04/11 05:37:05 1.8 +++ process.h 1999/07/29 02:19:51 @@ -134,4 +134,16 @@ #endif /* emacs */ +#if defined (__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC_MINOR__ >= 1) +# define HAVE_GETPT +#endif + +#ifdef HAVE_GETPT +#define PTY_ITERATION +#define PTY_OPEN \ + if ((fd = getpt()) < 0 || grantpt (fd) < 0 || unlockpt (fd) < 0) \ + return -1; +#define PTY_TTY_NAME_SPRINTF ptsname_r (fd, pty_name, sizeof (pty_name)); +#endif + #endif /* _XEMACS_PROCESS_H_ */ Index: process-unix.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-unix.c,v retrieving revision 1.11.2.5 diff -u -r1.11.2.5 process-unix.c --- process-unix.c 1998/12/29 10:54:27 1.11.2.5 +++ process-unix.c 1999/07/29 02:20:04 @@ -216,6 +216,7 @@ int fd; int c; + #ifdef PTY_ITERATION PTY_ITERATION #else @@ -265,7 +266,7 @@ if (access (pty_name, 6) != 0) { close (fd); -#if !defined(IRIS) && !defined(__sgi) +#if !defined(IRIS) && !defined(__sgi) && !defined (HAVE_GETPT) continue; #else return -1; From owner-xemacs-beta@xemacs.org Wed Jul 28 22:32:15 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA23225 for xemacs-beta-out; Wed, 28 Jul 1999 22:32:15 -0400 Received: from cherokee.intergate.bc.ca (cherokee.intergate.bc.ca [205.206.192.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA23215 for ; Wed, 28 Jul 1999 22:32:10 -0400 Received: from localhost (pm37s37.intergate.bc.ca [207.194.173.154]) by cherokee.intergate.bc.ca (8.9.3/8.9.3) with ESMTP id TAA16930 for ; Wed, 28 Jul 1999 19:31:53 -0700 (PDT) From: Gerald Gutierrez MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14239.49303.849093.581066@gargle.gargle.HOWL> Date: Wed, 28 Jul 1999 19:46:47 -0700 (PDT) To: xemacs-beta@xemacs.org Subject: Merging with GNU Emacs X-Mailer: VM 6.72 under Emacs 20.3.1 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi all. I've used GNU Emacs practically forever and have only recently tried Lucid Emacs. I was fairly surprised by the many differences. Having read the FAQ file regarding the merging of the two projects, I'd like to know something more about it. I realize that this is a touchy subject but I would only like to know a few facts. 1) Is there discussion in place about a possible merge? 2) Is there a possibility of an "XEmacs takeover" like with egcs/gcc? 3) Is there a reason why XEmacs authors haven't signed over the copyright to the FSF if their code is intended to be under the GPL? 4) Is GNU Emacs development still taking place, or is it again more or less like the egcs/gcc deal where GNU Emacs is just slowing down more and more? Thanks. From owner-xemacs-beta@xemacs.org Wed Jul 28 22:54:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA24090 for xemacs-beta-out; Wed, 28 Jul 1999 22:54:49 -0400 Received: from tweed.ppllc.com (mail1.ppllc.com [209.208.206.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA24087 for ; Wed, 28 Jul 1999 22:54:48 -0400 Received: (from colman@localhost) by tweed.ppllc.com (8.9.0/8.9.0) id XAA08171; Wed, 28 Jul 1999 23:06:06 -0400 (EDT) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> X-Attribution: Jake X-URL: http://www.ppllc.com From: Jake Colman Date: 28 Jul 1999 23:06:04 -0400 In-Reply-To: Hrvoje Niksic's message of "28 Jul 1999 21:27:33 +0200" Message-ID: <76lnc0tasj.fsf@ppllc.com> Lines: 19 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) 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> 21.1 is deeply frozen, sorry. Hrvoje> However, 21.2 happens to be quite stable, so xemacs-beta regulars Hrvoje> should not hesitate to try it out. Is there a tentative release schedule for 21.2? I'm itching to try it out but only if it is close to suitable for production use. -- 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 From owner-xemacs-beta@xemacs.org Wed Jul 28 23:31:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA25258 for xemacs-beta-out; Wed, 28 Jul 1999 23:31:25 -0400 Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA25254; Wed, 28 Jul 1999 23:31:24 -0400 Received: from erols.com (209-122-226-181.s435.tnt1.nyw.ny.dialup.rcn.com [209.122.226.181]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id XAA07069; Wed, 28 Jul 1999 23:32:20 -0400 (EDT) Message-ID: <379FCB7A.4185F8B3@erols.com> Date: Wed, 28 Jul 1999 23:33:14 -0400 From: "Matthew O. Persico" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SL Baur CC: xemacs-beta@xemacs.org Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote: > > Don't use shell mode. Use an xterm instead. Modern shells have *much* > better editing capabilities than shell mode. But not all programs do. I live in shell mode. I open xterms and use them in the normal course of work but anytime I want to use a program that does NOT have editing (like isql for Sybase/sqlplus for Oracle) I find it much easier to use shell mode. Oh yes, isql has a vi command and sqlplus has an ed command but that's not the same as beign able to recall on the command line, cut and paste, etc. From owner-xemacs-beta@xemacs.org Wed Jul 28 23:52:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA25824 for xemacs-beta-out; Wed, 28 Jul 1999 23:52:19 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA25818 for ; Wed, 28 Jul 1999 23:52:03 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id MAA18976; Thu, 29 Jul 1999 12:47:53 +0900 (JST) Mail-Copies-To: never To: Jake Colman Cc: Hrvoje Niksic , XEmacs Beta List Subject: XEmacs 21.2 release checklist (was Re: GNU Emacs new isearch feature) References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> <76lnc0tasj.fsf@ppllc.com> X-Attribution: sb From: SL Baur In-Reply-To: Jake Colman's message of "28 Jul 1999 23:06:04 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 12:47:53 +0900 Message-ID: Lines: 43 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jake Colman writes in xemacs-beta@xemacs.org: >>>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> 21.1 is deeply frozen, sorry. Hrvoje> However, 21.2 happens to be quite stable, so xemacs-beta regulars Hrvoje> should not hesitate to try it out. It is not particularly stable at the moment. New bugs are being introduced as fast as we remove old ones. If you build without Mule and without the new graphics stuffs, maybe. 21.2 is quite usable if you are diligent in keeping it patched up. At the moment, the source tree in CVS is too broken to make 21.2.19. > Is there a tentative release schedule for 21.2? No. We will release 21.2 when it's ready and not before. There are a specific set of features that should be in 21.2 before we release it. In no particular order[1]: 8. Andy Piper's new graphics stuffs 2. Elimination of dumping 12. Synch with FSF 20.4, particularly with regards to Mule stuffs 5. Jan Vroonhof's customization themes and ~/.xemacs 3. UCS4/UTF8 internal encoding changes 7. Michael Sperber's Lisp package overhaul 1. Fix new build problems ie. with X, without menubars, etc. Some of these are close, I think. I might have left something out. > I'm itching to try it out but only if it is close to suitable for > production use. It's not close in the sense you're probably thinking of. InfoDock isn't quite stable[2] with it, for example. Footnotes: [1] With apologies to Kyle for stealing her idea. [2] It's usable enough that I do all my editing at home with InfoDock/XEmacs 21.2, but not very close to release quality. From owner-xemacs-beta@xemacs.org Thu Jul 29 00:03:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA26098 for xemacs-beta-out; Thu, 29 Jul 1999 00:03:29 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA26095 for ; Thu, 29 Jul 1999 00:03:26 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id NAA18996; Thu, 29 Jul 1999 13:02:25 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Merging with GNU Emacs References: <14239.49303.849093.581066@gargle.gargle.HOWL> X-Attribution: sb From: SL Baur In-Reply-To: Gerald Gutierrez's message of "Wed, 28 Jul 1999 19:46:47 -0700 (PDT)" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 13:02:25 +0900 Message-ID: Lines: 46 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Gerald Gutierrez writes in xemacs-beta@xemacs.org: > Hi all. > I've used GNU Emacs practically forever and have only recently tried > Lucid Emacs. I was fairly surprised by the many differences. "Lucid Emacs" died over five year ago. For better or for worse, it is XEmacs now. > Having read the FAQ file regarding the merging of the two projects, > I'd like to know something more about it. I realize that this is a > touchy subject but I would only like to know a few facts. > 1) Is there discussion in place about a possible merge? No. > 2) Is there a possibility of an "XEmacs takeover" like with egcs/gcc? No. > 3) Is there a reason why XEmacs authors haven't signed over the > copyright to the FSF if their code is intended to be under the GPL? The major sticking point that caused separation was the fact that Richard was not satisfied with the way Sun handled the GPL-ization of the code they sponsored in Lucid Emacs and XEmacs. This cannot have been the real reason because the Mule code he has been adding to Emacs 20 isn't FSF copyright assigned and will never be FSF copyright assigned. Since it is entirely owned by a non-US government I sincerely doubt he has any legal recourse whatsoever in a US court should the situation change (unlike with a US corporation like Sun Microsystems) and according to what I've been told here, he doesn't have legal recourse in a Japanese court either. Since when it suits his purposes, he uses non-FSF copyright assigned code, I fail to see why I should care, so long as I am using GPL'ed code. > 4) Is GNU Emacs development still taking place, or is it again more or > less like the egcs/gcc deal where GNU Emacs is just slowing down > more and more? Yes, no. At the moment they are busy reimplementing the XEmacs redisplay engine (incompatibly of course). From owner-xemacs-beta@xemacs.org Thu Jul 29 00:14:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA26433 for xemacs-beta-out; Thu, 29 Jul 1999 00:14:34 -0400 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 AAA26429 for ; Thu, 29 Jul 1999 00:14:29 -0400 Received: from as303.ecc.u-tokyo.ac.jp (as303.ecc.u-tokyo.ac.jp [133.11.171.228]) by komaba.ecc.u-tokyo.ac.jp (8.9.3/3.7Wpl2/99020517) with ESMTP id NAA04963 for ; Thu, 29 Jul 1999 13:14:16 +0900 (JST) To: xemacs-beta@xemacs.org Subject: Re: GNU Emacs' rect.el References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> <87wvvngxqs.fsf@pc-hrvoje.srce.hr> From: Yoshiki Hayashi MIME-Version: 1.0 (generated by REMI 1.13.0 - "Saigata") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jul_29_13:14:15_1999-1" Date: 29 Jul 1999 13:14:15 +0900 In-Reply-To: <87wvvngxqs.fsf@pc-hrvoje.srce.hr> (Hrvoje Niksic's message of "26 Jul 1999 18:51:55 +0200") Message-ID: <1zihfmom6so.fsf@as303.ecc.u-tokyo.ac.jp> Lines: 50 User-Agent: ET-gnus/6.11.08 (based on Pterodactyl Gnus v0.95) REMI/1.13.0 (Saigata) FLIM/1.13.0 (Iwami) Emacs/20.2 (sparc-sun-solaris2.6) MULE/3.0 (MOMIJINOGA) Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: --Multipart_Thu_Jul_29_13:14:15_1999-1 Content-Type: text/plain; charset=US-ASCII Oops. Sorry Hrvoje. I sent reply to you directly by mistake. Hrvoje Niksic writes: > SL Baur writes: > > > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > > > > > I've never really grokked the concept of "multicolumn characters". We > > > already support proportional fonts. Shouldn't Japanese be treated the > > > same as anything else? > > > > It's not the same thing. Under normal settings, Japanese characters > > display twice as wide as Latin characters. > > The question is: which Latin characters? What are "normal settings" > to you? Does this mean that when I change my font (as I do, because > the default one is awful), the twice-as-wide relationship gets lost? Probably Latin-1. I guess Latin-2 is the same. It has nothing to do with font setting. Japanese characters display twice as wide and it also takes two columns. I mean, if the line is only US-ASCII and what-cursor-position returns column 40, the line has 40 characters. If there are Japanese characters and what-cursor-position returns column 40, there may be only 20 characters. For example, next part contain 11 Japanese characters. At the end of the line, what-cursor-position will say column 22. --Multipart_Thu_Jul_29_13:14:15_1999-1 Content-Type: text/plain; charset=ISO-2022-JP $B$3$N9T$O==0lJ8;z$G$9!#(B --Multipart_Thu_Jul_29_13:14:15_1999-1 Content-Type: text/plain; charset=US-ASCII (It says, this line has 11 characters.) I think this is why you need move-to-column-force. -- Yoshiki Hayashi --Multipart_Thu_Jul_29_13:14:15_1999-1-- From owner-xemacs-beta@xemacs.org Thu Jul 29 00:33:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id AAA27197 for xemacs-beta-out; Thu, 29 Jul 1999 00:33:52 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id AAA27193 for ; Thu, 29 Jul 1999 00:33:44 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id MAA18993; Thu, 29 Jul 1999 12:52:09 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) References: <379FCB7A.4185F8B3@erols.com> X-Attribution: sb From: SL Baur In-Reply-To: "Matthew O. Persico"'s message of "Wed, 28 Jul 1999 23:33:14 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 12:52:09 +0900 Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Matthew O Persico writes in xemacs-beta@xemacs.org: > SL Baur wrote: >> >> Don't use shell mode. Use an xterm instead. Modern shells have *much* >> better editing capabilities than shell mode. > But not all programs do. I live in shell mode. I open xterms and > use them in the normal course of work but anytime I want to use a > program that does NOT have editing (like isql for Sybase/sqlplus > for Oracle) I find it much easier to use shell mode. Isn't this situation what an inferior SQL mode is supposed to deal with? Don't we have an inferior SQL mode? From owner-xemacs-beta@xemacs.org Thu Jul 29 02:46:25 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA29541 for xemacs-beta-out; Thu, 29 Jul 1999 02:46:25 -0400 Received: from osa.osa.com.au (osa.osa.com.au [203.6.130.129]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA29536 for ; Thu, 29 Jul 1999 02:46:19 -0400 Received: (from uucp@localhost) by osa.osa.com.au (8.8.5/8.6.9) id QAA02216 for ; Thu, 29 Jul 1999 16:46:14 +1000 Received: from UNKNOWN(15.16.33.1), claiming to be "redgum.osa.com.au" via SMTP by osa.osa.com.au, id smtpda02145; Thu Jul 29 06:46:11 1999 Received: from morrigan.danann.net (morrigan.osa.com.au [15.16.33.101]) by redgum.osa.com.au (8.6.9/8.6.9) with ESMTP id QAA19017 for ; Thu, 29 Jul 1999 16:43:29 +1000 Received: by morrigan.danann.net (Postfix, from userid 1000) id 096DA57042; Thu, 29 Jul 1999 16:42:17 +1000 (EST) To: xemacs-beta@xemacs.org Subject: BUG REPORT: BBDB package is outdated :( From: Daniel Pittman Organization: Here, there and everywhere... Mail-Copies-To: Never X-spies: Kibo Nazi Ron Brown Semtex spy Watergate KGB cryptographic nuclear World Trade Center Albania Roswell radar genetic South Africa Date: 29 Jul 1999 16:42:17 +1000 Message-ID: <87zp0g7y9i.fsf@morrigan.osa.com.au> Lines: 14 User-Agent: Gnus/5.070093 (Pterodactyl Gnus v0.93) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The version of the BBDB currently available as a package is maintainer version 2.00.02. This version has a bug wherein it uses the extent-data function. This function is undefined in XEmacs 21.2 The current maintainer release is 2.00.06 (or possibly higher). This release has corrected this problem. Would it be possible to see the updated release installed as a package? Daniel -- Beware of Programmers who carry screwdrivers. From owner-xemacs-beta@xemacs.org Thu Jul 29 02:57:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA29813 for xemacs-beta-out; Thu, 29 Jul 1999 02:57:12 -0400 Received: from MAIL.Rhein-Ruhr.De (Alpha.DU.Rhein-Ruhr.De [194.94.231.17]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA29808 for ; Thu, 29 Jul 1999 02:57:08 -0400 Received: from dialin012.du.rhein-ruhr.de ([194.94.231.44] helo=laputa.fabian.home) by MAIL.Rhein-Ruhr.De with esmtp (Exim 2.12 #4) id 119k7C-00057Q-00 for xemacs-beta@xemacs.org; Thu, 29 Jul 1999 08:56:30 +0200 Received: (from mike@localhost) by laputa.fabian.home (8.9.3/8.9.3) id IAA29203; Thu, 29 Jul 1999 08:50:48 +0200 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14239.63944.693534.37416@laputa.fabian.home> Date: Thu, 29 Jul 1999 08:50:48 +0200 (CEST) To: xemacs-beta@xemacs.org Subject: term-mode (was Re: Shell trouble - third post (was Shell trouble - second post, please read)) In-Reply-To: References: X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: mike.fabian@mail.rhein-ruhr.de Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Rodney Stromlund writes in sb> xemacs-beta@xemacs.org: ... >> When I enter shell mode (I'm using ksh) if I start a program that >> has lots of output, I can't break it or move my cursor around until >> the program ends. sb> ... >> Please just email me and tell me to shut up! sb> Don't use shell mode. Use an xterm instead. Modern shells have sb> *much* better editing capabilities than shell mode. By the way, what happened to term-mode? For me the formatting in term-mode it seems to broken. `M-x term' opens a terminal window, but it behaves weird. For example if I type `ls' at the prompt, just after typing the `l' it looks like: mike@laputa ~/ttt$ l Then after typing the `s' I get: mike@laputa ~/ttt$ l ls And then after typing `return': mike@laputa ~/ttt$ l ls a b c mike@laputa ~/ttt$ Are other people seeing this behaviour too? Mike From owner-xemacs-beta@xemacs.org Thu Jul 29 02:58:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA29833 for xemacs-beta-out; Thu, 29 Jul 1999 02:58:31 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id CAA29828 for ; Thu, 29 Jul 1999 02:58:27 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id PAA19646; Thu, 29 Jul 1999 15:58:06 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: BUG REPORT: BBDB package is outdated :( References: <87zp0g7y9i.fsf@morrigan.osa.com.au> X-Attribution: sb From: SL Baur In-Reply-To: Daniel Pittman's message of "29 Jul 1999 16:42:17 +1000" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 15:58:06 +0900 Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I know. I have updated the version in CVS (not yet distributed due to other problems) to 2.00.06. I'm working on getting new Sumos etc. built as fast as I can. Daniel Pittman writes in xemacs-beta@xemacs.org: > The version of the BBDB currently available as a package is maintainer > version 2.00.02. This version has a bug wherein it uses the extent-data > function. This function is undefined in XEmacs 21.2 > The current maintainer release is 2.00.06 (or possibly higher). This > release has corrected this problem. > Would it be possible to see the updated release installed as a package? From owner-xemacs-beta@xemacs.org Thu Jul 29 03:24:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA30703 for xemacs-beta-out; Thu, 29 Jul 1999 03:24:31 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA30700 for ; Thu, 29 Jul 1999 03:24:29 -0400 Received: from metheny.enst.fr (OBmzmMobOUUzB3EonJfhr/pYtbPW+jMA@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id JAA27519 for ; Thu, 29 Jul 1999 09:24:28 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id JAA13162; Thu, 29 Jul 1999 09:24:25 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: BUG REPORT: BBDB package is outdated :( References: <87zp0g7y9i.fsf@morrigan.osa.com.au> 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: Daniel Pittman's message of "29 Jul 1999 16:42:17 +1000" 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: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Daniel Pittman writes: > The current maintainer release is 2.00.06 (or possibly higher). This > release has corrected this problem. > > Would it be possible to see the updated release installed as a package? Bomb Colin's mailbox. I've given up on this issue long ago ;-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Thu Jul 29 03:36:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA31035 for xemacs-beta-out; Thu, 29 Jul 1999 03:36:14 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA30994 for ; Thu, 29 Jul 1999 03:35:33 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id QAA19770; Thu, 29 Jul 1999 16:35:03 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: BUG REPORT: BBDB package is outdated :( References: <87zp0g7y9i.fsf@morrigan.osa.com.au> X-Attribution: sb From: SL Baur In-Reply-To: Didier Verna's message of "29 Jul 1999 09:24:25 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jul 1999 16:35:03 +0900 Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Didier Verna writes in xemacs-beta@xemacs.org: > Daniel Pittman writes: >> The current maintainer release is 2.00.06 (or possibly higher). This >> release has corrected this problem. >> >> Would it be possible to see the updated release installed as a package? > Bomb Colin's mailbox. I've given up on this issue long ago ;-) No! The blame is solely mine. From owner-xemacs-beta@xemacs.org Thu Jul 29 04:18:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA32027 for xemacs-beta-out; Thu, 29 Jul 1999 04:18:46 -0400 Received: from skylla.rus.uni-stuttgart.DE (skylla.rus.uni-stuttgart.de [129.69.1.8]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA32021 for ; Thu, 29 Jul 1999 04:18:38 -0400 Received: from itsma2.itsm.uni-stuttgart.de (itsma2.itsm.uni-stuttgart.de [129.69.62.42]) by skylla.rus.uni-stuttgart.DE (8.8.8/8.8.8) with ESMTP id KAA02640 for ; Thu, 29 Jul 1999 10:18:33 +0200 (MET DST) env-from (bauer@itsm.uni-stuttgart.de) Received: from itsma7.itsm.uni-stuttgart.de (itsma7.itsm.uni-stuttgart.de [129.69.62.47]) by itsma2.itsm.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id KAA02538; Thu, 29 Jul 1999 10:18:30 +0200 (MET DST) Received: from itsm.uni-stuttgart.de (localhost [127.0.0.1]) by itsma7.itsm.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id KAA31122; Thu, 29 Jul 1999 10:18:29 +0200 (MET DST) Message-ID: <37A00E55.5C85103D@itsm.uni-stuttgart.de> Date: Thu, 29 Jul 1999 10:18:29 +0200 From: Holger Bauer Reply-To: bauer@itsm.uni-stuttgart.de X-Mailer: Mozilla 4.6 [en] (X11; I; OSF1 V4.0 alpha) X-Accept-Language: German, de, en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: 21.1.4 on DU4.0e, wrong exec-directory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Bug report: Tried to install Xemacs Version 21.1.4 on our DEC Alpha DU4.0e system. However, all architecture dependent files get installed in the right place but xemacs does not find them because exec-directory points to the ...../lib-src directory and not to the architecture dependent directory. Could not find the bug since all the configuration variables in the corresponding Makefiles are set correctly. (Yes, I could have set the exec-directory myself, but this is just to dirty ...) I am not going back to xemacs-19.16 (which I throwed away since all the available binary packages dump core on VERY large files, always have to compile myself). Holger -- ------------------------------------------------ | Holger Bauer | Univ. of Stuttgart, ITSM | | Dipl.-Ing. | 70550 Stuttgart, Germany | | phone +49.711.685-3543, FAX +49.711.685-3280 | | http://www.itsm.uni-stuttgart.de/staff/bauer/ | ------------------------------------------------ "Experience comes from bad judgment" Mark Twain From owner-xemacs-beta@xemacs.org Thu Jul 29 05:24:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA01176 for xemacs-beta-out; Thu, 29 Jul 1999 05:24:55 -0400 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 FAA01173 for ; Thu, 29 Jul 1999 05:24:54 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA25754; Thu, 29 Jul 1999 02:24:38 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-201.beasys.com [192.168.11.201]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA10574; Thu, 29 Jul 1999 02:24:35 -0700 (PDT) Message-Id: <3.0.5.32.19990729102506.00a918c0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Jul 1999 10:25:06 +0100 To: Neal Becker , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: [patch] pty98 In-Reply-To: <87wvvkkxcl.fsf@nbecker.fred.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I've no idea what this patch does, but this sort of thing should go in the s&m files surely? andy At 10:23 PM 7/28/99 -0400, Neal Becker wrote: >+#if defined (__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC_MINOR__ >= 1) >+# define HAVE_GETPT >+#endif >+ >+#ifdef HAVE_GETPT >+#define PTY_ITERATION >+#define PTY_OPEN \ >+ if ((fd = getpt()) < 0 || grantpt (fd) < 0 || unlockpt (fd) < 0) \ >+ return -1; >+#define PTY_TTY_NAME_SPRINTF ptsname_r (fd, pty_name, sizeof (pty_name)); >+#endif >+ > #endif /* _XEMACS_PROCESS_H_ */ -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 29 05:25:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA01185 for xemacs-beta-out; Thu, 29 Jul 1999 05:25:06 -0400 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 FAA01179; Thu, 29 Jul 1999 05:25:01 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA25768; Thu, 29 Jul 1999 02:24:44 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-201.beasys.com [192.168.11.201]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA10591; Thu, 29 Jul 1999 02:24:42 -0700 (PDT) Message-Id: <3.0.5.32.19990729102513.00a8a500@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Jul 1999 10:25:13 +0100 To: SL Baur , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Merging with GNU Emacs In-Reply-To: References: <14239.49303.849093.581066@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 01:02 PM 7/29/99 +0900, SL Baur wrote: >Yes, no. At the moment they are busy reimplementing the XEmacs >redisplay engine (incompatibly of course). Which reminds me. Are they implementing anything we don't have in this area? I think I know enough about redisplay now to add any new features we are missing. I'm considering doing word wrap round images at some point. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 29 05:24:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA01170 for xemacs-beta-out; Thu, 29 Jul 1999 05:24:53 -0400 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 FAA01164; Thu, 29 Jul 1999 05:24:48 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id CAA25745; Thu, 29 Jul 1999 02:24:31 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-201.beasys.com [192.168.11.201]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id CAA10570; Thu, 29 Jul 1999 02:24:28 -0700 (PDT) Message-Id: <3.0.5.32.19990729102459.00a8d100@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Jul 1999 10:24:59 +0100 To: SL Baur , Jake Colman From: Andy Piper Subject: Re: XEmacs 21.2 release checklist (was Re: GNU Emacs new isearch feature) Cc: XEmacs Beta List In-Reply-To: References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> <76lnc0tasj.fsf@ppllc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: At 12:47 PM 7/29/99 +0900, SL Baur wrote: >Some of these are close, I think. I might have left something out. It would be nice if the module stuff was fixed to support MS-WIndows but I don't know who is going to do that. Certainly not me. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Thu Jul 29 08:11:39 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id IAA04839 for xemacs-beta-out; Thu, 29 Jul 1999 08:11:39 -0400 Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id IAA04827; Thu, 29 Jul 1999 08:11:26 -0400 Received: from sparrow.bear.com (user-2ive447.dialup.mindspring.com [165.247.16.135]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id IAA24432; Thu, 29 Jul 1999 08:11:23 -0400 (EDT) Received: from localhost (vallon@localhost) by sparrow.bear.com (8.9.3/8.9.3) with SMTP id HAA00450; Thu, 29 Jul 1999 07:50:34 -0400 Date: Thu, 29 Jul 1999 11:50:33 +0000 ( ) From: Justin Vallon To: Rodney Stromlund cc: xemacs@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: On Wed, 28 Jul 1999, Rodney Stromlund wrote: > Surely someone somewhere has had this problem. I am > on a HP-UX 10.20 PA2.0. I have tried switching my > stty settings to just about everything possible and > I always have the same problem. I have not gotten a > single email on this. Please just email me and tell > me to shut up! Please read on : > > ** Previous post ** > > When I enter shell mode (I'm using ksh) if I start a > program that has lots of output, I can't break it > or move my cursor around until the program ends. Its > almost like xemacs is waiting for the shell to take a > breath before it will interrupt it. That happens to me too, and it is really annoying. My guess is that input is arriving too fast for xemacs to process the input, making xemacs the bottleneck. Then, maybe X events are not handled while there is non-X pipe input to process. Maybe include display updates in there somewhere. Maybe non-X input is being considered a higher priority than X input and/or X display refresh has very low priority. I think both may be true. > This problem isn't there in telnet or rsh. It is there in > rlogin and shell. Maybe the process-input path is shorter in those modes? Does telnet do fontification? Maybe it can be turned off in shell modes to at least help with the input flood? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Thu Jul 29 09:16:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA06685 for xemacs-beta-out; Thu, 29 Jul 1999 09:16:31 -0400 Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA06681 for ; Thu, 29 Jul 1999 09:16:30 -0400 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id IAA27452 for ; Thu, 29 Jul 1999 08:16:29 -0500 (CDT) 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 IAA10791 for ; Thu, 29 Jul 1999 08:16:01 -0500 (CDT) Received: from wcsdsp3 (wcsdsp3.rtp.ericsson.se [147.117.125.240]) by netmanager7.rtp.ericsson.se (8.9.1/8.6.4) with ESMTP id JAA02924 for ; Thu, 29 Jul 1999 09:16:26 -0400 (EDT) Received: (toy@localhost) by wcsdsp3 (8.6.8/8.6.8) id JAA04616; Thu, 29 Jul 1999 09:16:42 -0400 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> <4niu76f5he.fsf@rtp.ericsson.se> From: Raymond Toy Date: 29 Jul 1999 09:16:42 -0400 In-Reply-To: SL Baur's message of "29 Jul 1999 11:19:49 +0900" Message-ID: <4nlnbzvbnp.fsf@rtp.ericsson.se> Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> Check the *Message-Log* buffer for messages. If you are running up sb> against the soft font-lock limit, there will be a message telling you sb> about it. What is your value of font-lock-maximum size? Size does sb> matter. I crank the size up in my .emacs, I don't know what the sb> default is. It's small enough to be annoying (IMO). It's set to 256000, the default, I think. However, I've been doing my tests on my 21K .bash_profile, which exhibits the problem. Some tests show that by the time normal-mode is called font-lock isn't turned on. For a different test file, which works as expected, by the time normal-mode is run, the buffer has already been font-locked. I need to trace through this a bit better. Ray From owner-xemacs-beta@xemacs.org Thu Jul 29 09:50:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA08046 for xemacs-beta-out; Thu, 29 Jul 1999 09:50:10 -0400 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 JAA08030 for ; Thu, 29 Jul 1999 09:50:04 -0400 Received: from liszt.laas.fr (liszt [140.93.21.56]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id PAA04134 for ; Thu, 29 Jul 1999 15:49:59 +0200 (MET DST) Received: (from emarsden@localhost) by liszt.laas.fr (8.9.3/8.9.3) id PAA07400; Thu, 29 Jul 1999 15:50:13 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Submitting new packages: pg.el & babel.el 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: 29 Jul 1999 15:50:13 +0200 Message-ID: Lines: 34 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi, This is to suggest inclusion of two elisp modules I have written in XEmacs (presumably as packages). * pg.el is a socket-level interface to the PostgreSQL RDBMS. It is a programmer's API, which allows you to send SQL queries to the backend, and receive the results with appropriate type coercions. It probably needs more testing before bundling. pg.el will eventually be included in Emacs. * babel.el is an interface to different translation engines available on Internet, such as Babelfish and SysTran. It uses w3 to submit requests to their web frontends, and formats the result. It can break large texts into several chunks and submit them sequentially. There are hooks for babel.el in recent versions of Pterodactyl Gnus, so it would be good for it to be easily available. I don't know what the correct procedure for requesting inclusion is ( says "please let us know"; I hope this is the right place). I am not able to stay current with development versions of XEmacs, so I can't do the packaging myself. -- Eric Marsden It's elephants all the way down From owner-xemacs-beta@xemacs.org Thu Jul 29 10:50:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA10712 for xemacs-beta-out; Thu, 29 Jul 1999 10:50:16 -0400 Received: from hdqmail (tlfa.com [207.211.203.2]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA10685; Thu, 29 Jul 1999 10:49:58 -0400 Received: from HDQGATE-Message_Server by hdqmail with Novell_GroupWise; Thu, 29 Jul 1999 09:52:56 -0500 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 29 Jul 1999 09:52:18 -0500 From: "Rodney Stromlund" To: Cc: , Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA10686 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yes, it is annoying and I agree that it seems that the shells output takes priority over your input. I made sure that font-lock was not on in case it was a regexp problem (actually I don't use font-lock in shell-mode ever). I looked at the 20.4 shell.el and the new package style shell.el and there isn't that much difference. If, from a shell buffer, I rlogin into another box I can break a program right away. If I exit the rlogin, the bad behaviour returns. I am guessing that since shell is on the same box the pipes are treated different than a pipe to a different machine. This could be a change to the process C code in XEmacs or it can be a un?x issue. ================================ Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu@wnco.com (214) 792-6484 ================================ >>> Justin Vallon 07/29/99 06:50AM >>> On Wed, 28 Jul 1999, Rodney Stromlund wrote: > Surely someone somewhere has had this problem. I am > on a HP-UX 10.20 PA2.0. I have tried switching my > stty settings to just about everything possible and > I always have the same problem. I have not gotten a > single email on this. Please just email me and tell > me to shut up! Please read on : > > ** Previous post ** > > When I enter shell mode (I'm using ksh) if I start a > program that has lots of output, I can't break it > or move my cursor around until the program ends. Its > almost like xemacs is waiting for the shell to take a > breath before it will interrupt it. That happens to me too, and it is really annoying. My guess is that input is arriving too fast for xemacs to process the input, making xemacs the bottleneck. Then, maybe X events are not handled while there is non-X pipe input to process. Maybe include display updates in there somewhere. Maybe non-X input is being considered a higher priority than X input and/or X display refresh has very low priority. I think both may be true. > This problem isn't there in telnet or rsh. It is there in > rlogin and shell. Maybe the process-input path is shorter in those modes? Does telnet do fontification? Maybe it can be turned off in shell modes to at least help with the input flood? -Justin vallon@mindspring.com From owner-xemacs-beta@xemacs.org Thu Jul 29 11:02:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA11381 for xemacs-beta-out; Thu, 29 Jul 1999 11:02:49 -0400 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 LAA11376 for ; Thu, 29 Jul 1999 11:02:47 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119rhl-0000Uf-00 for ; Thu, 29 Jul 1999 17:02:45 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs' rect.el References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> <87wvvngxqs.fsf@pc-hrvoje.srce.hr> <1zihfmom6so.fsf@as303.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: 29 Jul 1999 17:02:45 +0200 In-Reply-To: Yoshiki Hayashi's message of "29 Jul 1999 13:14:15 +0900" Message-ID: <87d7xbjy7e.fsf@pc-hrvoje.srce.hr> Lines: 43 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Yoshiki Hayashi writes: > > The question is: which Latin characters? What are "normal > > settings" to you? Does this mean that when I change my font (as I > > do, because the default one is awful), the twice-as-wide > > relationship gets lost? > > Probably Latin-1. I guess Latin-2 is the same. It has nothing to do > with font setting. Japanese characters display twice as wide and it > also takes two columns. Impossible. Whatever Latin fonts I choose, I see the same Japanese characters. So if I choose a wider Latin font (which I do, because the defaults are too small), there is no chance in hell that the Japanese glyphs *still* display exactly twice as wide as the Latin ones. > I mean, if the line is only US-ASCII and what-cursor-position > returns column 40, the line has 40 characters. If there are > Japanese characters and what-cursor-position returns column 40, > there may be only 20 characters. IMO `what-cursor-position' should either count the characters or maybe the pixels. Anything else is bound to be broken in almost every situation. I know the FSF did differently, and I think they made a mistake. > For example, next part contain 11 Japanese > characters. At the end of the line, what-cursor-position > will say column 22. > $B$3$N9T$O==0lJ8;z$G$9!#(B This is a "feature" of the `current-column' function, which in turn calls column_at_point(), which contains this: #ifdef MULE col += XCHARSET_COLUMNS (CHAR_CHARSET (c)); #else col ++; #endif /* MULE */ IMO the code above is wrong, and the function should simply return 11, not 22. From owner-xemacs-beta@xemacs.org Thu Jul 29 11:05:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA11531 for xemacs-beta-out; Thu, 29 Jul 1999 11:05:24 -0400 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 LAA11525 for ; Thu, 29 Jul 1999 11:05:20 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119rkE-0000Uh-00 for ; Thu, 29 Jul 1999 17:05:18 +0200 To: XEmacs Beta List Subject: Re: GNU Emacs new isearch feature References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> <76lnc0tasj.fsf@ppllc.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 Jul 1999 17:05:17 +0200 In-Reply-To: Jake Colman's message of "28 Jul 1999 23:06:04 -0400" Message-ID: <877lnjjy36.fsf@pc-hrvoje.srce.hr> Lines: 17 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> 21.1 is deeply frozen, sorry. > > Hrvoje> However, 21.2 happens to be quite stable, so xemacs-beta > Hrvoje> regulars should not hesitate to try it out. > > Is there a tentative release schedule for 21.2? I'm itching to try > it out but only if it is close to suitable for production use. 21.2 works nicely for me, for everyday editing and for news and mail-reading. Steve obviously has different experiences. I recommend you give 21.2 a shot, and if it doesn't work out for you, revert to 21.2. From owner-xemacs-beta@xemacs.org Thu Jul 29 11:07:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA11645 for xemacs-beta-out; Thu, 29 Jul 1999 11:07:42 -0400 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 LAA11639 for ; Thu, 29 Jul 1999 11:07:39 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119rmU-0000Um-00 for ; Thu, 29 Jul 1999 17:07:38 +0200 To: XEmacs Beta List Subject: Re: Merging with GNU Emacs References: <14239.49303.849093.581066@gargle.gargle.HOWL> <3.0.5.32.19990729102513.00a8a500@london.beasys.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 Jul 1999 17:07:37 +0200 In-Reply-To: Andy Piper's message of "Thu, 29 Jul 1999 10:25:13 +0100" Message-ID: <873dy7jxza.fsf@pc-hrvoje.srce.hr> Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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 01:02 PM 7/29/99 +0900, SL Baur wrote: > >Yes, no. At the moment they are busy reimplementing the XEmacs > >redisplay engine (incompatibly of course). > > Which reminds me. Are they implementing anything we don't have in this > area? Yes, quite a few things. Bill Perry might be more specific. > I think I know enough about redisplay now to add any new features we > are missing. Pixel-based scrolling, which would require clipping the top-most line in addition to the bottom-most one, would be really cool. From owner-xemacs-beta@xemacs.org Thu Jul 29 11:09:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA11711 for xemacs-beta-out; Thu, 29 Jul 1999 11:09:19 -0400 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 LAA11703 for ; Thu, 29 Jul 1999 11:09:17 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 119ro0-0000VA-00 for ; Thu, 29 Jul 1999 17:09:12 +0200 To: XEmacs Beta List Subject: Re: [patch] pty98 References: <3.0.5.32.19990729102506.00a918c0@london.beasys.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 Jul 1999 17:09:12 +0200 In-Reply-To: Andy Piper's message of "Thu, 29 Jul 1999 10:25:06 +0100" Message-ID: <87yafzijc7.fsf@pc-hrvoje.srce.hr> Lines: 7 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > I've no idea what this patch does, but this sort of thing should go > in the s&m files surely? No, we're trying to get rid of s&m files. getpt() should be detected by configure. From owner-xemacs-beta@xemacs.org Thu Jul 29 11:49:56 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA13377 for xemacs-beta-out; Thu, 29 Jul 1999 11:49:56 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA13371; Thu, 29 Jul 1999 11:49:49 -0400 Received: from megalith.bp.aventail.com (usrpri2-26.kiva.net [206.97.75.91]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id IAA04052; Thu, 29 Jul 1999 08:49:34 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id JAA03037; Thu, 29 Jul 1999 09:28:42 -0500 To: Andy Piper Cc: Neal Becker , xemacs-beta@xemacs.org Subject: Re: [patch] pty98 References: <3.0.5.32.19990729102506.00a918c0@london.beasys.com> Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 13 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) XEmacs/21.2 (Toshima) 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: > I've no idea what this patch does, but this sort of thing should go in the > s&m files surely? If it will truly work on _any_ glibc based system, and not just a linux glibc based box, then it belongs outside of the s&m directories, because it is really just C library dependent. If it requires linux though, then it can go to hellthe s&m directories. -bp From owner-xemacs-beta@xemacs.org Thu Jul 29 12:07:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA14042 for xemacs-beta-out; Thu, 29 Jul 1999 12:07:38 -0400 Received: from oakdale.ucdavis.edu (oakdale.ucdavis.edu [169.237.210.82]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA14037 for ; Thu, 29 Jul 1999 12:07:36 -0400 Received: (from hardaker@localhost) by oakdale.ucdavis.edu (8.9.3/8.9.3) id JAA17397; Thu, 29 Jul 1999 09:07:34 -0700 (PDT) Date: Thu, 29 Jul 1999 09:07:34 -0700 (PDT) Message-Id: <199907291607.JAA17397@oakdale.ucdavis.edu> From: "Wes Hardaker To: xemacs-beta@xemacs.org Subject: pgnus 0.95 gnus-demon-get-new-news() Reply-to: Wes Hardaker Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: pgnus 0.95 xemacs XEmacs 21.2 "Demeter" [Lucid] (hppa1.1-hp-hpux10.20) of Fri Apr 23 1999 on oakdale Lisp backtrace follows: mapconcat(char-to-string "|||" " ") # bind (value level function) trace-exit-message(nnimap-mark-to-flag-1 4 "gnus-expire") (insert (trace-exit-message (quote nnimap-mark-to-flag-1) trace-level ad-return-value)) ) # (unwind-protect ...) (save-excursion (set-buffer trace-buffer) (goto-char (point-max)) (insert (trace-exit-message ... trace-level ad-return-value))) ) # bind (trace-buffer trace-level) (let ((trace-level ...) (trace-buffer ...)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (if ... ...) (insert ...)) (setq ad-return-value (ad-Orig-nnimap-mark-to-flag-1 preds)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (insert ...))) ) # bind (ad-return-value) (let (ad-return-value) (let (... ...) (save-excursion ... ... ... ...) (setq ad-return-value ...) (save-excursion ... ... ...)) ad-return-value) ) # bind (preds) nnimap-mark-to-flag-1(expire) # bind (make-string always-list preds) ad-Orig-nnimap-mark-to-flag(expire nil nil) (setq ad-return-value (ad-Orig-nnimap-mark-to-flag preds always-list make-string)) ) # bind (trace-buffer trace-level) (let ((trace-level ...) (trace-buffer ...)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (if ... ...) (insert ...)) (setq ad-return-value (ad-Orig-nnimap-mark-to-flag preds always-list make-string)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (insert ...))) ) # bind (ad-return-value) (let (ad-return-value) (let (... ...) (save-excursion ... ... ... ...) (setq ad-return-value ...) (save-excursion ... ... ...)) ad-return-value) ) # bind (make-string always-list preds) nnimap-mark-to-flag(expire) # bind (pred) #((expirable . expire)) mapc(# ((marked . tick) (replied . reply) (expirable . expire) (killed . killed) (bookmarks . bookmark) (dormant . dormant) (scored . score) (saved . save) (cached . cache) (downloadable . download) (unsendable . unsend))) # (unwind-protect ...) # bind (server info group) ad-Orig-nnimap-request-update-info-internal("mlists.cmu-snmp-users" ("nnimap+crabtree:mlists.cmu-snmp-users" 3 ((1 . 14)) nil (nnimap "crabtree") ((uidvalidity . "922130009"))) "crabtree") (setq ad-return-value (ad-Orig-nnimap-request-update-info-internal group info server)) ) # bind (trace-buffer trace-level) (let ((trace-level ...) (trace-buffer ...)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (if ... ...) (insert ...)) (setq ad-return-value (ad-Orig-nnimap-request-update-info-internal group info server)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (insert ...))) ) # bind (ad-return-value) (let (ad-return-value) (let (... ...) (save-excursion ... ... ... ...) (setq ad-return-value ...) (save-excursion ... ... ...)) ad-return-value) ) # bind (server info group) nnimap-request-update-info-internal("mlists.cmu-snmp-users" ("nnimap+crabtree:mlists.cmu-snmp-users" 3 ((1 . 14)) nil (nnimap "crabtree") ((uidvalidity . "922130009"))) "crabtree") # bind (fast server group) ad-Orig-nnimap-request-group("mlists.cmu-snmp-users" "crabtree" nil) (setq ad-return-value (ad-Orig-nnimap-request-group group server fast)) ) # bind (trace-buffer trace-level) (let ((trace-level ...) (trace-buffer ...)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (if ... ...) (insert ...)) (setq ad-return-value (ad-Orig-nnimap-request-group group server fast)) (save-excursion (set-buffer trace-buffer) (goto-char ...) (insert ...))) ) # bind (ad-return-value) (let (ad-return-value) (let (... ...) (save-excursion ... ... ... ...) (setq ad-return-value ...) (save-excursion ... ... ...)) ad-return-value) ) # bind (fast server group) nnimap-request-group("mlists.cmu-snmp-users" "crabtree" nil) # bind (gnus-command-method group dont-check gnus-command-method) byte-code("..." [group dont-check method gnus-command-method gnus-find-method-for-group gnus-server-to-method gnus-get-function request-group gname string-match "^[^:]+:" 0 nil 1] 5) # (condition-case ... . ((error) (quit))) # bind (method active method dont-check scan group) gnus-activate-group("nnimap+crabtree:mlists.cmu-snmp-users" scan) # bind (method active group info foreign-level level newsrc level) gnus-get-unread-articles(5) # bind (gnus-read-active-file gnus-inhibit-demon nnmail-fetched-sources arg) gnus-group-get-new-news(5) # (unwind-protect ...) (save-excursion (gnus-group-get-new-news 5) (gnus-group-list-groups 5)) ) gnus-demon-get-new-news() byte-code("..." [handler] 1) # (condition-case ... . ((error))) # bind (handlers gnus-inhibit-demon handler time idle) gnus-demon() (lambda nil (gnus-demon))() # bind (this-command inhibit-quit quit-flag current-itimer) # (unwind-protect ...) # bind (match-data) byte-code("..." [match-data match-data ((store-match-data match-data)) itimer current-itimer nil quit-flag inhibit-quit this-command itimer-uses-arguments apply itimer-function itimer-function-arguments] 4) # (condition-case ... . ((error (byte-code "ÀÁ !#" ... 5)) (quit (byte-code "ÀÁ !Ä !\"" ... 4)))) # (unwind-protect ...) # bind (itimers itimer next-wakeup idle-time last-event-time recorded-run-time inhibit-quit time-elapsed) itimer-run-expired-timers(60.008877) # bind (sleep elapsed now itimer-inside-driver inhibit-quit ignored) itimer-timer-driver(nil) # (condition-case ... . error) # (catch top-level ...) [4] Segmentation fault xemacs From owner-xemacs-beta@xemacs.org Thu Jul 29 12:12:33 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA14260 for xemacs-beta-out; Thu, 29 Jul 1999 12:12:33 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA14256 for ; Thu, 29 Jul 1999 12:12:30 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id LAA18136; Thu, 29 Jul 1999 11:12:13 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14240.32093.653186.180671@buffalo.fnal.gov> Date: Thu, 29 Jul 1999 11:12:13 -0500 (CDT) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: GNU Emacs' rect.el In-Reply-To: <87d7xbjy7e.fsf@pc-hrvoje.srce.hr> References: <87u2qvmc0m.fsf@pc-hrvoje.srce.hr> <87wvvngxqs.fsf@pc-hrvoje.srce.hr> <1zihfmom6so.fsf@as303.ecc.u-tokyo.ac.jp> <87d7xbjy7e.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > > IMO `what-cursor-position' should either count the characters or maybe > the pixels. Anything else is bound to be broken in almost every > situation. I know the FSF did differently, and I think they made a > mistake. I heartily agree. Indeed, I think that for real support of variable-width fonts, we need two flavors of what-cursor-position, one which counts the characters, and one which counts the pixels. From owner-xemacs-beta@xemacs.org Thu Jul 29 12:44:48 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA16052 for xemacs-beta-out; Thu, 29 Jul 1999 12:44:48 -0400 Received: from buffalo.fnal.gov (buffalo.fnal.gov [131.225.84.156]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA16047 for ; Thu, 29 Jul 1999 12:44:43 -0400 Received: (from cgw@localhost) by buffalo.fnal.gov (8.8.7/8.8.7) id LAA27051; Thu, 29 Jul 1999 11:44:28 -0500 From: Charles G Waldman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14240.34028.39702.259256@buffalo.fnal.gov> Date: Thu, 29 Jul 1999 11:44:28 -0500 (CDT) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Merging with GNU Emacs In-Reply-To: <873dy7jxza.fsf@pc-hrvoje.srce.hr> References: <14239.49303.849093.581066@gargle.gargle.HOWL> <3.0.5.32.19990729102513.00a8a500@london.beasys.com> <873dy7jxza.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Face: %OO~XPb`a}(s2it:MIMa&Ig&fbz)+h$L,2js]uXlS*7R#!#e{6W^.z~0blXY]guz@qdC;-s>BG`iu,HOP"j\nV_W)'})|,9C>&St4H"\l$&:V;8)"gsPRlH S6]sBPDb:f<,&ReiQS59nI;6P{w1kPMSR|`8L6EaC?SBb|ujr$V^C8A+G3Z#'>U.> Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes: > Andy Piper writes: > > > I think I know enough about redisplay now to add any new features we > > are missing. > > Pixel-based scrolling, which would require clipping the top-most line > in addition to the bottom-most one, would be really cool. This would also help in the case when you have an image in a window; currently if the image is taller than the window you can't scroll through it. It would be neat to have pixel-based scrolling in both X and Y directions, IMO. From owner-xemacs-beta@xemacs.org Thu Jul 29 12:55:42 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA16447 for xemacs-beta-out; Thu, 29 Jul 1999 12:55:42 -0400 Received: from nbeckerpc.hns.com (nbeckerpc.hns.com [139.85.108.139]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA16438; Thu, 29 Jul 1999 12:55:30 -0400 Received: from nbecker by nbeckerpc.hns.com with local (Exim 3.02 #1) id 119tSZ-0000Uf-00; Thu, 29 Jul 1999 12:55:11 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: [patch] pty98 References: <3.0.5.32.19990729102506.00a918c0@london.beasys.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 29 Jul 1999 12:55:11 -0400 In-Reply-To: Andy Piper's message of "Thu, 29 Jul 1999 10:25:06 +0100" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> I've no idea what this patch does, but this sort of thing should go in the Andy> s&m files surely? It's not specific to any system. It's specific to glibc. Anyone want to suggest how to integrate this into s&m? From owner-xemacs-beta@xemacs.org Thu Jul 29 14:23:22 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA19749 for xemacs-beta-out; Thu, 29 Jul 1999 14:23:22 -0400 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 OAA19746 for ; Thu, 29 Jul 1999 14:23:18 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA27796; Thu, 29 Jul 1999 20:23:16 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006mI; Thu Jul 29 20:23:08 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA06971; Thu, 29 Jul 1999 20:23:08 +0200 To: xemacs-beta@xemacs.org, "Rodney Stromlund" Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) References: From: Jan Vroonhof Date: 29 Jul 1999 20:23:07 +0200 In-Reply-To: "Rodney Stromlund"'s message of "Wed, 28 Jul 1999 10:27:51 -0500" 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: "Rodney Stromlund" writes: > I am > on a HP-UX 10.20 PA2.0. I have tried switching my > stty settings to just about everything possible and > I always have the same problem. I have not gotten a > single email on this. Please just email me and tell > me to shut up! Please read on : This could be a problem with the asyncio SIGPOLL stuff. See static void request_sigio_on_device (struct device *d) in sysdep.c. HPUX10 is getting special treatment there. Maybe there is more needed or the special treatment is wrong for 10.20. > That's just a little too late! This is happens with the latest > release xemacs (21.1) and all betas I've used. This never happened > on 20.4. When did you start using the betas? Did you use any of the 21.0 range? > This problem isn't there in telnet or rsh. It is there in > rlogin and shell. Could try finding out what the process-connection-type is in each case? Can you seen obvious differences in strace/truss between the two different systems? Jan From owner-xemacs-beta@xemacs.org Thu Jul 29 14:32:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA20079 for xemacs-beta-out; Thu, 29 Jul 1999 14:32:19 -0400 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 OAA20076 for ; Thu, 29 Jul 1999 14:32:17 -0400 Received: (from daemon@localhost) by frege.math.ethz.ch (8.9.1/8.9.1) id UAA27910 for ; Thu, 29 Jul 1999 20:32:16 +0200 (MET DST) Received: from bolzano(129.132.146.140) via SMTP by frege, id smtpdAAAa006o2; Thu Jul 29 20:32:15 1999 Received: (vroonhof@localhost) by bolzano (SMI-8.6/D-MATH-client) id UAA06990; Thu, 29 Jul 1999 20:32:15 +0200 To: xemacs-beta@xemacs.org Subject: Re: vc-revert-buffer1 sacrifices fontification preserving minor modes References: <4noggyf9qj.fsf@rtp.ericsson.se> < From: Jan Vroonhof Date: 29 Jul 1999 20:32:14 +0200 In-Reply-To: Adrian Aichner's message of "28 Jul 1999 16:47:21 +0200" 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: Adrian Aichner writes: > APA> (setq font-lock-support-mode 'fast-lock-mode) Note that this statement is meaningless under XEmacs (it is a FSF thing in font-lock v2). Under XEmacs these things (still) get handled using font-lock-mode hook and friends. > APA> For font-lock-mode fontification is lost after `revert-buffer' calls > APA> `insert-file-contents'. > > This is still true. Actually it happens when `insert-file-contents' > calls `insert-file-contents-internal'. I am assuming this is the problem as the this should call the after-change-functions which should fontify the buffer. I haven't read the i-f-c broken thread completely yet. That could very well be the problem. Jan From owner-xemacs-beta@xemacs.org Thu Jul 29 17:30:35 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA26422 for xemacs-beta-out; Thu, 29 Jul 1999 17:30:35 -0400 Received: from max3p123.smart.net (max3p123.smart.net [216.84.81.123]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA26416 for ; Thu, 29 Jul 1999 17:30:27 -0400 Received: (from jmiller@localhost) by max3p123.smart.net (8.9.3/8.9.3) id RAA10366; Thu, 29 Jul 1999 17:31:15 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14240.51232.376878.728819@max3p123.smart.net.> Date: Thu, 29 Jul 1999 17:31:12 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: --with-shlib on rh6.0 X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: If I compile using the "--with-shlib" option on redhat 6.0, it fails with the following errors: .o ../lwlib/liblw.a -lXm -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtn.o `gcc -print-libgcc-file-name` sysdll.o: In function `dll_open': /cvs/xemacs/xemacs-21/src/sysdll.c:59: undefined reference to `dlopen' sysdll.o: In function `dll_close': /cvs/xemacs/xemacs-21/src/sysdll.c:65: undefined reference to `dlclose' sysdll.o: In function `dll_function': /cvs/xemacs/xemacs-21/src/sysdll.c:77: undefined reference to `dlsym' sysdll.o: In function `dll_variable': /cvs/xemacs/xemacs-21/src/sysdll.c:89: undefined reference to `dlsym' collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [src] Error 2 If I add -ldl to list of libraries to compile in, it will successfully compile. I assume this is something configure related but not sure what to check. jeff From owner-xemacs-beta@xemacs.org Thu Jul 29 20:21:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA03436 for xemacs-beta-out; Thu, 29 Jul 1999 20:21:55 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA03433 for ; Thu, 29 Jul 1999 20:21:52 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id JAA28461; Fri, 30 Jul 1999 09:21:35 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: Merging with GNU Emacs References: <14239.49303.849093.581066@gargle.gargle.HOWL> <3.0.5.32.19990729102513.00a8a500@london.beasys.com> <873dy7jxza.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "29 Jul 1999 17:07:37 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Jul 1999 09:21:35 +0900 Message-ID: Lines: 7 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > Pixel-based scrolling, which would require clipping the top-most line > in addition to the bottom-most one, would be really cool. And pixel-based filling, so auto-filling works properly with variable width fonts. From owner-xemacs-beta@xemacs.org Thu Jul 29 20:39:38 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA04031 for xemacs-beta-out; Thu, 29 Jul 1999 20:39:38 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA04022 for ; Thu, 29 Jul 1999 20:39:36 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id JAA28478; Fri, 30 Jul 1999 09:39:14 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: new bug in hm--html-menus 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 Jul 1999 09:39:14 +0900 Message-ID: Lines: 5 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Does this ring a bell to anyone? While compiling toplevel forms in file /project/xemacs/home/steve/devel/xemacs-packages/oa/hm--html-menus/hm--html-mode.el: !! Symbol's function definition is void ((get-popup-menu-response)) Done From owner-xemacs-beta@xemacs.org Thu Jul 29 20:44:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA04231 for xemacs-beta-out; Thu, 29 Jul 1999 20:44:51 -0400 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 UAA04227 for ; Thu, 29 Jul 1999 20:44:50 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A0n2-0000jj-00 for ; Fri, 30 Jul 1999 02:44:48 +0200 To: XEmacs Beta List Subject: backward-word: WTF? 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 Jul 1999 02:44:46 +0200 Message-ID: <87oggvge4h.fsf@pc-hrvoje.srce.hr> Lines: 7 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: You won't believe this one. Start up `xemacs -vanilla', type "a b" (no quotes) into *scratch*, then press `M-b'. For me the point ends up at the beginning of line instead of at the beginning of "b". Somebody seriously fucked up scan_words(), which a potential to damage XEmacs seriously. The `#ifdef MULE' code looks especially suspicious (I still run with Mule). Please be more careful when changing code. From owner-xemacs-beta@xemacs.org Thu Jul 29 21:15:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA05407 for xemacs-beta-out; Thu, 29 Jul 1999 21:15:52 -0400 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 VAA05400 for ; Thu, 29 Jul 1999 21:15:49 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A1H1-0000ka-00 for ; Fri, 30 Jul 1999 03:15:47 +0200 To: XEmacs Beta List Subject: Re: new bug in hm--html-menus 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: 30 Jul 1999 03:15:47 +0200 In-Reply-To: SL Baur's message of "30 Jul 1999 09:39:14 +0900" Message-ID: <87g127gcos.fsf@pc-hrvoje.srce.hr> Lines: 10 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Does this ring a bell to anyone? > > While compiling toplevel forms in file /project/xemacs/home/steve/devel/xemacs-packages/oa/hm--html-menus/hm--html-mode.el: > !! Symbol's function definition is void > ((get-popup-menu-response)) Maybe you compile without menubar support, so `get-popup-menu-response' is unavailable? From owner-xemacs-beta@xemacs.org Thu Jul 29 21:20:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA05526 for xemacs-beta-out; Thu, 29 Jul 1999 21:20:37 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA05522 for ; Thu, 29 Jul 1999 21:20:33 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id KAA29944; Fri, 30 Jul 1999 10:20:10 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: new bug in hm--html-menus References: <87g127gcos.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "30 Jul 1999 03:15:47 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Jul 1999 10:20:10 +0900 Message-ID: Lines: 39 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > SL Baur writes: >> Does this ring a bell to anyone? >> >> While compiling toplevel forms in file /project/xemacs/home/steve/devel/xemacs-packages/oa/hm--html-menus/hm--html-mode.el: >> !! Symbol's function definition is void >> ((get-popup-menu-response)) > Maybe you compile without menubar support, so > `get-popup-menu-response' is unavailable? Of course. I'm building the Sumos and I use a bare-ass naked featureless bytecompile engine to do it. It's been that way for several years now. You are not allowed to call X functions during bytecompilation (nor any other feature specific call). uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc ./configure '--with-mule' '--debug=no' '--error-checking=none' '--verbose=no' '--extra-verbose=no' '--compiler=gcc' '--mail-locking=file' '--cflags=-O' '--without-x11' '--prefix=/project/xemacs/home/steve/devel/dummy' '--without-shlib' '--without-canna' '--without-database' XEmacs 21.1.4 "Arches" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /project/xemacs/home/steve/devel/xemacs-21.1 What installation prefix should install use? /project/xemacs/home/steve/devel/dummy 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/ccs/lib:/usr/local/lib Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. movemail will use "dot-locking" for locking mail spool files. From owner-xemacs-beta@xemacs.org Thu Jul 29 21:21:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA05648 for xemacs-beta-out; Thu, 29 Jul 1999 21:21:53 -0400 Received: from slow.bp.aventail.com (usrpri2-4.kiva.net [206.97.75.69]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA05641 for ; Thu, 29 Jul 1999 21:21:50 -0400 Received: from aventail.com (megalith.bp.aventail.com [192.168.2.6]) by slow.bp.aventail.com (8.9.3/8.8.5) with ESMTP id UAA05887; Thu, 29 Jul 1999 20:21:24 -0500 Message-ID: <37A0FE59.9D54AC15@aventail.com> Date: Thu, 29 Jul 1999 20:22:33 -0500 From: William Perry X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jmiller@smart.net CC: xemacs-beta@xemacs.org Subject: Re: --with-shlib on rh6.0 References: <14240.51232.376878.728819@max3p123.smart.net.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Jeff Miller wrote: > If I compile using the "--with-shlib" option on redhat 6.0, it fails > with the following errors: > > .o ../lwlib/liblw.a -lXm -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtn.o `gcc -print-libgcc-file-name` > sysdll.o: In function `dll_open': > /cvs/xemacs/xemacs-21/src/sysdll.c:59: undefined reference to `dlopen' > sysdll.o: In function `dll_close': > /cvs/xemacs/xemacs-21/src/sysdll.c:65: undefined reference to `dlclose' > sysdll.o: In function `dll_function': > /cvs/xemacs/xemacs-21/src/sysdll.c:77: undefined reference to `dlsym' > sysdll.o: In function `dll_variable': > /cvs/xemacs/xemacs-21/src/sysdll.c:89: undefined reference to `dlsym' > collect2: ld returned 1 exit status > make[1]: *** [temacs] Error 1 > make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' > make: *** [src] Error 2 > > If I add -ldl to list of libraries to compile in, it will > successfully compile. I assume this is something configure related but > not sure what to check. Definitely configure related. Could you send your config.log (trim to the bits about checking for dlopen and -ldl if you could :) -bp From owner-xemacs-beta@xemacs.org Thu Jul 29 21:50:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA06915 for xemacs-beta-out; Thu, 29 Jul 1999 21:50:05 -0400 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 VAA06910 for ; Thu, 29 Jul 1999 21:50:01 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A1o7-0000lw-00 for ; Fri, 30 Jul 1999 03:49:59 +0200 To: XEmacs Beta List Subject: Re: new bug in hm--html-menus References: <87g127gcos.fsf@pc-hrvoje.srce.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: 30 Jul 1999 03:49:56 +0200 In-Reply-To: SL Baur's message of "30 Jul 1999 10:20:10 +0900" Message-ID: <87r9lqgb3v.fsf@pc-hrvoje.srce.hr> Lines: 8 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > You are not allowed to call X functions during bytecompilation (nor > any other feature specific call). I don't have the hm-- stuff around, so I can't fix the problem. I do remember that someone changed the code in question lately, so investigating that change should lead to the problem. From owner-xemacs-beta@xemacs.org Thu Jul 29 21:56:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA07222 for xemacs-beta-out; Thu, 29 Jul 1999 21:56:29 -0400 Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA07218; Thu, 29 Jul 1999 21:56:14 -0400 Received: from erols.com (209-122-223-187.s187.tnt3.nyw.ny.dialup.rcn.com [209.122.223.187]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id VAA25158; Thu, 29 Jul 1999 21:56:07 -0400 (EDT) Message-ID: <37A106A5.5E19F4B8@erols.com> Date: Thu, 29 Jul 1999 21:57:57 -0400 From: "Matthew O. Persico" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SL Baur CC: xemacs-beta@xemacs.org Subject: Re: Shell trouble - third post (was Shell trouble - second post, please read) References: <379FCB7A.4185F8B3@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: SL Baur wrote: > > Matthew O Persico writes in xemacs-beta@xemacs.org: > > > But not all programs do. I live in shell mode. I open xterms and > > use them in the normal course of work but anytime I want to use a > > program that does NOT have editing (like isql for Sybase/sqlplus > > for Oracle) I find it much easier to use shell mode. > > Isn't this situation what an inferior SQL mode is supposed to deal > with? Don't we have an inferior SQL mode? The only mode I know about for sure is sql-mode 0.992. I actually used it once when I was using Sybase exclusively. It did a pretty good job with sql code, but I never did feel comfortable using its interactive shell mode. All the other modes I've seen are sybase or oracle specific to my knowledge. Don't forget, I am running an interactive program (isql for Syb or sqlplus for Ora) and using xemacs shell mode as a convenience. I could just as well be using program FOOBar for something else. They value added here is the shell, forget what I am doing in it. From owner-xemacs-beta@xemacs.org Thu Jul 29 21:57:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA07200 for xemacs-beta-out; Thu, 29 Jul 1999 21:55:36 -0400 Received: from max3p123.smart.net (max3p123.smart.net [216.84.81.123]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA07182 for ; Thu, 29 Jul 1999 21:55:18 -0400 Received: (from jmiller@localhost) by max3p123.smart.net (8.9.3/8.9.3) id VAA13785; Thu, 29 Jul 1999 21:56:04 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14241.1588.597384.705061@max3p123.smart.net.> Date: Thu, 29 Jul 1999 21:56:04 -0400 (EDT) To: Subject: Re: XEmacs 21.2 release checklist (was Re: GNU Emacs new isearch feature) In-Reply-To: References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> <76lnc0tasj.fsf@ppllc.com> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> 1. Fix new build problems ie. with X, without menubars, etc. I've added several new configuration tests to my mega build script, it's now up to 21 tests. all-guess just "./configure" dynamic tests --with-shlib fast non mule, optimized for speed fastmule mule, optimzied for speed just-dialogs only use the dialog gui elemnt just-menubars only use the menubar gui element just-scrollbars only use the scrollbar gui element just-toolbars only use the toolbar gui element just-widgets only use the widget gui elements lesstif specify motif for scrollbar, dialog, and menubar min turn off all possible features, except X mule beta mule no-dialogs all gui elements except dialogs no-menubars all gui elements except menus no-scrollbars all gui elements except scrollbars no-toolbars all gui elements except toolbars no-widgets all gui elements except widgets no-tty no tty code no-x tty only, no X reg beta non-mule xaw3d link with libXaw3d of the above, only 4 fail. dynamic, just-toolbars, just-widgets, and min. I had to patch scrollbar-x.c to get just-scrollbars to compile. This is with the b18 CVS code, I haven't updated anything recently. The above tests all compile successfully on 21.1.4. with anything widget related being a no-op in that case. i've already sent in the "dynamic" failure. just-toolbars & just-widgets fail with gcc -c -g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gui-x.c gui-x.c: In function `mark_popup_data': gui-x.c:95: dereferencing pointer to incomplete type gui-x.c:100: dereferencing pointer to incomplete type gui-x.c:103: dereferencing pointer to incomplete type gui-x.c: At top level: gui-x.c:108: sizeof applied to an incomplete type gui-x.c: In function `gcpro_popup_callbacks': gui-x.c:123: sizeof applied to an incomplete type gui-x.c:124: dereferencing pointer to incomplete type gui-x.c:125: dereferencing pointer to incomplete type gui-x.c:126: dereferencing pointer to incomplete type make[1]: *** [gui-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 min fails with gcc -c -g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include glyphs-x.c glyphs-x.c: In function `x_widget_instantiate': glyphs-x.c:2223: `popup_selection_callback' undeclared (first use in this function) glyphs-x.c:2223: (Each undeclared identifier is reported only once glyphs-x.c:2223: for each function it appears in.) make[1]: *** [glyphs-x.o] Error 1 make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' make: *** [dump-elcs] Error 2 Command exited with non-zero status 2 From owner-xemacs-beta@xemacs.org Thu Jul 29 22:01:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA07369 for xemacs-beta-out; Thu, 29 Jul 1999 22:01:46 -0400 Received: from max3p123.smart.net (max3p123.smart.net [216.84.81.123]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA07355 for ; Thu, 29 Jul 1999 22:01:36 -0400 Received: (from jmiller@localhost) by max3p123.smart.net (8.9.3/8.9.3) id WAA13801; Thu, 29 Jul 1999 22:02:17 -0400 From: Jeff Miller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14241.1961.375889.626862@max3p123.smart.net.> Date: Thu, 29 Jul 1999 22:02:17 -0400 (EDT) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: backward-word: WTF? In-Reply-To: <87oggvge4h.fsf@pc-hrvoje.srce.hr> References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> X-Mailer: VM 6.71 under 21.2 (beta18) "Toshima" XEmacs Lucid Reply-To: jmiller@smart.net Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> You won't believe this one. Start up `xemacs -vanilla', type "a b" Hrvoje> (no quotes) into *scratch*, then press `M-b'. For me the point ends Hrvoje> up at the beginning of line instead of at the beginning of "b". Hrvoje> Somebody seriously fucked up scan_words(), which a potential to damage Hrvoje> XEmacs seriously. The `#ifdef MULE' code looks especially suspicious Hrvoje> (I still run with Mule). Please be more careful when changing code. it's ends up on the b for me with a non-mule xemacs 21.2.b18, so you're probably right about the mulage. From owner-xemacs-beta@xemacs.org Thu Jul 29 22:06:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id WAA07544 for xemacs-beta-out; Thu, 29 Jul 1999 22:06:49 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id WAA07518 for ; Thu, 29 Jul 1999 22:06:39 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id LAA02618; Fri, 30 Jul 1999 11:06:17 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: new bug in hm--html-menus References: <87g127gcos.fsf@pc-hrvoje.srce.hr> <87r9lqgb3v.fsf@pc-hrvoje.srce.hr> X-Attribution: sb From: SL Baur In-Reply-To: Hrvoje Niksic's message of "30 Jul 1999 03:49:56 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Jul 1999 11:06:17 +0900 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQkstRWcbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hrvoje Niksic writes in xemacs-beta@xemacs.org: > SL Baur writes: >> You are not allowed to call X functions during bytecompilation (nor >> any other feature specific call). > I don't have the hm-- stuff around, so I can't fix the problem. I do > remember that someone changed the code in question lately, so > investigating that change should lead to the problem. I won't have time until next week. If someone fixes it in the next few hours I will update the ftp site, otherwise there will be no hm--html-menus until next week. From owner-xemacs-beta@xemacs.org Thu Jul 29 23:04:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id XAA08934 for xemacs-beta-out; Thu, 29 Jul 1999 23:04:29 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id XAA08930 for ; Thu, 29 Jul 1999 23:04:26 -0400 Received: from miho.etl.go.jp (localhost [127.0.0.1]) by miho.etl.go.jp (8.9.3/8.9.3) with ESMTP id MAA06459 for ; Fri, 30 Jul 1999 12:04:07 +0900 (JST) Date: Fri, 30 Jul 1999 12:04:07 +0900 (JST) Message-Id: <199907300304.MAA06459@miho.etl.go.jp> Mail-Copies-To: Never From: "XEmacs Build 'Bot" Subject: XEmacs Build Report for XEmacs-21.2.19 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.19 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=/project/xemacs/home/steve/devel' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.2-b19 "Shinjuku" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /project/xemacs/home/steve/devel/xemacs-21.2 What installation prefix should install use? /project/xemacs/home/steve/devel 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/lib 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 Fri Jul 30 02:55:31 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA14511 for xemacs-beta-out; Fri, 30 Jul 1999 02:55:31 -0400 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 CAA14505 for ; Fri, 30 Jul 1999 02:55:26 -0400 Received: from brabantio.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 IAA20544; Fri, 30 Jul 1999 08:55:17 +0200 Received: (from sperber@localhost) by brabantio.informatik.uni-tuebingen.de (8.9.3/8.9.1) id IAA30296; Fri, 30 Jul 1999 08:55:14 +0200 To: bauer@itsm.uni-stuttgart.de Cc: xemacs-beta@xemacs.org Subject: Re: 21.1.4 on DU4.0e, wrong exec-directory References: <37A00E55.5C85103D@itsm.uni-stuttgart.de> 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: 30 Jul 1999 08:55:14 +0200 In-Reply-To: Holger Bauer's message of "Thu, 29 Jul 1999 10:18:29 +0200" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Toshima" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA14509 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Holger" == Holger Bauer writes: Holger> Bug report: Holger> Tried to install Xemacs Version 21.1.4 on our DEC Alpha DU4.0e system. Holger> However, all architecture dependent files get installed in the right Holger> place but xemacs does not find them because exec-directory points to the Holger> ...../lib-src directory ^^^^^ What's the value of the dots and what's the name of the directory you expected EXEC-DIRECTORY to point to? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla From owner-xemacs-beta@xemacs.org Fri Jul 30 03:31:01 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA15785 for xemacs-beta-out; Fri, 30 Jul 1999 03:31:01 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA15780 for ; Fri, 30 Jul 1999 03:30:58 -0400 Received: from metheny.enst.fr (0oXAcnIHrfgpkAs3U6KzJMaNMBDIofSP@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id JAA09691; Fri, 30 Jul 1999 09:30:55 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id JAA20314; Fri, 30 Jul 1999 09:30:52 +0200 (MET DST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> 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: Hrvoje Niksic's message of "30 Jul 1999 02:44:46 +0200" 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: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > You won't believe this one. Start up `xemacs -vanilla', type "a b" > (no quotes) into *scratch*, then press `M-b'. For me the point ends > up at the beginning of line instead of at the beginning of "b". In a similar vein, when you're at the beginning of the line and type M-f the point is put after the "a". Wouldn't it be more logical to put it after the space ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 03:43:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16191 for xemacs-beta-out; Fri, 30 Jul 1999 03:43:59 -0400 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 DAA16183 for ; Fri, 30 Jul 1999 03:43:53 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id AAA21693; Fri, 30 Jul 1999 00:43:35 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-53.beasys.com [192.168.11.53]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id AAA01387; Fri, 30 Jul 1999 00:43:27 -0700 (PDT) Message-Id: <3.0.5.32.19990730084357.00ab7350@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 08:43:57 +0100 To: jmiller@smart.net, From: Andy Piper Subject: Re: XEmacs 21.2 release checklist (was Re: GNU Emacs new isearch feature) In-Reply-To: <14241.1588.597384.705061@max3p123.smart.net.> References: <199907280031.RAA01874@mina.sr.hp.com> <87n1whjz2v.fsf@pc-hrvoje.srce.hr> <767lnl9c9w.fsf@ppllc.com> <87r9lsval6.fsf@pc-hrvoje.srce.hr> <76lnc0tasj.fsf@ppllc.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:56 PM 7/29/99 -0400, Jeff Miller wrote: >just-toolbars & just-widgets fail with > >gcc -c -g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gui-x.c >gui-x.c: In function `mark_popup_data': >gui-x.c:95: dereferencing pointer to incomplete type >gui-x.c:100: dereferencing pointer to incomplete type >gui-x.c:103: dereferencing pointer to incomplete type >gui-x.c: At top level: >gui-x.c:108: sizeof applied to an incomplete type >gui-x.c: In function `gcpro_popup_callbacks': >gui-x.c:123: sizeof applied to an incomplete type >gui-x.c:124: dereferencing pointer to incomplete type >gui-x.c:125: dereferencing pointer to incomplete type >gui-x.c:126: dereferencing pointer to incomplete type >make[1]: *** [gui-x.o] Error 1 >make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' >make: *** [dump-elcs] Error 2 I'll look at this. >min fails with > >gcc -c -g -Wno-switch -malign-loops=2 -malign-jumps=2 -I/usr/include/db1 -malign-functions=2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include glyphs-x.c >glyphs-x.c: In function `x_widget_instantiate': >glyphs-x.c:2223: `popup_selection_callback' undeclared (first use in this function) >glyphs-x.c:2223: (Each undeclared identifier is reported only once >glyphs-x.c:2223: for each function it appears in.) >make[1]: *** [glyphs-x.o] Error 1 >make[1]: Leaving directory `/cvs/xemacs/xemacs-21/src' >make: *** [dump-elcs] Error 2 >Command exited with non-zero status 2 This should get fixed with my patch being applied imminently. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 03:49:32 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16409 for xemacs-beta-out; Fri, 30 Jul 1999 03:49:32 -0400 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id CAA13790 for xemacs-announce-out; Fri, 30 Jul 1999 02:11:30 -0400 To: xemacs-announce@xemacs.org Subject: XEmacs 21.2.19 =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= 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 Jul 1999 15:11:07 +0900 Message-ID: Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= Reply-To: xemacs-beta@xemacs.org X-Mailing-List: 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/ New XEmacs lisp packages have been uploaded as well. The new Sumos are in: ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz Everything has been rebuilt & repackaged in order to fix an installation bug. Many packages have been updated. VM is now current, BBDB is now current to name two. Lots of bug fixes, lots of new bugs to find, in other words a typical beta XEmacs. Enjoy. "Shinjuku" is the ward of Tokyo where Jareth Hein lives. It is a very cool place to visit. It is 90/90 today, 90+ degrees and 90+% humidity. Please forgive me for being terse. Happy Birthday in advance to Jason Mastaler (Saturday is his birthday). to 21.2.19 "Shinjuku" -- various fixes from Gunnar Evermann -- XIM fixes from Kazuyuki IENAGA -- keymap fix from Katsumi Yamaoka -- Microsoft build fixes from Adrian Aichner -- documentation update from Adrian Aichner -- rect.el rewrite from Didier Verna -- custom comment fields from Didier Verna -- various fixes from Karl Hegbloom -- filling fix from Yoshiki Hayashi -- miscellaneous changes from Jeff Miller and Didier Verna -- configure hacking from Steve Baur -- various fixes from Bob Weiner -- Mule synching from MORIOKA Tomohiko -- various fixes from Steve Baur -- LDAP configure changes from Gregory Neil Shapiro -- gutter implementation from Andy Piper -- tab widgets in gutter from Andy Piper -- Custom themes, API part. See etc/custom/theme-examples from Jan Vroonhof From owner-xemacs-beta@xemacs.org Fri Jul 30 03:54:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16606 for xemacs-beta-out; Fri, 30 Jul 1999 03:54:00 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA16599 for ; Fri, 30 Jul 1999 03:53:48 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id QAA15222; Fri, 30 Jul 1999 16:43:02 +0900 (JST) Mail-Copies-To: never To: Eric Marsden Cc: xemacs-beta@xemacs.org Subject: Re: Submitting new packages: pg.el & babel.el References: X-Attribution: sb From: SL Baur In-Reply-To: Eric Marsden's message of "29 Jul 1999 15:50:13 +0200" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Jul 1999 16:43:02 +0900 Message-ID: Lines: 32 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Eric Marsden writes in xemacs-beta@xemacs.org: > Hi, > This is to suggest inclusion of two elisp modules I have written in > XEmacs (presumably as packages). O.K. > * pg.el is a socket-level interface to the PostgreSQL RDBMS. Definitely O.K. I like PostgreSQL. > * babel.el is an interface to different translation engines available > on Internet, such as Babelfish and SysTran. Synchronicity. I've just been experimenting with king.el, a front end to IBM's Translation King. > I don't know what the correct procedure for requesting inclusion is > ( says "please let us know"; I > hope this is the right place). You have posted to the right place. > I am not able to stay current with development versions of XEmacs, so > I can't do the packaging myself. I will add them. No problem. They're just single lisp files, so I'll add them to one of the existing single-file collections. I notice you also have a dict.el. Can we bundle that too? From owner-xemacs-beta@xemacs.org Fri Jul 30 04:21:20 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id DAA16908 for xemacs-beta-out; Fri, 30 Jul 1999 03:59:56 -0400 Received: from miho.etl.go.jp ([150.29.201.195]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id DAA16892 for ; Fri, 30 Jul 1999 03:59:45 -0400 Received: (from steve@localhost) by miho.etl.go.jp (8.9.3/8.9.3) id QAA15399; Fri, 30 Jul 1999 16:59:24 +0900 (JST) Mail-Copies-To: never To: xemacs-beta@xemacs.org Subject: Re: FYI mailcrypt-3.5.4 References: <99072708241200.11440@rpppc2.hns.com> X-Attribution: sb From: SL Baur In-Reply-To: Neal Becker's message of "Tue, 27 Jul 1999 08:23:29 -0400" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 30 Jul 1999 16:59:24 +0900 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Neal Becker writes in xemacs-beta@xemacs.org: > http://freshmeat.net/news/1999/07/26/933042852.html Server Error Server Error This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server's error log. From owner-xemacs-beta@xemacs.org Fri Jul 30 04:28:00 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id EAA17427 for xemacs-beta-out; Fri, 30 Jul 1999 04:11:09 -0400 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 EAA17423 for ; Fri, 30 Jul 1999 04:11:03 -0400 Received: from liszt.laas.fr (liszt [140.93.21.56]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id KAA18588 for ; Fri, 30 Jul 1999 10:11:00 +0200 (MET DST) Received: (from emarsden@localhost) by liszt.laas.fr (8.9.3/8.9.3) id KAA07672; Fri, 30 Jul 1999 10:11:15 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: Submitting new packages: pg.el & babel.el References: 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: 30 Jul 1999 10:11:14 +0200 In-Reply-To: SL Baur's message of 30 Jul 1999 16:43:02 +0900 Message-ID: Lines: 23 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "sb" == SL Baur writes: sb> I will add them. No problem. They're just single lisp files, so sb> I'll add them to one of the existing single-file collections. excellent, thanks. sb> I notice you also have a dict.el. Can we bundle that too? Not now. Firstly someone else had previously written something called `dict.el', so the name will have to change. Secondly it has very limited functionality; it should be merged with other dictionary interface packages to provide a uniform interface. webster.el ... -- Eric Marsden It's elephants all the way down From owner-xemacs-beta@xemacs.org Fri Jul 30 05:27:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA19897 for xemacs-beta-out; Fri, 30 Jul 1999 05:27:03 -0400 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 FAA19894 for ; Fri, 30 Jul 1999 05:26:52 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A8wA-0001DX-00 for ; Fri, 30 Jul 1999 11:26:46 +0200 To: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.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: 30 Jul 1999 11:26:43 +0200 In-Reply-To: Didier Verna's message of "30 Jul 1999 09:30:51 +0200" Message-ID: <87hfmm8p4c.fsf@pc-hrvoje.srce.hr> Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > In a similar vein, when you're at the beginning of the line and type > M-f the point is put after the "a". Er... That's the way Emacs has behaved since forever. :-) > Wouldn't it be more logical to put it after the space ? No? :-) What XEmacs does currently is often confusing to beginners, but I find that it works very well once you get used to it. What I reported was, however, a *bug*, plain and simple. And a very dangerous one because a lot of parsing code in language modes, Gnus, the internals, simply everywhere, expects scan_words() to work unchanged. From owner-xemacs-beta@xemacs.org Fri Jul 30 05:47:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA20333 for xemacs-beta-out; Fri, 30 Jul 1999 05:47:41 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id FAA20327 for ; Fri, 30 Jul 1999 05:47:36 -0400 Received: from metheny.enst.fr (tLyCDWhIArWKCB4bc3Y1SZNEf1wEL6rM@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id LAA14503; Fri, 30 Jul 1999 11:47:33 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id LAA23548; Fri, 30 Jul 1999 11:47:28 +0200 (MET DST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> <87hfmm8p4c.fsf@pc-hrvoje.srce.hr> 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: Hrvoje Niksic's message of "30 Jul 1999 11:26:43 +0200" 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: 24 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > > In a similar vein, when you're at the beginning of the line and type > > M-f the point is put after the "a". > > Er... That's the way Emacs has behaved since forever. :-) I know :-) > > Wouldn't it be more logical to put it after the space ? > > No? :-) What XEmacs does currently is often confusing to beginners, > but I find that it works very well once you get used to it. "Once you get used to it" as you say... Is this an argument? That's exactly because we're all "used to XEmacs" that I'm throwing out this kind of questions from time to time. :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 05:53:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id FAA20414 for xemacs-beta-out; Fri, 30 Jul 1999 05:53:05 -0400 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 FAA20411 for ; Fri, 30 Jul 1999 05:53:01 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A9LL-0001h2-00 for ; Fri, 30 Jul 1999 11:52:47 +0200 To: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> <87hfmm8p4c.fsf@pc-hrvoje.srce.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: 30 Jul 1999 11:52:43 +0200 In-Reply-To: Didier Verna's message of "30 Jul 1999 11:47:26 +0200" Message-ID: <87wvvi79ck.fsf@pc-hrvoje.srce.hr> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > > > Wouldn't it be more logical to put it after the space ? > > > > No? :-) What XEmacs does currently is often confusing to beginners, > > but I find that it works very well once you get used to it. > > "Once you get used to it" as you say... Is this an argument? That's > exactly because we're all "used to XEmacs" that I'm throwing out > this kind of questions from time to time. :-) But I would appreciate it if you threw them in a separate thread, not to confuse them with bug reports. From owner-xemacs-beta@xemacs.org Fri Jul 30 06:04:45 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA20692 for xemacs-beta-out; Fri, 30 Jul 1999 06:04:45 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id GAA20689 for ; Fri, 30 Jul 1999 06:04:41 -0400 Received: from metheny.enst.fr (Gp2yUFCD9w4kBZquEMGwxptCbbEKUkAp@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id MAA15223; Fri, 30 Jul 1999 12:04:39 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id MAA24924; Fri, 30 Jul 1999 12:04:34 +0200 (MET DST) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> <87hfmm8p4c.fsf@pc-hrvoje.srce.hr> <87wvvi79ck.fsf@pc-hrvoje.srce.hr> 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: Hrvoje Niksic's message of "30 Jul 1999 11:52:43 +0200" 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: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > But I would appreciate it if you threw them in a separate thread, not > to confuse them with bug reports. ?! C'mon, I think you made yourself perfectly clear. And if you want to avoid confusing people, start sticking `[BUG]' at the beginning of your Subject line instead of `WTF' at the end. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 06:20:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id GAA21187 for xemacs-beta-out; Fri, 30 Jul 1999 06:20:12 -0400 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 GAA21184 for ; Fri, 30 Jul 1999 06:20:08 -0400 Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 11A9lh-00022i-00 for ; Fri, 30 Jul 1999 12:20:01 +0200 To: XEmacs Beta List Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> <87hfmm8p4c.fsf@pc-hrvoje.srce.hr> <87wvvi79ck.fsf@pc-hrvoje.srce.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: 30 Jul 1999 12:19:55 +0200 In-Reply-To: Didier Verna's message of "30 Jul 1999 12:04:32 +0200" Message-ID: <87oggu7838.fsf@pc-hrvoje.srce.hr> Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Dionysos) 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: > Hrvoje Niksic writes: > > > But I would appreciate it if you threw them in a separate thread, > > not to confuse them with bug reports. > > ?! C'mon, I think you made yourself perfectly clear. And if you want > to avoid confusing people, start sticking `[BUG]' at the beginning > of your Subject line instead of `WTF' at the end. And the same to YOU, mac! Okay, just kidding. The [bug] thing is actually a good suggestion. I used to do that before, when functions other than `backward-word' got buggy. From owner-xemacs-beta@xemacs.org Fri Jul 30 09:19:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA24861 for xemacs-beta-out; Fri, 30 Jul 1999 09:19:46 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA24855 for ; Fri, 30 Jul 1999 09:19:45 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ACZd-0000u8-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 09:19:45 -0400 To: xemacs-beta@xemacs.org Subject: makeinfo fails on 21.2b19 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 09:19:45 -0400 Message-ID: Lines: 5 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: ./internals.texi:130: Menu reference to nonexistent node `Faces and Glyphs'. ./internals.texi:7878: warning: unreferenced node `Widget-Glyphs in the MS-WIndows Environment'. ./internals.texi:7883: warning: unreferenced node `Widget-Glyphs in the X Environment'. makeinfo: Removing output file `../../info/internals.info' due to errors; use --force to preserve. make[2]: *** [../../info/internals.info] Error 2 From owner-xemacs-beta@xemacs.org Fri Jul 30 09:18:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA24809 for xemacs-beta-out; Fri, 30 Jul 1999 09:18:27 -0400 Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA24801 for ; Fri, 30 Jul 1999 09:18:25 -0400 Received: from ulysse.enst.fr (root@inf.enst.fr [137.194.2.81]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id OAA21040 for ; Fri, 30 Jul 1999 14:40:32 +0200 (MET DST) Received: from metheny.enst.fr (upoCWi9+RLF6cPnwj0tX6rOv9uquDM3B@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id OAA20483 for ; Fri, 30 Jul 1999 14:40:31 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id OAA02978; Fri, 30 Jul 1999 14:40:27 +0200 (MET DST) To: Xemacs Beta Testers Subject: (b19) I can't use custom anymore (because of themes) 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 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: 10 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: I keep getting "invalid read syntax: #" error messages when trying to save options.el. The origin seems to be in the use of # in functions like custom-load-themes. I don't know what this syntax means. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 09:26:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25294 for xemacs-beta-out; Fri, 30 Jul 1999 09:26:11 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25286 for ; Fri, 30 Jul 1999 09:26:11 -0400 Received: from metheny.enst.fr (ml/UI8UUibhVxb1us43/5NsxlduV9sPK@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id PAA22254 for ; Fri, 30 Jul 1999 15:26:10 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id PAA03086; Fri, 30 Jul 1999 15:26:06 +0200 (MET DST) To: Xemacs Beta Testers Subject: Re: (b19) I can't use custom anymore (because of themes) 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: Didier Verna's message of "30 Jul 1999 14:40:27 +0200" 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: 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: I write: > I keep getting "invalid read syntax: #" error messages when trying to > save options.el. The origin seems to be in the use of # in functions like > custom-load-themes. I don't know what this syntax means. I'm wrong. It's a bug that I fixed some time ago, but seems to have reappeared with the themes stuff: custom doesn't protect symbols with special characters in them when writing the custom file. It's a matter of using print1-to-string instead of print1 somewhere. I haven't found out where yet. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 09:26:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25284 for xemacs-beta-out; Fri, 30 Jul 1999 09:26:10 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25281 for ; Fri, 30 Jul 1999 09:26:09 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ACfp-00012n-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 09:26:09 -0400 To: xemacs-beta@xemacs.org Subject: tab widgets/gutter serious redisplay problem Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 09:26:09 -0400 Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: 21.2.19 The tab widgets are being redrawn like crazy under some conditions. It's awful. For example, lots of scrolling output from shell mode in window 2 is causing the tab widgets to flash like crazy. Not sure yet precisely how to reproduce it - but I've seen it several times after just seconds of use - so it's not too hard. From owner-xemacs-beta@xemacs.org Fri Jul 30 09:28:09 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25372 for xemacs-beta-out; Fri, 30 Jul 1999 09:28:09 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25369 for ; Fri, 30 Jul 1999 09:28:08 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11AChk-00012p-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 09:28:08 -0400 To: xemacs-beta@xemacs.org Subject: customize/gutter breakage Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 09:28:08 -0400 Message-ID: Lines: 4 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I tried to use customize/gutter to turn off the gutter. When I tried to set for current session, I got this error: Use `set-specifier' to change a specifier's value: bottom-gutter-visible-p From owner-xemacs-beta@xemacs.org Fri Jul 30 09:36:08 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA25615 for xemacs-beta-out; Fri, 30 Jul 1999 09:36:08 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25612 for ; Fri, 30 Jul 1999 09:36:06 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ACpS-000135-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 09:36:06 -0400 To: xemacs-beta@xemacs.org Subject: gutter causes core dumps! Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 09:36:06 -0400 Message-ID: Lines: 10 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I'm getting core dumps. The lisp traceback shows it's from update-tab-in-gutter. The error occurs here (I can't paste the whole trace because it seems the parent process running Konsole doesn't cut and paste properly :(. The gdb trace is useless. set-image-instance-property(# (#)Buffers 744x21 on # 0x0x848f2c8 0x1fda> :items (["*gdb-xemacs-21.2-b19*" (buffers-tab-switch-to-buffer "*gdb-xe macs-21.2-b19*")] ["*scratch*" (buffers-tab-switch-to-buffer "*scratch*")] ["*Hy per Apropos*" (buffers-tab-switch-to-buffer "*Hyper Apropos*")])) From owner-xemacs-beta@xemacs.org Fri Jul 30 09:49:41 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26004 for xemacs-beta-out; Fri, 30 Jul 1999 09:49:41 -0400 Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA25997; Fri, 30 Jul 1999 09:49:34 -0400 Received: from metheny.enst.fr (o6/Ix/71PCScrQe3H62ZgTZbQlWGRcBg@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id PAA23466; Fri, 30 Jul 1999 15:49:33 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id PAA03153; Fri, 30 Jul 1999 15:49:30 +0200 (MET DST) To: xemacs-patches@xemacs.org Cc: XEmacs beta list Subject: [PATCH] protect symbols when writing 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 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: 56 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: OK, same places as before, plus another one. Must use prin1 instead of princ when outputting symbols, in order to protect special characters. I'm not going to apply it myself, since I'm off for one week in a few minutes. Please, another reviewer, do it if it's ok. 1999-07-30 Didier Verna * cus-edit.el (custom-save-variables): I said, use prin1 instead of princ to output symbols. (custom-save-face-internal): ditto. (custom-save-resets): ditto. Index: lisp/cus-edit.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/cus-edit.el,v retrieving revision 1.8.2.6 diff -u -u -r1.8.2.6 cus-edit.el --- cus-edit.el 1999/07/23 20:30:42 1.8.2.6 +++ cus-edit.el 1999/07/30 13:43:33 @@ -3280,7 +3280,7 @@ (when (or (and spec (eq (car spec) 'user) (eq (second spec) 'set)) comment) (princ "\n '(") - (princ symbol) + (prin1 symbol) (princ " ") ;; This comment stuf is in the way #### ;; Is (eq (third spec) (car saved-value)) ???? @@ -3313,7 +3313,7 @@ (eq (car theme-spec) 'user) (eq (second theme-spec) 'set)) comment) (princ "\n '(") - (princ symbol) + (prin1 symbol) (princ " ") (prin1 (get symbol 'saved-face)) (if (or comment now) @@ -3358,7 +3358,7 @@ (princ "(") (princ (quote ,setter)) (princ "\n '(") - (princ object) + (prin1 object) (princ " ") (prin1 (third spec)) (princ ")"))))))) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 09:54:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26192 for xemacs-beta-out; Fri, 30 Jul 1999 09:54:26 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id JAA26189 for ; Fri, 30 Jul 1999 09:54:25 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11AD7A-00013l-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 09:54:24 -0400 To: xemacs-beta@xemacs.org Subject: etc/custom/theme-examples? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 09:54:24 -0400 Message-ID: Lines: 4 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: According to CHANGES-beta: -- Custom themes, API part. See etc/custom/theme-examples from Jan Vroonhof I don't have any etc/custom-theme-anything From owner-xemacs-beta@xemacs.org Fri Jul 30 09:54:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA26203 for xemacs-beta-out; Fri, 30 Jul 1999 09:54:51 -0400 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 JAA26197 for ; Fri, 30 Jul 1999 09:54:49 -0400 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 KAA19954 for ; Fri, 30 Jul 1999 10:00:47 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id PAA16644; Fri, 30 Jul 1999 15:54:41 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: makeinfo fails on 21.2b19 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: 30 Jul 1999 15:54:03 +0200 In-Reply-To: nbecker@fred.net's message of "30 Jul 1999 09:19:45 -0400" Message-ID: Lines: 32 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "nbecker" == nbecker writes: nbecker> ./internals.texi:130: Menu reference to nonexistent node nbecker> `Faces and Glyphs'. Hello Neal, are you sure your internals.texi is the version which comes with 21.2-b19? I buillt 21.2-b19 today, including info, and had no errors. I use the XEmacs package `texinfo' to build the info files since I build natively under Windows NT. The support for `nmake /f xemacs.mak info` just made it into xemacs.mak in 21.2-b19. Regards, Adrian nbecker> ./internals.texi:7878: warning: unreferenced node nbecker> `Widget-Glyphs in the MS-WIndows Environment'. nbecker> ./internals.texi:7883: warning: unreferenced node nbecker> `Widget-Glyphs in the X Environment'. nbecker> makeinfo: Removing output file nbecker> `../../info/internals.info' due to errors; use --force to nbecker> preserve. nbecker> make[2]: *** [../../info/internals.info] Error 2 From owner-xemacs-beta@xemacs.org Fri Jul 30 10:10:47 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA26704 for xemacs-beta-out; Fri, 30 Jul 1999 10:10:47 -0400 Received: from mail.rdc1.on.home.com (ha1.rdc1.on.wave.home.com [24.2.9.66]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA26701 for ; Fri, 30 Jul 1999 10:10:44 -0400 Received: from LUCY ([24.65.44.84]) by mail.rdc1.on.home.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <19990730141041.BLTK17863.mail.rdc1.on.home.com@LUCY> for ; Fri, 30 Jul 1999 07:10:41 -0700 To: XEmacs Developers Subject: Re: backward-word: WTF? References: <87oggvge4h.fsf@pc-hrvoje.srce.hr> In-Reply-To: Hrvoje Niksic's message of "30 Jul 1999 02:44:46 +0200" From: Dmitry Yaitskov Organization: Just me at home Date: 30 Jul 1999 10:10:41 -0400 Message-ID: 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: Hrvoje Niksic wrote: > You won't believe this one. Start up `xemacs -vanilla', type "a b" > (no quotes) into *scratch*, then press `M-b'. For me the point ends > up at the beginning of line instead of at the beginning of "b". > > Somebody seriously fucked up scan_words(), which a potential to damage > XEmacs seriously. The `#ifdef MULE' code looks especially suspicious > (I still run with Mule). Please be more careful when changing code. > Just for the record - On XEmacs 21.2 (beta19) under NT, no Mule, works correctly. -- Cheers, -Dima. From owner-xemacs-beta@xemacs.org Fri Jul 30 10:22:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27279 for xemacs-beta-out; Fri, 30 Jul 1999 10:22:24 -0400 Received: from dreams. (ns.hanyon.co.kr [203.231.147.1]) by gwyn.tux.org (8.9.1/8.9.1) with SMTP id KAA27269; Fri, 30 Jul 1999 10:22:19 -0400 From: secure@deal.zzn.com Received: from bulkserver by dreams. (SMI-8.6/SMI-SVR4) id WAA07590; Fri, 30 Jul 1999 22:07:13 +0900 Date: Fri, 30 Jul 1999 22:07:13 +0900 Message-Id: <199907301307.WAA07590@dreams.> To: secure@deal.zzn.com Subject: Stuff Your Mailbox With $600 Checks... Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Inc. 500 environmental company has grown 5,000% in last 24 months! We need NEW dealers, company will train at home. Automatic marketing system in place, no selling. Earn $12,000 in just 120 days! Contact Dr. Steve Roti at 1-888-889-0908 From owner-xemacs-beta@xemacs.org Fri Jul 30 10:22:52 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27294 for xemacs-beta-out; Fri, 30 Jul 1999 10:22:52 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27291 for ; Fri, 30 Jul 1999 10:22:52 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ADYh-00015L-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 10:22:51 -0400 To: xemacs-beta@xemacs.org Subject: another core dump Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 10:22:07 -0400 Message-ID: Lines: 8 Original-Sender: X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: 21.2.b19 another core dump: #0 0x4041155c in chunk_free (ar_ptr=0x8589fffc, p=0x404a1104) at malloc.c:2960 #1 0x40411505 in __libc_free (mem=0x404a110c) at malloc.c:2932 #2 0x805577c in xfree (block=0x404a110c) at /usr/local/src/xemacs-21/src/alloc.c:318 #3 0x8134b87 in x_finalize_image_instance (p=0x87c9b00) at /usr/local/src/xemacs-21/src/glyphs-x.c:424 #4 0x80cf330 in finalize_image_instance (header=0x87c9b00, for_disksave=0) at /usr/local/src/xemacs-21/src/glyphs.c:816 [...] From owner-xemacs-beta@xemacs.org Fri Jul 30 10:25:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27369 for xemacs-beta-out; Fri, 30 Jul 1999 10:25:51 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27366 for ; Fri, 30 Jul 1999 10:25:49 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ADao-00015P-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 10:25:02 -0400 To: xemacs-beta@xemacs.org Subject: core dump Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 From: nbecker@fred.net Date: 30 Jul 1999 10:25:01 -0400 Message-ID: Lines: 197 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA27367 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Another core dump. This time a more complete trace: Note: I have NEVER had any core dumps with any betas before 19. Program received signal SIGSEGV, Segmentation fault. __libc_free (mem=0x110) at malloc.c:2914 malloc.c:2914: No such file or directory. (gdb) where #0 __libc_free (mem=0x110) at malloc.c:2914 #1 0x805577c in xfree (block=0x110) at /usr/local/src/xemacs-21/src/alloc.c:318 #2 0x8134b87 in x_finalize_image_instance (p=0x85167a8) at /usr/local/src/xemacs-21/src/glyphs-x.c:424 #3 0x80cf330 in finalize_image_instance (header=0x85167a8, for_disksave=0) at /usr/local/src/xemacs-21/src/glyphs.c:816 #4 0x80529f2 in sweep_lcrecords_1 (prev=0x81924d0, used=0xbfffec78) at /usr/local/src/xemacs-21/src/alloc.c:2569 #5 0x8053779 in gc_sweep () at /usr/local/src/xemacs-21/src/alloc.c:3159 #6 0x8053fd9 in garbage_collect_1 () at /usr/local/src/xemacs-21/src/alloc.c:3476 #7 0x807e439 in Ffuncall (nargs=4, args=0xbfffed40) at /usr/local/src/xemacs-21/src/eval.c:3135 #8 0x805ccdb in execute_optimized_program ( program=0x8626e24 "\212\214\b\t}\210\n«\004à \210eb\210ÄÅ\016\006ÇÈÅ\016\006Ç°\aÉÊ#«\nËÌ!\210eb\210ªçÉ\211\211\036\r\036\016\036\017Ä\016\006ÉÊ#­\024ÐÑ\224Ñ\225{Ñ\224Ñ\225|\210\016\022\"c\210ªæ-\20759", stack_depth=8, constants_data=0x860b8b0) at /usr/local/src/xemacs-21/src/bytecode.c:747 #9 0x805c976 in funcall_compiled_function (fun=140556548, nargs=4, args=0xbfffee40) at /usr/local/src/xemacs-21/src/bytecode.c:520 #10 0x807e802 in Ffuncall (nargs=5, args=0xbfffee3c) at /usr/local/src/xemacs-21/src/eval.c:3221 #11 0x805ccdb in execute_optimized_program ( program=0x882858c "eb\210ÀÁÂÃ#«&eb\210ÀÄÂÃ#­!ÅÆ\224Æ\225ÇÈ$\210ÀÉÂÃ#«êÅÊ\224Ê\225ÇÈ$\210ªßÅedÃ#\207", stack_depth=5, constants_data=0x882bd48) at /usr/local/src/xemacs-21/src/bytecode.c:747 #12 0x805c976 in funcall_compiled_function (fun=142788424, nargs=0, args=0xbffff0ac) at /usr/local/src/xemacs-21/src/bytecode.c:520 #13 0x807e802 in Ffuncall (nargs=1, args=0xbffff0a8) at /usr/local/src/xemacs-21/src/eval.c:3221 #14 0x807f04f in run_hook_with_args_in_buffer (buf=0x85fbb40, nargs=1, args=0xbffff0a8, cond=RUN_HOOKS_TO_COMPLETION) at /usr/local/src/xemacs-21/src/eval.c:3671 #15 0x80815da in run_hook_with_args (nargs=1, args=0xbffff0a8, cond=RUN_HOOKS_TO_COMPLETION) at /usr/local/src/xemacs-21/src/eval.c:3684 #16 0x8082ff0 in Frun_hooks (nargs=1, args=0xbffff0a8) at /usr/local/src/xemacs-21/src/eval.c:3539 #17 0x807e7b0 in Ffuncall (nargs=2, args=0xbffff0a4) at /usr/local/src/xemacs-21/src/eval.c:3206 #18 0x807eb1c in Fapply (nargs=2, args=0xbffff0a4) at /usr/local/src/xemacs-21/src/eval.c:3399 #19 0x807e7b0 in Ffuncall (nargs=3, args=0xbffff0a0) at /usr/local/src/xemacs-21/src/eval.c:3206 #20 0x805ccdb in execute_optimized_program ( program=0x85fd7dc "p\030Á\216ÂÃ\f\"*\207\022@(", stack_depth=3, constants_data=0x8603b78) at /usr/local/src/xemacs-21/src/bytecode.c:747 #21 0x805c976 in funcall_compiled_function (fun=140575564, nargs=1, args=0xbffff18c) at /usr/local/src/xemacs-21/src/bytecode.c:520 #22 0x807e802 in Ffuncall (nargs=2, args=0xbffff188) at /usr/local/src/xemacs-21/src/eval.c:3221 #23 0x805ccdb in execute_optimized_program ( program=0x8742a0c "À\021\n\013®\002\fÅ\211\211\036\006\036\a\036\b\e\036\t\212\nq\210ÊË!\210eb\210m¬\013ÅÌÍ\217\210Îy\210ªô\016\017«\005\016\020¬\006\016\a\237ª\023Ñ\036\022\016\a\237Ó\016\020\016\024\"­\003Õ ¤).\006\207", stack_depth=5, constants_data=0x8732c80) at /usr/local/src/xemacs-21/src/bytecode.c:747 #24 0x805c976 in funcall_compiled_function (fun=142121276, nargs=5, args=0xbffff27c) at /usr/local/src/xemacs-21/src/bytecode.c:520 #25 0x807e802 in Ffuncall (nargs=6, args=0xbffff278) at /usr/local/src/xemacs-21/src/eval.c:3221 #26 0x805ccdb in execute_optimized_program ( program=0x873c4ac "À\t\n\"J\eÄ\t!@Åa«\004ƪ\003\016\a\036\aÈ\0138\036\tÊ\036\013Ê\036\fÊ\036\rÎÄ\t!\211\026\017!¬\005ÐÑ!\210\013«\a\013@Æa«\030Ò\t!¬\023\016\023Ôk«\005Õp!\210ÐÖ\t×\t!#\210Ø\tÆ\"¬\023\016\023Ôk«\005Õp!\210ÐÖ\t×\t!#\210\t\026\031Ê\026\032Û\t!\026\034\016\t«\006Ý\016\t!\210Þ\t!«\005\016\037\026\rà\211\016\034\016!\"\016\"\"\026\034Ê\026#ä\t\016\034\"\210\016%\211\026\013«\017æ\016\034ç\016\034\016\013\"\"\026\032ª\bè\t\016)\"\026\013\016\013¬\005ê\202Ô", stack_depth=6, constants_data=0x875b570) at /usr/local/src/xemacs-21/src/bytecode.c:747 #27 0x805c976 in funcall_compiled_function (fun=142272828, nargs=3, args=0xbffff370) at /usr/local/src/xemacs-21/src/bytecode.c:520 #28 0x807e802 in Ffuncall (nargs=4, args=0xbffff36c) at /usr/local/src/xemacs-21/src/eval.c:3221 #29 0x805ccdb in execute_optimized_program ( program=0x85916ac "À\t!¬\fÂ\t\013\"J¬\005ÄÅ!\210ÆÇÈ\t#\210É\t!\036\nË\t!\036\f\016\n­\bÍ\t\016\016\016\017#\036\020\016\n¬!Ñ \210\016\022«\006Ó\016\022!\210ÔÕÖ\"\210×Õ!\210Ø \210ÙÚ!\210Û\202¾\001\016\020¬4\016\034Ýa«%p\016\022k¬\037Òp!\210\016\f¬\022Þ \210\016\037q\210à\t!\210áâ!\210ª\006ã\016\f!\210Æäå\"\210æ\202\207\001\016\020ça«=\016\034Ýa«\013p\016\022k¬\005Òp!\210\016\022«\006Ó\016\022!\210\016\f¬\024\016\037q\210à\t!\210áâ!\210ÔÁÖ\"\210ª\006ã\016\f!\210èçæ\"\202"..., stack_depth=5, constants_data=0x87b0458) at /usr/local/src/xemacs-21/src/bytecode.c:747 #30 0x805c976 in funcall_compiled_function (fun=142271260, nargs=6, args=0xbffff460) at /usr/local/src/xemacs-21/src/bytecode.c:520 #31 0x807e802 in Ffuncall (nargs=7, args=0xbffff45c) at /usr/local/src/xemacs-21/src/eval.c:3221 #32 0x805ccdb in execute_optimized_program ( program=0x87d0b24 "À\031\n«?À\eÄ\n\r\016\006\016\a\016\b\016\t&\006®\aÀ\025À\211\026\t)\211\021¬#\013Êa«\036\016\013q\210\016\f«\005ÍÎ!\210\nÏ k¬\aÏ \211\022ªÆÀ\211\022¬Ã\t)\207", stack_depth=8, constants_data=0x87afbe8) at /usr/local/src/xemacs-21/src/bytecode.c:747 #33 0x805c976 in funcall_compiled_function (fun=142271204, nargs=7, args=0xbffff55c) at /usr/local/src/xemacs-21/src/bytecode.c:520 #34 0x807e802 in Ffuncall (nargs=8, args=0xbffff558) at /usr/local/src/xemacs-21/src/eval.c:3221 #35 0x805ccdb in execute_optimized_program ( program=0x869710c "\bÁa\n®\003à Ä\211\211\211\035\036\006\036\a\036\b\032\036\t\bÁa«\003Ä\020\n¬\005ÊË!\210ÌÍÎ\n\016\017\"J\211\02588\026\006\b§«\004\bª\e\r«\005\r@ª\024Î\n\016\020\"J\211\026\a­\t\016\aAT\016\a@Z\026\bÑ\n\b®\032\016\b§­\025\016\bÒÓ\016\006·A!\\ÒÔ\016\006·A!\\ÁU\016\025Ä\016\tÄ\016\026&\a.\006\207y", stack_depth=8, constants_data=0x86fbb28) at /usr/local/src/xemacs-21/src/bytecode.c:747 #36 0x805c976 in funcall_compiled_function (fun=141527404, nargs=2, args=0xbffff658) at /usr/local/src/xemacs-21/src/bytecode.c:520 #37 0x807e802 in Ffuncall (nargs=3, args=0xbffff654) at /usr/local/src/xemacs-21/src/eval.c:3221 #38 0x805ccdb in execute_optimized_program (program=0x855d80c "À\tÂ\"\207", stack_depth=3, constants_data=0x86fbb98) at /usr/local/src/xemacs-21/src/bytecode.c:747 #39 0x805c976 in funcall_compiled_function (fun=141527432, nargs=1, args=0xbffff744) at /usr/local/src/xemacs-21/src/bytecode.c:520 #40 0x807e802 in Ffuncall (nargs=2, args=0xbffff740) at /usr/local/src/xemacs-21/src/eval.c:3221 #41 0x8060df1 in Fcall_interactively (function=141385900, record_flag=136080596, keys=136080596) at /usr/local/src/xemacs-21/src/callint.c:949 #42 0x807d614 in Fcommand_execute (cmd=141385900, record=136080596, keys=136080596) at /usr/local/src/xemacs-21/src/eval.c:2623 #43 0x80a1577 in execute_command_event (command_builder=0x822a1b0, event=140188748) at /usr/local/src/xemacs-21/src/event-stream.c:4345 #44 0x80a1af9 in Fdispatch_event (event=140188748) at /usr/local/src/xemacs-21/src/event-stream.c:4684 #45 0x8064a2b in Fcommand_loop_1 () at /usr/local/src/xemacs-21/src/cmdloop.c:578 #46 0x8064c46 in command_loop_1 (dummy=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:493 #47 0x808226b in condition_case_1 (handlers=136080692, bfun=0x8064c30 , barg=136080596, hfun=0x8064ca0 , harg=136080596) at /usr/local/src/xemacs-21/src/eval.c:1640 #48 0x8064d82 in command_loop_2 (dummy=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:255 #49 0x8082140 in internal_catch (tag=136154620, func=0x8064d50 , arg=136080596, threw=0x0) at /usr/local/src/xemacs-21/src/eval.c:1315 #50 0x806474c in initial_command_loop (load_me=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:304 #51 0x8079668 in xemacs_21_2_b19_i686_pc_linux () at /usr/local/src/xemacs-21/src/emacs.c:1763 #52 0x8079d2f in main () at /usr/local/src/xemacs-21/src/emacs.c:2188 #53 0x403d0cb3 in __libc_start_main (main=0x8079c30
, argc=1, argv=0xbffffc04, init=0x804e634 <_init>, fini=0x815b804 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffbfc) at ../sysdeps/generic/libc-start.c:78 (gdb) From owner-xemacs-beta@xemacs.org Fri Jul 30 10:36:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27596 for xemacs-beta-out; Fri, 30 Jul 1999 10:36:26 -0400 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 KAA27593 for ; Fri, 30 Jul 1999 10:36:24 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id HAA12605; Fri, 30 Jul 1999 07:36:03 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-216.beasys.com [192.168.11.216]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id HAA06529; Fri, 30 Jul 1999 07:36:00 -0700 (PDT) Message-Id: <3.0.5.32.19990730153625.00ad1b70@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 15:36:25 +0100 To: nbecker@fred.net, xemacs-beta@xemacs.org From: Andy Piper Subject: Re: tab widgets/gutter serious redisplay problem 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 09:26 AM 7/30/99 -0400, nbecker@fred.net wrote: >21.2.19 > >The tab widgets are being redrawn like crazy under some conditions. >It's awful. This is under X? i.e. 21.2.19+ rather than vanilla 21.2.19? >For example, lots of scrolling output from shell mode in window 2 is >causing the tab widgets to flash like crazy. Yeah there is a bug in the exposure ignore code which I'm just about to apply a fix for. Let me know if this doesn't cure it. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 10:36:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27614 for xemacs-beta-out; Fri, 30 Jul 1999 10:36:55 -0400 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 KAA27611 for ; Fri, 30 Jul 1999 10:36:53 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id HAA12669; Fri, 30 Jul 1999 07:36:36 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-216.beasys.com [192.168.11.216]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id HAA06719; Fri, 30 Jul 1999 07:36:34 -0700 (PDT) Message-Id: <3.0.5.32.19990730153705.00aaf100@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 15:37:05 +0100 To: nbecker@fred.net, xemacs-beta@xemacs.org From: Andy Piper Subject: Re: gutter causes core dumps! 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 09:36 AM 7/30/99 -0400, nbecker@fred.net wrote: >I'm getting core dumps. The lisp traceback shows it's from >update-tab-in-gutter. The error occurs here (I can't paste the whole >trace because it seems the parent process running Konsole doesn't cut >and paste properly :(. The gdb trace is useless. > > set-image-instance-property(#0x1b6b> (#)Buffers 744x21 on # 0x0x848f2c8 > 0x1fda> :items (["*gdb-xemacs-21.2-b19*" (buffers-tab-switch-to-buffer "*gdb-xe >macs-21.2-b19*")] ["*scratch*" (buffers-tab-switch-to-buffer "*scratch*")] ["*Hy >per Apropos*" (buffers-tab-switch-to-buffer "*Hyper Apropos*")])) I'm guessing this is a bug in the Tab widget. I've had to fix one core dumping bug already. I suggest you back-up to vanilla 21.2.19. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 10:37:10 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27625 for xemacs-beta-out; Fri, 30 Jul 1999 10:37:10 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27621 for ; Fri, 30 Jul 1999 10:37:08 -0400 Received: from megalith.bp.aventail.com (usrpri2-64.kiva.net [206.97.75.129]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id HAA28121; Fri, 30 Jul 1999 07:35:46 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id JAA03374; Fri, 30 Jul 1999 09:36:46 -0500 To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: tab widgets/gutter serious redisplay problem References: Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 20 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) 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: nbecker@fred.net writes: > 21.2.19 > > The tab widgets are being redrawn like crazy under some conditions. > It's awful. > > For example, lots of scrolling output from shell mode in window 2 is > causing the tab widgets to flash like crazy. > > Not sure yet precisely how to reproduce it - but I've seen it several > times after just seconds of use - so it's not too hard. Ditto here. Also the gutter tends to not get drawn at all when it is not flashing crazily. To repro here (linux, XFree86, WindowMaker 0.60) all I have to do is hit 'C-l' to refresh the screen and the tabs disappear. It comes back if I split the window (C-x 2 or 3), but disappears again as soon as I hit C-l -Bill P. From owner-xemacs-beta@xemacs.org Fri Jul 30 10:38:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27683 for xemacs-beta-out; Fri, 30 Jul 1999 10:38:17 -0400 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 KAA27680 for ; Fri, 30 Jul 1999 10:38:14 -0400 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 KAA23758 for ; Fri, 30 Jul 1999 10:44:01 -0400 (EDT) Received: from ZJ75T.ecf.teradyne.com (zj75t2.ecf.teradyne.com [131.101.192.70]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with SMTP id QAA16826; Fri, 30 Jul 1999 16:37:55 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: customize/gutter breakage 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: 30 Jul 1999 16:37:17 +0200 In-Reply-To: nbecker@fred.net's message of "30 Jul 1999 09:28:08 -0400" Message-ID: Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "nbecker" == nbecker writes: nbecker> I tried to use customize/gutter to turn off the gutter. nbecker> When I tried to set for current session, I got this nbecker> error: nbecker> Use `set-specifier' to change a specifier's value: nbecker> bottom-gutter-visible-p Yep, I get the same and here's the Backtrace: Signaling: (error "Use `set-specifier' to change a specifier's value" default-gutter-visible-p) set-default(default-gutter-visible-p nil) funcall(set-default default-gutter-visible-p nil) (cond ((eq state ...) (error "Cannot set hidden variable")) ((setq val ...) (goto-char ...) (error "%s" ...)) ((memq form ...) (when ... ... ...) (funcall set symbol ...) (put symbol ... ...) (put symbol ... comment) (put symbol ... comment)) (t (when ... ... ...) (funcall set symbol ...) (put symbol ... ...) (put symbol ... comment) (put symbol ... comment))) ) (let* ((form ...) (state ...) (child ...) (symbol ...) (set ...) (comment-widget ...) (comment ...) val) (cond (... ...) (... ... ...) (... ... ... ... ... ...) (t ... ... ... ... ...)) (custom-variable-state-set widget) (custom-redraw-magic widget)) ) widget-button1-click(#) call-interactively(widget-button1-click) From owner-xemacs-beta@xemacs.org Fri Jul 30 10:40:24 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27762 for xemacs-beta-out; Fri, 30 Jul 1999 10:40:24 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27759 for ; Fri, 30 Jul 1999 10:40:22 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ADpd-00016A-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 10:40:21 -0400 To: xemacs-beta@xemacs.org Subject: another dump in 21.2.19 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 From: nbecker@fred.net Date: 30 Jul 1999 10:40:21 -0400 Message-ID: Lines: 72 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA27760 Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Program received signal SIGSEGV, Segmentation fault. 0x805cb40 in execute_optimized_program ( program=0x86d4f84 "\b­\003Á \032\013\b«\004\n¬\004\fª\eÅ\nÆÇ#\022ÈÉÊ\n!\"\022\bËa«\b\016\fÍ\nEª\002\nL\210)\b¬\tÎÏ!\210ÐÑ!\210Ò \207", stack_depth=5, constants_data=0x821c050) at /usr/local/src/xemacs-21/src/bytecode.c:672 (gdb) where #0 0x805cb40 in execute_optimized_program ( program=0x86d4f84 "\b­\003Á \032\013\b«\004\n¬\004\fª\eÅ\nÆÇ#\022ÈÉÊ\n!\"\022\bËa«\b\016\fÍ\nEª\002\nL\210)\b¬\tÎÏ!\210ÐÑ!\210Ò \207", stack_depth=5, constants_data=0x821c050) at /usr/local/src/xemacs-21/src/bytecode.c:672 #1 0x805c976 in funcall_compiled_function (fun=139327004, nargs=0, args=0xbffff7ac) at /usr/local/src/xemacs-21/src/bytecode.c:520 #2 0x807e802 in Ffuncall (nargs=1, args=0xbffff7a8) at /usr/local/src/xemacs-21/src/eval.c:3221 #3 0x807f04f in run_hook_with_args_in_buffer (buf=0x847e308, nargs=1, args=0xbffff7a8, cond=RUN_HOOKS_TO_COMPLETION) at /usr/local/src/xemacs-21/src/eval.c:3671 #4 0x80815da in run_hook_with_args (nargs=1, args=0xbffff7a8, cond=RUN_HOOKS_TO_COMPLETION) at /usr/local/src/xemacs-21/src/eval.c:3684 #5 0x80831f1 in catch_them_squirmers_run_hook (hook_symbol=136170228) at /usr/local/src/xemacs-21/src/eval.c:3539 #6 0x807f90e in safe_run_hook_trapping_errors ( warning_string=0x8166120 "Error in `post-command-hook' (setting hook to nil)", hook_symbol=136170228, allow_quit=1) at /usr/local/src/xemacs-21/src/eval.c:1640 #7 0x80a327f in post_command_hook () at /usr/local/src/xemacs-21/src/event-stream.c:4429 #8 0x80a157f in execute_command_event (command_builder=0x822a1b0, event=139829536) at /usr/local/src/xemacs-21/src/event-stream.c:4348 #9 0x80a1af9 in Fdispatch_event (event=139829536) at /usr/local/src/xemacs-21/src/event-stream.c:4684 #10 0x8064a2b in Fcommand_loop_1 () at /usr/local/src/xemacs-21/src/cmdloop.c:578 #11 0x8064c46 in command_loop_1 (dummy=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:493 #12 0x808226b in condition_case_1 (handlers=136080692, bfun=0x8064c30 , barg=136080596, hfun=0x8064ca0 , harg=136080596) at /usr/local/src/xemacs-21/src/eval.c:1640 #13 0x8064d82 in command_loop_2 (dummy=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:255 #14 0x8082140 in internal_catch (tag=136154620, func=0x8064d50 , arg=136080596, threw=0x0) at /usr/local/src/xemacs-21/src/eval.c:1315 #15 0x806474c in initial_command_loop (load_me=136080596) at /usr/local/src/xemacs-21/src/cmdloop.c:304 #16 0x8079668 in xemacs_21_2_b19_i686_pc_linux () at /usr/local/src/xemacs-21/src/emacs.c:1763 #17 0x8079d2f in main () at /usr/local/src/xemacs-21/src/emacs.c:2188 #18 0x403d0cb3 in __libc_start_main (main=0x8079c30
, argc=1, argv=0xbffffc04, init=0x804e634 <_init>, fini=0x815b804 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffbfc) at ../sysdeps/generic/libc-start.c:78 From owner-xemacs-beta@xemacs.org Fri Jul 30 10:41:17 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id KAA27788 for xemacs-beta-out; Fri, 30 Jul 1999 10:41:17 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id KAA27785 for ; Fri, 30 Jul 1999 10:41:15 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11ADqU-00016G-00 for xemacs-beta@xemacs.org; Fri, 30 Jul 1999 10:41:14 -0400 To: xemacs-beta@xemacs.org Subject: another core dump Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 10:22:07 -0400 Message-ID: Lines: 8 Original-Sender: X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: 21.2.b19 another core dump: #0 0x4041155c in chunk_free (ar_ptr=0x8589fffc, p=0x404a1104) at malloc.c:2960 #1 0x40411505 in __libc_free (mem=0x404a110c) at malloc.c:2932 #2 0x805577c in xfree (block=0x404a110c) at /usr/local/src/xemacs-21/src/alloc.c:318 #3 0x8134b87 in x_finalize_image_instance (p=0x87c9b00) at /usr/local/src/xemacs-21/src/glyphs-x.c:424 #4 0x80cf330 in finalize_image_instance (header=0x87c9b00, for_disksave=0) at /usr/local/src/xemacs-21/src/glyphs.c:816 [...] From owner-xemacs-beta@xemacs.org Fri Jul 30 11:27:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA29871 for xemacs-beta-out; Fri, 30 Jul 1999 11:27:03 -0400 Received: from aurelius.ims.com (aurelius.ims.com [139.47.48.53]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA29864; Fri, 30 Jul 1999 11:26:36 -0400 Received: from plato.ims.com (plato.ims.com [139.47.5.95]) by aurelius.ims.com (8.9.0/8.9.0) with ESMTP id IAA02339; Fri, 30 Jul 1999 08:26:35 -0700 (PDT) Received: from jay (jay [139.47.5.61]) by plato.ims.com (8.9.1/8.9.1) with ESMTP id IAA14088; Fri, 30 Jul 1999 08:25:24 -0700 (PDT) Message-Id: <199907301525.IAA14088@plato.ims.com> To: SL Baur cc: xemacs-beta@xemacs.org Subject: Re: Merging with GNU Emacs In-reply-to: Your message of "30 Jul 1999 09:21:35 +0900." Date: Fri, 30 Jul 1999 08:24:45 -0700 From: Antonio Freixas Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: > Hrvoje Niksic writes in xemacs-beta@xemacs.org: > > > Pixel-based scrolling, which would require clipping the top-most line > > in addition to the bottom-most one, would be really cool. > > And pixel-based filling, so auto-filling works properly with variable > width fonts. Won't it take more than that to make auto-filling work properly? Since face information is not saved with a text file, the next person that views the variable-width auto-filled file won't necessarily get the same nice filling. It seems that to make this work, you have to define a word-processor mode. In this mode, carriage returns are stored only at the ends of paragraphs. Each paragraph would be auto-filled, using pixel resolution, each time a character was added or deleted or when a face changed. Each paragraph would also be refilled upon entering word processing mode. -- Antonio Freixas tonyf@ims.com (503) 626-5433 From owner-xemacs-beta@xemacs.org Fri Jul 30 11:23:29 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA29711 for xemacs-beta-out; Fri, 30 Jul 1999 11:23:29 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA29704; Fri, 30 Jul 1999 11:23:21 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11AEVE-0001HZ-00; Fri, 30 Jul 1999 11:23:20 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: gutter causes core dumps! References: <3.0.5.32.19990730153705.00aaf100@london.beasys.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 11:23:20 -0400 In-Reply-To: Andy Piper's message of "Fri, 30 Jul 1999 15:37:05 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> "Andy" == Andy Piper writes: Andy> At 09:36 AM 7/30/99 -0400, nbecker@fred.net wrote: Andy> I'm guessing this is a bug in the Tab widget. I've had to fix one core Andy> dumping bug already. I suggest you back-up to vanilla 21.2.19. I rebuilt with make clean first. Maybe it's stable now (not sure yet). What is the cvs tag to grab vanilla 21.2.19? From owner-xemacs-beta@xemacs.org Fri Jul 30 11:55:04 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id LAA31020 for xemacs-beta-out; Fri, 30 Jul 1999 11:55:04 -0400 Received: from mailhost2.telia-resellers.co.uk ([195.12.224.19]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id LAA31016 for ; Fri, 30 Jul 1999 11:55:02 -0400 Received: from lonexs1.telia.co.uk (unverified) by mailhost2.telia-resellers.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 30 Jul 1999 15:51:34 +0100 Received: by lonexs1.telia.co.uk with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jul 1999 15:55:01 +0100 Message-Id: From: Ian MacKinnon To: "'Xemacs Mailing List'" Subject: gutter problem Date: Fri, 30 Jul 1999 15:54:59 +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: Hi All, I am seeing a glitch with the gutter-items The tabs for deleted buffers don't want to go away ie visit a buffer, then delete that buffer, and the tab for it persists If I create a new frame, then the new frame is correct this is xemacs-21.2.19 on cygwin on NT --- Ian ************************************************************* 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 Jul 30 12:15:27 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA31659 for xemacs-beta-out; Fri, 30 Jul 1999 12:15:27 -0400 Received: from mark.nemr.net (mark.nemr.net [207.177.88.5]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA31655; Fri, 30 Jul 1999 12:15:25 -0400 Received: from liatris.local.net ([207.177.89.116]) by mark.nemr.net (Post.Office MTA v3.5.1 release 219 ID# 0-59387U6000L600S0V35) with ESMTP id net; Fri, 30 Jul 1999 11:15:15 -0500 Received: (from root@localhost) by liatris.local.net (8.8.8/8.8.5) id OAA20891; Fri, 30 Jul 1999 14:09:30 -0500 Date: Fri, 30 Jul 1999 14:09:30 -0500 Message-Id: <199907301909.OAA20891@liatris.local.net> From: Larry Ayers To: xemacs-build-reports@xemacs.org CC: xemacs-beta@xemacs.org Subject: [OK] 21.2 (beta19) "Shinjuku" XEmacs Lucid on i586-pc-linux Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Built from patched source, runs fine. I noticed that the gutter patches have been applied, and that there is a new menu-item (Options->Gutter Appearance). There is no visible gutter, though. Shouldn't there be? > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /box/xemacs-21.2-b14/Installation: > (Output from most recent run of ./configure) uname -a: Linux liatris 2.2.10 #1 Tue Jul 20 11:39:42 CDT 1999 i586 unknown ./configure '--prefix=/usr/local' '--with-site-lisp' '--with-xpm' '--with-tiff=no' '--with-dialogs=athena' '--error-checking=none' XEmacs 21.2-b19 "Shinjuku" configured for `i586-pc-linux'. Where should the build process find the source code? /box/xemacs-21.2-b14 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/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 native sound support. Compiling in support for Berkeley DB. 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 Motif 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. > Contents of /box/xemacs-21.2-b14/beta.err > keeping lines matching > "^--\[\[\|\]\]$\|make\[\|error\|warn\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compilation\|not\s-+found" > and then deleting lines matching > "confl.*with.*auto-inlining\|/box/xemacs-21\.2-b14/lisp/[^ ]+ hides " /box/xemacs-21.2-b14/lib-src/gnuserv.c:326: warning: `len' might be used uninitialized in this function /box/xemacs-21.2-b14/lib-src/etags.c:858: warning: `opt' might be used uninitialized in this function /box/xemacs-21.2-b14/lib-src/etags.c:1849: warning: array subscript has type `char' /box/xemacs-21.2-b14/lib-src/etags.c:1849: warning: array subscript has type `char' /box/xemacs-21.2-b14/lib-src/etags.c:1849: warning: array subscript has type `char' /box/xemacs-21.2-b14/lib-src/etags.c:1849: warning: array subscript has type `char' /box/xemacs-21.2-b14/lib-src/ootags.c:911: warning: `opt' might be used uninitialized in this function /box/xemacs-21.2-b14/lib-src/ootags.c:1912: warning: array subscript has type `char' /box/xemacs-21.2-b14/lib-src/ootags.c:1912: warning: array subscript has type `char' /box/xemacs-21.2-b14/src/config.h:36: warning: `alloca' redefined /usr/include/alloca.h:36: warning: this is the location of the previous definition bytecode.c:636: warning: `opcode' might be used uninitialized in this function callint.c:249: warning: `argcount' might be used uninitialized in this function callint.c:545: warning: `args' might be used uninitialized in this function callint.c:550: warning: `visargs' might be used uninitialized in this function callint.c:554: warning: `varies' might be used uninitialized in this function callint.c:555: warning: `arg_from_tty' might be used uninitialized in this function callint.c:556: warning: `argnum' might be used uninitialized in this function callint.c:571: warning: `prompt_start' might be used uninitialized in this function callint.c:572: warning: `prompt_limit' might be used uninitialized in this function callint.c:573: warning: `prompt_length' might be used uninitialized in this function callint.c:591: warning: `prompt_start' might be used uninitialized in this function callint.c:591: warning: `prompt_length' might be used uninitialized in this function callint.c:591: warning: `args' might be used uninitialized in this function callint.c:591: warning: `nargs' might be used uninitialized in this function callint.c:603: warning: `prompt_start' might be used uninitialized in this function callint.c:603: warning: `prompt_length' might be used uninitialized in this function callint.c:603: warning: `args' might be used uninitialized in this function callint.c:603: warning: `nargs' might be used uninitialized in this function callint.c:612: warning: `prompt_start' might be used uninitialized in this function callint.c:612: warning: `prompt_length' might be used uninitialized in this function callint.c:612: warning: `args' might be used uninitialized in this function callint.c:612: warning: `nargs' might be used uninitialized in this function callint.c:622: warning: `prompt_start' might be used uninitialized in this function callint.c:622: warning: `prompt_length' might be used uninitialized in this function callint.c:622: warning: `args' might be used uninitialized in this function callint.c:622: warning: `nargs' might be used uninitialized in this function callint.c:640: warning: `prompt_start' might be used uninitialized in this function callint.c:640: warning: `prompt_length' might be used uninitialized in this function callint.c:640: warning: `args' might be used uninitialized in this function callint.c:640: warning: `nargs' might be used uninitialized in this function callint.c:686: warning: `prompt_start' might be used uninitialized in this function callint.c:686: warning: `prompt_length' might be used uninitialized in this function callint.c:686: warning: `args' might be used uninitialized in this function callint.c:686: warning: `nargs' might be used uninitialized in this function callint.c:696: warning: `prompt_start' might be used uninitialized in this function callint.c:696: warning: `prompt_length' might be used uninitialized in this function callint.c:696: warning: `args' might be used uninitialized in this function callint.c:696: warning: `nargs' might be used uninitialized in this function callint.c:707: warning: `prompt_start' might be used uninitialized in this function callint.c:707: warning: `prompt_length' might be used uninitialized in this function callint.c:707: warning: `args' might be used uninitialized in this function callint.c:707: warning: `nargs' might be used uninitialized in this function callint.c:720: warning: `prompt_start' might be used uninitialized in this function callint.c:720: warning: `prompt_length' might be used uninitialized in this function callint.c:720: warning: `args' might be used uninitialized in this function callint.c:720: warning: `nargs' might be used uninitialized in this function callint.c:740: warning: `prompt_start' might be used uninitialized in this function callint.c:740: warning: `prompt_length' might be used uninitialized in this function callint.c:740: warning: `args' might be used uninitialized in this function callint.c:740: warning: `nargs' might be used uninitialized in this function callint.c:765: warning: `prompt_start' might be used uninitialized in this function callint.c:765: warning: `prompt_length' might be used uninitialized in this function callint.c:765: warning: `args' might be used uninitialized in this function callint.c:765: warning: `nargs' might be used uninitialized in this function callint.c:807: warning: `prompt_start' might be used uninitialized in this function callint.c:807: warning: `prompt_length' might be used uninitialized in this function callint.c:807: warning: `args' might be used uninitialized in this function callint.c:807: warning: `nargs' might be used uninitialized in this function callint.c:830: warning: `prompt_start' might be used uninitialized in this function callint.c:830: warning: `prompt_length' might be used uninitialized in this function callint.c:830: warning: `args' might be used uninitialized in this function callint.c:830: warning: `nargs' might be used uninitialized in this function callint.c:849: warning: `prompt_start' might be used uninitialized in this function callint.c:849: warning: `prompt_length' might be used uninitialized in this function callint.c:849: warning: `args' might be used uninitialized in this function callint.c:849: warning: `nargs' might be used uninitialized in this function callint.c:856: warning: `prompt_start' might be used uninitialized in this function callint.c:856: warning: `prompt_length' might be used uninitialized in this function callint.c:856: warning: `args' might be used uninitialized in this function callint.c:856: warning: `nargs' might be used uninitialized in this function callint.c:863: warning: `prompt_start' might be used uninitialized in this function callint.c:863: warning: `prompt_length' might be used uninitialized in this function callint.c:863: warning: `args' might be used uninitialized in this function callint.c:863: warning: `nargs' might be used uninitialized in this function editfns.c:1173: warning: `tzstring' might be used uninitialized in this function emacs.c:2196: warning: assignment from incompatible pointer type emacs.c:2255: warning: assignment from incompatible pointer type eval.c:2861: warning: `val' might be used uninitialized in this function eval.c:3127: warning: `val' might be used uninitialized in this function events.c:429: warning: `tail' might be used uninitialized in this function events.c:429: warning: `keyword' might be used uninitialized in this function events.c:546: warning: `modifiers' might be used uninitialized in this function event-tty.c:104: warning: `c' might be used uninitialized in this function redisplay-tty.c:329: warning: `instance' might be used uninitialized in this function extents.c:1822: warning: `start_open' might be used uninitialized in this function extents.c:1822: warning: `end_open' might be used uninitialized in this function extents.c:4378: warning: `fl' might be used uninitialized in this function extents.c:4390: warning: `at_flag' might be used uninitialized in this function extents.c:5010: warning: `layout' might be used uninitialized in this function fns.c:584: warning: `val' might be used uninitialized in this function fns.c:780: warning: `v' might be used uninitialized in this function frame.c:1571: warning: `ecran' might be used uninitialized in this function glyphs.c:326: warning: `typevec' might be used uninitialized in this function glyphs.c:1230: warning: `type' might be used uninitialized in this function glyphs.c:1267: warning: `type' might be used uninitialized in this function print.c:1091: warning: `i' might be used uninitialized in this function select.c:205: warning: `selection_data' might be used uninitialized in this function select.c:226: warning: `rest' might be used uninitialized in this function specifier.c:1643: warning: `tem' might be used uninitialized in this function specifier.c:1849: warning: `add_meth' might be used uninitialized in this function specifier.c:361: warning: `i' might be used uninitialized in this function symbols.c:309: warning: `tail' might be used uninitialized in this function symbols.c:1591: warning: `valcontents' might be used uninitialized in this function symbols.c:1984: warning: `valcontents' might be used uninitialized in this function symbols.c:2084: warning: `valcontents' might be used uninitialized in this function symbols.c:2131: warning: `bfwd' might be used uninitialized in this function symbols.c:2485: warning: `valcontents' might be used uninitialized in this function device-x.c: In function `x_IO_error_handler': device-x.c:112: warning: `d' might be used uninitialized in this function device-x.c:112: warning: `d' might be used uninitialized in this function glyphs-x.c:1154: warning: `dpy' might be used uninitialized in this function glyphs-x.c:1155: warning: `xs' might be used uninitialized in this function glyphs-x.c:1156: warning: `cmap' might be used uninitialized in this function glyphs-x.c:1157: warning: `depth' might be used uninitialized in this function glyphs-x.c:1158: warning: `visual' might be used uninitialized in this function glyphs-x.c:1162: warning: `result' might be used uninitialized in this function glyphs-x.c:1166: warning: `type' might be used uninitialized in this function glyphs-x.c:1167: warning: `force_mono' might be used uninitialized in this function glyphs-x.c:1209: warning: `type' might be used uninitialized in this function glyphs-x.c:1215: warning: `__s' might be used uninitialized in this function glyphs-x.c:1358: warning: `xs' might be used uninitialized in this function redisplay-x.c:451: warning: `instance' might be used uninitialized in this function window.c:438: warning: `retval' might be used uninitialized in this function window.c:438: warning: `retval' might be used uninitialized in this function window.c:438: warning: `retval' might be used uninitialized in this function window.c:4870: warning: `previous_minibuf_top' might be used uninitialized in this function window.c:407: warning: `retval' might be used uninitialized in this function Warning: doc lost for function make-char. /usr/local/lib/xemacs/site-lisp/pop3 hides /usr/local/lib/xemacs/packages/lisp/mail-lib/pop3 From owner-xemacs-beta@xemacs.org Fri Jul 30 12:25:49 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id MAA32117 for xemacs-beta-out; Fri, 30 Jul 1999 12:25:49 -0400 Received: from magoo.gshapiro.net (magoo.gshapiro.net [209.220.147.178]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id MAA32107; Fri, 30 Jul 1999 12:25:38 -0400 Received: (from gshapiro@localhost) by magoo.gshapiro.net (8.10.0.PreAlpha3/8.10.0.PreAlpha3) id d6UGPWW25221; Fri, 30 Jul 1999 09:25:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14241.53756.281709.415335@magoo.gshapiro.net> Date: Fri, 30 Jul 1999 09:25:32 -0700 (PDT) From: Gregory Neil Shapiro To: SL Baur Cc: xemacs-beta@xemacs.org Subject: Re: FYI mailcrypt-3.5.4 In-Reply-To: References: <99072708241200.11440@rpppc2.hns.com> X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >> http://freshmeat.net/news/1999/07/26/933042852.html sb> Server Error It's probably best to go right to the source: http://www.pobox.com/~lbudney/linux/software/mailcrypt.html From owner-xemacs-beta@xemacs.org Fri Jul 30 13:08:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id NAA01156 for xemacs-beta-out; Fri, 30 Jul 1999 13:08:19 -0400 Received: from e-fairy.jaist.ac.jp (e-fairy.jaist.ac.jp [150.65.185.91]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id NAA01150 for ; Fri, 30 Jul 1999 13:08:12 -0400 Received: from e-fairy.jaist.ac.jp (localhost.jaist.ac.jp [127.0.0.1]) by e-fairy.jaist.ac.jp (8.9.3+3.2W/3.7Wpl2/HOSHINO_RURI_LOVE) with ESMTP/IPv4 id CAA57960 for ; Sat, 31 Jul 1999 02:07:58 +0900 (JST) Date: Sat, 31 Jul 1999 02:07:44 +0900 Message-ID: <14241.56288.867659.87173S@e-fairy.jaist.ac.jp> From: KINOSHITA Masahiro To: xemacs-beta@xemacs.org Subject: [SUCCESS] XEmacs 21.2-b19 "Shinjuku" on FreeBSD User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.5 (=?ISO-2022-JP?B?GyRCTEBKdhsoQg==?=) FLIM/1.12.5 (=?ISO-2022-JP?B?GyRCSj9IKhsoQg==?=) MULE XEmacs/21.2 (beta19) (beta19) (=?ISO-2022-JP?B?GyRCPzc9SRsoQg==?=) (i386-unknown-freebsd3.2) Organization: =?ISO-2022-JP?B?GyRCS0xOJkBoQzwySjNYNTs9UUJnM1gxIUJnM1gbKEI=?= =?ISO-2022-JP?B?GyRCPnBKczJKM1g4JjVmMkobKEI=?= X-cite-me: =?ISO-2022-JP?B?GyRCJC0bKEI=?= X-URL: http://www.lapis-lazuli.nu./%7Ecue/ X-Public-Key-Info: http://www.lapis-lazuli.nu./%7Ecue/mypubkey.asc X-Fingerprint: 2F 6C 6B 9D E6 33 C3 39 A3 55 F8 B1 8F 20 25 E3 X-Key-Info: 1024bits, KeyID 0xEFD1E3A9, Created 1997-10-20, Algorithm RSA MIME-Version: 1.0 (generated by WEMI 1.13.4 - "=?ISO-2022-JP?B?GyRCQD4+RkRFGyhC?=") Content-Type: text/plain; charset=US-ASCII Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: % gcc -v gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) % uname -a FreeBSD **.jaist.ac.jp 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Wed Jul 28 15:20:14 JST 1999 m-kino@**.jaist.ac.jp:/var/v6/src/sys/compile/OMOIKANE i386 XEmacs 21.2-b19 "Shinjuku" configured for `i386-unknown-freebsd3.2'. Where should the build process find the source code? /home/fs361/m-kino/wor k/xemacs-21.2.19 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/freebsd.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O2 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/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib:/usr/X1 1R6/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 Mule (multi-lingual) 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 dialog boxes. Compiling in DSO module support. movemail will use "flock" 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 Jul 30 14:05:55 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA02861 for xemacs-beta-out; Fri, 30 Jul 1999 14:05:55 -0400 Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA02858; Fri, 30 Jul 1999 14:05:52 -0400 Received: from orihime.remus.dti.ne.jp (PPP22.tokyo-ap3.dti.ne.jp [210.170.144.22]) by smtp2.dti.ne.jp (8.9.3/3.7W) with ESMTP id DAA07731; Sat, 31 Jul 1999 03:05:42 +0900 (JST) From: Tsukamoto Tetsuo To: xemacs-beta@xemacs.org Cc: xemacs-beta-ja@xemacs.org Subject: Re: XEmacs 21.2.19 =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= is released References: X-Face-Version: X-Face utility v1.3.5.3 - "I Me Mine" with Select X-Face v0.10 - "Goodnight Tonight" 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 REMI 1.13.2 - =?ISO-8859-1?Q?=22=D2ike-Ikoin?= =?ISO-8859-1?Q?omori=22?=) Content-Type: text/plain; charset=US-ASCII Date: 31 Jul 1999 03:07:59 +0900 In-Reply-To: (SL Baur's message of "30 Jul 1999 15:11:07 +0900") Message-ID: User-Agent: ET-gnus/6.11.08 (based on Pterodactyl Gnus v0.95) (revision 04) REMI/1.13.2 (=?ISO-8859-1?Q?=D2ike-Ikoinomori?=) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-plamo-linux) Linux version 2.3.9 for NEC PC-9800 001pre Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Hi. >>>>> [30 Jul 1999 15:11:07 +0900] >>>>> SL Baur writes: > New XEmacs lisp packages have been uploaded as well. The new Sumos > are in: > ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz > ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz > Everything has been rebuilt & repackaged in order to fix an > installation bug. Many packages have been updated. VM is now > current, BBDB is now current to name two. When will the next XEmacs 21.1 come? I guess the new mule-base package will cause problems with 21.1.4. (set-language-environment calls set-japanese-environment, the latter calls the former, and .....) -- Tsukamoto, Tetsuo From owner-xemacs-beta@xemacs.org Fri Jul 30 14:16:21 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id OAA03207 for xemacs-beta-out; Fri, 30 Jul 1999 14:16:21 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id OAA03204; Fri, 30 Jul 1999 14:16:20 -0400 Received: from megalith.bp.aventail.com (usrpri2-64.kiva.net [206.97.75.129]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id LAA04218; Fri, 30 Jul 1999 11:14:57 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id NAA05201; Fri, 30 Jul 1999 13:15:57 -0500 To: xemacs-beta@xemacs.org cc: xemacs-patches@xemacs.org Subject: evil behaviour for enable-multibyte-characters Reply-to: wmperry@aventail.com X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 26 User-Agent: Gnus/5.070091 (Pterodactyl Gnus v0.91) 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 _HAS_ to be buffer-local if it is supposed to mimic the same variable under Emacs 20.x Without this, packages that (correctly) set enable-multibyte-characters can screw each other over. And individual applications should *NOT* have to make this buffer-local themselves. -bp Index: coding.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/coding.el,v retrieving revision 1.2.2.2 diff -c -w -r1.2.2.2 coding.el *** coding.el 1999/06/11 03:09:19 1.2.2.2 --- coding.el 1999/07/30 18:11:46 *************** *** 207,212 **** --- 207,213 ---- (copy-coding-system 'undecided 'automatic-conversion) (make-compatible-variable 'enable-multibyte-characters "Unimplemented") + (make-variable-buffer-local 'enable-multibyte-characters) (define-obsolete-variable-alias 'pathname-coding-system 'file-name-coding-system) From owner-xemacs-beta@xemacs.org Fri Jul 30 15:10:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA04888 for xemacs-beta-out; Fri, 30 Jul 1999 15:10:03 -0400 Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id PAA04882 for ; Fri, 30 Jul 1999 15:10:01 -0400 Received: from kaluha.cnri.reston.va.us (kaluha.cnri.reston.va.us [132.151.7.31]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id PAA07489 for ; Fri, 30 Jul 1999 15:09:53 -0400 (EDT) Received: from anthem.cnri.reston.va.us (anthem.cnri.reston.va.us [10.27.10.26]) by kaluha.cnri.reston.va.us (8.9.1b+Sun/8.9.1) with ESMTP id PAA25083 for ; Fri, 30 Jul 1999 15:09:59 -0400 (EDT) Received: (from bwarsaw@localhost) by anthem.cnri.reston.va.us (8.8.8+Sun/8.8.8) id PAA00851; Fri, 30 Jul 1999 15:09:58 -0400 (EDT) From: "Barry A. Warsaw" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14241.63621.963380.440319@anthem.cnri.reston.va.us> Date: Fri, 30 Jul 1999 15:09:57 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.2.19 =?ISO-2022-JP?B?IhskQj83PUkbKEIi?= is released References: X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) X-Attribution: BAW X-Oblique-Strategy: Humility of Intentions X-Url: http://www.python.org/~bwarsaw X-Face: bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass Content-Transfer-Encoding: 7bit Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: I just tried M-x pui-list-packages to do an update of my local packages and I got the message: Package-get PGP signature failed to verify ERROR: Header line added to ASCII armor: "Hash: SHA1" ERROR: Header line added to ASCII armor: "Hash: SHA1" Verifying... > g /anonymous@ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp...done > @ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp...97% (114.1 KB/s) > s@ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp...65% (80.7 KB/s) > s@ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp...31% (72.0 KB/s) > eving /anonymous@ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp... What am I doing wrong (this has worked for me before)? -Barry From owner-xemacs-beta@xemacs.org Fri Jul 30 15:12:44 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05000 for xemacs-beta-out; Fri, 30 Jul 1999 15:12:44 -0400 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 PAA04993 for ; Fri, 30 Jul 1999 15:12:40 -0400 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 PAA15678 for ; Fri, 30 Jul 1999 15:18:39 -0400 (EDT) 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 VAA21824; Fri, 30 Jul 1999 21:12:31 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Where is ps-print? 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: 30 Jul 1999 21:11:54 +0200 Message-ID: Lines: 9 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: During my update to all the latest packages I lost ps-print. I vaguely remember some discussions about it a while back. Where is ps-print? Thanks, Adrian From owner-xemacs-beta@xemacs.org Fri Jul 30 15:13:02 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05028 for xemacs-beta-out; Fri, 30 Jul 1999 15:13:02 -0400 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 PAA05020 for ; Fri, 30 Jul 1999 15:12:56 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA10083; Fri, 30 Jul 1999 12:12:39 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-88.beasys.com [192.168.11.88]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA17400; Fri, 30 Jul 1999 12:12:24 -0700 (PDT) Message-Id: <3.0.5.32.19990730201248.00aac9b0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 20:12:48 +0100 To: nbecker@fred.net, xemacs-beta@xemacs.org From: Andy Piper Subject: Re: another core dump 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: I'm now on a laptop-free holiday till wednesday. I'll take a look then. andy At 10:22 AM 7/30/99 -0400, nbecker@fred.net wrote: >21.2.b19 another core dump: >#0 0x4041155c in chunk_free (ar_ptr=0x8589fffc, p=0x404a1104) at malloc.c:2960 >#1 0x40411505 in __libc_free (mem=0x404a110c) at malloc.c:2932 >#2 0x805577c in xfree (block=0x404a110c) at /usr/local/src/xemacs-21/src/alloc.c:318 >#3 0x8134b87 in x_finalize_image_instance (p=0x87c9b00) at /usr/local/src/xemacs-21/src/glyphs-x.c:424 >#4 0x80cf330 in finalize_image_instance (header=0x87c9b00, for_disksave=0) > at /usr/local/src/xemacs-21/src/glyphs.c:816 >[...] > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 15:15:46 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05172 for xemacs-beta-out; Fri, 30 Jul 1999 15:15:46 -0400 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 PAA05167 for ; Fri, 30 Jul 1999 15:15:44 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA10243; Fri, 30 Jul 1999 12:15:27 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-88.beasys.com [192.168.11.88]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA19786; Fri, 30 Jul 1999 12:15:20 -0700 (PDT) Message-Id: <3.0.5.32.19990730201550.00969ab0@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 20:15:50 +0100 To: Ian MacKinnon , "'Xemacs Mailing List'" From: Andy Piper Subject: Re: gutter problem 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 03:54 PM 7/30/99 +0100, Ian MacKinnon wrote: >Hi All, >I am seeing a glitch with the gutter-items >The tabs for deleted buffers don't want to go away >ie visit a buffer, then delete that buffer, and the tab for it persists >If I create a new frame, then the new frame is correct > >this is xemacs-21.2.19 on cygwin on NT This is fixed in the latest CVS, but the latest CVS is causing many X problems. Windows may be ok. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 15:18:26 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA05274 for xemacs-beta-out; Fri, 30 Jul 1999 15:18:26 -0400 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 PAA05270 for ; Fri, 30 Jul 1999 15:18:24 -0400 Received: from san-jose.beasys.com (svlhome1.beasys.com [206.189.42.45]) by beamail.beasys.com (8.9.1a/8.9.1) with ESMTP id MAA10431 for ; Fri, 30 Jul 1999 12:18:04 -0700 (PDT) Received: from andyppc (hqvpn-192-168-11-88.beasys.com [192.168.11.88]) by san-jose.beasys.com (8.8.8+Sun/8.8.8) with SMTP id MAA21636 for ; Fri, 30 Jul 1999 12:17:54 -0700 (PDT) Message-Id: <3.0.5.32.19990730201821.00ad4220@london.beasys.com> X-Sender: andyp@london.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jul 1999 20:18:21 +0100 To: xemacs-beta@xemacs.org From: Andy Piper Subject: If you are experiencing gutter problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: .. then I advise using the 21.2.19 tag from CVS until I get back on wednesday and can take a look.... Builds from tarballs should be ok as that is vanilla 21.2.19 without the X tab support. got to go .... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd From owner-xemacs-beta@xemacs.org Fri Jul 30 16:10:03 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA07246 for xemacs-beta-out; Fri, 30 Jul 1999 16:10:03 -0400 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 QAA07243 for ; Fri, 30 Jul 1999 16:10:00 -0400 Received: by crystal.WonderWorks.COM id QQhadk16772; Fri, 30 Jul 1999 13:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14242.1685.361009.114116@crystal.WonderWorks.COM> Date: Fri, 30 Jul 1999 13:09:57 -0700 (PDT) From: Kyle Jones To: xemacs-beta@xemacs.org Subject: evil behaviour for enable-multibyte-characters In-Reply-To: <86lnbyhule.fsf@megalith.bp.aventail.com> References: <86lnbyhule.fsf@megalith.bp.aventail.com> X-Mailer: VM 6.73 under 21.2 (beta17) "Chiyoda" 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 we should drop this variable. It isn't implemented and really can't be implemented without hosing our MULE implementation in the same way the FSF Emacs is hosed. Is there anyone who wants this? From owner-xemacs-beta@xemacs.org Fri Jul 30 16:11:34 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA07294 for xemacs-beta-out; Fri, 30 Jul 1999 16:11:34 -0400 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 QAA07288 for ; Fri, 30 Jul 1999 16:11:31 -0400 Received: by crystal.WonderWorks.COM id QQhadk16905; Fri, 30 Jul 1999 13:11:30 -0700 (PDT) Received: from ulysse.enst.fr (inf.enst.fr [137.194.2.81]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id EAA17920 for ; Fri, 30 Jul 1999 04:25:55 -0400 Received: from metheny.enst.fr (kMd7xj/q3LvjG4XRqTO937ZOd3Be5UyM@metheny.enst.fr [137.194.204.4]) by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id KAA11496 for ; Fri, 30 Jul 1999 10:25:50 +0200 (MET DST) Received: (from verna@localhost) by metheny.enst.fr (8.8.8/8.8.8) id KAA21132; Fri, 30 Jul 1999 10:25:46 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: Recent XEmacs package building changes 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 "16 Jul 1999 17:56:50 +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: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) 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: > I have made some changes to the toplevel Makefile in xemacs-packages. > I have added support for loading an optional auxilliary file called > Local.rules, and have added `install' and `World' targets. A `make > install' will incrementally rebytecompile the specified packages and > install them somewhere. Actually, it seems that *all* packages are rebytecompiled, regardless of whether they appear in Local.rules. This causes problems for me since there are packages I don't want to install and I don't want to compile at all (they are checked out, however, since it's simpler to call `cvs co' only once, at the toplevel directory). Actually, since I never could checkout skk properly, the make process bombs out on this one and I have to modify the SUBDIRS variable of its Makefile by hand to remove it from the make process. Maybe it would be better if you compiled only the packages you want to install ? Unless you consider that Local.rules is there only for specifying different installations, not packages requirements. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna@inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19 From owner-xemacs-beta@xemacs.org Fri Jul 30 16:12:12 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA07316 for xemacs-beta-out; Fri, 30 Jul 1999 16:12:12 -0400 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 QAA07313 for ; Fri, 30 Jul 1999 16:12:10 -0400 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 QAA19851 for ; Fri, 30 Jul 1999 16:18:10 -0400 (EDT) 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 WAA21943; Fri, 30 Jul 1999 22:12:03 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Problems with ftp.xemacs.org & www.xemacs.org? 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: 30 Jul 1999 22:11:26 +0200 Message-ID: Lines: 10 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: Package downloads have been painfully slow an hung numerous times today in the timeframe of 16:00-18:00 MET DST. Got as low as 900B - 4KB/s transfer rates. Currently (21:00-22:00 MET DST) http://www.xemacs.org does not respond. http://cvs.xemacs.org is OK. Adrian From owner-xemacs-beta@xemacs.org Fri Jul 30 16:27:11 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA07925 for xemacs-beta-out; Fri, 30 Jul 1999 16:27:11 -0400 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 QAA07922 for ; Fri, 30 Jul 1999 16:27:07 -0400 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 QAA21036 for ; Fri, 30 Jul 1999 16:33:06 -0400 (EDT) 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 WAA22000; Fri, 30 Jul 1999 22:26:59 +0200 (MET DST) To: xemacs-beta@xemacs.org Subject: Re: Where is ps-print? 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: 30 Jul 1999 22:26:22 +0200 In-Reply-To: Adrian Aichner's message of "30 Jul 1999 21:11:54 +0200" Message-ID: Lines: 21 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: >>>>> "APA" == Adrian Aichner writes: APA> During my update to all the latest packages I lost ps-print. APA> I vaguely remember some discussions about it a while back. OK. I found the mail where Steven points to ftp://ftp.xemacs.org/pub/xemacs/beta/testing/ps-print-nomule-1.0-pkg.tar.gz but that file isn't any longer. Where can I get a non-mule ps-print? Regards, Adrian APA> Where is ps-print? APA> Thanks, APA> Adrian From owner-xemacs-beta@xemacs.org Fri Jul 30 16:41:59 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA08306 for xemacs-beta-out; Fri, 30 Jul 1999 16:41:59 -0400 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 QAA08303 for ; Fri, 30 Jul 1999 16:41:57 -0400 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 WAA12515 for ; Fri, 30 Jul 1999 22:41:49 +0200 (MET DST) Received: from decibel.fi.muni.cz (decibel.fi.muni.cz [147.251.51.14]) by anxur.fi.muni.cz (8.8.5/8.8.5) with ESMTP id WAA24975 for ; Fri, 30 Jul 1999 22:42:29 +0200 (MET DST) Received: from pekon by decibel.fi.muni.cz with local (Exim 3.02 #1 (Debian)) id 11AJTQ-0001Yj-00; Fri, 30 Jul 1999 22:41:48 +0200 To: xemacs-beta@xemacs.org Subject: Re: evil behaviour for enable-multibyte-characters References: <86lnbyhule.fsf@megalith.bp.aventail.com> X-URL: http://www.fi.muni.cz/~pekon/ From: Petr Konecny Date: 30 Jul 1999 22:41:47 +0200 In-Reply-To: wmperry@aventail.com's message of "30 Jul 1999 13:15:57 -0500" Message-ID: Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Toshima) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> William M. Perry (William) said: William> This _HAS_ to be buffer-local if it is supposed to mimic the William> same variable under Emacs 20.x William> Without this, packages that (correctly) set William> enable-multibyte-characters can screw each other over. And William> individual applications should *NOT* have to make this William> buffer-local themselves. Since it is compatibility variable, should not XEmacs provide also compatibility function for setting it ? It is set-buffer-multibyte in Emacs. Note, however, that some packages use setq-default to set it, and default-value to read its value. But I assume this is broken behaviour. Petr -- Ooh...I thought they smelled bad on the outside! -- Han Solo "Star Wars : The Empire Strikes Back" From owner-xemacs-beta@xemacs.org Fri Jul 30 16:48:13 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA08489 for xemacs-beta-out; Fri, 30 Jul 1999 16:48:13 -0400 Received: from rpppc2.hns.com ([139.85.108.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id QAA08486; Fri, 30 Jul 1999 16:48:10 -0400 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11AJZV-0001aq-00; Fri, 30 Jul 1999 16:48:05 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: another core dump References: <3.0.5.32.19990730201248.00aac9b0@london.beasys.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 30 Jul 1999 16:48:05 -0400 In-Reply-To: Andy Piper's message of "Fri, 30 Jul 1999 20:12:48 +0100" Message-ID: Lines: 2 X-Mailer: Gnus v5.6.45/XEmacs 21.2 - "Shinjuku" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: These dumps were 21.2.19+, as you said. I'm trying vanilla 21.2.19 now. From owner-xemacs-beta@xemacs.org Fri Jul 30 16:59:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id QAA08852 for xemacs-beta-out; Fri, 30 Jul 1999 16:59:14 -0400 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 QAA08849 for ; Fri, 30 Jul 1999 16:59:13 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.8.8/8.8.8) with ESMTP id NAA27043; Fri, 30 Jul 1999 13:57:51 -0700 (PDT) Message-Id: <199907302057.NAA27043@ptavv.es.net> To: Adrian Aichner cc: xemacs-beta@xemacs.org Subject: Re: Problems with ftp.xemacs.org & www.xemacs.org? In-reply-to: Your message of "30 Jul 1999 22:11:26 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 30 Jul 1999 13:57:51 -0700 From: "Kevin Oberman" Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Losses are quite high at the moment. Looks like MAE-East may be the problem. It frequently is. I'm seeing about 20% loss to the site (gwyn.tux.org) and to the first hop past MAE-East. MAE-East is the primary Atlantic coast network meet point. This is enough to bring TCP to a crawl. Unfortunately, there is little that can be done to fix it except to route around it. I just don't know of any other place to get to their carrier, rcn, at this time. The ftp and www sites are really the same place. cvs is an entirely separate system at a different location. 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 Fri Jul 30 17:38:53 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA10291 for xemacs-beta-out; Fri, 30 Jul 1999 17:38:53 -0400 Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.10.126]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA10274; Fri, 30 Jul 1999 17:38:32 -0400 Received: from localhost.icd.teradyne.com (localhost.icd.teradyne.com) by ICD.Teradyne.COM (8.8.5/8.8.5) with SMTP id RAA13496; Fri, 30 Jul 1999 17:31:55 -0400 (EDT) Received: by dusk1.afive (SMI-8.6/SMI-SVR4) id RAA14897; Fri, 30 Jul 1999 17:37:39 -0400 To: Tsukamoto Tetsuo Cc: xemacs-beta@xemacs.org, xemacs-beta-ja@xemacs.org Subject: Re: XEmacs 21.2.19 "$B?7=I(B" is released From: Vin Shelton Organization: The XEmacs Development Team References: Date: 30 Jul 1999 17:37:38 -0400 In-Reply-To: Tsukamoto Tetsuo's message of "31 Jul 1999 03:07:59 +0900" Message-ID: <545wvvhddjx.fsf@dusk1.icd.teradyne.com> Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: >>>>> On 31 Jul 1999, Tsukamoto Tetsuo said: Tsukamoto> When will the next XEmacs 21.1 come? Tsukamoto> I guess the new mule-base package will cause problems with 21.1.4. I currently have only a handful of fixes to apply for 21.1.5. I'm going off for a one-week vacation starting tomorrow, so 21.1.5 will probably not occur until the middle of the following week, say 8/10 or 8/11. - vin -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot From owner-xemacs-beta@xemacs.org Fri Jul 30 18:29:16 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id SAA12374 for xemacs-beta-out; Fri, 30 Jul 1999 18:29:16 -0400 Received: from newman.aventail.com (newman.aventail.com [216.207.80.1]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id SAA12370 for ; Fri, 30 Jul 1999 18:29:14 -0400 Received: from megalith.bp.aventail.com (usrpri2-46.kiva.net [206.97.75.111]) by newman.aventail.com (8.8.5/8.8.5) with ESMTP id PAA13203; Fri, 30 Jul 1999 15:27:50 -0700 (PDT) Received: (from wmperry@localhost) by megalith.bp.aventail.com (8.9.3/8.9.3) id RAA05923; Fri, 30 Jul 1999 17:28:51 -0500 To: Petr Konecny Cc: xemacs-beta@xemacs.org Subject: Re: evil behaviour for enable-multibyte-characters References: <86lnbyhule.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.070091 (Pterodactyl Gnus v0.91) 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: Petr Konecny writes: > >>>>> William M. Perry (William) said: > > William> This _HAS_ to be buffer-local if it is supposed to mimic the > William> same variable under Emacs 20.x > > William> Without this, packages that (correctly) set > William> enable-multibyte-characters can screw each other over. And > William> individual applications should *NOT* have to make this > William> buffer-local themselves. > > Since it is compatibility variable, should not XEmacs provide also > compatibility function for setting it ? It is set-buffer-multibyte in > Emacs. I'd just say screw it to the whole mess - these dont _DO_ anything in XEmacs, which is what compatibility variables are supposed to be for. This variable is causing nothing but problems, and programs will be doing the WRONG THING when they try to set it, even though they think they are being correct. > Note, however, that some packages use setq-default to set it, and > default-value to read its value. But I assume this is broken behaviour. Bleah! -bp From owner-xemacs-beta@xemacs.org Fri Jul 30 20:00:06 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA14825 for xemacs-beta-out; Fri, 30 Jul 1999 20:00:06 -0400 Received: from hermes.broadbase.com (mail.broadbase.com [204.153.177.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA14821 for ; Fri, 30 Jul 1999 20:00:05 -0400 Date: Fri, 30 Jul 1999 20:00:05 -0400 Message-Id: <199907310000.UAA14821@gwyn.tux.org> Received: from sloth.broadbase.com ([10.1.1.3]) by hermes.broadbase.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MCXAMA2F; Fri, 30 Jul 1999 17:00:04 -0700 From: Gleb Arshinov To: xemacs-beta@xemacs.org Subject: report-emacs-bug vs submit-bug-report Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Most packages call their bug report function (package-name)-submit-bug-report. It might be nice to rename XEmacs bug-reporting function to something like xemacs-submit-bug-report. Gleb From owner-xemacs-beta@xemacs.org Fri Jul 30 20:36:37 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id UAA15788 for xemacs-beta-out; Fri, 30 Jul 1999 20:36:37 -0400 Received: from kens.com (kens.com [129.250.30.40]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id UAA15785 for ; Fri, 30 Jul 1999 20:36:36 -0400 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 UAA15120 for ; Fri, 30 Jul 1999 20:36:37 -0400 (EDT) Received: (from robin@localhost) by socha.net (8.8.7/8.8.7) id CAA29177; Sat, 31 Jul 1999 02:36:08 +0200 To: xemacs-beta@xemacs.org Subject: compile problems with 21.2-b19 Organization: Never Take Me Alive 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: 31 Jul 1999 02:36:08 +0200 Message-ID: Lines: 12 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: Patched up from previous, and won't budge: [robin@hellfire xemacs] uname -a FreeBSD hellfire.socha.net 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Sun Jul 18 22:11:01 GMT 1999 root@hellfire.socha.net:/usr/src/sys/compile/HELLFIRE i386 [robin@hellfire xemacs] gcc -v gcc version 2.7.2.1 gcc -nostdlib -L/usr/local/lib -Xlinker -R/usr/local/lib:/usr/X11R6/lib -L/usr/X11R6/lib -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o debug.o unexelf.o dragdrop.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o realpath.o inline.o linuxplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o! marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o lastfile.o gmalloc.o free-hook.o vm-limit.o ralloc.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o ../lwlib/liblw.a -lXaw -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -lncurses -lm -lutil -lxpg4 -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o `gcc -print-libgcc-file-name` glyphs-x.o: In function `x_resize_subwindow': /usr/src/XEmacs/xemacs-21.2/src/glyphs-x.c(.text+0x4a4c): undefined reference to `IMAGE_INSTANCE_X_WIDGET_ID' *** Error code 1 From owner-xemacs-beta@xemacs.org Fri Jul 30 21:22:14 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id VAA17011 for xemacs-beta-out; Fri, 30 Jul 1999 21:22:14 -0400 Received: from hermes.broadbase.com (mail.broadbase.com [204.153.177.141]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id VAA17008 for ; Fri, 30 Jul 1999 21:22:12 -0400 Received: from sloth.broadbase.com ([10.1.1.3]) by hermes.broadbase.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MCXAMALG; Fri, 30 Jul 1999 18:22:11 -0700 From: Gleb Arshinov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14242.20511.311000.114806@gargle.gargle.HOWL> Date: Fri, 30 Jul 1999 18:23:43 -0700 (Pacific Daylight Time) To: xemacs-beta@xemacs.org Subject: pcl-cvs package X-Mailer: VM 6.72 under 21.2 (beta19) "Shinjuku" XEmacs Lucid Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: Stefan Monnier keeps announcing new versions of pcl-cvs in gnu.emacs.source. He says that it works under XEmacs. Could someone update the package? Gleb From owner-xemacs-beta@xemacs.org Sat Jul 31 01:36:19 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id BAA22906 for xemacs-beta-out; Sat, 31 Jul 1999 01:36:19 -0400 Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id BAA22903 for ; Sat, 31 Jul 1999 01:36:12 -0400 Received: from heart.cs.rochester.edu (heart.cs.rochester.edu [192.5.53.109]) by cayuga.cs.rochester.edu (8.9.3/Q) with ESMTP id BAA18212; Sat, 31 Jul 1999 01:36:04 -0400 (EDT) Received: (from zsh@localhost) by heart.cs.rochester.edu (8.9.3/8.9.3) id BAA03660; Sat, 31 Jul 1999 01:37:45 -0400 To: xemacs-beta@xemacs.org Cc: MORIOKA Tomohiko Subject: Bug in coding-system-list X-Attribution: ZSH Organization: U of Rochester X-Face: 'IF:e51ib'Qbl^(}l^&4-J`'P!@[4~O|&k#:@Gld#b/]oMq&`&FVY._3+b`mzp~Jeve~/#/ ERD!OTe<86UhyN=l`mrPY)M7_}`Ktt\K+58Z!hu7>qU,i.N7TotU[FYE(f1;}`g2xj!u*l`^&=Q!g{ *q|ddto|nkt"$r,K$[)"|6,elPH= GJ6Q From: Shenghuo ZHU Date: 31 Jul 1999 01:37:45 -0400 Message-ID: <2ng125wf9y.fsf@tiger.jia.vnet> Lines: 26 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: --=-=-= Function coding-system-list is supposed to list all coding-systems. But in 21.2.19, it can not list alias names. For example, (memq 'big5 (coding-system-list)) -> (big5 ...) (memq 'cn-big5 (coding-system-list)) -> nil (find-coding-system 'cn-big5) -> # This bug only exists in b19 not in previous versions because b19 uses `define-coding-system-alias' instead of `copy-coding-system'. Here is the patch. 1999-07-31 Shenghuo ZHU * file-coding.c (add_coding_system_to_list_mapper): Use key instead of value -> name. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=b19.diff --- file-coding.c 1999/07/31 04:55:09 1.1 +++ file-coding.c 1999/07/31 05:01:55 @@ -532,7 +532,7 @@ (struct coding_system_list_closure *) coding_system_list_closure; Lisp_Object *coding_system_list = cscl->coding_system_list; - *coding_system_list = Fcons (XCODING_SYSTEM (value)->name, + *coding_system_list = Fcons (key, *coding_system_list); return 0; } --=-=-= -- Shenghuo --=-=-=-- From owner-xemacs-beta@xemacs.org Sat Jul 31 09:55:51 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id JAA28603 for xemacs-beta-out; Sat, 31 Jul 1999 09:55:51 -0400 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 JAA28599 for ; Sat, 31 Jul 1999 09:55:48 -0400 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 KAA04315 for ; Sat, 31 Jul 1999 10:01:48 -0400 (EDT) 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 PAA16810; Sat, 31 Jul 1999 15:55:41 +0200 (MET DST) Cc: XEmacs Beta List Newsgroups: comp.emacs.xemacs Subject: Re: ps-print 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: 31 Jul 1999 15:54:29 +0200 Message-ID: Lines: 19 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku) In-Reply-To: Slava Kharin's message of "30 Jul 1999 16:20:12 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: comp.emacs.xemacs Sender: owner-xemacs-beta@xemacs.org Precedence: bulk X-Mailing-List: The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. >>>>> "Slava" == Slava Kharin writes: Slava> Hi, Slava> I upgraded the lisp package 'os-utils' to version 1.18 and Slava> discovered that ps-print is disappeared. What is happened Slava> to it? Yep, I saw the same. It has to do with a split between a no-MULE version of ps-print and a MULE version. I wasn't able to find out where these packages live at the moment. Adrian Slava> Thanks. Slava> -- Slava> Slava Kharin Slava> Canadian Centre for Climate Modelling & Analysis/AES From owner-xemacs-beta@xemacs.org Sat Jul 31 17:33:05 1999 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id RAA08396 for xemacs-beta-out; Sat, 31 Jul 1999 17:33:05 -0400 Received: (from majordom@localhost) by gwyn.tux.org (8.9.1/8.9.1) id PAA04905 for xemacs-announce-out; Sat, 31 Jul 1999 15:44:59 -0400 To: xemacs-announce@xemacs.org Subject: XEmacs 21.1.3 binary-kits are available From: Jason R Mastaler Date: 31 Jul 1999 13:42:08 -0600 Message-ID: Lines: 28 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2 (Toshima) 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: At long last, we are pleased to announce the availability of precompiled XEmacs binary-kits based on the XEmacs 21.1.3 release. You can find the binary-kits and associated installation instructions at the following location: Binary-kits for the following UNIX and Microsoft Windows platforms are available immediately: alpha DIGITAL UNIX V4.0D hppa HP/UX 11.0 i86pc FreeBSD 3.1 i86pc Solaris 7 i86pc Win32/cygwin mips IRIX 6.5 powerpc Linux/MkLinux (RPMS) rs6000 AIX 4.1.4 rs6000 AIX 4.2.1 Binary-kits for other popular platforms including i86pc/Linux, sparc/Solaris, and an InstallShield based release for Win32 will become available during the next couple of weeks. Check the FTP site periodically for availability. P.S - Thanks to all the binary-kit builders for their efforts, and a big Happy Birthday (today) to Steve Baur, our fearless leader!