Imagine a version of vterm that would extend the vt100 cursor control so that you could express subscripts and superscripts in something like H\e[0.5B2\e[0.5AO to produce H_2​O.

[woozle@toot.cat]

@riley That's my default thinking, yeah.

The only real use for client-side scripting should be for user customization. (Imagine being able to write a script to download your bank statements, instead of having to manually click through six different pages to get there.)

[riley@toot.cat]

@woozle The neo-#retrocomputing context that I imagined this sort of thing for was, if the terminal could be smart enough to do all sorts of Turbo Vision like things in itself, and the client would just have to ask it, then low-level programming languages, the sort of what one would use in a retrocomputer, could immediately and easily do fairly powerful and user-friendly UIs in an old-school fashion while not forcing the programmer to delve too heavily into the old-school "optimisation" tricks.

And incidentally, the same reasoning could apply to making neat Turbo Vision like user interfaces for shell scripts without having to mess around with curses in shell scripts, just echo ... (or, well, a couple of wrappers around it that add the appropriate escape codes). Yay for a portable interface between a retrocomputing environment and a still-relevant context!

[woozle@toot.cat]

@riley Oh! I'd forgotten what "Turbo Vision" referred to, though I think I wrote at least an app or two for it. (I mostly focused on my own GUI frameworks, both text and graphical, cuz that's how I roll).

...but yeah, that sounds very congruent with what I had in mind: it should be easy to request a window, to request a set of controls or static elements (without having to specify exact positions and manage how they move around as the window-size or resolution changes, etc., but being able to specify how they relate to each other so the client-side layout engine can make good default choices), to update element contents/appearance, and to receive input from the user interacting with the screen.

...and I suspect that if it was designed well from the ground up, it wouldn't have to be a even a fraction as bloated as most web-browsers.

[riley@toot.cat]

@woozle Speaking of finding transfem folks in unexpected places, https://jexer.sourceforge.io/. A beautiful thing, even if it's Java-based.

[riley@toot.cat]

@woozle The Pascal version of Turbo Vision for a typical application used to take about 100–150 kilobytes of x86-16 executable, depending on the widgets you would use. About 70 for truly minimal things such as a README pager.

Turbo / Borland C++ version of TV tended to turn out bulkier; not because it was itself bigger, but because of quirky differences of compilation and linking technologies between Borland's Pascal and C(++) toolchains.

[riley@toot.cat]

@woozle Also, Borland supplied a hypertext authoring system with the (late) versions of Turbo Vision, in the guise of 'context help'.

[woozle@toot.cat]

@riley I remember looking at the Windows help system and thinking "huh, might be kind of useful to be able to use this for other stuff..." -- but when I looked into it, the process for creating content was... complex, and involved compilation using some software that might have cost money or something (I don't quite remember)...

...so I put it off indefinitely, and then suddenly the web happened. #procrastinationFTW

[riley@toot.cat]

@woozle And now, Microsoft uses a form of wrapped-together HTML for its context help.

The TV sample applications that come with the Borland's TV toolchains, both Pascal and C version, come with the source code for a widget that displays help, according to 16-bit context indicators, and there's an utility called tvhc, for Turbo Vision Help Compiler, also in source code form, that takes text looking like this:

.topic Viewer=2
 File viewer ▄
  ▀▀▀▀▀▀▀▀▀▀▀▀
A file viewer views the contents of a text file. You can use the
arrow keys to move about in the file. A file is loaded via the
{File│Open:FOpen} menu item.

  Up         Move up one line
  Down       Move down one line
  Right      Move right one column
  Left       Move left one column
  PgUp       Move one page up
  PgDn       Move one page down
  Home       View right most column of the file
  End        View left most column of the file
  Ctrl-PgUp  View top of file
  Ctrl-PgDn  View bottom of file.

File viewers can be resized and moved using the {Windows} menu.

and converts it into an indexed binary structure that the widget can process. .topic indicates beginning of an article, Viewer is this particular article's name; 2 is its 16-bit code (also automatically made available as hcViewer in C cource, 'hc' standing for Help Context), and {Windows} is a hyperlink to topic named Windows. {File | Open:FOpen} is a hyperlink topic named FOpen, but labelled File | Open, since the topic names, considering that they become C constant names, have to be identifier-like.

Also, you can attach the 16-bit help contaxt tags to all sorts of things, such as menu items or budttons or checkboxes, so focusing one and and triggering the cmHelp command, often customarily available bound to the F1 key, can just pop up the help browser at the appropriate topic.

[riley@toot.cat]

@woozle Microsoft nearly killing Borland was a great damage inflicted to the art of software development. :blobcatsad:

[riley@toot.cat]

@woozle Speaking of the size of the application, I believe the code could be significantly smaller if the non-speed-critical parts would be implemented in a suitably chosen bytecode, and if constant data structures were stored pre-constructed rather than in the form of code that constructs them.

[riley@toot.cat]

@woozle Something that Microsoft did systematically early on, probably in order to make its products seem more alluring, was leaving important things such as binary formats and data structures and API calls undocumented, but then allow (selected) data about them 'leak out', and be written about in "third-party" books, such as, early on, a whole bunch of Peter Norton's ones. IIRC, the original Windows Help system was pretty much based on an (early) form of RTF, with a couple of extensions, and a packaging system. If you would know about the formats, you could easily write simple tools to convert files to and fro — but almost nobody had good understanding of the formats, reverse engineering could take you only so far, and so people got stuck with bulky, clumsy, limited, and expensive tools.

This sort of antipattern shows up repeatedly in the history of computers sold to private persons, and the @fsf doesn't contrast it against how the Free Software world works nearly often enough.

[riley@toot.cat]

@woozle Ironically, a part of why this particularl kind of dirty tricks work is, they hook into a type of toxic masculinity that has long been a common techbro feature: the feeling of superiority from learning a "secret" in a published book.

@fsf

[woozle@toot.cat]

@riley Information as Power is a common antipattern across all disciplines, yup.