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: ffap bindings suggestion Date: Thu, 9 Feb 2006 10:13:58 -0800 Message-ID: References: <87oe1gy4fe.fsf@jurta.org> 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 1139518744 15508 80.91.229.2 (9 Feb 2006 20:59:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2006 20:59:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 21:59:02 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 1F7Is8-0003jw-2M for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2006 21:58:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F7Is6-0008Lk-GT for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2006 15:58:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F7GIw-0007fY-As for emacs-devel@gnu.org; Thu, 09 Feb 2006 13:14:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F7GIu-0007cJ-F9 for emacs-devel@gnu.org; Thu, 09 Feb 2006 13:14:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F7GIt-0007br-K8 for emacs-devel@gnu.org; Thu, 09 Feb 2006 13:14:04 -0500 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 1F7GMU-0004rS-DD for emacs-devel@gnu.org; Thu, 09 Feb 2006 13:17:46 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k19IE0OB027066 for ; Thu, 9 Feb 2006 11:14:00 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k19IDx34017965 for ; Thu, 9 Feb 2006 11:13:59 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k19IDx7c017957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Feb 2006 11:13:59 -0700 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: <87oe1gy4fe.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= 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:50262 Archived-At: > Suggestion: Change the ffap bindings to [S-mouse-2] and [C-S-mouse-2]. I agree that it is common to use mouse-3 for pop-up menus, so I think the old keybinding [C-S-mouse-3] for ffap-menu is more natural than changing it to [C-S-mouse-2] which is more suitable to follow a link. We already have some menus on (modifier) mouse-2 when there exists a different menu on mouse-3. My idea was to keep the same mouse button for both ffap commands, and to reserve mouse-3 for (other) menus. > These keys are also undefined in vanilla Emacs. [S-mouse-2] is akin to > mouse-2 when the latter follows a link (which is essentially what > `ffap-at-mouse' does), so it feels natural to use. With recent changes in many modes to use mouse-1 instead of mouse-2 to follow a link, perhaps ffap should use a modifier with mouse-1, e.g. [C-S-mouse-1]. I don't think mouse-1 has yet replaced mouse-2 as the primary (initial) binding for following links - at least I hope it hasn't. My understanding was that mouse-1 was (sometimes) provided as an additional binding for following links. And mouse-1 link following can be easily turned off; turning off mouse-2 link following is more difficult. If there is no available modifier for mouse-1, then I think better default keybindings are: (global-set-key [C-S-mouse-3] 'ffap-menu) (global-set-key [C-S-mouse-2] 'ffap-at-mouse) or (global-set-key [C-S-mouse-1] 'ffap-at-mouse) I prefer [S-mouse-2] and [C-S-mouse-2], but I won't argue. The main thing is to get ffap-at-mouse off of mouse-3. > 2. Should variable `ffap-bindings' be a defcustom, so that > users can more > easily customize the bindings? In that case, the library > could be modified > slightly to not require users to put `(ffap-bindings)' in > their .emacs: > simply loading the library would create the (default or customized) > bindings. > > How do other libraries deal with multiple non-standard bindings? Many libraries provide a variable which during loading the library tells it to bind its non-standard bindings if this variable it non-nil. One difficulty with that (and some of the other approaches I mentioned) is getting back the original bindings if the feature is later turned off. That is, the user choice in that case is a one-time choice: use the library forever, with or without its bindings, or not. In the case of ffap, the library is (~) not used if its commands are not bound, so undoing the bindings would effectively "turn off" the feature. Undoing the bindings is, however, not made easy for users. In one of my libraries, I use a minor mode, and restore the original bindings when the mode is exited. I find that clean. However, the library currently just restores the vanilla Emacs (-q) bindings; it would of course be better to save the bindings at the time of entry into the mode, and restore those (original user bindings) when the mode is exited. I'm not referring here to a keymap that is local to the mode; in my case, the minor mode changes minibuffer key bindings. Is there no recommended way (or recommended ways) to handle this? It's not uncommon for a library to let users adopt the library's suggested (multiple, often global) bindings in some easy way. Perhaps we should come up with a recommended way for libraries to do that. That way should, in the best case, let users get back their original bindings when they no longer want to use the features of the library. Again, using a local keymap is obviously the way to go when appropriate. In the case of ffap, perhaps it would be better to create a minor mode and use a local keymap for the ffap bindings.