From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [drew.adams@oracle.com: Customize value menudoesn'trecognizemouse-2] Date: Tue, 1 Aug 2006 08:19:44 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1154445743 16417 80.91.229.2 (1 Aug 2006 15:22:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2006 15:22:23 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 01 17:22:20 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 1G7w4G-0000pL-B4 for ged-emacs-devel@m.gmane.org; Tue, 01 Aug 2006 17:22:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7w4F-0004Kc-NW for ged-emacs-devel@m.gmane.org; Tue, 01 Aug 2006 11:21:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7w46-0004JM-6a for emacs-devel@gnu.org; Tue, 01 Aug 2006 11:21:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7w43-0004Iw-DO for emacs-devel@gnu.org; Tue, 01 Aug 2006 11:21:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7w43-0004It-6R for emacs-devel@gnu.org; Tue, 01 Aug 2006 11:21:47 -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 1G7w6x-00011H-Ox for emacs-devel@gnu.org; Tue, 01 Aug 2006 11:24:47 -0400 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k6UKHut9029635 for ; Tue, 1 Aug 2006 09:21:45 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-66-137.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1681684151154445588; Tue, 01 Aug 2006 09:19:48 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 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:57939 Archived-At: > > From: "Drew Adams" > > > From: Richard Stallman > > > > > > On GNU/Linux, probably with Lucid menus, I can select from > > > the menu using any of the three mouse buttons. > > > > > > (The latter part happens only on MS-Windows.) > > > > > > It sounds like a bug in the way menus work in > > > Emacs on Windows. > > > > What Richard described for the other platforms is exactly the > > behavior I requested when I filed this bug. I'm confused: what are you saying here about how the problem at hand should be fixed? I have nothing to say about how the problem should be fixed. I reported what the problem was, and I have an opinion about what the correct behavior could be, but I have no opinion on how to implement a fix. From my perspective, mouse-2 in menus now performs on Windows as it does in other Windows GUI programs and as it works with some toolkits on X. mouse-2 on a button in Customize, which drops the value menu does _not_ behave as on X. Given these facts and the fact that mouse-2 behavior on Windows in both these types of menu msut be the same, what would you want that uniform behavior to be? I thought I made that clear from the start, but let me try to be clearer. As I said in this bug report, I would prefer that mouse-2 be able to open the value menu if and only if mouse-2 can also select from that menu. The same should be true of any mouse button: it should open a menu if and only if it can also use the menu (select from it). I feel the same about other menus, but this report was only about the Customize value menu. If all kinds of menus cannot be fixed this way, then let's at least fix as many as we can. It doesn't make sense for a user to discover that s?he can open a menu with a mouse button but cannot select from that menu with the same button. That seems obvious, to me. I also feel that this general principle should apply to all platforms, if possible. If there are trade-offs that must be made, however - for example, accept inconsistency across platforms vs accept inconsistency within a platform, then we can discuss those in context. Speaking generally, my personal preference, though it is not a strong one, is that it is usually more important to have consistency within Emacs on a given platform than it is to have consistency across platforms - provided that within-platform consistency is a move toward better interaction and not a downgrade to a consistent but poorer UI. That proviso points to another general principle that I support: Avoid reducing quality in the name only of consistency, whether it be consistency within a platform or across platforms. IOW, a lowest-common-denominator that is based solely on the rationale of consistency is not the ideal, for me. We should try to move up toward consistency, not down to it. The reason I think that within-platform consistency is generally more important is that a user spends more time within Emacs on one platform: cross-platform use of Emacs is generally less than within-platform use. So, inconsistency across platforms will tend to perturb users less than inconsistency within a platform. Note: "generally", "tend to" - this is only a general heuristic; YMMV. If the choice were, say, to fix this completely in Windows, making mouse use consistent across mouse buttons, but such consistency were not possible now in some other platform for some reason, then I would still prefer that fix to the "fix" of bringing all platforms to the same state of inconsistency in the mouse behavior, in the name of cross-platform consistency. Ratchet consistency upward, only. As I said, however: 1) if trade-offs are needed, then let's discuss them, and 2) my general preference for intra-platform consistency is a) not strong and b) general, not absolute across all cases.