[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: |
Sat, 13 Oct 2012 20:08:37 +0200 |
> Date: Sat, 13 Oct 2012 19:45:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
>
> >> (1) Change the window's buffer via `set-window-buffer'.
> >
> > This is taken care of by setting windows_or_buffers_changed.
>
> windows_or_buffers_changed is a global flag. How does redisplay find
> out _which_ window got a new buffer? Or does redisplay not care?
It doesn't care, in the sense that it always considers every window.
It _does_ care, in the sense that certain redisplay optimizations are
turned off when windows_or_buffers_changed is non-zero.
E.g., if nothing's changed since the last redisplay, then redisplay
will only enter try_cursor_movement for each window, quickly see that
point didn't move, and exit without doing anything. But if
windows_or_buffers_changed is non-zero, this optimizations is
disabled.
> >> (2) Change the size of the window (including toggling of scrollbars and
> >> fringes).
> >
> > Redisplay figures this out already, I think. Which commands/functions
> > make these changes?
>
> They all end up calling window_resize_apply.
They all also set windows_or_buffers_changed non-zero. So I think
these cases are already covered, as far as redisplay is concerned.
>
> >> (3) Change the buffer's position in the window (usually via scrolling,
> >> `set-window-point' and `set-window-start').
> >
> > These likewise set windows_or_buffers_changed, so they shouldn't be a
> > problem.
>
> But usually they affect only one window. Again, redisplay might not
> care. But I would be surprised that it doesn't handle such a simple
> case of optimization.
It tries. It disables fewer optimizations when last_modified is reset
than when windows_or_buffers_changed is non-zero. But I doubt that
this difference shows in many important situations. At least resizing
a window never affects only one window.
> >> Now in all of these cases, the respective routines in window.c would set
> >> the window's last_modified_flag to t, marking the window as dirty.
> >
> > I don't think this is necessary. Can you try without setting this
> > flag, and see if anything breaks?
>
> I said "would". last_modified_flag doesn't exist.
The same should be tru for the last_modified and last_overlay_modified
fields, which do exist.
> >> So why do we currently reset last_modified and last_overlay_modified in
> >> window.c?
> >
> > See above. Maybe I'm missing something, but
> > windows_or_buffers_changed should take care of all of this.
>
> OK. I'll comment them out after the feature freeze and we'll see ;-)
Thanks.
> 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?
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, (continued)
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Stefan Monnier, 2012/10/12
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/12
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/12
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame,
Eli Zaretskii <=
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/15
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/15
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/16
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/16
bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/15