From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: obarray
Date: Sun, 15 Dec 2013 18:28:03 +0100 [thread overview]
Message-ID: <87zjo2xbur.fsf@nl106-137-194.student.uu.se> (raw)
In-Reply-To: barmar-576B72.00585915122013@news.eternal-september.org
Barry Margolin <barmar@alum.mit.edu> writes:
> And many symbols that are variables are just local
> variables internal to functions (not to be confused
> with buffer-local variables); these shouldn't show up
> in describe-variable.
As in what you get with `let', `labels', and the defun
parameters?
> That's why the completing-read collection that
> describe-variable uses checks whether the symbol is
> bound or has a variable-documentation property.
Of course, in describe-variable, they define a variable
as:
- in obarray (always)
- is bound (`boundp') *and* is not a :keyword
(`keywordp'), *or*
- has variable-style documentation (definition 1)
Then, "v", in the interactive string, a variable is
"[a] symbol that is `custom-variable-p'." (2)
For my purposes, (1) is better, which makes sense since
my defun implements a (small) subset of
describe-function (instead the difference is how the
data is communicated with less noise, faster).
But: Why is (2) used in the interactive string? Is
there an advantage to (1) in this setting, *or* is this
something that just "is"? If (1) is a sensible
definition, is it all the same uncommon (as there is no
`is-variable-p' or the like, to encapsulate it, *and*
there is no way to get it into the interactive string
without this sort of big workaround)?
I don't say we should change describe-variable for
aesthetic purposes (surest way to break functional
code) but it is interesting if this is something that
"happened" or if anyone can see something beneath.
--
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united: http://user.it.uu.se/~embe8573
next prev parent reply other threads:[~2013-12-15 17:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-15 0:54 obarray Emanuel Berg
2013-12-15 1:14 ` obarray Juanma Barranquero
[not found] ` <mailman.9268.1387070101.10748.help-gnu-emacs@gnu.org>
2013-12-15 1:37 ` obarray Emanuel Berg
2013-12-15 1:56 ` obarray Michael Heerdegen
2013-12-15 1:59 ` obarray Juanma Barranquero
[not found] ` <mailman.9271.1387072648.10748.help-gnu-emacs@gnu.org>
2013-12-15 4:17 ` obarray Emanuel Berg
2013-12-15 4:17 ` obarray Barry Margolin
2013-12-15 4:47 ` obarray Michael Heerdegen
2013-12-15 4:55 ` obarray Emanuel Berg
2013-12-15 6:04 ` obarray Barry Margolin
2013-12-15 17:43 ` obarray Emanuel Berg
2013-12-16 17:44 ` obarray Barry Margolin
2013-12-17 1:47 ` obarray Michael Heerdegen
[not found] ` <mailman.9442.1387244871.10748.help-gnu-emacs@gnu.org>
2013-12-17 2:11 ` obarray Emanuel Berg
2013-12-17 2:55 ` obarray Michael Heerdegen
[not found] ` <mailman.9452.1387248989.10748.help-gnu-emacs@gnu.org>
2013-12-17 3:01 ` obarray Emanuel Berg
2013-12-17 17:32 ` obarray Barry Margolin
2013-12-17 17:42 ` obarray Emanuel Berg
[not found] ` <mailman.9279.1387082898.10748.help-gnu-emacs@gnu.org>
2013-12-15 5:11 ` obarray Emanuel Berg
2013-12-15 5:36 ` obarray Emanuel Berg
2013-12-15 6:17 ` obarray Michael Heerdegen
[not found] ` <mailman.9283.1387088419.10748.help-gnu-emacs@gnu.org>
2013-12-15 17:51 ` obarray Emanuel Berg
2013-12-15 6:15 ` obarray Michael Heerdegen
[not found] ` <mailman.9282.1387088166.10748.help-gnu-emacs@gnu.org>
2013-12-15 17:47 ` obarray Emanuel Berg
2013-12-15 5:58 ` obarray Barry Margolin
2013-12-15 17:28 ` Emanuel Berg [this message]
2013-12-17 14:38 ` obarray jack-mac
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=87zjo2xbur.fsf@nl106-137-194.student.uu.se \
--to=embe8573@student.uu.se \
--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).