How do you change the window title with an escape sequence?

[j4james]

I'm not sure if this is a bug, or I'm just doing something wrong, but I couldn't get the DECSWT (Set Window Title) escape sequence to work, and the xterm OSC 0 and OSC 2 sequences weren't any better. In case it makes any difference, the terminal type I'm using is k95, and I've tried both the GUI and console versions of Kermit (built from master).

I'm testing via a telnet connection into a Linux host, so the title initially starts out as something like "ip.address:port - Kermit 95". From looking at the code, I got the impression that this might be the usertitle, which seems to take precedence over the programmable title, so I figured I might need to clear that first.

So I tried Alt+X, and then SET TITLE, which does seem to clear it (it now only shows "Kermit 95"). But when I press Alt+X to return to the session again, it immediately changes back to the ip address title. If I do SET TITLE some_value, that value does stick around, but that obviously doesn't help, because I still then can't override it with an escape sequence.

[davidrg]

It's a bug! I'm kind of amazed I didn't notice before; I must have been doing all of my testing using the VT320 terminal type when I implemented the various xterm OSCs as it turns out VT320 effectively the only terminal type that was getting OSC support! Glad someone else is poking at K95 or that one might have slipped through.

I've pushed a fix for this so it should be working properly now.

[j4james]

Thank you! It's working for me now. However, when running through some of my DECSWT test cases, I noticed something that looks like it might be a bug. I'm trying to set a UTF-8 title like this (a Cyrillic UTF-8 sequence for ИОІСЕ):

echo -e '\e]21;\xd0\x98\xd0\x9e\xd0\x86\xd0\xa1\xd0\x95\e\\'

But that has no effect on the title. I could understand if perhaps you didn't want to support UTF-8 in titles (although it's worth noting that everyone else allows it, at least with Xterm title sequences). What's weird is that everything but the first character ends up echoed to the screen. So it seems like the first UTF-8 character is being treated as a kind of string terminator, which aborts the sequence.

The other thing I was testing, was to see if I could get other character sets to work in ISO mode. For example, whether this could set a title with DEC special graphics:

echo -e '\e(0\e]21;jklm\e\\\e(B'

Or whether this could set a Cyrillic title:

echo -e '\e.L\e}\e]21;\xB8\xBE\xA6\xC1\xB5\e\\'

In both cases the answer was no (i.e. the first one set the title to ASCII, and the second one to Latin-1). However, I'm not sure whether that's actually expected to work, because VTStar didn't seem to support other character sets either. Have you ever tried anything like this on your VT520? Surely there's got to be some way to set a title with characters outside the Latin-1 range?

[davidrg]

Gave those two a test on the VT520, but there wasn't any character set translation. Plus it seems to clear the 8th bit:

A little bit surprising really - I can't think of a good reason for it to treat the title specially.

As for what K95 is doing... I had to step through in the debugger to figure out. UTF-8 to UCS-2 happens first, then when sees that it is processing an escape sequence it proceeds to process it as ASCII throwing away all but the lower 7 or 8 bits (depending on byte size setting). Doing this to the first character happens to result in CAN. I think this is probably a bug - I'm not sure why you'd expect throwing away all but the lower 8 bits of a UCS-2 character to produce a sensible result. It should in this case perhaps explicitly insert a CAN into the stream to get back to normal mode rather than convert the stream into garbage.

I've added a ticket to deal with DECSWT, etc, specifically as K95 really ought to handle UTF-8 there though there are some details that will make it a bit more complicated to implement than it should be - #556

[j4james]

Plus it seems to clear the 8th bit:

Oh, that actually makes sense now that I think about it. There is a general restriction on the allowed characters in a command string. See STD 070 section 3.5.4: "the command string must be made up of characters in the range 0/8 to 0/13 inclusive and 2/0 to 7/14 inclusive." And while they don't explicitly say that the 8th bit is dropped for command strings, they do mention that in the documentation for ESC sequences and CSI sequences. See for example note "g" on page 3-24.

That said, if the title string is limited to 7-bits, you'd think they'd at least make it take the designated GL character set into account, so you could still map in characters outside the ASCII range. Anyway it's nice to know what the actual limits are on the VT520, so thanks for testing that.

[j4james]

I'm not sure why you'd expect throwing away all but the lower 8 bits of a UCS-2 character to produce a sensible result.

I'm wondering now whether this is just another application of the 7-bit rule mentioned above. But while that works reasonably for 8-bit character sets, because dropping the 8th bit will never change a printable character into a control character, the same can't be said for Unicode.

So if you want to be strictly VT520 compatible, it might make sense to stick to 7-bit truncation when in ISO-2022 mode, but when UTF-8 is enabled, it seems reasonable to allow all characters to be used (which is what most modern terminals support).

[davidrg]

Yeah, I think the real bug there is not that its truncating the characters - that code at least makes sense now. Its that its not taking utf-8 mode into account when it does it. Probably worth checking what xterm does, but I expect its safe enough to let unicode characters go into an OSC or DCS string, and for anything else just cancel the escape sequence as a unicode character isn't going to get consumed anyway.

[j4james]

One other thing I just remembered, despite the 7-bit rule in chapter 3, the ReGIS chapter says that the "legal character codes are 2/0 through 7/15, and 10/0 through 15/15" for quoted strings in the general grammar (see section 8.4.3.2). So it seems like there might be a bit of leniency in that rule. I couldn't get 8-bit characters to work using the VT240 ReGIS implementation, but maybe the VT340 supports it.

And I don't think I made this clear earlier, but VTStar does allow 8-bit characters to be used in the DECSWT sequence. It just doesn't support character set designations, so it only handles characters in the Latin-1 range. That's at least a step up from the ASCII range of the VT520 though. Next time you're running DECterm, you may want to give this a try there too.