Comment 14 for bug 1297051

> In an ideal world we would not have to do this because...

I disagree. Such an approach would prevent innovation, at least, there wouldn't be a way to communicate new features towards applications. In an ideal world, you could dynamically query the terminal for features and it would respond in a well-defined (standard but extendable) format. Or at least they'd identify themselves with a hardcoded name and version number (again, using a well-defined format), similarly to browsers' user-agent.

> quirks and limitations of individual emulations e.g. knowing that I have to send ESC[?40h for a width change.

This doesn't sounds like a quirk to me. The fact that xterm does so makes me believe that whichever physical terminal implemented this feature probably implemented it this way and hence this is the standard way to do it. If you omitted \e[?40h it's a bug in your app that you should fix and emit this escape unconditionally for all terminals. I might be wrong though.

Not having a standard response for ENQ, not even a container syntax (e.g. a fixed leading escape sequence and trailing character) makes it pretty braindamaged straight away. It only works if you make up your own arbitrary in-house rules (e.g. terminate by newline), configure all your terminals and change all your apps, something that probably nobody in the world is willing to do except for you. There's no way for an app to know if the response was indeed sent as a response, or (maybe just some of its characters) typed in by the user. Having to configure the terminals is already a wrong approach anyways, it's a thing that should work out of the box without configuring. Having to change all the applications running inside terminals to behave accordingly, maintaining them consistently (and duplicating relevant code in all of them - or are you maintaining your own screen drawing library?) sounds like a nightmare.

There are similar already existing methods for getting the actual terminal version and capabilities - note that all of them suck, but at least they are used widely. There's the TERM variable and the corresponding underlying termcap/terminfo database and common screen libraries (ncurses, slang) using these; there's the \e[c and \e[>c escapes that are recognized more commonly and have a well-defined response syntax+semantics, there's $VTE_VERSION (well, until you log in to a remote host). Plus, you can always just safely use the common subset of escape characters that are understood by all terminals.

Many modern terminal emulators (e.g. konsole, terminology, st) don't support setting an ENQ response either. If you rely on this feature, it sounds to me that you're using a really odd nonstandard way to solve a problem.