bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16526: 24.3.50; scroll-conservatively & c-mode regression


From: martin rudalics
Subject: 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]