Re: [PATCH] Really prevent quitting in sensitive contexts

[Daniel Colascione <dancol@dancol.org>]

On 3/11/20 7:20 PM, Stefan Monnier wrote:
>> with-local-quit is actually documented to allow this sort of
>> foreground quitting,
> 
> AFAIK it's not just documented to allow that, but it's designed
> specifically for that.

Right, but I can imagine it being useful more generally in some code 
that wants to be atomic against quit, but with exceptions. I don't know 
of any such code though.

>> but since the interactive C-g race is unavoidable, we should deprecate
>> use of with-local-quit for this purpose.
> 
> I tend to agree.
> 
>> This change adds a new inhibit-quit-override flag.
> 
> Sounds like an arm's race: then we'll have to add
> a with-local-quit-override-override, etc...

I considered making with-local-quit-override inaccessible from Lisp.

>> +behaves as if 'inhibit-quit' were t.  This change prevents
>> +with-local-quit from accidentally allowing quits inside process
>> +filters, redisplay callbacks, and other special contexts.
> 
> I'm not really familiar with those accidental cases.
> Maybe they can be fixed more directly by not using with-local-quit?

with-local-quit has been there for ten years. Can we just delete it?

> 
> Are there bug#NNN where these are discussed?

No. The motiviation is Tramp inflooping after a quit because it uses 
with-local-quit inside tramp-accept-process-output, which causes 
tramp-wait-for-regexp to retry infinitely and quickly.

I found *that* behavior trying to figure out why M-x compile over Tramp 
was hanging not only Emacs, but also the SSH connection more generally. 
I *think* it has something to do with compilation-filter calling 
file-truename, which invokes Tramp's handler, which wants to talk over 
the same SSH connection that's spewing compilation messages, deadlocking 
something somewhere.

We probably should make compile not filename lookup directly in the 
process filter.