@boon Thanks for your responses! Some go quite beyond the original topic, but I don't mind having an interesting discussion.


> Let me say up front ... if it doesn't support ISO-8859-1 any more then it aint a terminal emulator!! So you would need to update the man page. ;-)

Updating the man page will be the least of our worries... since we don't have one :-) (Some distros ship one, but that's a downstream decision.)

I've recently come across the opinion that Xterm, VTE and alike are _not_ "terminal emulators". A "terminal emulator" would need to set up an infrastructure on which the original DEC software runs, just like, let's say, ZX Spectrum or Commodore emulators, or (sort of) VMware work. Instead, analogously to WINE (Wine Is Not an Emulator), these are "terminals", more specifically "software terminals" rather than those old "hardware terminals". But not "emulators".

Terminology put aside... [well, not quite, (pun intended) there's a "software terminal" called Terminology which the next paragraph happens to apply to.]

There are many-many new players in the world of terminal emul... I mean software terminals. And surprisingly many of them don't support anything other than UTF-8. Which, in my opinion, is a welcomed decision.

The world is changing. Maybe some see a beauty in maintaining faithful compatibility with some old hardware (now 30-45-ish year old), I see a beauty in making progress, and switching to Unicode is definitely one. Maybe there's a software terminal that will maintain DEC VT102 or whatever compatibility for hundreds or thousands of years, VTE is not that.

And by dropping non-UTF-8 support, VTE will definitely remain a software terminal. Or as people tend to (perhaps incorrectly) call it, a terminal emulator.


> As to whether I would be screwed ... there are two answers to that
> 
> a) I can change the application [...]
> 
> b) What I can't change is software on which the application depends [...]

But does (b) emit C1 controls? Because if not then you should change your application; in fact, you should have done it 9.5 years ago when you filed this bugreport. If yes then I see your problem.


> Also, I hope that any such change would be flagged **well in advance**.

I'm not sure how exactly you wish to see such a flagging. The corresponding 'vte_terminal_set_encoding()' method has been marked as deprecated for 5 years now, it this good enough? Most likely the story will continue by the removal of the Preferences UI's Encoding dropdown box, while keeping the under-the-hood setting available in dconf for another few years. Consider that you have been warned well in advance. :)


> Another consideration is ... what terminal model the emulator "advertises" compatibility with

Advertising compatibility is a terrible mess.

Nowadays the primary source is the TERM variable, which is so limited in functionality that VTE has to choose between two bad solutions: piggyback xterm, or go its own route. A good system would allow the terminal itself to define its capabilities, not some 3rd party database (terminfo) maintained independenty, with potentially years of difference between the actual software and the description (and not being a way to version-match the two), potentially even a decade or more difference when ssh'ing. A good system would communicate the features across ssh on the spot, so that the remote server sees them fully accurately. A good system would be extendible with custom new features. If I implement a brand new feature, whatever it is, I'd like every user to know about it immediately, not years and years later. A good system would make all this information available to applications synchronously, because having to query the terminal and wait for its asynchronous answer has a lot of inherent problems. Via the TERM variable VTE lies that it's "xterm-256color", not because it's true, but because this is what we found to work the best in practice with existing apps.

And then there are escape sequences, such as DA1 which I believe originated from DEC hardware terminals, asking the terminal what DEC features it supports, to which VTE responds with something. Again, not because it wants to claim it's a fully faithful DEC, but because this seems to work the best in practice with existing apps.

Interestingly, just the other day I was working on a set of features for VTE (left/right margins, horizontal scrolling and such, while also revamping the top/bottom margin and vertical scrolling code). With the help of a kind contributor it turned out that actual DEC hardware terminals work notably differently from their documentation, and Xterm (which VTE usually takes as the reference) follows the documentation. Now what? That contributor's opinion was that I should follow the actual DEC hardware as reference. Given that hardly anyone has access to such a machine to verify the behavior, I surely don't, other software terminal developers probably don't either, I disregarded his suggestion and mostly followed the DEC documentation and Xterm. So then what model should we advertise ourselves as??

I wish feature reporting was solved properly in the world of terminals, but it's not. We set the environment variable VTE_VERSION, you're free to set up ssh to forward this variable, thereby we advertise ourselves as VTE, we also advertise as being (mostly) xterm-compatible, and also to some extent DEC-something-compatible, is this good enough? :)


> In reality, terminal emulators have traditionally taken a more laissez faire approach of just supporting whatever features they want to support. ;-)

Exactly.

VTE is presumably used (at least occasionally) by tens of millions of users, the vast majority of them on modern computers. They are by far the primary target audience. Every once in a while some ancient obsolete features that are hardly used by anyone are dropped to make the code simpler, cleaner, smaller, faster, and allow the developers to focus on new features with fewer hassles, increased productivity.

Unicode and UTF-8 have been around for 30 years+, as a **bugfix** for the former utter confusion: not being able to fully express what you wanted in a multi-lingual environment, and glyphs often being displayed wrongly (replaced by another glyph). Linux systems switched to using UTF-8 by default about 15-20+ years ago (Red Hat: 2000, Debian: 2007, the tiny little national Linux distribution with only a handful of developers, one of which I was at that time: 2005).

Let this concept sink in: We are talking about a former **bug** (a serious design bug) that has been fixed for about 15 years now. Not in your system, unfortunately you can't fix or replace that. And you expect your terminal to keep a workaround for that bug around practically forever. This might not happen. 

I'm happy if you choose to keep using VTE for as long as you can, maybe even by adding a compatibility layer in between if needed, but I can't promise to keep non-UTF-8 support around for you. You've been warned now, you probably won't receive another warning, it'll just be gone one day. I can't tell if it'll be today or 10 years from now, it's not my decision. (About 5 years ago VTE's main developer wanted to drop support for non-UTF-8, I convinced him to keep it for a while because it might still be in use. Nowadays I'm saying that I believe it's time we can drop it, and he seems to wish to keep that code around for another while. :)) If you want as faithful DEC emulation as possible, probably Xterm is your best bet in the long run.

I'm wondering if this all makes some sense to you...