bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19547: Patch for this bug


From: Reuben Thomas
Subject: bug#19547: Patch for this bug
Date: Tue, 8 Nov 2016 22:20:11 +0000

On 8 November 2016 at 20:40, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@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.

-- 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]