unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Mike Kupfer <m.kupfer@acm.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22043@debbugs.gnu.org
Subject: bug#22043: 25.0.50; search-forward and char folding
Date: Mon, 30 Nov 2015 12:31:43 -0800	[thread overview]
Message-ID: <10400.1448915503@allegro.localdomain> (raw)
In-Reply-To: Your message of "Mon, 30 Nov 2015 19:32:36 +0200." <83egf7mlzf.fsf@gnu.org>

Eli Zaretskii wrote:

> Anyway, if I return to the original issue, the section with the
> offending "Search commands in Emacs by default perform character
> folding" sentence has its main focus on explaining what is character
> folding and how to enable/disable it; it does not focus on the
> specific commands.

Well, the explanation of what character folding is actually happens in
the previous paragraph.  The one that starts with "Search commands in
Emacs by default perform character folding" is just about enabling or
disabling character folding.

I agree with your point about flow and not distracting the reader by
throwing multiple issues together.  And I think that for most users,
information about enabling/disabling char folding is more important than
knowing which functions do folding, so I think that paragraph should (as
it does) come next after the description of what char folding is.

> This is standard practice in user-level documentation, when
> describing complex issues: you first provide an overview that might
> not be 100% accurate, but should give the reader a clear and simple
> enough idea of the subject, leaving the more accurate details for
> later in-depth coverage.

Yes, but when I'm reading documentation, if I see what looks like a
definite statement and then I find something else that appears to
contradict the first statement, my first reaction is to start doubting
the documentation as a whole.  The way I usually handle this when I'm
writing is to insert a "weasel word".  What do you think about changing
the first phrase to

  Search commands in Emacs generally perform character folding by
  default

(or maybe "commonly" instead of "generally").  As a reader, this tells
me that there are exceptions but I shouldn't worry about them at this
point in the text.

As an alternative: sometimes in documentation I'll see a definite
statement, followed later by an explicit acknowledgement that the
statement was a simplification.  I'd be okay with that approach, too.
As a reader, it tells me that the first statement was deliberately
chosen, not an oversight.

regards,
mike





  reply	other threads:[~2015-11-30 20:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<15605.1448748702@allegro.localdomain>
     [not found] ` <<17193.1448823812@allegro.localdomain>
     [not found]   ` <<c38b93a3-7fd1-439b-afc4-b3f7d4e7b100@default>
     [not found]     ` <<837fl0obox.fsf@gnu.org>
2015-11-29 20:41       ` bug#22043: 25.0.50; search-forward and char folding Drew Adams
2015-11-30  4:53         ` Mike Kupfer
2015-11-30 17:33           ` Eli Zaretskii
2015-11-30  9:54         ` Artur Malabarba
2015-11-30 17:32         ` Eli Zaretskii
2015-11-30 20:31           ` Mike Kupfer [this message]
2015-11-30 20:51             ` Eli Zaretskii
2015-12-01  7:37               ` Andreas Röhler
2015-12-01 15:35                 ` Eli Zaretskii
2015-12-01 20:30                 ` Mike Kupfer
2015-12-02 14:10                   ` Eli Zaretskii
2015-12-08 12:06                     ` Artur Malabarba
2015-12-08 15:08                       ` Mike Kupfer
2015-12-08 16:26                         ` Eli Zaretskii
2015-11-28 22:11 Mike Kupfer
2015-11-28 23:57 ` Artur Malabarba
2015-11-29 16:33   ` Eli Zaretskii
2015-11-29 16:53     ` Artur Malabarba
2015-11-29 21:29     ` Artur Malabarba
2015-11-30 17:32       ` Eli Zaretskii
2015-11-29 16:32 ` Eli Zaretskii
2015-11-29 19:03   ` Mike Kupfer
2015-11-29 19:08     ` Drew Adams
2015-11-29 19:19       ` Eli Zaretskii
2015-11-29 20:31       ` Artur Malabarba
2015-11-29 19:10     ` Eli Zaretskii

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=10400.1448915503@allegro.localdomain \
    --to=m.kupfer@acm.org \
    --cc=22043@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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).