Re: [PATCH] Unconditional quit on SIGUSR2

[Stefan Monnier]

That reminds me of the idea to turn C-g C-g C-g into a "really break, no
matter what" key sequence.  Someone posted a patch for it a while back
and I didn't find the time to review it back then.

> === modified file 'doc/emacs/trouble.texi'
> --- doc/emacs/trouble.texi    2011-01-25 04:08:28 +0000
> +++ doc/emacs/trouble.texi    2011-03-29 17:47:26 +0000
> @@ -812,6 +812,14 @@
>  This backtrace is useful for debugging such long loops, so if you can
>  produce it, copy it into the bug report.
 
> address@hidden debug-on-special-event
> +If the normal quit process is ineffective, you can try sending Emacs
> +the special event given in @code{debug-on-special-event}, which by
> +default corresponds to SIGUSR2.  When Emacs receives this event, it
> +stops what it's doing, sets @code{debug-on-quit} to @code{t}, and
> +tries to break into the debugger in a variety of ways.  This process
> +happens even in places where quitting is normally not allowed.
> +
>  @item
>  Check whether any programs you have loaded into the Lisp world,
>  including your @file{.emacs} file, set any variables that may affect the

> === modified file 'doc/lispref/debugging.texi'
> --- doc/lispref/debugging.texi        2011-01-25 04:08:28 +0000
> +++ doc/lispref/debugging.texi        2011-03-29 17:46:44 +0000
> @@ -185,6 +185,20 @@
>  when you quit.  @xref{Quitting}.
>  @end defopt
 
> address@hidden debug-on-special-event
> +When this variable contains a symbol matching one of the special
> +events in @code{special-event-map} (@pxref{Active Keymaps}) and Emacs
> +receives the corresponding event, Emacs will break into the debugger
> +instead of processing the event normally, setting @code{debug-on-quit}
> +to @code{t} as a side effect.  This feature is useful for terminating
> +infinite loops in places where quits would normally be ignored, such
> +as in code that runs during redisplay.
> +
> +Currently, the only events Emacs recognizes as valid values for
> address@hidden are @code{sigusr1} and @code{sigusr2}.
> +
> address@hidden defopt

I'm not sure I'd want to advertise this feature in all manuals at this
point.  I'd rather see it in etc/DEBUG.  And it should include some info
about what happens after you get the backtrace: e.g. can you just hit
`q' to abort the inf-loop and go on using this Emacs sessions as if
nothing happened?

> +  if (SYMBOLP (Vdebug_on_special_event) &&
> +      STRINGP (XSYMBOL (Vdebug_on_special_event)->xname))

Use SYMBOL_NAME.  And I don't think STRINGP is needed here.

Another minor problem is that you use a name with "special-event" and
the doc makes references to "special-event-map" yet the two are
fundamentally unrelated (except that they both can handle SIGUSRn
signals).


        Stefan