From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuSBTYW1lZXIgU2luZ2g=?= Newsgroups: gmane.emacs.devel Subject: Re: Implementing Vertical Text support in Emacs Date: Sun, 20 Nov 2022 16:48:31 +0530 Message-ID: References: <83r13sttj6.fsf@gnu.org> <87wndi6xau.fsf@yahoo.com> <83mtebq0nd.fsf@gnu.org> <838rmtelfg.fsf@gnu.org> <83leqr9pb4.fsf@gnu.org> <83v8p5e5mt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fba4b605ede519b0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 20 12:19:39 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1owiMM-000ANF-TK for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Nov 2022 12:19:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owiLd-0007JL-Nl; Sun, 20 Nov 2022 06:18:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owiLY-0007J8-3o for emacs-devel@gnu.org; Sun, 20 Nov 2022 06:18:48 -0500 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owiLV-0000MC-7N; Sun, 20 Nov 2022 06:18:47 -0500 Original-Received: by mail-pf1-x435.google.com with SMTP id v28so8902078pfi.12; Sun, 20 Nov 2022 03:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ao9t14WmTYsYQtkgaCwRHnV61MpRBv9hIhQBEO14Jro=; b=iog0XByPIvVhoUFVYoQincsqQReZATjVd93kPJyxiyQjV4Z4CaS7nzCy8rYjePx8OV oI/RTEeJxyi9NRHz1ppBrWBYxcNQqi7QNDzCnGqFDCmDmmVuHBFNJCrVjtYCVdmkh9pP w8A57uUU3q8eJgRBsggvFWOmYkxxFdxj/DSeUMOSBu1t7mOCJhDjptvCi8SFlKKXpCiS yhQJ1kpcA9DEqB0Wi7b7hzE7Off+6xyjL41CkUruj5X3aanynx9nvN+JHgYhmuwzFc3a 9L/n5i6g/PXawG+NVY5k3+3IVGWdbSXsZ6Pb0QErZiYQXeK7pejTAY+j/6jlUyYafDHS +64g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ao9t14WmTYsYQtkgaCwRHnV61MpRBv9hIhQBEO14Jro=; b=p0t1kO6Sj2Hdm6R/KZxK7sSXNDiPIrg9O78xrmGBm1An//+ULGsoTLLynebM30z4DF Fu5hYJ++EMSJz5GnfauQTX8wS9O3CYvYDC4Fz+MsZA8ZhG0PE5D36WWEgx5LMPCurAmn K68k8QN2Epi8oXjPumdvqi/YdmXKGlSY5QW7DZN0yzDqzJxq8KdcGdI1YiMz6BXnSzNq ADPrqn/YQYY+o7Kv6vDEDaxmm1Y392/OctHqbkKje3jOg1uFQYVJOZMBlL10Z22etC3q pukvp7QZaIJDcKcTeB8DhxryYi+NhzTBZXI20xq/ipQEj3VyPRkcDhdapMak7susy5f4 lSFw== X-Gm-Message-State: ANoB5plQsNNgiBjMvr6LeC9cR9ubak2oYQnVeU3EOCNfoWFKEksi6/VA WdLVPPchCjeB6WC0Jo5gM8u0E7kMUMO16cmLvlZikIjL X-Google-Smtp-Source: AA0mqf5zQF6J8svQJVVhHSnLCk2EH3frzlRfX6bHfBDDzayPB6EfDRi+cMEo8FFp02/7xE/NkOB+PDBxVfm1y/T9FHQ= X-Received: by 2002:a63:4614:0:b0:46f:8982:cc8a with SMTP id t20-20020a634614000000b0046f8982cc8amr3389561pga.110.1668943122767; Sun, 20 Nov 2022 03:18:42 -0800 (PST) In-Reply-To: <83v8p5e5mt.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::435; envelope-from=lumarzeli30@gmail.com; helo=mail-pf1-x435.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300239 Archived-At: --000000000000fba4b605ede519b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I tried writing a vertical version of the display_line function but could not get it to work. Emacs does not display any character after these changes. (maybe I should have also rewrote move_it_in_display_line_to?) Therefore forgive me for asking again, if for now I just want to make the characters appear column wise instead of row wise, disregarding line overflow, or termination of a line etc, do I still have to look into the display_line function, because as I recall I had once removed most of the lines of the display_line function and Emacs was still displaying lines fines. Again, thank you for your patience. On Fri, Sep 30, 2022 at 12:00 PM Eli Zaretskii wrote: > > From: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 =E0=A4=B8=E0=A4=BF=E0=A4=82= =E0=A4=B9 Sameer Singh > > Date: Fri, 30 Sep 2022 01:27:01 +0530 > > Cc: emacs-devel@gnu.org > > > > Before you modify display_line, you need to decide how will the > > vertical-layout display produce glyphs. > > > > Can you please expand more on this? > > How to produce glyphs in a column wise order? > > I did that in the original message. Quoting myself: > > Before you modify display_line, you need to decide how will the > vertical-layout display produce glyphs. The easiest would be to > produce them in column-wise order, because that basically processes > the buffer in the order of character positions, like Emacs does now. > This will allow you to leave the lower levels, which walk the buffer > and deliver characters, mostly intact. > > So perhaps you should have a display_column function, which will look > like display_line, but instead of advancing the X coordinate, it will > advance the Y coordinate, and produce a single column, top to bottom. > Then the basic calculations should be the same as in display_line, > except the column ends when it reaches last_visible_y instead of > last_visible_x. IOW, the glyph matrices will be made of glyph columns > instead of glyph rows. Basically, the roles of the X and the Y > coordinates will be swapped. > > > I looked at gui_produce_glyphs and that led me to append_glyph, but I > could not figure out how the glyphs are > > produced. > > There is also draw_glyphs but I think working with that will require > editing the low level *term files (if it even is > > the right function) > > I didn't mean gui_produce_glyphs and its subroutines, I mean the logic > of how glyphs are produced, as described above, in display_line > itself. The current code in display_line produces glyph of a single > screen line, in visual order, from left to right. Above I suggested > to write a similar display_column function, which will produce glyphs > of a single column, top to bottom, and will make the decisions > regarding when the column is full and should be terminated, like > display_line does with respect to screen lines. Does this sounds like > a good approach to you? > > If the approach sounds good, but something in my description is > unclear, please ask more specific questions about those unclear parts > of what I wrote. > --000000000000fba4b605ede519b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tried writing a vertical version of the display_lin= e function but could not get it to work. Emacs does not display any charact= er after these changes.
(maybe I should have also rewrote move_it= _in_display_line_to?)

Therefore forgive me for ask= ing again, if for now I just want to make the characters appear column wise= instead of row wise, disregarding line overflow, or termination of a line = etc,
do I still have to look into the display_line function, beca= use as I recall I had once removed most of the lines of the display_line fu= nction and Emacs was still displaying lines fines.

Again, thank you for your patience.

On Fri, Sep 30, 2022 at 12:00= PM Eli Zaretskii <eli= z@gnu.org> wrote:
> From: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 =E0=A4=B8=E0=A4= =BF=E0=A4=82=E0=A4=B9 Sameer Singh <lumarzeli30@gmail.com>
> Date: Fri, 30 Sep 2022 01:27:01 +0530
> Cc: emacs-dev= el@gnu.org
>
>=C2=A0 Before you modify display_line, you need to decide how will the<= br> >=C2=A0 vertical-layout display produce glyphs.
>
> Can you please expand more on this?
> How to produce glyphs in a column wise order?

I did that in the original message.=C2=A0 Quoting myself:

=C2=A0 Before you modify display_line, you need to decide how will the
=C2=A0 vertical-layout display produce glyphs.=C2=A0 The easiest would be t= o
=C2=A0 produce them in column-wise order, because that basically processes<= br> =C2=A0 the buffer in the order of character positions, like Emacs does now.=
=C2=A0 This will allow you to leave the lower levels, which walk the buffer=
=C2=A0 and deliver characters, mostly intact.

=C2=A0 So perhaps you should have a display_column function, which will loo= k
=C2=A0 like display_line, but instead of advancing the X coordinate, it wil= l
=C2=A0 advance the Y coordinate, and produce a single column, top to bottom= .
=C2=A0 Then the basic calculations should be the same as in display_line, =C2=A0 except the column ends when it reaches last_visible_y instead of
=C2=A0 last_visible_x.=C2=A0 IOW, the glyph matrices will be made of glyph = columns
=C2=A0 instead of glyph rows.=C2=A0 Basically, the roles of the X and the Y=
=C2=A0 coordinates will be swapped.

> I looked at gui_produce_glyphs and that led me to append_glyph, but I = could not figure out how the glyphs are
> produced.
> There is also draw_glyphs but I think working with that will require e= diting the low level *term files (if it even is
> the right function)

I didn't mean gui_produce_glyphs and its subroutines, I mean the logic<= br> of how glyphs are produced, as described above, in display_line
itself.=C2=A0 The current code in display_line produces glyph of a single screen line, in visual order, from left to right.=C2=A0 Above I suggested to write a similar display_column function, which will produce glyphs
of a single column, top to bottom, and will make the decisions
regarding when the column is full and should be terminated, like
display_line does with respect to screen lines.=C2=A0 Does this sounds like=
a good approach to you?

If the approach sounds good, but something in my description is
unclear, please ask more specific questions about those unclear parts
of what I wrote.
--000000000000fba4b605ede519b0--