Jeff Miller <jmiller(a)smart.net&gt; writes: Didier described what was going on. Further analysis shows that the culprit is pre_activate_callback(), which simulates run_hook() functionality in order to notice whether the functions return t, but without supporting the make-local-hook feature. I started to write a correct fix for that, but then noticed that the resulting `any_changes' value gets ignored anyway, so fixing the bug it reduces to just using `run_hook', as menubar-msw.c does. Jeff, could you please confirm that this patch fixes the problem for you? 1998-08-26 Hrvoje Niksic <hniksic(a)srce.hr&gt; * menubar-x.c (my_run_hook): New unused function. (pre_activate_callback): Use run_hook for Qactivate_menubar_hook, since we ignore the results of the contained functions anyway. --- src/menubar-x.c.orig Wed Aug 26 12:00:45 1998 +++ src/menubar-x.c Wed Aug 26 12:55:21 1998 ＠＠ -333,6 +333,33 ＠＠ } #endif /* LWLIB_MENUBARS_LUCID || LWLIB_MENUBARS_MOTIF */ +#if 0 +/* #### Sort of a hack needed to process Vactivate_menubar_hook + correctly wrt buffer-local values. A correct solution would + involve adding a callback mechanism to run_hook(). This function + is currently unused. */ +static int +my_run_hook (Lisp_Object hooksym, int allow_global_p) +{ + /* This function can GC */ + Lisp_Object tail; + Lisp_Object value = Fsymbol_value (hooksym); + int changes = 0; + + if (!NILP (value) && (!CONSP (value) || EQ (XCAR (value), Qlambda))) + return !EQ (call0 (value), Qt); + + EXTERNAL_LIST_LOOP (tail, value) + { + if (allow_global_p && EQ (XCAR (tail), Qt)) + changes |= my_run_hook (Fdefault_value (hooksym), 0); + if (!EQ (call0 (XCAR (tail)), Qt)) + changes = 1; + } + return changes; +} +#endif + /* The order in which callbacks are run is funny to say the least. It's sometimes tricky to avoid running a callback twice, and to ＠＠ -358,12 +385,9 ＠＠ pre_activate_callback (Widget widget, LWLIB_ID id, XtPointer client_data) { /* This function can GC */ - struct gcpro gcpro1; struct device *d = get_device_from_display (XtDisplay (widget)); struct frame *f = x_any_window_to_frame (d, XtWindow (widget)); - Lisp_Object rest = Qnil; Lisp_Object frame; - int any_changes = 0; int count; /* set in lwlib to the time stamp associated with the most recent menu ＠＠ -418,24 +442,17 ＠＠ replace_widget_value_tree (hack_wv, wv->contents); free_popup_widget_value_tree (wv); } + else if (!POPUP_DATAP (FRAME_MENUBAR_DATA (f))) + return; else { - if (!POPUP_DATAP (FRAME_MENUBAR_DATA (f))) - return; +#if 0 /* Unused, see comment below. */ + int any_changes; + /* #### - this menubar update mechanism is expensively anti-social and the activate-menubar-hook is now mostly obsolete. */ - /* make the activate-menubar-hook be a list of functions, not a single - function, just to simplify things. */ - if (!NILP (Vactivate_menubar_hook) && - (!CONSP (Vactivate_menubar_hook) || - EQ (XCAR (Vactivate_menubar_hook), Qlambda))) - Vactivate_menubar_hook = Fcons (Vactivate_menubar_hook, Qnil); - - GCPRO1 (rest); - for (rest = Vactivate_menubar_hook; !NILP (rest); rest = Fcdr (rest)) - if (!EQ (call0 (XCAR (rest)), Qt)) - any_changes = 1; -#if 0 + any_changes = my_run_hook (Qactivate_menubar_hook, 1); + /* #### - It is necessary to *ALWAYS* call set_frame_menubar() now that incremental menus are implemented. If a subtree of a menu has been updated incrementally (a destructive operation), then that subtree ＠＠ -446,12 +463,14 ＠＠ that an INCREMENTAL_TYPE widget_value can be recreated... Hmmmmm. */ if (any_changes || !XFRAME_MENUBAR_DATA (f)->menubar_contents_up_to_date) -#endif set_frame_menubar (f, 1, 0); +#else + run_hook (Qactivate_menubar_hook); + set_frame_menubar (f, 1, 0); +#endif DEVICE_X_MOUSE_TIMESTAMP (XDEVICE (FRAME_DEVICE (f))) = DEVICE_X_GLOBAL_MOUSE_TIMESTAMP (XDEVICE (FRAME_DEVICE (f))) = x_focus_timestamp_really_sucks_fix_me_better; - UNGCPRO; } } -- Hrvoje Niksic <hniksic(a)srce.hr&gt; | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Manic depression is cool... your body can make its own drugs.