From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70820: [PATCH] Editable grep buffers Date: Sat, 18 May 2024 12:28:24 +0300 Message-ID: <86le47eafb.fsf@gnu.org> 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24578"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70820@debbugs.gnu.org To: Visuwesh , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 18 11:29:13 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s8GNN-0006Ao-QL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 May 2024 11:29:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s8GNC-0005FM-UO; Sat, 18 May 2024 05:29:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8GNA-0005Ew-5f for bug-gnu-emacs@gnu.org; Sat, 18 May 2024 05:29:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s8GN8-0004xC-Q9 for bug-gnu-emacs@gnu.org; Sat, 18 May 2024 05:28:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s8GNC-0000J3-3r for bug-gnu-emacs@gnu.org; Sat, 18 May 2024 05:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 May 2024 09:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70820 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70820-submit@debbugs.gnu.org id=B70820.17160245191165 (code B ref 70820); Sat, 18 May 2024 09:29:02 +0000 Original-Received: (at 70820) by debbugs.gnu.org; 18 May 2024 09:28:39 +0000 Original-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 Original-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 Original-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==; In-Reply-To: <87fruny6xe.fsf@gmail.com> (message from Visuwesh on Sun, 12 May 2024 10:15:33 +0530) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:285304 Archived-At: > 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?)