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!
This prepares us for actually making use of multiple session in a sane
way.
Notable implicit change is that we no longer crash on an "unrecognized
duct", instead always handling it as destined for the default session.
As follow-up to 3fdef1468, we now no longer store the prompt or cursor
in state. These were still used for view initialization, but it's more
appropriate to %hey the underlying console application in those cases.
The scry endpoints we remove, expecting clients that depended on them
to send a %hail instead.
No longer inserts newlines or redraws the prompt post-print, pushing
this responsibility down to drum where it belongs.
Additionally, separates the flow for dill's own output, from that of the
console application. This lets us keep the desired behavior for now, and
will ease reworking in the future.
Last-printed-line and cursor position are still kept around in dill
state, in order to respond to the relevant scry endpoints. These should
either be refactored to scry into the underlying console app, or be
removed entirely in favor of %hey.
Only detects mouse clicks. Though, "9" mode seems broken, or unsupported
or something? Probably need to upgrade to "1000" mode or higher, but
that also reports scrolling events and such, which don't want to steal
from the context we're running in just yet.
As of dc2c990c0 these are redundant, and keeping them in would result
in trailing whiteline.
The result is that sometimes we call u3l_log with the empty string. We
simply want it to insert a newline into the scrollback for us. GCC
complains about this, because it leads to using an empty format string,
but we consider this sane behavior. We update the flags accordingly.
We want to decouple drum state & semantics from term.c. But we also want
to continue showing printfs without mangling whatever the arvo side is
doing. Short of formalizing various "terminal modes", the best we can do
it assume that the main session is always in drum mode, and use that
assumption to squeeze into the actual content stream when doing printfs.
In essence, we insert the printf between the prompt and content, pushing
the content up into terminal scrollback. Both the prompt and cursor
position are maintained without knowledge of their original states.
Because this logic relies on knowing the (accurate) terminal height, and
this logic being the *only* thing in term.c that reads from the height,
we no longer initialize the terminal size with a sane height. Instead,
we set it to zero, and check for that to determine whether we're ready
to use this logic or not.
Due to the way this inserting works, trailing newlines are no longer
required from the output. For consistency, we manually add trailing
newlines when this logic cannot be used, both in the above-described
circumstance, and the less-common case of u3l_log.
This will of course need to be accounted for in all existing calls to
u3l_log, but we move that into the next commit for readability's sake.
Instead of confining you to just the bottom row. 0,0 is bottom left.
Doesn't behave exactly as expected for non-zero column coordinates yet,
but all in due time.
Instead of relative, character-based position. In anticipation of
greater degrees of cursor freedom, and so that we don't have to
track invisible characters all the time.
Likewise for belt. This necessitates renaming the %mor blit for newlines
to %nel, making this require a new runtime version. That's fine, more
breaking changes are to follow.
When a graph is joined, the subscriber receives an %add-graph update
that corresponds to the current state of the graph. This was not logged,
so if the graph did not recieve any updates before the subscription was
kicked, the whole graph would be have to be sent again. This would be
largely asymptomatic, however hark-store assumes that %add-graph will
only be emitted when a new graph is joined or created. As such, we log
this initial update, so that the push-hook can correctly ascertain the
backlog it needs to send and so %add-graph is only emitted once per
graph. This also opens the door for time-varying scries into
graph-store.
Fixes#4290
