On Sun, Aug 10, 2025 at 02:20:13PM +0100, Phillip Wood wrote: > On 10/08/2025 11:09, Phillip Wood wrote: > > On 09/08/2025 15:44, D. Ben Knoble wrote: > > > On Fri, Aug 8, 2025 at 1:43 PM Greg Hurrell via GitGitGadget > > > <gitgitgadget@xxxxxxxxx> wrote: > > > > From: Greg Hurrell <greg.hurrell@xxxxxxxxxxxxx> > > > > > > > > This commit takes the simple approach of unconditionally stripping any > > > > trailing tab. Consider the following three examples: > > > > > > > > 1. For file "foo bar", Git will emit "foo bar\t". > > > > 2. For file "foo\t", Git will emit "foo\t". > > > > 3. For file "foo bar\t", Git will emit "foo bar\t\t". > > When I wrote earlier I forgot that git quotes filenames with control > characters. If a name contains a tab it it quoted and so cases 2 and 3 will > be quoted and so there is no ambiguity when trimming a literal tab character > from the end. I haven't checked but I suspect git-jump does not handle > quoted filenames, if we wanted to add support it should be pretty easy as > Git.pm has a function to do the unquoting for us. Yeah, git-jump does not do any unquoting at all. Ironically I used the "+++" line because I wanted to avoid quoting and whitespace headaches on the "diff --git" line. But I guess it is unavoidable for truly weird path names. ;) I'd prefer to avoid an extra dependency on Git.pm and just leave it broken for quoted names. Since names with spaces are the likely thing to see, and those aren't quoted, I think running into this should be pretty rare (another alternative is to lazy-load Git.pm only when necessary, since we're already in a perl script). I wondered if it might almost work without any intelligence on the part of git-jump, just because vim's quickfix parser already does a bunch of heuristic regex matches, some of which understand quotes. But it looks like the answer is no. This one from the default set: "%f"%*\D%l: %m is quite close, and would match: echo content >'foo bar' vim -q <(printf '"foo bar":1: some error') but it won't automatically undo backslash escapes inside the quoted portion. So in something that actually needed quoting would end up looking for a file with the literal sequence "\t" in it, rather than a tab. Oh well. -Peff
