unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: John Yates <john@yates-sheets.org>
To: Richard Stallman <rms@gnu.org>
Cc: Tim Cross <theophilusx@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: Keybinding styles (was: [External] : Re: Gitlab Migration)
Date: Tue, 7 Sep 2021 08:02:03 -0400	[thread overview]
Message-ID: <CAJnXXogQe9ctfLz3aXrMp81cMhvTs_TGcdwVB2rxQCsX42_a5A@mail.gmail.com> (raw)
In-Reply-To: <E1mNRau-0006mS-Lt@fencepost.gnu.org>

On Mon, Sep 6, 2021 at 11:16 PM Richard Stallman <rms@gnu.org> wrote:
>
>   > As a first step towards Stefan's wish, might I suggest that we
>   > consider what it would take to move to a world in which other
>   > binding schemes are considered fully equal peers of our current
>   > default bindings?
>
> If "fully equal peers" means that we give them as much support to each
> of them as we do to the Emacs key bindings, we shouldn't.  It would be
> an enormous amount of work, and not worth it.  We won't urge people to
> make a version of the Emacs Manual that uses a different set of key
> bindings, nor to update it for each Emacs version.
>
> It's reasonable to support selecting other sets of key bindings,
> but the implementing them and supporting them will have to be up
> to whoever likes each one.

I did not suggest that we do any work specifically to support
any specific alternative set of key bindings.  What I attempted
to suggest is trying to understand the experience of someone
adopting Emacs from the outset with evil-mode or some other
alternative set of key bindings enabled.  To what extent can
that user be made to feel other than a second class member
of our community?  Can the user experience when perusing
documentation be either in terms of neutral function names
or, when key bindings must be mentioned, then in terms of
that user's elected bindings?

The implication was, until we accept at a cultural level, that
other sets of bindings should not be disadvantaged, we are
unlikely to make progress toward Stefan's stated wish:

> I keep wishing someone came up with a clever way for modes to specify
> their key-bindings in such a way that Emacs can automatically derive from
> it the keys to use "normally" as well as the keys to use in Evil or the
> keys to use in god-mode, or the keys to use in this hypothetical new
> `really-cua-mode`, ...
> So as to finally address this long-term maintenance challenge.

/john



  reply	other threads:[~2021-09-07 12:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 18:00 [External] : Re: Gitlab Migration Drew Adams
2021-09-03 20:06 ` Stefan Kangas
2021-09-03 22:49 ` Stefan Monnier
2021-09-04  2:00   ` Tim Cross
2021-09-04 13:26     ` Keybinding styles (was: [External] : Re: Gitlab Migration) Stefan Monnier
2021-09-04 13:39       ` Dmitry Gutov
2021-09-04 14:25         ` Keybinding styles Stefan Monnier
2021-09-04 15:44       ` Keybinding styles (was: [External] : Re: Gitlab Migration) Yuan Fu
2021-09-04 15:50         ` Eli Zaretskii
2021-09-04 15:55           ` Drew Adams
2021-09-04 16:07           ` Yuan Fu
2021-09-04 16:19             ` Eli Zaretskii
2021-09-06  3:07             ` Richard Stallman
2021-09-06 11:28               ` Dmitry Gutov
2021-09-04 19:55           ` Keybinding styles Daniel Fleischer
2021-09-04 20:52             ` Stefan Kangas
2021-09-05  7:17               ` tomas
2021-09-04 16:09         ` Bird
2021-09-04 20:48         ` Keybinding styles (was: [External] : Re: Gitlab Migration) Tim Cross
2021-09-05 19:03       ` John Yates
2021-09-06  4:34         ` Eli Zaretskii
2021-09-07  3:16         ` Richard Stallman
2021-09-07 12:02           ` John Yates [this message]
2021-09-08  3:29             ` Richard Stallman
2021-09-08 12:15               ` Keybinding styles André A. Gomes
2021-09-08 13:18                 ` Eli Zaretskii
2021-09-08 20:37                 ` John Yates
2021-09-09  5:39                   ` Eli Zaretskii
2021-09-15 13:40                     ` André A. Gomes
2021-09-15 14:26                       ` Stefan Kangas
2021-09-15 15:36                       ` Eli Zaretskii
2021-09-15 20:15                       ` Richard Stallman
2021-09-15 21:29                         ` Alexandre Garreau
2021-09-16  5:20                           ` Eli Zaretskii
2021-09-16  5:00                         ` Eli Zaretskii
2021-09-09  3:09                 ` Richard Stallman
2021-09-04 16:05     ` [External] : Re: Gitlab Migration Stefan Kangas
2021-09-04  2:20   ` Drew Adams
2021-09-04 13:14     ` Stefan Monnier
2021-09-04 14:58       ` Drew Adams
2021-09-04 16:10         ` Stefan Monnier
2021-09-04 16:40           ` Drew Adams
2021-09-05 19:27   ` John Yates
2021-09-07  3:16     ` Richard Stallman
2021-09-07 15:31       ` Barry Fishman
2021-09-09  3:07         ` Richard Stallman
2021-09-09 14:07           ` André A. Gomes

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=CAJnXXogQe9ctfLz3aXrMp81cMhvTs_TGcdwVB2rxQCsX42_a5A@mail.gmail.com \
    --to=john@yates-sheets.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=theophilusx@gmail.com \
    /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).