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

[Marshall, Simon]

            The comments indicate that the menu does not need to be
updated, but
            apparently the tool bar is not updated either, because
w->update_mode_line
            is not set to Qt.

            There seems to be no ill effects from reverting this change,
but since I
            don't know why it was made in the first place, I can not be
sure.
            Does anybody remember the reason for this change?

        I think I made this change just as an optimization.  So it could
be
        reverted safely.

        Another alternative is to execute, in that case,
        just the parts of the if-statement that are really needed in
that case.

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?

Richard, at the time you suggested a good general fix was to split the
functionality of windows_or_buffers_changed into different flags for
updating the mode line and updating menus, though I don't think anyone
volunteered to implement it.  Perhaps a flag for updating the tool bar
would also be useful.

Simon.