RE: No "Edit" menu-item in "Gnus"

["Drew Adams" <drew.adams@oracle.com>]

    > 1. Edit shouldn't be removed from the menu-bar for the sole reason
    > of saving menu-bar space and because the buffer might be
    > unmodifiable.

    Menus are for frequently used commands.

Only? What gave you that idea? It is sometimes very useful to have
infrequently used commands in menus - especially in Emacs. When do you use
the menu-bar? I tend to use it for commands that I've forgotten the name, or
the binding, or the variants of - that is, commands I use infrequently. I
use Vinicius's printing.el stuff via menu, for instance, because there are
printing-command variants that I never remember - I know I'll find them in
the Printing menu.

One advantage menus provide is just that: They organize commands into
classes (and subclasses), letting you look them up in a hierarchy. That's
really what menus "are for", if we must pick one thing. Menus are especially
useful to newbies for just that reason: you can figure out where a command
is by exploring the hierarchy (is it something to do with files? editing?
help?... is it about a bicycle?). In a flat command space, without
organization by classes, it's hard to find commands. (Fortunately, we also
have `apropos'.)

    If in a particular situation the entries of a menu are
    of rare use, and others are more important,
    omitting the rarely used menu might make sense.

Why would it make sense? What's to be gained? Menu-bar space? In that case,
if you can really determine that it is less important, put it on a "More"
menu as a submenu. There is no reason to remove it altogether, if it has
some use in that context.

And, as I said, it's difficult to determine that a menu is truly useless in
some context, because some library might have added to it, making it more
useful. Unmodifiable buffers are one example: If an app adds useful commands
that don't modify things to the Text Properties menu, then that menu becomes
more useful in an unmodifiable buffer.

    > If there is a problem with menu-bar space in some context,
    > then some other solution should be adopted. One solution
    > is to have a pull-down menu (e.g.  "More", "...", or a
    > triangle arrow) that combines some other menus as submenus.
    > Another solution is to let the menu-bar extend over
    > multiple lines when necessary - that's the current default,
    > and it's OK too.
    >
    > It's silly to assume a fixed frame width, in any case, and
    > to base decisions of which menus to include on that width.
    > I shrink-fit frames to fit their buffers, for example, so
    > they have different widths. Other people always maximize
    > their frames, or always use some fixed width that's
    > different from the default.

    The menu bar should fit on an 80-column text tty.

Maybe. And maybe 10 or 20 columns on a cell phone.

But what about the menu-bar on a display with window-manager windows? If an
80-column limit needs to be imposed for ttys, so be it. Emacs on ttys can
just remove menus from the menu-bar as needed. Why should the tty context
determine the design for all Emacs menu-bars? Lowest common denominator has
its limits (did Yogi Berra say that?).

    That is a hard limit that can't be come by by changing font
    sizes or resizing windows.

I can't parse that one. I guess maybe you mean that tty width is a hard
limit. See above - that shouldn't limit the rest of Emacs.