From: Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: Madhu <enometh@meer.net>, 73018@debbugs.gnu.org
Subject: bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer
Date: Mon, 09 Sep 2024 16:55:59 +0200 [thread overview]
Message-ID: <87bk0w511c.fsf@web.de> (raw)
In-Reply-To: <868qw2ruv3.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 08 Sep 2024 19:28:32 +0300")
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
Juri Linkov <juri@linkov.net> writes:
> M-: (buffer-substring (- (point-max) 2) (- (point-max) 1))
> => #("7" 0 1 (fontified nil invisible dired-hide-details-link))
>
> M-> ;; (end-of-buffer)
>
> M-: (buffer-substring (- (point-max) 2) (- (point-max) 1))
> => #("7" 0 1 (face default dired-symlink-filename t fontified t
> invisible dired-hide-details-link))
>
> And indeed, after going to the end of the Dired buffer
> the last file gets an additional property `dired-symlink-filename'
> used by Isearch/Replace.
So, the properties we use are of different types: some are already
attached by `dired-insert-set-properties', others later by font-lock
(see `dired-font-lock-keywords'). AFAIR this is because some tests are
more expensive than others (e.g. the test whether a link is broken) and
are intentionally delayed.
Would something like this be good?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-WIP-Bug-73018.patch --]
[-- Type: text/x-diff, Size: 1100 bytes --]
From c5ef8c8db7d8b2ab03998a0f3f2a1b820ff24e2a Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Mon, 9 Sep 2024 16:46:13 +0200
Subject: [PATCH] WIP: Bug#73018
---
lisp/dired-aux.el | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index d79ec342435..77dde7147bc 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -3740,8 +3740,12 @@ dired-isearch-search-filenames
The returned function narrows the search to match the search string
only as part of a file name enclosed by the text property `dired-filename'.
It's intended to override the default search function."
- (isearch-search-fun-in-text-property
- (funcall orig-fun) '(dired-filename dired-symlink-filename)))
+ (let ((search-fun
+ (isearch-search-fun-in-text-property
+ (funcall orig-fun) '(dired-filename dired-symlink-filename))))
+ (lambda (&rest args)
+ (font-lock-ensure)
+ (apply search-fun args))))
;;;###autoload
(defun dired-isearch-filenames ()
--
2.39.2
[-- Attachment #3: Type: text/plain, Size: 1153 bytes --]
A related question is whether everybody always wants to search in
symlink targets when isearching file names in dired... I don't. Would
it be worth to add an option for that? Currently the properties are
just hardcoded.
Then, in the above patch we could make the `font-lock-ensure' call
depend on the value of that option.
> Also noticed that doing the first replacement always raises an error:
>
> Debugger entered--Lisp error: (error "Match data clobbered by buffer
> modification hooks")
> replace-match("!" nil nil)
> replace-match-maybe-edit("!" nil nil nil (672 673 #<buffer char>) nil)
> perform-replace("7" "!" t t nil nil nil nil nil nil nil)
> query-replace-regexp("7" "!" nil nil nil nil nil)
> funcall-interactively(query-replace-regexp "7" "!" nil nil nil nil nil)
> command-execute(query-replace-regexp)
Do I interpret the code in replace_match correctly: this error doesn't
even mean the match data has been clobbered - only that modification
hooks called searching functions? I don't know what the referenced
search_regs.num_regs exactly contains. But we already seem to ensure
not to clobber match data.
Michael.
next prev parent reply other threads:[~2024-09-09 14:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 2:33 bug#73018: 31.0.50; wdired + replace-regexp only modifies the visible portion of the buffer Madhu
2024-09-04 3:25 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 8:58 ` Madhu
2024-09-04 9:08 ` Madhu
2024-09-04 16:13 ` Juri Linkov
2024-09-05 12:12 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 16:51 ` Madhu
2024-09-05 16:51 ` Juri Linkov
2024-09-06 12:04 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06 16:08 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 16:28 ` Juri Linkov
2024-09-09 14:55 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-09 17:13 ` Juri Linkov
2024-09-09 17:55 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09 17:14 ` Juri Linkov
2024-09-10 6:28 ` Juri Linkov
2024-09-10 13:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10 13:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-14 9:47 ` Eli Zaretskii
2024-09-15 13:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-15 15:02 ` Eli Zaretskii
2024-09-16 2:06 ` Madhu
2024-09-16 14:24 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-17 18:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-17 18:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-21 9:34 ` Eli Zaretskii
2024-09-23 3:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-23 11:51 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bk0w511c.fsf@web.de \
--to=bug-gnu-emacs@gnu.org \
--cc=73018@debbugs.gnu.org \
--cc=enometh@meer.net \
--cc=juri@linkov.net \
--cc=michael_heerdegen@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.