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: Fri, 30 Sep 2022 01:27:01 +0530 Message-ID: References: <83r13sttj6.fsf@gnu.org> <87wndi6xau.fsf@yahoo.com> <83mtebq0nd.fsf@gnu.org> <838rmtelfg.fsf@gnu.org> <83leqr9pb4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000860ab405e9d648f6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35325"; 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 Thu Sep 29 21:58:05 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 1odzfX-00092z-Dl for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Sep 2022 21:58:03 +0200 Original-Received: from localhost ([::1]:41426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odzfW-0000o9-HO for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Sep 2022 15:58:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odzen-00084E-7k for emacs-devel@gnu.org; Thu, 29 Sep 2022 15:57:17 -0400 Original-Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]:42509) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odzek-00045f-8b; Thu, 29 Sep 2022 15:57:15 -0400 Original-Received: by mail-yb1-xb29.google.com with SMTP id k3so1028845ybk.9; Thu, 29 Sep 2022 12:57:13 -0700 (PDT) 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; bh=mURtixe8/m34Chc0k7MKxG80mjo3Xp4vMjDm+bKGhHM=; b=Jt1Vb6iCLfriYR6hpaUAZ9XqYSDd/W08s2u9YgHTKmht5oyHN1pxWooCa7R3ogFxGq gTFI+rVFiXeXCroVAv8RVXCGhU2tI9bXpoSgaw8rlodbsxAz+S1mVBDBOT/xbzINRrVV 521gLDEO5BmOl6DnCoSAlVRq2cFu+8RDFJ6ZWe1IvIqObW337z3RXlmPX623d1pOK9dF qY8aHm1ZIMotBrzfUPajfWYdJZlNYw+NoRzNyJxsqVtk+tC/G1ZfalobJ78nHCLCs+rY z8je0pPwSa+mt4BGIs94ld3HnZOxawpK0KdPE2QKJ304Yf8lvq9rrHvvwYABT2ZNvcv0 ClBw== 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; bh=mURtixe8/m34Chc0k7MKxG80mjo3Xp4vMjDm+bKGhHM=; b=Q1XktDApJAD4d7bl33mVB9DGoUQFgAwtoNHAOgGwfp7EfVfkuJ+iSMecVoAlASof7C f6G4vbUJts49S2DgflXGrimv3E7VlyGHO8xXlpZ35hDRZVQxDP6AszSCSAqGB8TeAUHA TLBa5eY5JSfxfw9JyxZLbG6ZbKLEdKPhi6ljyAj392H14wtU8RZWtftndi8bRQ90N1Lm meaaasS7ZA/LkyylmiQbTSE+yORZOIiqjIhjPDuJEqwuZqsudG/pcHUVqKE2bUx6/B7h aHTqBypw4WiNCYHO3L8TAIDU2G2/X4l6E2zjqOR0uB4jVWGl0C7XyMRVgEhzms400k+G LNTA== X-Gm-Message-State: ACrzQf2UqLdcyaPJZG3AJafSp44OqhRYRH4jLyKWCRYyrUQEkGzFLF/T u4HFiJ8Nq9zRuuRvVEKq+ofzRkdvIgf/LbdqcWOgeKC6DtLnNMhr X-Google-Smtp-Source: AMsMyM4+/qin8unySpAMcKv9xzQ3Z19TogamM4knF8FC31I9WhULq1UnIZIIxUyTUoP68vkqnDvgguD6ImpvhwrEe/0= X-Received: by 2002:a25:37ce:0:b0:6b6:41a8:9df with SMTP id e197-20020a2537ce000000b006b641a809dfmr5041973yba.251.1664481432569; Thu, 29 Sep 2022 12:57:12 -0700 (PDT) In-Reply-To: <83leqr9pb4.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::b29; envelope-from=lumarzeli30@gmail.com; helo=mail-yb1-xb29.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" Xref: news.gmane.io gmane.emacs.devel:296484 Archived-At: --000000000000860ab405e9d648f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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 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) Thanks On Sat, Sep 10, 2022 at 9:47 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: Sat, 10 Sep 2022 21:23:32 +0530 > > Cc: emacs-devel@gnu.org > > > > In order to find the "real meat" of the display_line function I started > to slowly remove most of the lines of the > > function as long as it does not break emacs and text can be typed. > > > > In the end I was left with this a 20-25 lines function (excluding > comments and spaces): > > (I have attached this function too) > > > > static bool > > display_line (struct it *it, int cursor_vpos) > > { > > struct glyph_row *row =3D it->glyph_row; > > > > /* Clear the result glyph row and enable it. */ > > prepare_desired_row (it->w, row, false); > > > > row->y =3D it->current_y; > > > > /* Loop generating characters. The loop is left with IT on the next > > character to display. */ > > while (true) > > { > > > > /* Retrieve the next thing to display. Value is false if end of > > buffer reached. */ > > if (!get_next_display_element (it)) > > { > > break; > > } > > > > PRODUCE_GLYPHS (it); > > > > at_end_of_line: > > /* Is this a line end? If yes, we're also done, after making > > sure that a non-default face is extended up to the right > > margin of the window. */ > > if (ITERATOR_AT_END_OF_LINE_P (it)) > > { > > /* Consume the line end. This skips over invisible lines. */ > > set_iterator_to_next (it, true); > > break; > > } > > > > set_iterator_to_next (it, true); > > } > > > > /* Compute pixel dimensions of this line. */ > > compute_line_metrics (it); > > > > /* Prepare for the next line. This line starts horizontally at (X > > HPOS) =3D (0 0). Vertical positions are incremented. As a > > convenience for the caller, IT->glyph_row is set to the next > > row to be used. */ > > > > it->current_y +=3D row->height; > > ++it->glyph_row; > > return MATRIX_ROW_DISPLAYS_TEXT_P (row); > > } > > > > Obviously most of the things do not work such as bidi, word wrapping, > displaying cursor and line numbers but > > still text is being shown > > in rows one after the other and it can be scrolled, but now there are n= o > lines mentioning the hpos, the > > x-coordinate, first_visible_x or > > last_visible_x, does that mean I do not understand the display_line > function? I thought its function was to fill a > > row with glyphs in the desired matrix > > to display it on the glass but now I cannot find a line which fills the > matrix. > > That hides behind the PRODUCE_GLYPHS macro. > > > You had advised to swap the x and y > > coordinates, but here there > > is no x coordinate present! How can the redisplay still work? > > display_line also makes the decisions when the screen line is full and > the rest should be on the next screen line this is one of its most > important roles. But you have removed that code, so you don't see it > in what's left. The parts that deal with the X coordinate that > exceeds last_visible_x are those which make that decision. > --000000000000860ab405e9d648f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Before y= ou 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 colum= n wise order?
I looked at gui_produce_glyphs and that led me to a= ppend_glyph, but I could not figure out how the glyphs are produced.
<= div>There is also draw_glyphs but I think working with that will require ed= iting the low level *term files (if it even is the right function)

Thanks

On Sat, Sep 10, 2022 at 9:47 PM Eli Zarets= kii <eliz@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: Sat, 10 Sep 2022 21:23:32 +0530
> Cc: emacs-dev= el@gnu.org
>
> In order to find the "real meat" of the display_line functio= n I started to slowly remove most of the lines of the
> function as long as it does not break emacs and text can be typed.
>
> In the end I was left with this a 20-25 lines function (excluding comm= ents and spaces):
> (I have attached this function too)
>
> static bool
> display_line (struct it *it, int cursor_vpos)
> {
>=C2=A0 =C2=A0struct glyph_row *row =3D it->glyph_row;
>=C2=A0
>=C2=A0 =C2=A0/* Clear the result glyph row and enable it.=C2=A0 */
>=C2=A0 =C2=A0prepare_desired_row (it->w, row, false);
>
>=C2=A0 =C2=A0row->y =3D it->current_y;
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0/* Loop generating characters.=C2=A0 The loop is left with= IT on the next
>=C2=A0 =C2=A0 =C2=A0 character to display.=C2=A0 */
>=C2=A0 =C2=A0while (true)
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Retrieve the next thing to display.=C2=A0= Value is false if end of
> buffer reached.=C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!get_next_display_element (it))
> {
>=C2=A0 break;
> }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PRODUCE_GLYPHS (it);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0at_end_of_line:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Is this a line end?=C2=A0 If yes, we'= re also done, after making
> sure that a non-default face is extended up to the right
> margin of the window.=C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ITERATOR_AT_END_OF_LINE_P (it))
> {=C2=A0
>=C2=A0 /* Consume the line end.=C2=A0 This skips over invisible lines.= =C2=A0 */
>=C2=A0 set_iterator_to_next (it, true);
>=C2=A0 break;
> }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0set_iterator_to_next (it, true);
>=C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0/* Compute pixel dimensions of this line.=C2=A0 */
>=C2=A0 =C2=A0compute_line_metrics (it);
>
>=C2=A0 =C2=A0/* Prepare for the next line.=C2=A0 This line starts horiz= ontally at (X
>=C2=A0 =C2=A0 =C2=A0 HPOS) =3D (0 0).=C2=A0 Vertical positions are incr= emented.=C2=A0 As a
>=C2=A0 =C2=A0 =C2=A0 convenience for the caller, IT->glyph_row is se= t to the next
>=C2=A0 =C2=A0 =C2=A0 row to be used.=C2=A0 */
>
>=C2=A0 =C2=A0it->current_y +=3D row->height;
>=C2=A0 =C2=A0++it->glyph_row;
>=C2=A0 =C2=A0return MATRIX_ROW_DISPLAYS_TEXT_P (row);
> }
>
> Obviously most of the things do not work such as bidi, word wrapping, = displaying cursor and line numbers but
> still text is being shown
> in rows one after the other and it can be scrolled, but now there are = no lines mentioning the hpos, the
> x-coordinate, first_visible_x or
> last_visible_x, does that mean I do not understand the display_line fu= nction? I thought its function was to fill a
> row with glyphs in the desired matrix
> to display it on the glass but now I cannot find a line which fills th= e matrix.

That hides behind the PRODUCE_GLYPHS macro.

> You had advised to swap the x and y
> coordinates, but here there
> is no x coordinate present! How can the redisplay still work?

display_line also makes the decisions when the screen line is full and
the rest should be on the next screen line this is one of its most
important roles.=C2=A0 But you have removed that code, so you don't see= it
in what's left.=C2=A0 The parts that deal with the X coordinate that exceeds last_visible_x are those which make that decision.
--000000000000860ab405e9d648f6--