Mood: relaxed
Audio: Random sh4d0wcounc1L radio playlist,
currently: Qntal - Ab vox d'angel
Input device: wy325 terminal
====================================================================
Ah, another year, another phlog post! Yes yes, I realize it's already
February, but hey! ▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
This is gopher- █▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▉███▇▅▃
space. Things do ▐█▇▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▜▌ ▕████████
move slower. I'm ██████▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▜▎ ▐████████
writing this on ▕█████▛ ▐▏ ▐████████
one of my dumb ▐▉████▎ ▉ ▐████████
terminals and, ██████ ▊ ▐████████
as such, this ▕█████▊ ▕▋ ▐████████
phlog post will ▐█████▌ ▐▍ ██▉██████
be... about ██████▌ ▐▎ ██▉███▉▉▉
terminals! ... ▕██████▌ ▟ ██▉██▉▉▉▉
well, sort of, ▐████████▇▇▆▆▅▅▄▄▄▄▄▄▄▄▄▄▅▅▅▉▃▃▂▂▂▂▂▂▁▁▁▁▁▁ ▁█████▉▉▉▉
kind of, ▗████████████████████████████▊ ▔▔▔▔▔▔▔▕██████▉▉▉
mostly. ▗▞▘▂▞▜▌▂▂▂▂ ▁▁▁ ▏ ▔▗▔▄▔▔▃▘▔▕▇▞▘▗▅▃▖ ▄▖▄▄▄▄▃▃▟████████▀
▗▞▘▗▆▜▇█▂▆▂▂▂▁▁▁▅▔▖▔▖▙▂▋▝▂▝▁▆▆▆▖ ▁▟▙█▙█▙█▀▔ ▟████▛▘
There's ▆▌▁▁▁▁▁ ▀▀▀▀▀▀▀▜████▇▇ ▀▀▀▘▀▇▘▗▟█▟▉▇▋▃ ▔ ▗▟███▛▘
something ▔▔ ▀▀▀▀▀▀▀▀▀▜▆▆▅▅▅▅▄▄▄▃▃▃▃▃▂▂▂▁▝▀▀▀▝▀▝▀▘ ▗███▛▘
quite comfy about writing ▀▀▀▀▀▀▀▀▀▀▀▇▆▆▆▆▆▅▅███▘
up a bunch of stuff with just a terminal as input
device. It's very hard to get distracted. My Wyse and honeywell
terminals both still need a bit more work on their termcap files.
While there is a termcap for both on most *nix systems included by
default, these default termcaps are full of problematic mistakes
and missing features. The wyse terminal works relatively well when
I configure it with a vt220 personality for the most part - there's
a few keys that mess things up in vim, such as using the 'home' key,
but those are minor problems. However, the vt220 mode doesn't give me
access to the colors the terminal is capable of rendering (among a
few other features) - there is also a plethora of wy325-* termcaps
- one for each of the various terminal options, but those alas also
don't support color, and are broken in way more ways than the vt220
termcap. I did find a termcap online for this terminal that adds
color support to the vt220 mode, and that one ALMOST worked. I had to
modify it a bit, and i now have color in com and other programs on
SDF, which is really fun. It still needs a few tweaks however.
Sometimes com will send an escape character that will disable the
terminal's line-wrap setting, causing long lines to be truncated at
random. Then, if people start writing unicode, that will mess it up
completely, and freeze the terminal.
Similarly, the honeywell terminal works 'ok'-ish for the most part
with the 'vip-H' termcap, but there's always the odd random escape
that will mess things up. One thing that's cool about the green
phosphor screen on the honeywell is that it has a really cool weird
glow under the blacklights in the room, which makes it really fun to
use.
I may have mentioned in earlier phlog posts that I've been writing a
sort of 'modern'-ish implementation of TurboVision in cpp - I had
initially decided to not use curses, and write my own ansi/termio
stuff for it, so I wouldn't have to struggle too much with broken
termcaps for my various terms, but I think I might start over with
some of that work and go the opposite direction, and instead just.
.. fix the termcaps... because:
One of the biggest issues I have with the old terminals is that a lot
of modern applications just assume modern ansi escapes that work with
most terminal emulators, and don't use curses at all, and just output
raw escapes. - This of course breaks everything if the terminal uses
different escapes. - So, in the spirit of not adding to the problem,
I should probably just use curses.
I saw this icky article on the icky http the other day where an
opinionated developer was complaining about why people still use
ncurses in <insert "modern" year> - his opinion was that, given that
most terminals support plain ansi, everyone should just output plain
ansi escapes (his argument for this was, because ansi escapes are not
some mystery rocket science), and I guess, from his perspective, less
painful than dealing with the ncurses c api (hating C is so hot right
now) - Ok, so the problem with this is obviously that you can't just
assume all terminals support all ansi escapes in the same way. Clunky
C api's aside, having a concept of terminal capabilities is a good
thing, I think. And old terminals becoming less and less usable
because software (and their developers) don't bother with termcaps
is a bad thing. Old tech can still be useful! ( I'm aware that I am
preaching to the choir here, this is gopher after all) - Still, if
this is the new reality, and given that the termcaps for old obscure
terminals are less than perfect - maybe I should just write a screen/
tmux-like terminal emulation util. for physical terminals that just
translates "standard" ansi escapes to whatever the terminal is
capable of rendering per it's termcap. Using a terminal emulator on a
physical terminal is a weird concept though. Also, one could argue
that there isn't much standardized ansi, even among modern terminal
emulators. There are plenty of escapes that are unique to xterm, or
rxvt, vte, or whatever. So I still think that using curses would be
preferable to hard-coding escapes.
All that said, termcaps ARE a lot of work and a pain to write. It may
perhaps be a good idea to write a util that translates termcaps to
something like json/yaml/ <insert your favorite config format> and
back again. And if someone wants to write a curses alternative, that
is fine with me too - but please don't ditch the concept of checking
for terminal capabilities/mappings.
One invaluable resource in writing termcap files is terminal manuals,
and unfortunately, for a lot the more obscure old terminals, these
can be very hard to come by these days. Even online, bitsavers.org &
archive.org only have a limited selection. I recently managed to find
a manual for Honeywell VIP7800 terminals, which are similar to the
one I have, so this has been a useful thing to have. Yet still, there
are differences, and having the actual manual for my terminal would
be even better.
I'm in the process of digitizing the VIP7800 manual, it's a tedious
process, but hopefully in the end I will have a PDF I can upload to
archive.org/bitsavers - I will also (soon) add a =WANTED= section to
my phlog with a list of manuals I'm looking for, and maybe I'll get
lucky, and a kind soul will share with me one of their treasures. :)