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

[Alexandre Garreau]

Le mercredi 27 octobre 2021, 20:58:47 CEST Eli Zaretskii a écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Cc: help-gnu-emacs@gnu.org
> > Date: Wed, 27 Oct 2021 20:46:45 +0200
> > 
> > > > Anyway, what would a such change require and how much would it
> > > > overturn the current display engine?
> > > 
> > > The low level of the display engine will need to acquire a set of
> > > routines that work very differently from what we have there now.
> > > 
> > > And I don't even understand what is being expected from this.  E.g.,
> > > what happens when the user scrolls the window up or down?  Do all
> > > the
> > > columns change like a snake?
> > 
> > I expect a full TTB buffer to behave exactly as a LTR one but turned
> > 90° and portrait-like instead of landscape-like (like a screen
> > usually is)
> > 
> > Hence to see the rest of buffer, instead of scrolling up/down, the
> > user
> > would scroll left/right.
> 
> So you are not only talking about a revolution in the display engine,
> you are also talking about a revolution in scrolling commands.

That’s less than half a dozen of commands and the change is trivial, it’s 
just level of abstraction.

> > Interestingly, this is an already existing behavior within emacs, and
> > that question arises under any powerful-enough unicode-supporting
> > display: if you add a lot of dı̇̇̇̇̇̇̇̇̇̇̇̇̇̇̇̇acritics (like here)
> > on a character, the line becomes taller to contain it (most of other
> > software than emacs actually either fails (most often) to display
> > more than one diacritic (erroneously, since this is a necessary
> > display feature for some writing systems (such as vietnamese,
> > afair)), or (rarely, or only with Qt in textareas) overdisplays the
> > diacritics over the above lines, screenshot (Qt/KMail, GTK/Emacs)
> > attached).
> 
> I don't see any excess height of the lines, I think if you see that in
> Emacs, you have a faulty font or something.

Did you really look at the screenshots? don’t you see all the blank 
between the lines?

> > Interestingly, other GTK software than emacs just
> > fails to display several diacritic one on top of each other, and just
> > surimpress them all at the same place (so it’s unreadable), so emacs
> > performs just better than bare gtk alone.
> 
> Showing just one diacritic is TRT in this case.  Anything else is a
> display bug.

So how do you display languages which *need* several diacritics?

> > Btw it would be nice if emacs supported such tweaking of
> > directionality
> > (although my friend wouldn’t benefit from it since he’s a user of vim,
> > but I’m pretty sure that would be a point in advertising emacs to
> > him).
> You can have this with special bidirectional formatting control
> characters, like LRO and RLO.  Emacs supports them.

Yes I know but I mean to have that systematically without having to 
manually enter them at each script change (and avoiding to put them in a 
possibly shared file with people with different opinions regarding 
directionality)

> > > > would a solution to that problem possibly cover up with the
> > > > problem
> > > > I raised in the other almost-homonym thread?
> > > 
> > > Which is what?
> > 
> > “Future of display engines and lines”, where I started talking about
> > multicolumn and that continued about sub-buffers, evolving the display
> > engine, how web engines wouldn’t last long enough, etc.
> 
> No, that's an entirely different problem that would need an entirely
> different solution.

Ok.