Re: Old redisplay bug in xdisp.c, question about change

["Jan D." <jan.h.d@swipnet.se>]

> This particular change was part of a group of changes made to prevent or
> reduce multiple unnecessary runs of menu-bar-update-hook on things like
> scrolls, tooltips, mouse-1 with mouse-sel-mode, C-s, C-x 2 or menu-bar
> clicks.  (The performance impact is so bad that I use 21.1.90 + these
> changes for all my editing, rather than 21.2 or 21.3 which do not have
> them.)  The second part of this particular change made the code match
> the comment; at the time Gerd said this code dated from at least 1994.
> 
> It would be a shame if this change was simply reverted as the particular
> problem (multiple unnecessary runs of menu-bar-update-hook on scroll)
> will presumably resurface.  Does the fact that you don't always see a
> redisplay problem suggest that the bug lies elsewhere?

It the if-statement in update_tool_bar that is entered if w->update_mode_line
is Qt:

      /* If the user has switched buffers or windows, we need to
	 recompute to reflect the new bindings.  But we'll
	 recompute when update_mode_lines is set too; that means
	 that people can use force-mode-line-update to request
	 that the menu bar be recomputed.  The adverse effect on
	 the rest of the redisplay algorithm is about the same as
	 windows_or_buffers_changed anyway.  */
      if (windows_or_buffers_changed
	  || !NILP (w->update_mode_line)
	  || ((BUF_SAVE_MODIFF (XBUFFER (w->buffer))
	       < BUF_MODIFF (XBUFFER (w->buffer)))
	      != !NILP (w->last_had_star))
	  || ((!NILP (Vtransient_mark_mode)
	       && !NILP (XBUFFER (w->buffer)->mark_active))
	      != !NILP (w->region_showing)))
	{

The other parts are false, but I really don't know what they all mean.
windows_or_buffers_changed is 0 when I switch Info nodes.  In effect,
the buffer or the window has not changed, but its contents, active
and inactive menu and tool bar items have.

	Jan D.