emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Multiple runs of menu-bar-update-hook


From: Marshall, Simon
Subject: RE: Multiple runs of menu-bar-update-hook
Date: Wed, 9 Aug 2006 09:33:14 +0100

>     Is this the kind of debugging you wanted - does it help?
> 
> It is the right kind, and it gives some useful info.
> 
> Now the question is, since it ran the hook inside 
> update_menu_bar, why did it run the hook again in set_frame_menubar?
> Something near the start of that function must be setting 
> deep_p to nonzero.  Can you see what it is, and why?

It did not run it again in set_frame_menubar()---both runs of the hook are
from update_menu_bar() and via the same redisplay route.  The snippets from
the earlier email are:

=>[1] update_menu_bar(f = 0x964400, save_match_data = 0, hooks_run = 0),
line 9195 in "xdisp.c"
  [2] prepare_menu_bars(), line 9073 in "xdisp.c"
  [3] redisplay_internal(preserve_echo_area = 0), line 10902 in "xdisp.c"
  [4] redisplay(), line 10491 in "xdisp.c"
  [5] read_char(commandflag = 0, nmaps = 0, maps = (nil), prev_event =
541825072, used_mouse_menu = (nil), end_time = (nil)), line 2555 in
"keyboard.c"
  [6] read_filtered_event(no_switch_frame = 0, ascii_required = 0,
error_nonascii = 0, input_method = 0, seconds = 541825024), line 496 in
"lread.c"
  [7] Fread_event(prompt = 541825024, inherit_input_method = 541825024,
seconds = 541825024), line 600 in "lread.c"
  ...

And then:

=>[1] update_menu_bar(f = 0x964400, save_match_data = 0, hooks_run = 0),
line 9195 in "xdisp.c"
  [2] prepare_menu_bars(), line 9073 in "xdisp.c"
  [3] redisplay_internal(preserve_echo_area = 0), line 10902 in "xdisp.c"
  [4] redisplay(), line 10491 in "xdisp.c"
  [5] read_char(commandflag = 1, nmaps = 2, maps = 0xffbedd50, prev_event =
541825024, used_mouse_menu = 0xffbeddcc, end_time = (nil)), line 2555 in
"keyboard.c"
  [6] read_key_sequence(keybuf = 0xffbedf38, bufsize = 30, prompt =
541825024, dont_downcase_last = 0, can_return_switch_frame = 1,
fix_current_buffer = 1), line 8893 in "keyboard.c"
  [7] command_loop_1(), line 1536 in "keyboard.c"
  [8] internal_condition_case(bfun = 0x1bba38 = &command_loop_1(), handlers
= 541881992, hfun = 0x1bb068 = &cmd_error(Lisp_Object data)), line 1469 in
"eval.c"
  [9] command_loop_2(), line 1326 in "keyboard.c"
  [10] internal_catch(tag = 541883392, func = 0x1bb650 = &command_loop_2(),
arg = 541825024), line 1210 in "eval.c"
  [11] command_loop(), line 1305 in "keyboard.c"
  [12] recursive_edit_1(), line 1003 in "keyboard.c"
  [13] Frecursive_edit(), line 1064 in "keyboard.c"
  [14] main(argc = 2, argv = 0xffbee444), line 1794 in "emacs.c"

I would also say that it is not just the second call that is important to
understand, the first call is unnecessary too.  After all, I only did
mouse-1 in the selected frame (where the other frame is showing the same
buffer).

This is a guess based on what you have said previous: I think the reason
update_menu_bar() ran the hooks is because windows_or_buffers_changed = 1,
and that is because modify_overlay() sets it, and that is because the buffer
is shown in more than one window.  (See the latter parts of the earlier
email---let me know if you want me to send it again.)

Simon.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]