[Top][All Lists]
[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: |
Thu, 10 Aug 2006 14:06:20 +0100 |
> Was update_menu_bar called twice from a single call to
> prepare_menu_bars?
> If so, that means the mechanism I recently added to prevent
> that is broken.
>
> Or was prepare_menu_bars called twice? If so, how was it
> called, each time?
It was called twice. Sorry if this still isn't clear, this is just the
stack frames I sent earlier, but from a gcc build. This is the first call:
Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0)
at xdisp.c:9195
(gdb) where
#0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at
xdisp.c:9195
#1 0x000806ac in prepare_menu_bars () at xdisp.c:9073
#2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902
#3 0x00083ecc in redisplay () at xdisp.c:10491
#4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0,
prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555
#5 0x00270af4 in read_filtered_event (no_switch_frame=0, ascii_required=0,
error_nonascii=0, input_method=0, seconds=4687873) at lread.c:495
#6 0x00270eb0 in Fread_event (prompt=4687873, inherit_input_method=4687873,
seconds=4687873) at lread.c:600
#7 0x0024ab14 in Ffuncall (nargs=1, args=0xffbecec0) at eval.c:2988
#8 0x002a2cb8 in Fbyte_code (bytestr=3725827, vector=3725852, maxdepth=48)
at bytecode.c:679
#9 0x002492a4 in Feval (form=3725813) at eval.c:2319
#10 0x00244430 in Fprogn (args=3725805) at eval.c:435
#11 0x00180a68 in Ftrack_mouse (args=3725805) at keyboard.c:3498
#12 0x00248fe8 in Feval (form=3725797) at eval.c:2260
#13 0x00244430 in Fprogn (args=3725789) at eval.c:435
#14 0x0024b554 in funcall_lambda (fun=3725773, nargs=0,
arg_vector=0xffbed54c) at eval.c:3162
#15 0x0024ae14 in Ffuncall (nargs=1, args=0xffbed548) at eval.c:3039
#16 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48)
at bytecode.c:679
#17 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2,
arg_vector=0xffbed81c) at eval.c:3169
#18 0x0024ad30 in Ffuncall (nargs=3, args=0xffbed818) at eval.c:3028
#19 0x002a2cb8 in Fbyte_code (bytestr=3724235, vector=3724252, maxdepth=40)
at bytecode.c:679
#20 0x0024b5b8 in funcall_lambda (fun=3724196, nargs=1,
arg_vector=0xffbedb0c) at eval.c:3169
#21 0x0024ad30 in Ffuncall (nargs=2, args=0xffbedb08) at eval.c:3028
#22 0x00243528 in Fcall_interactively (function=7566081,
record_flag=4687873, keys=4747268) at callint.c:880
#23 0x00190a7c in Fcommand_execute (cmd=7566081, record_flag=4687873,
keys=4687873, special=4687873) at keyboard.c:9797
#24 0x0017b290 in command_loop_1 () at keyboard.c:1790
#25 0x00246eb4 in internal_condition_case (bfun=0x17910c <command_loop_1>,
handlers=4752009, hfun=0x178734 <cmd_error>) at eval.c:1469
#26 0x00178dd8 in command_loop_2 () at keyboard.c:1326
#27 0x00246644 in internal_catch (tag=4746241, func=0x178dac
<command_loop_2>, arg=4687873) at eval.c:1210
#28 0x00178d50 in command_loop () at keyboard.c:1305
#29 0x00178280 in recursive_edit_1 () at keyboard.c:1003
#30 0x001784e0 in Frecursive_edit () at keyboard.c:1064
#31 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794
Lisp Backtrace:
"read-event" (0x0)
"byte-code" (0x38da03)
"track-mouse" (0x38d9ed)
0x38d9cd Lisp type 5
"mouse-drag-track" (0x5c44ed)
"mouse-drag-region" (0x5c44ed)
"call-interactively" (0x737301)
(gdb)
The second call is:
Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0)
at xdisp.c:9195
(gdb) where
#0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at
xdisp.c:9195
#1 0x000806ac in prepare_menu_bars () at xdisp.c:9073
#2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902
#3 0x00083ecc in redisplay () at xdisp.c:10491
#4 0x0017dba4 in read_char (commandflag=1, nmaps=2, maps=0xffbedb60,
prev_event=4687873, used_mouse_menu=0xffbedcb4, end_time=0x0) at
keyboard.c:2555
#5 0x0018dd50 in read_key_sequence (keybuf=0xffbede60, bufsize=30,
prompt=4687873, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8902
#6 0x00179668 in command_loop_1 () at keyboard.c:1535
#7 0x00246eb4 in internal_condition_case (bfun=0x17910c <command_loop_1>,
handlers=4752009, hfun=0x178734 <cmd_error>) at eval.c:1469
#8 0x00178dd8 in command_loop_2 () at keyboard.c:1326
#9 0x00246644 in internal_catch (tag=4746241, func=0x178dac
<command_loop_2>, arg=4687873) at eval.c:1210
#10 0x00178d50 in command_loop () at keyboard.c:1305
#11 0x00178280 in recursive_edit_1 () at keyboard.c:1003
#12 0x001784e0 in Frecursive_edit () at keyboard.c:1064
#13 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794
(gdb)
Which I assume is the main loop.
You can see that both calls have come via redisplay(); the difference is
their callers. (Of course both runs of the hook are unnecessary, they have
been carried out because windows_or_buffers_changed = 1.) In the first:
#4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0,
prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555
#5 0x00270af4 in read_filtered_event (no_switch_frame=0, ascii_required=0,
error_nonascii=0, input_method=0, seconds=4687873) at lread.c:495
#6 0x00270eb0 in Fread_event (prompt=4687873, inherit_input_method=4687873,
seconds=4687873) at lread.c:600
And in the second:
#4 0x0017dba4 in read_char (commandflag=1, nmaps=2, maps=0xffbedb60,
prev_event=4687873, used_mouse_menu=0xffbedcb4, end_time=0x0) at
keyboard.c:2555
#5 0x0018dd50 in read_key_sequence (keybuf=0xffbede60, bufsize=30,
prompt=4687873, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8902
#6 0x00179668 in command_loop_1 () at keyboard.c:1535
As you can see, although both calls to redisplay() have come from
read_char():
while (!input_pending)
{
if (help_echo_showing_p && !EQ (selected_window, minibuf_window))
redisplay_preserve_echo_area (5);
else
--> redisplay ();
if (!input_pending)
/* Normal case: no input arrived during redisplay. */
break;
/* Input arrived and pre-empted redisplay.
Process any events which are not user-visible. */
swallow_events (0);
/* If that cleared input_pending, try again to redisplay. */
}
The callers/calls of read_char() are different.
What would you like me to look for?
> I did find a small bug in update_menu_bar which might explain
> the problem. This should fix the bug. I doubt that the bug
> is relevant in your scenario, but it might be. So please try
> this fix.
Thanks, but as you expected it does not fix the multiple runs for the case
of mouse-1 in a frame showing a buffer that is also shown in another frame.
Simon.
- RE: Multiple runs of menu-bar-update-hook, Marshall, Simon, 2006/08/07
- RE: Multiple runs of menu-bar-update-hook, Marshall, Simon, 2006/08/09
- RE: Multiple runs of menu-bar-update-hook, Marshall, Simon, 2006/08/09
- RE: Multiple runs of menu-bar-update-hook,
Marshall, Simon <=
- RE: Multiple runs of menu-bar-update-hook, Marshall, Simon, 2006/08/11
- RE: Multiple runs of menu-bar-update-hook, Marshall, Simon, 2006/08/14