bug#19547: 25.0.50; throw-on-input "fires" when switching workspace

[Michael Heerdegen <michael_heerdegen@web.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > (catch 'tag
> >   (let ((throw-on-input 'tag))
> >     (while t)))
> >
> > and switch to a different (X) workspace.  The loop is exited
> > immediately.
>
> Can you check with C-h l what event Emacs received?

The event isn't listed there.  I think it is focus-out or something like
that.

> I don't understand exactly the problem you're seeing.  Why is it
> a problem to stop computing the matching candidates when the user
> switches to another workspace?  If "switches to another workspace"
> means that the selected Emacs frame disappears (a likely scenario)

Exactly.

> then it seems harmless to stop computing the candidates.

I switch to a different workspace (or focus a different application) to
do something useful until matching has finished.

Imagine you have opened some large page on firefox, switch to another
app to do something else until the page is ready, and when you come back
to firefox, it shows a blank page, because it considers losing focus as
an important user input and just stops rendering.  That's what Helm
currently does with candidate matching cause it relies (and needs to
rely) on while-no-input.

Note that Helm can't just continue performing matching later, because
throw-on-input made Emacs jump out of the code.  Which is what we want
of cause when there was any "real" user input, i.e., when the user added
text to the matching pattern for example.