November 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: concat Texinfo [was: emacs 18, XEmacs 21.x, and calc v2.02f] 24 years, 1 month

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > I _was_ going to go fix the doc, but discovered more discrepancies. > > Lispref says > > (concat "abc" (list 120 (+ 256 121)) [122]) > ＠result{} "abcxyz" It's a documentation bug. I don't see why (concat "abc" '(120 377) [122]) would possibly return "abcxyz". when the number 377 does not correspond to the ASCII character ?y. > This is still considered a feature, right? Right. Since `concat' produces a string, all the list and vector elements are coerced to characters. The only coercion that makes sense for numbers is `int-char', and that should be documented. And yes, I'm aware that int-char is not the nicest function in the world, but within the bounds of XEmacs it makes sense and actually creates the least broken behaviour. For instance, this works both with and without Mule. (apply #'concat (mapcar #'list "Hrvoje Nikšić")) > --with-mule=no XEmacs does as the manual says (computes the > character modulo 256), right? It could signal an error just as well. That's what I think it *should* do, anyway. Calling int-char is one thing; accepting numbers outside the available range and truncating them silently is another.

1 participants
0 comments

Re: concat Texinfo [was: emacs 18, XEmacs 21.x, and calc v2.02f] 24 years, 1 month

Adrian Aichner

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "vin" == Vin Shelton <acs(a)xemacs.org> writes: vin> You are correct that the lispref claims that concat takes an vin> int, but that capability was taken out of XEmacs awhile ago, vin> I think around 20.something. Stephen> I _was_ going to go fix the doc, but discovered more discrepancies. Stephen> Lispref says Stephen> (concat "abc" (list 120 (+ 256 121)) [122]) Stephen> ＠result{} "abcxyz" Stephen> but in reality Mule does Stephen> oops ==> "abcx,By(Bz" Stephen> (that's a Latin-2 character between x and z). Stephen> This is still considered a feature, right? Stephen> --with-mule=no XEmacs does as the manual says (computes Stephen> the character modulo 256), right? No. In (emacs-version) "XEmacs 21.1 (patch 12) \"Channel Islands\" [Lucid] (i386-pc-win32) of Sat Sep 16 2000 on ZJ75T" (built without MULE) I get this: (concat "abc" (list 120 (+ 256 121)) [122]) **Message-Log** Wrong type argument: characterp, 377 **Backtrace** Signaling: (wrong-type-argument characterp 377) concat("abc" (120 377) [122]) eval((concat "abc" (list 120 (+ 256 121)) [122])) eval-interactive((concat "abc" (list 120 (+ 256 121)) [122])) eval-last-sexp((4)) call-interactively(eval-last-sexp) Adrian Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

1 participants
0 comments

Re: default value for find-file-compare-truenames? (was Re: links: ...) 24 years, 1 month

Hrvoje Niksic

palmieri(a)math.washington.edu (John H. Palmieri) writes: > > But it seems like the right default behaviour, so I see no good > > reason not to enable it by default. Is the GNU Emacs equivalent > > feature configurable? If yes, is it "on" by default? > > Yes and yes: there is a variable 'find-file-existing-other-name' > which has default value t. Ah, now I see it: `find-file-existing-other-name' is an alias for `find-file-compare-truenames',a built-in boolean variable. > (Of course, the default value of t is in conflict with the GNU Emacs > documentation which says > > If you visit two names for the same file, normally Emacs makes two > different buffers, but it warns you about the situation. > > If you wish to avoid visiting the same file in two buffers under > different names, set the variable `find-file-existing-other-name' to a > non-`nil' value. > > I'll have to submit a bug report.) They have probably changed the default at some point, but forgot to update the documentation. We should probably do the same, except for the documentation part.

1 participants
0 comments

Re: default value for find-file-compare-truenames? (was Re: links: ...) 24 years, 1 month

Hrvoje Niksic

palmieri(a)math.washington.edu (John H. Palmieri) writes: > Sorry, now that I've found the right variable, I guess my question is: > > Should find-file-compare-truenames be 't' by default instead of > 'nil'? Maybe. I set it to t in my .emacs. Most people probably wouldn't care. Some people might object that it's too "intelligent", and that it might break things in some situations. But it seems like the right default behaviour, so I see no good reason not to enable it by default. Is the GNU Emacs equivalent feature configurable? If yes, is it "on" by default?

2 participants
1 comments

Re: links: what should XEmacs do if two paths lead to the same file? 24 years, 1 month

Hrvoje Niksic

palmieri(a)math.washington.edu (John H. Palmieri) writes: > I have a directory '~/.www/Math307/' which is soft-linked to > '~/classes/307/WEB/'. If I'm using > > GNU Emacs 20.4.7 (alphaev5-dec-osf4.0f, X toolkit) of Fri Feb 25 2000 on hilbert1 > > when I find the files '~/classes/307/WEB/index.html' and > '~/.www/Math307/index.html', I am told > > ~/classes/307/WEB/index.html and /user1/palmieri/.www/Math307/index.html are the same file > > and I get only one new buffer called "index.html". I assume this is possible by the magic of symlinks? Have you set `find-file-compare-truenames' to a non-nil value? > when I find both files, I don't receive any such message, and I get > two buffers: "index.html" and "index.html<2>". If I edit one of the > files and then try to edit the other one, I'm asked > > index.html changed on disk; really edit the buffer? (y, n, r or C-h) > > which is good, but a little late, I think. It's definitely good, but it was not meant for the kind of situation you're facing. :-)

1 participants
0 comments

links: what should XEmacs do if two paths lead to the same file? 24 years, 1 month

John H Palmieri

I have a directory '~/.www/Math307/' which is soft-linked to '~/classes/307/WEB/'. If I'm using GNU Emacs 20.4.7 (alphaev5-dec-osf4.0f, X toolkit) of Fri Feb 25 2000 on hilbert1 when I find the files '~/classes/307/WEB/index.html' and '~/.www/Math307/index.html', I am told ~/classes/307/WEB/index.html and /user1/palmieri/.www/Math307/index.html are the same file and I get only one new buffer called "index.html". On the other hand, if I'm using XEmacs 21.2 (beta36) "Notus" [Lucid] (alpha-dec-osf5.0) of Tue Oct 24 2000 on goedel2 when I find both files, I don't receive any such message, and I get two buffers: "index.html" and "index.html<2>". If I edit one of the files and then try to edit the other one, I'm asked index.html changed on disk; really edit the buffer? (y, n, r or C-h) which is good, but a little late, I think. I prefer the GNU Emacs behavior; should XEmacs act the same way, or are there good reasons for keeping the current behavior? How hard would it be to switch? -- John H. Palmieri Dept of Mathematics, Box 354350 palmieri(a)math.washington.edu University of Washington http://www.math.washington.edu/~palmieri/ Seattle, WA 98195-4350

1 participants
1 comments

vc-cc 24 years, 1 month

Dhruva_KRISHNAMURTHY＠delmia.com

Hi, I removed the default "vc" folder and moved "vc-cc" in it's place ( and renamed it as "vc" ). When I try to access a file in ClearCase version control, it just stops at a message "Waiting to start Cleartool" and that it. The process usage is 0% ( Task Manager ). The same thing happens when I type M-x vc-dired-mode and try visiting a file in source control. I have provided the path to the "Cleartool.exe" also in my init.el file. I notice "Cleartool.exe" running in the Task Manager too. I am not sure where I have gone wrong. In the GNU Emacs 20.7, in "vc-dired-mode", it just hangs. I used the package available at: http://www.fukt.hk-r.se/~flognat/vc/vc-cc.zip for GNU Emacs. Looking forward for some information on this. with regards, dhruva

2 participants
1 comments

Re: open-network-stream to dead host hang XEmacs 24 years, 1 month

Gunnar Evermann

Hrvoje Niksic <hniksic(a)arsdigita.com> writes: > [ Added Ben Wing, who knows the most about XEmacs event loop, to Cc. ] I though Ben still reads xemacs-beta? > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > After 15 seconds the expected SIGALARM arrives and the X event queue > > is inspected for C-g but for some reason the C-g is not found. In my > > debugging run the C-g event was just not there. Another problem is > > that the SIGALARM is generated only once (this is fixable I guess). If > > I generate another couple of SIGALARMs by hand with kill then the C-g > > eventually shows up in the queue and open-network-stream is quit. > > Ben, can you comment on this? Is this how things are supposed to > work? > > Gunnar, you might be interested in the latest patch by Yoshiki, which > seems to make exactly the change necessary for the above to work > right. (But then again, it might not, with XEmacs it's hard to tell.) I doubt that this helps. I think the problem at a far lower level. In Simon's case we never get anywhere near the lisp command loop. The problem is that the X event that corresponds to C-g is not in the X queue (yet) and thus the XCheckIfEvent() in x_check_for_quit_char() doesn't find it. Gunnar

1 participants
0 comments

Current CVS Mule 21.2 crashes (on X only?) 24 years, 1 month

Stephen J. Turnbull

In CVS current, Mule on X crashes immediately. This may be related to Japanese hardware; the keysym that blows up is 1223 decimal, which puts it in the KATAKANA_JISX0201 range. (Cf x_keysym_to_character(), src/event-Xt.c:211.) `xemacs -nw -vanilla' does not crash. $ src/xemacs -vanilla & Fatal error: assertion failed, file /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h, line 569, lb >= 0x80 && lb <= 0xFF [...] 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 ...) [2]+ Aborted src/xemacs -vanilla C backtrace: bash-2.04$ gdb src/xemacs GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) run -vanilla Starting program: /home/steve/Projects/XEmacs/Builds/21.2/src/xemacs -vanilla Fatal error: assertion failed, file /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h, line 569, lb >= 0x80 && lb <= 0xFF Program received signal SIGABRT, Aborted. 0x40396e71 in kill () from /lib/libc.so.6 (gdb) where #0 0x40396e71 in kill () from /lib/libc.so.6 #1 0x40396b54 in raise () from /lib/libc.so.6 #2 0x40398261 in abort () from /lib/libc.so.6 #3 0x80ca76b in assert_failed ( file=0x82e0080 "/coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h", line=569, expr=0x82e00b3 "lb >= 0x80 && lb <= 0xFF") at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:3189 #4 0x8217467 in x_keysym_to_character (keysym=1223) at /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h:569 #5 0x8217750 in x_has_keysym (keysym=1223, hash_table={gu = { type = Lisp_Type_Record, val = 34853898}, s = {bits = 0, val = 69707796}, u = {bits = 0, val = 69707796}, ui = 139415592, i = 139415592, v = 0x84f5028, cv = 0x84f5028}, with_modifiers=1) at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:306 #6 0x821799a in x_reset_key_mapping (d=0x848ee70) at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:406 #7 0x8217a78 in x_reset_modifier_mapping (d=0x848ee70) at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:461 #8 0x821d6ba in x_init_modifier_mapping (d=0x848ee70) at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:625 #9 0x8214880 in x_init_device (d=0x848ee70, props={gu = { type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/device-x.c:803 #10 0x80b73dc in Fmake_device (type={gu = {type = Lisp_Type_Record, val = 269850822}, s = {bits = 0, val = 539701644}, u = {bits = 0, val = 539701644}, ui = 1079403288, i = 1079403288, v = 0x40566318, cv = 0x40566318}, connection={gu = {type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}, props={gu = {type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/device.c:588 #11 0x80d1bae in Ffuncall (nargs=3, args=0xbfffee78) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3528 #12 0x809d02e in execute_optimized_program ( program=0x8434480 "ÁÂ\b\"\207 by ", stack_depth=3, constants_data=0x406141fc) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746 #13 0x809cbb4 in funcall_compiled_function (fun={gu = { type = Lisp_Type_Record, val = 270077235}, s = {bits = 0, val = 540154470}, u = {bits = 0, val = 540154470}, ui = 1080308940, i = 1080308940, v = 0x406434cc, cv = 0x406434cc}, nargs=1, args=0xbffff0cc) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518 #14 0x80d1d10 in Ffuncall (nargs=2, args=0xbffff0c8) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563 #15 0x809d02e in execute_optimized_program ( program=0x848e990 "\f?\037Å \210\b＠\013B\022ÆÁ!«\b\t¬\005ÇÈ!\021ÉÊ!\210\nA\023Ë\211\024\207f)", stack_depth=2, constants_data=0x40600890) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746 #16 0x809cbb4 in funcall_compiled_function (fun={gu = { type = Lisp_Type_Record, val = 270071089}, s = {bits = 0, val = 540142178}, u = {bits = 0, val = 540142178}, ui = 1080284356, i = 1080284356, v = 0x4063d4c4, cv = 0x4063d4c4}, nargs=0, args=0xbffff31c) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518 #17 0x80d1d10 in Ffuncall (nargs=1, args=0xbffff318) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563 #18 0x809d02e in execute_optimized_program ( program=0x848e798 "\013A\035ÆÇ\032\031È\r!\025ÉÊ!«\004Ë \210\f«\016\b¬\013ÌÍÎ\f!ÏQ! \210Ð \210*Ñ \210Ò \210rÓÔ!q\210Õ \210Ö×!\210\016\036Øa«\005\016\037 \210)Ù Úa«\bÀ ¬\004Û \210Ü \210×\026 À \004ÝÇ!)\207steA\001", stack_depth=4, constants_data=0x4060f99c) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746 #19 0x809cbb4 in funcall_compiled_function (fun={gu = { type = Lisp_Type_Record, val = 270076073}, s = {bits = 0, val = 540152146}, u = {bits = 0, val = 540152146}, ui = 1080304292, i = 1080304292, v = 0x406422a4, cv = 0x406422a4}, nargs=0, args=0xbffff57c) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518 #20 0x80d1d10 in Ffuncall (nargs=1, args=0xbffff578) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563 #21 0x809d02e in execute_optimized_program ( program=0x8407ad8 "\t«\005ÆÇ!\207È\021É \211\034«\025\fG\rGW«\016Ê\r!Ê\f!k«\005Ë\f!\025)Ì\r!\025Í \210Î \210\013®\aÏÐ!\002È\eÑ\016#\016$\"\022\013«\tÒÓÔ\n\"Õ\"\210\n¬\006Ö \210ª\013×\n\016%\b\016&\013%\210Ø \210)\016!¬\022\016\"«\016ÙÚÛ\016'!\016\"\"ÜÈ#\210\016!¬\023\b¬\006Ý\016(!\210Ý\016)!\210Ý\016*!\210Þ\216ß \210)\016+\003à \207", stack_depth=7, constants_data=0x406100a4) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746 #22 0x809cbb4 in funcall_compiled_function (fun={gu = { type = Lisp_Type_Record, val = 270076290}, s = {bits = 0, val = 540152580}, u = {bits = 0, val = 540152580}, ui = 1080305160, i = 1080305160, v = 0x40642608, cv = 0x40642608}, nargs=0, args=0xbffff714) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518 #23 0x80d16af in Feval (form={gu = {type = Lisp_Type_Record, val = 269923146}, s = {bits = 0, val = 539846292}, u = {bits = 0, val = 539846292}, ui = 1079692584, i = 1079692584, v = 0x405acd28, cv = 0x405acd28}) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3388 #24 0x80cd028 in condition_case_1 (handlers={gu = {type = Lisp_Type_Record, val = 269853552}, s = {bits = 0, val = 539707104}, u = {bits = 0, val = 539707104}, ui = 1079414208, i = 1079414208, v = 0x40568dc0, cv = 0x40568dc0}, bfun=0x80d0b30 <Feval>, barg={gu = { type = Lisp_Type_Record, val = 269923146}, s = {bits = 0, val = 539846292}, u = {bits = 0, val = 539846292}, ui = 1079692584, i = 1079692584, v = 0x405acd28, cv = 0x405acd28}, hfun=0x80acbbc <cmd_error>, harg={gu = {type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:1651 #25 0x80acc6d in top_level_1 (dummy={gu = {type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/cmdloop.c:206 #26 0x80d69e7 in internal_catch (tag={gu = {type = Lisp_Type_Record, val = 269804556}, s = {bits = 0, val = 539609112}, u = {bits = 0, val = 539609112}, ui = 1079218224, i = 1079218224, v = 0x40539030, cv = 0x40539030}, func=0x80acc34 <top_level_1>, arg={gu = { type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}, threw=0x0) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:1317 #27 0x80abd29 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record, val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40, cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/cmdloop.c:285 #28 0x80c87e4 in sort_args (argc=2, argv=0xbffffca4) at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:2228 #29 0x80ca9fb in main (argc=2, argv=0xbffffca4, envp=0xbffffcb0) at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:2595 #30 0x40387bcc in __libc_start_main () from /lib/libc.so.6 Installation: uname -a: Linux tleepslib 2.4.0-test7 #1 Thu Sep 7 18:30:33 JST 2000 i686 unknown /coda/Projects/XEmacs/21.2-HEAD/configure '--srcdir=/coda/Projects/XEmacs/21.2-HEAD' '--with-widgets=athena' '--with-athena=3d' '--with-dialogs=athena' '--with-sound=none,nas' '--with-mule' '--with-xim=xlib' '--with-xfs' '--use-union-type' '--pdump' XEmacs 21.2-b36 "Notus" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /coda/Projects/XEmacs/21.2-HEAD Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for NAS (network audio system). Databases: Compiling in support for Berkeley database. Compiling in support for PostgreSQL. - Using PostgreSQL header file: postgresql/libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. - Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Using the union type for Lisp_Objects. Using the new portable dumper. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

3 participants
4 comments

Re: open-network-stream to dead host hang XEmacs 24 years, 1 month

Hrvoje Niksic

[ Added Ben Wing, who knows the most about XEmacs event loop, to Cc. ] Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > Simon Josefsson <simon(a)josefsson.org> writes: > > > $ xemacs -vanilla > > (open-network-stream "bug" nil "10.0.0.42" 42) > > > > Now XEmacs 21.1 (and 20.4) is hung, C-g doesn't do anything. XEmacs > > 21.2 seem fine. Perhaps the solution used there could be back-ported > > to XEmacs 21.1? > > I am afraid there are two bugs here. The first one is fundamental and > causes C-g in X not to work for interrupting system calls and the > second one makes it work in 21.2 nevertheless. Alas I only understand > and can "fix" the latter :-( > > Some explanations follow. (warning: I looked at most of this code for > the first time and don't understand some of it): > > - before calling connect() we call slow_down_interrupts() (for rather > unclear reasons documented in the slightly strange comments). > > - slow_down_interrupts ends up calling unrequest_sigio_on_device() > for the X file descriptor. In 21.2 this contains > > ------------ > #if defined (I_SETSIG) && !defined(HPUX10) > { > int events=0; > ioctl (filedesc, I_GETSIG, &events); > ioctl (filedesc, I_SETSIG, events & ~S_INPUT); > } > #elif defined (FASYNC) > fcntl (filedesc, F_SETFL, fcntl (filedesc, F_GETFL, 0) & ~FASYNC); > ------------- > > On Linux with glibc2.1 I_SETSIG is defined but the ioctl don't > actually work (this seems to be a feature), strace shows: > > > 14:36:07 ioctl(6, CDROMVOLCTRL, 0xbfffea84) = -1 EINVAL (Invalid argument) <0.000010> > 14:36:07 ioctl(6, CDROMEJECT, 0) = -1 EINVAL (Invalid argument) <0.000008> > > The effect is that SIGIO is *not* disabled and C-g is detected and > works as normal. > > For 21.1 Jan applied a patch to the above > http://www.xemacs.org/list-archives/xemacs-patches/199906/msg00000.html > > -#if defined (I_SETSIG) && !defined(HPUX10) > +#if defined (I_SETSIG) && !defined(HPUX10) && !defined(LINUX) > > now the fcntl () is executed instead and this works, i.e. SIGIO is > disabled and we rely on the slowed down C-g detection to work. Only > problem is it doesn't... > > > After 15 seconds the expected SIGALARM arrives and the X event queue > is inspected for C-g but for some reason the C-g is not found. In my > debugging run the C-g event was just not there. Another problem is > that the SIGALARM is generated only once (this is fixable I guess). If > I generate another couple of SIGALARMs by hand with kill then the C-g > eventually shows up in the queue and open-network-stream is quit. Ben, can you comment on this? Is this how things are supposed to work? Gunnar, you might be interested in the latest patch by Yoshiki, which seems to make exactly the change necessary for the above to work right. (But then again, it might not, with XEmacs it's hard to tell.) 2000-11-06 Yoshiki Hayashi <yoshiki(a)xemacs.org> * cmdloop.c (Fcommand_loop_1): Just add C-g to event queue. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Index: cmdloop.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/cmdloop.c,v retrieving revision 1.9.2.4 diff -u -r1.9.2.4 cmdloop.c --- cmdloop.c 2000/05/11 10:29:34 1.9.2.4 +++ cmdloop.c 2000/11/06 05:16:28 ＠＠ -549,9 +549,13 ＠＠ } } +#if 0 /* What's wrong with going through ordinary procedure of quit? + quitting here leaves overriding-terminal-local-map + when you type C-u C-u C-g. */ /* If ^G was typed before we got here (that is, before emacs was idle and waiting for input) then we treat that as an interrupt. */ QUIT; +#endif

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 2000