From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: Context menus and mouse-3 [was: Changes for emacs 28] Date: Mon, 14 Sep 2020 03:06:43 +0000 (UTC) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5683"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, Richard Stallman , emacs-devel@gnu.org, Arthur Miller , Dmitry Gutov , Gregory Heytings To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 14 05:07:27 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kHepy-0001Nn-Pw for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Sep 2020 05:07:26 +0200 Original-Received: from localhost ([::1]:60628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kHepx-0002TP-TE for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Sep 2020 23:07:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHepR-0001z4-TT for emacs-devel@gnu.org; Sun, 13 Sep 2020 23:06:53 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:36302) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHepP-00081O-OE; Sun, 13 Sep 2020 23:06:53 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08E3525b066246; Mon, 14 Sep 2020 03:06:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=O2hGvQ3hOIJbL+0uxOnKht16U+RA7glp9TFzngwDbhc=; b=imRSGSzJG7f+bQSHWKcit+f6s8/Wz9yylTnwWBtGLc/HvfLIKVoI3P3tVesbT+bPj63L B7WYiRV3nlZL5ARc8PNLx3vrxJpL6dNblmUNhN0AUeC+vxJIZtxeDU96oJvDKY9d/06S FayLTg8BJF+3Etr/bsJIKXzWVTrnprRdtZkiuAA8qjXcxK0RBSFK8/nd8Jj61Ss/eerS IZj87lamTvmPYKC1tChYwIesRNypNFrcqlvKDJneqJndpCshXsKQQknquXm3ZYukkL52 V9KUwfQHmMAE9q2N22QqBJPoZuacPMkQwpIQA5sK5JUAXQec6VKSazFiVHJnkywiDFDF sw== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 33gnrqkwp5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 14 Sep 2020 03:06:48 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08E35qPW111290; Mon, 14 Sep 2020 03:06:47 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 33h7wkchpq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Sep 2020 03:06:47 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 08E36imI021273; Mon, 14 Sep 2020 03:06:45 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5044.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9743 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009140030 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9743 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009140030 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/13 23:06:49 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -60 X-Spam_score: -6.1 X-Spam_bar: ------ X-Spam_report: (-6.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:255596 Archived-At: Ergus> The real problem is that now the right click Ergus> is bind to mouse-save-then-kill which I have Ergus> never ever used, but probably others have. and earlier: Ergus> Sadly we have bind to mouse-save-then-kill Ergus> which I don't find useful at all, but maybe Ergus> somebody will complain if we change it to Ergus> C- and move the panel to . I suspect that people who use a mouse but feel that `mouse-save-then-kill' isn't useful have never really understood what it offers. Part of the lack of understanding may come from not having read the manual about it. Node `Mouse Commands' of the Emacs manual makes the behavior clear, and thus how useful it can be. `mouse-3' lets you select text, delete or kill text, and extend or reduce the selection. That's a lot, and the actions to do those things fit well together. The extend-or-reduce bit works in a special way if you've selected text by multiple clicking: double-clicking or triple-clicking `mouse-1'. I invite you to read the full text, if you haven't already. And then play with it a bit. ___ What happens if you just read the doc string? You don't get a great idea of the richness of `mouse-3' behavior, IMO. It's OK, as far as a doc string goes. But it's unlikely to teach someone what they can do with it. Here's a suggestion for that doc string, and also for the doc strings for other `mouse-*' bindings (keys and commands): Provide a link to that `Mouse Commands' node in the manual. ___ To me, the behavior of `mouse-save-then-kill' is super useful. So much so that my library `mouse3.el' has, as a big part of its design, to keep that behavior, while supplementing it with `mouse-3' context menus. You can of course optionally just get the menus. But that's not where it's at - not the default behavior. The idea is to let you use the normal behavior as many times as you like - extend, reduce, kill, whatever - and then, if you like, click `mouse-3' at the same place again, to pop up a context menu. The first part is optional, and so is the menu popping. Click in the same spot for the menu. Click anywhere else for the vanilla behavior. The other big part of the design is context menu definition and behavior. Those two parts are logically independent, but it makes sense for them to be in the same library. There are alternative ways to define the menus, and alternative ways to present them. Menus can be mode-dependent or not, dynamic (programmed) or static. Menus can, and generally do, differ, depending on whether or not the region is active. When active, a context menu provides actions on the region or things in it. When inactive, it provides actions on thing(s) located where you click. (There are always multiple things located at the spot where you click. It's up to a particular menu to decide which things to act on.) ___ Should a context menu include _only_ items that pertain to the region or the location clicked? In general, no. But you can certainly have menus that do provide only that, if you want. Should a context menu include global menus as submenus, i.e., major-mode menus or menu-bar menus? That's up to you - an option controls this. If non-nil then yes: if the menu-bar is visible then include the major-mode menus; else include the menu-bar menus. ___ There are two alternative ways to define the menus: (1) use keymaps and extended menu items or (2) use the `x-poup-menu' form. The former is the default method. It gives you more control: keywords such as :visible and :enable, for instance. The latter is a bit simpler for defining, perhaps. Simple example code of using each method is provided in `mouse3.el', with explanation. An example of method #1 is provided for use with Dired mode. An example of #2 is provided for use with Picture mode. ___ `mouse3.el' is completely compatible with the traditional Emacs `mouse-3' behavior. The only place where they overlap is if you click `mouse-3' twice at the same spot. If you do that to delete the selected text, then to get that effect with `mouse3.el' you double-click instead. Vanilla Emacs doesn't distinguish a double-click from two clicks separated by more than the double-click time. (You can swap those two behaviors: slow 2-click to delete instead of to show menu.)