unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Dimech <dimech@gmx.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>, uzibalqa <uzibalqa@proton.me>,
	"heimeborgia@protonmail.com" <heimeborgia@protonmail.com>,
	"stefankangas@gmail.com" <stefankangas@gmail.com>,
	"65913@debbugs.gnu.org" <65913@debbugs.gnu.org>
Subject: bug#65913: with-help-window arranges for 'inhibit-read-only' to be set to 't'
Date: Thu, 14 Sep 2023 18:29:33 +0200	[thread overview]
Message-ID: <trinity-f1d23a23-3e7a-4b1e-8382-1a2bfa26bfc8-1694708973359@3c-app-mailcom-bs10> (raw)
In-Reply-To: <SJ0PR10MB5488A284AA5BEBCABE664B72F3F7A@SJ0PR10MB5488.namprd10.prod.outlook.com>


> Sent: Friday, September 15, 2023 at 4:03 AM
> 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'
>
> > 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.

Functioning autonomously in the whole point actually.  I support the
capability of being able to access to whatever might be needed in an
automated way for every function.  A function should have a list of
associations that are relevant to that function and have the capability
of giving you that information.


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

At least it should tell you what you wight need no know to
fully take advantage of the capabilities of that function.

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

Or a separate tool.

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

In many situation, compromises meant that valuable information is missing
and never included.   Instead of deciding the targeted set of readers,
tools should be as broad as they can ever be.  Because one might not know
presumptively what they might need.  Particularly when some function inplements
some convenient shortcuts.

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

The excuse is that one can look at whatever you are saying,
only to find out that it was all a waste of time.  For instance,
would one go through the Xah Talk Shows or go through the EmacsConf
or Libre Planet talks unless you are sure it will be useful ? I don't
think so !

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






  parent reply	other threads:[~2023-09-14 16:29 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
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 [this message]
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=trinity-f1d23a23-3e7a-4b1e-8382-1a2bfa26bfc8-1694708973359@3c-app-mailcom-bs10 \
    --to=dimech@gmx.com \
    --cc=65913@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --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).