Updates /app/herm and dependencies to work with latest dill, and
rewrites the entire webterm frontend to use xterm.js for rendering.
Webterm code needs a bit more work. Its subscription handling might
want to be moved out, it needs to handle resizing, react to landscape
theme changes, etc.
The bottom line is where we draw the spinner, so we're only interested
in screen draws that affect that part of the screen (so that we may
restore it after having drawn the spinner there).
Given recent changes, redraws should be less frequent than updates, so
we lazily store the utf32 encoded line contents in state, instead of
the eagerly converted utf8 version.
This keeps the cursor position at the last %hop location. And being able
to go back to that position without relying on state is just plain
convenient.
The exception here is %nel blits, which move the cursor (down and) to
the start of the line, as expected of "new line" semantics.
%url blits are meant for "activating" urls. Of course, opening a new
browser tab from within a C program is difficult, so we don't do it.
This is still better than doing the faux activation by just printing
the url. term.c no longer really knows where/how to draw it, and it's
meant as interactive behavior rather than visual output, anyway.
This simplifies the behavior of individual blits, making their
implementation simpler and giving arvo more control.
This lets us write on top of existing content, instead of completely
replacing the affected row. Additionally, lets us draw starting at the
cursor position, instead of the leftmost column.
To retain the previous behavior, preface with [%hop 0] to move the
cursor to the start of the line, [%wyp ~] to clear the existing content,
and finally your %lin to render it.
styx and stub are both defined in lull. Having functions for dealing
with them in zuse rather than userspace is fitting.
While not a _common_ format per se, it still seems best at home in
+format, instead of on its own.
Some of the remainder are still _presently_ unused, but point at
functionality we want to support again in the near future. The ones
removed here are either redundant or have no clear purpose.
As per the note a couple lines up, +fore depends on drum semantics being
active. We can only guarantee those being present for the default
session, not for any others. So, we print a warning when appropriate.
Before recent dill changes, this wouldn't always be visible, since it
would get drawn in place of (and subsequently get overwritten by) the
prompt. Now that it displays consistently again, it should look a bit
better than just a noun dump.
This is somewhat redundant with gall's own "reloading agent" printfs,
but you know what they say: printfs don't real!
