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

Previous Next

Full log

Message #8 received at 19547 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael_heerdegen <at> web.de
Cc: 19547 <at> debbugs.gnu.org
Subject: Re: bug#19547: 25.0.50;
 throw-on-input "fires" when switching workspace
Date: Fri, 09 Jan 2015 21:59:51 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Fri, 09 Jan 2015 16:46:58 +0100
> 
> (catch 'tag
>   (let ((throw-on-input 'tag))
>     (while t)))
> 
> and switch to a different (X) workspace.  The loop is exited
> immediately.
> 
> I don't think it is useful to count switching workspaces as input.  I
> hope we can change this.
> 
> Some background: in Helm, we use `while-no-input' around the code
> performing the matching against the candidates.  This way, we can
> immediately react when new input arrives - we avoid a delay caused by
> finishing matching candidates against an obsolete input pattern.
> 
> But currently, when you switch to a different workspace while matching
> is performed, Helm stops matching.
> 
> Of course we could work around this and restart matching anew in such a
> case, but it would be better if switching desktops would not tangle
> Emacs at all.  It is counter-intuitive, at least in this scenario.  The
> doc of throw-on-input only speaks about "keyboard input".

Documentation problems aside, you can't usefully define which events
will be considered as input and which won't, in a way that would DTRT
for everyone.  The decision is specific to the application, and
while-no-input cannot know that.

It could be that this particular event can be filtered out, but that's
just the top of the iceberg.  There are way too many different events
flowing into Emacs on a typical modern system, keyboard being just a
small part of that.

Previous Next

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