all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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

* 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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.