Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

Juri Linkov <address@hidden> 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.