Skip to content

Instantly share code, notes, and snippets.

@egmontkob
Last active March 26, 2024 01:51
Show Gist options
  • Save egmontkob/eb114294efbcd5adb1944c9f3cb5feda to your computer and use it in GitHub Desktop.
Save egmontkob/eb114294efbcd5adb1944c9f3cb5feda to your computer and use it in GitHub Desktop.
Hyperlinks in Terminal Emulators
@sje30
Copy link

sje30 commented May 3, 2022

Emacs 28.1 now supports these hyperlinks, see the following extract from the NEWS file:

*** Support for OSC escape sequences.
Adding the new function 'comint-osc-process-output' to
'comint-output-filter-functions' enables the interpretation of OSC
("Operating System Command") escape sequences in comint buffers.  By
default, only OSC 8, for hyperlinks, and OSC 7, for directory
tracking, are acted upon.  Adding more entries to
'comint-osc-handlers' allows a customized treatment of further escape
sequences.

e.g. the following setting will help create hyperlinks in shells.

(add-to-list 'comint-output-filter-functions 'comint-osc-process-output)

@bvtthead
Copy link

Working on a patch for suckless's st to support OSC 8 over at st-osc-8

@logrusorgru
Copy link

This misfeature should be dropped. And this proposal, to drop it, is also a contributing. @egmontkob, just spams all terminals developers, and removes all constructive critics. Good job.

@lypanov
Copy link

lypanov commented Sep 3, 2022

On a more productive note I've used the OSC 8 spec to create an e-ink environment for reading e-mail / RSS / Mastodon to force myself to do so on a weekly vs daily basis. This based around a custom fork of alot (a Python email client) to deal with OSC 8 output of mailcap entries, a wrapper around elinks which can transform it's hyperlink output into OSC 8, and a custom terminal emulator running over VNC (which runs well on my Boox eink reader) which supports OSC 8 (built upon the awesome mtm). Hyperlinks are navigated to via keyboard shortcuts vs mouse (in my case they are multiplexed to multiple services via a xdg-open replacement, they go to either Pinboard, or YouTube Watch Later). As per usual, I really should open source all of this. But I'm time limited and never happy with my code.

@egmontkob
Copy link
Author

I've removed most of the messages from a counterproductive conversation (and will also remove followup messages, if any).

In case anyone is interested, I've made web.archive.org crawl the page before every deletion (and will do so in case of followup messages, too), so everything is still available there.

@i30817
Copy link

i30817 commented Sep 9, 2022

I suppose there isn't a way to hover without actually allowing the 'opening' of a file? Ie if i wanted to replace a missing file 'string' by a smaller text and a normal hover text without actually allowing the 'opening' of that file but still allowing the 'copy'?

Guess i just have to explain in the message that the files don't exist so don't bother clicking, just right click and copy 'address'?

@ppwwyyxx
Copy link

ppwwyyxx commented Nov 12, 2022

I think there is a lot of value in keeping the list of supported apps/terminals maintained and it would also help the adoption. @egmontkob If you are not maintaining this gist anymore, could you set up a repo instead and share maintenance permission to others? I for one am interested in helping out.

FWIW, alacritty, kitty and konsole all support this now. For tmux, I'm using my fork here

@koconder
Copy link

koconder commented Nov 12, 2022 via email

@egmontkob
Copy link
Author

@ppwwyyxx @koconder

I deliberately stopped working on terminal emulators 2+ years ago. I do not wish to return, and do not wish to take on any additional responsibility related to this former hobby of mine, no matter how small it would be, such as maintaining permissions on a repo, filtering out spam, unkind messages, whatnot.

The best I can do is: If there is one (1) page whose owner promises to keep it updated for years going, with or without inviting others to co-maintain I don't care, whether it's a gist or repo or google docs or static webpage or what else I don't care, then I'm happy to add a link to that page from this gist.

Should I need to update that link more than about once a year, or should I ever see a debate about which competing page that link should point to (or I should point to multiple ones), I'll remove the link for good.

This is the most I'm offering to do. Does this sound fair enough? Thanks a lot!

@Alhadis
Copy link

Alhadis commented Nov 12, 2022

@egmontkob I've forked this Gist to Alhadis/OSC8-Adoption. Anybody who wishes to help collaborate need only ask for write access. 👍

@Alhadis
Copy link

Alhadis commented Nov 12, 2022

@egmontkob Is this Gist released under any particular license? Just asking so I know what license to add to OSC8-Adoption.

@ssbarnea
Copy link

ssbarnea commented Nov 12, 2022

Folks, it was an older wish of mine to create a github org that would promote standardization of various practices, terminal stuff being one of the first areas I was interested about.

I created https://github.com/stdize/terminals and I can invite everyone interested to it so we can work on this. I think this would be a more future proof way developing this, so it would not depend on a single person. Anyone interested? I already invited those that mentioned being interested about keeping it updated.

@ZanderBrown
Copy link

@lmorg
Copy link

lmorg commented Nov 13, 2022

myself and others said right from the outset that this project was a terrible endeavour because it didn’t take any security concerns into consideration and it was just hosted on one persons Gist meaning there was no community collaboration…and guess what, this guy gets bored and tells people, in the nicest possible way, to get lost while also deleting all the comments from other contributors.

As someone who is also actively part of the open source movement, this is absolutely how not to work with the community. What a shit show.

now if people really want to push this change through, can we at least follow some proper due process and not leave this as a dictatorship for one guys hobby project. Given we are requesting a change to the default behaviour for possibly millions of terminal users, let’s be sure we do this the correct way.

@ppwwyyxx
Copy link

Given the adoption and users who found this useful, it does seem very valuable to me to push it through. I don't know what happened in the past but it shouldn't stop us from doing this in a way more people find appropriate, especially given that the original author deliberately stop involving. Maybe the process in the past didn't make everyone happy, but what we're doing is to start a new process, and the first step is to have a repo where discussions can happen.

I currently co-maintain https://github.com/Alhadis/OSC8-Adoption. If anyone have suggestions on the process or the technical details feel free to comment there. I promise to not delete comments and assume other maintainers share the same opinion.

@egmontkob
Copy link
Author

@lmorg

myself and others said right from the outset that this project was a terrible endeavour because it didn’t take any security concerns into consideration

For the thousandth time...

Myself and others have explained many-many times that we did not design hyperlinking. The World Wide Web with its core feature, hyperlinking, had been out there for ~35 years when it was adapted to terminals. Prior to that, it had been successfully adapted to quite a few other places, such as emails, PDF, document processors, spreadsheets, markdown etc.

All we did was we took the very same concept and translated it from the language of HTML, PDF, DOC, XLS, ODT, MD... to the language of terminal escape sequences.

Therefore we clearly knew that we wouldn't open up any possible security or privacy holes that aren't present in those, many magnitudes larger areas.

Surely, phishing attacks, social engineering etc. do exist out there. Something that is doable by tricking someone to perform a series of steps, involving let's say an email or a HTML page or a PDF document with a misleading link, is now also possible via a terminal emulator instead of an email, HTML, PDF, whatever. Considering the relative market share of these, we've enlarged a hole about maybe by one millionth of its size. This is just one of the holes out of several ones that an attacker has to use, and is not the hole where any of those other software components try to stop the attacker.

If you are afraid that you're going to fall victim of such an attack, be it in a terminal or not, your best bet is to disconnect from the network, or rather, stop using computers altogether. OSC 8 does not change anything here.

Anyone who claims that OSC 8 has security problems is clearly unaware of how web security works.

Anyone who claims that OSC 8 has security problems AND that the designers of the feature didn't consider it is clearly unaware of how web security works AND is utterly disrespectful and rude against the designers with this obviously faulty assumption.

and it was just hosted on one persons Gist

Which is exactly one Gist more than the vast majority of terminal emulator features has.

meaning there was no community collaboration…

If you expect the feature to be designed as a community collaboration in the very page that documents the feature, I hope you can see that we have a chicken and egg problem.

The feature was designed in some terminal emulators' public issue trackers. Anyone super-duper interested in keeping an eye on terminal emulation improvements would have surely found that and could have joined the discussion before we finalized the details. This ship has sailed long ago.

The comments section of the Gist allows the community to discuss this feature; again, this is something that extremely few terminal emulation features have a dedicated place for.

and guess what, this guy gets bored

I'm glad you seem to know that the reason I no longer work on this feature is that I got bored.

It's interesting that it didn't occur to you that there could be a plethora of other reasons. A change in personal life, a change in day job, a change in health, new interests that need time which I'd have to find somewhere, and so on. Or maybe, just very maybe, getting sick and tired of having to deal with toxic people. No, you know it's not any of these, you know it's that I got bored.

I've been contributing to open source in and out for about 25 years now. Yet, it's a brand new concept to me that if I make any contribution, I'm supposed to maintain and support that until the day I die, that I cannot ever say that I used to work on something but I no longer do.

and tells people, in the nicest possible way, to get lost

Some people asked me to set up a place where they can edit the list. I told them that I won't do this, but if they do, I'll add a link from this page (and I made it clear upfront that I don't want to update this link every week or so, or decide which of multiple competing pages to link to etc. - isn't this fair enough??).

while also deleting all the comments from other contributors.

Moderation is not a foreign idea at all from open source. In fact, the tone of your recent comment would have deserved a ban in many open source projects. Unfortunately GitHub Gist doesn't let me do that.

As someone who is also actively part of the open source movement, this is absolutely how not to work with the community. What a shit show.

So, to summarize:

I volunteer a lot of time to co-design, implement, and document a feature.

I go above and beyond basic expectations to document this feature, whereas the existing precedence would have just been to let people figure out from the first implementation's bugtracker or from a brief readme. I even explain the security considerations.

Unlike the existing practice, I do it all in a place where users are allowed to comment. I do my best in addressing those comments.

Unlike the existing practice, I do maintain a list of supported apps. I do my best in keeping that list up to date for years.

Some people raise security concerns, all of which are answered and clearly proved wrong, although some result in me amending the Security chapter of the gist. In particular, on Mar 26, 2019 you say that you "really like" those changes.

In response to the frequently reoccurring vague waving of the security flag without any concrete details, me and some other contributors keep asking why people think the security aspect of hyperlinks in terminals is any different than hyperlinks anywhere else. No answer yet.

Mean comments begin to appear. I start moderating them. Again, beyond expectations, I do this in a way that those comments are still retrievable publicly, I tell where.

At one point I decide, for reasons that are none of your business, to discontinue maintaining the page (in fact, to discontinue working on terminals altogether). Instead of silently disappearing, I do make a note about it at the top.

Some folks reach out to me asking to set up a place where they can edit the list of supporting software (something that arguably should have never been part of this document). I tell them that I won't set up one, but if they do, I'll add a link to it.

Your turn now: You incorrectly and disrespectfully claim that the developers hadn't though about the security aspects despite the obvious opposite from the gist and comments, you have a problem with me moderating hostile comments, you have a problem with me no longer maintaining the page, you have a problem with me having chosen years ago a forum that doesn't allow multiple maintainers (whereas, again, the standard practice which you should compare to is not to create any such page at all), you have a problem with me not wishing to take on an additional task (even though I offer to add a link if someone else does it) [the last few ones summarized: you have a problem with the fact that my life moved on and I no longer wish to do any work with this feature whatsoever – as if I was morally obliged to keep working on this forever], and you call this a "shit show".

now if people really want to push this change through [...] Given we are requesting a change to the default behaviour for possibly millions of terminal users

No idea what change you're talking about. Not that I care.

as a dictatorship for one guys hobby project

The feature was not designed by one guy. It was designed by multiple senior engineers across multiple terminal emulators. And then implemented by many-many other terminal emulators whose developers would have presumably shouted out loud if they agreed to the slightest bit that it carries a security risk.

I happen to be the one who wrote this documentation, maintained it for a while, and took the blame for anything that anyone ever didn't like about the feature. Guys like you make me wish I never wrote this doc, or at least made it at a place where commenting isn't possible.


I'm doing a favor to you. I'm not deleting your comment. I'm leaving it here for everyone to see, to learn from, and if they wish to, to judge whose behavior is the problematic one.

But I'm also asking a favor from you. Get the hell out of here. Do not ever come back and comment here again. You wanna badmouth this project? Fine, absolutely fine. Do it somewhere else.

@egmontkob
Copy link
Author

egmontkob commented Nov 14, 2022

@Alhadis @ppwwyyxx @ssbarnea

You've already sent me two different links. Please come to an unambiguous agreement which one I should add to the gist. Thanks!

@lmorg
Copy link

lmorg commented Nov 14, 2022

Therefore we clearly knew that we wouldn't open up any possible security or privacy holes that aren't present in those, many magnitudes larger areas.

we’ve given examples of where this isn’t the case and what steps need to be included with any hyperlink specs to make it safe. You’ve deleted those comments and claimed because other unrelated systems include the same concept that somehow terminals are magically safe without any forethought.

Which is exactly one Gist more than the vast majority of terminal emulator features has.

as someone who works in this field, I can promise you that statement is not correct.

It's interesting that it didn't occur to you that there could be a plethora of other reasons.

At the end of the day, the reason is irrelevant. It should not be a Gist.

I've been contributing to open source in and out for about 25 years now.

Maybe, but not on anything impactful that requires following due process. Besides, past credentials are irrelevant, the issues I raised was with the management of this project not your past work.

I really wanted to work with you on this but you were nothing but obstructive throughout. Which would be fine if this were a personal project but you were using this Gist to then hound other developers to implement this into their shells and talking about this Gist as if due process had been followed. Which it hadn't.

you have a problem with me moderating hostile comments

you moderated all comments. almost none of them were hostile and even those that were, only turned hostile after you berated them. I'm genuinely a nice guy and very patient with open source maintainers (being one myself I'm very familiar with how terse and/or demanding some people can be). The problem was you dismissed anyone who offered counter discussions without any thought. And that’s where things turned hostile. You were hostile to us.

Again, this would be fine if this were your own hobby project; you do what makes you happy under those circumstances. But you were forcing through changes for the default behaviour of engineers worldwide and refusing to have a discussion about it. At least the others continuing on from you are building working groups (remember where i asked for due process?) whereas you were just accusing anyone who disagrees with you as being hostile. That’s is absolutely how now to work with the open source community.

Moderation is not a foreign idea at all from open source.

silencing objection isn’t a foreign concept either. Doesn’t make it right.

This needs a discussion. You discouraged that.

In fact, the tone of your recent comment would have deserved a ban in many open source projects. Unfortunately GitHub Gist doesn't let me do that.

With the greatest of respect, you seem entirely oblivious about your own tone throughout. People are reacting to the way you’re behaving. Not the other way around. However that all being said, on reflect, you're right that my previous comment was unnecessary.

I happen to be the one who wrote this documentation, maintained it for a while, and took the blame for anything that anyone ever didn't like about the feature. Guys like you make me wish I never wrote this doc, or at least made it at a place where commenting isn't possible.

Like it or not a discussion is necessary. You can slag me off all you want for offering counterarguments but that doesn't make me a bad person. However trying to push through a change in other peoples software without proper discourse absolutely is a bad way to manage open source. So I'm not the villain you're making me out to be. Is it really that bad to have an open dialogue? We're all adults, why can't we communicate like adults?

Anyway, I’ve said my piece and you’ve said yours. Let's draw a line under this and move on. 👍

@stuaxo
Copy link

stuaxo commented Nov 14, 2022

As a spectator; thanks @egmontkob for doing this work, better integration between GUI and Terminal has been needed for a long time, and as you mentioned, this work had already started elsewhere but needed a centralised place (here) for this to happen.

@ssbarnea It looks like the repo @ppwwyyxx co-maintains already has a fair amount of OSC-info https://github.com/Alhadis/OSC8-Adoption

It also looks like the the terminal working group is the best ultimate place for this, though I'll open an issue there first to see what people think.

@lmorg
Copy link

lmorg commented Nov 14, 2022

As a spectator; thanks @egmontkob for doing this work, better integration between GUI and Terminal has been needed for a long time, and as you mentioned, this work had already started elsewhere but needed a centralised place (here) for this to happen.

@ssbarnea It looks like the repo @ppwwyyxx co-maintains already has a fair amount of OSC-info https://github.com/Alhadis/OSC8-Adoption

It also looks like the the terminal working group is the best ultimate place for this, though I'll open an issue there first to see what people think.

Yes please to a working group :)

@PerBothner
Copy link

I think https://www.freedesktop.org/wiki/Specifications/ would be a good home.
Perhaps https://www.freedesktop.org/wiki/Specifications/hyperlinks-in-terminals.
Or https://www.freedesktop.org/wiki/Specifications/terminals/hyperlinks, if the site supports a specification hierarchy.
Someone needs to how get access to freedesktop.org and add this document, though it would probably have to be edited a bit according to freedesktop.org's standards.

I'd avoid https://gitlab.freedesktop.org/terminal-wg. Right now I can't find any of our old discussions, which is really weird. Beyond that, it had some fundmental problems. To start with, it separated specifications into "proposals", "accepted", and "rejected". The first problem is: Accepted by who? The other problem is the link changes depending on whether something is a proposal or accepted, which leads to dead links. There was an assumption that the goal was to reach consensus and then a specification would be accepted. However, that quickly turned out to be impossible: Endless discussions, because people had different goals and understandings. Some people were and are very opinionated - myself included. Discussion of an image protocol dragged on. (There was maybe some slight movement, but very little.) It also lacked leadership: I believe it was started by Gerard Nachman, but he lacked time to guide things or keep the site updated.

I think we may need to accept that there may be multiple competing protocols in an area. It's OK to write a specification that only one terminal implements. It's OK to write a specification that gets succeeded by something better - or is just more popular.

Going forward, I think the SRFI process has been somewhat successful. Anyone is free to propose a specification. Anyone is free to ignore it. A good editor (Arthur Glecker in the case of SRFI) keeps track of the status of specifications, and (as needed) nags people. (One could argue that the main problem with the SRFI process is that it has been too successsful, in the sense of too many specifications. Plus that it is used as an incubator for R7RS-large, which I think is becoming way too big.)

@egmontkob
Copy link
Author

@lmorg

we’ve given examples of where this isn’t the case and what steps need to be included with any hyperlink specs to make it safe

And then I updated the Security section according to your requests, to which you said on Mar 26, 2019 that "I really like the way you've written that. [...] Thank you"

But, you know what. I just realized I made a big mistake. This document should have never talked about security. It doesn't belong here. This document should only state how a certain escape sequence defines a URI for each character cell, and not say a single word about what to do with that information, leaving that up entirely to the implementation.

Teaching programmers how to open a URI (or rather, how to ask another application to open a URI) should not belong to this document. I made the mistake of beginning to go down this rabbit hole whereas it's obviously impossible to gather all the relevant knowledge here, then went further down due to your request, and even though at one point you were satisfied, years later you claim again that I didn't go down that hole deep enough. No, I shouldn't have even started to go down.

You’ve [...] claimed because other unrelated systems include the same concept that somehow terminals are magically safe without any forethought.

No, I claim that terminals are fine exactly because we transferred the very model, unchanged, that is already out there at many other places.

That was the very goal of this project.

And yes, we all know, that model has some shortcoming. Yes, CSRF attacks, phishing, whatnot do exist, we all know.

What I do have a problem with is you seem to claim that, for whatever reasons, terminals are conceptually different, terminals should not have adopted this very same model, but rather came up with something different (if at all), or I don't know.

If you have a problem with hyperlinking per se, if you have a problem with web pages, emails, PDFs, Markdown files etc. being able to contain hyperlinks, because of the possible CSRF, phishing, whatnot attacks that they make possible, then this one here is not the right forum to address that. Talk to the big players, not the tiny ones. Talk to W3C or whoever, tell them what ideas you have to improve the situation. Make the web adopt those, the smaller players (including terminals) will follow, and I am going to thank you.

Or you don't have a problem with these issues on those platforms, only in terminals? Hyperlinks on web pages are fine, hyperlinks in HTML emails are fine, hyperlinks in PDF documents are fine, hyperlinks in Word, Excel documents are fine, hyperlinks in Markdown files are fine, but the exact same hyperlinks in terminals are not?? You believe that, for whatever reason, terminals should enforce some stricter security model than other hyperlink-capable software?? It's utterly ridiculous. And yes, you do see it perfectly that I am not willing to waste my time continuing any discussion in this direction.

The goal of this feature was to adopt an existing, well-known, popular feature, an industry standard if you will, into the world of terminals (and so this is what we exactly did), not to come up with something different.

(Had we come up with something different, I surely hope that terminal emulators would have been heavily opposed to implementing that, and would have looked to adapt the standard way of hyperlinking instead. Or, for example, if this document said that terminal emulators must disable this feature by default, I surely do hope terminal emulators would disregard that.)

and it was just hosted on one persons Gist

Which is exactly one Gist more than the vast majority of terminal emulator features has.

as someone who works in this field, I can promise you that statement is not correct.

Okay, not that anyone cares, but this is probably objectively verifiable by anyone. How many features do terminals have? Depends on what you call a "feature" that makes sense to discuss on its own, but I'd say it's probably at least a hundred. As of 2.5 years ago when I stopped working on terminals, I can now recall 2 of them which had a GitHub Gist set up to talk about. Did I really miss so many more Gists??

It should not be a Gist.

I agree. It should be a static page, summarizing the bare minimum of the final design.

I'm genuinely a nice guy

So am I, believe or not. So where did it go wrong? I guess my level of patience and tolerance against reoccurring BS is much lower than yours.

and refusing to have a discussion about it.

We did discuss these issues, our opinions hardly got closer to each other, I don't think you've understood my arguments, and I refuse to discuss the same ridiculuous idea (namely that hyperlinking in terminals should adhere to stricter rules than hyperlinking anywhere else) over and over and over again.

But implementations are allowed to become stricter. They might present a 10 page long legal disclaimer that you have to accept before following that link. Or refuse to implement this feature, revert if they already did. Or whatever. But this doesn't belong here. Go ahead, raise your concerns at implementations, see what they think about it.

At least the others continuing on from you are building working groups

LOLOLOLOL. You have no idea who the creators of Terminal WG are, do you?

It all started with a private email, 4 years ago on this very day, sent to gnome-terminal's main developer, asking if he had any good idea where to host the specification of a forthcoming feature, having seen that GitHub Gist turned out to be a far-less-than-ideal choice for the hyperlink feature. This conversation eventually evolved to the creation of Terminal WG.

The sender of that email? You've guessed.

Now, unfortunately, it did not go well. Nowadays it's either completely dead, or I just managed to unsubscribe, I don't know. Turned out that inviting dozens of terminal emulator developers to design something together, without any hierarchy and leadership among the guys, is a terrible idea. The comment sections there are an utter disaster even compared to this one here.

That being said, would it be a good platform to host the community effort to track an existing feature's adaption? Maybe.

@lmorg
Copy link

lmorg commented Nov 15, 2022

Okay, not that anyone cares, but this is probably objectively verifiable by anyone. How many features do terminals have? Depends on what you call a "feature" that makes sense to discuss on its own, but I'd say it's probably at least a hundred. As of 2.5 years ago when I stopped working on terminals, I can now recall 2 of them which had a GitHub Gist set up to talk about. Did I really miss so many more Gists??

The ones I’ve come across weren’t hosted on GitHub. Often mailing lists or similarly “old school” tech.

anyways, I think we’ve reached an amicable impasse. I’d like us put this saga behind and hopefully the next time we (virtually) meet it will be far more joyous for both of us :)

good luck with whatever endeavours you’re currently working on

@Alhadis
Copy link

Alhadis commented Dec 19, 2022

@egmontkob Would you mind clarifying the license of this Gist? Currently, OSC8-Adoption lacks a license, and I'd prefer to release it under the terms chosen by the original author.

You've already sent me two different links. Please come to an unambiguous agreement which one I should add to the gist. Thanks!

Sorry, I somehow missed this reply.

I don't think @ssbarnea's org is related to this Gist (and by extension, OSC8-Adoption). It appears to be related to best and common practices, whereas this Gist merely tracks support for a particular feature amongst implementors. Moreover, the link provided by @ssbarnea points to an empty repository, so there's really nothing to come to an agreement over…

@MunifTanjim
Copy link

I just found out Tmux already supports it. It got merged half an year ago. tmux/tmux#3240

Just need to build tmux from source and add this in tmux config:

set -ga terminal-features "*:hyperlinks"

@dustymabe
Copy link

Just need to build tmux from source and...

And to be clear, the only reason you need to build it from source is because there hasn't been a new release yet so major distributions won't have the new feature. Right?

@MunifTanjim
Copy link

MunifTanjim commented Dec 27, 2022

And to be clear, the only reason you need to build it from source is because there hasn't been a new release yet so major distributions won't have the new feature. Right?

Yeah, it's not included in any released version yet. The last release was on 2022-Jun-9. This feature was merged on 2022-Jun-30.

@egmontkob
Copy link
Author

egmontkob commented Dec 30, 2022

@egmontkob Would you mind clarifying the license of this Gist? Currently, OSC8-Adoption lacks a license, and I'd prefer to release it under the terms chosen by the original author.

@Alhadis There's no explicit license. It's just a freaking documentation. Whatever the legal default is. I couldn't care less as long as people play fair (e.g. don't claim that they wrote it from scratch if obviously they didn't) – and if they don't, I don't have any means of enforcing any behavior anyway, regardless of license.

I'm not a lawyer and I'm not familiar with licenses that could be applied to design work, documentation, or list of software. I know open source loves to require everything to have a license. It's almost as if if I upvoted a comment on stackexchange that upvote would require a license :D I know I'm exaggerating, but you get the point. I find this "every piece of work anyone ever does has to have a license" quite ridiculous.

However...

I'd highly appreciate, in fact if you want me to add a link to your page then I insist, that your page doesn't repeat the specification of the feature; rather, it should solely be a list of supported software (as, by the way, the name "OSC8-Adoption" implies).

We've heard a few people claiming that this feature is fundamentally broken and should be revoked. You and your co-maintainer @ppwwyyxx have expressed that you won't delete / moderate any comments, i.e. leave room for these voices. I have no idea how you're planning to maintain that page, what if the specification part would receive changes, or (I don't expect this to happen, but cannot exclude the possibility) you change the specification more or less according to the request of those voices. Whether it's just some subtle wording changes, or fundamental ones that you make to the page, I'm afraid it wouldn't be clear anymore which of these two pages is the authentic one.

Of course it's possible that some day someone will come up with an extension to OSC 8 that will somehow get widespread. It's also possible that someone will come up with an extension that won't become popular. Independently from the popularity, an extension can be a good one or a bad one. However, because I'm not going to keep an eye on the developments, I wouldn't want to link to a page that potentially allows room for any of these to happen, thereby giving my implicit approval to some future change or a takeover of the specs. Whatever change some people might promote in the future should happen without my help, implicit or explicit.

Please turn that page into a list of OSC 8 supporting software, and not more. I'd be happy to link to that, then. For the specification itself, a link pointing to this page would highly be appreciated. If you or anyone else has an idea how to change OSC 8 itself or improve its documentation (apart from tracking its adoption), that should happen elsewhere.

I hope this all makes sense. Thanks for your understanding, and for the work you're putting into this!

Moreover, the link provided by @egmontkob

There must be some misunderstanding (or typo) here, that link wasn't provided by me.

@Alhadis
Copy link

Alhadis commented Jan 31, 2023

There's no explicit license.
[…]
I'd highly appreciate [that] your page doesn't repeat the specification of the feature; rather, it should solely be a list of supported software (as, by the way, the name "OSC8-Adoption" implies).

Right, done. Removing the specification text essentially renders my earlier question moot, as the remaining material constitutes derived and original work. I'm therefore going to license the repository under Creative Commons Zero (the same terms recommended by Wikipedia).

There must be some misunderstanding (or typo) here, that link wasn't provided by me.

You're right, it was a typo. I meant to tag @ssbarnea instead; I'll amend my earlier comment…

@Alhadis
Copy link

Alhadis commented Apr 25, 2023

Nudging @egmontkob.

@egmontkob
Copy link
Author

@Alhadis Apologies, this fell through the cracks. Done. Thanks!

@walles
Copy link

walles commented May 3, 2023

Regarding pagers, terminal hyperlinks are supported by moar since v1.14.0:

https://github.com/walles/moar

@Alhadis
Copy link

Alhadis commented May 6, 2023

@arvenil
Copy link

arvenil commented Jul 18, 2023

Is there any way to detect if terminal supports this feature?

@AnonymouX47
Copy link

AnonymouX47 commented Jul 18, 2023

@arvenil, it's answered in the document.

@alvaromuir
Copy link

alvaromuir commented Aug 1, 2023

for the life of me i can't get this to work when trying to replace a value with JQ.
I wouldv'e thought this was pretty straight forward:
echo '{"link":"\x1b]8;;https://google.com\x1b\\google.com\x1b]8;;\x1b]8;;\x1b\"}' | jq

@jamie-pate
Copy link

jamie-pate commented Sep 6, 2023

Is there any way to detect if terminal supports this feature?

No, and no standard way to disable it, so any program that adds these links ends up spamming escape characters all over your output (edit: if they are not 100% compatible with all forms of escape codes)

]8;id=274247;https://ansible-lint.readthedocs.io/rules/syntax-check/\syntax-check[specific]]8;;\: Invalid options for ansible.builtin.include_role: vars

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#backward-compatibility mentions that any terminal emulator that doesn't parse it correctly should consider this a bug since it doesn't properly follow ECMA-48

@AnonymouX47
Copy link

AnonymouX47 commented Sep 6, 2023

Hey @jamie-pate.

That should be considered a bug on the part of the program (I believe ansible-lint in your case) emitting the sequence, you should report the issue over there.

As Egmont explained, it's the duty of the program emitting the sequence to detect if its output stream is connected to a terminal device before emitting such sequences... The same applies to almost any other terminal control sequence, not just this.

Next time, kindly ask nicely about things you may not be well-informed about. 😃

EDIT: For the record, I saw your previous comment.

@egmontkob
Copy link
Author

Oh, and just for the fun of it (in response to a freshly deleted comment that's archived on web.archive.org)

feels like this whole thing put the horse before the cart

The last time I checked, that's where the horse belongs 😂

@jamie-pate
Copy link

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#backward-compatibility mentions that any terminal emulator that doesn't parse it correctly should consider this a bug since it doesn't properly follow ECMA-48

I was trying to be constructive, but to clarify, I mean that the terminal emulator is faulty if it parses colors and other ECMA-48 codes, but fails to properly deal with ]8

Trying to help people identify where to report the issues with various pieces of infrastructure that this is exposing.. e.g. concourse/concourse#4318

@mintty
Copy link

mintty commented Sep 6, 2023

I mean that the terminal emulator is faulty if it parses colors and other ECMA-48 codes, but fails to properly deal with ]8

Isn't that just what the quoted section is saying?

@jamie-pate
Copy link

jamie-pate commented Sep 6, 2023

I mean that the terminal emulator is faulty if it parses colors and other ECMA-48 codes, but fails to properly deal with ]8

Isn't that just what the quoted section is saying?

I was responding to this comment, which seems to be laying the blame on the emitter (Originating devices as per ECMA-48), not the consumer (Receiving devices as per ECMA-48):

Hey @jamie-pate.

That should be considered a bug on the part of the program (I believe ansible-lint in your case) emitting the sequence, you should report the issue over there.

My conclusion is that according to #backward-compatibility the Receiving device is 100% responsible for implementing the rest of ECMA-48 even if they just wanted fancy color support and implemented it by scanning through the wikipedia article on the subject. Therefore, if you have issues, you should report issues with the Receiving device implementer.

@AnonymouX47
Copy link

@jamie-pate Just to be clear, where exactly did you copy the following from?

]8;id=274247;https://ansible-lint.readthedocs.io/rules/syntax-check/\syntax-check[specific]]8;;\: Invalid options for ansible.builtin.include_role: vars

@jamie-pate
Copy link

jamie-pate commented Sep 6, 2023

The program generating the output is ansible-lint which creates output using the rich python library

The issue shows up when running inside concourse ci

@PerBothner
Copy link

Whether or not concourse-ci renders OSC 8 links as links is optional: nice but not required.
However, it should parse OSC escape sequences and ignore ones it doesn't handle. That is a pretty basic requirement for any kind of modern terminal emulator (or wrapper like screen/tmux) that claims to be more-or-less-xterm-compatible (which almost all do). If concourse-ci only claims to implement a minimal ansi/vt-NNN-style terminal, then ansible-lint/rich should not be emitting any OSC sequences.

@AnonymouX47
Copy link

AnonymouX47 commented Sep 6, 2023

The program generating the output is ansible-lint which creates output using the rich python library

The issue shows up when running inside concourse ci

I see.

Firstly, I believe @PerBothner has given a good reply (possibly with the exception of the last sentence).

In addition... as far as I know, rich does the necessary detection. So, the issue seems to lie on the end of concourse-ci. If concourse-ci "tells" the programs it executes that their output is a terminal device, then it should gracefully behave as one.

@jamie-pate
Copy link

jamie-pate commented Sep 6, 2023

Concourse doesn't advertise any virtual terminal support, but does support 'ANSI' color sequences ^[.... but not ^]8...

Many concourse examples add TERM=xterm-color to the environment, which advertises full support of the spec..

By removing the falsely advertised terminal advertisement from my config prevents the links, but I also lose all color.

@PerBothner
Copy link

If rich sees TERM=xterm-color I think it is reasonable for it to assume it is safe to emit OSC escape sequences, especially the more common ones.

So either fix/enhance concourse to ignore OSC escape sequences (probably not that difficult if it already handles ANSI color sequences). Or change TERM to something closer to what concourse supports, such as TERM=ansi. (I don't know if TERM=ansi will allow colors, but you should be able to find something that works.) And Concourse examples should be fixed to not use TERM=xterm-color as that is too much of a lie.

@jamie-pate
Copy link

jamie-pate commented Sep 6, 2023

I don't know if TERM=ansi will allow colors

Unfortunately, this doesn't seem to be possible.

The issue is that 'supports colors' has been the dominating aspect of terminfo for so long that every library that sniffs for terminal capabilities will only check if it 'supports colors' and then give up if it doesn't. Other Control Function escape sequences have not been on the radar for quite a while for this class of non-interactive program. (edit: see this relevant code from the rich library as an example.) (ncurses-alike libraries will need more capabilities)

I agree the best way forward is that concourse's elm-ansi should be updated. This leaves me currently with the task of stripping unsupported sequences using sed and that is fine.

(edit: Actually, concourse+rich still guesses 'standardcolor' without TERM)

@stuaxo
Copy link

stuaxo commented Sep 7, 2023

Probably worth opening a ticket on concourse ci for osc8 support since it's open source.

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