From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65854: Multi-file replacement diff Date: Mon, 11 Sep 2023 09:23:37 +0200 Message-ID: References: <86sf7mgd54.fsf@mail.linkov.net> <86bke943tp.fsf@mail.linkov.net> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11298"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65854@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 11 09:24:27 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qfbHX-00047l-LA for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Sep 2023 09:24:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qfbH6-0000BB-Ge; Mon, 11 Sep 2023 03:24:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qfbH4-0000Ay-QP for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2023 03:23:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qfbH4-0003Ej-IP for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2023 03:23:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qfbH7-00076C-U7 for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2023 03:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2023 07:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65854 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65854-submit@debbugs.gnu.org id=B65854.169441702927270 (code B ref 65854); Mon, 11 Sep 2023 07:24:01 +0000 Original-Received: (at 65854) by debbugs.gnu.org; 11 Sep 2023 07:23:49 +0000 Original-Received: from localhost ([127.0.0.1]:52003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfbGu-00075m-S9 for submit@debbugs.gnu.org; Mon, 11 Sep 2023 03:23:49 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:35022 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfbGr-00075c-Pq for 65854@debbugs.gnu.org; Mon, 11 Sep 2023 03:23:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1694417021; bh=Sqd6+Ss9GwogkUkq4PI3gHzAgTRIpKxKvhF1qQOcD4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YW0OgPeCUkTLKzsIp0um3xPL6JSbIdLu6gBLM5O5GiKPLQf8KrCt/WC97DXOk2Xia 6xPUN2f9G+5PL6NZ+0LIENthkHAw50V+6K3EyqM8X/0d/gZjcUX6tDy6BZHz5wANAy OIpKm9nCCVtxdQU6KyTpGZ5V9bn7brAXy9ZrrvNYaQ1+rEj5TfD337pf5Dqr1HbjJ7 KsuCesM3XgxMjzxH5kPInIlhKsxF2n61Dw7mWPnNZ5OJOZcj2AVlVtkut4Uiha+B6V Dni60mtF8DKVtflBkIHMF6wLEUO706U4INnykTIyJvuVNLDZOAtcnoIbgjrvIUEM2Q YMkHMIWP2hNBg== In-Reply-To: <86bke943tp.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 11 Sep 2023 09:33:06 +0300") X-Hashcash: 1:20:230911:65854@debbugs.gnu.org::W+P1LiE+vnKK6EPx:ZxU X-Hashcash: 1:20:230911:juri@linkov.net::CqDqJGb0gI+nT4mo:4g5P X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270032 Hi Juri, Juri Linkov writes: >>> +(defun multi-file-replace-as-diff (files-or-buffers from-string replacements regexp-flag delimited-flag) >>> + (require 'diff) >>> + (let ((inhibit-message t) >>> + (diff-buffer (get-buffer-create "*replace-diff*"))) >>> + (with-current-buffer diff-buffer >>> + (buffer-disable-undo (current-buffer)) >>> + (let ((inhibit-read-only t)) >>> + (erase-buffer)) >>> + (diff-mode)) >>> + (dolist (file-or-buffer files-or-buffers) >>> + (let ((file-name (if (bufferp file-or-buffer) buffer-file-name file-or-buffer))) >>> + (when file-name >>> + (with-temp-buffer >>> + (if (bufferp file-or-buffer) >>> + (insert-buffer-substring file-or-buffer) >>> + (insert-file-contents file-or-buffer)) >> >> I wonder what happens if I call `multi-file-replace-regexp-as-diff` and >> select a file `foo.txt`, that I already have open and modified in a >> buffer. IIUC, this will generate the diff based on the contents of the >> file on disk, not the buffer, so it might not match when I subsequently >> try to apply the diff to the buffer. WDYT? > > For such cases you can use multi-buffer-replace-regexp-as-diff > from this patch instead of multi-file-replace-regexp-as-diff. Well, in the simple example of one file, yes that possible, but the point is that you don't always know (or worry about) whether there's an overlap between the files you have open and modified and the files your regexp/wildcard matches. Let's say I'm editing an HTML file, and find something that I'd like to change. So I do it. Than I think "actually, let's change that across all my HTML files in this directory". IMO It would be great if I could use this new command, `multi-file-replace-regexp-as-diff`, to get a diff showing how that'd look. But in the proposed implementation, that won't work if one of those HTML files is open and modified--without any warning, Emacs would create a diff that doesn't apply. > The former generates the diff based on the contents of the > file in the buffer, the latter uses the contents on disk. Yes, but what is the use case for generating the diff based on the contents on disk when the file is modified in Emacs? Basically, my suggestion is to check in `multi-file-replace-regexp-as-diff` if any of the matching files are visited by some buffer, and if so simply pass the buffer instead of the file name for that file to `multi-file-replace-as-diff`. That way you always get an up-to-date diff, and you don't need to manually check that you don't have any of the matching files open by any chance. Does that make sense?