Should I parse the json output now if I want to use ripgrep in rust?

[BurntSushi]

Should I parse the json output now if I want to use ripgrep in rust? My main goal is customizing the output format so I can parse the cleaned result easily with fzf's --with-nth.

Originally posted by @NightMachinary in #1009 (comment)

[BurntSushi]

libripgrep is only about exposing the guts of what makes search work. There are no plans to expose the full CLI functionality of ripgrep as it exists today as a library. Most of ripgrep core is really just about parsing CLI flags and configuring the various grep dependencies to execute the search.

If you want to build your own kind of tool that is as fast as ripgrep but has a different interface/objective/whatever, then libripgrep is what you want.

If you just want to use ripgrep and all of its CLI functionality, then you should just call the rg process. If you want to change the output format, then you might be able to get away with massaging the default output format, but I don't know enough details about what you're trying to do. Otherwise, yes, the --json output format is going to be the most flexible and will let you do whatever you want. This is what VS Code uses.

[NightMachinery]

@BurntSushi My needs are actually pretty simple; I want consistency between matched lines and their context and the group separators: (the group separators are already configurable, I believe, so they are not an issue.)

rgbase () {
    command rg --smart-case --colors "match:none" --colors "match:fg:255,120,0" --colors "match:bg:255,255,255" --colors "match:style:nobold" --engine auto -C ${agC:-1} --color always --hidden "$@"
}
❯ rgbase --column --no-heading defv
dev/emacs/doom.md-2-For future reference, C-u is being overridden by evil due to these two settings in the evil module :
dev/emacs/doom.md:3:3:( defvar evil-want-C-u-scroll t )  ; moved the universal arg to  u
dev/emacs/doom.md:4:3:( defvar evil-want-C-u-delete t )
dev/emacs/doom.md-5-And can be reversed by adding these lines to ~/.doom.d/config.el :

As you see, the context lines are PATH-LINE_NUMBER-LINE while matched lines are PATH:LINE_NUMBER:COLUMN:LINE. This inconsistency makes it impossible to use these metadata with fzf --delimiter=':' --with-nth. I ideally want them like this:

Matches: PATH:LINE_NUMBER:COLUMN:LINE
Context: PATH:LINE_NUMBER:-1:LINE
Group seperators: PATH:-1:-1:PATH

[BurntSushi]

This is the same output format used by grep, so it might be worthwhile getting fzf to support multiple delimiters. But yeah, ripgrep exposes no way to change the - or : characters, so I guess you'd need to use --json for this.

[NightMachinery]

@BurntSushi fzf does support multiple delimiters; The problem is that the number of fields is shifting between match lines and context lines. Also, I just remembered, - is a very common character in lisp code files (and I personally use it a lot.), and that also breaks the whole scheme. I think adding an option --null-all that turns all delimiters used by rg to \x00 is a good solution. If this - gets fixed, I can forgo the column metadata and things will work out ok.

[BurntSushi]

Ah I see. Yeah, I'd rather not add more options for this. I think doing what you want with the JSON output should be easy enough in one specific case.