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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 Oct 2012 12:22:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: cschol2112@gmail.com, 12600@debbugs.gnu.org
> 
>  > When you reproduce the problem, do you see the code conditioned by the
>  > 'if' shown below being executed at all?
> 
> No.

QED.  Redisplay thinks that nothing's changed, and returns the
previous (wrong) window-end.

>  > (Btw, it looks like linum-mode doesn't expect to get nil from
>  > window-end, although the doc string explicitly says it's possible.)
> 
> I suppose the doc-string is wrong since otherwise we should have seen
> this already reported.  IIUC it returns either
> 
>        value = make_number (IT_CHARPOS (it));
> 
> or
> 
>      XSETINT (value, BUF_Z (b) - XFASTINT (w->window_end_pos));
> 
> while the nil reporting part was disabled.

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. 

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