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#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Mon, 27 Jan 2014 18:23:02 +0200 Message-ID: <83bnyx9yxl.fsf@gnu.org> References: <52E38286.1050306@gmx.at> <838uu4cq11.fsf@gnu.org> <52E3D131.2090705@gmx.at> <83r47wausm.fsf@gnu.org> <52E3EAC2.2040100@gmx.at> <83lhy4as2l.fsf@gnu.org> <52E4019C.5080905@gmx.at> <83k3dnc3rl.fsf@gnu.org> <83iot7c3bq.fsf@gnu.org> <52E4EF61.3050404@gmx.at> <831tzubqxw.fsf@gnu.org> <52E616E9.2040807@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390839868 9961 80.91.229.3 (27 Jan 2014 16:24:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2014 16:24:28 +0000 (UTC) Cc: acm@muc.de, 16526@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 27 17:24:30 2014 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 1W7oz3-00013s-2i for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jan 2014 17:24:25 +0100 Original-Received: from localhost ([::1]:60420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7oz2-0005Nr-Lh for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jan 2014 11:24:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7oyu-0005NN-Gf for bug-gnu-emacs@gnu.org; Mon, 27 Jan 2014 11:24:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7oyp-0007nZ-R8 for bug-gnu-emacs@gnu.org; Mon, 27 Jan 2014 11:24:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7oyg-0007k6-JZ; Mon, 27 Jan 2014 11:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W7oyg-0005Sz-8M; Mon, 27 Jan 2014 11:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 27 Jan 2014 16:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16526 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 16526-submit@debbugs.gnu.org id=B16526.139083979520954 (code B ref 16526); Mon, 27 Jan 2014 16:24:02 +0000 Original-Received: (at 16526) by debbugs.gnu.org; 27 Jan 2014 16:23:15 +0000 Original-Received: from localhost ([127.0.0.1]:38292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7oxu-0005Rt-3b for submit@debbugs.gnu.org; Mon, 27 Jan 2014 11:23:14 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:58298) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7oxq-0005Ri-9X for 16526@debbugs.gnu.org; Mon, 27 Jan 2014 11:23:11 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N0200N00ID31M00@mtaout26.012.net.il> for 16526@debbugs.gnu.org; Mon, 27 Jan 2014 18:22:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0200IHOIT88O70@mtaout26.012.net.il>; Mon, 27 Jan 2014 18:22:21 +0200 (IST) In-reply-to: <52E616E9.2040807@gmx.at> 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:84121 Archived-At: > Date: Mon, 27 Jan 2014 09:20:57 +0100 > From: martin rudalics > CC: acm@muc.de, 16526@debbugs.gnu.org > > Well... try_scrolling could detect that `point' is some 15000 lines away > from the current window start so trying to scroll the window as little > as possible might not be worth the effort. How would it detect that, except using the same method it uses now? Note that we are not talking physical lines in the buffer here, we are talking screen lines. Actually, not even that: we are talking _canonical_ screen lines, i.e. practically pixels. Now, those 15000 lines could well be covered by an invisible property, or by a display property that displays something other than buffer text. Or they could use a face that calls for a very small font, so that all the 15000 lines take very little screen estate. In all of these cases, a user who sets scroll-conservatively to 101 wants the screen scrolled rather than recentered. So that's what try_scrolling tries to do. It's why that function exists. However, try_scrolling's search is limited, so it normally fails very quickly. Except that in this case, the code invoked by JIT Lock hogs the CPU for a very long time. > > And here's where things go awry: For some reason, the CC Mode > > fontification code decides it needs to scan the buffer backwards, > > starting from EOB. So it goes temporarily to EOB (this is why I saw > > point being there), and scans all the way back, I think in this loop > > from c-append-lower-brace-pair-to-state-cache, which is called with > > its first argument FROM set to EOB: > > But it's redisplay which temporarily puts `point' at EOB and triggers > the fontification subsystem to "work" at that position? No, redisplay doesn't change point, not ever. It's cc-engine's routines that do it in this case, and I've shown where in the code that happens, see the backtrace I posted. > > This loop takes a lot of time, of course, and is a waste of time, > > since eventually try_scrolling comes to the correct conclusion that > > scrolling is impossible, and instead recenters at BOB. > > Are you sure that try_scrolling doesn't call this loop over and over > again? Sorry, I don't understand the question. try_scrolling doesn't include any loops where all this happens, it just calls move_it_to, a single call. All the rest happens inside that call. Normally, that call should just descend a few screen lines starting at point (which is at BOB), until it hits the limit I mentioned above, and then try_scrolling should return a failure indication. I did verify that there's a single call to move_it_to, and that all the time you wait is spent inside that call. > > Why does CC Mode decide to go from EOB backwards, I don't know; > > presumably, this is decided by c-parse-state-get-strategy as part of > > c-parse-state-1. > > This seems obvious. To decide whether code shall be fontified this way > or another it has to decide whether the code is part of a comment and > find that comment's start. As long as it is not aware of the fact that > `point' is already at BOB, obviously. Why shouldn't CC Mode be aware that point is at BOB? It has just to look at its value.