GNU bug report logs - #12600
24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12600 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame
Date: Sat, 13 Oct 2012 19:45:20 +0200

>> (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?

>> (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.

>> (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.

>> 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.

>> 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 ;-)

> We are going in circles, so there must be some misunderstanding here.
> Can you describe your complete change suggestion, wrt these flags?  In
> particular, what about buffer_modified_flag, and how does it enter
> this picture?

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.

I care about BUF_MODIFF/BUF_OVERLAY_MODIFF only in one place: When
calculating `window-end' after a buffer change but before the next
redisplay, `window-end' with UPDATE non-nil has to consult
BUF_MODIFF/BUF_OVERLAY_MODIFF in order to be sure whether it can reuse
window_end_pos.  window_end_pos would be nil (invalid) initially, set to
a valid value when Fwindow_end updates it, and be reset to nil wherever
we change the value of window_modified.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.