Hrvoje Niksic wrote: ... > However, the misfunctioning of C-g is an XEmacs bug under Cygwin. On > Linux, C-g is able to interrupt the loop. It seems they are having troubles with signals at cygnus, at least with blocking socket calls. Some might be fixed in the next DLL release. See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a' reply http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html In case it might avoid headaches... A+O.

At 11:15 AM 5/21/01 -0400, Paul Stodghill wrote: Try defining BROKEN_SIGIO in your s/cygwin32.h and see how that goes. It will enable C-g but led to random lockups last time I tried it. But we need a crash test dummy .... andy

I managed to get a backtrace by sending HUP to a xemacs-21.5-b1 process that was in an infloop. Here it is, milhouse$ xemacs-21.5-b1 [1]+ Stopped xemacs-21.5-b1 milhouse$ bg [1]+ xemacs-21.5-b1 & milhouse$ kill -1 %1 milhouse$ Fatal error (1). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, 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(a)xemacs.org&#39;. *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-21.5-b1.exe 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: looking-at("--text follows this line--$\\|[ ]*$\\|-- $\\|---+$\\|^?$\\|.*wro te:$\\|\\(\\([ ]*\\(\\w\\|[-_.]\\)+>+\\|[ ]*[]>�|:}+]\\)+\\)[ ]*$") # bind (quoted point beg end leading-space bolp not-break arg) message-newline-and-reformat(nil t) # bind (arg) message-fill-paragraph(nil) # bind (function fill-paragraph-function arg) #<compiled-function (arg) "...(54)" [function before end start arg fill-paragr aph-function nil forward-paragraph newline 1 backward-paragraph fill-region fill -region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix-arg . ..))>(nil) apply(#<compiled-function (arg) "...(54)" [function before end start arg fill- paragraph-function nil forward-paragraph newline 1 backward-paragraph fill-regio n fill-region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix -arg ...))> nil) # bind (args function) filladapt-funcall(fill-paragraph nil) # bind (paragraph-ignore-fill-prefix adaptive-fill-mode adaptive-fill-regexp c omment-multi-line fill-prefix retval) # (unwind-protect ...) byte-code("..." [function done retval sign delta fill-column nil t filladapt-a dapt 1 0 filladapt-funcall filladapt-paragraph-within-fill-tolerance success run -hooks filladapt-fill-paragraph-post-hook throw arg low high lim fill-prefix old -fill-column filladapt-mode comment-multi-line adaptive-fill-regexp adaptive-fil l-mode paragraph-ignore-fill-prefix filladapt-fill-column-tolerance filladapt-fi ll-column-backward-fuzz filladapt-fill-column-forward-fuzz] 7) # (catch done ...) # bind (arg function) filladapt-fill-paragraph(fill-paragraph nil) # bind (filladapt-inside-filladapt arg) fill-paragraph(nil) # bind (command-debug-status) call-interactively(fill-paragraph) # bind (arg) fill-paragraph-or-region(nil) # bind (command-debug-status) call-interactively(fill-paragraph-or-region) # (condition-case ... . error) # (catch top-level ...)

Olivier Fambon wrote: Hum. Not really... My fault. Miss-manipulated. The funny thing is that if you M-q on the first citation line, it works !!! eg: --text follows this line-- a This holds.

Ben Wing <ben(a)666.com&gt; writes: It does break out of inhibit-quit. C-g doesn't break this, but C-Sh-g does: (let ((inhibit-quit t)) (while t)) However, delays where slow_down_interrupts is involved, such as `connect', are *not* broken with C-Sh-g, and that's extremely annoying. Any way to fix that?

Gunnar Evermann <ge204(a)eng.cam.ac.uk&gt; writes: I see. This is very cool. I'll have to try it out!

Ben Wing <ben(a)666.com&gt; writes: I haven't run that code yet, sorry. Will do.

Paul Stodghill wrote: actually, i also found this bug, and i'll soon be posting a patch. [in the meantime, try holding down C-Sh-g, and you might get a break after awhile] -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.