unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: ffap bindings suggestion
Date: Thu, 9 Feb 2006 10:13:58 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICEEGLDCAA.drew.adams@oracle.com> (raw)
In-Reply-To: <87oe1gy4fe.fsf@jurta.org>

    > 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.

  reply	other threads:[~2006-02-09 18:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-08 18:46 ffap bindings suggestion Drew Adams
2006-02-09 17:33 ` Juri Linkov
2006-02-09 18:13   ` Drew Adams [this message]
2006-02-12  1:56     ` Drew Adams
2006-02-12 13:43       ` Stefan Monnier
2006-02-12 15:51         ` Drew Adams
2006-02-12 17:15           ` Stefan Monnier
2006-02-12 17:34             ` Drew Adams
2006-02-12 20:48           ` Stefan Monnier
2006-02-12 21:19             ` Drew Adams
2006-02-13  5:06               ` Stefan Monnier
2006-02-13 15:29                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICEEGLDCAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).