easymenu.el

easymenu.el

[B. Anyos]

Hi,

Latest changes to easymenu.el broke loading of ECB v2.27 (Emacs Code Browser)
I don't know how many apps out there that became incompatible with the change.

The logic in easy-menu-intern has changed:
   -> from downcase the entire string to flip the starting letter of each word.

Was this intentional so apps should adapt their code ?

Cheers,
  Bela

ps.: changing the corresponding item in ECB solved the problem...

Re: easymenu.el

[David Kastrup]

"B. Anyos" <banyos@freemail.hu> writes:

> Latest changes to easymenu.el broke loading of ECB v2.27 (Emacs Code
> Browser) I don't know how many apps out there that became
> incompatible with the change.
>
> The logic in easy-menu-intern has changed:
>    -> from downcase the entire string to flip the starting letter of
>       each word.
>
> Was this intentional so apps should adapt their code ?
>
> ps.: changing the corresponding item in ECB solved the problem...

Why is there a corresponding item?  Why doesn't ECB use easy-menu for
accessing menus created with easy-menu?

I really dislike Richard's change (for aesthetical reasons: I don't
like menu entries Gamma and gamma to be swapped), but it should not
break packages: the internal symbols from easymenu should either not
be used externally, or there should be a proper interface for
accessing them.

It appears we are having a problem here independent from that Richard
tried to address.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: easymenu.el

[Stefan]

I really think we should simply revert both changes to easy-menu-intern and
stop downcasing/upcasing anything: revert back to the 21.3 behavior.


        Stefan

Re: easymenu.el

[Peter Heslin]

On 2004-11-03, Stefan <monnier@iro.umontreal.ca> wrote:
>  I really think we should simply revert both changes to easy-menu-intern and
>  stop downcasing/upcasing anything: revert back to the 21.3 behavior.

FWIW, both printing.el (part of Emacs) and color-theme.el (not part of
Emacs, but widely used) now give menu-related errors on loading. 

Peter

Re: easymenu.el

[Richard Stallman]

    >  I really think we should simply revert both changes to easy-menu-intern and
    >  stop downcasing/upcasing anything: revert back to the 21.3 behavior.

The reason I changed easy-menu-intern to alter the name is so that
easy-menu would work with the standard menu items.  For instance, the
Options menu uses `options' as the symbol.  I changed easy-menu-intern
so it would convert "Options" into `options'.

If we take out this change, then either (1) we have to change the
symbols used in menu-bar.el, so that the Options menu uses `Options' as the
symbol, or (2) easy-menu will not work with those menus any more.

If we do (1), then programs that call define-key to set up menu items
in these menus will break.  However, I don't know how many of those
programs there are.

Re: easymenu.el

[Stefan]

> The reason I changed easy-menu-intern to alter the name is so that
> easy-menu would work with the standard menu items.  For instance, the
> Options menu uses `options' as the symbol.  I changed easy-menu-intern
> so it would convert "Options" into `options'.

> If we take out this change, then either (1) we have to change the
> symbols used in menu-bar.el, so that the Options menu uses `Options' as the
> symbol, or (2) easy-menu will not work with those menus any more.

Option (2) cannot really be true, because those things have never worked
with easy-menu (at least not in any released version of Emacs).

> If we do (1), then programs that call define-key to set up menu items
> in these menus will break.  However, I don't know how many of those
> programs there are.

Since this downcase-change is recent, only recently changed programs can
be affected and since we'd be getting back to Emacs-21.3 behavior, those
program would fail under Emacs-21.3 as well.

BTW, I've just installed a patch to easymenu that makes it look for
menu-item *names* when looking up keymaps, so you should now be able to say
(easy-menu-add-item nil '("File") ["foo" bar]) to add an entry "foo" in the
"File" menu even though that menu's key name is `files'.  As can be guessed
by the different spelling, this now works regardless of the actual
definition of easy-menu-intern, so I (re-)propose the additional patch below,


        Stefan


--- easymenu.el	06 Nov 2004 04:58:18 -0500	1.67
+++ easymenu.el	06 Nov 2004 05:06:15 -0500	
@@ -42,25 +42,7 @@
   :version "20.3")
 
 (defsubst easy-menu-intern (s)
-  (if (stringp s)
-      (let ((copy (copy-sequence s))
-	    (pos 0)
-	    found)
-	;; For each letter that starts a word, flip its case.
-	;; This way, the usual convention for menu strings (capitalized)
-	;; corresponds to the usual convention for menu item event types
-	;; (all lower case).  It's a 1-1 mapping so causes no conflicts.
-	(while (setq found (string-match "\\<\\sw" copy pos))
-	  (setq pos (match-end 0))
-	  (unless (= (upcase (aref copy found))
-		     (downcase (aref copy found)))
-	    (aset copy found
-		  (if (= (upcase (aref copy found))
-			 (aref copy found))
-		      (downcase (aref copy found))
-		    (upcase (aref copy found))))))
-	 (intern copy))
-    s))
+  (if (stringp s) (intern s) s))
 
 ;;;###autoload
 (put 'easy-menu-define 'lisp-indent-function 'defun)
@@ -437,8 +419,7 @@
 		  (error nil))		;`item' might not be a proper list.
 		;; Also check the string version of the symbol name,
 		;; for backwards compatibility.
-		(eq (car-safe item) (intern name))
-		(eq (car-safe item) (easy-menu-intern name)))))))
+		(eq (car-safe item) (intern name)))))))
 
 (defun easy-menu-always-true-p (x)
   "Return true if form X never evaluates to nil."

Re: easymenu.el

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

> BTW, I've just installed a patch to easymenu that makes it look for
> menu-item *names* when looking up keymaps, so you should now be able
> to say (easy-menu-add-item nil '("File") ["foo" bar]) to add an
> entry "foo" in the "File" menu even though that menu's key name is
> `files'.  As can be guessed by the different spelling, this now
> works regardless of the actual definition of easy-menu-intern, so I
> (re-)propose the additional patch below,

Two notes:

C-h k <menuitem>

seems to exhibit the symbol case, as does

C-h w whatever RET

I am not convinced this should be undesirable, however.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: easymenu.el

[Richard Stallman]

    C-h k <menuitem>

    seems to exhibit the symbol case, as does

    C-h w whatever RET

    I am not convinced this should be undesirable, however.

Since these are meant to show the sequence of event types,
I think they had better show them as they are.

In what way is this a problem?

Re: easymenu.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     C-h k <menuitem>
>
>     seems to exhibit the symbol case, as does
>
>     C-h w whatever RET
>
>     I am not convinced this should be undesirable, however.
>
> Since these are meant to show the sequence of event types,
> I think they had better show them as they are.

Yes.

> In what way is this a problem?

Well, obviously the resulting look _was_ a problem for somebody, or we
would not have got the case-folding code in Emacs-21.3 in the first
place.  Correct me if I am mistaken.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: easymenu.el

[Richard Stallman]

    Well, obviously the resulting look _was_ a problem for somebody, or we
    would not have got the case-folding code in Emacs-21.3 in the first
    place.  Correct me if I am mistaken.

The feature was introduced for compatibility, not for mere "looks".

Re: easymenu.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Well, obviously the resulting look _was_ a problem for somebody,
>     or we would not have got the case-folding code in Emacs-21.3 in
>     the first place.  Correct me if I am mistaken.
>
> The feature was introduced for compatibility, not for mere "looks".

Compatibility to what?  What did it fix that was not working before?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: easymenu.el

[Richard Stallman]

    Compatibility to what?  What did it fix that was not working before?

Use of easymenu to change the standard menu-bar menus.

Re: easymenu.el

[Richard Stallman]

    Since this downcase-change is recent, only recently changed programs can
    be affected and since we'd be getting back to Emacs-21.3 behavior, those
    program would fail under Emacs-21.3 as well.

Ok, I am convinced.  However, this means we should change all the
code in Emacs that defines menu bar menus the old-fashioned way,
to be compatible with the reverted easymenu.el.

    BTW, I've just installed a patch to easymenu that makes it look for
    menu-item *names* when looking up keymaps, so you should now be able to say
    (easy-menu-add-item nil '("File") ["foo" bar]) to add an entry "foo" in the
    "File" menu even though that menu's key name is `files'.  As can be guessed
    by the different spelling, this now works regardless of the actual
    definition of easy-menu-intern, so I (re-)propose the additional patch below,

That's clever.  I guess the problem is solved now, and we don't
have to change other code.

Re: easymenu.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

[Stefan:]

>     BTW, I've just installed a patch to easymenu that makes it look
>     for menu-item *names* when looking up keymaps, so you should now
>     be able to say (easy-menu-add-item nil '("File") ["foo" bar]) to
>     add an entry "foo" in the "File" menu even though that menu's
>     key name is `files'.  As can be guessed by the different
>     spelling, this now works regardless of the actual definition of
>     easy-menu-intern, so I (re-)propose the additional patch below,
>
> That's clever.

Actually, I'd say it's natural.  So I can't help suspecting that the
original design was there for a purpose.

> I guess the problem is solved now, and we don't have to change other
> code.

Is there any serious performance degradation to be expected, Stefan?
I think there was a time when calling menus the first time was rather
expensive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: easymenu.el

[Stefan]

> Is there any serious performance degradation to be expected, Stefan?
> I think there was a time when calling menus the first time was rather
> expensive.

The change should only affect calls to easy-menu-add-item, which are rare
and not repeated, so the impact should be minimal.


        Stefan

Re: easymenu.el

[Richard Stallman]

    FWIW, both printing.el (part of Emacs) and color-theme.el (not part of
    Emacs, but widely used) now give menu-related errors on loading. 

In the case of printing.el, the problem seems to be that it doesn't
intern the symbols it constructs.

Re: easymenu.el

[Vinicius Jose Latorre]

 >     FWIW, both printing.el (part of Emacs) and color-theme.el (not 
part of
 >     Emacs, but widely used) now give menu-related errors on loading.
 >
 > In the case of printing.el, the problem seems to be that it doesn't
 > intern the symbols it constructs.

Well, only part of the problem, as RMS pointed in a private email, the 
problem
is in part related with pr-get-symbol.

Changing pr-get-symbol to:

  (defun pr-get-symbol (name)
    (easy-menu-intern name))

It's possible to bootstrap & install Emacs, but an error occurs when 
starting
Emacs with (require 'printing) in ~/.emacs.

The problem is related with easy-menu-get-map, that it's used by
easy-menu-add-item.  And easy-menu-add-item is used by printing.el to change
File menu options.

Now, easy-menu-get-map returns:

   (easy-menu-get-map nil '("files"))
   ==> (keymap "files")

And before easymenu.el changing, easy-menu-get-map returned:

   (easy-menu-get-map nil '("files"))
   ==> (keymap (open-file menu-item Open File... ..) .....  File)


Vinicius