From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Line wrap reconsidered Date: Sun, 31 May 2020 13:39:56 -0400 Message-ID: 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> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="87258"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 31 19:47:00 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 1jfS32-000MaH-E4 for ged-emacs-devel@m.gmane-mx.org; Sun, 31 May 2020 19:47:00 +0200 Original-Received: from localhost ([::1]:60814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfS31-0007h2-Ed for ged-emacs-devel@m.gmane-mx.org; Sun, 31 May 2020 13:46:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfRwI-0006iB-EN for emacs-devel@gnu.org; Sun, 31 May 2020 13:40:02 -0400 Original-Received: from mail-qv1-xf30.google.com ([2607:f8b0:4864:20::f30]:39694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jfRwG-0004sY-8f; Sun, 31 May 2020 13:40:02 -0400 Original-Received: by mail-qv1-xf30.google.com with SMTP id r16so3441439qvm.6; Sun, 31 May 2020 10:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g9+mquKi/PlmJWG4PxK8vNXeMcvWcUBzrHpgz9Nf1wU=; b=lwI8VZ0Azw7TgXR+KWef5jhq4vPdMD8JT0w3CnziJLbdpbGnKJ2l+nvz0MYw3LfvVg 9ZQEwqVi9ruTxdMZGfWNSTeNcfzd+VFP0OY62sDyLMAlpH0EVgEHmN6OLzgaQEJ5DItW eHJ1c+pO2IFmqpoc/569yAGNInDrn9FlaCrZL/OKtiTTSUmnGTyjsz9qfpV4HSy08wsB YoT1R72D6CTVTXMGJmoLGiC/I5LRZv2c2TQFU5uqS2F7cuKoQy5PwroRotZKU0FneBKQ OUq0ipyedQgypH671IgXhuf5Lv/NLIo/0DuROUteWUeLwlpoU4bqbpe0OdLqwvyrWKuC y22Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g9+mquKi/PlmJWG4PxK8vNXeMcvWcUBzrHpgz9Nf1wU=; b=hX9V4Udg9sWr8Iy4aeN/jQP+KWHBICKZRJo8/LFAE1B5TGtUPjHJjmYe2sV92pDwpT qAejIdcE3JgNMaoCEiIDjucz0Gw3GYRHE5PHsOAAcvqqV9OYmGvlN08D4rPxLhsasVDE icYN8hgA8Wbctrzehes4WKxacnEtFzKvQA9EDbjxi5Zl9k760cEZbi8FcM6UF0+3UpSM 7V44xALaF2lsdPvkwgqn0zdLnSID7yog96KYS9OkmAGMQjfg9/P139YOcAK/gLJfXB6N bctJjIMOjh23HuHE1mVKW3EL50uKgVnqddkrKU3aiEiwiwxzrrhmA3R6H2o6qo0BeA+g QoUw== X-Gm-Message-State: AOAM532TkQVjbmJ5e7k6BwA198QbbuxzPvjVxU6/TMzZ68eikDRX4TEL gatndKy+2GAay2H0wuo4kGK6spSM0BNJOA== X-Google-Smtp-Source: ABdhPJz8tu/J6MVb8gFIw4QwbWn1tAUWBkGIsTFGqxzj14XmqY6TIFPhxSOyvBX/4adiE8q1mGHvBA== X-Received: by 2002:a0c:e7cc:: with SMTP id c12mr17675358qvo.231.1590946797925; Sun, 31 May 2020 10:39:57 -0700 (PDT) Original-Received: from ?IPv6:2601:98a:4200:9210:5a2:64f5:33b3:2c87? ([2601:98a:4200:9210:5a2:64f5:33b3:2c87]) by smtp.gmail.com with ESMTPSA id x13sm1575803qkj.36.2020.05.31.10.39.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2020 10:39:57 -0700 (PDT) In-Reply-To: <83blm6lzj3.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::f30; envelope-from=casouri@gmail.com; helo=mail-qv1-xf30.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:251688 Archived-At: > On May 30, 2020, at 2:14 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Fri, 29 May 2020 17:20:21 -0400 >> Cc: Lars Ingebrigtsen , >> emacs-devel@gnu.org >>=20 >>> Then you'll need to augment the test >>>=20 >>> else if (may_wrap) >>>=20 >>> 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. >>>=20 >>=20 >> I think I did jus that, i.e., if (may_wrap && = char_can_wrap_before(it)). >=20 > Fundamentally, yes. But having a complex condition >=20 > if (FOO && BAR) >=20 > makes the code harder to read and understand, and thus makes logical > errors easier, than a simple condition like >=20 > if (FOOBAR =3D=3D some_value) In principle, yes, but I doubt the current logic can be simplified. Do = you have some concrete example? >=20 >>>> Essentially I want to ask =E2=80=9Cif may_wrap =3D=3D true, what = does that mean? (In bidi context)=E2=80=9D Did the character to the left = of me (on glass) set it or the character to the right of me set it? >>>=20 >>> The one to the left. But it is not necessarily the "previous" >>> character in buffer position order. >>=20 >> I see, but then I don=E2=80=99t don=E2=80=99t understand how does the = current code work with bidi display. In bidi context, space char can=E2=80= =99t 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=E2=80=99m missing? >=20 > I think the cause of the confusion is the "in bidi context" part. > There are two such "contexts", and they behave differently: >=20 > . RTL characters when bidi-paragraph-direction is left-to-right > . RTL characters when bidi-paragraph-direction is right-to-left >=20 > Which one were you talking about? I was talking about the first one. >=20 >> Since may_wrap=E2=80=99s meaning is in terms of left and right, it = need to be reversed in bidi text, no? >=20 > If bidi-paragraph-direction is right-to-left, then yes, they are > reversed. But not if the paragraph direction is left-to-right. Then does bidi.c handle word wrapping when bidi-paragraph-direction is = right-to-left? Paragraph 3.4 mentioned that =E2=80=9CThe accumulated = widths of those glyphs (in logical order) are used to determine line = breaks.=E2=80=9D >=20 >> One more question. If I type 123456789... and set = bidi-paragraph-direction to =E2=80=98right-to-left, it is still = 123456789=E2=80=A6, just aligned to the right. I expected to see = =E2=80=A6987654321, that=E2=80=99s what right-to-left mean in Chinese = text. Why the order of each character not revered? >=20 > 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. I see, so characters have their inherited order and that never changes, = only paragraphs change orders.=20 >=20 >> UAX#9 didn=E2=80=99t say anything helpful. >=20 > 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. Thanks. Yuan