This represents an essentially complete rewrite of ncvisual and associated code. It had two major goals:
Improve the ncvisual API based off lessons learned, pursuant to the upcoming API freeze. In particular, I wanted to:
decouple ncvisuals from ncplanes. It should be possible to render a ncvisual to multiple planes, with different scaling each time. It should be possible to create an ncvisual without a plane, etc.
normalize the various ways of constructing an ncvisual -- file, memory, plane, etc.
Support multiple blitters, from 7-bit ASCII to Sixel. This required writing the blitters in several cases, and they're not yet in their final implementations (but the API is fine)
I have not yet unified Plots and Visuals, and might not, given that the Plot code works fine. We could at this point implement Plots in terms of Visuals, though -- the blitter backend range has been unified. Sixel is not yet implemented, though it is listed.
There is a new POC tool, blitter. It renders its arguments using all possible blitter+scaling combinations. Another new POC, resize, displays its argument, then resizes it to the screen size and displays that, explicitly making use of ncvisual_resize() rather than a scaling parameter to ncvisual_render().
This also eliminates some memory leaks and bugs we were seeing in trunk, and brings in Sixel scaffolding.
The C++ wrapper will also need patching back up; I cut most of it down while wrestling with this crap, urk.
Closes#638, #562, and #622.
We need support three distinct paths for destruction of
ncsubprocs: (1) external call to ncsubproc_destroy() while
the subprocess is running, (2) external call to
ncsubproc_destroy() after the subprocess has terminated, and
(3) internal call to ncsubproc_destroy() without any external
call. To do this properly, we always waitid() on the subprocess
in our ncsubproc thread, and do not cancel said thread. This
guarantees that the subprocess has been reaped if the thread
has exited. We throw a pidfd_send_signal() into the thread
prior to the waitid(), because this is safe with pidfds. The
thread reclaims no resources otherwise. ncsubproc_destroy(),
instead, reclaims them, after joining the ncsubproc thread.
It sends SIGKILL before the join, which is once again safe
thanks to pidfds. Resolves#552.
