unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juanma Barranquero'" <lekktu@gmail.com>
Cc: 8638@debbugs.gnu.org
Subject: bug#8638: 24.0.50; Imenu should not include vacuous defvars
Date: Sun, 8 May 2011 13:03:10 -0700	[thread overview]
Message-ID: <567CCE5B717E445496B4F685457F16AB@us.oracle.com> (raw)
In-Reply-To: <BANLkTind9v3rTpV9LzsZHw-mhoK9J94Rgg@mail.gmail.com>

> 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.






  parent reply	other threads:[~2011-05-08 20:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-08 18:15 bug#8638: 24.0.50; Imenu should not include vacuous defvars Drew Adams
2011-05-08 18:50 ` Juanma Barranquero
2011-05-08 19:07   ` Drew Adams
2011-05-08 19:25     ` Juanma Barranquero
2011-05-08 19:36       ` Drew Adams
2011-05-08 19:46         ` Juanma Barranquero
2011-05-08 19:46           ` Juanma Barranquero
2011-05-08 20:03           ` Drew Adams [this message]
2011-05-08 20:29             ` Juanma Barranquero
2011-05-08 20:39               ` Drew Adams
2011-05-08 20:52                 ` Juanma Barranquero
2011-05-08 21:49                   ` Drew Adams
2011-05-27 16:00     ` Drew Adams
2012-08-05 14:15       ` Chong Yidong
2012-08-05 16:27         ` Drew Adams
2012-08-06  3:43           ` Chong Yidong
2012-08-06  3:52             ` Drew Adams
2011-05-09 14:19   ` Stefan Monnier
2011-05-09 14:31     ` Juanma Barranquero

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=567CCE5B717E445496B4F685457F16AB@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=8638@debbugs.gnu.org \
    --cc=lekktu@gmail.com \
    /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).