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: Sat, 30 May 2020 09:14:56 +0300 Message-ID: <83blm6lzj3.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> 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="96268"; 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 Sat May 30 08:15:59 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 1jeuml-000OwB-D9 for ged-emacs-devel@m.gmane-mx.org; Sat, 30 May 2020 08:15:59 +0200 Original-Received: from localhost ([::1]:57692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeumk-00060V-Ef for ged-emacs-devel@m.gmane-mx.org; Sat, 30 May 2020 02:15:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeulo-0004Vg-Tr for emacs-devel@gnu.org; Sat, 30 May 2020 02:15:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57014) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeulo-0001RN-Hr; Sat, 30 May 2020 02:15:00 -0400 Original-Received: from [176.228.60.248] (port=4256 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jeulo-0002yd-4a; Sat, 30 May 2020 02:15:00 -0400 In-Reply-To: (message from Yuan Fu on Fri, 29 May 2020 17:20:21 -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:251641 Archived-At: > From: Yuan Fu > Date: Fri, 29 May 2020 17:20:21 -0400 > Cc: Lars Ingebrigtsen , > emacs-devel@gnu.org > > > Then you'll need to augment the test > > > > else if (may_wrap) > > > > with a test that the current character can be at BOL. Maybe you > > should also make may_wrap a tristate instead of just a boolean YES/NO. > > > > I think I did jus that, i.e., if (may_wrap && char_can_wrap_before(it)). Fundamentally, yes. But having a complex condition if (FOO && BAR) makes the code harder to read and understand, and thus makes logical errors easier, than a simple condition like if (FOOBAR == some_value) > >> Essentially I want to ask “if may_wrap == true, what does that mean? (In bidi context)” Did the character to the left of me (on glass) set it or the character to the right of me set it? > > > > The one to the left. But it is not necessarily the "previous" > > character in buffer position order. > > I see, but then I don’t don’t understand how does the current code work with bidi display. In bidi context, space char can’t appear on the right of the line, which is the beginning of a logic line, right? That requires the logic to reverse. Is there something I’m missing? I think the cause of the confusion is the "in bidi context" part. There are two such "contexts", and they behave differently: . RTL characters when bidi-paragraph-direction is left-to-right . RTL characters when bidi-paragraph-direction is right-to-left Which one were you talking about? I was talking about the first one. > Since may_wrap’s meaning is in terms of left and right, it need to be reversed in bidi text, no? If bidi-paragraph-direction is right-to-left, then yes, they are reversed. But not if the paragraph direction is left-to-right. > One more question. If I type 123456789... and set bidi-paragraph-direction to ‘right-to-left, it is still 123456789…, just aligned to the right. I expected to see …987654321, that’s what right-to-left mean in Chinese text. Why the order of each character not revered? Digits and LTR characters (like English text) are rendered left-to-right even in RTL paragraphs, so what you see is correct. That's why this is called "bidirectional": the direction is not just universally right-to-left. > UAX#9 didn’t say anything helpful. It does, albeit in a convoluted and hard-to-grasp way. See paragraph 3.3.6 there, and then rule L2 in paragraph 3.4, which describes the reordering procedure.