Re: [calendar] Holidays menu doesn't go away

Re: [calendar] Holidays menu doesn't go away

[John Paul Wallington]

Jesper Harder <harder@ifa.au.dk> wrote:

> The "Holidays" menu doesn't go away after quitting from the calendar.

There is a similar symptom if you invoke then quit `info'.

Here is a fix, but I am not sure when we do want to stick `menu-bar'
in the front of path.

--- easymenu.el	16 Mar 2003 00:39:23 -0000	1.57
+++ easymenu.el	19 Mar 2003 19:29:15 -0000
@@ -517,8 +517,7 @@
 by `easy-menu-item-present-p' or `easy-menu-remove-item' or a menu defined
 earlier by `easy-menu-define' or `easy-menu-create-menu'."
   (unless map
-    (setq map (current-global-map))
-    (push 'menu-bar path))
+    (setq map (current-global-map)))
   (setq map (easy-menu-get-map map path
 			       (and (null map) (null path)
 				    (stringp (car-safe item))

Re: [calendar] Holidays menu doesn't go away

[John Paul Wallington]

[apologies for replying to myself]

>> The "Holidays" menu doesn't go away after quitting from the calendar.
> There is a similar symptom if you invoke then quit `info'.

Getting rid of the (push 'menu-bar path) avoids those problems, but
causes `recentf-mode' not to add its menu.  This reversion avoids
that too.  But I don't why the change was made.

diff -u -r1.57 easymenu.el
--- easymenu.el	16 Mar 2003 00:39:23 -0000	1.57
+++ easymenu.el	20 Mar 2003 02:24:01 -0000
@@ -516,9 +516,6 @@
 ITEM is either defined as in `easy-menu-define' or a non-nil value returned
 by `easy-menu-item-present-p' or `easy-menu-remove-item' or a menu defined
 earlier by `easy-menu-define' or `easy-menu-create-menu'."
-  (unless map
-    (setq map (current-global-map))
-    (push 'menu-bar path))
   (setq map (easy-menu-get-map map path
 			       (and (null map) (null path)
 				    (stringp (car-safe item))

Re: [calendar] Holidays menu doesn't go away

[Stefan Monnier]

> >> The "Holidays" menu doesn't go away after quitting from the calendar.
> > There is a similar symptom if you invoke then quit `info'.
> 
> Getting rid of the (push 'menu-bar path) avoids those problems, but
> causes `recentf-mode' not to add its menu.  This reversion avoids
> that too.  But I don't why the change was made.
> 
> diff -u -r1.57 easymenu.el
> --- easymenu.el	16 Mar 2003 00:39:23 -0000	1.57
> +++ easymenu.el	20 Mar 2003 02:24:01 -0000
> @@ -516,9 +516,6 @@
>  ITEM is either defined as in `easy-menu-define' or a non-nil value returned
>  by `easy-menu-item-present-p' or `easy-menu-remove-item' or a menu defined
>  earlier by `easy-menu-define' or `easy-menu-create-menu'."
> -  (unless map
> -    (setq map (current-global-map))
> -    (push 'menu-bar path))

The logentry explains why:

	* emacs-lisp/easymenu.el (easy-menu-name-match): Catch any error
	that member-ignore-case might signal.
	(easy-menu-add-item): Default to the global map, as documented.
	(easy-menu-convert-item-1): Use match-string.

As for where it's documented: in the docstring a few lines above.
So recentf should probably not use a nil MAP if it wants to use
the local map.
Or should we change the doc instead ?


	Stefan

Re: [calendar] Holidays menu doesn't go away

[John Paul Wallington]

"Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu> wrote:

> The logentry explains why:
>
> 	* emacs-lisp/easymenu.el (easy-menu-name-match): Catch any error
> 	that member-ignore-case might signal.
> 	(easy-menu-add-item): Default to the global map, as documented.
> 	(easy-menu-convert-item-1): Use match-string.
>
> As for where it's documented: in the docstring a few lines above.
> So recentf should probably not use a nil MAP if it wants to use
> the local map.
> Or should we change the doc instead ?

The change to `easy-menu-add-item' causes trouble with info and
calendar, and also with external libraries like emacs-w3m.  Reversion
superficially avoids that trouble, but I don't really grok easymenu.
Maybe it is easier to change the doc instead if there are many callers
to fix.

Re: [calendar] Holidays menu doesn't go away

[Stefan Monnier]

> > The logentry explains why:
> >
> > 	* emacs-lisp/easymenu.el (easy-menu-name-match): Catch any error
> > 	that member-ignore-case might signal.
> > 	(easy-menu-add-item): Default to the global map, as documented.
> > 	(easy-menu-convert-item-1): Use match-string.
> >
> > As for where it's documented: in the docstring a few lines above.
> > So recentf should probably not use a nil MAP if it wants to use
> > the local map.
> > Or should we change the doc instead ?
> 
> The change to `easy-menu-add-item' causes trouble with info and
> calendar, and also with external libraries like emacs-w3m.  Reversion
> superficially avoids that trouble, but I don't really grok easymenu.
> Maybe it is easier to change the doc instead if there are many callers
> to fix.

I've been looking at what the XEmacs version does (since compatibility
is the whole point of easymenu) and there a nil MAP (which they call
MENU) means "use the current menu" which actually means use the menu
in the `current-menubar' which can be made a buffer-local variable,
but not necessarily.
Admittedly, it is almost always buffer-local, so I think you're
right that it's better to change the docstring and revert my patch
to the code.

But then it seems that easy-menu offers no way to portably add
a global menu.


	Stefan

Re: [calendar] Holidays menu doesn't go away

[Richard Stallman]

What XEmacs does in easymenu is not much of a guide, because the
XEmacs handling of menus is totally different.

The right way to implement what the doc string of easy-menu-add-item
says is by making easy-menu-get-map do the right thing.

Re: [calendar] Holidays menu doesn't go away

[Stefan Monnier]

> What XEmacs does in easymenu is not much of a guide, because the
> XEmacs handling of menus is totally different.

How XEmacs implements the behavior is indeed of no importance.  On the
other hand, the whole point os easy-menu is compatiblity between Emacs
and XEmacs, so their behavior better be the same, which is why XEmacs's
easymenu behavior is very much relevant.

> The right way to implement what the doc string of easy-menu-add-item
> says is by making easy-menu-get-map do the right thing.

It looks like the docstring disagrees with XEmacs's behavior as well
as with what most code expects.


	Stefan

Re: [calendar] Holidays menu doesn't go away

[Richard Stallman]

    It looks like the docstring disagrees with XEmacs's behavior as well
    as with what most code expects.

Would you please be more specific?  What is the disagreement?