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

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

bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh wh


From: Eli Zaretskii
Subject: bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame
Date: Sun, 14 Oct 2012 14:06:57 +0200

> Date: Sun, 14 Oct 2012 12:21:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
> 
>  >> Replace the three struct members last_modified, last_overlay_modified
>  >> and window_end_valid by one struct member called last_modified_flag -
>  >> actually calling it window_modified would be better.  Set
>  >> window_modified to t wherever we currently reset one of the three
>  >> members.  Redisplay, when fully done, would reset window_modified to nil
>  >> for every window it completes instead of setting the other members.
>  >
>  > And when a buffer is modified or its overlays are modified, what
>  > should we do to indicate to redisplay that the corresponding windows
>  > might need a more thorough redisplay?
> 
> When a window shows a buffer that has been modified since the last
> redisplay, that buffer must be redrawn.  More precisely, redisplay would
> walk all live windows and for each window
> 
> (1) Redraw if something in the window's buffer or a setting affecting
>      the display of all buffers (like the cursor type) was modified.

How do you know whether the window's buffer was modified, under your
suggestion?  Won't we need some record of "the last buffer state when
this window was displayed"?  E.g., how do we know that point moved
since last full redisplay of the window?

> (2) Redraw if the window itself has been modified.

You mean, its dimensions or start-point?  Or something else?

> (3) Don't redraw the window otherwise.  This would cover the case where
>      `point' was moved in a buffer not shown in this window or another
>      window was scrolled.
> 
> This would replace checking of windows_or_buffers_changed with a
> finer-grained has "this window or its buffer changed".  But after a
> cursory look at redisplay_window I doubt that such a change would be
> feasible.  And I have no idea to which extent (3) is already covered by
> try_window_id.

The normal "do-nothing" route is to call try_cursor_movement, then
"goto done".  try_window_id is called only if there's some change that
requires redisplaying some of the text, not just moving the cursor.





reply via email to

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