GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

Message #91 received at 16526 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 16526 <at> debbugs.gnu.org
Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Mon, 27 Jan 2014 18:26:10 +0100

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.