[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15576: 24.3.50; Some minor issues regarding the new TTY menus

From: Dani Moncayo
Subject: bug#15576: 24.3.50; Some minor issues regarding the new TTY menus
Date: Thu, 10 Oct 2013 21:07:25 +0200

> IOW for each submenu, you have 3 more or less equivalent/redundant "names":
> - the text to display in the parent menu (i.e. the only thing usually
>   displayed).
> - the "prompt" (which is only displayed if you pass that submenu to
>   directly popup-menu, or if you use the non-toolkit version of Emacs,
>   or now in the tty-menu code).
> - the event associated with this submenu.  It's usually a symbol rather
>   than a string (because it's compared with `eq'; and it can also be an
>   integer), but it's often just a symbol version of the "menu name".
> Those 3 can all be completely different, but normally/usually
> they're identical.

Well, I still don't see at all the point of that name redundancy,
because as I said, I don't think it makes any sense to show one text
for a menu item (holding a submenu), and show a different text for its
submenu's "prompt".  It is just plain confusing to me.

>> That's a pity.  It would be nice to have those drop-down text menus
>> also on GUI sessions.
> Why?

Text menus have its advantages over the GUI (toolkit) menus.  Emacs
has total control over them, so that one can do things such as
navigate through them with C-f, C-b, C-n, C-p.  Another advantage is
visual integration: the text menus look like the rest of the buffer
text, which is nice.

>>> I tend to close this as not-a-bug.  Any reasons not to?
>> See above, but you are the maintainer, so you decide.
> IIUC the issue is that fixing those things can represent a lot of work,
> whereas they fix only "cosmetic" issues, so it's difficult to justify
> the effort.

Fair enough...  :)

Dani Moncayo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]