XTGETTCAP replies are encoded in terminfo source format, instead of the compiled format

[craigbarnes]

Sending the query DCS + q 6B6631 ST (XTGETTCAP for kf1) to various terminals seems to produce the following DCS response strings:

• foot: DCS 1 + r 6B6631=1B4F50 ST
• kitty: DCS 1 + r 6B6631=1b4f50 ST
• xterm: DCS 1 + r 6B6631=1B4F50 ST
• ghostty: DCS 1 + r 6B6631=5C454F50 ST

The value in the first 3 of these responses decodes to the compiled terminfo format (ESC O P), whereas the one produced by ghostty appears to be in terminfo source format (\ E O P).

I chose this example query in particular because it works in xterm, but I discovered the inconsistency while looking at logs for dte's XTGETTCAP response handling:

# ghosty
dbg: src/terminal/query.c:126: unhandled XTGETTCAP reply: 1+r74736C=5C455D323B

# foot ("TITLE" is detected via XTGETTCAP/terminfo "tsl" here)
info: src/terminal/input.c:184: detected terminal feature TITLE via query

[mitchellh]

Thanks, this looks legit and easy to fix. We pre-generate all our XTGETTCAP responses at comptime so this should be easy to test and write a fix for. Thanks for the thorough bug report.

cc @rockorager I think you'd be interested (in knowing, not necessarily doing). I'll probably look at fixing this tonight.

[mitchellh]

Okay I'm still wading my way through ncurses source code to figure out what the hell is going on, which has been a fun exercise in tracing through manual text files, awk, and C using global variables. But based on this so far I've also found issues with xterm vs foot (and Ghostty).

XTGETTCAP for kbs

• xterm: 08
• ghostty: 5E48
• foot: 5E48 (with terminfo to match xterm)
• kitty: 48 ??? 🤔

It looks like no terminal except xterm is properly encoding control characters as documented in term(5).

Further, some \E sequences are not encoded, while others are. For example, if you request XTGETTCAP for setrgbf, Ghostty matches foot (xterm doesn't have this cap). It seems that any parameterized caps don't encode the \E but its not entirely clear that's true, I can't corroborate this with the tic source code and when I hexdump the termcap files directly, I see it encoded even for parameterized fields. So I don't know.

I also found that Neovim allows \E (literal) and just handles it directly. I'm not certain if it's because the person who wrote this uses Ghostty, though, I wasn't able to follow the blame trail far enough back.

The xterm docs also say: "Request Termcap/Terminfo String (XTGETTCAP)" emphasis mine. So it seems valid to respond with a terminfo string in addition to a termcap encoded string. Given the above, it looks like some terminals do do this. I admit this is a weak argument but there is evidence this is partially true, I just can't verify it with xterm.

I... don't have a conclusion yet, I'm just dumping the madness this is leading to.

[mitchellh]

Removing the contributor friendly label because this is anything but. I thought this would be a simple escape processing but the logic (possibly) looks... horrifying. The answer might be we need to just run a pre-processing script on the tic output in order to build this at a comptime rather than the simplistic (but elegant :( ) thing we are doing now.

[gpanders]

I also found that Neovim allows \E (literal) and just handles it directly. I'm not certain if it's because the person who wrote this uses Ghostty, though, I wasn't able to follow the blame trail far enough back.

Person who wrote this checking in. This is indeed the reason, specifically when testing with the Ms capability I observed the plain \E. I had no reason to think this was incorrect though (and it looks like it may not be!), so translated it accordingly.

[mitchellh]

From foot's generate-builtin-terminfo.py:

class StringCapability(Capability):
    def __init__(self, name: str, value: str):
       # Expand \E to literal ESC in non-parameterized capabilities
        if '%' not in value:
            # Ensure e.g. \E7 doesn’t get translated to “\0337”, which
            # would be interpreted as octal 337 by the C compiler
            value = re.sub(r'\\E([0-7])', r'\\033" "\1', value)

            # Replace \E with an actual escape
            value = re.sub(r'\\E', r'\\033', value)

            # Don’t escape ‘:’
            value = value.replace('\\:', ':')

        else:
            value = value.replace("\\", "\\\\")
            # # Need to double-escape backslashes. These only occur in
            # # ‘\E\’ combos. Note that \E itself is updated below
            # value = value.replace('\\E\\\\', '\\E\\\\\\\\')

            # # Need to double-escape \E in C string literals
            # value = value.replace('\\E', '\\\\E')


        super().__init__(name, value)

This confirms my suspicion that non-parameterized values are not escaped, and that's where Ghostty matches foot, but I don't know why they do this or how they found this to be the proper behavior. I can't find this documented or mirrored anywhere else yet.

[mitchellh]

@gpanders

Person who wrote this checking in. This is indeed the reason, specifically when testing with the Ms capability I observed the plain \E. I had no reason to think this was incorrect though (and it looks like it may not be!), so translated it accordingly.

Hah. Regardless, it looks like you do need this anyways since see above re: foot and parameterized fields.

[mitchellh]

I've made a PR #1703 that fixes this.

I've decided to fix it only insofar as I can vaguely understand what is going on. The final fix I decided is to:

1. Return the encoded form for any non-parameterized string
2. Encode \E to 0x1B
3. Encode control characters (i.e. ^H) to their byte form (i.e. 0x08).

Note that the third point differs from foot/Kitty but matches xterm. It also matches the more generalized rule that non-parameterized strings are returned in cap encoded form since cap encoded form would process those.

@craigbarnes Please note the third point, since this will be a differing behavior amongst many terminals you may want to be aware of. In situations like this, my stance with Ghostty is always -- in order -- specification, xterm, other terminals. So I've matched xterm here.