Add hyperlink style support about yansi HOT 6 CLOSED

I'm generally in favor, but there's a backwards compatibility issue. From the gist:

Any terminal that correctly implements OSC parsing according to ECMA-48 is guaranteed not to suffer from compatibility issues. That is, even if explicit hyperlinks aren't supported, the target URI is silently ignored and the supposed-to-be-visible text is displayed, without artifacts.

Here's the problem: imagine a builder method that lets you set a link on a Paint:

println!("Visit our {}", Paint::new("docs").link("https://api.rocket.rs"));

On terminals that support links, they'll see:

Visit our docs.

But terminals that don't support links will see:

Visit our docs.

That is, the link is completely lost.

You want to display the actual link and likely different text if the hyperlink won't be rendered:

Visit our docs at https://api.rocket.rs.

What's the API for this? The following seems unfortunate:

println!("Visit our {}", Paint::new("docs").link_or("https://api.rocket.rs", "docs at https://api.rocket.rs"));

Maybe we can default to showing the link in parenthesis when .link() is used without .link_or():

Visit our docs (https://api.rocket.rs).

There is also this:

At this moment, terminals known to be buggy (OSC 8 resulting in display corruption) are VTE versions up to 0.46.2 and 0.48.1, Windows Terminal up to 0.9, Emacs's built-in terminal, and screen with 700+ character long URLs.

So, to be safe, we'd need to conservatively detect whether the terminal supports hyperlinks. This project seems to do it, but it's not clear to me how correct or reliable it is. We should have no false positives; false negatives are okay.

We should have a Paint::supports_hyperlinks() and Paint:enable_hyperlinks(bool), or some version of these APIs, to force detect/force-enable/force-disable hyperlink support.

from yansi.

yansi today seems to be just mechanism of painting, leaving the policy of what's supported to elsewhere (see #18). As long as we provide a way for users to disable coloring, I see it as the user's decision for how accurate the detection needs to be.

from yansi.

If we support something conditionally, we should support detecting it. It doesn't make sense to say "Hey, you can enable or disable hyperlink support, but you gotta figure out if the thing you're talking to actually supports it!" This is totally error prone and really unfriendly.

Edit: come to think of it, I suppose yansi already doesn't do this. We certainly already leave it to users to figure out if coloring is supported in their output. I suppose the reason I see such a difference between "can I use colors?" and "can I use hyperlinks?" is that the former has pretty reasonable answers in "is it a TTY? then yes!". And when this isn't sufficient, yansi does answer the question, i.e, for Windows consoles.

from yansi.

Alright, I think if we disable displaying hyperlinks by default and have a toggle for enabling them, my concerns are resolved. This is the inverse of what we do for coloring, which makes sense given the differences I've alluded to above.

from yansi.

I suppose the reason I see such a difference between "can I use colors?" and "can I use hyperlinks?" is that the former has pretty reasonable answers in "is it a TTY? then yes!".

That isn't true for true color but yansi supports that.

from yansi.

The v2 branch now has experimental hyperlinking support.

from yansi.