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 15:56:35 +0100
> 
> Say that, in that line, i have an image, which emacs knows about because
> there's, say, a text property with 4 rows x 5 columns as the image
> extent (which we derive from knowing the image size and the terminal
> cell size, in pixels).  For movement and display purpose, we tell Emacs
> to interpret that as the block of pure text
> 
> xxxx
> xxxx
> xxxx
> xxxx
> xxxx
> 
> and emacs, initially, displays that, as a normal tty would, with point
> at the beginning of the block.  Now, it computes how many lines are
> visible after any required scrolling, and then asks kitty to draw, on
> the visible rectangle, the corresponding part of the image.
> 
> All movements and positioning would happen as if all that is being
> displayed are blocks of text.  Of course that means that line numbers
> won't treat images as spawning just one line, but several.  I find that
> actually an advantage from the user's point of view, because the images
> are taking more than one line in the glass, so to me it's very natural
> that emacs tells me that, at the beginning of the image, line is no. 2,
> and, at the end, line is no. 20.

But you do want to support text and images in the same buffer, don't
you?  So the following situation:

  tttttttttttttttttttt (1)
       IIIIIII
       IIIIIII
       IIIIIII
  tttt IIIIIII ttttttt (2)
  tttttttttttttttttttt (3)

where "t" is text is "I" is an image, should be supported, yes?  So
now, if point is on the top-most text line (1), and the user types
C-n, don't you want point to the text on the line that displays the
image, line (2)?  This is what happens on GUI frames, and I very much
doubt that users will be happy to see the cursor somewhere between
lines (1) and (2).  And even if they do like that, what would be the
position of point in that case, i.e. what will "C-x =" display?

> Yes.  I am proposing we tell emacs that what's on the screen is some
> lines of xs-text and making that, actually, true in every sense except
> that we also tell kitty to display those rows differently at the very
> end, when emacs is done with its text display duties.

That will break too much of both user expectations and Emacs features,
whereby every position on the screen where we put the cursor has some
buffer address.  What you suggest is a trick that may make display
easier (and I'm not even sure in this part), but it will require many
changes all over the rest of Emacs, because Emacs isn't prepared to
deal with such disconnect between the screen coordinates and the text
it displays.