Comments (6)
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.
Related Issues (20)
- Automatic disabling when stdout/stderr is not a terminal. HOT 1
- Docify crate HOT 3
- Bright colors? HOT 6
- Implement standard traits for Style HOT 3
- Update docs to call out `Default` constructor for Style HOT 2
- API to constrain a `Style` from truecolor to basic colors HOT 3
- const-fn the API HOT 2
- Global enable/disable encourages the wrong behavior HOT 4
- Encourage colored-output common practices HOT 3
- Gracefully initialize/auto-detect behind the scenes? HOT 3
- Add a feature flag to automate Windows coloring HOT 6
- Version 1.0? HOT 2
- Used parking_lot version is quite old HOT 5
- Cannot build/compile from source HOT 1
- Impl `{Upper,Lower}Hex` for `Paint` HOT 1
- The method `clear` in trait `Paint` causes a conflict with `Vec::clear` HOT 4
- FR: Implement `AsRef<str>` for `Painted<&str>`
- Allow conditions to accept closures HOT 2
- The method `Paint::clear` breaks the project when using `String.clear` HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yansi.