unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 29400-done@debbugs.gnu.org
Subject: bug#29400: 26.0; Add Elisp manual index entry for `defvar' to node `Compiler Errors'
Date: Fri, 24 Nov 2017 08:54:39 -0800 (PST)	[thread overview]
Message-ID: <f6b9ee9f-e49a-4d7d-9af8-12fb6f3af11d@default> (raw)
In-Reply-To: <<83a7zbagbk.fsf@gnu.org>>

> > Node `Compiler Errors' seems to be the only place in the Elisp manual
> > where we tell users that you can use a vacuous `defvar' (no value) to
> > suppress a byte-compiler warning about it not being defined.
> >
> > But this node has no index entry - at least none that has the word
> > `defvar' in it.  Please add such an entry.
> 
> I added some index entries, 

Thank you.

> but I don't understand why you wanted an
> index entry with "defvar" in it.  A reader who will look for "defvar"
> when they want to find ways of suppressing compiler warnings already
> knows that defvar is used for that purpose, so why would they use such
> a topic at Info-index's prompt?

To find exactly what the manual says about it.

You might know that some Java method is what you want,
but you might want to consult the Java doc again for
details.  Just because you know something about
something that is in the manual doesn't mean that you
never want to check the manual about it again.

Or you might want to get to the doc to be able to point
someone else to it (URL or manual+node-name).  I often
point users to sections of the manual.  And in this
case looking up `defvar' in the index is the first
thing I would do.

Imagining that someone who knows that `defvar' can be
used to suppress some compiler warnings should never
want or need to find where this is covered in the
manual by checking `defvar' in the index suggests a
narrow understanding of indexing - which is not
normally what you show.

> That's the opposite of what good
> index entries should provide -- they should _lead_ to defvar's
> description as the way to suppress warnings when the reader thinks of
> "warnings" or some such.

Looking in the index for `warning' is not the only
reasonable way to use an index for this - see above.

> > And please either add the same info (about this use of a vacuous
> > `defvar') to node `Defining Variables' or add a cross-reference from
> > that node to node `Compiler Errors'.
> 
> Done.

Thanks.





       reply	other threads:[~2017-11-24 16:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<f03d7e3c-b121-4aad-bc5c-1f4a8fba506f@default>
     [not found] ` <<83a7zbagbk.fsf@gnu.org>
2017-11-24 16:54   ` Drew Adams [this message]
2017-11-24 17:10     ` bug#29400: 26.0; Add Elisp manual index entry for `defvar' to node `Compiler Errors' Eli Zaretskii
     [not found] <<<f03d7e3c-b121-4aad-bc5c-1f4a8fba506f@default>
     [not found] ` <<<83a7zbagbk.fsf@gnu.org>
     [not found]   ` <<f6b9ee9f-e49a-4d7d-9af8-12fb6f3af11d@default>
     [not found]     ` <<83wp2f8uwr.fsf@gnu.org>
2017-11-24 17:39       ` Drew Adams
2017-11-22 16:50 Drew Adams
2017-11-24 14:42 ` Eli Zaretskii

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=f6b9ee9f-e49a-4d7d-9af8-12fb6f3af11d@default \
    --to=drew.adams@oracle.com \
    --cc=29400-done@debbugs.gnu.org \
    --cc=eliz@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 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).