From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Implementing Vertical Text support in Emacs Date: Fri, 30 Sep 2022 09:30:18 +0300 Message-ID: <83v8p5e5mt.fsf@gnu.org> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19895"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuSBTYW1lZXIgU2luZ2g=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 30 08:31:55 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 1oe9Yw-00052I-Kc for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 08:31:54 +0200 Original-Received: from localhost ([::1]:43582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oe9Yv-000381-3C for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 02:31:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oe9Xd-0002LP-3g for emacs-devel@gnu.org; Fri, 30 Sep 2022 02:30:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oe9Xc-0005rE-Rs; Fri, 30 Sep 2022 02:30:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6895CdhDOe+TOXO26zZ7poREa2Qjrazf31GVBc6eX3I=; b=Vj9bA3ecLVRPNxzYao2S eFm1E3htFPNfAYV3U2aajvHz7xlUQsSsbef9y5zR76zjM8sB/SXa2AAbLrq0ezN7M7ZSExvRFZJly GLhiD36jFtoZdgdvjKe7qdH8B2eiFjuuynTrmwJVAIHcPum0ARycs9+EpWrc+rmDoKQGf+8QpO/9d NBhj0J/jA1QJQCAeE1tjDgEyj1dPaxfKTM2yNOYMoLKCu4z+9JGSYrdySlZk1j0eVxo6llemEckwe LQNVEZL3qq1OdD4Wo7lGkw/G8BHU4N+4UZ2T+tyGn+rG/IZCj7o/tutvx6zThZbG1m1k6vAvhM8qI fECyjncuU2Mc/w==; Original-Received: from [87.69.77.57] (port=3581 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oe9Xb-0000Sq-Tn; Fri, 30 Sep 2022 02:30:32 -0400 In-Reply-To: (message from =?utf-8?B?4KS44KSu4KWA4KSwIOCkuOCkv+CkguCkuQ==?= Sameer Singh on Fri, 30 Sep 2022 01:27:01 +0530) 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:296494 Archived-At: > From: समीर सिंह 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.