bug#23026: 25.0.92; menu-bar bug?

bug#23026: 25.0.92; menu-bar bug?

[Leo Liu]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]


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? How to make
the two behave consistently?

Leo

[-- Attachment #2: t.el --]
[-- Type: application/emacs-lisp, Size: 430 bytes --]

bug#23026: 25.0.92; menu-bar bug?

[Eli Zaretskii]

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

bug#23026: 25.0.92; menu-bar bug?

[Leo Liu]

On 2016-03-16 17:36 +0200, Eli Zaretskii wrote:
> 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.

Make sense and thanks for the info.

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

Thanks.

Leo