I also tested this feature and noticed that the current implementation does not preserve params in hyperlinks. In particular, the id parameter is important so that terminals can highlight all hyperlinks with the same id. You can try this in Bash and see how your terminal highlights them together:

printf '\e]8;id=1;http://example.com\e\\The first part of the link\e]8;;\e\\\n'
printf '\e]8;id=1;http://example.com\e\\and the second part of the link.\e]8;;\e\\\n'

There's also a quirk in the feature that highlights words when the mouse is over a word, and spaces when the mouse is over them. It gives the impression that there are two hyperlinks instead of one:

printf '\e]8;;http://example.com\e\\This  is  a  link\e]8;;\e\\\n'

This can be replicated with Alacritty, Contour and Xfce terminals, but not with Kitty and Wezterm.

Despite these issues, this looks very promising!

Hey @veltza!

Thank you so much for testing this out and leaving some feedback!

For testing, I mostly use this example file. I noticed that even outside lf, behaviour varies greatly between iTerm, kitty and ghostty (using cat hyperlink-demo.txt).

I found it rather difficult to differentiate between mismatches caused by incorrect parsing on my side and different implementations on a terminal level. However, I will look deeper into this.

Edit: I noticed you were also involved in testing the new preloading feature. Thanks once again for taking your time to test new features and patches, it really helps a lot! ❤️

For testing, I mostly use this example file. I noticed that even outside lf, behaviour varies greatly between iTerm, kitty and ghostty (using cat hyperlink-demo.txt).

I also used that test file when I implemented OSC-8 support in my st fork. The file includes so many edge cases that I didn’t bother handling all of them either. So I recommend that you don't spend too much time on them either, because applications use fairly simple hyperlinks anyway.

I also tested this feature and noticed that the current implementation does not preserve params in hyperlinks. In particular, the id parameter is important so that terminals can highlight all hyperlinks with the same id. You can try this in Bash and see how your terminal highlights them together:

printf '\e]8;id=1;http://example.com\e\\The first part of the link\e]8;;\e\\\n'
printf '\e]8;id=1;http://example.com\e\\and the second part of the link.\e]8;;\e\\\n'

This is fixed now!

There's also a quirk in the feature that highlights words when the mouse is over a word, and spaces when the mouse is over them. It gives the impression that there are two hyperlinks instead of one:

printf '\e]8;;http://example.com\e\\This  is  a  link\e]8;;\e\\\n'

This can be replicated with Alacritty, Contour and Xfce terminals, but not with Kitty and Wezterm.

Not sure why this happens, cross-terminal stuff is a real pain (as everyone here seems to be aware of).

OK, this is related to the id as well (or lack thereof). The docs encourage some tools to generate an id if none has been given.

Edit: This has been fixed now as well.

Please take one last look, @joelim-work.
Thank you very much for taking your time.
I am actually quite pleased with how this code has turned out.

@CatsDeservePets Hold on, I’ve found a bug. I’ll report it shortly.

I also analyzed the strange behavior of hyperlinks using my st fork and found that lf generates two hyperlinks from a single hyperlink and draws them on top of each other.

For example, if I print a hyperlink like this:

printf '\e]8;;http://example.com\e\\This is link\e]8;;\e\\\n'

lf generates two hyperlinks:

1. First, it prints the hyperlink as it should:

printf '\e[3;53H\e]8;;http://example.com\e\\This is link\e[3;105H\e[0m\e]8;;\e\\\n'

2. But then for some reason it prints another hyperlink on top of it and only renders the word because it skips spaces with escape sequences:

printf '\e[3;53H\e]8;;http://example.com\e\\This\e[3;58His\e[3;61Hlink\e[3;105H\e[0m\e]8;;\e\\\n'

This second hyperlink is what's causing the strange behavior. So if we could get rid of it, we wouldn't need to create any fallback ids in the first place.

Oh, interesting.

Oh, interesting.

Indeed. It would be interesting to know what causes it and why. My concern is that, without knowing its purpose, it might cause additional side effects.

Edit: I found out that the behavior comes from tcell and can be reproduced with the hyperlink.go demo. I also found out that it was gdamore/tcell@d17cf8b that broke the behavior of hyperlinks. But since I am not familiar with tcell, I don't understand why it causes this regression. So I guess no one uses hyperlinks because no one has noticed this yet.

Oh, interesting.

Indeed. It would be interesting to know what causes it and why. My concern is that, without knowing its purpose, it might cause additional side effects.

Edit: I found out that the behavior comes from tcell and can be reproduced with the hyperlink.go demo. I also found out that it was gdamore/tcell@d17cf8b that broke the behavior of hyperlinks. But since I am not familiar with tcell, I don't understand why it causes this regression. So I guess no one uses hyperlinks because no one has noticed this yet.

And once again thank you for your research. So this is outside the scope of this PR. I will update the custom id generation and will mark this as ready for review, as I don't think this will causes any trouble.

It seems to me that there might be a problem with tcell incorrectly diffing the screen state to determine which parts to update.

Regarding the id parameter, I am just wondering but is there a need to autogenerate one if it is not provided? The aim here is to simply convert existing OSC8 sequences to Tcell style objects, and that external applications that generate these sequences should be responsible for filling in the ID if it is needed.

Regarding the id parameter, I am just wondering but is there a need to autogenerate one if it is not provided? The aim here is to simply convert existing OSC8 sequences to Tcell style objects, and that external applications that generate these sequences should be responsible for filling in the ID if it is needed.

Without the id, it's up to the terminal emulator to decide which links belong together (some are smarter than others). I do agree, ideally the ID is provided by the external application, but that isn't always the case (I'd imagine users writing some configuration to output clickable links don't add it either).
There is an entire section about this in the gist.

Quoting from there:

Complex apps that manage the full screen and wish to explicitly linkify URIs, such as viewers or editors, should assign explicit ids that identify that particular link, so that it keeps being underlined together even across a linebreak, across another pane or window of the app's UI, and even across crazily optimized screen updates (e.g. when it repaints only a part of an anchor text). Such an id might perhaps be the file offset, or the (row, column) tuple where the hyperlink starts. Apps that support multiple windows, such as the imaginary text editor with that screenshot above, should add the ID of the window to the link's id too so that it does not conflict with the same target URI appearing in another window.

Complex apps that display data that might itself contain OSC 8 hyperlinks (such as terminal multiplexers, less -R) should do the following: If the encountered OSC 8 hyperlink already has an id, they should prefix it with some static string, or if multiple windows/panes are supported by the app, a prefix that's unique to that window/pane to prevent conflict with other windows/panes. If the encountered OSC 8 hyperlink does not have an id, they should automatically create one so that they can still have multiple windows/panes and can still crazily partially update the screen and keep it as a semantically single hyperlink towards the host emulator (remember the difference in VTE and iTerm2 when no id is set which becomes relevant here, so it should be avoided). This id should be taken from a namespace that cannot conflict with a mangled explicit id. It's probably much easier to implement VTE's approach here: assign a new id (maybe a sequential integer) whenever an OSC 8 with an URI but no id is encountered. This way there's absolutely no need to maintain any internal pool of the active hyperlink ids or anything like that, it's just a trivial mapping each time an OSC 8 is encountered in the data that needs to be displayed.

Regarding the id parameter, I am just wondering but is there a need to autogenerate one if it is not provided?

@joelim-work The reason has already been explained in this thread. So feel free to fix tcell so we don't have to use this workaround.

I think at this point, this PR can be merged.

Sorry, I was busy the last few days so I didn't have a chance to respond.

Regarding the double hyperlink issue in Tcell, I can reproduce it with the hyperlink.go demo too. I think what is happening is that the space character is a magic value used in Tcell to indicate an 'empty' cell. This means that clearing the screen and then printing foo bar will result in only cells containing visible characters being marked as dirty and then sent as updates to the terminal, creating the second hyperlink with only foo and bar.

But this is just speculation on my part, it's probably worth raising an issue in Tcell since it would be nice to not have this kind of workaround. The code is fine for now though, thanks for working on the feature.