From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Itai Berli Newsgroups: gmane.emacs.bugs Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs Date: Tue, 4 Jul 2017 12:19:42 +0300 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403043ec4d49cab9105537a644f" X-Trace: blaine.gmane.org 1499160078 20287 195.159.176.226 (4 Jul 2017 09:21:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2017 09:21:18 +0000 (UTC) To: 27525@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 04 11:21:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSK1A-0004wF-Uf for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jul 2017 11:21:13 +0200 Original-Received: from localhost ([::1]:39727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSK1E-00008T-Pc for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jul 2017 05:21:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSK15-00006p-MS for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2017 05:21:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dSK10-0007xC-So for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2017 05:21:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48494) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dSK10-0007x8-OW for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2017 05:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dSK10-0003dV-Ji for bug-gnu-emacs@gnu.org; Tue, 04 Jul 2017 05:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Itai Berli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jul 2017 09:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27525-submit@debbugs.gnu.org id=B27525.149916002913915 (code B ref 27525); Tue, 04 Jul 2017 09:21:02 +0000 Original-Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 09:20:29 +0000 Original-Received: from localhost ([127.0.0.1]:51171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSK0T-0003cM-IL for submit@debbugs.gnu.org; Tue, 04 Jul 2017 05:20:29 -0400 Original-Received: from mail-ua0-f182.google.com ([209.85.217.182]:35053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSK0S-0003c9-9m for 27525@debbugs.gnu.org; Tue, 04 Jul 2017 05:20:28 -0400 Original-Received: by mail-ua0-f182.google.com with SMTP id j53so123214077uaa.2 for <27525@debbugs.gnu.org>; Tue, 04 Jul 2017 02:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nv25QueirqnbsbWoJQDoHVEXpCve5GY+JB9dCaMfo6g=; b=pfJo+s5U75z0/qLGwTaCn+mlBdc2rVq610WLo6LeiyEToOKyRpflqyJrjI5fEtFk// irG9Z+j3tnrCfvkHusDGZ0gLR2bsoY3BiB4IXVPfJoNoYDVLvmGYQhoknTjErBtB3dSN 2nUpS18DE6ayJTGRZkGt0QgfwKFTiN5P/TBdmGCs8M6v0+r9DB5p/4saBZ+DBt1XS+B+ UKbnykajPVLuZsBLttFf8PwDpVRRrKUEDF5Z1yAmsXcy9EQg8+6VCTc/EBFV9h4LznvW bsmPi+3iuiiCgLo0Oclyj/Ikg4G5R0dewi48OwZCQSYmSVlH1rGMd+rfS2aIr+CNePdF ZpqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nv25QueirqnbsbWoJQDoHVEXpCve5GY+JB9dCaMfo6g=; b=CbjtyQ0TzHFA3XeTJm7zokwEZ+q9F3X5diBKT9ZYMA7U0oK256bfIMBR1SeLrm7+xi AvMlSdcJ37DYp6P2Y+9kxiLXyjHHfPXg0/eaNTgHv6zzqf7qLcrXYJ1ncou0TBZGFqHM FVqXQa7jDA+epAnArzcLLByW/3LwsqPc93LrLryppKPARZ44F8EgZalaNRZ+2AgHooq5 Bj7r3Elkhtl998n4AUe4QsJJSNz2N9KEnCPFIJLliK1lFxWZEV1ja9gBC4SHzy4Zufi2 4UdSnGPyKTaXm35IRRuT4WZn2a/D/ZGzLELHrfQTqWSwZnMSVtQnlissqljoYrq5RGQO Hc1w== X-Gm-Message-State: AKS2vOzqMiU0IAxRe9m6IVIs5ZxKqyMapUL3nuofaxahz0otsfkS+3sh dteYv9TdB+tuqSSmiTaRD7UDvThpBA1O X-Received: by 10.159.51.220 with SMTP id y28mr25550928uab.130.1499160022656; Tue, 04 Jul 2017 02:20:22 -0700 (PDT) Original-Received: by 10.176.70.85 with HTTP; Tue, 4 Jul 2017 02:19:42 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:134164 Archived-At: --f403043ec4d49cab9105537a644f Content-Type: text/plain; charset="UTF-8" I'd also like to add what should be obvious (considering the fact the Emacs provides a line wrapping feature to begin with) that the "remedy" of braking long lines by inserting newline character is not very usable, as one would have to move the newlines to other locations if one had to add a few more words to the line. On Tue, Jul 4, 2017 at 12:11 PM, Itai Berli wrote: > I obviously didn't end up replacing the bullet points by numbers... > > On Tue, Jul 4, 2017 at 12:10 PM, Itai Berli wrote: > >> I'd like to add that this behavior breaks the Unicode bidirectional >> algorithm (UBA), and hence invalidates Emacs' claim of full conformance, or >> indeed of weak conformance, for that matter (so-called 'implicit >> bidirectionality' -- see section 4.2 of the UBA specifications). >> >> The reason is that section 3.4 'Reordering Resolved Levels' of the >> algorithm states (I replaced the bullet points in the original by numbers): >> >> > * The characters are shaped into glyphs [...] >> *> * *The accumulated widths of those glyphs *(in logical order)* are >> used to determine line breaks. >> >> The Emacs line-wrapping algorithm does not use the logical order of the >> glyphs to determine line breaks, as evidence by the example given in my >> original post, which I shall link to again: http://imgur.com/Bckn7zP >> > > --f403043ec4d49cab9105537a644f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd also like to add what should be obvious (consideri= ng the fact the Emacs provides a line wrapping feature to begin with) that = the "remedy" of braking long lines by inserting newline character= is=C2=A0not very usable, as one would hav= e to move the newlines to other locations if one had to add a few more word= s to the line.


On Tue, Jul 4, 2= 017 at 12:11 PM, Itai Berli <itai.berli@gmail.com> wrote:=
I obviously didn't = end up replacing the bullet points by numbers...

On Tue, Jul 4, 2017 at 12:1= 0 PM, Itai Berli <itai.berli@gmail.com> wrote:
I'd like to add that this beha= vior breaks the Unicode bidirectional algorithm (UBA), and hence invalidate= s Emacs' claim of full conformance, or indeed of weak conformance, for = that matter=C2=A0(so-called 'implicit bidirectionality' -- see sect= ion 4.2 of the UBA specifications).

The reason is that s= ection 3.4 'Reordering Resolved Levels' of the algorithm states (I = replaced the bullet points in the original by numbers):

> * The characters are shaped into glyphs [...]
> = *=C2=A0The accumulated widths of those glyphs (in logical order)= are used to determine line=20 breaks.

The Emacs line-wrapping algorithm does= not use the logical order of the glyphs to determine line breaks, as evide= nce by the example given in my original post, which I shall link to again:= =C2=A0http://imgur.c= om/Bckn7zP


--f403043ec4d49cab9105537a644f--