From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 22043@debbugs.gnu.org, m.kupfer@acm.org
Subject: bug#22043: 25.0.50; search-forward and char folding
Date: Mon, 30 Nov 2015 19:32:36 +0200 [thread overview]
Message-ID: <83egf7mlzf.fsf@gnu.org> (raw)
In-Reply-To: <bc7949e5-fa16-42a8-bd16-ecb0280c421c@default>
> Date: Sun, 29 Nov 2015 12:41:16 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: m.kupfer@acm.org, 22043@debbugs.gnu.org
>
> > > IOW, isn't this default behavior true for all incremental
> > > search commands except regexp search, and only for those
> > > commands (no non-incremental search commands)?
> >
> > No. Nonincremental vs incremental is not the issue. The issue is
> > whether the search function that the command employs uses regexps or
> > not. It is a limitation of how these features are implemented that
> > they absolutely require regexp search.
>
> OK, but from a user point of view, is this not the case:
>
> 1. S?he invokes search using `C-M-s' or `C-s', which are
> advertised as regexp and plain (non regexp) search. IOW,
> regardless of what might go on under the covers (and a
> lot already does, for lax whitespace searching), s?he
> thinks of `C-s' as performing a non-regexp search.
Perhaps so, but (a) I see that you've dropped the incremental vs
nonincremental distinction, which agrees with what I say above; and
(b) we cannot really say in the manual something like "commands
invoked by `C-s' do character folding", because the reader might not
yet know/remember enough for such a distinction to be useful for her.
> 2. There is no character folding with the "regexp" commands
> (`C-M-s'), because char folding substitutes its own regexp
> for the user input, and char folding does not currently
> parse regexp-pattern user input.
That's implementation. From the user POV, typing "C-M-s M-s '"
magically does support character folding, but it also switches the
search to a non-regexp one! So is it a regexp search or isn't it?
> Perhaps, to be more precise, the difference is search that
> does or does not accept general regexp patterns as _input_.
> Those that do have "regexp" (or "-re-"?) in their name;
> those that do not do not have it. The former do not
> support char folding; the latter do. Is that correct (and
> complete)?
I think neither, because of the subtle behind-the-scenes effect of the
"M-s C" toggles (where C is a character like ' or _ or w).
> I guess I was mistaken in thinking that non-incremental
> search commands, such as `nonincremental-search-forward',
> do not support char folding (regardless of whether they
> include "-re" in their name). Which ones support it, and
> under what circumstances?
Each command should tell in its doc string whether it does or doesn't,
and the manual should also document that where it describes the
command itself. AFAICS, this is currently (as of today ;-) so. I
don't think we can do any better. The real criterion is "where it's
easy to provide given the limitations of the implementation we have",
but that's not useful for user documentation.
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. So it uses some vague definitions of the default
behavior, which is later described more accurately for each particular
command. 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. I don't see how we can do significantly
better; all of the proposals till now make the description much more
complicated and thus confusing, especially upon first reading.
If people think that saying something more vague like
Some search commands by default perform character folding (whether
it does or doesn't is documented for each specific command)
will do a better job, maybe we could use that. To me, this sounds
worse, because it immediately raises the question: which commands do
and which don't. That question will interfere with the reader's
attention to the issue at hand, which isn't the particular commands,
but the folding in general and how to toggle/disable it.
next prev parent reply other threads:[~2015-11-30 17:32 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 [this message]
2015-11-30 20:31 ` Mike Kupfer
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=83egf7mlzf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=22043@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=m.kupfer@acm.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).