Re: Interpretation of a space in regexp isearch?

[Chong Yidong]

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