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: Mon, 13 Nov 2017 06:36:10 -0800 (PST) Message-ID: <0ad9af94-11cc-4dae-841f-f2918342d1bf@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 1510583831 3483 195.159.176.226 (13 Nov 2017 14:37:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 14:37:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 13 15:37:05 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 1eEFrE-0000cb-Gc for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 15:37:04 +0100 Original-Received: from localhost ([::1]:54766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEFrL-0006kV-RW for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 09:37:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEFqX-0006js-71 for emacs-devel@gnu.org; Mon, 13 Nov 2017 09:36:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEFqT-0000PE-VB for emacs-devel@gnu.org; Mon, 13 Nov 2017 09:36:21 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17199) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEFqT-0000Mt-Ml for emacs-devel@gnu.org; Mon, 13 Nov 2017 09:36:17 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vADEaEVY028997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 14:36:15 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vADEaDZA021770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 14:36:14 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vADEaCZJ022807; Mon, 13 Nov 2017 14:36:13 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: aserv0021.oracle.com [141.146.126.233] 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:220139 Archived-At: > >> 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. > > > > The active region is not visible as such until `mouse-3' > > is released (the up event). >=20 > It doesn't matter, in my UI suggestion. You can either > do: (short) click =3D> do good ol' mouse-save-then-kill > press-and-hold =3D> pop up a contextual menu The point was not about simply killing the region text. Of course you can kill it using a single, normal click. That's true of `mouse3.el', as well. That's nothing new. The point was about being able to act on the active region in other ways, with a contextual menu appropriate to the region being active. (Being able to. Nothing _requires_ you to have a menu that is sensitive to the region being active.) Again: the region is not highlighted until `mouse-3' is released (up event). You should be able to see the region if you intend to act on it. > > So even if this could be made to provide a menu for > > acting on the region, the region would not be visible. >=20 > It's visible if it was activated by an earlier command, > of course. E.g. "mouse-3" followed by "down-mouse-3". Pressing and holding down `mouse-3' does _not_ highlight the region. That happens only when `mouse-3' is released. If you mean first click `mouse-3' (press and release) and then press and hold `mouse-3', then you are talking about _two_ `mouse-3' clicks (it will be released) - similar to what `mouse3.el' does. Besides not highlighting the region that is active and can be acted on, your approach has the disadvantage of mistakenly killing the region when an intended long press happens to be a bit too short. With the `mouse3.el' approach you can't mistakenly kill the region. Instead, the menu is available if you mistakenly click too slowly, giving you another chance to kill the region. IOW, it's the other way around. > > The `mouse3.el' code intentionally provides for > > two menus: > > * One for actions on the active region... > > * One for other actions... >=20 > My suggestion doesn't attempt to provide that. Right. Nothing to reflect/distinguish the context of the region being active. So again: >> I think a better UI is to pop a menu for a "long press". > ^^^^^^^^^^^ > Why do you think so? What's better about it?