Is there any specification on this anywhere? I don't think this is an officially supported OSC, right?

Also it's pretty useless if no shell supports it. Is there support in bash/zsh/fish?

No, it's not an official VT100 code. I think the macOS Terminal.app were using it first, but I don't have where I read that to hand.

From the digging I've done on wsl Ubuntu, if you have libvte-2.91-common package installed then your bash / zsh shells should be emitting this escape code as part of the prompt.

As part of testing this patch I've customised my powershell prompt to include it too, and I'm really enjoying that SpawnNewInstance is going to the right directory 😄

Having searched the vte Gnome project, I can see usage of the code in their source:

https://gitlab.gnome.org/GNOME/vte/blob/master/src/osc
https://gitlab.gnome.org/GNOME/vte/blob/master/src/parser-osc.hh#L63
https://gitlab.gnome.org/GNOME/vte/blob/master/src/vteseq.cc#L6423

I haven't found an official "specification" of it beyond that and the discussion in the other links I pasted above.

(I'll fix the linux builds, sorry, only tested on Windows!)

I haven't found an official "specification" of it beyond that and the discussion in the other links I pasted above.

That doesn't really sound like it's something we should just implement and it is likely going to be extremely unreliable. Using libvte-common is absolutely not an option.

So unless we get some shells in on this to discuss this feature and its advantages/disadvantages from their perspective, I don't think it's a great idea.

I'm also missing some feature detection here. The shell needs to be able to query if this escape is supported. It just seems like there's a lot of standardization missing here, I don't think just implementing things and letting everyone else figure out the details is a good idea.

Without a proper specification and constraints around how it should work, this is just going to be extremely messy and make nobody happy.

Understood. I'll see if I can find anything more concrete. Perhaps we'll see what the Windows Terminal guys decide too...

I don't particularly care a ton about the other terminal emulators. We need applications (shells specifically) to support it. And we need to have a clear specification to tell the applications how things are expected to work.

Agreed regarding shell support; my thinking regarding the Windows Terminal guys is that if they do proceed and implement as per microsoft/terminal#3158 then I would guess they will work with the Powershell guys to add support. So that discussion could be worth following.

I would guess they will work with the Powershell guys to add support. So that discussion could be worth following

Yeah, that makes sense. Though it seems absolutely bizarre to me to do this just by "copy-pasting" the work of other terminal emulators rather than trying to at least create a standard across a few terminal emulators.

The closest place to where an issue about specification and standardization could be raised is https://gitlab.freedesktop.org/terminal-wg/specifications as far as I know. That's the only place that attempts to unify multiple terminal emulator projects, though it seems driven mostly by VTE. If you're interested in pushing this issue forward, addressing an issue about the lack of standardization there might be helpful.

@egmontkob might know more about this feature as VTE developer.

This is a de facto standard, something probably not written in stones anywhere, but used by quite a few terminals.

Also it's pretty useless if no shell supports it. Is there support in bash/zsh/fish?

Fish supports it. Bash and zsh can be configured (e.g. via their prompt command) to emit it. The more terminals support it, the more likely a request against bash or zsh to support it out of the box would be accepted.

and it is likely going to be extremely unreliable.

Unreliable in what sense? Even more, why extremely?

Using libvte-common is absolutely not an option.

This is a great point. Here distributions should step up and configure it for every user, every terminal and every shell by default. Until then, you can maybe replicate vte.sh's functionality for Alacritty.

To make it even worse, what we'll need here is to get it sourced for all login and non-login shells. Distributions and mainstream bash developer all refuse to make it possible. See e.g. https://gitlab.gnome.org/GNOME/vte/issues/37 and follow the links from there for detailed discussions.

I'm also missing some feature detection here. The shell needs to be able to query if this escape is supported.

It uses the OSC framework. Just emit it, terminals that don't support it should ignore it. If a terminal doesn't support, nor silently ignores it, that terminal is buggy and should either be quickly fixed, or be ditched by users. (I know that's not how it works... But the way it can reasonably work is that users facing this problem can just disable the OSC 7 feature in their applications.)

Asynchronous feature detection is the most fragile thing one can do in terminal emulation, causing much more harm than good. If there's anything "extremely unreliable" then this is. It is literally impossible to reliably asynchronously query a feature, and literally impossible to do it in a way that cannot potentially cause harm to further operation of whatever you're doing (if the asynchronous response arrives after the timeout elapsed and the issuer has already given up – it will be received by whichever next step reading some input, totally not expecting this "garbage").

Synchronous feature detection would need a revamped terminfo that fixes essential problems with the current one, e.g. solves the problem of forwarding across ssh, versioning etc., solves the reason why many terminals decide to piggyback another one's terminal description (which is bad, but in many aspects still less bad than going with its own description).

Without a proper specification and constraints around how it should work, this is just going to be extremely messy and make nobody happy.

There's no formal specification I'm aware of. It's OSC 7 URI and it works. What else do you need? And I'm pretty sure that in gnome-terminal (and presumably in Terminal.app too) it makes many-many users extremely happy.

rather than trying to at least create a standard across a few terminal emulators.

What do you mean by "standard"? Is several terminals taking the same feature from each other (which is called "de facto standard", if I'm not mistaken) not good enough for you? Do you need a "de jure standard"? There's no way anyone could add it to VT100, ECMA-48 or similar specs that were written decades ago. What is an authority that you would accept as de jure standard? What if I write two sentences in a gist somewhere, would that be good enough?

Would you accept a page on "Terminal WG" as de jure standard? Would it make you guys change your mind, more likely to include this feature? The feature got design and implemented in a few terminasl before Terminal WG was created. If someone makes a note on Terminal WG saying that that's what a few terminals do and let's do so, would that change your mind? If so, go ahead and propose it there – Terminal WG is not an authority above you, it's a collaborative platform for participants just like you.

though it seems driven mostly by VTE

This is not true.

Thanks @egmontkob, that's more information than I would have uncovered with weeks of research 😄

Thanks for the great feedback @egmontkob.

The more terminals support it, the more likely a request against bash or zsh to support it out of the box would be accepted.

There's certainly some chicken and egg problem going on here. So it likely makes sense not to put too much value into missing application support. However it should still be ensured that features are actually desired. But I guess it might have been a bit misguided from me to expect application to request this feature, because it's something that can be directly used by a user too. So a user requesting it (like in this PR) would already show some sort of 'application support'.

Unreliable in what sense? Even more, why extremely?

I'm not entirely sure what my goal was with this statement, but I think the context might have been just a bit confusing. This was mostly about implementing things based on the code of others, rather than following some documentation written on the escape.

It's not unlikely that if terminal emulators implement features from one another instead of some central-ish place, that every modification will be propagated and new modifications might be introduced at every step. This can lead to big variations from implementation to implementation. If all implementations are started from the same basis, only the modifications are an issue, not the propagation of the modifications of others. Changes that are made are also harder to track, since nobody knows who's copying whom.

It uses the OSC framework. Just emit it, terminals that don't support it should ignore it.

I guess with this feature it's not really relevant if the terminal supports it, since it's mostly a "fire and forget" way to inform the terminal emulator about something. Though that only works if nobody else makes their own separate OSC that matches this one, then you'd still need a way to know which terminal supports what. But I guess with this feature it already has sufficient traction for this not to be an issue.

Asynchronous feature detection is the most fragile thing one can do in terminal emulation

This is certainly true and a big cause of headaches.

What do you mean by "standard"? Is several terminals taking the same feature from each other (which is called "de facto standard", if I'm not mistaken) not good enough for you?

Yes exactly. Why it often might be a way things get standardized, I don't think it's a good way. It lacks communication between the involved parties, often is a bit more unclear and gives the 'big guys' way too much leverage to cause headaches for others that have not implemented the non-standard yet (I'm not trying to accuse VTE of anything, but that's how Browsers seem to do features these days unfortunately).

There's no way anyone could add it to VT100, ECMA-48 or similar specs that were written decades ago.

Yeah this is certainly true, but I don't expect most authors of 'modern'-ish terminal emulators require something to be printed in a book to be valid. There's certainly other channels that would suffice, it's mostly about the documentation part rather than the official standardization process.

What if I write two sentences in a gist somewhere, would that be good enough?

That would certainly go a long way already (similar to what you've done for the URL escape I'd assume). That would resolve the issues with trying to implement something by guessing what their code could possibly mean. Though I still think that this doesn't address the issue of giving others a good way to give feedback on something.

Would you accept a page on "Terminal WG" as de jure standard?

That's exactly the kinda thing I am looking for. Which is why I was proposing that we should create an issue about this on the terminal-wg gitlab.

Terminal WG is not an authority above you, it's a collaborative platform for participants just like you.

I think it's definitely a good idea and the right approach, so I'd be all for getting involved in the process there. A good variety of terminal emulators being represented there is an absolute necessity for it to support and I definitely think that we can do our part here (like for this feature for example).

though it seems driven mostly by VTE

I haven't done any research on the origins, but I've been going mostly off of the people I've seen talking around there. Though maybe your general activity has just been misleading in this regard.

I've noticed that the Kitty developer has also been active on there, but I've just gone mostly based on the other users I've seen contribute around there. Though I've thought George Nachman was involved with VTE too, which turns out to be incorrect (he's behind iTerm it seems).

As stated previously though, the concept can't succeed without involvement of a variety of terminal emulator projects and there's no point to complain about it without ever trying to cooperate ourselves. Judgment about too heavy steering from certain projects can be made after there actually has been an issue, instead of assuming the worst from the beginning, it's definitely worth a shot at improving some of the long standing issues.

For reference: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/20.

On macOS, the escape sequences are actually specified in Terminal.app > Preferences... > Profiles > Tab

There has been no interest in standardizing on this escape sequence and the benefits of it are only really visible to me on Windows. Because of that I won't accept this pull request to implement this functionality.

Understood, thanks for the effort you put in attempting to standardize this sequence!