Re: Customizing key bindings

[Per Abrahamsen]

Miles Bader <address@hidden> writes:

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

That definition was identical, given a suitable definition of "user".

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

So do I, which is why I have tried advocating the 100% solution.

> I'm not sure what you mean by `duplicate on start-up' 

".emacs" contains:

   (setq foo 'bar)

The user say:
   M-x customize-option <ret> foo <ret>

Customize warns that the option is set "outside customize".  If he
nonetheless go ahead and saves it, it will have no effect since it
will be overwritten by the setq in the next session.

This is the whole point of differentiating between "set by customize"
and "set outside customize".  It is there to help the user from
screwing himself, either directly (by saving an option already set in
".emacs"), or indirectly (by customizing an option some other package
he loads believe it has the right to change).

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

The problem is not setting, but saving the binding.  If he saves the
binding, it will be set twice on upstart.  The final value will depend
on whether the "define-key" call is before or after the
"custom-set-variables" call.

> The benefit of making .emacs bindings `user bindings' is that people can't

Should that be "can"?

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

It might be intuitive, but frustrating when they start a new session,
and the customization they erased in the previous session magically
reappears.

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

So you can change the format of keymaps, with no fear of breaking user
code?