One of the really cool things about chafa is that it has both sixel and kitty graphic renderers! (and iterm2 images as well) So you can output kitty if the terminal supports it, but fall back to ascii if it doesn’t.
What interests me about it is the unicode mosaic output format that looks higher quality than the usual upper half block or braille character approaches without needing to support a special protocol.
Setting aside the usual compatibility issues with those things.. neither are available from your buildbot. Also while Jupyter does supports images other notebooking ecosystems may not, and anyway you need a file whereas chafa can work with streams.
I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
It should in theory be possible to mount the new virtual package over the lower module - but I don't think works currently (I'll have to test this). Doing this would make modifications available globally like you describe.
Let me explain what inspired me to create modshim:
I've written a Jupyter client for the terminal (euporie), for which I've had to employ monkey-patching of various third-party packages to achieve my goals and avoid forking those packages. For example, I've added terminal graphics support & HTML/CSS rendering to prompt-toolkit (a Python TUI library), and I've changed aiohttp to not raise errors on non-200 http responses. These are things the upstream package maintainers do not want to maintain or will not implement, and likewise I do not want to maintain forks of these packages.
So far I've got away with monkey-patching, but recently I implemented a kernel for euporie which runs on the local interpreter (the same interpreter as the application itself). This means that my patches are exposed to the end user in a REPL, resulting in potentially unexpected behaviour for users when using certain 3rd party packages in Python through euporie. Modshim will allow me to keep my patched versions isolated from the end user.
Additionally, I would like to publish some of my patches to prompt_toolkit as a new package extending prompt_toolkit, as I think they would be useful to others building TUI applications. However, the changes required need to be deeply integrated to work, which would mean forking prompt_toolkit (something I'd like to avoid). modshim will make it possible for me to publish just my modifications.
Perhaps it's a somewhat niche use-case, and modshim is not something most Python users would ever need to use. I just thought it was something novel enough to be of interest to other HN users.
> messing around with import internals in python is extremely tricky to get right
This is true! modshim has been the most complicated thing I've written by some way!
It's up to individual applications how they implement user input. All of this is entirely possible in modern terminal emulators - look at the micro text editor, for example.
I guess most shells (bash, zsh, etc.) keep things "traditional" for backwards compatibility reasons.
I don't know about overprinting per se, but you can already use whatever foreground+background colors you want; how much benefit would overprinting be?
This would allow more complex shapes to be drawn by combining multiple glyphs, which would be useful for complex TUI applications (there are only a limited number of box-drawing characters available) Also, this could allow drawing more than two colours per terminal cell.
That doesn't solve the two-colors-per-cell challenge. But it makes for some very realistic terminal images.
For higher fidelity rendering, I think the next best option is supporting image protocols like sixels or Kitty inline raster images. I'm not sure how overprinting would compare to existing options.
It would be good if there was more emphasis on graceful degradation in TUI libraries, such as falling back to ASCII art when terminal graphics are not supported.
> Some new TUI libraries, such as vaxis, are designed specifically to avoid using terminfo at all and exclusively use queries to determine feature capabilities.
I take this approach in euporie [1], having encountered the same issues with using terminfo as discussed. However, there were a few terminal features which I could not find a way to query - iTerm2 graphics support, for example.
