[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Customizing key bindings

From: Miles Bader
Subject: Re: Customizing key bindings
Date: Mon, 9 Sep 2002 10:09:30 -0400
User-agent: Mutt/1.3.28i

On Mon, Sep 09, 2002 at 02:20:33PM +0200, Per Abrahamsen wrote:
> Miles Bader <address@hidden> writes:
> > The usual way that global bindings are established is to bind the key
> > ahead of time (often via ###autoload), and autoload the package when
> > the binding is first invoked.  In those cases, the `default binding' is
> > established ahead of time, so customize will find it.
> Only for bundled packages.  
> > Non-trival differences in behavior based on (interactive-p) are
> > something that make me nervous.
> Me too, but nobody protested when Stefan added such functionality to
> define-minor-mode, so I presumed it was an acceptable solution.
> > If I can try to restate what you said, it seems to be:
> Yes.  I find this this simple and intuitive.

Er, you omitted my additional definition, which abstracts things a bit more;
does that mean you find a problem with it?

> > So is there a definition of `user' that's easy to implement? 
> I define "user" to be someone who use the interactive fascilities for
> customizing Emacs, rather than the Lisp fascilities for the same.

Unfortunately, that doesn't really match a typical emacs user; emacs users
use `lisp' facilities to define keys all the time.

I know you're coming from the point of view where customize is more
important, but please try to understand that many of us wish to at least
_try_ to make both sets of users happy.

> > I'm not sure, maybe something like `not defined while loading a
> > file'.
> That may be more reliable, rather than, as now, gradually making
> existing commands customize aware, as people think of them.
> E.g. set-variable should probably really be customize aware when
> called interactively.
> > That would catch customize, M-x global-set-key, M-: (global-set-key
> > ...), hooks, eval-region, etc.  It would also mean that bindings
> > established in .emacs are `non-user' which may be good or bad, but
> > maybe it could be made be an exception to the loading-files test.
> They should be "non-user", as we don't want customize to duplicate
> these bindings on start-up.

I'm not sure what you mean by `duplicate on start-up' -- if .emacs bindings
are marked as `user bindings' then they won't overwrite the `binding
defaults' for the keys they define; if custom then defines any of the same
bindings, it will overwrite the _user_ bindings, but not the `binding
defaults'.  So there's no `duplication', just redefinition -- just as if you
had used customize to define the same key twice.

The benefit of making .emacs bindings `user bindings' is that people can't
use `revert to default binding' to get rid of a (non-custom) .emacs binding
and go back to the binding established by the default emacs code, which many
people would find intuive I think.

> I probably shouldn't say this, but it will be simpler for XEmacs,
> where keymaps are an opaque type.

Perhaps in theory, but in practice I think that's not true -- there are so
many wierd twists in the keymap format that no one in their right mind
actually modifies them without using standard keymap functions.  As far as I
can see the only real use of the non-opaque keymaps is that it's easy to
print them out and see what's in there...

P.S.  All information contained in the above letter is false,
      for reasons of military security.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]