Re: Implementing image support for kitty terminal

[Eli Zaretskii <eliz@gnu.org>]

> From: Jose A Ortega Ruiz <jao@gnu.org>
> Cc: tom@logand.com, emacs-devel@gnu.org
> Date: Fri, 09 Sep 2022 07:21:34 +0100
> 
> On Fri, Sep 09 2022, Eli Zaretskii wrote:
> 
> >> From: Jose A Ortega Ruiz <jao@gnu.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Fri, 09 Sep 2022 00:32:32 +0100
> >> 
> >> also, a term emacs running inside kitty or foot in wayland is very
> >> noticeably faster than the graphical counterpart
> >
> > That advantage will almost certainly go away, at least partially,
> > if/when we implement the new backend as proposed by Gerd, because some
> > of that advantage is due to the simplicity of the TTY frame geometry
> > and text layout, something that will be lost as soon as we support
> > variable-height screen lines on TTY frames.
> 
> hmm. in the image display protocol that kitty supports, everything can
> be done, if desired, in terms of rows and columns, and the terminal
> itself works, as far as i understand, in terms of character cells:
> couldn't we retain that modus operandi?

I think you misunderstand what Gerd proposed.  He proposed abandoning
the fixed-line-height assumption of the text-mode layout calculations.
Thus, TTY frames could have screen lines of variable height, although
their granularity will still be the height of the TTY character cell.

Once screen lines are of variable height, some of the advantages of
TTY display go away, because we no longer can assume that the next
or previous screen line is exactly one character cell away.

> for instance, displaying an image would amount (logically) to
> displaying a bunch of lines of text, all of the same length, with
> the only peculiarity that maybe the cells on the borders wouldn't
> look completely filled.

That won't work, because Emacs must know the screen layout; you cannot
lie to it with impunity.  For example, with your idea above, if point
is in the first line of a window, and you type C-n, and the next line
displays an image which takes more than one character cell's height,
then what will be the line number, as it's known to Emacs, when point
moves to that second line?  If you tell Emacs that there are 10 lines
of text in-between, instead of a single tall line, Emacs will think
the next line is line 11, whereas from the user POV it's line 2.

A lot of Emacs features depend on Emacs knowing exactly what's on the
screen, so you cannot easily lie to it about that.