Support hyperlinks terminal escapes

[passcod]

See this gist: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

This is supported in iTerm2 and Gnome Terminal.

echo -e '\e]8;;http://example.com\aThis is a link\e]8;;\a'

displays This is a link with some formatting (in gnome term it's a dotted underline) and is clickable to open the given hyperlink.

Tmux currently has no support, so until that happens it's likely not going to be too useful in alacritty, but still a cool feature nonetheless.

[jwilm]

@passcod thanks for filing the issue! This is the approach I had in mind for URL handling. I thought there was another issue for it, but all I can find is #113, and that's not quite the same.

[chrisduerr]

Are there any applications that actually use this though? I feel like implementing a feature to display URLs when no application will ever use it, seems like a waste.

IRC clients like weechat do not support this as far as I know. And it looks like most terminal emulators also do not support this.

[jwilm]

@chrisduerr The more I think about this, it really seems like we need to support both. URL detection is good for a lot of common use cases, but full screen apps like weechat will benefit from the escape sequence.

Even if weechat doesn't already support it, adding a plugin which modifies output really wouldn't be too much work (run parser to find html, wrap with escape sequence).

[wayneashleyberry]

Although not published yet, there's an interesting npm package for rendering these links here: https://github.com/sindresorhus/ink-link. It would be amazing if these could render correctly in Alacritty!

[leezu]

systemd now makes use of this

[chrisduerr]

Huh, I didn't expect any major adoption at this point. That's really good to hear, thanks for the heads-up!

I think it would still make sense to implement both in one go, but that shouldn't be too much additional work.

[aperum]

Isn't this a huge security risk without a preview? One could easily do:

echo -e '\e]8;;http://bad.link\ahttp://good.link\e]8;;\a'

Or not?

[chrisduerr]

Alacritty can show the real URL on hover the same way a Browser does.

The functionality to render text at the bottom of the terminal already exists for drawing the redraw timer and has also been used in #1188.

[tblancher]

Has this been implemented? I see a problem with long, wrapped URLs in mutt, in both and outside of tmux. The URL grabber only appears to get the first apparent line of the URL.

I'm just trying alacritty for the first time, and this will keep me from using it as my daily driver. In urxvt, I have to load a custom Perl mapper script to get wrapped URLs to be fully clickable, so alacritty isn't alone with this problem.

[kchibisov]

@tblancher mutt doesn't wrap urls the way you expect iirc (it wrap it with it's pager, but doesn't set WRAP on a cell), you can pipe a message to a less though (That's what I'm doing here).

[tblancher]

I've noticed that less allows *most* URLs to be clickable, but not all of them (in the same message). Also, you lose a lot of the controls within mutt by not using the builtin pager. I know this works with my `mapper` Perl script in urxvt (for some reason the one that ships in the stock urxvt-perls package doesn't seem to work for this).

…

On Sat, Oct 12, 2019 at 12:11:27PM -0700, Kirill Chibisov wrote: ***@***.*** mutt doesn't wrap urls the way you expect iirc (it wrap it with it's pager, but doesn't set WRAP on a cell), you can pipe a message to a less though (That's what I'm doing here). — You are receiving this because you were mentioned. Reply to this email directly, [2]view it on GitHub, or [3]unsubscribe. References Visible links 1. https://github.com/tblancher 2. #922 3. https://github.com/notifications/unsubscribe-auth/AAOFGQYWFTTPDLWB33ZZW3TQOION7ANCNFSM4EFUQHBA

[kchibisov]

I've noticed that less allows most URLs to be clickable, but not all of them
(in the same message). Also, you lose a lot of the controls within mutt by not
using the builtin pager.

I'm not suggesting to use other pager, I'm suggesting to pipe message content to less on demand when you want to open urls which were wrapped by mutt's pager. So, this binding should give you better understand on what I'm talking about (just press Shift + U while reading a message with mutt's pager).

macro pager U "\
:set my_tmp_pipe_decode=\$pipe_decode\n\
:set pipe_decode\n\
|less\n\
:set pipe_decode=\$my_tmp_pipe_decode\n\
:unset my_tmp_pipe_decode\n"

Anyway this issue is a bit different from your problem. I don't think that mutt supports this escapes.

[tblancher]

I can just run "<pipe-message>less<enter>" and it seems to work OK. Better than urlscan. Although not as pretty, it's more useful because less doesn't lose context (one of the purported features of urlscan). mailcap launches it through elinks -dump automatically, less just fixes the links. Most of the time, anyway.

…

On Sat, Oct 12, 2019 at 10:18:58PM -0700, Kirill Chibisov wrote: I've noticed that less allows most URLs to be clickable, but not all of them (in the same message). Also, you lose a lot of the controls within mutt by not using the builtin pager. I'm not suggesting to use other pager, I'm suggesting to pipe message content to less on demand when you want to open urls which were wrapped by mutt's pager. So, this binding should give you better understand on what I'm talking about (just press Shift + U while reading a message with mutt's pager). macro pager U "\ :set my_tmp_pipe_decode=\$pipe_decode\n\ :set pipe_decode\n\ |less\n\ :set pipe_decode=\$my_tmp_pipe_decode\n\ :unset my_tmp_pipe_decode\n" Anyway this issue is a bit different from your problem. I don't think that mutt supports this escapes. — You are receiving this because you were mentioned. Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe. References Visible links 1. #922 2. https://github.com/notifications/unsubscribe-auth/AAOFGQYSBU7RLBFTSBMZB4TQOKVUFANCNFSM4EFUQHBA

[lachesis]

This is now used by GCC-10's static analysis warnings with the -fanalyzer option. See this redhat blog entry and ctrl-f suitable terminal for more details. I would love to have this feature in Alacritty as well.

[pothos]

It's also used by ls which is great to open any file or folder with the standard application (like xdg-open file://…some.pdf):

$ ls --hyperlink=auto

[legrostdg]

alacritty also fails to recognize multiline urls in vim

[kchibisov]

It fails because vim splits those with \n. The url managing in such(alt screen) apps is up to app. If you try multi line url by printing it via echo it'll work. Nothing we can do about such urls in vim, because the url is on 2 logical lines, not a 1 logical line, like it'll be with echo.

[sersorrel]

Nothing we can do about such urls in vim

well, implementing support for the hyperlink escape sequence would be one piece of the puzzle :) the other piece being a vim plugin or patch to vim itself to make it emit that escape sequence in the appropriate places.

[kchibisov]

well, implementing support for the hyperlink escape sequence would be one piece of the puzzle :) the other piece being a vim plugin or patch to vim itself to make it emit that escape sequence in the appropriate places.

I mean if vim supported that escape sequence then we can do something about it, but vim doesn't support it, meaning that in a current point in time we can't do anything about that. If vim will support that escape sequence than we can do something about it by implementing the escape sequence.

[chrysn]

Please let's not get hung up too much on particular applications that don't have support for this yet (especially those like mutt that generally can only guess as well) -- sure, vim or mutt support would make this even more useful, but given how systemd, ls and gcc already produce useful enough links, this should not be a chicken and egg problem any more.

[adrian-gierakowski]

this feature is a must for any modern terminal IMHO

here's another useful application: a couple of wrappers for ripgrep/vim which allow one to open files in vim at the exact location of a match found by ripgrep: https://github.com/lilydjwg/search-and-view

[aeneby]

I agree with @aperum above - this is a security risk. Browsers, mail clients, etc have the ability to show a preview link before you click. I hope this doesn't become a thing.

[chrysn]

I wouldn't put too much thought to the "one URI shown, a different one clicked" aspect. In the end it's up to registered URI handlers to behave reasonably safe. "Looks like an URI" is quite hard to tell (that's a reason for this in the first place), and there can be good reasons for differences. (Eg. "Why you shouldn't use example.com" won't go to example.com even though today's overzealous autolinkers would make it go there).

A preview is nice and customary, but mobile environments only show link targets when asked too.

[aeneby]

In the end it's up to registered URI handlers to behave reasonably safe

I realise there will be differing opinions on this, but I have to disagree. Users need to be able to make informed choices about what they're clicking on.

[chrysn]

I think that both can be accommodated, possibly with configuration defaults varying by platform (to match the users' expectations). Let's explore options: * Show URI on mouse-over: Yes or no; may depend on further GUI support in alacritty (maybe like the GUI that renders the ctrl-shift-f search box, with some extra trickery to avoid shadowing the link itself if it's in the last line). This could be on-by-default once implemented (but I wouldn't put it as mandatory to have for a first iteration of this feature). * What to do on click: * Run URI handler (platform specific, may be configurable on its own. May need additional vetting eg. on Linux where xdg-open can take both URIs and files, and if the link target is not URI shaped the action has to be rejected.) * Show URI for confirmation and run handler if accepted. (Also depends on further GUI support. Could alternatively offer top copy the selected URI to the clipboard. Might show the application that will be opened for the URI, but that's very platform dependent -- on Linux it'd be `xdg-settings get default-url-scheme-handler `$SCHEME"`, other platforms may not have something like that). * Copy link to clipboard. All those could, in a first viable implementation, be provided by a single configuration entry describing an executable to run with a clicked-on hyperlink URI. A value of `xdg-open` would provide the first, some `zenity --question` invocation the second and something xsel based the third. I still think that not showing the URI but running xdg-open is a sufficiently safe default (or the configured handler's fault when it isn't), but anyway the problem is reduced to finding community acceptable defaults. (Personally, I'd think that unsafe programs should never be in x-scheme-handler registrations, and that any "Do you really want to open ***@***.*** with untrusted-application?" checks should be zenity-like scripts registered as x-scheme-handler in the place of the untrusted application, but that'd need discussion around the xdg, probably).

[oxalica]

What to do on click

Maybe worth mentioning that, KDE konsole open the link on Ctrl+Click instead of direct click. I think this should be preferred. We should not override the left-button-click behavior for the program inside the tty.

[ewtoombs]

A URL tooltip when mousing over is necessary, but if it has that, this would be an insanely useful feature to have.

[XhstormR]

I have a question, this hyperlinks feature won't work with tmux latest version 3.3, right?

[kchibisov]

ask tmux, it's up to it to handle it, since it's also a terminal emulator. If tmux has setting to enable it'll work.

[lilydjwg]

Only latest tmux git works fine, and you need set set -ga terminal-features "*:hyperlinks".

[fma0x]

When putting Alacritty in vi mode, I just press shift and click. It works for me.

And I tested again, and only shift solves it.