From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: poplife-mode Date: Sun, 12 Nov 2017 17:36:33 -0800 (PST) Message-ID: <91be4692-f10a-465d-bd73-1a1b6bd2271f@default> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510537013 7504 195.159.176.226 (13 Nov 2017 01:36:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 01:36:53 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 13 02:36:48 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eE3g7-0001Xp-QY for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 02:36:47 +0100 Original-Received: from localhost ([::1]:52042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eE3gD-00065M-8b for ged-emacs-devel@m.gmane.org; Sun, 12 Nov 2017 20:36:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eE3g5-00061F-7P for emacs-devel@gnu.org; Sun, 12 Nov 2017 20:36:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eE3g1-0003Co-8m for emacs-devel@gnu.org; Sun, 12 Nov 2017 20:36:45 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:28921) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eE3g1-0003AK-07 for emacs-devel@gnu.org; Sun, 12 Nov 2017 20:36:41 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAD1aadX007967 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 01:36:38 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vAD1aauk018451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 01:36:36 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAD1aZgR027372; Mon, 13 Nov 2017 01:36:35 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220122 Archived-At: > > I just read up on how Drew's library `mouse3' solves the problem. If > > I understood it right, it redefines mouse-save-then-kill (mouse-3's > > normal binding) to respond differently to either a double-click of > > mouse-3 or two single-clicks of mouse-3 in the same spot. A > > double-click kills the region as it usually does, whereas two > > single-clicks pop up a contextual menu with menu items based on either > > the "thing at point" (if no region is selected) or the selected > > region. This also seems like o good solution. >=20 > FWIW, I think a better UI is to pop a menu for a "long press". > I.e. bind it to down-mouse-3 but wait a little and if there's not been > any "mouse-up" event with 1s or so, then pop up the contextual menu. That is similar, yes. But in practice what happens (in my experience) is that a second click follows, which might or might not be quick enough to be considered a double-click. IOW, a "faulty" double-click is handled by `mouse3.el' as an extension of a successful/true double-click. Since double-click for `mouse-3' kills the selected text, if a region is active and the second click is not quick enough to be the second part of a double-click, you can still kill the text, by choosing `Kill', which is the first item in the (default) menu provided by `mouse3.el'. This is also a good way for users to discover the possibilities of a mouse-3 contextual menu: stumble on it by double-clicking too slowly (and choosing `Kill' to finish it off). (Someone who clicks slowly or unevenly might also be a particularly good candidate as someone who appreciates being able to use the menu.) Note too that with `mouse3.el' a second click of `mouse-3' provides different menus, depending on whether the active region is empty. If it is empty then the menu applies to the mouse-click position (it is the same position for both clicks). If the region is non-empty then the menu applies to the region. (Sure, that two-menu system could be transferred to the long-mouse-3-press that you suggest instead.) FWIW, I've never been a fan of of a longer-press-means-different-behavior UI. My impression (but I'm not a user of it) is that this behavior is clunky in CUA-mode, for example. Better, I think, to depend on the single timing that users are alrady used to, which applies to all of their apps equally, and which they have already configured if they don't want the default delay: the double-click delay. What I just said also echoes what Eli said about your suggestion: Is it a good idea to invent a UI that is unlike anything out there in any other GUI application, at least AFAIK? Last time Emacs did that there was no other app around, but not so nowadays... The double-click delay, on the other hand, is something that pretty much everyone is used to. > I think this should actually be provided in core: down-mouse-3 should be > bound to a command implementing this, with some standardized way to find > a contextual menu (looking at local char-properties, and if not > found, buffer-local variable). I don't think I can agree, here, if only because in some contexts users/libraries end up defining a behavior for `down-mouse-3', with an `ignore' behavior of `mouse-3', and in other contexts (or other users or other libraries) do the opposite: act upon `mouse-3' and ignore on `down-mouse-3'. Even the platform can make a difference in such a choice, IIRC. In any case, there must be some way for users to opt out of any such mouse-3 behavior. The behavior of `mouse3.el', which is highly configurable, is 100% optional.