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: Fri, 29 May 2020 17:20:21 -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> 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="48114"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 29 23:21:04 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 1jemR5-000CQ8-Tx for ged-emacs-devel@m.gmane-mx.org; Fri, 29 May 2020 23:21:04 +0200 Original-Received: from localhost ([::1]:56150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jemR4-0004Uy-V1 for ged-emacs-devel@m.gmane-mx.org; Fri, 29 May 2020 17:21:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jemQU-0003dX-Id for emacs-devel@gnu.org; Fri, 29 May 2020 17:20:26 -0400 Original-Received: from mail-qk1-x735.google.com ([2607:f8b0:4864:20::735]:37405) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jemQT-0000vH-FK; Fri, 29 May 2020 17:20:26 -0400 Original-Received: by mail-qk1-x735.google.com with SMTP id b27so3621439qka.4; Fri, 29 May 2020 14:20:24 -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=xp4Y5PHwAyHtx/meIKWqUXVCuOIiHf9HJRAIdjvlcCQ=; b=TXSSmlhZXqyBPECiOrSDv1hsmECFaKvReanHk6TgCxt7KEh1QCfW6FulXtfqPLqHFG B8rSDY69pY0neyhu+sWsgni+kcFL3Y56apQvkzAw2KVPNlbDVvvb4xwGzk9rZdMQvsST D+0igm6F22st+2S2rpkl3A5kzwkHr49WCQIaFMhlUAJVQbAlB9wozJvfN48iv08Nglm+ w+CJFdATr4FUoo5iye1jUw/Ba4wABEe9q/KosXYpuZvv9u0pKFp6nT0tyqTRZy6VSWHF G60/IoQmGaI1C2DXPv7N8i+MwUHPyjmFQZhxNwIsBqr5CgElLh3hiG07WCoeqP/n0gq7 vMxw== 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=xp4Y5PHwAyHtx/meIKWqUXVCuOIiHf9HJRAIdjvlcCQ=; b=aAFkKoKayQKuj/UdZ9ojW/h15caH/DEGsSB21xDA8jbI+TTc7Ra6IP1dN/RbBxxtPl nZGdns0UGHNjLQYu385lkEcUQpBjHfNl2Eq8BHxVI+WAG9WsYmA5MF+NH9au9mlZ8RBC gnZUl6bEla6p6M1cjKKiTG69js0Uqm6mX5zVGCzsugFFJ8LXiwBUD3tjOf/RjBsHHRUz iBNFjfLtPBAyU6u3tvA0h4/R8gy+d8Mf80rfD5XXM9VcI8ck9c+f8V/AHQF8CauflWOv roOzQrez0FpK9yWBpzxm0GRlLgMIIYsSKVAeEZihFjt8208L7yec+itSPUI7l5uzLu70 cKzA== X-Gm-Message-State: AOAM530qbpIDpqVsA0Ha3synyL4jcSJ2UcFzWVE1escxmwJOdxcN+Kcj R6rT2d3XzZZXfKYNtCwC0eqxXsklieytXQ== X-Google-Smtp-Source: ABdhPJwtSVIKzudrkDZ+navrvoquK5J1YIIYG9cNNZ03R5C5DVcbZNC+WJKvs3LE++w43IHAva8nVw== X-Received: by 2002:a05:620a:21c4:: with SMTP id h4mr9808229qka.478.1590787223323; Fri, 29 May 2020 14:20:23 -0700 (PDT) Original-Received: from [192.168.1.10] (c-174-60-229-153.hsd1.pa.comcast.net. [174.60.229.153]) by smtp.gmail.com with ESMTPSA id p38sm9270581qtp.60.2020.05.29.14.20.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 14:20:22 -0700 (PDT) In-Reply-To: <83r1v3qlel.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::735; envelope-from=casouri@gmail.com; helo=mail-qk1-x735.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:251628 Archived-At: > On May 29, 2020, at 2:56 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Thu, 28 May 2020 15:34:28 -0400 >> Cc: larsi@gnus.org, >> emacs-devel@gnu.org >>=20 >> In the current code IT_DISPLAYING_WHITESPACE can check for = can_wrap_before and can_wrap_after in the same time, but in my new code, = we have to perform two checks in the same iteration, because some char = can wrap before but now after, and some can wrap after but not before, = etc.=20 >=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 I think I did jus that, i.e., if (may_wrap && char_can_wrap_before(it)). >>> Which "continue" are you alluding to here? Do you mean "lines are >>> continued"? because if lines are not being wrapped, we have only = one >>> choice: go back to the last wrap point we found, end the screen line >>> (a.k.a. "break the line") there, and continue with the text on the >>> next screen line. >>=20 >> I think there is another option where we wrap at current point. On = line 23356: >>=20 >> /* If line-wrap is on, check if a >> previous wrap point was found. */ >> else if (wrap_row_used > 0 >> /* Even if there is a previous = wrap >> point, continue the line here = as >> usual, if (i) the previous = character >> was a space or tab AND (ii) = the >> current character is not. */ >> && (!may_wrap >> || IT_DISPLAYING_WHITESPACE = (it))) >> goto back_to_wrap; >>=20 >> I was alluding to this =E2=80=9Ccontinue=E2=80=9D: =E2=80=9Ccontinue = the line here as usual=E2=80=9D. What does it mean? Does it mean we = insert a line break here? I think your response below confirms my guess. >=20 > Yes, "continue the line" here means we break the line here instead of > going back to the wrap point. This code handles the case when there's > a previous wrap point, but the current character fits exactly on the > line, and that current character is a TAB or SPC. >=20 >>> I mean the indentation: the original code used TABs and spaces, but >>> your code uses only spaces. >>=20 >> How do I fix it? Any guideline file? >=20 > Just make sure indent-tabs-mode is non-nil when you edit C files. Ok. >=20 >>>> and the redisplay iterator will still go through them LTR >>>=20 >>> Not sure what you mean by "go through them LTR". The iterator can >>> move forward or backward, or even jump to a far-away place. You >>> cannot assume that the next character examined will be the next >>> character in the buffer. >>=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. 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? What I=E2=80=99m saying is: Normal text: space: can wrap: after (in logical order), right (in visual = order) Cannot wrap: before (in logical order), left (in visual order) Bidi text: space: can wrap: after (in logical order), _left_ (in visual = order) Cannot wrap: before (in logical order), _right_ (in visual order) Since may_wrap=E2=80=99s meaning is in terms of left and right, it need = to be reversed in bidi text, no? >=20 >> Actually, I just tried again and the code works for bidi. Maybe last = time I didn=E2=80=99t turned on word-wrap while thinking I did. >=20 > You need to try both with bidi-paragraph-direction set to > left-to-right and right-to-left. If both work, then the code is OK. 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? UAX#9 didn=E2=80=99t = say anything helpful. Yuan