Add support for rendering filenames as hyperlinks

[liff]

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.

[Don42]

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.

[ogham]

I had no idea about this feature, but it looks really useful!

[jcklpe]

+1 to this feature.

[ahsanp]

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.

[ariasuni]

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.

[ahsanp]

That sounds great! Thank you!

[mpldr]

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

[XhstormR]

Maybe can add file:/// prefix, eg: file:///Users/user/Downloads/123.txt

[XhstormR]

This feature is really helpful.

[valpackett]

Looks like there is an ansi_term PR: ogham/rust-ansi-term#61

But ansi_term doesn't seem very actively maintained… maybe it would be a good idea to migrate to termwiz ;)

[ariasuni]

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.

[aaccioly]

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.

[mpldr]

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.

[jasonjckn]

+1 feature request

[akharrou]

+1

[Dapacruz]

+1

[ttys3]

lsd already has it.

lsd-rs/lsd#642

[Dapacruz]

lsd already has it.

Peltoche/lsd#642

For this reason I use lsd, but I like how exa ignores files listed in .gitignore.

[daviessm]

This would be a good first issue for someone new to the project, based on the implementation in lsd.

[Jackenmen]

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

[mpldr]

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](https://www.rfc-editor.org/rfc/rfc8089#page-18).

[Jackenmen]

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).

[mpldr]

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_CONNECTION` has 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

[ariasuni]

exa is unmaintained (see #1243), and this has been done in the active fork eza, so I’m closing this.