From unknown Tue Jun 17 20:16:01 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#77732 <77732@debbugs.gnu.org> To: bug#77732 <77732@debbugs.gnu.org> Subject: Status: grep-edit-buffer errors with incionsistent behaviour Reply-To: bug#77732 <77732@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:16:01 +0000 retitle 77732 grep-edit-buffer errors with incionsistent behaviour reassign 77732 emacs submitter 77732 Johann H=C3=B6chtl severity 77732 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 05:34:23 2025 Received: (at submit) by debbugs.gnu.org; 11 Apr 2025 09:34:23 +0000 Received: from localhost ([127.0.0.1]:48762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3AmE-0005Sl-Qf for submit@debbugs.gnu.org; Fri, 11 Apr 2025 05:34:23 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37312) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3AmC-0005SW-73 for submit@debbugs.gnu.org; Fri, 11 Apr 2025 05:34:20 -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 1u3Am6-00068j-OK for bug-gnu-emacs@gnu.org; Fri, 11 Apr 2025 05:34:14 -0400 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1u3Am5-0007XL-7J for bug-gnu-emacs@gnu.org; Fri, 11 Apr 2025 05:34:14 -0400 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-7043db8491dso18244937b3.0 for ; Fri, 11 Apr 2025 02:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744364051; x=1744968851; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=RF6cALKpFI/lwOeQ/Nc/1TjY/bh4ZozgF+82LxEA4HM=; b=im/WREMqv6wY8G4wPK58071bcogKSZLNWpskw5DwORJidUgiotYhGN8Sn2zXct3fyp EiYsL7vKdQHEIY9NvAd/YQLTgguJVyJE0bZforBOnYlKjk2Q6Xb8z+Eow2gBYepXQ/ut vqP66lfueIDO5SuDRa4V+FO/ddpMEu6aoTmPF8TLFyV0IBzoiO4VxrGZdhchJf3pq3Ra jKcbmE2eGiX/1V0Njgz9BQ4I2jBGtAx9aHuVdqvajTANNmqVlyh/5O3clxpL9i5HSRnq PDKHKAIGrcWwuP8RsuS1COIQ/K6YIqIpnPkNm55AT2iGqlEteqDMKbGZU8kqI8tOGGL5 9uRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744364051; x=1744968851; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RF6cALKpFI/lwOeQ/Nc/1TjY/bh4ZozgF+82LxEA4HM=; b=RnmudyUKQnzR3bl3jLBQo7VP8syxYbApGWu5gsbyb4CSN3+xzai5xGqT+CG3xid0kD +LVUqiRVoD0y95yuDx37aiWsLL9KoySE4Oi4ZLr+BJ8S74ZsBYGKNUEtg0jEudN4b9Tk Z32mCwbW9JJ/6oGUxZxU4edukOwThgFmPMc7OjJ+b0zqOKMx7PO3r6+2CMt/zdky9Aam XjPxVL4MXvQanrsKtZlbL35fkEBpLLuQY74zl6vsd2/e8o+URYBnqmJLxyxP4dfuw6d0 cOjnJrD17ZeoJ1ngY1LqwMrhbfzJL0RiPJtgIwxuDsvSPzdMgHdg6uWSj80mmsUGaDlL lCaA== X-Gm-Message-State: AOJu0YymHsWXKsVN6x/1MmAY0y8kVUnP+oOhoHY0KhPkvf5aPRFjqbSc oZXx3JasBAZmf97gYNEVOjoN/cCx00JQp3XUleoLG6s2EfeLR9Vi44AbAp8GBZ+nlvvKGHInVSP QFruggSq5QQp+Ep90e/G9bBP16+qlRcw= X-Gm-Gg: ASbGncvJOM3hWfp5OZ2ogRThNK9LzBDKUMsP5Ir+8qIbv0Fa7QrWYdKJnP+wraJKIwC Cpx3jRrGUhAlVBlJ3iLGjKUyzMpW+DLpcOV00i28btGbSrDPvIa8xPv+eKCXbdYBGmhU9tuTjJc 7UXroZQCcLV+rzXVJH4v88Rg== X-Google-Smtp-Source: AGHT+IF/Tqq5j7hGvGaCRuBqcyRezZC+dFRUauSG2ovi3krpj5XIzFOs6yVvKJ9jGFHDrJ8m5SkcYkrEY0vElFxkpGA= X-Received: by 2002:a05:690c:45c4:b0:6ff:28b2:50bd with SMTP id 00721157ae682-70559981602mr32821057b3.2.1744364051416; Fri, 11 Apr 2025 02:34:11 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Johann_H=C3=B6chtl?= Date: Fri, 11 Apr 2025 11:33:59 +0200 X-Gm-Features: ATxdqUHafRUnuUC41DjDcDNZbgGEQSO4FAZmfH8rzBEP4hpUf6G-9nnI6aozt-g Message-ID: Subject: grep-edit-buffer errors with incionsistent behaviour To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000a4d48806327d6768" Received-SPF: pass client-ip=2607:f8b0:4864:20::112c; envelope-from=johann.hoechtl@gmail.com; helo=mail-yw1-x112c.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, HTML_MESSAGE=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 (/) --000000000000a4d48806327d6768 Content-Type: text/plain; charset="UTF-8" I am using Emacs from HEAD on Windows I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent. When I rgrep and there are few results (< 15) , I can enter grep buffer pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter with 'e' and so on. When there are more results, (between 15 and 70) I still can enter with 'e' get out with C-c C-c but when I try to re-enter I get the error message Wrong type argument: stringp, nil The buffer later although still in grp-mode does not behave any longer as a grep mode, 'g' or 'e' results in the error Buffer is read only : # When there are many results, I get the error message Wrong type argument: stringp, nil already on the first invocation attempt. Thew boundaries are somewhat moving but at least I have the feeling the more matches are, the more frequently I run into the Wrong type argument: stringp, nil already at first try. --000000000000a4d48806327d6768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am using Emacs from HEAD on Window= s

I tried to reproduce the behaviour with emacs -Q= but it still remains inconsistent.

When I rgrep a= nd there are few results (< 15) , I can enter grep buffer pres 'e= 9; to enter grep-edit mode, get out of it with C-c C-c, re-enter with '= e' and so on.

When there are more results,= (between 15 and 70)=C2=A0 I still can enter with 'e' get out with = C-c C-c but when I try to re-enter I get the error message Wrong type argum= ent: stringp, nil
The buffer later although still in grp-mode doe= s not behave any longer as a grep mode, 'g' or 'e' results = in the error Buffer is read only : #<buffer *grep*>

When there are many results, I get the error message=20 Wrong type argument: stringp, nil already on the first invocation attempt.<= /div>

Thew boundaries are somewhat moving but at least I= have the feeling the more matches are, the more frequently I run into the =

Wrong type argument: stringp, nil

already at = first try.
--000000000000a4d48806327d6768-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 06:38:08 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 10:38:08 +0000 Received: from localhost ([127.0.0.1]:48943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3Blw-0000Ze-1j for submit@debbugs.gnu.org; Fri, 11 Apr 2025 06:38:08 -0400 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:43172) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3Blt-0000Z6-1b for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 06:38:05 -0400 Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-225df540edcso29826525ad.0 for <77732@debbugs.gnu.org>; Fri, 11 Apr 2025 03:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744367879; x=1744972679; 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=e5/PwgdCozFitc7uvgNkzRXV7WRS696eqYb9GAT0QIc=; b=l+xZ57Xjv7/ABNdZPeJJJ+csZOxRYz0XUJXQl/eQjnIIEct2HHn+ftSCZQ6DV0tx1C rkvivGBkxRfMkDgypFMHDm8ZB3LwPf1VY/t4oCUgO5vSuKZcex075YvSzPdJusfVCZ6r MnhZN/5VDhPmv6cwwatftF8n6BppNw0txLdV38GamBTRQNMSBoY3aEp7t9rJZ2ZfM8yK XQrgfZs5im7CSonSuWmqK3YXqSaTqQ1ihsigOt+B/61jqrXiWbaE8G84vmI9j+5gnLR/ gu2b4mfHQqpxdoX2gVM2+E0P4tX8EAS50K7maldyRK+rrFHPi7tl3g6Kx/CgpmwV0TS0 FEvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744367879; x=1744972679; 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=e5/PwgdCozFitc7uvgNkzRXV7WRS696eqYb9GAT0QIc=; b=JhmxTNrKIRK30/BIj3gCf2w+m815mNodITsFkVQA0DweiysnzQQx6Jlo/yrQbJpSdF YK/JvTL/IFsJfnV/bd/6E4ei+dII7GCZAXgR48RUJp4sZ3vQjn78QG06AL0mX9UQupQO wc7Lsv3mlHWMEQ2ICqpZTA9RJ6ma2aNSxJ+GHUeAZAR4vvL+xghvPjDIakrjY6O/l5uJ DbjnmbU0n0UBHajwAiRMgast2Ug8BzviCspaLo1edIUm0E51yoQzSqkw07JRAEyf7OKr Gbl9WLWBL9144uETj2QU41sOIlK3uk5913gdeFq6sa7mHT4QZOPb585hzyz1XpQfKiw/ U9wg== X-Gm-Message-State: AOJu0YzhEg3+wfMS/VD9U3itXft9dLjkkZ3BiCFGVH8mlzMBSVFpP456 H5jm+UnDHLyGMQPrje0DkvSjo6JZgQR2qoBo9LlTaCXF7YleIQG4 X-Gm-Gg: ASbGnctDSZk6F3n5ychXHc6ydTe9ARYyGZRNZLyFc28KO/KR+Arahm1Ea4Uz3hp78GY FVTsCIPNywLaJi3e2nVrCuJUCGRf5UNoJ8AFpk4yds4197pAarO8+Q9sWH12ibRRcVv59Y1XznF FlNyCVNKQPSrw2J4BIxWhAWV6VU5JdJ8Mu8OzAZbvsZn0R5NdBQBKWRLypzi5YymrJxHTKQmmJc EivSx2PDoMumCAVwkBplrcZAqDocn7XsXLpJURAa7g8RTfQhJtO6Py4OCvmYgw+D/M4YVJyZLL8 dt7r9QfRdD7pm8PGvkobluhPxCC2KJvXRnbzE+8ZTAZj0ua7UFrx X-Google-Smtp-Source: AGHT+IH71UfMU3uDYegnfFVWUKpV+QBeVeAYyv8I5+fJZMkvU5qfeeWvTjKADgdCttTHgeefTbdL7w== X-Received: by 2002:a17:903:8cd:b0:224:3994:8a8c with SMTP id d9443c01a7336-22b69474cb3mr93968535ad.8.1744367878627; Fri, 11 Apr 2025 03:37:58 -0700 (PDT) Received: from localhost ([1.7.159.71]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-22ac7b65112sm45467135ad.19.2025.04.11.03.37.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Apr 2025 03:37:58 -0700 (PDT) From: Visuwesh To: Johann =?utf-8?Q?H=C3=B6chtl?= Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: References: Date: Fri, 11 Apr 2025 16:07:54 +0530 Message-ID: <87plhj7zlp.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: [வெள்ளி ஏப்ரல் 11, 2025] Johann Höchtl wrote: > I am using Emacs from HEAD on Windows > > I tried to reproduce the behaviour with emacs -Q but it still remains > inconsistent. > > When I rgrep and there are few results (< 15) , I can enter grep b [...] Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -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) 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.71 listed in zen.spamhaus.org] -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: 77732 Cc: 77732@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: [வெள்ளி ஏப்ரல் 11, 2025] Johann Höchtl wrote: > I am using Emacs from HEAD on Windows > > I tried to reproduce the behaviour with emacs -Q but it still remains > inconsistent. > > When I rgrep and there are few results (< 15) , I can enter grep b [...] 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 [1.7.159.71 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=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE=AA= =E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Johann H=C3=B6chtl wrote: > I am using Emacs from HEAD on Windows > > I tried to reproduce the behaviour with emacs -Q but it still remains > inconsistent. > > When I rgrep and there are few results (< 15) , I can enter grep buffer > pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter wi= th > 'e' and so on. > > When there are more results, (between 15 and 70) I still can enter with > 'e' get out with C-c C-c but when I try to re-enter I get the error messa= ge > Wrong type argument: stringp, nil > The buffer later although still in grp-mode does not behave any longer as= a > grep mode, 'g' or 'e' results in the error Buffer is read only : # *grep*> > > When there are many results, I get the error message Wrong type argument: > stringp, nil already on the first invocation attempt. > > Thew boundaries are somewhat moving but at least I have the feeling the > more matches are, the more frequently I run into the > > Wrong type argument: stringp, nil > > already at first try. Can you please share the backtrace? Say M-x toggle-debug-on-error RET before trying to reproduce the error above. I mostly tested grep-edit-mode with M-x rgrep, and a good amount of results. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 07:51:54 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 11:51:54 +0000 Received: from localhost ([127.0.0.1]:49220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3CvJ-0007Na-PM for submit@debbugs.gnu.org; Fri, 11 Apr 2025 07:51:54 -0400 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]:42151) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3CvG-0007NF-Mw for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 07:51:51 -0400 Received: by mail-pg1-x541.google.com with SMTP id 41be03b00d2f7-af52a624283so1625508a12.0 for <77732@debbugs.gnu.org>; Fri, 11 Apr 2025 04:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744372304; x=1744977104; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=QEZFCc5PMkMuprUJCMDWccWRpZGl5H50kw9rdUzWlIQ=; b=HwUT0/Jk3D1ZTro01wE8SEWgTgpcemnqezA8RPZry2v8f58YSayib9IBhMHvuBauWK l2xmyLWTfFpdyBGzGE+xcN9s69D0+9ykr2O4K8SdQafVIh7bs0nOQFwGemzfErVcSz5f gq6YUMiqj5wPhqfjTbje49uPYeOc8cO5O6PUX3lo0wvCFEA3nSv4t75FUYDez0KzcuiX zQGx3y//c3gtg7vxd31dyD1vyiad43u59cgIa0E5Maf3mcGIcsYAI2G+z8qfTnEIoGFi tdn5Jvlus/zZrykDECQ5PzLcd7dgJBGXD4tiWl/dPPDga+TUnvdUmybUv+D3bf43sXkz 3sBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744372304; x=1744977104; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QEZFCc5PMkMuprUJCMDWccWRpZGl5H50kw9rdUzWlIQ=; b=uGOxm9pTBVQ3wJ9kcVe/N3HYEfbGzq5Lgfejq9lRy62ZOxYci9OMgC4v6AZva853eG znoFiHuo7i7m3dahLAMDfZIuyBk/9dCrF3VjUFuB8pzBJNPmkO07bF/5+ykT9FtHFkNG Y4tZaIgrSywbVb9fnNa1yO0BIfhLasvJtlq9BlzI/br+wno3gGY/pODkiABBasrQOJN8 noU3GHmGrDWTbWcwWcU/xR3+tXbURucd5GiWs1qBx+peu6FvFlbJOsVi1i3nluIm7v8v CBPlXaWM3HbAMVPgiek9ZnIOAphyqdhqlH3Go5Egp0boffTkWzr8YxYCX71gpw0qQduJ RNwg== X-Gm-Message-State: AOJu0YwuT3Un8YcBkrW3Vd2c+7DJU1Fp8StNznhMIkNeqR+ao7TSquzW 149F9Q1cKt9jvT3chwMdPNm3Go5//gBzH90ePCwa6aU41XD+H7Qw X-Gm-Gg: ASbGncuEwt+MO7P3CCXA4Z5us3k6DlUm8AtoWCloTHLSE6Ip9dJRQCqjFOsZ1/pKCFU WGJVwjQGXo2I7Os5PDOtSaSMBL1YLZDZ2kgNsGKil2/jy9MIstqHP/ZHjm3dad/FLtGK427dc6W x+b/roiTk+P80Qd/pY0U33iTBhfFE4uOQQLKqUVCwpHPT9k0f8Z9hQQVDBM3Yl5C6hgqSX8zuLR 5I0twiTyG0T0BEGaM6bQalkqbIk8IseH1T8ieJafy5vQEALqAUiLeN2htcOstpltmXS9te5+I8Q beWZbgTADTzNu+ldJbOCQQi2jGLTFz0QlTxBug== X-Google-Smtp-Source: AGHT+IEh4pb+qkF0Ldy86doByvfoDGoLsdQNf7PlZn4AKjKTCfL9kBDIudq9xb8tf6QQcPK+sR72RQ== X-Received: by 2002:a17:90b:2b8f:b0:2ee:c30f:33c9 with SMTP id 98e67ed59e1d1-30823672ee2mr4201206a91.14.1744372304523; Fri, 11 Apr 2025 04:51:44 -0700 (PDT) Received: from localhost ([115.240.90.130]) by smtp.gmail.com with UTF8SMTPSA id 98e67ed59e1d1-306df06a1aesm5335650a91.5.2025.04.11.04.51.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Apr 2025 04:51:44 -0700 (PDT) From: Visuwesh To: Johann =?utf-8?Q?H=C3=B6chtl?= Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: References: <87plhj7zlp.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 11 Apr 2025 17:21:40 +0530 Message-ID: <87frie9ar7.fsf@gmail.com> 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: 77732 Cc: 77732@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 (-) [ Please use Reply All in your mail client to ensure the entire conversation is recorded in the bug tracker. ] [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE=AA= =E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Johann H=C3=B6chtl wrote: > First thank you for the hint of toggle-debug-on-error, TIL > > The trace: > > Debugger entered--Lisp error: (wrong-type-argument stringp nil) > compilation-find-file-1(# "Grep started at Fri Apr > 11 12" nil nil) > compilation-find-file(# "Grep started at Fri Apr 11 > 12" nil) > compilation--update-markers((nil 58 (("Grep started at Fri Apr 11 12" > nil) nil (58 #1)) nil nil) # nil 0) > grep-edit--prepare-buffer() > grep-change-to-grep-edit-mode() > funcall-interactively(grep-change-to-grep-edit-mode) > command-execute(grep-change-to-grep-edit-mode) > > > The buffer starts the following: > > -*- mode: grep; default-directory: "~/OneDrive - Online/Dokumente/" -*- > Grep started at Fri Apr 11 12:58:57 > I can reproduce the issue with 17 hits but not with >200. I will try digging into this more. > Am Fr., 11. Apr. 2025 um 12:37 Uhr schrieb Visuwesh : > >> [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE= =AA=E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Johann H=C3=B6chtl wrote: >> >> > I am using Emacs from HEAD on Windows >> > >> > I tried to reproduce the behaviour with emacs -Q but it still remains >> > inconsistent. >> > >> > When I rgrep and there are few results (< 15) , I can enter grep buffer >> > pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter >> with >> > 'e' and so on. >> > >> > When there are more results, (between 15 and 70) I still can enter wi= th >> > 'e' get out with C-c C-c but when I try to re-enter I get the error >> message >> > Wrong type argument: stringp, nil >> > The buffer later although still in grp-mode does not behave any longer >> as a >> > grep mode, 'g' or 'e' results in the error Buffer is read only : #> > *grep*> >> > >> > When there are many results, I get the error message Wrong type argume= nt: >> > stringp, nil already on the first invocation attempt. >> > >> > Thew boundaries are somewhat moving but at least I have the feeling the >> > more matches are, the more frequently I run into the >> > >> > Wrong type argument: stringp, nil >> > >> > already at first try. >> >> Can you please share the backtrace? Say M-x toggle-debug-on-error RET >> before trying to reproduce the error above. I mostly tested >> grep-edit-mode with M-x rgrep, and a good amount of results. >> From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 07:57:55 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 11:57:55 +0000 Received: from localhost ([127.0.0.1]:49237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3D18-0007hA-OC for submit@debbugs.gnu.org; Fri, 11 Apr 2025 07:57:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41562) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3D15-0007gn-Qt for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 07:57:52 -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 1u3D10-0003MY-GY; Fri, 11 Apr 2025 07:57: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=IwEBYeOmNGm/jiy9ubtU3WPn3dHQrOzNnJTMFbSa9no=; b=KLD5HNMpC7HBrNY1UGV9 3B13Fe+75cYxNga/GYPebwUBnAb9FU2BEG8hNNWYwq+sL/L0GZMXQ1Q6lOch5X2NgiiSF3J4Bu/7R BatS6q/EwaqUT9dAQB1muw6y94Lweb6Cd+qwALRKY+ksGvL2hK86nt0GOrO+ZneQDF1H1MmXQ+cm0 7biUzMv+IAFaRfIAh6yfi6N9eqMQkJvBcL6E5ZSBSMfHqWLxnxdFBjyYAqDyfWJwtXpZ1iaHUrPfo kpVzqi2KqgZ1U+KbNqqIB7N4qDHxG/xBDpZ4IM0K+Ph1Hkrp8STuESYODQoqhj4NkV7WiL5ujd1Q9 De+2XxvEw5eILA==; Date: Fri, 11 Apr 2025 14:57:42 +0300 Message-Id: <86wmbqoqq1.fsf@gnu.org> From: Eli Zaretskii To: Johann =?utf-8?Q?H=C3=B6chtl?= In-Reply-To: (message from Johann =?utf-8?Q?H=C3=B6chtl?= on Fri, 11 Apr 2025 11:33:59 +0200) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77732 Cc: 77732@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: Johann Höchtl > Date: Fri, 11 Apr 2025 11:33:59 +0200 > > I am using Emacs from HEAD on Windows > > I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent. > > When I rgrep and there are few results (< 15) , I can enter grep buffer pres 'e' to enter grep-edit mode, get > out of it with C-c C-c, re-enter with 'e' and so on. > > When there are more results, (between 15 and 70) I still can enter with 'e' get out with C-c C-c but when I try > to re-enter I get the error message Wrong type argument: stringp, nil > The buffer later although still in grp-mode does not behave any longer as a grep mode, 'g' or 'e' results in the > error Buffer is read only : # > > When there are many results, I get the error message Wrong type argument: stringp, nil already on the first > invocation attempt. I cannot reproduce this with today's master branch on MS-Windows. I just tried with a Grep command that yielded 128 hits, and didn't see any errors. Please show the complete recipe for reproducing the problem, with all the steps and commands explicitly shown. It is best if you can show this in the Emacs source tree, so that all of us can easily try the same recipe with the same files. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 08:31:58 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 12:31:58 +0000 Received: from localhost ([127.0.0.1]:49374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3DY4-0001iz-Uu for submit@debbugs.gnu.org; Fri, 11 Apr 2025 08:31:57 -0400 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]:45414) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3DXy-0001hi-G8 for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 08:31:51 -0400 Received: by mail-pg1-x543.google.com with SMTP id 41be03b00d2f7-af5cdf4a2f8so1460948a12.3 for <77732@debbugs.gnu.org>; Fri, 11 Apr 2025 05:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744374704; x=1744979504; 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=ScKDWx3P/kkqK/9IDuSV7VLVRA+b6CqaxyDdPNWsPqQ=; b=F7MCF/P+Gp2CcIYnLzs3hBUB00DKeCsM/DRH3s2NCpngYOJ655GElVL8hecSY4s0bP qxTAGUyUO5PxMT6erhmoVyy9re4uckx96CBoyIuzoRBrLYLHnHUoObc1xe/1KyXZOa4/ efdwv5kWPsFucKe2dLzPvjJch5mhUkPuwucD4mJubRwrzavoTCjLYWo+rmOOLsKV2KXh CGiNlaXV3nrRwSRpf4B2PuHSP8f+iPCYwfqjxCbfF3HdQmWRwZp4VRsbi3qlEJHs6mKj wuygWexJQT6GPZGll4fww6Qe2K9jx0rLmGhFglA8csaGnC7zgZ04ZPk/hu98h/b0TTZY 0D8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744374704; x=1744979504; 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=ScKDWx3P/kkqK/9IDuSV7VLVRA+b6CqaxyDdPNWsPqQ=; b=pKPIbFd77vErZQ9Ke7w4OSoIC07KRMlGosHBkV6ihelLPk4SZzM565QyUKHMbUW9+R SM99fm5QRIKkDpilfTh/AK69DM/0iRvai5GX8gHGnPD5qM3Vg+zURbhWKvXTT7COEoC6 2dHwckxmqxaZYdPbK4t2RxODRBdYgyQL2DQ/wLglPHVoFkFnF93o9I09OGCyjGT9yWbu 5GEsllGSZeH9ATZF4umiJZdPHuQvxV105f6XzLWiLwPJ0y35vbqBehY4ypBcvDiYaauy Y9epZWsD8hpEnGZZrZ3fbs0VT8FTW7UFGVc4RM0kt1VQlUnCgzPMLTsEYkoba3uosa5n Lcaw== X-Forwarded-Encrypted: i=1; AJvYcCUcCbufoJsouBx00PSrLFETZYiHGhsar7Bb6PNEDSi1A2dC3fELZ9U9+ooLHVlQIdVAVVH6Dg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwMwvsyrae0GGsIEv1bvdJSMXeAQQFeBj96OYd6BAUpRrbuGvhR ZWcJlfPid2fpbCN1KSriFI/rlSk0O97TlDnXvHCLIFfL2EAWOzgu X-Gm-Gg: ASbGnctezJHnPqXJ3wQ7ZvS77nBDDwOe9sPPOpf68UWg62h/NGnU/5DYofIwu6OMv1D fLHCU6/bF0IFCBSgyg/xVLHYYrvdJ4dZkHQW4kZhZTy/7PEoAvUdwf7NqTdOkS1U/PBOp1OkVof 6ryMCIbwBqftl/hdqdHgQ39Ftp0vmODOMGXhoEjf58kHgNQ+GKOQ6cPTB/unyDnbo+ozb/5esVr ay2AcuufdCwQxQ5jPObMXRJ/5w+KTyfD3O82qAyxQB2zNlI2WP+Y05ZmGa90UJhl1SDMhNDfpCh N4J7JH0bxN2Ns0Ro15820/2ylHs9YrKV1OBJquem8hdkpoZ64Gc/ X-Google-Smtp-Source: AGHT+IFGTDYEGRaT5vAd7rRyFhbQ/QBpHww79JdFcMvvc8z+iS6vzcRmNag83HyeCHwZDijrXDqpTg== X-Received: by 2002:a17:90b:274e:b0:2f9:c139:b61f with SMTP id 98e67ed59e1d1-30823670d71mr4362825a91.14.1744374703526; Fri, 11 Apr 2025 05:31:43 -0700 (PDT) Received: from localhost ([1.7.159.71]) by smtp.gmail.com with UTF8SMTPSA id 98e67ed59e1d1-306dd10c447sm5570864a91.3.2025.04.11.05.31.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Apr 2025 05:31:42 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <86wmbqoqq1.fsf@gnu.org> References: <86wmbqoqq1.fsf@gnu.org> Date: Fri, 11 Apr 2025 18:01:27 +0530 Message-ID: <87bjt298ww.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: [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> From: Johann Höchtl >> Date: Fri, 11 Apr 2025 11:33:59 +0200 >> >> I am using Emacs from HEAD on Windows >> >> I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent. [...] 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.71 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:543 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) X-Debbugs-Envelope-To: 77732 Cc: Johann =?utf-8?Q?H=C3=B6chtl?= , 77732@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: [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> From: Johann Höchtl >> Date: Fri, 11 Apr 2025 11:33:59 +0200 >> >> I am using Emacs from HEAD on Windows >> >> I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent. [...] 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:543 listed in] [list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.71 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 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE=AA= =E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Eli Zaretskii wrote: >> From: Johann H=C3=B6chtl >> Date: Fri, 11 Apr 2025 11:33:59 +0200 >>=20 >> I am using Emacs from HEAD on Windows >>=20 >> I tried to reproduce the behaviour with emacs -Q but it still remains in= consistent. >>=20 >> When I rgrep and there are few results (< 15) , I can enter grep buffer = pres 'e' to enter grep-edit mode, get >> out of it with C-c C-c, re-enter with 'e' and so on. >>=20 >> When there are more results, (between 15 and 70) I still can enter with= 'e' get out with C-c C-c but when I try >> to re-enter I get the error message Wrong type argument: stringp, nil >> The buffer later although still in grp-mode does not behave any longer a= s a grep mode, 'g' or 'e' results in the >> error Buffer is read only : # >>=20 >> When there are many results, I get the error message Wrong type argument= : stringp, nil already on the first >> invocation attempt. > > I cannot reproduce this with today's master branch on MS-Windows. I > just tried with a Grep command that yielded 128 hits, and didn't see > any errors. It seems like the number of hits is specific for this bug to hit. > Please show the complete recipe for reproducing the problem, with all > the steps and commands explicitly shown. It is best if you can show > this in the Emacs source tree, so that all of us can easily try the > same recipe with the same files. Here's a reproduction: 1. Download the attachment cp2k-mode.el 2. emacs -Q 3. M-x grep RET 4. After '-e' in the command, type " '^(def[^ ]\+ cp2k-' cp2k-mode.el". 5. The above grep command should produce 17 hits. 6. Say e. 7. Say C-c C-c. 8. Say e. 9. After this, move your point to "Grep finished..." message, and inspect the value of the text-property compilation-message. It should have a non-nil value. 10. Say C-c. 11. Say e, and witness the reported error. I inserted a few message statements (see patch below), and I cannot figure out where the sudden addition in the compilation-message is coming from. We could bail from calling grep-edit--prepare-buffer if we detect an occur-target-prefix text-property but there might be a deeper seated bug somewhere. diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index b0105f08ea2..ec2b600971c 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -1055,15 +1055,18 @@ grep (defun grep-edit--prepare-buffer () "Mark relevant regions read-only, and add relevant occur text-properties= ." (save-excursion + (message "----") (goto-char (point-min)) (let ((inhibit-read-only t) (dummy (make-marker)) match) - (while (setq match (text-property-search-forward 'compilation-annota= tion)) + (while (setq match (text-property-search-forward 'compilation-annota= tion + nil (lambda (_val p= rop-val) prop-val))) (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-messag= e)) + (message "%S %S" (point) (get-text-property 2527 'compilation-mess= age)) (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))) @@ -1078,7 +1081,8 @@ grep-edit--prepare-buffer (prop-match-end match) 'compilation-message) (1+ (pos-eol))) - `(occur-target ((,m . ,m))))))))) + `(occur-target ((,m . ,m)))))) + (message "%S %S" (point) (get-text-property 2527 'compilation-messag= e))))) =20 (defvar-keymap grep-edit-mode-map :doc "Keymap for `grep-edit-mode'." @@ -1109,21 +1113,26 @@ grep-change-to-grep-edit-mode (when (get-buffer-process (current-buffer)) (error "Cannot switch when grep is running")) (use-local-map grep-edit-mode-map) + (message "before prep %S %S" (point) (get-text-property 2527 'compilatio= n-message)) (grep-edit--prepare-buffer) + (message "after prep %S %S" (point) (get-text-property 2527 'compilation= -message)) (setq buffer-read-only nil) (setq major-mode 'grep-edit-mode) (setq mode-name "Grep-Edit") (buffer-enable-undo) + (message "after undo %S %S" (point) (get-text-property 2527 'compilation= -message)) (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 "after hook %S %S" (point) (get-text-property 2527 'compilation= -message)) (message (substitute-command-keys "Editing: Type \\[grep-edit-save-changes] to return to Grep mo= de"))) =20 (defun grep-edit-save-changes () "Switch back to Grep mode." (interactive) + (message "%S %S" (point) (get-text-property 2527 'compilation-message)) (unless (derived-mode-p 'grep-edit-mode) (error "Not a Grep-Edit buffer")) (remove-hook 'after-change-functions #'occur-after-change-function t) @@ -1134,7 +1143,8 @@ grep-edit-save-changes (force-mode-line-update) (buffer-disable-undo) (setq buffer-undo-list t) - (message "Switching to Grep mode")) + (message "Switching to Grep mode") + (message "%S %S" (point) (get-text-property 2527 'compilation-message))) =20 ;;;###autoload (defun grep-find (command-args) --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=cp2k-mode.el Content-Transfer-Encoding: quoted-printable ;;;;; Emacs major mode for cp2k input, written by Lianheng Tong -*- lexica= l-binding: t; -*- ;;;;; Copyright (c) Lianheng Tong ;;;;; Last modify date: Saturday, 2014/01/25 ;;;; Syntax highlighting of keywords (defconst cp2k-font-lock-keywords (rx-let ((spc (+ (any " \t"))) (maybe-spc (* (any " \t"))) (cp2k-bol (seq bol maybe-spc))) ;; Blocks. `((,(rx cp2k-bol (group "&" ;; Consider BEGIN and END lines. (? "END" maybe-spc) (1+ (syntax word)))) (1 font-lock-function-name-face)) ;; Keywords. (,(rx cp2k-bol bow (group (not (any "0-9" "@$&")) (1+ (syntax word))) spc (? (1+ (syntax word)))) (1 font-lock-keyword-face)) ;; Preprocessor type 1. (,(rx cp2k-bol (group "@" (or "IF" "INCLUDE" "ENDIF"))) (1 font-lock-preprocessor-face)) ;; Preprocessor type 2. (,(rx cp2k-bol (group "@SET") spc (group (1+ (syntax word)))) (1 font-lock-preprocessor-face) (2 font-lock-variable-name-face nil = t)) ;; variables (,(rx "$" (? "{") (group (1+ (syntax word))) (? "}")) (1 font-lock-variable-name-face)))) "Font-lock keywords for `cp2k-mode'.") ;;;; Syntax table (defconst cp2k-mode-syntax-table (let ((st (make-syntax-table))) (modify-syntax-entry ?# "<" st) ; # is beg. comment (modify-syntax-entry ?! "<" st) ; ! is beg. comment (modify-syntax-entry ?\n ">" st) ; \n is end. comment (modify-syntax-entry ?_ "w" st) ; underscore is part of names (modify-syntax-entry ?\' "\"" st) ; string quote (modify-syntax-entry ?\" "\"" st) ; string quote (modify-syntax-entry ?\r "-" st) ; return is whitespace (modify-syntax-entry ?+ "." st) ; + is puntuation (modify-syntax-entry ?- "." st) ; - is puntuation (modify-syntax-entry ?* "." st) ; * is puntuation (modify-syntax-entry ?/ "." st) ; / is puntuation (modify-syntax-entry ?=3D "." st) ; =3D is puntuation (modify-syntax-entry ?\\ "\\" st) ; \ is escape char st) "Syntax table for `cp2k-mode'.") ;;;; Define keymap for the major mode (defvar cp2k-mode-map (let ((map (make-sparse-keymap))) ;; Define mode specific key-bindings here (define-key map (kbd "C-j") #'newline-and-indent) (define-key map (kbd "C-c ;") #'comment-region) (define-key map (kbd "TAB") #'cp2k-indent-line) (define-key map (kbd "C-M-a") #'cp2k-beginning-of-block) (define-key map (kbd "C-M-e") #'cp2k-end-of-block) (define-key map (kbd "C-c C-c") #'outline-toggle-children) (define-key map (kbd "C-c C-a") #'outline-show-all) (define-key map (kbd "C-c C-t") #'outline-show-subtree) map) "Keymap for `cp2k-mode'.") ;;;; Syntax indentation (defvar cp2k-indent 2 "standard indentation for in `cp2k-mode'") (defconst cp2k-emptyline "^\\s-*$" "regexp matching an empty line in `cp2k-mode'") (defconst cp2k-opening ;; note that this definition also matches cp2k-closing, so for ;; positive identification of cp2k-opening, one must use AND ;; construct with (not lookingat cp2k-closing). One way to avoid ;; this is to construct search for line that does NOT contain END, ;; however, practical implementation of that leads to emacs ;; occasionally throwing the exception "regex stack overflow"... ;; The emacs regex search is pretty crudely implemented, and it is ;; far more robust to do a positive search, than negative ;; searches. So I opted for this more crude method here. (rx bol (* (any " \t")) (or (seq "&" (1+ (syntax word))) (seq "@IF" eow))) ;; "^[ \t]*\\(\\(&\\sw+\\)\\|\\(@IF\\>\\)\\)" "regexp matching lines starting (or closing --- due to limitations in regex implementation) a cp2k block in `cp2k-mode'") (defconst cp2k-closing (rx bol (* any " \t") (or (seq "&END" (* any) eol) (seq "@ENDIF" eow)) eol) ;;"^[ \t]*\\(\\(&END[ \t]*.*$\\)\\|\\(@ENDIF\\>\\)\\).*$" "regexp matching lines closing a cp2k block in `cp2k-mode'") (defsubst cp2k-at-opening-p () "Return non-nil if looking at a section opening line." (and (looking-at-p cp2k-opening) (not (looking-at-p cp2k-closing)))) (defsubst cp2k-at-closing-p () "Return non-nil if looking at a section closing line." (looking-at-p cp2k-closing)) (defun cp2k-beginning-of-block (&optional not-set-mark) "move the cursor to the beginning of the block in `cp2k-mode'" (interactive) (if (not not-set-mark) (push-mark)) (beginning-of-line) (let ((find-opening t) (in-nested nil) (initial-opening nil)) ;; If at section opening, search for the parent. (when (and (cp2k-at-opening-p) (not (bobp))) (setq initial-opening t)) (while (and find-opening (not (bobp))) ;; We are not in a nested situation, and we found the necessary ;; section opening. (if (and (cp2k-at-opening-p) (not in-nested) (not initial-opening)) (setq find-opening nil) (when (cp2k-at-opening-p) (setq in-nested nil) (setq initial-opening nil)) (forward-line -1) ;; If the line is a closing statement, skip to the line of ;; the opening statement. (when (cp2k-at-closing-p) (setq in-nested t) (cp2k-beginning-of-block t)))))) (defun cp2k-end-of-block (&optional not-set-mark) "move the cursor to the ending of the block in `cp2k-mode'" (interactive) (if (not not-set-mark) (push-mark)) (beginning-of-line) (let ((find-closing t) (in-nested nil) (initial-closing nil)) ;; If at section closing, search for the parent. (if (and (cp2k-at-closing-p) (not (eobp))) (setq initial-closing t)) (while (and find-closing (not (eobp))) (if (and (cp2k-at-closing-p) (not in-nested) (not initial-closing)) (setq find-closing nil) (when (cp2k-at-closing-p) (setq in-nested nil) (setq initial-closing nil)) (forward-line 1) ;; If the line is a opening statement, skip to the line of ;; the closing statement. (when (cp2k-at-opening-p) (setq in-nested t) (cp2k-end-of-block t)))))) (defun cp2k-forward-one-line () "move the cursor forward one line, ignore empty or comment lines, in `cp2= k-mode'" (beginning-of-line) (forward-line 1) (while (and (or (looking-at cp2k-emptyline) (looking-at "^[ \t]*#")) (not (eobp))) (forward-line 1))) (defun cp2k-backward-one-line () "move the cursor forward one line, ignore empty or comment lines, in `cp2= k-mode'" (beginning-of-line) (forward-line -1) (while (and (or (looking-at cp2k-emptyline) (looking-at "^[ \t]*#")) (not (bobp))) (forward-line -1))) (defun cp2k-left-of-point-is-empty () "check if the left of the point is only white space in `cp2k-mode'" (let (not-empty) (save-excursion (setq not-empty (re-search-backward "[^ \t]" (line-beginning-position) t 1))) (not not-empty))) (defun cp2k-indent-line () "indent current line in `cp2k-mode'" (interactive) (let ((indent 0) (position (point-marker))) ;; record initial indentation position (back-to-indentation) (indent-line-to (max 0 (catch 'indentation (save-excursion (beginning-of-line) (and (bobp) (throw 'indentation 0)) ;; get the block indentation (save-excursion (cp2k-beginning-of-block t) (setq indent (current-indentation))) ;; look at the current line (when (cp2k-at-closing-p) (throw 'indentation indent)) ;; move up one non-empty line (cp2k-backward-one-line) (setq indent (current-indentation)) (when (cp2k-at-opening-p) (setq indent (+ indent cp2k-indent))) (throw 'indentation indent))))) ;; move cursor to indentation point if in the beginning white ;; space otherwise leave unchanged (goto-char position) (when (cp2k-left-of-point-is-empty) (back-to-indentation)) (set-marker position nil))) ;;;; Define mode hook (defvar cp2k-mode-hook nil) ;;;; Entry function (define-derived-mode cp2k-mode fundamental-mode "cp2k" "Major mode for editing cp2k input. Copyright (c) Lianheng Tong 2013/12/0= 6" :syntax-table cp2k-mode-syntax-table ;; setq-local is undefined in emacs versions prior 24.3, it is ;; equivalent to make-local-variable, and followed by setq, and this ;; is what has been used here. This works for older versions of ;; emacs. (make-local-variable 'comment-start) (setq comment-start "# ") (make-local-variable 'comment-start-skip) (setq comment-start-skip "#+\\s-*") ;; see emacs manual on font-lock-defaults, nil here means also ;; font-lock comments and strings, and t means the value of ;; font-lock-keywords-case-fold-search is set to non-nil, allowing ;; case insensitive search (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(cp2k-font-lock-keywords nil t)) ;; whether the indentation key-word search case-sensitive or not (in ;; my implementation, using looking-at function) is effected only by ;; the variable case-fold-search, and is uneffected by ;; font-lock-keywords-case-fold-search. So turn case-fold-search on ;; just in case (make-local-variable 'case-fold-search) (setq case-fold-search t) (make-local-variable 'indent-line-function) (setq indent-line-function 'cp2k-indent-line)) ;;;; Add to autoload alist (add-to-list 'auto-mode-alist '("\\.cp2kin\\'" . cp2k-mode)) ;;;; Setup outline mode (when (require 'outline nil 'noerror) (add-hook 'cp2k-mode-hook 'outline-minor-mode) ;; in outline mode, the level of header depends on the length of ;; match, which suits our purposes quite well (setq outline-regexp "[ \t]*\\(&\\|@\\(IF\\|EN\\)\\)")) ;;;; Last line (provide 'cp2k-mode) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 11:56:49 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 15:56:49 +0000 Received: from localhost ([127.0.0.1]:51388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3GkL-00087v-By for submit@debbugs.gnu.org; Fri, 11 Apr 2025 11:56:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52614) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3GkI-00087f-Vq for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 11:56:48 -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 1u3GkD-0006KI-El; Fri, 11 Apr 2025 11:56:41 -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=JZO3xfBh3Z6tr8zX//53ENTSnLP+ARZON2ehwk/KqIE=; b=Uyqi9ZnH6H6bTopvJLt1 yIVNtt+mTW08lf1bttDxoRXo6De82W8LNyxvewkNoY3TGHJoSL39lwx1jLlwN8O0n3Hw6BqTGnN+z PpD1v45PUYLfnKQL6QdiCFJmZBsyphN7jtoJaMnTyEgno1eQdjMX9aQ2alDxtasoQjob7NkUe/NZa r/MqU2l47DftaWefQXY42hi1nsjK6dCzke+BL0nD2XDB1tZx4rSA67pUsrHXkMDMK7pKuZW+6xuCI mIEEc1vcpVzP7+gbLVo46AIc8UHRenoT2KAy5z0lOr2yKrh24RfFTdpcgtwugiN5oLseHIPZ6KL/3 xz1MnGNYLW7lrA==; Date: Fri, 11 Apr 2025 18:56:37 +0300 Message-Id: <86tt6uofnu.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87bjt298ww.fsf@gmail.com> (message from Visuwesh on Fri, 11 Apr 2025 18:01:27 +0530) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.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: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: Johann Höchtl , > 77732@debbugs.gnu.org > Date: Fri, 11 Apr 2025 18:01:27 +0530 > > I inserted a few message statements (see patch below), and I cannot > figure out where the sudden addition in the compilation-message is > coming from. Which addition is that? I'm afraid you lost me here. Can you explain which line of code causes the error, and why? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 12:13:06 2025 Received: (at 77732) by debbugs.gnu.org; 11 Apr 2025 16:13:06 +0000 Received: from localhost ([127.0.0.1]:51451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3H06-0000VC-4A for submit@debbugs.gnu.org; Fri, 11 Apr 2025 12:13:06 -0400 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]:45225) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3H01-0000UY-2c for 77732@debbugs.gnu.org; Fri, 11 Apr 2025 12:13:05 -0400 Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-22423adf751so22226275ad.2 for <77732@debbugs.gnu.org>; Fri, 11 Apr 2025 09:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744387975; x=1744992775; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=93RJY3zoyAf6MMOHLiyB2+26Wc3b6yfBK06/cEORh8w=; b=ZBmvsVxRQn32EvFJISlX7tK6zsWFqlCwnkVXcSP7iLCSLaMKnpFTbWQTFCxCcufqWm vzUeEkT1ChUk1rf/49ChwT+mj0MOrdBa134IvA0p9ZGmci1p43ORLUVZw991dH4TPe8Q p0IJN+TEPse7cYRzbxGJ0C5MQsGd62/NntmSRWx4wKTMUBbzSx3pPGjjHcQYaC5EF7M6 pD+jyD2wlyi2Fo3W27EENvCkNGbU6OB2lioQTufQ9e92BtmfNIxUhtekgXdfW5RiO7aj MFibmsyxJL9sBZWTkC1DIciTnvWB5IEyqdHK7+F/HoqRfrbCsOhLZe7natwDcENrKFnb FdzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744387975; x=1744992775; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=93RJY3zoyAf6MMOHLiyB2+26Wc3b6yfBK06/cEORh8w=; b=mlXmdWPH63KP6yvu6CsfeprlQC5QUzVu3fi31bCULxjs5GzLUnIuukp0M0yLw+65gv wv4NROivjGaSEt1WYUyvnzezSCGBrQGYroJvLUDNKj2AreyopGM4vKTqDmRcbnJ+3XY9 c4Kp3jeM5dbzBGh9GsOVRXiU2EmTqZVLbNFxKZG8nygLgttQcqYWINzwuLpWLzTLpXsZ lHwSM9ucwR6wktYsXUS2e4BsktkbJwgLsYB0BCb2GHDVvhKm90nyWiMfTIUyLM6t24vQ Y8ZO7wGr4n1bBP315ez0p/Qb9325qvFCSYUtbZ8g0H+6tJZvTAt7vPNUBG3Y0wnz4B6k YjiA== X-Forwarded-Encrypted: i=1; AJvYcCXYqkSkdDvkqu/Jv87Bz5ToDtDLpgTpaAfgRPJCtUGfkKD0LjMWdC7j/Bl1aGUo4Wd3e/VldQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxiAgFDb7nAjJd1XwoVPQW5CCLBnq1Hk9PEu5v3KSKgo0f+eWYI VrRL09YWnFYAwjY/yRCZ+8l0mM2YOWDe6SZQQOFcckUdLSw37P0g X-Gm-Gg: ASbGncu+bov3o6QC6pubtE6QB7PP3gT2+Neom4bmySudCkLwu0JH3GZFPY2XToYyn0M rLPfjvmulHX2sqy7m3VlUrPJJ+y12GXN+P56apWAOax5wZGUxasN8usoTsat1T7msrSzTP9xeKx tOljcUOI9wIx6kp4bB4o74vkJgB4seHLf4qOvZT7Pxh3YibstHbJ1ztcJlMijwZNCMzkjfdMz9J OfU2m5uSDuG/QBQCEoslLcM/tDYBa4e4HXdhxqDYCghGfwmTrdF2YL5mZEVYxcldQ8Z6AHM14zv ARmhYdPMzmEu/Nf3aG3V0O2DDgeDqikxyQQFi8xV3g== X-Google-Smtp-Source: AGHT+IEkro/SYgNkBGiQGT3uQMr1U/ljyW++JUm7GpSRasCz18kT96FvKLt4aNPYOAw4y+qWUh55Rg== X-Received: by 2002:a17:902:cec9:b0:227:e980:9190 with SMTP id d9443c01a7336-22bea4fcad1mr53843465ad.44.1744387974742; Fri, 11 Apr 2025 09:12:54 -0700 (PDT) Received: from localhost ([1.7.159.71]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-22ac7c93aa3sm51302895ad.149.2025.04.11.09.12.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Apr 2025 09:12:54 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <86tt6uofnu.fsf@gnu.org> References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 11 Apr 2025 21:42:51 +0530 Message-ID: <871pty8ynw.fsf@gmail.com> 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: [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: Johann Höchtl , >> 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 18:01:27 +0530 >> >> I inserted a few message statements (see patch below), and I cannot >> figure out w [...] 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.71 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:641 listed in] [list.dnswl.org] X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: Johann Höchtl , >> 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 18:01:27 +0530 >> >> I inserted a few message statements (see patch below), and I cannot >> figure out w [...] 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:641 listed in] [list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.71 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE=AA= =E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: Johann H=C3=B6chtl , >> 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 18:01:27 +0530 >>=20 >> I inserted a few message statements (see patch below), and I cannot >> figure out where the sudden addition in the compilation-message is >> coming from. > > Which addition is that? I'm afraid you lost me here. Oops, I butchered the statement: after the second time you type 'e', the "Grep finished..." message attains a non-nil compilation-message text-property. > Can you explain which line of code causes the error, and why? That's what I tried to figure out by adding the message statements but I fail to understand how the compilation-message text-property is being Added. The relevant bits from *Messages* is at the end. When I say 'e' for the first time then go back to grep-mode with C-c C-c, there's no extra compilation-message text-property. When I say 'e' for the second time around, till the end of grep-change-to-grep-edit-mode, there's no extra compilation-message text-property (lines marked with *). But in the gap between grep-change-to-grep-edit-mode and me saying C-c C-c (with no other action being done by me in between), the extra compilation-message text-property is added to the "Grep finished..." line. Grep finished with 17 matches found before prep 1 nil ---- 1666 nil 1718 nil 1769 nil 1809 nil 1847 nil 1890 nil 1932 nil 1974 nil 2024 nil 2074 nil 2149 nil 2218 nil 2269 nil 2321 nil 2378 nil 2424 nil 2471 nil [2 times] after prep 1 nil after undo 1 nil after hook 1 nil Editing: Type C-c C-c to return to Grep mode 1 nil Switching to Grep mode 1 nil before prep 1 nil ---- 1666 nil 1718 nil 1769 nil 1809 nil 1847 nil 1890 nil 1932 nil 1974 nil 2024 nil 2074 nil 2149 nil 2218 nil 2269 nil 2321 nil 2378 nil 2424 nil 2471 nil [2 times] * after prep 1 nil * after undo 1 nil * after hook 1 nil Editing: Type C-c C-c to return to Grep mode 1 #s(compilation--message (nil 33 (("Grep finished with 17 matches foun= d at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) Switching to Grep mode 1 #s(compilation--message (nil 33 (("Grep finished with 17 matches foun= d at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) before prep 1 #s(compilation--message (nil 33 (("Grep finished with 17 = matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) ---- 1666 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1718 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1769 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1809 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1847 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1890 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1932 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 1974 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2024 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2074 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2149 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2218 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2269 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2321 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2378 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2424 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2471 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) 2583 #s(compilation--message (nil 33 (("Grep finished with 17 matches f= ound at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil) Entering debugger... From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 06:26:25 2025 Received: (at 77732) by debbugs.gnu.org; 12 Apr 2025 10:26:25 +0000 Received: from localhost ([127.0.0.1]:54119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3Y48-00017g-HU for submit@debbugs.gnu.org; Sat, 12 Apr 2025 06:26:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50748) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3Y46-00017P-U7 for 77732@debbugs.gnu.org; Sat, 12 Apr 2025 06:26:23 -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 1u3Y41-0004XH-Gc; Sat, 12 Apr 2025 06:26:17 -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=qu5CimedZffVlGb61Xa5tRsb8IzFzYA8j2wp56WdQX0=; b=drjOGgzyDkH5z5K1x5Bt RCU5SInYyEc4pURvxUcRxXxxWMcSU6hRopQkaP+ZayTomfE2Q8z/LhhoCS0ypkzGZic4T6YvuJnb6 kGlRNBblQoEdQEqIlMrf9WsIrmyYikd46VTsueK344kCoE1isMCZV7CnTSes7NDfTjzrZb0PiAspN pdtEXzogh0CeReb2/wFo+lerKta8waZRaHML5OFKADE3YmdFfj5a2FIj/95/+bONrnFBFZEUV7u6L hr+uGU3qnkbRWbJnsBB+rv88bqSxx9CNt59Uh5YyCXjxYzMFQmPr93BiclMaiN3f1Ng/KLewkGj1y LBvOlaDOJulnWQ==; Date: Sat, 12 Apr 2025 13:26:14 +0300 Message-Id: <86r01xn0ah.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <871pty8ynw.fsf@gmail.com> (message from Visuwesh on Fri, 11 Apr 2025 21:42:51 +0530) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> <871pty8ynw.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: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org > Date: Fri, 11 Apr 2025 21:42:51 +0530 > > [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: > > >> From: Visuwesh > >> Cc: Johann Höchtl , > >> 77732@debbugs.gnu.org > >> Date: Fri, 11 Apr 2025 18:01:27 +0530 > >> > >> I inserted a few message statements (see patch below), and I cannot > >> figure out where the sudden addition in the compilation-message is > >> coming from. > > > > Which addition is that? I'm afraid you lost me here. > > Oops, I butchered the statement: after the second time you type 'e', the > "Grep finished..." message attains a non-nil compilation-message > text-property. > > > Can you explain which line of code causes the error, and why? > > That's what I tried to figure out by adding the message statements but I > fail to understand how the compilation-message text-property is being > Added. The relevant bits from *Messages* is at the end. > > When I say 'e' for the first time then go back to grep-mode with C-c > C-c, there's no extra compilation-message text-property. > > When I say 'e' for the second time around, till the end of > grep-change-to-grep-edit-mode, there's no extra compilation-message > text-property (lines marked with *). But in the gap between > grep-change-to-grep-edit-mode and me saying C-c C-c (with no other > action being done by me in between), the extra compilation-message > text-property is added to the "Grep finished..." line. I'm guessing this is font-lock (called via jit-lock mechanism)? Maybe you should do something with font-lock-extra-managed-props? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 08:10:24 2025 Received: (at 77732) by debbugs.gnu.org; 12 Apr 2025 12:10:25 +0000 Received: from localhost ([127.0.0.1]:54341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3Zgk-0005cK-7d for submit@debbugs.gnu.org; Sat, 12 Apr 2025 08:10:24 -0400 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]:60641) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3Zgf-0005ZG-9A for 77732@debbugs.gnu.org; Sat, 12 Apr 2025 08:10:19 -0400 Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-22403cbb47fso30927915ad.0 for <77732@debbugs.gnu.org>; Sat, 12 Apr 2025 05:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744459811; x=1745064611; 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=zOkHzmlLP783bbUPn/F2HynrIiJKFxZfNTXRXz1EM78=; b=KwUzxTR1qB34gA0JDEhugwt7hRQ554obg9Z8BZGZiVHY0mc+5kxqZdWIur06bPCFXV 04xoZwyrumg37UYPdRdcq6pmHr8PUip91NfrVAp+wZ0vteNLbmr97lVJVAOT6VdqAtQX lccgw03+E23NX3gy237YoaBgbjP/3wBLoxYhYYnzhGsQT7qqTLlak15DhSmAPGl9MuWe rGWOj7D3deibk1KJOwhXZ2lbG7/vGY/OBXGhUCOsl8VhyVrzh/96nNYM0dEqDh5QY+k6 At+fHaoN8sk+z7rUcAEmHvyb7eUKLXhHJHWMlmn4HW1qfG9b7mqNIP2RjUiTBiZWXFNq vkNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744459811; x=1745064611; 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=zOkHzmlLP783bbUPn/F2HynrIiJKFxZfNTXRXz1EM78=; b=lW8Q6rM+xOA8KB8JjPmPxXYsfhZErdAeRpbIE539jyoZY9InhVH7n59JqXrxl/u5zL gK2xyGm27cSgBf9pmUGzXBsG9GyPjAiATzKd2h1FdFxxHOD0V8Liaozt6PIfWbL3IgiW RypZvYTUUGyq3Oglnsdocphqxoel+EzxCKUjGVz6rhWzKSYiy5Ac6FcMc0jGuFarsBxE A0u8T0VVk0AY8dYM0H2WbSdynbyqOD+/vh/t6Bj0n0cKnot6w5yeL6tridUm4sZcSgta BZ6SjJMl5IZcF8BBk2vTwVpgIEI3UJxHSI8Z3df4hulDO2MT9hDoXqOdxAyCd6dW0tLk iMoQ== X-Forwarded-Encrypted: i=1; AJvYcCXkk5CGlwom1N0NhM53A2RRP8LO9arcOkAu7vE3rj9ZMcBwXn0RMCKUBbbzMc5dAbAi3M4Q1w==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz4017WWu0xtcIici7g1p5coASY3MO/MZdMGXYYryA4vr3HSysZ igGqDVvvpnqLcmeUiP1OPt9Dif/rJ/SR3RoOwED5xAHGFF6AB+Pm X-Gm-Gg: ASbGncvgVnJHjNOdylPZITEBH+ypLCB2ZPnF/32eu6jQOrB9zRF3eXULecDwlLhe9ny bvbkAnkDtAN4Kpp9bGceG9IrvZqBd7FjwTI9WtRlUSje2ZUyp2O5TX1503UJIkDFor2iBWmzPxP CA5vLfzYufCc+SomI5dZYOahe+6jXzj36vZvw0/o6ki/EOTSSDB5WUfRoFl/3Tuc9AHZDEWNEGD PRmLczdbHgC9GQNw7GLLJXLHhKV6T55MhxkVnfKzyrw8WqsZWg/QGRuQKCf0audr6J1entkB7V/ cz2S37p76EtdgWmOR0KDRPdGPOaMiaZ7CZUlbOQr6Q== X-Google-Smtp-Source: AGHT+IEZCeXWxnDjCMqm4/w7K/O6Q61yjJhX/WYug9a910RouyTc/8aXMaky121MMOAId6Iv6XLk5A== X-Received: by 2002:a17:902:d4ca:b0:223:54aa:6d15 with SMTP id d9443c01a7336-22bea4b6e10mr81643095ad.12.1744459810853; Sat, 12 Apr 2025 05:10:10 -0700 (PDT) Received: from localhost ([1.7.159.71]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-22ac7cbee8bsm66478965ad.208.2025.04.12.05.10.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Apr 2025 05:10:10 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <86r01xn0ah.fsf@gnu.org> References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> <871pty8ynw.fsf@gmail.com> <86r01xn0ah.fsf@gnu.org> Date: Sat, 12 Apr 2025 17:40:07 +0530 Message-ID: <87tt6t60o0.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: 4.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: [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 21:42:51 +0530 >> >> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> >> >> [...] Content analysis details: (4.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.71 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:641 listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 21:42:51 +0530 >> >> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: >> >> >> [...] 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:641 listed in] [list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [1.7.159.71 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (visuweshm[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=8F=E0=AE=AA=E0=AF=8D=E0=AE=B0=E0=AE=B2= =E0=AF=8D 12, 2025] Eli Zaretskii wrote: >> From: Visuwesh >> Cc: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org >> Date: Fri, 11 Apr 2025 21:42:51 +0530 >>=20 >> [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=8F=E0=AE= =AA=E0=AF=8D=E0=AE=B0=E0=AE=B2=E0=AF=8D 11, 2025] Eli Zaretskii wrote: >>=20 >> >> From: Visuwesh >> >> Cc: Johann H=C3=B6chtl , >> >> 77732@debbugs.gnu.org >> >> Date: Fri, 11 Apr 2025 18:01:27 +0530 >> >>=20 >> >> I inserted a few message statements (see patch below), and I cannot >> >> figure out where the sudden addition in the compilation-message is >> >> coming from. >> > >> > Which addition is that? I'm afraid you lost me here. >>=20 >> Oops, I butchered the statement: after the second time you type 'e', the >> "Grep finished..." message attains a non-nil compilation-message >> text-property. >>=20 >> > Can you explain which line of code causes the error, and why? >>=20 >> That's what I tried to figure out by adding the message statements but I >> fail to understand how the compilation-message text-property is being >> Added. The relevant bits from *Messages* is at the end. >>=20 >> When I say 'e' for the first time then go back to grep-mode with C-c >> C-c, there's no extra compilation-message text-property. >>=20 >> When I say 'e' for the second time around, till the end of >> grep-change-to-grep-edit-mode, there's no extra compilation-message >> text-property (lines marked with *). But in the gap between >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other >> action being done by me in between), the extra compilation-message >> text-property is added to the "Grep finished..." line. > > I'm guessing this is font-lock (called via jit-lock mechanism)? That may be the case... > Maybe you should do something with font-lock-extra-managed-props? Just pushing 'compilation-message to font-lock-extra-managed-props did not help. Unfortunately, I do not know enough to debug this one. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 08:51:46 2025 Received: (at 77732) by debbugs.gnu.org; 12 Apr 2025 12:51:46 +0000 Received: from localhost ([127.0.0.1]:54384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3aKo-0004c5-4j for submit@debbugs.gnu.org; Sat, 12 Apr 2025 08:51:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45590) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3aKm-0004ar-5V for 77732@debbugs.gnu.org; Sat, 12 Apr 2025 08:51:44 -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 1u3aKg-0001ir-HU; Sat, 12 Apr 2025 08:51:38 -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=fyM+UNHKAJOKNQkK6UvvmdDYFNyBT37tqxVn0E5jl7Q=; b=awPp2jFUg+INUz4sAj7m UZA2n2GvudM6RjFAgMz2YKWRQGC4eTvGxZzLSPEawTxn2wpKzg6tVy0Dfs5dan4pcYOAkmD+/iK1y xBrIlp5JA/ou5Rsw5PjmcX2rCUaMV7eVanVGPp40/fHpP60kFirVqx6WviYyt4fzHtWDncUQodbgJ B9jyoQzCG3Reeimaf7vLuUpbGUg3LdeLE2Dr2Hbx50jDrznaZLx/xTsmARQXNcScYzHngnTPtjbdn qFV/bxsfS7DvV+K3c+xITuKFCgIKchNY6a6Ona2by6J9qszdX/Ut8WxN57KrILBANpV0M8ReBrd1W PoiWvOcd5gfPqA==; Date: Sat, 12 Apr 2025 15:51:36 +0300 Message-Id: <868qo5mtk7.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87tt6t60o0.fsf@gmail.com> (message from Visuwesh on Sat, 12 Apr 2025 17:40:07 +0530) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> <871pty8ynw.fsf@gmail.com> <86r01xn0ah.fsf@gnu.org> <87tt6t60o0.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: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org > Date: Sat, 12 Apr 2025 17:40:07 +0530 > > [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote: > > >> From: Visuwesh > >> Cc: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org > >> Date: Fri, 11 Apr 2025 21:42:51 +0530 > >> > >> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote: > >> > >> >> From: Visuwesh > >> >> Cc: Johann Höchtl , > >> >> 77732@debbugs.gnu.org > >> >> Date: Fri, 11 Apr 2025 18:01:27 +0530 > >> >> > >> >> I inserted a few message statements (see patch below), and I cannot > >> >> figure out where the sudden addition in the compilation-message is > >> >> coming from. > >> > > >> > Which addition is that? I'm afraid you lost me here. > >> > >> Oops, I butchered the statement: after the second time you type 'e', the > >> "Grep finished..." message attains a non-nil compilation-message > >> text-property. > >> > >> > Can you explain which line of code causes the error, and why? > >> > >> That's what I tried to figure out by adding the message statements but I > >> fail to understand how the compilation-message text-property is being > >> Added. The relevant bits from *Messages* is at the end. > >> > >> When I say 'e' for the first time then go back to grep-mode with C-c > >> C-c, there's no extra compilation-message text-property. > >> > >> When I say 'e' for the second time around, till the end of > >> grep-change-to-grep-edit-mode, there's no extra compilation-message > >> text-property (lines marked with *). But in the gap between > >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other > >> action being done by me in between), the extra compilation-message > >> text-property is added to the "Grep finished..." line. > > > > I'm guessing this is font-lock (called via jit-lock mechanism)? > > That may be the case... > > > Maybe you should do something with font-lock-extra-managed-props? > > Just pushing 'compilation-message to font-lock-extra-managed-props did > not help. Unfortunately, I do not know enough to debug this one. And it doesn't help that it is a heisenbug: I could only reproduce it once, even with your recipe. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 10:54:04 2025 Received: (at 77732) by debbugs.gnu.org; 12 Apr 2025 14:54:07 +0000 Received: from localhost ([127.0.0.1]:57696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3cF6-0007oW-Vh for submit@debbugs.gnu.org; Sat, 12 Apr 2025 10:54:03 -0400 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]:42326) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3cF2-0007mw-9M for 77732@debbugs.gnu.org; Sat, 12 Apr 2025 10:53:57 -0400 Received: by mail-pf1-x442.google.com with SMTP id d2e1a72fcca58-7398d65476eso2370761b3a.1 for <77732@debbugs.gnu.org>; Sat, 12 Apr 2025 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744469630; x=1745074430; 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=2L7gtbHAByJRCqomazjjzZwsHz8L1/kK/sHEbTJ75Dw=; b=LW/uH9qJMNFE1xLzyUV3DFiLysyGCxKbXukNlEtwygBH3QDhlvYMxWPEgN7bUdeTRP wvdFzzxuRGXAOD5vv8TzrRtF7sKvDwY0Hs7pKnFh+DGbovjqD9wghzzDSEr5OzrAuIHt 1oHQIrc7OA4+6XyX5Ggndl2OSW1NmnK/UykG11DWSRvOKYeNBAMQp1xIJjC72ItRoDAu R1W24z3IoER5jG4/roMMFIPqrEXJ4+/nJx24YsDbstlUiUSrq70ToVvpbKlbx9TLpxqo L9//qSSBak9zydSniiEUKO5alofoC/ku111kEJ+OeaucP+Trq2b0Dm8YO/vmqpHQ5b+f aodg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744469630; x=1745074430; 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=2L7gtbHAByJRCqomazjjzZwsHz8L1/kK/sHEbTJ75Dw=; b=o1JzV33R/cswQkSrgZVZJ3qKD5S1UTUOPWl6z+QWXudMX4eWAIlsYGm0RsMoBDD04C /zKQG+5nu7/G2qwhJrAxHnf0/WUpiWpfuPvMT3CPYb6WaA9AJqnTM1tMXQ3JfR3yJSNo 7flyRTdRvDfHIYzmQ5IPRfU9wy/5pdlb/itpn2oHPfxXciWRr2cIyjgdPXC7a8qqJeLB YxzxZ2brQCdcQvyadJCxAqhXlhzppZ75nN652RG7ybYbmMmAW4cNC+cH3N+l3hvEOJDA q3Jwd2na0CFYkTK+4V8VkVdycTKwzwsidQ8pMcVAh086aLFmYSX0tTAxIKO4mooUeb2n VVPA== X-Forwarded-Encrypted: i=1; AJvYcCVRIRNA5REZEcBH86n3md3koDGd+Xwz8OTvtyb9tYLwBD/nV0mLWDyNLUAWso04W4+ZUayjlw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywj0BXglqjxU1mwQwItYjF0QI1cjsqASYfr5n65fQKLa2bb2qWD kHUCqs13sQhEtEdWphW8y4Z0IrkgLGiSfwEcsri/X1dVRFpP8OZ3 X-Gm-Gg: ASbGncshk2WIijDDtg6aRb0tyaFVqQBnZfYEadCm2Fn8Dz85oPfkpsm1tAuimzVspkQ c/rbpQEgS/IM7nu7hOwnxduBechUAW5x0K9EoBrDJJKw5mGpicAovvl2NBRsltnbYUlEzlKyIkA UNIYN/ZrPmBfXzN4T8O/TJz3/frrhAtWC1wfzTcjdtJA60SG+YSDBFrjm/dKfQlzFe83uloyLrp fcAIRvc1iyFKSEvRLp/+08ZwUrbk9/e1KDTBXtaSyUw63+kPc5K4n4norGHYnGX8QKXPGVt3LSB xIA3JNkUZcCqNdPasz6MWqRIAIZ7e4eCnrddcg== X-Google-Smtp-Source: AGHT+IEYdDWfEZEZam4Xk2mbQxr0aBJFMazJ6avt3GtUREb/qsY/dpmIIrLSvoSH8cnqOERIV7e6yQ== X-Received: by 2002:a05:6a00:1484:b0:736:4d05:2e35 with SMTP id d2e1a72fcca58-73bd0bd1a07mr8577606b3a.3.1744469629459; Sat, 12 Apr 2025 07:53:49 -0700 (PDT) Received: from localhost ([115.240.90.130]) by smtp.gmail.com with UTF8SMTPSA id d2e1a72fcca58-73bd21c5ea3sm3585445b3a.66.2025.04.12.07.53.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Apr 2025 07:53:49 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <868qo5mtk7.fsf@gnu.org> References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> <871pty8ynw.fsf@gmail.com> <86r01xn0ah.fsf@gnu.org> <87tt6t60o0.fsf@gmail.com> <868qo5mtk7.fsf@gnu.org> Date: Sat, 12 Apr 2025 20:23:45 +0530 Message-ID: <87lds55t3a.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: 77732 Cc: johann.hoechtl@gmail.com, 77732@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=AE=A9=E0=AE=BF =E0=AE=8F=E0=AE=AA=E0=AF=8D=E0=AE=B0=E0=AE=B2= =E0=AF=8D 12, 2025] Eli Zaretskii wrote: > [...] >> >> When I say 'e' for the second time around, till the end of >> >> grep-change-to-grep-edit-mode, there's no extra compilation-message >> >> text-property (lines marked with *). But in the gap between >> >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other >> >> action being done by me in between), the extra compilation-message >> >> text-property is added to the "Grep finished..." line. >> > >> > I'm guessing this is font-lock (called via jit-lock mechanism)? >>=20 >> That may be the case... >>=20 >> > Maybe you should do something with font-lock-extra-managed-props? >>=20 >> Just pushing 'compilation-message to font-lock-extra-managed-props did >> not help. Unfortunately, I do not know enough to debug this one. > > And it doesn't help that it is a heisenbug: I could only reproduce it > once, even with your recipe. I can reproduce it every time I repeat the recipe. Does it help to use M-x rgrep instead? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 13 02:04:12 2025 Received: (at 77732) by debbugs.gnu.org; 13 Apr 2025 06:04:12 +0000 Received: from localhost ([127.0.0.1]:37183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3qRu-0005Y8-F2 for submit@debbugs.gnu.org; Sun, 13 Apr 2025 02:04:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45672) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3qRr-0005Wg-K9 for 77732@debbugs.gnu.org; Sun, 13 Apr 2025 02:04:08 -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 1u3qRl-0007Ga-9a; Sun, 13 Apr 2025 02:04:01 -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=9Vy0bs18SbrrgfoOAzPHRY3bfCfkAdHk2TS/9gPgbug=; b=lLgQNYWgroB+Pq2VUD20 YKi/RJOTsQ8W16Y2UcwSCgu3gekCvmK0fTWQZErSbdpZE90CyeqE6PCQGEyzPPbpEPMYV5bgBw5YJ 9/FoQcArGbJzQJo/hNC5g4i0VnX0kvsnX0SpulcQPZ4lnxYTjAKRUJ/Q6ZIuSyXUtYGTM+cX14+gb GOgHtmpbH9TFAfK9KiL1CQhymks4KpEXOkr3AFDxEkk/GrMvMdbvPUEzv9+CL7Y+UgCK+1Qpu/24F K9ZamB3cyliJEzfrpku/WawnQuWN5UE0Pr04SVrvabBkVSXWXNUNn+2ngLJPwNht1hYOvnEOm6ub3 LMrw6RHE1MI2Gg==; Date: Sun, 13 Apr 2025 09:03:56 +0300 Message-Id: <8634ecmwc3.fsf@gnu.org> From: Eli Zaretskii To: Visuwesh In-Reply-To: <87lds55t3a.fsf@gmail.com> (message from Visuwesh on Sat, 12 Apr 2025 20:23:45 +0530) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: <86wmbqoqq1.fsf@gnu.org> <87bjt298ww.fsf@gmail.com> <86tt6uofnu.fsf@gnu.org> <871pty8ynw.fsf@gmail.com> <86r01xn0ah.fsf@gnu.org> <87tt6t60o0.fsf@gmail.com> <868qo5mtk7.fsf@gnu.org> <87lds55t3a.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: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: johann.hoechtl@gmail.com, 77732@debbugs.gnu.org > Date: Sat, 12 Apr 2025 20:23:45 +0530 > > [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote: > > > [...] > >> >> When I say 'e' for the second time around, till the end of > >> >> grep-change-to-grep-edit-mode, there's no extra compilation-message > >> >> text-property (lines marked with *). But in the gap between > >> >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other > >> >> action being done by me in between), the extra compilation-message > >> >> text-property is added to the "Grep finished..." line. > >> > > >> > I'm guessing this is font-lock (called via jit-lock mechanism)? > >> > >> That may be the case... > >> > >> > Maybe you should do something with font-lock-extra-managed-props? > >> > >> Just pushing 'compilation-message to font-lock-extra-managed-props did > >> not help. Unfortunately, I do not know enough to debug this one. > > > > And it doesn't help that it is a heisenbug: I could only reproduce it > > once, even with your recipe. > > I can reproduce it every time I repeat the recipe. Does it help to use > M-x rgrep instead? No. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 13 04:01:37 2025 Received: (at 77732) by debbugs.gnu.org; 13 Apr 2025 08:01:37 +0000 Received: from localhost ([127.0.0.1]:37954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3sHY-0001pg-2U for submit@debbugs.gnu.org; Sun, 13 Apr 2025 04:01:36 -0400 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:52243) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u3sHV-0001nw-7o for 77732@debbugs.gnu.org; Sun, 13 Apr 2025 04:01:34 -0400 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e61d91a087so4852140a12.0 for <77732@debbugs.gnu.org>; Sun, 13 Apr 2025 01:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744531287; x=1745136087; darn=debbugs.gnu.org; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=rUxwoW5Ul/t56dXrM3pqCgK9ZBoAaz1VdCWdJEQprFQ=; b=d2pPjhHmovKwtvswZFl3bWAwTTJXBwB7/8NdMw7hEQIDz3xpYIKhB4M26pP+W5XA3Y tSynpZjYeH5DrcIWzA1Z0Cb8C0RHcCzlr5c4NyBT3ueLa8Jbq/LU2qjQ07sDue6cQ/ln p6ArXEnrlEokspGeyOxvx28IkTti+Cn76jsARWFxDy7kJgWXZsOseN6b8FvSeAPEWT6h IZlKcsEf5aZD3+z3gTtzoXFsoyOHUg4eIX8+kXrQp2s+Pmf4+5+rRQKEbuojw+Xl5wDY X383s7uWiDIwTUFeiNyqw9ak0YMfkuxV/tXgJHiXgabftiTmEPFv3PIv5/dikWtoLYXy eNUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744531287; x=1745136087; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rUxwoW5Ul/t56dXrM3pqCgK9ZBoAaz1VdCWdJEQprFQ=; b=PvF/uBMQ3M/UzRKFW2qm6CfvA3vXbCBUf0ibO4Vvj7XVcIOR1Df5xmKR/q0F/JHY+v BOocXyr4Ad1+hrpuuFDZhEupKh81ToBr8dUaRrE4HJfIZuGRNGsfLPeq2HBzs6MtNbgj JCnWpOS54UTI6M1jtrWVuepoOw9JMqflX1x974MbqD+yeG2xLZKvS7WJzO0Isk5dd80A YrYEuAeLwUH04sVr9yqEiXzO76K2nR5YqCpTdi7QkLhj3KxML0Y8RyxTtqa2jqsIdoj8 fVtJ1Ubu5tXpt6sFfsCs80W3nITbVQLPjImaUnEsqC4qSixeyKE2c4OWlFNWQN0enqOQ i8Og== X-Forwarded-Encrypted: i=1; AJvYcCWEYos5gXJjPwls5YjT00bZrWGar1pJqz4oUcJuAgsVbehSosi1KSKzKf33+BF9k10WF6z0sg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzCk5hfLOwZ8/sorBDruBUmsyzuO62EEN8a7tayim2SlT04eMgi f361IR/tBv0wcAaee1phm28eIEn+yhLiIaxjgmi7i3ZSatKFzp9e X-Gm-Gg: ASbGncvonZ/3zdcTyKEyAPgBx3nw3cCxOiIui8u9Q5/d5Pt539VNAd8Al+cI3xAM/tR JJE1Ub8oh327G7guCCOFxQjvTHMkf5zRmx7kAzLKYOqheV3DW4BdqumPL6mDMoux4oQ+uuKvrsd RVZWwRp2iODf2X80gOgvXkfDdCqgr37lL2KsgMyZl7ObGgEadTqEocrK4pRb5ONguNKAu6+5Jyg UIfGyVTc4IGu8EoGUoPq5ghiSZ48R8JAIiGvyD2XqJ6M3W8jN1G78BtOABEBhcNSO7KoepHOxGU p2qXaQ0HKK964sWbCQ2xeKCAnj96YtIhrX1cfBCNP4MVfA== X-Google-Smtp-Source: AGHT+IFayi4WTSr2QR8O2kP4oFnUTX5UMUYjVjfZZynN1clD9M6hLYE9V4LD7HSnz2IP+ueNIdDlpw== X-Received: by 2002:a17:906:db05:b0:ac7:16eb:8499 with SMTP id a640c23a62f3a-acad3439edbmr748727866b.5.1744531286527; Sun, 13 Apr 2025 01:01:26 -0700 (PDT) Received: from localhost ([185.229.155.55]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-acaa1ccacecsm696678966b.127.2025.04.13.01.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Apr 2025 01:01:26 -0700 (PDT) From: "Paul D. Nelson" To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <8634ecmwc3.fsf@gnu.org> (message from Eli Zaretskii on Sun, 13 Apr 2025 09:03:56 +0300) Date: Sun, 13 Apr 2025 10:01:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, 77732@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 (-) Here's a reliable recipe that produces what I suspect is the key issue: ---------------------------------------- emacs -Q Disable global-font-lock-mode. Use rgrep in any situation that returns some match. (The emacs source tree works, as does a dummy folder containing "test.txt" with a single line "foo".) In the *grep* buffer, press n. ---------------------------------------- After this, the line "Grep finished ..." has the compilation-message text property, which should not happen. The erroneous property gets added in compilation-parse-errors in the final "add-text-properties", apparently because the regexp used to detect matches picks up the "Grep finished..." line. Hope this helps narrow it down. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 19 10:18:23 2025 Received: (at 77732) by debbugs.gnu.org; 19 Apr 2025 14:18:23 +0000 Received: from localhost ([127.0.0.1]:34951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u691S-0008Pl-Jm for submit@debbugs.gnu.org; Sat, 19 Apr 2025 10:18:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46540) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u691P-0008PQ-EK for 77732@debbugs.gnu.org; Sat, 19 Apr 2025 10:18:20 -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 1u691J-00054P-JC; Sat, 19 Apr 2025 10:18:13 -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=dH9UXAt8U9p2lnnKGzUlD5bTkTSvblrT1xXu5ARFXTc=; b=DdVEEjyqA2Yb hZcF+2Hj4byRxXqr6huon/r9jtd5q30dbSngS1XzSQ+C+gyYU6Hq1KcaLD/Bznnae59rY+vzegr0s aWbo+CTzE36VoEOon+flJ4o6I8ILYaoj830nKX5C9/b5avmcjeQCqLOBifWPx/jrPI4iWvE1a73ZG iFgmXRP7EwZd6E9bVLwGPkYBXCCnhOY/fjHrv8VoxcsYuDESvvBUUqcsZKutE6OsuZEmQdMb5TJzd 0hk3RQ4BrZRTJ6KKnIn9ml4zArBLulC4gFtIoyeHSTTCep8qedvAxR4t62XPgifVkJV2m256e+dJh JRZWsXJwvWBvNf3kwzF1Zw==; Date: Sat, 19 Apr 2025 17:18:10 +0300 Message-Id: <861pto8cbh.fsf@gnu.org> From: Eli Zaretskii To: "Paul D. Nelson" In-Reply-To: (ultrono@gmail.com) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, 77732@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: "Paul D. Nelson" > Cc: visuweshm@gmail.com, johann.hoechtl@gmail.com, 77732@debbugs.gnu.org > Date: Sun, 13 Apr 2025 10:01:25 +0200 > > Here's a reliable recipe that produces what I suspect is the key issue: > > ---------------------------------------- > emacs -Q > > Disable global-font-lock-mode. > > Use rgrep in any situation that returns some match. (The emacs source > tree works, as does a dummy folder containing "test.txt" with a single > line "foo".) > > In the *grep* buffer, press n. > ---------------------------------------- > > After this, the line "Grep finished ..." has the compilation-message > text property, which should not happen. > > The erroneous property gets added in compilation-parse-errors in the > final "add-text-properties", apparently because the regexp used to > detect matches picks up the "Grep finished..." line. Thanks, but can you be more specific? Which regexp is that, and why does it match "Grep finished..." only sometimes? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 20 12:04:41 2025 Received: (at 77732) by debbugs.gnu.org; 20 Apr 2025 16:04:41 +0000 Received: from localhost ([127.0.0.1]:51307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u6X9s-0002qr-Js for submit@debbugs.gnu.org; Sun, 20 Apr 2025 12:04:40 -0400 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:49241) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u6X9p-0002pt-T2 for 77732@debbugs.gnu.org; Sun, 20 Apr 2025 12:04:38 -0400 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-aaecf50578eso497962566b.2 for <77732@debbugs.gnu.org>; Sun, 20 Apr 2025 09:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745165071; x=1745769871; darn=debbugs.gnu.org; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=bLvAESJPXKKeZ819yyn4o/2lbtjLjPBicaeLahbrtJs=; b=Bf4MMvKJ2RedkKGw+HBMoLapWILuwHH8CEDJhevu6PQdHtEdeAr+9Mbci4igXwiVQ7 9yDwp/ZBhcYpx/TOnqWI7a/m8NE9e8fb02fooGnDPglfrVyhvQwFmrBYaJlj9ds7OAcD p+S/ThqnUxJSYKQvQiWcFWLtfJI0tK6v8b54lSPqvXEXYE4EGKiYhmma11kd2sGYVHWm Ttur7fSQYRxkjueaTOxwMYp90Eg7NnG18CTo+ULtWq9bQ1uPDg77iphVr9Ru78CuMcUQ S22erJHYCDAsmmA1M2+qHEc/ufSVljwXT5DU0Uf7p0fouhu2PvN99krJRYtUTCvpkmj7 o0WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745165071; x=1745769871; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bLvAESJPXKKeZ819yyn4o/2lbtjLjPBicaeLahbrtJs=; b=mdMSF6iX4GAtLutpTyJBlqMKawW+6Y15mfFhK0T3HI8AKw3znKfDoNPXXEngPlZPhO AWbEFTfxVEdliQZpTuu4NOa/nPmUczkdz9CgoAlOfuoepXXjYAnTI08F+nT6+yr63cyN PZdO3sNdvEJF9SmIiRxz10/kT8hDJx9x9H0kKtHGlSkGRzHdc2BX0lPatFDrV7lAHBBl lW/PKpS78EziB1ICWEe5kdfeL1PszIF4zKQWFa0kJJ44s+7bn9XyRbzP2LhxBcap5Hld M9npT/8eA2tqBMBSqoYB4KI89D+dno7s2zyHWvAYx+r0c56tcaPStXu1KdFbOU6XiKfo fMZw== X-Forwarded-Encrypted: i=1; AJvYcCVwgBdRqvvbElj3LLIomy7ck6LXbYqvYd4WxuABm1jkpFUwxTOadOhNbvJDAGWtEf9tt7X4wA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy96OabyN7O+H6bWvEyT3SRU9wXx2HFqa4Zm33m1+q6p3li7cSN z/eEW5NuvAaNmoPWCQpThxKouDaz8UZ/IQJKkZ9BHhxW9QCozcimRlkdvIsl X-Gm-Gg: ASbGncs2/z6ThlnYT1q9SxKuk109tDI+Hf1OkeBfHp32Pnwjj/VGi7QnYZdOkslYVMD gOKhozTgXQUp/knrfP83nlbAWP/rSv3gsALU8XBRQ6mFSIfJ8D0jOGjPdyuCHlDuELh5r8wxFtM qSYRdcC1lQnGhtDchIiZhzGkSAIPwAiMZ7ELr5p+or+I7ayhxz8Bp+9kcCVddHdm20Bxkub710C Nl98Q1hLmdyWp9coXETD6kr93sXu5g+vcu6kzc+Ii0T5rCOvIHcgKGvbNp/84VLLMzorX1H7JWq eHHFloGB5dlfJsU0JtyLWvffMsncW8fGHVSocAYO8BZmRBOfFBIWolO2 X-Google-Smtp-Source: AGHT+IGb/+vvSUkzOzV4/Rhcn7pJ2o/TOnk9h1oYPKeqorF9nlPhOiZ7Ren2TZW6bhpJ4r2XTCT6hQ== X-Received: by 2002:a17:907:2da5:b0:ac3:8626:615 with SMTP id a640c23a62f3a-acb74df2c05mr839982366b.49.1745165070935; Sun, 20 Apr 2025 09:04:30 -0700 (PDT) Received: from localhost ([185.229.155.55]) by smtp.gmail.com with UTF8SMTPSA id 4fb4d7f45d1cf-5f625833ef1sm3480160a12.51.2025.04.20.09.04.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Apr 2025 09:04:29 -0700 (PDT) From: "Paul D. Nelson" To: Eli Zaretskii Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: <861pto8cbh.fsf@gnu.org> (message from Eli Zaretskii on Sat, 19 Apr 2025 17:18:10 +0300) Date: Sun, 20 Apr 2025 18:04:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, 77732@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 (-) Eli Zaretskii writes: >> The erroneous property gets added in compilation-parse-errors in the >> final "add-text-properties", apparently because the regexp used to >> detect matches picks up the "Grep finished..." line. > > Thanks, but can you be more specific? Which regexp is that, and why > does it match "Grep finished..." only sometimes? Sure. It's the first regexp from grep-regexp-alist, and it matches "Grep finished..." consistently: evaluating (with-temp-buffer (insert "./test.txt:1:foo Grep finished with matches found at Sun Apr 20 15:28:29, duration 0.10 s") (let ((pat (car (nth 0 grep-regexp-alist))) results) (goto-char (point-min)) (while (re-search-forward pat nil t) (push (list :file (match-string 1) :line (match-string 2)) results)) (nreverse results))) yields ((:file "./test.txt" :line "1") (:file "Grep finished with matches found at Sun Apr 20 15" :line "28")) As a result, compilation-parse-errors adds the compilation-message property to "Grep finished". Thus, with font-lock disabled, there's a clear, reproducible bug caused by a broad regexp. When font-lock is enabled, it often "covers up" the bug via the following entry in grep-mode-font-lock-keywords (simplified): ("^Grep[/a-zA-Z]* finished with \\(...\\).*" (0 '(face nil compilation-message nil ...) t) ...) The unpredictability must come from some race between compilation-parse-errors and font-lock-fontify-region. I think the right thing to do is to fix the bug in the "font lock disabled" case, but it's a complicated issue and I don't have an immediate suggestion. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 21 10:27:22 2025 Received: (at 77732) by debbugs.gnu.org; 21 Apr 2025 14:27:22 +0000 Received: from localhost ([127.0.0.1]:35931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u6s7F-0003QB-Ge for submit@debbugs.gnu.org; Mon, 21 Apr 2025 10:27:21 -0400 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:50507) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u6s7C-0003Pm-1d for 77732@debbugs.gnu.org; Mon, 21 Apr 2025 10:27:19 -0400 Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ac339f53df9so705161566b.1 for <77732@debbugs.gnu.org>; Mon, 21 Apr 2025 07:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745245631; x=1745850431; darn=debbugs.gnu.org; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=UDACzR3pKMtgPWHiZu3x2ExncgfIR2Y30dIx/yfpvo0=; b=QtJZCoACEjPLPfFKTv/vLlTT6CQMX9kqK8y1p6vVGp3MFllsfiWO4oapZZZZEryBpJ 7Qjqw5SLuLJHPkT+FHrBkHPyTLsP8Y0/d//YqRM+Mkgrm7+11VtpXsQerTBApNF3gWca RmXDWET5sE7ix+qip5YgbzYHB8np90hYc2Me0xqISC+zoQswOvcglyfrYBQ+6cXFeG+I uWvy6lnuMhrUuoFFnYWzG1DNVflFP7o2oY0N7n6KBOXuAAyoGW4T2a7a8aD6pooh8uzT b2ekCsPI2L4qTJ1SCMgqKCkroMXdAwxX6XUpk3qxQweX2h7lO3fmm4szqFFZNH6VTDkZ c1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745245631; x=1745850431; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UDACzR3pKMtgPWHiZu3x2ExncgfIR2Y30dIx/yfpvo0=; b=W4oVgP93a0hCYhLOdklLRNq6NP+xVHVOJw1fTinMgia9d8rMQJ2kPxSxbftJtvG/xQ mp4/y1xV9/rkRnSsuj85hb+VidxJEbW1hJInCAfMnbuzV2nhFGcPrWf7xtupNQPvQzh9 vaeiNlaWVVVv3aBbb1IY08nmdyTBZSqFbfWCpkG/ImHqA6YtsTXsr3vuz/jWCLH73384 xU49BJ54eGO0iQ0+HdDG1FoostIICY9xef6flshQX7SWgBzMf8zQbHhxYrGvp7Nf4T9z 71NjkpKC8hnOnocXusJfX3fOsarALcDMask4e5dBUVLVZH4NlupXA9NJAVTNIxlfCZCh Sf9A== X-Forwarded-Encrypted: i=1; AJvYcCWaziZ5rH5gjbBNaWuAaao7Be/8XHU/3pLitPkGPK4WaN3139bz3J1TNGGmConmOjxSCkLhHg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyBKjXbt3W/Gwk4pEsAcdB3TCuVSCHZ5ATBr5S/Qcd72ghWOjEG Mc0yo5pntVCy7UNxcM4wTg3t4enf7d74qtRBSha1K+2eHuks+beu X-Gm-Gg: ASbGncs34qSlOZ5FguyHAjgHWY4LgyTlL8fbyw5pmamsbtYuvugglUhlNmv0L0FSdf2 5ldgg4V8qokab3N1CDGhpa5B5F23rTTaZTD822fDw17gWRywTLU2gGehS7gb1BPWugq+JL1JHJz 0rsdF97O8lmTeUBweVZFwZ7n+z1hLHqUjKIOxvYNeL5VYLr27D57HUuLjDbA/ToVAMtiPZHKacv RhovYeiAZNaFHx/3u6GZhUP1YtLUTS7a3AJDZmyJUwjWT+Q9kKmRHpDE8YaQ9Uh6mc0vTKaIpMW j9UtFLmLBjVbjbf71zneFnjXQRtypXCK2yfSy7K53y2HnA== X-Google-Smtp-Source: AGHT+IH/9uLf27/O4iHr3yPxvgjKbAGYCB4r8F0EblxAMYw1Ic3S7DsAXGac3tfjIqKjPOSDAU1dpQ== X-Received: by 2002:a17:907:3d4c:b0:ac4:3d0:8bc6 with SMTP id a640c23a62f3a-acb74b2d277mr1180746266b.13.1745245631141; Mon, 21 Apr 2025 07:27:11 -0700 (PDT) Received: from localhost ([185.229.155.55]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-acb6efa17f9sm509665766b.165.2025.04.21.07.27.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Apr 2025 07:27:10 -0700 (PDT) From: "Paul D. Nelson" To: "Paul D. Nelson" Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour In-Reply-To: (ultrono@gmail.com) Date: Mon, 21 Apr 2025 16:27:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77732 Cc: johann.hoechtl@gmail.com, eliz@gnu.org, 77732@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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I took a look at the manual entry for compilation-mode, which contains: Sometimes =E2=80=98compilation-error-regexp-alist=E2=80=99 doesn't c= orrectly determine the filename that is the source of the error. Use user option =E2=80=98compilation-transform-file-match-alist=E2=80=99 to make any ne= cessary adjustments, such as adding or changing a directory component, or even considering certain compiler messages not error messages at all. This suggests a surgical fix (attached) that addresses the cases of the bug that I had been able to reproduce. Perhaps Johann can check if it addresses his cases, too. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Fix-grep-buffer-display-of-finished-lines-as-matches.patch >From 2efcd27bb75c104b93116b2678ba2569dddebd9a Mon Sep 17 00:00:00 2001 From: Paul Nelson Date: Mon, 21 Apr 2025 16:25:06 +0200 Subject: [PATCH] Fix grep buffer display of "finished" lines as matches * lisp/progmodes/grep.el (grep-compilation-transform-finished-rules): New variable containing rules to prevent "Grep finished" lines from being misinterpreted as matches. (grep-mode): Add these rules to compilation-transform-file-match-alist (bug#77732). --- lisp/progmodes/grep.el | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index b0105f08ea2..ed64d8a5bc8 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -542,6 +542,13 @@ grep-mode-font-lock-keywords "Additional things to highlight in grep output. This gets tacked on the end of the generated expressions.") +(defvar grep-compilation-transform-finished-rules + '(("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)\\|\\(no matches found\\)\\).*" . nil) + ("^Grep[/a-zA-Z]* \\(exited abnormally\\|interrupt\\|killed\\|terminated\\)\\(?:.*with code \\([0-9]+\\)\\)?.*" . nil)) + "Rules added to `compilation-transform-file-match-alist' in `grep-mode' +These prevent the \"Grep finished\" lines from being misinterpreted as +matches (bug#77732).") + ;;;###autoload (defvar grep-program "grep" "The default grep program for `grep-command' and `grep-find-command'. @@ -971,6 +978,9 @@ grep-mode grep-hit-face) (setq-local compilation-error-regexp-alist grep-regexp-alist) + (setq-local compilation-transform-file-match-alist + (append grep-compilation-transform-finished-rules + compilation-transform-file-match-alist)) (setq-local compilation-mode-line-errors grep-mode-line-matches) ;; compilation-directory-matcher can't be nil, so we set it to a regexp that -- 2.39.3 (Apple Git-145) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 22 11:12:10 2025 Received: (at 77732) by debbugs.gnu.org; 22 Apr 2025 15:12:10 +0000 Received: from localhost ([127.0.0.1]:49368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7FIA-0000GZ-3t for submit@debbugs.gnu.org; Tue, 22 Apr 2025 11:12:10 -0400 Received: from mail-yb1-xb2c.google.com ([2607:f8b0:4864:20::b2c]:58804) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u7FI7-0000GJ-TC for 77732@debbugs.gnu.org; Tue, 22 Apr 2025 11:12:08 -0400 Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-e589c258663so4370174276.1 for <77732@debbugs.gnu.org>; Tue, 22 Apr 2025 08:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745334722; x=1745939522; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uT7IT9su2A+wH5sRU/cE8urfwlHaqvqdwJT7VXIsrDg=; b=mCeCgpX++jN7kE8tviYUE2c8ydh4VdDjFhCktBApTaVLbJlTOiby4RZsaoalZ9cInq Z/cIJk56eiN8H2Phry1KO5qYXNZ7+SJWnm508qn/vAMrZkkvGF7nKdrUpYfdOqUuZccp GT0ih3uTdgXERVg2K58VlZpEixxcT5k64rHle5fc68Oe70JE58GshZW4yvCfMxwEIbGv S3nMtCsGX1sTFiOLO4Uutxm0cOdhIGjJOlV06s0UtOFMklDJsHUx87LqEDknsAi5iy8m YutlUts8t6dEO4SkHpY4wDPp+DWwHYbCQXmkrZK9D2LcRXy/mDds+mlxcP1Sjw2zfDJ6 0q0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745334722; x=1745939522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uT7IT9su2A+wH5sRU/cE8urfwlHaqvqdwJT7VXIsrDg=; b=d9Q0yVZRdij2b++gF7k5kxx9WZa7OG6MOIlBvBLgeNBOjakNuipyuDn/1NBsqd9kEg h8qM7vfVVyxaDteA9ASQVEjYRxRpXASsGeshqWvWZ2SDxa00pm2IGnlyqJKyS1g0KDOI dketHJvuyx/13qwgjqKd9Nxz8ep2RPPS8DWZaPE4UTMHdTPIol1kYwDZjOtk53ceaB1P QLeFOvQo1Gz2mUGeUpfJwXOiWX8D1aItlhVy2qT0nRonjWGh4yvr7+PlzOcTvcBi5u5V ihTnrdiX8rXQ63Z+c5qkdt4X4HzAcEnpM9eNwQjYmuaEZi9u8+L0ho+wcvOFn/96X2n/ MPyA== X-Forwarded-Encrypted: i=1; AJvYcCV8AyZDGkjB+6Tc4XgySQMdjsglf+C5EYS4SE53EeqGzwnLLLpgwCMraXSyM77SxNmUV4D+Gg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxGzYUBT+bk/eFvLgsuvcxWRCuPcN0XDtkFqtlD9bUowqiU6gDX F/XkkNGvLSebwXE+yrxhDjhR+6Wo5MPSuRP58gVVyNgTLpgnrVxnev1WWrNQ/WC9+z533hFkHaH 5w5pBPR5Pgbjf1rVlNJzI/XJ4xw== X-Gm-Gg: ASbGnctiYNfkvilR4npN2JlSkBINE3+B4YGNSvhSx+uKFV2Vzd8sr39hSEiy4y+RGJJ +3lRsNK/GQSyizBH2EnKpjWZHPVtjoRuZ9jo/PvGZLuF/OE7Q03SLt2DRMZuoj+oO/pXKIVn1hK AZ6AUXHJt/Tif6FooFC2OkAw== X-Google-Smtp-Source: AGHT+IEi0YdtB8vO8u233nY6Oq+BPSBkUnOkUX+7JTz+atSUKT+RWdZkbjF0Mobbcl8SbKroGB/j3f0gIPhQ2AeUGzM= X-Received: by 2002:a05:6902:4482:b0:e72:d0d3:4c3 with SMTP id 3f1490d57ef6-e72d0d305e3mr6759472276.49.1745334722086; Tue, 22 Apr 2025 08:12:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Johann_H=C3=B6chtl?= Date: Tue, 22 Apr 2025 17:11:49 +0200 X-Gm-Features: ATxdqUGUsr2mMzfwVA42b19oTky6nJ7NPOgbn6WoKqkEIB0wLHYx1MOlNo04F4o Message-ID: Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour To: "Paul D. Nelson" Content-Type: multipart/alternative; boundary="0000000000001fd2aa06335f68c2" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 77732 Cc: eliz@gnu.org, 77732@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 (-) --0000000000001fd2aa06335f68c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I extracted grep.el from grep.el.gz I loaded the patch and applied it to grep.el The hunks applied successfully I retried my rgrep opperation and got this in messages: Source file =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/pro= gmodes/grep.el=E2=80=99 newer than byte-compiled file; using older file Making completion list... compilation-start: Symbol=E2=80=99s value as variable is void: grep-compilation-transform-finished-rules [2 times] So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o Still no luck but the compilation error remains compilation-start: Symbol= =E2=80=99s value as variable is void: grep-compilation-transform-finished-rules A new native byte compiled version of grep.el was created though. Is the compilation error actually misleading? It seems as if I get the erro= r Source file =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/pro= gmodes/grep.el=E2=80=99 newer than byte-compiled file; using older file Making completion list... compilation-start: Symbol=E2=80=99s value as variable is void: grep-compilation-transform-finished-rule using older file would indicate that it is using grep.elc but it seems Emacs does in fact use the NEW pathed grep.el Am Mo., 21. Apr. 2025 um 16:27 Uhr schrieb Paul D. Nelson : > I took a look at the manual entry for compilation-mode, which contains: > > Sometimes =E2=80=98compilation-error-regexp-alist=E2=80=99 doesn't= correctly > determine the filename that is the source of the error. Use user > option > =E2=80=98compilation-transform-file-match-alist=E2=80=99 to make any = necessary > adjustments, such as adding or changing a directory component, or eve= n > considering certain compiler messages not error messages at all. > > This suggests a surgical fix (attached) that addresses the cases of the > bug that I had been able to reproduce. Perhaps Johann can check if it > addresses his cases, too. > > --0000000000001fd2aa06335f68c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I extracted grep.el from grep.el.gz
I loade= d the patch and applied it to grep.el
The hunks applied successfu= lly

I retried my rgrep opperation and got this in = messages:

Source file =E2=80=98c:/Users/HoechtlJ/A= ppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el=E2=80=99 newe= r than byte-compiled file; using older file
Making completion list...compilation-start: Symbol=E2=80=99s value as variable is void: grep-compil= ation-transform-finished-rules [2 times]

So I rena= med grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o

Still no luck but the compilation error remains=20 compilation-start: Symbol=E2=80=99s value as variable is void: grep-compila= tion-transform-finished-rules

A new native by= te compiled version of grep.el was created though.

Is the compilation error actually misleading? It seems as if I get the err= or

Source file=20 =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/pro= gmodes/grep.el=E2=80=99 newer than byte-compiled file; using older file
Making completion list.= ..
compilation-start: Symbol=E2=80=99s value as variable is void: grep-c= ompilation-transform-finished-rule

using older file would indicate that it is using = grep.elc but it seems Emacs does in fact use the NEW pathed grep.el

Am Mo., 21. Apr. 2025 um 16:27=C2=A0Uhr schrieb Pa= ul D. Nelson <ultrono@gmail.com= >:
I took a l= ook at the manual entry for compilation-mode, which contains:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Sometimes =E2=80=98compilation-error-regexp-alis= t=E2=80=99 doesn't correctly
=C2=A0 =C2=A0 determine the filename that is the source of the error.=C2=A0= Use user option
=C2=A0 =C2=A0 =E2=80=98compilation-transform-file-match-alist=E2=80=99 to m= ake any necessary
=C2=A0 =C2=A0 adjustments, such as adding or changing a directory component= , or even
=C2=A0 =C2=A0 considering certain compiler messages not error messages at a= ll.

This suggests a surgical fix (attached) that addresses the cases of the
bug that I had been able to reproduce.=C2=A0 Perhaps Johann can check if it=
addresses his cases, too.

--0000000000001fd2aa06335f68c2-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 22 11:30:15 2025 Received: (at 77732) by debbugs.gnu.org; 22 Apr 2025 15:30:15 +0000 Received: from localhost ([127.0.0.1]:49427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7FZe-0001D0-LR for submit@debbugs.gnu.org; Tue, 22 Apr 2025 11:30:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50424) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u7FZb-00017V-5s for 77732@debbugs.gnu.org; Tue, 22 Apr 2025 11:30:12 -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 1u7FZV-0001QP-7N; Tue, 22 Apr 2025 11:30:05 -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=wLi/mP/KutTaZiyTq6fglwg+YGcZmvxEXryOgSBTns8=; b=F+Ny5bM6g+YE8iTVSUKF KUFXTfIVS+8nM8duWnGZrWcpWvG8ghTjlrNkF71X70uhaKlMaA3IhFER3cUmMnCb3DKKh++xoIY/r v9qWlKRyw+MM8WmnLPU1GRyym60waCCUA1+TYYGO77T2doTb61l8cevehc2sRr3iODgkH3iFB4HQ7 qe/VasQS8YvaSAckVB5IhR4eivbg8zqgU6457RQ+cv1bBPrzVhI1UIhG1JkPgP1TBOi1QqceU5gTK 4elHY2v0Nui7AmKO2uzp2MR5thzoPAtDBSxDnZaTB2xwIeNi0vBA8DVovt3GORBQnOyPf5qOePMaH hCA1Mj8wqPDmOQ==; Date: Tue, 22 Apr 2025 18:30:00 +0300 Message-Id: <8634e02ozr.fsf@gnu.org> From: Eli Zaretskii To: Johann =?utf-8?Q?H=C3=B6chtl?= In-Reply-To: (message from Johann =?utf-8?Q?H=C3=B6chtl?= on Tue, 22 Apr 2025 17:11:49 +0200) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77732 Cc: visuweshm@gmail.com, 77732@debbugs.gnu.org, ultrono@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: Johann Höchtl > Date: Tue, 22 Apr 2025 17:11:49 +0200 > Cc: eliz@gnu.org, visuweshm@gmail.com, 77732@debbugs.gnu.org > > I extracted grep.el from grep.el.gz > I loaded the patch and applied it to grep.el > The hunks applied successfully > > I retried my rgrep opperation and got this in messages: > > Source file ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’ newer > than byte-compiled file; using older file > Making completion list... > compilation-start: Symbol’s value as variable is void: grep-compilation-transform-finished-rules [2 times] > > So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o > > Still no luck but the compilation error remains compilation-start: Symbol’s value as variable is void: > grep-compilation-transform-finished-rules > > A new native byte compiled version of grep.el was created though. > > Is the compilation error actually misleading? It seems as if I get the error > > Source file ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’ newer > than byte-compiled file; using older file > Making completion list... > compilation-start: Symbol’s value as variable is void: grep-compilation-transform-finished-rule > > using older file would indicate that it is using grep.elc but it seems Emacs does in fact use the NEW pathed > grep.el To save yourself from all this trouble, patch grep.el in the source tree, and then say "make install". This will compile the patched grep.el and will install it in the correct place. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 22 11:46:11 2025 Received: (at 77732) by debbugs.gnu.org; 22 Apr 2025 15:46:11 +0000 Received: from localhost ([127.0.0.1]:49526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7Fp4-00020e-H5 for submit@debbugs.gnu.org; Tue, 22 Apr 2025 11:46:10 -0400 Received: from mail-yw1-x112e.google.com ([2607:f8b0:4864:20::112e]:54734) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u7Fp2-000202-HA for 77732@debbugs.gnu.org; Tue, 22 Apr 2025 11:46:09 -0400 Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-6ff1e375a47so48975387b3.1 for <77732@debbugs.gnu.org>; Tue, 22 Apr 2025 08:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745336763; x=1745941563; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wplQHMVoR88fZhwEwd+HqqH5ULJJ+JjHYm5d1ggTR24=; b=FIktposHXXXx5e20w4YHibWIwGY8sozLtLmqQuKLmire8T6bjKOITEMLBQ/JB+j9aL xjHfjn37o5RkCUYvqmX6oh1Xl666ZaeAjieKZr8Dxe+ENpZ8UXvJ1qhRgOMakdv0GG3e h7UaV8fF0DJZ6pCRetTevt6Dgh5aFfKWdqHc0y40yEDFdSH4euo0p1LWZMlPfEliiRy9 drQIgl6CegV7hceODmqZN88KnfV5BDFZWEPe3zGdWBWTF7hAfpL14womR/OXLJiMMDV2 whHldEU/vb3PAsz1aSjdhnSULgEJwm82ox68i3KXxmOxMc/O+xggnJvluyttG5xcUK9w 60dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745336763; x=1745941563; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wplQHMVoR88fZhwEwd+HqqH5ULJJ+JjHYm5d1ggTR24=; b=wfYqiyTUsY6kMSPbfBuim4s1SAwAqMULygbY9r1CmZ9INgyHjy/32uGS38d/TaWMWh PXEBWdIKbpdqfiwcchGn3IDjBIUFa/nHaW0Gk0q5LzhltmuO1H0TYgri/lRm6/4mg0wH ReLrrlOfs306iDDFrNHk3VzPFBwLjPJQ17cD4geYnDY4YEMsv0axaTOeFO2FnsczbQ1o 3cEKRauFloOj2BV/D0uaKS/wy7TYWPxuBIUFHOaDk5d7FYWHRRwLa3IHZOFnRLM0Bz9x uHRKTADwILCxO3rj7tn4KxgOmwAf0obiCoSqlWf/4+GBSzVyDwoksn2RPaQmQUt93+v9 DqiA== X-Forwarded-Encrypted: i=1; AJvYcCXxovvLzbUypNv18fV0Xp00Nabf23+EF7G8dzr9m70IZiiUw9m+wnlKKtn9vaX8Zh6yGsT5DA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzOff4lZaNpYpbeJy27z/UCUf1I+evBwO8Ggs/utIPcJfn1TLtd fnPgwiU9Dzyfqi4Fs0xWoDpdwS6NJQzDvM+HTUcXIU+VHYngoV+qfBTuU7eo4xbe75H8bq3gntM ZOc+h5iVpm3VV/gmdHkCP5RaSSw== X-Gm-Gg: ASbGncudfnPkD85uKpX+eV5laA0XtDj77obaNhyYkUaxNSInSAzYyiVP41oWVzeJcrv Got+2dh8vXlIXj3k5fJbKwf72VoJyCY3/IMlH9Exwu2DRd6xWzvNsKrLVHAc2+ULTUF0g7wHroz 1O6XEkzaR8Kg4QwkFTNpdL X-Google-Smtp-Source: AGHT+IEco4xqR/RKnmANL39X4/e43AEuv0QCuNGfApa+ZxmygZOO/yBhkDG5kojHkl+T2s8azpE6dFUAn0bGODT069g= X-Received: by 2002:a05:690c:9c13:b0:6fd:42c8:3c6a with SMTP id 00721157ae682-706cce0caf9mr218979557b3.34.1745336762838; Tue, 22 Apr 2025 08:46:02 -0700 (PDT) MIME-Version: 1.0 References: <8634e02ozr.fsf@gnu.org> In-Reply-To: <8634e02ozr.fsf@gnu.org> From: =?UTF-8?Q?Johann_H=C3=B6chtl?= Date: Tue, 22 Apr 2025 17:45:51 +0200 X-Gm-Features: ATxdqUHvI7sLPQu80hFfkWODKFK-lQBRmBIW4KW7fiXgPUcn0ZrHORyE8hJRAxQ Message-ID: Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000c33d1406335fe108" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 77732 Cc: visuweshm@gmail.com, 77732@debbugs.gnu.org, ultrono@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 (-) --000000000000c33d1406335fe108 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Di., 22. Apr. 2025 um 17:30 Uhr schrieb Eli Zaretskii : > > From: Johann H=C3=B6chtl > > Date: Tue, 22 Apr 2025 17:11:49 +0200 > > Cc: eliz@gnu.org, visuweshm@gmail.com, 77732@debbugs.gnu.org > > > > I extracted grep.el from grep.el.gz > > I loaded the patch and applied it to grep.el > > The hunks applied successfully > > > > I retried my rgrep opperation and got this in messages: > > > > Source file > =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/p= rogmodes/grep.el=E2=80=99 > newer > > than byte-compiled file; using older file > > Making completion list... > > compilation-start: Symbol=E2=80=99s value as variable is void: > grep-compilation-transform-finished-rules [2 times] > > > > So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o > > > > Still no luck but the compilation error remains compilation-start: > Symbol=E2=80=99s value as variable is void: > > grep-compilation-transform-finished-rules > > > > A new native byte compiled version of grep.el was created though. > > > > Is the compilation error actually misleading? It seems as if I get the > error > > > > Source file > =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/p= rogmodes/grep.el=E2=80=99 > newer > > than byte-compiled file; using older file > > Making completion list... > > compilation-start: Symbol=E2=80=99s value as variable is void: > grep-compilation-transform-finished-rule > > > > using older file would indicate that it is using grep.elc but it seems > Emacs does in fact use the NEW pathed > > grep.el > > To save yourself from all this trouble, patch grep.el in the source > tree, and then say "make install". This will compile the patched > grep.el and will install it in the correct place. > Would have to do that on Linux, the Windows machine is not apt for any serious development. Maybe I can get around that hassle .. --000000000000c33d1406335fe108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Am Di., 22. Apr= . 2025 um 17:30=C2=A0Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> From: Johann H=C3=B6chtl <johann.hoechtl@gmail.com>
> Date: Tue, 22 Apr 2025 17:11:49 +0200
> Cc: eliz@gnu.org= , visuweshm@gmail.= com, 77732@d= ebbugs.gnu.org
>
> I extracted grep.el from grep.el.gz
> I loaded the patch and applied it to grep.el
> The hunks applied successfully
>
> I retried my rgrep opperation and got this in messages:
>
> Source file =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs= /31.0.50/lisp/progmodes/grep.el=E2=80=99 newer
> than byte-compiled file; using older file
> Making completion list...
> compilation-start: Symbol=E2=80=99s value as variable is void: grep-co= mpilation-transform-finished-rules [2 times]
>
> So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o
>
> Still no luck but the compilation error remains compilation-start: Sym= bol=E2=80=99s value as variable is void:
> grep-compilation-transform-finished-rules
>
> A new native byte compiled version of grep.el was created though.
>
> Is the compilation error actually misleading? It seems as if I get the= error
>
> Source file =E2=80=98c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs= /31.0.50/lisp/progmodes/grep.el=E2=80=99 newer
> than byte-compiled file; using older file
> Making completion list...
> compilation-start: Symbol=E2=80=99s value as variable is void: grep-co= mpilation-transform-finished-rule
>
> using older file would indicate that it is using grep.elc but it seems= Emacs does in fact use the NEW pathed
> grep.el

To save yourself from all this trouble, patch grep.el in the source
tree, and then say "make install".=C2=A0 This will compile the pa= tched
grep.el and will install it in the correct place.
=C2= =A0
Would have to do that on Linux, the Windows machine is not ap= t for any serious development. Maybe I can get around that hassle ..
--000000000000c33d1406335fe108-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 22 11:52:59 2025 Received: (at 77732) by debbugs.gnu.org; 22 Apr 2025 15:52:59 +0000 Received: from localhost ([127.0.0.1]:49542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7Fvf-0002It-Fb for submit@debbugs.gnu.org; Tue, 22 Apr 2025 11:52:59 -0400 Received: from mail-yw1-x1131.google.com ([2607:f8b0:4864:20::1131]:45383) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u7Fvc-0002Ig-JZ for 77732@debbugs.gnu.org; Tue, 22 Apr 2025 11:52:57 -0400 Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-6ff37565232so44604097b3.3 for <77732@debbugs.gnu.org>; Tue, 22 Apr 2025 08:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745337170; x=1745941970; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=V0br/zKBGPKy8KcRSeIxM/fhUA4VZzbvMunwwtTKmVQ=; b=lAIOPE0qNo6bdprH5VqtpU2uIbx5kZVvkC37SsI/JrCtRoSB2iUgT+ns1P/NMXG60B ekc6pHqvC4EGvnByjtWhdaZ9r4mh4SxvrvCrnNt005oxYw0vkv1Ah9MTMrp47U82w09g hxvRGhBn60iprZQZrBEKJL08ZnKWYkbibDY79vHmUIfz6zs26Lv8BukAN/UI5n4lQzDc p4BShpV0MEkRYkKTg4vlOPU0x5EVM2seJ39MBH8AQvoX3udh04WNPAwhJlcQIrEnYy/o ZoM5FS9OhNNWhJFiQ0FiQvsxSsqEPlKACLx5+P9W1usuXOt2hFI5GiT197R16Zufix2n Bujg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745337170; x=1745941970; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=V0br/zKBGPKy8KcRSeIxM/fhUA4VZzbvMunwwtTKmVQ=; b=wRPHSvY/2VzQcKyOQ28a4y8xQRhSj6Yg21Wn38PhtwE6gZxMrFxnCO+kIDo5Fp1XEx hya3FoQp1j4DhhF0t6RGJqLGpViw8Xuv6HpfBjN27P3q2LW2p7mjhABO4+mvGJ3Sm+Lq u3uofy2u/vS9sbfUlZruCqmU0R5Tx0hIZQECbiPlyYXorTbtcFN65sn1Wgmqlrvr4AV3 c9hpz2X7g0FQYW8k36PHfmPIGetns/YrcLRotlbTx3yrXRCTdzDy0uHa/DPC7BsuRGxx x5DH7ptl0nBD2qeAnwERWCEjzYpxOEomC1v47fk/COEuiTfNU2fTSYuAmHbBt8zkvCki KWGg== X-Forwarded-Encrypted: i=1; AJvYcCXGxdWtKCYyY8fWT3zeoElDoLjNC7ujbtpxpdGiFF1CLVr7oEYIOC0TOpFxZSHQuIqqnMoohA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwrilRqQFgBE6nCyH0qR3X6XOu7ufsmm4MbDIQ5D2qIDzc6IEBJ 1CmExMGcVeRBYwhSAmhmQ3ZNpLW5NRWfsayB4rH8bIHYgT5qYzzV7stYPCZT2Tlb12TkIGR648Y zx56jqqPpIVUncW8oefo9HgkMVPE= X-Gm-Gg: ASbGncs/fGXffe6Q8DO8WnWsc2/HKLznx2Mxw3qHeVIMcwQK6WxtKwOnsH9LEfbsPFM Gsa+Efnz1mPMrYiOciR1XQYDUoL4zXU7EMFliF97Z1DY+82XEVIzyTgBRjFW0LC4JmLMCOB6NOA qMCJosKXxTalFkez+NnvGh0uY= X-Google-Smtp-Source: AGHT+IHSKrU6boSqKRgWWO6BtGs8498eajCYIxdxP01gO28PHCnbnE51rdTCKQ7bH+WKZGx4W1X2vER773mUcJIrCHs= X-Received: by 2002:a05:690c:6287:b0:703:b30d:3e2b with SMTP id 00721157ae682-706ccd1c77dmr256242777b3.20.1745337170342; Tue, 22 Apr 2025 08:52:50 -0700 (PDT) MIME-Version: 1.0 References: <8634e02ozr.fsf@gnu.org> In-Reply-To: From: Paul Nelson Date: Tue, 22 Apr 2025 17:52:39 +0200 X-Gm-Features: ATxdqUHhBunKN4kuSNsqblnTyP-W3nqBkq27Pn0HMTip8ibxBxAaabIZv7YVHDM Message-ID: Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour To: =?UTF-8?Q?Johann_H=C3=B6chtl?= Content-Type: multipart/alternative; boundary="0000000000000d3b3006335ffa86" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77732 Cc: Eli Zaretskii , 77732@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 (-) --0000000000000d3b3006335ffa86 Content-Type: text/plain; charset="UTF-8" Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with point after the "defvar grep-compilation-transform-finished-rules" form --0000000000000d3b3006335ffa86 Content-Type: text/html; charset="UTF-8"
Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with point after the "defvar grep-compilation-transform-finished-rules" form
--0000000000000d3b3006335ffa86-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 23 05:08:45 2025 Received: (at 77732) by debbugs.gnu.org; 23 Apr 2025 09:08:45 +0000 Received: from localhost ([127.0.0.1]:53044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7W60-0008BO-QP for submit@debbugs.gnu.org; Wed, 23 Apr 2025 05:08:45 -0400 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]:51621) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u7W5v-00089s-2Y for 77732@debbugs.gnu.org; Wed, 23 Apr 2025 05:08:42 -0400 Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-e72cc45d99cso2552624276.3 for <77732@debbugs.gnu.org>; Wed, 23 Apr 2025 02:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745399313; x=1746004113; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WdgDLwRD7cQ5365YmsMlaCOMj1q/oRKSZvJPGddxLaY=; b=Z1MxvZa59z4+FwJsiGbnBQk7tmx07kDsNKdC/0pM/Zmgqp2yqIwhpER27py+koOdRV ASqsJMQhbBw4QsxLlyggCQBUuTkU2olEozaBsplj+8QzkuQmFy+6V2hoAuwXtvzmfRnK 4dpdJxhXeoT1EcbyyAz4Ai3BPrtf8evM5ziMltaU2jO82Z4PviKdm1dZ6ddl7GhozBr6 c5l4eBwyUN5UnE2yq3MyOJn/uKFivlGAnap4baJC2P9L1mGtgVlwtLXvHwrZMMqFVMzF HsNPXgK5TnvXTTWMMADUmZIagPXknhzxiMSb9CA8HXIHjyFdUJ0w18MaDEp3XC3iSgjZ 0JSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745399313; x=1746004113; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WdgDLwRD7cQ5365YmsMlaCOMj1q/oRKSZvJPGddxLaY=; b=YZGOypfyzCbFcP0ZmUdcrrzrvXKyrxkqbgzwcfB/1b8hlF0OLc11TtH7A640/84QCr bAN5kWLnq2Rs7XUY3su/K8EI7ox68hOSo/wfdiGDSk0o2K5ZW6lCJfKa59NVBXwwZr0w NokL9fSfiNC/296P14rhdSowYA8apWfB1VepdmIr6ijqUIrlw3PLf2i9pRkr/8zMcH/H oRj4NPpUVRERTULOBfQtVrLTFScKQJimifaLlH5sskLx7oX/7uX78irTFcJA69O503q7 BdCin0zT+3BB2e1DvctN+i2trthXcF6A7F1MYGrfNkmRh5QEWbTbXujPe6BZ/hiKxygq fsKw== X-Forwarded-Encrypted: i=1; AJvYcCWvbtISrkf0787wTmVZAC7asomnHxLz+Zv8rLgdeu32J0hEf2gGQlWu2SOAUvXUnKlVjc8tQw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzjxODlzNpff3iEHaCV65dcS3O12D9snyTgOMAxRtFfbv2qMkmX /mlKQ6zkbdSmfSsyBwppMOQgmMAVk//ST2IV5P0URWcWyPLsQcKk2yey3rWoGo8vWuUE2LTckUb z+8x+pOx4pacBisrJKZ8ZvX1YSQ== X-Gm-Gg: ASbGncse7Ky7v1LhTMx91848N7dtoo8IHP2U4uJ0krb9nsY4S48EH2rPSFcGyclPunk heg1EQ0AzYOm65A9y+5SItUPhxceRzymCBiNr3+pJaPfeEjzTfcc41aSLQmYGq0l0XcE1jUQf1U I0N3DxprRcRkm4FsohJQAsbe2L+IBDRJ4eqhq4+NdQ22SISuqS7MSn X-Google-Smtp-Source: AGHT+IFUzTkXUzqimsH0GfVv+JrBB9iurnscsz8w/YiZ8hx69kkooDleorMfcnE+sKt/bsfWGDprEVhTGZ6VuqWcdKQ= X-Received: by 2002:a05:6902:12cb:b0:e72:d424:8e11 with SMTP id 3f1490d57ef6-e72d4249b94mr9925775276.31.1745399313177; Wed, 23 Apr 2025 02:08:33 -0700 (PDT) MIME-Version: 1.0 References: <8634e02ozr.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Johann_H=C3=B6chtl?= Date: Wed, 23 Apr 2025 11:08:22 +0200 X-Gm-Features: ATxdqUHZ5BdFHBopONNlXcong3DVTdDIXdBgtZyk-i-Q60KQ7xcGW2-r1NHzP3w Message-ID: Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour To: Paul Nelson Content-Type: multipart/alternative; boundary="0000000000000da68a06336e720f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77732 Cc: Eli Zaretskii , 77732@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 (-) --0000000000000da68a06336e720f Content-Type: text/plain; charset="UTF-8" Am Di., 22. Apr. 2025 um 17:52 Uhr schrieb Paul Nelson : > Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with > point after the "defvar grep-compilation-transform-finished-rules" form > That worked I did some tests with few matches, many matches For my use-cases this fixes the bug. --0000000000000da68a06336e720f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Am Di., 22. Apr= . 2025 um 17:52=C2=A0Uhr schrieb Paul Nelson <ultrono@gmail.com>:
Try opening the new= grep.el, C-c C-e in the buffer, then C-x C-e with point after the "de= fvar grep-compilation-transform-finished-rules" form

That worked
I did some tests with few = matches, many matches
For my use-cases this fixes the bug.
--0000000000000da68a06336e720f-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 26 08:37:25 2025 Received: (at 77732-done) by debbugs.gnu.org; 26 Apr 2025 12:37:25 +0000 Received: from localhost ([127.0.0.1]:59201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8emb-000084-CA for submit@debbugs.gnu.org; Sat, 26 Apr 2025 08:37:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39878) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8emX-00006n-2M for 77732-done@debbugs.gnu.org; Sat, 26 Apr 2025 08:37:22 -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 1u8emQ-0007ry-Qb; Sat, 26 Apr 2025 08:37:15 -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=hDk54li5YUZicR/qEx0x88ZZGLW3HA1+AE+X/fkBBeM=; b=jUj7fLnNO32mhYsWCkeA B4lUQ/wo8disSx1VanpOXt1QGmzQ6ULRvURbowbQHjGpTZY/Mx16Va197MqWdw5Y02wPnfTr/4sG3 JzmBrQu+wU1jDGfCTlBMdJv+CR1zqQ12Gx6tphoVe2wCGCCWORKGdctrW+tZbvRs6L/lzjmDibDHh rpFJGHAcnQQAM8hUuUEu2vSMkbJzWqDirSaYdSfcC0SiTt7dhXG3clvNS7VlDYJ3JQMdZIRFn+eDJ jjTvCAUvKvStOK9406H4L50UJQx4QUJhggHcHmCmpCZ2+LL2LENY2m1F5GrXHop+5/ve4a3ZmjzT2 liC7jliJD44Afw==; Date: Sat, 26 Apr 2025 15:37:11 +0300 Message-Id: <86v7qrt7yg.fsf@gnu.org> From: Eli Zaretskii To: Johann =?utf-8?Q?H=C3=B6chtl?= In-Reply-To: (message from Johann =?utf-8?Q?H=C3=B6chtl?= on Wed, 23 Apr 2025 11:08:22 +0200) Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour References: <8634e02ozr.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77732-done Cc: 77732-done@debbugs.gnu.org, visuweshm@gmail.com, ultrono@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: Johann Höchtl > Date: Wed, 23 Apr 2025 11:08:22 +0200 > Cc: Eli Zaretskii , visuweshm@gmail.com, 77732@debbugs.gnu.org > > Am Di., 22. Apr. 2025 um 17:52 Uhr schrieb Paul Nelson : > > Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with point after the "defvar > grep-compilation-transform-finished-rules" form > > That worked > I did some tests with few matches, many matches > For my use-cases this fixes the bug. Thanks, I've now installed this on the master branch, and I'm closing this bug. From unknown Tue Jun 17 20:16:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 25 May 2025 11:24:16 +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