Re: The unwarranted scrolling assumption

[Lennart Borgman]

On Thu, Jun 17, 2010 at 9:26 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Thu, 17 Jun 2010 21:14:04 +0200
>> Cc: address@hidden
>>
>> >  if (b->clip_changed
>> >           && !NILP (w->window_end_valid)
>> >           && w->current_matrix->buffer == b
>> >           && w->current_matrix->zv == BUF_ZV (b)
>> >           && w->current_matrix->begv == BUF_BEGV (b))
>> >    b->clip_changed = 0;
>> >
>> > So, if b->clip_changed is non-zero at entry to reconsider_clip_changes,
>> > and w->window_end_valid is non-nil, as you say, this code should have
>> > reset b->clip_changed to zero.  And yet you say it didn't.  Why not?
>> > what prevented it from doing so?
>>
>> I thought so first too, but please see the message I just sent with an
>> explanation of the patches I sent.
>
> Sorry, that doesn't explain it to me, because narrowing is not part of
> the recipe at all.
>
> Again, PLEASE answer my questions, if you really want my help in
> understanding this issue.  What parts of the above condition prevented
> reconsider_clip_changes from resetting b->clip_changed to zero?  If
> needed, please re-run under GDB (without your patches) and see what
> other factors are at work here.

I can now answer you question again since I have found a new way to
make "jumping scrolling" appear. However the situation above is not
involved, at least not directly, since ->clip_changed is 0. (I think
there is an unused global variable clip_changed that is not used.)

The situation is now this:
- I am using my patch (in the state I sent it here).
- I have seen no problem with the patch (but as I said I think there
is one problem though it has not shown up).
- It is quite hard to make Emacs do the "jumping scrolling".

So it is better, still there are problems.

- It is possible to still get Emacs to do the "jumping scrolling".
- To do that I narrow the buffer to 45 c, turn on visual-line mode and
add a wrap-prefix on the line.
- Then if I just hold down the down arrow it can happen after a while.
- My output shows that it is because try_scrolling failed.

Some variables as I see them now at the recenter: label in redisplay_window:
  scroll_step == 1
  temp_scroll_step == 0
  current_buffer->clip_changed ==0   Why current_buffer, there is a
variable buffer here?
  current_buffer->scroll_up_aggressively == 45459482, same down

BTW, the use of current_buffer here seems to me to be a bug.

And it is because clip_changed is 0 that try_scrolling is tested, see
the output here from the DebPrint below and some statement later:

  redisplay_window b try_scr, clip_changed=0, >= BEGV: 1, <= ZV: 1,
jtop=1, llmf=0
  try_scrolling SCROLLING_FAILED clear_glyph <---------------- This
seem to be the reason why try_scrolling failed.
  redisplay_window.SCROLLING_FAILED (This is the return value from
try_scrolling)
  redisplay_window.recenter centering_position=-1 (This is at the
"recenter:" label)

      DebPrint (("redisplay_window b try_scr, clip_changed=%d, >=
BEGV: %d, <= ZV: %d, jtop=%d, llmf=%d",
                 current_buffer->clip_changed,
                 CHARPOS (startp) >= BEGV,
                 CHARPOS (startp) <= ZV,
                 just_this_one_p,
                 last_line_misfit
                 ));

The line in the buffer it stopped at is wrapped once and is indented.

I guess an interesting part may be why clear_glyph_matrix failed. Do
you think there is something interesting there?