GNOME Bugzilla – Bug 734823
support for custom OSC sequences
Last modified: 2021-06-10 14:55:29 UTC
iterm2 has this feature: ^[]50;SetProfile=foobar^G https://code.google.com/p/iterm2/wiki/ProprietaryEscapeCodes (Request originally found here: https://bugs.launchpad.net/terminator/+bug/1289908. As per the comment there, vte would probably need to emit a signal with the new profile name as its parameter.)
OSC 50 is set-font in xterm, so we certainly won't be using the iterm sequence for this. Now as for the feature itself, what's the use case? I just don't see it. Also, what are the security implications of this? (As for the rest of the sequences on that iterm page: AFAIK ReqeustAttention has a sequence in xterm, clipboard selection too, we have the cwd one done right, scrollback clearing should be CSI 3J (bug 678042), focusing has an xterm one, cursor shape as well (bug 720821). Did they do any research before introducing this‽)
There are a couple of use cases for custom escape sequences such as this. For example I currently use Terminology as my terminal emulator and whenever I SSH into certain systems, I use one of its custom escape sequences to set a new background image in the emulator window and back again after logging out. As a matter of fact I was just looking into python-vte for this because it's used in Guake which I'd like to do the same thing with.
vte does not support background images anymore, so that's not relevant here.
Personally I'd like to see this more generically and allow the containing application to receive OSC codes. This feature could take one of two forms, either have VTE pass up to the application any OSC it doesn't recognize or have the application pre-define which OSC cases it is interested in. The one benefit of forcing the app to pre-define the OSC is that VTE could reject codes conflicting with codes known to be used. This would allow app developers to meet specific use cases that may be relevant to them but not others. For example, the profile example here is only relevant to applications that define a profile similar to what gnome terminal does, I'm sure there are many cases where VTE is embedded (Builder maybe?) where the concept of profile is not relevant. For another example, the Fedora notification patch (https://bugzilla.gnome.org/show_bug.cgi?id=711059) which uses OSC 777 could use this mechanism and would not require a patch to VTE if this feature was supported (although obviously gnome-terminal would still need to be patched). Without this feature application developers would have to rely on other IPC mechanisms such as what Pantheon terminal is doing with DBus for notifications. The major problem with IPC is that it doesn't work for SSH whereas the iTerm2 shell integration can be deployed on remote machines to provide a better terminal experience. Without this feature I'll probably be going down the same path with Terminix that Pantheon did, which is implementing some sort of DBus/Pipe IPC solution which IMHO is a lot less optimal then being able to define OSC codes. The iterm2 shell integration documentation covers a lot of the features that they provide based on using escape codes. https://iterm2.com/shell_integration.html
Wow, Terminix's author here. Welcome! :) I agree with your request. Christian, what do you think? If you agree too, it'd be nice to have a separate bug report, or at least change the title of this one. Pantheon's IPC approach is ugly as hell and I'd really dislike to see Terminix take the same path. We'd need to draw a clear line what to expose to the containing app. Would OSC sequences be enough, or would someone require later for us to expose unrecognized CSI, DECSET etc.? Also, terminal emulation should be done in vte as much as possible, instead of delegating to the container. Just wondering... If this feature is implemented, we _could_ remove the standalone window operation (resize, move, iconify etc.) signals (maybe on the next API/ABI breakage) and let them use the said generic infrastructure. The question is: _should_ we? The same applies to the window title, current directory etc., vte no longer has to know about these concepts if it can just forward these to g-t or terminix. What's the right boundary up to which it's vte's job, and from which it's the container app's job to decide what to do? It's unclear to me. E.g. OSC 7 current directory uses URL escaping, it's simpler to unescape once in vte rather than individually in each terminal app. As for iterm's shell integration: It does a whole lot of other things (e.g. with marking the prompts) that couldn't be done purely in the container app. See bug 403130 why your request is not trivial to implement; needs quite a bit of refactoring to our current matcher. > [...] This feature could take one of two forms, > either have VTE pass up to the application any OSC it doesn't recognize or > have the application pre-define which OSC cases it is interested in. The one > benefit of forcing the app to pre-define the OSC is that VTE could reject > codes conflicting with codes known to be used. I guess you mean it could reject conflicting codes when they are defined, rather than when they are encountered. And what would the container app do when it sees that vte rejects such a definition? It looks like a coding error which shouldn't be reported to the user. Hence, I don't see any fundamental difference between the two approaches and don't have a preference right now. I don't even have an opinion right now whether the container app should define callbacks for each separate OSC number, or one generic.
(In reply to Egmont Koblinger from comment #5) > Wow, Terminix's author here. Welcome! :) Thanks, really appreciate all the effort Christian, yourself and others have put into VTE. > Just wondering... If this feature is implemented, we _could_ remove the > standalone window operation (resize, move, iconify etc.) signals (maybe on > the next API/ABI breakage) and let them use the said generic infrastructure. > The question is: _should_ we? The same applies to the window title, current > directory etc., vte no longer has to know about these concepts if it can > just forward these to g-t or terminix. What's the right boundary up to which > it's vte's job, and from which it's the container app's job to decide what > to do? It's unclear to me. E.g. OSC 7 current directory uses URL escaping, > it's simpler to unescape once in vte rather than individually in each > terminal app. My two cents is that there are core features that VTE should provide, I would think title and current directory reasonably fall into that bucket. I don't think it would be a good idea to go full generic. > > [...] This feature could take one of two forms, > > either have VTE pass up to the application any OSC it doesn't recognize or > > have the application pre-define which OSC cases it is interested in. The one > > benefit of forcing the app to pre-define the OSC is that VTE could reject > > codes conflicting with codes known to be used. > > I guess you mean it could reject conflicting codes when they are defined, > rather than when they are encountered. And what would the container app do > when it sees that vte rejects such a definition? It looks like a coding > error which shouldn't be reported to the user. Hence, I don't see any > fundamental difference between the two approaches and don't have a > preference right now. My thinking would be if the container tries to define a code that VTE knows is commonly used that it should ignore it and emit a warning/error on stderr similar to what GTK does. The idea is to put a little bit of a fence around this to prevent app developers like me, who don't have the same broad low level terminal knowledge you guys do,from doing something stupid. It also gives a hint to the developer why the OSC code he picked isn't working. Having said that, I'm not fussed either way. > I don't even have an opinion right now whether the container app should > define callbacks for each separate OSC number, or one generic. I'd prefer a generic signal personally.
(In reply to Egmont Koblinger from comment #5) > See bug 403130 why your request is not trivial to implement; needs quite a > bit of refactoring to our current matcher. I ws thinking about this some more, does the state machine to fix 403130 really need to be implemented in order to support this? Looking at the Fedora patch for OSC 777 notifications, to my very newbie look it appears it was able to achieve this with relatively little code change in VTE. If we go with the model of the container/app specifying the OSC codes it was interested in, wouldn't it just be matter of firing off an event when that a specified code is encountered without having to worry about the overall state context? I'll freely admit this might be a naive view but I'm very interested in this feature, I'm worried that predicating it on bug 403130 is going to mean this feature will not see the light of day anytime soon.
In Fedora's patch the unique prefix "OSC 777" is known in advance, hence it's simple to hook up their new code to this escape sequence. The matcher table is built up once when a VTE widget is constructed, based on the static entries defined in caps.c. There's no way to modify it (add/remove entries) later on dynamically, based on API calls or whatever. So no, the change wouldn't be as simple as you're hoping for.
(In reply to Egmont Koblinger from comment #8) > The matcher table is built up once when a VTE widget is constructed, based > on the static entries defined in caps.c. There's no way to modify it > (add/remove entries) later on dynamically, based on API calls or whatever. > > So no, the change wouldn't be as simple as you're hoping for. Makes sense but how about adding a few (like 2 to 3) hard-coded OSC sequences to caps.c that are not in use as "application defined data" and expose the data passed via the OSC with a signal to the application. If you look at iTerm, they use OSC 50 and then simply use that one OSC to pass a variety of information back using a key=value type combination. Sorry if I'm being a pest about this, it's just that this capability would open up a lot of options for those of us writing terminal apps based on VTE.
(In reply to Gerald Nunn from comment #9) > Makes sense but how about adding a few (like 2 to 3) Why not 1, then? :) I'm really not against the entire idea, but wouldn't want to rush for something not well-designed either. (E.g. I wouldn't want to design the feature around ease of implementation as a goal. If a nice design required refactoring VTE's code vs. an ugly design could be implemented quickly, I'd vote for the first.) So, some questions... Is 1 prefix really enough? Can we go for 777 (as urxvt)? Will it be compatible with urxvt's design? Will it be compatible with Fedora's notification patch? Should we pass the entire string to the terminal application literally and let it split at semicolons etc., or should vte do some basic parsing and send a more structured data (e.g. key-value pairs) to the terminal app? How can we be sure that terminal emulators built around VTE won't conflict in the future (interpret the same field differently)? Just hope for the best? Christian, any opinion here?
(In reply to Egmont Koblinger from comment #10) > Why not 1, then? :) At this point I would be happy with 1, just 2 or 3 might add some flexibility > I'm really not against the entire idea, but wouldn't want to rush for > something not well-designed either. (E.g. I wouldn't want to design the > feature around ease of implementation as a goal. If a nice design required > refactoring VTE's code vs. an ugly design could be implemented quickly, I'd > vote for the first.) Please don't take this as an insult, but as friend used to say "Delivery is a feature". Bug 403130 which you originally pointed to indicate the complexity of the issue was opened in 2007 and is still open. I say don't take it as an insult because I fully understand that fixing that bug requires a lot of work and people are working on a volunteer basis so it depends on resources. Would I prefer a well thought solution that leverages a shiny new state machine, absolutely, but sometimes you make comprises in order to deliver something rather then nothing. You have to weigh the benefits of delivering the feature versus the negatives of delivering the feature sub-optimally. In this case I feel like the pros outweigh the cons. > Is 1 prefix really enough? Well I did suggest a few :), however even one would be enough using some variation of the way iTerm2 is using OSC 50. > Can we go for 777 (as urxvt)? Will it be compatible with urxvt's design? > Will it be compatible with Fedora's notification patch? I would suggest if this were to happen Fedora should re-work the patch, if necessary, to leverage this feature. > Should we pass the entire string to the terminal application literally and > let it split at semicolons etc., or should vte do some basic parsing and > send a more structured data (e.g. key-value pairs) to the terminal app? I'd prefer passing the entire string for maximum flexibility personally. > How can we be sure that terminal emulators built around VTE won't conflict > in the future (interpret the same field differently)? Just hope for the best? We already have terminals conflicting on OSC codes, as Christian as pointed out iTerm using OSC 50 versus xterm, I would hope apps would be smart enough to only deal with responses they are interested in and ignore others. For example, if I were to use iterm's key value pair style, I'd prefix the key with an app specific constant like "terminix.". Maybe that concept could be baked into this feature somehow by requiring a specific data format with a string indicating the app it is intended for.
An important remark: If we're going for the totally generic approach, it's important that right after (and perhaps even right before) encountering such an escape sequence, we need to break out of the process_incoming() loop and let all the pending actions take effect. E.g. 1. If an application prints this in a single run: OSC vte-custom whatever \a OSC 4 get color \a and the vte-custom operation changes the profile, the get color operation must report the new color. E.g. 2. If an application prints OSC 0 set new window title \a OSC vte-custom whatever \a and the custom handler happens to query the window title, it must receive the newly set one. And so on... Probably there'll be troubles when vte-custom triggers an encoding change (see bug 731208) or a font change (see bug 731137), but we should aim for the best.
Christian I'm very interested in implementing this feature in Terminix and I would be happy to volunteer to implement this feature in VTE. As I've outlined here, the idea would be to implement this tactically for now via hard-code OSC code(s) with a view to support it more strategically when broader work, such as the state engine, is undertaken. I expect this would follow the style of the Fedora Notifications patch (https://bugzilla.gnome.org/show_bug.cgi?id=711059), however rather then wiring the OSC code specifically for notifications it would be done as a generic capability/signal allowing application defined data data via the OSC code(s). Fedora could leverage this capability for notifications and thus would remove the need for a separate patch for that. I will be upfront and say I'm not a C developer but I have the time and willingness to put in the effort assuming there is a reasonable chance the patch would be accepted with the obvious caveat it meets quality requirements. If you think it's a non-starter I'd appreciate knowing that as well so I can look at what my alternatives are. If you want additional information, for example a design treatment, I'd be willing to do that as well.
Alright, let's repurpose this bug for 'custom OSC sequences'. As Egmont already noted in comment 5, due to the way our parser currently works, we can't add API to define arbitrary new OSC codes, so if we do add something here, it'll just be one/a few. At the same time, I don't like the approach the OSC 777 patch does by providing essentially a free-form sequence. Parsing arguments correctly is hard, and we should make our API easy to use correctly and safely. Security is a concern too, since apart from correct parsing, API users need to e.g. do rate limiting, and not reply strings back to the terminal that came from the terminal (à la CVE-2003-0070). Apart from the problems that comment 12 mentions, a callback or signal dispatched directly from the parser would mean that we would always have to have the parser in the main thread (as opposed to in a specific thread, or even OOP). So I don't like that approach either. What would work, I think, is the OSC Number ; Key=Value [; Key=Value] ST approach. The API can register the expected Key values, the parser can keep track of changes as they occur, and emit changes later at the same time as emit_pending_changes(). However, in general I think most features should be implemented inside vte directly. Comment 1 shows that "change profile" is the exception here rather than the norm.
Thanks for the feedback chpe, I'm happy to volunteer my time to implement this following the direction you have provided, I don't have much experience with C or the Linux C tool chain but I'm happy to learn considering how much this will benefit Terminix. One question though, should the notification system proposed in 711059 be implemented using this mechanism?
I think this should stand independent of bug 711059.
Is there still interest in this?
I would still be interested and would implement it in Tilix if available in vte.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2125.