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 16:31:43 +0300 Message-ID: <83li4brnwg.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> <5204D77B.2040900@siege-engine.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1376055197 3476 80.91.229.3 (9 Aug 2013 13:33:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2013 13:33:17 +0000 (UTC) Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, deng@randomsample.de To: "Eric M. Ludlam" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 09 15:33:17 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 1V7mod-00054H-Bx for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 15:33:15 +0200 Original-Received: from localhost ([::1]:41509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7mod-0005Zm-0T for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 09:33:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7moV-0005Zb-5Z for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 09:33:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7moQ-0000Mz-HO for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 09:33:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7moQ-0000Mu-Ei for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 09:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V7moQ-0003Ll-5I for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 09:33: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 13: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.137605513912808 (code B ref 15045); Fri, 09 Aug 2013 13:33:01 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 13:32:19 +0000 Original-Received: from localhost ([127.0.0.1]:49245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7mni-0003KV-Id for submit@debbugs.gnu.org; Fri, 09 Aug 2013 09:32:19 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47262) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7mnf-0003KE-BU for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 09:32:16 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MR900L00MTXIZ00@a-mtaout20.012.net.il> for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 16:31:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900LQVMWD3XA0@a-mtaout20.012.net.il>; Fri, 09 Aug 2013 16:31:26 +0300 (IDT) In-reply-to: <5204D77B.2040900@siege-engine.com> 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:77156 Archived-At: > Date: Fri, 09 Aug 2013 07:50:19 -0400 > From: "Eric M. Ludlam" > CC: David Engster , gundaetiapo@gmail.com, > monnier@iro.umontreal.ca, 15045@debbugs.gnu.org > > > IOW, it's the caller of input-pending-p etc. that is the fault here, > > not the timers that it inadvertently lets run. > > In my mind, to anyone using input-pending-p to deal with responsiveness > in long running code, a timer that causes a redisplay is the source of > the problem. Emacs is a complex piece of software. We cannot remove that complexity no matter how hard we try. And yes, this requires developers to be aware of what can happen when they call certain APIs. There's nothing new here. > Even if we resolve which is the real bug, or at least the proposed > solution here, people will still cause redisplays in timeres, and call > input-pending-p in long running code, and those problems will need to be > debugged again in the future. Again, nothing new. It's okay to propose solutions to these issues, but a "solution" which tells timers not to force redisplay is a non-starter, IMO, because some of them cannot do their thing without displaying something at specific times. > * In a timer, disallow dispatch of other timers until done. Sounds not a good idea to me, as too many useful features use timers, and users will be surprised to see them sometimes unable to run. > * Record redisplay requests in timers, and force redisplay when the > timer exists. Not good for timers that must display at certain times, with minimal delays. > * In input-pending-p, dont' allow new timers to run, > doc only talks about command input, not timers. What if input arrives because of a timer? > * In timers, redisplay always assumes you don't want to move point and > puts it back before the draw. Redisplay doesn't have any idea where is "back". When redisplay is entered, it finds point at a certain location. It has no idea where it was before, all it knows (in some cases, not all of them) is where point was in each window during the last redisplay cycle, which could be 5 msec ago or 5 min ago. > It is clear to me that there are valid use cases for both redisplay in a > timer, and input-pending-p being used in long-running programs. Adding > funky restrictions to either seems untenable with the size of the Emacs > dev community. It would be better to tackle the problem at its source. I'm sorry, but I don't see "the source" here. What is the source of the problem, in your opinion? In my opinion, the source of the problem is that application code moves point to a place it didn't intend the user to see, and then calls some APIs that trigger redisplay and reveal that location of point (and potentially even cause a scroll). The solution could be (a) avoid triggering redisplay, or (b) restore point before calling something that could cause redisplay. What other solutions do you envision that don't limit the basic features involved in this?