From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Line wrap reconsidered Date: Fri, 19 Jun 2020 15:38:15 +0300 Message-ID: <83sgerxmbs.fsf@gnu.org> References: <92FF4412-04FB-4521-B6CE-52B08526E4E5@gmail.com> <878shfsq35.fsf@gnus.org> <83imgivjak.fsf@gnu.org> <83lfletr03.fsf@gnu.org> <4895C6EE-5E1F-44BF-93C1-CC5F7C096F73@gmail.com> <9766BA3D-B8F9-456B-9F59-60D21B86E390@gmail.com> <83sgfls2ul.fsf@gnu.org> <83v9kgq6jy.fsf@gnu.org> <5E75D1E2-8BFF-45DA-A643-40DBD5784508@gmail.com> <83r1v3qlel.fsf@gnu.org> <83blm6lzj3.fsf@gnu.org> <83pnakj8fs.fsf@gnu.org> <83k10sj60l.fsf@gnu.org> <0B30F8C8-9B8F-4FCB-B9FB-1B5A0E993CDB@gmail.com> <838sgjzij2.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="ciao.gmane.io:159.69.161.202"; logging-data="52776"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 14:40:58 2020 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 1jmGKH-000DdI-AV for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 14:40:57 +0200 Original-Received: from localhost ([::1]:37730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmGKG-0001ES-CH for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 08:40:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmGHs-0005yY-4Q for emacs-devel@gnu.org; Fri, 19 Jun 2020 08:38:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44841) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmGHr-00050U-Ow; Fri, 19 Jun 2020 08:38:27 -0400 Original-Received: from [176.228.60.248] (port=4157 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmGHr-0005SD-6Y; Fri, 19 Jun 2020 08:38:27 -0400 In-Reply-To: (message from Yuan Fu on Fri, 19 Jun 2020 08:04:47 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:252345 Archived-At: > From: Yuan Fu > Date: Fri, 19 Jun 2020 08:04:47 -0400 > Cc: Lars Ingebrigtsen , > emacs-devel@gnu.org > > > Maybe I don't understand the exact meaning of NOT_AT_EOL/NOT_AT_BOL > > that Kinsoku assigns to that. Can you provide a formal definition of > > that, or point me to some document where that is explained? > > Since kinsoku.el is for asian characters which are all LTR[1], the exact meaning of NOT_AT_EOL/NOT_AT_BOL in bidi context probably doesn’t really matter, but to make kinsoku retain the same behavior (thus looks right) in both RTL and LTR lines, I choose to define BOL as left edge and EOL as right edge. So NOT_AT_EOL means can’t be the right-most character in a line. > > From your message I thought in RTL lines the iterator draws from right to left (you said each glyph is prepended to the previous one). So in RTL context when we are at the end of a logical line, we are at the left edge; on the other hand, in normal LTR context when we are at the end of a logical line, we are at the right edge. Hence the flip. What do you mean by "in the RTL context"? Remember: bidi reordering can take place in two different situations: then the paragraph direction is left-to-right, and when it's right-to-left. In the former situation, the lines begin on the left, in the latter they begin on the right. But LTR text, such as CJK characters, will always be rendered left-to-right, no matter what is the paragraph direction. So which "RTL context" did you mean here? > As I mentioned above, I don’t think kinsoku cares/is defined for this situation. And I took the definition to assume strict LTR, mapping BOL to left and EOL to right. The ultimate effect is that, no matter what the bidi context is, NOT_AT_EOL character, like 《, never appears at the right edge. So we don’t get > > > 我今天看来了本书，感觉挺有意思，名字是《 > 钢铁是怎样炼成的》。 > > Instead, we have > > 我今天看来了本书，感觉挺有意思，名字是 > 《钢铁是怎样炼成的》。 What do you see in the text below? אבגד הוזחטיכך למנן 我今天看来了本书，感觉挺有意思，名字是 《钢铁是怎样炼成的》。 (I assume you are reading your email in Emacs; if not, copy/paste this text into an Emacs buffer whose bidi-paragraph-direction is nil, and look at the resulting display.) Does the above look correct, from the Kinsoku POV? This is how LTR CJK text will be displayed in a paragraph with right-to-left base direction. Do you still think something needs to be flipped here? > Now, is that mapping TRT for other characters? I don’t know. But I think it make sense for kinsoku (again, asian text, all LRT). IMHO, maybe for a generic definition we can define BOL as left edge for LTR character and right edge for RTL character. I think that will look good for most text. We must use BOL and EOL in their logical-order meanings, otherwise the result will be utter confusion. In the above example, the EOL character in the first line is 是, and it is not at the left edge of the line. It is at the logical-order end of the line, i.e. the character after it in the buffer position order is the newline. But if we had RTL characters instead of the CJK text above, the character at EOL would indeed have been displayed at the left edge of the line. > [1] There is also a top-down layout, but I don’t think we need to worry about that. Right.