Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As long as terminal used supports sixel graphics.


I wrote a graphics library for non-sixel terminals

https://github.com/dheera/python-termgraphics

Might be interesting to mod this library to support this as a fallback.


Looks good! I've seen a few such libraries. My favorite is chafa: https://hpjansson.org/chafa/


A labor of love, congratulations.


xterm supports sixel, so surely anything that sets TERM=xterm256-color or similar will be compatible… right? ∗cough∗ gnome-terminal ∗cough∗


xterm supports sixel, so surely if your TERM is xterm-kitty, it's supported right?


I would say so, yes (not a fan of kitty's general NIH), but it could be argued that `xterm-kitty` is at least not identical to a $TERM used for xterm.


Indeed. I was trying to humorously reference the author's staunch refusal to remove `xterm` from the TERM identifier, knowing full well that many programs simply look for `^xterm` when determining if the terminal is compatible. As you eluded to with 'NIH', the same author refused to implement Sixel in Kitty because it is "inferior" to Kitty's image implementation.


What does "NIH" mean in this context?


Kitty developer decided to go with a custom image display protocol instead of going with sixel.


https://en.wikipedia.org/wiki/Not_invented_here - When someone or some group prefers to re-invent something rather than using an existing, perfectly serviceable solution.


Not Invented Here


Why do we now have User-Agent in the terminal ;-;


Isn't the TERM variable ancient? I know one of the "common" exported variables is the VT100, sold in 1978.


Yes, it is very old.


mlterm works




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: