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, 19 Jun 2020 08:04:47 -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> <83pnakj8fs.fsf@gnu.org> <83k10sj60l.fsf@gnu.org> <0B30F8C8-9B8F-4FCB-B9FB-1B5A0E993CDB@gmail.com> <838sgjzij2.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="65097"; 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 Jun 19 14:14:17 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 1jmFuS-000GpB-LD for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 14:14:16 +0200 Original-Received: from localhost ([::1]:54064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmFuR-0008TV-Mc for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 08:14:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmFlV-00025X-Uv for emacs-devel@gnu.org; Fri, 19 Jun 2020 08:05:02 -0400 Original-Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]:44751) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmFlL-0006yl-B4; Fri, 19 Jun 2020 08:05:01 -0400 Original-Received: by mail-qk1-x72f.google.com with SMTP id b4so8585771qkn.11; Fri, 19 Jun 2020 05:04:50 -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=89lr63Uv2JHC+e7kTsJA+Z4IhSLIWBxM0vuvpMgC94k=; b=OSJ70d58oR9tVG4PLBeynp1Iv5cP84+6pCD/xpUaFTjYG+ntZIHTZuWeGDY9o2ymgf x2MBr5cwbDRxJb86rtW6qyn4s+Im1M+MUaNO+RYFDbg0K6zrdfCqocL+Apdy2/+o9Icg d7ktc7DBibuctkDSxKIc8XzkLkUMV0zhemNDIszEcxvetSM/GgT0FHAzZym/I6/HkCRS RtPuAk1YRNuJ9bGJ/jomIctWnA2/gBsbsqwQiVyJUV1mu1PoapwK7+uAO5GUp/X5Vhbh f4Cwt5wfcv5H8ONmFfvIxDaKEkxZ9MDI1Ss12S7jh79otH73fiNiuHfnx/T/68rxbnZg h5gw== 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=89lr63Uv2JHC+e7kTsJA+Z4IhSLIWBxM0vuvpMgC94k=; b=fa017yKIZOdiAXY3rhLZx3VI5QPBFlFrRQe61abwrxsvbKpnOWHPTAM2UWrvRtgklu yHh1KXmbDO9gplu290XArNOp/9wEdb6nxyaJ+eVvCCNv/TurAF4uyvm53GMyOD4CE3Dr sLOr3pfU66af2gafaU1Hv2iUt9fz7NPd8vB5Xli9+ith2GEdUowSF8dO/qV2NimO2eMU yB5JOy2nlsNKQn5JbsdnZTRDk1zZSg9yrCzVZAZHiWmEKxk6QSZTvoURgoiZvo3LVrNT /3cRE5HyKXnRuBtjMAujTaSVu0act9lF58Ki0kOegTRi/kCGjWFOJLaE7AIdbsQujure PF9Q== X-Gm-Message-State: AOAM5304IlXv/rkNUBfhZ+Wy5sbYUz2viwvJNn0cirV3uEt9zs8Bnera VZyaWfKQx8ZlbvgUmOBwbNt32hm6PmtIXg== X-Google-Smtp-Source: ABdhPJz9tHGqJxueNlOCM7Rp2Lcxupz+w1CHZ2eIGDiRwz2RlSogHqxyvImObHwq10/5hL9QGaR7Xw== X-Received: by 2002:a05:620a:576:: with SMTP id p22mr3069550qkp.257.1592568289532; Fri, 19 Jun 2020 05:04:49 -0700 (PDT) Original-Received: from ?IPv6:2601:98a:4200:9210:f9:e10f:5b2e:903c? ([2601:98a:4200:9210:f9:e10f:5b2e:903c]) by smtp.gmail.com with ESMTPSA id q124sm6459509qke.51.2020.06.19.05.04.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 05:04:48 -0700 (PDT) In-Reply-To: <838sgjzij2.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::72f; envelope-from=casouri@gmail.com; helo=mail-qk1-x72f.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_HELO_NONE=0.001, SPF_PASS=-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:252343 Archived-At: > On Jun 19, 2020, at 2:17 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Thu, 18 Jun 2020 17:46:53 -0400 >> Cc: Lars Ingebrigtsen , >> emacs-devel >>=20 >> I have to do another change for kinsoku.el to work right in bidi. = Kinsoku.el defined NOT_AT_BOL and NOT_AT_EOL categories. These = categories are flipped in bidi paragraphs: what was EOL becomes BOL and = vice versa. So I flipped them in my predicate function depending on = it->bidi_p. >=20 > I don't think I understand what you mean here. BOL and EOL are > logical-order terminology, and bidi reordering doesn't change their > meaning. >=20 > 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? =20 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=E2=80=99t = 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=E2=80=99t be the = right-most character in a line. =46rom 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. > The > important aspect of this is that in bidi-reordered text the character > that appears at the left edge of a line is not necessarily the first > character of the line after the preceding newline. So the issue is > what does Kinsoku say about such situations? IOW, definitions that > assume strict LTR text will not help us here. As I mentioned above, I don=E2=80=99t 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 =E3=80=8A, never = appears at the right edge. So we don=E2=80=99t get =E6=88=91=E4=BB=8A=E5=A4=A9=E7=9C=8B=E6=9D=A5=E4=BA=86=E6=9C=AC=E4=B9=A6=EF= =BC=8C=E6=84=9F=E8=A7=89=E6=8C=BA=E6=9C=89=E6=84=8F=E6=80=9D=EF=BC=8C=E5=90= =8D=E5=AD=97=E6=98=AF=E3=80=8A =E9=92=A2=E9=93=81=E6=98=AF=E6=80=8E=E6=A0=B7=E7=82=BC=E6=88=90=E7=9A=84=E3= =80=8B=E3=80=82 Instead, we have =E6=88=91=E4=BB=8A=E5=A4=A9=E7=9C=8B=E6=9D=A5=E4=BA=86=E6=9C=AC=E4=B9=A6=EF= =BC=8C=E6=84=9F=E8=A7=89=E6=8C=BA=E6=9C=89=E6=84=8F=E6=80=9D=EF=BC=8C=E5=90= =8D=E5=AD=97=E6=98=AF =E3=80=8A=E9=92=A2=E9=93=81=E6=98=AF=E6=80=8E=E6=A0=B7=E7=82=BC=E6=88=90=E7= =9A=84=E3=80=8B=E3=80=82 Now, is that mapping TRT for other characters? I don=E2=80=99t 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. Yuan [1] There is also a top-down layout, but I don=E2=80=99t think we need = to worry about that.