bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48321: 27.2; Text copied from *grep* buffer has NUL (0x00) character


From: R. Diez
Subject: bug#48321: 27.2; Text copied from *grep* buffer has NUL (0x00) characters
Date: Sun, 9 May 2021 21:14:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

Emacs' default "Grep Command" is "grep --color -nH --null -e ", which
includes option "--null". This means that grep is embedding an ASCII NUL
character (a binary 0x00) after the filenames.

This is what an rgrep text search occurrence looks like in the *grep* buffer:

./some/file.txt:123:some text line

The first ':' is actually a binary null, but the *grep* buffer hides this fact.

If you copy that text line to an Emacs text file buffer, it then looks like
this:

./some/file.txt^@123:some text line

The ^@ is the representation for the binary null, but that is easy to
miss in long text lines.

A text file with an embedded NUL character causes problems
everywhere. There are errors or warnings with Meld, Pluma, Geany,
Mousepad, and probably many more.

In my opinion, copying text from a *grep* buffer that looks like ":"
should not suddenly deliver a NUL character instead. That's just
unexpected and prone to problems down the line.

Stefan Monnier suggested the following:

----8<----8<----8<----
This "what you see in NOT what you get" is indeed undesirable.  I'm not
sure it's easy to fix in a reliable way in Emacs (beside not using
`--null` as Eli points out), but I suggest you `M-x report-emacs-bug`.
Maybe grep-mode can add a `filter-buffer-substring-function` that
converts those NUL into `:`.
----8<----8<----8<----

For more information, see the discussion starting with this mailing list
message:

Text copied from *grep* buffer has NUL (0x00) characters
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-05/msg00360.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]