Re: Whitespace search and regex.c

[Stefan Monnier <monnier@iro.umontreal.ca>]

>     What is this recent change to regex.c w.r.t whitespace search all about?
>     This is really ugly.

>     As best as I can tell, this is to avoid the problem where
>     (replace-regexp-in-string " " "\\(?:\s-+\\)" ...) does not give the right
>     result because the " " could be inside brackets.

> It has nothing to do with replace-regexp-in-string, which doesn't use
> this feature.
I didn't mean to say that it was used by replace-regexp-in-string but that
it was used for those cases where you want a regex generated by
systematically replacing " " with something else (such as "\\(?:\s-+\\)").

In those cases, the obvious way to do it (with replace-regexp-in-string or
some piece of code that ends up doing something similar) suffers from the
fact that it will replace " " even if it appears inside brackets delimiting
a char-range.

> It is for the sake of user-level search features that
> want a series of SPCs to stand for some broader kind of whitespace.

I'm afraid that doesn't tell me really what it is for.  I.e. why is it
implemented this way rather than some other way?  What was the precise goal?

E.g. if you told me to implement a "user-level search features that
want a series of SPCs to stand for some broader kind of whitespace" it'd
never occur to me to fiddle with regex.[ch].  Instead, I'd add a piece of
elisp code which replaces every SPC (or sequence of SPC) in a regex with
some other regex.  E.g. I'd use something like (replace-regexp-in-string " "
"\\(?:\s-+\\)" ...).  Now maybe in order to correctly do the replacement in
the presence of brackets, I'd probably add a function like
(parse-partial-regex REGEXP POS), potentially (tho probably not at first)
implemented in regex.[ch].

>     After all this problem manifests itself at a few other places (such as
>     regexp-opt-depth) as well.
> I don't follow how this relates to regexp-opt-depth.
> Would you please spell that out?

Regexp-opt-depth has to count the number of occurences of "\\(" in a regexp,
but it should be careful not to count those occurences that appear within
brackets.

>     E.g. a function (parse-partial-regex REGEXP POS)
>     which would return a value indicating whether POS is within brackets or not.

> That would be helpful for making C-q SPC in I-search DTRT both
> inside and outside brackets.

Yes, and it would also help the previous code (before your changes) make SPC
DTRT both inside and outside brackets.  I thought your change was trying to
solve exactly this problem, and that it ends up just pushing it from SPC to
C-q SPC.


        Stefan