unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: mattiase@acm.org, rms@gnu.org, 41006@debbugs.gnu.org,
	rtm443x@googlemail.com
Subject: bug#41006: 26.3; regular expressions documentation
Date: Fri, 08 May 2020 21:47:30 +0300	[thread overview]
Message-ID: <83sggagt6l.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkmnxA2Fjyt9-w-GhMFgjd7OpoFGiR1U2FL0mjREfBcftjw@mail.gmail.com> (message from Stefan Kangas on Fri, 8 May 2020 11:17:50 -0700)

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 8 May 2020 11:17:50 -0700
> Cc: rms@gnu.org, mattiase@acm.org, 41006@debbugs.gnu.org, 
> 	rtm443x@googlemail.com
> 
> > If the latter, then do you suggest to describe the search before
> > describing the regexps themselves?
> 
> For the user manual, I actually like that the commands are introduced
> early in `(emacs) Regexp Search', which is what users are looking for.
> Then we can explain the details of how to use them.

I think this will be suboptimal.  The chapter (or the whole manual) is
either read in its entirety (if the reader is new to the topic), or is
used as a reference.  For the former use case, we should introduce
regular expressions before we explain how to use them, otherwise the
text will be confusing (see below).  For the latter use case, the
order is entirely immaterial, since the readers are supposed to use
index-search to get directly where the subject they are looking for is
described.

IME, it sometimes helps to describe usage of something before
explaining what that something is, but only if the latter follows very
closely in the footsteps of the former.  Something like this (to take
an example of something I used just today):

  In buffers where Font Lock mode is enabled, patterns are highlighted
  using font lock.  In buffers where Font Lock mode is disabled,
  patterns are applied using overlays; in this case, the highlighting
  will not be updated as you type.  The Font Lock mode is considered
  "enabled" in a buffer if its `major-mode' causes
  `font-lock-specified-p' to return non-nil, which means the major
  mode specifies support for Font Lock.

This is not the case in the regexp search description case: there, we
will have a long list of search commands, and the reader will read all
that and all the time wonder what the heck is that "regular
expression" thing and how to write one.  When I bump into text that
doesn't explain an unusual term a sentence or two after it is first
used, I become annoyed and scan quickly forward until I find the
definition; only then I can continue reading.  My recommendation is to
avoid such "delayed" definitions.





  reply	other threads:[~2020-05-08 18:47 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
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 [this message]
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=83sggagt6l.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=41006@debbugs.gnu.org \
    --cc=mattiase@acm.org \
    --cc=rms@gnu.org \
    --cc=rtm443x@googlemail.com \
    --cc=stefan@marxist.se \
    /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).