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: Mon, 6 Jan 2025 16:11:47 +0200 Message-ID: References: <86jzb96qul.fsf@gnu.org> 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="18402"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , 75379@debbugs.gnu.org To: Matthias Meulien Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 06 15:12:15 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 1tUnq2-0004bC-0z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 15:12:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUnpu-0003TJ-UH; Mon, 06 Jan 2025 09:12:06 -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 1tUnps-0003Sk-41 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 09:12:04 -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 1tUnpq-0007M2-PK for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 09:12: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=o69mtV+m4YrjoWLMKP6pHEUKHyL7K9qp8TX0kGJZpbA=; b=V56rKp9pHJdTRm92spUSSEPh4qwMilc6KPBWVsn3m/Uf1hawfWFM4IMsXYl9HVc496HL2rkvyi7MwFg4ukRUZKk5JT5pIxCiSdHxr7Cfe9CJDLlWlI1RF6yfHp3M8Qrd+2Fnx8Y8tQ8ZTe5lLaAgTMA6aT4sVtoUOUhZXRbZWE+DexA1xxqmb4/pwDJgYrYziSv6OEuN7esSecC8j3vKN//4UJy6mELeUpJqsxYZwtzUFpf+F6ZKvUiTCa2Jw3IKBsgJcnknK8H+JKbNpA+OCKFQisKRmjkR5sldnjsAzstsJapAjazFd90YZHCijf+gJ1yq/h1/AGs7x0stBHcvvQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUnpq-0006LO-E7 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 09:12: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: Mon, 06 Jan 2025 14:12: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.173617272024377 (code B ref 75379); Mon, 06 Jan 2025 14:12:02 +0000 Original-Received: (at 75379) by debbugs.gnu.org; 6 Jan 2025 14:12:00 +0000 Original-Received: from localhost ([127.0.0.1]:37384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUnpn-0006L5-W1 for submit@debbugs.gnu.org; Mon, 06 Jan 2025 09:12:00 -0500 Original-Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:47345) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUnpl-0006Kl-Bt for 75379@debbugs.gnu.org; Mon, 06 Jan 2025 09:11:58 -0500 Original-Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id C0E881380A4E; Mon, 6 Jan 2025 09:11:51 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Mon, 06 Jan 2025 09:11:51 -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=1736172711; x=1736259111; bh=o69mtV+m4YrjoWLMKP6pHEUKHyL7K9qp8TX0kGJZpbA=; b= mQQYVoKLwmMrhpDi1XNedU3SHjQVvDOZNisdc3/ma+A9nl8LN/u7g1vlf6dSzX0n nLeJaTijnw2q4jKfJYHK+76bjQIT2r7AAFQsvlk6nK7cQTlVxFOvyjwPDTpK+2jP d3dYDtgoWfWbRYmTq2slMCTUOGUtNzPed+rTEn+k/XJnJE/HU5bjute4chptn3Uu vUjrAdkl7zDHTmouBCm5qOZcaYzFmnHcDTKL91ny3g96pBh2oAslvoH2+99hGUMg X/uzmZ5p0HRXrO27NoPXw3qxEgP6CJEMB5EBeKJdaUrzRCtrlE/rzJ2+RjREt41W ucpwjDTGxPurWK0v16h+cQ== 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=1736172711; x= 1736259111; bh=o69mtV+m4YrjoWLMKP6pHEUKHyL7K9qp8TX0kGJZpbA=; b=m Ver5aibBKUPFBFRhWncMJR/czPqkOYgR40RxRAzmOk05IWPPOenejhBB7wBZxmtT QDiLHZQNEgFyD7wBvOWXafsKlNj1OBLmKz+7jqKMiFD4nNy2sbCbQ6jb89EBEkHq x+b7Qa6vO3Cz+7i+0djBD10I7/XmkFGxgMzCxBQ8Mahm/rePsNouIrPSESN8bFut oK22ita1RXD6SDNjqmB4KdGI6z7G842YjTYfOdlvAyidWov0qUJGX9BKMrzNpFeS zGIUqnfgbeWUXKt52fr28x7NadeM/K32vSHMbSvPH3bhVZ5y67WlLykl6Ucy95gN usrdmbn51zIxCmwoVl+jg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudegtddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehorhhonhhtvggvsehgmhgrih hlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepjeeh feejleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Jan 2025 09:11:50 -0500 (EST) Content-Language: en-US In-Reply-To: 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:298659 Archived-At: On 06/01/2025 14:36, Matthias Meulien wrote: > Thanks, this is a solid proposal, but as per comment: > >                   ;; TODO: Show these matches as well somehow? > > we would probably want to print these weird matches as well, in the > future. As you mention, search programs have a flag which avoids > printing these matches, but in certain rare cases it might happen > that a > mostly text file is detected as binary - and then it seems > preferable to > print all of such matches in the buffer rather than ignore them. > (Unless > people disagree?) > > And yeah, it's an old comment, so this improvement is not high on the > list, but whenever we (I/you/anybody else) get around to implementing > it, > > > What would be the "right thing to do"? To try to fix the current behavior on FR locales, we would tell grep to output its messages in English. That would make xref-matches-in-files behave the same across languages. Step 2 would be to render the "binary file matches" elements in the UI. > Should we call grep and ugrep > with "--binary-files=text" (and ripgrep has the equivalent "-a") and > then ask Emacs to guess whether each match is "compatible" with the > process encoding system and based on that decide whether to display the > match or print a warning like "match found among unprintable binary > data" nearby the file name? That's a more advanced solution - not sure if we can handle edge cases uniformly, such as actual binary files without newlines. Apparently newer Grep versions (2.11+ or something like that) will also break lines on null bytes, but that still creates higher odds of having very long strings in the output sometimes. Could be worth an experiment, though. A possible upside is being able to display these matches just like the others.