No "Edit" menu-item in "Gnus"

No "Edit" menu-item in "Gnus"

[Kim F. Storm]

Why does Gnus hide the Edit menu item?

There are several items on that menu that are useful when reading mail
and news.

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

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Why does Gnus hide the Edit menu item?
>
> There are several items on that menu that are useful when reading mail
> and news.

Maybe we should have the Edit menu selectively grey out what does not
work on read-only buffers?  This is partly done, but somewhat
inconsistently.  For example, "Yank" is allowed.  The definition of
x-clipboard-yank does not have an (interactive "*") spec.  I don't
know whether that is the reason, or whether the interactive-spec does
not get consulted automatically.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jan Djärv]

David Kastrup writes:
> storm@cua.dk (Kim F. Storm) writes:
> 
>> Why does Gnus hide the Edit menu item?
>>
>> There are several items on that menu that are useful when reading mail
>> and news.
> 
> Maybe we should have the Edit menu selectively grey out what does not
> work on read-only buffers?  This is partly done, but somewhat
> inconsistently.  For example, "Yank" is allowed.  The definition of
> x-clipboard-yank does not have an (interactive "*") spec.  I don't
> know whether that is the reason, or whether the interactive-spec does
> not get consulted automatically.

It is because the function clipboard-yank didn't have one.  Maybe they both 
should have one?  But those are not automatically applied to the menu, I've 
made a change in x-win.el so that paste is disabled for read-only buffers.

	Jan D.

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

[Reiner Steib]

[ Adding ding ]

On Mon, Aug 14 2006, Kim F. Storm wrote:

> Why does Gnus hide the Edit menu item?

Probably because there's not enough horizontal space in the menu bar,
depending on the fonts.  (IIRC does hide it since ages.  What's the
occasion that you bring it up now?)

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

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Richard Stallman]

    Maybe we should have the Edit menu selectively grey out what does not
    work on read-only buffers?  This is partly done, but somewhat
    inconsistently.  For example, "Yank" is allowed.

Can you propose specific patches to do this?

      The definition of
    x-clipboard-yank does not have an (interactive "*") spec.

It ought to have one; could you add that?

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

[Kim F. Storm]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

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

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Jason Rumney]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Probably because there's not enough horizontal space in the menu bar,
> depending on the fonts.

That is true of the summary buffer, but not the Article buffer, where
the functions that others have pointed out are most useful.

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.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

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

Menus are for frequently used commands.  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.

> 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.  That is a hard
limit that can't be come by by changing font sizes or resizing
windows.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 16 Aug 2006 00:22:15 +0200
> Cc: Gnus <ding@gnus.org>, emacs-devel@gnu.org
> 
> Menus are for frequently used commands.  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.

That's true, but I don't think "Edit" items are so rarely used in this
case.

> The menu bar should fit on an 80-column text tty.  That is a hard
> limit that can't be come by by changing font sizes or resizing
> windows.

I think rearranging the Gnus-specific menu bar items so that there are
fewer top-level items can solve the problem without exceeding this
limit.

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

[Jan Djärv]

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



Reiner Steib skrev:
> [ Adding ding ]
> 
> On Mon, Aug 14 2006, Kim F. Storm wrote:
> 
>> Why does Gnus hide the Edit menu item?
> 
> Probably because there's not enough horizontal space in the menu bar,
> depending on the fonts.

FWIW, the GTK menu bar has a drop down button as last entry for those entries 
that doesn't fit, quite nice actually.  See attached picture.

	Jan D.


[-- Attachment #2: menus.jpg --]
[-- Type: image/jpeg, Size: 19701 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Reiner Steib skrev:
>> [ Adding ding ]
>>
>> On Mon, Aug 14 2006, Kim F. Storm wrote:
>>
>>> Why does Gnus hide the Edit menu item?
>>
>> Probably because there's not enough horizontal space in the menu bar,
>> depending on the fonts.
>
> FWIW, the GTK menu bar has a drop down button as last entry for those
> entries that doesn't fit, quite nice actually.  See attached picture.

The topic was the menu bar, not the toolbar.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Reiner Steib skrev:
>>> [ Adding ding ]
>>>
>>> On Mon, Aug 14 2006, Kim F. Storm wrote:
>>>
>>>> Why does Gnus hide the Edit menu item?
>>> Probably because there's not enough horizontal space in the menu bar,
>>> depending on the fonts.
>> FWIW, the GTK menu bar has a drop down button as last entry for those
>> entries that doesn't fit, quite nice actually.  See attached picture.
> 
> The topic was the menu bar, not the toolbar.
> 

It is too early in the morning here obviously....

	Jan D.

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

[Drew Adams]

    >>> Why does Gnus hide the Edit menu item?
    >>
    >> Probably because there's not enough horizontal space in the menu bar,
    >> depending on the fonts.
    >
    > FWIW, the GTK menu bar has a drop down button as last entry for those
    > entries that doesn't fit, quite nice actually.  See attached picture.

    The topic was the menu bar, not the toolbar.

You're right about that, but this idea was exactly what I meant - do the
same thing for menus, not just toolbar icons.

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

[Richard Stallman]

    FWIW, the GTK menu bar has a drop down button as last entry for those entries 
    that doesn't fit, quite nice actually.  See attached picture.

In that case, we would want the least useful menu bar items
to be the ones that wind up in that indirect bucket.