wdired replace-regexp (continue bug 14013?)

wdired replace-regexp (continue bug 14013?)

[Madhu]

* commit  935cc42795686710f82b8928b6802f20be8f27c0
|Author:     Juri Linkov <juri@linkov.net>
|AuthorDate: Mon Mar 28 21:00:32 2022 +0300
|Commit:     Juri Linkov <juri@linkov.net>
|CommitDate: Mon Mar 28 21:00:32 2022 +0300
|    Add search function to search within filenames in Dired and WDired
| (bug#14013)

introduces a variable `wdired-search-replace-filenames' which defaults
to t. When this variable is tured on regexp-replace in wdired buffers is
limited to the visible portion of the buffer.

```
mkdir /dev/shm/test-foo -pv
for i in $(seq 1 40); do ln -sv /foo/$i /dev/shm/test-foo; done
(dired "/dev/shm/test-foo")
(wdired-change-to-wdired-mode)
(replace-regexp "foo" "bar")
```

Only the first screenful of files are operated on.

setting the variable to nil seems to works on the whole buffer. but can
someone explain how this behaviour comes effect?

The relevant code is

```wdired.el: (wdired-change-to-wdired-mode)
  (when wdired-search-replace-filenames
    (add-function :around (local 'isearch-search-fun-function)
                  #'dired-isearch-search-filenames
                  '((isearch-message-prefix . "filename ")))
    (setq-local replace-search-function
                (setq-local replace-re-search-function
                            (funcall isearch-search-fun-function)))
```
and

```wdired.el:(wdired-change-to-dired-mode)
  (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)
    ;; Restore dired hook
    (add-hook 'isearch-mode-hook #'dired-isearch-filenames-setup nil t))
```

Using add-function and remove-function (local) instead of hooks
complicates the debugging, in this case makes it opaque to me.  At what
point does this "implicit narrowing" which results in this behaviour
come into effect?

I set (setq search-highlight nil search-highlight-submatches nil
query-replace-highlight nil query-replace-highlight-submatches nil),
Should I follow up on the the archived bug
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14013
?

Re: wdired replace-regexp (continue bug 14013?)

[Michael Heerdegen via Emacs development discussions.]

Madhu <enometh@meer.net> writes:

> introduces a variable `wdired-search-replace-filenames' which defaults
> to t. When this variable is tured on regexp-replace in wdired buffers is
> limited to the visible portion of the buffer.

Oh no, this is not good news.  But good that you found it.

This likely happens just because the buffer is fontified lazily and text
properties in not yet displayed parts of the buffer are not yet
attached.

> Should I follow up on the the archived bug
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14013
> ?

Please create a new report - this is a new issue.  Many thanks in
advance!


Michael.

Re: wdired replace-regexp (continue bug 14013?)

[Michael Heerdegen via Emacs development discussions.]

Michael Heerdegen via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> This likely happens just because the buffer is fontified lazily and text
> properties in not yet displayed parts of the buffer are not yet
> attached.

In that case evaluating (font-lock-ensure) in the search buffer should
fix the issue.  It may be necessary to do that before switching to
wdired.  Could you maybe test if that has an effect?


Thx,

Michael.

Re: wdired replace-regexp (continue bug 14013?)

[Madhu]

* Michael Heerdegen via "Emacs development discussions." <87ttew537j.fsf@web.de> :
Wrote on Tue, 03 Sep 2024 14:30:56 +0200:

> Michael Heerdegen via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>> This likely happens just because the buffer is fontified lazily and text
>> properties in not yet displayed parts of the buffer are not yet
>> attached.
>
> In that case evaluating (font-lock-ensure) in the search buffer should
> fix the issue.  It may be necessary to do that before switching to
> wdired.  Could you maybe test if that has an effect?

Yes this seems to fix the problem. I'll send a message to the bug list
shortly.  This part works.  But I'm seeing another another problem with
the test case I posted:

"replace-match-maybe-edit: Match data clobbered by buffer modification
hooks"

This goes away when I call (load-library "wdired") again I can't figure
out why this should happen, it happens even if I protect all the calls
to string-match in wdired.el with (save-match-data) and recompile
I'll try a new build first.

Re: wdired replace-regexp (continue bug 14013?)

[Michael Heerdegen via Emacs development discussions.]

Madhu <enometh@meer.net> writes:

> Yes this seems to fix the problem. I'll send a message to the bug list
> shortly.

TIA.

> But I'm seeing another another problem with the test case I posted:
>
> "replace-match-maybe-edit: Match data clobbered by buffer modification
> hooks"

This happens with emacs -Q?


Michael.