unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>, Richard Stallman <rms@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: The new keymap functions
Date: Wed, 17 Nov 2021 16:06:55 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488EEB669331996823BE62DF39A9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87ee7fp66g.fsf@gnus.org>

>>> 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	other threads:[~2021-11-17 16:06 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13  6:56 The new keymap functions Lars Ingebrigtsen
2021-11-13  7:31 ` Stefan Kangas
2021-11-13  7:50   ` Lars Ingebrigtsen
2021-11-13 11:36 ` Joost Kremers
2021-11-13 12:07   ` Lars Ingebrigtsen
2021-11-15 13:01     ` Dmitry Gutov
2021-11-15 16:53       ` Lars Ingebrigtsen
2021-11-16  7:28         ` Lars Ingebrigtsen
2021-11-16 14:08           ` Eli Zaretskii
2021-11-16 14:24             ` Lars Ingebrigtsen
2021-11-16 15:13               ` Eli Zaretskii
2021-11-16 15:19                 ` Lars Ingebrigtsen
2021-11-16 17:16                   ` Eli Zaretskii
2021-11-17  7:30                     ` Lars Ingebrigtsen
2021-11-13 15:09 ` Stefan Monnier
2021-11-13 15:24   ` Lars Ingebrigtsen
2021-11-14  3:17 ` Lars Ingebrigtsen
2021-11-14  5:05 ` Phil Sainty
2021-11-14  5:14   ` Lars Ingebrigtsen
2021-11-14  7:15     ` Eli Zaretskii
2021-11-14 10:53       ` Lars Ingebrigtsen
2021-11-14 11:01         ` Lars Ingebrigtsen
2021-11-14  7:41     ` Yuri Khan
2021-11-15  4:52 ` Richard Stallman
2021-11-15  5:14   ` Lars Ingebrigtsen
2021-11-16  4:05   ` Richard Stallman
2021-11-16  7:38     ` Lars Ingebrigtsen
2021-11-16 16:25       ` [External] : " Drew Adams
2021-11-17  4:16       ` Richard Stallman
2021-11-17  7:55         ` Lars Ingebrigtsen
2021-11-17 16:06           ` Drew Adams [this message]
2021-11-16 16:24     ` [External] : " Drew Adams
2021-11-16 20:14 ` Juri Linkov
2021-11-17  4:16   ` Richard Stallman
2021-11-17  7:36   ` Lars Ingebrigtsen
2021-11-17  8:10     ` Juri Linkov
2021-11-17  9:42       ` Robert Pluim
2021-11-17 17:03         ` Juri Linkov
2021-11-18  9:15           ` Lars Ingebrigtsen
2021-11-18 10:25             ` Robert Pluim
2021-11-18 10:33               ` Lars Ingebrigtsen
2021-11-18 10:37                 ` Lars Ingebrigtsen
2021-11-18 10:54                   ` Robert Pluim
2021-11-18 10:59                     ` Lars Ingebrigtsen
2022-11-15 18:38         ` Juri Linkov
2022-11-17  7:31           ` Juri Linkov
2022-11-17  8:35             ` Robert Pluim
2022-11-17 15:04               ` Robert Pluim
2022-11-17 17:29                 ` Juri Linkov
2022-11-18  8:33                   ` Robert Pluim
2022-11-18 15:41                     ` Robert Pluim
2023-03-17 14:48                 ` Robert Pluim
2023-03-18 18:04                   ` Juri Linkov
2023-03-20  8:54                     ` Robert Pluim
2021-11-17 20:57     ` Bob Rogers
2021-11-18  3:53       ` Richard Stallman

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=SJ0PR10MB5488EEB669331996823BE62DF39A9@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rms@gnu.org \
    /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).