emacs-devel
[Top][All Lists]
Advanced

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

RE: [External] : Re: Experimentally unbind M-o on the trunk


From: Drew Adams
Subject: RE: [External] : Re: Experimentally unbind M-o on the trunk
Date: Wed, 10 Feb 2021 17:58:02 +0000

> The bindings people are suggesting suppressing are all
> basic editing commands.  If their bindings are taken
> from them, then they become inaccessible, und
> unknowable, to all but a few old hands.  Newbies should
> also be able to discover and use back-to-indentation,
> open-line, and so forth.

Menus.  Apropos.

(This is not a comment about any specific key
proposals.  It's just to say that commands are
discoverable.  And, yes, discoverability has
room for improvement.)

And nothing prevents a 3rd-party library or
even Emacs itself, from providing one or more
commands that set up a given set of bindings.
Au choix.  That's different from binding those
keys by default.  And such key-set choices
could be available by commands on the Help menu.

There are other possibilities.

All of that said, I don't think we should willy
nilly remove default key bindings.  Discussion
and reasoned argument & decision are called for.
The point is that some keys might well be
candidates for freeing up.

I suggested also possible refactoring: using
prefix keys more, grouping related commands on
a common prefix.

And I suggested making commands repeatable that
are now non-repeatable but are currently bound to
repeatable keys (e.g. `C-a').  [This doesn't, in
general, free up keys, but it might in some cases,
e.g. having a single repeatable key where you can
reverse the direction on the fly (including at the
outset).]

> Another reason is that if somebody rebinds a much
> used basic command back to its traditional key
> sequence, that blocks out all the potentially
> useful commands which other people now feel free
> to bind to that key sequence.

I don't see that as a real problem.  That's just
deciding to rebind a key that's already bound to
something else (at least in some context, e.g.
some mode, after activating some set of keys, or
loading some library).

Caveat emptor.  Users can bind and unbind any
keys they like.  That's already the case.

> I also don't see that the case has been made
> for freeing up vast numbers of key bindings
> for external packages.

I don't think anyone has suggested that.
Certainly not vast numbers.

My own suggestion was to reserve, for 3rd-party
code, at least for a while - a moratorium,
those keys that currently do NOT have default
key bindings.  And there certainly are not vast
numbers of those.

> If I've understood correctly, these key
> sequences are wanted for things like
> `switch-on-foo-minor-mode', where the reserved
> minor mode bindings are not yet available.

No, I don't think so.  I don't think anyone
proposed default-binding such switch-keys-on
commands OR the bindings that such a command
would make - whether minor-mode or otherwise.

And I don't think anyone proposed reserving
such commands.

But maybe I've misunderstood the point you make, there.

> Each user will have her own set of minor modes
> she uses, that set will typically be small, so
> setting her own set of bindings is reasonable
> to expect.  Beyond the basic facilities, we
> shouldn't be trying to set up a universal set
> of bindings for everybody.

100% agreement about that last point.  (I
might well have misunderstood some of your
other points.)



reply via email to

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