From: Jean Louis <bugs@gnu.support>
To: Drew Adams <drew.adams@oracle.com>
Cc: Gregory Heytings <gregory@heytings.org>,
"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
Date: Wed, 10 Feb 2021 14:30:41 +0300 [thread overview]
Message-ID: <YCPD4XlcRgZwFxHi@protected.rcdrun.com> (raw)
In-Reply-To: <SA2PR10MB4474B86095BA434AE266A217F38E9@SA2PR10MB4474.namprd10.prod.outlook.com>
* Drew Adams <drew.adams@oracle.com> [2021-02-09 20:14]:
> > So I think there is no need to reserve more keys for third party
> > packages. Finally, keys are limited.
>
> The question is not about reserving keys
> for 3rd-party use _from users_. It's about
> reserving them from Emacs itself, i.e., so
> they don't become new _default_ bindings.
Sure I understand that. The point from me was that those keys reserved
for users can be advised for use by third party packages just as the
Org mode does it. In my opinion there is no problem there. Org mode
suggests users to bind let us say {C-c c} for `org-capture' and so
many do. In the same way can do also other packages.
Such keys are then not bound by the package automatically but reserved
for users.
For example I do not mind pressing {C-x v v} for version control, so I
would not mind typing {C-c o KEY} for org related functions. Then
maybe piece of artificial intelligence or simple description in the
package would advise me to set `C-c o' as a prefix for org related
functions, and I would be set.
Then for magit I could set `C-c m' as magit related prefix and I could
use anything there like {C-c m g} or anything. Though I do not use
magit. It is example.
So maybe people discuss here about keys to be reserved for automated
bindings, to let the package authors decide which key to bind that
will not conflict with any of Emacs keys and none of user defined
keys.
I see that those keys reserved for users should be suggested by
packages. Like package could say "Use one of F5-F9 as prefix key for
Magit"
Using Super key like that key between Control and Aternative Control
that may have Windoze logo on it is very handy on X, but not so handy
in console. It may not work without special setups. If some automated
solution is found in Emacs for Super key to work in console the same
as in X, then that could be door to opening many new keys for
reservations.
General problem is that Emacs needs many keys. I would like having the
keyboard with more modifiers.
Jean
next prev parent reply other threads:[~2021-02-10 11:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-08 22:01 ` Francis Belliveau
2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 8:36 ` "Windows" key [was: Repurpose one key and reserve it for third-party] packages tomas
2021-02-10 22:54 ` PROPOSAL: Repurpose one key and reserve it for third-party packages Francis Belliveau
2021-02-09 6:31 ` Jean Louis
2021-02-09 9:13 ` Gregory Heytings
2021-02-10 11:17 ` Jean Louis
2021-02-09 17:13 ` [External] : " Drew Adams
2021-02-09 17:49 ` Gregory Heytings
2021-02-09 18:12 ` Drew Adams
2021-02-09 19:23 ` Gregory Heytings
2021-02-09 20:52 ` [External] : " Drew Adams
2021-02-09 21:15 ` Gregory Heytings
2021-02-09 21:47 ` [External] : " Drew Adams
2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 22:58 ` Drew Adams
2021-02-09 23:23 ` Drew Adams
2021-02-09 23:48 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 9:05 ` Robert Thorpe
2021-02-10 14:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 14:59 ` Gregory Heytings
2021-02-10 11:33 ` [External] : " Jean Louis
2021-02-10 11:41 ` Thibaut Verron
2021-02-10 15:29 ` Eli Zaretskii
2021-02-10 11:30 ` Jean Louis [this message]
2021-02-09 8:13 ` Marcin Borkowski
2021-02-09 9:13 ` Gregory Heytings
[not found] <7ef75c33936136eb3a20@heytings.org>
[not found] ` <8735y56naf.fsf@posteo.net>
[not found] ` <8ed9b43502ae9a36b057@heytings.org>
[not found] ` <87tuqk6d9d.fsf@posteo.net>
[not found] ` <3966473cc1ab9f104724@heytings.org>
2021-02-10 23:35 ` Philip K.
2021-02-11 8:45 ` Gregory Heytings
2021-02-11 13:53 ` Philip K.
2021-02-11 15:59 ` Gregory Heytings
2021-02-11 16:59 ` [External] : " Drew Adams
2021-02-11 16:58 ` Drew Adams
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=YCPD4XlcRgZwFxHi@protected.rcdrun.com \
--to=bugs@gnu.support \
--cc=drew.adams@oracle.com \
--cc=gregory@heytings.org \
--cc=help-gnu-emacs@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.
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).