what are your thoughts on ripgrep's new support for hyperlinks? #2611
Replies: 11 comments 33 replies
-
I love to see this! From my experience of trying to roll out the use of hyperlinks in a TUI in a big company, there are going to be people running terminal emulators that choke on them in a bad way. From a quick skim of #2610 it seems like you have an env var that will disable both colors and hyperlinks, but I would suggest that you also have an env var that will disable hyperlinks separately from colorization so that the people affected by that have the lowest friction way to bypass hyperlinks while retaining colorization; it will save you from pitchforks and fire-drills to restore their workflow! I'll also share this discussion with some wezterm users that might be willing to try and give feedback. |
Beta Was this translation helpful? Give feedback.
-
Just tested on macOS Sonoma ( There's one thing I'd personally want to change: It opens in the OS default editor rather than This feature is really awesome. |
Beta Was this translation helpful? Give feedback.
-
Below's a wall of random thoughts while trying it out, I hope some of it is going to be useful. Documentation-wise: The example in the first paragraph of the documentation you get from When it comes to built-in formats, I think it could be helpful if what they correspond to was listed somewhere. I'm not saying that the exact value should be part of the no-breaking contract, just that it could be nice to know what it's doing, even if it may change slightly in some way in the future.
Another thing is that I tried to just first go with my gut and try
I don't know if that's something fixable or if it's just how rg behaves for all arguments but I wanted to mention it, at least. Behavior-wise: I will have to play with this in WSL (or Windows) too, maybe tomorrow... Sadly, Windows Terminal has some limitations with what it can do with hyperlinks but maybe I'll figure something out with a custom protocol handler since the Terminal Preview finally allows custom protocols to work too. Hopefully, nothing will break when using a preview version of Terminal 😄 Time to end this with a non-addressable piece of feedback, perhaps it will be helpful to someone else reading my comment - one thing that threw me off, coming from kitty's hyperlinked_grep, is that the default doesn't contain the line number column and so I thought that the documentation saying that hyperlinks are enabled by default is wrong since I couldn't see it by hovering over lines in the search results (this being doubled down by the fact that you actually have to hover over the line number, not the line). I absolutely think that this is the correct choice though since it's not really well-established what the format for specifying the line should be ( |
Beta Was this translation helpful? Give feedback.
-
Testing on Windows Terminal, it seems to work |
Beta Was this translation helpful? Give feedback.
-
On kitty, it works as well, Thank you! It would be super nice if it hyperlinked the entire line rather than just the line number for ease of clicking. Using Using |
Beta Was this translation helpful? Give feedback.
-
Tested with a few terminals on Linux (Mageia 9):
|
Beta Was this translation helpful? Give feedback.
-
It works on MacOS Ventura (13.4), iterm2 Build 3.4.20. Links are underlined by default which make it hard to read but that's an iterm2 problem. I'd like to be able to view the format strings for each target of --hyperlink-format without looking at the source. iterm2 already match some pattern and make them clickable to open files, and with hyperlink in rg, this bypass any configuration of patterns set by iterm. I guess it might break a couple of people with custom hooks in iterm when they upgrade, but it's a matter of reconfiguring and it will most likely be more accurate than iterm2. But you know everybody has their workflow so you can't please everyone. IMHO the paragraph with the default format should be first. Most user will care about setting to one of |
Beta Was this translation helpful? Give feedback.
-
Currently, hyperlinks are not printed when a file is specified from command line (e.g. |
Beta Was this translation helpful? Give feedback.
-
Tested on Windows in Wezterm using powershell and the default settings work well. |
Beta Was this translation helpful? Give feedback.
-
I'm a Linux (Fedora) user with a licensed Sublime Text editor, and I can't get Apparently under Linux ripgrep is using this protocol handler (which is advertised as being for MacOS) and has format I would prefer that when using Thanks to Andrew and Lucas for working on this, this is really a productivity enhancer. |
Beta Was this translation helpful? Give feedback.
-
Actually I've been using hyperlinks with ripgrep for a long time, with a wrapper script and the |
Beta Was this translation helpful? Give feedback.
-
Main ask: Compile ripgrep from master with
cargo build --release
and try out its new support for hyperlinks. Hyperlinks using afile:https://
scheme are enabled by default, but you can do things likerg --hyperlink-format vscode ...
to make ripgrep emit hyperlinks in a format accepted by VS Code.rg --help
has documentation for the format accepted by--hyperlink-format
. Does it work? Are the docs clear? What is sub-optimal? Just, in general, what is your experience? (NOTE: If you're using tmux, its latest release doesn't support hyperlinks. You'll need to build tmux from source and then addset-option -sa terminal-features ",*:hyperlinks"
to your tmux configuration to make it work.)Context: A while back, #665 was filed to request hyperlink support. @ltrzesniewski then put in a huge amount of work to get an initial implementation up in #2483. I did a little bit of polishing work and merged hyperlink support in #2610. From my perspective, there is potential for this feature to be a bit risky since it seems quite dependent on each individual application's support for hyperlinks. This is why, for example, things like
--hyperlink-format vscode
and--hyperlink-format textmate
exist, since different applications have different hyperlink formats. The default on Unix isfile:https://{host}{path}
while the default on Windows isfile:https://{path}
. (It sounds like using{host}
on Windows doesn't work quite well? That is something I'd love folks to try since I'm not a Windows user.)Anyway, because of the integration specifics here, I'm interested in getting some feedback before the ripgrep 14 release. The most important thing is making sure the design is right, since it will be harder to change once it has been released. I would love folks to try it out and see what goes wrong!
UPDATE(2023-10-30): I'm currently planning for
--hyperlink-format=none
to be the default in the ripgrep 14 release. That is, hyperlinks won't be enabled by default. To get "default" support, one will be able to use--hyperlink-format=default
. The reason for this is because it sounds like some environments bungle up hyperlinks (see an experience report in the comments below). I'd rather be a bit more cautious in the first release with hyperlink support, so I'm going to make them opt-in initially. It's plausible that subsequent releases will enable hyperlinks by default.Beta Was this translation helpful? Give feedback.
All reactions