unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jean Louis <bugs@gnu.support>
Cc: emacs-devel@gnu.org, petterih@iki.fi, yandros@gmail.com
Subject: Re: Manual does not mention dictionary.el
Date: Sat, 07 Dec 2024 09:27:27 +0200	[thread overview]
Message-ID: <861pykkl5s.fsf@gnu.org> (raw)
In-Reply-To: <A8023C75-C4F2-4645-9B1B-2D27866E5FEA@gnu.support> (message from Jean Louis on Fri, 06 Dec 2024 22:14:26 +0300)

> Date: Fri, 06 Dec 2024 22:14:26 +0300
> From: Jean Louis <bugs@gnu.support>
> CC: yandros@gmail.com
> 
> >> For me, manuals (texinfo, man pages) are "the" definitive source for 
> >> information about the installed features.  Occasionally I use C-h a too, 
> >> as it often catches things that are not mentioned in manuals.
> >
> >This is not the best practice for Emacs.  The Emacs manuals don't
> >mention all the features, simply because there are too many of them,
> >and mentioning them all will make the manuals impractically large.
> >
> >By contrast, the built-in Help commands will return information about
> >all the features that are either already loaded or auto-loaded.
> >
> 
> As an advocate for clarity and completeness, I believe the Emacs manual should encompass all features of Emacs.

This was never the practice in Emacs, and is basically infeasible.
The Emacs manuals are also printed and sold by the FSF shop, so they
must be of reasonable size.  The ELisp manuals already prints in 2
volumes.  (There are also manuals in doc/misc/, which document large
stand-alone features.)

> By definition, a manual is meant to provide comprehensive guidance, and leaving features undocumented goes against its purpose.

That some variable or command are not in the manual doesn't mean they
are "undocumented", because Emacs includes built-in documentation in
the form of doc strings.

> Emacs is a vast and powerful tool, and its users deserve a reference that covers every aspect of its functionality to truly harness its potential.
> 
> We shall not look for size of manual to be "practical" while avoiding inclusion of useful features.

Again, this is not our policy here, and never has been.

And if you want to preach for fuller documentation, how about if you
start by volunteering to improve its coverage, by making sure every
new variable and function that are added to Emacs get properly
documented in the corresponding manuals?  Because that particular
battlefield in the Emacs development is in sore need of dedicated
volunteers, and the maintainers alone cannot be expected to fill all
that void.

> But what do you mean, practical for what situation?
> 
> Is it for printing maybe?

Yes.



  reply	other threads:[~2024-12-07  7:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11 20:13 Manual does not mention dictionary.el Petteri Hintsanen
2024-10-11 21:35 ` Divya
2024-10-11 22:39   ` Juergen Fenn
2024-10-12  7:21 ` Eli Zaretskii
2024-10-12  9:39   ` Petteri Hintsanen
2024-10-12 18:23     ` chad
2024-10-12 18:32       ` Eli Zaretskii
2024-10-12 21:59         ` Joost Kremers
2024-10-13  5:12           ` Eli Zaretskii
2024-10-14  1:39             ` chad
2024-10-14  7:11               ` Joost Kremers
2024-10-14 14:07                 ` Eli Zaretskii
2024-10-14 13:50               ` Eli Zaretskii
2024-10-14 18:23                 ` chad
2024-10-15  0:46                   ` Michael Heerdegen via Emacs development discussions.
2024-10-15  5:30                     ` chad
2024-10-15 12:20                       ` Eli Zaretskii
2024-10-15 13:14                     ` Eli Zaretskii
2024-11-23 13:13       ` Petteri Hintsanen
2024-11-23 13:51         ` Eli Zaretskii
2024-12-06 19:14           ` Jean Louis
2024-12-07  7:27             ` Eli Zaretskii [this message]
2024-12-06 19:19   ` Jean Louis
2024-12-07  7:29     ` Eli Zaretskii
2024-12-07  7:35       ` Jean Louis

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=861pykkl5s.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=bugs@gnu.support \
    --cc=emacs-devel@gnu.org \
    --cc=petterih@iki.fi \
    --cc=yandros@gmail.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).