Turn HTML output into links

[epage]

Problem

In most terminals, if a URL is printed it is turned into a link you can click on for easy opening. This is less true for file paths.

This is less of a problem for cargo doc --open as cargo will open the page up for you.

Places where we are falling short include

• cargo doc --target foo --target bar (--open doesn't work)
• Wanting to a cargo doc invocation that you can run multiple times, using shell history, without editing in/out --open
• cargo doc calls wrapped in other tools, like make
• cargo build --timings (it'd be awkward to add a --open just for --timings)

Proposed Solution

Turn the file paths into links using ANSI escape codes

Notes

From #12859 (review)

This looks great. Have you consider integrating something like hyperlinks in terminal emulators?

ripgrep just got a similar feature, though not by using OSC escape sequence:

• https://github.com/BurntSushi/ripgrep/blob/7099e174acbcbd940f57e4ab4913fee4040c826e/crates/printer/src/hyperlink_aliases.rs#L4-L22

• what are your thoughts on ripgrep's new support for hyperlinks? BurntSushi/ripgrep#2611

[epage]

Things we'd need to work through:

In theory, terminals that support ANSI escape codes should either support or gracefully degrade in the presence of hyperlinks and so we could do this based on term.color. However, not all do.
We could leverage supports-hyperlinks. We could maybe even add a term.hyperlinks that is "always", "auto", and "never" that gets ANDed with term.color.

anstream strips ANSI escape codes in an all-or-nothing way, so if we want control besides term.color, we'd need to track that state ourselves. At the most basic level, this could be Shell::supports_hyperlinks. A more advanced version would be

impl Shell {
    fn hyperlink(&self, link: &str) -> Hyperlink {...}
}

struct Hyperlink { ... }

impl Hyperlink {
    fn open(&self) -> impl Display;
    fn close(&self) -> impl Display;
}

format!("Some text with a {}{}{}", link.open(), path.display(), link.close());

Another tricky aspect, from the ripgrep discussion, is that you shouldn't leave the hostname as default for hyperlinks due to SSH ... except on Windows due to bugs.

[epage]

Also, iiuc ripgrep went above and beyond and supports hyperlink patterns for opening files in editors to a specific file/line which requires knowing what editor is being used. This is done with a specific flag.

That means just for our use cases, we can skip that. If we want to extend this to cargo and rustc diagnostic messages, then we'd need to reconsider this.

[epage]

@Muscraft this could have interesting ramifications for diagnostics. At the most basic level, we could make links out of references to the manifest (like package.version linking to the documentation for that field). If we apply ripgrep's concept of "editor links" than we could make the file paths + line + column information openable for editing.

EDIT: Also, if we rewrote rustc's messages, then we could link to docs.rs for crates.io dependencies in error messages related to their API