Re: Customizing key bindings

[Miles Bader]

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

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