bug#23026: 25.0.92; menu-bar bug?

[Eli Zaretskii <eliz@gnu.org>]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Wed, 16 Mar 2016 13:38:20 +0800
> 
> 1. Start a GUI emacs with -q
> 2. load the attached t.el file
> 3. M-x test
> 4. look at the menu-bar and notice there is `Test' menu
> 5. mouse-click the first line and notice `Test' is gone
> 6. mouse-click the second line so that `Test' reappears
> 7. C-p to move to first line and notice `Test' doesn't disappear
> 
> The difference between 5 and 7 is puzzling. Is this a bug?

No, it's a redisplay optimization: Emacs doesn't redraw the menu bar
when all that's changed is cursor position.  In 99.999% of cases,
cursor motion doesn't require any changes in the menu-bar items, so
redrawing the menu bar after each movement of point would just slow
down cursor motion and cause annoying flickering of the menu bar.
Therefore, we don't do it.  I'm not sure I understand what's special
about this use case that we'd want to disable this optimization.

By contrast, a mouse click potentially activates/deactivates the mark
and extends or removes the region highlight, so many redisplay
optimizations are disabled when we process the click -- it isn't just
moving point.

> How to make the two behave consistently?

By "consistently" I believe you mean you'd like the menu bar updated
when point moves via keyboard commands, yes?  If so, you should force
a more thorough redisplay, e.g. by calling force-mode-line-update,
when point moves in a way that requires a change in the menu bar.  How
exactly to do that depends on your real-life use case -- it could be a
post-command-hook, or a special binding in the keymap which you put in
the property, or a function in cursor-sensor-functions property, or
something else.