From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#70820: [PATCH] Editable grep buffers Date: Wed, 08 May 2024 17:48:02 +0530 Message-ID: <878r0klcp1.fsf@gmail.com> References: <87seytlhcq.fsf@gmail.com> <86pltxa40q.fsf@gnu.org> <87jzk5kmwk.fsf@gmail.com> <86ikzoa51h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20260"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 70820@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 08 14:19:10 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 1s4gGM-0005DB-It for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 May 2024 14:19:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4gFs-00030L-4m; Wed, 08 May 2024 08:18:40 -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 1s4gFp-0002tt-Ob for bug-gnu-emacs@gnu.org; Wed, 08 May 2024 08:18:38 -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 1s4gFp-0006Zh-G8 for bug-gnu-emacs@gnu.org; Wed, 08 May 2024 08:18:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s4gGE-0002ob-Hb for bug-gnu-emacs@gnu.org; Wed, 08 May 2024 08:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 May 2024 12:19: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.171517071910781 (code B ref 70820); Wed, 08 May 2024 12:19:02 +0000 Original-Received: (at 70820) by debbugs.gnu.org; 8 May 2024 12:18:39 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <86ikzoa51h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 May 2024 14:58:50 +0300") 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:284671 Archived-At: [=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.