Re: Implementing image support for kitty terminal

[Eli Zaretskii <eliz@gnu.org>]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: jao@gnu.org, emacs-devel@gnu.org
> Date: Thu, 08 Sep 2022 20:30:39 +0200
> 
> On Wed 07 Sep 2022 at 22:51, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Tomas Hlavaty <tom@logand.com>
> >> Second, tty emacs would need to somehow reserve rectangle for the image.
> >> This might be lots of work I guess.
> > The second part is the problem I'm talking about.  The other two are
> > much simpler to add, I think.
> 
> Maybe the difficulty comes from the idea that tty emacs should somehow
> match GUI emacs capabilities when displaying images.

No, it comes from the basic design of the display engine, which is
common to GUI and TTY frames, as far as layout is concerned.

> The original use-case in this thread was using kitty terminal to view
> documents like doc-view or pdf-tools.  There is no need to implement
> full GUI like graphics capabilities for that.  In emacs-framebuffer, I
> simply use the dimensions and position of the buffer to display images
> without changing any layouting in tty emacs.  Adding images to eww would
> be more complex, but I guess the change could be to shr layouting
> written in elisp instead of changing emacs C code.

You are again thinking about a completely different layer than the one
which bothers me the most.  As soon as you want to display images
together with text, or even scroll through tall images displayed alone
in a buffer, the basic layout issues come into play, because Emacs
scrolls and updates the display by considering internally which
portions of the window need to be redrawn and how, and it does that by
comparing old coordinates of the stuff that was on the screen with the
new coordinates of the stuff that should be on the screen.  For this,
it must now which part of the display occupies what screen location,
and this must be done in the coordinate system used by the display
code, which represents the screen as "glyph matrices": a series of
glyph rows, and each display element as a glyph in some glyph row.
This design is identical in both GUI and TTY windows, and the code
which deals with the glyph matrices is the same in both cases.

Of course, if all you want is to display a single image on the screen,
and don't want to support scrolling of images nor display of images
mixed with text, then these issues pretty much disappear.  But I very
much doubt that this will be good enough for our users.  It is
definitely much less interesting from my POV, because it basically
means we implement some kludgey and severely restricted semi-solution.