Re: unwind-protect within while-no-input

[Dmitry Gutov]

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.