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

[Michael Heerdegen]

Juri Linkov <juri@jurta.org> writes:

> >> -  (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).

> > 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?

Michael.