Re: unwind-protect within while-no-input

[Dmitry Gutov <dmitry@gutov.dev>]

On 29/05/2024 03:39, Stefan Monnier wrote:
>>>> All right. Would you say that the general class of circumstances like
>>>>
>>>>    - completion is performed when Emacs is idle
>>>>    - non-essential is t
>>>>    - called by icomplete to show completion hints
>>>>
>>>> is a good general rule to apply while-no-input?
>>> Yes, basically the choice should be made on the UI side.  The completion
>>> table itself doesn't know why the caller wants the info so it can't know
>>> whether user input makes the request pointless.
>> Yeah, definitely. I was just wondering whether we should make that choice
>> entirely in the UI, or make it additionally opt-in for completion tables
>> (telling the UI that it's fine with such treatment).
> Maybe it would be useful for completion tables to be able to tell the
> UI whether `while-no-input` is "supported", but I'm not sure we have
> enough evidence to suggest it would be useful.
> 
> BTW, in practice completion tables can already "override" a UI's
> `while-no-input`, if necessary, by rebinding `throw-on-input` to nil.

Okay, that makes sense.

I guess it's more of a backward compatibility concern - how some 
(possibly many) existing completion tables might start misbehaving after 
the new release of company-mode, and some one of them might not have a 
dedicated maintainer these days.

The popularity of Corfu and icomplete indicates that it's mostly fine. 
OTOH, some conservative users (who would otherwise have problems with 
while-no-input) might just be staying with company-mode because of 
stronger backward compat.

Buuut... I guess I could flip the switch and wait for reports, as usual.