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 20:47:27 +0300 Message-ID: <83bllfx80g.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> <83sgerxmbs.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="105628"; 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 19:53:09 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 1jmLCP-000RLR-Mf for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 19:53:09 +0200 Original-Received: from localhost ([::1]:51298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmLCO-0005vY-MP for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 13:53:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmL76-0002WE-Gu for emacs-devel@gnu.org; Fri, 19 Jun 2020 13:47:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52306) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmL76-0002Zd-48; Fri, 19 Jun 2020 13:47:40 -0400 Original-Received: from [176.228.60.248] (port=3291 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmL75-0004ly-8o; Fri, 19 Jun 2020 13:47:39 -0400 In-Reply-To: (message from Yuan Fu on Fri, 19 Jun 2020 13:22:18 -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:252385 Archived-At: > From: Yuan Fu > Date: Fri, 19 Jun 2020 13:22:18 -0400 > Cc: Lars Ingebrigtsen , > emacs-devel@gnu.org > > > 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? > > Oooh so there are four cases: LRT text in LTR paragraph, LRT text in RTL paragraph, RTL text in RTL paragraph, and RTL text in LTR paragraph. And the order in which the iterator draws glyphs depends on the paragraph order (although it doesn’t know it). Am I right? You can say that there are 4 cases, yes. But from the iterator POV, there are only 2: either the text of the same direction as the paragraph, or of the opposite direction. > > אבגד הוזחטיכך למנן 我今天看来了本书，感觉挺有意思，名字是 > > 《钢铁是怎样炼成的》。 > > > > (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? > > Kinsoku looks right, yes. However the period (“。”) seems to be interpreted as RTL text, not sure why. That's expected, since the period has a "weak directionality", so at the end of the paragraph it takes the paragraph direction. > > 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. > > > > I see. However, I suggest to define EOL and BOL (in kinsoku) in terms of visual edges, instead of the logical order. Because we are using this information (NOT_AT_BOL, etc) for visual layout. When we are at a window edge and ask if this character can appear at this edge, we are interested in the visual aspect rather than the logical order, if you get what I mean. If that works, then fine. > BTW, what does it->bidi_p mean exactly? Does it mean bidi-display-reordering is t, or current paragraph is ‘right-to-left, or the char at point is RTL, or something else? It means bidi reordering is in effect. For displaying buffer text, it is determined by bidi-display-reordering. > Can I know whether I’m at the left edge or the right edge? You can, but why do you need to?