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 #34 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: Thu, 11 Oct 2012 09:12:50 +0200

> It was disabled with a comment saying
>
>   #if 0 /* This change broke some things.  We should make it later.  */
>                                            ^^^^^^^^^^^^^^^^^^^^^^^
> If everybody agrees that the doc string is wrong, then we should
> permanently delete this code when we update the doc.  Otherwise, some
> day the function will begin returning nil, and applications should be
> prepared for that.

Looking at the ChangeLogs this apparently changed back and forth two
times with limited success.

>>  >   if (! NILP (update)
>>  >       && ! (! NILP (w->window_end_valid)
>>  > 	    && w->last_modified >= BUF_MODIFF (b)
>>  > 	    && w->last_overlay_modified >= BUF_OVERLAY_MODIFF (b))
>>  >       && !noninteractive)
>>
>> Is there anything that has not been set when the frame got resized?
>
> I'm guessing it's the window_end_valid flag, since no buffer changes
> are involved in the recipe.  Which probably means that the resize did
> not yet become known to the display engine by the time this function
> is called.
>
> Of course, this is all theory, and I was wrong before.  It would be
> best to trace this with a debugger and see what's going on.

I have no idea what these window structure members (window_end_valid,
last_modified and last_overlay_modified) stand for in practice, who's
supposed to set them, why and when.  At least setting window_end_valid
to Qnil in window_resize_apply did not help.  But writing

  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.

martin

Previous Next

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