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: Wed, 16 Oct 2013 10:57:31 -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> <83ppr7pr6c.fsf@gnu.org> <83li1upkfx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11348918b9571a04e8dceb3c X-Trace: ger.gmane.org 1381935495 3699 80.91.229.3 (16 Oct 2013 14:58:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Oct 2013 14:58:15 +0000 (UTC) Cc: 15045@debbugs.gnu.org, David Engster , Eric Ludlam To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 16 16:58: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 1VWSYE-0005EK-J2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Oct 2013 16:58:18 +0200 Original-Received: from localhost ([::1]:47774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWSYE-0001Z4-6M for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Oct 2013 10:58:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWSY4-0001XR-RW for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2013 10:58:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWSXy-0007nv-Me for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2013 10:58:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWSXy-0007ni-As for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2013 10:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VWSXy-0004XW-4e for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2013 10:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2013 14:58:02 +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.138193546117419 (code B ref 15045); Wed, 16 Oct 2013 14:58:02 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 16 Oct 2013 14:57:41 +0000 Original-Received: from localhost ([127.0.0.1]:54388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWSXc-0004Ws-G1 for submit@debbugs.gnu.org; Wed, 16 Oct 2013 10:57:41 -0400 Original-Received: from mail-oa0-f49.google.com ([209.85.219.49]:57564) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VWSXZ-0004We-Uv for 15045@debbugs.gnu.org; Wed, 16 Oct 2013 10:57:38 -0400 Original-Received: by mail-oa0-f49.google.com with SMTP id j10so593768oah.22 for <15045@debbugs.gnu.org>; Wed, 16 Oct 2013 07:57:32 -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=wZKYCjg1+cVhZkQSs4pZTpq0XC9R4JCY0qw3cvOYArI=; b=Mp3DZ8ZADors64ZT28mhPjwoV2srW/RqXS+Ohewu9+068WkOMAsHAHcIrOkGyjYOwS JoaSTdmYnsaCEFaNago+QGyhNiJsNBIc7dVksNGUVTLGOvv1Xss/2GfAXOp16nuRMtPS fSExe28XbmUcGR7OGKsfU0YsznAoNXBTlNpqlGfaQiYX2M6HAcWJbZ2qyKP4BYANJfGk pYzaaH9G4FUSXGdbH9xtkzsjPZZo3JuG1k/VAFLLNJSnoSvVlDSK6sTNDC/5Rcu/qts1 N7Ofzoo/gMc8d2b202rI5LKymFvF9AzYhue8usZ7wLZJH06kE0QMJngHoVgqwWGItNfE jiHg== X-Received: by 10.182.149.234 with SMTP id ud10mr674979obb.73.1381935452082; Wed, 16 Oct 2013 07:57:32 -0700 (PDT) Original-Received: by 10.76.156.103 with HTTP; Wed, 16 Oct 2013 07:57:31 -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:79312 Archived-At: --001a11348918b9571a04e8dceb3c Content-Type: text/plain; charset=ISO-8859-1 > The easiest solution is to add an optional argument `check-timers' > to input-pending-p, so you can preserve the exact same behavior. I assume you mean no-check-timers, nil being default. > In the long run, we should try and clean up sit-for, but you may not > have the courage to dig into this right now. I'm arguing I don't need to dig into sit-for's complexity to maintain its current behavior. If (sit-for 0 ...) calls something like thread-yield which in turn calls timer_check, then all ways of calling sit-for would have unchanged behavior. Even so, because of other calls to input-pending-p not through sit-for, there could conceivably be regressions in the latencies of timers, due to background tasks not yielding when they used to. If we discovered such cases, the solution is straight forward: replace (input-pending-p) with (sit-for 0 t) in the offending background task. But I understand the objection. If the no-check-timers arg solution is what you want, I'll prepare a patch to add it and have Semantic and NXML use it. Also, what do you think are the merits of putting in the specpdl-walking check discussed earlier, enabled with --enable-checking? I can't see a legit case where check_timers is called when point is on an excursion. Such code should not make any assumptions about the other timers the user is running which might call redisplay. > The current state of the concurrency branch is not always > representative of what it should ideally look like ;-) But even if > timers are made to belong to a thread, thread-yield should probably > check timers. The timer behavior on the concurrency branch seems reasonable. Moving them to their own threads might be complex, not least because of concerns that the global lock will be yielded often enough to not regress timer latencies. --001a11348918b9571a04e8dceb3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> The easiest solution is to add an optional argument `= check-timers'
> to input-pending-p, so you can preserve the exact= same behavior.

I assume you mean no-check-timers, nil being default= .

> In the long run, we should try and clean up sit-for, but you may n= ot
> have the courage to dig into this right now.

I'm argu= ing I don't need to dig into sit-for's complexity to maintain
its current behavior. If (sit-for 0 ...) calls something like
thread-yie= ld which in turn calls timer_check, then all ways of calling
sit-for wou= ld have unchanged behavior.

Even so, because of other calls to input= -pending-p not through
sit-for, there could conceivably be regressions in the latencies of
time= rs, due to background tasks not yielding when they used to. If we
discov= ered such cases, the solution is straight forward: replace
(input-pendin= g-p) with (sit-for 0 t) in the offending background task.
But I understand the objection.

If the no-check-timers arg solution = is what you want, I'll prepare a
patch to add it and have Semantic a= nd NXML use it.

Also, what do you think are the merits of putting in= the
specpdl-walking check discussed earlier, enabled with
--enable-checking?= I can't see a legit case where check_timers is
called when point is= on an excursion. Such code should not make any
assumptions about the ot= her timers the user is running which might
call redisplay.

> The current state of the concurrency branch is = not always
> representative of what it should ideally look like ;-) B= ut even if
> timers are made to belong to a thread, thread-yield shou= ld probably
> check timers.

The timer behavior on the concurrency branch seem= s reasonable. Moving
them to their own threads might be complex, not lea= st because of
concerns that the global lock will be yielded often enough= to not
regress timer latencies.

--001a11348918b9571a04e8dceb3c--