bug#40773: newsticker documentation

[Eli Zaretskii]

> Date: Wed, 29 Apr 2020 14:55:54 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: ulf.jasper@web.de, 40773@debbugs.gnu.org
> 
> > Then I don't understand the rationale for removing the entries from
> > there.  What useful purpose would that serve?
> 
> It manages and guides users' expectations. Emacs should have a single
> authoritative manual, and users should feel confident that they can turn
> to a single place for the comprehensive documentation. When you
> partially duplicate components in a second place, you confuse beginner
> users as to where to turn for documentation.
> 
> If it were up to me, the entire Emacs section for M-x info would have just
> three entries:
> 
> Emacs
> * The emacs manual             All the features of the default emacs
> * Your emacs extensions        Docs for the add-ons you've installed
> * Other emacs help             Ways to quickly find information

What you describe is very different from how the Info system is
supposed to be used.  We have commands like info-apropos and
info-display-manual and info-lookup to free us from the need to browse
the top-level Info directory menu.  That's because starting from DIR
implies a top-down search for what you want, and that is very
inefficient.  The DIR node also tends to be very large if you have
many manuals installed.  For example, installing GNU Coreutils will
cause DIR to have an entry for every command in that package, and
installing glibc will have an entry for every standard C library
function there.  That's why Info have commands to land you where you
want to be, either directly or in a very small number of steps.

Basically, an efficient use of Info should cause you to seldom if ever
look at DIR; I don't remember when I last looked at it on my system,
and I use Info every day.  DIR exists to help Info commands find what
I'm looking for, not for me to read through it, certainly not
frequently.

So maybe we should improve the Info commands and the databases they
use to make the various packages described in separate manuals more
discoverable, but the specific measures you propose look to me like
steps in the wrong direction.