emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Allen Li <vianchielfaura@gmail.com>
Cc: Nicolas Goaziou <mail@nicolasgoaziou.fr>, 28263-done@debbugs.gnu.org
Subject: bug#28263:  bug#28263: 24.5; Org: `C-c LETTER' keys
Date: Wed, 6 Dec 2017 07:23:07 -0800 (PST)	[thread overview]
Message-ID: <c6cdf0b9-b15e-407c-a0f6-784757b6719b@default> (raw)
In-Reply-To: <CAJr1M6fBapQ_6agwT71gQu1zv0Op0pseL1GuC5Yow2KWjzcdcA@mail.gmail.com>

> Could you summarize how you think the situation could be improved in
> one or two sentences?
> 
> I think what you are trying to say is, Org mode should make global
> key bindings for some commands.

No.  I'm saying that Org should not suggest that users bind
keys that are reserved for use by users to Org commands.

And it should not then present those keys in the doc.

And it should not say anything about the doc using those
keys for illustrative purposes or assuming that users
have bound those keys.

Org should do _nothing_ with such reserved keys.  It
should not mention them at all in its doc.

If Org wants to recommend or suggest that users bind some
particular commands to keys, including to prefix keys, it
can do that.  But don't mention any particular keys
(preferably), and certainly do not suggest using any
particular keys.

*IF* Org feels that certain commands should definitely be
bound globally *THEN* (1) it should present that as a
concrete proposal to emacs-devel for consideration and
(2) if agreed on, Org should just bind those keys globally.

That's Org's decision.  I'm not in any way suggesting
that Org should bind global keys.  In fact, I hope it
does not do so.  But I can't decide what's best for
everyone here.  Maybe some global keys should be
sacrificed for Org.  I doubt it, but maybe Emacs Dev
would decide that that's appropriate.

What Org does now is, IMO, a shame-faced way of getting
a bunch of keys bound globally for its purposes, without
actually binding them.  And what's more, the keys in
question are keys that are always reserved for users.
That's not right.

> However, this is problematic because there are pretty much no global
> keys available that are not reserved for major modes, minor modes, or
> the user,

Tough.  We're all in that boat.  (And anyway, it's not true
in such absolute terms.)  That's the whole point of
reserving keys - to prevent things like Org from gobbling
them all up.

And nothing prevents Org from defining a minor mode that
it intends all Org users to use all the time - in effect
providing a whole new space for its "global" key bindings.

(Not `org-mode', of course, if you want the keys available
even when Org mode is turned off.)

> and at any rate I don’t think we could justify binding
> global keys by default since Org mode is a pretty small application
> within Emacs.  calendar.el does not have a global key.  remember.el
> does not have a global key.  et cetera.  Org mode is no different.

Exactly.  Please follow their example: Don't suggest to
users to bind keys reserved to them to Org commands.

> If we make an Org minor mode, that’s really no better than the user
> just binding his own keys vs turning on the minor mode.

Defining such a minor mode is exactly the way to go, to
get pretty much global behavior without locking in keys
to the absolutely global `global-map'.

Turning on a minor mode that binds keys in its keymap
_is_ a bit like binding your own keys globally.  The
difference is that they are not bound globally.  In
both cases the user makes the choice.  But in one
case the user does not (and ALL users do not) sacrifice
the global keys reserved for users.

Turn the mode on to get its bindings.  Turn it off
to be rid of its bindings.  That's the clean Emacs
way to handle such things. Sneakily recommending to
users that they bind keys reserved for users to Org
commands is not right.  It's not fair to users, most
of all.  And it's not fair to other modes and the
rest of Emacs.  You might say it's "orgocentric".


> Also, the
> reserved minor mode keys are not very good (hard to press), and they
> can conflict with other minor modes, which is probably undesirable for
> Org users.

Tough.  We all live with it.  Emacs is not only for Org.

And in any case, you can put any number of keys on a
prefix key.  And there are plenty of prefix keys that
are not reserved for users.

> Is your complaint simply that we suggest a key for the user to bind?

See above.  If you take the approach of suggesting a key
to bind, it should not be a key that is reserved for users.

This really shouldn't be hard to understand.  Please see
how other packages/modes deal with it.

Yes, key sequences are a limited resource.  For _all_ of us.
For all of Emacs and for all users.  If Org is just starting
to realize this and play fair then it's about time.

  reply	other threads:[~2017-12-06 15:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <936768a0-1a2e-4a89-8a11-8f1779f8591d@default>
2017-12-04 21:45 ` bug#28263: 24.5; Org: `C-c LETTER' keys Nicolas Goaziou
2017-12-04 22:42   ` Drew Adams
2017-12-05 11:28     ` Nicolas Goaziou
2017-12-05 15:15       ` Drew Adams
2017-12-06  7:58         ` bug#28263: " Allen Li
2017-12-06  7:59         ` Allen Li
2017-12-06 15:23           ` Drew Adams [this message]
2017-12-06 20:09             ` bug#28263: " Allen Li
     [not found]             ` <871shilz7h.fsf@nicolasgoaziou.fr>
2018-02-19  0:26               ` Drew Adams
2018-02-19  9:24                 ` Nicolas Goaziou
2018-02-19 16:21                   ` Drew Adams
2018-02-20  0:38                     ` Nicolas Goaziou

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.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6cdf0b9-b15e-407c-a0f6-784757b6719b@default \
    --to=drew.adams@oracle.com \
    --cc=28263-done@debbugs.gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    --cc=vianchielfaura@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/org-mode.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).