bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20.6 outline.el - separate menus should be one Outline menu.


From: Jari Aalto+mail.emacs
Subject: Re: 20.6 outline.el - separate menus should be one Outline menu.
Date: 09 Jan 2001 20:07:22 +0200
User-agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 (i386-*-windows98.1998)

* Tue 2001-01-09 Eli Zaretskii <address@hidden> mail.emacs
| On 9 Jan 2001, Jari Aalto+mail wrote:
| 
| >     When outline-minor-mode is turned on, it creates separate 
| >     menus 
| > 
| >         Headings Show Hide
| > 
| >     I think it shoudl behave line other minor modes, where each mode
| >     occupies only one distictive slot, under which it defines submenus.
| 
| Taking a single slot is not a universal convention in Emacs.  Other
| modes, such as Dired and RMAIL, take several slots.

I would find it good to make it a standard convention unless there is
strong reason to do otherwise. From mail buffer this is undertandable
(Gnus et all), but for a common editing buffer it would be better if
files sticked with one menu per mode.

It is a trivial change to make outline to use one menu. That would also
improve usability, because all related item to outline are collected in
under same place.

It is standard GUI practise whcih is comonly used by some software
companies, if that matters anything.

| >     I suggest using shorter name "Out" to leave room for other members
| >     in the menubar.
| 
| In Emacs 21, the standard menu bar is much shorter, so I don't think
| there's a need for such extreme actions.

The length of the menu name matters. I was told by Gerd that it is not
possible to make menubar to occupy permanently 2 or user configurable
number of rows in (NT?) Emacs.

I find it extremely distracting and disturbing that when I switch
two windows, the window resizes itself because he other buffer
has "less" menus than the other buffer. This causes constant eye-drain 
when the swiths is frequesmt.

This is really a great inconvenience while using Gnus currently
(the constat meny bar line count change as menu bar resizes itself)


Were the menus short, there would be greater possibility that the menus
fit on one line in 90% of the cases.

To the record, I use lots of modes that define menus simultaneously.

| >     In any case the menubar name is good to be made configurable.
| 
| ???  The menu-bar items should IMHO be standardized so that people
| always could find them quickly.  Making them easily changeable seems
| like a bad idea.  (Of course, since menus are created on the Lisp
| level, you can always change them with some effort, but I don't think
| we need to make it too easy.)

The nurturing of users should be gone by now. By providing
configuration, the users can adapt to their needs. Why should one be
concerned how users like to use Emacs? This kind of argumentation is
unnecessary and shows no commitment to let users to select their own
preferences.

-- 
http://tiny-tools.sourceforge.net/
Swatch  @time http://www.ryanthiessen.com/swatch/resources.htm
Convert @time http://www.mir.com.my/iTime/itime.htm




reply via email to

[Prev in Thread] Current Thread [Next in Thread]