Re: Implementing image support for kitty terminal

[Jose A Ortega Ruiz]

On Fri, Sep 09 2022, Eli Zaretskii wrote:

[...]

> 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?

no, not necessarily.  i'd be already pretty happy even if that wouldn't
be possible. for my uses cases, rendering that as

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

would be good enough.  moreover, there are few cases of images inserted
by even current graphical emacs (at least in my use cases) with text
flowing on the sides (i remember even having to advice eww at some point
to get inline images).

> 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?

well, i cannot speak for other users.  for me, something like the above,
even if far from perfect, would be a big improvement over no images at
all.

>> 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.

fair enough.  that's the kind of warning i was looking for, to avoid
wasting time chasing wild geese.  if even an imperfect hack is going to
need such an effort, it's not worth it.

thanks,
jao
-- 
There are two ways to write error-free programs; only the third one
works.
  - Alan Perlis, Epigrams on Programming