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?