> 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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug