RE: Have you all gone crazy? Was: On being web-friendly and why info must die

[Drew Adams <drew.adams@oracle.com>]

>  > >  > she wants to read about "cut and paste".
> 
>  > > You mean 12.3 “Cut and Paste” Operations on Graphical Displays
>  > > right?  I agree that the *user* wants to be there, but I'm not
>  > > sure *we* want her to be there.  In particular, on "i cut" I 
>  > > would be very tempted to land her in the parent, "Killing and
>  > > Moving Text".
>  >
>  > Irrelevant to this discussion.
> 
> Look who's talking!

Sigh.  ad hominem (again).  Please point to one thing I've said
here that is irrelevant to this discussion - but off list, as
that too is irrelevant here.  Stick to arguments about the topic.
The topic is not me or you.

> But no, this *is* relevant to this discussion.  The point (which
> was made explicitly) is that Eli and I disgree on "the right" node
> for the index;

No, that is not the point.  If you think a different node is more
appropriate, file a bug report.  Eli is not right all the time. ;-)

But what is this about "the right node" for "cut"?  Do you think
there is or should be only one?

Most manually defined indexes allow for multiple targets for the
same index entry, although it is usually helpful to qualify them
using secondary entries.

Simply "cut" as input and index entry could point to several places
in the Emacs manual.  Preferably they would be qualified, to help
you decide which is closer to what you are looking for.

And lo and behold, so there are.  Already.  There are several
such related "cut" index entries:

cut                   - "Cut and Paste" Operations on Graphical Display
cut and paste         - Glossary
cutting text          - Deletion and Killing
X cutting and pasting - Cut and Paste with Other Window Applications

(The last one does not appear for vanilla Emacs `i cut' completion,
but it does for Icicles and probably other completion enhancers.)

Those designing indexes make judgment calls, yes.  And you might
disagree with any given judgment, yes.  Likewise, search-engine
scoring.

> in such cases Google style "implicit" indexing based on user
> behavior which provides a variety of choices may be more useful
> than Info-style indexing based on focused choices by knowledgeable
> editors.

No one denies that full-text search indexing can be useful.

And manually designed indexes provide "a variety of choices" as well.

In this particular case, googling - just entering "emacs cut" -
returns this as the only hit for the Emacs manual: `"Cut and Paste"
Operations on Graphical Display'.  (The same hit that you ended
up at by `i cut RET'.)  That is the only hit for the Emacs manual
among the first 20 pages (200 hits), at least.

However, to be fair, if you google "emacs manual cut" then you do
get much better results.  There are 5 hits among the first 10 that
target www.gnu.org for the manual, one of which is the "Cut and
Paste" node.  And yes, there are 2 hits among the first 10 that
target your prefered node (but not at gnu.org).

Anyway, the point is not that googling cannot help you find
information about Emacs - including information that is in the
manual.  The point is that we need not (and should not) choose
only one or the other.

You have both available, right now.  And if you find that for some
information in the manual `i' doesn't cut the mustard and googling
does a better job, then please do file a bug report.