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

Previous Next

Full log

Message #67 received at 12600 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#12600: 24.2.50; linum-mode: line numbers in fringe do not
	refresh when resizing frame
Date: Sat, 13 Oct 2012 11:51:46 +0200

>> last_modifed_flag is a fictitious variable I would set when the window
>> changes.  When it's set, redisplay must redisplay the window.
>
> What do you mean by "window changes"?  And how would any code outside
> of the display engine know whether some change requires to redisplay a
> window?

There are three types of window changes we have to consider:

(1) Change the window's buffer via `set-window-buffer'.

(2) Change the size of the window (including toggling of scrollbars and
    fringes).

(3) Change the buffer's position in the window (usually via scrolling,
    `set-window-point' and `set-window-start').

There might be indirect changes as well (e.g., when setting a window
display property) but let's stick to the three cited above.  All these
require usually a complete redisplay of the buffer in the window.  There
is one exception, namely when `split-window-keep-point' is nil,
`split-window-below' tries to keep the old display (but I doubt that
this works with variable height fonts and it will likely fail as soon as
we split windows pixel-wise).

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.  When
resizing or splitting windows, usually more than one window is affected;
for scrolling usually one window is affected.  When the display engine
scans windows, it has to redisplay a window when the flag is set,
resetting the flag when it's done.  Otherwise, it will redisplay the
window iff the buffer's modification flag says so.

Note that the last_modified_flag of the window covers both last_modified
and last_overlay_modified as far as the window's redisplay is concerned.

`window-end' with non-nil UPDATE requires a different treatment anyway
because it inspects a cached value that is invalidated either by a
buffer modification or a window change.  Hence the only simple solution
for this is to reset window_end_pos to nil whenenver we set that
window's last_modified_flag.  `window-end' then would update
window_end_pos either if it is nil or the buffer was modified since the
last redisplay.

> Anyway, I don't think the above is right.  Only the display engine
> should set this variable.  The display engine should figure out itself
> whether to redisplay a window, by using other means.  If it doesn't,
> that's a bug.

So why do we currently reset last_modified and last_overlay_modified in
window.c?

>> We'd obviously have an independent buffer_modified_flag.  A window must
>> be redisplayed if either buffer_modified_flag is set (modulo any
>> optimizations which I won't dispute here) or its last_modifed_flag is
>> set.
>
> But comparing the buffer's modiff with last_modified already
> accomplishes this, so what would be the purpose of converting
> last_modified to a boolean flag, and then introducing another struct
> member that acts exactly like last_modified does today?

The last_modified_flag struct member would replace three members that
have very obscure semantics IMHO.

martin

Previous Next

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