From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.bugs Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Date: Fri, 09 Aug 2013 18:10:04 +0200 Message-ID: <87pptmsv4z.fsf@engster.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1376064905 19368 80.91.229.3 (9 Aug 2013 16:15:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2013 16:15:05 +0000 (UTC) Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, eric@siege-engine.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 09 18:15:04 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 1V7pLE-0000ww-Fw for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 18:15:04 +0200 Original-Received: from localhost ([::1]:52963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7pLE-0001k5-2I for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 12:15:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7pL6-0001fi-KG for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 12:15:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7pHL-0006ui-Gh for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 12:11:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7pHL-0006uZ-A1 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 12:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V7pHK-00010J-61 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 12:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Engster Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 16:11: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.13760646193749 (code B ref 15045); Fri, 09 Aug 2013 16:11:02 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 16:10:19 +0000 Original-Received: from localhost ([127.0.0.1]:49962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pGZ-0000yG-MJ for submit@debbugs.gnu.org; Fri, 09 Aug 2013 12:10:16 -0400 Original-Received: from randomsample.de ([83.169.19.17]:45097) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7pGS-0000xx-I0 for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 12:10:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=PfaCMo+v/XNcc/V3/FIP/a6mVnVvpHBQQJI2gGRGNUU=; b=tAYVe1oQSmRjRjpl9XYZvO1KjqbY6fFNw0p+DI3xy3ogzK3AVyWbFv4rld626mfTRJ+YAmUREolE0BE+lF2Lz230b5/1m1++I3sT9olSYPVGD+geO91j9H7Vp+FvKOuM; Original-Received: from dslc-082-083-054-159.pools.arcor-ip.net ([82.83.54.159] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7pGP-0000QO-2p; Fri, 09 Aug 2013 18:10:05 +0200 In-Reply-To: <83zjsrs3k2.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Aug 2013 10:53:33 +0300") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) 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:77179 Archived-At: Eli Zaretskii writes: >> From: David Engster >> Cc: gundaetiapo@gmail.com, monnier@iro.umontreal.ca, >> 15045@debbugs.gnu.org, eric@siege-engine.com > >> Date: Fri, 09 Aug 2013 07:36:07 +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? After which idle time does redisplay kick in anyway? >> AFAICS, any function that calls things like >> `accept-process-output', `input-pending-p' or `sit-for' inside a >> `save-excursion' might get an unwanted scrolling effect if point is >> temporarily moved to some invisible location. > > You mean, because of timers that might get run and cause redisplay? Yes. > Yes, that's possible. But the way to avoid this is to never call > these when point is in a place the user won't expect. Forcing the > Emacs community not to trigger redisplay inside timers is IMO _not_ > the right way, because this is unnecessarily restrictive, and would > disallow a whole bunch of useful features for no good reason. I said: "doing redisplay in timers is not nice". I did not say that it should be forbidden (if that's even possible). However, I do propose the following: - Deleting the 'sit-for' in the display-time-event-handler, since I would think that it is the most likely suspect for a non-idle timer that does redisplay in a usual Emacs session. The force-mode-line-update should be enough, and even if it isn't: if the minute is updated half a second too late, we can live with that (we can already live with a displayed 'load' value that's up to a minute old). - In (info "(elisp) Timers"), the manual already discourages certain things in timers, like changing buffer content or waiting with `sit-for'. I think we should add something like this: "Also, enforcing a redisplay in non-idle timers is problematic, since they may run at times when other functions have moved point or narrowed the buffer temporarily. The redisplay would make these visible, leading to unwanted scrolling or sudden narrowing and subsequent widening of the buffer. You should rather try if waiting for the next redisplay after the timer has run is sufficient for your needs. If you just change the mode-line, use `force-mode-line-update' instead of a full redisplay." - We should add information to the documentation of `access-process-output' and `input-pending-p', like "Note that timers may run during this function, which may trigger a redisplay. So before calling this function, you should make sure that any temporary changes you made to point position or the buffer (like narrowing) are undone, as to not make these changes visible." 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. > 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. >> 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. Also, the bug is slightly different in that speck does not only alter point, but also narrows the buffer, which is even more scary than unwanted scrolling. >> I thought that the jit-lock timer is a non-idle timer, but you are >> right. > > There's no jit-lock timer. Yes. Sorry for being imprecise. I meant the jit-lock defer timer. -David