From: Eli Zaretskii <eliz@gnu.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: stefankangas@gmail.com, 68963@debbugs.gnu.org
Subject: bug#68963: 30.0.50; [PATCH] Split Eshell built-in command documentation into subsections
Date: Thu, 08 Feb 2024 09:07:16 +0200 [thread overview]
Message-ID: <867cjfxwm3.fsf@gnu.org> (raw)
In-Reply-To: <aa3d7387-5ad6-e4bd-66a0-08e5c55695be@gmail.com> (message from Jim Porter on Wed, 7 Feb 2024 18:05:07 -0800)
> Date: Wed, 7 Feb 2024 18:05:07 -0800
> Cc: 68963@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
>
> On 2/7/2024 12:22 PM, Stefan Kangas wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> But then subdivision into sections has other problems. For example,
> >> who says that 'ls' is only "for directories", ln, mv, and rm are only
> >> "for files", and info is "for searching"? A person can reasonably
> >> think about these (and others) differently. And why "basename" is not
> >> about files?
> >
> > FWIW, I tend to agree with Eli: having all built-in commands on one page
> > also provides some benefit, especially to power users (the likely
> > audience for eshell) that are already familiar with a standard Unix
> > shell and just wants to know "what's different about Eshell" or "what
> > does Eshell provide".
>
> Ok, no problem. It just seemed a bit hard to navigate to me, but I don't
> have any issues with keeping all the commands together.
I'm not against subdividing that section. My point was that if you
want these commands to be easier to find, the subdivision itself is
not enough; you need additional measures.
> How about the attached patch instead? It just moves the list of commands
> to a sub-node, and also makes the "defining new built-ins" a proper
> sub-node too. That should keep things a bit easier to navigate, and then
> we can add more indexing as needed later.
No objections here. But once again: your points about being able to
find the commands by categories are well-taken, and adding indexing to
make that easier would also be a good change.
Thanks.
next prev parent reply other threads:[~2024-02-08 7:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 0:02 bug#68963: 30.0.50; [PATCH] Split Eshell built-in command documentation into subsections Jim Porter
2024-02-07 3:31 ` Eli Zaretskii
2024-02-07 4:26 ` Jim Porter
2024-02-07 12:54 ` Eli Zaretskii
2024-02-07 20:22 ` Stefan Kangas
2024-02-08 2:05 ` Jim Porter
2024-02-08 7:07 ` Eli Zaretskii [this message]
2024-02-08 20:30 ` Jim Porter
2024-02-09 7:05 ` Eli Zaretskii
2024-02-10 1:44 ` Jim Porter
2024-02-08 21:32 ` Stefan Kangas
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867cjfxwm3.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=68963@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
--cc=stefankangas@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.