[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: Stefan Monnier
Subject: bug#15576: 24.3.50; Some minor issues regarding the new TTY menus
Date: Thu, 10 Oct 2013 17:04:01 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> 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,

I don't claim there is "a point" to it.  I'm just explaining why this is
what we have.  This triple redundancy is not good (just like any other
not-automatically-sync'd-redundancy is not good), but it's unlikely to
disappear soon.
To add insult to injury, the "keymap prompt" is usually kept at the very
end of the keymap, so it's "costlyish" to fetch it.

> 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.

Agreed.  We should fix those cases we discover.  IOW please fix the
"Select Buffer" to be just "Buffer".

>>> 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.

At least with the Gtk menus, C-f/C-b/C-n/C-p work just fine.  But indeed
it probably depends on the toolkit.

> Another advantage is visual integration: the text menus look like the
> rest of the buffer text, which is nice.

Well, I'll probably welcome a patch that makes the code work in GUI
sessions, but I don't think Eli (nor I) will be very motivated to work
on it.


reply via email to

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