From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#75379: 30.0.93; project-find-regexp expects "C" or "en" locale Date: Tue, 07 Jan 2025 19:39:40 +0200 Organization: LINKOV.NET Message-ID: <87y0zmjzfn.fsf@mail.linkov.net> References: <86jzb96qul.fsf@gnu.org> <871pxg3xu5.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2223"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) Cc: 75379@debbugs.gnu.org, Eli Zaretskii , Matthias Meulien To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 07 18:41:12 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 1tVDZo-0000Pf-CM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jan 2025 18:41:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVDZh-0007IK-0D; Tue, 07 Jan 2025 12:41:05 -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 1tVDZe-0007Hk-DS for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 12:41:02 -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 1tVDZd-0003uy-Us for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 12:41:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=D6E3HD3304mMuv716a4X/gNW9HGCINNY8kxcAP+AJJw=; b=uQjpOjGmRYlAQcNrcMTxnuDH0oRwc9bkwJs4hg0g3tKJdysbRxk57juC4s4SNV3V4/ZUCNPA4GCRK9Fauw9yxkQFD6fhhXRLlTzrfHM9stIx4U0YT9lWD570rrDNMlGpnp/2kI3lbASLJpZYyhfrTfviqxmJl87z+DcUP9iRsc76XjbYAfbV7iLZiucIY2kjeNqsml4z4NV4lpbdd9AOxj86adJRU0YvirQSMmGzYs0DBGjvFYXElQTOqcsPAcgreL6EJD439tRL8Id4uecTiAHJmAS8Bikv29pDS+7FzfUWKThXKji5s1rU6ElzHfY1Ss1FZylyCCs68a4Um2FB3g==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVDZd-0003fc-Or for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 12:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2025 17:41:01 +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.173627162614029 (code B ref 75379); Tue, 07 Jan 2025 17:41:01 +0000 Original-Received: (at 75379) by debbugs.gnu.org; 7 Jan 2025 17:40:26 +0000 Original-Received: from localhost ([127.0.0.1]:44481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVDZ4-0003eC-8u for submit@debbugs.gnu.org; Tue, 07 Jan 2025 12:40:26 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:34231) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVDZ3-0003e0-70 for 75379@debbugs.gnu.org; Tue, 07 Jan 2025 12:40:25 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id A3561E0003; Tue, 7 Jan 2025 17:40:14 +0000 (UTC) In-Reply-To: (Dmitry Gutov's message of "Mon, 6 Jan 2025 22:33:21 +0200") X-GND-Sasl: juri@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:298732 Archived-At: >> Indeed, "Binary file matches" is a very important message that >> helps not to miss any matches in a text file that happens >> to accidentally contain a NUL byte. This saved me many times >> while using rgrep. 'project-find-regexp' could do the same, >> and show the same messages in the*xref* output buffer. >> So to not mess with translations, a simpler solution would be >> just to copy all unhandled messages from grep/ripgrep output >> to the xref buffer as is. > > Good point, maybe we could show different messages this way. It would be nice to keep all unprocessed lines. > But I think what I was trying to do there is distinguish between Grep > succeeding and ending up with an error (which we should report with > user-error), and the process exit status wasn't enough for that. > > Indeed, here's a command to try: > > git ls-files -z | xargs -0 grep gtags > > In the Emacs repository (among others) it exits with the status 123, > apparently one or more of the Grep sub-invocations ended up with non-zero > status (likely 1, indicating "no matches"). Even though the combined search > finds a bunch of results, that doesn't change xargs's exit status. And we > can't special-case the status 123 because "if any invocation of the command > exited with status 1-125" covers both Grep calls that found nothing and > Grep calls which were done with unrecognized flags (Grep exit status 2, > IIUC). 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: (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?