[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14013: 24.3.50; dired-isearch-filenames-regexp is matching text outs
From: |
Michael Heerdegen |
Subject: |
bug#14013: 24.3.50; dired-isearch-filenames-regexp is matching text outside filenames |
Date: |
Sat, 03 Jun 2023 00:29:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.