unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 30530@debbugs.gnu.org, mail@nicolasgoaziou.fr
Subject: bug#30530: 26.0; Emacs manual: mention (1) user-reserved keys, (2) users can bind any	keys
Date: Fri, 2 Mar 2018 07:17:14 -0800 (PST)	[thread overview]
Message-ID: <c6ddbec3-e423-496e-a77c-93c185f34110@default> (raw)
In-Reply-To: <<83woyvvy8g.fsf@gnu.org>>

> > > > The Emacs doc makes clear that these keys are reserved for users.
> > >
> > > Being reserved means that users can bind them.
> >
> > You keep repeating that, but it has never been in question.
> 
> You are questioning that, by insisting that no document can
> suggest binding those keys.

Not at all.  It is fine for the Emacs and Elisp manuals to
point out that users can bind these keys and that the keys
are reserved for them.

That's in fact the point of this bug report: to make that
message even more clear than it has been, by bringing it
to the attention of readers of the Emacs manual.

It is a message not just for library writers (which is
why it is in the Elisp manual).  It is a message for
end users - it's about keys reserved for _them_ (so it
belongs also in the Emacs manual).

Same goes for blogs and other documents.  Same also for
the doc of a library.  Reminding users that these keys
are reserved for their use - however they might want to
bind them - is _always_ a good thing.

That's not the same thing as the doc of a library that
most Emacs users use, and that is often the gateway to
starting to use Emacs, telling users that they should
bind these keys _for that library_, for best results.

That is tantamount to the Emacs manual or tutorial
telling users that these keys are reserved for users
(good) BUT that Emacs recommends that they bind some
of them to Org commands (bad).  That's misleading,
confusing, and not helpful, IMO.

And there's no need for it.  It is enough for any doc,
including the Org doc, to simply remind users that
they can bind any of these keys without worry that
some library will change them.

We should not start Emacs users off with a suggestion
that they bind such keys for Org (or anything else).

Or if we really think (I don't) that that's the way
to start using Emacs then Org should bind those keys
by default.  In that case, there would be no pretense
of reserving them.  (Users could still, of course,
bind them.)

Either the keys are reserved for users or they are
not.  IMHO, the _single_ message about these keys
from Emacs to users (especially new users) should
be the message that these keys are reserved for
their use.  End of story.

That message should not be diluted and confused
by a second message that for best results you are
nevertheless encouraged to bind many such keys to
Org commands.





  parent reply	other threads:[~2018-03-02 15:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<f630bd00-a129-48ec-8788-2ed09964b598@default>
     [not found] ` <<83lgfi4qw2.fsf@gnu.org>
2018-02-24 17:00   ` bug#30530: 26.0; Emacs manual: mention (1) user-reserved keys, (2) users can bind any keys Drew Adams
2018-02-24 17:44     ` Eli Zaretskii
2018-02-24 21:27       ` Nicolas Goaziou
2018-03-01 15:44         ` Eli Zaretskii
     [not found]       ` <<87zi3y13jf.fsf@nicolasgoaziou.fr>
     [not found]         ` <<83d10nyf4y.fsf@gnu.org>
2018-03-01 17:31           ` Drew Adams
2018-03-01 19:22             ` Eli Zaretskii
2018-03-01 19:30               ` Noam Postavsky
     [not found]       ` <<<87zi3y13jf.fsf@nicolasgoaziou.fr>
     [not found]         ` <<<83d10nyf4y.fsf@gnu.org>
     [not found]           ` <<92c8fd97-8e96-4e2b-8706-f5ca97869912@default>
     [not found]             ` <<831sh3y51x.fsf@gnu.org>
2018-03-01 21:00               ` Drew Adams
2018-03-01 21:33                 ` Noam Postavsky
2018-03-02  5:32                 ` Eli Zaretskii
     [not found]       ` <<<<87zi3y13jf.fsf@nicolasgoaziou.fr>
     [not found]         ` <<<<83d10nyf4y.fsf@gnu.org>
     [not found]           ` <<<92c8fd97-8e96-4e2b-8706-f5ca97869912@default>
     [not found]             ` <<<831sh3y51x.fsf@gnu.org>
     [not found]               ` <<eea83f2b-2dea-49c6-941d-5db34a741a5d@default>
     [not found]                 ` <<83woyvvy8g.fsf@gnu.org>
2018-03-02 15:17                   ` Drew Adams [this message]
2018-03-02 15:49                     ` Eli Zaretskii
2018-02-19 16:16 Drew Adams
2018-02-24 10:35 ` Eli Zaretskii

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=c6ddbec3-e423-496e-a77c-93c185f34110@default \
    --to=drew.adams@oracle.com \
    --cc=30530@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /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).