unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Cc: Emacs-Devel <emacs-devel@gnu.org>
Subject: RE: emacs 22 - regular-expression isearch on spaces extremely lenient
Date: Sat, 29 Apr 2006 07:41:08 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAEGCDFAA.drew.adams@oracle.com> (raw)
In-Reply-To: <2cd46e7f0604281356i582388e2kef07922b6b6a9a3a@mail.gmail.com>

    i recently started noticing that emacs 22 regular expression isearches
    do not treat spaces exactly - any number of spaces in your search will
    map to any number, same or different, of spaces in the target.

    can anyone tell me whether or not it's deliberate, and what the
    rationale is?

(setq search-whitespace-regexp nil) will turn this off. When this is nil,
each space you type matches literally, against one space.

`search-whitespace-regexp' is, by default, "\\s-+", which searches for any
amount of whitespace when you type a space. This was introduced for regexp
search in Emacs 21, I believe. There is no such "magic-space" searching in
Emacs 20. Doc:

 If non-nil, regular expression to match a sequence of whitespace chars.
 This applies to regular expression incremental search.
 When you put a space or spaces in the incremental regexp, it stands for
 this, unless it is inside of a regexp construct such as [...] or *, + or ?.
 You might want to use something like "[ \t\r\n]+" instead.
 In the Customization buffer, that is `[' followed by a space,
 a tab, a carriage return (control-M), a newline, and `]+'.

The rationale was, I believe, that some users might want that: type space to
find any amount of whitespace, in particular, to find two words that are
separated by a newline.

There was talk of using this "magic-space" searching also for plain
incremental search in Emacs 22, but I don't think that was done.

FWIW, I agree with Miles on this - this is a misfeature, if turned on by
default. It should be off by default, and you should be able to turn it on
via a simple toggle during incremental search (regexp or plain).

Here is what I wrote 2005/02/06 to emacs-devel on this:

            > > sometimes the actual whitespace matters.
            > Right: in *regexp* search.
          while people generally expect regexp searches to be a bit
          fuzzy, they might expect a non-regexp search to be exact.
          Since the fuzzy whitespace matching often "looks" like normal
          matching (because the majority of whitespace is in fact a
          single space), it might take some time to see what's going on,
          resulting in some subtle errors. This is particularly true if
          one embeds a search inside a keyboard macro [which I often do].

    Plain (incremental) search should be a literal search. Regexp
    search should rigorously respect the regexp. People don't expect
    either to be fuzzy.

    The question is "Under what circumstances should typing a space be
    interpreted as wanting to search for any amount of whitespace?"

    This is unrelated to both plain search and regexp search. You
    might or might not want this _input effect_ with either plain
    or regexp search.

    This is akin to word search (as I think someone mentioned).
    Ultimately, a word search or a space-means-whitespace search is
    implemented with a regexp search - but the point in both cases
    is to provide a user-friendly way to do it, instead of requiring
    users to know about regexps.

    By default, neither `C-M-s' nor `C-s' should respect the
    user-friendly space-input feature. Or, rather, the default
    behavior of each should be determined by a user option - a la
    case-fold-search. And, regardless of the value of this option,
    you should be able to toggle space-means-whitespace
    searching from both `C-M-s' and `C-s', via a key sequence.

    The question then becomes how to toggle this space-means-whitespace
    searching?

  reply	other threads:[~2006-04-29 14:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2cd46e7f0604281353l38f7672gd3cfe0c64fdf0cb4@mail.gmail.com>
2006-04-28 20:56 ` emacs 22 - regular-expression isearch on spaces extremely lenient Ken Manheimer
2006-04-29 14:41   ` Drew Adams [this message]
2006-04-29 17:23     ` Eric Hanchrow
2006-05-01 14:51       ` Kevin Rodgers
2006-05-02  2:04         ` Richard Stallman
2006-05-01 18:04     ` ken manheimer
2006-05-01 18:44       ` emacs 22 - regular-expression isearch on spacesextremely lenient Drew Adams
     [not found]     ` <mailman.1189.1146507010.9609.help-gnu-emacs@gnu.org>
2006-05-30  5:17       ` emacs 22 - regular-expression isearch on spaces extremely lenient David Combs
2006-05-30  6:21         ` Tim X
2006-05-30  8:31         ` David Kastrup
     [not found] ` <mailman.1109.1146290553.9609.help-gnu-emacs@gnu.org>
2006-04-29  7:47   ` Miles Bader
     [not found] <mailman.1118.1146321681.9609.help-gnu-emacs@gnu.org>
2006-04-29 15:16 ` don provan

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=DNEMKBNJBGPAOPIJOOICAEGCDFAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@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.
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).