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?