From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#19547: Patch for this bug Date: Tue, 8 Nov 2016 22:20:11 +0000 Message-ID: References: <874ms03qj1.fsf@web.de> <8360nxhfiw.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ebaa6392c690540d18b10 X-Trace: blaine.gmane.org 1478643680 29345 195.159.176.226 (8 Nov 2016 22:21:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Nov 2016 22:21:20 +0000 (UTC) Cc: 19547@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 08 23:21:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4ElS-0006Rv-KN for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2016 23:21:10 +0100 Original-Received: from localhost ([::1]:35800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4ElV-0000nX-JV for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2016 17:21:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4ElO-0000nG-1I for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 17:21:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4ElJ-0002zH-V1 for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 17:21:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34707) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4ElJ-0002z9-RT for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 17:21:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c4ElJ-0005q4-KI for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2016 17:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Nov 2016 22:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19547 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19547-submit@debbugs.gnu.org id=B19547.147864362122390 (code B ref 19547); Tue, 08 Nov 2016 22:21:01 +0000 Original-Received: (at 19547) by debbugs.gnu.org; 8 Nov 2016 22:20:21 +0000 Original-Received: from localhost ([127.0.0.1]:50106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4Ekf-0005p2-1e for submit@debbugs.gnu.org; Tue, 08 Nov 2016 17:20:21 -0500 Original-Received: from mail-lf0-f53.google.com ([209.85.215.53]:35441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c4Ekb-0005ok-Hw for 19547@debbugs.gnu.org; Tue, 08 Nov 2016 17:20:19 -0500 Original-Received: by mail-lf0-f53.google.com with SMTP id b14so150494904lfg.2 for <19547@debbugs.gnu.org>; Tue, 08 Nov 2016 14:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uiEneZUSLsRFeKOtcSIllBLFrR3rRy1Fhn6iJCql5eg=; b=j7AQQRLTn4vafiaX0Qg6CejgNF2zojJaNszvV5io7ATguCkVpwm4g9MgdJ58y62AOs o4KKL+wDRoxrbZq4ed413KgMKbGLriEWYk83bJoox6vq8qCNYMnmuD99lcCJKKJO1DJ+ IMZfnnvVdzn0LTAPF22Gha5Kqw7wofMsWT5IU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uiEneZUSLsRFeKOtcSIllBLFrR3rRy1Fhn6iJCql5eg=; b=KXeu/5bnZffXL0x4l05vIY4sR+8DWHANGzueaRQDLfGU3WHQpcuDjx+QAguCantjRj YB46KV5qwPM0iHg4vzyxbyIPHY6k+0VG5BzXHzefT09Zqcz+IwJEZC6YAxlbWx6js3o8 k3GPd5VXb5xHUkYLKcDiENst6TMQ7ZNJgIB7mbrsuWh2IatxaqRGYswRB6RvzGMiMvhL jUVxTwaRJDzHBQCo+TuScd2PYNiiAvAuReJ9JJcyAe2H6Gdex/R3vhS0rk4gW+MYhx9D KRlcEm3VW9ERM1YHeF/XKbjVNwC1vGv1FRC41gxh5R1IjzxFhzuPrG67tKM4XEuwvDQE eHNg== X-Gm-Message-State: ABUngvfiGI90dNJM/gBMShQorJQ90QlmH9TwBsA3BylFjxoGt8Wd0/VVW0Ewqc+OjwXebMh28J+VIx/vAGUQs2tt X-Received: by 10.25.139.195 with SMTP id n186mr8459408lfd.27.1478643611666; Tue, 08 Nov 2016 14:20:11 -0800 (PST) Original-Received: by 10.25.212.211 with HTTP; Tue, 8 Nov 2016 14:20:11 -0800 (PST) In-Reply-To: <8360nxhfiw.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125496 Archived-At: --001a113ebaa6392c690540d18b10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 November 2016 at 20:40, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 8 Nov 2016 18:28:28 +0000 > > > > Further, at present it would not help helm to implement Eli's suggestio= n > 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? > =E2=80=8BI'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. --=20 http://rrt.sc3d.org --001a113ebaa6392c690540d18b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 sugg= estion of a list of events for input-pending-p
> to ignore, as Helm currently does not use that (it has a custom versio= n of while-no-input that does not call
> input-pending-p).

The suggestion was not that specific.=C2=A0 The idea was to let Lisp
programs specify which special events they would like to consider as
input.=C2=A0 E.g., define a variable that holds a list of such events, and<= br> 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).=C2=A0 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.=C2=A0 Can you do that?
<= div>
= =E2=80=8BI'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 sufferi= ng from the bug.

I&= #39;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 wou= ld be sad to have to wait (perhaps forever!) for a "good" fix, wh= en 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, bu= t no (reasonable) application will be adversely affected by this fix.
=

--=C2=A0
http://rrt.sc3d.org
--001a113ebaa6392c690540d18b10--