Re: [PATCH] Unconditional quit on SIGUSR2

[Eli Zaretskii]

> Date: Mon, 28 Mar 2011 12:49:53 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> On 3/28/2011 12:41 PM, Eli Zaretskii wrote:
> > We are miscommunicating: I meant that delivering a SIGTERM will end up
> > in fatal_error_signal, which will save all that's worth saving, before
> > Emacs commits suicide.  Your patch achieves the same goal, as far as
> > saving unsaved work is concerned, except it uses SIGUSR2.
> 
> My patch does not do the same thing.  Instead, my patch returns the user 
> to an *interactive* context where he can continue using Emacs normally 
> after resolving whatever was causing the infinite loop (perhaps by 
> closing a buffer, or setting some configuration variables).  It is not 
> an unconditional quit the same way SIGTERM is.

I would not recommend anyone to continue using Emacs normally after
interrupting uninterruptible ops.

> It would solve that problem but introduce another: users have no way of 
> knowing went font-lock happens.  Innocently typing C-g at the wrong time 
> can terminate font lock and leave parts of the buffer unfontified.

If the user doesn't know when to type C-g, she won't know when to type
"kill PID -USR2", either.