unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Recent changes in parsing.texi
Date: Mon, 26 Dec 2022 01:44:15 -0800	[thread overview]
Message-ID: <9313F78F-DEF4-45F0-BD2C-96870D97BE85@gmail.com> (raw)
In-Reply-To: <83k02f2tnk.fsf@gnu.org>



> On Dec 25, 2022, at 11:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sun, 25 Dec 2022 10:54:17 -0800
>> Cc: emacs-devel@gnu.org
>> 
>>> If a symbol appears in some @defXX directive, there's no need for a
>>> separate @cindex entry, since @defXX does that automatically.  (Also,
>>> I mistakenly used @cindex where I should have used @vindex; fixed.)
>>> 
>>> I added these index entries because these variables didn't seem to
>>> appear in any @defXX directive, nor had any existing index entries.
>>> If I missed something, please tell.
>> 
>> Thanks, I was actually just asking for confirmation of my understanding. Because my impression of vindex was that they mark the paragraph introducing and defining the variable. Basically you need to add it if you use a plain paragraph instead of defar to introduce that variable. And your change seem to imply we need to index every occurrence of a variable.
> 
> The @vindex marks the place where the variable is documented to its
> fullest.  There should be just one such place, and all the other
> places where the variable is mentioned should have cross-references to
> that full description.  With one exception: if you document some very
> special and particular aspect of the variable in a different place,
> that place should have its own @vindex qualified by the aspect.  For
> example:
> 
>  @vindex foobar@{, using in empty buffers}
> 
> (You need the @r{..} thingy in @vindex and @findex because otherwise
> the entire text of these index entries is typeset as if it were in
> @code; @cindex doesn't need @r{..}.
> 
>> Just to clarify, do I need to add @vindex bbb in the following case? (Ie, do I need to index every occurrence of a variable, or do I only need to index where it is defined?
> 
> Only index the full description of the variable, of which there should
> be just one in the entire manual.  If there's no description, then
> index the best approximation to it, i.e. the one place where you say
> the most about it.

Thanks a bunch! I fully understand it now.

Yuan


      reply	other threads:[~2022-12-26  9:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-25  7:30 Recent changes in parsing.texi Eli Zaretskii
2022-12-25  8:27 ` Yuan Fu
2022-12-25  9:08   ` Yuan Fu
2022-12-25  9:36     ` Eli Zaretskii
2022-12-25 18:54       ` Yuan Fu
2022-12-25 19:02         ` Eli Zaretskii
2022-12-26  9:44           ` Yuan Fu [this message]

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=9313F78F-DEF4-45F0-BD2C-96870D97BE85@gmail.com \
    --to=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@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).