Re: The unwarranted scrolling assumption

[Lennart Borgman <lennart.borgman@gmail.com>]

On Sat, Jun 19, 2010 at 10:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Sat, 19 Jun 2010 02:18:13 +0200
>> Cc: emacs-devel@gnu.org
>>
>> I just checked the code. w->current_matrix->begv/zv is only set in
>>
>>   mark_window_display_accurate_1 (w, accurate_p)
>>
>> That means that it has the value needed to set clip_changed as I suggested.
>
> You cannot base such general conclusions on what the code does now.
> Each API and each member of the structures we use _must_ live up to
> their contract, as documented in the source.  Any new code _must_
> follow those contracts, or else it will break Emacs some day, if not
> today.


Why do you assume that I have not checked this? Please see the
description of the begv/zv members.


>> >> IOW, we still need to find out why reconsider_clip_changes fails to
>> >> reset the clip_changed flag.
>>
>> I think I have explained that several times. narrow_to_region etc sets
>> clip_changed to 1 without ever caring about the state redisplay is in.
>
> That is true, but then reconsider_clip_changes is supposed to fix the
> value for redisplay's purposes.  The question is: why it seemingly
> fails in your case, when you lean on the <down> key, in the original
> recipe you posted?


I have explained that this happens because of the bad assumption that
narrow_to_region can set clip_changed and that redisplay later can
correct this. It is not true because redisplay does not have the
needed information (i.e. it does not know if the change was made after
last successful redisplay.)


>> I could go into more details, but is that necessary?
>
> Yes, it's necessary.  Without understanding the reasons of why
> reconsider_clip_changes fails, your patch cannot be accepted, because
> the need in such a patch and its correctness cannot be established.


Please see above.


> But please do not "go into details" of how narrow_to_region is wrong
> in setting the clip_changed flag.  That is not the issue here.  The
> issue is what happens in reconsider_clip_changes, that prevents it
> from resetting the clip_changed flag.


I am afraid if you do not want to look into those details ()that I
have told too many times already) you will not be able to understand
the problem.