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

[Drew Adams]

    >> There are several items on that menu that are useful when
    >> reading mail and news.
    >
    > Which specific items do you have in mind?  I'd guess that at least the
    > most important "Search" and "Go To" items have Gnus equivalents.

    "Select All", "Copy", "Go To > Find Tag", "Beginning of buffer" ...
    (If those are useless in Gnus, then they are useless in everywhere)
    and:
    "Text Properties > Describe Properties"

In general, I'd say:

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.

2. A menu (e.g. Edit) shouldn't be removed unless it's sure that none of its
menu items make sense in the given context. And that's almost never sure,
simply because apps can add items to a menu. A less important, mode-specific
menu might be different, but an important menu like Edit should not be
removed.

3. There are lots of Edit menu items that would make sense in buffers that
currently don't show the Edit menu. I'm thinking of Dired, for example.

Kim mentioned some such items. Others are:

- Syntax Highlighting menu

- Text Properties menu generally - other apps might add to this menu

- Search menu generally (although I think this should be a top-level menu)

- Go To menu generally (although I think Go To belongs under Search)

- Bookmarks menu generally (although I think Bookmarks belongs under Search)

In sum, most of the Edit submenus make sense, even in buffers that cannot be
modified. What's more, applications might add to the Edit menu, and some of
those additions might be appropriate for unmodifiable buffers.

Individual menu items can be made inactive (disabled) when they are not
appropriate in some context. It is inappropriate to remove an important menu
like Edit altogether, presumably because the word "edit" means modify and
the buffer in question is not modifiable.

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.