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>
Cc: 11178@debbugs.gnu.org, cyd@gnu.org
Subject: bug#11178: 24.0.94; Elisp manual: add index entries for :link LINK-DATA alternatives
Date: Wed, 11 Apr 2012 13:34:45 -0700	[thread overview]
Message-ID: <D7C740E12CB34809AED64E67C710F36F@us.oracle.com> (raw)
In-Reply-To: <83y5q23vu0.fsf@gnu.org>

> > Again, you are talking about indexing _topics_.  I am 
> > talking about _reference_ index entries.
> 
> We've been through this before, Drew, and we already established that
> your views about indexing are not shared.  Bringing that up again
> won't change that.

There you go again, Eli, generalizing and ad hominem ad nauseum.

Apparently "my views" related to this bug report _are_ shared when it comes to
button properties, functions, etc. - those are all indexed individually by name.

You just do not agree that link alternatives should be handled the same way.  It
would be fair enough to say that (we can disagree), but you do not.  

Instead, you cast this as being about some purported general "view" of mine.
No, it's about the question posed by the bug report: indexing the individual
link alternatives, which are specific Emacs-Lisp symbols/sexps.

As for "bringing it up again won't change that": Again, you are generalizing,
caricaturing, and ignoring the particular request.  I have never before brought
up this request.

And I understood as soon as Yidong said "That makes no sense" that the request
would likely not be fulfilled.  His reason, that there was already a topic entry
for adding links to custom docs, does not at all address the need expressed -
this bug report.  Your independent request for adding more topic entries does
not address it either.

So I explained the difference, using a particular button property (_not_ the
topic of button properties) as an example of how we do typically DTRT.
Functions that are mentioned in the manual are indexed under their names, in
addition to being indirectly indexed via topics where they are mentioned.
Likewise button properties and other entities.  Not so link alternatives.  

That is this bug.  It has nothing to do with wanting more topic entries about
links or linking.
 
> > If a user wants to look up the particular button property 
> > `follow-link', she does `i follow-link' and Bob's an uncle.
> >
> > This is about looking up a particular :link alternative,
> > such as `emacs-commentary-link'.  It is not about looking
> > up the topic of "links to documentation for customization items".
> 
> She can also do 'i link TAB', see "link, customization keyword" and
> Bob's her uncle.  IOW, if she already knows she's after follow-link,
> she'll have no trouble finding it.

Still missing the point, Eli.  `follow-link' is the example of a case where we
do DTRT: the `follow-link' button property is indexed as such, not only
indirectly via topics (such as "button properties") where it is mentioned.

It's about indexing the particular, literal reference term: `follow-link' in the
case of the button property (done), and `emacs-commentary-link' in the case of
the link alternative (not done).






      reply	other threads:[~2012-04-11 20:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 22:24 bug#11178: 24.0.94; Elisp manual: add index entries for :link LINK-DATA alternatives Drew Adams
2012-04-11  6:18 ` Chong Yidong
2012-04-11  6:27   ` Drew Adams
2012-04-11  8:13     ` Eli Zaretskii
2012-04-11 17:37       ` Drew Adams
2012-04-11 19:35         ` Eli Zaretskii
2012-04-11 20:34           ` Drew Adams [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=D7C740E12CB34809AED64E67C710F36F@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11178@debbugs.gnu.org \
    --cc=cyd@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).