Create a gist now

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Hyperlinks in Terminal Emulators
@evaryont

This comment has been minimized.

Show comment
Hide comment
@evaryont

evaryont Apr 25, 2017

This isn't made explicit, and I didn't see any concrete consensus in the discussions, how are arbitrary/non-standard URL schemes handled? From the looks of things, it's not the terminal's responsibility, they will just pass the URL to the OS's own file open routines. So if I wanted to generate a link to say, an IRC chatroom:

echo -e '\e]8;;irc://irc.freenode.net/#lobby\a#lobby channel\e]8;;\a'

All I will need to do is make sure my IRC client is registered in the system to handle irc:// links. Is that correct?

This isn't made explicit, and I didn't see any concrete consensus in the discussions, how are arbitrary/non-standard URL schemes handled? From the looks of things, it's not the terminal's responsibility, they will just pass the URL to the OS's own file open routines. So if I wanted to generate a link to say, an IRC chatroom:

echo -e '\e]8;;irc://irc.freenode.net/#lobby\a#lobby channel\e]8;;\a'

All I will need to do is make sure my IRC client is registered in the system to handle irc:// links. Is that correct?

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Apr 25, 2017

@evaryont You're right, we don't intend to go into such details. It's up to the terminal emulator to decide which schemes it supports and what action it takes on them, probably delegating this decision to some lower level OS routine.

Most terminal emulators already autodetect standard URLs appearing on the screen. On one hand, it's reasonable for them to take the same action, regardless whether e.g. "irc://..." is autodetected as a visible string, or specified explicitly via this new escape sequence. On the other hand, the new one is potentially more easily configurable by the users since they won't have to handcraft complicated regexes, so perhaps some terminal emulators will add a configuration option for this.

It might also make sense for terminal emulators to offer the possibility to override the OS-wide action because the OS-wide registry would probably prefer to open a graphical app, whereas if coming from a terminal emulator, you might want to prefer to open a terminal-based IRC client in a new window/tab of the same terminal emulator, or similarly, prefer a lynx-style browser for http/https rather than a graphical one.

This is an open ended question, leaving room for terminal emulators to come up with nice ideas.

Owner

egmontkob commented Apr 25, 2017

@evaryont You're right, we don't intend to go into such details. It's up to the terminal emulator to decide which schemes it supports and what action it takes on them, probably delegating this decision to some lower level OS routine.

Most terminal emulators already autodetect standard URLs appearing on the screen. On one hand, it's reasonable for them to take the same action, regardless whether e.g. "irc://..." is autodetected as a visible string, or specified explicitly via this new escape sequence. On the other hand, the new one is potentially more easily configurable by the users since they won't have to handcraft complicated regexes, so perhaps some terminal emulators will add a configuration option for this.

It might also make sense for terminal emulators to offer the possibility to override the OS-wide action because the OS-wide registry would probably prefer to open a graphical app, whereas if coming from a terminal emulator, you might want to prefer to open a terminal-based IRC client in a new window/tab of the same terminal emulator, or similarly, prefer a lynx-style browser for http/https rather than a graphical one.

This is an open ended question, leaving room for terminal emulators to come up with nice ideas.

@ssbarnea

This comment has been minimized.

Show comment
Hide comment
@ssbarnea

ssbarnea Jun 21, 2017

This is really cool! I found this after looking for the same thing myself (and wasting some time with the reddit thread).
Is there any ANSI "coloring" python library already implementing this? I would love to start giving hyperlinks as output. The option to display them raw is not ok.

ssbarnea commented Jun 21, 2017

This is really cool! I found this after looking for the same thing myself (and wasting some time with the reddit thread).
Is there any ANSI "coloring" python library already implementing this? I would love to start giving hyperlinks as output. The option to display them raw is not ok.

@Foxboron

This comment has been minimized.

Show comment
Hide comment
@Foxboron

Foxboron Jul 8, 2017

Wouldn't this allow rather ugly attack vectors where the user doesn't understand what he/she is clicking?

Foxboron commented Jul 8, 2017

Wouldn't this allow rather ugly attack vectors where the user doesn't understand what he/she is clicking?

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jul 12, 2017

@ssbarnea Not that I'm aware of. Thanks for spreading the news of this feature and asking others to add support!

Owner

egmontkob commented Jul 12, 2017

@ssbarnea Not that I'm aware of. Thanks for spreading the news of this feature and asking others to add support!

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jul 12, 2017

@Foxboron I'm fairly sure there's no risk here at all. The situation shouldn't be any worse than clicking on a link on an untrusted webpage. In fact, webpages are worse. First, they can leak data via the Referer field which isn't filled out if you click from the terminal emulator. Second, they can do nasty JS tricks to alter the target just when you click on the link (sometimes this is actually used for good purposes, like to inject a redirector which hides the referring page). In the terminal emulator a malicious app can still probably overwrite the link target at any time, but it has no clue when you're about to click.

Any webpage that does harmful things (e.g. delete data stored on a server) by just visiting a link suffer from CSRF bug anyway which can be exploited from browsers (malicious websites) too.

Owner

egmontkob commented Jul 12, 2017

@Foxboron I'm fairly sure there's no risk here at all. The situation shouldn't be any worse than clicking on a link on an untrusted webpage. In fact, webpages are worse. First, they can leak data via the Referer field which isn't filled out if you click from the terminal emulator. Second, they can do nasty JS tricks to alter the target just when you click on the link (sometimes this is actually used for good purposes, like to inject a redirector which hides the referring page). In the terminal emulator a malicious app can still probably overwrite the link target at any time, but it has no clue when you're about to click.

Any webpage that does harmful things (e.g. delete data stored on a server) by just visiting a link suffer from CSRF bug anyway which can be exploited from browsers (malicious websites) too.

@towolf

This comment has been minimized.

Show comment
Hide comment
@stefanhaustein

This comment has been minimized.

Show comment
Hide comment
@stefanhaustein

stefanhaustein Sep 3, 2017

What happens to "data:" urls or pure local (#) links? Any chance to get anything to STDIN or back to a terminal based app that doesn't involve registering a link handler with the window manager? Use case: local link handling inside a "pure" command-line app with hyperlink support.

What happens to "data:" urls or pure local (#) links? Any chance to get anything to STDIN or back to a terminal based app that doesn't involve registering a link handler with the window manager? Use case: local link handling inside a "pure" command-line app with hyperlink support.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Sep 3, 2017

@stefanhaustein Interpretation of different schemes (or lack thereof) is up to the terminal emulator. E.g. with "data:" URLs they might show a popup with the content, or store in a temporary file and open that. Note that with the current limit of 2083 bytes for the URL in both VTE and iTerm2, the "data:" scheme isn't quite useful. I wouldn't want to significantly increase the limit (let alone remove it altogether) because then a malicious utility could cause the terminal emulator to eat tons of memory.

Handling the link inside the existing terminal emulator is alas again something that would be truly problematic. It would raise tons of questions like what to do if an app is already running or if you're ssh'd to a remote host, and probably a whole lot more. Not to mention that if we did anything like this, that would probably introduce serious security concerns.

The closest you can do with the current design is to specify a handler that opens a new terminal window and a specific app inside that, e.g. "lynx" for "http(s)" scheme. I'm not sure if iTerm2 allows you to configure this. GNOME Terminal takes the handler app from the global GNOME-wide configuration, hence it cannot differ from what's used for graphical apps. This is something we might improve on if there's a high demand – or other VTE-based apps might implement this.

Owner

egmontkob commented Sep 3, 2017

@stefanhaustein Interpretation of different schemes (or lack thereof) is up to the terminal emulator. E.g. with "data:" URLs they might show a popup with the content, or store in a temporary file and open that. Note that with the current limit of 2083 bytes for the URL in both VTE and iTerm2, the "data:" scheme isn't quite useful. I wouldn't want to significantly increase the limit (let alone remove it altogether) because then a malicious utility could cause the terminal emulator to eat tons of memory.

Handling the link inside the existing terminal emulator is alas again something that would be truly problematic. It would raise tons of questions like what to do if an app is already running or if you're ssh'd to a remote host, and probably a whole lot more. Not to mention that if we did anything like this, that would probably introduce serious security concerns.

The closest you can do with the current design is to specify a handler that opens a new terminal window and a specific app inside that, e.g. "lynx" for "http(s)" scheme. I'm not sure if iTerm2 allows you to configure this. GNOME Terminal takes the handler app from the global GNOME-wide configuration, hence it cannot differ from what's used for graphical apps. This is something we might improve on if there's a high demand – or other VTE-based apps might implement this.

@flarn2006

This comment has been minimized.

Show comment
Hide comment
@flarn2006

flarn2006 Sep 13, 2017

@egmontkob: Malicious "utilities" aren't worth worrying about. If you're executing a malicious binary, you've got much bigger problems than a terminal emulator eating up memory. However, catting a text file could be a problem, as people expect text files to be safe to display. This is actually similar to an issue MS-DOS had with the ANSI.SYS driver, only that was much worse, as that allowed random text files to change what the keys on your keyboard do—for instance, making a common letter instead type a command that formats your hard drive and press Enter.

@egmontkob: Malicious "utilities" aren't worth worrying about. If you're executing a malicious binary, you've got much bigger problems than a terminal emulator eating up memory. However, catting a text file could be a problem, as people expect text files to be safe to display. This is actually similar to an issue MS-DOS had with the ANSI.SYS driver, only that was much worse, as that allowed random text files to change what the keys on your keyboard do—for instance, making a common letter instead type a command that formats your hard drive and press Enter.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Sep 13, 2017

@flarn2006 Thanks for the clarification, I indeed did not clearly distinguish these two. A malicious binary can also be a compromised binary on a remote system that you ssh into, in which case it's like locally cating a maliciously constructed text file (plus all the damage being done over there on the compromised system). As far as the terminal emulator is concerned, it's only the incoming byte stream that matters.

Owner

egmontkob commented Sep 13, 2017

@flarn2006 Thanks for the clarification, I indeed did not clearly distinguish these two. A malicious binary can also be a compromised binary on a remote system that you ssh into, in which case it's like locally cating a maliciously constructed text file (plus all the damage being done over there on the compromised system). As far as the terminal emulator is concerned, it's only the incoming byte stream that matters.

@hdon

This comment has been minimized.

Show comment
Hide comment
@hdon

hdon Oct 10, 2017

A note to any maintainers of terminal emulators out there: please include a prominent option to scale back this feature. I've been using terminal emulators for 20 years and one behavior I find really annoying is clicking even what is obviously a URL and then having it come up in my browser. Sometimes I'm just trying to select text...

(Oh, and rectangle select is a nice feature, too, guys!)

hdon commented Oct 10, 2017

A note to any maintainers of terminal emulators out there: please include a prominent option to scale back this feature. I've been using terminal emulators for 20 years and one behavior I find really annoying is clicking even what is obviously a URL and then having it come up in my browser. Sometimes I'm just trying to select text...

(Oh, and rectangle select is a nice feature, too, guys!)

@mofux

This comment has been minimized.

Show comment
Hide comment
@mofux

mofux Nov 28, 2017

For reference, xterm.js is tracking this feature request here: xtermjs/xterm.js#1134

mofux commented Nov 28, 2017

For reference, xterm.js is tracking this feature request here: xtermjs/xterm.js#1134

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Nov 28, 2017

@mofux Thanks, added.

Owner

egmontkob commented Nov 28, 2017

@mofux Thanks, added.

@devkev

This comment has been minimized.

Show comment
Hide comment
@devkev

devkev Nov 30, 2017

To follow up on @Foxboron's earlier comment, it would be great if this document included a requirement for terminals to prominently inform the user of the actual URL before they click on it, eg. on hover (similar to web browsers). iTerm2 does this, but I'm not sure about other terminals.

This isn't just a convenience, it's important to prevent attacks like '\e]8;;http://malicious.com/\ahttp://safe.com/\e]8;;\a' (ie. the user thinks they're clicking a link to safe.com, but they're actually going to malicious.com), which is why I think it should be mandatory.

devkev commented Nov 30, 2017

To follow up on @Foxboron's earlier comment, it would be great if this document included a requirement for terminals to prominently inform the user of the actual URL before they click on it, eg. on hover (similar to web browsers). iTerm2 does this, but I'm not sure about other terminals.

This isn't just a convenience, it's important to prevent attacks like '\e]8;;http://malicious.com/\ahttp://safe.com/\e]8;;\a' (ie. the user thinks they're clicking a link to safe.com, but they're actually going to malicious.com), which is why I think it should be mandatory.

@aisamanra

This comment has been minimized.

Show comment
Hide comment
@aisamanra

aisamanra Nov 30, 2017

Given that our Matterhorn project was linked to up above, I figure I should note here that our newest Matterhorn release—version 40400.0.0—produces hyperlink escape sequences for all links which appear in the chat. (Matterhorn is built on top of the vty and brick libraries, which are medium- and high-level abstractions over terminals, respectively, and both of these libraries added support for hyperlink escape sequences in October.)

Given that our Matterhorn project was linked to up above, I figure I should note here that our newest Matterhorn release—version 40400.0.0—produces hyperlink escape sequences for all links which appear in the chat. (Matterhorn is built on top of the vty and brick libraries, which are medium- and high-level abstractions over terminals, respectively, and both of these libraries added support for hyperlink escape sequences in October.)

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Dec 1, 2017

@aisamanra: Thanks, added.

Owner

egmontkob commented Dec 1, 2017

@aisamanra: Thanks, added.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Dec 1, 2017

@devkev: gnome-terminal shows the target as a tooltip (appears about half a second after you stop moving the mouse). Not sure about tilix and I cannot test it right now.

I'm not sure I fully share your concerns. It's a quite complex scenario and I'm wondering if the terminal emulator is the right way to address this, I'm honestly not sure.

Certain utilities use this feature for linkifying what they autodetect as links anyways, just to keep it working across linebreaks or so. As far as I understand, the aforementioned Matterhorn is such an example: it cannot be tricked by a remote user to show URLs where the actual target differs from the visible text. Other utilities, like ls also always produce trustable output.

Another use case is where the visible URL and the target are significantly different. Let's say a site literally called malicious.com looks totally like Facebook, phishing for your data hoping that you'd enter your credentials there. In this case this malicious URL will also be visible in your browser's URL bar, and I'm not entirely sure how much the terminal emulator also showing this URL would help you notice what's going on.

Yet another use case is where the actual URL looks damn similar to the one it's phishing, let's say faceboook.com (with three o's) or some Unicode ideographs. In this case again the terminal emulator showing the target probably wouldn't help you too much in catching the phishing attempt. Also note that this does not only hold for such OSC 8 explicit hyperlinks, the current feature of autodetecting URLs in pretty much every graphical terminal emulator also suffers from this issue, it isn't addressed there and I'm not aware of anyone ever having complained about it.

To tell a malicious site, it's probably a better approach to have some centrally maintained database of known such sites, and check the URL against that. And that's what modern browsers do when you open the URL. The same functionality could be repeated elsewhere too: In utilities that present links to the users (let's say, terminal based e-mail clients); in the URL-opening framework of popular graphical desktops (e.g. whatever happens behind the scenes after a gtk_show_uri()); or indeed in terminal emulators. I'm not sure what the best place for this is.

Given what browsers already do, terminal emulators here could be another line of defense, but would definitely not be the only one, nor the strongest one. As such, I wouldn't make it a requirement. I'd say terminal emulators are recommended to show the target URL, but it's also up to the users to choose an emulator accordingly (or file feature requests, PRs) if this feature is important for them. Obviously there's also room for further improvements, e.g. some terminal emulators might want download some malware list and check the URL against it, or might highlight the domain name (as browsers do in the URL bar) or might want to warn the user in case non-ASCII letters are present in the domain name, etc.

So I'd suggest that we bring these issues to the attention of terminal emulator developers, and recommend them to at least somehow conveniently let users figure out the URL before they activate it. Does this sound reasonable to you?

Owner

egmontkob commented Dec 1, 2017

@devkev: gnome-terminal shows the target as a tooltip (appears about half a second after you stop moving the mouse). Not sure about tilix and I cannot test it right now.

I'm not sure I fully share your concerns. It's a quite complex scenario and I'm wondering if the terminal emulator is the right way to address this, I'm honestly not sure.

Certain utilities use this feature for linkifying what they autodetect as links anyways, just to keep it working across linebreaks or so. As far as I understand, the aforementioned Matterhorn is such an example: it cannot be tricked by a remote user to show URLs where the actual target differs from the visible text. Other utilities, like ls also always produce trustable output.

Another use case is where the visible URL and the target are significantly different. Let's say a site literally called malicious.com looks totally like Facebook, phishing for your data hoping that you'd enter your credentials there. In this case this malicious URL will also be visible in your browser's URL bar, and I'm not entirely sure how much the terminal emulator also showing this URL would help you notice what's going on.

Yet another use case is where the actual URL looks damn similar to the one it's phishing, let's say faceboook.com (with three o's) or some Unicode ideographs. In this case again the terminal emulator showing the target probably wouldn't help you too much in catching the phishing attempt. Also note that this does not only hold for such OSC 8 explicit hyperlinks, the current feature of autodetecting URLs in pretty much every graphical terminal emulator also suffers from this issue, it isn't addressed there and I'm not aware of anyone ever having complained about it.

To tell a malicious site, it's probably a better approach to have some centrally maintained database of known such sites, and check the URL against that. And that's what modern browsers do when you open the URL. The same functionality could be repeated elsewhere too: In utilities that present links to the users (let's say, terminal based e-mail clients); in the URL-opening framework of popular graphical desktops (e.g. whatever happens behind the scenes after a gtk_show_uri()); or indeed in terminal emulators. I'm not sure what the best place for this is.

Given what browsers already do, terminal emulators here could be another line of defense, but would definitely not be the only one, nor the strongest one. As such, I wouldn't make it a requirement. I'd say terminal emulators are recommended to show the target URL, but it's also up to the users to choose an emulator accordingly (or file feature requests, PRs) if this feature is important for them. Obviously there's also room for further improvements, e.g. some terminal emulators might want download some malware list and check the URL against it, or might highlight the domain name (as browsers do in the URL bar) or might want to warn the user in case non-ASCII letters are present in the domain name, etc.

So I'd suggest that we bring these issues to the attention of terminal emulator developers, and recommend them to at least somehow conveniently let users figure out the URL before they activate it. Does this sound reasonable to you?

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Dec 2, 2017

I'll also note that soon Vty will not do hyperlinking by default because of garbage output with older versions of VTE. An API call will be required to opt in and enable it. For more info: jtdaugherty/vty#137

I'll also note that soon Vty will not do hyperlinking by default because of garbage output with older versions of VTE. An API call will be required to opt in and enable it. For more info: jtdaugherty/vty#137

@devkev

This comment has been minimized.

Show comment
Hide comment
@devkev

devkev Dec 4, 2017

@egmontkob, I think you may have missed the point. This isn't about trying to detect malicious sites, or spoofing attempts. It's about users being able to make an informed choice (about clicking on a link). Without the ability to discover the actual url, arbitrary-text links introduce an ambiguity that prevents users from being able to trust any links presented to them. This makes the linking feature effectively useless, and a security risk.

Suppose you have a terminal which:

  • auto links urls
  • displays arbitrary-text links to urls (ie. this spec)
  • does not have any way for users to discover the actual url of these links

Now you (the user) see the linkified text https://www.google.com/ somewhere on your screen. If you click on this, will the Google homepage be loaded in your browser? You have absolutely no way of knowing. Clicking the link could open literally any url at all, including urls that you (the user) would never have chosen to click if you had been properly informed.

This is why it's vital for users to be able to discover the actual url of any link. It's the same reason that web browsers and email clients show users the actual url. It applies to any software that presents arbitrary text hyperlinks.

devkev commented Dec 4, 2017

@egmontkob, I think you may have missed the point. This isn't about trying to detect malicious sites, or spoofing attempts. It's about users being able to make an informed choice (about clicking on a link). Without the ability to discover the actual url, arbitrary-text links introduce an ambiguity that prevents users from being able to trust any links presented to them. This makes the linking feature effectively useless, and a security risk.

Suppose you have a terminal which:

  • auto links urls
  • displays arbitrary-text links to urls (ie. this spec)
  • does not have any way for users to discover the actual url of these links

Now you (the user) see the linkified text https://www.google.com/ somewhere on your screen. If you click on this, will the Google homepage be loaded in your browser? You have absolutely no way of knowing. Clicking the link could open literally any url at all, including urls that you (the user) would never have chosen to click if you had been properly informed.

This is why it's vital for users to be able to discover the actual url of any link. It's the same reason that web browsers and email clients show users the actual url. It applies to any software that presents arbitrary text hyperlinks.

@devkev

This comment has been minimized.

Show comment
Hide comment
@devkev

devkev Dec 4, 2017

Also, terminology's ticket tracking this feature is https://phab.enlightenment.org/T6329

devkev commented Dec 4, 2017

Also, terminology's ticket tracking this feature is https://phab.enlightenment.org/T6329

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Dec 4, 2017

@devkev I understand your usability concerns here, but I don't understand how it's a security or privacy concern, and as such, I'd leave it up to authors of terminal emulators, and leave it up to users to choose a terminal emulator meeting their needs.

As I've already mentioned in this comment, this problem is also present and is more serious on webpages. E.g. search for something in Google and hover over the results. In the bottom corner of the browser, you'll see that the link points let's say to Wikipedia. The moment you click on it (before the browser begins to follow it) the link target is changed to some Google-owned redirector. This is a proof that it can be done on webpages, and hence probably can be done for malicious purposes as well. At least in terminal emulators, the target cannot be altered just when you click on it.

Owner

egmontkob commented Dec 4, 2017

@devkev I understand your usability concerns here, but I don't understand how it's a security or privacy concern, and as such, I'd leave it up to authors of terminal emulators, and leave it up to users to choose a terminal emulator meeting their needs.

As I've already mentioned in this comment, this problem is also present and is more serious on webpages. E.g. search for something in Google and hover over the results. In the bottom corner of the browser, you'll see that the link points let's say to Wikipedia. The moment you click on it (before the browser begins to follow it) the link target is changed to some Google-owned redirector. This is a proof that it can be done on webpages, and hence probably can be done for malicious purposes as well. At least in terminal emulators, the target cannot be altered just when you click on it.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Dec 4, 2017

@devkev I've added the Terminology link, thanks. (Honestly, I don't expect any terminal emulator that refused true color support to implement this one, and hence I myself didn't bother filing feature requests against them.)

Owner

egmontkob commented Dec 4, 2017

@devkev I've added the Terminology link, thanks. (Honestly, I don't expect any terminal emulator that refused true color support to implement this one, and hence I myself didn't bother filing feature requests against them.)

@vapier

This comment has been minimized.

Show comment
Hide comment
@vapier

vapier Feb 26, 2018

i've implemented this in hterm (commit) and released it in hterm-1.76. couldn't see any way of updating the gist or sending an update request directly.

vapier commented Feb 26, 2018

i've implemented this in hterm (commit) and released it in hterm-1.76. couldn't see any way of updating the gist or sending an update request directly.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Feb 28, 2018

@vapier Thanks a lot, it's great to hear this feature is gaining popularity. I've updated the page. (I've no clue either how to do collaborative stuff on gists.)

Owner

egmontkob commented Feb 28, 2018

@vapier Thanks a lot, it's great to hear this feature is gaining popularity. I've updated the page. (I've no clue either how to do collaborative stuff on gists.)

@1Hyena

This comment has been minimized.

Show comment
Hide comment
@1Hyena

1Hyena Mar 11, 2018

Just learned about this! This is awesome, it has enormous implications to text-based gaming (MUDs). Is it possible to send a predefined string to stdin when user clicks on a link? That would make Text User Interfaces s so much more convenient to use.

1Hyena commented Mar 11, 2018

Just learned about this! This is awesome, it has enormous implications to text-based gaming (MUDs). Is it possible to send a predefined string to stdin when user clicks on a link? That would make Text User Interfaces s so much more convenient to use.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Mar 13, 2018

@1Hyena It would probably be a quite straightforward change to e.g. gnome-terminal to handle special URIs like send-text:foobar. There's no standard for such protocol (scheme) though, and more importantly, this feature wouldn't be accepted mainstream due to the serious security implications.

Owner

egmontkob commented Mar 13, 2018

@1Hyena It would probably be a quite straightforward change to e.g. gnome-terminal to handle special URIs like send-text:foobar. There's no standard for such protocol (scheme) though, and more importantly, this feature wouldn't be accepted mainstream due to the serious security implications.

@modest

This comment has been minimized.

Show comment
Hide comment
@modest

modest Apr 7, 2018

It seems critical to include some spec guidance on schema whitelists and security. The reality on most platforms is that many apps register insecure URI schema handlers for private usage. (My Mac has over 140 of these protocols registered.) These apps did not consider the security or privacy implications of the schema being abused by a third party. A malicious URL can cause these apps to take actions without user confirmation, crash the process, execute arbitrary code, login as a different user, or repeatedly call the police.

For this reason, all major web browsers have whitelists for URL schemas that are allowed without prompting the user (usually just http:, https:, and ftp:). For all other URL schemas, the user is prompted after clicking the link and must explicitly allow the schema handler to open. This prevents users from being tricked into clicking on links that abuse poorly-secured schema handlers from installed apps.

Example of a security prompt in Chrome when clicking a skype: link
screen shot 2018-04-06 at 22 19 44

@egmontkob:

I'm fairly sure there's no risk here at all. The situation shouldn't be any worse than clicking on a link on an untrusted webpage.

It is true that this feature is no more dangerous than a web browser, but only if implemented with a schema whitelist like a web browser. Otherwise, this exposes terminals to a dangerous and widespread category of vulnerabilities.

modest commented Apr 7, 2018

It seems critical to include some spec guidance on schema whitelists and security. The reality on most platforms is that many apps register insecure URI schema handlers for private usage. (My Mac has over 140 of these protocols registered.) These apps did not consider the security or privacy implications of the schema being abused by a third party. A malicious URL can cause these apps to take actions without user confirmation, crash the process, execute arbitrary code, login as a different user, or repeatedly call the police.

For this reason, all major web browsers have whitelists for URL schemas that are allowed without prompting the user (usually just http:, https:, and ftp:). For all other URL schemas, the user is prompted after clicking the link and must explicitly allow the schema handler to open. This prevents users from being tricked into clicking on links that abuse poorly-secured schema handlers from installed apps.

Example of a security prompt in Chrome when clicking a skype: link
screen shot 2018-04-06 at 22 19 44

@egmontkob:

I'm fairly sure there's no risk here at all. The situation shouldn't be any worse than clicking on a link on an untrusted webpage.

It is true that this feature is no more dangerous than a web browser, but only if implemented with a schema whitelist like a web browser. Otherwise, this exposes terminals to a dangerous and widespread category of vulnerabilities.

@gsemet

This comment has been minimized.

Show comment
Hide comment
@gsemet

gsemet Apr 14, 2018

Guake has been updated and should support this now :)

gsemet commented Apr 14, 2018

Guake has been updated and should support this now :)

@nickl-

This comment has been minimized.

Show comment
Hide comment
@nickl-

nickl- May 1, 2018

Testing the waters to see if the community has an interest to explore and define standards for currently off-spec but terminal hypertext link related/useful uri schemes. URI schemes and OS specific scheme handlers for terminal hypertext links functionality directed back towards the shell session.

See nickl-/term-hyperlinks and create an issue with your comments and suggestions.

nickl- commented May 1, 2018

Testing the waters to see if the community has an interest to explore and define standards for currently off-spec but terminal hypertext link related/useful uri schemes. URI schemes and OS specific scheme handlers for terminal hypertext links functionality directed back towards the shell session.

See nickl-/term-hyperlinks and create an issue with your comments and suggestions.

@haya14busa

This comment has been minimized.

Show comment
Hide comment
@haya14busa

haya14busa May 4, 2018

FWIW, I write a shell script which support tmux too. https://github.com/haya14busa/hyperlink

FWIW, I write a shell script which support tmux too. https://github.com/haya14busa/hyperlink

@PerBothner

This comment has been minimized.

Show comment
Hide comment
@PerBothner

PerBothner May 10, 2018

DomTerm version 1.0.2 now supports this escape sequence.

DomTerm also has special handling of file: URLs of the form file:/filename#position=line or file:/filename#position=line:column. Clicking on such a link brings up an editor at the specified position. See here and here. These links can be created explicitly (using the \e]8 escape sequence or DomTerm's more general sequence to embed HTML), or implicit (based on matching the pattern FILENAME:LINE: or FILENAME:LINE:COLUMN: - as produced by compiler error messages). This may worth considering as an extension of the specification.

DomTerm version 1.0.2 now supports this escape sequence.

DomTerm also has special handling of file: URLs of the form file:/filename#position=line or file:/filename#position=line:column. Clicking on such a link brings up an editor at the specified position. See here and here. These links can be created explicitly (using the \e]8 escape sequence or DomTerm's more general sequence to embed HTML), or implicit (based on matching the pattern FILENAME:LINE: or FILENAME:LINE:COLUMN: - as produced by compiler error messages). This may worth considering as an extension of the specification.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob May 10, 2018

@modest Thanks a lot, I believe you raised an important problem.

In an ideal world, I guess we could just sit back and blame those URL handler apps that do harmful stuff upon clicking on their URLs, couldn't we? We're far from this, and as such, sure it would be desirable for terminal emulators to ask for confirmation.

I don't know if certain operating systems or desktop environments provide any support (framework) for this, or it needs to be implemented from scratch in terminal emulators. Ideally, I guess anyone who provides a method to open a URL (e.g. GTK+'s gtk_show_uri()) should give us some help here. In practice I'm afraid they don't.

Owner

egmontkob commented May 10, 2018

@modest Thanks a lot, I believe you raised an important problem.

In an ideal world, I guess we could just sit back and blame those URL handler apps that do harmful stuff upon clicking on their URLs, couldn't we? We're far from this, and as such, sure it would be desirable for terminal emulators to ask for confirmation.

I don't know if certain operating systems or desktop environments provide any support (framework) for this, or it needs to be implemented from scratch in terminal emulators. Ideally, I guess anyone who provides a method to open a URL (e.g. GTK+'s gtk_show_uri()) should give us some help here. In practice I'm afraid they don't.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob May 10, 2018

@PerBothner Thanks for the heads-up!

I actually looked around a while ago and was surprised to see that there wasn't a common notation for jumping to a certain position. It would sure be nice to see a standard emerging. Compiler errors, as you mention, is a perfect use case. Another one could be the filename as printed by grep in front of every matching line.

(As far as gnome-terminal is concerned, there's nothing we could do in gnome-terminal itself though, handling the position should go into GTK+.)

I can see a couple of issues, though.

A local file, denoted by the file: scheme, could still have a MIME type, probably autodetected based on extension or file contents magic. And that MIME type could be e.g. text/html or any other format that does have the concept of internal positions to jump to. So, we have a conflict since these two features don't have a separate namespace. Should a file:/foo.html#position=5 jump to the fifth line, or to the HTML tag having the ID of "position=5"? (But let's take one step back: Who decides whether to open this file with a plain text viewer as raw text, or with a HTML viewer as rendered HTML? Anyone adding that "#position=5" probably expects that it'll be opened as a text file. So shouldn't we also add the possibility to force opening with a plain text viewer; e.g. by specifying a forced MIME type?)

I find the choice of the word "position=" quite unfortunate, as it's not clearly extendable to other use cases, e.g. byte offset in a text file, page number within a PDF, time offset within a video etc. They're all positions, taking a unit of a different dimension as their argument. Probably "line=" and "column=" would be better, although I'm not sure what should be the separator between them (is another '#' okay?).

For plain text files let's assume that "line" is a clear story (let's for now put aside all those confusions that CR vs. LF vs. CR-LF can cause). "column" is more problematic. What's the encoding of the text file? Do we count bytes, or characters, or width in terminal (including double-wide characters), or Unicode codepoints, or what exactly? How to handle TAB? What about BiDi, is it logical or visual column?

Would be nice to have some standard (maybe even an RFC) about this. I'm afraid DomTerm isn't a strong enough reference everyone would agree to follow.

Owner

egmontkob commented May 10, 2018

@PerBothner Thanks for the heads-up!

I actually looked around a while ago and was surprised to see that there wasn't a common notation for jumping to a certain position. It would sure be nice to see a standard emerging. Compiler errors, as you mention, is a perfect use case. Another one could be the filename as printed by grep in front of every matching line.

(As far as gnome-terminal is concerned, there's nothing we could do in gnome-terminal itself though, handling the position should go into GTK+.)

I can see a couple of issues, though.

A local file, denoted by the file: scheme, could still have a MIME type, probably autodetected based on extension or file contents magic. And that MIME type could be e.g. text/html or any other format that does have the concept of internal positions to jump to. So, we have a conflict since these two features don't have a separate namespace. Should a file:/foo.html#position=5 jump to the fifth line, or to the HTML tag having the ID of "position=5"? (But let's take one step back: Who decides whether to open this file with a plain text viewer as raw text, or with a HTML viewer as rendered HTML? Anyone adding that "#position=5" probably expects that it'll be opened as a text file. So shouldn't we also add the possibility to force opening with a plain text viewer; e.g. by specifying a forced MIME type?)

I find the choice of the word "position=" quite unfortunate, as it's not clearly extendable to other use cases, e.g. byte offset in a text file, page number within a PDF, time offset within a video etc. They're all positions, taking a unit of a different dimension as their argument. Probably "line=" and "column=" would be better, although I'm not sure what should be the separator between them (is another '#' okay?).

For plain text files let's assume that "line" is a clear story (let's for now put aside all those confusions that CR vs. LF vs. CR-LF can cause). "column" is more problematic. What's the encoding of the text file? Do we count bytes, or characters, or width in terminal (including double-wide characters), or Unicode codepoints, or what exactly? How to handle TAB? What about BiDi, is it logical or visual column?

Would be nice to have some standard (maybe even an RFC) about this. I'm afraid DomTerm isn't a strong enough reference everyone would agree to follow.

@PerBothner

This comment has been minimized.

Show comment
Hide comment
@PerBothner

PerBothner May 29, 2018

"Should a file:/foo.html#position=5 jump to the fifth line, or to the HTML tag having the ID of "position=5"?"

The character '=' is not valid for the id attribute in either XML and HTML 4. It is allowed by HTML 5, but discouraged. Some user agents may be able to go to check if there is an ID with value "position=5", but if they can't it is reasonable to ignore that possibility.

"Probably "line=" and "column=" would be better,"

That doesn't handle ranges: START_LINE:START_COLUMN to END_LINE:END_COLUMN. For an error messages or grep output it can be useful to not only navigate to a position, but also to high-light a range.

"although I'm not sure what should be the separator between them (is another '#' okay?)"

I don't believe so. Using '&' seems reasonable - it matches the convention for "query string" (starting with '?'). Basically, the server handles the '?' part; the browser handles the '#' part.

"So shouldn't we also add the possibility to force opening with a plain text viewer; e.g. by specifying a forced MIME type?"

The format can be extended. For example foo.ext#position=10:12&mime-type=text/plain

"find the choice of the word "position=" quite unfortunate"

I'm not disagreeing. Just keep in mind that the encoding should support ranges.

""column" is more problematic. What's the encoding of the text file? Do we count bytes, or characters, or width in terminal (including double-wide characters), or Unicode codepoints, or what exactly? How to handle TAB? What about BiDi, is it logical or visual column?"

The Language Server Protocol counts 16-bit characters. I.e. Unicode characters not in the BMP (Basic Multilingual Plane) count 2 as they use a surrogate pair. Nice and simple for Java or JavaScript but not very semantic and somewhat error-prone (since people will often skip dealing with it.)

In LSP both line and column numbers are zero-based, not one-based. (DomTerm #position values are one-based, though.)

LSP does specify 1 for with TAB and double-wide characters (in the BMP), which I think is a reasonable choice.

Note it is possible to pick one convention - and allow future extensions. A URL could possible encode positions in more than one way:

foo.java#position=3:10&lsp-position=2:12

Some user-agents could handle #position; some could handle #lsp-position; some could handle both. Some producers (compilers etc) could emit one or the other or both. If a handler sees #lsp-position but can only handle #position it can convert to the former by adding 1. That might not be 100% right but it would usually be good enough.

An RFC could be nice, I agree.

"Should a file:/foo.html#position=5 jump to the fifth line, or to the HTML tag having the ID of "position=5"?"

The character '=' is not valid for the id attribute in either XML and HTML 4. It is allowed by HTML 5, but discouraged. Some user agents may be able to go to check if there is an ID with value "position=5", but if they can't it is reasonable to ignore that possibility.

"Probably "line=" and "column=" would be better,"

That doesn't handle ranges: START_LINE:START_COLUMN to END_LINE:END_COLUMN. For an error messages or grep output it can be useful to not only navigate to a position, but also to high-light a range.

"although I'm not sure what should be the separator between them (is another '#' okay?)"

I don't believe so. Using '&' seems reasonable - it matches the convention for "query string" (starting with '?'). Basically, the server handles the '?' part; the browser handles the '#' part.

"So shouldn't we also add the possibility to force opening with a plain text viewer; e.g. by specifying a forced MIME type?"

The format can be extended. For example foo.ext#position=10:12&mime-type=text/plain

"find the choice of the word "position=" quite unfortunate"

I'm not disagreeing. Just keep in mind that the encoding should support ranges.

""column" is more problematic. What's the encoding of the text file? Do we count bytes, or characters, or width in terminal (including double-wide characters), or Unicode codepoints, or what exactly? How to handle TAB? What about BiDi, is it logical or visual column?"

The Language Server Protocol counts 16-bit characters. I.e. Unicode characters not in the BMP (Basic Multilingual Plane) count 2 as they use a surrogate pair. Nice and simple for Java or JavaScript but not very semantic and somewhat error-prone (since people will often skip dealing with it.)

In LSP both line and column numbers are zero-based, not one-based. (DomTerm #position values are one-based, though.)

LSP does specify 1 for with TAB and double-wide characters (in the BMP), which I think is a reasonable choice.

Note it is possible to pick one convention - and allow future extensions. A URL could possible encode positions in more than one way:

foo.java#position=3:10&lsp-position=2:12

Some user-agents could handle #position; some could handle #lsp-position; some could handle both. Some producers (compilers etc) could emit one or the other or both. If a handler sees #lsp-position but can only handle #position it can convert to the former by adding 1. That might not be 100% right but it would usually be good enough.

An RFC could be nice, I agree.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob May 31, 2018

The character '=' is not valid for the id attribute

Still, it's a pretty ugly design if the semantics of a keyword depends on whether the value contains such a sign or not. But it might still be the best we can come up with.

That doesn't handle ranges: START_LINE:START_COLUMN to END_LINE:END_COLUMN. For an error messages or grep output it can be useful to not only navigate to a position, but also to high-light a range.

Is this really needed, or is it an overkill? If really needed, don't we need multiple ranges too? E.g. grep can find multiple matches within a row. I'd rather say it's an overkill for now, but the chosen design should be forward compatible with such possible improvements.

Language Server Protocol

Never heard of that; will need to take a closer look.

counts 16-bit characters. I.e. Unicode characters not in the BMP (Basic Multilingual Plane) count 2 as they use a surrogate pair [...] not very semantic and somewhat error-prone

They use a surrogate pair in UTF-16, the most brain-damaged encoding of Unicode, combining the disadvantages of other representation formats (UCS-4 and UTF-8). This encoding should have died out a long time ago. Luckily AFAICT it's mostly used internally by some legacy stuff that originated in the very early days Unicode, like Java. (Or is it still a common thing in Windows?) Especially in the Unix world where data exchange happens primarily in UTF-8, I can't imagine any valid reason for non-BMP to be handled differently from BMP.

I'd say it's a TERRIBLE thing, freaking error-prone, and gets an absolutely "no go" vote from me.

LSP does specify 1 for with TAB and double-wide characters (in the BMP), which I think is a reasonable choice.

Agree. We need to encode logical positions within the text file, rather than visual positions. The editor that opens the file will know the tab width it chooses and will place the cursor in its corresponding visual position, meaning that the indicated column number will probably be quite different, it's its internal business. Tools like gcc -ftabstop=... will need to take care to generate different column numbers for the URL than for the visual column number they print based on their assumption of tab width.

Note it is possible to pick one convention - and allow future extensions.

Future extensions: yes. Future alternatives: no.

If a handler sees #lsp-position but can only handle #position it can convert to the former by adding 1.

(s/former/latter I guess.)

If a handler recognizes the keyword #lsp-position and knows to add 1, then it already supports it (at least to some basic degree), doesn't it? What if it doesn't recognize this keyword at all?

There has to be a minimum base that's commonly used everywhere, and there could go extensions on top of that, that's okay. It's NOT okay to have competing alternatives, i.e. if an emitter may emit either format X or Y, and a consumer might understand only one of X and Y.

Owner

egmontkob commented May 31, 2018

The character '=' is not valid for the id attribute

Still, it's a pretty ugly design if the semantics of a keyword depends on whether the value contains such a sign or not. But it might still be the best we can come up with.

That doesn't handle ranges: START_LINE:START_COLUMN to END_LINE:END_COLUMN. For an error messages or grep output it can be useful to not only navigate to a position, but also to high-light a range.

Is this really needed, or is it an overkill? If really needed, don't we need multiple ranges too? E.g. grep can find multiple matches within a row. I'd rather say it's an overkill for now, but the chosen design should be forward compatible with such possible improvements.

Language Server Protocol

Never heard of that; will need to take a closer look.

counts 16-bit characters. I.e. Unicode characters not in the BMP (Basic Multilingual Plane) count 2 as they use a surrogate pair [...] not very semantic and somewhat error-prone

They use a surrogate pair in UTF-16, the most brain-damaged encoding of Unicode, combining the disadvantages of other representation formats (UCS-4 and UTF-8). This encoding should have died out a long time ago. Luckily AFAICT it's mostly used internally by some legacy stuff that originated in the very early days Unicode, like Java. (Or is it still a common thing in Windows?) Especially in the Unix world where data exchange happens primarily in UTF-8, I can't imagine any valid reason for non-BMP to be handled differently from BMP.

I'd say it's a TERRIBLE thing, freaking error-prone, and gets an absolutely "no go" vote from me.

LSP does specify 1 for with TAB and double-wide characters (in the BMP), which I think is a reasonable choice.

Agree. We need to encode logical positions within the text file, rather than visual positions. The editor that opens the file will know the tab width it chooses and will place the cursor in its corresponding visual position, meaning that the indicated column number will probably be quite different, it's its internal business. Tools like gcc -ftabstop=... will need to take care to generate different column numbers for the URL than for the visual column number they print based on their assumption of tab width.

Note it is possible to pick one convention - and allow future extensions.

Future extensions: yes. Future alternatives: no.

If a handler sees #lsp-position but can only handle #position it can convert to the former by adding 1.

(s/former/latter I guess.)

If a handler recognizes the keyword #lsp-position and knows to add 1, then it already supports it (at least to some basic degree), doesn't it? What if it doesn't recognize this keyword at all?

There has to be a minimum base that's commonly used everywhere, and there could go extensions on top of that, that's okay. It's NOT okay to have competing alternatives, i.e. if an emitter may emit either format X or Y, and a consumer might understand only one of X and Y.

@sigalrm

This comment has been minimized.

Show comment
Hide comment
@sigalrm

sigalrm Jun 2, 2018

Hello, TermySequence is my new terminal multiplexer which supports this escape sequence from the initial release. Thanks for doing this specification work.

sigalrm commented Jun 2, 2018

Hello, TermySequence is my new terminal multiplexer which supports this escape sequence from the initial release. Thanks for doing this specification work.

@stuaxo

This comment has been minimized.

Show comment
Hide comment
@stuaxo

stuaxo Jun 4, 2018

This is great, I've been wanting something like this forever.

We need a way that the shell can be aware a hyperlink has been clicked - it would be good if there was an easy way that clicking a directory, bash could cd into it if properly setup.

stuaxo commented Jun 4, 2018

This is great, I've been wanting something like this forever.

We need a way that the shell can be aware a hyperlink has been clicked - it would be good if there was an easy way that clicking a directory, bash could cd into it if properly setup.

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jun 4, 2018

@stuaxo This – or doing anything inside the same terminal, e.g. opening a text-based browser or e-mail client for an http(s) or mailto link – would need an enormous amount of design and work, and is outside of the goals of this project. There would either need to be a separate communication channel between the terminal emulator and the shell solely for the purposes of such new features, or the terminal emulator would need to completely understand what's happening inside (something like iTerm2's shell integration, but probably even more thorough), would need to know whether the shell is sitting idle at the prompt and no partial command has been entered (which probably requires explicit support from the shell), and in that case it could feed the necessary faked keystrokes to type that cd command for you. And then make sure it's free of security issues, and race conditions due to the full duplex asynchronous nature of the communication channel between the shell and the terminal (probably the synthesized cd command would need to be enclosed in special symbols similarly to bracketed paste). It's unlikely for anything like this to happen. Explicit hyperlinks are useful for opening certain resources externally to the current terminal emulator (either in a separate graphical app, or in a newly launched terminal emulator).

Owner

egmontkob commented Jun 4, 2018

@stuaxo This – or doing anything inside the same terminal, e.g. opening a text-based browser or e-mail client for an http(s) or mailto link – would need an enormous amount of design and work, and is outside of the goals of this project. There would either need to be a separate communication channel between the terminal emulator and the shell solely for the purposes of such new features, or the terminal emulator would need to completely understand what's happening inside (something like iTerm2's shell integration, but probably even more thorough), would need to know whether the shell is sitting idle at the prompt and no partial command has been entered (which probably requires explicit support from the shell), and in that case it could feed the necessary faked keystrokes to type that cd command for you. And then make sure it's free of security issues, and race conditions due to the full duplex asynchronous nature of the communication channel between the shell and the terminal (probably the synthesized cd command would need to be enclosed in special symbols similarly to bracketed paste). It's unlikely for anything like this to happen. Explicit hyperlinks are useful for opening certain resources externally to the current terminal emulator (either in a separate graphical app, or in a newly launched terminal emulator).

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jun 4, 2018

@stuaxo Thinking about it a bit more, something along the lines of how bracketed paste technically works could work here too. If a certain mode is enabled then clicked hyperlinks would be sent to the app enclosed between some special marks. (If the mode is disabled, which would be the default, then nothing would be sent.) It would be the shell deciding what to do (e.g. cd if it's a file: URL with the local hostname), rather than the terminal emulator deciding to fake type a cd command. It could even change the directory when the command line is not empty (similarly to e.g. how ^X^V is handled in bash). The shell could even be configured to launch certain apps on clicking some types of URLs – the problem being though that it'd only work whenever the shell doesn't have a foreground job running.

In order to move forward, I guess we'd need buy-in from at least one popular shell, plus ideally a few other (non-shell) use cases in mind as well. I can't really think of the latter kind; non-shell apps probably aren't interested in URLs back in the scrollback, and if a fullscreen app is interested about URLs emitted by itself then it can more easily do its own mouse handling. So I'm still afraid it'd be a marginal feature which may not be worth the efforts.

Owner

egmontkob commented Jun 4, 2018

@stuaxo Thinking about it a bit more, something along the lines of how bracketed paste technically works could work here too. If a certain mode is enabled then clicked hyperlinks would be sent to the app enclosed between some special marks. (If the mode is disabled, which would be the default, then nothing would be sent.) It would be the shell deciding what to do (e.g. cd if it's a file: URL with the local hostname), rather than the terminal emulator deciding to fake type a cd command. It could even change the directory when the command line is not empty (similarly to e.g. how ^X^V is handled in bash). The shell could even be configured to launch certain apps on clicking some types of URLs – the problem being though that it'd only work whenever the shell doesn't have a foreground job running.

In order to move forward, I guess we'd need buy-in from at least one popular shell, plus ideally a few other (non-shell) use cases in mind as well. I can't really think of the latter kind; non-shell apps probably aren't interested in URLs back in the scrollback, and if a fullscreen app is interested about URLs emitted by itself then it can more easily do its own mouse handling. So I'm still afraid it'd be a marginal feature which may not be worth the efforts.

@ssbarnea

This comment has been minimized.

Show comment
Hide comment
@ssbarnea

ssbarnea Jun 5, 2018

@egmontkob See tartley/colorama#134 for adding hyperlink support in colorama, the most popular ANSI python library. Implementing this there will open it to lots of tools. Some support would be needed to get the buy in, I already made a pull request.

PS. I think that it could be very useful for the the "ANSI" cause to have a proper gitlab project (maybe even org) that tracks/documents improvements and support of different extensions on various applications. Using a personal gist does not send the best signal (may give the impression that there is only one supporter behind).

ssbarnea commented Jun 5, 2018

@egmontkob See tartley/colorama#134 for adding hyperlink support in colorama, the most popular ANSI python library. Implementing this there will open it to lots of tools. Some support would be needed to get the buy in, I already made a pull request.

PS. I think that it could be very useful for the the "ANSI" cause to have a proper gitlab project (maybe even org) that tracks/documents improvements and support of different extensions on various applications. Using a personal gist does not send the best signal (may give the impression that there is only one supporter behind).

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jun 5, 2018

@ssbarnea If anyone's willing to create and maintain a documentation of all the terminal emulator extensions out there, it would be highly appreciated. It won't be me.

Owner

egmontkob commented Jun 5, 2018

@ssbarnea If anyone's willing to create and maintain a documentation of all the terminal emulator extensions out there, it would be highly appreciated. It won't be me.

@stuaxo

This comment has been minimized.

Show comment
Hide comment
@stuaxo

stuaxo Jun 5, 2018

@egmontkob maybe it's a matter of getting some shells to understand file:/// for local directories - zsh already can change to a directory if you enter a path without cd

stuaxo commented Jun 5, 2018

@egmontkob maybe it's a matter of getting some shells to understand file:/// for local directories - zsh already can change to a directory if you enter a path without cd

@egmontkob

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Jun 6, 2018

@stuaxo Having to parse a file:/// URI is not the problematic part here at all.

zsh already can change to a directory if you enter a path without cd

bash too. And it's absolutely irrelevant here.

Owner

egmontkob commented Jun 6, 2018

@stuaxo Having to parse a file:/// URI is not the problematic part here at all.

zsh already can change to a directory if you enter a path without cd

bash too. And it's absolutely irrelevant here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment