GNU bug report logs - #27873
26.0.50; M-x grep broken

Previous Next

Full log

View this message in rfc822 format

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: 27873 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#27873: 26.0.50; M-x grep broken
Date: Sun, 30 Jul 2017 18:48:26 +0000

[Message part 1 (text/plain, inline)]

"git apply" refused to apply the patch, but I applied it by hand, and it
seems to work fine.  Thanks.

On Sun, Jul 30, 2017 at 8:30 AM <npostavs <at> users.sourceforge.net> wrote:

> tags 27873 + patch
> quit
>
> Eric Hanchrow <eric.hanchrow <at> 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.
>
>

[Message part 2 (text/html, inline)]

Previous Next

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