From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Date: Mon, 14 Oct 2013 15:32:40 -0400 Message-ID: References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> <87pptmsv4z.fsf@engster.org> <83siyira0w.fsf@gnu.org> <87vc3drhuv.fsf@engster.org> <83haexrgjn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158c6f00b2a7804e8b88864 X-Trace: ger.gmane.org 1381779195 30399 80.91.229.3 (14 Oct 2013 19:33:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Oct 2013 19:33:15 +0000 (UTC) Cc: 15045@debbugs.gnu.org, David Engster , Eric Ludlam To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 14 21:33:18 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VVntF-00065G-RV for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2013 21:33:18 +0200 Original-Received: from localhost ([::1]:38464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVntF-00080L-ES for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2013 15:33:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVnt6-0007v7-8g for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2013 15:33:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVnt0-0001Wa-9A for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2013 15:33:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVnt0-0001WT-6x for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2013 15:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VVnsz-0001xY-LX for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2013 15:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2013 19:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13817791707460 (code B ref 15045); Mon, 14 Oct 2013 19:33:01 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 14 Oct 2013 19:32:50 +0000 Original-Received: from localhost ([127.0.0.1]:49288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVnsn-0001wD-UI for submit@debbugs.gnu.org; Mon, 14 Oct 2013 15:32:50 -0400 Original-Received: from mail-ob0-f176.google.com ([209.85.214.176]:46433) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VVnsk-0001vY-Pf for 15045@debbugs.gnu.org; Mon, 14 Oct 2013 15:32:47 -0400 Original-Received: by mail-ob0-f176.google.com with SMTP id wo20so5071788obc.21 for <15045@debbugs.gnu.org>; Mon, 14 Oct 2013 12:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DI5WH9EjLS0ckpXPdE84KKHveh+J4JqZQ9CDqOM5B+c=; b=Mw884mUWQ2fyCwqt7/JANYteDhr60ZRGH66cgSJpNb06wxfZz8arQ0eGOabp/IN2vY nWN6aLFTPAYc+9rn7S3N/5qK9Z3uwnj9RlHqa3ch1mUiklFnbfhUCcp5CZkyMjUJCSvs 4u+yjVZZ34tUJD5BuxOZCqNxixiPRIcBYbBT4NsYbEttYur04FbIxf1pm7lDw2Pkl1/r xTBRZWA7HBxTvOdUkn0m+IGsortlhfA5e5hcsRNZf2RtxChNvXoK6V+5pT5V6flz5/4K Mo1x1IRuqHaVXiHIepUaon8NYRn4jz5Rhy7CoifnRqpKHhcqy75hFZONViqAhgh4aVUz Sa/Q== X-Received: by 10.182.50.130 with SMTP id c2mr7926884obo.35.1381779160900; Mon, 14 Oct 2013 12:32:40 -0700 (PDT) Original-Received: by 10.76.156.103 with HTTP; Mon, 14 Oct 2013 12:32:40 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79247 Archived-At: --089e0158c6f00b2a7804e8b88864 Content-Type: text/plain; charset=ISO-8859-1 > >> >> That sounds wrong. > >> > Are you saying that using the READABLE_EVENTS_DO_TIMERS_NOW flag above > >> > is wrong? > >> I think so: input-pending-p is not expected to wait, so I don't see any > >> reason to run timers. > > I think the only reason, as with all the other places where we run > > timers, is to make Emacs look appear more responsive, notwithstanding > > the on-going processing. > > I suspect that the users of input-pending-p which care about running > timers would be better served by (sit-for 0 t). Currently, it's 100% > equivalent, but the intention is a lot more clear. Given this has come up again separately in bug 15567, may I make the change to input-pending-p? diff --git a/src/keyboard.c b/src/keyboard.c index e0cd4d4..fdb7c7d 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -9962,8 +9962,7 @@ if there is a doubt, the value is t. */) /* Process non-user-visible events (Bug#10195). */ process_special_events (); - return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW - | READABLE_EVENTS_FILTER_EVENTS) + return (get_input_pending (READABLE_EVENTS_FILTER_EVENTS) ? Qt : Qnil); } 'make check' passes. Eli Zaretskii: > What if input arrives because of a timer? If this is an issue, I propose input-pending-p return t if a timer is ready to run. Then the long running task would exit, unwind its save-excursion, then allow the timer to run. Perhaps this contorts the meaning of "input", but OTOH the documentation for input-pending-p already states that a false positive return can happen: Return t if command input is currently available with no wait. Actually, the value is nil only if we can be sure that no input is available; if there is a doubt, the value is t. Would you want this in the same changeset as the patch above? Or not worry about it until "someone screams"? --089e0158c6f00b2a7804e8b88864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> >> >> That sounds wrong.
> >>= > Are you saying that using the READABLE_EVENTS_DO_TIMERS_NOW flag abov= e
> >> > is wrong?
> >> I think so: input-pendin= g-p is not expected to wait, so I don't see any
> >> reason to run timers.
> > I think the only reason, a= s with all the other places where we run
> > timers, is to make Em= acs look appear more responsive, notwithstanding
> > the on-going = processing.
>
> I suspect that the users of input-pending-p which care about r= unning
> timers would be better served by (sit-for 0 t).=A0 Currently= , it's 100%
> equivalent, but the intention is a lot more clear.<= br>
Given this has come up again separately in bug 15567, may I make thechange to input-pending-p?

diff --git a/src/keyboard.c b/src/keyboa= rd.c
index e0cd4d4..fdb7c7d 100644
--- a/src/keyboard.c
+++ b/src/= keyboard.c
@@ -9962,8 +9962,7 @@ if there is a doubt, the value is t.=A0 */)
=A0=A0= /* Process non-user-visible events (Bug#10195).=A0 */
=A0=A0 process_sp= ecial_events ();
=A0
-=A0 return (get_input_pending (READABLE_EVENTS_= DO_TIMERS_NOW
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 | READABLE_EVENTS_FILTER_EVENTS)
+=A0 return (get_input_pendin= g (READABLE_EVENTS_FILTER_EVENTS)
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ? Qt : Qni= l);
=A0}
=A0
'make check' passes.

Eli Zaretskii: > What if input arrives because of a timer?

If this is an issue, = I propose input-pending-p return t if a timer is
ready to run. Then the = long running task would exit, unwind its
save-excursion, then allow the = timer to run. Perhaps this contorts the
meaning of "input", but OTOH the documentation for input-pending-= p
already states that a false positive return can happen:

=A0 Ret= urn t if command input is currently available with no wait.
=A0 Actually= , the value is nil only if we can be sure that no input is
=A0 available; if there is a doubt, the value is t.

Would you want t= his in the same changeset as the patch above? Or not
worry about it unti= l "someone screams"?

--089e0158c6f00b2a7804e8b88864--