unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 40773@debbugs.gnu.org
Subject: bug#40773: newsticker documentation
Date: Wed, 29 Apr 2020 22:14:59 +0300	[thread overview]
Message-ID: <83d07qxfws.fsf@gnu.org> (raw)
In-Reply-To: <20200429185554.wd2byg5lksp7ngj5@E15-2016.optimum.net> (message from Boruch Baum on Wed, 29 Apr 2020 14:55:54 -0400)

> 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.





  reply	other threads:[~2020-04-29 19:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 15:55 bug#40773: newsticker documentation Boruch Baum
2020-04-28 13:08 ` Ulf Jasper
2020-04-29  4:18   ` Boruch Baum
2020-04-29  7:58     ` Eli Zaretskii
2020-04-29  9:12       ` Boruch Baum
2020-04-29  9:34         ` Eli Zaretskii
2020-04-29 18:55           ` Boruch Baum
2020-04-29 19:14             ` Eli Zaretskii [this message]
2020-04-29 19:25               ` Boruch Baum
2020-04-29 19:13           ` Boruch Baum
2022-02-07  1:19       ` Lars Ingebrigtsen

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=83d07qxfws.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=40773@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    /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).