Re: Verticality and future of display engine and lines (bis) [Was: Re: RTL lines]

[Eli Zaretskii <eliz@gnu.org>]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 28 Oct 2021 09:12:38 +0200
> 
> > I guess you are unaware, or perhaps forgot, that the display engine
> > itself scrolls the window when it finds that necessary.
> 
> oh… but still that’s a few functions right…? I hope… like “scroll down” 
> and “scroll up” calls that should be conditionally changed to “scroll 
> forward” and “scroll backward”

I guess you think that scrolling, in whatever direction, is a simple
business.  It isn't; what those "few functions" do has a lot of
implicit assumptions, most of them will be wrong with the change of
direction.  Someone(TM) will have to come up with the necessary logic
that doesn't exist, and make it support all the scroll-related
features we have, like scroll-step, scroll-conservatively,
scroll-up/down-aggressively, scroll-preserve-screen-position, etc.
And then the low-level code which scrolls the screen by moving pixels
will have to be rethought as well.

> > > Did you really look at the screenshots? don’t you see all the blank
> > > between the lines?
> > 
> > I'm talking about what I see in my Emacs session where I read your
> > email.  If any Emacs session displays that as you describe, that's
> > either a font configuration problem or some rendering bug that isn't
> > present in my build of Emacs.
> 
> But did you look at the screenshots? doesn’t your gnus support simple and 
> direct display of mime attachments?

(I don't use Gnus.)  Of course, I looked at them.  Why do you ask?
they look like display bugs to me, as I said.

> > and I'm not even sure I understand why would you like to
> > do something like that.
> 
> I already said it was to make reading more comfortable without having to 
> lump from one part of the text to another, read, and yet again go there to 
> resume reading, so the direction of reading is always consistent (and 
> ideally to have even less jumping, one would need to use boustrophedon as 
> a script direction, but afaik no existing software supports that)

I cannot imagine it will be easy to read an RTL text that wasn't
reordered for display.  You'd have to read it one character at a time,
something that is extremely slow.