From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8638: 24.0.50; Imenu should not include vacuous defvars Date: Sun, 8 May 2011 13:03:10 -0700 Message-ID: <567CCE5B717E445496B4F685457F16AB@us.oracle.com> References: <6A3327809B8B440D99CDCDCED77E9575@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1304885053 21147 80.91.229.12 (8 May 2011 20:04:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 8 May 2011 20:04:13 +0000 (UTC) Cc: 8638@debbugs.gnu.org To: "'Juanma Barranquero'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 08 22:04:07 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QJAD0-0005oX-9C for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 May 2011 22:04:06 +0200 Original-Received: from localhost ([::1]:57111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJACz-0006Iz-9Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 May 2011 16:04:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJACx-0006It-Bx for bug-gnu-emacs@gnu.org; Sun, 08 May 2011 16:04:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJACw-0007lu-Jl for bug-gnu-emacs@gnu.org; Sun, 08 May 2011 16:04:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJACw-0007lo-IM for bug-gnu-emacs@gnu.org; Sun, 08 May 2011 16:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QJACv-0006XH-Tt; Sun, 08 May 2011 16:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 May 2011 20:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8638 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8638-submit@debbugs.gnu.org id=B8638.130488501725093 (code B ref 8638); Sun, 08 May 2011 20:04:01 +0000 Original-Received: (at 8638) by debbugs.gnu.org; 8 May 2011 20:03:37 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QJACW-0006Wg-VJ for submit@debbugs.gnu.org; Sun, 08 May 2011 16:03:37 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QJACU-0006WR-4M for 8638@debbugs.gnu.org; Sun, 08 May 2011 16:03:34 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p48K3PVm011413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 May 2011 20:03:27 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p48K3Ouj001229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 20:03:25 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p48K3JZ4010886; Sun, 8 May 2011 15:03:19 -0500 Original-Received: from dradamslap1 (/10.159.41.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 May 2011 13:03:19 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcwNuLPit31Vr3W/Sf+BKE/xetsgKAAAQh6g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4DC6F710.0054:SCFSTAT5015188,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 08 May 2011 16:04:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46333 Archived-At: > I disagree. IMHO, in a lexical binding package, yes, there are > variable definitions. In some cases the variables are documented in > the docstring of a function or somesuch, but they are real variables > nonetheless. Instead of sweeping them under the carpet, perhaps it > would be better to suggest the programmer to add proper docstrings and > initial values to them. No one is sweeping anything under the carpet. If you want to show them in an Imenu menu, fine; just don't mix them in with definitions that people will want to visit to see doc strings and initial values. That programmers should be encouraged to use doc strings and specify initial values is a separate issue. That does not imply that vacuous defvars should be included in the Variables menu. As a signal to the byte compiler, a vacuous definition is useful - as such. That's what it is for. By definition it should not have an initial value or doc string. That a vacuous definition, like a full one, is now used also to declare a variable special (dynamic scoping) does not mean that vacuous defvars should be included in the Variables menu. Whether a vacuous definition should indicate dynamic scope to the byte-compiler is another question. As you say, in most cases what we want to suggest is that programmers use a full definition for that, instead. But using a vacuous definition to quiet undefined var warnings is legitimate - in that case the programmer does _not_ want to include any initial value. IMO, you are mixing in things that don't belong to this thread. A defvar that is used _only_ as a byte-compiler declaration and not to provide an initial value (and hopefully a doc string) does not belong in the same submenu as full definitions. When you follow a Variables menu entry to its code, you want to see what the code for the variable is. You do not want to see only a vacuous defvar that provides no more information than the menu item itself.