[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Verticality and future of display engine and lines (bis) [Was: Re: RTL lines]
Date: Wed, 27 Oct 2021 21:58:47 +0300

> From: Alexandre Garreau <>
> Cc:
> 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.

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]