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

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

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Hi Eli,

First of all, thanks for implementing drop-down text menus.  They are
way better that the text-mode-menus implemented so far.

Here are some minor issues I've noticed after a quick test:

1. The "Buffers" menu becomes "Select Buffers" when selected (see
capture-1.png).  I think that the text of the menus should not change
upon selection.

2. When I select the "Help" menu, the drop-down list is shown shifted a
bit to the left wrt its "normal" position, because of lack of enough
space at the right side of the window (see capture-2.png).  That's OK,
but the menu header ("Help") should not be shifted at all from its
original position (only the drop-down list should be).  As you can see,
the "elp" string at the right side looks weird.  IMO, TRT would be to
show something like capture-2-fixed.png.

3. From a GUI session, disable menu-bar-mode and type F10.  I see that
the old text mode menu is shown.  Why not show the new drop-down text
menu instead?

Thanks.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-09 on LEG570
Bzr revision: 15565 eliz@gnu.org-20131009145313-a2ht28fv2r8hozxy
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

-- 
Dani Moncayo

[-- Attachment #2: capture-1.png --]
[-- Type: image/png, Size: 10808 bytes --]

[-- Attachment #3: capture-2.png --]
[-- Type: image/png, Size: 13180 bytes --]

[-- Attachment #4: capture-2-fixed.png --]
[-- Type: image/png, Size: 12847 bytes --]

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

[Eli Zaretskii]

> Date: Wed, 9 Oct 2013 21:06:13 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> First of all, thanks for implementing drop-down text menus.  They are
> way better that the text-mode-menus implemented so far.

You are welcome.

> 1. The "Buffers" menu becomes "Select Buffers" when selected (see
> capture-1.png).  I think that the text of the menus should not change
> upon selection.

The text shown at the top of the menu is the so-called "prompt string"
that comes from the menu structure.  And in menu-bar.el we have this:

         ;; We used to "(define-key (current-global-map) [menu-bar buffer]"
         ;; but that did not do the right thing when the [menu-bar buffer]
         ;; entry above had been moved (e.g. to a parent keymap).
	 (setcdr global-buffers-menu-map (cons "Select Buffer" buffers-menu)))))
                                               ^^^^^^^^^^^^^^^

The menu display code does not invent anything, it just shows what's
in the menu.  If you want to change that, change menu-bar.el.
(Personally, I don't see why "Select Buffer" is wrong here, but that's
me.)

> 2. When I select the "Help" menu, the drop-down list is shown shifted a
> bit to the left wrt its "normal" position, because of lack of enough
> space at the right side of the window (see capture-2.png).  That's OK,
> but the menu header ("Help") should not be shifted at all from its
> original position (only the drop-down list should be).

The menu is dropped as a single entity, and the heading (the prompt
string) starts at the left edge of the menu.  So this is by design,
and won't change.

> As you can see, the "elp" string at the right side looks weird.

It doesn't look weird to me, but I'm used to this.  Try clicking the
mouse on the menu bar, somewhere within the "Help" string, and you
will see that the menu is dropped where the mouse clicks, not
necessarily where the "Help" is.

IOW, this is a feature.

> 3. From a GUI session, disable menu-bar-mode and type F10.  I see that
> the old text mode menu is shown.  Why not show the new drop-down text
> menu instead?

Because the code for the new drop-down text menu will not work in the
GUI session.  The internals of the display engine which the menu code
piggy-backs are completely different in the GUI mode.

I tend to close this as not-a-bug.  Any reasons not to?

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

[Dani Moncayo]

>> 1. The "Buffers" menu becomes "Select Buffers" when selected (see
>> capture-1.png).  I think that the text of the menus should not change
>> upon selection.
>
> The text shown at the top of the menu is the so-called "prompt string"
> that comes from the menu structure.  And in menu-bar.el we have this:
>
>          ;; We used to "(define-key (current-global-map) [menu-bar buffer]"
>          ;; but that did not do the right thing when the [menu-bar buffer]
>          ;; entry above had been moved (e.g. to a parent keymap).
>          (setcdr global-buffers-menu-map (cons "Select Buffer" buffers-menu)))))
>                                                ^^^^^^^^^^^^^^^
>
> The menu display code does not invent anything, it just shows what's
> in the menu.  If you want to change that, change menu-bar.el.
> (Personally, I don't see why "Select Buffer" is wrong here, but that's
> me.)

I think "Select Buffer" is wrong simply because it is different from
"Buffers".  I mean, what is the point of showing one text (Buffers)
when the menu is not selected, and another text (Select Buffer) when
it is?  I've not seen such a thing before anywhere, and I don't see
what sense it does make.  (the GUI "Buffer" menu of course does not
exhibits such a strange behavior).

>> 2. When I select the "Help" menu, the drop-down list is shown shifted a
>> bit to the left wrt its "normal" position, because of lack of enough
>> space at the right side of the window (see capture-2.png).  That's OK,
>> but the menu header ("Help") should not be shifted at all from its
>> original position (only the drop-down list should be).
>
> The menu is dropped as a single entity, and the heading (the prompt
> string) starts at the left edge of the menu.

That's the current behavior, yes.

> So this is by design, and won't change.

Well, the current design is surely simpler, but IMO it is definitely
not the best one.  When I am navigating through the top level menus I
obviously expect every header to stay where it was before it was
selected.  When I type C-f to reach the "Help" menu (from the
Lisp-Interaction menu) and see that weird effect... mmm it clearly
feels counter intuitive to me.

>> As you can see, the "elp" string at the right side looks weird.
>
> It doesn't look weird to me, but I'm used to this.

?? What sense does it make to show that residual "elp" string at the
right of the "Help" header?  It is not the end of the world, but I
really don't think it is TRT either.

> Try clicking the
> mouse on the menu bar, somewhere within the "Help" string, and you
> will see that the menu is dropped where the mouse clicks, not
> necessarily where the "Help" is.

The mouse doesn't work here (on a TTY session).

> IOW, this is a feature.

I hope you to reconsider that, because IMHO it is a misfeature.

>> 3. From a GUI session, disable menu-bar-mode and type F10.  I see that
>> the old text mode menu is shown.  Why not show the new drop-down text
>> menu instead?
>
> Because the code for the new drop-down text menu will not work in the
> GUI session.  The internals of the display engine which the menu code
> piggy-backs are completely different in the GUI mode.

That's a pity.  It would be nice to have those drop-down text menus
also on GUI sessions.  Then consider this point a feature request then
(who knows, perhaps some day it might be implemented).

> I tend to close this as not-a-bug.  Any reasons not to?

See above, but you are the maintainer, so you decide.

-- 
Dani Moncayo

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

[Eli Zaretskii]

severity 15576 wishlist
thanks

> Date: Wed, 9 Oct 2013 22:11:48 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15576@debbugs.gnu.org
> 
> I think "Select Buffer" is wrong simply because it is different from
> "Buffers".  I mean, what is the point of showing one text (Buffers)
> when the menu is not selected, and another text (Select Buffer) when
> it is?

I don't know.  Perhaps someone thought of this as a prompt.

Anyway, the way to change that is in menu-bar.el, where the menu is
constructed.

> >> As you can see, the "elp" string at the right side looks weird.
> >
> > It doesn't look weird to me, but I'm used to this.
> 
> ?? What sense does it make to show that residual "elp" string at the
> right of the "Help" header?

The same sense as does showing the text under the menu, which is also
partially obscured.

You seem to think about "Help" on the menu bar as part of the dropped
menu.  But it isn't: it is just part of the normal TTY frame display,
like the text in the text area.  They both are partially obscured by
the menu.

> > Try clicking the
> > mouse on the menu bar, somewhere within the "Help" string, and you
> > will see that the menu is dropped where the mouse clicks, not
> > necessarily where the "Help" is.
> 
> The mouse doesn't work here (on a TTY session).

I thought you were on Windows.  If not, try there, the mouse should
work for dropping menus.

> >> 3. From a GUI session, disable menu-bar-mode and type F10.  I see that
> >> the old text mode menu is shown.  Why not show the new drop-down text
> >> menu instead?
> >
> > Because the code for the new drop-down text menu will not work in the
> > GUI session.  The internals of the display engine which the menu code
> > piggy-backs are completely different in the GUI mode.
> 
> That's a pity.  It would be nice to have those drop-down text menus
> also on GUI sessions.  Then consider this point a feature request then
> (who knows, perhaps some day it might be implemented).
> 
> > I tend to close this as not-a-bug.  Any reasons not to?
> 
> See above, but you are the maintainer, so you decide.

Well, you have wishlist now.  Volunteers are welcome to implement
those changes.

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

[Dani Moncayo]

>> > Try clicking the
>> > mouse on the menu bar, somewhere within the "Help" string, and you
>> > will see that the menu is dropped where the mouse clicks, not
>> > necessarily where the "Help" is.
>>
>> The mouse doesn't work here (on a TTY session).
>
> I thought you were on Windows.  If not, try there, the mouse should
> work for dropping menus.

For the record:  I was (am) on Windows.  The mouse didn't work here
because I had "Quick Edit Mode" turned on.  (checkbox in the
"Properties" dialog of the console window, "Options" tab).

If I turn that mode off, the mouse does work on TTY menus.

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

[Stefan Monnier]

> I think "Select Buffer" is wrong simply because it is different from
> "Buffers".  I mean, what is the point of showing one text (Buffers)
> when the menu is not selected, and another text (Select Buffer) when
> it is?  I've not seen such a thing before anywhere, and I don't see
> what sense it does make.

You'd see it if you build Emacs with X11 but without GUI toolkit.
This used to be the only case where the "keymap prompt" is used for the
menus (it's also used for the title of the popup menus, tho).

It's largely a historical accident, but here's the technical background:
menus are represented in Emacs as keymaps which (as a first
approximation) are alists mapping events to "menu-items".  A menu-item
is (again, to a first approximation) a pair of a chunk of text (to be
displayed in the menu) and the corresponding binding (either a command
or another keymap if it's a submenu).
When you get a "submenu", the submenu is just the (sub)keymap, rather
than the menu-item that holds this sub-keymap, so you don't know the
name that was displayed for that submenu.  So in order to display
a "title", you need the keymap to carry a "name" (which is called the
keymap-prompt).
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.

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

Why?

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


        Stefan

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

[Dani Moncayo]

> 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

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

[Drew Adams]

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

Dani, the point of having potentially different names is that there are
different uses of a given menu, including the popup case that Stefan
described and which is fairly rare.

But yes, nothing prevents someone from using the same name for all
three uses.  IOW, you *can* use different names for different uses,
but nothing requires you to.

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

[Stefan Monnier]

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


        Stefan