Use repgrep to open an editor at a match location

[galpressman]

It would be great if it was possible to jump to the selected file and line (open in editor for example) instead of just find and replace.

[acheronfail]

To clarify, is your request to be able to open the selected file in an editor?

Say for example, hovering over a match in foo.txt at line 42 - press a button - and then the program will launch the user's $EDITOR with the file and line?

[galpressman]

Exactly!
Using this tool for code navigation in addition to find and replace would be super helpful.

[acheronfail]

@galpressman now that I think about it, if your goal is to use ripgrep to find places in files you want to jump to and edit, would using something like https://github.com/jremmen/vim-ripgrep in vim solve your use-case? There are plenty of tools which integrate ripgrep in command line editors, etc.

I suppose rgr could also do the same, but I'm just thinking that your use-case could be better solved by using vim and a ripgrep plugin there...

[galpressman]

Thanks, I tried it and it's less convenient than the repgrep UI.
Anyway, feel free to close the issue if you think this feature shouldn't be implemented.

[acheronfail]

I think this could be implemented without too much difficulty, but we'd need to consider how to implement it in a scalable way (for multiple editors). For example, with vim you can use vim '+call cursor(10, 5)' ./my-file to open a file on line 10 and column 5. But this obviously is vim specific, and wouldn't work for other editors.

Happy to implement this, but we should give it some thought to make sure that we can build it in an easy to maintain way.

Perhaps a configuration option? I'll have to give this some more thought.

[acheronfail]

I've thought about this a little more, and I think implementing it is going to be more difficult than anticipated; some of the reasons I think so are:

Invalidating match results when making changes in an external editor

1. User runs rgr <search-term>
2. rgr opens with a list of matches
3. User uses this feature to open preferred editor at a matched line+column
4. User makes a change to the match in the editor, saves it and exits
5. User returns to rgr, but now - the match may not exist anymore, since the results are definitely stale

This could be worked around, if after we detect the editor has been closed, to re-run the rg command against the file that was just edited, and update the interface accordingly.

Handling multiple editors

The best thing I can think of right now, is adding a configuration file for rgr, and then adding an editor_cmd string.
That way, a user could create (as an example) a config file with editor_cmd = "helix {{path}}:{{line}}:{{col}}", and configure it to work with their desired editor.

Have a look at how kitty does this for example: https://sw.kovidgoyal.net/kitty/kittens/hyperlinked_grep/

Potential issues with unicode

I'm not 100% sure if all commonly used editors handle line and column numbers the same. Due to how rgr works, it may have to use different definitions of column (a character, a code point, a graphene cluster, etc).

Again, I'm not certain about this, but it could be an obstacle.