unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: jan via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: rms@gnu.org
Cc: 41006@debbugs.gnu.org
Subject: bug#41006: 26.3; regular expressions documentation
Date: Sun, 3 May 2020 11:31:52 +0100	[thread overview]
Message-ID: <CADJx9Ld4BsGtwvxmMQRFenGJXBMUMtBN59OE7eQKYi4C-Yc6hQ@mail.gmail.com> (raw)
In-Reply-To: <E1jV5UR-00016K-UH@fencepost.gnu.org>

Well there's a name I recognise!  Wasn't expecting that.

Anyway, allow me to push back slightly.  I have long ago training in
user interfaces, but I'm no expert.

To transmit info it has to be, among other things, 'evident' or
'obvious'.  In this case I'd say that means visible.
Section "15.6 Syntax of Regular Expressions" is very visible.  It's
easily navigable up and down by mouse or keyboard, also the scroll bar
gives clearer indication of how much there is and where you are on the
page.  Great stuff.
Even better it's easy to browse 'exhaustively' - if I start at the top
of the page and into the bottom I know I've covered everything.  I
find that property very useful as I do *a lot* of technical reading.

But it's only showing about half the information.  There is no evident
indication that there is more.  I'm not the first person to get
confused by this
(<http://emacs.1067599.n8.nabble.com/regex-question-td75006.html> "The
answer you seek seems to be in a separate section (Regexp Backslash),
at least in the version I am currently using" - that took about 15
seconds to find).

If you combine  both sections together it would be visible and
exhaustive.  Whether it would be too long is something I can't answer,
but my opinion would be it's okay (based purely on my evidence-free
opinion).

If you don't want to combine them then make the other half reasonably
visible (it's rather odd that the top of the section points you at
"(elisp)Regular Expressions" but not to backslash section).  About the
only evidence there is a second section,  is right at the very top in
the breadcrumbs (Next: Regexp Backslash) and a little hint at the end
("...since backslashes can legitimately precede these characters where
they _have_ special meaning, as in...").

Specifically may have suggests that the start that currently looks like this:

"
15.6 Syntax of Regular Expressions
==================================

This section (and this manual in general)...
"

perhaps have a direct link to the next section, like this

"
15.6 Syntax of Regular Expressions
==================================

Non-Backslash Regular Expressions   <--- dead link because you're here
Backslash Regular Expressions (more regexp syntax)  <--- live link

This section (and this manual in general)...
"

And perhaps repeat that link at the end of that help page as well.

Or something else.  Whatever you think works, assuming you even think
I have a point.

regards

jan



On 03/05/2020, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > 1. Suggest emacs' excellent documentation should not distinguish
> between
>   > Regexps and Regexp Backslash in the manual.
>   > That is, these 2 should be combined:
>
> When a node is too long, browsing in Info becomes inconvenient.
> Therefore, we look for a reading way to split up the node.
>
> We found that way to split up the node on regexps.
> There is no logical _need_ to split the topic that way, but it is not
> unreasonable, so it was a valid solution to the overlongness.
>
> I expect that many nodes are too long now, and we should look for
> reasonable ways to split them.
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>





  reply	other threads:[~2020-05-03 10:31 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 19:06 bug#41006: 26.3; regular expressions documentation jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-03  3:40 ` Richard Stallman
2020-05-03 10:31   ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-05-03 13:07 ` Mattias Engdegård
2020-05-03 14:00   ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-03 20:08   ` Drew Adams
2020-05-03 20:31     ` Stefan Kangas
2020-05-04  1:00       ` Drew Adams
2020-05-05  2:56       ` Richard Stallman
2020-05-05 10:05         ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-05 16:51           ` Mattias Engdegård
2020-05-05 18:20         ` Stefan Kangas
2020-05-05 18:40           ` Drew Adams
2020-05-05 19:04             ` Stefan Kangas
2020-05-05 19:42               ` Drew Adams
2020-05-05 21:23                 ` Stefan Kangas
2020-05-05 21:37                   ` Drew Adams
2020-05-07  2:40                   ` Richard Stallman
2020-05-09  3:48               ` Richard Stallman
2020-05-07  2:41             ` Richard Stallman
2020-05-07  3:17               ` Drew Adams
2020-05-08  2:51                 ` Richard Stallman
2020-05-07 10:31               ` Stefan Kangas
2020-05-07  2:41           ` Richard Stallman
2020-05-07  3:18             ` Drew Adams
2020-05-07 10:32             ` Stefan Kangas
2020-05-08  2:49               ` Richard Stallman
2020-05-08  6:47                 ` Eli Zaretskii
2020-05-08 10:10                   ` Stefan Kangas
2020-05-08 10:31                     ` Eli Zaretskii
2020-05-08 18:17                       ` Stefan Kangas
2020-05-08 18:47                         ` Eli Zaretskii
2020-05-08 20:09                           ` Stefan Kangas
2020-05-08 10:04                 ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-09  3:56                   ` Richard Stallman
2020-05-08 16:49                 ` Drew Adams
2020-05-09  3:53                   ` Richard Stallman
2020-05-09  3:54                   ` Richard Stallman
2020-05-07  2:41           ` Richard Stallman
2020-05-04  3:10   ` Richard Stallman
2020-05-04  9:13     ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-05  2:56       ` Richard Stallman
2020-05-05 10:02         ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-05 17:12     ` Mattias Engdegård
2020-05-05 17:40       ` Eli Zaretskii
2020-05-05 17:50         ` jan via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-05 18:09         ` Stefan Kangas
2020-05-05 18:23           ` Eli Zaretskii
2020-05-07  2:42       ` Richard Stallman
2022-04-29 12:22 ` 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=CADJx9Ld4BsGtwvxmMQRFenGJXBMUMtBN59OE7eQKYi4C-Yc6hQ@mail.gmail.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=41006@debbugs.gnu.org \
    --cc=rms@gnu.org \
    --cc=rtm443x@googlemail.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).