bug#14013: 24.3.50; dired-isearch-filenames-regexp is matching text outside filenames

[Juri Linkov <juri@jurta.org>]

>> >> -  (remove-function (local 'isearch-filter-predicate)
>> >> -                   #'wdired-isearch-filter-read-only)
>> >> +  (when wdired-search-replace-filenames
>> >> +    (remove-function (local 'isearch-search-fun-function)
>> >> +                     #'dired-isearch-search-filenames)
>> >> +    (kill-local-variable 'replace-search-function)
>> >> +    (kill-local-variable 'replace-re-search-function))
>> >
>> > Juri, when a user disables `wdired-search-replace-filenames' while still
>> > in wdired-mode, won't we fail to undo these settings when the user
>> > then returns to normal dired? - should we not better undo these things
>> > unconditionally?
>>
>> If these calls are idempotent, we could remove the condition.
>> Could you please confirm there is no adverse effect after removing this.
>
> Both `remove-function' and `k-l-variable' are documented to do nothing
> when the function to be removed is not present/ there is no local
> variable binding.
>
>> Also there is another call at the end that can't be removed:
>>
>>   (add-hook 'isearch-mode-hook #'dired-isearch-filenames-setup nil t)
>
> I think we should remove the condition when entering wdired here (for
> the same reason).

If you don't see a problem, then let's change this in master.

>> > Second question: could we advice (local 'replace-search-function) and
>> > (local 'replace-re-search-function) instead of replacing the value (it
>> > might be nicer to users of other packages)?
>>
>> This looks nicer in theory.  But in practice I expect to see a lot of
>> conflicts.
>
> What conflicts?

Usual conflicts when two pieces of code are working simultaneously
on the same thing.  So we need concrete examples to verify if
everything is correct.