Re:Show HN: kitty-graphics.el – Images, LaTeX and PDFs in te...
by cashmere1337 on Wednesday March 11, 2026 @03:52AM
(#47332742)
A few days ago I posted the initial release of kitty-graphics.el here. Thanks for all the feedback, bug reports and feature requests. I went ahead and built everything that was asked for.
Here's what's new in v0.2.1:
- Org inline images now work properly. The core feature from v0.1 got a robustness overhaul. File links, attachment links and relative paths all work.
- LaTeX fragment preview in org-mode via C-c C-x C-l. Renders through dvipng, displayed inline via Kitty protocol. No GUI frame needed.
- doc-view integration. PDFs, DVI and PostScript files render in the terminal. Page navigation, zoom, centering all work.
- Image-mode with zoom controls and centering. Uses its own major mode now to avoid evil-mode conflicts.
- Dirvish integration. Image previews in the preview pane, no config needed.
- Images hide when org headings are collapsed. This was the first bug report and it's fixed.
- LRU image cache instead of the old unbounded hash table.
- Less flicker on buffer/window switches.
- Overflow protection for tall images near the bottom of the window.
Re:Show HN: kitty-graphics.el – Images, LaTeX and PDFs in te...
by cashmere1337 on Wednesday March 11, 2026 @08:07AM
(#47334539)
Great question!
I actually use GUI Emacs more often than terminal Emacs. But when I'm deep in a CLI-centric workflow, deploying over SSH, running commands, maybe taking notes, it's much more convenient to stay in the terminal. And when I need to glance at an image, a screenshot or a PDF in that context, it's nice not to have to leave.
I started this purely out of curiosity, just wanted to see how far the Kitty graphics protocol could go in Emacs. When I realized you could get surprisingly far with zero dependencies, I decided to build it out properly for the Emacs community rather than just for myself.
Displaying images in terminal Emacs was considered basically impossible for a long time. Whenever new users coming from other TUI editors or terminal-centric workflows asked about it, the answer was always "just use GUI Emacs". That's a valid answer, but it's nice to finally have an alternative.
Here's what's new in v0.2.1:
- Org inline images now work properly. The core feature from v0.1 got a robustness overhaul. File links, attachment links and relative paths all work.
- LaTeX fragment preview in org-mode via C-c C-x C-l. Renders through dvipng, displayed inline via Kitty protocol. No GUI frame needed.
- doc-view integration. PDFs, DVI and PostScript files render in the terminal. Page navigation, zoom, centering all work.
- Image-mode with zoom controls and centering. Uses its own major mode now to avoid evil-mode conflicts.
- Dirvish integration. Image previews in the preview pane, no config needed.
- Images hide when org headings are collapsed. This was the first bug report and it's fixed.
- LRU image cache instead of the old unbounded hash table.
- Less flicker on buffer/window switches.
- Overflow protection for tall images near the bottom of the window.
Full writeup with GIFs: https://cashmere.rs/blog/kitty-graphics-el-v021-release
Repo: https://github.com/cashmeredev/kitty-graphics.el
Curious where you see this being most useful in practice, documentation workflows, data exploration, or something else?
I actually use GUI Emacs more often than terminal Emacs. But when I'm deep in a CLI-centric workflow, deploying over SSH, running commands, maybe taking notes, it's much more convenient to stay in the terminal. And when I need to glance at an image, a screenshot or a PDF in that context, it's nice not to have to leave. I started this purely out of curiosity, just wanted to see how far the Kitty graphics protocol could go in Emacs. When I realized you could get surprisingly far with zero dependencies, I decided to build it out properly for the Emacs community rather than just for myself.
Displaying images in terminal Emacs was considered basically impossible for a long time. Whenever new users coming from other TUI editors or terminal-centric workflows asked about it, the answer was always "just use GUI Emacs". That's a valid answer, but it's nice to finally have an alternative.