emacs-devel
[Top][All Lists]
Advanced

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

Re: Options menu


From: David Kastrup
Subject: Re: Options menu
Date: Sat, 19 Mar 2005 12:24:34 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Eli Zaretskii" <address@hidden> writes:

>> From: "Lennart Borgman" <address@hidden>
>> Date: Fri, 18 Mar 2005 23:56:02 +0100
>> Cc: address@hidden
>
>> 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




reply via email to

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