Rename `vt.h` to `terminal.h`

[Dragorn421]

The special character sequences allowing the game (and modern software) to print stuff to the console with colors, are called ANSI escape codes (from Wikipedia, introduced in the 1970s)

Still from Wikipedia, in 1978 the VT100 terminal (picture below by Jason Scott) was introduced, it supported ANSI codes and its massive popularity popularized ANSI codes.

Fast forward to early 2020, a bunch of cool people continue to work on the decompilation of Ocarina of Time 64.

@Random06457 wants to introduce color codes, since OoT mq debug uses those in osSyncPrintf calls that originally went to the IS64 / IS-viewer (not sure what the actual name is), a development peripheral for the N64 to look at logs printed by the game.

@MNGoldenEagle suggests VT, from the name of similar products as the VT100 mentioned above.

(source: screenshot shared by Random, zeldaret discord, #oot-decomp, 02/02/2022 (nice date), https://discord.com/channels/688807550715560050/688851317593997489/938533598951260162 )

And probably since everything in that file at the time was VT_-prefixed the file was simply named vt.h.

Happy end!

... or so everyone thought

It lasted until @Thar0 decided in #1144 to add BEL, the ASCII BEL character which, when printed, makes a sound play. (for example on windows/in wsl, it makes the commonly heard "windows can't do that" sound)

vt.h is a good home for BEL, as that file was dedicated to defines for stuff going to a terminal anyway (basically used by osSyncPrintfs)

But it meant that vt.h had now grown bigger than the ANSI escape codes the VT100 and such were among the first to implement, and it was inevitable some dude would come over and decide the name had to evolve by now.

I hope all the defines find their new terminal.h home cozy

---

vt.h -> terminal.h since

• it also has the BEL character define which is ASCII and not an ANSI escape code which VT refers to
• arguably "VT" refers more to the "brand" than standing for "Video Terminal" (which is more of a outdated term anyway imo)

Also VT_ -> TE_ as in "TErminal", for similar reasons

[Dragorn421]

VT_ isn't any more specific than T_ as a prefix and I think the only reason to be attached to it is being used to it, I don't see T_ conflicting with anything more than VT_, T_ relies on context to be understood (being inside osSyncPrintf) just as much as VT_

I did expect resistance to changing VT_ to T_, and I would be ok (but sad because: see PR description and above comment) to keep VT_, but I want to make sure it's not just conservatism

[fig02]

I am not attached to VT at all, but I can understand just T_ being a little off putting. Idk if its just an aesthetic thing, but just the single letter feels very strange, vs the two letters which makes it a bit more "identifiable" as an acronym.

That said, I would get used to it fast and dont really mind. But I can understand the hesitancy

[mzxrules]

It's not just an aesthetic thing. Assuming we limit domain names to the characters A-Z 0-9, each letter we drop increases the chance of a name conflict at the domain level by a factor of x36. With VT, there is a 1 in 936 chance of a domain conflict, whereas with T it's just one in 26, since leading with 0-9 isn't valid. Whatever we assign to T, it needs to be pretty universal since we only have one T to work with.

Personally I've used T to represent type (specifically when in the decomp phase of this project), and I imagine T = Type is more universal than T = Terminal

[Dragorn421]

I mean, when are we ever going to introduce anything using a T_ prefix? We avoid short prefixes exactly for those name clashing reasons, but these defines get a special treatment since we really want to cut down on the verbosity and can't afford having 30-characters-long macros to change the text color inside a printf, so again I think T_ will be fine for the same reason VT_ has been fine, we just don't usually use such short prefixes.

And to refocus the argument, my point for VT_ -> T_ isn't about character length, it's that VT stands for Video Terminal and historically refers to a type/"brand"? of terminals from 40 years ago (see: VT100 above), just having T_ for Terminal is more modern/accurate/inclusive (note today the terminals we use are technically "terminal emulators" when spelled in full, as a terminal is supposed to be this physical thing)

So I could also suggest TERMINAL_ or TERM_ but I assumed those would be too long. If it's not though we could use that

EDIT: Or ANSI_ or idk

[fig02]

if we use something other than T_, i think it should be VT. it still remains as short as possible while still avoiding the issues some people have with one letter. Even tho it is technically not accurate and stems from a brand of something, it serves as a close enough and unique identifier for our purposes here.

That said im still fine with T as well and dont think we'll ever run into a situation where it conflicts

[EllipticEllipsis]

T_ is pretty non-determinative, and most languages use T to mean a type of some sort (in generics etc.), so I think it increases the ambiguity. I'm surprised there doesn't actually seem to be a semi-standard set of macros people use for these anyway.

[Dragorn421]

so if not T_, TERM_ ?

[fig02]

tbh would just like VT cause its short (but not one letter). I know the technicality of it not being vt is what motivated this change in the first place, but I think it serves its purpose fine of just being a unique identifier (that is mostly accurate)

the file name being changed to terminal.h instead is good though (and should also help with people new to the codebase figuring out what the macros are for)

[Dragorn421]

TE_ ? Sorry for my insistence but I'd really like to be able to tell "the TE_ prefix stands for TErminal" instead of "the VT_ prefix comes from history"

[mzxrules]

Decided to do my own research on all of this to get a better understanding of the situation

First thought is that BEL doesn't actually belong in vt.h. it's just... stuck there, simply because we don't have much need for definitions for the other ASCII control characters to have a dedicated header for them.

Second, vt.h itself is entirely unnecessary (which also further proves my point that BEL shouldn't be defined there). It's nice to have when you're reading it from the string side of things (and probably a good enough reason to keep it), but that's the only benefit. I don't ever see it being "completed" to where it properly supports all the valid ANSI escape codes, I think the macros within the file make a mess out of something that should otherwise be pretty straightforward, and personally I feel like it'd be easier in the long run to just learn the raw escape codes and use them instead.

Third, changing the name from vt.h -> terminal.h greatly broadens the scope of the file, which I don't think is appropriate to do here. Not that Zelda64 has a functioning terminal buried in either game, but would like the file to be specific to the problem of making escape codes readable to casuals.

Fourth, vt can be backronym'd to "virtual terminal", as seen here in these microsoft docs: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

[Dragorn421]

First thought is that BEL doesn't actually belong in vt.h. it's just... stuck there, simply because we don't have much need for definitions for the other ASCII control characters to have a dedicated header for them.

hence why terminal.h

Second, vt.h itself is entirely unnecessary (which also further proves my point that BEL shouldn't be defined there). It's nice to have when you're reading it from the string side of things (and probably a good enough reason to keep it), but that's the only benefit. I don't ever see it being "completed" to where it properly supports all the valid ANSI escape codes, I think the macros within the file make a mess out of something that should otherwise be pretty straightforward, and personally I feel like it'd be easier in the long run to just learn the raw escape codes and use them instead.

We should have raw ansi escape codes directly in the strings? I'm sure that's not a popular opinion (I certainly disagree)

Third, changing the name from vt.h -> terminal.h greatly broadens the scope of the file, which I don't think is appropriate to do here. Not that Zelda64 has a functioning terminal buried in either game, but would like the file to be specific to the problem of making escape codes readable to casuals.

broadening the scope is the point

we have rcp.h and the game doesn't feature a RCP

Fourth, vt can be backronym'd to "virtual terminal", as seen here in these microsoft docs: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

which excludes other terminal types

the more common term is "terminal emulator" anyway (do a web search on both terms)

[Dragorn421]

This now (well, since one month) is VT_ -> TE_

[Dragorn421]

Back to VT_ (= Virtual Terminal) (parkour!)