all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.

  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.