unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>, emacs-devel@gnu.org
Subject: Re: Options menu
Date: Sat, 19 Mar 2005 12:24:34 +0100	[thread overview]
Message-ID: <x57jk3dgjx.fsf@lola.goethe.zz> (raw)
In-Reply-To: <01c52c6d$Blat.v2.4$713e68a0@zahav.net.il> (Eli Zaretskii's message of "Sat, 19 Mar 2005 12:20:38 +0200")

"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

  reply	other threads:[~2005-03-19 11:24 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18  8:54 Options menu Kim F. Storm
2005-03-18 10:31 ` David Kastrup
2005-03-18 12:57   ` Kim F. Storm
2005-03-18 14:58   ` Chong Yidong
2005-03-18 22:56   ` Lennart Borgman
2005-03-19 10:20     ` Eli Zaretskii
2005-03-19 11:24       ` David Kastrup [this message]
2005-03-19 15:32         ` Eli Zaretskii
2005-03-19 15:55           ` David Kastrup
2005-03-19 15:51       ` Lennart Borgman
2005-03-19 16:51         ` David Kastrup
2005-03-19 17:22         ` Eli Zaretskii
2005-03-19 18:18           ` Lennart Borgman
2005-03-20 12:59         ` Richard Stallman
2005-03-20 16:26           ` David Kastrup
2005-03-20 16:58             ` Luc Teirlinck
2005-03-20 17:31               ` David Kastrup
2005-03-20 17:43                 ` Luc Teirlinck
2005-03-20 18:06                   ` David Kastrup
2005-03-21  1:19                   ` Richard Stallman
2005-03-21  1:19                 ` Richard Stallman
2005-03-20 19:31             ` Lennart Borgman
2005-03-20 20:49               ` David Kastrup
2005-03-20 20:45             ` Jason Rumney
2005-03-20 21:40               ` David Kastrup
2005-03-20 22:27               ` Lennart Borgman
2005-03-20 23:10                 ` Luc Teirlinck
2005-03-21  0:02                   ` David Kastrup
2005-03-21  1:26                     ` Luc Teirlinck
2005-03-22  3:34                       ` Richard Stallman
2005-03-21  1:41                     ` Luc Teirlinck
2005-03-21  6:12                     ` Lennart Borgman
2005-03-21 23:28                       ` Luc Teirlinck
2005-03-21 23:35                         ` David Kastrup
2005-03-21 23:50                           ` Luc Teirlinck
2005-03-22  0:15                             ` David Kastrup
2005-03-22  6:20                               ` Lennart Borgman
2005-03-22 20:44                           ` Richard Stallman
2005-03-22 22:37                             ` David Kastrup
2005-03-20 22:12             ` Miles Bader
2005-03-18 15:48 ` Drew Adams
2005-03-18 20:30   ` Eli Zaretskii
2005-03-18 20:53     ` Drew Adams
2005-03-19 10:13       ` Eli Zaretskii
2005-03-19  3:08 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x57jk3dgjx.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman.073@student.lu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).