unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 13571@debbugs.gnu.org
Subject: bug#13571: 24.3.50; doc of `interactive'
Date: Fri, 29 Apr 2016 09:00:59 -0700 (PDT)	[thread overview]
Message-ID: <34ce18af-ab24-46ed-b6e9-911a58ed0e33@default> (raw)
In-Reply-To: <871t5p4blg.fsf@gnus.org>

> > 1. For `v' it should not say "Variable name", even if it also mentions
> > `custom-variable-p'.  It should speak of "option", not "variable".
> > E.g.:
> >
> >  Option: a symbol that is `custom-variable-p'.  The name is read.
> >
> > A user should not need to click `custom-variable-p', or be already
> > familiar with that Lisp predicate, to understand that this reads
> > an option name, not the name of an arbitrary variable.
> 
> I disagree.  Saying that it's a variable helps with understanding here.

No.  There are several kinds of variable in Emacs Lisp.  This is
a very particular kind of variable.  And what is  particularly
special about it (besides being global and dynamic) is that it is
(1) specifically intended for user modification and, in particular,
(2) modification using the Customize UI.

> > 2. There is confusion in the doc string and in (elisp)
> > `Interactive Codes' regarding (a) what a given interactive
> > code reads and (b) what value it returns/provides for the argument.
> >
> > In particular, we misleadingly see mention of "name" here and there.
> >
> > A name is read in such cases, but a name, i.e., a string, is not
> > always what is returned.  In many cases, a symbol is returned.
> > A symbol is a special Lisp object, and definitely not a name.
> > It has a name, as well as other properties.
> >
> > Some of the entries, such as `b', are correct: they read and return a
> > name, not the object named (e.g. a buffer).
> >
> > The following entries incorrectly speak of "name".  They read names, but
> > they return symbols, and the doc is not clear about this.
> >
> > a
> > C
> > v
> > z
> > Z
> 
> All these say that are symbols, and I think that's clear enough.

1. Wrong. z and Z say no such thing (in the doc string).

2. You miss the point, which is made extra clear in the part of
the report that you elided:

  See the entry for `S' in the manual (not the doc string),
  for proper distinction between what is read (a symbol name)
  and what is returned (a symbol).  See also #1 above, for
  another example of possible wording.

If you consult that entry you see this:

  `S'
     An interned symbol whose name is read in the minibuffer.  Terminate
     the input with either `C-j' or <RET>.  Other characters that
     normally terminate a symbol (e.g., whitespace, parentheses and
     brackets) do not do so here.  Prompt.

Very clear.  It reads a name and returns a symbol.  The same
behavior is true for the other codes mentioned in this bug
report, but their descriptions do NOT make this clear.  That's
the bug.

A symbol is an object that has a name.  A name is not a symbol.
A symbol name is read with these codes.  A symbol is not read,
but a symbol is returned.





      reply	other threads:[~2016-04-29 16:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-28  2:21 bug#13571: 24.3.50; doc of `interactive' Drew Adams
2016-04-28 22:23 ` Lars Ingebrigtsen
2016-04-29 16:00   ` Drew Adams [this message]

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=34ce18af-ab24-46ed-b6e9-911a58ed0e33@default \
    --to=drew.adams@oracle.com \
    --cc=13571@debbugs.gnu.org \
    --cc=larsi@gnus.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.
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).