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

[martin rudalics <rudalics@gmx.at>]

 > 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