RE: File menu changes (suggestions) / Options menu

RE: File menu changes (suggestions) / Options menu

[David Reitter]

Drew Adams wrote:

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

It doesn't matter what command names are behind the menu entries.  
Some of the command names seem inconsistent anyways, and a user  
doesn't necessarily care for command names. A user wants to save the  
current buffer. She can either save it, or save it "as" something.  
Hence, the menu entries should be "Save" and "Save as...". If we need  
to inform the user how to do the same thing with keyboard commands,  
we do so afterwards. If the user wants to access the stuff  
programmatically (very rare), he can always do a C-h k.

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

The version I'm working with has "Open" (not New), and if it is  
"New" (but means find-file), it should be renamed. "new" creates  
something new, i.e. an empty buffer - and doesn't load an existing  
file. The problem may be that find-file can also create a new file.  
If you want to stick with that, rename the entry to "New/Open..."

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

I agree with both of you. I would suggest to stick it in the Buffers  
menu. There is room for it, and we have a "Frames" submenu in the  
Buffers menu when there is more than one frame. It would nicely  
correlate to the "Windows" menu existing in standard GUIs, but  
because so many people work with a single frame and switch between  
buffers, it makes sense to stick to the menu title "buffers" and have  
frames as a submenu, and split/unsplit on the top-level hierarchy,  
separated with a line separator.

Can I make another suggestion?
Some items in the Options menu are buffer-local (truncate-lines),  
while most are global. It would be smart to separate the two kinds of  
items.
I'm not sure about the "case-insensitive search". In Aquamacs, I have  
moved it to the Edit/search sub-menu.

It would also be good if someone could work on making "Set Font/ 
Fontset" a proper sub-menu (this might be Carbon specific, I don't  
know).

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

It seems quite clear to me that given the semantics
of Emacs' file-open there can never be a happy choice
between New and Open.  This is because in the CUA
world these operations have clear implications about
the existence or non-existence of the argument object.

New and Open have readily understood and internalize
failure semantics.  Users do not view such failures
as inefficiencies or a lack of DWIM in the interface.
They experience it instead as a confidence building
feature: either their expressed intent is successfully
carried out or they receive an indication of a failure.

OTOH Emacs' file-open offers no way to express such
detailed intent.  Instead it smears the distinction
that separate New and Open present.

One solution might be to add an optional tri-valued
argument to find-file: CLASSIC, NEW, EXISTING.

/john

Re: File menu changes (suggestions)

[Miles Bader]

On 6/22/05, John S. Yates, Jr. <john@yates-sheets.org> wrote:
> They experience it instead as a confidence building
> feature

Who's this "they"?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Thu, 23 Jun 2005 09:46:02 +0900, you wrote:

>On 6/22/05, John S. Yates, Jr. <john@yates-sheets.org> wrote:
>> They experience it instead as a confidence building
>> feature
>
>Who's this "they"?

My bad.  Earlier I wrote "... in the CUA world ...".  The unclear
"they" was meant to refer to those working primarily with GUI
applications conforming to some variant of CUA, be it MS Windows
Mac OS or some X-based desktop.

Also, I must confess that, after posting from home this morning my
earlier note, on my drive into work I realized I was only one half
correct in my description of the Emacs / CUA clash.  That is my
description of the mismatch between file-open and traditional CUA
Open.. was more or less correct.  The clash between file-open and
New.. is the fact that file-open always inspects the directory and
alters its behavior based on whether the requested filename exists.

Thus file-open always establishes early the name under which a user's
buffer will be saved.  CUA New.. by contrast creates a new document
associated with a mechanically generated vacuous filename, guaranteed
to be unique.  The user then supplies the desired filename later via
the SaveAs.. operation.

/john

Re: File menu changes (suggestions)

[Miles Bader]

On 6/23/05, John S. Yates, Jr. <john@yates-sheets.org> wrote:
> >> They experience it instead as a confidence building
> >> feature
> >
> >Who's this "they"?
> 
> My bad.  Earlier I wrote "... in the CUA world ...".  The unclear
> "they" was meant to refer to those working primarily with GUI
> applications conforming to some variant of CUA, be it MS Windows
> Mac OS or some X-based desktop

Yeah I kind of assumed that.  My question was more as to how you know
what "they" want/like[*].  It seems reasonably clear that the
different models will lead to some confusion when switching between
them, but is there really evidence of some inherent preference?

It seems to me that both models are convenient/comforting in some
situations and annoying/restrictive in others.

[*] Who is this "we", white man?!?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Thu, 23 Jun 2005 11:31:01 +0900, you wrote:

>Yeah I kind of assumed that.  My question was more as to how you know
>what "they" want/like[*].  It seems reasonably clear that the
>different models will lead to some confusion when switching between
>them, but is there really evidence of some inherent preference?
>
>It seems to me that both models are convenient/comforting in some
>situations and annoying/restrictive in others.

I can see that my original point really did not come through.  Let
me try again...

I think that we are doing a poor job of seducing CUA-reared would-be
users into Emacs-hood by grafting-on a CUA-like menu facade when the
very first menu likely to be invoked exposes our neophytes to a false
similarity.

Rather than argue about which common CUA name most closely matches
some Emacs function that we feel we need to expose, a way to truly
proper matches would be to think about how we might modify Emacs --
which we boast to ourselves is so infinitely malleable -- so that it
might present truly CUA-like behavior.  If one accepts this premise
then some amount of reflecting on where presently insurmountable
mismatches exist and what extensions might allow Emacs to overcome
those mismatches is in order.

Hence my original -- though admittedly flawed -- proposal.

/john

Re: File menu changes (suggestions)

[Miles Bader]

"John S. Yates, Jr." <john@yates-sheets.org> writes:
> I think that we are doing a poor job of seducing CUA-reared would-be
> users into Emacs-hood by grafting-on a CUA-like menu facade when the
> very first menu likely to be invoked exposes our neophytes to a false
> similarity.

Where there it's possible to use a similar layout to other common
systems, that's done, but I don't think there's really any attempt at
all to clone CUA, and doing so is not the goal.

In other words, it's good to remove gratuitous differences from other
popular apps -- but not at the cost of actually changing the Emacs
interface.  The menus reflect the interface.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: File menu changes (suggestions)

[Richard M. Stallman]

    Rather than argue about which common CUA name most closely matches
    some Emacs function that we feel we need to expose, a way to truly
    proper matches would be to think about how we might modify Emacs --
    which we boast to ourselves is so infinitely malleable -- so that it
    might present truly CUA-like behavior.

I agree with Miles about this.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Fri, 24 Jun 2005 01:36:14 -0400, RMS wrote:

>    Rather than argue about which common CUA name most closely matches
>    some Emacs function that we feel we need to expose, a way to truly
>    proper matches would be to think about how we might modify Emacs --
>    which we boast to ourselves is so infinitely malleable -- so that it
>    might present truly CUA-like behavior.
>
>I agree with Miles about this.

Does that mean that you dis / repudiate Kim's work on CUA-mode?

I was not advocating an incompatible change to file-open.  Rather
I think it is well within the Emacs philosophy to extend file-open
so that it could be configured to provide CUA-like semantics.

/john

Re: File menu changes (suggestions)

[Richard M. Stallman]

    Does that mean that you dis / repudiate Kim's work on CUA-mode?

I thought we were talking about the standard Emacs behavior.  CUA-mode
as an optional mode is a separate issue.  I am not saying anything
about that.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "John S. Yates, Jr." <john@yates-sheets.org>
> Date: Thu, 23 Jun 2005 07:18:15 -0400
> 
> Rather than argue about which common CUA name most closely matches
> some Emacs function that we feel we need to expose, a way to truly
> proper matches would be to think about how we might modify Emacs --
> which we boast to ourselves is so infinitely malleable -- so that it
> might present truly CUA-like behavior.

I think Emacs cannot by default present a truly CUA-like behavior
because its default key bindings and frequent commands originated
elsewhere, and are very old and entrenched in our user base.  Where we
could follow CUA guidelines without disrupting old traditions, we
already did.

There's an optional CUA Mode in Emacs; perhaps it should modify the
menu structure to be more CUA-like.  This could make CUA-infected
newbies happier.

Re: File menu changes (suggestions)

[LENNART BORGMAN]

From: David Kastrup <dak@gnu.org>

> I think the main point is that the mode is set from auto-mode-alist,
> and that things like auto-insert work.  Specifying the file name saves
> specifying mode and stuff.

And understanding how the mode is choosen is one of the difficult things for beginners (and several others;-)

I would suggest that New Something always gets a file name. And I would suggest that the user picks this as now.

Re: File menu changes (suggestions)

[LENNART BORGMAN]

From: "Richard M. Stallman" <rms@gnu.org>

>     > Maybe instead "New File Buffer"? It is actually a new 
> buffer that  
>    is setup so that it will be associated with a file.
> 
>    I think that'd be the ideal.
>    I think many people can't associate much with the concept of 
> "visiting".
> I explained why I don't like "New File Buffer".  Instead of "Visit",
> maybe some other verb is clearer, such as "Start", "Prepare", "Edit".

I believe "New <something/nothing>" is far better than your last suggestions. They are not familiar in this context.

Re: File menu changes (suggestions)

[Miles Bader]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:
>> I explained why I don't like "New File Buffer".  Instead of "Visit",
>> maybe some other verb is clearer, such as "Start", "Prepare", "Edit".
>
> I believe "New <something/nothing>" is far better than your last
> suggestions. They are not familiar in this context.

It's better to use a slightly less common word than not make sense.
"Familiar in this context" is not some sort of trump card, merely one
thing to consider.

The Emacs command is indeterminate (as to whether the file exists or
not), so the menu name should be as well.  I like "Visit File" best
myself; another possibility is to use explicitly indeterminate wording,
like "New/Open File".

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: File menu changes (suggestions)

[Johan Bockgård]

Miles Bader <miles@lsi.nec.co.jp> writes:

> another possibility is to use explicitly indeterminate wording, like
> "New/Open File".

I think that might work.

-- 
Johan Bockgård

Re: File menu changes (suggestions)

[David Reitter]

Lennart Borgman wrote:

 > Maybe instead "New File Buffer"? It is actually a new buffer that  
is setup so that it will be associated with a file.

I think that'd be the ideal.
I think many people can't associate much with the concept of "visiting".

Re: File menu changes (suggestions)

[Richard M. Stallman]

     > Maybe instead "New File Buffer"? It is actually a new buffer that  
    is setup so that it will be associated with a file.

    I think that'd be the ideal.
    I think many people can't associate much with the concept of "visiting".

I explained why I don't like "New File Buffer".  Instead of "Visit",
maybe some other verb is clearer, such as "Start", "Prepare", "Edit".

File menu changes (suggestions)

[Drew Adams]

Suggestions to change some File menu items. A few of the renamings might be
considered for this release.

1. Unsplit Windows is a very poor name. It doesn't give you a hint of what
it does; in particular, it doesn't suggest that the current window is the
only one that will remain displayed.

It should be named something like `Delete Other Windows' or simply
`One Window'.

2. Don't reference "buffer" or "file" in File menu items, when this just
refers to the current buffer/file (or the one that will become current). The
unreferenced object in a File menu item is understood to be the current
buffer/file. And the distinction between file and buffer is not needed here.

 - New File                    -> New (but Open is better - see 3, below)
 - Save (current buffer)       -> Save
 - Close (current buffer)      -> Close
 - Save Buffer As              -> Save As
 - Print Buffer                -> Print
 - PostScript Print Buffer     -> PostScript Print
 - Revert Buffer               -> Revert

People are used to all of these File commands in other applications. You
don't see "Save Page" or "Close Page" in Web-browsers or "Save File" in
other editors.

In particular:

a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)".
These should be made consistent, since the same thing (the current buffer)
is involved in each case. It is not as if one acted on the current buffer
and the other prompted for an existing buffer to act upon.

b. New File does not really create a new file; it opens a buffer (new or
existing) that can be saved to a file (new or existing). Not mentioning
"file" and "buffer" avoids the distinction, which doesn't matter here
anyway. Mentioning "file" and "buffer", and using "file" where it should be
"buffer", just misleads. So, New is better than New File (but see 3, below).


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".
Open File is technically "open existing file", but "Open File" is adequate
for this action, and it fits with Open Directory and Insert File - explicit
mention of "File" suggests an existing file here.


4. A better name for Revert is Reopen. Just as Paste is preferable to Yank
in a menu, so is Reopen preferable to Revert: more users will understand it
immediately.


5. Move all of the window and frame stuff to a new menu, "Frames". This menu
is analogous to the "Buffers" menu.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 19 Jun 2005 16:25:53 -0700
> 
> 2. Don't reference "buffer" or "file" in File menu items, when this just
> refers to the current buffer/file (or the one that will become current). The
> unreferenced object in a File menu item is understood to be the current
> buffer/file. And the distinction between file and buffer is not needed here.
> 
>  - New File                    -> New (but Open is better - see 3, below)
>  - Save (current buffer)       -> Save
>  - Close (current buffer)      -> Close
>  - Save Buffer As              -> Save As
>  - Print Buffer                -> Print
>  - PostScript Print Buffer     -> PostScript Print
>  - Revert Buffer               -> Revert
> 
> People are used to all of these File commands in other applications. You
> don't see "Save Page" or "Close Page" in Web-browsers or "Save File" in
> other editors.

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

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

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

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

> 4. A better name for Revert is Reopen.

Do you know of any other GUI applications that have such a menu
entry?

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

Re: File menu changes (suggestions)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> 4. A better name for Revert is Reopen.
>
> Do you know of any other GUI applications that have such a menu
> entry?

xpdf, xdvi and ggv have "Reload", gimp has "Revert".

I have not seen any "Reopen".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: File menu changes (suggestions)

[Drew Adams]

    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.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 20 Jun 2005 09:53:13 -0700
> 
>     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?

It's not the same: "buffer" is _in_addition_ to "Save" etc., not
_instead_ of them.

> Menu-item names can serve as a bridge between terms that newbies are used to
> and Emacs terminology.

Exactly: thus "Save Buffer As" includes both the familiar "Save As"
and the reference to "buffer".

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

Wed are miscommunicating: I didn't mean the name of the Lisp function,
I meant the command name that appears in the menu.

> - The command name is irrelevant here.

I disagree.

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

There were a lot of iterations about this, the current situation was a
compromise between what different people wanted.  Let's not go there
again.

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

A lone "New" isn't better.  I think we didn't find a better
alternative.

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

Richard didn't want that, since in Emacs, `window' means something
different.

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

I think other applications use the same name.  Perhaps just "Split"
would be better, I don't know.

RE: File menu changes (suggestions)

[Drew Adams]

    We are miscommunicating: I didn't mean the name of the Lisp function,
    I meant the command name that appears in the menu.

    > - The command name is irrelevant here.

    I disagree.

Obviously, if I thought you were speaking of the Lisp command name, then
that is what I meant was irrelevant here. And the menu command name is
obviously relevant to the menu command name (!). And the rest of the line
you quote read "Again: `yank'.", making it even clearer that I meant that
the Lisp command name was irrelevant to the menu command name. Is that what
you disagree with?

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

    Richard didn't want that, since in Emacs, `window' means something
    different.

I proposed "Frames", not "Windows" - see just above. I simply mentioned that
a menu (called "Windows") with a similar purpose is a common occurrence.

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

    I think other applications use the same name.  Perhaps just "Split"
    would be better, I don't know.

Verbs without objects in the File menu should, by default, refer to the
default object for that menu, which is the current file/buffer. "Split" by
itself would not suggest that a new window was to be created. It might
suggest that the current file/buffer would be split, but that is not what
happens.

What's wrong with "New Window" for the menu command to create a new window?

Re: File menu changes (suggestions)

[Richard Stallman]

	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?

Each one of these words is a different issue.
Please do not start arguments based on a mistaken
idea that they should be treated uniformly.
That kind of discussion is not useful, and it is a waste
of time.  We consider these issues one by one.

Re: File menu changes (suggestions)

[Mathias Dahl]

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

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

I do not agree. "Split Window" is in my opinion a very good
description of what that command does. I don't understand what you
mean by "a single window with a divider": how would that look? If the
window has a divider how can there only be one window?

Re: File menu changes (suggestions)

[Miles Bader]

On 6/21/05, Mathias Dahl <brakjoller@gmail.com> wrote:
> > Another possible renaming I forgot to mention is "Split Window". The
> > window is not split to result in a single window with a
> > divider.
> 
> I do not agree. "Split Window" is in my opinion a very good
> description of what that command does.

Indeed.  Morever, it gives important information about the way the
command works (which something like "new window" would _not_ do, and
might actually be more confusing for that reason).

Remember, the goal is not to be perfectly consistent with other apps,
merely to provide a reasonable compromise that will help users of
other apps adapt quickly and painlessly to emacs, and hopefully lead
to them becoming skillful users of Emacs.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Richard M. Stallman]

I've now read all the mail in this thread, and here are my conclusions.

    1. Unsplit Windows is a very poor name. It doesn't give you a hint of what
    it does; in particular, it doesn't suggest that the current window is the
    only one that will remain displayed.

I agree this name is sort of confusing.  I do not see any obvious
right name, but I came up with Absorb Other Windows, which I think is
pretty clear.  I have been trying to think of other verbs, but I can't
find one that is entirely right.  "Devour"?  "Ingest"?  "Conquer"?

    a. Currently, there is an inconsistency wrt "Buffer" and "(current buffer)".
    These should be made consistent, since the same thing (the current buffer)
    is involved in each case.

I agree that that is inconsistent.  It does not seem to be a useful
distinction, as currently made.  So I propose to remove "Buffer" from
well-known operations, and leave it in names of operations that are
unusual or where it contrasts with "Region".

Here are the changes I propose to make.

People pointed out that "New File" might be confusing
since it does not in fact make a new file.  I think the name
"Visit New File" will help show that this isn't the same as the usual
"New File" operation.

Please write to me if you see a problem with these changes, or want to
suggest an alteration in one of these changes.


*** menu-bar.el	17 Jun 2005 09:37:17 -0400	1.260
--- menu-bar.el	25 Jun 2005 19:15:51 -0400	
***************
*** 99,111 ****
  	      :help "Open a new frame"))
  
  (define-key menu-bar-file-menu [one-window]
!   '(menu-item "Unsplit Windows" delete-other-windows
  	      :enable (not (one-window-p t nil))
! 	      :help "Make selected window fill its frame"))
  
  (define-key menu-bar-file-menu [split-window]
    '(menu-item "Split Window" split-window-vertically
! 	      :help "Split selected window in two"))
  
  (define-key menu-bar-file-menu [separator-window]
    '(menu-item "--"))
--- 99,111 ----
  	      :help "Open a new frame"))
  
  (define-key menu-bar-file-menu [one-window]
!   '(menu-item "Absorb Other Windows" delete-other-windows
  	      :enable (not (one-window-p t nil))
! 	      :help "Selected window swallows all windows in the frame"))
  
  (define-key menu-bar-file-menu [split-window]
    '(menu-item "Split Window" split-window-vertically
! 	      :help "Split selected window in two windows"))
  
  (define-key menu-bar-file-menu [separator-window]
    '(menu-item "--"))
***************
*** 159,170 ****
  					 (current-buffer))))))
  	      :help "Re-read current buffer from its file"))
  (define-key menu-bar-file-menu [write-file]
!   '(menu-item "Save Buffer As..." write-file
  	      :enable (not (window-minibuffer-p
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Write current buffer to another file"))
  (define-key menu-bar-file-menu [save-buffer]
!   '(menu-item "Save (current buffer)" save-buffer
  	      :enable (and (buffer-modified-p)
  			   (buffer-file-name)
  			   (not (window-minibuffer-p
--- 159,170 ----
  					 (current-buffer))))))
  	      :help "Re-read current buffer from its file"))
  (define-key menu-bar-file-menu [write-file]
!   '(menu-item "Save As..." write-file
  	      :enable (not (window-minibuffer-p
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Write current buffer to another file"))
  (define-key menu-bar-file-menu [save-buffer]
!   '(menu-item "Save" save-buffer
  	      :enable (and (buffer-modified-p)
  			   (buffer-file-name)
  			   (not (window-minibuffer-p
***************
*** 175,183 ****
    '(menu-item "--"))
  
  (define-key menu-bar-file-menu [kill-buffer]
!   '(menu-item "Close (current buffer)" kill-this-buffer
  	      :enable (kill-this-buffer-enabled-p)
! 	      :help "Discard current buffer"))
  (define-key menu-bar-file-menu [insert-file]
    '(menu-item "Insert File..." insert-file
  	      :enable (not (window-minibuffer-p
--- 175,183 ----
    '(menu-item "--"))
  
  (define-key menu-bar-file-menu [kill-buffer]
!   '(menu-item "Close" kill-this-buffer
  	      :enable (kill-this-buffer-enabled-p)
! 	      :help "Discard (kill) current buffer"))
  (define-key menu-bar-file-menu [insert-file]
    '(menu-item "Insert File..." insert-file
  	      :enable (not (window-minibuffer-p
***************
*** 194,200 ****
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Read an existing file into an Emacs buffer"))
  (define-key menu-bar-file-menu [new-file]
!   '(menu-item "New File..." find-file
  	      :enable (not (window-minibuffer-p
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Read or create a file and edit it"))
--- 194,200 ----
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Read an existing file into an Emacs buffer"))
  (define-key menu-bar-file-menu [new-file]
!   '(menu-item "Visit New File..." find-file
  	      :enable (not (window-minibuffer-p
  			    (frame-selected-window menu-updating-frame)))
  	      :help "Read or create a file and edit it"))

Re: File menu changes (suggestions)

[Lennart Borgman]

Richard M. Stallman wrote:

>People pointed out that "New File" might be confusing
>since it does not in fact make a new file.  I think the name
>"Visit New File" will help show that this isn't the same as the usual
>"New File" operation.
>
Does not "Visit New File" also imply that a new file is made?

Maybe instead "New File Buffer"? It is actually a new buffer that is 
setup so that it will be associated with a file.

Re: File menu changes (suggestions)

[Richard M. Stallman]

    Does not "Visit New File" also imply that a new file is made?

It does not have that implication for me.  The word "visit" takes
away the implication that it _creates_ the new file.

Maybe some other word is better than "visit", but I can't think of one
now.

    Maybe instead "New File Buffer"? It is actually a new buffer that is 
    setup so that it will be associated with a file.

That term could be unclear too, for people who don't know Emacs.  It
is grammatically ambiguous.

Re: File menu changes (suggestions)

[Lennart Borgman]

Richard M. Stallman wrote:

>    Maybe instead "New File Buffer"? It is actually a new buffer that is 
>    setup so that it will be associated with a file.
>
>That term could be unclear too, for people who don't know Emacs.  It
>is grammatically ambiguous.
>  
>
I would not expect them to believe that every new file will be named 
"Buffer" ... ;-)

RE: File menu changes (suggestions)

[Drew Adams]

For a new name for "New File", recent discussion has included candidates
Visit New File and New File Buffer.

As I said in my original post, which started this, the problem here is
"New". The best name for this Emacs operation is, as in the past, "Open". I
gave reasons previously.

The problem then is distinguishing this from opening an existing file
*only*. For that, I suggested that "Open File" would be sufficient, since
"file" implies an existing file - you cannot open a new file; you can only
create a new file.

If people don't think that "Open File" sufficiently makes this clear, then
let's call it "Open Existing File" to remove all doubt. The two menu items
would then be:

 - "Open Existing File" = create/select a buffer for an
                          existing file.

 - "Open" = new or existing: "Open Existing File" or
            create a buffer for a new file.

However, as I mentioned, to be consistent, "Open Directory" and "Insert
File" should then also be renamed "Open Existing Directory" and "Insert
Existing File".

I personally think that the following sufficiently suggest existing objects:
"Open File", "Open Directory", and "Insert File". But if people prefer "Open
Existing File" to "Open File", then we have the choice of opting for
consistency, using "Existing" for the others also, or inconsistency, using
it only for "Open Existing File".

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 26 Jun 2005 16:13:02 -0700
> 
> For a new name for "New File", recent discussion has included candidates
> Visit New File and New File Buffer.
> 
> As I said in my original post, which started this, the problem here is
> "New". The best name for this Emacs operation is, as in the past, "Open". I
> gave reasons previously.

What I say below will probably be ignored, but I feel I must say it
anyway.

The current discussion and the suggested changes is nothing more than
a regress: we are slowly going back to the less compatible names and
structure we had before Emacs 21.1 hit the streets.

I think we should leave the menus alone.  It took a lot of work to
come to what we have now, the result exists for quite some time, and
it didn't make users unhappy.  As they say, the enemy of "good" is
"better".

And on top of that, now is not the time.  Let's leave any changes in
the menus for Emacs 23, which will have changes anyway, due to
Unicode.

Re: File menu changes (suggestions)

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Does not "Visit New File" also imply that a new file is made?
>
> It does not have that implication for me.  The word "visit" takes
> away the implication that it _creates_ the new file.
>
> Maybe some other word is better than "visit", but I can't think of one
> now.

New Unsaved File ?

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

Re: File menu changes (suggestions)

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> New Unsaved File ?

I suspect many users would simply strangle themselves rather than try to
figure out what that means...

-miles
-- 
Would you like fries with that?

Re: File menu changes (suggestions)

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
>> New Unsaved File ?
>
> I suspect many users would simply strangle themselves rather than
> try to figure out what that means...

That was pretty much my first thought, minus the flowery language.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Richard M. Stallman]

    New Unsaved File ?

This operation has two differences from the usual "New" command:
   1. It doesn't write the file yet.
   2. You do specify the name now.
"Unsaved" expresses #1, but I think that #2 is what users
will find the most visibly surprising.

That leads me to think that "Open New File" or "Open Nonexistent File"
might be the best approach.  This is a lot closer to the usual "Open"
command than to the typical "New" command.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Sun, 26 Jun 2005 00:46:31 -0400
> Cc: emacs-devel@gnu.org
> 
>     1. Unsplit Windows is a very poor name. It doesn't give you a hint of what
>     it does; in particular, it doesn't suggest that the current window is the
>     only one that will remain displayed.
> 
> I agree this name is sort of confusing.  I do not see any obvious
> right name, but I came up with Absorb Other Windows, which I think is
> pretty clear.  I have been trying to think of other verbs, but I can't
> find one that is entirely right.  "Devour"?  "Ingest"?  "Conquer"?

FWIW, I see nothing wrong with "Unsplit".  At least one other GUI
program uses "Remove split", which is very similar; if that is better,
let's use it.  I think names like "Absorb", "Devour", etc. will tell
nothing to users.

Re: File menu changes (suggestions)

[Lennart Borgman]

Eli Zaretskii wrote:

>>From: "Richard M. Stallman" <rms@gnu.org>
>>Date: Sun, 26 Jun 2005 00:46:31 -0400
>>Cc: emacs-devel@gnu.org
>>
>>    1. Unsplit Windows is a very poor name. It doesn't give you a hint of what
>>    it does; in particular, it doesn't suggest that the current window is the
>>    only one that will remain displayed.
>>
>>I agree this name is sort of confusing.  I do not see any obvious
>>right name, but I came up with Absorb Other Windows, which I think is
>>pretty clear.  I have been trying to think of other verbs, but I can't
>>find one that is entirely right.  "Devour"?  "Ingest"?  "Conquer"?
>>    
>>
>
>FWIW, I see nothing wrong with "Unsplit".  At least one other GUI
>program uses "Remove split", which is very similar; if that is better,
>let's use it.  I think names like "Absorb", "Devour", etc. will tell
>nothing to users.
>
How about "Only One Window"?

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Date: Sun, 26 Jun 2005 20:00:29 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: rms@gnu.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> 
> How about "Only One Window"?

Fine with me.

RE: File menu changes (suggestions)

[Drew Adams]

    > How about "Only One Window"?

    Fine with me.

"One Window" (my original suggestion) says just as much.

My other original suggestion, "Delete Other Windows" is clearest: the
command just deletes the other windows.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Sun, 26 Jun 2005 11:20:51 -0700, you wrote:

>    > How about "Only One Window"?
>
>    Fine with me.
>
>"One Window" (my original suggestion) says just as much.
>
>My other original suggestion, "Delete Other Windows" is clearest: the
>command just deletes the other windows.

Maximize?

/john

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

Lennart Borgman wrote:

>John S. Yates, Jr. wrote:
>
>>Maximize?
>
>It is a quite funny remark, but I do not believe anyone will understand 
>"Only One Window" that way... ;-)

But I was not trying to be funny.

"Maximize" was a sincere suggestion.  That is because if the
goal is to analogize Emacs' behavior to that of applications
familiar to new users then the widely used Multiple Document
Interface application style must be taken into account:

  http://en.wikipedia.org/wiki/Multiple_document_interface

Except for the fact that MDI document windows are not tiled
they are very akin to Emacs windows.  An MDI document window
invariably has iconize, close and maximize/restore icons on
its title bar.  Clicking an MDI document's maximize icon has
an effect identical to delete-other-windows:

 - all other documents become invisible (ie their "windows"
   get deleted)
 - the clicked document grows to occupy the entire workspace
   of the MDI application (essentially the containing Emacs
   frame)

/john

Re: File menu changes (suggestions)

[David Kastrup]

"John S. Yates, Jr." <john@yates-sheets.org> writes:

> Lennart Borgman wrote:
>
>>John S. Yates, Jr. wrote:
>>
>>>Maximize?
>>
>>It is a quite funny remark, but I do not believe anyone will
>>understand "Only One Window" that way... ;-)
>
> But I was not trying to be funny.

How about "World domination"?  That should be pretty obvious to every
player of "Risk".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Robert J. Chassell]

"John S. Yates, Jr." <john@yates-sheets.org> wrote

   Except for the fact that MDI document windows are not tiled
   they are very akin to Emacs windows.  

I don't know about MDI documents.

There is a huge difference between deleting other windows within a
frame and maximizing a frame so it covers all the other frames that
previously could be seen.

In my non-Emacs programs, the word `maximize' means `occupy an entire
desktop (or `workspace'; the language varies)', not `occupy one frame
in a manner that also provides for a mode line and echo area'

Are the displays in which MDI documents are shown like Emacs windows
which exist in a frame?  Can you have two or three of them in the same
frame?

    - the clicked document grows to occupy the entire workspace
      of the MDI application (essentially the containing Emacs
      frame)

When you say this, do you mean the buffer grows to occupy an entire
frame?  You use the word `essentially' which suggests that the `entire
workspace' is something other than a frame whose size you do not
change.

Or do you mean the buffer (and frame dressing) grows to occupy an
entire desktop and covers over all the other frames visible on that
desktop?  (This is what `maximize' means for my frames.)

I have just changed the work area for writing this message to occupy
one frame and also provide for mode line and echo area.  Eleven other
frames are visible on this desktop, and this user and session are
running seven other desktops with thirty-seven other frames visible on
them.  (I had not realized how many frames I was running.  Of these
frames, only five are different instances of Emacs.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Mon, 27 Jun 2005 17:47:53 (UTC), Robert J. Chassell wrote:

>I don't know about MDI documents.

In anticipation of which I included the link to the Wikipedia
article.  It includes an example of a Java MDI application.
Here again is the link to the article:

  http://en.wikipedia.org/wiki/Multiple_document_interface

And here is the included image showing multiple child windows
within the parent application's window (Emacs frame):

  http://en.wikipedia.org/wiki/Image:MenuWindow.png

>There is a huge difference between deleting other windows within a
>frame and maximizing a frame so it covers all the other frames that
>previously could be seen.
>
>In my non-Emacs programs, the word `maximize' means `occupy an entire
>desktop (or `workspace'; the language varies)', not `occupy one frame
>in a manner that also provides for a mode line and echo area'

The former understand need not preclude the latter.  Maximize is
and operation on a window relative to its siblings.  When a child
window and its siblings all reside within a single parent window
the notion of maximization is easily defined.

>Are the displays in which MDI documents are shown like Emacs windows
>which exist in a frame?  Can you have two or three of them in the same
>frame?

Yes, that is the essence of MDI.

>
>    - the clicked document grows to occupy the entire workspace
>      of the MDI application (essentially the containing Emacs
>      frame)
>
>When you say this, do you mean the buffer grows to occupy an entire
>frame?  You use the word `essentially' which suggests that the `entire
>workspace' is something other than a frame whose size you do not
>change.

I think your question is incorrectly formed even if I interpret it
according to Emacs vocabulary.  It is not the buffer that grows but
rather the window displaying the buffer.  Most other applications
do not make this distinction (though the CodeWright editor does).

But the answer to what I believe to be the intent of your question
is that the window (an Emacs window) displaying the child document
(an Emacs buffer) grows to occupy the entire parent application's
window (Emacs frame), hiding all other document windows within the
application.  This is independent of whether the parent application
window (Emacs frame) is maximized or not.

>Or do you mean the buffer (and frame dressing) grows to occupy an
>entire desktop and covers over all the other frames visible on that
>desktop?  (This is what `maximize' means for my frames.)

No. See discussion above.  A MDI application is essentially a mini-
window manager, in much the same way that Emacs is.  The only real
difference is that Emacs know only how to tile.  Your typical MDI
applications understands operations on individual child windows
(minimize, restore, maximize and close) as well as operations on
the full set of child windows (tiling horizontally and vertically,
cascading, etc).

A MDI child window exhibits functionality relative to its parent
window that is entirely analogous to that exhibited by a top-level
application window relative to the desktop.  Because the analogy is
so strong if the MDI application and the desktop window manager draw
from the same collection of decorations then the widgets used end up
being visually identical in both contexts.

This was not the case in the Wikipedia image cited above.  But I just
did a quick Google search and found the following page at the bottom
of which is an obvious example:

  http://www.csharphelp.com/archives/archive227.html

/john

Re: File menu changes (suggestions)

[David Kastrup]

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

>     > How about "Only One Window"?
>
>     Fine with me.
>
> "One Window" (my original suggestion) says just as much.

No.  But "Single Window" would, more or less.  "One Window" could also
mean "One More Window".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: File menu changes (suggestions)

[Drew Adams]

    >     > How about "Only One Window"?
    > "One Window" (my original suggestion) says just as much.

    No.  But "Single Window" would, more or less.  "One Window" could
    also mean "One More Window".

OK by me. The command takes you from multiple windows to a single window -
clear enough.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 27 Jun 2005 15:24:48 +0200
> Cc: emacs-devel@gnu.org
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> >     > How about "Only One Window"?
> >
> >     Fine with me.
> >
> > "One Window" (my original suggestion) says just as much.
> 
> No.  But "Single Window" would, more or less.  "One Window" could also
> mean "One More Window".

FYI, "One Window" is what we had before Emacs 21.1.  Like I said: we
are regressing.

RE: File menu changes (suggestions)

[Drew Adams]

    FYI, "One Window" is what we had before Emacs 21.1.  Like I said: we
    are regressing.

Not all movement from one version to the next is progress. It happens
sometimes that previous behavior was better than current behavior. Life is
like that, sometimes.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 27 Jun 2005 11:13:48 -0700
> 
>     FYI, "One Window" is what we had before Emacs 21.1.  Like I said: we
>     are regressing.
> 
> Not all movement from one version to the next is progress. It happens
> sometimes that previous behavior was better than current behavior. Life is
> like that, sometimes.

With all due respect, I don't know where you get the right to talk
about the 21.1 menu design with such an arrogance.  That design was
based on a lot of research.  Menus of quite a few other GUI programs
were studied, as well as various GUI design guidelines for popular
toolkits.  The initial version based on that research was then
scrutinized in prolonged discussions, and what went into v21.1 was the
best solution we could find to the various issues and problems raised
in those discussions.

By contrast, your suggestions are based on opinions of a single
individual.

RE: File menu changes (suggestions)

[Drew Adams]

    >     FYI, "One Window" is what we had before Emacs 21.1.  Like
    >     I said: we are regressing.
    >
    > Not all movement from one version to the next is progress.
    > It happens sometimes that previous behavior was better than
    > current behavior. Life is like that, sometimes.

    With all due respect, I don't know where you get the right to
    talk about the 21.1 menu design with such an arrogance.

With all due respect, don't get nasty. I did not mention 21.1 - or any
particular Emacs version. You quoted my message in its entirety, and it says
nothing about specific versions. And I do have the right to talk about any
design - anyone does. And I do not feel arrogant - sorry if you take my
suggestions that way.

I simply pointed out the general rule that not all evolution is in the
direction of progress. Or at least that's what I meant to say. Sorry if that
wasn't clear.

You, on the other hand, labeled "regression" any move to return to a
previous state. "regression: 1) Reversion; retrogression. 2) Relapse to a
less perfect or developed state." You assume perhaps that all past changes
have improved things; I don't share that point of view - in general or in
the particular case of Emacs.

My point was that, instead of considering all movement to a previous state
to be regression, we should consider potential changes on a case-by-case
basis, judging them on their own merits - regardless of whether they might
have already been visited. Even if most past Emacs changes have meant
progress (which is what I think), we should still be able to question any of
them and suggest improvements.

My general remark about evolution was a response to your blanket judgement
that we are regressing by even considering renamings like "New File" ->
"Open". Such a change might represent a return to the past, but that would
not, by itself, constitute regression. By speaking of "regression", you put
a negative value on such a movement, in a wholesale way.

If you take the (arrogant?) point of view that we have already achieved the
"best of all possible worlds" because lots of discussion, research,
experimentation, and expertise went into the existing design, then yes, it's
futile not only to suggest repeating a past state but also to suggest any
other changes.

I (arrogantly?) have a less deferential attitude toward the status quo, but
that doesn't mean that I don't value and respect it, its history, and the
people who constructed it - I do.

    By contrast, your suggestions are based on opinions of a
    single individual.

How do you know what I base my suggestions on? On the other hand, yes, my
suggestions reflect my opinions, of course. It seems to me that you are the
one who is arrogantly arguing from authority. I'm only speaking my mind,
and, yes, I only speak for myself. You don't have to agree, but please try
to be polite.

ad hominem ad nauseum.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 27 Jun 2005 15:33:47 -0700
> 
> With all due respect, don't get nasty.

If you get arrogant, I get nasty.

> I simply pointed out the general rule that not all evolution is in the
> direction of progress.

We are not talking philosophy in this list.  We are talking specific
practical issues.

> If you take the (arrogant?) point of view that we have already achieved the
> "best of all possible worlds" because lots of discussion, research,
> experimentation, and expertise went into the existing design, then yes, it's
> futile not only to suggest repeating a past state but also to suggest any
> other changes.

Not everything in Emacs is based on such an effort.  The current menu
structure is.  I never said that it's the best of all possible
arrangements, but the fact that we changed it from A to B does mean
that the merits and demerits of A vs B were already considered and
after a long and constructive discussion we concluded that B is
better.  So going back to A without at least pointing out where the
previous considerations were incorrect is a regression (a negative
label) that wastes our valuable time and energy, and on top of that
threatens to set us back 5 or 6 years.

> I (arrogantly?) have a less deferential attitude toward the status quo, but
> that doesn't mean that I don't value and respect it, its history, and the
> people who constructed it - I do.

Such respect does not mean anything if it does not have specific and
clear expression.  Arguing that we should go back to what was already
considered and rejected, without at least retracing past discussions
and pointing out where they were wrong, is anything but an expression
of any respect for past deliberations, time, and energy invested back
then, to say nothing of the effort we invest now.

> please try to be polite.

Yeah, right.

Re: File menu changes (suggestions)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Drew Adams" <drew.adams@oracle.com>
>> Date: Mon, 27 Jun 2005 15:33:47 -0700
>> 
>> With all due respect, don't get nasty.
>
> If you get arrogant, I get nasty.

We don't need an arms' race in escalation.

>> If you take the (arrogant?) point of view that we have already
>> achieved the "best of all possible worlds" because lots of
>> discussion, research, experimentation, and expertise went into the
>> existing design, then yes, it's futile not only to suggest
>> repeating a past state but also to suggest any other changes.
>
> Not everything in Emacs is based on such an effort.  The current
> menu structure is.  I never said that it's the best of all possible
> arrangements, but the fact that we changed it from A to B does mean
> that the merits and demerits of A vs B were already considered and
> after a long and constructive discussion we concluded that B is
> better.  So going back to A without at least pointing out where the
> previous considerations were incorrect is a regression (a negative
> label) that wastes our valuable time and energy, and on top of that
> threatens to set us back 5 or 6 years.

Well, Drew is right that not every change is progress, but unless a
change has produced new insights or new information is volunteered, I
agree that the difference is not likely to merit wasting considerable
time discussing it.

We have other areas that are clearly quite more in need of further
improvement.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> I agree this name is sort of confusing.  I do not see any obvious
>> right name, but I came up with Absorb Other Windows, which I think is
>> pretty clear.  I have been trying to think of other verbs, but I can't
>> find one that is entirely right.  "Devour"?  "Ingest"?  "Conquer"?
>
> FWIW, I see nothing wrong with "Unsplit".  At least one other GUI
> program uses "Remove split", which is very similar; if that is better,
> let's use it.  I think names like "Absorb", "Devour", etc. will tell
> nothing to users.

I agree. Unsplit Windows at least conveys the notion that it does the
opposite of Split Window. Coming up with a new verb would remove that
association.

Re: File menu changes (suggestions)

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> I agree. Unsplit Windows at least conveys the notion that it does the
> opposite of Split Window.

But it doesn't do the opposite of split-window...

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, drew.adams@oracle.com,
>    emacs-devel@gnu.org
> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: Mon, 27 Jun 2005 11:06:54 +0900
> 
> Jason Rumney <jasonr@gnu.org> writes:
> > I agree. Unsplit Windows at least conveys the notion that it does the
> > opposite of Split Window.
> 
> But it doesn't do the opposite of split-window...

If you unsplit immediately after splitting, it does precisely that.

Re: File menu changes (suggestions)

[Miles Bader]

On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote:
> > > I agree. Unsplit Windows at least conveys the notion that it does the
> > > opposite of Split Window.
> >
> > But it doesn't do the opposite of split-window...
> 
> If you unsplit immediately after splitting, it does precisely that.

Yeah, but the menu label doesn't change depending on the number of
windows displayed, so the label used has to be accurate for all cases
(and > 2 windows is hardly a rare occurance!!).

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[David Kastrup]

Miles Bader <snogglethorpe@gmail.com> writes:

> On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote:
>> > > I agree. Unsplit Windows at least conveys the notion that it does the
>> > > opposite of Split Window.
>> >
>> > But it doesn't do the opposite of split-window...
>> 
>> If you unsplit immediately after splitting, it does precisely that.
>
> Yeah,

No.  I just tried it.  I had a two-window frame, used C-x 2 (got three
windows) and then C-x 1.  After that, I had only a single frame.

So it wasn't the opposite, but rather more that happened.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Cc: miles@gnu.org,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 27 Jun 2005 15:26:26 +0200
> 
> Miles Bader <snogglethorpe@gmail.com> writes:
> 
> > On 6/27/05, Eli Zaretskii <eliz@gnu.org> wrote:
> >> > > I agree. Unsplit Windows at least conveys the notion that it does the
> >> > > opposite of Split Window.
> >> >
> >> > But it doesn't do the opposite of split-window...
> >> 
> >> If you unsplit immediately after splitting, it does precisely that.
> >
> > Yeah,
> 
> No.  I just tried it.  I had a two-window frame, used C-x 2 (got three
> windows) and then C-x 1.  After that, I had only a single frame.

Look, ma: another pedant...

Re: File menu changes (suggestions)

[Jason Rumney]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>> I agree. Unsplit Windows at least conveys the notion that it does the
>> opposite of Split Window.
>
> But it doesn't do the opposite of split-window...

That's a rather pedantic definition of opposite, and dwelling on such
pedantry when choosing menu names results in confusion for less
experienced users, because you're removing helpful associations
between menu entries in return for absolute correctness.

Re: File menu changes (suggestions)

[Miles Bader]

On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote:
> > But it doesn't do the opposite of split-window...
> 
> That's a rather pedantic definition of opposite

No it's not (are you serious?).  "Unsplit window" vaguely implies that
it simply undoes a previous split-window, leaving other windows alone
-- but it doesn't do that, it removes all other windows.  The lack of
symmetry is not subtle.

> and dwelling on such
> pedantry when choosing menu names results in confusion for less
> experienced users, because you're removing helpful associations
> between menu entries in return for absolute correctness.

... and dwelling on "symmetry" when it conflicts with clarity is also
counter-productive.  In many cases there is no perfect name that will
help all people form all the right associations; all we can do is try
to consider all the factors, and come up with something that results
in a minimum of confusion.

-miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Date: Mon, 27 Jun 2005 18:41:31 +0900
> From: Miles Bader <snogglethorpe@gmail.com>
> Cc: Miles Bader <miles@gnu.org>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, 
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote:
> > > But it doesn't do the opposite of split-window...
> > 
> > That's a rather pedantic definition of opposite
> 
> No it's not (are you serious?).  "Unsplit window" vaguely implies that
> it simply undoes a previous split-window

To me, it means that a window (``frame'' in our parlance) that was
previously split into two or more parts now becomes "unsplit", i.e. we
are left with a frame that has only one window.

> > and dwelling on such
> > pedantry when choosing menu names results in confusion for less
> > experienced users, because you're removing helpful associations
> > between menu entries in return for absolute correctness.
> 
> ... and dwelling on "symmetry" when it conflicts with clarity is also
> counter-productive.  In many cases there is no perfect name that will
> help all people form all the right associations; all we can do is try
> to consider all the factors, and come up with something that results
> in a minimum of confusion.

I think "Unsplit" is the most associative name of all those suggested
in this discussion.  Perhaps we should take a user poll to see whose
opinion is closer to them.  Personally, I fully agree with Jason.

Re: File menu changes (suggestions)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 27 Jun 2005 18:41:31 +0900
>> From: Miles Bader <snogglethorpe@gmail.com>
>> Cc: Miles Bader <miles@gnu.org>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, 
>> 	drew.adams@oracle.com, emacs-devel@gnu.org
>> 
>> On 6/27/05, Jason Rumney <jasonr@gnu.org> wrote:
>> > > But it doesn't do the opposite of split-window...
>> > 
>> > That's a rather pedantic definition of opposite
>> 
>> No it's not (are you serious?).  "Unsplit window" vaguely implies that
>> it simply undoes a previous split-window
>
> To me, it means that a window (``frame'' in our parlance) that was
> previously split into two or more parts now becomes "unsplit", i.e. we
> are left with a frame that has only one window.

If you prefer that verb, I'd rather say something like "Unsplit all"
or something like that to make obvious that it is not symmetric with
"Split".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Lennart Borgman]

David Kastrup wrote:

>If you prefer that verb, I'd rather say something like "Unsplit all"
>or something like that to make obvious that it is not symmetric with
>"Split".
>
After this incredible discussion of this rather tiny (but important) 
issue I actually had to look at the menu... - I guess most of us mostly 
use the keyboard, at least for splitting?;-)

There is a separate section for splitting + frames. It kind of makes 
sense but it establish an environment for the name so to say:

    --------------------
    Split Window
    Remove Window Splitting
    New Frame
    Delete Frame
    --------------------

"Remove Window Splitting" is my candidate now.  That groups the two 
window splitting entries together. Frame is another group. (And I do not 
have to see that difficult word "unsplit".)

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Cc: miles@gnu.org,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 27 Jun 2005 22:05:33 +0200
> 
> > To me, it means that a window (``frame'' in our parlance) that was
> > previously split into two or more parts now becomes "unsplit", i.e. we
> > are left with a frame that has only one window.
> 
> If you prefer that verb, I'd rather say something like "Unsplit all"
> or something like that to make obvious that it is not symmetric with
> "Split".

As Jason and myself tried to explained, it _is_ symmetric, just
perhaps not in the sense that you think.  It makes something that was
split be unsplit.  And that something, which we call ``frame'' is
called ``window'' elsewhere.  So, "Split Window" and "Unsplit Window"
is the natural choice.  (We actually say "Unsplit Windows" instead, to
avoid calling the frame ``a window''.  But to me, that subtlety is
secondary in this case; I'm quite sure many, perhaps most, users of
the menu don't even notice it.)

Re: File menu changes (suggestions)

[Richard M. Stallman]

    FWIW, I see nothing wrong with "Unsplit".  At least one other GUI
    program uses "Remove split", which is very similar; if that is better,
    let's use it.

It isn't better a priori, but if it is widely used and lots of people
would have seen it, that would make it better.  What other programs
use "Remove split"?

    How about "Only One Window"?

I think that is better than just "One Window".  The word "Only"
carries the implication of getting rid of the rest.  Or maybe "Just
This Window", which indicates that the selected window is the
one that will remain.

What do people think of "Just This Window"?

    >"One Window" (my original suggestion) says just as much.
    >
    >My other original suggestion, "Delete Other Windows" is clearest: the
    >command just deletes the other windows.

    Maximize?

"Maximize" is associated with frames, so people would get the wrong
idea.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Mon, 27 Jun 2005 01:38:12 -0400
> 
>     FWIW, I see nothing wrong with "Unsplit".  At least one other GUI
>     program uses "Remove split", which is very similar; if that is better,
>     let's use it.
> 
> It isn't better a priori, but if it is widely used and lots of people
> would have seen it, that would make it better.  What other programs
> use "Remove split"?

I saw it in Word.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Mon, 27 Jun 2005 09:24:33 +0200, you wrote:

>> It isn't better a priori, but if it is widely used and lots of people
>> would have seen it, that would make it better.  What other programs
>> use "Remove split"?
>
>I saw it in Word.

Yes, though I wonder how many Word users are aware of its existence
or actually use it.  OTOH Excel users use it all the time.

/john

Re: File menu changes (suggestions)

[Lennart Borgman]

John S. Yates, Jr. wrote:

>On Mon, 27 Jun 2005 09:24:33 +0200, you wrote:
>
>  
>
>>>It isn't better a priori, but if it is widely used and lots of people
>>>would have seen it, that would make it better.  What other programs
>>>use "Remove split"?
>>>      
>>>
>>I saw it in Word.
>>    
>>
>
>Yes, though I wonder how many Word users are aware of its existence
>or actually use it.  OTOH Excel users use it all the time.
>  
>
But at least in Word it is in another kind of context I believe:

- A window is what we call a frame. "Split Window" would be "Split Frame".
- You can only split in two parts.
- The two parts contains the same file.

In this context "Remove Split" is meaningful and does the opposite of 
"Split Window".

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Date: Mon, 27 Jun 2005 15:26:52 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  drew.adams@oracle.com, 
>  emacs-devel@gnu.org
> 
> - A window is what we call a frame. "Split Window" would be "Split Frame".
> - You can only split in two parts.
> - The two parts contains the same file.
> 
> In this context "Remove Split" is meaningful and does the opposite of 
> "Split Window".

Except that "Remove Split" doesn't say which split it removes, and
thus leaves even the meaning of ``remove'' ambiguous.

Re: File menu changes (suggestions)

[Lennart Borgman]

Eli Zaretskii wrote:

>No, I understood you perfectly.  I still submit that the exact meaning
>of "split" in "remove split" is more ambiguous than "remove split
>between windows" or simply "unsplit window".
>  
>
And I just suggested "Remove Window Splitting" - but now I realize it is 
ambigous...

Hm. "Remove All Splitting", hm "Unsplit Windows" - not the pluralis. Hm. 
>From my own arguing on the list I actually feel that "Unsplit Windows" 
might be better. Less ambigous. Shorter. Contains both "split" and 
"window" (good for grouping the items logically). "Unsplit Frame 
Windows" - less ambigous still. ("Unsplit All Windows" is a bit more 
ambigous.)

So I would go for "Unsplit Frame Windows". It misses that "One" but it 
is better for the text of logical grouping in the menus. The "One" will 
be implied I guess.

But "unsplit" tastes bad. Maybe I just need education in english?

Re: File menu changes (suggestions)

[Richard M. Stallman]

    Except that "Remove Split" doesn't say which split it removes, and
    thus leaves even the meaning of ``remove'' ambiguous.

I see no ambiguity.  It removes the split which exists.
What other split could it remove?

Re: File menu changes (suggestions)

[Lennart Borgman]

Richard M. Stallman wrote:

>    Except that "Remove Split" doesn't say which split it removes, and
>    thus leaves even the meaning of ``remove'' ambiguous.
>
>I see no ambiguity.  It removes the split which exists.
>What other split could it remove?
>  
>
English is not my mohter tongue but it sounds to me like "remove one 
split" (which?).  Maybe "Remove Splitting", "Remove Splits"?

Re: File menu changes (suggestions)

[Richard M. Stallman]

    - A window is what we call a frame. "Split Window" would be "Split Frame".
    - You can only split in two parts.
    - The two parts contains the same file.

    In this context "Remove Split" is meaningful and does the opposite of 
    "Split Window".

Our "Split Window" operation does split into two parts that show
the same file (more generally, same buffer).  So "Remove Split"
fits well.  Both of them are more general than that, but I think
users will understand that generalization.

"Single Window" also seems like it might be a good name.

So it is between those two.

Re: File menu changes (suggestions)

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     - A window is what we call a frame. "Split Window" would be "Split Frame".
>     - You can only split in two parts.
>     - The two parts contains the same file.
>
>     In this context "Remove Split" is meaningful and does the opposite of 
>     "Split Window".
>
> Our "Split Window" operation does split into two parts that show
> the same file (more generally, same buffer).  So "Remove Split"
> fits well.

"Remove Splits" would probably be more fitting, as the frame is
completely unsplit afterwards and all splitting operations are undone.

> "Single Window" also seems like it might be a good name.
>
> So it is between those two.

One problem I see with that is that beginners, one of the main
audiences for menus, might feel less secure with Emacs terminology and
the difference between frames and windows.

Since splitting can't really apply to frames (which are separate items
on the desktop), "Remove Splits" would probably feel less ambiguous to
a beginner.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Stefan Monnier]

> People pointed out that "New File" might be confusing
> since it does not in fact make a new file.  I think the name
> "Visit New File" will help show that this isn't the same as the usual
> "New File" operation.

Rather than change menu entries's names to less "standard" ones, we should
change their behavior to better match what users expect.

E.g. find-file might require confirmation before opening
a non-existent file.  I'll love such a new feature, seeing how often I do
"C-x C-f emacs/src/rege TAB RET" only to find myself in "regexp." rather
than in the "regexp.c" that I intended to open.

As for the "New File" entry, there are several options.  One is to just
create a new buffer called "New Document" and not attached to any file.
This mimicks many "CUA-style" systems.  It sucks because it does give us
a chance to choose a good minor mode, and because we won't be able to
autosave the file [this latter point could be fixed, of course].

Another option is to prompt for a file name and require confirmation if the
file already exists.  It's a slightly different behavior than those other
"CUA-style" systems, but unsuspecting users should hopefully not find
it confusing, which is all we really care about.

I guess I'm just repeating what Miles and Eli have said.


        Stefan

Re: File menu changes (suggestions)

[Lennart Borgman]

Stefan Monnier wrote:

>Rather than change menu entries's names to less "standard" ones, we should
>change their behavior to better match what users expect.
>
>E.g. find-file might require confirmation before opening
>a non-existent file.  I'll love such a new feature, seeing how often I do
>"C-x C-f emacs/src/rege TAB RET" only to find myself in "regexp." rather
>than in the "regexp.c" that I intended to open.
>  
>
Agree.

>Another option is to prompt for a file name and require confirmation if the
>file already exists.  It's a slightly different behavior than those other
>"CUA-style" systems, but unsuspecting users should hopefully not find
>it confusing, which is all we really care about.
>
>I guess I'm just repeating what Miles and Eli have said.
>  
>
I too repeat and agree.

Re: File menu changes (suggestions)

[John S. Yates, Jr.]

On Tue, 28 Jun 2005 01:28:53 -0400, you wrote:

>> People pointed out that "New File" might be confusing
>> since it does not in fact make a new file.  I think the name
>> "Visit New File" will help show that this isn't the same as the usual
>> "New File" operation.
>
>Rather than change menu entries's names to less "standard" ones, we should
>change their behavior to better match what users expect.

Exactly the attitude I advocate.

>E.g. find-file might require confirmation before opening
>a non-existent file.  I'll love such a new feature, seeing how often I do
>"C-x C-f emacs/src/rege TAB RET" only to find myself in "regexp." rather
>than in the "regexp.c" that I intended to open.

I love it.

>As for the "New File" entry, there are several options.  One is to just
>create a new buffer called "New Document" and not attached to any file.
>This mimicks many "CUA-style" systems.  It sucks because it does give us
>a chance to choose a good minor mode, and because we won't be able to
>autosave the file [this latter point could be fixed, of course].

(Miss "not" near end of 3rd line?)

>Another option is to prompt for a file name and require confirmation if the
>file already exists.  It's a slightly different behavior than those other
>"CUA-style" systems, but unsuspecting users should hopefully not find
>it confusing, which is all we really care about.

Yes! A very nice solution.  It alters the timing of when the user
supplies the ultimate file-name but preserves essential Emacs models.

In fact I suspect that one would be very hard put to find a user of a
CUA-like system who would argue that giving new documents an initial,
application-generated name and path, only to later have to remember
to use SaveAs.. instead of Save is a virtue to be preserved.  Thus I
believe that Stefan's suggestion would be quite palatable to the CUA
community.

>I guess I'm just repeating what Miles and Eli have said.

No.  You have made a concrete suggestion that has not been aired
before.  I heartily endorse both the suggestion and your attitude
of how to respond to the not-yet-Emacs-users community.

/john

Re: File menu changes (suggestions)

[Richard M. Stallman]

    >Another option is to prompt for a file name and require confirmation if the
    >file already exists.  It's a slightly different behavior than those other
    >"CUA-style" systems, but unsuspecting users should hopefully not find
    >it confusing, which is all we really care about.

I think that is a good idea.  It follows the design of Emacs,
but it warns users who are confused.

Re: File menu changes (suggestions)

[Miles Bader]

2005/7/1, Richard M. Stallman <rms@gnu.org>:
>     >Another option is to prompt for a file name and require confirmation if the
>     >file already exists.  It's a slightly different behavior than those other
>     >"CUA-style" systems, but unsuspecting users should hopefully not find
>     >it confusing, which is all we really care about.
> 
> I think that is a good idea.  It follows the design of Emacs,
> but it warns users who are confused.

(defun new-file (filename)
  (interactive)
  (let ((find-file-confirm-existing t))
    (find-file filename)))

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Richard M. Stallman]

    (defun new-file (filename)
      (interactive)
      (let ((find-file-confirm-existing t))
	(find-file filename)))

That is a fine way, but the variable find-file-confirm-existing
doesn't seem to exist yet.

Would you like to implement this?

Re: File menu changes (suggestions)

[Miles Bader]

2005/7/2, Richard M. Stallman <rms@gnu.org>:
>     (defun new-file (filename)
>       (interactive)
>       (let ((find-file-confirm-existing t))
>         (find-file filename)))
>
> Would you like to implement this?

Er, sure. 

-Miles
-- 
Do not taunt Happy Fun Ball.

RE: File menu changes (suggestions)

[Drew Adams]

    find-file might require confirmation before opening
    a non-existent file.
    
    "New File" entry ... prompt for a file name and require 
    confirmation if the file already exists.

Good solutions, both. Thanks.

Re: File menu changes (suggestions)

[Lennart Borgman]

Drew Adams wrote:

>    find-file might require confirmation before opening
>    a non-existent file.
>    
>    "New File" entry ... prompt for a file name and require 
>    confirmation if the file already exists.
>
>Good solutions, both. Thanks.
>  
>
I agree too.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 28 Jun 2005 01:28:53 -0400
> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> Rather than change menu entries's names to less "standard" ones, we should
> change their behavior to better match what users expect.

Yes, I agree.  File->New seems like a case in point.

> As for the "New File" entry, there are several options.  One is to just
> create a new buffer called "New Document" and not attached to any file.
> This mimicks many "CUA-style" systems.  It sucks because it does give us
> a chance to choose a good minor mode, and because we won't be able to
> autosave the file [this latter point could be fixed, of course].
> 
> Another option is to prompt for a file name and require confirmation if the
> file already exists.  It's a slightly different behavior than those other
> "CUA-style" systems, but unsuspecting users should hopefully not find
> it confusing, which is all we really care about.

Yet another variety would be to create a buffer which does have a
file, call it "Unnamed" or some such (i.e., in the default directory),
and if such a file already exists, modify it by attaching something
like a number.

> I guess I'm just repeating what Miles and Eli have said.

Ah, so that's why I agree with you ;-)

Re: File menu changes (suggestions)

[Miles Bader]

On 6/29/05, Eli Zaretskii <eliz@gnu.org> wrote:
> Yet another variety would be to create a buffer which does have a
> file, call it "Unnamed" or some such (i.e., in the default directory),
> and if such a file already exists, modify it by attaching something
> like a number.

I think the default emacs behavior (if the buffer doesn't have a name,
ask for one when saving) is far better.   You could create new
_buffer_ names like "unnamed" or whatever, but actually setting the
_file_ name to that seems harmful.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[David Kastrup]

Miles Bader <snogglethorpe@gmail.com> writes:

> On 6/29/05, Eli Zaretskii <eliz@gnu.org> wrote:
>> Yet another variety would be to create a buffer which does have a
>> file, call it "Unnamed" or some such (i.e., in the default
>> directory), and if such a file already exists, modify it by
>> attaching something like a number.
>
> I think the default emacs behavior (if the buffer doesn't have a
> name, ask for one when saving) is far better.  You could create new
> _buffer_ names like "unnamed" or whatever, but actually setting the
> _file_ name to that seems harmful.

How does autosave work with an unnamed buffer?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Miles Bader]

2005/6/29, David Kastrup <dak@gnu.org>:
> How does autosave work with an unnamed buffer?

It tries to concoct an auto-save filename from the buffer name
(remember, buffers always have names, but not always filenames) and a
few likely directories.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Stefan Monnier]

>> Yet another variety would be to create a buffer which does have a
>> file, call it "Unnamed" or some such (i.e., in the default directory),
>> and if such a file already exists, modify it by attaching something
>> like a number.

> I think the default emacs behavior (if the buffer doesn't have a name,
> ask for one when saving) is far better.   You could create new
> _buffer_ names like "unnamed" or whatever, but actually setting the
> _file_ name to that seems harmful.

It all depends on whether other parts of the code would be adjusted or not.
The important issues about the behavior of "new files" (whose file name has
not yet been set):
- make sure C-x C-s prompts for a file name.
- make sure autosave works.
- make sure the auto-save-list includes the new files.
- there might be more.

Of course the other option of prompting for a file name before creating the
new buffer solves all the above problems (along with the others that have to
do with the choice of major mode, ...), which is why I'm in favor of that
one, even if it's a bit less CUA-ish.


        Stefan

Re: File menu changes (suggestions)

[Miles Bader]

On 6/29/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> - make sure C-x C-s prompts for a file name.

This seems to work already if you save a buffer with no associated filename.

> Of course the other option of prompting for a file name before creating the
> new buffer solves all the above problems (along with the others that have to
> do with the choice of major mode, ...), which is why I'm in favor of that
> one, even if it's a bit less CUA-ish.

It's also often very annoying to be forced to pick a filename upfront...

Granted that one can "rename" the file by using save-as before ever
using save, but it's step one has to remember to do (and one I often
forget).

I think the changes you note would actually be very good to have
around regardless of the menu issue actually -- I often want to create
a file which may or may not be temporary, which I want to be
auto-saved, but which I don't know the name of yet.  My current
solution is to visit "/tmp/,blah" or whatever, and then use C-x C-w to
save it when I decide upon a name, but it'd be cool if I could set
things up so that there was some way of identifying which
non-file-associated buffers should be auto-saved.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Eli Zaretskii]

> Date: Wed, 29 Jun 2005 13:45:16 +0900
> From: Miles Bader <snogglethorpe@gmail.com>
> Cc: miles@gnu.org, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On 6/29/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > - make sure C-x C-s prompts for a file name.
> 
> This seems to work already if you save a buffer with no associated filename.

True; but what about if you kill Emacs? IIRC, a buffer that has no
associated file will not cause Emacs to prompt for saving it, right?
That's why I suggested to pick some mundane file name automatically.

Re: File menu changes (suggestions)

[Miles Bader]

2005/6/30, Eli Zaretskii <eliz@gnu.org>:
> > This seems to work already if you save a buffer with no associated filename.
> 
> True; but what about if you kill Emacs? IIRC, a buffer that has no
> associated file will not cause Emacs to prompt for saving it, right?
> That's why I suggested to pick some mundane file name automatically.

I don't think we should be creating random filenames, and I think we
should treat such "new" buffers more like (though not entirely like)
scratch buffers than normal file-visiting buffers.

However, if someone creates a buffer with a "New File" menu item, it
is actually somewhat more likely that they intended to save it.

So I can envision a "New File" menu item that would (1) keep the
buffer-file-name `nil', but (2) turn on auto-save mode, and (3) mark
the buffer specially so that exit-emacs asks about saving it (and if
you answer `y', asks you for a filename).

[Of course scratch buffers created the old-fashioned way should
continue to be not saved by default; that's far too ingrained to
change I think.  Maybe a non-menu user would want to use "M-x
new-file" sometimes though...]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: File menu changes (suggestions)

[Richard M. Stallman]

The Emacs design decision is to guide users to specify the file name
when creating the buffer.  We don't want them to leave it for later.
So we will not change the interface to encourage users to leave the file
name for later.

Re: File menu changes (suggestions)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Yet another variety would be to create a buffer which does have a
>>> file, call it "Unnamed" or some such (i.e., in the default directory),
>>> and if such a file already exists, modify it by attaching something
>>> like a number.
>
>> I think the default emacs behavior (if the buffer doesn't have a name,
>> ask for one when saving) is far better.   You could create new
>> _buffer_ names like "unnamed" or whatever, but actually setting the
>> _file_ name to that seems harmful.
>
> It all depends on whether other parts of the code would be adjusted or not.
> The important issues about the behavior of "new files" (whose file name has
> not yet been set):
> - make sure C-x C-s prompts for a file name.
> - make sure autosave works.
> - make sure the auto-save-list includes the new files.
> - there might be more.

I think the main point is that the mode is set from auto-mode-alist,
and that things like auto-insert work.  Specifying the file name saves
specifying mode and stuff.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: File menu changes (suggestions)

[Richard M. Stallman]

    > Yet another variety would be to create a buffer which does have a
    > file, call it "Unnamed" or some such (i.e., in the default directory),
    > and if such a file already exists, modify it by attaching something
    > like a number.

I am not willing to distort Emacs that far
just to fit the mold of someone else's interface.

Re: File menu changes (suggestions)

[public]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> E.g. find-file might require confirmation before opening
> a non-existent file.  I'll love such a new feature, seeing how often I do
> "C-x C-f emacs/src/rege TAB RET" only to find myself in "regexp." rather
> than in the "regexp.c" that I intended to open.

Here is what I use in Easymacs, which I have modified from
http://www-xray.ast.cam.ac.uk/~gmorris/dotemacs.html -- I just added the
make-directory bit.

  (defadvice find-file (around confirm-new-file activate)
    "If file does not exist, prompt."
    (let ((file (ad-get-arg 0)))
      (when (or (not (interactive-p))
               (find-buffer-visiting file)
               (string-match "\\`/\\[" file) ; old-style TRAMP
               (string-match "\\`/[a-zA-Z0-9@]:" file) ; new-style TRAMP
               (file-directory-p file)
               ;; file-exists-p does not handle wildcards.
               (file-expand-wildcards file)
               ;; A nice trick, but not necessary.
;;;         (string-match "0\n\\'" (shell-command-to-string
;;;                                 (format "ls %s; echo $?" file)))
               (yes-or-no-p
                (format "`%s' does not exist, create new file? " file)))
        
        ;; Is this a good idea? If we open a new file by accident,
        ;; despite the confirmation, we probably don't want the directory.
        (unless (file-directory-p (file-name-directory file))
          (make-directory (file-name-directory file) t))
        ad-do-it)))

  (defadvice switch-to-buffer (around confirm-new-buffer activate)
    "If buffer does not exist, prompt."
    (let ((buff (ad-get-arg 0)))
      (if (or (not (interactive-p))
              (get-buffer buff)
              (yes-or-no-p
               (format "`%s' does not exist, create new file? " buff)))
          ad-do-it)))