[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unwind-protect and inhibit-quit

From: Felix Dietrich
Subject: Re: unwind-protect and inhibit-quit
Date: Fri, 16 Jul 2021 16:56:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Felix Dietrich <> writes:

> Eli Zaretskii <> writes:
>>> From: Thibaut Verron <>
>>> Date: Fri, 16 Jul 2021 10:10:36 +0200
>>> Cc: help-gnu-emacs <>
>>> > You could use inhibit-quit, but that is generally a bad idea from the
>>> > UI point of view, when invoking potentially long-running functions:
>>> > you are preventing the user from interrupting that long function.  For
>>> > example, suppose the FTP command stalls for some reason.
>>> >
>>> Now I'm curious too... Would something like this work?
>>>  (let ((inhibit-quit t))
>>>    (setq process
>>>       (let ((inhibit-quit nil))
>>>          (ftp-setup-buffer host file))))
>> It might, but I still suggest to bind inhibit-quit non-nil only for
>> short durations of time and as little as possible.  There be dragons.
> I just found the “with-local-quit” macro.  Itʼs comment says that the
> quit-flag “will not be handled until the next function call”.  Doesnʼt
> that imply that once the let form has a value to return, the assignment
> should go through?  Admittingly, this is a lot of guessing on my side,
> as I do not know Emacs internals.

Nevermind, the manual states (I added the ‘*’ as highlighting):
“Eventually, ‘inhibit-quit’ will become ‘nil’ again, such as when its
binding is unwound at the end of a ‘let’ form.  *At that time*, if
‘quit-flag’ is still non-‘nil’, *the requested quit happens
immediately.*”[1]  So there might be more happening at the end of a let.
I guess only the source will tell, and “there be dragons” is the
definitive warning to follow for now.

[1]  (info "(elisp) Quitting")

Felix Dietrich

reply via email to

[Prev in Thread] Current Thread [Next in Thread]