We refer to the buffer on purpose: we want users to see Emacs
terminology even in the menus, and even when the menus are following
established UI guidelines and use standard entries like "New" and
"Close".
Why then do we use Paste instead of Yank?
Menu-item names can serve as a bridge between terms that newbies are used to
and Emacs terminology. Users can find operations they are familiar with in
the menus, and gradually learn the associated commands, which can have very
different names.
It doesn't help if we use common terminology in uncommon ways - see "New"
below.
> a. Currently, there is an inconsistency wrt "Buffer" and
"(current buffer)".
That's not an inconsistency: in the first case, "Buffer" is part of
the command name; in the second, it's a minor comment about the
command's operation.
1. "Save Buffer As" runs command `write-file'. Where's the beef - er -
"buffer"?
2. "Save (current buffer)" runs command `save-buffer'.
3. "Close (current buffer)" runs command `kill-this-buffer'.
4. "Revert Buffer" runs command `revert-buffer'.
- 1,2 & 3 seem opposite of the convention you say is behind the names. 4
confirms your rule, as do the "* Print Buffer" items. Not much of a rule
(explanation).
- The command name is irrelevant here. Again: `yank'.
- A minor comment about a command's operation belongs perhaps in a tooltip
or help, but not in the name of the menu item itself.
> New is better than New File (but see 3, below).
No, it is not better, since it doesn't say what new entity is created.
Other GUI programs have a submenu there or work only with one type of
entities (or just leave it vague, which we didn't want to do).
So "New File" says that a new file is created? Yes, it says that, but it
tells not the truth: no file is created by this operation.
> 3. WRT 2b, it is true that the file or buffer opened need not
in fact be
> new, so even "New" is misleading. The problem arises because
we need a name
> to distinguish
open-new-or-existing-buffer-for-new-or-existing-file from
> Open File (existing file only). A better name for New would
be just "Open".
"New" is a standard entry in the "File" menu, so I don't think
renaming it to (a non-standard) "Open" is a good idea.
The name "New" is standard, but our meaning/use of that name is not so
standard. "New" in many (most?) applications (e.g. Word and Windows Explorer
are common ones) will not let you open an existing document.
Our "Open" can do two things: 1) create new, 2) open existing.
However, "Open Directory" does not create a new directory. That too is a
place where we might consider either renaming the item or extending command
`dired' to incorporate the behavior of `dired-create-directory'.
> 4. A better name for Revert is Reopen.
Do you know of any other GUI applications that have such a menu
entry?
I have seen "Revert to Saved", which is also clearer than "Revert" (and
"Revert Buffer").
My knowledge is limited - you might be right; "Reopen" seems clearer to me,
though. "Reload", which David mentioned, is also clearer (though it also
suggests Columbine or Grand Theft Auto). Web browsers often use "Refresh"
(in the View menu) for reloading a page (although the "reloading" often uses
the cache, by default).
> 5. Move all of the window and frame stuff to a new menu, "Frames".
Not good: we have a crammed menu bar already, adding more top-level
items would only make things worse with no real advantage.
Agreed. But 1) this stuff has little to do with "File"; 2) use of a
"Windows" menu, having a similar purpose, is common in other apps; 3) I
think it is likely that we will have more frame and window commands to add
to a Frames menu in the future.
Again, I didn't expect that much of what I threw out would be agreed upon,
especially in the immediate.
I do think we might agree to rename a few of the items for this release. I'm
thinking, for instance, of "Unsplit Windows".
Another possible renaming I forgot to mention is "Split Window". The window
is not split to result in a single window with a divider. "New Window" would
be a better name for this menu item.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
