counsel-git-grep: Breaks when filenames contain colons #153

Closed
hpdeifel opened this Issue Jun 18, 2015 · 9 comments

Projects

None yet

2 participants

@hpdeifel

The first colon seems to be taken as the separating character, but file names can contain colons. A current real life example for me were email files in an mbox.

M-x grep seems to handle the case correctory

@abo-abo
Owner
abo-abo commented Jun 19, 2015

I don't understand what you mean here. I created a test repo, committed a file with a colon in it (weird, but fine). I'm not getting any bug when the input contains colons.

@hpdeifel

In a git repo with the file foo:bar, counsel-git-grep opens the file foo, when hitting RET on a matching line.

@abo-abo
Owner
abo-abo commented Jun 19, 2015

I see it now, thanks. But how do you propose I fix this? git grep can't customize the separator.
I can put a regex there that tries to match a line number, but still it will be buggy if you manage to name a file to include a semicolon and a number.

@hpdeifel

It seems to have a --null option, just like grep. I don't know if that is usable from elisp, but it's the usual way to treat these ambiguities .

@abo-abo
Owner
abo-abo commented Jun 19, 2015

--null doesn't solve it:

[~/Downloads/test]$ git --no-pager grep --full-name -n --no-color -i -e "oo"
as:df:1:test:foo:bar
as:df:2:helloooo
[~/Downloads/test]$ git --no-pager grep --full-name -n --no-color -i -e "oo" --null
as:df1test:foo:bar
as:df2helloooo

But matching for a regex should work 99% of the time. I'll push the change shortly.

@abo-abo abo-abo added a commit that closed this issue Jun 19, 2015
@abo-abo Add better positioning to counsel-git-grep finalizer
counsel.el (counsel-git-grep-action): Use a regex instead of just
splitting the string on ":". Additionally, goto match, not just the line
of the match.

Fixes #153
5fcdfb4
@abo-abo abo-abo closed this in 5fcdfb4 Jun 19, 2015
@hpdeifel

I think --null does solve it:

% git --no-pager grep --full-name -n --no-color -i -e "test" --null | xxd
00000000: 666f 6f3a 6261 7200 3100 7468 6973 2069  foo:bar.1.this i
00000010: 7320 6120 7465 7374 0a                   s a test.

as you can see, there is a 0x00 byte after the file name, which cannot appear as part of it.

I don't know how M-x grep does it, but it works in this case.

@abo-abo
Owner
abo-abo commented Jun 19, 2015

0x00 byte after the file name

This doesn't work well: I have to use split-string on the output of start-process eventually. And it bugs out because of the null byte. Just try the current code. I'm sure it's sufficient.

@hpdeifel

Yep, the new code works very well. Thank you!

It still itches me that it's theoretically possible to be buggy (now with filenames that contain colons and numbers). I just tried

ELISP> (split-string (shell-command-to-string  "git --no-pager grep --full-name -n --no-color --null -i -e \"test\"") "\0")
("foo:bar" "1" "this is a test\n")

which seems to work very well.

But please don't bother. It's fine the way it's implemented, if I really need to scratch my itch, I'll create a pull request.

@abo-abo
Owner
abo-abo commented Jun 19, 2015

which seems to work very well.

That isn't the problem. The problem I think is split-string ... "\n": the \0 chars interfere there.

But please don't bother. It's fine the way it's implemented, if I really need to scratch my itch, I'll create a pull request.

Fine, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment