From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Mon, 27 Jan 2014 18:26:10 +0100 Message-ID: <52E696B2.30903__25478.3765566119$1390843663$gmane$org@gmx.at> 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> <83bnyx9yxl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390843650 26520 80.91.229.3 (27 Jan 2014 17:27:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2014 17:27:30 +0000 (UTC) Cc: acm@muc.de, 16526@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 27 18:27:36 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 1W7py7-0003eA-Tv for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jan 2014 18:27:32 +0100 Original-Received: from localhost ([::1]:60895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7py7-0003aP-Fd for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jan 2014 12:27:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7pxw-0003aA-O6 for bug-gnu-emacs@gnu.org; Mon, 27 Jan 2014 12:27:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7pxp-0003X2-EE for bug-gnu-emacs@gnu.org; Mon, 27 Jan 2014 12:27:20 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7pxe-0003TN-SP; Mon, 27 Jan 2014 12:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W7pxe-00073N-CW; Mon, 27 Jan 2014 12:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 27 Jan 2014 17:27: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.139084358227052 (code B ref 16526); Mon, 27 Jan 2014 17:27:02 +0000 Original-Received: (at 16526) by debbugs.gnu.org; 27 Jan 2014 17:26:22 +0000 Original-Received: from localhost ([127.0.0.1]:38340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7pwz-00072F-4k for submit@debbugs.gnu.org; Mon, 27 Jan 2014 12:26:21 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:50940) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7pww-000725-Dz for 16526@debbugs.gnu.org; Mon, 27 Jan 2014 12:26:19 -0500 Original-Received: from [62.47.49.194] ([62.47.49.194]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LmJsk-1VXwtv2Fow-00a16A for <16526@debbugs.gnu.org>; Mon, 27 Jan 2014 18:26:17 +0100 In-Reply-To: <83bnyx9yxl.fsf@gnu.org> X-Provags-ID: V03:K0:awDQ7gEhU93pDfLLX9vlzrAWwoFE37KZ4GHcMRef2+MxyloYnzc QA2EmJcribVmStLMejuSi07Q4UT408LI6qSU4x8tl6IczW61Q3CiYIQgsBuh0ptTJopkfXG 8ZIURs9DZEJZsCx8QBIlvxW32qqSmVTw6b2YF6jKyXZVqqXKgPpzSTwfAzueQCPMO3jibvW uDiSqfoLO3oCAqbO4CxOQ== 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:84129 Archived-At: > 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. At least now I understand why setting `scroll-conservatively' to 101 can be expensive. >> 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. I see. Fontification routines just get the boundaries they have to operate on. The backtrace is difficult to interpret - I never know which of Alan's macros save excursion. But since it returns a buffer position it likely that it reuses that position later on. >> 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. I just wanted to make sure that there's no loop in try_scrolling. > Why shouldn't CC Mode be aware that point is at BOB? It has just to > look at its value. It shouldn't matter anyway since, as you said above, the display engine never sets point. Thanks for the clarifications. My questions were naive because I never looked into how scrolling works and moreover do not understand c-mode macros well. martin