* RE: File menu changes (suggestions) / Options menu
@ 2005-06-21 15:51 David Reitter
2005-06-22 12:32 ` File menu changes (suggestions) John S. Yates, Jr.
0 siblings, 1 reply; 11+ messages in thread
From: David Reitter @ 2005-06-21 15:51 UTC (permalink / raw
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-21 15:51 File menu changes (suggestions) / Options menu David Reitter
@ 2005-06-22 12:32 ` John S. Yates, Jr.
2005-06-23 0:46 ` Miles Bader
0 siblings, 1 reply; 11+ messages in thread
From: John S. Yates, Jr. @ 2005-06-22 12:32 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-22 12:32 ` File menu changes (suggestions) John S. Yates, Jr.
@ 2005-06-23 0:46 ` Miles Bader
2005-06-23 2:26 ` John S. Yates, Jr.
0 siblings, 1 reply; 11+ messages in thread
From: Miles Bader @ 2005-06-23 0:46 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 0:46 ` Miles Bader
@ 2005-06-23 2:26 ` John S. Yates, Jr.
2005-06-23 2:31 ` Miles Bader
0 siblings, 1 reply; 11+ messages in thread
From: John S. Yates, Jr. @ 2005-06-23 2:26 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 2:26 ` John S. Yates, Jr.
@ 2005-06-23 2:31 ` Miles Bader
2005-06-23 11:18 ` John S. Yates, Jr.
0 siblings, 1 reply; 11+ messages in thread
From: Miles Bader @ 2005-06-23 2:31 UTC (permalink / raw
Cc: emacs-devel, miles
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 2:31 ` Miles Bader
@ 2005-06-23 11:18 ` John S. Yates, Jr.
2005-06-23 11:39 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: John S. Yates, Jr. @ 2005-06-23 11:18 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 11:18 ` John S. Yates, Jr.
@ 2005-06-23 11:39 ` Miles Bader
2005-06-24 5:36 ` Richard M. Stallman
2005-06-24 10:10 ` Eli Zaretskii
2 siblings, 0 replies; 11+ messages in thread
From: Miles Bader @ 2005-06-23 11:39 UTC (permalink / raw
Cc: emacs-devel
"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!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 11:18 ` John S. Yates, Jr.
2005-06-23 11:39 ` Miles Bader
@ 2005-06-24 5:36 ` Richard M. Stallman
2005-06-25 1:24 ` John S. Yates, Jr.
2005-06-24 10:10 ` Eli Zaretskii
2 siblings, 1 reply; 11+ messages in thread
From: Richard M. Stallman @ 2005-06-24 5:36 UTC (permalink / raw
Cc: miles, emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-24 5:36 ` Richard M. Stallman
@ 2005-06-25 1:24 ` John S. Yates, Jr.
2005-06-25 16:40 ` Richard M. Stallman
0 siblings, 1 reply; 11+ messages in thread
From: John S. Yates, Jr. @ 2005-06-25 1:24 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: File menu changes (suggestions)
2005-06-23 11:18 ` John S. Yates, Jr.
2005-06-23 11:39 ` Miles Bader
2005-06-24 5:36 ` Richard M. Stallman
@ 2005-06-24 10:10 ` Eli Zaretskii
2 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2005-06-24 10:10 UTC (permalink / raw
Cc: miles, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-06-25 16:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-21 15:51 File menu changes (suggestions) / Options menu David Reitter
2005-06-22 12:32 ` File menu changes (suggestions) John S. Yates, Jr.
2005-06-23 0:46 ` Miles Bader
2005-06-23 2:26 ` John S. Yates, Jr.
2005-06-23 2:31 ` Miles Bader
2005-06-23 11:18 ` John S. Yates, Jr.
2005-06-23 11:39 ` Miles Bader
2005-06-24 5:36 ` Richard M. Stallman
2005-06-25 1:24 ` John S. Yates, Jr.
2005-06-25 16:40 ` Richard M. Stallman
2005-06-24 10:10 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.