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 #40 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, cschol2112 <at> gmail.com
Subject: Re: bug#12600: 24.2.50;	linum-mode: line numbers in fringe do not
	refresh when resizing frame
Date: Fri, 12 Oct 2012 09:32:01 +0200

>>    if (! NILP (update)
>> /**       && ! (! NILP (w->window_end_valid) **/
>> /** 	    && w->last_modified >= BUF_MODIFF (b) **/
>> /** 	    && w->last_overlay_modified >= BUF_OVERLAY_MODIFF (b)) **/
>>        && !noninteractive)
>>
>> makes the problem disappear.
>>
>> So apparently this can be fixed easily but as long as I don't understand
>> that cryptic conjunct I won't do it.
>
> That 'if' is just an optimization: it tries to avoid a (potentially
> expensive) call to move_it_vertically.  It could be expensive with
> large windows and/or very long lines, for example.
>
> So if window-end is not supposed to be called in some inner loop, and
> we don't mind getting slower on behalf of a package whose design is
> known to be flawed anyway, we can disable the optimization.  Disabling
> this optimization should never do any harm, AFAIU, except slow down
> the function.

Before doing that, could you please in window.h eventually update the
comments for display related fields like last_modified,
last_overlay_modified, last_point to say who's supposed to (re-)set them
to which value.  I'm afraid the current situation is a mess.

For example, what does the "displayed buffer's text modification events
counter as of last time display completed" mean?  Suppose redisplay has
set this to 37.  Apparently, setting it to 36 means that the next
redisplay will notice that for this window display is not accurate and
has to be redone because 36 < 37.

But why is a flag insufficient to accomplish that?  IIUC it's set only
once by mark_window_display_accurate_1 and everywhere else reset to 0.
Why can't we set it to "accurate" in mark_window_display_accurate_1 and
"inaccurate" everwhere else?

And why do we have additional fields for last_overlay_modified and
window_end_valid?  What sense does it make to handle these separately?
For example, wherever last_modified is reset to 0 last_overlay_modified
is always reset to 0 too.  Isn't that plain overkill?

martin

Previous Next

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