Options menu

Options menu

[Kim F. Storm]

With the recent addition of "blinking cursor" to the options
menu, it has become even more dis-organized than before.


I suggest to rearrange it slightly to make the structure
more logical and useful, by placing frequently used
items at the top and "one-time" customizations later.

For example:


OPTIONS
======================================
   Customize Emacs                   >
--------------------------------------
   Language Environment (Mule)       >
   Set Font/fontset
--------------------------------------
   Show/Hide                         >
[] Blinking Cursor
[] Syntax Highlighting
[] Paren Match Highlighting
[] Active Region Highlighting
--------------------------------------
[] Truncate Long Lines in this Buffer
[] Word Wrap in Text Modes
[] Case-insensitive Search
[] C-x/C-c/C-v cut-and-paste (CUA)
--------------------------------------
[] Use Directory Names in Buffer Names
[] Save Places in Files between Sessions
[] Automatic File De/compression
--------------------------------------
[] Enter Debugger on Error
[] Enter Debugger on Quit/C-g
--------------------------------------
   Save Options
======================================



Personally, I would also like to rename "Show/Hide" to "Appearence"
and move "Blinking Cursor" under that heading, but that's less
important.

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

Re: Options menu

[David Kastrup]

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

> With the recent addition of "blinking cursor" to the options
> menu, it has become even more dis-organized than before.
>
>
> I suggest to rearrange it slightly to make the structure
> more logical and useful, by placing frequently used
> items at the top and "one-time" customizations later.

Uh, that's not "logical", that is at best "useful", and for a doubtful
value of "useful": after all, a logical grouping will save people time
also by letting them skip over uninteresting sections.

> OPTIONS
> ======================================
>    Customize Emacs                   >
> --------------------------------------
>    Language Environment (Mule)       >
>    Set Font/fontset
> --------------------------------------
>    Show/Hide                         >
> [] Blinking Cursor
> [] Syntax Highlighting
> [] Paren Match Highlighting
> [] Active Region Highlighting
> --------------------------------------

I don't think putting submenus at the top is a good idea, since the
usual menu semantics imply that some of those menus tend to open in
the process of trying to select options below them.

Customization menus tend to be at the bottom of menu stacks, anyway,
for almost all applications I know.


> [] Truncate Long Lines in this Buffer
> [] Word Wrap in Text Modes
> [] Case-insensitive Search
> [] C-x/C-c/C-v cut-and-paste (CUA)
> --------------------------------------

The order of the above is completely arbitrary.  We have some
highlighting stuff, then we have the buffer-specific long line stuff,
then we have some formatting specific "in text modes", then comes a
completely unrelated search option, and then again an editing mode
speciality.

This is pretty much chaotic.

> [] Use Directory Names in Buffer Names

Looks like a candidate for "Appearance".  Appearance could be
structured into overall appearance (frame stuff, cursor, menubar,
toolbar, speedbar) and detailed appearance (dirnames in buffers, file
name shadow, syntax highlighting).

> [] Save Places in Files between Sessions
> [] Automatic File De/compression

I'd remove the latter point from the menus and enable it by default.

> --------------------------------------
> [] Enter Debugger on Error
> [] Enter Debugger on Quit/C-g
> --------------------------------------

Not sure whether this is a good idea to put in a user menu.  It makes
it somewhat easier to give instructions for generating backtraces in
the case of tracking down a bug.  But it also is clutter.

> Personally, I would also like to rename "Show/Hide" to "Appearence"
> and move "Blinking Cursor" under that heading, but that's less
> important.

I think now that Emacs has a --no-blinking-cursor command line option
that is also given by --help, those people that can't stand the cursor
long enough to configure it off have a reasonable escape path.  So I'd
move the Blinking Cursor to Appearance.  We should do what is
reasonably possible to reduce clutter.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> OPTIONS
>> ======================================
>>    Customize Emacs                   >
>> --------------------------------------
>>    Language Environment (Mule)       >
>>    Set Font/fontset
>> --------------------------------------
>
> I don't think putting submenus at the top is a good idea, since the
> usual menu semantics imply that some of those menus tend to open in
> the process of trying to select options below them.

But the point of the rearrange is that those things are something
you use more often than the "one shot" options below it.  How
often do you toggle Syntax Highlighting?

> Customization menus tend to be at the bottom of menu stacks, anyway,
> for almost all applications I know.

I know, but on the Edit menu, or Tools menu -- and is called Options
or Preferences ... so it's still difficult to find.  Putting it at
the top of Options make it EASY to find.

>> [] Truncate Long Lines in this Buffer
>> [] Word Wrap in Text Modes
>> [] Case-insensitive Search
>> [] C-x/C-c/C-v cut-and-paste (CUA)
>
> The order of the above is completely arbitrary.  

Agree -- but it is the current order, I just don't have a better
proposal.

>> [] Use Directory Names in Buffer Names
>
> Looks like a candidate for "Appearance".  Appearance could be
> structured into overall appearance (frame stuff, cursor, menubar,
> toolbar, speedbar) and detailed appearance (dirnames in buffers, file
> name shadow, syntax highlighting).

I agree this would be a significant enhancement.

>
>> [] Save Places in Files between Sessions
>> [] Automatic File De/compression
>
> I'd remove the latter point from the menus and enable it by default.

Ok with me.

>
>> --------------------------------------
>> [] Enter Debugger on Error
>> [] Enter Debugger on Quit/C-g
>> --------------------------------------
>
> Not sure whether this is a good idea to put in a user menu.  It makes
> it somewhat easier to give instructions for generating backtraces in
> the case of tracking down a bug.  But it also is clutter.

For me, those are really the only options that I use regularly,
so removing them from Options may be ok if they are moved to
some other menu.

Perhaps they would fit better on the Help menu -- then then
you cannot save them (but do you really want to do that?)
I never want to save them, and was actually surprised to see
that they _are_ saved by "Save Options"!!!


>
>> Personally, I would also like to rename "Show/Hide" to "Appearence"
>> and move "Blinking Cursor" under that heading, but that's less
>> important.
>
> I think now that Emacs has a --no-blinking-cursor command line option
> that is also given by --help, those people that can't stand the cursor
> long enough to configure it off have a reasonable escape path.  So I'd
> move the Blinking Cursor to Appearance.  We should do what is
> reasonably possible to reduce clutter.

Agree.

Re: Options menu

[Chong Yidong]

> I don't think putting submenus at the top is a good idea, since the
> usual menu semantics imply that some of those menus tend to open in
> the process of trying to select options below them.

Another annoying aspect is that the submenus will open up while navigating
the menus with the left/right arrows, so you can't access the top-level
menus consecutively.  I don't know how often people do this in Emacs,
though.

RE: Options menu

[Drew Adams]

[-- Attachment #1.1: Type: text/plain, Size: 2130 bytes --]

    OPTIONS
    ======================================
1      Customize Emacs                   >
    --------------------------------------
2      Language Environment (Mule)       >
3      Set Font/fontset
    --------------------------------------
4      Show/Hide                         >
5   [] Blinking Cursor
6   [] Highlighting
7   [] Active Region Highlighting
    --------------------------------------
8   [] Truncate Syntax Highlighting
9   [] Paren Match Long Lines in this Buffer
10  [] Word Wrap in Text Modes
11  [] Case-insensitive Search
12  [] C-x/C-c/C-v cut-and-paste (CUA)
    --------------------------------------
13  [] Use Directory Names in Buffer Names
14  [] Save Places in Files between Sessions
15  [] Automatic File De/compression
    --------------------------------------
16  [] Enter Debugger on Error
17  [] Enter Debugger on Quit/C-g
    --------------------------------------
18     Save Options
    ======================================

1. I agree generally with David's siggestions.

2. Below is one possible reordering, with some name changes (shorter).
Submenus use nouns; menu items use verbs. Some items could be removed, as
Kim & David suggested. Debug stuff could be combined in a submenu instead of
a main-menu pane.

3. Note the ellipsis (...) for Font: This opens a dialog box (at least on
Windows).


[] Remember Last Place in Files 14
[] Search Case-Sensitively      11
[] C-x/c/v to Cut, Copy, Paste  12
[] Auto (De)compress Files      15
---------------------------
[] Enter Debugger on Error      16
[] Enter Debugger on Quit (C-g) 17
---------------------------
Font...                          3
Appearance                  >    4
    (+ current Show/Hide menu)

    [] Highlight                 6
    [] Highlight Region          7
    [] Highlight Matching Parens 9
    ----------------------------
    [] Blink Cursor              5
    [] Truncate Long Lines       8
    [] Word-Wrap in Text Modes  10
    [] Add Path to Buffer Name  13

Language Environment (Mule) >    2
More Options (Customize)    >    1
-----------------------
Save Options                    18

[-- Attachment #1.2: Type: text/html, Size: 8652 bytes --]

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

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

Re: Options menu

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 18 Mar 2005 07:48:49 -0800
> 
>     OPTIONS
>     ======================================
> 1      Customize Emacs                   >
>     --------------------------------------
> 2      Language Environment (Mule)       >
> 3      Set Font/fontset
>     --------------------------------------
> 4      Show/Hide                         >
> 5   [] Blinking Cursor
> 6   [] Highlighting
> 7   [] Active Region Highlighting

Please don't make such a change: the simple toggle-type options should
come first, and the submenus (like Mule) later.  Not the other way
around.  Likewise with Customize: it should come after the toggles.

RE: Options menu

[Drew Adams]

    > From: "Drew Adams" <drew.adams@oracle.com>
    > Date: Fri, 18 Mar 2005 07:48:49 -0800
    >
    >     OPTIONS
    >     ======================================
    > 1      Customize Emacs                   >
    >     --------------------------------------
    > 2      Language Environment (Mule)       >
    > 3      Set Font/fontset
    >     --------------------------------------
    > 4      Show/Hide                         >
    > 5   [] Blinking Cursor
    > 6   [] Highlighting
    > 7   [] Active Region Highlighting

    Please don't make such a change: the simple toggle-type options should
    come first, and the submenus (like Mule) later.  Not the other way
    around.  Likewise with Customize: it should come after the toggles.

Uh, are you sure you're replying to me? What you quoted was from Kim; I
suggested something different that agrees 100% with what you just said.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> Looks like a candidate for "Appearance".  Appearance could be
> structured into overall appearance (frame stuff, cursor, menubar,
> toolbar, speedbar) and detailed appearance (dirnames in buffers, file
> name shadow, syntax highlighting).

Without wanting to comment too much on this now I would like to say I like
the idea of an "Appearance" submenu. I have many times thought of suggesting
a "View" top menu which would contain the same things.

Most applications I use on w32 have a "View" top menu. I do not know about
GNOME hear, whether it proposes something like this or not. My gut feeling
is however that most w32 users would expect a "View" top menu. (According to
user surveys the order and content of the top menu seems to be important. It
should be coherent across applications if possible.)

My gut also tells me it is unlikely that we will have a "View" top menu now.
However an "Appearance" sub menu with the same content will serve part of
the same purpose and will propably IMO feel logical for most users.

I believe that also the appropriate toggle things like "Blinking cursor"
should go into this submenu.

Re: Options menu

[Richard Stallman]

    I suggest to rearrange it slightly to make the structure
    more logical and useful, by placing frequently used
    items at the top and "one-time" customizations later.

People, please let's NOT have a long discussion of whether to do this.
Kim, could you look at what people have already said, think about it,
and what you think is best?

Re: Options menu

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 18 Mar 2005 12:53:29 -0800
> 
>     Please don't make such a change: the simple toggle-type options should
>     come first, and the submenus (like Mule) later.  Not the other way
>     around.  Likewise with Customize: it should come after the toggles.
> 
> Uh, are you sure you're replying to me? What you quoted was from Kim; I
> suggested something different that agrees 100% with what you just said.

I was writing to whomever considers such a rearrangement, and your
message did at first say that you "generally agree" with it.

It is unfortunate that so many messages on this list, including in
this thread, lately became so long and wordy that I cannot afford
reading more than their first page (my pages are 40-line long), and
consequently sometimes miss major points that are beyond that.  I'm
embarrassed to raise this issue, but I'd really ask people to try to
write more concisely and exercise will power to omit minor points.
Sorry if this sounds inappropriate, but it bugs me for quite some time
now.

Re: Options menu

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> Date: Fri, 18 Mar 2005 23:56:02 +0100
> Cc: emacs-devel@gnu.org
> 
> Most applications I use on w32 have a "View" top menu.

This was considered when the menu bar was restructured in preparation
for Emacs 21.1.  The conclusion, IIRC, was that View is generally
inappropriate in a text editor, because it is not a program whose
purpose is to show you something, in which case View selects what
details you are being shown.

> My gut also tells me it is unlikely that we will have a "View" top menu now.
> However an "Appearance" sub menu with the same content will serve part of
> the same purpose and will propably IMO feel logical for most users.

If all Appearance does is be a parent for a few more-or-less unrelated
options, then we'd be better off without it.

When Emacs 21.1 was released, many users complained about the changed
menu-bar structure, even though the new structure was generally
better, certainly more standard-compliant, and had many useful
additions.  Still, they complained.  There's a lesson to be learned
here, IMHO: significant changes in the menu bar should only be done
for a very good reason.

Re: Options menu

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
>> Date: Fri, 18 Mar 2005 23:56:02 +0100
>> Cc: emacs-devel@gnu.org
>
>> My gut also tells me it is unlikely that we will have a "View" top
>> menu now.  However an "Appearance" sub menu with the same content
>> will serve part of the same purpose and will propably IMO feel
>> logical for most users.
>
> If all Appearance does is be a parent for a few more-or-less
> unrelated options, then we'd be better off without it.

I don't see how grouping those options that concern the display/window
appearance of Emacs outside of any buffers (and basically
mode-independent) under "Appearance" makes them unrelated.  The
purpose is to group them under an obvious item.  Moving them in a
submenu seems appropriate to me since people will tend to use this
menu once for configuring their personal preferences, and then stay
off it.  The plethora of available options makes it a good candidate
for a submenu: a top menu would necessitate a very careful choice of
"most relevant", and since this menu really is all about taste and
little about functionality, we can spend years fighting over the
relevancy of particular options.

> When Emacs 21.1 was released, many users complained about the
> changed menu-bar structure, even though the new structure was
> generally better, certainly more standard-compliant, and had many
> useful additions.  Still, they complained.  There's a lesson to be
> learned here, IMHO: significant changes in the menu bar should only
> be done for a very good reason.

Uh, Eli?  Reality check.  The last released menu structure is from the
year 2001 or so.  No matter _what_ we will release next, it will have
significant changes all over the board.  So we might as well aim for
the best solution instead of "least amount of changes" as compared to
some fuzzy non-released state.

Consistency and cleanliness _are_ good reasons.  Once we have released
something, _then_ changes should be done only for a good reason.  I
agree with that lesson you proclaim here.  And so it becomes more
important that we release the best we can manage, since _currently_ we
are not bound by precedence: the current structure _is_ already
completely dissimilar to the last released one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Eli Zaretskii]

> Cc: "Lennart Borgman" <lennart.borgman.073@student.lu.se>,
> 	  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 19 Mar 2005 12:24:34 +0100
> 
> > When Emacs 21.1 was released, many users complained about the
> > changed menu-bar structure, even though the new structure was
> > generally better, certainly more standard-compliant, and had many
> > useful additions.  Still, they complained.  There's a lesson to be
> > learned here, IMHO: significant changes in the menu bar should only
> > be done for a very good reason.
> 
> Uh, Eli?  Reality check.  The last released menu structure is from the
> year 2001 or so.

It was redesigned in 2001, but it was last released just a few weeks
ago, with Emacs 21.4.

> No matter _what_ we will release next, it will have significant
> changes all over the board.

Not in the menu-bar's menu structure, AFAIK.

> Consistency and cleanliness _are_ good reasons.

Apparently, not good enough for quite a few users.  That was what I
was trying to tell above, obviously with no success.

> the current structure _is_ already completely dissimilar to the last
> released one.

Unless I miss a lot of changes, I don't see how the current CVS is
``completely dissimilar'' to v21.4 as far as the menu bar is
concerned.  The changes are quite small.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>

> > Most applications I use on w32 have a "View" top menu.
>
> This was considered when the menu bar was restructured in preparation
> for Emacs 21.1.  The conclusion, IIRC, was that View is generally
> inappropriate in a text editor, because it is not a program whose
> purpose is to show you something, in which case View selects what
> details you are being shown.

I think that "View" here mostly is a synonym for "Appearance". In for
example Firefox View menu the main items are:

    Toolbars, Status Bar, Sidebars;
    Stop, Reload;
    Text Size, Page Style, Character Encoding;
    Page Source, Full Screen.

So if that was the reason not to have a View top menu then it might be time
to rethink?


> When Emacs 21.1 was released, many users complained about the changed
> menu-bar structure, even though the new structure was generally
> better, certainly more standard-compliant, and had many useful
> additions.  Still, they complained.  There's a lesson to be learned
> here, IMHO: significant changes in the menu bar should only be done
> for a very good reason.

This can be compared to that users of the perhaps most common office
software suite said that the restructuring of the menus in the different
applications to make them more similar was one of the things they liked the
best in the 2000 release. They all have a View top menu now.

Re: Options menu

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Cc: "Lennart Borgman" <lennart.borgman.073@student.lu.se>,
>> 	  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 19 Mar 2005 12:24:34 +0100
>> 
>> > When Emacs 21.1 was released, many users complained about the
>> > changed menu-bar structure, even though the new structure was
>> > generally better, certainly more standard-compliant, and had many
>> > useful additions.  Still, they complained.  There's a lesson to be
>> > learned here, IMHO: significant changes in the menu bar should only
>> > be done for a very good reason.
>> 
>> Uh, Eli?  Reality check.  The last released menu structure is from the
>> year 2001 or so.
>
> It was redesigned in 2001, but it was last released just a few weeks
> ago, with Emacs 21.4.

I just took a look at Emacs 21.4 and noticed that it indeed is quite
similar to what we have now except for a few additions (New file,
Hide/Show, Blinking Cursor, CUA mode and some others).  Somehow I was
of the opinion that the big redesign happened post-21.1.

>> No matter _what_ we will release next, it will have significant
>> changes all over the board.
>
> Not in the menu-bar's menu structure, AFAIK.
>
>> Consistency and cleanliness _are_ good reasons.
>
> Apparently, not good enough for quite a few users.  That was what I
> was trying to tell above, obviously with no success.

Well, since Hide/Show is an addition since the last release, renaming
it to "Appearance" would not be a compatibility consideration.  And
moving blink-cursor-mode inside of it would make the menu _more_
similar to what we had previously.

>> the current structure _is_ already completely dissimilar to the
>> last released one.
>
> Unless I miss a lot of changes, I don't see how the current CVS is
> ``completely dissimilar'' to v21.4 as far as the menu bar is
> concerned.  The changes are quite small.

You are correct.  Sorry for being confused about that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "Eli Zaretskii" <eliz@gnu.org>
>
>> > Most applications I use on w32 have a "View" top menu.
>>
>> This was considered when the menu bar was restructured in preparation
>> for Emacs 21.1.  The conclusion, IIRC, was that View is generally
>> inappropriate in a text editor, because it is not a program whose
>> purpose is to show you something, in which case View selects what
>> details you are being shown.
>
> I think that "View" here mostly is a synonym for "Appearance". In for
> example Firefox View menu the main items are:
>
>     Toolbars, Status Bar, Sidebars;
>     Stop, Reload;
>     Text Size, Page Style, Character Encoding;
>     Page Source, Full Screen.
>
> So if that was the reason not to have a View top menu then it might be time
> to rethink?

"Page Source" is not exactly "Appearance".  I have to admit being
surprised at this usage, nevertheless.

Gnumeric offers

New View (generate a new frame into same "buffer")
Freeze Panes
Windows -> (list of available windows to jump to)
Toolbars -> (list of available toolbars to enable)
View Statusbar (checkmark)
Full Screen
Zoom

This is a bit more mixed than just static appearance setup, but also
carries weight in that direction.

Personally, I find "View" strongly associated with viewing files, in
particular in the contest of Emacs.

I find "View" less appropriate for what it is used in Firefox et al
than "Appearance".  The one thing that speaks for "View" is that the
name is shorter, taking up less space as a top item in the menu bar.

But I don't think this sort of functionality would warrant a top menu
item in most modes in Emacs.  If for compatibility reasons or whatever
it was decided to make this a top item, I'd probably also opt for
"View" just for saving menu bar real space.

One argument for that would be that _when_ you use this menu, you are
likely to use it several times in succession until Emacs' appearance
meets your needs, and then it will be tiring to go through
Options/Appearance for every selection.  In GTK+, you would probably
just tear off the menu (if you know how to do it) for this process.

But we are running short of menubar space for a typical LaTeX editing
session with preview-latex, RefTeX, AUCTeX (two! top menus) and
LaTeX-math-mode already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> Cc: <emacs-devel@gnu.org>
> Date: Sat, 19 Mar 2005 16:51:55 +0100
> 
> I think that "View" here mostly is a synonym for "Appearance". In for
> example Firefox View menu the main items are:
> 
>     Toolbars, Status Bar, Sidebars;
>     Stop, Reload;
>     Text Size, Page Style, Character Encoding;
>     Page Source, Full Screen.

These are all either toggle-type options (we have most of them under
Options->Show/Hide) or text/font options (we have them under
Edit->Text Properties).  To dedicate a whole top-level item to them
sounds unwise.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>

> These are all either toggle-type options (we have most of them under
> Options->Show/Hide) or text/font options (we have them under
> Edit->Text Properties).  To dedicate a whole top-level item to them
> sounds unwise.

Yes, I actually believe that is the case too. But keeping sort of similar
grouping under Appearance in the Option menu would in my opinion be a good
alternative. After all you do not change this things very often. A more
important thing is probably that they are easy to find and that means
logical structure, similarity and not too long menus (at least).

Re: Options menu

[Richard Stallman]

I don't want to rethink the Emacs menu bar now.
It would be a big argument.  Let's not have the argument.

People, when someone starts a discussion about a substantial change in
Emacs, please don't argue about the details.  If you disagree with the
idea, please just say that this is the wrong time to consider such a
change.

Re: Options menu

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I don't want to rethink the Emacs menu bar now.
> It would be a big argument.  Let's not have the argument.
>
> People, when someone starts a discussion about a substantial change
> in Emacs, please don't argue about the details.  If you disagree
> with the idea, please just say that this is the wrong time to
> consider such a change.

Oh, but it isn't really a substantial change.  It is getting the
details right that we are quibbling about.  And in the course of that
several things have come to light.  Basically, we have the following:

a) The layout of menu bar and Options menu has _not_ significantly
changed since 21.1, so any restructuring that is not a significant
improvement will tend to make people notice/complain/whatever.

b) one of the few additions we have is the "Hide/Show" menu.  It
appears that similar functionality is available in other applications
as a top-level menu "View".  There has pretty much consent on the list
that this does not seem to be a good option for Emacs (and it
certainly would be a large change).

It has been proposed to rather name this menu "Appearance" since
Hide/Show in an editor is more or less connotated with folding.
Naming it "View" to match the top-level name of other applications for
this item does not seem to be a good idea: since it is a submenu, it
would be unlike to other applications, anyway, and the name "View"
seems to be chosen more for its brevity than its accuracy.

c) The option blink-cursor-mode has been put into the top level of the
Options menu at the wish of people that say that it is too painful for
them to dig through the menus to turn this off.  But in the mean-time,
we have gained an appropriate command line option (mentioned in the
manual page), so this should not be an issue.  Logically, it would
appear to fit with what currently is in "Hide/Show", though it fits
the wording of the menu even less.  At its current place in the
Options menu, it appears rather out of context.

So as the "minimal" solution as compared to the last release, I would
propose
a) naming the current "Hide/Show" (which has not yet been released
under this name) into "Appearance".
b) move the blink-cursor-mode option there, even in case that people
would not want to have "Appearance" rather than "Hide/Show".

That's pretty much the minimal version of rearrangement with regard to
the current state that has, I think, more or less met approval.  It
does not concern _anything_ that has already been released in 21.4.

If nobody objects in the next day or so, I volunteer to install these
two changes including checking the documentation for accuracy.  I
think we have said more or less all that needs to be said.  If I am
wrong in assuming that nobody would object, we can still hold a vote
instead of further discussion.


Ok, I hope I am not wrong in my estimate that we can settle this in
this manner at the current point of time, without causing too much
anguish or bad feelings.

And now for something completely different.  Please don't consider the
following a part of the above proposal: I would not want to ram it
down people's throats without having had a chance to think about it:

Since I have stared now at the current menus for 21.4 and 22.x for
longer than probably ever previously, I would like to mention one
other thing that has struck me as standing out negatively, and this
_would_ be a change with regard to 21.4: I'd swap the order of the
"Save Options" and "Customize Emacs" menu entries to make "Save
Options" be the last entry in the menu: that's where people look for
it.

I am also not happy about the "Customize Emacs" menu name: it implies
that selecting options in the Options menu would be different from
customizing Emacs.  I'd prefer to have this menu called "All Options"
or so, saving the "Customize" moniker for the tooltip.  This would be
in line with already made changes to things like
"global-font-lock-mode" which we now present as "Syntax Highlighting".

Please don't spend much time arguing these two points.  The first
point only warrants an "Agree" "Don't agree", and then we can just go
by majority, and the situation for the second one basically is the
same.  Since both of these suggestions would be a change with regard
to 21.4, if there is any contention about them (except maybe for
better proposals for the "All Options" menu), we should rather drop
them instead of wasting time discussing them, if the advantages are
not seen as clearcut as I imagine.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Luc Teirlinck]

David Kastrup wrote:

   Since both of these suggestions would be a change with regard
   to 21.4, if there is any contention about them (except maybe for
   better proposals for the "All Options" menu), we should rather drop
   them instead of wasting time discussing them, if the advantages are
   not seen as clearcut as I imagine.

They are not as clearcut as you imagine.

Sincerely,

Luc.

Re: Options menu

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> David Kastrup wrote:
>
>    Since both of these suggestions would be a change with regard
>    to 21.4, if there is any contention about them (except maybe for
>    better proposals for the "All Options" menu), we should rather drop
>    them instead of wasting time discussing them, if the advantages are
>    not seen as clearcut as I imagine.
>
> They are not as clearcut as you imagine.

Then they are off my agenda for 22.1.  I sometimes wish that we had
appointed or elected "dictators" for specific subsystems of Emacs: it
is clear that unilateral agreement is very hard to achieve, and so
we'd probably get more things achieved with less quibbling if people
could just present their case without catering for all other
proposals, and then one person who is generally trusted in that
respect (and can be replaced in that function if people agree) makes
the call.  We'd probably achieve something a bit closer to coherency
with less total investment of time and nerves that way.

Of course Richard fills in some of that space, but given his
intermittent access and numerous other chores, the current situation
still lends itself to too much arguing which in the end achieves less
with probably a higher total frustration level than if somebody was
declared responsible for decisions in certain areas.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Luc Teirlinck]

   Of course Richard fills in some of that space,

Of course.

   but given his intermittent access and numerous other chores,

But the problem here are things like:

   If nobody objects in the next day or so, I volunteer to install these
   two changes

If you were willing to wait at least two days for a decision, then at
the very least Richard would have the time to say that he needed more time.

Sincerely,

Luc.

Re: Options menu

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

>    Of course Richard fills in some of that space,
>
> Of course.
>
>    but given his intermittent access and numerous other chores,
>
> But the problem here are things like:
>
>    If nobody objects in the next day or so, I volunteer to install these
>    two changes
>
> If you were willing to wait at least two days for a decision, then
> at the very least Richard would have the time to say that he needed
> more time.

Ok, so apart from waiting for a while for objections, I won't do a
thing without Richard giving the ok for it explicitly.

"Volunteer" was just meant to tell people that I am willing to do the
work (so they don't need to consider being burdened with that work for
rogering this), not that I was trying to establish facts to spite
anyone.

Better?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>


> It has been proposed to rather name this menu "Appearance" since

Agree.


> c) The option blink-cursor-mode has been put into the top level of the
...
> a) naming the current "Hide/Show" (which has not yet been released
> under this name) into "Appearance".

Agree. It is a one time shot and I guess it should be possible to do it
once.


> b) move the blink-cursor-mode option there, even in case that people
> would not want to have "Appearance" rather than "Hide/Show".

Agree if that unfortunately happens.


> _would_ be a change with regard to 21.4: I'd swap the order of the
> "Save Options" and "Customize Emacs" menu entries to make "Save
> Options" be the last entry in the menu: that's where people look for
> it.

That would be good.

> I am also not happy about the "Customize Emacs" menu name: it implies
> that selecting options in the Options menu would be different from
> customizing Emacs.  I'd prefer to have this menu called "All Options"

Agree. Maybe "Browse All Options".


> "global-font-lock-mode" which we now present as "Syntax Highlighting".

Can this go into "Appearance" too please. A shorter structured menu makes it
easier for users.

Re: Options menu

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> Since I have stared now at the current menus for 21.4 and 22.x for
> longer than probably ever previously, I would like to mention one
> other thing that has struck me as standing out negatively, and this
> _would_ be a change with regard to 21.4: I'd swap the order of the
> "Save Options" and "Customize Emacs" menu entries to make "Save
> Options" be the last entry in the menu: that's where people look for
> it.

I think the reason to put it above "Customize Emacs" is to avoid
misleading users into thinking that it will save changes made inside
customize.

> I am also not happy about the "Customize Emacs" menu name: it implies
> that selecting options in the Options menu would be different from
> customizing Emacs.  I'd prefer to have this menu called "All Options"

This has the same potential for misleading users about the scope of
"Save Options".

Re: Options menu

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

>> "global-font-lock-mode" which we now present as "Syntax
>> Highlighting".
>
> Can this go into "Appearance" too please. A shorter structured menu
> makes it easier for users.

It has been there already in Emacs-21.1, and all the other
"Hide/View/Appearance/whatever" options concern the frame/window
layout as opposed to the windows content themselves.  We already have
transient-mark-mode and show-paren-mode (which also operate _in_) the
buffer in the Options menu.

So it would appear that such a move does not make sense without at
least a major menu restructuring, and we have ruled that out for 22.1.
So please let's not reopen this can of worms.  No restructuring of
things established in 21.1, not without very compelling reason.  We
closed this discussion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Since I have stared now at the current menus for 21.4 and 22.x for
>> longer than probably ever previously, I would like to mention one
>> other thing that has struck me as standing out negatively, and this
>> _would_ be a change with regard to 21.4: I'd swap the order of the
>> "Save Options" and "Customize Emacs" menu entries to make "Save
>> Options" be the last entry in the menu: that's where people look
>> for it.
>
> I think the reason to put it above "Customize Emacs" is to avoid
> misleading users into thinking that it will save changes made inside
> customize.
>
>> I am also not happy about the "Customize Emacs" menu name: it
>> implies that selecting options in the Options menu would be
>> different from customizing Emacs.  I'd prefer to have this menu
>> called "All Options"
>
> This has the same potential for misleading users about the scope of
> "Save Options".

Ok, now I know at least a potential reason for that arrangement.
Given that information, I am pretty much of the opinion that this
arrangement is fundamentally broken, and swapping the two menu entries
is a feeble attempt of conceiling it.  We won't fool anybody but
ourselves by that (well, we _will_ fool the users).

Putting "customize" off the "Options" menu altother does not appear
helpful (how about an unselectable entry "See also Tools/Customize"?),
so the only reasonably safe way I can think of is having "Save
Options" quip:

"Some Options have been set with Customize.  Save them too?"

as long as customized non-saved options remain.

Yes, this would make the proposed renaming of "Customize Emacs" into
"All Options" not the best idea.  However, "Customize Emacs" also does
not bring across the information that "Customize" is a special way of
customizing Emacs: the "Options" menu certainly is also used for
customizing Emacs.  So either we'd have to name this "Use Customize"
or "Customize" only, or "Customize Tool" (which would beg the question
why it is not in the "Tools" menu).

Swapping the menu entries alone (as is the reason for the current
arrangement) is far too obscure to help users figure that out.  In
addition, it will be a convenient shortcut for people playing around
with several customize options before they settle on an arrangement
they find fit for saving.

I am glad to hear that there is a reason for that strange order of
options, but I think the problem we are trying to solve that way
requires a less subtle approach.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Miles Bader]

On Sun, 20 Mar 2005 17:26:02 +0100, David Kastrup <dak@gnu.org> wrote:
> b) one of the few additions we have is the "Hide/Show" menu.  It
> appears that similar functionality is available in other applications
> as a top-level menu "View".  There has pretty much consent on the list
> that this does not seem to be a good option for Emacs (and it
> certainly would be a large change).

Actually I think the name "Hide/Show" was chosen precisely because it
is used in other GUI applications, usually as a submenu of a top-level
"View" menu.

The top-level "View" menu in other apps tends to be much more general,
with "Hide/Show" as a submenu for enabling various toolbars, status
lines, etc.

[Stuff like this tends to change periodically as the winds of GUI
fashion blow of course; the above was true at the time the menu was
initially added.]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

> I think the reason to put it above "Customize Emacs" is to avoid
> misleading users into thinking that it will save changes made inside
> customize.

I am beginning to feel dizzy. Do you mean something like this:

1) M-x customize-option, debug-on-error

2) Change it and "Set" it in the customization buffer.

3) Choose menu "Save Options".

What happens on your computer? On my computer debug-on-error is saved as far
as I can see.

Re: Options menu

[Luc Teirlinck]

Lennart Borgman wrote:

   3) Choose menu "Save Options".

   What happens on your computer? On my computer debug-on-error is saved as far
   as I can see.

If I understood the code in menu-bar.el correctly (I did not try out
anything), then an oversimplified description of the situation if you
choose "Save Options" is:

1.  The following options get saved if their value was set
    either through the menu bar _or_ through Custom.:

scroll-bar-mode debug-on-quit debug-on-error menu-bar-mode
tool-bar-mode save-place uniquify-buffer-name-style fringe-mode
fringe-indicators case-fold-search display-time-mode
auto-compression-mode current-language-environment default-input-method
text-mode-hook.

In as far as text-mode-hook is concerned, the entire current value of
text-mode hook gets saved, not just the part mentioned in the Options
Menu.  This could easily be inappropriate.  All one can do is hope for
the better.

2.  The following options get saved to the custom-set-variables form,
    no matter how they got their value:

line-number-mode column-number-mode cua-mode show-paren-mode
transient-mark-mode global-font-lock-mode blink-cursor-mode

3.  Other options never get saved.

I believe that we might have to clean this situation up after the
release, as part of making changes and bug fixes to Custom.

Sincerely,

Luc.

Re: Options menu

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Lennart Borgman wrote:
>
>    3) Choose menu "Save Options".
>
>    What happens on your computer? On my computer debug-on-error is
>    saved as far as I can see.
>
> If I understood the code in menu-bar.el correctly (I did not try out
> anything), then an oversimplified description of the situation if you
> choose "Save Options" is:
>
> 1.  The following options get saved if their value was set
>     either through the menu bar _or_ through Custom.:
>
> scroll-bar-mode debug-on-quit debug-on-error menu-bar-mode
> tool-bar-mode save-place uniquify-buffer-name-style fringe-mode
> fringe-indicators case-fold-search display-time-mode
> auto-compression-mode current-language-environment
> default-input-method text-mode-hook.
>
> In as far as text-mode-hook is concerned, the entire current value
> of text-mode hook gets saved, not just the part mentioned in the
> Options Menu.  This could easily be inappropriate.  All one can do
> is hope for the better.
>
> 2.  The following options get saved to the custom-set-variables form,
>     no matter how they got their value:
>
> line-number-mode column-number-mode cua-mode show-paren-mode
> transient-mark-mode global-font-lock-mode blink-cursor-mode
>
> 3.  Other options never get saved.
>
> I believe that we might have to clean this situation up after the
> release, as part of making changes and bug fixes to Custom.

Well, that assessment of the situation certainly sounds like
qualifying for the "bug fixes" department even before the release, and
I don't think it can be considered adequately addressed in
release-quality merely by having the "Save Options" menu entry appear
above the "Customize Emacs" submenu.

As I mentioned before, I think the sanest way would be to have "Save
Options" prompt "Options have been set by Customize.  Save them too?"
in case that options outside of the list have been changed from their
default values in this session using Customize without saving.  (Do we
have a handle on whether they were touched by Customize itself?
Perhaps we should.) That would avoid ugly surprises to the user so
that we don't need to have an obscure menu order catering for that,
and it would lower the problem to a level where we can afford thinking
about the rest of the problem after the release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Richard Stallman]

    But the problem here are things like:

       If nobody objects in the next day or so, I volunteer to install these
       two changes

Yes, exactly.  No one should EVER wait less than 2 days for such
responses.

Re: Options menu

[Richard Stallman]

      I sometimes wish that we had
    appointed or elected "dictators" for specific subsystems of Emacs:

We do, for many parts.  For instance, Handa is in charge of Mule
issues and mostly decides them on his own.  But there are parts
that nobody wants to take special responsibility for.

Re: Options menu

[Luc Teirlinck]

David Kastrup wrote:

   Well, that assessment of the situation certainly sounds like
   qualifying for the "bug fixes" department even before the release, and
   I don't think it can be considered adequately addressed in
   release-quality merely by having the "Save Options" menu entry appear
   above the "Customize Emacs" submenu.

It is not really as bad as I may have made it seem.  The options that
get saved are those options that are _listed_ in the menu and that are
not buffer local.  Some get saved if they were set through the menu
bar _or_ through Custom.  (There does not seem to be too much we can
do about that right now.  Without storing more stuff in property
lists, Emacs can not distinguish.)  Others get apparently saved to the
`custom-set-variables-form' no matter how they got a non-standard
value.  This might be easier to fix.

The text-mode-hook problem occurs even if text-mode-hook gets saved
through Custom, although in a less bad form.  A similar problem occurs
when saving any hook variable through Custom.  It is a known problem
to be addressed some time after the release.  The problem with the
menu bar is much worse than the general Custom problem however,
because the user does not even get a chance to notice that he is
saving unrelated stuff to text-mode-hook.  The problem occurs when
trying to save "Word Wrap in Text Modes".  Maybe it might be better to
either enable global auto-fill in all modes (if I understand
correctly, that has just recently become possible) or to enable
auto-fill on a buffer by buffer basis.  Either one would make the hook
problem go away in as far as the menu bar is concerned.

Sincerely,

Luc.

Re: Options menu

[Luc Teirlinck]

>From my previous message:
   
   Some get saved if they were set through the menu
   bar _or_ through Custom.  (There does not seem to be too much we can
   do about that right now.  Without storing more stuff in property
   lists, Emacs can not distinguish.)

Even so, we might not _want_ to do anything about it.  A value which
the user saved through Custom still shows up in the Options Menu.  So
"Save Options" saves exactly all options that the user can see (if he
looks at all submenus), that are not buffer local.

Sincerely,

Luc.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> As I mentioned before, I think the sanest way would be to have "Save
> Options" prompt "Options have been set by Customize.  Save them too?"

Agree. This would be much less surprising than the current situation and as
far as I remember our discussions it would not be too difficult to
implement.

Maybe the prompting could be more helpful (All/Quit/Yes etc), but that is
just details.

Re: Options menu

[Luc Teirlinck]

Lennart Borgman wrote:

   > As I mentioned before, I think the sanest way would be to have "Save
   > Options" prompt "Options have been set by Customize.  Save them too?"

   Agree. This would be much less surprising than the current situation and as
   far as I remember our discussions it would not be too difficult to
   implement.

Any of this should _clearly_ wait till after the release.  It very
much depends on what happens with the Custom discussion, which we can
not afford to re-open right now.

Sincerely,

Luc.

Re: Options menu

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Lennart Borgman wrote:
>
>    > As I mentioned before, I think the sanest way would be to have
>    > "Save Options" prompt "Options have been set by Customize.
>    > Save them too?"
>
>    Agree. This would be much less surprising than the current
>    situation and as far as I remember our discussions it would not
>    be too difficult to implement.
>
> Any of this should _clearly_ wait till after the release.  It very
> much depends on what happens with the Custom discussion,

I don't see that at all.  Customize is involved only as far as it is a
menu entry in the "Options" menu and can be used to set options in a
different way.

This will not change at all.

> which we can not afford to re-open right now.

Correct, but I don't see how it would be relevant.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Luc Teirlinck]

David Kastrup wrote:

   > which we can not afford to re-open right now.

   Correct, but I don't see how it would be relevant.

Several ways.  For instance, in that discussion I believe I remember
that Kim proposed to remove the possibility of setting without saving
altogether.  I guess this will meet with disagreement from some
people, but if it does get adopted, it would make this entire
discussion completely moot.  All options set through Custom or the
Options menu would be saved, because we would have set == saved.

Sincerely,

Luc.

Re: Options menu

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> David Kastrup wrote:
>
>    > which we can not afford to re-open right now.
>
>    Correct, but I don't see how it would be relevant.
>
> Several ways.  For instance, in that discussion I believe I remember
> that Kim proposed to remove the possibility of setting without
> saving altogether.  I guess this will meet with disagreement from
> some people, but if it does get adopted, it would make this entire
> discussion completely moot.  All options set through Custom or the
> Options menu would be saved, because we would have set == saved.

So what?  This would come with removing the "Save Options" from the
menus certainly as well: everything else would not make sense.

But we are not looking for a solution for offering a consistent and
suitably nonconfusing interface for Emacs-23.

We are looking for a consistent and suitabley nonconfusing interface
for the next release, Emacs-22.1, with the _current_ version of
Customize.  And the currently existing combination in CVS is
inconsistent and confusing.  There is not much we can do about the
inconsistency as Customize will not change with its semantics until
the release, but we can lessen the confusion this causes.

We need to marry the current, unchanged Customize with the menus in
the best manner for Emacs-22.1.

The future Customize is irrelevant.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Options menu

[Richard Stallman]

      Some get saved if they were set through the menu
    bar _or_ through Custom.  (There does not seem to be too much we can
    do about that right now.

This behavior is not wrong.  We should not "do anything" about it.

      Without storing more stuff in property
    lists, Emacs can not distinguish.)  Others get apparently saved to the
    `custom-set-variables-form' no matter how they got a non-standard
    value.  This might be easier to fix.

I don't think it is broken, so please don't try to fix it.

    The text-mode-hook problem occurs even if text-mode-hook gets saved
    through Custom, although in a less bad form.

This, I think, is worth fixing.  Fixing it in menu-bar.el could be
easy.  Here's one idea:

Create an option text-mode-auto-fill-mode which, if t, means enable
use of auto-fill when in text mode.  This option's defcustom could
have a :set function that updates text-mode-hook.

Then menu-bar.el only needs to toggle that option in a way that
runs its :set function, and save that option when appropriate.

Re: Options menu

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> We need to marry the current, unchanged Customize with the menus in
> the best manner for Emacs-22.1.
> 
> The future Customize is irrelevant.

Agree.

Re: Options menu

[Richard Stallman]

I think this is a tempest in a teapot, and I wish people
would drop this subject and move on to fixing some of the bugs
that have recently been reported.

Re: Options menu

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I think this is a tempest in a teapot, and I wish people
> would drop this subject and move on to fixing some of the bugs
> that have recently been reported.

Just FYI, Drew took this off-list with a few people copied, and
basically he and I seemed to be the only ones more than marginally
interested, and we wildly disagreed (Drew's standpoint being that
every menu should have its own "Save Options" and never save what is
not in the menu itself, and I completely opposed).

Since repeating back one's arguments between two persons is not
getting anywhere (and probably nobody would be interested in the
outcome, anyway), I quit as well.

So that was that.  I still think it a mistake that "Save Options" will
not even bother to ask whether it should also save options one set
with "Customize", and I had been willing to implement that proposal,
but as no agreement can be reached, let's just keep this as it has
been before.  Shrug.

To make up for it, I fixed some bugs in textprop.c.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum