"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> From: "Lennart Borgman" <[EMAIL PROTECTED]> >> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
