It was realized that our libreadline wrapper was incompatible with the new input method, indeed fundamentally so. Rip out all libreadline support. Implement a minimal ncdirect_readline() -- quite minimal, but enough to get by. We'll want to fill this out later.
So no ABI/API breakage, though perhaps some visible behavioral change.
more and more terminals are switching their
interpretation of DECSDM to match the actual VT340
behavior, rather than that of XTerm prior to
patchlevel 369. start using \e[?80l by default to
turn DECSDM on. track terminalsXversions which
use the previous behavior, and for them, emit 80h.
continue to always send 8452h, on which i have
no data suggesting anything but one interpretation.
remove pixel_shutdown. note that Alacritty switched
over to the new semantics in 0.15.1.
We were using the value of pixel_shutdown to decide
whether we needed to take a kitty-specific path or
not. Instead, just use the pixel_implementation field
of tinfo, which was added a few weeks back.
* split up ncdirect_dump_{sprixel, cellplane}()
* build ncdirect_dump_cellplane() out of fbuf #2167
* [macos] don't run pandoc in workflow
* [gpm] account for margins in mouse reports
* [in] drop mouse clicks from top/left margins
* [ffmpeg] compile against avformat 59+ w/out warnings
Hardcode a call to ncplane_resize_maximize() in
notcurses_resize_internal() for the standard plane,
when handling the standard pile. allow the user
to set the standard plane's resize callback beyond
that. closes#2163.
Much as we needed to do in the accounting core for
kitty animation, whether we blitted a sprixcell of
alpha nulls or instead wiped it affects how we
rebuild under KITTY_ANIMATION, which right now is
all Kitty >= 0.20.0 since KITTY_SELFREF is disabled.
This gets KITTY_ANIMATION working perfectly on
bitmapstates. I've accomplished this by stashing a
bool onto the end of each KITTY_ANIMATION-style
auxvector, set high if it originated in a reblit's
null alphas, and low if it was zorched by a wipe.
Set {c, r} arguments to animation directive based
on whether this is set. See #2161.
When using the reflexive composition extension to the
Kitty graphics protocol, we refer to the previously-
blitted image to rebuild cells, and thus don't have to
keep a copy of the image ourselves. We just blit null-
alpha cells to wipe, and then execute a reflective
composition to rebuild. The auxvector is a single word,
holding the state we were in before the wipe, since we
don't have a copy of the image to look at to determine
the state afresh (and caching it is more efficient
anyway). Good, good.
Except. When we reload the plane, we want to carry over
those wipe cells, yes? I.e. if there was a plane above
the graphic before, and we replace the graphic, that
plane still better be above it. And that means editing
the cell out of the new graphic that we blit up, on the
fly. Which we were doing. Problem is, if we later need
to rebuild that cell, and we reflexively compose using
this new image, *we reflexively compose the edited-out
cell*, and thus remain wiped (our RGB values get set
properly, but we have all 0 alphas). No good!
So instead, in KITTY_SELFREF (the most advanced kitty
implementation, corresponding to reflexive composition),
do a pass at the end and send AAAAA wipes for any
ANNIHILATED{_TRANS} sprixcells. We don't present until
both have hit (since we're using a new image ID), so
there's no flicker, though there is some bandwidth cost.
That handles rebuilding. Problem is, if we then need to
wipe these same sprixcells *again*, our auxvecs were
set to ANNIHILATED{_TRANS}, and thus no wipe takes place.
Rather than blindly propagating the auxvec across the
frames, properly reset the auxvec according to the new
blit. This handles wiping post rebuild, closing the cycle.
Kitty 0.22.0+ now runs the bitmapstates PoC perfectly.
Closes#2143. woo-hah!