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>, uzibalqa <uzibalqa@proton.me>
Cc: "65913@debbugs.gnu.org" <65913@debbugs.gnu.org>,
	"heimeborgia@protonmail.com" <heimeborgia@protonmail.com>,
	"stefankangas@gmail.com" <stefankangas@gmail.com>
Subject: bug#65913: with-help-window arranges for 'inhibit-read-only' to be set to 't'
Date: Thu, 14 Sep 2023 16:03:56 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488A284AA5BEBCABE664B72F3F7A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83fs3hmk33.fsf@gnu.org>

> In general, there's no need to mention in each and every doc string
> that to learn about some subject you should read the manual where that
> subject is described.  This is trivial, and having to repeat that
> everywhere will just bloat Emacs for no good reason.

Amen.

This is a common request from users, who sometimes
expect a complete answer to their question - aimed
at their particular immediate context/problem - or
a complete understanding of something, to be right
in front of them, at the first page or help msg
they encounter.  And they want it to be aimed at
their particular level of background understanding.

It's an individualistic, "Gimme, gimme, gimme, me!"
approach, naively ignoring the fact that whatever
help they hope to find will likely aim to also help
others, with different backgrounds, questions,
contexts, problems.

I'm guessing this can also come partly from a
frustration from _searching_ as the main - or even
the only - navigation users employ.  Search can be
very good, or very bad.  Some experience/knowledge
are needed to search effectively, as well as good
search tools.

Emacs has good search tools.  The first thing users
should learn is how to Ask Emacs.  The help commands
of course, and later even how to ask using Lisp etc.

A just-what-I-need-right-here-right-now expectation
is a problem for help/documentation in general, but
especially so nowadays, when it's no longer the case
(if it ever was) that readers start at the start of
a book and read sequentially.

Now, more than ever, "Every Page Is Page One".

https://everypageispageone.com/

Readers arrive at a URL by googling or following a
link from somewhere.  Off the web, inside Emacs,
they arrive at an Info node or a *Help* description
directly.

The solution to the "problem" is for every "page"
to provide relevant links to other pages/topics.
Every one.  That way, wherever you start you can
pretty much follow the paths you want, to get the
info you need.

It's not a simple problem with a trivial solution.
Deciding what goes into a given "page"/topic, and
which other topics to link to, is a judgment call
- or more correctly lots of judgment calls.  And
that means that even with the "best" design, for
some set of targeted readers/users, some will be
frustrated.  (Even deciding what the targeted set
of readers should be is non-trivial and involves
compromises.)

A good model of a generally helpful doc system is
Wikipedia.

Emacs help and doc are pretty darn good.  This is
largely because Emacs maintainers - first RMS and
now Eli, in particular - have long been hugely
interested in the help/doc - self-documenting -
feature/aspect of Emacs.  Emacs didn't exactly
invent self-documenting, perhaps, but it nearly
did so.

> Consulting the documentation is one of the
> first lessons that each Emacs user learns,
> and resisting that lesson is not recommended.

Agreed.  There's no excuse for not dipping into
the manuals.  Or for not taking advantage of
other sources: tutorials, videos Q&A venues, etc.
Different users learn differently, of course.

That said, more links from *Help* to manuals
could help, I think.





  parent reply	other threads:[~2023-09-14 16:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 10:41 bug#65913: with-help-window arranges for 'inhibit-read-only' to be set to 't' Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 13:13 ` Eli Zaretskii
2023-09-13 13:26   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 13:56     ` Eli Zaretskii
2023-09-13 14:26       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 14:04   ` Stefan Kangas
2023-09-13 14:46     ` Eli Zaretskii
2023-09-13 14:54       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:21         ` Stefan Kangas
2023-09-13 19:03         ` Eli Zaretskii
2023-09-13 19:16           ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14  4:53             ` Eli Zaretskii
2023-09-14 10:41               ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14 12:50                 ` Eli Zaretskii
2023-09-14 13:17                   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14 16:03               ` Drew Adams [this message]
2023-09-14 16:15                 ` Eli Zaretskii
2023-09-14 16:40                   ` Christopher Dimech
2023-09-14 16:55                     ` Eli Zaretskii
2023-09-14 19:04                       ` Christopher Dimech
2023-09-14 16:29                 ` Christopher Dimech
2023-09-13 14:51     ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:14       ` Stefan Kangas
2023-09-13 15:34         ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 15:51           ` Stefan Kangas
2023-09-13 16:24             ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors

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=SJ0PR10MB5488A284AA5BEBCABE664B72F3F7A@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=65913@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=heimeborgia@protonmail.com \
    --cc=stefankangas@gmail.com \
    --cc=uzibalqa@proton.me \
    /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).