emacs-devel
[Top][All Lists]
Advanced

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

Re: delete-overlay causes recentering


From: Chong Yidong
Subject: Re: delete-overlay causes recentering
Date: Sun, 15 Apr 2007 15:06:41 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux)

Chong Yidong <address@hidden> writes:

>> The behavior arose from the following change:
>>
>> 2006-04-20  Kim F. Storm  <address@hidden>
>>
>>      * xdisp.c (redisplay_window): Fix last change.
>>
>>      * xdisp.c (redisplay_window): If current window start is not at the
>>      beginning of a line, select a new window start if buffer is modified
>>      and window start is in the modified region, but the first change is
>>      before window start.

The problem is in the part of the code at xdisp.c:13145:

    /* Make sure beg_unchanged and end_unchanged are up to date.
       Do it only if buffer has really changed.  This may or may
       not have been done by try_window_id (see which) already. */
    if (MODIFF > SAVE_MODIFF
        /* This seems to happen sometimes after saving a buffer.  */
        || BEG_UNCHANGED + END_UNCHANGED > Z_BYTE)
      {
        if (GPT - BEG < BEG_UNCHANGED)
          BEG_UNCHANGED = GPT - BEG;
        if (Z - GPT < END_UNCHANGED)
          END_UNCHANGED = Z - GPT;
      }

This code seems to be copied from try_window_id.  I am not sure what
the original justification for this is, but it is a little too strict
when it comes to overlay changes.

That's because modify_overlay (buffer.c:3703), which is used to mark
overlay changes, calls BUF_COMPUTE_UNCHANGED, which alters
BUF_BEG_UNCHANGED and BUF_END_UNCHANGED directly without moving the
gap.  However, the result is that the "make sure beg_unchanged and
end_unchanged are up to date" check, which compares these to the
actual gap positions, thinks more of the buffer has been modified than
it actually has.  It then proceeds to recenter the display.

If we use the original values of BEG_UNCHANGED and END_UNCHANGED,
before it is "updated" by the above code, the spurious recentering
does not take place.  The original (2006) test case also seems to
behave OK -- in that case, we recenter correctly.  However, I can't be
certain this is correct because I don't know the original
justification for the above check.

WDYT?





reply via email to

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