From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#75379: 30.0.93; project-find-regexp expects "C" or "en" locale Date: Tue, 7 Jan 2025 21:38:39 +0200 Message-ID: <01eae803-0869-4bd3-a089-77c5050b870e@gutov.dev> References: <86jzb96qul.fsf@gnu.org> <871pxg3xu5.fsf@mail.linkov.net> <87y0zmjzfn.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 75379@debbugs.gnu.org, Eli Zaretskii , Matthias Meulien To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 07 20:39:23 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tVFQ9-0009tZ-UF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jan 2025 20:39:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVFPs-0008QU-UK; Tue, 07 Jan 2025 14:39:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVFPr-0008Po-2Y for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 14:39:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tVFPq-0000jL-Q7 for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 14:39:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=dURsMz4KEVEl1Ne0tIUETL9KbAFQpOCVOTqljdG2pQE=; b=QbH63leHNRqiGqAgW3GYQL158qYDUSqr8aCp2WNeUn7tyvFFmmK+c6CQCrG5YItIzMI7vdkj4RlKhp0e6UaZ4SBadzJcUMtsjSxVNrvJWMyc3272tC48JOesn1P9DeEQ8TcfJw++gw5yqu7eN+7Sow+AKyg5zCktuXitGIF3Ad/e6ECUwuvaUurvXHzov5CBqtx628pg1ejL0BswDVlGt1M46lsAhZKbFMXqzx9OC6t03GATOrGaFkRs8evH5imE/8ARdUQCjlCKDmz+yXgf9orRF1uu7zggfU3PCVWLPi/wqOEn3HbQ/Ef83HutQo4Tx0IVBMp/GlD7mZ/axkh6RA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVFPq-0001zP-Jg for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 14:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2025 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75379 X-GNU-PR-Package: emacs Original-Received: via spool by 75379-submit@debbugs.gnu.org id=B75379.17362787417640 (code B ref 75379); Tue, 07 Jan 2025 19:39:02 +0000 Original-Received: (at 75379) by debbugs.gnu.org; 7 Jan 2025 19:39:01 +0000 Original-Received: from localhost ([127.0.0.1]:44748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVFPk-0001z4-PJ for submit@debbugs.gnu.org; Tue, 07 Jan 2025 14:39:01 -0500 Original-Received: from fout-a2-smtp.messagingengine.com ([103.168.172.145]:38929) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVFPe-0001yh-FX for 75379@debbugs.gnu.org; Tue, 07 Jan 2025 14:38:55 -0500 Original-Received: from phl-compute-08.internal (phl-compute-08.phl.internal [10.202.2.48]) by mailfout.phl.internal (Postfix) with ESMTP id 4A6BB1380221; Tue, 7 Jan 2025 14:38:45 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Tue, 07 Jan 2025 14:38:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1736278725; x=1736365125; bh=dURsMz4KEVEl1Ne0tIUETL9KbAFQpOCVOTqljdG2pQE=; b= 4ro61hmViNc57gsPAHs9PPPI1QER5icAp80U/SlgRdn5XlgJWdML1ZiA9MA18vID NxbipEZEDpthTv483YnxdMhOXVT5iAgy7FiSqOeRik1kpdKc2l55n+M5TaqbuBEh EHMxbVycBGPBpL+aVffCFziC/B3/XQP5VOseUDPqYTwmEbv1o29JpqkwxrQYUjuZ 6Vg16A3oBuqDYvGZdcgLAWG557fyaxtnBaxZ9ydUh4IAcil9CQG1ELscmclld/IY TLyfkCTZJ8wewxPd5HgwtytmaKVCYtF18qz+QmDqU740lQkGuUL3AZKzpeWwpfhM dN0SG+w1gmx9yIvMhnWT/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1736278725; x= 1736365125; bh=dURsMz4KEVEl1Ne0tIUETL9KbAFQpOCVOTqljdG2pQE=; b=X q36rIQEywKN2FT+Wnww0xyLgh28J8yTn3+7HccBuihYYaD9kgol+y6lb++eFggx2 cYn22iFzGdW6dOrYZy4UpIH0HYLOzC1+1em620fG0WnYYNkg610l95KGvy5BOdWQ mgPcPelzpPP/CMspbLMSqN4I2uMhUnJyy1yBLsFUqpgBXNNRPSp8U9hCgdm9gbGo gQpgfVQ/vvgceH0ouIyHfTTDZANOYT+bbadRTAV/Zd8cxaJryscRsoe9Nrfq3iFY 17emE4Fqqm2rJjZlKn/xm8CPMDf0v+F7/DzucU7vIW9nV2PuGIxgnHSE04rVDfAF MCz/u1lCAtCSw1m8Pbkwg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegvddguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddv jeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrd guvghvqeenucggtffrrghtthgvrhhnpeegleefteekgffhvdfhtdegveevveetteegteev geettdehhfdukeetheffueekkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthht ohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhurhhisehlihhnkhhovh drnhgvthdprhgtphhtthhopehorhhonhhtvggvsehgmhgrihhlrdgtohhmpdhrtghpthht ohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepjeehfeejleesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Jan 2025 14:38:42 -0500 (EST) Content-Language: en-US In-Reply-To: <87y0zmjzfn.fsf@mail.linkov.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298746 Archived-At: On 07/01/2025 19:39, Juri Linkov wrote: > This is a known problem. Since the exit status is unreliable, > this is why 'grep-exit-message' has to use such a trick that > no output (i.e. '(not (buffer-modified-p))') indicates no matches: What about errors, though? Missing programs, unsupported flags, etc. Maybe Grep gets by without that due to the explicit probing step in grep-compute-defaults, but I'm not sure it's worth building up its counterpart in xref.el. > (if (eq status 'exit) > ;; This relies on the fact that `compilation-start' > ;; sets buffer-modified to nil before running the command, > ;; so the buffer is still unmodified if there is no output. > (cond ((and (zerop code) (buffer-modified-p)) > (if (> grep-num-matches-found 0) > (cons (format (ngettext "finished with %d match found\n" > "finished with %d matches found\n" > grep-num-matches-found) > grep-num-matches-found) > "matched") > '("finished with matches found\n" . "matched"))) > ((not (buffer-modified-p)) > '("finished with no matches found\n" . "no match")) > >> Also, when we know the format of come messages we can parse the file name >> out of them and create a button in the output buffer. Simply copying any >> unhandled messages removes that possibility. > Can we detect a file name in any message, e.g. by matching a path separator? We use 'grep --null', so the file name separator is a zero byte. We could scan the buffer to see whether there are any zero bytes (and if none - that would mean no matches), but the "binary file matches" message doesn't use that separator ¯\_(ツ)_/¯ Not does it start with a file name, so we have to have a separate understanding about that message's structure anyway: grep: test/lisp/gnus/mml-sec-resources/pubring.kbx: binary file matches grep: test/lisp/gnus/mml-sec-resources/secring.gpg: binary file matches grep: test/lisp/gnus/mml-sec-resources/trustdb.gpg: binary file matches