[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: |
Sat, 25 Jan 2014 19:25:32 +0100 |
>> Well ... so you know why it calls back_comment around the END of the
>> buffer?
>
> It starts at the end of the buffer, but then moves all the way back
> to the beginning.
IIUC `beginning-of-buffer' does set_point_both. Does that move all the
way back to the beginning?
> And yes, I know why: it's because scroll-conservatively causes
> redisplay to examine buffer text around point,
Where is `point' at that time?
> when it decides where
> to place window-start. This is triggered by redisplay after the move
> to the end of the buffer.
But the `end-of-buffer' call terminates cleanly after a few seconds -
that's what the `sit-for' proves in my code.
>> > What I see is that find_defun_start is called many times,
>>
>> ... 530 times as I mentioned earlier ...
>>
>> > with its
>> > first argument moving from _end_ of the buffer backwards.
>>
>> Not monotonously. Sometimes it's called from the same position (for
>> example 948653 is at least three times on my list) again.
>
> True. But I'm not sure this is relevant to the slow redisplay.
It hints at some really bad code embedded in really bad code.
>> > This
>> > happens when Emacs needs to redisplay the last portion of the buffer,
>> > immediately after the call to end-of-buffer.
>>
>> Hmm ... but the problem is when going to BOB.
>
> No, going to BOB is instantaneous. The problem happens in redisplay
> after going to EOB.
EOB happens before my `sit-for'.
>> > JIT Lock is triggered also when font-lock is turned on after the move
>> > to end of the buffer. But the difference seems to come from the fact
>> > that under scroll-conservatively, we examine the buffer a little bit
>> > above/below the window, when we decide where to put window-start.
>>
>> And somehow a "current position" is still near the end of the buffer at
>> that time.
>
> Yes, because Emacs is at EOB.
Why?
martin
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/23
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/24
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Alan Mackenzie, 2014/01/24
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Juanma Barranquero, 2014/01/24
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression,
martin rudalics <=
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/25
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/26
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Eli Zaretskii, 2014/01/26
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Alan Mackenzie, 2014/01/26
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/27
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Stefan Monnier, 2014/01/27
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, martin rudalics, 2014/01/27
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Stefan Monnier, 2014/01/27
- bug#16526: 24.3.50; scroll-conservatively & c-mode regression, Alan Mackenzie, 2014/01/29