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)

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

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