From: Reuben Thomas <rrt@sc3d.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 19547@debbugs.gnu.org
Subject: bug#19547: Patch for this bug
Date: Tue, 8 Nov 2016 22:20:11 +0000 [thread overview]
Message-ID: <CAOnWdoivvpDR2Lg9pk5ADSVVsQqOxAQmD38BXb==w6SbgW79CQ@mail.gmail.com> (raw)
In-Reply-To: <8360nxhfiw.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
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.
--
http://rrt.sc3d.org
[-- Attachment #2: Type: text/html, Size: 3012 bytes --]
next prev parent reply other threads:[~2016-11-08 22:20 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 15:46 bug#19547: 25.0.50; throw-on-input "fires" when switching workspace Michael Heerdegen
2015-01-09 19:59 ` Eli Zaretskii
2015-01-09 21:48 ` Michael Heerdegen
2015-01-10 9:14 ` Eli Zaretskii
2015-01-09 23:33 ` Stefan Monnier
2015-01-10 0:00 ` Michael Heerdegen
2015-01-10 1:26 ` Michael Heerdegen
2015-01-10 9:12 ` Eli Zaretskii
2015-01-10 22:24 ` Michael Heerdegen
2015-01-11 1:47 ` Stefan Monnier
2015-01-20 2:46 ` Michael Heerdegen
2015-01-20 3:43 ` Eli Zaretskii
2015-01-29 19:59 ` Michael Heerdegen
2015-01-31 8:38 ` Eli Zaretskii
2015-02-01 14:25 ` Michael Heerdegen
2015-02-01 15:54 ` Eli Zaretskii
2015-02-01 17:21 ` Michael Heerdegen
2015-02-01 17:35 ` Eli Zaretskii
2015-10-13 10:50 ` Michael Heerdegen
2015-12-10 20:14 ` John Wiegley
2015-12-10 22:05 ` Michael Heerdegen
2015-12-10 23:01 ` John Wiegley
[not found] ` <83fuz98gre.fsf@gnu.org>
2015-12-11 10:17 ` Thierry Volpiatto
[not found] ` <838u518d32.fsf@gnu.org>
2015-12-11 14:22 ` Michael Heerdegen
[not found] ` <83r3it6m5u.fsf@gnu.org>
2015-12-26 0:37 ` Michael Heerdegen
2015-12-26 10:01 ` Eli Zaretskii
2015-01-10 9:18 ` Eli Zaretskii
2016-11-08 18:28 ` bug#19547: Patch for this bug Reuben Thomas
2016-11-08 20:40 ` Eli Zaretskii
2016-11-08 22:20 ` Reuben Thomas [this message]
2016-11-09 19:43 ` Eli Zaretskii
2016-11-09 22:03 ` Reuben Thomas
2016-11-10 17:46 ` Eli Zaretskii
2016-11-25 17:10 ` Thierry Volpiatto
2016-11-26 7:40 ` Eli Zaretskii
2016-11-26 8:39 ` Andreas Schwab
2016-11-26 9:02 ` Eli Zaretskii
2016-11-26 18:50 ` Thierry Volpiatto
2016-11-27 6:52 ` Thierry Volpiatto
2016-11-27 14:07 ` npostavs
2016-11-27 14:53 ` Thierry Volpiatto
2016-11-27 15:54 ` Eli Zaretskii
2016-11-27 17:59 ` Thierry Volpiatto
2016-11-27 18:40 ` Eli Zaretskii
2016-11-27 19:03 ` Thierry Volpiatto
2016-11-27 19:39 ` Eli Zaretskii
2016-11-27 19:54 ` Thierry Volpiatto
2016-11-27 20:06 ` Eli Zaretskii
2016-11-27 20:53 ` Thierry Volpiatto
2016-11-30 20:27 ` Thierry Volpiatto
2016-12-01 3:28 ` Eli Zaretskii
2017-06-11 22:03 ` npostavs
2016-11-27 18:42 ` npostavs
2016-11-27 19:08 ` Thierry Volpiatto
2016-11-27 7:16 ` Thierry Volpiatto
2016-11-27 18:05 ` Reuben Thomas
2016-11-27 18:29 ` Thierry Volpiatto
2016-11-27 21:10 ` Johan Bockgård
2016-11-28 6:00 ` Thierry Volpiatto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOnWdoivvpDR2Lg9pk5ADSVVsQqOxAQmD38BXb==w6SbgW79CQ@mail.gmail.com' \
--to=rrt@sc3d.org \
--cc=19547@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).