From unknown Fri Aug 15 04:07:47 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#70820 <70820@debbugs.gnu.org> To: bug#70820 <70820@debbugs.gnu.org> Subject: Status: [PATCH] Editable grep buffers Reply-To: bug#70820 <70820@debbugs.gnu.org> Date: Fri, 15 Aug 2025 11:07:47 +0000 retitle 70820 [PATCH] Editable grep buffers reassign 70820 emacs submitter 70820 Visuwesh severity 70820 normal tag 70820 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 12:25:50 2024 Received: (at submit) by debbugs.gnu.org; 7 May 2024 16:25:50 +0000 Received: from localhost ([127.0.0.1]:43511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4NdW-0003WL-2X for submit@debbugs.gnu.org; Tue, 07 May 2024 12:25:50 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4NdT-0003WF-5b for submit@debbugs.gnu.org; Tue, 07 May 2024 12:25:48 -0400 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 1s4Ncy-00052q-Ce for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 12:25:16 -0400 Received: from mail-oo1-xc43.google.com ([2607:f8b0:4864:20::c43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s4Ncw-0002as-JA for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 12:25:16 -0400 Received: by mail-oo1-xc43.google.com with SMTP id 006d021491bc7-5ac90ad396dso1968566eaf.3 for ; Tue, 07 May 2024 09:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715099113; x=1715703913; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=QFvwqEI7oz5LCbyvhuHly8RuI6z9DKFX2FBUZ+LFkGc=; b=VC3SZj46CKO1V90QGyWz5k1HtONFOJUbqz6032MaG/JdtJVESK4kazU7ykHAgvmhJs ajkSc3Qbd62HQ6wXhfMF0dscXQdp4KjRUVQa41A/K7PQS+6YdVIlmFGqh1lJBRUL+bu0 SosXUG0VcLck+FxTKZ36aaZge76SkyCcBE1R2DqfqzMhBJQgvNL/eVmpdhQbMSSbnWAP CgEI5NU0w6s9fONbPDPoFmTHvLZzFDP2W8wgh7ljDxyT6PqELI3xumrFWOrUQkI1jfoP V+7WVTobZ5aLVprfSJOXX5BK9lBrzquonY14TBAGw19hpQsWR6nrnC9IvxlQH7xOsuBr 4pUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715099113; x=1715703913; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QFvwqEI7oz5LCbyvhuHly8RuI6z9DKFX2FBUZ+LFkGc=; b=dopwIJxDiP3Do5hlQxj/5W0/rOfNI1a3V9fzI1UGf1lZqVZbyPjk9EQBfF4d4Vq8tU TbChdLihq2WSzJsMIVz/Hw4JbN0Hd9at1HCTCMOTbKP1EAFWZqMnqFIFA8RdQhOPYvSY syVsFL4Du9rZr2tFvLkJDtZPDgwjpX5QrB3ac7sNHkFbk6hBxIIw1J80CamnxKfYI9rf Qbva57qFPhVPVwzR33vNFJBx+yHHEEfkc3pFA/7//ZyDoRI6FzIiFn3Wv8tnqza1Bsva wHVHGm1Gw771d5muk+f7PIWgqJvCDAIvAJR0xAIp0SxGFMZzvphk7mwR9I2WxxBqgwZX Mmhw== X-Gm-Message-State: AOJu0YzlLqIkccqkeZzFx6r5ZuumwH9JomkI6PF16tIpebG5lBHOwZND m2IK07VMH/3V3hQFwz7Wc8fOAyulVnJXr+k+3t1GIwDvqNZLssSPtKxiuMRI X-Google-Smtp-Source: AGHT+IHBgHVn8UtWUV9d5xZRB9OHZl8bs9y7S+7YP9VP5HxJM7KrNRu4kB+nD7jzg+uqQwiX8b060g== X-Received: by 2002:a05:6358:e488:b0:192:2540:554c with SMTP id e5c5f4694b2df-192d2a1776amr29101655d.1.1715099112631; Tue, 07 May 2024 09:25:12 -0700 (PDT) Received: from localhost ([49.204.134.76]) by smtp.gmail.com with ESMTPSA id k133-20020a636f8b000000b0062d54efed87sm1207817pgc.53.2024.05.07.09.25.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 May 2024 09:25:11 -0700 (PDT) From: Visuwesh To: bug-gnu-emacs@gnu.org Subject: [PATCH] Editable grep buffers Date: Tue, 07 May 2024 21:55:09 +0530 Message-ID: <87seytlhcq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::c43; envelope-from=visuweshm@gmail.com; helo=mail-oo1-xc43.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain Tags: patch Attached patch is a proof of concept for an occur-edit-mode alike for *grep* buffers. It uses the new track-changes library to track the edits made in the *grep* buffer to then finally save these edits to the corresponding files. I've tested this with: 1. pure deletions: If you have a match that says "(cur-beg start" and you change it to "(cur- start". This is special because track-changes-fetch passes equal BEG and END to grep-edit--track-changes-finalise. 2. edits: something like "(cur-beg start" -> "(cur-beg start balh" is handled like you would expect. 3. edits with newline: if the edit includes a newline, then that is reproduced. and what is not handled currently: deleting a match line to imply deletion of that line from the matched file. I don't know how to handle this currently, I need to learn the library more. There's also definitely a million more cases that I didn't anticipate when I wrote the logic for grep-edit--track-changes-finalise. I'm sending the patch now to see if there's enough interest before I go about fixing the edge cases (there's bug#52815). If there is enough interest, I will take a shot at implementing something like this for xref result buffers too. In GNU Emacs 30.0.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.0, Xaw scroll bars) of 2024-05-07 built on astatine Repository revision: 4b31074f5f49898ba0499a2b617cad425750eafa Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101011 System Description: Debian GNU/Linux trixie/sid Configured using: 'configure --with-sound=alsa --with-x-toolkit=lucid --with-json --without-xaw3d --without-gconf --without-libsystemd --with-cairo --with-xft' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=grep-edit.diff diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 657349cbdff..3fa6fce0e8d 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -31,6 +31,7 @@ (eval-when-compile (require 'cl-lib)) (require 'compile) +(require 'track-changes) (defgroup grep nil "Run `grep' and display the results." @@ -295,6 +296,8 @@ grep-mode-map (define-key map "}" #'compilation-next-file) (define-key map "\t" #'compilation-next-error) (define-key map [backtab] #'compilation-previous-error) + + (define-key map "e" #'grep-edit-minor-mode) map) "Keymap for grep buffers. `compilation-minor-mode-map' is a cdr of this.") @@ -1029,6 +1032,71 @@ grep command-args) #'grep-mode)) +(defvar-local grep-edit--tracker nil + "ID of the `track-changes' tracker.") + +(defun grep-edit--track-changes-signal (_id &optional _distance) + ;; Empty because we want to simply accumulate the changes at end + ;; when the user calls the finish function. + nil) + +(defun grep-edit--track-changes-finalise (beg end _before) + (let ((grep-buf (current-buffer)) + (cur-res beg)) ; Point at current grep result. + (save-excursion + (while (<= cur-res end) + (goto-char cur-res) + (let* ((change-beg (next-single-char-property-change (pos-bol) 'compilation-message)) + ;; `1-' is required to ignore the newline. + (change-end (1- (next-single-char-property-change (pos-eol) 'compilation-message))) + (loc (compilation--message->loc + (get-text-property (pos-bol) 'compilation-message))) + (line (compilation--loc->line loc)) + (file (caar (compilation--loc->file-struct loc)))) + (with-current-buffer (find-file-noselect file) + (save-excursion + (goto-char (point-min)) + (forward-line (1- line)) + (delete-region (pos-bol) (pos-eol)) + (insert-buffer-substring-no-properties grep-buf change-beg change-end)))) + (setq cur-res (next-single-property-change cur-res 'compilation-message)))))) + +(define-minor-mode grep-edit-minor-mode + "Minor mode for editing *grep* buffers. +In this mode, changes to the *grep* buffer are applied to the +originating files upon saving using \\[grep-save-changes]." + :lighter " Grep-Edit" + (if (null grep-edit-minor-mode) + (progn + (setq buffer-read-only t) + (buffer-disable-undo) + (use-local-map grep-mode-map)) + (unless grep-edit--tracker + (use-local-map grep-edit-minor-mode-map) + (setq buffer-read-only nil) + (buffer-enable-undo) + (setq grep-edit--tracker + (track-changes-register #'grep-edit--track-changes-signal + :disjoint t))) + (message (substitute-command-keys + "Editing: \\[grep-edit-save-changes] to return to Grep mode.")))) + +(defun grep-edit-save-changes () + "Save the changes made to the *grep* buffer." + (interactive) + (when (and grep-edit-minor-mode grep-edit--tracker) + (track-changes-fetch grep-edit--tracker #'grep-edit--track-changes-finalise) + (message "Applied edits, switching to Grep mode.") + (track-changes-unregister grep-edit--tracker) + (setq grep-edit--tracker nil) + (grep-edit-minor-mode -1))) + +(defvar grep-edit-minor-mode-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map text-mode-map) + (define-key map (kbd "C-c C-c") #'grep-edit-save-changes) + map) + "Keymap for `grep-edit-minor-mode'.") ;;;###autoload (defun grep-find (command-args) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 13:24:07 2024 Received: (at 70820) by debbugs.gnu.org; 7 May 2024 17:24:07 +0000 Received: from localhost ([127.0.0.1]:43753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4OXu-00046G-5a for submit@debbugs.gnu.org; Tue, 07 May 2024 13:24:07 -0400 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]:43363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4OXo-00045t-Ma for 70820@debbugs.gnu.org; Tue, 07 May 2024 13:24:04 -0400 Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-6f4302187c0so4149499b3a.1 for <70820@debbugs.gnu.org>; Tue, 07 May 2024 10:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715102610; x=1715707410; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=I4SBcw5nxWJPoYd+6Nl+Is7o9msgCSeLzjGbDu7Ssac=; b=UAa9mSY90UnpIJ05Zk3niztZPUTdeEItUDLpXljvkK/jzrkruszcWfFg+9wmA/YCXb 6HbZpyhaYRSfq0W+uuU4PtyAiJHAMVV7cCiA3+6nW9FOgCPMHhcYLb3RrGx+44wnafUC iF6qlPRMJUQNez2zJvWUGaHyjZX4ZxeU9Vn6nsyPssSheKK2XBu0IoAMP7Oism03fjlb CVkzlfPaDGVl+jzcsodK5DGQJYybu6VEPIkuhb1DB+6mgoETakvVswL1LBU0gSho8y1a oHV0cvAXkmk8Ubb1vuRTgJwv/QGb9HXRmDEqrQyVcClFtg9er8iwYOuJv1AEOTBkz9IM Vklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715102610; x=1715707410; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I4SBcw5nxWJPoYd+6Nl+Is7o9msgCSeLzjGbDu7Ssac=; b=Ce8ByLI/1KIb5n4HU3tv21uVvXkT0sJPzGtoC+RzLCec4xdTnevxvLXuwBD9ES2BY3 Sk3A66BMPOJu+7pfp/JN4cRmnCmq5//9MZYdZ6Nhh4ea7u4H7bnb/IYSQeP/801dHMWG OS0pY6D5YisDGJNw3UeTm7FWoYr/zg2cOL7YUsCk0wc3KLMlkMPTrsPMKUUeCwgE+Pte hNjPBjrNoozn+7S03ll2kE5mcn1MIL8jRbKbGH/QrMDvkaEXHp1rmu0rxhfdI+aV7JUY V7yJSYV6gD5jysML/jfBfI/8jz1oliv0gfaqUTrSWL1xJCK++VumhPE+WieJAaXSeI3I WwEw== X-Forwarded-Encrypted: i=1; AJvYcCWF3AdpAbT3h8ilC+WV5H58dG7ruv4TUWL9NEnKjSCe/1NiS+GoojgG6IaY3X93nnq3NDp2YpdRmbcJcHRT6z+/FmaEn/s= X-Gm-Message-State: AOJu0YyMnxENgO6/IRQu3cPG+YsYBubMqDRcaGY+mL+uGqGFEKYGxhmj cc5bdGLpE+WzLvSJFSRqsaW3h1B/smnR5wnpDEKLdSedg3UrRFfj X-Google-Smtp-Source: AGHT+IHtMEtzj1IhajPuWoOUah432BW1aNU8dDGsFzJYM4kwLFJc9JotzCHtAumTmBPiENVSz7EbCQ== X-Received: by 2002:a05:6a21:819d:b0:1aa:954f:d466 with SMTP id adf61e73a8af0-1afc8983469mr524181637.23.1715102609807; Tue, 07 May 2024 10:23:29 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id b8-20020aa78ec8000000b006f4401df71bsm9311077pfr.151.2024.05.07.10.23.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 May 2024 10:23:29 -0700 (PDT) Message-ID: Date: Tue, 7 May 2024 10:23:30 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers Content-Language: en-US To: Visuwesh , 70820@debbugs.gnu.org References: <87seytlhcq.fsf@gmail.com> From: Jim Porter In-Reply-To: <87seytlhcq.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/7/2024 9:25 AM, Visuwesh wrote: > I'm sending the patch now to see if there's enough interest before I go > about fixing the edge cases (there's bug#52815). If there is enough > interest, I will take a shot at implementing something like this for > xref result buffers too. How does this compare to the existing wgrep package? That doesn't have copyright assignment to the FSF, but otherwise, I think it's the bar against which any similar package should be measured. I use it pretty frequently (and have even written a plugin for it for my own grep-like major mode), and it's pretty much exactly the way I'd want this sort of thing to work. Something with feature-parity that lives in the Emacs tree would be great though. From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 14:09:33 2024 Received: (at 70820) by debbugs.gnu.org; 7 May 2024 18:09:33 +0000 Received: from localhost ([127.0.0.1]:43939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4PFs-0007FX-SP for submit@debbugs.gnu.org; Tue, 07 May 2024 14:09:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4PFo-0007FR-Bs for 70820@debbugs.gnu.org; Tue, 07 May 2024 14:09:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4PFJ-0000Ls-Qj; Tue, 07 May 2024 14:08:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3PpZBK226scGsm6ox04YgOtaBrvG/uZXNRqFsVpAA+I=; b=Q1xcuPxxLeFE tW0jmoBhYLG5OsMh2HRcyULM2b8D3XQj9yf31rY52USw/Ey/B8Rb5/kOgaCZriaUlHpOK+GvNCVrQ 44shs9rNLu1CqCT1YF9capapz44mjuvx9jzvqo1gKU91d99mw5D6V2tvF9WvrOfjHwKHSw6GgBHS1 7xm87RidiP9OdplcMMPBVuT77w6LlwIAGceO1nvhdrhdFdAuJ+w6wdmuyxOGQg5C2nNLUT1Bwy7rt KmiLdFlon+Tyv9VXNiF6A911ASlRula0aanLYQEG7K+xA+Rqr5tGggPq5+TRyccP2LMvvSzJViasw 8RLIGFTsWvdkxYZEEWmtrw==; Date: Tue, 07 May 2024 21:08:37 +0300 Message-Id: <86pltxa40q.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87seytlhcq.fsf@gmail.com> (message from Visuwesh on Tue, 07 May 2024 21:55:09 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Visuwesh > Date: Tue, 07 May 2024 21:55:09 +0530 > > Attached patch is a proof of concept for an occur-edit-mode alike for > *grep* buffers. It uses the new track-changes library to track the > edits made in the *grep* buffer to then finally save these edits to the > corresponding files. I've tested this with: > > 1. pure deletions: If you have a match that says "(cur-beg start" > and you change it to "(cur- start". This is special because > track-changes-fetch passes equal BEG and END to > grep-edit--track-changes-finalise. > 2. edits: something like "(cur-beg start" -> "(cur-beg start balh" > is handled like you would expect. > 3. edits with newline: if the edit includes a newline, then that is > reproduced. > > and what is not handled currently: deleting a match line to imply > deletion of that line from the matched file. I don't know how to handle > this currently, I need to learn the library more. > > There's also definitely a million more cases that I didn't anticipate > when I wrote the logic for grep-edit--track-changes-finalise. > > I'm sending the patch now to see if there's enough interest before I go > about fixing the edge cases (there's bug#52815). If there is enough > interest, I will take a shot at implementing something like this for > xref result buffers too. Thanks for working on this. I wonder if this could be somehow either based on or at least have the same look-and-feel as occur-edit-mode, which provides a very similar feature in *occur* buffers. From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 23:13:09 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 03:13:09 +0000 Received: from localhost ([127.0.0.1]:46310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Xjw-00084b-Sr for submit@debbugs.gnu.org; Tue, 07 May 2024 23:13:09 -0400 Received: from mail-oo1-xc41.google.com ([2607:f8b0:4864:20::c41]:55396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Xjs-00084C-D3 for 70820@debbugs.gnu.org; Tue, 07 May 2024 23:13:07 -0400 Received: by mail-oo1-xc41.google.com with SMTP id 006d021491bc7-5b1ffd24c58so2082444eaf.2 for <70820@debbugs.gnu.org>; Tue, 07 May 2024 20:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715137953; x=1715742753; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=J1BNu8FaLNAvuAO9womKI2FmwDdtjGVW3TWXpMrVxkc=; b=nnk6c66k0klQNJFEpkUH0ailuJ4ENk0AV7A2PrhXj9zRLjmo5f8X2RKjiK5/UiQIqX m7NnbiIywxCwuDu5zdGmxID8T1eJpRgxMyUt19wCYw+A7HPy8eA2CvR3aJi7CMtNuJCh 2yV3VOcC+kt7Ikp2gJlYExsbbON1Ya3WiQRqpuJ+6/Tip2HK9NKD14Se1zJsxfkXFEHn ZFV1OqDwX9m1jwsJYfdFjArU2qnsaz2fi0DBWD/aY2XeYgmk4Af8PQgOPc8Nd42mmbfG f2X7/Yd8XfuEUawFcwLdAkvzFcl9e2TPNSIp2+g9/6VUehGHS9UQM9S0eZ8NIII4pmpP tnpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715137953; x=1715742753; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=J1BNu8FaLNAvuAO9womKI2FmwDdtjGVW3TWXpMrVxkc=; b=tnNvXaB0F0LKxQCZ7vIq9WfdOOBuItnUdJHzOHDVahWhx2w9YR8ClIspVPigXUHtMO iooRvuGfR5xLAUzKu3yL+CpKqSbDzokJcg2laD0dp9gStKi62c/i9ziq/tgWm8n+UNu7 1RFSd/dy2tOfkQBQXyzAUo72tc6hQBmm8C7Tn5VjWbzEfMd8F/lZCZvaLbPp02avhxdU dkEGR5Qinfag2SQ4tkIB2zofYSeb1584mvbc4m4DX+pMq2WDNpmQPAYXq1g4xoiSGVw1 zFJpLsP+b6deYc+YdeCYiO11Yx0Bheo3tUL5Mnfc75cBW0uLJvTfVaadvD2iVSgRcI8V OL/Q== X-Gm-Message-State: AOJu0YxAOf1DkLfxpNVdmsaCZqcu3LUU5RsC511+kVyACvlAX96KC7Wb bSeQG+S3u2ZdGbMroJcsMRFpvBsU4dn5B0FMVw+ffcAWMDiAMDSw X-Google-Smtp-Source: AGHT+IFsc9i8JBbH1SFCPnhw4Rbs9PRAZtlbk4zKdcsfCAIYjjo+2rAWUZHEuKbpwkJieLpUkAdYIw== X-Received: by 2002:a05:6870:b69a:b0:23c:4a4b:ba97 with SMTP id 586e51a60fabf-24097c6745amr1615392fac.22.1715137953350; Tue, 07 May 2024 20:12:33 -0700 (PDT) Received: from localhost ([49.204.130.239]) by smtp.gmail.com with ESMTPSA id u9-20020a056a00098900b006f3ef4e7551sm6048723pfg.217.2024.05.07.20.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 May 2024 20:12:32 -0700 (PDT) From: Visuwesh To: Jim Porter Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: (Jim Porter's message of "Tue, 7 May 2024 10:23:30 -0700") References: <87seytlhcq.fsf@gmail.com> Date: Wed, 08 May 2024 08:42:30 +0530 Message-ID: <87o79hkndt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF=8D = =E0=AE=AE=E0=AF=87 07, 2024] Jim Porter wrote: > On 5/7/2024 9:25 AM, Visuwesh wrote: >> I'm sending the patch now to see if there's enough interest before I go >> about fixing the edge cases (there's bug#52815). If there is enough >> interest, I will take a shot at implementing something like this for >> xref result buffers too. > > How does this compare to the existing wgrep package? That doesn't have > copyright assignment to the FSF, but otherwise, I think it's the bar > against which any similar package should be measured. I use it pretty > frequently (and have even written a plugin for it for my own grep-like > major mode), and it's pretty much exactly the way I'd want this sort > of thing to work. Something with feature-parity that lives in the > Emacs tree would be great though. I definitely agree that wgrep is the standard to which my patch should be compared with. I haven't actually used wgrep before but I took a look at its README and so far, the features that are missing are: =C2=B7 I already quoted: deleting lines from the file. I may tackle th= is once I get the basic editing features reliable. =C2=B7 Aborting changes wholesale: this should be easy and is already on my list. =C2=B7 Aborting changes in a region: I wonder if we cannot simply use undo restricted to a region to do it. But otherwise, I can take a look at implementing this since I am also interested in this (but once I get the basics reliable). Thanks for your input. If I missed something from wgrep that you use, please let me known. I will play around with wgrep in some time to learn more about what it offers myself. From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 23:23:27 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 03:23:27 +0000 Received: from localhost ([127.0.0.1]:46351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Xtv-0008DW-4A for submit@debbugs.gnu.org; Tue, 07 May 2024 23:23:27 -0400 Received: from mail-oa1-x44.google.com ([2001:4860:4864:20::44]:49250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Xts-0008DA-S8 for 70820@debbugs.gnu.org; Tue, 07 May 2024 23:23:26 -0400 Received: by mail-oa1-x44.google.com with SMTP id 586e51a60fabf-23e94f0788aso2045726fac.2 for <70820@debbugs.gnu.org>; Tue, 07 May 2024 20:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715138574; x=1715743374; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8fFHZUUDIWyFatsN/E7uXxfuYJMj2SJD4OQomr5vmJo=; b=XB1mtAFriLJmynB6FvVUnpQPAz2YCC6UxEhtTB0SiOCKy4edNEdSQBckBp5T+ZCYFr kNddebidsRKblgufnYzKTIF7dpGQkmD7o8/ndgtUfAnT+IlLjxZt+nZrDaHbt6jQRPPp JaPi5dPLhfxZh5zVWWXiIB/TMa88qlNII3K+axWIJLS6EOepZNV2MMs3di75ChZB4UUU rENrq418E+Llrj5EDPR1kgZo5+Ari/nL4fzFNIrJ/QJGvVHkGd95etIwoF9IoH/WSYi+ alm9lRRm2xdhYIn89sflANZc/qQ1MCuyGtEGHvDTdLGXWVS4bclBFbEpQCrPmBsfIa0M UG5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715138574; x=1715743374; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8fFHZUUDIWyFatsN/E7uXxfuYJMj2SJD4OQomr5vmJo=; b=IYqjF7kZHlGz0QqcHPwfzKIoC+uVs1X5t8JEB0Aub46UDJAoxEKSiYYqnCqfRe+7mJ be33tFw+9gOyLb/vtgXSk3XpFgZg+Z3VHm4pOTu1JKX/+hOTJZxwqIH7CTW9mNyvkf7+ RUkQUtQGzNL9Rdd7UR6JVLJNChnysI1oBj7fH9mHIl5kZLBkVLG4tOxVF8N2lqbGxQHc 8r4CgNlkhPDWy0DvJ+OqJU0d+7dzkqhnr/c7p1USRz17P9D+sS2mql+26Hs4iWSuwZ9S Faoe5pnYodBQh49pNm4Ycqqy2ICYmGCjN5la7+doP2zVZnfcimHJpQzBlMQGXiMg/Jap wDjg== X-Gm-Message-State: AOJu0YxzkdqxL68VB3QaQL9cFy8cLrrBRX2uLmOCClRbatj61pPsdTRR grFKnxPHW4X/LFXOh4WAlHvk/ARIDhgO0nwpHYZKc2oJGAzR6FscYJ6jlrS6 X-Google-Smtp-Source: AGHT+IGGwXG2bhdybmCKC6UJ2gibKOEJJWkz6rhPdBZqDe+xRqlMdgDWbV8600ZgjSJS2lULnzkQmQ== X-Received: by 2002:a05:6870:9619:b0:229:ce58:477a with SMTP id 586e51a60fabf-2409891f318mr1579723fac.19.1715138573702; Tue, 07 May 2024 20:22:53 -0700 (PDT) Received: from localhost ([49.204.130.239]) by smtp.gmail.com with ESMTPSA id f17-20020aa78b11000000b006f45e7121a2sm6450282pfd.41.2024.05.07.20.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 May 2024 20:22:53 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86pltxa40q.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 May 2024 21:08:37 +0300") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> Date: Wed, 08 May 2024 08:52:51 +0530 Message-ID: <87jzk5kmwk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF=8D = =E0=AE=AE=E0=AF=87 07, 2024] Eli Zaretskii wrote: > [...] > Thanks for working on this. > > I wonder if this could be somehow either based on=20 Basing it on occur-edit-mode would be a lot more work I think, but I understand your concern wrt it being already established and bug-free, etc. This was my original plan but I bailed since the occur buffer's text-properties has marker objects (IIRC) but I want to avoid using markers since having many buffers open was a personal pet peeve of mine, along with the slow-typing experience due to occur's after-change-function immediately reflecting the changes in the original buffer. The latter is avoided in my patch since we commit the changes only at the end so the typing during the edit is smooth. > or at least have the > same look-and-feel as occur-edit-mode, which provides a very similar > feature in *occur* buffers. This is what I am aiming for ideally since I am a fan of its interface myself (preferring it over xref). The major difference between occur-edit-mode and my patch's grep-edit-minor-mode is that it is implemented as a minor mode: I chose a minor-mode because all the buffer local variables that are required to make the commands from the *grep* buffer functional are killed when switching major-modes (so even g doesn't work!). We could work around this by marking the relevant variables permanent-local but this feels unclean? The other difference that I can see now: the filename and the line number parts aren't marked read-only so it can be edited when grep-edit-minor-mode is active. I will mark them read-only to have the experience closer to occur-edit-mode. From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 00:12:22 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 04:12:22 +0000 Received: from localhost ([127.0.0.1]:46537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4YfF-0000LL-Tr for submit@debbugs.gnu.org; Wed, 08 May 2024 00:12:22 -0400 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]:49297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Yf8-0000L9-78 for 70820@debbugs.gnu.org; Wed, 08 May 2024 00:12:18 -0400 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1ed0abbf706so27264485ad.2 for <70820@debbugs.gnu.org>; Tue, 07 May 2024 21:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715141503; x=1715746303; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=TUflPv154ye+GVhSCgzK+7uydJ8K28j2sD1y08FMTdA=; b=WQtwJ84VSuKSzsv6iXryXcANy5YD8KdOMFMbAHOYB0sM011DftBhTVENaDHQ/M5Vcm hIVmRvf4iM0FY4VDdUE7oDx/PtTfcaVMgDdHe7c/6g3W0M8DY3gu85t1LDcCJhpPJwdD Y/sxDdwDYsSG2e0YTCCl4jJjBfN7Npb+wlBRnlNo56hEc+Jz9pLXABEU9YlRiEg1pM54 mjdUDQSJEBqCS8Kfz+dHMpLhMAo9BEq4ZwxvcuLvUzZ86wnmDTUugbyWvwOnOjUNvBaz p6batZV1jvI/ISWjd0ZP0h+p0c2yUiKJaYq/FLyZTiSNhXH4xvtT6UyRA09h8COxMkii UCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715141503; x=1715746303; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TUflPv154ye+GVhSCgzK+7uydJ8K28j2sD1y08FMTdA=; b=YrpNO9PLYglg8PSM8h8o6rKqmLfAzKh45PTpvzkWwAfCW4R9fr1sAo9xAUZs+ro2Jh ldwlL2Ap9b9+OG4zM8g1/+zZhp5/eRTMQwW27yDl02jFxn84K89h4020X6vdbuBGEOhT rJ/Lj0J66Teuf779x88a+AhKTreYCU+/SAuBBYJ4jz+zTLBzZPeB5FRkPOlt8Wd0SDgM Pd3OfoGcpiovw8ywDLE9uiztBRBuKz+N1wsJLatGw9utsmO8bXVF7mnSQpxy3RMTKPln li4LZWlIr5Seqffh6skh4EdBIKTQ65LFISCe+G/rVzbs/oro1+PkLJ9YBn2sQqQUWbfp wjUw== X-Gm-Message-State: AOJu0YxaN/TyLWXOMkC/aLJYH+CdsQBACUFCyN4D45kdE5saBUdnfc6y w7IMNUc8eNqkdq0abPlkQZxoVSLXldsIXpXoC7srhpt+5Cq3gFNl X-Google-Smtp-Source: AGHT+IGiEp1s0iGegMTaZelSsRNpkdI2I4xRE8riKRlPSdSw5F6ghpO2gwo6kyrysbsz/KHdoRJlvw== X-Received: by 2002:a17:902:e852:b0:1e5:9391:1d44 with SMTP id d9443c01a7336-1eeb078f212mr18855925ad.47.1715141502720; Tue, 07 May 2024 21:11:42 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id n10-20020a170902e54a00b001e29c4b7bd2sm10871908plf.240.2024.05.07.21.11.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 May 2024 21:11:42 -0700 (PDT) Message-ID: Date: Tue, 7 May 2024 21:11:42 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers To: Visuwesh References: <87seytlhcq.fsf@gmail.com> <87o79hkndt.fsf@gmail.com> Content-Language: en-US From: Jim Porter In-Reply-To: <87o79hkndt.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/7/2024 8:12 PM, Visuwesh wrote: > Thanks for your input. If I missed something from wgrep that you use, > please let me known. I will play around with wgrep in some time to > learn more about what it offers myself. In addition to the things you mentioned, here are the most important features from wgrep for me: * Mark all non-result parts of the buffer (the command string, file names, line numbers, etc) as read-only. This is especially valuable if you want to use 'query-replace' or similar to modify the results. Then you can't inadvertently edit those bits. * Fontify any results with changes (both in the grep-mode buffer and the original files). This is really useful for being able to see what I've changed. * Adding all the necessary hooks/functions so other grep-like modes can use this. For example, see this file from wgrep, which lets you use wgrep with ag.el: . (This matters to me partly because I'm the author of Urgrep - a "universal recursive grep" mode that can use any grep-like program to do searches. I've added my own support in Urgrep for wgrep.) From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 01:11:49 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 05:11:49 +0000 Received: from localhost ([127.0.0.1]:46814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Zam-00018B-PL for submit@debbugs.gnu.org; Wed, 08 May 2024 01:11:49 -0400 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]:48352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Zak-00017x-AM for 70820@debbugs.gnu.org; Wed, 08 May 2024 01:11:47 -0400 Received: by mail-pj1-x1044.google.com with SMTP id 98e67ed59e1d1-2b33e342c03so3415606a91.0 for <70820@debbugs.gnu.org>; Tue, 07 May 2024 22:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715145074; x=1715749874; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=OURMamFewAP4qDWZveJVugL2RB6IYxH//XM2cyorinQ=; b=UfoYCS0FSOWQgQC5UckiQ7T7ziioCG64rCfubc0Rw3Ssx0HfiYSmXjGW8ENwr6yfQL 0hFuKvclSrV3658My5rRMyEvoL5H48rhmFnRhE7IezC7NcYizJWrsgCsrBbV27rVPBEu fdCWq4WojDKNHyhYQKAlYZvUGMK8LY7qSbLInQCi9c/8I1/+Fu0jdFc17kqLUiO6+TRx eEwGYM18lPtNi0kf33kzolOUPMV2R5HI4PCJAggSYMDG4Wg4lC5Mt9jjkK43AObW151L j8IuZr41grATAOablp8NIQAlvXpISRWXDQQJLy8DvZgVN+6GioG5Cd6jVbUEfGovOiyl qzEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715145074; x=1715749874; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OURMamFewAP4qDWZveJVugL2RB6IYxH//XM2cyorinQ=; b=fmZ4xkUEWClY2yg0eGpZbgsLAHI67pwuiVK+lzIHdhj+WtDYA5ragly2vXSPiR8oON Ohhj3ykJNOmhMOKv0JWXvbWe2K+Azsrty8mASksw+Q7orC8z9zZ7GxKHxfMNjr4Briq8 Yt/yapaAMUZ3Mc4aYrZwhx5rIS1iNv7dRqDF/dAISsli0adlr0SocAFroUEIppMVCv31 HarZQIXwtsde6IwXTVn8s69HXlKC0FyPGPy0WIX/i0sfOIcxN9JdGsjMw47K2Ho4jQPO KbqPxPh3AKAja2Xtoo1Q2c4VXNLC9CLKqwNIcVw5FWY7rb3Cvq1dXmkOpwZV7OKjcBdy bE9A== X-Gm-Message-State: AOJu0Yz+LMRjdGVCwlMO/mqrRVq11C/RHzuOFzRy9bbNWTrjJSgPWgbq xnQD1l2r2J4bshzEY26NCZG9Je56tikqZfB8HpkuuITQahsPY/ST X-Google-Smtp-Source: AGHT+IE5efjlwxt24/PG6Irq+CFeV0aASJ+pU0bxr+hDWwDzOjp0tvNfdUFF46VA6UEXEMh5J6yzLA== X-Received: by 2002:a17:90a:a90:b0:2a4:e9d:9888 with SMTP id 98e67ed59e1d1-2b6165a3afdmr1550641a91.16.1715145073551; Tue, 07 May 2024 22:11:13 -0700 (PDT) Received: from localhost ([49.204.130.239]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b62863cd9dsm465127a91.12.2024.05.07.22.11.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 May 2024 22:11:12 -0700 (PDT) From: Visuwesh To: Jim Porter Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: (Jim Porter's message of "Tue, 7 May 2024 21:11:42 -0700") References: <87seytlhcq.fsf@gmail.com> <87o79hkndt.fsf@gmail.com> Date: Wed, 08 May 2024 10:41:10 +0530 Message-ID: <87cypwlwgh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF=8D = =E0=AE=AE=E0=AF=87 07, 2024] Jim Porter wrote: > On 5/7/2024 8:12 PM, Visuwesh wrote: >> Thanks for your input. If I missed something from wgrep that you use, >> please let me known. I will play around with wgrep in some time to >> learn more about what it offers myself. > > In addition to the things you mentioned, here are the most important > features from wgrep for me: Thanks. > * Mark all non-result parts of the buffer (the command string, file > names, line numbers, etc) as read-only. This is especially valuable > if you want to use 'query-replace' or similar to modify the > results. Then you can't inadvertently edit those bits. This is now done. > * Fontify any results with changes (both in the grep-mode buffer and > the original files). This is really useful for being able to see > what I've changed. I agree that it would be nice to have this in *grep* buffer but I would like to avoid editing the file on-the-fly since it introduces typing lag IME with occur-edit-mode. If you want to know the edits that were made, you can use diff-buffer-with-file so I hope leaving out the highlighting in the file would be okay. > * Adding all the necessary hooks/functions so other grep-like modes > can use this. For example, see this file from wgrep, which lets you > use wgrep with ag.el: > . = (This > matters to me partly because I'm the author of Urgrep - a "universal > recursive grep" mode that can use any grep-like program to do > searches. I've added my own support in Urgrep for wgrep.) With grep-edit-minor-mode, as long as the compilation-message text-property is present at the beginning of the line, you do not need to do anything extra. I look at this to gain the information about the filename and the line number. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=grep-edit.diff diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 657349cbdff..517d1bd5ecd 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -31,6 +31,7 @@ (eval-when-compile (require 'cl-lib)) (require 'compile) +(require 'track-changes) (defgroup grep nil "Run `grep' and display the results." @@ -295,6 +296,8 @@ grep-mode-map (define-key map "}" #'compilation-next-file) (define-key map "\t" #'compilation-next-error) (define-key map [backtab] #'compilation-previous-error) + + (define-key map "e" #'grep-edit-minor-mode) map) "Keymap for grep buffers. `compilation-minor-mode-map' is a cdr of this.") @@ -1029,6 +1032,86 @@ grep command-args) #'grep-mode)) +(defvar-local grep-edit--tracker nil + "ID of the `track-changes' tracker.") + +(defun grep-edit--track-changes-signal (_id &optional _distance) + ;; Empty because we want to simply accumulate the changes at end + ;; when the user calls the finish function. + nil) + +(defun grep-edit--track-changes-finalise (beg end _before) + (let ((grep-buf (current-buffer)) + (cur-res beg)) ; Point at current grep result. + (save-excursion + (while (<= cur-res end) + (goto-char cur-res) + (let* ((change-beg (next-single-char-property-change (pos-bol) 'compilation-message)) + ;; `1-' is required to ignore the newline. + (change-end (1- (next-single-char-property-change (pos-eol) 'compilation-message))) + (loc (compilation--message->loc + (get-text-property (pos-bol) 'compilation-message))) + (line (compilation--loc->line loc)) + (file (caar (compilation--loc->file-struct loc)))) + (with-current-buffer (find-file-noselect file) + (save-excursion + (goto-char (point-min)) + (forward-line (1- line)) + (delete-region (pos-bol) (pos-eol)) + (insert-buffer-substring-no-properties grep-buf change-beg change-end)))) + (setq cur-res (next-single-property-change cur-res 'compilation-message)))))) + +(defun grep-edit--mark-read-only () + "Mark annotations and info regions read-only." + (save-excursion + (goto-char (point-min)) + (let ((inhibit-read-only t) + match) + (while (setq match (text-property-search-forward 'compilation-annotation)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t))) + (goto-char (point-min)) + (while (setq match (text-property-search-forward 'compilation-message)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t)))))) + +(define-minor-mode grep-edit-minor-mode + "Minor mode for editing *grep* buffers. +In this mode, changes to the *grep* buffer are applied to the +originating files upon saving using \\[grep-save-changes]." + :lighter " Grep-Edit" + (if (null grep-edit-minor-mode) + (progn + (setq buffer-read-only t) + (buffer-disable-undo) + (use-local-map grep-mode-map)) + (grep-edit--mark-read-only) + (unless grep-edit--tracker + (use-local-map grep-edit-minor-mode-map) + (setq buffer-read-only nil) + (buffer-enable-undo) + (setq grep-edit--tracker + (track-changes-register #'grep-edit--track-changes-signal + :disjoint t))) + (message (substitute-command-keys + "Editing: \\[grep-edit-save-changes] to return to Grep mode.")))) + +(defun grep-edit-save-changes () + "Save the changes made to the *grep* buffer." + (interactive) + (when (and grep-edit-minor-mode grep-edit--tracker) + (track-changes-fetch grep-edit--tracker #'grep-edit--track-changes-finalise) + (message "Applied edits, switching to Grep mode.") + (track-changes-unregister grep-edit--tracker) + (setq grep-edit--tracker nil) + (grep-edit-minor-mode -1))) + +(defvar grep-edit-minor-mode-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map text-mode-map) + (define-key map (kbd "C-c C-c") #'grep-edit-save-changes) + map) + "Keymap for `grep-edit-minor-mode'.") ;;;###autoload (defun grep-find (command-args) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 07:59:30 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 11:59:30 +0000 Received: from localhost ([127.0.0.1]:48474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4fxK-0008II-Bj for submit@debbugs.gnu.org; Wed, 08 May 2024 07:59:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4fxH-0008IC-SN for 70820@debbugs.gnu.org; Wed, 08 May 2024 07:59:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4fwl-0008NB-AD; Wed, 08 May 2024 07:58:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=UZyK+z45CPu5vDZAgkL0bkytW9WhcvZivcC9I75zFwc=; b=YClvvFNyZusfNGDo2OBR 8C12Ri/X4bhjY06dxjxIRzzJAaEEgBAYiUkPEfr8KzcSlb8whi9vp4m9FMQ5j/Axi56eaWju7Jhep ayMxG6vT0oQEGtYbcU7fxugNcULipe0c3F7Qy7ytHh2jwrUOm7jyro4DHiG8wdVcT0i9k9RSi6a7j BajIBpIjeoqm/vpI5OyeuICLJn9sebflAJFRvr5boZx7bBweypdgRIeY3LtPt2ifjeUk8+Zll7eJT sR+eByAEXGQmDYB7SI5Ix4DxvNBmvM4tfrc05m1jIMzw/l9LSI7m1YFcCBGAi0kLIpagTqO+wq3v3 B0H8NzWf3n5FCQ==; Date: Wed, 08 May 2024 14:58:50 +0300 Message-Id: <86ikzoa51h.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87jzk5kmwk.fsf@gmail.com> (message from Visuwesh on Wed, 08 May 2024 08:52:51 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Visuwesh > Cc: 70820@debbugs.gnu.org > Date: Wed, 08 May 2024 08:52:51 +0530 > > [செவ்வாய் மே 07, 2024] Eli Zaretskii wrote: > > > [...] > > Thanks for working on this. > > > > I wonder if this could be somehow either based on > > Basing it on occur-edit-mode would be a lot more work I think, but I > understand your concern wrt it being already established and bug-free, > etc. This was my original plan but I bailed since the occur buffer's > text-properties has marker objects (IIRC) but I want to avoid using > markers since having many buffers open was a personal pet peeve of mine, > along with the slow-typing experience due to occur's > after-change-function immediately reflecting the changes in the original > buffer. The latter is avoided in my patch since we commit the changes > only at the end so the typing during the edit is smooth. I think having similar features that work very differently is not a good thing for Emacs. So I urge you to reconsider your decisions and make this more like occur-edit-mode. In particular, I don't understand the difficulty with using the markers and what does it have to do with the ability of having many Grep buffers. > This is what I am aiming for ideally since I am a fan of its interface > myself (preferring it over xref). The major difference between > occur-edit-mode and my patch's grep-edit-minor-mode is that it is > implemented as a minor mode: I chose a minor-mode because all the buffer > local variables that are required to make the commands from the *grep* > buffer functional are killed when switching major-modes (so even g > doesn't work!). We could work around this by marking the relevant > variables permanent-local but this feels unclean? I don't think I understand this difficulty, either: with occur-edit-mode it is solved by making occur-edit-mode be derived from occur-mode. Couldn't you do the same with your mode? From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 08:18:39 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 12:18:39 +0000 Received: from localhost ([127.0.0.1]:48576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4gFr-0002np-3e for submit@debbugs.gnu.org; Wed, 08 May 2024 08:18:39 -0400 Received: from mail-pj1-x1042.google.com ([2607:f8b0:4864:20::1042]:46423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4gFn-0002ni-Tm for 70820@debbugs.gnu.org; Wed, 08 May 2024 08:18:38 -0400 Received: by mail-pj1-x1042.google.com with SMTP id 98e67ed59e1d1-2b338460546so3247728a91.1 for <70820@debbugs.gnu.org>; Wed, 08 May 2024 05:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715170684; x=1715775484; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HJWhBDW/HKdff1mG7N0s+JyPqgUDtMVz9njpIdYeHFs=; b=HoPcK+ha2ayVPhqdmeVksH79Wg3o17/A/d/B8mQgqnBUsZVkVg4QidTFh6PPwo2wLy V67cIME0s+ZOewd3N7HqlYRvuunvGOFu+75tQKdurwR8PaGKablk0tjLEUITujosFBz6 o1mGf5VA8JQl2W/nVXmamRnnWy2BZX5OGANHSRTCV9dWn5nNhXVEXi53g3exdIpzmTlC JLhOdlBdr6NaO4i2dLy3CZyB7KbSonPtZtGLh+REyUAVDiKm4fRq/74XGexzObFp2UMk BA4/7wT5xwsGoXbrttK/QwvjJfV9sgwybfK7zXSgmlIQ/ocef74jsWhWPkfNX63+ps59 N5Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715170684; x=1715775484; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HJWhBDW/HKdff1mG7N0s+JyPqgUDtMVz9njpIdYeHFs=; b=FQ7/AtvkDLgzOcMoOGtp5N6LR59y0wLDeOQEJ+rP8UVceD6uPbw9lJkH0+NQHO+Gv2 O6VpDoLImTeZsnKVUJaG8NZ02TCoSR4lUfOfNYyVoZyO/Oi3hGhh7sHXzuvWNhOpoWV3 MT4VIr58x9h1lJlx/xP9ik8wl7Brb72cttl71MDYIMiDx3dZZs1uAMWpQSmS30v4uQhd E7gIkpd2ixxbTg6SjXgqO4JCZ9PzBDOe7YLh4rYijXpKCEYy66pow6az+DHhEOEyj0Kp EcYGWld7aJ7svE6cVF5jxxb/ZvXqkPXNBs1QkIQJ3CC7iZnsf+3K+84Ts7H1vnGI4Vle 3EDQ== X-Gm-Message-State: AOJu0YymElYbIQKuS0HQqsoTiG4or2OxbASvT5NED8EXPeAE5gToxTo2 HhKwHt+v25N8F2xmB2fVZQFENWnRiKylaaIHHosnyPnfJGPMAEoo X-Google-Smtp-Source: AGHT+IFFl/ZqZExrCp1MPaazsO/ba2PVAGIsNnXdZAOfmGKhPiUemRak9hU3iEKzQPY9XI3RHMLslQ== X-Received: by 2002:a17:90a:6306:b0:2b6:22bd:f4b2 with SMTP id 98e67ed59e1d1-2b622bdf51bmr1628661a91.4.1715170684484; Wed, 08 May 2024 05:18:04 -0700 (PDT) Received: from localhost ([49.204.130.239]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b62863a5b2sm1297225a91.6.2024.05.08.05.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 May 2024 05:18:04 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86ikzoa51h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 May 2024 14:58:50 +0300") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> Date: Wed, 08 May 2024 17:48:02 +0530 Message-ID: <878r0klcp1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=AE=E0=AF=87 08, 2024]= Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 70820@debbugs.gnu.org >> Date: Wed, 08 May 2024 08:52:51 +0530 >>=20 >> [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF= =8D =E0=AE=AE=E0=AF=87 07, 2024] Eli Zaretskii wrote: >>=20 >> > [...] >> > Thanks for working on this. >> > >> > I wonder if this could be somehow either based on=20 >>=20 >> Basing it on occur-edit-mode would be a lot more work I think, but I >> understand your concern wrt it being already established and bug-free, >> etc. This was my original plan but I bailed since the occur buffer's >> text-properties has marker objects (IIRC) but I want to avoid using >> markers since having many buffers open was a personal pet peeve of mine, >> along with the slow-typing experience due to occur's >> after-change-function immediately reflecting the changes in the original >> buffer. The latter is avoided in my patch since we commit the changes >> only at the end so the typing during the edit is smooth. > > I think having similar features that work very differently is not a > good thing for Emacs. So I urge you to reconsider your decisions and > make this more like occur-edit-mode. In particular, I don't > understand the difficulty with using the markers and what does it have > to do with the ability of having many Grep buffers. It is not having many Grep buffers but visiting the "original" files unnecessarily that tends to be annoying. I am not sure if there is a scheme to make these visits conservative, I would need to look further. I do not think using track-changes to keep track of the edits will do too much harm since the trickiest part of keeping track of the buffer modifications proper is left to an "external" library. If I'm not wrong, track-changes was introduced to make looking at buffer modifications less error-prone. >> This is what I am aiming for ideally since I am a fan of its interface >> myself (preferring it over xref). The major difference between >> occur-edit-mode and my patch's grep-edit-minor-mode is that it is >> implemented as a minor mode: I chose a minor-mode because all the buffer >> local variables that are required to make the commands from the *grep* >> buffer functional are killed when switching major-modes (so even g >> doesn't work!). We could work around this by marking the relevant >> variables permanent-local but this feels unclean? > > I don't think I understand this difficulty, either: with > occur-edit-mode it is solved by making occur-edit-mode be derived from > occur-mode. Couldn't you do the same with your mode? No because occur-mode makes occur-revert-arguments permanent-local so `g' survives the major-mode changes. For revert-buffer alone, compilation-arguments needs to be marked permanent-local. As it is a part of compile.el, I am not sure if marking it as such is safe. This is why I think having a minor-mode is better. From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 09:50:19 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 13:50:19 +0000 Received: from localhost ([127.0.0.1]:49035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4hgZ-0003lE-Ea for submit@debbugs.gnu.org; Wed, 08 May 2024 09:50:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4hgV-0003l8-SI for 70820@debbugs.gnu.org; Wed, 08 May 2024 09:50:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4hg0-0005EL-Pe; Wed, 08 May 2024 09:49:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=xDssSeiJ7NPXswY5f7mjJu9eiuL2FIxyw6phbqxCo7I=; b=kK3DBXOpTkVh2MLib+yg BWjN8aTrY855r07rjnSbwN9Ij5G/Ui4IjPgjL21SDaqnJKExEe+IeTeB6mzqsuKMGXhuvYPn4Y/yF yatTSG5Pwf3Hqaxp24Lmb8efqXEp2lSXsw7tII7/TrEw1bAljBYXF9aWrJMLgvHxFulBFcV/YldGA bUWyr0LLpYeEmhoos03AfeK62SAKpv5ouWO+6bqtngK2pWlfKZrVH0XVNVt6zVuNAE2l2df/r/50Y K/pbM4jTm5UIZrkrCAvx3gUqhID2qJaE1PL59nvtWw+5RI2B4SxLcs99sXjoObk7dmvsKb7+c6QEK i4tvHw6RqNfOXw==; Date: Wed, 08 May 2024 16:49:41 +0300 Message-Id: <864jb89zwq.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <878r0klcp1.fsf@gmail.com> (message from Visuwesh on Wed, 08 May 2024 17:48:02 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Visuwesh > Cc: 70820@debbugs.gnu.org > Date: Wed, 08 May 2024 17:48:02 +0530 > > [புதன் மே 08, 2024] Eli Zaretskii wrote: > > > I think having similar features that work very differently is not a > > good thing for Emacs. So I urge you to reconsider your decisions and > > make this more like occur-edit-mode. In particular, I don't > > understand the difficulty with using the markers and what does it have > > to do with the ability of having many Grep buffers. > > It is not having many Grep buffers but visiting the "original" files > unnecessarily that tends to be annoying. Why is this annoying? > > I don't think I understand this difficulty, either: with > > occur-edit-mode it is solved by making occur-edit-mode be derived from > > occur-mode. Couldn't you do the same with your mode? > > No because occur-mode makes occur-revert-arguments permanent-local so > `g' survives the major-mode changes. > > For revert-buffer alone, compilation-arguments needs to be marked > permanent-local. As it is a part of compile.el, I am not sure if > marking it as such is safe. This is why I think having a minor-mode is > better. It sounds like a minor issue which shouldn't have such grave consequences. Why do you think making compilation-arguments permanent-local would be a problem? We could ask people who frequently contribute to compile.e land grep.el if they see any problem with doing that. From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 13:38:17 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 17:38:17 +0000 Received: from localhost ([127.0.0.1]:49959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4lFB-0006SL-Db for submit@debbugs.gnu.org; Wed, 08 May 2024 13:38:17 -0400 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]:59416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4lF7-0006S6-G0 for 70820@debbugs.gnu.org; Wed, 08 May 2024 13:38:16 -0400 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-5d8b887bb0cso6959a12.2 for <70820@debbugs.gnu.org>; Wed, 08 May 2024 10:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715189862; x=1715794662; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=oNuWEmm839/sWWiUCvy6WLJqsJdXAjdFb9DbmsZhAwU=; b=CzyWn+F567T4V5JA4jI41f1EKhjM025s7Qo2P1K74Mmp182T+uRm3nmMmJQu41hrgs O8ssaH+WhG5HmPvMSjh+6wjrGf+9xatTcszODnxfxLhklP1GeSXsI1Y5DO63FVgme9kZ lI2di/LzE8WQES+Pw1CJnP2jZG2dfkLm0iMIwUGkuNntYf5j+HJDV3zQMdMlYZLoY7oE faKsHu8+vhboNCVuSqbYAOjICXEkpPJgQFRiooDnVPV4pbcDuXYpVDIWlV3iN93+IliU bRuyhFFNGG+HtXf6JjBOkLdQAPjQ9zaLd8o6HkqvZ2F4zYB4uqScJSeiCkTlg//Ui9tM 97qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715189862; x=1715794662; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oNuWEmm839/sWWiUCvy6WLJqsJdXAjdFb9DbmsZhAwU=; b=mR8FFJzwkcEzP/LDxa/PhvlipYA4uUeNFdwolpxnhr8xQEMAtgSIcgYRNKUxcR+xrV tFIdmGcFOD/SnG2d3LYPn+A8D70yjEVC6ZXmmkNLniw5lCnP5zJpO/S1jV04BYi4yEEt vHYwgL15TD6lQOI3SoRKGanAgQSsfycBWr5nBgop1mjplKi3Iu2mWqVKYi0rGYQhhCmH e2nbeNRgLKxwE7D3+DuZ99gYoFGzGFDBIqAMyXWsKscxgJJllgWPwzNRDkmMvJpOpjui XOJZtuSbPnENIWonBnh5g7iEKTHeImKIayAsB7Ihzocj4JviNKdrPiRnlFSPdVrDXW+U D2sg== X-Gm-Message-State: AOJu0Yyzp5OiHf3ZKcWOUnT1EnIVN0BX/XFkYoiDGCXJaujlzbvA380U fGONwBdoMzOCvEvJ3Ns/HqVh6YUu1q/6+A7X92gYB4GHUcKQRqXn X-Google-Smtp-Source: AGHT+IG7/sK+9s8kgXodFT9MuAjygUoIvKbLFdrggwWZ3VwDG81MBTQ27Cuy/+HzklVT/n8r6S0KRg== X-Received: by 2002:a17:90a:bb0f:b0:2ab:d82e:1afb with SMTP id 98e67ed59e1d1-2b6165a6785mr3516950a91.16.1715189861838; Wed, 08 May 2024 10:37:41 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id 60-20020a17090a09c200b002b624b0161fsm1873027pjo.19.2024.05.08.10.37.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 May 2024 10:37:41 -0700 (PDT) Message-ID: <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> Date: Wed, 8 May 2024 10:37:42 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers Content-Language: en-US To: Eli Zaretskii , Visuwesh References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> From: Jim Porter In-Reply-To: <86ikzoa51h.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/8/2024 4:58 AM, Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 70820@debbugs.gnu.org >> Date: Wed, 08 May 2024 08:52:51 +0530 >> >> Basing it on occur-edit-mode would be a lot more work I think, but I >> understand your concern wrt it being already established and bug-free, >> etc. This was my original plan but I bailed since the occur buffer's >> text-properties has marker objects (IIRC) but I want to avoid using >> markers since having many buffers open was a personal pet peeve of mine, >> along with the slow-typing experience due to occur's >> after-change-function immediately reflecting the changes in the original >> buffer. The latter is avoided in my patch since we commit the changes >> only at the end so the typing during the edit is smooth. > > I think having similar features that work very differently is not a > good thing for Emacs. So I urge you to reconsider your decisions and > make this more like occur-edit-mode. In particular, I don't > understand the difficulty with using the markers and what does it have > to do with the ability of having many Grep buffers. I agree that using markers would probably be a good idea, assuming I'm imagining things correctly. (In particular, this needs to be robust about what happens if you have a file open with some changes already, run grep to find matches in that file, and then modify those matches.) However, I agree with Visuwesh about not committing changes until the end. For the grep case, you could have results in many, many files, including (especially?) ones not open in Emacs yet. By waiting until the end to commit the changes, you don't have to worry about what happen to these files. (The only other options I can think of would be to visit those files, which could require opening hundreds or thousands of files at once; or to immediately change the files on disk, which could ruin those files.) From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 14:43:29 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 18:43:29 +0000 Received: from localhost ([127.0.0.1]:50259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mGG-0007I5-VO for submit@debbugs.gnu.org; Wed, 08 May 2024 14:43:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mGE-0007Hy-R9 for 70820@debbugs.gnu.org; Wed, 08 May 2024 14:43:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4mFj-0007fy-UX; Wed, 08 May 2024 14:42:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BmWIkWYnFlqoYLstgU9hpBfP+DkorvmsgSSRbHmXdVs=; b=AaSAskpExH6f 9u8R4DXRnmcaqWrC/HW00HIXiGpyNPFVPEv+QvB8tGc9MeYOqxGRb3ZFbR4h+N7zm/kXvrQ/sW7cP al9zsMeM7+590jZ7Y8PYU3edYXPNNi9uh9u+ENixVz6fgFJGB6IsUC9OSqg2Gh5bJo2LSUsAw8G0C 0ktHVMVQL1pVVUa7UuSPRrIOUYIX9QUvCEyYMFjZvkCi9jPx4BGf9GY+waqZ1SQxbMGzkDNV2Q3z/ 1N4ZGXRIO3MKHoO214VicEomSc9nuFcImUl0Cozi4ITqqYEoMT1YYwLr8VFB+aVaDHtlvpa813fOs JE29JAU7zwC+mQPEnnoIZA==; Date: Wed, 08 May 2024 21:42:50 +0300 Message-Id: <86ttj887rp.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> (message from Jim Porter on Wed, 8 May 2024 10:37:42 -0700) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 8 May 2024 10:37:42 -0700 > Cc: 70820@debbugs.gnu.org > From: Jim Porter > > However, I agree with Visuwesh about not committing changes until the > end. For the grep case, you could have results in many, many files, > including (especially?) ones not open in Emacs yet. I don't see why. Grep shows all the matches in one file before it goes to the next. So each time you edit the matches, you have just one file to care about, right? Or what am I missing? From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 15:20:18 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 19:20:18 +0000 Received: from localhost ([127.0.0.1]:50424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mpt-0001wv-Lr for submit@debbugs.gnu.org; Wed, 08 May 2024 15:20:18 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:55450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mpq-0001wn-Sn for 70820@debbugs.gnu.org; Wed, 08 May 2024 15:20:16 -0400 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6edc61d0ff6so137309b3a.2 for <70820@debbugs.gnu.org>; Wed, 08 May 2024 12:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715195983; x=1715800783; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=1trAe2O73xJOD/6WfBvTE2XoOG6/rFFgg/flbKMKqCk=; b=c4JOMqjnRZFaZRJlTj6zjNymG3rYLpB4/a/ySyAT6O+oz29YGVAaLK7YA5znO4AWN4 jGTQj/cdotsWZgzDhFmas8Sy7Gwk6OgQu/QpcKoqm2AnoOjP8qIELGgSFN34DcEuRcw+ Z0DztYdtxja66ScFE3STOWbg53SFh8qwvKn0MRL4UXNSL7mEfTHbvFXyLR9RF2N/SG5Q wHEV61VgTTN0bqCKMsfipda3DlPZEhYLE0gEiZvjUb4GvRuByrWs8H1bil/Q5q2MKqMn eC1Q1q61WeYllL3/1tlPOC8UK8gJCy3O9bSTfZXKO6/J3wyJ9G39n6B6pOIMyPBGUkqA X0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715195983; x=1715800783; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1trAe2O73xJOD/6WfBvTE2XoOG6/rFFgg/flbKMKqCk=; b=H0Pt8kV+b2aDPFsxoVH6KyhZUGONifVNo8Rz7SY5oVw624aHJT2LZvaeJhs38kD0Hu 8Bhzyx5RSLMDJl/UtR8dlZPZQuddq6TDwVflLanja3rmHhq+ATWYU+U1Jn2FjkSaPf3R Sqa7+6hnWexW8NN8D7+gJoBq/5mU5GfkQWwT0J6rSpb8Ya70o+cKf6oF3sWPrgXZ0c1C /JABIjpV2elIzEGHv6csdgyTCIjGr+YiMLvxJ6oKR1N+oYuFqLRJWoBA2woyOXX01VT4 /D95dj+1NvKS8A2gJoaCVblr5Ee0jomNGVzAgC6ePOg48lR/Wra/SaCKg1HZgXIFB3l0 qzxw== X-Gm-Message-State: AOJu0YyoH+s1hWzUvdYFs5mPHqYF4mPeFeojtMTDllL/boYKyEuoovfF /BlgFsvb/dD0lo1YHUYKO3cAkbKDxpRwsVuzcm/Zkw4LX7JKN00R X-Google-Smtp-Source: AGHT+IE2xu/CMvF4Y/teUWtdZAbRbrmQniJuKxl279ixZT7cuTlZlCGscYhbzKAm5HXOpVtk4FdKsA== X-Received: by 2002:a05:6a00:6309:b0:6ed:e1c:102e with SMTP id d2e1a72fcca58-6f49c2a38d4mr3429686b3a.24.1715195983099; Wed, 08 May 2024 12:19:43 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id u10-20020aa7838a000000b006f456b23f90sm8343399pfm.31.2024.05.08.12.19.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 May 2024 12:19:42 -0700 (PDT) Message-ID: Date: Wed, 8 May 2024 12:19:41 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers Content-Language: en-US To: Eli Zaretskii References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> <86ttj887rp.fsf@gnu.org> From: Jim Porter In-Reply-To: <86ttj887rp.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/8/2024 11:42 AM, Eli Zaretskii wrote: >> Date: Wed, 8 May 2024 10:37:42 -0700 >> Cc: 70820@debbugs.gnu.org >> From: Jim Porter >> >> However, I agree with Visuwesh about not committing changes until the >> end. For the grep case, you could have results in many, many files, >> including (especially?) ones not open in Emacs yet. > > I don't see why. Grep shows all the matches in one file before it > goes to the next. So each time you edit the matches, you have just > one file to care about, right? Or what am I missing? One of the ways I use wgrep is that I first search across my entire repo for some matching lines. Then, I activate wgrep and use query-replace to mass-change all those lines. (I use the "!" key with query-replace to tell it to change everything without prompting once I'm happy with my command.) This frequently involves me changing dozens of files at once even for relatively small projects. Maybe there are better ways to perform this sort of action, but I find this method very useful because it shows me the steps along the way so that I can check my work before I commit to changing all those lines. I also don't have to manually step through each change once I'm happy with what I see. From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 15:23:34 2024 Received: (at 70820) by debbugs.gnu.org; 8 May 2024 19:23:34 +0000 Received: from localhost ([127.0.0.1]:50440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mt4-0001zW-Cj for submit@debbugs.gnu.org; Wed, 08 May 2024 15:23:34 -0400 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]:61850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4mt2-0001z9-NP for 70820@debbugs.gnu.org; Wed, 08 May 2024 15:23:33 -0400 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-5ac61cf3fffso50554eaf.3 for <70820@debbugs.gnu.org>; Wed, 08 May 2024 12:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715196181; x=1715800981; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=hdhL2AwpONAFHbudDa9zJ4DsjvW5i3ZjrodhzyaidWM=; b=VgQSARpniCvWUqRoojlZBZ2MDtLdeI5AQghJgrDNizHS3LFqJ2S9hUtfDoL3Chz63i e6mS0rZV9re+1wa9jhF99p2lxbICHfFP+aJDZl1mGwVG+t8wS2RDN/mXhUE7z84UXozY 335iV1mnYPIfmjWYGjUc1aO/ytdZcYOMXyhhzuoY4HUY+DKuDa/bC0ID8x5oCWqbCEn+ 45KrQnhy9v7ulmk+96awWHAfLL3HHpe5Cz5HIESsVO/jnMg4Z5ceZBsmSBGfVIoItRGY 0ib7DcB1TRMdamUscgNEeuL4xn4sjSLEBDI1wlIwSsc95QYi1xEhcEP+VUyR2RmU5VZ6 svSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715196181; x=1715800981; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hdhL2AwpONAFHbudDa9zJ4DsjvW5i3ZjrodhzyaidWM=; b=cAxQ0ZWoENHAF25lvztdLH2f1SR8n4C2Mh7WGzOyZbhLR78cxKuB2fNC8Lr/BU6E/w wCn9stkxHOXnXJ3IBA9sPzm36a0eu8FwuxOsWh9v+8A5px/h7sAXYPndIOve9zInbnjI TFBfXncKJh2aseCCgPcmCWeCFOTHKF1+R+nLYYDugOD1I3sdoAk2A3Qwe9dGB5gaKPYl VLAh34PmmMNEXMi5qSiQ4hzUatGBR34Ko3SxcYaY1wdeT/fMFZvVGR4REOMqyIRF9MQL 5nFssd4SYqbih0zWNnL+uG1gM2p8os5MXGu8Hr994icay2bsASWpDEkrCWzIi6noRedI KT+w== X-Gm-Message-State: AOJu0YwlGk0IGjvVoN9PMgAMAEol2v7g4G4J0Si1oi4NX4GbnLrmwHie HCfDqQTZuhEkVO9YKy8gk19cdfKoYQuCIOcLxVrqPz0iXgjGDoj7 X-Google-Smtp-Source: AGHT+IHBUUzw3so0MQypShS/QgWXo1ERyzaww/p4d+EOe8kQNAVMZDdPn2nVASr6031r1WNgf8wKww== X-Received: by 2002:a05:6358:88c:b0:189:9aa2:c25d with SMTP id e5c5f4694b2df-192d377886amr402974955d.20.1715196181325; Wed, 08 May 2024 12:23:01 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id i191-20020a6387c8000000b005df58c83e89sm11916746pge.84.2024.05.08.12.23.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 May 2024 12:23:00 -0700 (PDT) Message-ID: Date: Wed, 8 May 2024 12:23:00 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers Content-Language: en-US From: Jim Porter To: Eli Zaretskii References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> <86ttj887rp.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/8/2024 12:19 PM, Jim Porter wrote: > Maybe there are better ways to perform this sort of action, but I find > this method very useful because it shows me the steps along the way so > that I can check my work before I commit to changing all those lines. I > also don't have to manually step through each change once I'm happy with > what I see. Oh, one thing I forgot to add about this: If I perform this action and the changed lines in my grep buffer don't look right, I can just exit wgrep without saving the changes and try again. From debbugs-submit-bounces@debbugs.gnu.org Thu May 09 00:42:03 2024 Received: (at 70820) by debbugs.gnu.org; 9 May 2024 04:42:03 +0000 Received: from localhost ([127.0.0.1]:52842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4vbW-00081u-Rd for submit@debbugs.gnu.org; Thu, 09 May 2024 00:42:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4vbT-00081X-Mo for 70820@debbugs.gnu.org; Thu, 09 May 2024 00:42:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4vay-0007Gk-Ff; Thu, 09 May 2024 00:41:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RrnrgYSIfXGqq7l6G6dlDBxKtPt2ofJfATOdKXCnpK0=; b=HA6tViSkBlYT a9PpoC2eoRIpLPAzcA7F5to+yPQZELVJ4+yzCSmfR+cMRZtX/j5V9SZBNPka839MNqLrJr8kvaI3d H9qgU8HURnQ2hG31tFz0YagA8UMakddbt+xJns4GoS2ZKBn5bGCxtAyALnJT5sHdYy6/PgUG4CQaA ZmxqkppCgvN9CQstFWs7VTA6TcnRLweHg9itQmxmef/PDqCOXRnJVo45238Y5Cj3sgIKR2+wbmLU8 81H/l2nQOeYdJ8zdFH0aKDZpZ18ChtgZ4SC7GisJg9s4dpz87/C3pbqs2mo/74Jg+11KpaH8tzOoh tY3mE6r0Dbjhk/yVuqTKyQ==; Date: Thu, 09 May 2024 07:41:25 +0300 Message-Id: <86o79f8umi.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: (message from Jim Porter on Wed, 8 May 2024 12:23:00 -0700) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> <86ttj887rp.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 8 May 2024 12:23:00 -0700 > From: Jim Porter > Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com > > On 5/8/2024 12:19 PM, Jim Porter wrote: > > Maybe there are better ways to perform this sort of action, but I find > > this method very useful because it shows me the steps along the way so > > that I can check my work before I commit to changing all those lines. I > > also don't have to manually step through each change once I'm happy with > > what I see. > > Oh, one thing I forgot to add about this: If I perform this action and > the changed lines in my grep buffer don't look right, I can just exit > wgrep without saving the changes and try again. We are not going to remove wgrep, so if you prefer that way of operating on grep hits, you still can. Here we are discussing a new feature, and it doesn't have to be bit-by-bit compatible to all the similar packages out there. But it does need to make sense as part of Emacs, if it is part of grep.el. From debbugs-submit-bounces@debbugs.gnu.org Thu May 09 06:33:14 2024 Received: (at 70820) by debbugs.gnu.org; 9 May 2024 10:33:14 +0000 Received: from localhost ([127.0.0.1]:54511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s515O-0006Ad-8v for submit@debbugs.gnu.org; Thu, 09 May 2024 06:33:14 -0400 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:45085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s515K-0006AX-EV for 70820@debbugs.gnu.org; Thu, 09 May 2024 06:33:12 -0400 Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-1edf506b216so4894305ad.2 for <70820@debbugs.gnu.org>; Thu, 09 May 2024 03:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715250758; x=1715855558; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=i17DLaGMRRiWTJ5ycLkXm4W63+7W8/3qJK4Eq6cKqRo=; b=YGjsxh71I5mQ0NA/4v+7Ww0dJrcMLCsGeKHN9mWFpTOoqIDJC52AHDocrp9EPbLyZz r1t1Ffm8i7bu5SwFkQpEHqLpghJxj/P1Ik8I8ysIaYdFnp4y+Wn5ymWDG987K1CnZHKm Sj9GbGjdpQMuQzTKF/yK/8Fym7SxlEiaVqyO6QUct+tLQbEEOzGO2nsNhKla5w7ZkugQ sdYE6Lwe3m2lTf1p32zk+wDShKyBO8WkDhpiMrvKirU0E+nqkPOVklZIubWRVRJ83Qd/ 8xsfvpK9uQeVDJwZ3LmV5jKseEB+A2xnGsbp0ieo80vKVVyrvZQ6DyEIotmQgWEzz/ak u+bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715250758; x=1715855558; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=i17DLaGMRRiWTJ5ycLkXm4W63+7W8/3qJK4Eq6cKqRo=; b=cReBaMVlqT2eFaEghfwELCMvFN/fadRQuidVZLoZeHi+NYDrqIAW/0Aw4KqxG2xWbl AjshSy8uwQAKp+i44O7WJ+GDJ+CMY7TDFO235m703y0CJq0/VjDcmiwMg+49re8ZeFwY jFdRUcI+cvEGjOBQX1WlL/PffE4iWAtoLDAq5JnEF5/NtipnJD4dxGYBGFyehogjrZeO 1ztfJY/qrRw6fjn4+ugA0cfaPNi1jFbndswHPKO1GYeb5Z13KFAp90Ug/bBImf5wMOui XEoAwNrI6B9sBI/86FaQ6oTnxGD34+YfOQ1rv0w8YXowtd2fITVxX57WftFOFMY8aAzy f3/w== X-Gm-Message-State: AOJu0YwlRUTvBupCslSW4I6+Z9PNwyIJnwsK6RxvPIQolmlx4i0tGSmB V96T4v0uslZdLoBi8LGmqZEPJ48JZs8vSxy3Sw00aJImmGjDMQht X-Google-Smtp-Source: AGHT+IGjtN+dh/VQ8J/aJfXA2/lab6ubZDMqPp7aUbb13DviW6RxsBZH/2duRiCWQkjX8FmYlYqmHQ== X-Received: by 2002:a17:902:cecc:b0:1e5:8175:4968 with SMTP id d9443c01a7336-1eeb03a4865mr63160335ad.9.1715250758549; Thu, 09 May 2024 03:32:38 -0700 (PDT) Received: from localhost ([49.204.138.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0c25698csm11093235ad.305.2024.05.09.03.32.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 May 2024 03:32:38 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <864jb89zwq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 May 2024 16:49:41 +0300") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> Date: Thu, 09 May 2024 16:02:35 +0530 Message-ID: <87wmo3jmws.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.6 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [புதன் மே 08, 2024] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 70820@debbugs.gnu.org >> Date: Wed, 08 May 2024 17:48:02 +0530 >> >> [புதன் மே 08, 2024] Eli Zaretskii wrote: >> >> > I think having similar features that work [...] Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [49.204.138.192 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:642 listed in] [list.dnswl.org] X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [புதன் மே 08, 2024] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 70820@debbugs.gnu.org >> Date: Wed, 08 May 2024 17:48:02 +0530 >> >> [புதன் மே 08, 2024] Eli Zaretskii wrote: >> >> > I think having similar features that work [...] Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:642 listed in] [list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [49.204.138.192 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=AE=E0=AF=87 08, 2024]= Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 70820@debbugs.gnu.org >> Date: Wed, 08 May 2024 17:48:02 +0530 >>=20 >> [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=AE=E0=AF=87 08, 20= 24] Eli Zaretskii wrote: >>=20 >> > I think having similar features that work very differently is not a >> > good thing for Emacs. So I urge you to reconsider your decisions and >> > make this more like occur-edit-mode. In particular, I don't >> > understand the difficulty with using the markers and what does it have >> > to do with the ability of having many Grep buffers. >>=20 >> It is not having many Grep buffers but visiting the "original" files >> unnecessarily that tends to be annoying. > > Why is this annoying? > >> > I don't think I understand this difficulty, either: with >> > occur-edit-mode it is solved by making occur-edit-mode be derived from >> > occur-mode. Couldn't you do the same with your mode? >>=20 >> No because occur-mode makes occur-revert-arguments permanent-local so >> `g' survives the major-mode changes. >>=20 >> For revert-buffer alone, compilation-arguments needs to be marked >> permanent-local. As it is a part of compile.el, I am not sure if >> marking it as such is safe. This is why I think having a minor-mode is >> better. > > It sounds like a minor issue which shouldn't have such grave > consequences. Why do you think making compilation-arguments > permanent-local would be a problem? We could ask people who > frequently contribute to compile.e land grep.el if they see any > problem with doing that. It feels like a potential far-fetching change. But in any case, I will give a shot at recreating the required markers, etc. for occur-after-change-function to work. Will send a patch once I have a working prototype. From debbugs-submit-bounces@debbugs.gnu.org Thu May 09 12:15:26 2024 Received: (at 70820) by debbugs.gnu.org; 9 May 2024 16:15:26 +0000 Received: from localhost ([127.0.0.1]:56101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s56QX-00068s-OW for submit@debbugs.gnu.org; Thu, 09 May 2024 12:15:26 -0400 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:52654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s56QU-0005if-4r for 70820@debbugs.gnu.org; Thu, 09 May 2024 12:15:23 -0400 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6ee13f19e7eso975467b3a.1 for <70820@debbugs.gnu.org>; Thu, 09 May 2024 09:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715271290; x=1715876090; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=mVCBOg0tfcCbyHIwc/rUvXGUgzrIzwV+FRg1BGslOXY=; b=MHrFRQWBlwdzC5ym94UceeCUK2B5gqCCbJZDi0faaht/oNnrAnNYbndYRyDwSN3iWs E/bALk+cUqf9yI6AhjFEay2Qfh+I233U6tQg899lSkYrbyh9xCxDVTKzEV7dlGnunU9Q D9MdK7SAhsOh26Q/bPCt8LfjvC1TE80jpVAhz6R6nTy3yAkTZnDhvSxVdQvZ9fc13VBx S0iPcxwYITJYbq0q0NA8/nOcAWugDmgAt6HN60lrnapxDf1lJq/U3BqpTgygdwoerHJD 9UWViye3LtIlGiH13ts4tev84AA3XLM95bMMbv3tmGGTXGMjHgZeNZaNkR9piV9GZST4 kY3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715271290; x=1715876090; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mVCBOg0tfcCbyHIwc/rUvXGUgzrIzwV+FRg1BGslOXY=; b=Si23eARcSVgq+SweLsfFPonfmBJWZIft3Kv2Ed2KkUiWPrzaL6dlOYztJnwmY5NqYQ eACcVeo4xrC/MXULh+/KBPbOGVjfCmQtLDZmguPTKmCigkb08Cwb42F6UGYwu7RIPgx8 QJbV2h47zZk4+EYNJj4klrewB+MaLX6KzvzL9szSb66fNqniNowQviUoL0BpHblimcaA WU3U0sLPtjVM9iV069vAuzJE2QdFw2Mi2TMlnGrqH3UHva5znp8aUpoPuhpV7hBaQTFH GXpnIsPBdW7kpRfj/es54VZGU2fhyBmzsk69AsDUSUkc48gXiZ11zh17cUfrmS2o9zmN MM/w== X-Gm-Message-State: AOJu0Yy7xK4zcFD76t6e8XT628qgTSBxVBU3QMzerdSPqvnx/XU99Iaq ndUaUUGAtvntDkltvRHUT+kbYRUtD3CUdUvoVuxEURvaJH1Is+rUBFR8Ow== X-Google-Smtp-Source: AGHT+IG9rCk2RsvNKL35IZeoqLpwwhkglZPfQPHiJmIee6MTvP7j4DZmROH9r/cxdNGo1npbB/paNQ== X-Received: by 2002:a05:6a21:1f28:b0:1af:4fd7:6c6f with SMTP id adf61e73a8af0-1afde0e6179mr197184637.35.1715271290208; Thu, 09 May 2024 09:14:50 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id 41be03b00d2f7-63411904351sm1500563a12.91.2024.05.09.09.14.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 May 2024 09:14:49 -0700 (PDT) Message-ID: <728e5a0e-8437-b4c0-5bc6-7eaac83aafec@gmail.com> Date: Thu, 9 May 2024 09:14:50 -0700 MIME-Version: 1.0 Subject: Re: bug#70820: [PATCH] Editable grep buffers Content-Language: en-US To: Eli Zaretskii References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <434a4b40-900a-6e24-8e8a-9c67a618fb11@gmail.com> <86ttj887rp.fsf@gnu.org> <86o79f8umi.fsf@gnu.org> From: Jim Porter In-Reply-To: <86o79f8umi.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 5/8/2024 9:41 PM, Eli Zaretskii wrote: > We are not going to remove wgrep, so if you prefer that way of > operating on grep hits, you still can. Here we are discussing a new > feature, and it doesn't have to be bit-by-bit compatible to all the > similar packages out there. But it does need to make sense as part of > Emacs, if it is part of grep.el. I certainly don't expect this facility to be identical to wgrep (I didn't bother mentioning the bits of wgrep that I'm not interested in), but I think it does have some very good ideas too. For the case of only making changes at the end, I mainly wanted to express my agreement with Visuwesh's initial implementation and to explain how wgrep's similar behavior makes certain tasks easier. From debbugs-submit-bounces@debbugs.gnu.org Sun May 12 00:46:45 2024 Received: (at 70820) by debbugs.gnu.org; 12 May 2024 04:46:45 +0000 Received: from localhost ([127.0.0.1]:52287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s616i-0002RI-F3 for submit@debbugs.gnu.org; Sun, 12 May 2024 00:46:45 -0400 Received: from mail-oa1-f68.google.com ([209.85.160.68]:45547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s616g-0002R8-8j for 70820@debbugs.gnu.org; Sun, 12 May 2024 00:46:43 -0400 Received: by mail-oa1-f68.google.com with SMTP id 586e51a60fabf-23ee34c33ceso2214319fac.3 for <70820@debbugs.gnu.org>; Sat, 11 May 2024 21:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715489136; x=1716093936; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Z7hIOErRZadE8fKeifUV4vxdT+yIUPa/Wbv6ZJtD/0M=; b=VU267vap+ArxUMlL7nipKkeS3AFB7EjxfH3cSfzwGGE6HSkSm2EF5A1OIVBU1Khoo7 OnHxVQGtiMYajO67Ny7YtNcSe+I8sy7f0niueUy0cf3VY9AB1BXUHN1ptNR4U7FeKhbE Gc/LcID3OseL0tX54Gk/4Yvdp/FNmvRLFlxf1VLvAcHK0Xd1LtHPBUsuGbOnwtc92d0w YtCWbJNXSK+VRgQpszRVEAxKYUTD+OYVxkFiUXy6LJ5+c3FR91qDaKz6Efs9NBeqOC6B Vg+gdDjktppffIQPCIpI1lRLoXQBcRDfMyCfpwt/V248rKpsLYgRwsuSYefuRvuaSMZd mFkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715489136; x=1716093936; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Z7hIOErRZadE8fKeifUV4vxdT+yIUPa/Wbv6ZJtD/0M=; b=SsXgp383N+1d32En/O7hjeLZIpdwHlpqPPIn3PfVKwXjixWbKKgsEMhoRXU54z6xLD 7jGljQKlL/QYTL6+1EK0Ln39OPf5BdCIy9uhva9Abq7HAFUfZeZwl8aN3uFdCrmfVKLB TQkGAwkOr7bHQEQfN2wF23IKzdJxkXVDqgm831SiyGIx7rfY22ZOwRWcmZD+cUsp8OLo 8wIeOQQszb5SDCWAcWK//PtUe5EA5nCEi9gNTPtIDu2z0he2LeKx0vGJvvSnBkoQB1W7 lSqnBPgD7eos1n0PdfM+a2opSIiUlsSckxiO8Lv5MOqO9nHQcZr5E3KBlceYgdxPVtPQ v4Yw== X-Gm-Message-State: AOJu0Yx9XEFmkedvwKGfdhow+XZBWePhPYDqntBF22DuIPYMco8EE24N bibAUgYKcDSpMIukpBSWiizEMgFZO8fQJhtNZZOQDMuY14p8ny5y X-Google-Smtp-Source: AGHT+IGV5fCKw1rFoIEdlP2888KLrYtLBFimNdCxyrQ3WS+p2mooeJ22j7qiy14WFt8PMrADSA0L/g== X-Received: by 2002:a05:6870:5491:b0:23c:ed7f:d9d5 with SMTP id 586e51a60fabf-24172c5d4f8mr8326004fac.35.1715489136493; Sat, 11 May 2024 21:45:36 -0700 (PDT) Received: from localhost ([49.205.82.119]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4eccc3b91sm2128837b3a.66.2024.05.11.21.45.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 May 2024 21:45:35 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <87wmo3jmws.fsf@gmail.com> (Visuwesh's message of "Thu, 09 May 2024 16:02:35 +0530") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> Date: Sun, 12 May 2024 10:15:33 +0530 Message-ID: <87fruny6xe.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=B5=E0=AE=BF=E0=AE=AF=E0=AE=BE=E0=AE=B4=E0=AE=A9=E0=AF=8D =E0=AE=AE= =E0=AF=87 09, 2024] Visuwesh wrote: >>> > I don't think I understand this difficulty, either: with >>> > occur-edit-mode it is solved by making occur-edit-mode be derived from >>> > occur-mode. Couldn't you do the same with your mode? >>>=20 >>> No because occur-mode makes occur-revert-arguments permanent-local so >>> `g' survives the major-mode changes. >>>=20 >>> For revert-buffer alone, compilation-arguments needs to be marked >>> permanent-local. As it is a part of compile.el, I am not sure if >>> marking it as such is safe. This is why I think having a minor-mode is >>> better. >> >> It sounds like a minor issue which shouldn't have such grave >> consequences. Why do you think making compilation-arguments >> permanent-local would be a problem? We could ask people who >> frequently contribute to compile.e land grep.el if they see any >> problem with doing that. > > It feels like a potential far-fetching change. But in any case, I will > give a shot at recreating the required markers, etc. for > occur-after-change-function to work. Will send a patch once I have a > working prototype. OK, please find attached patch. I am still not using a major-mode because of the change-major-mode-hook in compilation-setup: (add-hook 'change-major-mode-hook #'compilation--remove-properties nil = t) that strips off all the text-properties. And there seem to be too many important local variables that is set up by both grep.el and compile.el so I think it is easier to use a minor-mode here. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=grep-edit.diff diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index b18eb81fee1..867ebc92d75 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -2829,6 +2829,53 @@ compilation-find-buffer (current-buffer) (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))) +(defun compilation--update-markers (loc marker screen-columns first-column) + "Update markers in LOC, and set MARKER to location pointed by LOC. +SCREEN-COLUMNS and FIRST-COLUMN are the value of +`compilation-error-screen-columns' and `compilation-first-column' to use +if they are not set buffer-locally in the target buffer." + (with-current-buffer + (if (bufferp (caar (compilation--loc->file-struct loc))) + (caar (compilation--loc->file-struct loc)) + (apply #'compilation-find-file + marker + (caar (compilation--loc->file-struct loc)) + (cadr (car (compilation--loc->file-struct loc))) + (compilation--file-struct->formats + (compilation--loc->file-struct loc)))) + (let ((screen-columns + ;; Obey the compilation-error-screen-columns of the target + ;; buffer if its major mode set it buffer-locally. + (if (local-variable-p 'compilation-error-screen-columns) + compilation-error-screen-columns screen-columns)) + (compilation-first-column + (if (local-variable-p 'compilation-first-column) + compilation-first-column first-column)) + (last 1)) + (save-restriction + (widen) + (goto-char (point-min)) + ;; Treat file's found lines in forward order, 1 by 1. + (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) + (when (car line) ; else this is a filename without a line# + (compilation-beginning-of-line (- (car line) last -1)) + (setq last (car line))) + ;; Treat line's found columns and store/update a marker for each. + (dolist (col (cdr line)) + (if (compilation--loc->col col) + (if (eq (compilation--loc->col col) -1) + ;; Special case for range end. + (end-of-line) + (compilation-move-to-column (compilation--loc->col col) + screen-columns)) + (beginning-of-line) + (skip-chars-forward " \t")) + (if (compilation--loc->marker col) + (set-marker (compilation--loc->marker col) (point)) + (setf (compilation--loc->marker col) (point-marker))) + ;; (setf (compilation--loc->timestamp col) timestamp) + )))))) + ;;;###autoload (defun compilation-next-error-function (n &optional reset) "Advance to the next error message and visit the file where the error was. @@ -2838,7 +2885,6 @@ compilation-next-error-function (setq compilation-current-error nil)) (let* ((screen-columns compilation-error-screen-columns) (first-column compilation-first-column) - (last 1) (msg (compilation-next-error (or n 1) nil (or compilation-current-error compilation-messages-start @@ -2850,9 +2896,9 @@ compilation-next-error-function (user-error "No next error")) (setq compilation-current-error (point-marker) overlay-arrow-position - (if (bolp) - compilation-current-error - (copy-marker (line-beginning-position)))) + (if (bolp) + compilation-current-error + (copy-marker (line-beginning-position)))) ;; If loc contains no marker, no error in that file has been visited. ;; If the marker is invalid the buffer has been killed. ;; So, recalculate all markers for that file. @@ -2869,46 +2915,7 @@ compilation-next-error-function ;; (equal (compilation--loc->timestamp loc) ;; (setq timestamp compilation-buffer-modtime))) ) - (with-current-buffer - (if (bufferp (caar (compilation--loc->file-struct loc))) - (caar (compilation--loc->file-struct loc)) - (apply #'compilation-find-file - marker - (caar (compilation--loc->file-struct loc)) - (cadr (car (compilation--loc->file-struct loc))) - (compilation--file-struct->formats - (compilation--loc->file-struct loc)))) - (let ((screen-columns - ;; Obey the compilation-error-screen-columns of the target - ;; buffer if its major mode set it buffer-locally. - (if (local-variable-p 'compilation-error-screen-columns) - compilation-error-screen-columns screen-columns)) - (compilation-first-column - (if (local-variable-p 'compilation-first-column) - compilation-first-column first-column))) - (save-restriction - (widen) - (goto-char (point-min)) - ;; Treat file's found lines in forward order, 1 by 1. - (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) - (when (car line) ; else this is a filename without a line# - (compilation-beginning-of-line (- (car line) last -1)) - (setq last (car line))) - ;; Treat line's found columns and store/update a marker for each. - (dolist (col (cdr line)) - (if (compilation--loc->col col) - (if (eq (compilation--loc->col col) -1) - ;; Special case for range end. - (end-of-line) - (compilation-move-to-column (compilation--loc->col col) - screen-columns)) - (beginning-of-line) - (skip-chars-forward " \t")) - (if (compilation--loc->marker col) - (set-marker (compilation--loc->marker col) (point)) - (setf (compilation--loc->marker col) (point-marker))) - ;; (setf (compilation--loc->timestamp col) timestamp) - )))))) + (compilation--update-markers loc marker screen-columns first-column)) (compilation-goto-locus marker (compilation--loc->marker loc) (compilation--loc->marker end-loc)) (setf (compilation--loc->visited loc) t))) diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 657349cbdff..1b1de0ef77d 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -295,6 +295,8 @@ grep-mode-map (define-key map "}" #'compilation-next-file) (define-key map "\t" #'compilation-next-error) (define-key map [backtab] #'compilation-previous-error) + + (define-key map "e" #'grep-edit-minor-mode) map) "Keymap for grep buffers. `compilation-minor-mode-map' is a cdr of this.") @@ -1029,6 +1031,66 @@ grep command-args) #'grep-mode)) +(defun grep-edit--prepare-buffer () + "Mark relevant regions read-only, and add relevant occur text-properties." + (save-excursion + (goto-char (point-min)) + (let ((inhibit-read-only t) + (dummy (make-marker)) + match) + (while (setq match (text-property-search-forward 'compilation-annotation)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t))) + (goto-char (point-min)) + (while (setq match (text-property-search-forward 'compilation-message)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t occur-prefix t)) + (let ((loc (compilation--message->loc (prop-match-value match))) + m) + ;; Update the markers if necessary. + (unless (and (compilation--loc->marker loc) + (marker-buffer (compilation--loc->marker loc))) + (compilation--update-markers loc dummy compilation-error-screen-columns compilation-first-column)) + (setq m (compilation--loc->marker loc)) + (add-text-properties (prop-match-beginning match) + (or (next-single-property-change + (prop-match-end match) + 'compilation-message) + (1+ (pos-eol))) + `(occur-target ((,m . ,m))))))))) + +(defvar grep-edit-minor-mode-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map text-mode-map) + (define-key map (kbd "C-c C-c") #'grep-edit-save-changes) + map) + "Keymap for `grep-edit-minor-mode'.") + +(define-minor-mode grep-edit-minor-mode + "Minor mode for editing *grep* buffers. +In this mode, changes to the *grep* buffer are applied to the +originating files." + :lighter " Grep-Edit" + (if (null grep-edit-minor-mode) + (progn + (setq buffer-read-only t) + (buffer-disable-undo) + (remove-hook 'after-change-functions #'occur-after-change-function t) + (use-local-map grep-mode-map)) + (grep-edit--prepare-buffer) + (use-local-map grep-edit-minor-mode-map) + (setq buffer-read-only nil) + (buffer-enable-undo) + (add-hook 'after-change-functions #'occur-after-change-function nil t) + (message (substitute-command-keys + "Editing: \\[grep-edit-save-changes] to return to Grep mode.")))) + +(defun grep-edit-save-changes () + "Switch back to Grep mode." + (interactive) + (when grep-edit-minor-mode + (message "Switching to Grep mode.") + (grep-edit-minor-mode -1))) ;;;###autoload (defun grep-find (command-args) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 05:28:38 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 09:28:39 +0000 Received: from localhost ([127.0.0.1]:60575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8GMo-0000Ij-GO for submit@debbugs.gnu.org; Sat, 18 May 2024 05:28:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33314) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8GMn-0000IZ-7a for 70820@debbugs.gnu.org; Sat, 18 May 2024 05:28:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8GMe-0004tq-5P; Sat, 18 May 2024 05:28:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=JkPQYkrHAwx1vRCwpWEvR8LkyFTa7kJlEpWLIbhYi8w=; b=Zk+h6IO1fujTUE7/+ThT yOQ3NcAvxKa8v8+1JkVZt2kt3gp/afakywSy/m3tDNJwOMA7Qn70d/JEXgDgZJd5UEAEqcw29+ckb y48HzJGRXGn6Tq3zm0NTqeoq4Khz3H/M8RqrA+40ZPDhcVtIEAtcSoT8Cs+/1irgG63Z/ztuJCVlK dy1cfvhjBIk/7ZVXkd8tuUSo/m5fitVEyw/YKF8g2a6cy4OZV8I9FeNW0aHMt1GD5OqZ7nFq1j1z4 t/J4oMY+/y73rCP+/fvw2bb6n6PBFbjU+G2+JB4+GwB2NSf6HheqI/+N5WKyqUnFOMuw01dw1sQWA uHyncAs3MmqblA==; Date: Sat, 18 May 2024 12:28:24 +0300 Message-Id: <86le47eafb.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh , Stefan Monnier In-Reply-To: <87fruny6xe.fsf@gmail.com> (message from Visuwesh on Sun, 12 May 2024 10:15:33 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Visuwesh > Cc: 70820@debbugs.gnu.org > Date: Sun, 12 May 2024 10:15:33 +0530 > > [வியாழன் மே 09, 2024] Visuwesh wrote: > > >>> > I don't think I understand this difficulty, either: with > >>> > occur-edit-mode it is solved by making occur-edit-mode be derived from > >>> > occur-mode. Couldn't you do the same with your mode? > >>> > >>> No because occur-mode makes occur-revert-arguments permanent-local so > >>> `g' survives the major-mode changes. > >>> > >>> For revert-buffer alone, compilation-arguments needs to be marked > >>> permanent-local. As it is a part of compile.el, I am not sure if > >>> marking it as such is safe. This is why I think having a minor-mode is > >>> better. > >> > >> It sounds like a minor issue which shouldn't have such grave > >> consequences. Why do you think making compilation-arguments > >> permanent-local would be a problem? We could ask people who > >> frequently contribute to compile.e land grep.el if they see any > >> problem with doing that. > > > > It feels like a potential far-fetching change. But in any case, I will > > give a shot at recreating the required markers, etc. for > > occur-after-change-function to work. Will send a patch once I have a > > working prototype. > > OK, please find attached patch. I am still not using a major-mode > because of the change-major-mode-hook in compilation-setup: > > (add-hook 'change-major-mode-hook #'compilation--remove-properties nil t) > > that strips off all the text-properties. And there seem to be too many > important local variables that is set up by both grep.el and compile.el > so I think it is easier to use a minor-mode here. Any reason not to modify compilation--remove-properties not to remove all the text properties in this particular case? AFAIU, change-major-mode-hook is run by kill-all-local-variables, which the major mode should call, so just before that you could remove compilation--remove-properties from change-major-mode-hook, and that would disable this face removal, no? (I must admit that unconditionally removing the faces is not very friendly on the part of compilation-mode. Stefan, are there better ways of doing that, perhaps?) From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 09:24:05 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 13:24:06 +0000 Received: from localhost ([127.0.0.1]:33492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8K2f-0006En-LJ for submit@debbugs.gnu.org; Sat, 18 May 2024 09:24:05 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8K2a-0006EE-AP for 70820@debbugs.gnu.org; Sat, 18 May 2024 09:24:04 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A3389800E9; Sat, 18 May 2024 09:23:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1716038629; bh=S4e1ghQU4AG9ob6TEtNozplMsUlVVg7vxB+Fvb0MtN4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=V/7zZA+9lHmz+AyYHxIwdAPoOBNn8cDt5GZ/ea76tbeXnQNKGK7z0T5dvn1Umsjif OJ9RvaWyV7cBAjFJLQTFwygk2Np36KH6C9cobe143idn2s8l+2X5SsAFPqpJdLZgVV gyZQ3eNNPd8zrBBtgx4ChnXHXbUchtEJs83u+H2WX4/xoqpBEYqEYKMAZ9IZj19Omv kQo3ziMfY1vnnMDUgEtoV0jUUuWk6i4M9Z76l+iak0wQUWRAAZqXEEvujnJCDKosQp YHlnIUZm8cttCNa60zUEz8zGS7yPX1lomI5rvULJKOiw2/yYi568Beut1q08SQBgHT DAk5kQ+lTeFHQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7370A80B4E; Sat, 18 May 2024 09:23:49 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 48FC4120611; Sat, 18 May 2024 09:23:49 -0400 (EDT) From: Stefan Monnier To: Jim Porter Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: (Jim Porter's message of "Tue, 7 May 2024 10:23:30 -0700") Message-ID: References: <87seytlhcq.fsf@gmail.com> Date: Sat, 18 May 2024 09:23:48 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/markdown; charset=UTF-8 X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, Visuwesh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > How does this compare to the existing wgrep package? That doesn't have > copyright assignment to the FSF, but otherwise, I think it's the bar against > which any similar package should be measured. I use it pretty frequently > (and have even written a plugin for it for my own grep-like major mode), and > it's pretty much exactly the way I'd want this sort of thing to > work. Something with feature-parity that lives in the Emacs tree would be > great though. FWIW, I don't see "live in Emacs tree" as particularly desirable for such a user-oriented package. It's already in NonGNU ELPA, so trivially installable. Note: I have not looked at the code of `wgrep.el`, so maybe there are good reasons to reinvent this wheel, but "live in the Emacs tree" isn't a good reason. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 09:34:54 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 13:34:54 +0000 Received: from localhost ([127.0.0.1]:33541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8KD7-0000re-I1 for submit@debbugs.gnu.org; Sat, 18 May 2024 09:34:54 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8KCr-0000rO-NG for 70820@debbugs.gnu.org; Sat, 18 May 2024 09:34:52 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B5DC800E9; Sat, 18 May 2024 09:34:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1716039266; bh=HRIm5LZdIyK83vhlVSbg/SY3IO/NtAxh0b+eC+YtV+8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ewuAkv8eMZ2JZDu5qIObOAnv0pOOGEVhvydJwmNgF1atQnHYh1keuod0EwTsH/jI4 AazURIyLY9bzPfMOOMbsOBjk52lciSv26gf32li2kxG6WtLx071HFdRIS5mRWvXC3H ISJNC1Lojj7z8XNktL6daXXR+Jvco4g305tTh8+IaBOpJC/QX9poPsDF2a+evyzv7U nBuzit+AFha+Le7D30rt1o1AIBU1aqrNfcf6mOjgMlqqEHhYCnrnn2DE95fMC/ZE2c YVAa+f6aEc9wakKMrZmnRKPa2eR3dLtGOwPanOqNzk0h8ER2rTMGKBowgEiUUXZNY9 YzNJfEBh8UDIA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3D1178091C; Sat, 18 May 2024 09:34:26 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0E3BF12021C; Sat, 18 May 2024 09:34:26 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <864jb89zwq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 May 2024 16:49:41 +0300") Message-ID: References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> Date: Sat, 18 May 2024 09:34:25 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/markdown; charset=UTF-8 X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, Visuwesh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> > I don't think I understand this difficulty, either: with >> > occur-edit-mode it is solved by making occur-edit-mode be derived from >> > occur-mode. Couldn't you do the same with your mode? >> >> No because occur-mode makes occur-revert-arguments permanent-local so >> `g' survives the major-mode changes. >> >> For revert-buffer alone, compilation-arguments needs to be marked >> permanent-local. As it is a part of compile.el, I am not sure if >> marking it as such is safe. This is why I think having a minor-mode is >> better. > > It sounds like a minor issue which shouldn't have such grave > consequences. Why do you think making compilation-arguments > permanent-local would be a problem? We could ask people who > frequently contribute to compile.e land grep.el if they see any > problem with doing that. AFAICT it would be harmless to make it permanent-local. Indeed, this var belongs with the contents of the buffer rather than with its mode (in a sense it is akin to `buffer-file-name` in that it says where the contents comes from), so it makes a lot of sense to mark it permanent-local. Side note: I believe things become simpler&cleaner if you separate the major mode function from the command that switches to it (just like `wdired-change-to-wdired-mode` is separate from `wdired-mode`). E.g. that lets you save&restore buffer-local vars like `compilation-arguments`, and it let you remove or disable `compilation--remove-properties` in a straightforward manner. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 09:36:11 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 13:36:11 +0000 Received: from localhost ([127.0.0.1]:33551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8KEN-0000su-9x for submit@debbugs.gnu.org; Sat, 18 May 2024 09:36:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8KEL-0000sm-9d for 70820@debbugs.gnu.org; Sat, 18 May 2024 09:36:09 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 82D3480B4E; Sat, 18 May 2024 09:36:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1716039359; bh=9V4nnM6fF4vh4sE5112LRW3NJn7YoUjw6jvH8HT56kE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dT+gPPAZeKcj67HjdkjI66wzupmi8STLYDo6xiSnRhcl/SfY4iSM+ECntJ3Bdm5P5 OZgXdrnWv8AzsVgo6WzmNrOGVAUgmc62+NADYUG5Rd9iFKG1GWyuhr3mXgliPFC6D/ 1jyoUTi+4xo+cgRUcdBJxM4GFvPrwd/AW2l98Vvk2DYCMbgDhHyUMJ+OnCatwe8n2H Rkxe+vnO/IjCdhNjOv9mhvQZJoe805hGiQE127r/NGOld2cowBdg75IiE8klvOS/RH up3u9t4EvNr6Gje8cPFQPDZ9mc7P8NZc5zzO71kCJTXSswtBb5AkOXRPsC0LznmBRE 8eFEsI4tsMLLQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7F7B7800E9; Sat, 18 May 2024 09:35:59 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 54FD212012E; Sat, 18 May 2024 09:35:59 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86le47eafb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 May 2024 12:28:24 +0300") Message-ID: References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> Date: Sat, 18 May 2024 09:35:58 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/markdown; charset=UTF-8 X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, Visuwesh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (I must admit that unconditionally removing the faces is not very > friendly on the part of compilation-mode. Stefan, are there better > ways of doing that, perhaps?) These are properties which the major mode (unconditionally) added, so it doesn't seem unfriendly to remove them unconditionally when switching to an unrelated major mode. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 11:44:58 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 15:44:58 +0000 Received: from localhost ([127.0.0.1]:34114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8MF0-0006M6-1o for submit@debbugs.gnu.org; Sat, 18 May 2024 11:44:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8MEt-0006LV-TU for 70820@debbugs.gnu.org; Sat, 18 May 2024 11:44:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8MEj-0008ET-SG; Sat, 18 May 2024 11:44:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1QsoNEZKLQYCqYWI68cCrKStVO66BNPR75TRWRI4wzY=; b=EqnUIFvfQZD3 H5Z825dzTTcfmNSMdY5VAakD27PmO7PtYkOENvOOPHfA59YQZFEcWs8BXgVzG7lytpyE7pZJS4IMV rX5zCl0OwmPR3kIyJWeTZbk/cQHOm2fjbOXJNyiSxsCmOAetFN7212ROXUgbACSv7ABMWLuObEMyp 2x2ZuyKHl/kNsGKv24kd84HHNoqAsu3czYKs8G4izaruOgHLgBBpAW4cfupIl6baCRK9c7glw2M7X bKJ/+9GnlVX/PDZIDBwopEEisWmhD9VD6VN+fbUaUnsWCdDFtrizvome2oO8dqcvYgMF9PSa0I0cE qe9fz/ZKXg1QKpXH4BA2qg==; Date: Sat, 18 May 2024 18:44:38 +0300 Message-Id: <86pltjceft.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 18 May 2024 09:35:58 -0400) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Visuwesh , 70820@debbugs.gnu.org > Date: Sat, 18 May 2024 09:35:58 -0400 > > > (I must admit that unconditionally removing the faces is not very > > friendly on the part of compilation-mode. Stefan, are there better > > ways of doing that, perhaps?) > > These are properties which the major mode (unconditionally) added, so it > doesn't seem unfriendly to remove them unconditionally when switching to > an unrelated major mode. Yes, but how does compilation-mode know the other major-mode is "unrelated"? It could be very related, as this discussion demonstrates. From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 12:27:19 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 16:27:19 +0000 Received: from localhost ([127.0.0.1]:34300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8Mtz-00074B-FH for submit@debbugs.gnu.org; Sat, 18 May 2024 12:27:19 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8Mtx-000745-K7 for 70820@debbugs.gnu.org; Sat, 18 May 2024 12:27:18 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0FE61441D6D; Sat, 18 May 2024 12:27:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1716049626; bh=xZmpONxpZj7Gg/jyu5I3liq8w7mfg+lLkw80VDWkKfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nfqRnZNcqJLfLOSsKSriI2W2d30TfwpdXNSWzTnWRsTSM4qsgglccXP2OobDXJsyq 5SjOME8SHgxNL8jl27OU1HzXem50h9EAtxOeWpbkliBMLz7bYmt8nJhELX+GWPtxp9 cnn5lnOBde4rsJO+s+0pziC8DDoPkTRgaOh+swsdftb6iK0cmVy2bLoQiStOAxNFM7 UTAG1tceoYvf9zvoCX0siSFklL+AU2sk4/OCHTctVVq258eXsgzWAAs71p8fqigK2J 8/6+PJ8mIE6OW+SSFGet7DKC1ohonrNZdim0x4sRd8U9V5pSkld22zDlNSXcKkopw6 sqPggMlYuOd6Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D0C26441D6B; Sat, 18 May 2024 12:27:06 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A1953120635; Sat, 18 May 2024 12:27:06 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86pltjceft.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 May 2024 18:44:38 +0300") Message-ID: References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> Date: Sat, 18 May 2024 12:27:06 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/markdown; charset=UTF-8 X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.004 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> These are properties which the major mode (unconditionally) added, so it >> doesn't seem unfriendly to remove them unconditionally when switching to >> an unrelated major mode. > Yes, but how does compilation-mode know the other major-mode is > "unrelated"? It could be very related, as this discussion > demonstrates. If it's related it has access to internals, so it can so things like disabling `compilation--remoave-properties`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 12:28:43 2024 Received: (at 70820) by debbugs.gnu.org; 18 May 2024 16:28:43 +0000 Received: from localhost ([127.0.0.1]:34310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8MvK-00074x-RQ for submit@debbugs.gnu.org; Sat, 18 May 2024 12:28:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8MvI-00074r-4g for 70820@debbugs.gnu.org; Sat, 18 May 2024 12:28:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8Mv9-0007fR-4Q; Sat, 18 May 2024 12:28:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=S7XXGQthIGr/NiIM584SseHx1Oj1jk6qGhF1ty8uwaI=; b=UTwEf7FLKfA8 kZ1xp10cL7IxeXanYVAqJ3+jp5J/kvUrb5P7cm2Nd9JONB8ZhTs+WmXr/ev0RBn3cGRic1tRv0izK 8J2kap8PdaLCS/OOp0bM6Jv0U3xQ0PMwKggdJ1yxOHOWsr5+hBZuZ9HYP1tKvcPwsTORp1xYe3UGF 2CVCUi5YV4fm0RiWG/w6VSkGdDna1nlmKA2o/2UnB34XmaBe4/060upg2mCLB2tfwcjfVYZDBkTwo +P+mNC9lZdzIJAGwxXinxkvP/cS6yh4Jbk4ecylp6BgN/wmofIWOmxpgTW+qpuM2/al2faQynj+N0 NPlG/QGP7FRsABGeJhutJQ==; Date: Sat, 18 May 2024 19:28:27 +0300 Message-Id: <86ikzbcces.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 18 May 2024 12:27:06 -0400) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, visuweshm@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: visuweshm@gmail.com, 70820@debbugs.gnu.org > Date: Sat, 18 May 2024 12:27:06 -0400 > > >> These are properties which the major mode (unconditionally) added, so it > >> doesn't seem unfriendly to remove them unconditionally when switching to > >> an unrelated major mode. > > Yes, but how does compilation-mode know the other major-mode is > > "unrelated"? It could be very related, as this discussion > > demonstrates. > > If it's related it has access to internals, so it can so things like > disabling `compilation--remoave-properties`. OK, so my suggestion to Visuwesh is the best way of dealing with this. Fine by me. From debbugs-submit-bounces@debbugs.gnu.org Mon May 20 06:12:08 2024 Received: (at 70820) by debbugs.gnu.org; 20 May 2024 10:12:08 +0000 Received: from localhost ([127.0.0.1]:41824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8zzz-0008Lw-Q5 for submit@debbugs.gnu.org; Mon, 20 May 2024 06:12:08 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:54724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8zzw-0008LY-Tq for 70820@debbugs.gnu.org; Mon, 20 May 2024 06:12:06 -0400 Received: by mail-pl1-f193.google.com with SMTP id d9443c01a7336-1f2ecea41deso60377365ad.1 for <70820@debbugs.gnu.org>; Mon, 20 May 2024 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716199854; x=1716804654; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=gakrwPyoTSkRKyYkBwKtkTQHOz3Werg2CjYFDB7resE=; b=OaE24urRz3Vk4K2E5yTwDZPkxo42TaZG7mlkELy4sOarrG8XdvliBMVm++gQj0+G3W xEMJOfm8t7QB8zDnCbZjqBETJDbXBuUN0CQ+KWPgjbFxD0ibGPvVC9Rj6W1XrZTNlXQb 6NotXaKqpRHYFNK3aA0Cgz1kBht6M8AvAztUpBaRs4NLSCwh6/t9f+FPLmfe3eYB1OCn kAuwXuhQbwMLcW4FwDhVxwjeK4VXpBntJl9zzqXEizXxjVuyPuBIpbKH5aMEM7t1vNSD f7ZphjXPvO/2gbR0usnROdz2qmohdI82SjEoV15SU3ld4cb7/pKEZQGygsfFTFYKh3Ni eYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716199854; x=1716804654; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gakrwPyoTSkRKyYkBwKtkTQHOz3Werg2CjYFDB7resE=; b=sH6p2hgESiMHDA4+JI1Wk8kHa1lECLkaYJPAtMR3DMrhRd7Ju/sbgXX74RVryHOR4j G0CW7lbmtzdyoe+srg+O8QwTzk+4O+aJ4XaoEEy3xkXEhEC22bgTrnyaQTrvjMKfdJ25 qy3rW0A2Pi3Ke9W+HgHD/F9cgyQevzEFdz61qjDjDfgVyYIMSq9KkJesVfSvgG2RHpo9 WFGo5hz8j5GlWxUq06CvLplFEi+6nDKhmg4LOWpxmhPeUvHBX+lVDhO48FDSTI1cwlFb urHXyl8p34ddfx1wkGxzTIsFVdlIaSmz7g4ntqzMduHUU9fQ4oWIqqBmzCBaACYBz+2D MKdw== X-Forwarded-Encrypted: i=1; AJvYcCXWN7UTbwOjaafNMzLPcg0iImwN9NGRkaMv1nsrrQ11pA0xYaeBZ/+Go1iBn45/76mj0eW8vwhaGiILzPCeJAeo26/a8eE= X-Gm-Message-State: AOJu0YwIbcH5QZuS32Ful/hbnbRgi8au7YhJsLt6mcl5FFub1Yx7Nhyd zI9x/AB85wPLYomK3gWI2pP30mXwsKwRXO+xJRH6MLDPh4emiiu3vOp76EOR X-Google-Smtp-Source: AGHT+IH6+wAO64A4EH0Gnb92NtBShyVJuv5KgstmDQ1AHSQCk2NynO2xw5vYnK/Tmc7t6Y0KqilxCA== X-Received: by 2002:a05:6a00:1807:b0:6e8:f66f:6b33 with SMTP id d2e1a72fcca58-6f4e029fc8emr35041692b3a.4.1716199854128; Mon, 20 May 2024 03:10:54 -0700 (PDT) Received: from localhost ([103.232.241.147]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4d2af2bafsm18709294b3a.162.2024.05.20.03.10.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 03:10:53 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86ikzbcces.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 May 2024 19:28:27 +0300") Date: Mon, 20 May 2024 15:40:47 +0530 Message-ID: <87y1844wuw.fsf@gmail.com> References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=AE=E0=AF=87 18, 2024] Eli Zaretskii wro= te: >> From: Stefan Monnier >> Cc: visuweshm@gmail.com, 70820@debbugs.gnu.org >> Date: Sat, 18 May 2024 12:27:06 -0400 >>=20 >> >> These are properties which the major mode (unconditionally) added, so= it >> >> doesn't seem unfriendly to remove them unconditionally when switching= to >> >> an unrelated major mode. >> > Yes, but how does compilation-mode know the other major-mode is >> > "unrelated"? It could be very related, as this discussion >> > demonstrates. >>=20 >> If it's related it has access to internals, so it can so things like >> disabling `compilation--remoave-properties`. > > OK, so my suggestion to Visuwesh is the best way of dealing with this. > Fine by me. Thank you Stefan & Eli, I will take a closer look at your suggestions when time permits. I have limited internet access outside my work hours so I cannot reply to your messages in full. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 28 04:35:05 2024 Received: (at 70820) by debbugs.gnu.org; 28 Jul 2024 08:35:05 +0000 Received: from localhost ([127.0.0.1]:42685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sXzMu-0001P8-C9 for submit@debbugs.gnu.org; Sun, 28 Jul 2024 04:35:05 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:52501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sXzMs-0001OX-5L for 70820@debbugs.gnu.org; Sun, 28 Jul 2024 04:35:03 -0400 Received: by mail-oi1-f196.google.com with SMTP id 5614622812f47-3db18102406so1779207b6e.1 for <70820@debbugs.gnu.org>; Sun, 28 Jul 2024 01:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722155625; x=1722760425; darn=debbugs.gnu.org; h=mime-version:user-agent:references:message-id:date:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=1tOAnwwLjPVgrVE/9csFJMnLdS1wI0Fu/Tmne9LP8KM=; b=HuLkTwEP+r3naBXb7/+mdp4VbGti47F2K2LUVP0WTSIN5IiDhC6jYsK6Uia6SqI63o g0E1dykF+3gFKpju9wkLms31HGJAz48icldRGfMFoACIc7D4mtfsKsHqRenY1p27myaC 3gKbhqH7xweikjLQOz5qvg5ViQbvcnHiX4O+zfzW86kILMTvEfqGTmxqei/hYttGc+98 qq6Ls0p3knk93RF982NnpmvDv670i6NUkdc0l1VYHML7FR4fHhWvA3yn6340Jp8Y5mpo owKXp/47faf9qkf40m2Mh4sNRu0Xvl0ou1aSZBxv1LSqkrRwB23BQAOgk3dXYKtY1aun V7ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722155625; x=1722760425; h=mime-version:user-agent:references:message-id:date:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1tOAnwwLjPVgrVE/9csFJMnLdS1wI0Fu/Tmne9LP8KM=; b=FUbN44rkDmrmGro42obdT46Lh9XoMnYuZ34EVcfK/GvkRZu+z+Jqk1nqC95dbhj1zR KExf30rtIwr5NNEazZSI/dTiofP4HoMjGc+IIzKcANAW4FCnoYgaWu6CuRD6VZuviajD ZvPl/YWFz1+jAluDw2jpodRi80YFNZiDvwOVJs1USW+XhATSQDUP3XqTCnh4qrlZebEV tVJ6b5QrPqIelrzVJOWi5gVxhyLRrlcXxPV1IRLf1XqiUTD9alTo1VvTSLBt4H3nBIoa wti1/toNilC5X1l2qmAm1a5zl4PWSp/iibLrjDL98TY/4JuMuMcns0xZn3DtVJu9tb4p HQPw== X-Forwarded-Encrypted: i=1; AJvYcCWBFqhmUTSgBk9abaG5Xp77ou+MfpsnEKJmmIdD72D8pYKikubfS9DEs7Tgil7dd5KCN/NX96ehdk8LB2Z3X2NEwi9HViU= X-Gm-Message-State: AOJu0YzLQFHdKHTdHedtzRX7ohmVigYcJPDnPX3gJn0bgBKTMrSQ4UvT Rcf4tTXAvd2zLxggVdcAQ08PxrFriWrwogbeLvCcrZgZQl0PPOqH X-Google-Smtp-Source: AGHT+IFouJD4O3A/8HJ2eNLO3LW3w5A7drT9FOyMtne6QqJGcZyS99ekNCpdDm8MVks89hMRjon/BQ== X-Received: by 2002:a05:6808:11c1:b0:3db:269b:964b with SMTP id 5614622812f47-3db269b984dmr5554503b6e.12.1722155625242; Sun, 28 Jul 2024 01:33:45 -0700 (PDT) Received: from localhost ([49.204.119.35]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70ead86ff31sm5253104b3a.144.2024.07.28.01.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jul 2024 01:33:44 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86ikzbcces.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 May 2024 19:28:27 +0300") Date: Sun, 28 Jul 2024 14:03:32 +0530 Message-ID: <87le1lj4pv.fsf@gmail.com> References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=AE=E0=AF=87 18, 2024] Eli Zaretskii wro= te: >> From: Stefan Monnier >> Cc: visuweshm@gmail.com, 70820@debbugs.gnu.org >> Date: Sat, 18 May 2024 12:27:06 -0400 >>=20 >> >> These are properties which the major mode (unconditionally) added, so= it >> >> doesn't seem unfriendly to remove them unconditionally when switching= to >> >> an unrelated major mode. >> > Yes, but how does compilation-mode know the other major-mode is >> > "unrelated"? It could be very related, as this discussion >> > demonstrates. >>=20 >> If it's related it has access to internals, so it can so things like >> disabling `compilation--remoave-properties`. > > OK, so my suggestion to Visuwesh is the best way of dealing with this. > Fine by me. Sorry for the long delay. I finally got the time to work on this properly. The attached patch uses a major-mode, akin to wdired-mode like Stefan suggested in another message. This side-steps previous issues with buffer-local variables and compilation--remove-properties. If this approach is okay, I will work on updating the documentation, etc. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=grep-edit-v2.diff diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index b18eb81fee1..867ebc92d75 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -2829,6 +2829,53 @@ compilation-find-buffer (current-buffer) (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))) +(defun compilation--update-markers (loc marker screen-columns first-column) + "Update markers in LOC, and set MARKER to location pointed by LOC. +SCREEN-COLUMNS and FIRST-COLUMN are the value of +`compilation-error-screen-columns' and `compilation-first-column' to use +if they are not set buffer-locally in the target buffer." + (with-current-buffer + (if (bufferp (caar (compilation--loc->file-struct loc))) + (caar (compilation--loc->file-struct loc)) + (apply #'compilation-find-file + marker + (caar (compilation--loc->file-struct loc)) + (cadr (car (compilation--loc->file-struct loc))) + (compilation--file-struct->formats + (compilation--loc->file-struct loc)))) + (let ((screen-columns + ;; Obey the compilation-error-screen-columns of the target + ;; buffer if its major mode set it buffer-locally. + (if (local-variable-p 'compilation-error-screen-columns) + compilation-error-screen-columns screen-columns)) + (compilation-first-column + (if (local-variable-p 'compilation-first-column) + compilation-first-column first-column)) + (last 1)) + (save-restriction + (widen) + (goto-char (point-min)) + ;; Treat file's found lines in forward order, 1 by 1. + (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) + (when (car line) ; else this is a filename without a line# + (compilation-beginning-of-line (- (car line) last -1)) + (setq last (car line))) + ;; Treat line's found columns and store/update a marker for each. + (dolist (col (cdr line)) + (if (compilation--loc->col col) + (if (eq (compilation--loc->col col) -1) + ;; Special case for range end. + (end-of-line) + (compilation-move-to-column (compilation--loc->col col) + screen-columns)) + (beginning-of-line) + (skip-chars-forward " \t")) + (if (compilation--loc->marker col) + (set-marker (compilation--loc->marker col) (point)) + (setf (compilation--loc->marker col) (point-marker))) + ;; (setf (compilation--loc->timestamp col) timestamp) + )))))) + ;;;###autoload (defun compilation-next-error-function (n &optional reset) "Advance to the next error message and visit the file where the error was. @@ -2838,7 +2885,6 @@ compilation-next-error-function (setq compilation-current-error nil)) (let* ((screen-columns compilation-error-screen-columns) (first-column compilation-first-column) - (last 1) (msg (compilation-next-error (or n 1) nil (or compilation-current-error compilation-messages-start @@ -2850,9 +2896,9 @@ compilation-next-error-function (user-error "No next error")) (setq compilation-current-error (point-marker) overlay-arrow-position - (if (bolp) - compilation-current-error - (copy-marker (line-beginning-position)))) + (if (bolp) + compilation-current-error + (copy-marker (line-beginning-position)))) ;; If loc contains no marker, no error in that file has been visited. ;; If the marker is invalid the buffer has been killed. ;; So, recalculate all markers for that file. @@ -2869,46 +2915,7 @@ compilation-next-error-function ;; (equal (compilation--loc->timestamp loc) ;; (setq timestamp compilation-buffer-modtime))) ) - (with-current-buffer - (if (bufferp (caar (compilation--loc->file-struct loc))) - (caar (compilation--loc->file-struct loc)) - (apply #'compilation-find-file - marker - (caar (compilation--loc->file-struct loc)) - (cadr (car (compilation--loc->file-struct loc))) - (compilation--file-struct->formats - (compilation--loc->file-struct loc)))) - (let ((screen-columns - ;; Obey the compilation-error-screen-columns of the target - ;; buffer if its major mode set it buffer-locally. - (if (local-variable-p 'compilation-error-screen-columns) - compilation-error-screen-columns screen-columns)) - (compilation-first-column - (if (local-variable-p 'compilation-first-column) - compilation-first-column first-column))) - (save-restriction - (widen) - (goto-char (point-min)) - ;; Treat file's found lines in forward order, 1 by 1. - (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) - (when (car line) ; else this is a filename without a line# - (compilation-beginning-of-line (- (car line) last -1)) - (setq last (car line))) - ;; Treat line's found columns and store/update a marker for each. - (dolist (col (cdr line)) - (if (compilation--loc->col col) - (if (eq (compilation--loc->col col) -1) - ;; Special case for range end. - (end-of-line) - (compilation-move-to-column (compilation--loc->col col) - screen-columns)) - (beginning-of-line) - (skip-chars-forward " \t")) - (if (compilation--loc->marker col) - (set-marker (compilation--loc->marker col) (point)) - (setf (compilation--loc->marker col) (point-marker))) - ;; (setf (compilation--loc->timestamp col) timestamp) - )))))) + (compilation--update-markers loc marker screen-columns first-column)) (compilation-goto-locus marker (compilation--loc->marker loc) (compilation--loc->marker end-loc)) (setf (compilation--loc->visited loc) t))) diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 657349cbdff..605e763b444 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -295,6 +295,8 @@ grep-mode-map (define-key map "}" #'compilation-next-file) (define-key map "\t" #'compilation-next-error) (define-key map [backtab] #'compilation-previous-error) + + (define-key map "e" #'grep-change-to-grep-edit-mode) map) "Keymap for grep buffers. `compilation-minor-mode-map' is a cdr of this.") @@ -1029,6 +1031,90 @@ grep command-args) #'grep-mode)) +(defun grep-edit--prepare-buffer () + "Mark relevant regions read-only, and add relevant occur text-properties." + (save-excursion + (goto-char (point-min)) + (let ((inhibit-read-only t) + (dummy (make-marker)) + match) + (while (setq match (text-property-search-forward 'compilation-annotation)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t))) + (goto-char (point-min)) + (while (setq match (text-property-search-forward 'compilation-message)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t occur-prefix t)) + (let ((loc (compilation--message->loc (prop-match-value match))) + m) + ;; Update the markers if necessary. + (unless (and (compilation--loc->marker loc) + (marker-buffer (compilation--loc->marker loc))) + (compilation--update-markers loc dummy compilation-error-screen-columns compilation-first-column)) + (setq m (compilation--loc->marker loc)) + (add-text-properties (prop-match-beginning match) + (or (next-single-property-change + (prop-match-end match) + 'compilation-message) + (1+ (pos-eol))) + `(occur-target ((,m . ,m))))))))) + +(defvar grep-edit-mode-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map text-mode-map) + (define-key map (kbd "C-c C-c") #'grep-edit-save-changes) + map) + "Keymap for `grep-edit-mode'.") + +(defvar grep-edit-mode-hook nil + "Hooks run when changing to Grep-Edit mode.") + +(defun grep-edit-mode () + "Major mode for editing *grep* buffers. +In this mode, changes to the *grep* buffer are applied to the +originating files. +\\ +Type \\[grep-edit-save-changes] to exit Grep-Edit mode, return to Grep +mode. + +The only editable texts in a Grep-Edit buffer are the match results." + (interactive) + (error "This mode can be enabled only by `grep-change-to-grep-edit-mode'")) +(put 'grep-edit-mode 'mode-class 'special) + +(defun grep-change-to-grep-edit-mode () + "Switch to `grep-edit-mode' to edit *grep* buffer." + (interactive) + (unless (derived-mode-p 'grep-mode) + (error "Not a Grep buffer")) + (when (get-buffer-process (current-buffer)) + (error "Cannot switch when grep is running")) + (use-local-map grep-edit-mode-map) + (grep-edit--prepare-buffer) + (setq buffer-read-only nil) + (setq major-mode 'grep-edit-mode) + (setq mode-name "Grep-Edit") + (buffer-enable-undo) + (set-buffer-modified-p nil) + (setq buffer-undo-list nil) + (add-hook 'after-change-functions #'occur-after-change-function nil t) + (run-mode-hooks 'grep-edit-mode-hook) + (message "Editing: \\[grep-edit-save-changes] to return to Grep mode")) + +(defun grep-edit-save-changes () + "Switch back to Grep mode." + (interactive) + (unless (derived-mode-p 'grep-edit-mode) + (error "Not a Grep-Edit buffer")) + (remove-hook 'after-change-functions #'occur-after-change-function t) + (use-local-map grep-mode-map) + (setq buffer-read-only t) + (setq major-mode 'grep-mode) + (setq mode-name "Grep") + (force-mode-line-update) + (buffer-disable-undo) + (setq buffer-undo-list t) + (message "Switching to Grep mode")) ;;;###autoload (defun grep-find (command-args) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 13 20:31:39 2024 Received: (at 70820) by debbugs.gnu.org; 14 Aug 2024 00:31:39 +0000 Received: from localhost ([127.0.0.1]:45721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1se1vP-000856-0d for submit@debbugs.gnu.org; Tue, 13 Aug 2024 20:31:39 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1se1vN-00084j-1D for 70820@debbugs.gnu.org; Tue, 13 Aug 2024 20:31:37 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C6EBF803B1; Tue, 13 Aug 2024 20:30:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1723595455; bh=ZTjGi/OM43m7/Z5Unq1JPx2ZykGBTwOp0rwb/mT++QE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=K/DM8KhTSkH/x0UPvoIIw2XyNVLqCU8meH8Y9YqT+9sR84NNgBx/NCkKT9G5CvWsw GaHuyooAj/4FqdcuPxi0SO7P6pqA3/oWV9DmIBxQEqYK02g6HdEtY2U2uY4vor31o4 HHw+tzA6NBUUvc5ns/U4XL5NMm0wF/VwUKyCf+09lvM46jsB2+z5SWextXbYOpIjFO xhkAEKONaagUkqtCxIeA4nCJT0JoN1CiM2aP0B9FPagWIw3RbE8uEMBJjRHoBbhERD Avo/xA+d95Q/3lXSSwolBrFxhRoAqGfL8w03hgrN930IlCg3gfQ5Eaml+dnaszn58N rDmR3FIxMxuZA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1B45D80672; Tue, 13 Aug 2024 20:30:55 -0400 (EDT) Received: from pastel (unknown [216.154.9.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1156120495; Tue, 13 Aug 2024 20:30:54 -0400 (EDT) From: Stefan Monnier To: Visuwesh Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <87le1lj4pv.fsf@gmail.com> (Visuwesh's message of "Sun, 28 Jul 2024 14:03:32 +0530") Message-ID: References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> Date: Tue, 13 Aug 2024 20:30:53 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.175 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: Eli Zaretskii , 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > +(defun compilation--update-markers (loc marker screen-columns first-column) > + "Update markers in LOC, and set MARKER to location pointed by LOC. > +SCREEN-COLUMNS and FIRST-COLUMN are the value of > +`compilation-error-screen-columns' and `compilation-first-column' to use > +if they are not set buffer-locally in the target buffer." > + (with-current-buffer > + (if (bufferp (caar (compilation--loc->file-struct loc))) > + (caar (compilation--loc->file-struct loc)) > + (apply #'compilation-find-file > + marker > + (caar (compilation--loc->file-struct loc)) > + (cadr (car (compilation--loc->file-struct loc))) > + (compilation--file-struct->formats > + (compilation--loc->file-struct loc)))) > + (let ((screen-columns > + ;; Obey the compilation-error-screen-columns of the target > + ;; buffer if its major mode set it buffer-locally. > + (if (local-variable-p 'compilation-error-screen-columns) > + compilation-error-screen-columns screen-columns)) > + (compilation-first-column > + (if (local-variable-p 'compilation-first-column) > + compilation-first-column first-column)) > + (last 1)) > + (save-restriction > + (widen) > + (goto-char (point-min)) > + ;; Treat file's found lines in forward order, 1 by 1. > + (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) > + (when (car line) ; else this is a filename without a line# > + (compilation-beginning-of-line (- (car line) last -1)) > + (setq last (car line))) > + ;; Treat line's found columns and store/update a marker for each. > + (dolist (col (cdr line)) > + (if (compilation--loc->col col) > + (if (eq (compilation--loc->col col) -1) > + ;; Special case for range end. > + (end-of-line) > + (compilation-move-to-column (compilation--loc->col col) > + screen-columns)) > + (beginning-of-line) > + (skip-chars-forward " \t")) > + (if (compilation--loc->marker col) > + (set-marker (compilation--loc->marker col) (point)) > + (setf (compilation--loc->marker col) (point-marker))) > + ;; (setf (compilation--loc->timestamp col) timestamp) > + )))))) Are there any changes in this code, or is it "verbatim" the code extracted from `compilation-next-error-function`? > +(defvar grep-edit-mode-hook nil > + "Hooks run when changing to Grep-Edit mode.") It's just "Hook" because `grep-edit-mode-hook` is a hook. Hooks contain functions, so when you run a hook, the corresponding functions are called. > +(defun grep-edit-mode () > + "Major mode for editing *grep* buffers. > +In this mode, changes to the *grep* buffer are applied to the > +originating files. > +\\ > +Type \\[grep-edit-save-changes] to exit Grep-Edit mode, return to Grep > +mode. > + > +The only editable texts in a Grep-Edit buffer are the match results." > + (interactive) > + (error "This mode can be enabled only by `grep-change-to-grep-edit-mode'")) > +(put 'grep-edit-mode 'mode-class 'special) > + > +(defun grep-change-to-grep-edit-mode () > + "Switch to `grep-edit-mode' to edit *grep* buffer." > + (interactive) > + (unless (derived-mode-p 'grep-mode) > + (error "Not a Grep buffer")) > + (when (get-buffer-process (current-buffer)) > + (error "Cannot switch when grep is running")) > + (use-local-map grep-edit-mode-map) > + (grep-edit--prepare-buffer) > + (setq buffer-read-only nil) > + (setq major-mode 'grep-edit-mode) > + (setq mode-name "Grep-Edit") > + (buffer-enable-undo) > + (set-buffer-modified-p nil) > + (setq buffer-undo-list nil) > + (add-hook 'after-change-functions #'occur-after-change-function nil t) > + (run-mode-hooks 'grep-edit-mode-hook) > + (message "Editing: \\[grep-edit-save-changes] to return to Grep mode")) I'm tempted to say you should use `major-mode-suspend/resume` (which would avoid the duplication of parts of `grep-mode` in `grep-edit-save-changes`), but I guess this might re-introduce the problem with buffer-local variables. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 13 22:45:30 2024 Received: (at 70820) by debbugs.gnu.org; 14 Aug 2024 02:45:30 +0000 Received: from localhost ([127.0.0.1]:45792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1se40w-0003zM-A0 for submit@debbugs.gnu.org; Tue, 13 Aug 2024 22:45:30 -0400 Received: from mail-oo1-f68.google.com ([209.85.161.68]:57615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1se40u-0003z5-Cf for 70820@debbugs.gnu.org; Tue, 13 Aug 2024 22:45:28 -0400 Received: by mail-oo1-f68.google.com with SMTP id 006d021491bc7-5d5f9d68805so3472279eaf.3 for <70820@debbugs.gnu.org>; Tue, 13 Aug 2024 19:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723603428; x=1724208228; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=C1j4sWd1GbKl0Hrp1NNKSTbTtbwJqderfGxraXNcnsw=; b=PxhHl3s4FQmRbV5aKGE2NKTseSVy+N+Lzet8Gd/QJT94sJ2wPVZxNeeL7UugzxUpJA Bq+fVhl7vKK9YIqxo3ESD/O6E2Q+AsP7LxfYihP7VhJe9rcxP3ygPIqYJqAuN6P1AME1 Q+p2kpEs+lS4iNNCt8hvV+rurM1nzgLaxB/dt7x1EDy0IqDGEQbz8ps7lr/+lRtWtzaL cRrsMnTHFkzPuG2x3dZDvJXXkK4sUwz9VSgboe+PYrbX46J9HiswKWJMIc1JdDcDUqj4 KG3CL4pLviInn22c9aW2tIoVC952f9bmb5R1XYKC+0yXko5C7Le88Xu3VpOYZibFoJIw 2Cfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723603428; x=1724208228; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=C1j4sWd1GbKl0Hrp1NNKSTbTtbwJqderfGxraXNcnsw=; b=K/b7k0vt6z67U1GfEbKkKAHUN1Ccr1W1t+vmEJX/kBS2UcwVKZ/ikix2WH4+D1EvGO EQ5wUtMlWzqrwoXmBvevFb79nL5J80cIRk0FLL8MPYiFwFJwCE/4/Z0Zanz32fatbFLW MdvBxdRJQbXMs771ndhrR3KLJFZyA7AbLk9y9xWqBSU5WdHDXE3VUVoqxJcXVm2l44xk TQgwfVIHqg/VVgn+UtDBpWFg7M2B1u2gFF8pGMl0g+0pvuUWVRYRrFTzenXVscu21i7O wjtB0+AR5ZxNydMWQ5UDF3r87/Xw3upBAIMg/AqoXnFNz2HdLMtMFM7nHt+s59oE8Yw+ kV8g== X-Forwarded-Encrypted: i=1; AJvYcCW8VnMFj9PdflzywIZmJO4aqJTKIjz17eW0OVMjHf9WydsroYupCZeEjM9P7caNyqzDlitx3o+H509uA1Er/sRTQen/rAI= X-Gm-Message-State: AOJu0YxJc09bUu3wvfKvdOJa6PsHWa/pOP6SQfHRg8x8ekxj8h4zuEwW Mu8QM6W3GSPZllv3ZhEcaSMQMjZGMj69oMA1GS4esSx9quwbBDFe X-Google-Smtp-Source: AGHT+IFO2R55DSGvZZ6UKpeVLBFnPtnGPMgJABDJ7oUYAUk1JGnWALVBbxKiZvb246ASAxo0yIjFOQ== X-Received: by 2002:a05:6870:5252:b0:261:164d:685e with SMTP id 586e51a60fabf-26fe5c28ee0mr1866420fac.43.1723603428243; Tue, 13 Aug 2024 19:43:48 -0700 (PDT) Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7c6979d3ea4sm1845923a12.14.2024.08.13.19.43.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Aug 2024 19:43:47 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: (Stefan Monnier via's message of "Tue, 13 Aug 2024 20:30:53 -0400") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> Date: Wed, 14 Aug 2024 08:13:42 +0530 Message-ID: <87bk1vzuw1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [செவ்வாய் ஆகஸ்ட் 13, 2024] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: >> +(defun compilation--update-markers (loc marker screen-columns first-column) >> + "Update markers in LOC, and set MARKER to location pointed by LOC. >> +SCREEN-COLUMNS and FIRST-COLUMN are the valu [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [209.85.161.68 listed in bl.score.senderscore.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.161.68 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.161.68 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 70820 Cc: Eli Zaretskii , 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF=8D = =E0=AE=86=E0=AE=95=E0=AE=B8=E0=AF=8D=E0=AE=9F=E0=AF=8D 13, 2024] Stefan Mon= nier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" = wrote: >> +(defun compilation--update-markers (loc marker screen-columns first-col= umn) >> + "Update markers in LOC, and set MARKER to location pointed by LOC. >> +SCREEN-COLUMNS and FIRST-COLUMN are the value of >> +`compilation-error-screen-columns' and `compilation-first-column' to use >> +if they are not set buffer-locally in the target buffer." >> + (with-current-buffer >> + (if (bufferp (caar (compilation--loc->file-struct loc))) >> + (caar (compilation--loc->file-struct loc)) >> + (apply #'compilation-find-file >> + marker >> + (caar (compilation--loc->file-struct loc)) >> + (cadr (car (compilation--loc->file-struct loc))) >> + (compilation--file-struct->formats >> + (compilation--loc->file-struct loc)))) >> + (let ((screen-columns >> + ;; Obey the compilation-error-screen-columns of the target >> + ;; buffer if its major mode set it buffer-locally. >> + (if (local-variable-p 'compilation-error-screen-columns) >> + compilation-error-screen-columns screen-columns)) >> + (compilation-first-column >> + (if (local-variable-p 'compilation-first-column) >> + compilation-first-column first-column)) >> + (last 1)) >> + (save-restriction >> + (widen) >> + (goto-char (point-min)) >> + ;; Treat file's found lines in forward order, 1 by 1. >> + (dolist (line (reverse (cddr (compilation--loc->file-struct loc= )))) >> + (when (car line) ; else this is a filename without a line# >> + (compilation-beginning-of-line (- (car line) last -1)) >> + (setq last (car line))) >> + ;; Treat line's found columns and store/update a marker for e= ach. >> + (dolist (col (cdr line)) >> + (if (compilation--loc->col col) >> + (if (eq (compilation--loc->col col) -1) >> + ;; Special case for range end. >> + (end-of-line) >> + (compilation-move-to-column (compilation--loc->col co= l) >> + screen-columns)) >> + (beginning-of-line) >> + (skip-chars-forward " \t")) >> + (if (compilation--loc->marker col) >> + (set-marker (compilation--loc->marker col) (point)) >> + (setf (compilation--loc->marker col) (point-marker))) >> + ;; (setf (compilation--loc->timestamp col) timestamp) >> + )))))) > > Are there any changes in this code, or is it "verbatim" the code > extracted from `compilation-next-error-function`? It is extracted verbatim from compilation-next-error-function. >> +(defvar grep-edit-mode-hook nil >> + "Hooks run when changing to Grep-Edit mode.") > > It's just "Hook" because `grep-edit-mode-hook` is a hook. Hooks contain > functions, so when you run a hook, the corresponding functions are called. Ah, I was under the impression that the functions were also referred to as hooks. I will correct them in a future patch. >> +(defun grep-edit-mode () >> + "Major mode for editing *grep* buffers. >> +In this mode, changes to the *grep* buffer are applied to the >> +originating files. >> +\\ >> +Type \\[grep-edit-save-changes] to exit Grep-Edit mode, return to Grep >> +mode. >> + >> +The only editable texts in a Grep-Edit buffer are the match results." >> + (interactive) >> + (error "This mode can be enabled only by `grep-change-to-grep-edit-mo= de'")) >> +(put 'grep-edit-mode 'mode-class 'special) >> + >> +(defun grep-change-to-grep-edit-mode () >> + "Switch to `grep-edit-mode' to edit *grep* buffer." >> + (interactive) >> + (unless (derived-mode-p 'grep-mode) >> + (error "Not a Grep buffer")) >> + (when (get-buffer-process (current-buffer)) >> + (error "Cannot switch when grep is running")) >> + (use-local-map grep-edit-mode-map) >> + (grep-edit--prepare-buffer) >> + (setq buffer-read-only nil) >> + (setq major-mode 'grep-edit-mode) >> + (setq mode-name "Grep-Edit") >> + (buffer-enable-undo) >> + (set-buffer-modified-p nil) >> + (setq buffer-undo-list nil) >> + (add-hook 'after-change-functions #'occur-after-change-function nil t) >> + (run-mode-hooks 'grep-edit-mode-hook) >> + (message "Editing: \\[grep-edit-save-changes] to return to Grep mode"= )) > > I'm tempted to say you should use `major-mode-suspend/resume` (which > would avoid the duplication of parts of `grep-mode` in > `grep-edit-save-changes`), but I guess this might re-introduce the > problem with buffer-local variables. Yes, unfortunately it will re-introduce the problem with buffer-local variables.=20=20 If everyone is okay with the current patch, I can get to writing the NEWS entry and updating the manual. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 14 07:38:40 2024 Received: (at 70820) by debbugs.gnu.org; 14 Aug 2024 11:38:41 +0000 Received: from localhost ([127.0.0.1]:46326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1seCKu-00018d-IA for submit@debbugs.gnu.org; Wed, 14 Aug 2024 07:38:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1seCKt-00018I-0u for 70820@debbugs.gnu.org; Wed, 14 Aug 2024 07:38:39 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1AC77440493; Wed, 14 Aug 2024 07:37:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1723635475; bh=Tn2OSw5cS5zfOSmZ8cbt+t+2+jczVmCXuX+iawoaIy4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NK9/CSXk5XTEYzo/MvVQWnMKULZsRF4SZui9OrtrFj+wfqkfQ9UMZF7KZ+1txv4zu dSNCnCFKKJCqksdGLKjg5PxuAGFEsHichqX3vZTvDn+b036pVeY3AJ+F7AsM0V3TAv Uw00PbkSNTAUy59nJ5Qdn3j+pgb91jrKMiRwN+Gu10WaQWCiRUps2FPX8qE/mjmRNB Tuv6bdYfBlqDtgz/KJEDSFS15BR5Btjw68xu58ki/9tqO66O5KJmH46rdckEtVjlBH o5xJkI6c4gbxUQutm8+3lczCXbfznLShwqjHB9cRXU3c1M6TpGkYzLBj/pJx6eCWrN oJNSrU2HPA4BQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 893C5441BF1; Wed, 14 Aug 2024 07:37:55 -0400 (EDT) Received: from pastel (unknown [216.154.9.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5AD1112046B; Wed, 14 Aug 2024 07:37:55 -0400 (EDT) From: Stefan Monnier To: Visuwesh Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <87bk1vzuw1.fsf@gmail.com> (Visuwesh's message of "Wed, 14 Aug 2024 08:13:42 +0530") Message-ID: References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> <87bk1vzuw1.fsf@gmail.com> Date: Wed, 14 Aug 2024 07:37:53 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.375 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: Eli Zaretskii , 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Are there any changes in this code, or is it "verbatim" the code >> extracted from `compilation-next-error-function`? > It is extracted verbatim from compilation-next-error-function. Great, thanks. >>> +(defvar grep-edit-mode-hook nil >>> + "Hooks run when changing to Grep-Edit mode.") >> It's just "Hook" because `grep-edit-mode-hook` is a hook. Hooks contain >> functions, so when you run a hook, the corresponding functions are called. > Ah, I was under the impression that the functions were also referred to > as hooks. You're far from the only one: it's a common confusion, and it's frequent to see docstrings which encourage that confusion. > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. +1 Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 31 03:55:53 2024 Received: (at 70820) by debbugs.gnu.org; 31 Aug 2024 07:55:53 +0000 Received: from localhost ([127.0.0.1]:53823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skIxc-00060s-HV for submit@debbugs.gnu.org; Sat, 31 Aug 2024 03:55:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skIxa-00060Z-Lz for 70820@debbugs.gnu.org; Sat, 31 Aug 2024 03:55:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1skIwY-0003MM-Uq; Sat, 31 Aug 2024 03:54:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Opf4SWkmxcyVyXP8wq5YOG+NXrQpv+sE72cg29EBN7g=; b=hNsioBND6rTs5lHqyzm+ cAbI7hN124WLrY0f7YU9O7uNZPc57xpxsgdNHr2338CeE/jMNjGz1FuAbH5rM473fqmcjbYKeimLS CBJ5JegxyCht4fVvGTvTJD43TNRFyLDBx4v8WhMpARiqCtTvMFuX3HbDWNJvJlfC3a7/1x9wtJVDX arRPoAT+cVinY5QBUPkXazTdPrK4MQG+z+K5MAPM06YeU9L7Q1ANm+6sjY4A2cOQxdCuqJl9lHDhd 6xXYi1MkvNEmFv0iHo0rQLqHvVM3vqjkvXnx5mxb/kcWQSvVeQC4wTWmhzayW8udoZ2l29CAPrw1Q E8gcAyLSOYSFng==; Date: Sat, 31 Aug 2024 10:54:44 +0300 Message-Id: <86y14dcekb.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87bk1vzuw1.fsf@gmail.com> (message from Visuwesh on Wed, 14 Aug 2024 08:13:42 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> <87bk1vzuw1.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ping! Can we make progress with this issue? I think there were no objections to your proposal. > From: Visuwesh > Cc: Eli Zaretskii , 70820@debbugs.gnu.org > Date: Wed, 14 Aug 2024 08:13:42 +0530 > > [செவ்வாய் ஆகஸ்ட் 13, 2024] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > > >> +(defun compilation--update-markers (loc marker screen-columns first-column) > >> + "Update markers in LOC, and set MARKER to location pointed by LOC. > >> +SCREEN-COLUMNS and FIRST-COLUMN are the value of > >> +`compilation-error-screen-columns' and `compilation-first-column' to use > >> +if they are not set buffer-locally in the target buffer." > >> + (with-current-buffer > >> + (if (bufferp (caar (compilation--loc->file-struct loc))) > >> + (caar (compilation--loc->file-struct loc)) > >> + (apply #'compilation-find-file > >> + marker > >> + (caar (compilation--loc->file-struct loc)) > >> + (cadr (car (compilation--loc->file-struct loc))) > >> + (compilation--file-struct->formats > >> + (compilation--loc->file-struct loc)))) > >> + (let ((screen-columns > >> + ;; Obey the compilation-error-screen-columns of the target > >> + ;; buffer if its major mode set it buffer-locally. > >> + (if (local-variable-p 'compilation-error-screen-columns) > >> + compilation-error-screen-columns screen-columns)) > >> + (compilation-first-column > >> + (if (local-variable-p 'compilation-first-column) > >> + compilation-first-column first-column)) > >> + (last 1)) > >> + (save-restriction > >> + (widen) > >> + (goto-char (point-min)) > >> + ;; Treat file's found lines in forward order, 1 by 1. > >> + (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) > >> + (when (car line) ; else this is a filename without a line# > >> + (compilation-beginning-of-line (- (car line) last -1)) > >> + (setq last (car line))) > >> + ;; Treat line's found columns and store/update a marker for each. > >> + (dolist (col (cdr line)) > >> + (if (compilation--loc->col col) > >> + (if (eq (compilation--loc->col col) -1) > >> + ;; Special case for range end. > >> + (end-of-line) > >> + (compilation-move-to-column (compilation--loc->col col) > >> + screen-columns)) > >> + (beginning-of-line) > >> + (skip-chars-forward " \t")) > >> + (if (compilation--loc->marker col) > >> + (set-marker (compilation--loc->marker col) (point)) > >> + (setf (compilation--loc->marker col) (point-marker))) > >> + ;; (setf (compilation--loc->timestamp col) timestamp) > >> + )))))) > > > > Are there any changes in this code, or is it "verbatim" the code > > extracted from `compilation-next-error-function`? > > It is extracted verbatim from compilation-next-error-function. > > >> +(defvar grep-edit-mode-hook nil > >> + "Hooks run when changing to Grep-Edit mode.") > > > > It's just "Hook" because `grep-edit-mode-hook` is a hook. Hooks contain > > functions, so when you run a hook, the corresponding functions are called. > > Ah, I was under the impression that the functions were also referred to > as hooks. I will correct them in a future patch. > > >> +(defun grep-edit-mode () > >> + "Major mode for editing *grep* buffers. > >> +In this mode, changes to the *grep* buffer are applied to the > >> +originating files. > >> +\\ > >> +Type \\[grep-edit-save-changes] to exit Grep-Edit mode, return to Grep > >> +mode. > >> + > >> +The only editable texts in a Grep-Edit buffer are the match results." > >> + (interactive) > >> + (error "This mode can be enabled only by `grep-change-to-grep-edit-mode'")) > >> +(put 'grep-edit-mode 'mode-class 'special) > >> + > >> +(defun grep-change-to-grep-edit-mode () > >> + "Switch to `grep-edit-mode' to edit *grep* buffer." > >> + (interactive) > >> + (unless (derived-mode-p 'grep-mode) > >> + (error "Not a Grep buffer")) > >> + (when (get-buffer-process (current-buffer)) > >> + (error "Cannot switch when grep is running")) > >> + (use-local-map grep-edit-mode-map) > >> + (grep-edit--prepare-buffer) > >> + (setq buffer-read-only nil) > >> + (setq major-mode 'grep-edit-mode) > >> + (setq mode-name "Grep-Edit") > >> + (buffer-enable-undo) > >> + (set-buffer-modified-p nil) > >> + (setq buffer-undo-list nil) > >> + (add-hook 'after-change-functions #'occur-after-change-function nil t) > >> + (run-mode-hooks 'grep-edit-mode-hook) > >> + (message "Editing: \\[grep-edit-save-changes] to return to Grep mode")) > > > > I'm tempted to say you should use `major-mode-suspend/resume` (which > > would avoid the duplication of parts of `grep-mode` in > > `grep-edit-save-changes`), but I guess this might re-introduce the > > problem with buffer-local variables. > > Yes, unfortunately it will re-introduce the problem with buffer-local > variables. > > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. > From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 31 04:05:13 2024 Received: (at 70820) by debbugs.gnu.org; 31 Aug 2024 08:05:13 +0000 Received: from localhost ([127.0.0.1]:53863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skJ6f-0006L0-7h for submit@debbugs.gnu.org; Sat, 31 Aug 2024 04:05:13 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:42355) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skJ6d-0006Kf-3B for 70820@debbugs.gnu.org; Sat, 31 Aug 2024 04:05:11 -0400 Received: by mail-pf1-f196.google.com with SMTP id d2e1a72fcca58-7142448aaf9so1782809b3a.1 for <70820@debbugs.gnu.org>; Sat, 31 Aug 2024 01:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725091387; x=1725696187; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Vvd9stiOh4al2WqNWrXlrcosLl4T5e+H0jIy55UGq0c=; b=fifw9Lm7dLDfC/3nAZIvBPtMEvlCqtUX6J/nZ3LgI6VtuF6BIyCvmekuVrDf/cLqV5 xVF7sGzheukWZ8huPNITH1b+zF+eXu1os8dDmtoszoXEpwcTh6nL5YbAg5q5LmAQxR3x 53sYWgzXqMEI3WzFKpo2slUTW6VgSSiPOov1BI/5vbeaHM/NEXY9VeWkI/YKOm4w2AJt QCB/SHj+WwB3qpnZecLGJTbtnYk5nrtWOkFgbynS6YVARtpm1sSHtRyYcfg3mmcb9zSF d0F+Ds37gIAP6K0u+N28/eziCZnigO4wLssJiS/I2lRLbSDLYdMeDxK2LomuW8OZcqXE i08Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725091387; x=1725696187; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Vvd9stiOh4al2WqNWrXlrcosLl4T5e+H0jIy55UGq0c=; b=fcTYd4TkQCbPVFoALnwOXI6M9EiH/YvuPt/CbfPO2aVJXPidL3+Y6/CDN3nCmCyNds S9NFuY/VEUGdCcBd9aSWqAaBFSTf2nm8ikHRCawouOf8S8BIO4ergdwgn8Yy4TLCo0Cx azGei14Y0sUOOhqsgqDS9kPsX7LO7z+vDPBNsL9HHm7dvLU86sXeVwFpJ19s2o3ZJUHV Op2uXbyFQdpJTwjAax5pmyGE6pmEiQ1Axfk3NOFynwLYtyQijIRcWNXTYvDE3y8GqTyF VKAgFM2z1SgQTuVGBTT7y6WlfonZDfIIF3yy3FfiMcxefk81TN1csa2+Q9OGIeTn7Cuy Mz8A== X-Forwarded-Encrypted: i=1; AJvYcCWNXY1LPEY6S8U7VjlqkA82HtRm2SXUe+2hC+S/rPH0Li+63fzmFNTZPNMbZjlI7Ew6/BGw5Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwbySFtQgFGgG4akfqU01+lSMu0/WnR8MENaByMeNAMMDam/XUm HsD5aAceyMgQnqWATZN0mm5jfyLlHubtXoBV/cspGpGcQY/psoZN X-Google-Smtp-Source: AGHT+IFaQx2DKvBy/wkwfbmwsurYa6W/XkVg6MDlp8+j+a414MItyvw0sUmKxqtUXWSq1g7Ffu5M7A== X-Received: by 2002:a05:6a00:8717:b0:710:9d5e:1154 with SMTP id d2e1a72fcca58-715e0f775a4mr10349593b3a.2.1725091387058; Sat, 31 Aug 2024 01:03:07 -0700 (PDT) Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-715e569e220sm3816797b3a.132.2024.08.31.01.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Aug 2024 01:03:06 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <86y14dcekb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 31 Aug 2024 10:54:44 +0300") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> <87bk1vzuw1.fsf@gmail.com> <86y14dcekb.fsf@gnu.org> Date: Sat, 31 Aug 2024 13:33:03 +0530 Message-ID: <871q25glvs.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [சனி ஆகஸ்ட் 31, 2024] Eli Zaretskii wrote: > Ping! Can we make progress with this issue? I think there were no > objections to your proposal. I will send a proper patch in the coming week then. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.210.196 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.196 listed in list.dnswl.org] 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [209.85.210.196 listed in bl.score.senderscore.com] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 70820 Cc: 70820@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=86=E0=AE=95=E0=AE=B8=E0=AF=8D=E0=AE=9F= =E0=AF=8D 31, 2024] Eli Zaretskii wrote: > Ping! Can we make progress with this issue? I think there were no > objections to your proposal. I will send a proper patch in the coming week then. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 09 10:40:41 2024 Received: (at 70820) by debbugs.gnu.org; 9 Sep 2024 14:40:41 +0000 Received: from localhost ([127.0.0.1]:33824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snfZI-0001d1-Ol for submit@debbugs.gnu.org; Mon, 09 Sep 2024 10:40:41 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:52506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snfZG-0001cm-W1 for 70820@debbugs.gnu.org; Mon, 09 Sep 2024 10:40:39 -0400 Received: by mail-pl1-f196.google.com with SMTP id d9443c01a7336-20543fdb7acso30273755ad.1 for <70820@debbugs.gnu.org>; Mon, 09 Sep 2024 07:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725892769; x=1726497569; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=vy9w9Cwo+VJJSKlz1o/cqA9vaLR9WF6DrTojsU34TZw=; b=Ty2O+zKlYkbfzhaNf5aoKQLeU87hi72LHEwaKkNcbvyWvcKRfk7xIAW88w9eVNDwtu YPcHxPcnNhcFF4E8QdFkvtmPZ+PP9ZOuR5jK+bWsT8kZEGvZj53Ol5CIhRa1PNTdMmUJ 7hdSQVSZgIPzFFGYHfdb4I+YFutHaxcbB6qFXvlz/2byTfbZfoCEf949LBHUo2PmWgg9 OKKPESg6bTJV4jpSwJN6bEWEPFe2Qe+rgH8qJfbhuxd96jwcKtliOUfxjpdqxrptEsFt cjz3C2PqNQ/UfiL3/jWOXGI3diMLW4y7oqXFjXEic4J9ajXqLZn+lDLpu4hNV5BMRYas 98HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725892769; x=1726497569; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vy9w9Cwo+VJJSKlz1o/cqA9vaLR9WF6DrTojsU34TZw=; b=jgfSKupwRW6psQXDLw+m5o3YqaBD3artOW/I24O4OHjnRPl4l9OYDRZQYiR/TRwbP/ Nq0MZAAPIYqiciM1ndm3B2uo+lwqj1zMq+RCJmggnYTJZgfYUpmdq9Rs6XkkI+UR5cdK N5btKwMDsg/gDNhOYD5LlGmu6xEkK4GQ0hTiIcejONa6EHScMZBrswZOkwPhSvIXubOt 7U2ULYBMkLfstLW0KLWEFyAQmC+yME5RANzHLno08N2rnm4ui1bBwxFWcqhaBPq0+MSv V0sXAgy+apHnz8ZkQ7pyfaHCKhpP87IOT/NbZMEKDvx4M7DcXh9tkokpTiio7QNjGDYR Xy4Q== X-Forwarded-Encrypted: i=1; AJvYcCWzKVXZQRGdZlc9BTNZhfnKxzGiuP+BFqtUiA5Vy3AAdhbIVHMGznK0QK04Z+sm/4bCHJG9tg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwZibLeJERvYTDSZKfeAHw+rfMex17don4sfANb7G1Ubf+0FL+2 V9wOgT+E1Y3RRytUgg93hEYwcukL/z7RJdbIJAIQyc7Lh8Gq3mZ0 X-Google-Smtp-Source: AGHT+IEwj3V/c2vbKrlkIgEbdw//A9WbqPeVQ/E9Cwfhnlyt1xBH9M4FyJFw4H8UaXTv+C9/ERuGsQ== X-Received: by 2002:a17:902:d2d2:b0:206:b79e:5780 with SMTP id d9443c01a7336-206f0507dc6mr121792245ad.24.1725892769020; Mon, 09 Sep 2024 07:39:29 -0700 (PDT) Received: from localhost ([1.7.159.70]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20710e33a92sm34770385ad.105.2024.09.09.07.39.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 07:39:28 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#70820: [PATCH] Editable grep buffers In-Reply-To: <87bk1vzuw1.fsf@gmail.com> (Visuwesh's message of "Wed, 14 Aug 2024 08:13:42 +0530") References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> <87bk1vzuw1.fsf@gmail.com> Date: Mon, 09 Sep 2024 20:09:22 +0530 Message-ID: <8734m8opr9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 3.6 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [புதன் ஆகஸ்ட் 14, 2024] Visuwesh wrote: > [...] > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. Sorry for the long delay. I've now attached a patch with such documentation changes. Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.70 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.196 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.214.196 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 70820 Cc: Eli Zaretskii , 70820@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [புதன் ஆகஸ்ட் 14, 2024] Visuwesh wrote: > [...] > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. Sorry for the long delay. I've now attached a patch with such documentation changes. Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.214.196 listed in wl.mailspike.net] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.70 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.196 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=86=E0=AE=95=E0=AE=B8= =E0=AF=8D=E0=AE=9F=E0=AF=8D 14, 2024] Visuwesh wrote: > [...] > If everyone is okay with the current patch, I can get to writing the > NEWS entry and updating the manual. Thanks. Sorry for the long delay. I've now attached a patch with such documentation changes. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Make-the-grep-buffer-editable.patch >From 52e4d82dd3f28065e5e3ea390c4629783bcf139d Mon Sep 17 00:00:00 2001 From: Visuwesh Date: Mon, 9 Sep 2024 20:08:04 +0530 Subject: [PATCH] Make the *grep* buffer editable * lisp/progmodes/compile.el (compilation--update-markers): Factor out function... (compilation-next-error-function): from here. Adjust to use above. * lisp/progmodes/grep.el (grep-edit--prepare-buffer) (grep-edit-mode-map, grep-edit-mode-hook, grep-edit-mode) (grep-change-to-grep-edit-mode, grep-edit-save-changes): Add new grep-edit-mode to make the grep results editable like in 'occur-edit-mode' by using the 'occur' framework. (grep-mode-map): Bind 'e' to the new command 'grep-change-to-grep-edit-mode'. * doc/emacs/building.texi (Grep Searching): Update Info manual to include the above command. * etc/NEWS: Announce the change. (bug#70820) --- doc/emacs/building.texi | 10 +++++ etc/NEWS | 9 ++++ lisp/progmodes/compile.el | 95 +++++++++++++++++++++------------------ lisp/progmodes/grep.el | 86 +++++++++++++++++++++++++++++++++++ 4 files changed, 156 insertions(+), 44 deletions(-) diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi index bb03d8cf325..4b2f1ed0649 100644 --- a/doc/emacs/building.texi +++ b/doc/emacs/building.texi @@ -528,6 +528,16 @@ Grep Searching shell commands, customize the option @code{grep-find-abbreviate} to a @code{nil} value. +@findex grep-change-to-grep-edit-mode +@cindex Grep Edit mode +@cindex mode, Grep Edit + Typing @kbd{e} in the @file{*grep*} buffer makes the buffer writiable +and enters the Grep Edit mode. Similar to Occur Edit mode (@pxref{Other +Repeating Search}), you can edit the matching lines reported by +@code{grep} and have those changes reflected in the buffer visiting the +originating file. Type @kbd{C-c C-c} to leave the Grep Edit mode and +return to the Grep mode. + @node Flymake @section Finding Syntax Errors On The Fly @cindex checking syntax diff --git a/etc/NEWS b/etc/NEWS index c6f8b0062e4..24b43108ecb 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -290,6 +290,15 @@ the built-in Web server. Interactively, when invoked with a prefix argument, 'php-ts-mode-run-php-webserver' prompts for the config file as well as for other connection parameters. +** Grep + ++++ +*** Grep results can be edited to reflect changes in the originating file. +Like Occur Edit mode, typing 'e' in the '*grep*' buffer will now make +the 'grep' results editable. The edits will be reflected in the buffer +visiting the originating file. Typing 'C-c C-c' will leave the Grep +Edit mode. + * New Modes and Packages in Emacs 31.1 diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index d2e74aa44a6..a78ac1b6462 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -2855,6 +2855,53 @@ compilation-find-buffer (current-buffer) (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))) +(defun compilation--update-markers (loc marker screen-columns first-column) + "Update markers in LOC, and set MARKER to location pointed by LOC. +SCREEN-COLUMNS and FIRST-COLUMN are the value of +`compilation-error-screen-columns' and `compilation-first-column' to use +if they are not set buffer-locally in the target buffer." + (with-current-buffer + (if (bufferp (caar (compilation--loc->file-struct loc))) + (caar (compilation--loc->file-struct loc)) + (apply #'compilation-find-file + marker + (caar (compilation--loc->file-struct loc)) + (cadr (car (compilation--loc->file-struct loc))) + (compilation--file-struct->formats + (compilation--loc->file-struct loc)))) + (let ((screen-columns + ;; Obey the compilation-error-screen-columns of the target + ;; buffer if its major mode set it buffer-locally. + (if (local-variable-p 'compilation-error-screen-columns) + compilation-error-screen-columns screen-columns)) + (compilation-first-column + (if (local-variable-p 'compilation-first-column) + compilation-first-column first-column)) + (last 1)) + (save-restriction + (widen) + (goto-char (point-min)) + ;; Treat file's found lines in forward order, 1 by 1. + (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) + (when (car line) ; else this is a filename without a line# + (compilation-beginning-of-line (- (car line) last -1)) + (setq last (car line))) + ;; Treat line's found columns and store/update a marker for each. + (dolist (col (cdr line)) + (if (compilation--loc->col col) + (if (eq (compilation--loc->col col) -1) + ;; Special case for range end. + (end-of-line) + (compilation-move-to-column (compilation--loc->col col) + screen-columns)) + (beginning-of-line) + (skip-chars-forward " \t")) + (if (compilation--loc->marker col) + (set-marker (compilation--loc->marker col) (point)) + (setf (compilation--loc->marker col) (point-marker))) + ;; (setf (compilation--loc->timestamp col) timestamp) + )))))) + ;;;###autoload (defun compilation-next-error-function (n &optional reset) "Advance to the next error message and visit the file where the error was. @@ -2864,7 +2911,6 @@ compilation-next-error-function (setq compilation-current-error nil)) (let* ((screen-columns compilation-error-screen-columns) (first-column compilation-first-column) - (last 1) (msg (compilation-next-error (or n 1) nil (or compilation-current-error compilation-messages-start @@ -2876,9 +2922,9 @@ compilation-next-error-function (user-error "No next error")) (setq compilation-current-error (point-marker) overlay-arrow-position - (if (bolp) - compilation-current-error - (copy-marker (line-beginning-position)))) + (if (bolp) + compilation-current-error + (copy-marker (line-beginning-position)))) ;; If loc contains no marker, no error in that file has been visited. ;; If the marker is invalid the buffer has been killed. ;; So, recalculate all markers for that file. @@ -2895,46 +2941,7 @@ compilation-next-error-function ;; (equal (compilation--loc->timestamp loc) ;; (setq timestamp compilation-buffer-modtime))) ) - (with-current-buffer - (if (bufferp (caar (compilation--loc->file-struct loc))) - (caar (compilation--loc->file-struct loc)) - (apply #'compilation-find-file - marker - (caar (compilation--loc->file-struct loc)) - (cadr (car (compilation--loc->file-struct loc))) - (compilation--file-struct->formats - (compilation--loc->file-struct loc)))) - (let ((screen-columns - ;; Obey the compilation-error-screen-columns of the target - ;; buffer if its major mode set it buffer-locally. - (if (local-variable-p 'compilation-error-screen-columns) - compilation-error-screen-columns screen-columns)) - (compilation-first-column - (if (local-variable-p 'compilation-first-column) - compilation-first-column first-column))) - (save-restriction - (widen) - (goto-char (point-min)) - ;; Treat file's found lines in forward order, 1 by 1. - (dolist (line (reverse (cddr (compilation--loc->file-struct loc)))) - (when (car line) ; else this is a filename without a line# - (compilation-beginning-of-line (- (car line) last -1)) - (setq last (car line))) - ;; Treat line's found columns and store/update a marker for each. - (dolist (col (cdr line)) - (if (compilation--loc->col col) - (if (eq (compilation--loc->col col) -1) - ;; Special case for range end. - (end-of-line) - (compilation-move-to-column (compilation--loc->col col) - screen-columns)) - (beginning-of-line) - (skip-chars-forward " \t")) - (if (compilation--loc->marker col) - (set-marker (compilation--loc->marker col) (point)) - (setf (compilation--loc->marker col) (point-marker))) - ;; (setf (compilation--loc->timestamp col) timestamp) - )))))) + (compilation--update-markers loc marker screen-columns first-column)) (compilation-goto-locus marker (compilation--loc->marker loc) (compilation--loc->marker end-loc)) (setf (compilation--loc->visited loc) t))) diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index d2d0baa235c..54006560224 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -310,6 +310,8 @@ grep-mode-map (define-key map "}" #'compilation-next-file) (define-key map "\t" #'compilation-next-error) (define-key map [backtab] #'compilation-previous-error) + + (define-key map "e" #'grep-change-to-grep-edit-mode) map) "Keymap for grep buffers. `compilation-minor-mode-map' is a cdr of this.") @@ -1052,6 +1054,90 @@ grep command-args) #'grep-mode)) +(defun grep-edit--prepare-buffer () + "Mark relevant regions read-only, and add relevant occur text-properties." + (save-excursion + (goto-char (point-min)) + (let ((inhibit-read-only t) + (dummy (make-marker)) + match) + (while (setq match (text-property-search-forward 'compilation-annotation)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t))) + (goto-char (point-min)) + (while (setq match (text-property-search-forward 'compilation-message)) + (add-text-properties (prop-match-beginning match) (prop-match-end match) + '(read-only t occur-prefix t)) + (let ((loc (compilation--message->loc (prop-match-value match))) + m) + ;; Update the markers if necessary. + (unless (and (compilation--loc->marker loc) + (marker-buffer (compilation--loc->marker loc))) + (compilation--update-markers loc dummy compilation-error-screen-columns compilation-first-column)) + (setq m (compilation--loc->marker loc)) + (add-text-properties (prop-match-beginning match) + (or (next-single-property-change + (prop-match-end match) + 'compilation-message) + (1+ (pos-eol))) + `(occur-target ((,m . ,m))))))))) + +(defvar grep-edit-mode-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map text-mode-map) + (define-key map (kbd "C-c C-c") #'grep-edit-save-changes) + map) + "Keymap for `grep-edit-mode'.") + +(defvar grep-edit-mode-hook nil + "Hooks run when changing to Grep-Edit mode.") + +(defun grep-edit-mode () + "Major mode for editing *grep* buffers. +In this mode, changes to the *grep* buffer are applied to the +originating files. +\\ +Type \\[grep-edit-save-changes] to exit Grep-Edit mode, return to Grep +mode. + +The only editable texts in a Grep-Edit buffer are the match results." + (interactive) + (error "This mode can be enabled only by `grep-change-to-grep-edit-mode'")) +(put 'grep-edit-mode 'mode-class 'special) + +(defun grep-change-to-grep-edit-mode () + "Switch to `grep-edit-mode' to edit *grep* buffer." + (interactive) + (unless (derived-mode-p 'grep-mode) + (error "Not a Grep buffer")) + (when (get-buffer-process (current-buffer)) + (error "Cannot switch when grep is running")) + (use-local-map grep-edit-mode-map) + (grep-edit--prepare-buffer) + (setq buffer-read-only nil) + (setq major-mode 'grep-edit-mode) + (setq mode-name "Grep-Edit") + (buffer-enable-undo) + (set-buffer-modified-p nil) + (setq buffer-undo-list nil) + (add-hook 'after-change-functions #'occur-after-change-function nil t) + (run-mode-hooks 'grep-edit-mode-hook) + (message "Editing: \\[grep-edit-save-changes] to return to Grep mode")) + +(defun grep-edit-save-changes () + "Switch back to Grep mode." + (interactive) + (unless (derived-mode-p 'grep-edit-mode) + (error "Not a Grep-Edit buffer")) + (remove-hook 'after-change-functions #'occur-after-change-function t) + (use-local-map grep-mode-map) + (setq buffer-read-only t) + (setq major-mode 'grep-mode) + (setq mode-name "Grep") + (force-mode-line-update) + (buffer-disable-undo) + (setq buffer-undo-list t) + (message "Switching to Grep mode")) ;;;###autoload (defun grep-find (command-args) -- 2.45.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 14 05:44:14 2024 Received: (at 70820-done) by debbugs.gnu.org; 14 Sep 2024 09:44:14 +0000 Received: from localhost ([127.0.0.1]:44832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spPK9-0001aJ-My for submit@debbugs.gnu.org; Sat, 14 Sep 2024 05:44:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spPK7-0001a0-5p for 70820-done@debbugs.gnu.org; Sat, 14 Sep 2024 05:44:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spPJr-000839-7i; Sat, 14 Sep 2024 05:43:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lF7r3XLg6dcoaXrF9+NypG+tDvS1JQrWItuYgJEdJew=; b=RyQf14UNme+gzDoRCdJH tEfEdiHV/5dHv1d5hTIPaUp5KS0VETtb2BrgiEarI7jUXKSPc55ru73FdsfM0HXjSreGvxuUH4yCN bYgwUFG4nifqdSlNQZlq8pH3vwIbdq3q6dPYRgky/sIiw7Y0/I9jH4vCyCDogY92VmjjBxwYbzAIw kJhauYY3LeoVlsClKVheXn7cOUCo7pHFmDNrTl2A0TiKH/vad6SAGQcOFTJ9F3ZoJZPmYeMy0MXrg TUPg4XDZk3W3An4YXCc+5GhwjpVyu3viBwFmKlj+m61tviW+x5L3oC7CVO3OeUcIImC6PDYzD93b2 lYG4lxEWSJOfLA==; Date: Sat, 14 Sep 2024 12:43:52 +0300 Message-Id: <86jzfeh8o7.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <8734m8opr9.fsf@gmail.com> (message from Visuwesh on Mon, 09 Sep 2024 20:09:22 +0530) Subject: Re: bug#70820: [PATCH] Editable grep buffers References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> <878r0klcp1.fsf@gmail.com> <864jb89zwq.fsf@gnu.org> <87wmo3jmws.fsf@gmail.com> <87fruny6xe.fsf@gmail.com> <86le47eafb.fsf@gnu.org> <86pltjceft.fsf@gnu.org> <86ikzbcces.fsf@gnu.org> <87le1lj4pv.fsf@gmail.com> <87bk1vzuw1.fsf@gmail.com> <8734m8opr9.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70820-done Cc: 70820-done@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Visuwesh > Cc: Eli Zaretskii , 70820@debbugs.gnu.org > Date: Mon, 09 Sep 2024 20:09:22 +0530 > > [புதன் ஆகஸ்ட் 14, 2024] Visuwesh wrote: > > > [...] > > If everyone is okay with the current patch, I can get to writing the > > NEWS entry and updating the manual. Thanks. > > Sorry for the long delay. I've now attached a patch with such > documentation changes. Thanks, installed on the master branch, and closing the bug. From unknown Fri Aug 15 04:07:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 12 Oct 2024 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator