Output format with parseable match indices?

[birkenfeld]

For integration in other tools (editors...) it would be great to have a parseable output format that includes the start and end index for each match in a line. You can do it with colors (but see #242) but it's not really what colors are meant for.

ag has --ackmate, which outputs something like this:

$ ag --ackmate host
:src/util.rs
85;43 4,55 4:                                       ext_host: "localhost".into(),

[BurntSushi]

Is ackmate a sufficiently popular format that we should just provide that and call it done? Is it convenient to use? Is there a specification for it?

[BurntSushi]

Note that --vimgrep exists, but I think it's missing the end position of a match (it give you line number and starting column number).

[birkenfeld]

Is ackmate a sufficiently popular format that we should just provide that and call it done? Is it convenient to use? Is there a specification for it?

It seems to be what ack clones have. Convenience is probably not that important here - although I like that it avoids text volume because file names are not repeated. There is no specification that I know of.

[BurntSushi]

The format for --ackmate appears to be:

:{file-path}
{line};{column} {length}:{match}

Note that the --vimgrep --heading format is:

{file-path}
{line}:{column}:{match}

They are pretty close, including the reduction in volume by avoiding repeated file paths. Alas, --vimgrep is missing the length of the match. I don't think changing --vimgrep is an option, and supporting --ackmate seems nice if only because it's probably a format that people have written ad hoc parsers for.

[BurntSushi]

One thing that grates me a little bit is that I managed to implement the --vimgrep option in the Printer without actually mentioning or relying on the concept "vimgrep." (Instead, it's a combination of line_per_match, column and line_number.) With --ackmate, its format is so weird that I'd probably need to add an option just for it. Blech.

[BurntSushi]

@birkenfeld Could you say more about why you specifically need this? I've never done an editor integration, so I don't really know. However, I do know that lots of folks have already integrated ripgrep into emacs and vim, and this is the first I'm hearing that --vimgrep is insufficient.

[BurntSushi]

The "orthogonal" way to do this I guess is to add a --length option that includes the length of the match (in bytes). And if we're going to make --column imply --line-number, then --length probably needs to in turn imply --column. That way, you could use rg --length --heading foo to get:

{file-path}
{line}:{column}:{length}:{match}

I think I'd prefer this over hacking --ackmate into the printer. (Which I have plans of factoring out into a library.)

[birkenfeld]

The goal is highlighting matched parts of a line in an editor-specific way (e.g. faces in Emacs). The ripgrep Emacs package once had this feature, but relied on parsing color escapes, which changed in 0.3.

A vimgrep-like format including match length is possible, but harder to handle because usually you'd want to display a matching line only once, but highlight multiple matches if appropriate. With an ackmate-like format, which specifies all matches in a single line (see initial post), that requires much less postprocessing of the output.

cc @nlamirault (the ripgrep.el author)

[BurntSushi]

but relied on parsing color escapes

Wow. I didn't even consider that as a breaking change. And probably still don't. Relying on color escapes sounds like really bad juju! But I understand why someone might do it if there's no other way!

A vimgrep-like format including match length is possible, but harder to handle because usually you'd want to display a matching line only once, but highlight multiple matches if appropriate.

OK, this is a key thing I was missing. I guess in vim, the opposite is true. This also means that my description of the ackmate format above was wrong. It looks like this instead:

:{file-path}
({line};{column} {length}, ...):{match}

Blech. I guess I begrudgingly accept that we should do this. I will attempt to put this into the current printer, but it's not going to be nice, and hopefully I can rethink it for libripgrep. The key problem with adding stuff to the printer is that you need to consider its interaction with every other output flag. For example, does --no-heading/--heading have an effect with --ackmate? (Yes?) What about --no-filename? (Yes?) Some others: --vimgrep, --null, --context/--before-context/--after-context.