Interpretation of a space in regexp isearch?

Interpretation of a space in regexp isearch?

[Bastien]

Hi,

I just found out that

  C-u C-s [a-z]\. [A-Z] 

matches more than one space character.

Is this a bug?

How can I search only one space character?

Thanks!

-- 
 Bastien

Re: Interpretation of a space in regexp isearch?

[Dmitry Gutov]

Bastien <bzg@gnu.org> writes:
 > I just found out that
 >
 >   C-u C-s [a-z]\. [A-Z]
 >
 > matches more than one space character.
 >
 > Is this a bug?
 >
 > How can I search only one space character?

The docstring for `isearch-forward-regexp' says:

   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 C-q SPC.

Re: Interpretation of a space in regexp isearch?

[Davis Herring]

> I just found out that
> 
>   C-u C-s [a-z]\. [A-Z] 
> 
> matches more than one space character.
> 
> Is this a bug?

It's a feature, but I don't remember how to change it at the moment.
`search-spaces-regexp' is almost it.

> How can I search only one space character?
> 
> Thanks!

Put it in a character class ("[ ]").

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Interpretation of a space in regexp isearch?

[Bastien]

Davis Herring <herring@lanl.gov> writes:

> It's a feature, but I don't remember how to change it at the moment.
> `search-spaces-regexp' is almost it.

Yep -- it's ̀search-whitespace-regexp'.

Dmitry Gutov <dgutov@yandex.ru> writes:

> The docstring for `isearch-forward-regexp' says:
>
>   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 C-q SPC.

That's it, thanks!

-- 
 Bastien

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Bastien <bzg@gnu.org> writes:

> Davis Herring <herring@lanl.gov> writes:
>
>> It's a feature, but I don't remember how to change it at the moment.
>> `search-spaces-regexp' is almost it.
>
> Yep -- it's ̀search-whitespace-regexp'.

FWIW, I've long been of the opinion that this feature is exactly
backward.  The `search-whitespace-regexp' whitespace matching feature
should apply to ordinary incremental search, and it should *not* apply
to regexp incremental search.

Re: Interpretation of a space in regexp isearch?

[Dmitry Gutov]

Chong Yidong <cyd@gnu.org> writes:

 > Bastien <bzg@gnu.org> writes:
 >
 >> Davis Herring <herring@lanl.gov> writes:
 >>
 >>> It's a feature, but I don't remember how to change it at the moment.
 >>> `search-spaces-regexp' is almost it.
 >>
 >> Yep -- it's =CC=80search-whitespace-regexp'.
 >
 > FWIW, I've long been of the opinion that this feature is exactly
 > backward.  The `search-whitespace-regexp' whitespace matching feature
 > should apply to ordinary incremental search, and it should *not* apply
 > to regexp incremental search.

I think that would make more sense, too.

Re: Interpretation of a space in regexp isearch?

[Bastien]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> FWIW, I've long been of the opinion that this feature is exactly
>> backward.  The `search-whitespace-regexp' whitespace matching feature
>> should apply to ordinary incremental search, and it should *not* apply
>> to regexp incremental search.
>
> I think that would make more sense, too.

My opinion too.

-- 
 Bastien

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

>>> FWIW, I've long been of the opinion that this feature is exactly
>>> backward.  The `search-whitespace-regexp' whitespace matching feature
>>> should apply to ordinary incremental search, and it should *not* apply
>>> to regexp incremental search.
>>
>> I think that would make more sense, too.
>
> My opinion too.

+1

IMO, that feature is what the user usually wants in an ordinary search
(regardless it's incremental or not; even if that search is part of a
ordinary replace command).

On the other and, in a rexexp search (or regexp search&replace) I
think that the common case is the opposite: the user normally doesn't
want that feature.

So, what about making that feature optional for these two scenarios?
("on" by default in the regexp case and "off" by default in the normal
case).

-- 
Dani Moncayo

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

> So, what about making that feature optional for these two scenarios?
> ("on" by default in the regexp case and "off" by default in the normal
> case).

Sorry, obviously I meant "off" for regexp and "on" for the normal search.

-- 
Dani Moncayo

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

>>>> FWIW, I've long been of the opinion that this feature is exactly
>>>> backward.  The `search-whitespace-regexp' whitespace matching feature
>>>> should apply to ordinary incremental search, and it should *not* apply
>>>> to regexp incremental search.
>>>
>>> I think that would make more sense, too.
>>
>> My opinion too.
>
> +1
>
> IMO, that feature is what the user usually wants in an ordinary search
> (regardless it's incremental or not; even if that search is part of a
> ordinary replace command).
>
> On the other and, in a rexexp search (or regexp search&replace) I
> think that the common case is the opposite: the user normally doesn't
> want that feature.
>
> So, what about making that feature optional for these two scenarios?
> ("off" by default in the regexp case and "on" by default in the normal
> case).

BTW, but #10885 would be solved with this proposal.

-- 
Dani Moncayo

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> >>> FWIW, I've long been of the opinion that this feature is
> >>> exactly backward.  The `search-whitespace-regexp' whitespace 
> >>> matching feature should apply to ordinary incremental search,
> >>> and it should *not* apply to regexp incremental search.
> >>
> >> I think that would make more sense, too.
> > My opinion too.
> +1
> 
> IMO, that feature is what the user usually wants in an ordinary search
> (regardless it's incremental or not; even if that search is part of a
> ordinary replace command).
> 
> On the other and, in a rexexp search (or regexp search&replace) I
> think that the common case is the opposite: the user normally doesn't
> want that feature.
> 
> So, what about making that feature optional for these two scenarios?
> ("on" by default in the regexp case and "off" by default in the normal
> case).

+0.2

We've been through this before, I think, but...

By default, "magic-space" searching should be OFF for both simple and regexp
search.  Each SPC you type should search for a single SPC, by default.  Simple.
No surprise.

Others have given reasons for the regexp case (+1).  For the simple-search case:
I do not think it is appropriate for users, especially newbies, to have to
figure out and use `C-q SPC' (WTF?) to search for a single SPC char.

I do agree, however, that magic-space searching can be very useful, and it
should be easily available, via a toggle key, for both simple and regexp
searching.

The best approach is to *let users decide*:

* Treat both simple and regexp search the same way.

* Have a Boolean variable that controls the behavior:
  literal-SPC or magic-space searching.

* Have a toggle key that flips the Boolean value.
  The new value stays in effect (including in future
  searches for the same session) until flipped again.
  (Some candidates for the key: `M-SPC', `M-s SPC'.)

* The variable's default value provides literal SPC search
  as the default (i.e., initial) behavior - for all searches:
  simple & regexp.

* Users can set the variable value in their init files, if
  they want to change the default (i.e., initial) behavior.

(Personally, I would prefer that the variable be a defcustom, but I'm a
heretic.)


[Even without this proposal, the doc for Isearch (e.g. C-s C-h m) should mention
the behavior of SPC in a regexp search - it is currently silent about this.
With this proposal, it should mention the two SPC behaviors and the toggle key.]

Re: Interpretation of a space in regexp isearch?

[Davis Herring]

> We've been through this before, I think, but...
> 
> By default, "magic-space" searching should be OFF for both simple and regexp
> search.  Each SPC you type should search for a single SPC, by default.  Simple.
> No surprise.

Unless you filled a paragraph (perhaps via auto-fill-mode) and don't
remember doing so.

> Others have given reasons for the regexp case (+1).  For the simple-search case:
> I do not think it is appropriate for users, especially newbies, to have to
> figure out and use `C-q SPC' (WTF?) to search for a single SPC char.

If you're searching just for a space, the only differences will be that
you stop only once at each stretch of whitespace (and that you stop at
all at (sequences of) tabs, which, as common as they are, are still
almost always rare compared to spaces).  Why would you even care?  Sure,
if you're searching for "a b" you'll find "a  b", but when would you
search for that, caring about missing the latter, and not be using a
regexp (as to find sentences with only one space separating them)?

> I do agree, however, that magic-space searching can be very useful, and it
> should be easily available, via a toggle key, for both simple and regexp
> searching.

Is "let's add an isearch toggle key" what you meant by "We've been
through this before"?

> * Treat both simple and regexp search the same way.

In regexp search, you can choose between \s-+ and SPC -- that's why so
many have said just now that this magic is appropriate for C-s and not
C-M-s.

> * Have a toggle key that flips the Boolean value.
>   The new value stays in effect (including in future
>   searches for the same session) until flipped again.
>   (Some candidates for the key: `M-SPC', `M-s SPC'.)

How is M-SPC any easier than C-q?  (This is an argument for having the
default be "on" for this magic; otherwise you need a way to summon it
for one use and C-q doesn't fit there.)  As always, adding keys to
isearch reduces the set you can use on exit (M-SPC is useful here).

> * Users can set the variable value in their init files, if
>   they want to change the default (i.e., initial) behavior.

Er, yes?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> > By default, "magic-space" searching should be OFF for both 
> > simple and regexp search.  Each SPC you type should search
> > for a single SPC, by default.  Simple.  No surprise.
> 
> Unless you filled a paragraph (perhaps via auto-fill-mode) and don't
> remember doing so.

?

Perhaps you mean filling with justification, so there can be stretches of
multiple SPC chars?  Or perhaps you are referring to `SPC SPC' after a period?
Sorry, I don't see the problem you are hinting at.

The behavior of SPC meaning to search for a single SPC char is pretty common in
other editors (from TextPad to MS Word).  And it has always been the default
behavior for simple search in Emacs as well.  How is it surprising?

> If you're searching just for a space, the only differences 
> will be...

We know what the differences are.

> Why would you even care?  Sure, if you're searching for
> "a b" you'll find "a  b",

You answered your own question.

> but when would you search for that, caring about missing
> the latter, and not be using a regexp (as to find sentences
> with only one space separating them)?

You would search for that anytime you would search for it. ;-)  Try searching
your own message for `a b', for instance - that's `a', `SPC', `b'.

Honestly, it is silly to suppose that users never or rarely want to search for a
set number of SPC chars, including for just one SPC.  Especially programmers.

> Is "let's add an isearch toggle key" what you meant by "We've been
> through this before"?

No.  I have a vague recollection that we have discussed before whether Isearch
should search for only a single SPC when you type a SPC.  I do not have a
reference for you, however.

> > * Treat both simple and regexp search the same way.
> 
> In regexp search, you can choose between \s-+ and SPC -- that's why so
> many have said just now that this magic is appropriate for C-s and not
> C-M-s.

Yes, I realize that.

And yet we still have SPC being magic for regexp search, don't we?  Even though
it is simple enough to use \s-+, and it always has been.

If people have in the past thought that SPC being magic in regexp search was
handy (and yes, it can be easier to hit `SPC' than to type `\s-+', especially
for multiple such in a long regexp), then their arguments still apply.

And yes, "so many" clearly have thought that in the past, including Richard.
The magic-space behavior for regexp search is at least as old as Emacs 20.

I recognize that SPC acting "magically" can be useful whatever the search mode.
Apparently you do not.

* I do not see magic-space SPC as something that is useful ONLY for
  regexp search (the current and traditional approach).  And I do not
  see it as useful ONLY for simple search (which you seem to be arguing).

* I do not see literal-space SPC as something that is useful ONLY for
  regexp search (which you seem to be arguing).  And I do not see it as
  useful ONLY for simple search (the current and traditional approach).

Each SPC-search mode can be useful for both simple and regexp search, IMO.

> > * Have a toggle key that flips the Boolean value.
> >   The new value stays in effect (including in future
> >   searches for the same session) until flipped again.
> >   (Some candidates for the key: `M-SPC', `M-s SPC'.)
> 
> How is M-SPC any easier than C-q?

No one said it was.

But you are comparing apples and orangutans.  C-q does not toggle the search
mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an
otherwise magic-space sea.

> (This is an argument for having the default be "on" for this magic;

It's not much of an argument, AFAICT.

I don't care much whether the _default_ default is on or off.  If users can set
the default SPC-search mode themselves, and if they have a simple way to toggle
the mode, then a discussion about what the _default_ default behavior should be
amounts to much ado about nothing.

> otherwise you need a way to summon it for one use and C-q
> doesn't fit there.)

Not sure what you mean by "one use".  Do you mean one search or one occurrence
in a search string that also has other occurrences of SPC?

If the former, then the answer is to toggle (and then toggle again when that
one-off search is over).  A quick toggle is perfect for a one-off search in the
other mode.

If the latter, then I guess you are saying that if magic-space search is off
(why talk about the _default_ here?) then in simple search it is hard to search
for _both_ a contiguous stretch of whitespace and a single SPC (or a given
number N of SPC chars) in the same search string.

If that's what you're saying, it is a red herring, Mr Herring.  That same
situation exists both today and with the proposal from Yidong.

That is a difficulty for simple search whether magic is off or on: One cannot
easily match both a stretch of whitespace and a single SPC (as opposed to a
stretch) in the same search string.  It is inherent to simple search - that use
case cries out for regexp search instead.

As such, this has nothing to do with what the default behavior should be.  But
as I say, I really do not care much what the default behavior is, as long as
users can set their own default behavior and toggle the behavior on the fly.

> As always, adding keys to isearch reduces the set you can use on exit
> (M-SPC is useful here).

Blah.

> > * Users can set the variable value in their init files, if
> >   they want to change the default (i.e., initial) behavior.
> 
> Er, yes?

Yes?

Dunno what is unclear here.  The point is that you and I can each start out with
the behavior we want.

Today, the _code_ decides in a hard-coded way that regexp search uses
magic-space and simple search does not.  Yidong proposes the opposite - but
still hard-coding.  And I guess you are agreeing with that proposal.

I'm saying let the user decide.  Both what the initial behavior is and on the
fly.

Re: Interpretation of a space in regexp isearch?

[Davis Herring]

>> Unless you filled a paragraph (perhaps via auto-fill-mode) and don't
>> remember doing so.
> 
> ?
> 
> Perhaps you mean filling with justification, so there can be stretches of
> multiple SPC chars?  Or perhaps you are referring to `SPC SPC' after a period?
> Sorry, I don't see the problem you are hinting at.

Because you typed a space between two words, but it eventually became a
newline (and possibly indentation).

> You would search for that anytime you would search for it. ;-)  Try searching
> your own message for `a b', for instance - that's `a', `SPC', `b'.
> 
> Honestly, it is silly to suppose that users never or rarely want to search for a
> set number of SPC chars, including for just one SPC.  Especially programmers.

What is silly is a file that contains (for a fixed ?a and ?b) so many "a
 b" substrings that C-s-ing through them to find your desired "a b"
instance is troublesome.

>> Is "let's add an isearch toggle key" what you meant by "We've been
>> through this before"?
> 
> No.  I have a vague recollection that we have discussed before whether Isearch
> should search for only a single SPC when you type a SPC.  I do not have a
> reference for you, however.

The "through this before" I hinted at was "you often argue for
additional toggle keys in isearch".  It was a bit of a poke, nothing
important.

> And yet we still have SPC being magic for regexp search, don't we?  Even though
> it is simple enough to use \s-+, and it always has been.

That's why all the +1s in this thread have been for moving the magic (by
default) to the non-regexp case where this trick doesn't work.

> I recognize that SPC acting "magically" can be useful whatever the search mode.
> Apparently you do not.

I see it as so useful in the simple case that it can merely be
customizable, not "togglable".

In the regexp case, it is not always useful, but it's already easy to
change, so I again need no toggle key for it.  Either I customize it on,
and I can use C-q SPC as needed, or I customize it off, and I can use
\s-+ as needed.

> But you are comparing apples and orangutans.  C-q does not toggle the search
> mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an
> otherwise magic-space sea.

With the default set to "more magic", C-q gets you "no magic", same as
your toggle would.  Your toggle would work the other way too, but as I
said I don't feel the need for the other way (often enough for an
isearch key).

> If [one occurrence] is what you're saying, it is a red herring, Mr Herring.  That same
> situation exists both today and with the proposal from Yidong.
> 
> That is a difficulty for simple search whether magic is off or on: One cannot
> easily match both a stretch of whitespace and a single SPC (as opposed to a
> stretch) in the same search string.  It is inherent to simple search - that use
> case cries out for regexp search instead.

With magic C-s, you can easily match it with appropriate C-q.  The
toggle would only be a win for a search string like
"lots_of_words_like_foo_bar_baz quux quoo frobozz bandersnatch cupcake"
where the _ represents a magic space and the spaces are not magic.  If
the string is instead "alternating words_with different_kinds
of_spaces", the toggle will be twice as expensive as C-q.  (I have no
idea which one of these is more likely; neither seems terribly common.)

>>> * Users can set the variable value in their init files, if
>>>   they want to change the default (i.e., initial) behavior.
>>
>> Er, yes?
> 
> Yes?
> 
> Dunno what is unclear here.  The point is that you and I can each start out with
> the behavior we want.

That users can customize Emacs is so obvious as to render that text
distracting.  It's not important.

> Today, the _code_ decides in a hard-coded way that regexp search uses
> magic-space and simple search does not.  Yidong proposes the opposite - but
> still hard-coding.  And I guess you are agreeing with that proposal.

The current code decides that regexp search has a custom option (which
is of course much heavier when it is not key-accessible), and that
simple search has no choice at all.  Yidong's proposal (given obvious
backward-compatibility obligations and standard customizability ideas)
would surely be to change the default for the existing variable and add
`search-search-whitespace-regexp' or so that controlled C-s, defaulted
to the current default for `search-whitespace-regexp'.  Given the rarity
(IMO) of caring about searching for single spaces in a simple search (as
would justify having quick access to both modes within simple search),
and the relative ease of making a regexp search do whatever you want
regardless of the value of `search-whitespace-regexp', I find no problem
with this proposal.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Interpretation of a space in regexp isearch?

[Dmitry Gutov]

On 15.08.2012 17:59, Drew Adams wrote:
> By default, "magic-space" searching should be OFF for both simple and regexp
> search.  Each SPC you type should search for a single SPC, by default.  Simple.
> No surprise.
>
> Others have given reasons for the regexp case (+1).  For the simple-search case:
> I do not think it is appropriate for users, especially newbies, to have to
> figure out and use `C-q SPC' (WTF?) to search for a single SPC char.

I have had `isearch-forward-regexp' bound to C-s for about as long as 
I'm using Emacs (thanks to starter-kit.el), and I've never encountered a 
situation where the current default behavior caused a problem. I never 
even knew that SPC did something special until I read the doc yesterday. 
Still, logically, it doesn't make sense since the `-regexp' version is 
supposed to be fine-controlled by the user, and they can easily write 
the required regexp.

On the flip side, I've seen many times that less-technical users can be 
sloppy with the amount of whitespace between words. If the non-regexp 
version is supposed to be easy to use, then `search-whitespace-regexp' 
behavior might be quite useful there. And `fill-paragraph' behavior adds 
to that argument, too.

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> On the flip side, I've seen many times that less-technical 
> users can be sloppy with the amount of whitespace between words.
> If the non-regexp version is supposed to be easy to use, then 
> `search-whitespace-regexp' behavior might be quite useful there.

Less-technical users are often used to less-technical editors that do NOT try to
be so clever (er, that is, "easy to use").

MS Word, for instance (yes, as far as simple searching is concerned, it can be
considered an editor).  And typical web browsers (whose simple on-page searching
can also be compared here).

You type a space to look for a space, two spaces to look for two spaces,...

Not every search (or even most searches?) by less-technical users is intended to
ignore additional whitespace.  Whitespace can matter to less-technical users
too.  And less-technical does not necessarily mean more sloppy, including about
whitespace between words.

Re: Interpretation of a space in regexp isearch?

[Dmitry Gutov]

On 16.08.2012 3:21, Drew Adams wrote:
>> On the flip side, I've seen many times that less-technical
>> users can be sloppy with the amount of whitespace between words.
>> If the non-regexp version is supposed to be easy to use, then
>> `search-whitespace-regexp' behavior might be quite useful there.
>
> Less-technical users are often used to less-technical editors that do NOT try to
> be so clever (er, that is, "easy to use").

Incremental search in Emacs is different enough from the search function 
in simple editors, I think, that doing things the same way is not very 
valuable.

> Not every search (or even most searches?) by less-technical users is intended to
> ignore additional whitespace.  Whitespace can matter to less-technical users
> too.  And less-technical does not necessarily mean more sloppy, including about
> whitespace between words.

Like I said, the amount of false positives is, in my experience, 
negligible. But it can prevent some false negatives, in some situations, 
for certain user expectations.

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> >> On the flip side, I've seen many times that less-technical
> >> users can be sloppy with the amount of whitespace between words.
> >> If the non-regexp version is supposed to be easy to use, then
> >> `search-whitespace-regexp' behavior might be quite useful there.
> >
> > Less-technical users are often used to less-technical 
> > editors that do NOT try to be so clever (er, that is, "easy
> > to use").
> 
> Incremental search in Emacs is different enough from the 
> search function in simple editors, I think, that doing things
> the same way is not very valuable.

Oh, we are so smart.

How come those who _invented_ incremental search and
_invented_ Emacs were not so terribly smart?
http://en.wikipedia.org/wiki/Incremental_search

Someone should also tell the web browsers that offer incremental search...

---

Seriously, I'm convinced of the usefulness of magic-SPC simple search.  No one
is suggesting that Emacs must "do things the same way" as simple editors.

The question about minimizing surprise here is a question about the _default_
behavior: which simple-search behavior is turned on to begin with, with `emacs
-Q'.

And I don't really care a whole lot whether you make magic-SPC the default
behavior.  What I care about more is (a) the ability to easily toggle it on/off
on the fly and (b) the ability for users to choose their own default (initial)
behavior.

---

BTW, it just occurred to me that when magic-SPC searching is turned on for
simple search, it could help to (optionally) highlight consecutive SPC, and any
non-SPC, whitespace chars in search hits (slightly) differently from the normal
search-hit highlighting.

And within a search hit, non-SPC whitespace chars (e.g. TAB, nobreak space)
could be highlighted (slightly) differently from SPC chars.  (This is for search
hits - not the same thing as `nobreak-char-display'.)

This would distinguish search hits with more than one whitespace char, and those
with non-SPC whitespace chars, from those with only one SPC char.  And it would
help users tell which SPC-search mode they are currently in.

It might be less surprising for a user who is not expecting (aware of) matching
of consecutive whitespace chars and matching of non-SPC whitespace chars when
s?he hits SPC, if such matches were more apparent.  And that includes not just a
newbie but also someone who has forgotten that magic-SPC search is turned on.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> IMO, that feature is what the user usually wants in an ordinary search
> (regardless it's incremental or not; even if that search is part of a
> ordinary replace command).
>
> On the other and, in a rexexp search (or regexp search&replace) I
> think that the common case is the opposite: the user normally doesn't
> want that feature.

I committed a change to trunk to make non-regexp isearch match multiple
spaces via search-spaces-regexp.

As for regexp isearch, it seems disruptive to remove the feature now,
since some some users might have grown to rely on it.  So I left regexp
isearch alone (i.e. it still does the multiple spaces matching).

It is now possible to change the variable `search-whitespace-regexp' and
give it a cons cell value, which specifies different behaviors for
ordinary and regexp isearch.

Re: Interpretation of a space in regexp isearch?

[Bastien]

Chong Yidong <cyd@gnu.org> writes:

> Dani Moncayo <dmoncayo@gmail.com> writes:
>
>> IMO, that feature is what the user usually wants in an ordinary search
>> (regardless it's incremental or not; even if that search is part of a
>> ordinary replace command).
>>
>> On the other and, in a rexexp search (or regexp search&replace) I
>> think that the common case is the opposite: the user normally doesn't
>> want that feature.
>
> I committed a change to trunk to make non-regexp isearch match multiple
> spaces via search-spaces-regexp.

Great, thanks.

> As for regexp isearch, it seems disruptive to remove the feature now,
> since some some users might have grown to rely on it.  So I left regexp
> isearch alone (i.e. it still does the multiple spaces matching).

I think the behavior in regexp isearch will be less surprising now.
So keeping the two behaviors (in isearch and regexp isearch) in sync
looks okay to me.

> It is now possible to change the variable `search-whitespace-regexp' and
> give it a cons cell value, which specifies different behaviors for
> ordinary and regexp isearch.

Even better!  Thanks for implementing this,

-- 
 Bastien

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

> I committed a change to trunk to make non-regexp isearch match multiple
> spaces via search-spaces-regexp.
>
> As for regexp isearch, it seems disruptive to remove the feature now,
> since some some users might have grown to rely on it.  So I left regexp
> isearch alone (i.e. it still does the multiple spaces matching).
>
> It is now possible to change the variable `search-whitespace-regexp' and
> give it a cons cell value, which specifies different behaviors for
> ordinary and regexp isearch.

Thank's Chong.

While testing your change, I've noticed a couple of things that I'd
like to understand:

1. Info mode has its own variable `Info-search-whitespace-regexp'.
Why is it necessary?  I guess there's a reason (which I don't know by
now) so it seems that your change should also affect to this variable.

2. Why don't you include \n and \r by default in the regexp?  IMO
that'd be TRT for most users.

TIA.

-- 
Dani Moncayo

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

> While testing your change, I've noticed a couple of things that I'd
> like to understand:
>
> 1. Info mode has its own variable `Info-search-whitespace-regexp'.
> Why is it necessary?  I guess there's a reason (which I don't know by
> now) so it seems that your change should also affect to this variable.
>
> 2. Why don't you include \n and \r by default in the regexp?  IMO
> that'd be TRT for most users.

3.  Why should this feature be limited to _incremental_ searches?  I
don't think it should.  The documentation states this limitation (see
[1][2][3]) but according to the tests I've done, non-incremental
searches also take `search-whitespace-regexp' into account.


-----------

[1] Docstring of command `isearch-forward'.
[2] Docstring of variable `search-whitespace-regexp'.
[3] Info node "(emacs) Regexp Search".

-- 
Dani Moncayo

Re: Interpretation of a space in regexp isearch?

[Johan Bockgård]

Chong Yidong <cyd@gnu.org> writes:

> I committed a change to trunk to make non-regexp isearch match multiple
> spaces via search-spaces-regexp.

The magic of `C-q SPC' is missing for non-regexp searches though.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> It is now possible to change the variable `search-whitespace-regexp' and
> give it a cons cell value, which specifies different behaviors for
> ordinary and regexp isearch.

I think a cons cell is an unsuitable data structure for this customization.
It has no room for extension.  For example, it makes sense to add
a value for word search that currently is hard-coded in `word-search-regexp'
as "\\W+", but there is no clean way to add it to this user option.

A better approach is to have two separate user options
for ordinary and regexp search whitespace like:

(defcustom search-whitespace-regexp "\\s-+"
  ...

(defcustom re-search-whitespace-regexp search-whitespace-regexp
  ...

`re-search-whitespace-regexp' inheriting its default value
from `search-whitespace-regexp' will provide backward-compatibility
for users who already customized the old variable.

Then later a new user option could be easily added for `word-search-regexp'
like:

(defcustom word-search-whitespace-regexp "\\W+"
  ...

Also I'm concerned about `re-search-forward' being slower than
`search-forward' for plain strings.  Could it be optimized
to use `search-forward' instead of `re-search-backward'
in non-regexp isearch at least in these three cases:

1. When there are no spaces in the search string;
2. When the user typed `C-q SPC';
3. When the user option `search-whitespace-regexp' is nil?

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> 1. Info mode has its own variable `Info-search-whitespace-regexp'.
> Why is it necessary?  I guess there's a reason (which I don't know by
> now)

`Info-search-whitespace-regexp' is used in the regexp-based `Info-search'.
Its default value is the same as for `search-whitespace-regexp'
(actually it could inherit the default value directly from the value of
`search-whitespace-regexp').

> so it seems that your change should also affect to this variable.

Yes, these changes affect this variable.  The condition that checks for
`isearch-regexp' should be removed from `Info-search' like in the patch
below (could be installed after resolving other problems).

> 2. Why don't you include \n and \r by default in the regexp?  IMO
> that'd be TRT for most users.

The default value of `search-whitespace-regexp' is "\\s-+"
that means it matches whitespace including \n and \r by default.
However, some modes override this default whitespace syntax
where newlines are not whitespace.  For example, in Lisp
a newline ends a comment.  But currently you can't search
in comments without regard to line breaks anyway.
To implement this, `search-whitespace-regexp' should also
ignore the semicolon that starts a comment.

> 3.  Why should this feature be limited to _incremental_ searches?  I
> don't think it should.  The documentation states this limitation (see
> [1][2][3]) but according to the tests I've done, non-incremental
> searches also take `search-whitespace-regexp' into account.

By the term "non-incremental searches" do you mean
`M-x nonincremental-search-forward RET' or `C-s RET'?

PS: The patch for info.el:

=== modified file 'lisp/info.el'
--- lisp/info.el	2012-08-25 20:00:40 +0000
+++ lisp/info.el	2012-08-28 08:27:44 +0000
@@ -328,7 +328,7 @@ (defcustom Info-breadcrumbs-depth 4
   :type 'integer
   :group 'info)
 
-(defcustom Info-search-whitespace-regexp "\\s-+"
+(defcustom Info-search-whitespace-regexp search-whitespace-regexp
   "If non-nil, regular expression to match a sequence of whitespace chars.
 This applies to Info search for regular expressions.
 You might want to use something like \"[ \\t\\r\\n]+\" instead.
@@ -1892,9 +1892,7 @@ (defun Info-search (regexp &optional bou
 		      (or (null found)
 			  (not (run-hook-with-args-until-failure
 				'isearch-filter-predicates beg-found found))))
-	    (let ((search-spaces-regexp
-		   (if (or (not isearch-mode) isearch-regexp)
-		       Info-search-whitespace-regexp)))
+	    (let ((search-spaces-regexp Info-search-whitespace-regexp))
 	      (if (if backward
 		      (re-search-backward regexp bound t)
 		    (re-search-forward regexp bound t))
@@ -1914,9 +1912,7 @@ (defun Info-search (regexp &optional bou
 	  (if (null Info-current-subfile)
 	      (if isearch-mode
 		  (signal 'search-failed (list regexp "at the end of manual"))
-		(let ((search-spaces-regexp
-		       (if (or (not isearch-mode) isearch-regexp)
-			   Info-search-whitespace-regexp)))
+		(let ((search-spaces-regexp Info-search-whitespace-regexp))
 		  (if backward
 		      (re-search-backward regexp)
 		    (re-search-forward regexp))))
@@ -1975,9 +1971,7 @@ (defun Info-search (regexp &optional bou
 			    (or (null found)
 				(not (run-hook-with-args-until-failure
 				      'isearch-filter-predicates beg-found found))))
-		  (let ((search-spaces-regexp
-			 (if (or (not isearch-mode) isearch-regexp)
-			     Info-search-whitespace-regexp)))
+		  (let ((search-spaces-regexp Info-search-whitespace-regexp))
 		    (if (if backward
 			    (re-search-backward regexp nil t)
 			  (re-search-forward regexp nil t))

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> The magic of `C-q SPC' is missing for non-regexp searches though.

`C-q SPC' inserts "[ ]" in regexp search.  The problem for non-regexp
search is how to avoid quoting "[ ]" in `regexp-quote'.

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

On Tue, Aug 28, 2012 at 10:28 AM, Juri Linkov <juri@jurta.org> wrote:
>> 1. Info mode has its own variable `Info-search-whitespace-regexp'.
>> Why is it necessary?  I guess there's a reason (which I don't know by
>> now)
>
> `Info-search-whitespace-regexp' is used in the regexp-based `Info-search'.

OK but why do we need it?  I.e, why can't use
`search-whitespace-regexp' also in Info mode?

> Its default value is the same as for `search-whitespace-regexp'
> (actually it could inherit the default value directly from the value of
> `search-whitespace-regexp').
>
>> so it seems that your change should also affect to this variable.
>
> Yes, these changes affect this variable.  The condition that checks for
> `isearch-regexp' should be removed from `Info-search' like in the patch
> below (could be installed after resolving other problems).

Does your patch makes `Info-search-whitespace-regexp' in Info mode
behave like `search-whitespace-regexp' in other modes?

>> 2. Why don't you include \n and \r by default in the regexp?  IMO
>> that'd be TRT for most users.
>
> The default value of `search-whitespace-regexp' is "\\s-+"
> that means it matches whitespace including \n and \r by default.
> However, some modes override this default whitespace syntax
> where newlines are not whitespace.  For example, in Lisp
> a newline ends a comment.  But currently you can't search
> in comments without regard to line breaks anyway.
> To implement this, `search-whitespace-regexp' should also
> ignore the semicolon that starts a comment.

Ok I see it now.

>> 3.  Why should this feature be limited to _incremental_ searches?  I
>> don't think it should.  The documentation states this limitation (see
>> [1][2][3]) but according to the tests I've done, non-incremental
>> searches also take `search-whitespace-regexp' into account.
>
> By the term "non-incremental searches" do you mean
> `M-x nonincremental-search-forward RET' or `C-s RET'?

I mean `C-s RET' or `C-M-s RET'.


-- 
Dani Moncayo

Re: Interpretation of a space in regexp isearch?

[Stefan Monnier]

I have other things to do, so I haven't participated in this thread,
but FWIW, I think that search-whitespace-regexp is not something that
should be used by default.


        Stefan "who also dislikes its internal implementation"


>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

>> The magic of `C-q SPC' is missing for non-regexp searches though.
> `C-q SPC' inserts "[ ]" in regexp search.  The problem for non-regexp
> search is how to avoid quoting "[ ]" in `regexp-quote'.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> I have other things to do, so I haven't participated in this thread,
> but FWIW, I think that search-whitespace-regexp is not something that
> should be used by default.

Ignoring whitespace in isearch is a very useful feature.
But I agree that its current implementation is far from optimal.

It would be better to reimplement it in isearch exactly the same way
as `isearch-word' is implemented because these two are similar features.

A new `isearch-whitespace' toggled by `M-s SPC' could construct a regexp
like in `word-search-regexp' and search it with `re-search-forward' in
`isearch-search-fun-default'.  This will provide flexibility to solve
related problems.

To make this feature less "magic" and surprising to users,
it could reveal a constructed regexp after switching from ordinary
isearch mode to regexp mode.  As well as after switching from word mode
to regexp mode could also reveal the regexp used to search words
ignoring punctuation.

Another variant to implement `isearch-toggle-whitespace' is like
`isearch-toggle-case-fold' that changes the value of the internal
variable `case-fold-search' effective to both regexp and non-regexp
searches.  But I don't know how difficult is to modify the
search engine to ignore whitespace the same way as it ignores case
using translation tables.

Regarding the need to quote literal spaces in non-regexp search,
one example of possible solution is HTML that uses "nobr"
for essential whitespace that should not be ignored.
Doing the same in isearch for `C-q SPC' would insert "no-break space"
to the search string.  Then repeating a non-regexp search
from the search ring will correctly interpret it as a literal space
(as opposed to the normal space character interpreted as whitespace pattern).

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

>> `Info-search-whitespace-regexp' is used in the regexp-based `Info-search'.
>
> OK but why do we need it?  I.e, why can't use
> `search-whitespace-regexp' also in Info mode?

Maybe we could make `Info-search-whitespace-regexp' obsolete now.

> Does your patch makes `Info-search-whitespace-regexp' in Info mode
> behave like `search-whitespace-regexp' in other modes?

Yes, I see no differences.

>>> 3.  Why should this feature be limited to _incremental_ searches?  I
>>> don't think it should.  The documentation states this limitation (see
>>> [1][2][3]) but according to the tests I've done, non-incremental
>>> searches also take `search-whitespace-regexp' into account.
>>
>> By the term "non-incremental searches" do you mean
>> `M-x nonincremental-search-forward RET' or `C-s RET'?
>
> I mean `C-s RET' or `C-M-s RET'.

Then the word "incremental" should be removed from the docstrings of
`isearch-forward' and `search-whitespace-regexp' and from the Info node
"(emacs) Regexp Search".

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> Regarding the need to quote literal spaces in non-regexp search,
> one example of possible solution is HTML that uses "nobr"
> for essential whitespace that should not be ignored.
> Doing the same in isearch for `C-q SPC' would insert "no-break space"
> to the search string.  Then repeating a non-regexp search
> from the search ring will correctly interpret it as a literal space
> (as opposed to the normal space character interpreted as 
> whitespace pattern).

I liked most of what you said up to that point.  It generally echoes what I said
earlier (including adding a toggle).

But I don't agree with this last part.  We should not mix nobreak-space with
this whitespace-search feature, at all.

Users should keep the ability to search for nobreak-space chars and ordinary
space chars separately, including in the same search string.  The former are
perfectly legitimate, normal chars.  If you cannot type a nobreak-space char to
search literally for such a char, then we're back at square 1.

Please do not look for any existing char to signify something special here, thus
taking it away from literal search.

C-q should be the only char/key that does that kind of thing.

It's fine to have keys that toggle different search "modes" (word, case-fold,
diff whitespace patterns, etc.).  But let's not sacrifice some char (e.g.
nobreak-space), so that its use in a search string means something special, not
searching for itself.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> The magic of `C-q SPC' is missing for non-regexp searches though.
>
> `C-q SPC' inserts "[ ]" in regexp search.  The problem for non-regexp
> search is how to avoid quoting "[ ]" in `regexp-quote'.

Good point.  Here's how to handle this: when isearch-regexp is nil, make
isearch-process-search-string call regexp-quote for each addition to the
search string; then have isearch-quote-char suppress quoting by passing
an optional arg to isearch-process-search-string.

Then in isearch-search-fun-default, we can use re-search-forward for
plain isearch as well, since the search string will have been
appropriately quoted when processed.  See attached patch.


*** lisp/isearch.el	2012-08-26 04:08:32 +0000
--- lisp/isearch.el	2012-08-29 06:38:42 +0000
***************
*** 2200,2217 ****
    "Quote special characters for incremental search."
    (interactive)
    (let ((char (read-quoted-char (isearch-message t))))
!     ;; Assume character codes 0200 - 0377 stand for characters in some
!     ;; single-byte character set, and convert them to Emacs
!     ;; characters.
!     (if (and isearch-regexp (= char ?\s))
! 	(if (subregexp-context-p isearch-string (length isearch-string))
! 	    (isearch-process-search-string "[ ]" " ")
! 	  (isearch-process-search-char char))
        (and enable-multibyte-characters
  	   (>= char ?\200)
  	   (<= char ?\377)
  	   (setq char (unibyte-char-to-multibyte char)))
!       (isearch-process-search-char char))))
  
  (defun isearch-printing-char ()
    "Add this ordinary printing character to the search string and search."
--- 2200,2222 ----
    "Quote special characters for incremental search."
    (interactive)
    (let ((char (read-quoted-char (isearch-message t))))
!     (cond
!      ((/= char ?\s)
!       ;; Assume character codes 0200 - 0377 stand for characters in
!       ;; some single-byte character set, and convert them to Emacs
!       ;; characters.
        (and enable-multibyte-characters
  	   (>= char ?\200)
  	   (<= char ?\377)
  	   (setq char (unibyte-char-to-multibyte char)))
!       (isearch-process-search-char char))
!      ((and isearch-regexp
! 	   (null (subregexp-context-p isearch-string
! 				      (length isearch-string))))
!       (isearch-process-search-char char))
!      ;; Handle C-q SPC by disabling `search-whitespace-regexp' match.
!      (t
!       (isearch-process-search-string "[ ]" " " t)))))
  
  (defun isearch-printing-char ()
    "Add this ordinary printing character to the search string and search."
***************
*** 2239,2245 ****
         (char-to-string char)
       (isearch-text-char-description char))))
  
! (defun isearch-process-search-string (string message)
    (setq isearch-string (concat isearch-string string)
  	isearch-message (concat isearch-message message))
    (isearch-search-and-update))
--- 2244,2252 ----
         (char-to-string char)
       (isearch-text-char-description char))))
  
! (defun isearch-process-search-string (string message &optional no-quote)
!   (unless (or isearch-regexp no-quote)
!     (setq string (regexp-quote string)))
    (setq isearch-string (concat isearch-string string)
  	isearch-message (concat isearch-message message))
    (isearch-search-and-update))
***************
*** 2443,2458 ****
  	     (funcall isearch-word string lax)
  	   (word-search-regexp string lax))
  	 bound noerror count))))
-    (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 (regexp-quote string) bound noerror count))
! 
! (defun isearch-search-backward (string &optional bound noerror count)
!   (re-search-backward (regexp-quote string) bound noerror count))
  
  (defun isearch-search-string (string bound noerror)
    "Search for the first occurrence of STRING or its translation.
--- 2450,2457 ----
  	     (funcall isearch-word string lax)
  	   (word-search-regexp string lax))
  	 bound noerror count))))
     (t
!     (if isearch-forward 're-search-forward 're-search-backward))))
  
  (defun isearch-search-string (string bound noerror)
    "Search for the first occurrence of STRING or its translation.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> A better approach is to have two separate user options
> for ordinary and regexp search whitespace like:
>
> (defcustom search-whitespace-regexp "\\s-+"
>   ...
>
> (defcustom re-search-whitespace-regexp search-whitespace-regexp
>   ...

I'm OK with having two options, but the trouble is finding the right
names: they need to have the right prefix.  I don't like
re-search-whitespace-regexp, because the name seems to indicate that it
affects re-search-forward the Lisp function, rather than the incremental
regexp search user-level feature.  (Note that search-whitespace-regexp
is similarly poorly named).

Maybe isearch-spaces-regexp and isearch-regexp-spaces-regexp, with
search-whitespace-regexp an obsolete alias for the latter?  Though
isearch-regexp-spaces-regexp sounds a bit weird.

> Also I'm concerned about `re-search-forward' being slower than
> `search-forward' for plain strings.

Someone mentioned that he had replaced C-s with isearch-forward-regexp
for a long time, without any ill effects.  Let's revisit the speed issue
iff it actually bites in practice.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

>>> The magic of `C-q SPC' is missing for non-regexp searches though.
>>
>> `C-q SPC' inserts "[ ]" in regexp search.  The problem for non-regexp
>> search is how to avoid quoting "[ ]" in `regexp-quote'.
>
> Good point.  Here's how to handle this: when isearch-regexp is nil, make
> isearch-process-search-string call regexp-quote for each addition to the
> search string; then have isearch-quote-char suppress quoting by passing
> an optional arg to isearch-process-search-string.
>
> Then in isearch-search-fun-default, we can use re-search-forward for
> plain isearch as well, since the search string will have been
> appropriately quoted when processed.  See attached patch.

Unfortunately, this will expose the regexp used in non-regexp search
in such cases as editing the search string with M-e or repeating
the previous search from the search ring.  All special regexp characters
will be displayed as quoted with \.  This will mean that there is no more
plain non-regexp search from the user's point of view.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> I'm OK with having two options, but the trouble is finding the right
> names: they need to have the right prefix.  I don't like
> re-search-whitespace-regexp, because the name seems to indicate that it
> affects re-search-forward the Lisp function, rather than the incremental
> regexp search user-level feature.  (Note that search-whitespace-regexp
> is similarly poorly named).
>
> Maybe isearch-spaces-regexp and isearch-regexp-spaces-regexp, with
> search-whitespace-regexp an obsolete alias for the latter?  Though
> isearch-regexp-spaces-regexp sounds a bit weird.

There are other variables that have the `search-' prefix instead of
`isearch-'.  I don't know why.  But when using the same naming convention
as is used in `search-ring' and `regexp-search-ring', or in
`search-ring-max' and `regexp-search-ring-max', or in
`search-ring-yank-pointer' and `regexp-search-ring-yank-pointer' etc.
then the variable names would be:
`search-whitespace-regexp' and `regexp-search-whitespace-regexp'.
I have no opinion about the `isearch-' prefix but at least
these names will be consistent with other search variable names.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> But let's not sacrifice some char (e.g. nobreak-space), so that its
> use in a search string means something special, not searching for itself.

The space character is special to indicate whitespace.
We need another special character to indicate literal space
in non-regexp searches.  Could you find a better character
than nobreak-space?

Re: Interpretation of a space in regexp isearch?

[Stefan Monnier]

> Unfortunately, this will expose the regexp used in non-regexp search
> in such cases as editing the search string with M-e or repeating
> the previous search from the search ring.  All special regexp characters
> will be displayed as quoted with \.  This will mean that there is no more
> plain non-regexp search from the user's point of view.

Agreed.  It will also show up when you hit M-% or similarly reuse the
last search string in things like occur.  It can all be fixed with more
code, but it complicates everything for very little benefit.
I'd rather we just don't bother with search-whitespace-regexp in the
default isearch behavior, especially since nobody actually requested
it, AFAICT (at best, people pointed out that it seems counterintuitive
to have it in regexp-search but not in the normal search).


        Stefan

Re: Interpretation of a space in regexp isearch?

[Dani Moncayo]

> I'd rather we just don't bother with search-whitespace-regexp in the
> default isearch behavior, especially since nobody actually requested
> it, AFAICT (at best, people pointed out that it seems counterintuitive
> to have it in regexp-search but not in the normal search).

FWIW, I am _very_ interested in this feature.  Having the ability of
using it at will both in basic and regexp search (and replace)
commands is a very useful feature which I'll use everyday.

And I'm convinced many other people will use it too.

-- 
Dani Moncayo

RE: Interpretation of a space in regexp isearch?

[Drew Adams]

> > But let's not sacrifice some char (e.g. nobreak-space), so that its
> > use in a search string means something special, not 
> searching for itself.
> 
> The space character is special to indicate whitespace.
> We need another special character

IMO, you are too liberal with the "we need"s.

> to indicate literal space in non-regexp searches.

I don't buy the assumption that we need a "special char" to indicate a literal
space in a non-regexp search.

Toggling this new mode on/off should suffice for most simple searches where you
want to search for literal SPC chars.

For the remainder, i.e., simple searches where both literal spaces and
magic-whitespace are searched for in the same search string, I would say that
users should take one of these approaches:

1. use regexp search instead (seriously)
2. use C-q (or perhaps C-u?) to escape the following character to be treated
literally

#2 might require some work by Emacs Dev.

> Could you find a better character than nobreak-space?

Sorry, I don't buy the claim that "we need another special character to indicate
literal space in non-regexp searches."

---

Look, we could be doing this kind of thing for other magic search strings also.
Essentially the idea is to come up with a shortcut (for typing and visibility)
for a regexp (or other complex searching pattern/mechanism) that is used often,
for common matches.

A second part of the idea is to hide the fact that such complex searching is
involved - whether for simple or regexp searching.

If a user knows that s?he is doing regexp search, then any shortcut "mode" that
enables the user to, say, type only `(' instead of `\(', can be turned on/off
with a toggle.  Yes, sure, we need to define each mode state completely, e.g.,
how to indicate a literal `(' when `(' means what `\(' means in the opposite
mode state.

I proposed long ago, for instance, a toggle for a `.' in regexp search to match
also newlines, i.e., any character.  IOW, `.' in one mode state of the toggle,
`.' would be equivalent to "\\(.\\|[\n]\\)" in the other (traditional) state.

I still think that particular enhancement would be helpful.  I've used it in
Icicles for years, and it is very handy, IMO.  I use text properties so the user
(optionally, and by default) sees only `.' when s?he types `.', but in fact what
is used is the regexp that matches also \n.

Such a magic, multi-line dot is (optionally) highlighted in the minibuffer, so
you can distinguish it.  And you can hit a key to toggle the state.  And you can
hit another key to toggle whether the `.' is shown as `.' or as its underlying
regexp.  When such a multi-line dot is present in the minibuffer, editing treats
it as a single char; e.g., it DTRT when you delete or transpose chars.

How do I deal with the case of mixing multi-line and ordinary dots in the same
minibuffer input (analog to a search string)?  A prefix arg to `.' flips it from
its usual behavior (whether multi-line or normal/literal) to the opposite.  We
_might_ want to do similarly for Isearch.

Here is a bit more explanation.
http://www.emacswiki.org/emacs/Icicles_-_Dot%2c_Dot%2c_Dot

Consider that food for thought.  I'm not actively suggesting that the same
approach should be used for Isearch, or that it is "the answer".

My point here is:

1. The motivation for the current magic whitespace discussion can be generalized
to other magic chars or SOMETHING-ignoring modes.  So the discussion should
perhaps be more general also.

2. Sacrificing a "special char" (e.g. nobreak-space) for this kind of thing is
the wrong approach, IMO.

I would also add that whenever we do something like this that hides what's
really going on from the user, as a convenience, there is the possibility of
confusion and complication.  So we had better enable users to alternatively SEE
what is otherwise hidden.

A toggle to show the ugly, underlying stuff as part of the search string is
helpful to users.  For one thing, it can help them understand why what they
think they are searching for might not be what they are really searching for.
It gives them a means to investigate and learn more.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> Toggling this new mode on/off should suffice for most simple searches
> where you want to search for literal SPC chars.

I agree there is less trouble toggling whitespace mode with `M-s SPC'
than applying an ugly solution to quote literal spaces with `C-q SPC'.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> It will also show up when you hit M-% or similarly reuse the
> last search string in things like occur.

Bug#10885 should be fixed anyway even for the old functionality of using
whitespace in isearch-regexp because currently when replacement is
started from isearch-regexp it doesn't find the same matches as isearch.

> It can all be fixed with more code, but it complicates everything for
> very little benefit.

I believe adding whitespace mode (implemented like `isearch-toggle-word'
or `isearch-toggle-case-fold') and without quoting literal spaces
will simplify existing functionality that is currently inconsistent
and hardly customizable.

Other related programs have two counterpart options to ignore case and ignore
whitespace like e.g. Diff with --ignore-case and --ignore-all-space
or in Emacs two options `compare-ignore-case' and `compare-ignore-whitespace'.

The functionality to ignore case is well supported in search and replace
with the command `isearch-toggle-case-fold' and the user options
`search-upper-case' in isearch, and `case-replace' in replace.
But ignoring whitespace is underdeveloped in search and replace.
I think just replicating the same options for whitespace will
fill this gap in functionality.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> It would be better to reimplement it in isearch exactly the same way
> as `isearch-word' is implemented because these two are similar
> features.
>
> A new `isearch-whitespace' toggled by `M-s SPC' could construct a regexp
> like in `word-search-regexp' and search it with `re-search-forward' in
> `isearch-search-fun-default'.  This will provide flexibility to solve
> related problems.

I think this is a good idea.

I'd like the whitespace munging to be enabled for C-s, unless the user
disables it by customizing `search-whitespace-regexp' (or whatever
variable we decide on).  So `isearch-forward' itself should pass the
relevant flag to `isearch-mode'.

Instead of adding an `isearch-whitespace' flag, I think this is best
implemented as a third possible value for `isearch-word', say the symbol
`match-any-whitespace'.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> Instead of adding an `isearch-whitespace' flag, I think this is best
> implemented as a third possible value for `isearch-word', say the
> symbol `match-any-whitespace'.

Whoops, `isearch-word' already accepts function values, for purposes of
symbol searching.  The `isearch-toggle-whitespace' command simply needs
to set this.  Maybe that's is what you already had in mind.

Do you want to take a crack at it, or shall I?

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

>> Instead of adding an `isearch-whitespace' flag, I think this is best
>> implemented as a third possible value for `isearch-word', say the
>> symbol `match-any-whitespace'.
>
> Whoops, `isearch-word' already accepts function values, for purposes of
> symbol searching.  The `isearch-toggle-whitespace' command simply needs
> to set this.  Maybe that's is what you already had in mind.

The problem is that whitespace mode can be active together with regexp mode
and also simultaneously with plain C-s mode.  This is different from
`isearch-word' that is a separate mode mutually exclusive with C-s and C-M-s.
For instance, `isearch-toggle-regexp' sets `isearch-word' to nil, but it
should not disable whitespace mode (it should be disabled only with
the command `isearch-toggle-whitespace').

This is why I tend to implement it more like `isearch-toggle-case-fold'
than `isearch-toggle-word'.

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> (defcustom search-whitespace-regexp "\\s-+"
>   ...
>
> (defcustom re-search-whitespace-regexp search-whitespace-regexp
>   ...
>
> `re-search-whitespace-regexp' inheriting its default value
> from `search-whitespace-regexp' will provide backward-compatibility
> for users who already customized the old variable.

This trick to preserve backward compatibility doesn't work for
isearch.el's defcustoms, because they are loaded by default.  So if the
user customizes `search-whitespace-regexp', a new
`regexp-search-whitespace-regexp' in isearch.el would end up with the
default value of s-w-r, not the customized value.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> This trick to preserve backward compatibility doesn't work for
> isearch.el's defcustoms, because they are loaded by default.  So if the
> user customizes `search-whitespace-regexp', a new
> `regexp-search-whitespace-regexp' in isearch.el would end up with the
> default value of s-w-r, not the customized value.

Actually I see no need to have two separate values of whitespace regexps.

What is needed more is a new option to enable/disable this feature
without changing the value of `search-whitespace-regexp'.

Then its default value could depend on the major mode.  For instance,
the users might want to enable whitespace mode in Text mode, Help mode and
Info mode, but not in other modes.  This will be easy to do in hooks
setting a buffer-local value of the new variable `search-whitespace'
(or `whitespace-search').

So it will have the same flexibility as its counterpart option
`case-fold-search' (but its isearch implementation will be different
because currently whitespace mode is applicable only to regexp search).

Re: Interpretation of a space in regexp isearch?

[Stefan Monnier]

> The problem is that whitespace mode can be active together with regexp mode
> and also simultaneously with plain C-s mode.

I think that combining whitespace mode with regexp mode was a mistake,
so I'm not sure how important it is to support it.


        Stefan

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

>> The problem is that whitespace mode can be active together with regexp mode
>> and also simultaneously with plain C-s mode.
>
> I think that combining whitespace mode with regexp mode was a mistake,
> so I'm not sure how important it is to support it.

Disallowing whitespace mode with regexp mode will simplify matters,
and if someone still wants this functionality then it could be
configured by adding a new user option `regexp-search-whitespace'
(like `search-whitespace' but for regexp mode).

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> Chong Yidong <cyd@gnu.org> writes:
>
> Do you want to take a crack at it, or shall I?

The following patch just echoes what was being said
in this discussion so far.  Please review it and decide
what to do next.

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2012-08-27 04:08:32 +0000
+++ lisp/isearch.el	2012-08-31 00:04:17 +0000
@@ -109,6 +109,19 @@ (defcustom search-nonincremental-instead
   :type 'boolean
   :group 'isearch)
 
+(defcustom search-whitespace t
+    "If non-nil, a space will match a sequence of whitespace chars.
+When you enter a space or spaces in the incremental search, it
+will match any sequence matched by the regexp in the variable
+`search-whitespace-regexp'.
+
+If the value is nil, each space you type matches literally,
+against one space."
+  :type '(choice (const :tag "Treat Spaces Literally" nil)
+		 (const :tag "Match a sequence of whitespace chars" t))
+  :group 'isearch
+  :version "24.3")
+
 (defcustom search-whitespace-regexp (purecopy "\\s-+")
   "If non-nil, regular expression to match a sequence of whitespace chars.
 When you enter a space or spaces in the incremental search, it
@@ -120,20 +133,10 @@ (defcustom search-whitespace-regexp (pur
 incremental search.  If the value is nil, each space you type
 matches literally, against one space.
 
-The value can also be a cons cell (REGEXP-1 . REGEXP-2).  In that
-case, REGEXP-1 is used as the value for ordinary incremental
-search, and REGEXP-2 is used for regexp incremental search.
-
 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 '(choice (const :tag "Treat Spaces Literally" nil)
-		 (cons (choice :tag "For Ordinary Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil))
-		       (choice :tag "For Regexp Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil)))
 		 regexp)
   :group 'isearch
   :version "24.3")
@@ -510,6 +525,7 @@ (defvar isearch-mode-map
     (define-key map "\M-r" 'isearch-toggle-regexp)
     (define-key map "\M-e" 'isearch-edit-string)
 
+    (define-key map "\M-s " 'isearch-toggle-whitespace)
     (define-key map "\M-sc" 'isearch-toggle-case-fold)
     (define-key map "\M-sr" 'isearch-toggle-regexp)
     (define-key map "\M-sw" 'isearch-toggle-word)
@@ -1374,7 +1400,8 @@ (defun isearch-toggle-regexp ()
   ;; The status stack is left unchanged.
   (interactive)
   (setq isearch-regexp (not isearch-regexp))
-  (if isearch-regexp (setq isearch-word nil))
+  (if isearch-regexp (setq isearch-word nil
+			   search-whitespace nil))
   (setq isearch-success t isearch-adjusted t)
   (isearch-update))
 
@@ -1383,7 +1410,8 @@ (defun isearch-toggle-word ()
   ;; The status stack is left unchanged.
   (interactive)
   (setq isearch-word (not isearch-word))
-  (if isearch-word (setq isearch-regexp nil))
+  (if isearch-word (setq isearch-regexp nil
+			 search-whitespace nil))
   (setq isearch-success t isearch-adjusted t)
   (isearch-update))
 
@@ -1392,6 +1420,8 @@ (defun isearch-toggle-symbol ()
   (interactive)
   (setq isearch-word (unless (eq isearch-word 'isearch-symbol-regexp)
 		       'isearch-symbol-regexp))
+  (if isearch-word (setq isearch-regexp nil
+			 search-whitespace nil))
   (setq isearch-success t isearch-adjusted t)
   (isearch-update))
 
@@ -1409,6 +1439,19 @@ (defun isearch-toggle-case-fold ()
   (sit-for 1)
   (isearch-update))
 
+(defun isearch-toggle-whitespace ()
+  "Toggle whitespace matching in searching on or off."
+  (interactive)
+  (setq search-whitespace (not search-whitespace))
+  (let ((message-log-max nil))
+    (message "%s%s [whitespace matching %s]"
+	     (isearch-message-prefix nil isearch-nonincremental)
+	     isearch-message
+	     (if search-whitespace "enabled" "disabled")))
+  (setq isearch-success t isearch-adjusted t)
+  (sit-for 1)
+  (isearch-update))
+
 \f
 ;; Word search
 
@@ -1558,15 +1611,6 @@ (defun isearch-query-replace-regexp (&op
    (list current-prefix-arg))
   (isearch-query-replace delimited t))
 
-(defun isearch-whitespace-regexp ()
-  "Return the value of `search-whitespace-regexp' for the current search."
-  (cond ((not (consp search-whitespace-regexp))
-	 search-whitespace-regexp)
-	(isearch-regexp
-	 (cdr search-whitespace-regexp))
-	(t
-	 (car search-whitespace-regexp))))
-
 (defun isearch-occur (regexp &optional nlines)
   "Run `occur' using the last search string as the regexp.
 Interactively, REGEXP is constructed using the search string from the
@@ -1606,7 +1650,8 @@ (defun isearch-occur (regexp &optional n
 	;; Set `search-upper-case' to nil to not call
 	;; `isearch-no-upper-case-p' in `occur-1'.
 	(search-upper-case nil)
-	(search-spaces-regexp (isearch-whitespace-regexp)))
+	(search-spaces-regexp (if search-whitespace
+				  search-whitespace-regexp)))
     (occur regexp nlines)))
 
 (declare-function hi-lock-read-face-name "hi-lock" ())
@@ -2428,6 +2488,8 @@ (defun isearch-search-fun ()
 (defun isearch-search-fun-default ()
   "Return default functions to use for the search."
   (cond
+   ((and search-whitespace search-whitespace-regexp (not isearch-regexp))
+    (if isearch-forward 'whitespace-search-forward 'whitespace-search-backward))
    (isearch-word
     (lambda (string &optional bound noerror count)
       ;; Use lax versions to not fail at the end of the word while
@@ -2446,12 +2508,12 @@ (defun isearch-search-fun-default ()
    (isearch-regexp
     (if isearch-forward 're-search-forward 're-search-backward))
    (t
-    (if isearch-forward 'isearch-search-forward 'isearch-search-backward))))
+    (if isearch-forward 'search-forward 'search-backward))))
 
-(defun isearch-search-forward (string &optional bound noerror count)
+(defun whitespace-search-forward (string &optional bound noerror count)
   (re-search-forward (regexp-quote string) bound noerror count))
 
-(defun isearch-search-backward (string &optional bound noerror count)
+(defun whitespace-search-backward (string &optional bound noerror count)
   (re-search-backward (regexp-quote string) bound noerror count))
 
 (defun isearch-search-string (string bound noerror)
@@ -2503,7 +2565,8 @@ (defun isearch-search ()
 		  search-invisible))
 	    (inhibit-quit nil)
 	    (case-fold-search isearch-case-fold-search)
-	    (search-spaces-regexp (isearch-whitespace-regexp))
+	    (search-spaces-regexp (if search-whitespace
+				      search-whitespace-regexp))
 	    (retry t))
 	(setq isearch-error nil)
 	(while retry
@@ -2805,7 +2912,8 @@ (defvar isearch-lazy-highlight-window-st
 (defvar isearch-lazy-highlight-window-end nil)
 (defvar isearch-lazy-highlight-case-fold-search nil)
 (defvar isearch-lazy-highlight-regexp nil)
-(defvar isearch-lazy-highlight-space-regexp nil)
+(defvar isearch-lazy-highlight-whitespace nil)
+(defvar isearch-lazy-highlight-whitespace-regexp nil)
 (defvar isearch-lazy-highlight-word nil)
 (defvar isearch-lazy-highlight-forward nil)
 (defvar isearch-lazy-highlight-error nil)
@@ -2873,7 +2981,8 @@ (defun isearch-lazy-highlight-new-loop (
 	  isearch-lazy-highlight-last-string  isearch-string
 	  isearch-lazy-highlight-case-fold-search isearch-case-fold-search
 	  isearch-lazy-highlight-regexp       isearch-regexp
-	  isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp)
+	  isearch-lazy-highlight-whitespace   search-whitespace
+	  isearch-lazy-highlight-whitespace-regexp search-whitespace-regexp
 	  isearch-lazy-highlight-word         isearch-word
 	  isearch-lazy-highlight-forward      isearch-forward)
       (unless (equal isearch-string "")
@@ -2887,7 +2996,8 @@ (defun isearch-lazy-highlight-search ()
   (condition-case nil
       (let ((case-fold-search isearch-lazy-highlight-case-fold-search)
 	    (isearch-regexp isearch-lazy-highlight-regexp)
-	    (search-spaces-regexp isearch-lazy-highlight-space-regexp)
+	    (search-spaces-regexp (if isearch-lazy-highlight-whitespace
+				      isearch-lazy-highlight-whitespace-regexp))
 	    (isearch-word isearch-lazy-highlight-word)
 	    (search-invisible nil)	; don't match invisible text
 	    (retry t)

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> The following patch just echoes what was being said
> in this discussion so far.  Please review it and decide
> what to do next.

Thanks, this mostly looks good.  Some comments:

- search-whitespace should not be a defcustom, since it is altered by
  commands like isearch-toggle-whitespace.  Users can customize whether
  to enable the feature by default setting search-whitespace-regexp to
  either nil or a regexp.  I think search-whitespace should be renamed
  to something more accurate like isearch-lax-space-match, and made into
  a defvar.

- Don't call the functions whitespace-search-forward; the whitespace-
  prefix should be reserved for whitespace.el.  Call it something like
  isearch-forward-lax-space-match.

- Instead of [whitespace matching enabled/disabled], I suggest the
  messages [strict space matching] and [lax space matching].

Also, I guess it won't be difficult to make M-s SPC work for regexp
search too, by making it change search-spaces-regexp.  This can be left
for later.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> - search-whitespace should not be a defcustom, since it is altered by
>   commands like isearch-toggle-whitespace.  Users can customize whether
>   to enable the feature by default setting search-whitespace-regexp to
>   either nil or a regexp.  I think search-whitespace should be renamed
>   to something more accurate like isearch-lax-space-match, and made into
>   a defvar.

Like there are two existing variables with similar functionality
`compare-windows-whitespace' and `compare-ignore-whitespace',
maybe it would be better to have similar names in isearch:
the already existing `search-whitespace-regexp'
and a new defvar `isearch-ignore-whitespace'.

> - Don't call the functions whitespace-search-forward; the whitespace-
>   prefix should be reserved for whitespace.el.  Call it something like
>   isearch-forward-lax-space-match.

The prefix `isearch-' is not quite right because these functions
can be used in other packages like replace.el being bound to
`replace-search-function'.  `search-' seems more right.

And when using the suffix `-ignore-whitespace' we could have functions:
`search-forward-ignore-whitespace' and `search-backward-ignore-whitespace'.

Or do you think `-ignore-whitespace' implies a more general functionality?
For instance, instead of the current limited implementation that just
turns every space character into a whitespace regexp like in:

(defun search-forward-ignore-whitespace (string &optional bound noerror count)
  (let ((search-spaces-regexp search-whitespace-regexp))
    (re-search-forward (regexp-quote string) bound noerror count)))

it would be also useful to completely ignore all whitespace differences
between the search string and the buffer text with the following
implementation:

(defun search-whitespace-regexp (string)
  (replace-regexp-in-string
   search-whitespace-regexp
   search-whitespace-regexp
   string nil t))

(defun search-forward-ignore-whitespace (string &optional bound noerror count)
  (re-search-forward (search-whitespace-regexp (regexp-quote string))
		     bound noerror count))

This is truly whitespace ignoring function that is very useful
when yanking and searching lines containing a mix of spaces, tabs
and newlines.  This implementation ignores whitespace in the same way
as `word-search-regexp' ignores punctuation.

I don't want to complicate this feature, but this possibility
for future development could be taken into account when thinking
about suitable names for new functions and variables.

> Also, I guess it won't be difficult to make M-s SPC work for regexp
> search too, by making it change search-spaces-regexp.  This can be left
> for later.

When users bind `isearch-forward-regexp' to C-s and use regexp search
as simple search, they will miss this feature.  So when leaving it,
a separate variable is needed to disable whitespace mode in regexp mode,
but to enable it in non-regexp simple mode by default.  This requires
a new variable `isearch-regexp-ignore-whitespace' but it complicates the
functionality, so maybe it should be removed from the next version of the patch?

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2012-08-27 04:08:32 +0000
+++ lisp/isearch.el	2012-08-31 09:30:33 +0000
@@ -120,20 +120,10 @@ (defcustom search-whitespace-regexp (pur
 incremental search.  If the value is nil, each space you type
 matches literally, against one space.
 
-The value can also be a cons cell (REGEXP-1 . REGEXP-2).  In that
-case, REGEXP-1 is used as the value for ordinary incremental
-search, and REGEXP-2 is used for regexp incremental search.
-
 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 '(choice (const :tag "Treat Spaces Literally" nil)
-		 (cons (choice :tag "For Ordinary Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil))
-		       (choice :tag "For Regexp Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil)))
 		 regexp)
   :group 'isearch
   :version "24.3")
@@ -510,6 +512,7 @@ (defvar isearch-mode-map
     (define-key map "\M-r" 'isearch-toggle-regexp)
     (define-key map "\M-e" 'isearch-edit-string)
 
+    (define-key map "\M-s " 'isearch-toggle-whitespace)
     (define-key map "\M-sc" 'isearch-toggle-case-fold)
     (define-key map "\M-sr" 'isearch-toggle-regexp)
     (define-key map "\M-sw" 'isearch-toggle-word)
@@ -556,6 +564,17 @@ (defvar isearch-word nil
 The property `isearch-message-prefix' put on this function specifies the
 prefix string displayed in the search message.")
 
+(defvar isearch-ignore-whitespace t
+  "If non-nil, a space will match a sequence of whitespace chars.
+When you enter a space or spaces in the incremental search, it
+will match any sequence matched by the regexp in the variable
+`search-whitespace-regexp'.
+If the value is nil, each space you type matches literally,
+against one space.")
+
+(defvar isearch-regexp-ignore-whitespace nil
+  "Like `isearch-ignore-whitespace' but for regexp mode.")
+
 (defvar isearch-cmds nil
   "Stack of search status sets.
 Each set is a vector of the form:
@@ -1409,6 +1434,24 @@ (defun isearch-toggle-case-fold ()
   (sit-for 1)
   (isearch-update))
 
+(defun isearch-toggle-whitespace ()
+  "Toggle whitespace matching in searching on or off."
+  (interactive)
+  (if isearch-regexp
+      (setq isearch-regexp-ignore-whitespace (not isearch-regexp-ignore-whitespace))
+    (setq isearch-ignore-whitespace (not isearch-ignore-whitespace)))
+  (let ((message-log-max nil))
+    (message "%s%s [%s]"
+	     (isearch-message-prefix nil isearch-nonincremental)
+	     isearch-message
+	     (if (if isearch-regexp
+		     isearch-regexp-ignore-whitespace
+		   isearch-ignore-whitespace)
+		 "ignore whitespace"
+	       "treat spaces literally")))
+  (setq isearch-success t isearch-adjusted t)
+  (sit-for 1)
+  (isearch-update))
 \f
 ;; Word search
 
@@ -1507,6 +1561,25 @@ (defun isearch-symbol-regexp (string &op
 (put 'isearch-symbol-regexp 'isearch-message-prefix "symbol ")
 
 \f
+;; Search ignoring whitespace
+
+(defun search-forward-ignore-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-forward (regexp-quote string) bound noerror count)))
+
+(defun search-backward-ignore-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-backward (regexp-quote string) bound noerror count)))
+
+(defun re-search-forward-ignore-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-forward string bound noerror count)))
+
+(defun re-search-backward-ignore-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-backward string bound noerror count)))
+
+\f
 (defun isearch-query-replace (&optional delimited regexp-flag)
   "Start `query-replace' with string to replace from last search string.
 The arg DELIMITED (prefix arg if interactive), if non-nil, means replace
@@ -1522,6 +1595,14 @@ (defun isearch-query-replace (&optional
 	;; set `search-upper-case' to nil to not call
 	;; `isearch-no-upper-case-p' in `perform-replace'
 	(search-upper-case nil)
+	(replace-search-function
+	 (if (and isearch-ignore-whitespace (not regexp-flag))
+	     #'search-forward-ignore-whitespace
+	   replace-search-function))
+	(replace-re-search-function
+	 (if (and isearch-regexp-ignore-whitespace regexp-flag)
+	     #'re-search-forward-ignore-whitespace
+	   replace-re-search-function))
 	;; Set `isearch-recursive-edit' to nil to prevent calling
 	;; `exit-recursive-edit' in `isearch-done' that terminates
 	;; the execution of this command when it is non-nil.
@@ -1558,15 +1639,6 @@ (defun isearch-query-replace-regexp (&op
    (list current-prefix-arg))
   (isearch-query-replace delimited t))
 
-(defun isearch-whitespace-regexp ()
-  "Return the value of `search-whitespace-regexp' for the current search."
-  (cond ((not (consp search-whitespace-regexp))
-	 search-whitespace-regexp)
-	(isearch-regexp
-	 (cdr search-whitespace-regexp))
-	(t
-	 (car search-whitespace-regexp))))
-
 (defun isearch-occur (regexp &optional nlines)
   "Run `occur' using the last search string as the regexp.
 Interactively, REGEXP is constructed using the search string from the
@@ -1606,7 +1678,11 @@ (defun isearch-occur (regexp &optional n
 	;; Set `search-upper-case' to nil to not call
 	;; `isearch-no-upper-case-p' in `occur-1'.
 	(search-upper-case nil)
-	(search-spaces-regexp (isearch-whitespace-regexp)))
+	(search-spaces-regexp
+	 (if (if isearch-regexp
+		 isearch-regexp-ignore-whitespace
+	       isearch-ignore-whitespace)
+	     search-whitespace-regexp)))
     (occur regexp nlines)))
 
 (declare-function hi-lock-read-face-name "hi-lock" ())
@@ -2203,7 +2286,7 @@ (defun isearch-quote-char ()
     ;; Assume character codes 0200 - 0377 stand for characters in some
     ;; single-byte character set, and convert them to Emacs
     ;; characters.
-    (if (and isearch-regexp (= char ?\s))
+    (if (and isearch-regexp isearch-regexp-ignore-whitespace (= char ?\s))
 	(if (subregexp-context-p isearch-string (length isearch-string))
 	    (isearch-process-search-string "[ ]" " ")
 	  (isearch-process-search-char char))
@@ -2443,16 +2534,19 @@ (defun isearch-search-fun-default ()
 	     (funcall isearch-word string lax)
 	   (word-search-regexp string lax))
 	 bound noerror count))))
+   ((and isearch-regexp isearch-regexp-ignore-whitespace
+	 search-whitespace-regexp)
+    (if isearch-forward
+	're-search-forward-ignore-whitespace
+      're-search-backward-ignore-whitespace))
    (isearch-regexp
     (if isearch-forward 're-search-forward 're-search-backward))
+   ((and isearch-ignore-whitespace search-whitespace-regexp)
+    (if isearch-forward
+	'search-forward-ignore-whitespace
+      'search-backward-ignore-whitespace))
    (t
-    (if isearch-forward 'isearch-search-forward 'isearch-search-backward))))
-
-(defun isearch-search-forward (string &optional bound noerror count)
-  (re-search-forward (regexp-quote string) bound noerror count))
-
-(defun isearch-search-backward (string &optional bound noerror count)
-  (re-search-backward (regexp-quote string) bound noerror count))
+    (if isearch-forward 'search-forward 'search-backward))))
 
 (defun isearch-search-string (string bound noerror)
   "Search for the first occurrence of STRING or its translation.
@@ -2503,17 +2597,13 @@ (defun isearch-search ()
 		  search-invisible))
 	    (inhibit-quit nil)
 	    (case-fold-search isearch-case-fold-search)
-	    (search-spaces-regexp (isearch-whitespace-regexp))
 	    (retry t))
 	(setq isearch-error nil)
 	(while retry
@@ -2805,7 +2942,8 @@ (defvar isearch-lazy-highlight-window-st
 (defvar isearch-lazy-highlight-window-end nil)
 (defvar isearch-lazy-highlight-case-fold-search nil)
 (defvar isearch-lazy-highlight-regexp nil)
-(defvar isearch-lazy-highlight-space-regexp nil)
+(defvar isearch-lazy-highlight-whitespace nil)
+(defvar isearch-lazy-highlight-whitespace-regexp nil)
 (defvar isearch-lazy-highlight-word nil)
 (defvar isearch-lazy-highlight-forward nil)
 (defvar isearch-lazy-highlight-error nil)
@@ -2847,6 +2985,10 @@ (defun isearch-lazy-highlight-new-loop (
 			  isearch-regexp))
 		 (not (eq isearch-lazy-highlight-word
 			  isearch-word))
+		 (not (eq isearch-lazy-highlight-whitespace
+			  isearch-ignore-whitespace))
+		 (not (eq isearch-lazy-highlight-whitespace-regexp
+			  search-whitespace-regexp))
                  (not (= (window-start)
                          isearch-lazy-highlight-window-start))
                  (not (= (window-end)   ; Window may have been split/joined.
@@ -2873,7 +3015,8 @@ (defun isearch-lazy-highlight-new-loop (
 	  isearch-lazy-highlight-last-string  isearch-string
 	  isearch-lazy-highlight-case-fold-search isearch-case-fold-search
 	  isearch-lazy-highlight-regexp       isearch-regexp
-	  isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp)
+	  isearch-lazy-highlight-whitespace   isearch-ignore-whitespace
+	  isearch-lazy-highlight-whitespace-regexp search-whitespace-regexp
 	  isearch-lazy-highlight-word         isearch-word
 	  isearch-lazy-highlight-forward      isearch-forward)
       (unless (equal isearch-string "")
@@ -2887,7 +3030,8 @@ (defun isearch-lazy-highlight-search ()
   (condition-case nil
       (let ((case-fold-search isearch-lazy-highlight-case-fold-search)
 	    (isearch-regexp isearch-lazy-highlight-regexp)
-	    (search-spaces-regexp isearch-lazy-highlight-space-regexp)
+	    (search-spaces-regexp (if isearch-lazy-highlight-whitespace
+				      isearch-lazy-highlight-whitespace-regexp))
 	    (isearch-word isearch-lazy-highlight-word)
 	    (search-invisible nil)	; don't match invisible text
 	    (retry t)

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Or do you think `-ignore-whitespace' implies a more general
> functionality?

> it would be also useful to completely ignore all whitespace
> differences between the search string and the buffer text with the
> following implementation:

No, ignoring whitespace differences entirely is not desireable.  If the
user searches for the word "tome" and isearch hits on "to me", that
would be annoying.

That's why I suggested the suffix -lax-space-match.  Or, if that is too
wordy, maybe -lax will do (there's already word-search-*-lax but I think
that's OK since this feature doesn't overlap with word search).  Or
maybe -lazy-spaces.  Or feel free to suggest something better.

The message for isearch-toggle-whitespace should not speak of "ignoring
whitespace", for the same reason.

> The prefix `isearch-' is not quite right because these functions
> can be used in other packages like replace.el being bound to
> `replace-search-function'.  `search-' seems more right.

Using the search- prefix for the functions is OK.  Apart from the above
terminology issues, the rest of the patch also looks OK.

> When users bind `isearch-forward-regexp' to C-s and use regexp search
> as simple search, they will miss this feature.  So when leaving it, a
> separate variable is needed to disable whitespace mode in regexp mode,
> but to enable it in non-regexp simple mode by default.  This requires
> a new variable `isearch-regexp-ignore-whitespace' but it complicates
> the functionality, so maybe it should be removed from the next version
> of the patch?

I think the simplest, most backward compatible solution is simply to
allow search-whitespace-regexp to take a cons cell value :-P

Sure, a cons cell is not extensible, but is there any forseeable way in
which we'd want to extend this beyond simply distinguishing ordinary and
regexp isearch?  The feature does not overlap with word search, so that
seems pretty irrelevant.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> No, ignoring whitespace differences entirely is not desireable.
> If the user searches for the word "tome" and isearch hits on "to me",
> that would be annoying.

It doesn't ignore empty whitespace differences because
`search-whitespace-regexp' matches non-empty strings
as a 1+ sequence of whitespace with "\\s-+".  Of course,
changing it to "\\s-*" would be annoying.

But what I meant is that the current C implementation
of `search-spaces-regexp' can be converted to Lisp as:

(defun search-forward-ignore-whitespace (string &optional bound noerror count)
  (re-search-forward (search-whitespace-regexp (regexp-quote string))
		     bound noerror count))

(defun search-whitespace-regexp (string)
  (replace-regexp-in-string
   " +"
   search-whitespace-regexp
   string nil t))

whereas it would be also very useful to have

(defun search-whitespace-regexp (string)
  (replace-regexp-in-string
   "\\s-+"
   search-whitespace-regexp
   string nil t))

that matches a non-empty sequence of whitespace, not just spaces.

So what I think is that this matching regexp could be configurable
with the default value " +".

> That's why I suggested the suffix -lax-space-match.  Or, if that is too
> wordy, maybe -lax will do (there's already word-search-*-lax but I think
> that's OK since this feature doesn't overlap with word search).  Or
> maybe -lazy-spaces.  Or feel free to suggest something better.

The reason why I think that related function and variable names
should contain the word `whitespace' is because it will connect it
with the already existing `search-whitespace-regexp'.

OTOH, the suffix `-lax' is short and has no limited meaning,
so maybe it would be good to have names like:

(defcustom search-whitespace-regexp
(defvar isearch-whitespace-lax
(defun isearch-toggle-whitespace-lax
(defun search-forward-whitespace-lax
(defun search-backward-whitespace-lax

> The message for isearch-toggle-whitespace should not speak of "ignoring
> whitespace", for the same reason.

One message for `isearch-toggle-whitespace' was taken from the defcustom
definition of `search-whitespace-regexp' to display the same meaning as
"treat spaces literally".  Another message to enable this feature
could display something more meaningful too like
"space matches a sequence of whitespace chars".

> I think the simplest, most backward compatible solution is simply to
> allow search-whitespace-regexp to take a cons cell value :-P

I meant that supporting lax whitespace in regexp mode makes functionality
more complicated because of adding special conditions in
`isearch-toggle-whitespace', `isearch-query-replace',
`isearch-occur', `isearch-search-fun-default'.

But configuring it with a cons cell makes it more complicated.

So the question was rather do we need to support lax whitespace
in regexp mode at all?

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> It doesn't ignore empty whitespace differences because
> `search-whitespace-regexp' matches non-empty strings as a 1+ sequence
> of whitespace with "\\s-+".  Of course, changing it to "\\s-*" would
> be annoying.

Right, but the phrase "ignore whitespace" seems to indicate completely
ignoring whitespace differences *in the search string*, including empty
whitespace differences.  So it is a poor name.

> The reason why I think that related function and variable names
> should contain the word `whitespace' is because it will connect it
> with the already existing `search-whitespace-regexp'.

I see your point.  The naming system for `search-spaces-regexp' and
`search-whitespace-regexp' is badly muddled, but I guess we have to live
with it.

How about -lazy-whitespace or -lax-whitespace?  Then the command would
be isearch-toggle-lazy-whitespace or isearch-toggle-lax-whitespace.

> One message for `isearch-toggle-whitespace' was taken from the defcustom
> definition of `search-whitespace-regexp' to display the same meaning as
> "treat spaces literally".

Instead of "treat spaces literally", I think "match spaces literally"
would be more accurate.  The opposite message could be "match spaces
loosely", which is about the best we can do in a short message, I think.

> So the question was rather do we need to support lax whitespace in
> regexp mode at all?

I don't think we should remove the feature outright, so there ought to
be some way to enable it for regexp mode.  Adding some complication to
the code for this purpose is fine.

That is to say, even if we change things so that C-M-s does not do lax
space matching by default, it should be easy to get the feature back (by
customizing a variable), just in case some user somewhere depends on the
feature.

Re: Interpretation of a space in regexp isearch?

[Juri Linkov]

> Right, but the phrase "ignore whitespace" seems to indicate completely
> ignoring whitespace differences *in the search string*, including empty
> whitespace differences.  So it is a poor name.

In Diff this option is called --ignore-space-change
that ignores changes in the amount of white space,
but this name is too long.

> How about -lazy-whitespace or -lax-whitespace?  Then the command would
> be isearch-toggle-lazy-whitespace or isearch-toggle-lax-whitespace.

Then the names of search functions would be:

lax-whitespace-search-forward    - for simple search, and
re-lax-whitespace-search-forward - for regexp search.

And "re-lax" is not a synonym for "lazy" :-)  In programming
"lazy" means delayed evaluation, so it's not applicable here
(but isearch-lazy-highlight fits this definition because
it delays the evaluation of highlighting for other matches).

Using the same naming convention as in word-search-forward-lax
like whitespace-search-forward-lax or whitespace-lax-search-forward
is also not possible because as you said the whitespace- prefix
is reserved for whitespace.el.

Thus the remaining possibility is to add -lax-whitespace
as the suffix like:

search-forward-lax-whitespace
re-search-forward-lax-whitespace

that is implemented in the patch below.

If it's basically OK then I'd like to install it,
so you could make more necessary changes.

>> So the question was rather do we need to support lax whitespace in
>> regexp mode at all?
>
> I don't think we should remove the feature outright, so there ought to
> be some way to enable it for regexp mode.  Adding some complication to
> the code for this purpose is fine.
>
> That is to say, even if we change things so that C-M-s does not do lax
> space matching by default, it should be easy to get the feature back (by
> customizing a variable), just in case some user somewhere depends on the
> feature.

With a separate variable for regexp lax matching like
`isearch-regexp-lax-whitespace' it will be easy to enable/disable it
and also easier to mark it obsolete later before removing the feature.

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2012-08-27 04:08:32 +0000
+++ lisp/isearch.el	2012-09-01 11:47:01 +0000
@@ -120,20 +120,10 @@ (defcustom search-whitespace-regexp (pur
 incremental search.  If the value is nil, each space you type
 matches literally, against one space.
 
-The value can also be a cons cell (REGEXP-1 . REGEXP-2).  In that
-case, REGEXP-1 is used as the value for ordinary incremental
-search, and REGEXP-2 is used for regexp incremental search.
-
 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 '(choice (const :tag "Treat Spaces Literally" nil)
-		 (cons (choice :tag "For Ordinary Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil))
-		       (choice :tag "For Regexp Isearch"
-			       regexp
-			       (const :tag "Treat Spaces Literally" nil)))
 		 regexp)
   :group 'isearch
   :version "24.3")
@@ -510,6 +512,7 @@ (defvar isearch-mode-map
     (define-key map "\M-r" 'isearch-toggle-regexp)
     (define-key map "\M-e" 'isearch-edit-string)
 
+    (define-key map "\M-s " 'isearch-toggle-lax-whitespace)
     (define-key map "\M-sc" 'isearch-toggle-case-fold)
     (define-key map "\M-sr" 'isearch-toggle-regexp)
     (define-key map "\M-sw" 'isearch-toggle-word)
@@ -556,6 +564,17 @@ (defvar isearch-word nil
 The property `isearch-message-prefix' put on this function specifies the
 prefix string displayed in the search message.")
 
+(defvar isearch-lax-whitespace t
+  "If non-nil, a space will match a sequence of whitespace chars.
+When you enter a space or spaces in the incremental search, it
+will match any sequence matched by the regexp in the variable
+`search-whitespace-regexp'.
+If the value is nil, each space you type matches literally,
+against one space.")
+
+(defvar isearch-regexp-lax-whitespace nil
+  "Like `isearch-lax-whitespace' but for regexp mode.")
+
 (defvar isearch-cmds nil
   "Stack of search status sets.
 Each set is a vector of the form:
@@ -1409,6 +1434,24 @@ (defun isearch-toggle-case-fold ()
   (sit-for 1)
   (isearch-update))
 
+(defun isearch-toggle-lax-whitespace ()
+  "Toggle whitespace matching in searching on or off."
+  (interactive)
+  (if isearch-regexp
+      (setq isearch-regexp-lax-whitespace (not isearch-regexp-lax-whitespace))
+    (setq isearch-lax-whitespace (not isearch-lax-whitespace)))
+  (let ((message-log-max nil))
+    (message "%s%s [%s]"
+	     (isearch-message-prefix nil isearch-nonincremental)
+	     isearch-message
+	     (if (if isearch-regexp
+		     isearch-regexp-lax-whitespace
+		   isearch-lax-whitespace)
+		 "match spaces loosely"
+	       "match spaces literally")))
+  (setq isearch-success t isearch-adjusted t)
+  (sit-for 1)
+  (isearch-update))
 \f
 ;; Word search
 
@@ -1506,6 +1560,24 @@ (defun isearch-symbol-regexp (string &op
 
 (put 'isearch-symbol-regexp 'isearch-message-prefix "symbol ")
 
+;; Search with lax whitespace
+
+(defun search-forward-lax-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-forward (regexp-quote string) bound noerror count)))
+
+(defun search-backward-lax-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-backward (regexp-quote string) bound noerror count)))
+
+(defun re-search-forward-lax-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-forward string bound noerror count)))
+
+(defun re-search-backward-lax-whitespace (string &optional bound noerror count)
+  (let ((search-spaces-regexp search-whitespace-regexp))
+    (re-search-backward string bound noerror count)))
+
 \f
 (defun isearch-query-replace (&optional delimited regexp-flag)
   "Start `query-replace' with string to replace from last search string.
@@ -1522,6 +1594,14 @@ (defun isearch-query-replace (&optional
 	;; set `search-upper-case' to nil to not call
 	;; `isearch-no-upper-case-p' in `perform-replace'
 	(search-upper-case nil)
+	(replace-search-function
+	 (if (and isearch-lax-whitespace (not regexp-flag))
+	     #'search-forward-lax-whitespace
+	   replace-search-function))
+	(replace-re-search-function
+	 (if (and isearch-regexp-lax-whitespace regexp-flag)
+	     #'re-search-forward-lax-whitespace
+	   replace-re-search-function))
 	;; Set `isearch-recursive-edit' to nil to prevent calling
 	;; `exit-recursive-edit' in `isearch-done' that terminates
 	;; the execution of this command when it is non-nil.
@@ -1558,15 +1638,6 @@ (defun isearch-query-replace-regexp (&op
    (list current-prefix-arg))
   (isearch-query-replace delimited t))
 
-(defun isearch-whitespace-regexp ()
-  "Return the value of `search-whitespace-regexp' for the current search."
-  (cond ((not (consp search-whitespace-regexp))
-	 search-whitespace-regexp)
-	(isearch-regexp
-	 (cdr search-whitespace-regexp))
-	(t
-	 (car search-whitespace-regexp))))
-
 (defun isearch-occur (regexp &optional nlines)
   "Run `occur' using the last search string as the regexp.
 Interactively, REGEXP is constructed using the search string from the
@@ -1606,7 +1677,11 @@ (defun isearch-occur (regexp &optional n
 	;; Set `search-upper-case' to nil to not call
 	;; `isearch-no-upper-case-p' in `occur-1'.
 	(search-upper-case nil)
-	(search-spaces-regexp (isearch-whitespace-regexp)))
+	(search-spaces-regexp
+	 (if (if isearch-regexp
+		 isearch-regexp-lax-whitespace
+	       isearch-lax-whitespace)
+	     search-whitespace-regexp)))
     (occur regexp nlines)))
 
 (declare-function hi-lock-read-face-name "hi-lock" ())
@@ -2203,7 +2285,7 @@ (defun isearch-quote-char ()
     ;; Assume character codes 0200 - 0377 stand for characters in some
     ;; single-byte character set, and convert them to Emacs
     ;; characters.
-    (if (and isearch-regexp (= char ?\s))
+    (if (and isearch-regexp isearch-regexp-lax-whitespace (= char ?\s))
 	(if (subregexp-context-p isearch-string (length isearch-string))
 	    (isearch-process-search-string "[ ]" " ")
 	  (isearch-process-search-char char))
@@ -2443,16 +2533,19 @@ (defun isearch-search-fun-default ()
 	     (funcall isearch-word string lax)
 	   (word-search-regexp string lax))
 	 bound noerror count))))
+   ((and isearch-regexp isearch-regexp-lax-whitespace
+	 search-whitespace-regexp)
+    (if isearch-forward
+	're-search-forward-lax-whitespace
+      're-search-backward-lax-whitespace))
    (isearch-regexp
     (if isearch-forward 're-search-forward 're-search-backward))
+   ((and isearch-lax-whitespace search-whitespace-regexp)
+    (if isearch-forward
+	'search-forward-lax-whitespace
+      'search-backward-lax-whitespace))
    (t
-    (if isearch-forward 'isearch-search-forward 'isearch-search-backward))))
-
-(defun isearch-search-forward (string &optional bound noerror count)
-  (re-search-forward (regexp-quote string) bound noerror count))
-
-(defun isearch-search-backward (string &optional bound noerror count)
-  (re-search-backward (regexp-quote string) bound noerror count))
+    (if isearch-forward 'search-forward 'search-backward))))
 
 (defun isearch-search-string (string bound noerror)
   "Search for the first occurrence of STRING or its translation.
@@ -2503,17 +2596,13 @@ (defun isearch-search ()
 		  search-invisible))
 	    (inhibit-quit nil)
 	    (case-fold-search isearch-case-fold-search)
-	    (search-spaces-regexp (isearch-whitespace-regexp))
 	    (retry t))
 	(setq isearch-error nil)
 	(while retry
@@ -2805,7 +2941,8 @@ (defvar isearch-lazy-highlight-window-st
 (defvar isearch-lazy-highlight-window-end nil)
 (defvar isearch-lazy-highlight-case-fold-search nil)
 (defvar isearch-lazy-highlight-regexp nil)
-(defvar isearch-lazy-highlight-space-regexp nil)
+(defvar isearch-lazy-highlight-lax-whitespace nil)
+(defvar isearch-lazy-highlight-regexp-lax-whitespace nil)
 (defvar isearch-lazy-highlight-word nil)
 (defvar isearch-lazy-highlight-forward nil)
 (defvar isearch-lazy-highlight-error nil)
@@ -2847,6 +2984,10 @@ (defun isearch-lazy-highlight-new-loop (
 			  isearch-regexp))
 		 (not (eq isearch-lazy-highlight-word
 			  isearch-word))
+		 (not (eq isearch-lazy-highlight-lax-whitespace
+			  isearch-lax-whitespace))
+		 (not (eq isearch-lazy-highlight-regexp-lax-whitespace
+			  isearch-regexp-lax-whitespace))
                  (not (= (window-start)
                          isearch-lazy-highlight-window-start))
                  (not (= (window-end)   ; Window may have been split/joined.
@@ -2873,7 +3014,8 @@ (defun isearch-lazy-highlight-new-loop (
 	  isearch-lazy-highlight-last-string  isearch-string
 	  isearch-lazy-highlight-case-fold-search isearch-case-fold-search
 	  isearch-lazy-highlight-regexp       isearch-regexp
-	  isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp)
+	  isearch-lazy-highlight-lax-whitespace   isearch-lax-whitespace
+	  isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace
 	  isearch-lazy-highlight-word         isearch-word
 	  isearch-lazy-highlight-forward      isearch-forward)
       (unless (equal isearch-string "")
@@ -2887,7 +3029,6 @@ (defun isearch-lazy-highlight-search ()
   (condition-case nil
       (let ((case-fold-search isearch-lazy-highlight-case-fold-search)
 	    (isearch-regexp isearch-lazy-highlight-regexp)
-	    (search-spaces-regexp isearch-lazy-highlight-space-regexp)
 	    (isearch-word isearch-lazy-highlight-word)
 	    (search-invisible nil)	; don't match invisible text
 	    (retry t)

Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> search-forward-lax-whitespace
> re-search-forward-lax-whitespace
>
> that is implemented in the patch below.
>
> If it's basically OK then I'd like to install it,
> so you could make more necessary changes.

This patch looks fine, please go ahead.  Thanks for writing it.

> With a separate variable for regexp lax matching like
> `isearch-regexp-lax-whitespace' it will be easy to enable/disable it
> and also easier to mark it obsolete later before removing the feature.

I'm fine with that.