GNU bug report logs - #19547
25.0.50; throw-on-input "fires" when switching workspace

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19547 <at> debbugs.gnu.org
Subject: bug#19547: 25.0.50; throw-on-input "fires" when switching workspace
Date: Sat, 10 Jan 2015 01:00:50 +0100

Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.