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: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19547 <at> debbugs.gnu.org
Subject: bug#19547: Patch for this bug
Date: Tue, 8 Nov 2016 22:20:11 +0000

[Message part 1 (text/plain, inline)]

On 8 November 2016 at 20:40, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Date: Tue, 8 Nov 2016 18:28:28 +0000
> >
> > Further, at present it would not help helm to implement Eli's suggestion
> of a list of events for input-pending-p
> > to ignore, as Helm currently does not use that (it has a custom version
> of while-no-input that does not call
> > input-pending-p).
>
> The suggestion was not that specific.  The idea was to let Lisp
> programs specify which special events they would like to consider as
> input.  E.g., define a variable that holds a list of such events, and
> test the value of that variable in the same place where you propose to
> add yet another event to those ignored for the purposes of
> throw-on-input (IMO, the same list should be looked at in
> readable_events, which will then make input-pending-p consistent with
> while-no-input and any other similar functionality).  It shouldn't be
> too hard to implement that, and we gain a certain peace of mind in
> that we don't have to worry about some hypothetical application that
> would like to do stuff differently from Helm.
>
> IOW, since this is going to go on master, I see no reason to hurry
> with a simple solution, and would prefer a slightly more complex one,
> but one that is more future-proof.  Can you do that?
>

​I'm in the middle of a long list of Emacs bugs I am trying to fix, and
this one came up by chance at the same time, because I was suffering from
the bug.

I'd rather have a simple fix that can also go on the emacs-25 branch, and I
don't really have more time to work on a proper fix, sorry.

On the other hand, I think it would be sad to have to wait (perhaps
forever!) for a "good" fix, when an acceptable fix is available. In
particular, no reasonable application is going to expect a request for the
selection to trigger a keyboard input event. So indeed future applications
may need the "good" fix, but no (reasonable) application will be adversely
affected by this fix.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Previous Next

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