From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: RE: No "Edit" menu-item in "Gnus" Date: Tue, 15 Aug 2006 16:37:51 -0700 Message-ID: References: <858xlp8wrs.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155685113 21499 80.91.229.2 (15 Aug 2006 23:38:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Aug 2006 23:38:33 +0000 (UTC) Cc: Gnus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 16 01:38:31 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GD8UE-0003QD-50 for ged-emacs-devel@m.gmane.org; Wed, 16 Aug 2006 01:38:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8UD-0002bH-7Q for ged-emacs-devel@m.gmane.org; Tue, 15 Aug 2006 19:38:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GD8Tz-0002Z5-Fu for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:38:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GD8Ty-0002Xr-8m for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:38:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8Ty-0002Xl-0Q for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:38:02 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GD8a6-0006q2-BV for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:44:22 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7FNbxwg019512; Tue, 15 Aug 2006 17:37:59 -0600 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-31.vpn.oracle.com [141.144.81.31]) by rgmgw2.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k7FNbwTH021081; Tue, 15 Aug 2006 17:37:58 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <858xlp8wrs.fsf@lola.goethe.zz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58426 gmane.emacs.gnus.general:63560 Archived-At: > 1. Edit shouldn't be removed from the menu-bar for the sole reason > of saving menu-bar space and because the buffer might be > unmodifiable. Menus are for frequently used commands. Only? What gave you that idea? It is sometimes very useful to have infrequently used commands in menus - especially in Emacs. When do you use the menu-bar? I tend to use it for commands that I've forgotten the name, or the binding, or the variants of - that is, commands I use infrequently. I use Vinicius's printing.el stuff via menu, for instance, because there are printing-command variants that I never remember - I know I'll find them in the Printing menu. One advantage menus provide is just that: They organize commands into classes (and subclasses), letting you look them up in a hierarchy. That's really what menus "are for", if we must pick one thing. Menus are especially useful to newbies for just that reason: you can figure out where a command is by exploring the hierarchy (is it something to do with files? editing? help?... is it about a bicycle?). In a flat command space, without organization by classes, it's hard to find commands. (Fortunately, we also have `apropos'.) If in a particular situation the entries of a menu are of rare use, and others are more important, omitting the rarely used menu might make sense. Why would it make sense? What's to be gained? Menu-bar space? In that case, if you can really determine that it is less important, put it on a "More" menu as a submenu. There is no reason to remove it altogether, if it has some use in that context. And, as I said, it's difficult to determine that a menu is truly useless in some context, because some library might have added to it, making it more useful. Unmodifiable buffers are one example: If an app adds useful commands that don't modify things to the Text Properties menu, then that menu becomes more useful in an unmodifiable buffer. > If there is a problem with menu-bar space in some context, > then some other solution should be adopted. One solution > is to have a pull-down menu (e.g. "More", "...", or a > triangle arrow) that combines some other menus as submenus. > Another solution is to let the menu-bar extend over > multiple lines when necessary - that's the current default, > and it's OK too. > > It's silly to assume a fixed frame width, in any case, and > to base decisions of which menus to include on that width. > I shrink-fit frames to fit their buffers, for example, so > they have different widths. Other people always maximize > their frames, or always use some fixed width that's > different from the default. The menu bar should fit on an 80-column text tty. Maybe. And maybe 10 or 20 columns on a cell phone. But what about the menu-bar on a display with window-manager windows? If an 80-column limit needs to be imposed for ttys, so be it. Emacs on ttys can just remove menus from the menu-bar as needed. Why should the tty context determine the design for all Emacs menu-bars? Lowest common denominator has its limits (did Yogi Berra say that?). That is a hard limit that can't be come by by changing font sizes or resizing windows. I can't parse that one. I guess maybe you mean that tty width is a hard limit. See above - that shouldn't limit the rest of Emacs.