bug#10885: Replace expressions: enhance functionality when searching in filled paragraphs

[Dani Moncayo]

On Thu, Sep 6, 2012 at 6:50 PM, Juri Linkov <juri@jurta.org> wrote:
>> 1.  You've defined two separate variables (`isearch-lax-whitespace'
>> and `isearch-regexp-lax-whitespace') to enable/disable the lax
>> whitespace matching in search commands: one for basic search commands
>> and the other for regexp search commands.  But there is only one
>> similar variable (replace-lax-whitespace) which controls both basic
>> and regexp replace commands.  Why this inconsistency?  I.e. why not
>> define also a `replace-regexp-lax-whitespace' variable?
>
> `isearch-regexp-lax-whitespace' was necessary to provide
> backward-compatibility for old functionality.  Very likely
> it will be declared obsolete.

Ah Good.  I think we all agree that this feature is
confusing/unnecessary in regexp search & replace.

>  But of course, it would be better
> to have `replace-regexp-lax-whitespace' for consistency until
> they both will be declared obsolete simultaneously.
>
>> 2.  While in an incremental search commands, it is possible to toggle
>> the value of the corresponding variable with `M-s SPC'.  Why not
>> having the same possibility in incremental replace commands?
>
> Isearch has different implementation than query-replace.
> query-replace uses the normal minibuffer to read a string to replace.
> Implementing `M-s SPC' for it means more trouble:
> `query-replace-read-from' should set the arg `keymap' of
> `read-from-minibuffer' to a new keymap with the `M-s SPC' keybinding
> bound to a function to toggle the value of the defcustom option.

But I meant to bind `M-s SPC' not while reading the arguments, but
right after that, i.e. during the interactive replacing.

>> 3.  Many users will want a consistent behavior wrt whitespace-matching
>> between (regexp) search and (regexp) replace commands.  So, why not
>> allowing to "connect" the corresponding variables?  I.e. why not
>> defining some special value for `replace-lax-whitespace' and
>> `replace-regexp-lax-whitespace' which means "get the value from the
>> corresponding search variable" ?
>
> When it will be decided that isearch and query-replace should have
> the same default values, then `replace-lax-whitespace' could inherit
> its default value from `isearch-lax-whitespace'.

But I don't meant that.  What I want is the possibility to have these
two variables "synchronized" or "connected" at every moment, even
after toggling its value with `M-s SPC'.  IOW: make Isearch and
query-replace _share_ the same setting (at every moment).

-- 
Dani Moncayo