GNU bug report logs - #75379
30.0.93; project-find-regexp expects "C" or "en" locale

Previous Next

Full log

Message #47 received at 75379 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75379 <at> debbugs.gnu.org
Subject: Re: bug#75379: 30.0.93; project-find-regexp expects "C" or "en" locale
Date: Mon, 6 Jan 2025 16:11:47 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.