Hacker News new | ask | show | jobs
by pxc 1190 days ago
That would be because GNOME Terminal doesn't support sixel graphics.

https://www.arewesixelyet.com/#gnome-terminal

Looks like if you build the latest libvte from master and make sure to explicitly enable sixel support via the appropriate build time flag, you can then build GNOME Terminal against that and you'll have sixel support:

https://gitlab.gnome.org/GNOME/vte/-/issues/253

1 comments

Ah, thanks. I made the mistake of assuming any modern terminal would/should by default.
Yep! It's surprising to me, too, how recently (within the past 4 years, by my estimation) there has been an intense, renewed interest in sixel.

It has coincided with the creation of a lot of new terminal emulators (some of the youngest have the most support for sixel and similar features), and with the trend of using GPU acceleration in terminal emulators.

I couldn't exactly say 'why now', but one guess is that macOS' explosion in popularity among developers and the relatively high popularity of desktop Linux within the developer community in particular have produced a generation of developers who appreciate the power and flexibility of the Unix command line but have also grown up with rich graphics on their computers from the start.

There's clearly a strong contemporary desire for a more IDE-like terminal experience, and for graphically enriched tools that are still decidedly text-centric. Efforts to establish new standards and protocols for this have mostly withered or seen little uptake, so resurrecting support for (today) rarely-used features of old physical terminals has emerged as a viable approach for adding graphics to our CLI environments.

Maybe some day we'll escape from the 80s, but for now it seems that we are still returning to them to find 'new' material, for various practical reasons.

> I couldn't exactly say 'why now', but one guess is that macOS' explosion in popularity among developers and the relatively high popularity of desktop Linux within the developer community in particular have produced a generation of developers who appreciate the power and flexibility of the Unix command line but have also grown up with rich graphics on their computers from the start

This so much!

I mostly have 2 apps running: Edge and a terminal. On windows, this terminal is mintty (wonderful!) or Windows Terminal (no sixel support yet).

On wayland, I use foot or wezterm. I need plots, and it's much faster to use gnuplot without leaving the terminal

When I need more, I open excel or rstudio. Excel cells are very text centric, and likewise for Rstudio chunks.

> Maybe some day we'll escape from the 80s, but for now it seems that we are still returning to them to find 'new' material, for various practical reasons.

I use notebooks for literate programming. It seems new? (as in, I don't think it was done in the 80s)

I wouldn't say embedding graphical content is a return to the 80s, but more like making a new mashup taking the best of the old (command line interface= minimalist yet powerful) and the recent (graphics= high information density) to go beyond the limitations of each.

> I use notebooks for literate programming. It seems new? (as in, I don't think it was done in the 80s)

I've done a bit of the same with Emacs via Org-mode and Babel, and I want to do more! Literate programming (and even literate DevOps!) is great.

If it's picking up these days, I think that's wonderful. But the idea is indeed from 1984 (via Knuth)! So in that way, the resurgence of literate programming is the result of mining the ancient computing past for great ideas we've not yet done enough justice as an industry/practice/science. :)

> I wouldn't say embedding graphical content is a return to the 80s, but more like making a new mashup taking the best of the old (command line interface= minimalist yet powerful) and the recent (graphics= high information density) to go beyond the limitations of each.

I wrote what I wrote without any real pessimism. I think there's a lot that's still great about old technology, like Unix or Lisp.

In terms of really 'escaping from the 80s' I had something narrower in mind, like the actual implementation details of retaining compatibility with old terminals and implementing new features via escape sequences and stuff like that. I think some day more of a clean slate could be more flexible or easier to hack on. (Which is, for me, just a hunch— I've never worked on a terminal emulator myself.) But even then, I think that 'escape' would still be as much about doing justice to old ideas as being able to let go of old implementation details.

> But the idea is indeed from 1984 (via Knuth)

Today I Learned :)

> I think some day more of a clean slate could be more flexible or easier to hack on. (Which is, for me, just a hunch— I've never worked on a terminal emulator myself.)

Not really. Please understand the old protocols (ex: sixels) as making you handle a required subset of the problems the new protocols (ex: kitty, etc) will also require you to handle (like storing the bitmap, invalidation, scrollback)

> But even then, I think that 'escape' would still be as much about doing justice to old ideas as being able to let go of old implementation details.

As long as I can get videos and plots along text in my terminal, I don't care if it's old or new: it just enables me to do more :)

Give any sixel-less terminal the sixel-tmux googles and you'll see an ascii rendition of the sixel images: https://github.com/csdvrx/sixel-tmux

It's not ideal unless you use a very small font, but it's better than nothing.

BTW some people recompile libvte to get proper sixel support in their favorite terminal: https://github.com/mate-desktop/mate-terminal/issues/410 and then get results like: https://www.youtube.com/watch?v=mLQbAYJGZMA