easymenu suffix problem?

easymenu suffix problem?

[Glenn Morris]

With a window-system:

emacs -Q -f calendar

C-h k on the "Holidays" menu, "For Year 2007".

you get:

<menu-bar> <Holidays> <For Year> runs the command menu-function-1
 ...

You get the same binding to menu-function-1 for each "For Year XXXX"
entry, which means one always gets the holidays for 2002, no matter
which item one clicks.

Each menu-item in the menu has name "For Year" (sans suffix), which is
presumably why they all end up running the same command (for the first
entry).

Is this an easymenu problem? This menu is created with:

(easy-menu-define nil calendar-mode-map nil cal-menu-holidays-menu)

cal-holidays-menu has a structure like:

 ["For Year"
  (lambda nil
    (interactive)
    (holiday-list (+ displayed-year -5) (+ displayed-year -5)))
  :suffix (number-to-string (+ displayed-year -5))]
 ["For Year"
  (lambda nil
    (interactive)
    (holiday-list (+ displayed-year -4) (+ displayed-year -4)))
  :suffix (number-to-string (+ displayed-year -4))]

So, the :suffix part is only affecting the _label_ associated with the
menu-item, not the actual _name_ of the item in the keymap. Is this
how it is supposed to work? I can't see that this would be much use.

Re: easymenu suffix problem?

[Glenn Morris]

Glenn Morris wrote:

> You get the same binding to menu-function-1 for each "For Year XXXX"
> entry, which means one always gets the holidays for 2002, no matter
> which item one clicks.

I think this can be worked around by using :label (undocumented, BTW)
instead of :suffix, and using a counter for the menu-item names. I
still don't understand if easymenu is doing the right thing with
:suffix though.


*** cal-menu.el.~1.78.~	2007-11-24 18:48:06.000000000 -0800
--- cal-menu.el	2007-11-25 19:42:02.000000000 -0800
***************
*** 95,106 ****
      ,@(let ((l ()))
          ;; Show 11 years--5 before, 5 after year of middle month.
          (dotimes (i 11)
!           (push (vector "For Year"
                          `(lambda ()
                             (interactive)
                             (holiday-list (+ displayed-year ,(- i 5))
                                           (+ displayed-year ,(- i 5))))
!                         :suffix `(number-to-string (+ displayed-year ,(- i 5))))
                  l))
          (nreverse l))
      "--"
--- 95,107 ----
      ,@(let ((l ()))
          ;; Show 11 years--5 before, 5 after year of middle month.
          (dotimes (i 11)
!           (push (vector (format "hol-year-%d" i)
                          `(lambda ()
                             (interactive)
                             (holiday-list (+ displayed-year ,(- i 5))
                                           (+ displayed-year ,(- i 5))))
!                         :label `(format "For Year %d"
!                                        (+ displayed-year ,(- i 5))))
                  l))
          (nreverse l))
      "--"

Re: easymenu suffix problem?

[Stefan Monnier]

>> You get the same binding to menu-function-1 for each "For Year XXXX"
>> entry, which means one always gets the holidays for 2002, no matter
>> which item one clicks.

> I think this can be worked around by using :label (undocumented, BTW)
> instead of :suffix, and using a counter for the menu-item names. I
> still don't understand if easymenu is doing the right thing with
> :suffix though.

The problem with easy-menu, is that it generates the command's binding
based on the entry name and this cannot be created dynamically (at
least not conveniently), so it can't make use of :suffix.  What should
happen, is that easymenu should detect that it's seeing "the same name"
again in the same menu and then generate a different key.


        Stefan

Re: easymenu suffix problem?

[Glenn Morris]

Stefan Monnier wrote:

> What should happen, is that easymenu should detect that it's seeing
> "the same name" again in the same menu and then generate a different
> key.

It's not obvious to me how to do that. easy-menu-convert-item-1, which
would need to choose a new name in the event of a clash, only
processes a single item, and does not know anything about the map
which the items will be installed in.

Is the comment in that function about "merge multiple entries with the
same name" referring to some other, desired, functionality? In other
words, the choosing-a-unique-name thing would only be needed in the
case of name clashes caused by the use of :suffix?

Re: easymenu suffix problem?

[Stefan Monnier]

>> What should happen, is that easymenu should detect that it's seeing
>> "the same name" again in the same menu and then generate a different
>> key.

> It's not obvious to me how to do that. easy-menu-convert-item-1, which
> would need to choose a new name in the event of a clash, only
> processes a single item, and does not know anything about the map
> which the items will be installed in.

Indeed, it may require a bit of reshuffling.

> Is the comment in that function about "merge multiple entries with the
> same name" referring to some other, desired, functionality? In other
> words, the choosing-a-unique-name thing would only be needed in the
> case of name clashes caused by the use of :suffix?

Hmm... now I can't quite remember eactly why I wanted to merge
those entries.  Maybe it was just that relying on string eq-tests was
a bit brittle.


        Stefan

Re: easymenu suffix problem?

[Stefan Monnier]

> Each menu-item in the menu has name "For Year" (sans suffix), which is
> presumably why they all end up running the same command (for the first
> entry).

> Is this an easymenu problem? This menu is created with:

This problem in easymenu should now be fixed.


        Stefan