Consider accepting iTerm’s link format

[ticky]

iTerm’s hyperlink format differs from that supported by us, which makes interoperability a bit weird.

iTerm 2’s links look like this:

printf '\033]8;;https://buildkite.com\aBuildkite\033]8;;\a'

Our links look like this:

printf '\033]1339;url=https://buildkite.com;content=Buildkite\a’

Valid links in Buildkite’s style don’t render at all in iTerm 2, whilst due to being surrounded by ANSI escape codes, iTerm 2’s links fall back to just being text.

Bonus points: If we felt really fancy, we could even make use of the extra provision for a key-value parameter to enable a fix for #32:

printf '\033]8;target=_blank;https://buildkite.com\aBuildkite\033]8;;\a'

[ticky]

@mipearson I don’t suppose you know where the chosen 1339 escape code was from? I don’t seem to be able to establish provenance other than your adding it in #30!

[mipearson]

I .. might have picked it out of thin air? I can't remember if iterm supported links at the time, it might have been a code I chose as it wasn't used elsewhere.

[ticky]

That’s fair - image_code + 1 totes sounds reasonable too! 😃

[lox]

Yeah, I reckon we should totally just support the iterm2 one @ticky

[felixfbecker]

iTerm's image format is different too: https://www.iterm2.com/documentation-images.html

[djmarcin]

What's the reasoning behind requiring the escape sequence for links? Would it not be generally helpful to just linkify anything starting with http:// or https://? It seems like a bad user experience to have to muck about with escape codes to generate links in build output.

[mipearson]

Talking as one of the original authors of this, but I don't work for buildkite, and their views may differ:

It would have been hard to code with the way that terminal parses input (poorly, but quickly).

There's also gotchas that you need to deal with when auto-linking anything that starts with https:// - eg what to do about periods or quotes at the end. I've a vague memory that there might be security concerns as well.

(worth noting also that iterm2 used to auto-link, but then stopped when it turned into a security nightmare as it would try to resolve the domain to work out whether something was a "link" or not, meaning that sometimes people's things that looked like links but were actually security credentials would be transmitted in the clear to a DNS server)

[felixfbecker]

The link escape sequence is to turn any text into a link, much like on the web, without needing to show the full URL in the output

[alecthomas]

FWIW this is now supported by many more terminal emulators and tools, including ls in coreutils, gcc, and so on: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

[dgl]

Any update? Just found out I can't make output which works with this library and in an OSC8 supporting terminal.

[dgl]

I realised because terminal-to-html doesn't handle ST as a terminator, like a conforming terminal should, it is possible to make output that results in the same thing on iTerm2 and this. That's probably confusing to say; so best illustrated by this code:

func crazyURL(url string) string {
        // This generates a very particular set of escape sequences:
        //   OSC8 + ST (terminal-to-html doesn't see this terminator) + URL
        //   OSC8 + BEL (empty URL - terminates OSC8, "xterm" terminator)
        //   OSC1339 (custom buildkite URL)
	return fmt.Sprintf("\x1B]8;;%s\x1B\\%s\x1B]8;;\x07\x1B]1339;url=%s\x07",
            url, url, url)
}

That will result in a single URL being visible and it will be a link in both iTerm2 and terminal-to-html (and correctly degrades to just the plain text version in terminals not supporting OSC8/OSC1339).