From: Drew Adams <drew.adams@oracle.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Allen Li <vianchielfaura@gmail.com>, 28263-done@debbugs.gnu.org
Subject: bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys
Date: Sun, 18 Feb 2018 16:26:45 -0800 (PST) [thread overview]
Message-ID: <cd8c169f-5c97-449b-829d-abfd091345db@default> (raw)
In-Reply-To: <871shilz7h.fsf@nicolasgoaziou.fr>
> Drew Adams <drew.adams@oracle.com> writes:
>
> > 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.
>
> This is your own interpretation of the two paragraphs in
> the Elisp manual that treat about reserved keys, IMO.
It's my opinion of what Org mode _should_ do.
And it coincides with what other libraries do. And it
fits what the manual suggests.
Your opinion is apparently that Emacs (in the Org-mode
doc) should recommend that users sacrifice those keys
to Org. We disagree about that.
You want Emacs to (1) tell users that these keys are
reserved for them to bind, BUT also to (2) recommend
that if they use Org mode (which most users probably
do now) then they should bind them to Org commands.
I don't want Emacs to do #2. #1 is good; #2 is bad,
and it, in effect, undercuts #1.
In my opinion no library should suggest that users
sacrifice their reserved keys for that library.
Users are free to do that, of course. But it's
impolite, IMO, for a library to recommend that they
do so.
Users aren't stupid - they can figure out, if they
end up using some commands often, that they might
want to bind them to keys, including perhaps to
their reserved keys. They don't need a library to
pitch them that idea. And newbie users might well
get the wrong idea that they really need to follow
that suggestion or they could have a "bad experience".
Libraries that are purely 3rd-party can of course
do anything they like (not that they should, but
they can).
But I'd offer the same opinion for purely 3rd-party
libraries: Don't recommend that users globally bind
their reserved keys for your mode.
Org mode is not only a 3rd-party library. It is
now part of GNU Emacs. All the more reason to be
nice to users.
> Anyway, for the record, I modified Org manual (for Org 9.2) so it
> doesn't assume anymore users followed advice and bound `C-c a', `C-c
> l'... In fact, I removed every reference to user reserved keybindings,
Very good. Thank you for doing the right thing there.
> but one, in the following paragraphs:
>
> For a better experience, the three Org commands ~org-store-link~,
> ~org-capture~ and ~org-agenda~ ought to be accessible anywhere in
> Emacs, not just in Org buffers. To that effect, you need to bind
> them
> to globally available keys, like the ones reserved for users (see
> [[info:elisp::Key%20Binding%20Conventions]]). Here are suggested
> bindings, please modify the keys to your own liking.
>
> #+begin_src emacs-lisp
> (global-set-key "\C-cl" 'org-store-link)
> (global-set-key "\C-ca" 'org-agenda)
> (global-set-key "\C-cc" 'org-capture)
> #+end_src
Not good, IMHO.
And there is _no need_ to mention those keys.
It should be fine and enough to leave off the part
about ", like the ones reserved ... #+end_src."
That part's not needed for users to understand
that if they want global behavior then they can
bind global keys - which is the only message you
need to get across about those commands.
And, once again, those words shamefacedly suggest
that users use those keys. Same problem.
Again:
> > Org should not suggest that users bind keys that
> > are reserved for use by users to Org commands.
Org is widely used. Recommending that users use
those keys for Org is nearly tantamount to no
longer reserving them for users. Not quite as bad
as actually binding them to Org commands on their
behalf (which would clearly contravene the guideline),
but almost as bad.
And totally unnecessary.
> I dare to think this is a good enough advice to belong to the manual,
> with enough safeguards to let users know what it entails. I also think
> it is fair, because the manual doesn't talk about these bindings anymore
> later on.
I'm on record, at least, as disagreeing with that.
One opinion.
Anyway, thank you for no longer having the rest of
the Org manual depend on the assumption that users
have sacrificed those keys to Org.
Perhaps someday someone else will finish the job by
removing the manual's suggestion that they should
make that sacrifice, "for a better experience".
next prev parent reply other threads:[~2018-02-19 0:28 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
2017-12-06 20:09 ` bug#28263: " Allen Li
[not found] ` <871shilz7h.fsf@nicolasgoaziou.fr>
2018-02-19 0:26 ` Drew Adams [this message]
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=cd8c169f-5c97-449b-829d-abfd091345db@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).