exa
exa copied to clipboard
ogham
Add support for rendering filenames as hyperlinks
Some terminal emulators support escape sequences that can be used to mark text as a hyperlink.
Could a similar option perhaps be added to exa? Coreutils ls supports this since 8.28.
Sounds interesting, I expect this depends on #211 being implemented.
Edit: No longer sure if there really is a dependency. I forgot how complex character escapes can be.
Hi! Given that ansi_term doesn't yet support hyperlink painting, would it be okay to make a pull request that supports this painting without using ansi_term? More specifically, one would add in the hyperlink escape codes in the render functions. That way we can avoid messing up text cell width in the output.
Well, I guess you could just make a PR for ansi_term (which is also maintained by ogham) directly, though it sounds a little bit more complicated.
No longer sure if there really is a dependency. I forgot how complex character escapes can be.
Pretty easy actually… since it's just a URI, you can use normal URI-encoding (space -> %20 and so on). Maybe this helps (it's in Go though) https://git.sr.ht/~poldi1405/go-ansi/tree/master/item/hyperlinks.go#L20
Looks like there is an ansi_term PR: https://github.com/ogham/rust-ansi-term/pull/61
But ansi_term doesn't seem very actively maintained… maybe it would be a good idea to migrate to termwiz ;)
Well, I didn’t look at termwiz, but it could be interesting to try to use it instead of rust-ansi-term and see if it’s still as performant/doesn’t grow the binary too much/etc.
Kitty has a great implementation of Hyperlink actions. To the point that I now naturally expect to be able to click on files, URLs, etc and expect my terminal emulator to launch something useful. It would be lovely if exa would implement this feature.
Just in case this is eventually implemented, I'd like to add to
XhstormR's comment that URLs require a hostname part, so
file://your-hostname/Users/user/… would be the actually valid URL.
Usually this is implicitly handled, but maybe some terminal emulator
actually requires it.
lsd already has it.
For this reason I use lsd, but I like how exa ignores files listed in .gitignore.
This would be a good first issue for someone new to the project, based on the implementation in lsd.
Note that lsd's implementation does not put the hostname in the URL which the spec referred to in the issue description considers mandatory:
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#file-uris-and-the-hostname
In practice, this allows capable terminal emulators to handle non-local file URLs properly, e.g. download the file to a temporary local file through SSH before trying to open it which is what, for example, kitty or iTerm 2 can do:
- https://sw.kovidgoyal.net/kitty/kittens/remote_file/
- https://iterm2.com/documentation-shell-integration.html#:~:text=track%20their%20progress.-,Upload%20with%20scp,-If%20you%20drop
On Fri Oct 14, 2022 at 5:29 PM CEST, Jakub Kuczys wrote:
Note that
lsd's implementation does not put the hostname in the URL which the spec referred to in the issue description considers mandatory: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#file-uris-and-the-hostname
Just a minor correction. The RFC implies heavily that the authority can remain empty for local files.
The specification I linked (which is the specification for hyperlinks in terminal emulators) mentions RFC 8089 and explicitly chooses to be stricter here and requires always specifying the hostname.
Besides, the tool can't reliably know whether it's running in a "local" context or whether it's running in the ssh context. For the tool running on some computer, all files are considered local but that doesn't mean that the terminal emulator itself runs on that same computer (as is the case for SSH).
On Fri Oct 14, 2022 at 8:57 PM CEST, Jakub Kuczys wrote:
The specification I linked (which is the specification for hyperlinks in terminal emulators) mentions RFC 8089 and explicitly chooses to be stricter here and requires always specifying the hostname. That is correct, I would just wonder whether this might confuse browsers.
Besides, the tool can't reliably know whether it's running in a "local" context or whether it's running in the ssh context. This might be related to the default settings – which may vary by distribution – but for all systems I've tried (5 so far) a variable called
SSH_CONNECTIONhas been set and is populated with the IP of the server, which can be used as the authority.
For the tool running on some computer, all files are considered local but that doesn't mean that the terminal emulator itself runs on that same computer. Agreed, I also don't question that adding the hostname is a good idea, I just think it warrants some consideration to break the informal OSC-8 standard in favour of more closely follow RFC 8089 and avoid potential issues. At least in my home network my hostname does not resolve if not connectde to my VPN and this might be an issue for some programs handling file:// links.
Since I don't make extensive use of my mouse when working with a terminal, I don't wish to cause trouble to the implementor and rely on their better judgement, I just wish to offer my perspective for potential consideration. :)
-- Moritz Poldrack https://moritz.sh
exa is unmaintained (see https://github.com/ogham/exa/issues/1243), and this has been done in the active fork eza, so I’m closing this.