search-whitespace-regexp

search-whitespace-regexp

[Chong Yidong]

CVS Emacs has a variable, search-whitespace-regexp, which is a regexp that
replaces any space or spaces entered into isearch-forward-regexp. Setting
this variable to "[ \t\r\n]+" provides incremental searching across line
breaks, which is a commonly requested feature. However, I believe that
using search-whitespace-regexp in isearch-forward-regexp is a misfeature.
It should instead be used for isearch-forward.

When a user calls isearch-forward-regexp, he probably knows the precise
expression he wants, and how to craft a regular expression to find it. In
certain situations, it might be a nuisance for Emacs to silently tamper
with the regular expression he supplies.

The search-whitespace-regexp feature is more appropriate for "casual"
incremental searching. New users, in particular, do not expect isearch to
be foiled by line breaks. However, telling them to set
search-whitespace-regexp and use isearch-forward-regexp instead is not a
good solution, because commonly-used characters such as "." have a special
meaning in regexps.

The solution is to apply the search-whitespace-regexp behavior to
isearch-forward, rather than isearch-forward-regexp. The following patch
accomplishes this

*** isearch.el~	Fri Feb  4 19:33:15 2005
--- isearch.el	Fri Feb  4 21:59:13 2005
***************
*** 109,120 ****
    :type 'boolean
    :group 'isearch)

! (defcustom search-whitespace-regexp "\\s-+"
    "*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 `]+'."
    :type 'regexp
--- 109,119 ----
    :type 'boolean
    :group 'isearch)

! (defcustom search-whitespace-regexp nil
    "*If non-nil, regular expression to match a sequence of whitespace chars.
! This applies to incremental search. When you put a space or
! spaces in the incremental search string, it stands for this.
! You might want to use something like \"[ \\t\\r\\n]+\".
  In the Customization buffer, that is `[' followed by a space,
  a tab, a carriage return (control-M), a newline, and `]+'."
    :type 'regexp
***************
*** 573,584 ****
  Do incremental search forward for regular expression.
  With a prefix argument, do a regular string search instead.
  Like ordinary incremental search except that your input
! is treated as a regexp.  See \\[isearch-forward] for more info.
!
! In regexp incremental searches, a space or spaces normally matches
! any whitespace (the variable `search-whitespace-regexp' controls
! precisely what that means).  If you want to search for a literal space
! and nothing else, enter `[ ]'."
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))

--- 572,578 ----
  Do incremental search forward for regular expression.
  With a prefix argument, do a regular string search instead.
  Like ordinary incremental search except that your input
! is treated as a regexp.  See \\[isearch-forward] for more info."
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))

***************
*** 2029,2035 ****
       (isearch-regexp
        (if isearch-forward 're-search-forward 're-search-backward))
       (t
!       (if isearch-forward 'search-forward 'search-backward)))))

  (defun isearch-search ()
    ;; Do the search with the current search string.
--- 2023,2043 ----
       (isearch-regexp
        (if isearch-forward 're-search-forward 're-search-backward))
       (t
!       (if isearch-forward 'isearch-search-forward
'isearch-search-backward)))))
!
! (defun isearch-search-forward (string &optional bound noerror count)
!   (re-search-forward
!    (if search-whitespace-regexp
!        (replace-regexp-in-string " +" search-whitespace-regexp string)
!      string)
!    bound noerror count))
!
! (defun isearch-search-backward (string &optional bound noerror count)
!   (re-search-backward
!    (if search-whitespace-regexp
!        (replace-regexp-in-string " +" search-whitespace-regexp string)
!      string)
!    bound noerror count))

  (defun isearch-search ()
    ;; Do the search with the current search string.
***************
*** 2041,2047 ****
        (let ((inhibit-point-motion-hooks search-invisible)
  	    (inhibit-quit nil)
  	    (case-fold-search isearch-case-fold-search)
- 	    (search-spaces-regexp search-whitespace-regexp)
  	    (retry t))
  	(if isearch-regexp (setq isearch-invalid-regexp nil))
  	(setq isearch-within-brackets nil)
--- 2049,2054 ----
***************
*** 2377,2384 ****
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (let ((case-fold-search isearch-case-fold-search)
! 	(search-spaces-regexp search-whitespace-regexp))
      (funcall (isearch-search-fun)
               isearch-string
               (if isearch-forward
--- 2384,2390 ----
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (let ((case-fold-search isearch-case-fold-search))
      (funcall (isearch-search-fun)
               isearch-string
               (if isearch-forward

Re: search-whitespace-regexp

[Andreas Schwab]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> The solution is to apply the search-whitespace-regexp behavior to
> isearch-forward, rather than isearch-forward-regexp. The following patch
> accomplishes this

and breaks searching when the search string contains regexp meta
characters.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: search-whitespace-regexp

[Chong Yidong]

>> The solution is to apply the search-whitespace-regexp behavior to
>> isearch-forward, rather than isearch-forward-regexp. The following patch
>> accomplishes this
>
> and breaks searching when the search string contains regexp meta
> characters.

I don't understand what you mean. Isearch (not isearch-regexp) doesn't
treat regexp meta characters specially.

Re: search-whitespace-regexp

[Chong Yidong]

> and breaks searching when the search string contains regexp meta
> characters.

Whoops, stupid me. I see what you mean now. (Stefan also pointed it out.)

Re: search-whitespace-regexp

[Stefan Monnier]

> --- 2023,2043 ----
>        (isearch-regexp
>         (if isearch-forward 're-search-forward 're-search-backward))
>        (t
> !       (if isearch-forward 'isearch-search-forward
> 'isearch-search-backward)))))
> !
> ! (defun isearch-search-forward (string &optional bound noerror count)
> !   (re-search-forward
> !    (if search-whitespace-regexp
> !        (replace-regexp-in-string " +" search-whitespace-regexp string)
> !      string)
> !    bound noerror count))
> !
> ! (defun isearch-search-backward (string &optional bound noerror count)
> !   (re-search-backward
> !    (if search-whitespace-regexp
> !        (replace-regexp-in-string " +" search-whitespace-regexp string)
> !      string)
> !    bound noerror count))

I generally agree with your proposal to change the behavior of isearch such
that only plain search uses a "magical space", whereas regexp search is made
more "raw".  But the above code is wrong in that it fails to quote
chars like "[" in the search string.

You probably want to use something like

  (re-search-forward (mapconcat 'regexp-quote
                                (split-string string)
                                search-whitespace-regexp)
                     bound noerror count)

instead,


        Stefan

Re: search-whitespace-regexp

[Chong Yidong]

> I generally agree with your proposal to change the behavior of isearch
> such that only plain search uses a "magical space", whereas regexp search
> is made more "raw".  But the above code is wrong in that it fails to quote
> chars like "[" in the search string.

How about this revised patch?

*** isearch.el~	Fri Feb  4 19:33:15 2005
--- isearch.el	Fri Feb  4 23:47:15 2005
***************
*** 109,122 ****
    :type 'boolean
    :group 'isearch)

! (defcustom search-whitespace-regexp "\\s-+"
    "*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 `]+'."
    :type 'regexp
    :group 'isearch)

--- 109,124 ----
    :type 'boolean
    :group 'isearch)

! (defcustom search-whitespace-regexp nil
    "*If non-nil, regular expression to match a sequence of whitespace chars.
! When you put a space or spaces in the incremental search string,
! it will be replaced with this regular expression when searching.
! This applies to `isearch-forward' and `isearch-backward', but not
! the regular expression searches `isearch-forward-regexp' and
! `isearch-backward-regexp'. You might want to use something like
! \"[ \\t\\r\\n]+\". In the Customization buffer, that is `['
! followed by a space, a tab, a carriage return (control-M), a
! newline, and `]+'."
    :type 'regexp
    :group 'isearch)

***************
*** 514,519 ****
--- 516,525 ----
  With a prefix argument, do an incremental regular expression search
instead.
  \\<isearch-mode-map>
  As you type characters, they add to the search string and are found.
+
+ If `search-whitespace-regexp' is non-nil, any space or spaces
+ entered are replaced with that regular expression when searching.
+
  The following non-printing keys are bound in `isearch-mode-map'.

  Type \\[isearch-delete-char] to cancel last input item from end of
search string.
***************
*** 573,584 ****
  Do incremental search forward for regular expression.
  With a prefix argument, do a regular string search instead.
  Like ordinary incremental search except that your input
! is treated as a regexp.  See \\[isearch-forward] for more info.
!
! In regexp incremental searches, a space or spaces normally matches
! any whitespace (the variable `search-whitespace-regexp' controls
! precisely what that means).  If you want to search for a literal space
! and nothing else, enter `[ ]'."
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))

--- 579,585 ----
  Do incremental search forward for regular expression.
  With a prefix argument, do a regular string search instead.
  Like ordinary incremental search except that your input
! is treated as a regexp.  See \\[isearch-forward] for more info."
    (interactive "P\np")
    (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))

***************
*** 2029,2035 ****
       (isearch-regexp
        (if isearch-forward 're-search-forward 're-search-backward))
       (t
!       (if isearch-forward 'search-forward 'search-backward)))))

  (defun isearch-search ()
    ;; Do the search with the current search string.
--- 2030,2045 ----
       (isearch-regexp
        (if isearch-forward 're-search-forward 're-search-backward))
       (t
!       (if isearch-forward 'isearch-search-forward
!         'isearch-search-backward)))))
!
! (defun isearch-search-forward (string &optional bound noerror count)
!   (let ((search-spaces-regexp search-whitespace-regexp))
!     (re-search-forward (regexp-quote string) bound noerror count)))
!
! (defun isearch-search-backward (string &optional bound noerror count)
!   (let ((search-spaces-regexp search-whitespace-regexp))
!     (re-search-backward (regexp-quote string) bound noerror count)))

  (defun isearch-search ()
    ;; Do the search with the current search string.
***************
*** 2041,2047 ****
        (let ((inhibit-point-motion-hooks search-invisible)
  	    (inhibit-quit nil)
  	    (case-fold-search isearch-case-fold-search)
- 	    (search-spaces-regexp search-whitespace-regexp)
  	    (retry t))
  	(if isearch-regexp (setq isearch-invalid-regexp nil))
  	(setq isearch-within-brackets nil)
--- 2051,2056 ----
***************
*** 2377,2384 ****
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (let ((case-fold-search isearch-case-fold-search)
! 	(search-spaces-regexp search-whitespace-regexp))
      (funcall (isearch-search-fun)
               isearch-string
               (if isearch-forward
--- 2386,2392 ----
  (defun isearch-lazy-highlight-search ()
    "Search ahead for the next or previous match, for lazy highlighting.
  Attempt to do the search exactly the way the pending isearch would."
!   (let ((case-fold-search isearch-case-fold-search))
      (funcall (isearch-search-fun)
               isearch-string
               (if isearch-forward

Re: search-whitespace-regexp

[Richard Stallman]

    However, I believe that
    using search-whitespace-regexp in isearch-forward-regexp is a misfeature.
    It should instead be used for isearch-forward.

For years, string search has treated characters literally while regexp
search has treated space as "any whitespace".  To reverse this would
be an incompatible change that would affect every user.

I think you're the first person ever to ask for this change.  I think
it would cause more trouble than benefit.

However, if a poll of users is done, and we find that most users would
prefer this change, I would consider it.

Re: search-whitespace-regexp

[Chong Yidong]

>     However, I believe that
>     using search-whitespace-regexp in isearch-forward-regexp is a
>     misfeature. It should instead be used for isearch-forward.
>
> For years, string search has treated characters literally while regexp
> search has treated space as "any whitespace".  To reverse this would
> be an incompatible change that would affect every user.
>
> I think you're the first person ever to ask for this change.  I think
> it would cause more trouble than benefit.
>
> However, if a poll of users is done, and we find that most users would
> prefer this change, I would consider it.

In that case, I propose just changing string search, using a variable
search-whitespace, analogous to search-whitespace-regexp. This should
default to nil, so that the default behavior of string search is identical
to Emacs 21.3 and below. If the user customizes the value, he gets the
"magical space" behavior.

I have come across several complaints about newlines interfering with
string search. For example, a website called "Emacs for Writers", which is
written by a professional writer and non-programmer who uses Emacs, says
this:

http://www.therandymon.com/linux/woodnotes/emacswriter/node15.html
   One limitation of regular searches in documents that have been formatted
   (filled) is that if the two words are separated by a newline, the
   incremental search function won't find them.

He goes on to recommend using word search, but the problem with word
search is that it is not incremental. As I have mentioned, regular
expression search is also problematic for casual use, especially if the
user is unfamiliar with regexp syntax, because characters like "." have
special meaning.

A cursory search through Google turned up indicates that there have been
plenty of user requests for something like this over the years. For
example:

http://groups.google.com.sg/groups?selm=199803011846.NAA30567%40feedback.princeton.edu&output=gplain
  I edit tex documents (such as my thesis), and I usually find locations
  in a document using isearch (^S).  Searching for a couple words in a
  row (say "the dog") is usually enough to narrow down the location.
  However, if "the" and "dog" are separated by a newline, then isearch
  won't find them...

  Is there a totally different approach that would make plain iserach
  smart enough to understand that SPACE could be a newline (or a tab)?
  The advantage of using plain isearch instead of regexp isearch is that
  I wouldn't have to escape special characters like "[".

Re: search-whitespace-regexp

[Richard Stallman]

    In that case, I propose just changing string search, using a variable
    search-whitespace, analogous to search-whitespace-regexp. This should
    default to nil, so that the default behavior of string search is identical
    to Emacs 21.3 and below. If the user customizes the value, he gets the
    "magical space" behavior.

I would be willing to install that.

We would need legal papers from you to be able to install your code.
Do you want to sign them?

Re: search-whitespace-regexp

[Stefan Monnier]

> In that case, I propose just changing string search, using a variable
> search-whitespace, analogous to search-whitespace-regexp. This should
> default to nil, so that the default behavior of string search is identical
> to Emacs 21.3 and below. If the user customizes the value, he gets the
> "magical space" behavior.

Wait.  That doesn't make any sense.  I haven't seen *anyone* ask for plain
search to treat spaces as "just one SPC char".  AFAICT everybody is happy
with the behavior where a space in the search text is interpreted as "any
sequence of blank chars".

The only discussion here is about removing the "magic space" from
regexp-searches, not from plain searches.  Or did I miss something?


        Stefan

Re: search-whitespace-regexp

[Miles Bader]

On Sun, 06 Feb 2005 11:21:27 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Wait.  That doesn't make any sense.  I haven't seen *anyone* ask for plain
> search to treat spaces as "just one SPC char".  AFAICT everybody is happy
> with the behavior where a space in the search text is interpreted as "any
> sequence of blank chars".

FWIW, there are definitely cases where I get pissed at regexp-search
for doing that -- it's not always the case that one is just searching
for words that are separated by "some whitespace", sometimes the
actual whitespace matters.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: search-whitespace-regexp

[Stefan Monnier]

>> Wait.  That doesn't make any sense.  I haven't seen *anyone* ask for plain
>> search to treat spaces as "just one SPC char".  AFAICT everybody is happy
>> with the behavior where a space in the search text is interpreted as "any
>> sequence of blank chars".

> FWIW, there are definitely cases where I get pissed at regexp-search
> for doing that -- it's not always the case that one is just searching
> for words that are separated by "some whitespace", sometimes the
> actual whitespace matters.

Right: in *regexp* search.


        Stefan

Re: search-whitespace-regexp

[Miles Bader]

On Sun, 06 Feb 2005 17:49:42 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> >> Wait.  That doesn't make any sense.  I haven't seen *anyone* ask for plain
> >> search to treat spaces as "just one SPC char".  AFAICT everybody is happy
> >> with the behavior where a space in the search text is interpreted as "any
> >> sequence of blank chars".
> 
> > FWIW, there are definitely cases where I get pissed at regexp-search
> > for doing that -- it's not always the case that one is just searching
> > for words that are separated by "some whitespace", sometimes the
> > actual whitespace matters.
> 
> Right: in *regexp* search.

Er, well, that's the point -- so far it's been a problem only in
regexp search because that feature (whitespace fuzzy matching) has
only been implemented there.  If it's implemented by default in normal
isearch, it might start to be a problem there too.

It might even be a bigger problem because 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].

-Miles
-- 
Do not taunt Happy Fun Ball.

RE: search-whitespace-regexp

[Drew Adams]

    > > 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? An obvious candidate is `C-s C-SPC'. (Some will no doubt argue
against this because it means you can't just end a search and set the mark
this way.)

Re: search-whitespace-regexp

[Miles Bader]

On Sun, 6 Feb 2005 16:28:33 -0800, Drew Adams <drew.adams@oracle.com> wrote:
> The question then becomes how to toggle this space-means-whitespace
> searching? An obvious candidate is `C-s C-SPC'. (Some will no doubt argue
> against this because it means you can't just end a search and set the mark
> this way.)

Yes, I think it's not good for exactly that reason; I'll bet a fair
number searches are precisely for the purpose of getting to the place
where you want to set a mark...

"M-SPC", on the other hand, is by default bound to "just-one-space",
which seems eerily related to this isearch feature; morever, most
other "isearch special commands" are bound to meta-keys (M-r, M-e,
etc).

So how about M-SPC toggling this flag in isearch...?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: search-whitespace-regexp

[Chong Yidong]

Let me try to explain my idea more clearly.

Since RMS has raised the issue of incompatibility, I think the default
behavior for isearch should be left as it was in 21.3, for the moment. In
other words, regexp search has a magic space, and string search doesn't.
However, there should be a way for the user to customize this.

It is relatively easy for a user to get rid of the magic space for regexp
search, if he wants to:
  (setq search-whitespace-regexp nil)

However, there is no easy way for a user to turn on the magic space for
string search; you have to hack isearch.el to do it. I suggest
implementing an analogous mechanism for string search (I'm not certain
what the variable should be called, though):

  (defvar search-string-whitespace-regexp nil
  "If non-nil, regular expression to match a sequence of whitespace chars.
  This applies to ordinary incremental search.
  You might want to use something like "[ \t\r\n]+" instead.")

Because the default is nil, there is no magic space, and the behavior is
like 21.3 and below; but users or Lisp libraries can set it as needed. For
example, longlines.el can set it to "[ \n]" so that linebreaks and spaces
are treated equally.

RE: search-whitespace-regexp

[Drew Adams]

    So how about M-SPC toggling this flag in isearch...?

I vote yes.

    It is relatively easy for a user to get rid of the magic space
    for regexp search: ... search-whitespace-regexp ...
    I suggest implementing an analogous mechanism for string search
    (I'm not certain what the variable should be called, though):

If we use two different variables, which makes sense for flexibility and
code, it still might be good to find a way to toggle either using the same
function. That way, the same key binding (e.g. `C-s M-SPC', `C-M-s M-SPC')
could work for (toggle) both.

WRT the current 21.3 behavior and the issue of compatibility:

I think the default behavior wrt this should be the same for both regexp and
regular isearch: no "magic" whitespace search. This corresponds to what I
think most people expect, out-of-the-box, for both string and regexp
searches: respect the input exactly.

This is incompatible with 21.3, but it is compatible with 20.7 (which had no
magic whitespace isearch). I don't think we should worry about compatibility
here, anyway (it is easy for users to change the behavior) - we should just
DTRT.

Re: search-whitespace-regexp

[Andreas Schwab]

Miles Bader <snogglethorpe@gmail.com> writes:

> So how about M-SPC toggling this flag in isearch...?

Btw, we already have a word search, but on a rather obscure key: C-s RET
C-w.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: search-whitespace-regexp

[Richard Stallman]

    So how about M-SPC toggling this flag in isearch...?

I am very much against this.  I think I have used that command
to exit a search.

Re: search-whitespace-regexp

[Richard Stallman]

    Wait.  That doesn't make any sense.  I haven't seen *anyone* ask for plain
    search to treat spaces as "just one SPC char".

That is what it does now.

      AFAICT everybody is happy
    with the behavior where a space in the search text is interpreted as "any
    sequence of blank chars".

Do you mean, everyone would be happy if a space in string search text
were interpreted that way?

Re: search-whitespace-regexp

[Stefan Monnier]

>       AFAICT everybody is happy
>     with the behavior where a space in the search text is interpreted as "any
>     sequence of blank chars".

> Do you mean, everyone would be happy if a space in string search text
> were interpreted that way?

Yes.  Especially if the regexp-search (in contrast) doesn't use such magic.
This way, you can easily turn off the magic (by using regexp-search) for
those rare cases where you really want to match "just one space".


        Stefan

Re: search-whitespace-regexp

[Miles Bader]

On Mon, 07 Feb 2005 16:07:44 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> >       AFAICT everybody is happy
> >     with the behavior where a space in the search text is interpreted as "any
> >     sequence of blank chars".
> 
> > Do you mean, everyone would be happy if a space in string search text
> > were interpreted that way?
> 
> Yes.  Especially if the regexp-search (in contrast) doesn't use such magic.
> This way, you can easily turn off the magic (by using regexp-search) for
> those rare cases where you really want to match "just one space".

That seems bizarre.  Using a regexp search would just mess things up
more.  Those cases where one wants a search to be exact are hardly
going to be the ones where you just want to pop into regexp mode! 
[Not to mention, I suspect it will not be immediately obvious that
searches are more fuzzy than intended.]

Anyway, the statement that "everybody would be happy" is clearly wrong.

-Miles
-- 
Do not taunt Happy Fun Ball.