tags 27873 + patch
quit

Eric Hanchrow <eric.hanchrow@gmail.com> writes:

> This displayed a *grep* buffer that looked something like I expected,
> but:
>
> * instead of there being exactly one line with some underlining
> (indicating a "hit"), there were a bunch: the one I expected, as well
> as a few before it like this:
>
> grep: git-repositories: Is a directory
> grep: guix: Is a directory
> grep: homedir: Is a directory
> grep: homework: Is a directory
> grep: iTunesDSM: Is a directory
> grep: jessie64: Is a directory
> grep: local: Is a directory
> grep: log: Is a directory
> grep: mygo: Is a directory
> grep: node_modules: Is a directory
> grep: perl5: Is a directory
> phonetic-alphabet.txt1:Stolen from http://www.fourmilab.ch/documents/phoneticalphabet/
> grep: pprof: Is a directory
>
> You can't tell from what I've pasted above, but the 9 "Is a directory"
> lines before the actual hit were red and underlined, just like the
> match was.
>
> * Hitting C-x `, instead of visiting the file with the hit, put a
> nine-line-high prompt in the minibuffer, as if it was asking me which
> directory to find the file in a directory with a really weird name.
> (You can see some evedince of this in the "Recent messages" stuff below).

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27840 is a similar report from a few days ago.

It's not a duplicate though, this bug is because I thought using --null
would make it possible to get filenames containing newlines
unambiguously, but I was wrong.  Here's a patch, also covers a couple of
minor issues that came up later in Bug#6843.