bug#4043: 23.1; thanks for emacs 23!

bug#4043: 23.1; thanks for emacs 23!

[xah lee]

not sure what's the best channel to say this, but i just compiled  
emacs 23 on my mac nari-a-hitch! Just wanted to say thanks to all the  
emacs developers. Thank you!

this is on a iMac (1.9 Ghz PowerPC G5; the last G5 model), running OS  
X 10.4.11.

GNU Emacs 23.1.1 (powerpc-apple-darwin8.11.0, NS apple-appkit-824.48)  
of 2009-08-04 on xahg5.local

   Xah
∑ http://xahlee.org/

☄

bug#4043: 23.1; thanks for emacs 23!

[Richard Stallman]

You could really thank us
by switching from non-free MacOS to a free operating system
such as GNU/Linux or BSD.

bug#4043: 23.1; thanks for emacs 23!

[Xah Lee]

How about improving emacs? Because when you improve software of your 
philosophy, then automatically more people will use it.

I would like to see this area improved:

• Emacs's Menu Usability Problem
  http://xahlee.org/emacs/modernization_menu.html

Thank you.

  Xah
∑ http://xahlee.org/

☄

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "xah lee" <xah@xahlee.org>; <4043@emacsbugs.donarmstrong.com>
Cc: <bug-gnu-emacs@gnu.org>; <xah@xahlee.org>
Sent: Wednesday, August 05, 2009 7:15 PM
Subject: Re: bug#4043: 23.1; thanks for emacs 23!


> You could really thank us
> by switching from non-free MacOS to a free operating system
> such as GNU/Linux or BSD. 

Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Stefan Monnier]

> • Emacs's Menu Usability Problem
>  http://xahlee.org/emacs/modernization_menu.html

Some of them sound like good ideas.  Here's my take on it:

> The non-interactive search menus are for one-time use, and do not have
> keyboard shortcuts. This operation method is extremely inefficient, and
> probably is almost never used statistically. Since Emacs provides
> interactive search features, both by menu as well as by keyboard
> shortcut, it should replace these one-time find menu items

I agree that getting rid of the non-interactive search items in
Edit->Search would be a good simplification.

> Emacs's Edit menu.
> The 3 Goto menu items are not much useful.
>     * The “Goto Buffer Position...” invokes the command goto-char, which
>     moves the cursor to the nth char in a buffer. If a programer wants
>     to go to a particular position, typically it is done by line number
>     and column number. The “goto-char” is used for elisp
>     programing. Perhaps less than 2% of Emacs users actually program in
>     elisp. Elisp programers wouldn't need a menu for goto-char. They'd
>     call it by typing M-x.

Yes this one seems pretty useless.

>     * The Goto beginning/ending of buffer is useless as a menu. Users
>     can intuitively press the Page Up, Page Down keys, scroll the mouse,
>     or “Ctrl+Home” and “Ctrl+End” to do the same thing.  All these
>     methods are familiar to users because they are implemented in most
>     apps across Windows, Mac, Linux.  For those using Emacs's “M-<” and
>     “M->” shortcuts, they don't need the menu or the menu to
>     remind them.

[ Please write GNU/Linux rather than just "Linux" when talking about the
  whole system. ]

Not sure about these.  They're not very useful maybe, but they do serve
the purpose of indicating what is the canonical keybinding for
those commands.

> Emacs 22's Options menu.
>     * The “Active Region Highlighting” is on by default in Emacs
>     23. This behavior is standard in all modern editors.  For old time
>     Emacs users who want it off, they can be easily do so thru
>     Customization menu or elisp code.

Maybe this will make sense at some point, but just activating it by
default in Emacs-23 required a fair bit of confrontation.  One of the
conditions to turn it on was that it be as easy as possible to turn it
back off, even in those cases where modifying the .emacs is not an
option (e.g. using someone else's Emacs).

>     * The “Case-Insensitive Search” should be moved to be together with
>     the interactive search menu under Edit.

This also sounds OK, except for the problem of making the behavior of
the "Save options" menu entry clear: currently this entry saves all the
options that appear above in the menu.  So if we move an entry to some
other menu, we get into some trouble.
> 
>     * The Blinking Cursor is standard behavior in all editors.  Probably
>     less than 0.1% users would want to tweak it.  If a tweaker wants it
>     off, he can easily do so using the Customization menu.

This option is one of the ones that generated the largest amount of
noise when Emacs-21 came out (along with the tool-bar and the fringes).
I personally find it very annoying.  So here again, it's in the menu so
it can easily be turned off even in sessions where the .emacs cannot
be modified.

>     * The Enter Debugger commands are used for elisp programing
>     only.  They are not useful for vast majority of Emacs users.

I wouldn't mind removing it from the menu.

>     * The tool-bar is a bar consisting of largish buttons for copy, cut,
>     paste, open, etc.  This is not useful for most people who use Emacs.

I'd tend to agree, but I'm not sure I'm ready to turn it off by default.

>     * The Scroll-bar and Fringe menu items should be gone.  Scroll-bar is
>     a standard feature in all applications.  If a power user wants it
>     off, he can do so thru the customization menu.  The Fringe adjustment
>     is again for tweakers.  It adds distraction.

Those entries mostly play the role of advertisement.

>     * The Time, Battery, are of little use. Their functionality are
>     provided by the OS's tool bar. Again, for geeks who need it, it is
>     easy to call the command by “M-x”.

I'd tend to agree.  But I also do not remember why they were added, so
maybe there's just something I'm missing.

>     * The Size Indication, which shows the file size in the mode-line,
>     should be gone too because for those who needs this feature, they
>     don't need a menu.

No opinion on this one.


        Stefan

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 5:36 AM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
> I agree that getting rid of the non-interactive search items in
> Edit->Search would be a good simplification.

I would suggest burying them deeper down in the menus instead. For
advertising reasons it is still good to have them there.


>> Emacs's Edit menu.
>>     * The Goto beginning/ending of buffer is useless as a menu. Users
>>     can intuitively press the Page Up, Page Down keys, scroll the mouse,
>>     or “Ctrl+Home” and “Ctrl+End” to do the same thing.  All these
>>     methods are familiar to users because they are implemented in most
>>     apps across Windows, Mac, Linux.  For those using Emacs's “M-<” and
>>     “M->” shortcuts, they don't need the menu or the menu to
>>     remind them.
>
> Not sure about these.  They're not very useful maybe, but they do serve
> the purpose of indicating what is the canonical keybinding for
> those commands.

For whom? I think new users will probably use C-End etc.


>>     * The “Case-Insensitive Search” should be moved to be together with
>>     the interactive search menu under Edit.
>
> This also sounds OK, except for the problem of making the behavior of
> the "Save options" menu entry clear: currently this entry saves all the
> options that appear above in the menu.  So if we move an entry to some
> other menu, we get into some trouble.

The "Save options" is in my opinion confusing. I think it would be
better to ask for each option if it would be set permanently or just
temporarily.

This would be easier to understand and there would be no obstacle of
this kind for moving them.


>>     * The Scroll-bar and Fringe menu items should be gone.  Scroll-bar is
>>     a standard feature in all applications.  If a power user wants it
>>     off, he can do so thru the customization menu.  The Fringe adjustment
>>     is again for tweakers.  It adds distraction.
>
> Those entries mostly play the role of advertisement.

Maybe bury them under "Show/Hide - Advanced - Scroll-bar" etc?


>>     * The Time, Battery, are of little use. Their functionality are
>>     provided by the OS's tool bar. Again, for geeks who need it, it is
>>     easy to call the command by “M-x”.
>
> I'd tend to agree.  But I also do not remember why they were added, so
> maybe there's just something I'm missing.

Bury it under advanced as above.


>>     * The Size Indication, which shows the file size in the mode-line,
>>     should be gone too because for those who needs this feature, they
>>     don't need a menu.

Bury it under advanced.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs

[Stefan Monnier]

>> I agree that getting rid of the non-interactive search items in
>> Edit->Search would be a good simplification.
> I would suggest burying them deeper down in the menus instead.
> For advertising reasons it is still good to have them there.

I see no need to advertise them.  I'd rather improve isearch so that the
non-interactive search commands are never needed (AFAIK this is already
the case, but it seems you disagree).

>> Not sure about these.  They're not very useful maybe, but they do serve
>> the purpose of indicating what is the canonical keybinding for
>> those commands.
> For whom? I think new users will probably use C-End etc.

We recommend M-> and M-< because they are more likely to work under ttys.

>>>     * The “Case-Insensitive Search” should be moved to be together with
>>>     the interactive search menu under Edit.
>> 
>> This also sounds OK, except for the problem of making the behavior of
>> the "Save options" menu entry clear: currently this entry saves all the
>> options that appear above in the menu.  So if we move an entry to some
>> other menu, we get into some trouble.

> The "Save options" is in my opinion confusing. I think it would be
> better to ask for each option if it would be set permanently or just
> temporarily.

> This would be easier to understand and there would be no obstacle of
> this kind for moving them.

Could be.  But I wouldn't want to ask the question when the option is
chosen, only when "Save options" is selected.

>>>     * The Scroll-bar and Fringe menu items should be gone.  Scroll-bar is
>>>     a standard feature in all applications.  If a power user wants it
>>>     off, he can do so thru the customization menu.  The Fringe adjustment
>>>     is again for tweakers.  It adds distraction.
>> Those entries mostly play the role of advertisement.
> Maybe bury them under "Show/Hide - Advanced - Scroll-bar" etc?

The show/hide submenu is very large, so the benefit seems dubious.

>>>     * The Time, Battery, are of little use. Their functionality are
>>>     provided by the OS's tool bar. Again, for geeks who need it, it is
>>>     easy to call the command by “M-x”.
>> I'd tend to agree.  But I also do not remember why they were added, so
>> maybe there's just something I'm missing.
> Bury it under advanced as above.

Maybe if/when more stuff gets added to show/hide.


        Stefan

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 05:53:25 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
> 
> The "Save options" is in my opinion confusing.

I don't see how it can be.  Many other GUI programs have a similar
feature, and I didn't find it confusing at all.

> I think it would be better to ask for each option if it would be set
> permanently or just temporarily.

That'd be a major annoyance, I think.

> Maybe bury them under "Show/Hide - Advanced - Scroll-bar" etc?
> 
> 
> >>     * The Time, Battery, are of little use. Their functionality are
> >>     provided by the OS's tool bar. Again, for geeks who need it, it is
> >>     easy to call the command by “M-x”.
> >
> > I'd tend to agree.  But I also do not remember why they were added, so
> > maybe there's just something I'm missing.
> 
> Bury it under advanced as above.
> 
> 
> >>     * The Size Indication, which shows the file size in the mode-line,
> >>     should be gone too because for those who needs this feature, they
> >>     don't need a menu.
> 
> Bury it under advanced.

Please, let's not go the way of all the silly programs that put
everything interesting under "Advanced"!

In a good UI, each feature should be put under a group whose name
gives a hint that the feature could be reasonably looked up in that
group.  Having group names such as "Advanced" or "More options", that
have no mnemonic value, is abusing the menus, which are supposed to
make the job of finding a feature _easier_, not harder.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 7:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 9 Aug 2009 05:53:25 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
>>
>> The "Save options" is in my opinion confusing.
>
> I don't see how it can be.  Many other GUI programs have a similar
> feature, and I didn't find it confusing at all.

They do? It does not at all seem common to me, but maybe I have just
missed it. I just looked in Firefox and OpenOffice.org and I can't see
anything similar.


>> I think it would be better to ask for each option if it would be set
>> permanently or just temporarily.
>
> That'd be a major annoyance, I think.

Exactly why?

I think the current "Save Options" is hard to understand. For me it is
nothing I recognize from other program GUIs. How do you know which
options it will save? Is it only those visible in the menu at the
moment you call the function? Or does it include options further down
in the menus? (I don't know actually.) What happens if you call it
from the command line?

I suggest removing it or replacing it with customize-customze which is
more consistent. Or maybe a version of that just lists which variables
to save.


>> Maybe bury them under "Show/Hide - Advanced - Scroll-bar" etc?
>>
>>
>> >>     * The Time, Battery, are of little use. Their functionality are
>> >>     provided by the OS's tool bar. Again, for geeks who need it, it is
>> >>     easy to call the command by “M-x”.
>> >
>> > I'd tend to agree.  But I also do not remember why they were added, so
>> > maybe there's just something I'm missing.
>>
>> Bury it under advanced as above.
>>
>>
>> >>     * The Size Indication, which shows the file size in the mode-line,
>> >>     should be gone too because for those who needs this feature, they
>> >>     don't need a menu.
>>
>> Bury it under advanced.
>
> Please, let's not go the way of all the silly programs that put
> everything interesting under "Advanced"!

Are you misunderstanding what I suggested? I did not suggest a single
"Advanced". I suggested that as a subgroup/submenu.

I think that is a very good and common practice. It gives a good
structure while at the same time it does not burden those that does
not need to see the advanced options. Still they have an easy chance
to find out they are there.

In what way do you find this silly?


> In a good UI, each feature should be put under a group whose name
> gives a hint that the feature could be reasonably looked up in that
> group.  Having group names such as "Advanced" or "More options", that
> have no mnemonic value, is abusing the menus, which are supposed to
> make the job of finding a feature _easier_, not harder.

Please see above. I think you are misunderstanding.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 19:56:06 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
> 
> On Sun, Aug 9, 2009 at 7:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >> Date: Sun, 9 Aug 2009 05:53:25 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
> >>
> >> The "Save options" is in my opinion confusing.
> >
> > I don't see how it can be.  Many other GUI programs have a similar
> > feature, and I didn't find it confusing at all.
> 
> They do? It does not at all seem common to me, but maybe I have just
> missed it. I just looked in Firefox and OpenOffice.org and I can't see
> anything similar.

Try harder.

> >> I think it would be better to ask for each option if it would be set
> >> permanently or just temporarily.
> >
> > That'd be a major annoyance, I think.
> 
> Exactly why?

Because I don't like to be annoyed with interactive prompts too much,
they get in the way of fast typing.

> Are you misunderstanding what I suggested?

No, I understand you very well.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:02 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 9 Aug 2009 19:56:06 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
>>
>> On Sun, Aug 9, 2009 at 7:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> >> Date: Sun, 9 Aug 2009 05:53:25 +0200
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
>> >>
>> >> The "Save options" is in my opinion confusing.
>> >
>> > I don't see how it can be.  Many other GUI programs have a similar
>> > feature, and I didn't find it confusing at all.
>>
>> They do? It does not at all seem common to me, but maybe I have just
>> missed it. I just looked in Firefox and OpenOffice.org and I can't see
>> anything similar.
>
> Try harder.


You got me. I simply must be missing it. Exactly where in the Firefox
menus is it??


>> >> I think it would be better to ask for each option if it would be set
>> >> permanently or just temporarily.
>> >
>> > That'd be a major annoyance, I think.
>>
>> Exactly why?
>
> Because I don't like to be annoyed with interactive prompts too much,
> they get in the way of fast typing.


How can fast typing interfere with setting an option in the menus?

(Well it can, or could at least before. If you opened the menu and
made your choice too fast then nearly anything could happen. But I do
not know if that is still buggy because I used my patched version to
avoid that. BTW Firefox still has a rather similar bug.)



>> Are you misunderstanding what I suggested?
>
> No, I understand you very well.


So you are saying that subgroups are bad because they do not give you
enough structure?

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 20:10:41 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
> 
> So you are saying that subgroups are bad because they do not give you
> enough structure?

I'm saying that subgroups called "advanced" are bad.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:15 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 9 Aug 2009 20:10:41 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
>>
>> So you are saying that subgroups are bad because they do not give you
>> enough structure?
>
> I'm saying that subgroups called "advanced" are bad.

You said

  In a good UI, each feature should be put under a group whose name
  gives a hint that the feature could be reasonably looked up in that
  group.  Having group names such as "Advanced" or "More options", that
  have no mnemonic value, is abusing the menus, which are supposed to
  make the job of finding a feature _easier_, not harder.

Maybe the name "Advanced" is bad but we were talking about the
structure of the menus. Making a subgroup named "Advanced" is not bad
IMO since it is a subgroup with a context.

Rather, within that context it may be a very good mnemonic.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 20:21:46 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > I'm saying that subgroups called "advanced" are bad.
> 
> You said
> 
>   In a good UI, each feature should be put under a group whose name
>   gives a hint that the feature could be reasonably looked up in that
>   group.  Having group names such as "Advanced" or "More options", that
>   have no mnemonic value, is abusing the menus, which are supposed to
>   make the job of finding a feature _easier_, not harder.

Yes, and that goes for subgroups as well.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:51 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 9 Aug 2009 20:21:46 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> > I'm saying that subgroups called "advanced" are bad.
>>
>> You said
>>
>>   In a good UI, each feature should be put under a group whose name
>>   gives a hint that the feature could be reasonably looked up in that
>>   group.  Having group names such as "Advanced" or "More options", that
>>   have no mnemonic value, is abusing the menus, which are supposed to
>>   make the job of finding a feature _easier_, not harder.
>
> Yes, and that goes for subgroups as well.


And the reason? You can hardly avoid seeing the contexts in the menus.
It is actually one of the main thing in a cascading menu.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 20:54:11 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On Sun, Aug 9, 2009 at 8:51 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >> Date: Sun, 9 Aug 2009 20:21:46 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >>
> >> > I'm saying that subgroups called "advanced" are bad.
> >>
> >> You said
> >>
> >>   In a good UI, each feature should be put under a group whose name
> >>   gives a hint that the feature could be reasonably looked up in that
> >>   group.  Having group names such as "Advanced" or "More options", that
> >>   have no mnemonic value, is abusing the menus, which are supposed to
> >>   make the job of finding a feature _easier_, not harder.
> >
> > Yes, and that goes for subgroups as well.
> 
> 
> And the reason?

But you just quoted me explaining that, see above!

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 20:10:41 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On Sun, Aug 9, 2009 at 8:02 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >> Date: Sun, 9 Aug 2009 19:56:06 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
> >>
> >> On Sun, Aug 9, 2009 at 7:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >> >> Date: Sun, 9 Aug 2009 05:53:25 +0200
> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> >> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
> >> >>
> >> >> The "Save options" is in my opinion confusing.
> >> >
> >> > I don't see how it can be.  Many other GUI programs have a similar
> >> > feature, and I didn't find it confusing at all.
> >>
> >> They do? It does not at all seem common to me, but maybe I have just
> >> missed it. I just looked in Firefox and OpenOffice.org and I can't see
> >> anything similar.
> >
> > Try harder.
> 
> 
> You got me. I simply must be missing it. Exactly where in the Firefox
> menus is it??

Hint: what are all those "Apply" buttons you click to make the
selected options permanent?

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:55 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 9 Aug 2009 20:10:41 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> On Sun, Aug 9, 2009 at 8:02 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> >> Date: Sun, 9 Aug 2009 19:56:06 +0200
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Cc: monnier@iro.umontreal.ca, xah@xahlee.org, emacs-devel@gnu.org
>> >>
>> >> On Sun, Aug 9, 2009 at 7:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> >> >> Date: Sun, 9 Aug 2009 05:53:25 +0200
>> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> >> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
>> >> >>
>> >> >> The "Save options" is in my opinion confusing.
>> >> >
>> >> > I don't see how it can be.  Many other GUI programs have a similar
>> >> > feature, and I didn't find it confusing at all.
>> >>
>> >> They do? It does not at all seem common to me, but maybe I have just
>> >> missed it. I just looked in Firefox and OpenOffice.org and I can't see
>> >> anything similar.
>> >
>> > Try harder.
>>
>>
>> You got me. I simply must be missing it. Exactly where in the Firefox
>> menus is it??
>
> Hint: what are all those "Apply" buttons you click to make the
> selected options permanent?


They are very different. You do not find them in the menus. They are
more like our save/set buttons in customize buffers.

Most often I believe program does not make the distinction between
saved and set options as Emacs does. I looked for example at Firebug
in Firefox menu. There you just toggle options permanently by clicking
them in the menu.

However if Apply buttons was what you were thinking of then why not
have a customize-save-customized entry instead in the options menu?
This would be much better than the current "Save Options" in my
opinion.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

BTW, there are many things that could be in the menus. For example I
just had to use the tag commands to find my way in the Emacs sources.
I use them very seldom so I always forget them and have to look them
up again.

It is quite a bit irritating that they are not in the menus. I would
suggest putting them under goto. Just make a submenu

   Edit / Go to / Tags

and put all the commands in (info "(emacs) Find Tag") there.

Such things would be very helpful. The reason to not put them there
has been arguments like "it is too much" and "it is too deep".

These arguments are much weaker than the advertising/finding argument
in favor of having them there. (Do I have to say more about that? Just
imaging asking a new user for example. Or someone like me that does a
bit here and a bit there and forgets in between.)

Re: Fiddling with the menus

[Jason Rumney]

Lennart Borgman wrote:
> BTW, there are many things that could be in the menus. For example I
> just had to use the tag commands to find my way in the Emacs sources.
> I use them very seldom so I always forget them and have to look them
> up again.
>
> It is quite a bit irritating that they are not in the menus. I would
> suggest putting them under goto. Just make a submenu
>
>    Edit / Go to / Tags

How about not making submenus three levels deep and putting them 
directly under Edit / Go To where they already are?

> e more appropriate under Edit / Search ;-)
>   

Re: Fiddling with the menus

[Lennart Borgman]

On Mon, Aug 10, 2009 at 1:00 AM, Jason Rumney<jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> BTW, there are many things that could be in the menus. For example I
>> just had to use the tag commands to find my way in the Emacs sources.
>> I use them very seldom so I always forget them and have to look them
>> up again.
>>
>> It is quite a bit irritating that they are not in the menus. I would
>> suggest putting them under goto. Just make a submenu
>>
>>   Edit / Go to / Tags
>
> How about not making submenus three levels deep and putting them directly
> under Edit / Go To where they already are?

Just because Edit / Go To gets very long and I expect more things ot
be added there. CEDET has something to say I believe... ;-)


>> e more appropriate under Edit / Search ;-)

Maybe. I am not sure how a user sees it. Where s?he most easily finds it.

Re: Fiddling with the menus

[Jason Rumney]

Lennart Borgman wrote:
> On Mon, Aug 10, 2009 at 1:00 AM, Jason Rumney<jasonr@gnu.org> wrote:
>   
>> Lennart Borgman wrote:
>>     
>>> BTW, there are many things that could be in the menus. For example I
>>> just had to use the tag commands to find my way in the Emacs sources.
>>> I use them very seldom so I always forget them and have to look them
>>> up again.
>>>
>>> It is quite a bit irritating that they are not in the menus. I would
>>> suggest putting them under goto. Just make a submenu
>>>
>>>   Edit / Go to / Tags
>>>       
>> How about not making submenus three levels deep and putting them directly
>> under Edit / Go To where they already are?
>>     
>
> Just because Edit / Go To gets very long and I expect more things ot
> be added there. CEDET has something to say I believe... ;-)
>
>
>   
>>> e more appropriate under Edit / Search ;-)
>>>       

Err, that was left in by mistake. I originally thought the Tag commands 
were in Search, but they are in Go To (there are commands to search the 
tagged files in search, but that actually does a search, in case you 
have not updated the TAGS file recently I guess).

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Stephen J. Turnbull]

Lennart Borgman writes:

 > It is quite a bit irritating that they are not in the menus. I would
 > suggest putting them under goto. Just make a submenu
 > 
 >    Edit / Go to / Tags
 > 
 > and put all the commands in (info "(emacs) Find Tag") there.

XEmacs puts Tags under Tools (you can do more with them than just go
to) at the top level.

 > Such things would be very helpful. The reason to not put them there
 > has been arguments like "it is too much" and "it is too deep".

How about, "it can be damn slow"?  XEmacs does have fairly deep and
quite redundant menus, and I like them because of the discoverability.
But constructing the menus does take quite a bit of time because they
live in the files that they pertain to, which have to be loaded.

That's not a reason to avoid them completely (eg, it could be done at
build time using an automenu tool similar to auto-autoloads), but it
is definitely a consideration if you want to implement deep
discoverable menus.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 22:36:42 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: xah@xahlee.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> BTW, there are many things that could be in the menus. For example I
> just had to use the tag commands to find my way in the Emacs sources.
> I use them very seldom so I always forget them and have to look them
> up again.
> 
> It is quite a bit irritating that they are not in the menus. I would
> suggest putting them under goto. Just make a submenu
> 
>    Edit / Go to / Tags
> 
> and put all the commands in (info "(emacs) Find Tag") there.

??? Are you looking at Emacs 23 or at some other version?  In Emacs
23, we have in "Edit->Go To" submenu "Find Tag", "Find Tag in Other
Window", "Find Next Tag", "Next Tag in Other Window", "Tags Apropos",
and "Set Tags File Name".

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Lennart Borgman]

On Mon, Aug 10, 2009 at 5:03 AM, Eli Zaretskii<eliz@gnu.org> wrote:

>> BTW, there are many things that could be in the menus. For example I
>> just had to use the tag commands to find my way in the Emacs sources.
>> I use them very seldom so I always forget them and have to look them
>> up again.
>>
>> It is quite a bit irritating that they are not in the menus. I would
>> suggest putting them under goto. Just make a submenu
>>
>>    Edit / Go to / Tags
>>
>> and put all the commands in (info "(emacs) Find Tag") there.
>
> ??? Are you looking at Emacs 23 or at some other version?  In Emacs
> 23, we have in "Edit->Go To" submenu "Find Tag", "Find Tag in Other
> Window", "Find Next Tag", "Next Tag in Other Window", "Tags Apropos",
> and "Set Tags File Name".


I mean there are some more that are missing. You are right there are
many, but for example M-* is something I find useful. And some of the
other missing too.

I really can't understand what the reason was to not put them in the
menu when they are important enough to have key bindings.

Re: Fiddling with the menus

[Stefan Monnier]

>> >> I think it would be better to ask for each option if it would be set
>> >> permanently or just temporarily.
>> > That'd be a major annoyance, I think.
>> Exactly why?
> Because I don't like to be annoyed with interactive prompts too much,
> they get in the way of fast typing.

Obviously asking via repeated prompts would be annoying.  But maybe
showing the list of options modified in a buffer where you can then
click "save" either for all of them, or for each individual one would
seem to make it sufficiently non-painful and a lot more clear.


        Stefan

Re: Fiddling with the menus

[Lennart Borgman]

On Mon, Aug 10, 2009 at 4:27 AM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>>> >> I think it would be better to ask for each option if it would be set
>>> >> permanently or just temporarily.
>>> > That'd be a major annoyance, I think.
>>> Exactly why?
>> Because I don't like to be annoyed with interactive prompts too much,
>> they get in the way of fast typing.
>
> Obviously asking via repeated prompts would be annoying.  But maybe
> showing the list of options modified in a buffer where you can then
> click "save" either for all of them, or for each individual one would
> seem to make it sufficiently non-painful and a lot more clear.

Maybe give the user a choice between customize-customized and
customize-save-customized?

(And the latter should check if there is something to save which it
does not do now.)

Re: Fiddling with the menus

[Stefan Monnier]

[ Sorry, hit C-c C-c before it was time.  Here's the rest of the list. ]

> Emacs 22's Tool menu.

> The menu items for rmail and gnus do not work out of the box, because
> these features need operating system's support and setup that requires
> some sys admin expertise.

Agreed.  The way to fix it is to make M-x rmail and/or M-x gnus run some
kind of "wizard" to configure them.

> Today, vast majority of people use web based email services, even
> among professional programers.  Also, unlike the situation of the
> 1980s and 1990s, where most programer's “workstation” machines running
> unix are setup to run sendmail services. Today, even linux users, most
> are probably not setup to run sendmail.  Microsoft Windows, today used
> by ~95% of personal computer users world wide, does not come with
> “sendmail”.  Mac OS X uses PostFix as its MTA and is not enabled
> by default.

By "sendmail", this menu entry means sendmail.el which uses
the "sendmail" command provided by most/all MTAs, including Postfix.
Sadly, this command is commonly non-functional, so here again,
sendmail.el should run some kind of wizard to make sure that sending
email is properly configured.

> It is questionable, that the gnus and rmail should have a menu item.

These are important packages that deserve to have a visible entry point.

> For those programers who might want to use these and have the
> expertise to set it up, they can most certainly find out about these
> features online or in the Emacs documentation.  For the Emacs
> die-hards accustomized to using rmail or gnus, they never actually
> pull these menus to invoke the commands.  They simply type “M-x rmail”
> or “M-x gnus”.

Not necessarily: they may temporarily be using Emacs without access to
a keyboard.

> The game items seem a bit silly.

Maybe, but it costs just one entry.

> For Emacs to showoff a game, it should at least show a outstanding
> implementation, or some game that has merits to stands itself.  (A
> typing game implemented in elisp would be suitable, or a Emacs
> interface to GNU Go, GNU Chess,

Agreed, these would be good.

> or music player.)

Not exactly a game.

> Emacs's help menu. Extremely confusing and chaotic.

> In the Emacs's help menu, there are about 30 items. With this many
> items, they are more confusing than helpful.  Many of these are
> outdated, redundant, never used, or FSF propaganda.  The following are
> some explanation.

The Emacs maintainers consider FSF propaganda to be important.

> The content of “Emacs FAQ”, “Emacs News”, “Emacs Known Problems”, are
> about 5 or 10 years out of date.

If Emacs News is out of date, it's a bug.

The "known problems" indeed tend to be very out of date, tho not all of
them are.  We should probably split this file into sections for problems
which have been reported for specific releases (with a note that
problems in older releases may still be relevant).

The FAQ's maintenance has always been a bit problematic, indeed.  I'd be
happy to drop it.

> Similarly, the “External Packages” is hopelessly outdated.  For this,
> the emacswiki (emacswiki.org) provides far more useful resource.

We could link to some web page on www.gnu.org.  But we need someone to
keep it up-to-date.  Maybe along with ELPA.

> The “Find Emacs Packages” item has rather confusing name. After using
> Emacs 8 hours a day for 10 years, i pulled it today for the first
> time, and realized it is a keyword based search on bundled elisp
> packages. Looking at the result, it does not seems very useful. For
> example, clicking on OOP shows a bunch of modes that really have
> little to do with Object Oriented Programing. Perhaps it should go
> into the “Search Documentation” sub-menu.

This command needs a lot of work to make it useful, I find.

> The “Emacs Psychotherapist” is the forefront of AI research in the
> 1960s. (It is a implementation of ELIZA) Having it in 1980s is way
> cool. Having it in 1990s in a text editor is a novelty. Today, as
> a demo of elisp power or as a fun program, it's rather stupid.

I'd call it silly, and silliness is a quality.

> The “Getting New Versions”, “Copying Condition”, “(Non)Warranty” are
> all redundant.

I don't see how they're redundant.  But yes, “Getting New Versions”
sounds old.  It should probably link to www.gnu.org/software/emacs.

> In today's web info world, it's silly that a Emacs
> users would pull a menu to know where to get new versions.  A modern
> replacement should be “Check Update” that tells user if his Emacs is
> up to date, or better, automatically upgrade Emacs as a option.
> Such a feature is common in all modern apps.

Under GNU/Linux this doesn't belong in the application but in the
distribution, and indeed it works just fine for Emacs just like it works
for all other applications.
For other platforms, we could imagine better support for installers and
semi-automatic update, but not until someone writes them.

> The “Copying Condition” and “(Non)Warranty” are part of the licensing
> and user agreement.  No app today has it as a menu item.  All 3 items,
> are linked in the “About Emacs” menu item's doc, and that is
> sufficient and appropriate.

Oh, that's what you meant by redundant, then I think I agree.

> The “About GNU” is Richard Stallman's FSF propaganda.  Its inclusion
> in Emacs's Help menu is more about politics than as a helpful resource
> for the Emacs software.  The Emacs manual has FSF propaganda littered
> throughout already.  This menu item burdens the Help menu with another
> non-helpful item.  Again, “About Emacs” has a link to it already.

Politics matter.

> The items in “More Manuals” sub-menu, can all be gone except the “All
> Other Manuals (Info)” and the the “Lookup Subject in all manuals...”
> (info-apropos).  The “All Other Manuals (Info)” should be moved to the
> top, and serve as the one entry point for all manuals, and the
> info-apropos menu item can move to the “Search Documentation”
> sub menu.

That sounds OK.


        Stefan

Re: Fiddling with the menus

[CHENG Gao]

*On Sun, 09 Aug 2009 01:05:35 -0400
* Also sprach Stefan Monnier <monnier@iro.umontreal.ca>:


>> The content of “Emacs FAQ”, “Emacs News”, “Emacs Known Problems”, are
>> about 5 or 10 years out of date.
>
> If Emacs News is out of date, it's a bug.
>
> The "known problems" indeed tend to be very out of date, tho not all of
> them are.  We should probably split this file into sections for problems
> which have been reported for specific releases (with a note that
> problems in older releases may still be relevant).
>
> The FAQ's maintenance has always been a bit problematic, indeed.  I'd be
> happy to drop it.

I think "Emacs Known Problems" should only show outstanding problems in
CURRENT emacs. I am not sure, but I guess some problems have already
been solved (in my Emacs built from Emacs git source). Problems for old
releases should be archived in seperate files (like PROBLEMS-20, PROBLEMS-21).

And some problems are caused by third party packages (for example VM).
It could be put into another file.

My understand is "Emacs Known Problems" is for problems related to
current Emacs and its bundled packages.


>> Similarly, the “External Packages” is hopelessly outdated.  For this,
>> the emacswiki (emacswiki.org) provides far more useful resource.
>
> We could link to some web page on www.gnu.org.  But we need someone to
> keep it up-to-date.  Maybe along with ELPA.

I think a page on www.gnu.org or emacswiki.org  can not solve this
problem. It could be even worse. Updating a webpage or wiki page does
not mean less work than a patch to MORE.STUFF. On the contrary it could
mean more work.

>
>> The “Getting New Versions”, “Copying Condition”, “(Non)Warranty” are
>> all redundant.
>
> I don't see how they're redundant.  But yes, “Getting New Versions”
> sounds old.  It should probably link to www.gnu.org/software/emacs.
>
>> In today's web info world, it's silly that a Emacs
>> users would pull a menu to know where to get new versions.  A modern
>> replacement should be “Check Update” that tells user if his Emacs is
>> up to date, or better, automatically upgrade Emacs as a option.
>> Such a feature is common in all modern apps.
>
> Under GNU/Linux this doesn't belong in the application but in the
> distribution, and indeed it works just fine for Emacs just like it works
> for all other applications.
> For other platforms, we could imagine better support for installers and
> semi-automatic update, but not until someone writes them.

A link to distribution page is enough. This feature is too platform
specific. GNU/Linux systems have package manageement system to do this.
Even MacOS has package management system like Macports, Fink or Rudix
to do this. Maybe it's useful for Windows, since there is official
distribution for Windows.

Emacs website can supply some kind of API to let Emacs to grab the
latest version. It need not be real API.

From Emacs site you can read 
,----
| Releases
| The current stable release is 23.1. To obtain it, visit the obtaining section.
`----

Someone could write an interactive function to parse
http://www.gnu.org/software/emacs/ to get it. Emacs page could be
revised to be a little parser friendly to use a special tag or comment.

Say from Emacs website page source:

,----
| <h3 id="Releases">Releases</h3>
| 
| <p><b>The current stable release is 23.1</b>.  To obtain it, visit
| the <a href="#Obtaining">obtaining</a> section.</p>
`----

It could be changed to:

,----
| <h3 id="Releases">Releases</h3>
| 
| <p><b>The current stable release is 23.1</b><!--Latest:23.1-->.  To
| obtain it, visit the <a href="#Obtaining">obtaining</a> section.</p>
`----

Parsing function can grab <!--Latest:23.1--> to get the version number.
It can then do comparison and ask users to go to distribution page to
download or shout to some maintainers (for their platforms) to update
the package.



>> The items in “More Manuals” sub-menu, can all be gone except the “All
>> Other Manuals (Info)” and the the “Lookup Subject in all manuals...”
>> (info-apropos).  The “All Other Manuals (Info)” should be moved to the
>> top, and serve as the one entry point for all manuals, and the
>> info-apropos menu item can move to the “Search Documentation”
>> sub menu.
>
> That sounds OK.

How about change "All other Manuals" to "All Manuals (C-h i)"? I think
many users (if not most) will start here. It even deserves as the first
item under Help menu.

And info-apropos could be put some place here: 
,----
|   The Info Directory is the top-level menu of major Info topics.
|   Type "d" in Info to return to the Info Directory.  Type "q" to exit Info.
|   Type "?" for a list of Info commands, or "h" to visit an Info tutorial.
|   Type "m" to choose a menu item--for instance,
|     "mEmacs<Return>" visits the Emacs manual.
|   In Emacs Info, you can click mouse button 2 on a menu item
|   or cross reference to follow it to its target.
|   Each menu line that starts with a * is a topic you can select with "m".
|   Every third topic has a red * to help pick the right number to type.
`----

Personally I suggest to put Emacs coding standards to a seperate file
and a first level item under Help menu. It's a good propoganda.
And I think elispinto and elispref deserve the first level item under
Help menu.


-- 
Numquam minus solus quam cum solus

Re: Fiddling with the menus

[Eli Zaretskii]

> From: CHENG Gao <chenggao@gmail.com>
> Date: Sun, 09 Aug 2009 17:51:27 +0800
> 
> I think "Emacs Known Problems" should only show outstanding problems in
> CURRENT emacs.

Would you like to volunteer to maintain etc/PROBLEMS along these
lines?  Mind you, the task is not as easy as it maybe sounds, because
knowing just which problems are solved and which are not is quite
hard, especially if the problem is about an OS you don't use and don't
have access to.

Let's take a random entry:

    ** Emacs crashes when you use Bibtex mode.

    This happens if your system puts a small limit on stack size.  You can
    prevent the problem by using a suitable shell command (often `ulimit')
    to raise the stack size limit before you run Emacs.

How to know if this still happens? the entry doesn't even say on which
system it was spotted.

> And some problems are caused by third party packages (for example VM).
> It could be put into another file.

I don't think this is a good idea.  Someone looking for his/her
problem shouldn't need to scan numerous files.

> My understand is "Emacs Known Problems" is for problems related to
> current Emacs and its bundled packages.

Yes, but Emacs could have problems caused by third-party packages as
well.  We don't want to omit the information about that, if it can
help.  For example:

    *** Emacs says it has saved a file, but the file does not actually
    appear on disk.

    This can happen on certain systems when you are using NFS, if the
    remote disk is full.  It is due to a bug in NFS (or certain NFS
    implementations), and there is apparently nothing Emacs can do to
    detect the problem.  Emacs checks the failure codes of all the system
    calls involved in writing a file, including `close'; but in the case
    where the problem occurs, none of those system calls fails.

Sounds useful, doesn't it?

Re: Fiddling with the menus

[CHENG Gao]

*On Sun, 09 Aug 2009 20:38:54 +0300
* Also sprach Eli Zaretskii <eliz@gnu.org>:

>> From: CHENG Gao <chenggao@gmail.com>
>> Date: Sun, 09 Aug 2009 17:51:27 +0800
>> 
>> I think "Emacs Known Problems" should only show outstanding problems in
>> CURRENT emacs.
>
> Would you like to volunteer to maintain etc/PROBLEMS along these
> lines?  Mind you, the task is not as easy as it maybe sounds, because
> knowing just which problems are solved and which are not is quite
> hard, especially if the problem is about an OS you don't use and don't
> have access to.

Really scared. PROBLEMS is very big, near 3900 lines. 
Yes you are right. It's very hard to clarify which is solved and which
is  not.  Feedbacks from many users are needed.

> Let's take a random entry:
>
>     ** Emacs crashes when you use Bibtex mode.
>
>     This happens if your system puts a small limit on stack size.  You can
>     prevent the problem by using a suitable shell command (often `ulimit')
>     to raise the stack size limit before you run Emacs.
>
> How to know if this still happens? the entry doesn't even say on which
> system it was spotted.
>
>> And some problems are caused by third party packages (for example VM).
>> It could be put into another file.
>
> I don't think this is a good idea.  Someone looking for his/her
> problem shouldn't need to scan numerous files.
>
>> My understand is "Emacs Known Problems" is for problems related to
>> current Emacs and its bundled packages.
>
> Yes, but Emacs could have problems caused by third-party packages as
> well.  We don't want to omit the information about that, if it can
> help.  For example:
>
>     *** Emacs says it has saved a file, but the file does not actually
>     appear on disk.
>
>     This can happen on certain systems when you are using NFS, if the
>     remote disk is full.  It is due to a bug in NFS (or certain NFS
>     implementations), and there is apparently nothing Emacs can do to
>     detect the problem.  Emacs checks the failure codes of all the system
>     calls involved in writing a file, including `close'; but in the case
>     where the problem occurs, none of those system calls fails.
>
> Sounds useful, doesn't it?

Lines 994-1022 talk about MULE-UCS compilation problem, and the very
first problem says:

,----
| * Mule-UCS doesn't work in Emacs 23.
| 
| It's completely redundant now, as far as we know.
`----

So for current release (23.1), the former seems weird.

And I trust some problems occur for platforms removed from current
release.

Maybe we just let it be. Anyway known problems could be solved soon or
put into TODO.

-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.

Re: Fiddling with the menus

[Eli Zaretskii]

> From: CHENG Gao <chenggao@gmail.com>
> Date: Mon, 10 Aug 2009 02:06:30 +0800
> 
> Lines 994-1022 talk about MULE-UCS compilation problem, and the very
> first problem says:
> 
> ,----
> | * Mule-UCS doesn't work in Emacs 23.
> | 
> | It's completely redundant now, as far as we know.
> `----
> 
> So for current release (23.1), the former seems weird.

Yes, those 2 entries should probably be united.

> And I trust some problems occur for platforms removed from current
> release.

I'm sure they are, the problem is to know which ones.

> Maybe we just let it be.

But if you spot any that can be removed or modified, please report
them.  TIA

Re: Fiddling with the menus

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:17 PM, Eli Zaretskii<eliz@gnu.org> wrote:

> But if you spot any that can be removed or modified, please report
> them.  TIA


Maybe the mantenance could be made easier today when we have bug
tracker. The bug numbers could be entered in etc/PROBLEMS. (Or is that
already used?)

Re: Fiddling with the menus

[Eli Zaretskii]

> Date: Sun, 9 Aug 2009 20:24:15 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: CHENG Gao <chenggao@gmail.com>, emacs-devel@gnu.org
> 
> On Sun, Aug 9, 2009 at 8:17 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> 
> > But if you spot any that can be removed or modified, please report
> > them.  TIA
> 
> 
> Maybe the mantenance could be made easier today when we have bug
> tracker. The bug numbers could be entered in etc/PROBLEMS.

Most entries in PROBLEMS should be about issues with software beyond
Emacs, or with misconfigured systems or software, or with incorrect
Emacs usage that many users tend to hit.  I don't think bug reports
will replace those.

Also, searching PROBLEMS is orders of magnitude easier and faster than
searching through the bug tracker database.

Re: Fiddling with the menus

[Lennart Borgman]

On Sun, Aug 9, 2009 at 8:54 PM, Eli Zaretskii<eliz@gnu.org> wrote:

>> Maybe the mantenance could be made easier today when we have bug
>> tracker. The bug numbers could be entered in etc/PROBLEMS.
>
> Most entries in PROBLEMS should be about issues with software beyond
> Emacs, or with misconfigured systems or software, or with incorrect
> Emacs usage that many users tend to hit.  I don't think bug reports
> will replace those.

No, but probably some of those problems will enter the bug database
and it might be easier to keep track of what is happening there. The
bug tracker is hopefully updated.

Re: Fiddling with the menus

[Jason Rumney]

Eli Zaretskii wrote:
> Most entries in PROBLEMS should be about issues with software beyond
> Emacs, or with misconfigured systems or software, or with incorrect
> Emacs usage that many users tend to hit.  I don't think bug reports
> will replace those.
>
> Also, searching PROBLEMS is orders of magnitude easier and faster than
> searching through the bug tracker database.
>   

Lennart wasn't saying that the bug tracker replaces PROBLEMS, just that 
it could make maintenance easier if entries in PROBLEMS were tagged with 
the bug# if there is a corresponding bug report. Then someone could go 
through PROBLEMS before a release and check if any of the bugs have been 
closed or had workarounds added to them.

Re: Fiddling with the menus

[Stefan Monnier]

> Really scared. PROBLEMS is very big, near 3900 lines. 
> Yes you are right. It's very hard to clarify which is solved and which
> is  not.  Feedbacks from many users are needed.

Right, which is why I suggested to separate by "problems reported".
I.e. you can try to scan the mailing list to see if a given problem was
reported for a given version.  That doesn't mean the other problems are
fixed, but at least there's no positive evidence it's not fixed.


        Stefan

Re: Fiddling with the menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 09 Aug 2009 01:05:35 -0400
> Cc: emacs-devel@gnu.org
> 
> > The game items seem a bit silly.
> 
> Maybe, but it costs just one entry.

Yes, and what's wrong with some humor and play, for a change?  Why
should Emacs be so dead serious?

> > The “Find Emacs Packages” item has rather confusing name. After using
> > Emacs 8 hours a day for 10 years, i pulled it today for the first
> > time

Shame on Xah.

> > Looking at the result, it does not seems very useful. For
> > example, clicking on OOP shows a bunch of modes that really have
> > little to do with Object Oriented Programing. Perhaps it should go
> > into the “Search Documentation” sub-menu.

There's nothing magic here: the keywords assigned to each package is a
human's job; Finder just puts all of them into a database and
trivially searches that.  Patches are welcome for adding more keywords
and (more importantly) to re-index existing packages so that the
search is more useful.

> > The “Emacs Psychotherapist” is the forefront of AI research in the
> > 1960s. (It is a implementation of ELIZA) Having it in 1980s is way
> > cool. Having it in 1990s in a text editor is a novelty. Today, as
> > a demo of elisp power or as a fun program, it's rather stupid.
> 
> I'd call it silly, and silliness is a quality.

Indeed.  It's entertainment, and sometimes it could make a difference
when you need to relax after a lot of work.  People who live inside
Emacs should not need to go out to look for entertainment.

> > The items in “More Manuals” sub-menu, can all be gone except the “All
> > Other Manuals (Info)” and the the “Lookup Subject in all manuals...”
> > (info-apropos).

On a typical GNU system, "All Other Manuals" will lead to a
humongously long list of available manuals.  Heck, even on my Windows
box there are over 50 items in that list!  So what's wrong with having
a few of them that are related to Emacs easily reachable without
having to wade through a long list?  Can you say "usability"?

Re: Fiddling with the menus

[Juri Linkov]

>> > Looking at the result, it does not seems very useful. For
>> > example, clicking on OOP shows a bunch of modes that really have
>> > little to do with Object Oriented Programing. Perhaps it should go
>> > into the “Search Documentation” sub-menu.
>
> There's nothing magic here: the keywords assigned to each package is a
> human's job; Finder just puts all of them into a database and
> trivially searches that.  Patches are welcome for adding more keywords
> and (more importantly) to re-index existing packages so that the
> search is more useful.

It is also important to remove some keywords.  You just said:

  In a good UI, each feature should be put under a group whose name
  gives a hint that the feature could be reasonably looked up in that
  group.  Having group names such as "Advanced" or "More options", that
  have no mnemonic value, is abusing the menus, which are supposed to
  make the job of finding a feature _easier_, not harder.

Exactly the same can be said about keywords.  There are keywords that
have no mnemonic value like "convenience", "extensions", "tools".
They should be removed with re-indexing existing packages.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Fiddling with the menus

[Stefan Monnier]

> Exactly the same can be said about keywords.  There are keywords that
> have no mnemonic value like "convenience", "extensions", "tools".
> They should be removed with re-indexing existing packages.

Oh yes, these have always struck me as meaningless indeed.


        Stefan

Re: Fiddling with the menus

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  xah@xahlee.org,  emacs-devel@gnu.org
> Date: Mon, 10 Aug 2009 02:14:23 +0300
> 
> It is also important to remove some keywords.  You just said:
> 
>   In a good UI, each feature should be put under a group whose name
>   gives a hint that the feature could be reasonably looked up in that
>   group.  Having group names such as "Advanced" or "More options", that
>   have no mnemonic value, is abusing the menus, which are supposed to
>   make the job of finding a feature _easier_, not harder.
> 
> Exactly the same can be said about keywords.  There are keywords that
> have no mnemonic value like "convenience", "extensions", "tools".
> They should be removed with re-indexing existing packages.

Yes, I agree.

Re: Fiddling with the menus

[Dan Nicolaescu]

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

  > [ Sorry, hit C-c C-c before it was time.  Here's the rest of the list. ]
  > 
  > > Emacs 22's Tool menu.

Here's some small suggestions for the Tools menu:

- move Debugger right after Compile ...
- move the version control entries before the spell checker

Re: Fiddling with the menus

[Lennart Borgman]

On Tue, Aug 11, 2009 at 7:06 AM, Dan Nicolaescu<dann@ics.uci.edu> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>  > [ Sorry, hit C-c C-c before it was time.  Here's the rest of the list. ]
>  >
>  > > Emacs 22's Tool menu.
>
> Here's some small suggestions for the Tools menu:
>
> - move Debugger right after Compile ...
> - move the version control entries before the spell checker

... and remove the grep entry. The advertising of grep style command
should be for lgrep/rgrep (and they should be in Edit/Search).
lgrep/rgrep mentions grep and their common command history. That is
enough for the advertising in a case like this I believe.

Should perhaps Spelling be moved to the Edit menu? It does not have
very much in common with Compile etc (but with Mail of course)?

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Florian Beck]

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

>> • Emacs's Menu Usability Problem
>>  http://xahlee.org/emacs/modernization_menu.html
>
> Some of them sound like good ideas.  Here's my take on it:

While I don't necessarily agree that emacs' popularity is held back by
to complicated menus, by all means do this.

However, menus are *also* used to explore features. So I would recommend
adding *more* commands to the menu at second or even third level (which
at the moment is shunned, because it's tedious for work, but it's great
for exploring features).

- How about introducing an easy way to add commands to the menu (maybe
  via key binding in the minibuffer)?
- How about an extra menu »New in Emacs 23«?
- How about making the toolbar useful by allowing the user to move menu
  items onto it?

-- 
Florian Beck

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> From: Florian Beck <abstraktion@t-online.de>
> Date: Sun, 09 Aug 2009 14:37:08 +0200
> Cc: Xah Lee <xah@xahlee.org>, emacs-devel@gnu.org
> 
> - How about an extra menu »New in Emacs 23«?

What's wrong with "Help->Emacs news"?

> - How about making the toolbar useful by allowing the user to move menu
>   items onto it?

Patches to add this are most welcome.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 08 Aug 2009 23:36:04 -0400
> Cc: emacs-devel@gnu.org
> 
> >     * The Time, Battery, are of little use. Their functionality are
> >     provided by the OS's tool bar. Again, for geeks who need it, it is
> >     easy to call the command by “M-x”.
> 
> I'd tend to agree.

These settings are already in a second-level menu, so how can they
possibly bother anyone?  Just because Xah doesn't see any use for
them, it doesn't mean others won't.  When I work on a laptop, I have
the Battery display on all the time, because Emacs lets me customize
that display in ways most OSes never will.  As for Time, why should I
move my eyes to the system's display, somewhere on the fringes of the
screen, just to know what time it is?

> But I also do not remember why they were added

Mainly to advertise these features.  Many users don't know Emacs has
them.

Re: Fiddling with the menus

[Richard Riley]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sat, 08 Aug 2009 23:36:04 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> >     * The Time, Battery, are of little use. Their functionality are
>> >     provided by the OS's tool bar. Again, for geeks who need it, it is
>> >     easy to call the command by “M-x”.
>> 
>> I'd tend to agree.
>
> These settings are already in a second-level menu, so how can they
> possibly bother anyone?  Just because Xah doesn't see any use for
> them, it doesn't mean others won't.  When I work on a laptop, I have

Then turn them on. Most people have a desktop clock already
configured. Seems obvious enough.

> the Battery display on all the time, because Emacs lets me customize
> that display in ways most OSes never will.  As for Time, why should I

Then turn it on for laptops. More specifically yours. Most of us have a
system battery monitor.

> move my eyes to the system's display, somewhere on the fringes of the
> screen, just to know what time it is?

And why should everyone else have their emacs modeline infested with
unnecessary stuff when they have the GUI properly configured.

>
>> But I also do not remember why they were added
>
> Mainly to advertise these features.  Many users don't know Emacs has
> them.

Poor excuse since there are millions of things emacs has which new users
won't know about. They were put there to appease a tiny minority I
suspect.

Re: Fiddling with the menus

[Eli Zaretskii]

> From: Richard Riley <rileyrgdev@googlemail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  xah@xahlee.org,  emacs-devel@gnu.org
> Date: Sun, 09 Aug 2009 20:05:51 +0200
> 
> > These settings are already in a second-level menu, so how can they
> > possibly bother anyone?  Just because Xah doesn't see any use for
> > them, it doesn't mean others won't.  When I work on a laptop, I have
> 
> Then turn them on. Most people have a desktop clock already
> configured. Seems obvious enough.
> 
> > the Battery display on all the time, because Emacs lets me customize
> > that display in ways most OSes never will.  As for Time, why should I
> 
> Then turn it on for laptops. More specifically yours. Most of us have a
> system battery monitor.
> 
> > move my eyes to the system's display, somewhere on the fringes of the
> > screen, just to know what time it is?
> 
> And why should everyone else have their emacs modeline infested with
> unnecessary stuff when they have the GUI properly configured.

Hey, we are not talking about turning them on!  We are talking about
whether they are important enough to be in the menu.  If someone
doesn't want their modeline infested, they are free not to turn them
on.  Puff! problem's gone.

Re: Fiddling with the menus

[Stefan Monnier]

>> >     * The Time, Battery, are of little use. Their functionality are
>> >     provided by the OS's tool bar. Again, for geeks who need it, it is
>> >     easy to call the command by “M-x”.
>> I'd tend to agree.
> These settings are already in a second-level menu, so how can they
> possibly bother anyone?

As long as that menu is small enough, it might be OK to keep it, but
that doesn't mean it's useful.

> When I work on a laptop, I have the Battery display on all the time,

Great.  I have global-reveal-mode ON all the time.  So by that same
argument we should make it available from the menu.

> because Emacs lets me customize that display in ways most OSes never
> will.

We're not talking about eliminating the battery display.  Only about
whether or not it should be present in the menu.

> As for Time, why should I move my eyes to the system's display,
> somewhere on the fringes of the screen, just to know what time it is?

Same argument.  You're arguing against the elimination of the feature,
but that's not what we're talking about.

>> But I also do not remember why they were added
> Mainly to advertise these features.  Many users don't know Emacs
> has them.

Are they sufficiently important to warrant advertisement?
Are people going to prefer Emacs over something else because it can
display the time and battery status?


        Stefan

Re: Fiddling with the menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: xah@xahlee.org,  emacs-devel@gnu.org
> Date: Sun, 09 Aug 2009 22:09:42 -0400
> 
> > When I work on a laptop, I have the Battery display on all the time,
> 
> Great.  I have global-reveal-mode ON all the time.  So by that same
> argument we should make it available from the menu.
> 
> > because Emacs lets me customize that display in ways most OSes never
> > will.
> 
> We're not talking about eliminating the battery display.  Only about
> whether or not it should be present in the menu.
> 
> > As for Time, why should I move my eyes to the system's display,
> > somewhere on the fringes of the screen, just to know what time it is?
> 
> Same argument.  You're arguing against the elimination of the feature,
> but that's not what we're talking about.

The argument was that they are "of little use".  I wanted to say that
I use them a lot.  If someone wants more than 2 opposite opinions,
let's have a poll.  Otherwise, let's stop wasting energy on such petty
issues.  We've been rearranging the menus time and again, since Emacs
21.1, and there's always someone else to come and say the menus are
not useful.

> >> But I also do not remember why they were added
> > Mainly to advertise these features.  Many users don't know Emacs
> > has them.
> 
> Are they sufficiently important to warrant advertisement?
> Are people going to prefer Emacs over something else because it can
> display the time and battery status?

I only know we put them there in Emacs 22.  At that time, there was a
consensus that this is a good thing.  Maybe we should let them be
there for a few more version before we decide that we were all on
drugs back then.

Re: Fiddling with the menus

[Juri Linkov]

>> The non-interactive search menus are for one-time use, and do not have
>> keyboard shortcuts. This operation method is extremely inefficient, and
>> probably is almost never used statistically. Since Emacs provides
>> interactive search features, both by menu as well as by keyboard
>> shortcut, it should replace these one-time find menu items
>
> I agree that getting rid of the non-interactive search items in
> Edit->Search would be a good simplification.

Then we could replace these items with "Search files" (grep)
and "Recursive grep" (rgrep) in Edit->Search.

>>     * The Goto beginning/ending of buffer is useless as a menu. Users
>>     can intuitively press the Page Up, Page Down keys, scroll the mouse,
>>     or “Ctrl+Home” and “Ctrl+End” to do the same thing.  All these
>>     methods are familiar to users because they are implemented in most
>>     apps across Windows, Mac, Linux.  For those using Emacs's “M-<” and
>>     “M->” shortcuts, they don't need the menu or the menu to
>>     remind them.
>
> Not sure about these.  They're not very useful maybe, but they do serve
> the purpose of indicating what is the canonical keybinding for
> those commands.

I think there are enough places in Emacs (tutorials, manuals) that
teach using M-< and M->.

>> Emacs 22's Options menu.
>>     * The “Active Region Highlighting” is on by default in Emacs
>>     23. This behavior is standard in all modern editors.  For old time
>>     Emacs users who want it off, they can be easily do so thru
>>     Customization menu or elisp code.
>
> Maybe this will make sense at some point, but just activating it by
> default in Emacs-23 required a fair bit of confrontation.  One of the
> conditions to turn it on was that it be as easy as possible to turn it
> back off, even in those cases where modifying the .emacs is not an
> option (e.g. using someone else's Emacs).

BTW, the Options menu should also contain an item to toggle
`delete-selection-mode' since there is much demand for it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Fiddling with the menus

[Lennart Borgman]

On Mon, Aug 10, 2009 at 1:09 AM, Juri Linkov<juri@jurta.org> wrote:
>> I agree that getting rid of the non-interactive search items in
>> Edit->Search would be a good simplification.
>
> Then we could replace these items with "Search files" (grep)
> and "Recursive grep" (rgrep) in Edit->Search.

One reason for keeping the "normal non-interactive search items" is
that this is what many new users are used to. Maybe place them one
sublevel down with an appropriate name?

Adding rgrep/lgrep would be very good.

I believe it also would be good to merge the "Search" and "Replace"
menus. For example there are elisp code for replacing grep matches.
Such functionality fits best right under rgrep/lgrep. The "Replace"
submenu is also very short.

Maybe adding more fucntionality to a new "Search and Replace" submenu
would make it long. However in my opinion it seems easier to find
things in such an organisation - even if we had to make more
sublevels. Finding/advertising is the important thing. (And again:
perhaps adding the menu items to M-x history...)


>> Maybe this will make sense at some point, but just activating it by
>> default in Emacs-23 required a fair bit of confrontation.  One of the
>> conditions to turn it on was that it be as easy as possible to turn it
>> back off, even in those cases where modifying the .emacs is not an
>> option (e.g. using someone else's Emacs).
>
> BTW, the Options menu should also contain an item to toggle
> `delete-selection-mode' since there is much demand for it.

Options / Confrontation Resolutions ...

RE: Fiddling with the menus

[Drew Adams]

Lennart> ... merge the "Search" and "Replace" menus

Jason> I originally thought the Tag commands were
     > in Search, but they are in Go To (there are
     > commands to search the tagged files in search,
     > but that actually does a search...

I don't really want to get into this thread. Been there, done that. I'll just
say (once more) what I do, FWIW.

I have a top-level Search menu - it's not under Edit.

On the Search menu, I have all of the search and replace stuff, as well as all
of the "goto" stuff. (The entries shown here with `>' are submenus.)

--------------------
Incremental Search >
Replace >
Grep...
Occurrences...
Tags >
Bookmarks >
Go To >
--------------------

The last one is just the vanilla Go To catchall. I didn't bother to do anything
with it, so it still duplicates the tags stuff - someday I'll remove the tags
stuff from Go To.

I do still have non-incremental search stuff on the Search menu also, but I
agree that it could go away. Here's how I present the non-incremental stuff:

------------------
String Forward...
       Backward...
Regexp Forward...
       Backward...
Word   Forward...
       Backward...
------------------
Repeat Forward
       Backward
------------------

The Incremental Search submenu looks similar, but without the Word and Repeat
items. (Yes, it could reasonably have Word items too.)

The Replace submenu looks like this:

----------------
Query String
      Regexp...
      Map...
      Tags... (again: M-,)
----------------
Global String...
       Regexp
----------------

The Tags submenu looks like this:

----------------------------
Find Tag...
Find Next Tag
----------------------------
Find Tag Regexp...
Search Tagged Files...
Continue Tags Search/Replace
----------------------------
Tags Apropos...
Set Tags File Name...
----------------------------

For buffers such as Dired, I have no Edit menu; just the Search menu.

[I also have Icicles submenus for the Search, Tags, and Bookmarks menus.]

Re: Fiddling with the menus

[Stefan Monnier]

> One reason for keeping the "normal non-interactive search items" is
> that this is what many new users are used to.  Maybe place them one
> sublevel down with an appropriate name?

Using Emacs without isearch would be ridiculous, so they'll have to
learn to use it.  And it's pretty easy to figure out how it works.
So I do not see it as a reason to put it in the menus.


        Stefan

bug#4043: 23.1; thanks for emacs 23!

[Richard Stallman]

    How about improving emacs?

The person who wrote to thank us for Emacs 23 already likes Emacs.
But he is running it on an operating system, MacOS, which does not
respect his freedom.  I suppose he does not recognize the problem in
this.

We do hope to improve Emacs, but improving Emacs will not
teach people to recognize and reject the evil in MacOS.
That is a separate job, and we need to do them both.

Re: Fiddling with the menus (was: bug#4043: 23.1; thanks for emacs 23!)

[Xah Lee]

[-- Attachment #1: Type: text/plain, Size: 7226 bytes --]

just wanted to chime in to say thanks for considering this.

I'm more inclined to agree with Stephan Monnier's message at the start of
the thread.

possibly adding a menu that lists most popular computer language modes for
people to switch to might be nice. Because that way user can have a glance
of what modes are supported, and when they open a empty file (say, code
copied from the web, which happens a lot in at least web dev), they can
switch to that mode thru the menu. One problem i find about calling the mode
name directly wiht M-x for new users is that the command name is not always
intuitive e.g. cperl-mode, nxml-mode, js2-mode etc.

Here're some personal code diddling with the menu. It's probably not useful
for implementation in source, only as a graft on ... maybe can be used as a
quick What It Looks Like thing.

 Xah

-----------------------------------------
;; file menu

(define-key global-map [menu-bar file open-file] '("Open file or folder" .
find-file))
(define-key global-map [menu-bar file kill-buffer] '("Close" .
close-current-buffer))
(define-key global-map [menu-bar file new-file] '("New" . new-empty-buffer))

(define-key global-map [menu-bar file dired] nil)
(define-key global-map [menu-bar file insert-file] nil)
(define-key global-map [menu-bar file make-frame-on-display] nil)

;; edit menu
(define-key global-map [menu-bar edit search search-forward] nil)
(define-key global-map [menu-bar edit search search-backward] nil)
(define-key global-map [menu-bar edit search re-search-forward] nil)
(define-key global-map [menu-bar edit search re-search-backward] nil)
(define-key global-map [menu-bar edit search repeat-search-fwd] nil)
(define-key global-map [menu-bar edit search repeat-search-back] nil)

(define-key global-map [menu-bar edit goto go-to-pos] nil)
(define-key global-map [menu-bar edit goto beg-of-buf] nil)
(define-key global-map [menu-bar edit goto end-of-buf] nil)

;; options menu
(define-key global-map [menu-bar options cua-mode] nil)
(define-key global-map [menu-bar options transient-mark-mode] nil)

(define-key global-map [menu-bar options blink-cursor-mode] nil)
(define-key global-map [menu-bar options debug-on-error] nil)
(define-key global-map [menu-bar options debug-on-quit] nil)

(define-key global-map [menu-bar options showhide showhide-tool-bar] nil)
(define-key global-map [menu-bar options showhide showhide-scroll-bar] nil)
(define-key global-map [menu-bar options showhide showhide-fringe] nil)

(define-key global-map [menu-bar options showhide mac-font-panel-mode] nil)
(define-key global-map [menu-bar options showhide showhide-battery] nil)
(define-key global-map [menu-bar options showhide showhide-date-time] nil)
(define-key global-map [menu-bar options showhide size-indication-mode] nil)

(define-key global-map (kbd "<S-down-mouse-1>") nil)

;; buffers menu
(define-key global-map [menu-bar buffer next-buffer] '("Next User Buffer" .
next-user-buffer))
(define-key global-map [menu-bar buffer previous-buffer] '("Previous User
Buffer" . previous-user-buffer))
(define-key global-map [menu-bar buffer next-emacs-buffer] '("Next Emacs
Buffer" . next-emacs-buffer))
(define-key global-map [menu-bar buffer previous-emacs-buffer] '("Previous
Emacs Buffer" . previous-emacs-buffer))

(define-key global-map [menu-bar buffer list-all-buffers] '("List All
Buffers" . ibuffer))

;; tools menu
(define-key global-map [menu-bar tools gnus] nil)
(define-key global-map [menu-bar tools rmail] nil)
(define-key global-map [menu-bar tools compose-mail] nil)
(define-key global-map [menu-bar tools games] nil)

;; obsolete, outdated contents. Much replaced by web.
(define-key global-map [menu-bar help-menu getting-new-versions] nil)
(define-key global-map [menu-bar help-menu describe-distribution] nil)

(define-key global-map [menu-bar help-menu external-packages] nil)
(define-key global-map [menu-bar help-menu more] nil)

(define-key global-map [menu-bar help-menu emacs-known-problems] nil)
(define-key global-map [menu-bar help-menu emacs-problems] nil)
(define-key global-map [menu-bar help-menu find-emacs-packages] nil)

;; outdated humor and tech
(define-key global-map [menu-bar help-menu eliza] nil) (define-key
global-map [menu-bar help-menu emacs-psychotherapist] nil)

;; antiquated tutorial. If it needs a tutorial, something is wrong with UI.
(define-key global-map [menu-bar help-menu emacs-tutorial] nil)
(define-key global-map [menu-bar help-menu emacs-tutorial-language-specific]
nil)
(define-key global-map [menu-bar help-menu emacs-faq] nil)
(define-key global-map [menu-bar help-menu search-documentation
emacs-terminology] nil)

;; remove some FSF philosophy. (already linked in About Emacs)
(define-key global-map [menu-bar help-menu about-gnu-project] nil)
(define-key global-map [menu-bar help-menu describe-copying] nil)
(define-key global-map [menu-bar help-menu describe-no-warranty] nil)
(define-key global-map [menu-bar help-menu more-manuals order-emacs-manuals]
nil)
(define-key global-map [menu-bar help-menu manuals order-emacs-manuals] nil)
(define-key global-map [menu-bar help-menu about-gnu-project] nil)


;; Create language modes menu
(define-key-after global-map [menu-bar file lang-modes] (cons "Language
Modes" (make-sparse-keymap "major modes")) 'kill-buffer )

(define-key global-map [menu-bar file lang-modes bash] '("Bash" . sh-mode))
(define-key global-map [menu-bar file lang-modes tcl] '("TCL" . tcl-mode))
(define-key global-map [menu-bar file lang-modes ruby] '("Ruby" .
ruby-mode))
(define-key global-map [menu-bar file lang-modes python] '("Python" .
python-mode))
(define-key global-map [menu-bar file lang-modes php] '("PHP" . php-mode))
(define-key global-map [menu-bar file lang-modes perl] '("Perl" .
cperl-mode))
(define-key global-map [menu-bar file lang-modes separator1] '("--"))
(define-key global-map [menu-bar file lang-modes haskell] '("Haskell" .
haskell-mode))
(define-key global-map [menu-bar file lang-modes ocaml] '("OCaml" .
tuareg-mode))
(define-key global-map [menu-bar file lang-modes elisp] '("Emacs Lisp" .
emacs-lisp-mode))
(define-key global-map [menu-bar file lang-modes separator2] '("--"))
(define-key global-map [menu-bar file lang-modes latex] '("LaTeX" .
latex-mode))
(define-key global-map [menu-bar file lang-modes js] '("Javascript" .
js2-mode))
(define-key global-map [menu-bar file lang-modes xml] '("XML (xml-mode)" .
xml-mode))
(define-key global-map [menu-bar file lang-modes nxml] '("XML (nxml-mode)" .
nxml-mode))
(define-key global-map [menu-bar file lang-modes html] '("HTML" .
html-mode))
(define-key global-map [menu-bar file lang-modes css] '("CSS" . css-mode))
(define-key global-map [menu-bar file lang-modes separator3] '("--"))
(define-key global-map [menu-bar file lang-modes java] '("Java" .
java-mode))
(define-key global-map [menu-bar file lang-modes c++] '("C++" . c++-mode))
(define-key global-map [menu-bar file lang-modes c] '("C" . c-mode))

;; TO DO:
;; • remove dividers
;; • move incremental search menus one level up.
;; • reorg the help menu and submenu.

 Xah

[-- Attachment #2: Type: text/html, Size: 8961 bytes --]