Re: Implementing image support for kitty terminal

[Eli Zaretskii <eliz@gnu.org>]

> From: Jose Antonio Ortega Ruiz <jao@gnu.org>
> Date: Wed, 07 Sep 2022 16:50:08 +0100
> 
> The kitty terminal emulator (which runs under X11 and wayland) offers a
> simple protocol for displaying images, fully described at
> <https://sw.kovidgoyal.net/kitty/graphics-protocol/>.  
> 
> In a nutshell, it accepts an escape sequence that make it enter "graphic
> mode", followed by either encoded image data or a path to an image file
> or a shared memory location to display.  Among several other niceties,
> the protocol allows drawing to rectangles specified in cell units. As a
> simple example, the sequence:
> 
>    <ESC>_Gf=100,t=f,c=50,r=100;<encoded /path/to/file.png><ESC>\
> 
> would make kitty draw the image in file.png rescaling it to 50 columns
> and 100 rows.  By default, the current cursor position is used, but it's
> also possible to specify pixel offsets and sizes.
> 
> At first sight, it looks as if adding support for this protocol to
> emacs's tty terminal (when kitty, or the capability (it seems other
> terminals support the same protocol) is detected) shouldn't be too
> complex, and with that, perhaps, provide direct support for the
> elisp-level image- API for these terminals (so that, for instance,
> doc-view or pdf-tools or displaying images in eww buffers would work out
> of the box).  Am i wrong?

It's hard to tell, because you haven't described your ideas of
implementing that.  In particular, the current model of image display
in the Emacs display engine is that an image is basically considered a
single very large character, from the screen layout POV.  I guess
that's not what you have in mind for the above, so IMO it's important
to come up with an alternative model that would somehow fit with the
current display code with only minor changes, if we want this not to
be too complex.

> On a personal note, if that were possible it would put emacs on a kitty
> terminal on the same league as the full graphical version for my needs,
> with the added benefit of dramatically reduced RAM footprint, faster
> display and, last but not least, a truly great alternative to pgtk in
> wayland.  So, if the implementation is feasible, i'd be willing to help
> if needed.

I don't think anyone will disagree that extending the capabilities of
TTY frames in this direction will be a very good and useful feature.