From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: obarray Date: Sun, 15 Dec 2013 18:28:03 +0100 Organization: Aioe.org NNTP Server Message-ID: <87zjo2xbur.fsf@nl106-137-194.student.uu.se> References: <87haabq6gl.fsf@nl106-137-194.student.uu.se> <87bo0irj13.fsf@nl106-137-194.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387128616 23365 80.91.229.3 (15 Dec 2013 17:30:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Dec 2013 17:30:16 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Dec 15 18:30:22 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VsFWG-0007hH-3B for geh-help-gnu-emacs@m.gmane.org; Sun, 15 Dec 2013 18:30:20 +0100 Original-Received: from localhost ([::1]:51868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsFWF-0001Su-Nr for geh-help-gnu-emacs@m.gmane.org; Sun, 15 Dec 2013 12:30:19 -0500 Original-Path: usenet.stanford.edu!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 46 Original-NNTP-Posting-Host: VVbyYd/iFZoeWNmD9i++cQ.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:2khtl0WQq8FZrNlFDyt4pRy5hWc= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:202745 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:95014 Archived-At: Barry Margolin 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