From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Date: Fri, 09 Aug 2013 21:31:27 +0300 Message-ID: <83siyira0w.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1376073135 12722 80.91.229.3 (9 Aug 2013 18:32:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2013 18:32:15 +0000 (UTC) Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com To: David Engster Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 09 20:32:16 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 1V7rTz-0001IW-4a for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 20:32:15 +0200 Original-Received: from localhost ([::1]:33262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7rTy-0002Nc-PW for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 14:32:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7rTr-0002Kj-UB for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 14:32:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7rTn-0007cy-AR for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 14:32:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7rTn-0007cs-7E for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 14:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V7rTm-0006fn-Go for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 14:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 18:32: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.137607308125558 (code B ref 15045); Fri, 09 Aug 2013 18:32:02 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 18:31:21 +0000 Original-Received: from localhost ([127.0.0.1]:50220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rT6-0006e8-EF for submit@debbugs.gnu.org; Fri, 09 Aug 2013 14:31:20 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45627) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7rT2-0006da-K4 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 14:31:18 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MRA000000Q8AT00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 21:31:10 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRA0008D0RX5860@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 21:31:10 +0300 (IDT) In-reply-to: <87pptmsv4z.fsf@engster.org> X-012-Sender: halo1@inter.net.il 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:77206 Archived-At: > From: David Engster > Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, 15045@debbugs.gnu.org, eric@siege-engine.com > Date: Fri, 09 Aug 2013 18:10:04 +0200 > > >> >> However, doing redisplay in timers is not nice. > >> > > >> > Why not? > >> > >> Because doing redisplay is a user-visible side effect, and in general, > >> timers shouldn't have those. > > > > How else can a timer such as that of display-time do its thing? IOW, > > when the purpose of a timer is to cause something to be displayed, > > they have no alternative but to force redisplay. > > As you know, Emacs does not have strict timers. If you say to Emacs: one > minute from now, say 'foo', and Emacs happens to be busy one minute from > now, nothing will happen until it waits again. So I wonder: with such a > lenient definition of "timer", does the wait for the next redisplay > really matter? Emacs very seldom is busy for a long time, so in practice you will see the 1-min timer do its thing pretty much on time. > After which idle time does redisplay kick in anyway? Redisplay doesn't count idle time to kick in, so there's no answer to your question. Redisplay is triggered by several reasons, one of them being waiting for keyboard input, which you might call "being idle", although that's not exactly accurate. > As a sidenote: What "bunch of useful features" do you have in mind for > non-idle timers that do redisplay? They shouldn't alter buffer content, > so what can they do that would need immediate redisplay? Displaying some > kind of progress/time indicator is pretty much the only thing I can come > up with. Any display-related feature, such as blinking something, displaying something ion the mode line or header line, etc. Altering a buffer can be one of the effects, btw, e.g. in a feature that shows the list of processes on a system and refreshes that list every second. > > IOW, it's the caller of input-pending-p etc. that is the fault here, > > not the timers that it inadvertently lets run. > > Until yesterday, I was completely unaware that `accept-process-output' > or `input-pending-p' could run timers that do redisplay, and I think I'm > in good company. The doc-strings do not mention it, so there must be > lots of third-party code which does not pay attention to this, so we > should try that this bug triggers as little as possible. I agree that the doc strings should make a prominent reference to this issue. > >> In fact, I just understood another bug in speck-mode (which is similar > >> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw > >> that those also happen at every full minute while typing. > > > > Then there's the same bug there, that's all. > > Yes. But it shows that this bug is easy to make, and it's hard to track > down. It is also very rare.