emacs-devel
[Top][All Lists]
Advanced

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

RE: [External] : Re: The new keymap functions


From: Drew Adams
Subject: RE: [External] : Re: The new keymap functions
Date: Wed, 17 Nov 2021 16:06:55 +0000

>>> Like I said before -- all these functions
>>> destructively modify a keymap,

Is "destructively" important here?  If you
intend to make the same argument without it,
then you should maybe drop it, for clarity.

Otherwise, in the future someone wanting to be
faithful to this `Lars Doctrine' may think or
claim that it applies _only_ when destructively
modifying.  (Or is that what you mean/want?)

You should be clear about what you're setting
down in your new tablets of stone.
___

>> That is true, but what users think of operating
>> on is a key sequence, not the keymap.
> 
> Perhaps they think that because we've called the
> functions stuff like `define-key'.  (Which we're
> now not doing.)

Perhaps.  But perhaps not only for that reason.

They think that because that's what the operation
does.

Users are primarily concerned with _keys_, not
keymaps, if only (but not only) because most user
settings of keys are in the global map.

Knowing about different keymaps and having a need
to change a map other than `global-map' is not in
the first approximation view of an Emacs user.

And rightfully so.  We have, and manipulate,
multiple keymaps _not for their own sake_, but to
_organize key bindings_.
___

But if you're really set on doing this then you
should, I think, be consistent with what we do
currently, and have always done, with other
objects that have parts/attributes:

we use the name `set-<object>-<part>', not
`<object>-set-<part>'.

Consider:

set-buffer-*
set-case-*
set-char-table-*
set-coding-*
set-cursor-*
set-display-table-*
set-face-*
set-file-*
set-font-*
set-frame-*
set-fringe-*
set-input-*
set-justification-*
set-keyboard-coding-*
set-language-*
set-marker-*
set-mouse-*
set-process-*
set-shell-*
set-terminal-*
set-window-*

Not only that, but names matching `.*-set-',
that is, with some name part before `set',
typically have, as the part that precedes
`set', a library prefix or a language prefix,
not an object/type name.

There are relatively few exceptions, where an
object name precedes `set'.  And even in those
cases the object name can usually be seen to
also be a library prefix.

With your preference of emphasizing the keymap,
setting a key binding in a given keymap should,
in keeping with our convention, be called
something like `set-keymap-binding'.

You're instead creating more inconsistency, it
seems.

Please take a look at existing names, and I
think you'll see that I'm right.  They follow
a pattern, and it ain't the pattern you're
trying to follow now.
___

Oh, and I don't find any existing `unset-*'
functions (i.e., names starting with `unset').
The only unsetting functions I see are the
`*-unset-key' functions.

You could think of those as almost starting
with `unset', as the part that precedes it is
just local|global.  But again, nothing like
using the prefix `keymap-'.

Unsetting has traditionally been seen and
handled as just a particular kind of setting,
AFAICT.



reply via email to

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