From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Verticality and future of display engine and lines (bis) [Was: Re: RTL lines]
Date: Wed, 27 Oct 2021 21:58:47 +0300 [thread overview]
Message-ID: <838ryeuwew.fsf@gnu.org> (raw)
In-Reply-To: <3414507.SNmyYOu4Ja@galex-713.eu> (message from Alexandre Garreau on Wed, 27 Oct 2021 20:46:45 +0200)
> 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.
> 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.
next prev parent reply other threads:[~2021-10-27 18:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 12:40 RTL lines Alexandre Garreau
2021-10-18 13:18 ` Eli Zaretskii
2021-10-27 19:26 ` Alexandre Garreau
2021-10-28 6:04 ` Eli Zaretskii
2021-10-28 6:08 ` Alexandre Garreau
2021-10-28 7:03 ` tomas
2021-10-28 8:59 ` Eli Zaretskii
2021-10-27 14:50 ` Verticality and future of display engine and lines (bis) [Was: Re: RTL lines] Alexandre Garreau
2021-10-27 16:18 ` Eli Zaretskii
2021-10-27 18:46 ` Alexandre Garreau
2021-10-27 18:58 ` Eli Zaretskii [this message]
2021-10-27 19:54 ` Alexandre Garreau
2021-10-28 6:53 ` Eli Zaretskii
2021-10-28 7:12 ` Alexandre Garreau
2021-10-28 9:23 ` Eli Zaretskii
2021-10-28 14:40 ` Alexandre Garreau
2021-10-28 16:11 ` Eli Zaretskii
2021-10-28 7:18 ` Alexandre Garreau
2021-10-28 9:28 ` Eli Zaretskii
2021-10-28 14:28 ` Alexandre Garreau
2021-10-28 16:07 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838ryeuwew.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.