GNU logs - #27525, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 29 Jun 2017 07:45:01 +0000
Resent-Message-ID: <handler.27525.B.149872229329661 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 27525 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Itai Berli <itai.berli@HIDDEN>
Date: Thu, 29 Jun 2017 10:23:15 +0300
Message-ID: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

The line-wrapping algorithm for formatting multi-lingual paragraphs
containing text in languages of opposite directionality (e.g. English
and Hebrew) is inconsistent with other text editing applications
(including Gmail, Google Docs, Libre Writer, MS-Word, Pages, and
TextEdit), as well as with Emacs itself!

Consider as an example the following paragraph that starts with two
Hebrew words followed by the opening of Lincoln's Gettysburg Address.

=D7=A0=D7=90=D7=95=D7=9D =D7=92=D7=98=D7=99=D7=A1=D7=91=D7=95=D7=A8=D7=92 F=
our score and seven years ago our fathers brought forth
on this continent, a new nation, conceived in Liberty, and dedicated to
the proposition that all men are created equal.

When I type this inside the `M-x report-emacs-bug` buffer, and press
`RET`, the paragraph lines wrap as follows, similar to how the other
applications mentioned above handle it.

ILLUSTRATION: A correct way to line-wrap a bidi paragraph
http://imgur.com/9VDZFz0

If I now copy this paragraph and paste it in a new buffer, the line
wrapping is preserved.

However, when I *type* the same paragraph inside a new buffer, (as well as
when I finish typing the paragraph insie the `M-x report-emacs-bug`
buffer, just before pressing `RET`), the lines wrap as follows.

ILLUSTRATION: An incorrect way to line-wrap a bidi paragraph
http://imgur.com/Bckn7zP

Observe that the English text flows from the bottom of the paragraph to
the top, which makes no sense, since the words of the paragraph have a
natural, logical ordering within the paragraph that is independent of their
directionality, but the way the lines are wrapped in the last screenshot
disrupts this logical order by placing the last word ('equal') on the
same line as the first two words (the Hebrew words), whereas the third
word ('Four') is positioned two lines apart.



In GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21
Version 10.9.5 (Build 13F1911))
 of 2016-09-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
 'configure --with-ns '--enable-locallisppath=3D/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  ivy-mode: t
  shell-dirtrack-mode: t
  projectile-mode: t
  helm-descbinds-mode: t
  async-bytecomp-package-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
ad-handle-definition: =E2=80=98ibuffer=E2=80=99 got redefined
Turn on helm-projectile key bindings
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/Users/itaiberli/.emacs.d/elpa/seq-2.20/seq hides
/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/seq

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils colir color counsel
jka-compr esh-util etags xref project swiper reftex reftex-vars
two-column ivy delsel ivy-overlay helm-projectile helm-files rx
image-dired tramp tramp-compat tramp-loaddefs trampver shell pcomplete
format-spec dired-x dired-aux ffap helm-tags helm-bookmark helm-adaptive
helm-info bookmark pp helm-external helm-net browse-url xml url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source gnus-util mm-util help-fns
mail-prsvr password-cache url-vars mailcap helm-buffers helm-grep
helm-regexp helm-utils helm-locate helm-help helm-types projectile grep
compile comint ansi-color ring ibuf-ext ibuffer thingatpt helm-descbinds
helm easy-mmode helm-source cl-seq eieio-compat eieio eieio-core
helm-multi-match helm-lib dired helm-config helm-easymenu cl-macs
async-bytecomp async advice edmacro kmacro finder-inf tex-site info
package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 312113 14836)
 (symbols 48 30403 0)
 (miscs 40 88 163)
 (strings 32 51779 9508)
 (string-bytes 1 1669823)
 (vectors 16 50217)
 (vector-slots 8 844607 6040)
 (floats 8 564 139)
 (intervals 56 243 0)
 (buffers 976 18))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Itai Berli <itai.berli@HIDDEN>
Subject: bug#27525: Acknowledgement (25.1; Line wrapping of bidi paragraphs)
Message-ID: <handler.27525.B.149872229329661.ack <at> debbugs.gnu.org>
References: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
X-Gnu-PR-Message: ack 27525
X-Gnu-PR-Package: emacs
Reply-To: 27525 <at> debbugs.gnu.org
Date: Thu, 29 Jun 2017 07:45:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 27525 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
27525: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27525
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 29 Jun 2017 14:57:02 +0000
Resent-Message-ID: <handler.27525.B27525.149874817026438 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Thu, 29 Jun 2017 17:55:43 +0300
Message-Id: <83h8yyrggg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
 (message from Itai Berli on Thu, 29 Jun 2017 10:23:15 +0300)
References: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Thu, 29 Jun 2017 10:23:15 +0300
> 
> The line-wrapping algorithm for formatting multi-lingual paragraphs
> containing text in languages of opposite directionality (e.g. English
> and Hebrew) is inconsistent with other text editing applications
> (including Gmail, Google Docs, Libre Writer, MS-Word, Pages, and
> TextEdit), as well as with Emacs itself!

The inconsistency with Emacs is because in the first case the text is
broken into separate lines with newlines, whereas in the second it's a
single long line.

> נאום גטיסבורג Four score and seven years ago our fathers brought forth
> on this continent, a new nation, conceived in Liberty, and dedicated to
> the proposition that all men are created equal.
> 
> When I type this inside the `M-x report-emacs-bug` buffer, and press
> `RET`, the paragraph lines wrap as follows, similar to how the other
> applications mentioned above handle it.
> 
> ILLUSTRATION: A correct way to line-wrap a bidi paragraph
> http://imgur.com/9VDZFz0
> 
> If I now copy this paragraph and paste it in a new buffer, the line
> wrapping is preserved.
> 
> However, when I *type* the same paragraph inside a new buffer, (as well as
> when I finish typing the paragraph insie the `M-x report-emacs-bug`
> buffer, just before pressing `RET`), the lines wrap as follows.
> 
> ILLUSTRATION: An incorrect way to line-wrap a bidi paragraph
> http://imgur.com/Bckn7zP
> 
> Observe that the English text flows from the bottom of the paragraph to
> the top, which makes no sense, since the words of the paragraph have a
> natural, logical ordering within the paragraph that is independent of their
> directionality, but the way the lines are wrapped in the last screenshot
> disrupts this logical order by placing the last word ('equal') on the
> same line as the first two words (the Hebrew words), whereas the third
> word ('Four') is positioned two lines apart.

Yes, Emacs's line-wrapping doesn't work well when the text
directionality is opposite to the paragraph direction.  The reasons
are technical (I can tell the details if someone is interested), but
in the nutshell the requirements of the UBA in that area would need a
thorough change of how the basic Emacs display layout is designed.

The remedy is usually simple: break the long lines into shorter ones
by inserting newlines.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
References: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
In-Reply-To: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 29 Jun 2017 18:37:01 +0000
Resent-Message-ID: <handler.27525.B27525.149876140020382 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 27525 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Itai Berli <itai.berli@HIDDEN>
Date: Thu, 29 Jun 2017 21:35:53 +0300
Message-ID: <CABsNJ=M1ohY=fsB1OJ+7dSN0ET8fbG9ABxEULg50cqRpr+ezyA@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> The remedy is usually simple: break the long lines into shorter ones
by inserting newlines.

I'm sorry but this is no remedy at all. This is like going back to the
typewriter era.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
References: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
In-Reply-To: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 09:12:01 +0000
Resent-Message-ID: <handler.27525.B27525.149915946512990 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149915946512990
          (code B ref 27525); Tue, 04 Jul 2017 09:12:01 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 09:11:05 +0000
Received: from localhost ([127.0.0.1]:51161 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSJrN-0003NS-Cx
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:11:05 -0400
Received: from mail-vk0-f41.google.com ([209.85.213.41]:34744)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dSJrL-0003My-O5
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:11:04 -0400
Received: by mail-vk0-f41.google.com with SMTP id r125so107958100vkf.1
 for <27525 <at> debbugs.gnu.org>; Tue, 04 Jul 2017 02:11:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=mMLp4MTWwSFyGBmNmkUewkc/IQtPxttUxcEB1g70QqE=;
 b=CUKmCMR+Q15FlaYtJTUs5QhR8+ENcGGBxtcHkMwMcYgmM+fyS319diFcpMxIvbl2f7
 BG5nwyEpaVXtS+UIw1M70AP1DJKADAhBc0VfcTNv49v+6oPjy2b756J54tjcTOIF7WHJ
 5VSu7sFiByK7+ZWBwA8YF0jnIAQvIQhc5b+pOy/+GKP3VvdsSUcr/kcR1PDSWWMxmD2k
 vkyRPVodhEdjaB9ywf/t3Ma3xykyVODwHNRENbh0rYG+DsZwIxc/caWAn/Pf5GBe4kOv
 VEXN1nmDMtvl4V8SHFnX88h23GVAunijibpF9gwSpxuSaUeSynbToSJ069OVg07JXFxB
 guEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=mMLp4MTWwSFyGBmNmkUewkc/IQtPxttUxcEB1g70QqE=;
 b=DheyWpPPOR4yIRNqhF9R0pBT913NKuy1QxVm0vijAz2E3KDsDumL2FunkGz6lb4ry6
 zSUxR+DQaW3CNrwZpbo7LBQhAKHlwfVHSxNYwYN+e7FX6TWPnFlXVOVJ766KrSf23HO8
 QyyFr2Csj1OP04+R/OcyHfXz4Gla9NTHqaS6nRqgFEPIhBaJ1/l4Xru/rl4c1Ov8GAhh
 Vd1fMkYHiVZwFGXz9l/XsaOFiq5drSuMsxEpBdUhMLovmJsqW1QUwbhldqhT4QvnL163
 yIyUgL8Q1+ExurZcFcAUiPXpBjnvF7gQPM5KIe0dYMJbS4pJLI84Iu3p+AZueIGmtlOP
 XQbw==
X-Gm-Message-State: AKS2vOzZGRMOQps8H5i0kQmvI40mZOSfNp6+fXrPDdasS+OgHFpklsqp
 J7aqPNXWqlNv/i2Y6g4jxjWwaSD7fLca2I0=
X-Received: by 10.31.151.148 with SMTP id z142mr18380720vkd.3.1499159457897;
 Tue, 04 Jul 2017 02:10:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.70.85 with HTTP; Tue, 4 Jul 2017 02:10:17 -0700 (PDT)
From: Itai Berli <itai.berli@HIDDEN>
Date: Tue, 4 Jul 2017 12:10:17 +0300
Message-ID: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11426464f3243405537a4271"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--001a11426464f3243405537a4271
Content-Type: text/plain; charset="UTF-8"

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

--001a11426464f3243405537a4271
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to add that this behavior breaks the Unicode =
bidirectional algorithm (UBA), and hence invalidates Emacs&#39; claim of fu=
ll conformance, or indeed of weak conformance, for that matter=C2=A0(so-cal=
led &#39;implicit bidirectionality&#39; -- see section 4.2 of the UBA speci=
fications).<div><br></div><div>The reason is that section 3.4 &#39;Reorderi=
ng Resolved Levels&#39; of the algorithm states (I replaced the bullet poin=
ts in the original by numbers):</div><div><br></div><div>&gt; * The charact=
ers are shaped into glyphs [...]</div><div><i>&gt; *=C2=A0</i>The accumulat=
ed widths of those glyphs <i>(in logical order)</i> are used to determine l=
ine=20
    breaks.</div><div><br></div><div>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=A0<a href=3D"http://imgur.com/Bckn7zP">http://imgur.com/Bckn7zP</a></di=
v></div>

--001a11426464f3243405537a4271--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 09:12:02 +0000
Resent-Message-ID: <handler.27525.B27525.149915951213056 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149915951213056
          (code B ref 27525); Tue, 04 Jul 2017 09:12:02 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 09:11:52 +0000
Received: from localhost ([127.0.0.1]:51164 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSJs8-0003OV-MF
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:11:52 -0400
Received: from mail-ua0-f179.google.com ([209.85.217.179]:36525)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dSJs7-0003OI-Aw
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:11:51 -0400
Received: by mail-ua0-f179.google.com with SMTP id g40so123142290uaa.3
 for <27525 <at> debbugs.gnu.org>; Tue, 04 Jul 2017 02:11:51 -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=PFCZ/7ZA/yOmThZ8VlopI8/in2YF/EH6XXyly1r9pmY=;
 b=dIaxKBTMu4AEC/mqKRW6uz9YC2yTFujwllZ6MNXXqDxg5vKNDS1zLfPPyMhdbzBBZ2
 eC1K0vKzzr4NG6T05D3IvkqsgYVEgQdJvnST3+MyYMkl7EH2ADUzexBvCYcFGc5pJdq+
 izewWhSvm+f7WJ9cRPKXGUV9GLghxLXlPiPAzqp45MM4zKJ3698SM9/cy8gP27XW0IG7
 ZATOkSBnyOQ7ilfb2Av+NbsnmClRMN6Dew9am46Ug5j10esOdK1cTzZQgcfsD7q7iUqo
 majIfvubmT6kJWY+7VF1oatqoIQlQ7U5HK4XExfFo8UrgDxmOKS8PDegwddZVd4IexVu
 w2Yw==
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=PFCZ/7ZA/yOmThZ8VlopI8/in2YF/EH6XXyly1r9pmY=;
 b=I8YNb74U0ji8/OJL1Bkn2l7RDO2dpefgKN38uEn9ZwKwoAopzA688TSadQw0cSPttr
 7DFsOJtlH5yohi9bof8Ehoi+5bu5s8C7Aivpjy0/BUOG0rANyGKxcGRDZ3Fwhl1iyx6d
 2MmMaJ62otA1b2wrDm0Ms6GpckEMWgm/x3UTuDPzJbMmthq3nkBii1ai9vdlNAzZKsoM
 D40j5nYvl3z4zWCTJeKgCgghBHXqwPG7aVJ0UzK+nISE6H4YZHcApOXpy8h+Wtzslebb
 YgA1756Lp0arWQLqv2uOwPCLBUAybNL2hgU6M2UXwul0g26+33j/m9To2UqfsSlGybP3
 R9Ow==
X-Gm-Message-State: AKS2vOzxQQpW8aM4Mp+pCyzMCkwXKzPZBOf3XYJ8fqNMNu1p2sz5QqS7
 cDI50qoGC0MsZh6eOXBCCWLSE1G27gbq
X-Received: by 10.176.95.10 with SMTP id p10mr23545725uah.73.1499159505797;
 Tue, 04 Jul 2017 02:11:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.70.85 with HTTP; Tue, 4 Jul 2017 02:11:05 -0700 (PDT)
In-Reply-To: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Tue, 4 Jul 2017 12:11:05 +0300
Message-ID: <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
Content-Type: multipart/alternative; boundary="f403043ee360ce058705537a4557"
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

--f403043ee360ce058705537a4557
Content-Type: text/plain; charset="UTF-8"

I obviously didn't end up replacing the bullet points by numbers...

On Tue, Jul 4, 2017 at 12:10 PM, Itai Berli <itai.berli@HIDDEN> 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
>

--f403043ee360ce058705537a4557
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I obviously didn&#39;t end up replacing the bullet points =
by numbers...</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Tue, Jul 4, 2017 at 12:10 PM, Itai Berli <span dir=3D"ltr">&lt;<a href=
=3D"mailto:itai.berli@HIDDEN" target=3D"_blank">itai.berli@HIDDEN</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39=
;d like to add that this behavior breaks the Unicode bidirectional algorith=
m (UBA), and hence invalidates Emacs&#39; claim of full conformance, or ind=
eed of weak conformance, for that matter=C2=A0(so-called &#39;implicit bidi=
rectionality&#39; -- see section 4.2 of the UBA specifications).<div><br></=
div><div>The reason is that section 3.4 &#39;Reordering Resolved Levels&#39=
; of the algorithm states (I replaced the bullet points in the original by =
numbers):</div><div><br></div><div>&gt; * The characters are shaped into gl=
yphs [...]</div><div><i>&gt; *=C2=A0</i>The accumulated widths of those gly=
phs <i>(in logical order)</i> are used to determine line=20
    breaks.</div><div><br></div><div>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=A0<a href=3D"http://imgur.com/Bckn7zP" target=3D"_blank">http://imgur.c=
om/<wbr>Bckn7zP</a></div></div>
</blockquote></div><br></div>

--f403043ee360ce058705537a4557--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 09:21:02 +0000
Resent-Message-ID: <handler.27525.B27525.149916002913915 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149916002913915
          (code B ref 27525); Tue, 04 Jul 2017 09:21:02 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 09:20:29 +0000
Received: from localhost ([127.0.0.1]:51171 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSK0T-0003cM-IL
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:20:29 -0400
Received: from mail-ua0-f182.google.com ([209.85.217.182]:35053)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dSK0S-0003c9-9m
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 05:20:28 -0400
Received: by mail-ua0-f182.google.com with SMTP id j53so123214077uaa.2
 for <27525 <at> 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)
MIME-Version: 1.0
Received: by 10.176.70.85 with HTTP; Tue, 4 Jul 2017 02:19:42 -0700 (PDT)
In-Reply-To: <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Tue, 4 Jul 2017 12:19:42 +0300
Message-ID: <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
Content-Type: multipart/alternative; boundary="f403043ec4d49cab9105537a644f"
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

--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 <itai.berli@HIDDEN> wrote:

> I obviously didn't end up replacing the bullet points by numbers...
>
> On Tue, Jul 4, 2017 at 12:10 PM, Itai Berli <itai.berli@HIDDEN> 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

<div dir=3D"ltr">I&#39;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 &quot;remedy&quot; of braking long lines by inserting newline character=
 is=C2=A0<span style=3D"font-size:12.8px">not 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.</span><div><span style=3D"font-size:12.8px"><br></span></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 4, 2=
017 at 12:11 PM, Itai Berli <span dir=3D"ltr">&lt;<a href=3D"mailto:itai.be=
rli@HIDDEN" target=3D"_blank">itai.berli@HIDDEN</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I obviously didn&#39;t =
end up replacing the bullet points by numbers...</div><div class=3D"m_-4815=
211137200357978HOEnZb"><div class=3D"m_-4815211137200357978h5"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 4, 2017 at 12:1=
0 PM, Itai Berli <span dir=3D"ltr">&lt;<a href=3D"mailto:itai.berli@HIDDEN=
om" target=3D"_blank">itai.berli@HIDDEN</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d like to add that this beha=
vior breaks the Unicode bidirectional algorithm (UBA), and hence invalidate=
s Emacs&#39; claim of full conformance, or indeed of weak conformance, for =
that matter=C2=A0(so-called &#39;implicit bidirectionality&#39; -- see sect=
ion 4.2 of the UBA specifications).<div><br></div><div>The reason is that s=
ection 3.4 &#39;Reordering Resolved Levels&#39; of the algorithm states (I =
replaced the bullet points in the original by numbers):</div><div><br></div=
><div>&gt; * The characters are shaped into glyphs [...]</div><div><i>&gt; =
*=C2=A0</i>The accumulated widths of those glyphs <i>(in logical order)</i>=
 are used to determine line=20
    breaks.</div><div><br></div><div>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=A0<a href=3D"http://imgur.com/Bckn7zP" target=3D"_blank">http://imgur.c=
om/Bckn7z<wbr>P</a></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>

--f403043ec4d49cab9105537a644f--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 14:41:01 +0000
Resent-Message-ID: <handler.27525.B27525.149917922217667 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149917922217667
          (code B ref 27525); Tue, 04 Jul 2017 14:41:01 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 14:40:22 +0000
Received: from localhost ([127.0.0.1]:52270 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSP02-0004at-C5
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:40:22 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42638)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dSP01-0004ah-5A
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:40:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dSOzr-0004eK-Vg
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:40:15 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48124)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dSOzr-0004eG-S0; Tue, 04 Jul 2017 10:40:11 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1789
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dSOzr-0001Tw-7G; Tue, 04 Jul 2017 10:40:11 -0400
Date: Tue, 04 Jul 2017 17:40:07 +0300
Message-Id: <83lgo4nu48.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 (message from Itai Berli on Tue, 4 Jul 2017 12:10:17 +0300)
References: <CABsNJ=P7vXK8j2dXUyfkk-+wUH1JAe=ipwHGnd4Oo=Lx+AZMuQ@HIDDEN>
 <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Tue, 4 Jul 2017 12:10:17 +0300
> 
> 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).

Yes, line wrapping when text direction is opposite to the paragraph
direction is where Emacs deviates from the UBA.  I've added this
caveat to the Emacs manuals a few days ago.

The "full conformance" part refers to the fact that all the explicit
directional controls are supported, including the isolates.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 14:45:02 +0000
Resent-Message-ID: <handler.27525.B27525.149917944617999 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149917944617999
          (code B ref 27525); Tue, 04 Jul 2017 14:45:02 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 14:44:06 +0000
Received: from localhost ([127.0.0.1]:52274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSP3d-0004gE-Tl
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:44:06 -0400
Received: from eggs.gnu.org ([208.118.235.92]:43566)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dSP3c-0004ff-Ka
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:44:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dSP3T-00076E-Km
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:43:59 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48148)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dSP3T-00076A-HM; Tue, 04 Jul 2017 10:43:55 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1790
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dSP3S-0001da-Pb; Tue, 04 Jul 2017 10:43:55 -0400
Date: Tue, 04 Jul 2017 17:43:51 +0300
Message-Id: <83k23onty0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 (message from Itai Berli on Tue, 4 Jul 2017 12:19:42 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Tue, 4 Jul 2017 12:19:42 +0300
> 
> 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.

Emacs provides several convenience feature for this purpose.  There's
the auto-fill mode, which will refill paragraphs automatically as you
type.  There's also the 'M-q' key which will refill, and optionally
also justify, the marked region, defaulting to the current paragraph
if region is not active.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 14:54:02 +0000
Resent-Message-ID: <handler.27525.B27525.149918002118817 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149918002118817
          (code B ref 27525); Tue, 04 Jul 2017 14:54:02 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 14:53:41 +0000
Received: from localhost ([127.0.0.1]:52278 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSPCu-0004tR-V9
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:53:41 -0400
Received: from mail-vk0-f48.google.com ([209.85.213.48]:36549)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dSPCt-0004tF-ST
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 10:53:40 -0400
Received: by mail-vk0-f48.google.com with SMTP id y70so111412145vky.3
 for <27525 <at> debbugs.gnu.org>; Tue, 04 Jul 2017 07:53:39 -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=RBo4iHS880fZiIkXx70zhDc6dvvmRqdgCaDee1j7MC4=;
 b=QDoV5INE9SMlPNY4wrlZtEmvMrzAKf7JBLb2a2PRmFNcPbiPn/85ndNSAMbw34MXI4
 el8sCbg4jZcuBP7xBpsDe+e4pYCWDrk3q0G9vl5SqewXK47OaMZqqQIh/dHN62tTHKYY
 TgNfBu9xhQNL7bRccRIp3Q7nNeAkG1VP46kl38i4NjQC3CwR2F9LBY3pu5YtZwob4Rjn
 igBawr0EgXqpQ2/7Sj6QzCKrdMABHwYhI/tLIWrMLUYJZRG14UPmTf/fhIq4WJ+kUfXm
 hPvP2I0sIF4LEgzF+ln1GujRP+UEVCpyWl6JmNOnq1SkHBBS9fqQtVkm/b+V/G4DlmQ5
 5VCw==
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=RBo4iHS880fZiIkXx70zhDc6dvvmRqdgCaDee1j7MC4=;
 b=peVqOK2FIbGtZBH8aVOJGY/JLfKB+ChJpJui9D/HuJ54TC60UtFXsk/ZcFPYYjkjqY
 ycIpaEDCBdeejVdzTBQTpXBjqN3d/dPGuIat78FveTh9hitB9gfwUKkzG5h4R35X3Y+Z
 OQ1Ia6ssZ9IiUdeCKyoNcBuKBPfIvQ3oWnKJs1Q4uaBnFSxZsUlIUPUjqpGRFcszf9n7
 5c2jSlE/IcgL4yrSzqibyuECj93lu1uD4p8F+mxlBFWxrQZiQMa/MC48W7yufwqNysmG
 xH/f+CvV7FLy3gqs61sgD7o9RokFq2iWpYU10s8faQhnR1x5WOAabZovmW0TSp8QshQS
 XWng==
X-Gm-Message-State: AKS2vOy0NZhn1jUuL3YfBdlUw4uxs6jNuRW+7mRUcEkpoUPX3fAuGQMZ
 TXxh1qsCii8xYIQIKyTypxiZVE7r4kEe
X-Received: by 10.31.138.135 with SMTP id m129mr21196826vkd.84.1499180012946; 
 Tue, 04 Jul 2017 07:53:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.70.85 with HTTP; Tue, 4 Jul 2017 07:52:52 -0700 (PDT)
In-Reply-To: <83k23onty0.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <83k23onty0.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Tue, 4 Jul 2017 17:52:52 +0300
Message-ID: <CABsNJ=MxiaaCa1vyT4QJmTnW9GtxP16NzEvFYg5x1C1LDdgscg@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11457146204b9c05537f0cc9"
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

--001a11457146204b9c05537f0cc9
Content-Type: text/plain; charset="UTF-8"

Is this considered a bug to be fixed? If so, what priority does it have,
and what's the time frame for a complete fix?

On Tue, Jul 4, 2017 at 5:43 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Itai Berli <itai.berli@HIDDEN>
> > Date: Tue, 4 Jul 2017 12:19:42 +0300
> >
> > 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.
>
> Emacs provides several convenience feature for this purpose.  There's
> the auto-fill mode, which will refill paragraphs automatically as you
> type.  There's also the 'M-q' key which will refill, and optionally
> also justify, the marked region, defaulting to the current paragraph
> if region is not active.
>

--001a11457146204b9c05537f0cc9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is this considered a bug to be fixed? If so, what priority=
 does it have, and what&#39;s the time frame for a complete fix?</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 4, 2017 at=
 5:43 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN=
g" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">&gt; From: Itai Berli &lt;<a href=3D"mailto:itai.berli@gmail=
.com">itai.berli@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 4 Jul 2017 12:19:42 +0300<br>
&gt;<br>
&gt; I&#39;d also like to add what should be obvious (considering the fact =
the Emacs provides a line wrapping feature to<br>
&gt; begin with) that the &quot;remedy&quot; of braking long lines by inser=
ting newline character is not very usable, as one<br>
&gt; would have to move the newlines to other locations if one had to add a=
 few more words to the line.<br>
<br>
Emacs provides several convenience feature for this purpose.=C2=A0 There&#3=
9;s<br>
the auto-fill mode, which will refill paragraphs automatically as you<br>
type.=C2=A0 There&#39;s also the &#39;M-q&#39; key which will refill, and o=
ptionally<br>
also justify, the marked region, defaulting to the current paragraph<br>
if region is not active.<br>
</blockquote></div><br></div>

--001a11457146204b9c05537f0cc9--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 15:20:02 +0000
Resent-Message-ID: <handler.27525.B27525.149918158021220 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149918158021220
          (code B ref 27525); Tue, 04 Jul 2017 15:20:02 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 15:19:40 +0000
Received: from localhost ([127.0.0.1]:52313 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSPc4-0005WC-5J
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 11:19:40 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58871)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dSPc2-0005W0-Kq
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 11:19:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dSPbs-0002QY-IP
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 11:19:33 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48641)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dSPbs-0002QQ-E4; Tue, 04 Jul 2017 11:19:28 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1986
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dSPbr-0002sQ-OV; Tue, 04 Jul 2017 11:19:28 -0400
Date: Tue, 04 Jul 2017 18:19:24 +0300
Message-Id: <83h8ysnsar.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=MxiaaCa1vyT4QJmTnW9GtxP16NzEvFYg5x1C1LDdgscg@HIDDEN>
 (message from Itai Berli on Tue, 4 Jul 2017 17:52:52 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <83k23onty0.fsf@HIDDEN>
 <CABsNJ=MxiaaCa1vyT4QJmTnW9GtxP16NzEvFYg5x1C1LDdgscg@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Tue, 4 Jul 2017 17:52:52 +0300
> 
> Is this considered a bug to be fixed?

I would love to see that fixed, yes.

> If so, what priority does it have, and what's the time frame for a complete
> fix?

Priority is only relevant when there's someone who intends to work on
this soon and knows how to fix it.  I don't think there's such a
person at this time.

I myself thought about this quite a lot, and I simply have no idea how
to fix this without redesigning most of the Emacs display code.  And
to do that, it will take someone more talented than myself and/or
someone with much more time on their hands.  Sorry.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jul 2017 23:06:01 +0000
Resent-Message-ID: <handler.27525.B27525.149920954231500 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149920954231500
          (code B ref 27525); Tue, 04 Jul 2017 23:06:01 +0000
Received: (at 27525) by debbugs.gnu.org; 4 Jul 2017 23:05:42 +0000
Received: from localhost ([127.0.0.1]:52638 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSWt4-0008C0-Cy
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 19:05:42 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41400)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1dSWt3-0008Bn-99
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 19:05:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rms@HIDDEN>) id 1dSWsx-0006zB-AP
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 19:05:36 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53622)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rms@HIDDEN>)
 id 1dSWst-0006t4-D7; Tue, 04 Jul 2017 19:05:31 -0400
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1dSWss-0000ey-Uw; Tue, 04 Jul 2017 19:05:31 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-reply-to: <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 (message from Itai Berli on Tue, 4 Jul 2017 12:19:42 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
Message-Id: <E1dSWss-0000ey-Uw@HIDDEN>
Date: Tue, 04 Jul 2017 19:05:30 -0400
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

It might be good if Emacs could refill lines automatically the way
some other ediors do.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Jul 2017 02:30:02 +0000
Resent-Message-ID: <handler.27525.B27525.149922178124422 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: rms@HIDDEN
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149922178124422
          (code B ref 27525); Wed, 05 Jul 2017 02:30:02 +0000
Received: (at 27525) by debbugs.gnu.org; 5 Jul 2017 02:29:41 +0000
Received: from localhost ([127.0.0.1]:52784 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSa4S-0006Lp-UJ
	for submit <at> debbugs.gnu.org; Tue, 04 Jul 2017 22:29:41 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42583)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dSa4R-0006Lc-BB
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 22:29:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dSa4H-0001xD-1r
 for 27525 <at> debbugs.gnu.org; Tue, 04 Jul 2017 22:29:34 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55676)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dSa4G-0001wy-Ui; Tue, 04 Jul 2017 22:29:28 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2536
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dSa49-0002Ql-L8; Tue, 04 Jul 2017 22:29:22 -0400
Date: Wed, 05 Jul 2017 05:29:08 +0300
Message-Id: <8337abobuz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <E1dSWss-0000ey-Uw@HIDDEN> (message from Richard
 Stallman on Tue, 04 Jul 2017 19:05:30 -0400)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Richard Stallman <rms@HIDDEN>
> Date: Tue, 04 Jul 2017 19:05:30 -0400
> Cc: 27525 <at> debbugs.gnu.org
> 
>   > 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.
> 
> It might be good if Emacs could refill lines automatically the way
> some other ediors do.

We already have that: "M-x visual-line-mode RET".

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Jul 2017 23:00:02 +0000
Resent-Message-ID: <handler.27525.B27525.149929555832370 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149929555832370
          (code B ref 27525); Wed, 05 Jul 2017 23:00:02 +0000
Received: (at 27525) by debbugs.gnu.org; 5 Jul 2017 22:59:18 +0000
Received: from localhost ([127.0.0.1]:53879 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dStGQ-0008Q1-LJ
	for submit <at> debbugs.gnu.org; Wed, 05 Jul 2017 18:59:18 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42659)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1dStGP-0008Pq-BD
 for 27525 <at> debbugs.gnu.org; Wed, 05 Jul 2017 18:59:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rms@HIDDEN>) id 1dStGJ-0007GA-3Z
 for 27525 <at> debbugs.gnu.org; Wed, 05 Jul 2017 18:59:11 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40704)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rms@HIDDEN>)
 id 1dStGF-0007Dj-KK; Wed, 05 Jul 2017 18:59:07 -0400
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1dStGF-0008K2-1h; Wed, 05 Jul 2017 18:59:07 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-reply-to: <8337abobuz.fsf@HIDDEN> (message from Eli Zaretskii on Wed, 05
 Jul 2017 05:29:08 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
Message-Id: <E1dStGF-0008K2-1h@HIDDEN>
Date: Wed, 05 Jul 2017 18:59:07 -0400
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We already have that: "M-x visual-line-mode RET".

That seems to break lines
byt not to fill them together.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 06 Jul 2017 02:41:04 +0000
Resent-Message-ID: <handler.27525.B27525.1499308806534 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: rms@HIDDEN
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.1499308806534
          (code B ref 27525); Thu, 06 Jul 2017 02:41:04 +0000
Received: (at 27525) by debbugs.gnu.org; 6 Jul 2017 02:40:06 +0000
Received: from localhost ([127.0.0.1]:53984 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dSwi5-00008Y-Uk
	for submit <at> debbugs.gnu.org; Wed, 05 Jul 2017 22:40:06 -0400
Received: from eggs.gnu.org ([208.118.235.92]:34283)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dSwi2-00007m-WD
 for 27525 <at> debbugs.gnu.org; Wed, 05 Jul 2017 22:40:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dSwht-0005Jo-KR
 for 27525 <at> debbugs.gnu.org; Wed, 05 Jul 2017 22:39:57 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43114)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dSwht-0005Je-H9; Wed, 05 Jul 2017 22:39:53 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3289
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dSwhl-0005eO-Lr; Wed, 05 Jul 2017 22:39:46 -0400
Date: Thu, 06 Jul 2017 05:39:30 +0300
Message-Id: <83r2xumgpp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <E1dStGF-0008K2-1h@HIDDEN> (message from Richard
 Stallman on Wed, 05 Jul 2017 18:59:07 -0400)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <E1dStGF-0008K2-1h@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Richard Stallman <rms@HIDDEN>
> CC: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
> Date: Wed, 05 Jul 2017 18:59:07 -0400
> 
>   > We already have that: "M-x visual-line-mode RET".
> 
> That seems to break lines
> byt not to fill them together.

Then maybe I don't understand what you meant by "fill".  This feature
produces exactly the same display as M-q, but it doesn't insert
newline characters into the buffer.  Isn't that what you meant by
"filling"?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 06 Jul 2017 16:02:02 +0000
Resent-Message-ID: <handler.27525.B27525.149935691428780 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149935691428780
          (code B ref 27525); Thu, 06 Jul 2017 16:02:02 +0000
Received: (at 27525) by debbugs.gnu.org; 6 Jul 2017 16:01:54 +0000
Received: from localhost ([127.0.0.1]:55350 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dT9E1-0007U7-Ri
	for submit <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:01:54 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54731)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1dT9E0-0007Tv-K5
 for 27525 <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:01:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rms@HIDDEN>) id 1dT9Du-0002Yy-Hp
 for 27525 <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:01:47 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54069)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rms@HIDDEN>)
 id 1dT9Dq-0002W9-Nq; Thu, 06 Jul 2017 12:01:42 -0400
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1dT9Dq-0000RY-5P; Thu, 06 Jul 2017 12:01:42 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-reply-to: <83r2xumgpp.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 06
 Jul 2017 05:39:30 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <E1dStGF-0008K2-1h@HIDDEN> <83r2xumgpp.fsf@HIDDEN>
Message-Id: <E1dT9Dq-0000RY-5P@HIDDEN>
Date: Thu, 06 Jul 2017 12:01:42 -0400
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Then maybe I don't understand what you meant by "fill".  This feature
  > produces exactly the same display as M-q, but it doesn't insert
  > newline characters into the buffer.

That isn't what I saw.  What I saw is that it split individual lines
but didn't recombine them.

For instance, I inserted this text

======================================================================
Then maybe I don't understand what you meant by "fill".  This feature
produces exactly the same display as M-q, but it doesn't insert newline characters into the buffer.
Isn't that what you meant by
"filling"?
======================================================================

and enabled visual-line-mode, and what I see looks like

======================================================================
Then maybe I don't understand what you meant by "fill".  This feature
produces exactly the same display as M-q, but it doesn't insert newline
characters into the buffer.
Isn't that what you meant by
"filling"?
======================================================================

My Emacs sources are from December,  If this doesn't fail for you,
maybe it has been fixed since then.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 06 Jul 2017 16:19:01 +0000
Resent-Message-ID: <handler.27525.B27525.149935790230149 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: rms@HIDDEN
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149935790230149
          (code B ref 27525); Thu, 06 Jul 2017 16:19:01 +0000
Received: (at 27525) by debbugs.gnu.org; 6 Jul 2017 16:18:22 +0000
Received: from localhost ([127.0.0.1]:55355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dT9Ty-0007qC-9b
	for submit <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:18:22 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33814)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dT9Tw-0007pz-Eu
 for 27525 <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:18:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dT9Tn-00082r-Uy
 for 27525 <at> debbugs.gnu.org; Thu, 06 Jul 2017 12:18:15 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54500)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dT9Tn-00082l-RH; Thu, 06 Jul 2017 12:18:11 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3530
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dT9Tg-0000wR-Oz; Thu, 06 Jul 2017 12:18:05 -0400
Date: Thu, 06 Jul 2017 19:17:49 +0300
Message-Id: <83h8ypmtea.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <E1dT9Dq-0000RY-5P@HIDDEN> (message from Richard
 Stallman on Thu, 06 Jul 2017 12:01:42 -0400)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <E1dStGF-0008K2-1h@HIDDEN> <83r2xumgpp.fsf@HIDDEN>
 <E1dT9Dq-0000RY-5P@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Richard Stallman <rms@HIDDEN>
> CC: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
> Date: Thu, 06 Jul 2017 12:01:42 -0400
> 
>   > Then maybe I don't understand what you meant by "fill".  This feature
>   > produces exactly the same display as M-q, but it doesn't insert
>   > newline characters into the buffer.
> 
> That isn't what I saw.  What I saw is that it split individual lines
> but didn't recombine them.

Oh, you expected Emacs to remove the hard newlines as part of the
feature?  That's right, it doesn't do that, and neither do the other
editors.  They only remove "soft" newlines, and Emacs does that as
well.  Removing hard newlines would be a misfeature, IMO, since in
this mode they are user-controlled, and Emacs has no business
second-guessing the user.

> My Emacs sources are from December,  If this doesn't fail for you,
> maybe it has been fixed since then.

No, what you see is how it's supposed to work.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Jul 2017 18:24:01 +0000
Resent-Message-ID: <handler.27525.B27525.14994518402157 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.14994518402157
          (code B ref 27525); Fri, 07 Jul 2017 18:24:01 +0000
Received: (at 27525) by debbugs.gnu.org; 7 Jul 2017 18:24:00 +0000
Received: from localhost ([127.0.0.1]:57060 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dTXv6-0000Yj-IM
	for submit <at> debbugs.gnu.org; Fri, 07 Jul 2017 14:24:00 -0400
Received: from eggs.gnu.org ([208.118.235.92]:56147)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1dTXv4-0000YW-To
 for 27525 <at> debbugs.gnu.org; Fri, 07 Jul 2017 14:23:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rms@HIDDEN>) id 1dTXuy-0002R0-L9
 for 27525 <at> debbugs.gnu.org; Fri, 07 Jul 2017 14:23:53 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55957)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rms@HIDDEN>)
 id 1dTXuu-0002Mu-Hd; Fri, 07 Jul 2017 14:23:48 -0400
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1dTXut-00038o-Ua; Fri, 07 Jul 2017 14:23:47 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-reply-to: <83h8ypmtea.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 06
 Jul 2017 19:17:49 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <E1dStGF-0008K2-1h@HIDDEN> <83r2xumgpp.fsf@HIDDEN>
 <E1dT9Dq-0000RY-5P@HIDDEN> <83h8ypmtea.fsf@HIDDEN>
Message-Id: <E1dTXut-00038o-Ua@HIDDEN>
Date: Fri, 07 Jul 2017 14:23:47 -0400
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Removing hard newlines would be a misfeature, IMO, since in
  > this mode they are user-controlled, and Emacs has no business
  > second-guessing the user.

That's clearly right for editing _in_ that mode.

But it might be useful to have an alternate way to get into the mode,
one which would convert hard newlines to soft ones.  Exiting would
convert them back.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Jul 2017 19:22:01 +0000
Resent-Message-ID: <handler.27525.B27525.14994552997184 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: rms@HIDDEN
Cc: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.14994552997184
          (code B ref 27525); Fri, 07 Jul 2017 19:22:01 +0000
Received: (at 27525) by debbugs.gnu.org; 7 Jul 2017 19:21:39 +0000
Received: from localhost ([127.0.0.1]:57075 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dTYot-0001ro-AI
	for submit <at> debbugs.gnu.org; Fri, 07 Jul 2017 15:21:39 -0400
Received: from eggs.gnu.org ([208.118.235.92]:57696)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dTYor-0001rZ-Cx
 for 27525 <at> debbugs.gnu.org; Fri, 07 Jul 2017 15:21:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dTYoh-0006V1-B9
 for 27525 <at> debbugs.gnu.org; Fri, 07 Jul 2017 15:21:32 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56792)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dTYoh-0006Uf-7u; Fri, 07 Jul 2017 15:21:27 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4719
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dTYoa-0002Ma-1F; Fri, 07 Jul 2017 15:21:20 -0400
Date: Fri, 07 Jul 2017 22:21:08 +0300
Message-Id: <83y3s0kq8r.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <E1dTXut-00038o-Ua@HIDDEN> (message from Richard
 Stallman on Fri, 07 Jul 2017 14:23:47 -0400)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <E1dStGF-0008K2-1h@HIDDEN> <83r2xumgpp.fsf@HIDDEN>
 <E1dT9Dq-0000RY-5P@HIDDEN> <83h8ypmtea.fsf@HIDDEN>
 <E1dTXut-00038o-Ua@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Richard Stallman <rms@HIDDEN>
> CC: itai.berli@HIDDEN, 27525 <at> debbugs.gnu.org
> Date: Fri, 07 Jul 2017 14:23:47 -0400
> 
> But it might be useful to have an alternate way to get into the mode,
> one which would convert hard newlines to soft ones.  Exiting would
> convert them back.

Should be a nice new feature, yes.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 09 Jul 2017 18:18:02 +0000
Resent-Message-ID: <handler.27525.B27525.149962427727216 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org, itai.berli@HIDDEN
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149962427727216
          (code B ref 27525); Sun, 09 Jul 2017 18:18:02 +0000
Received: (at 27525) by debbugs.gnu.org; 9 Jul 2017 18:17:57 +0000
Received: from localhost ([127.0.0.1]:59115 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dUGmL-00074u-JF
	for submit <at> debbugs.gnu.org; Sun, 09 Jul 2017 14:17:57 -0400
Received: from odoacer.turtle-trading.net ([217.91.34.180]:45622)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <benny@HIDDEN>) id 1dUGmK-00074g-Cj
 for 27525 <at> debbugs.gnu.org; Sun, 09 Jul 2017 14:17:56 -0400
Received: from justinian.turtle-trading.net ([192.168.2.118])
 by odoacer.turtle-trading.net with esmtp (Exim 4.80)
 (envelope-from <benny@HIDDEN>)
 id 1dUGm5-0001UO-PE; Sun, 09 Jul 2017 20:17:41 +0200
Received: from benny by justinian.turtle-trading.net with local (Exim 4.84_2)
 (envelope-from <benny@HIDDEN>)
 id 1dUGm5-0002vb-LV; Sun, 09 Jul 2017 20:17:41 +0200
From: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
Date: Sun, 09 Jul 2017 20:17:41 +0200
In-Reply-To: <8337abobuz.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 05 Jul
 2017 05:29:08 +0300")
Message-ID: <87eftpa30a.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

>> From: Richard Stallman <rms@HIDDEN>
>> It might be good if Emacs could refill lines automatically the way
>> some other ediors do.

Eli Zaretskii writes:
> We already have that: "M-x visual-line-mode RET".

JFTR, even that does not help in this case.  With visual-line-mode the
order of the lines is still wrong with the text that the OP gave.

benny

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 09 Jul 2017 18:31:02 +0000
Resent-Message-ID: <handler.27525.B27525.149962504128459 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org, itai.berli@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.149962504128459
          (code B ref 27525); Sun, 09 Jul 2017 18:31:02 +0000
Received: (at 27525) by debbugs.gnu.org; 9 Jul 2017 18:30:41 +0000
Received: from localhost ([127.0.0.1]:59136 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dUGyf-0007Ox-FC
	for submit <at> debbugs.gnu.org; Sun, 09 Jul 2017 14:30:41 -0400
Received: from eggs.gnu.org ([208.118.235.92]:46278)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dUGyd-0007Ok-AE
 for 27525 <at> debbugs.gnu.org; Sun, 09 Jul 2017 14:30:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dUGyX-0007My-AF
 for 27525 <at> debbugs.gnu.org; Sun, 09 Jul 2017 14:30:34 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55410)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dUGyR-0007Kg-7Z; Sun, 09 Jul 2017 14:30:27 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3342
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dUGyQ-0003mm-FN; Sun, 09 Jul 2017 14:30:26 -0400
Date: Sun, 09 Jul 2017 21:30:20 +0300
Message-Id: <83a84djweb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87eftpa30a.fsf@HIDDEN> (message from Benjamin
 Riefenstahl on Sun, 09 Jul 2017 20:17:41 +0200)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
> Cc: 27525 <at> debbugs.gnu.org,  itai.berli@HIDDEN
> Date: Sun, 09 Jul 2017 20:17:41 +0200
> 
> >> From: Richard Stallman <rms@HIDDEN>
> >> It might be good if Emacs could refill lines automatically the way
> >> some other ediors do.
> 
> Eli Zaretskii writes:
> > We already have that: "M-x visual-line-mode RET".
> 
> JFTR, even that does not help in this case.  With visual-line-mode the
> order of the lines is still wrong with the text that the OP gave.

Of course.  It isn't supposed to help.  From the POV of the display
engine, visual-line-mode is just a fancy kind of producing
continuation lines, so all the problems you see with continued lines
will still be there in visual-line-mode.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jul 2017 08:52:01 +0000
Resent-Message-ID: <handler.27525.B27525.15004543031148 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.15004543031148
          (code B ref 27525); Wed, 19 Jul 2017 08:52:01 +0000
Received: (at 27525) by debbugs.gnu.org; 19 Jul 2017 08:51:43 +0000
Received: from localhost ([127.0.0.1]:47135 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dXkhr-0000IQ-6E
	for submit <at> debbugs.gnu.org; Wed, 19 Jul 2017 04:51:43 -0400
Received: from mail-wr0-f170.google.com ([209.85.128.170]:34485)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dXkhp-0000IA-2k
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 04:51:41 -0400
Received: by mail-wr0-f170.google.com with SMTP id 12so55790432wrb.1
 for <27525 <at> debbugs.gnu.org>; Wed, 19 Jul 2017 01:51:40 -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=10kuq68qhnwo9jTG3k227/wTeRDujh/aPJF7U0IknRc=;
 b=i9oqn3GOYK2QaGNfiFlLsvpaiincZwcZNU7Se1DC1ZgyOVd5vJpU5BdiXW2pmIadxa
 3kIOUFsACyP/BSn6KRxZP4RsFMsnuz5vLXlnvCvOvPVDdR09odC2QyCKHrzoMp92FIS2
 HKI8IcIGQsgDtEExE8s4SGw0MSQdMtwcvLGThqDae+mwwXgxqHNflAjvWDSYOcdDMlbn
 nbwqkX+ygxHd+IrHt13JLFZ6oc3pKj2d2MMH8TpnxpN489/Ob+XW0uBdCZi4RFdppKwn
 bAzqZbX2rQuqZv+NviOmndqSXdELfhi9mAMXgndbwHEJ4Xu9DcH3QrlQlcP+li0CmTW2
 YWIQ==
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=10kuq68qhnwo9jTG3k227/wTeRDujh/aPJF7U0IknRc=;
 b=k1ZN4+iSkP/mqytaApr8sYtbdVhFDHFu6OrCoSKU96uJkDnASJd/rRWBqsAhIAxQf+
 CbIm2A1V38DILJcJDZi8HIJ2+DuCHkh8ZmdjcoSG1Dayj8Lpi+nkEJVWwmismiKD28kX
 SgEOykCxCdb+NV/GV30aqh5CWD9rem/E3xxiHa5may3ASlx4PvLQlZN/6xxgqTdCoRog
 DmmPTg7jaP76+wLxQ/cI/Lbjz4x5BmKpsoBRNVjZsmIUSTnUTR7bmIeIFnKKedt/R4F3
 8+NygEHPRPrIlZqrpAu8t4VczEtoh+LM8pjRCPPvuVdmKnZnh8AZ8XwVEGZ6NV4KzucN
 qL8Q==
X-Gm-Message-State: AIVw112eNB6y7mdSiQLTGtz4HIEMU07dpBgmkEC4k1/N0obrxd9zL++s
 o6ySz2a8ZCnX4B92hgUoD1hM9ZU80VyVKIY=
X-Received: by 10.223.166.109 with SMTP id k100mr3383890wrc.209.1500454295068; 
 Wed, 19 Jul 2017 01:51:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.9 with HTTP; Wed, 19 Jul 2017 01:50:54 -0700 (PDT)
In-Reply-To: <83a84djweb.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Wed, 19 Jul 2017 11:50:54 +0300
Message-ID: <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
Content-Type: multipart/alternative; boundary="f403045cf7664267710554a7bde4"
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

--f403045cf7664267710554a7bde4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Eli, in different bug report, namely 27526, I recently wrote the following
remark:

> the line-wrapping bug is still a major annoyance, at best, and until it
is fixed, Emacs cannot claim to be Unicode compliant.

to which you replied:

> I disagree, as I already said many times.

You do agree, though, that Emacs does not conform to the Unicode
Bidirectional Algorithm as specified in the Unicode Standard Annex #9.
After all, the following paragraph appears in the bidi code itself (
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/bidi.c):

   Note that, because reordering is implemented below the level in
   xdisp.c that breaks glyphs into screen lines, we are violating
   paragraph 3.4 of UAX#9. which mandates that line breaking shall be
   done before reordering each screen line separately.

So the only thing you disagree with me is that non-conformance to the
Unicode Bidirectional Algorithm is tantamount to non-conformance to the
Unicode Standard. Well, this disagreement is easily settled by reading
article C12 'Bidirectional Text' of section 3.2 'Conformance Requirements'
of the Unicode Standard:

A process that displays text containing supported right-to-left characters
or embedding codes shall display all visible representations of characters
(excluding format characters) in the same order as if the Bidirectional
Algorithm had been applied to the text, unless tailored by a higher-level
protocol as permitted by the specification.

* The Bidirectional Algorithm is specified in Unicode Standard Annex #9,
=E2=80=9CUni- code Bidirectional Algorithm.=E2=80=9D


On Sun, Jul 9, 2017 at 9:30 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
> > Cc: 27525 <at> debbugs.gnu.org,  itai.berli@HIDDEN
> > Date: Sun, 09 Jul 2017 20:17:41 +0200
> >
> > >> From: Richard Stallman <rms@HIDDEN>
> > >> It might be good if Emacs could refill lines automatically the way
> > >> some other ediors do.
> >
> > Eli Zaretskii writes:
> > > We already have that: "M-x visual-line-mode RET".
> >
> > JFTR, even that does not help in this case.  With visual-line-mode the
> > order of the lines is still wrong with the text that the OP gave.
>
> Of course.  It isn't supposed to help.  From the POV of the display
> engine, visual-line-mode is just a fancy kind of producing
> continuation lines, so all the problems you see with continued lines
> will still be there in visual-line-mode.
>

--f403045cf7664267710554a7bde4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Eli, in different bug report, namely 27526, I recently wro=
te the following remark:<div><br></div><div><span style=3D"font-size:12.8px=
">&gt; the=C2=A0</span><span class=3D"gmail-m_4586446226191867975gmail-m_16=
48264449077757751gmail-m_7580623812396828587gmail-m_7648370520775038743gmai=
l-m_-8476453000225662030gmail-m_50193904117246291gmail-il" style=3D"font-si=
ze:12.8px;background-color:rgb(255,255,255)">line</span><span style=3D"font=
-size:12.8px">-</span><span class=3D"gmail-m_4586446226191867975gmail-m_164=
8264449077757751gmail-m_7580623812396828587gmail-m_7648370520775038743gmail=
-m_-8476453000225662030gmail-m_50193904117246291gmail-il" style=3D"font-siz=
e:12.8px;background-color:rgb(255,255,255)">wrapping</span><span style=3D"f=
ont-size:12.8px">=C2=A0bug is still a major=C2=A0</span><span style=3D"font=
-size:12.8px">annoyance, at best, and until it is fixed, Emacs cannot claim=
 to be Unicode compliant.</span><br style=3D"font-size:12.8px"><br>to which=
 you replied:</div><div><br></div><div>&gt;=C2=A0<span style=3D"font-size:1=
2.8px">I disagree, as I already said many times.</span></div><div><br></div=
><div>You do agree, though, that Emacs does not conform to the Unicode Bidi=
rectional Algorithm as specified in the Unicode Standard Annex #9. After al=
l, the following paragraph appears in the bidi code itself (<a href=3D"http=
://git.savannah.gnu.org/cgit/emacs.git/tree/src/bidi.c">http://git.savannah=
.gnu.org/cgit/emacs.git/tree/src/bidi.c</a>):</div><div><pre><code>   Note =
that, because reordering is implemented below the level in
   xdisp.c that breaks glyphs into screen lines, we are violating
   paragraph 3.4 of UAX#9. which mandates that line breaking shall be
   done before reordering each screen line separately.</code></pre></div><d=
iv>So the only thing you disagree with me is that non-conformance to the Un=
icode Bidirectional Algorithm is tantamount to non-conformance to the Unico=
de Standard. Well, this disagreement is easily settled by reading article C=
12 &#39;Bidirectional Text&#39; of section 3.2 &#39;Conformance Requirement=
s&#39; of the Unicode Standard:</div><div><br></div><div><font face=3D"mono=
space, monospace">A process that displays text containing supported right-t=
o-left characters or embedding codes shall display all visible representati=
ons of characters (excluding format characters) in the same order as if the=
 Bidirectional Algorithm had been applied to the text, unless tailored by a=
 higher-level protocol as permitted by the specification.</font></div><div>=
<font face=3D"monospace, monospace"><br></font></div><div><font face=3D"mon=
ospace, monospace">* The Bidirectional Algorithm is specified in Unicode St=
andard Annex #9, =E2=80=9CUni- code Bidirectional Algorithm.=E2=80=9D</font=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Sun, Jul 9, 2017 at 9:30 PM, Eli Zaretskii <span di=
r=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">&gt; From: Benjamin Riefenstahl &lt;<a href=3D"mailto:b.riefenstahl@turtl=
e-trading.net" target=3D"_blank">b.riefenstahl@turtle-trading.<wbr>net</a>&=
gt;<br>
&gt; Cc: <a href=3D"mailto:27525 <at> debbugs.gnu.org" target=3D"_blank">27525@d=
ebbugs.gnu.org</a>,=C2=A0 <a href=3D"mailto:itai.berli@HIDDEN" target=3D=
"_blank">itai.berli@HIDDEN</a><br>
&gt; Date: Sun, 09 Jul 2017 20:17:41 +0200<br>
<span>&gt;<br>
&gt; &gt;&gt; From: Richard Stallman &lt;<a href=3D"mailto:rms@HIDDEN" tar=
get=3D"_blank">rms@HIDDEN</a>&gt;<br>
&gt; &gt;&gt; It might be good if Emacs could refill lines automatically th=
e way<br>
&gt; &gt;&gt; some other ediors do.<br>
&gt;<br>
&gt; Eli Zaretskii writes:<br>
&gt; &gt; We already have that: &quot;M-x visual-line-mode RET&quot;.<br>
&gt;<br>
&gt; JFTR, even that does not help in this case.=C2=A0 With visual-line-mod=
e the<br>
&gt; order of the lines is still wrong with the text that the OP gave.<br>
<br>
</span>Of course.=C2=A0 It isn&#39;t supposed to help.=C2=A0 From the POV o=
f the display<br>
engine, visual-line-mode is just a fancy kind of producing<br>
continuation lines, so all the problems you see with continued lines<br>
will still be there in visual-line-mode.<br>
</blockquote></div><br></div></div></div>

--f403045cf7664267710554a7bde4--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jul 2017 13:01:02 +0000
Resent-Message-ID: <handler.27525.B27525.15004692046260 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.15004692046260
          (code B ref 27525); Wed, 19 Jul 2017 13:01:02 +0000
Received: (at 27525) by debbugs.gnu.org; 19 Jul 2017 13:00:04 +0000
Received: from localhost ([127.0.0.1]:47272 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dXoaB-0001cp-Li
	for submit <at> debbugs.gnu.org; Wed, 19 Jul 2017 09:00:04 -0400
Received: from mail-wr0-f175.google.com ([209.85.128.175]:33069)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dXoa9-0001bp-9E
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 09:00:02 -0400
Received: by mail-wr0-f175.google.com with SMTP id v105so28091825wrb.0
 for <27525 <at> debbugs.gnu.org>; Wed, 19 Jul 2017 06:00:01 -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=nnWM+oMYDs5eQRfx3C/xsLhoEwJn5qmJdj1XKApKUGs=;
 b=P/58dzt4L3RkomFkthzVcIogQwGWARiJrI7y/uRNBW8h3jPUb893mrEAZRKeAaB/BS
 +tWLNP/B1bU+xAXyrvzXfxGLzKpnoRjUMkgbAgtF0kjphFOXrD3bh3sU5sfqqIHP0aJu
 Ac89IQaE3fFOmjJE7c5fl2XRc6XZxCxz//yJEdxxF+4y/jzBKhO27E7CQhErcde4ViV+
 02wFfrcaWedbaN3VP7NU9MB4jL0EfHGf9lKQMtYX/yDQL/qii/ebGBGfxloB5dEm5uDJ
 J2C8LTNsKF6QqjUTyPSGjkRk4Hjj+kLsN5+oQ5ORVtR/C/uZn0Q3hggGLRVEzQ0epQUD
 uWog==
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=nnWM+oMYDs5eQRfx3C/xsLhoEwJn5qmJdj1XKApKUGs=;
 b=AQKMIqK+ONKU2KLDruf9MZo9S7BefHw6vaU0uc3cHjOJlV7UDrc4McjIPx0jaSQy8p
 WQDPXg7d4eF6IwAbGGUbzfVZDMqXACTBEFHQRZ21ZVudQRhxYuYBrYwwN5IeZbFKNJwb
 osvlC5bR8oHSX0U3KD+nWPM/aR1tmFTh/Mn5/MpRLy/BEqt/g2bXzamxpWVct5Y41KQ5
 7kfU/64RJ+aSAYfCiO7YN7iYIZ4SJyj0bOLUm3SoEOg2PqUtP4Pm5w8cYt44FAC0Il7y
 xmgUf67qgsUbMYI0mFK1Fi2sP/5E+3DA7/VUAhU1qqYyDL3h+sR+qqP4oB9olxXRIbz6
 tQaA==
X-Gm-Message-State: AIVw111XVvcUF4sGVR3u9i5+DStYkUgDiM/NfRH62ORB9Q2Xa/Pv0zD7
 zbxD53FY5qU2w8qAIsaF68OcswFyEGe6uKg=
X-Received: by 10.223.170.150 with SMTP id h22mr4516857wrc.140.1500469195154; 
 Wed, 19 Jul 2017 05:59:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.9 with HTTP; Wed, 19 Jul 2017 05:59:14 -0700 (PDT)
In-Reply-To: <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Wed, 19 Jul 2017 15:59:14 +0300
Message-ID: <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
Content-Type: multipart/alternative; boundary="94eb2c1b47ce5fc6bd0554ab35a5"
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

--94eb2c1b47ce5fc6bd0554ab35a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

And in case you counter that Emacs takes advantage of the "higher-level
protocol" clause, this clause doesn't apply to paragraph 3.4, which Emacs
violates.

But don't take my word for it. I contacted Mr. Aharon Lanin in the matter.
Mr. Lanin is a senior software engineer at Google Tel Aviv as well as one
of the three editors of the Unicode Bidirectional Algorithm from version
6.3.0 till the latest one, v. 10.0.0. I presented him with the following
screenshot of a bidi paragraph in Emacs (it's the same screenshot as I
posted originally in the present ticket): http://imgur.com/Bckn7zP

I list below an excerp from our conversation, which Mr. Lanin has given me
permission to quote.

--- EXCERPT BEGIN ---

***Me***: Just to be clear, are the following statements correct for the
Unicode Standard v. 8.0.0 and above? (I'm mentioning v. 8.0.0 because this
is the version that Emacs claims conformance to.)

1. The way Emacs handles line wrapping of bidi paragraphs does not satisfy
section 3.4 of the Unicode Bidirectional Algorithm. There are no provisions
for higher-level protocol interpretation of this section.

2. If a candidate implementation of the Unicode Bidirectional Algorithm
doesn't satisfy section 3.4, it does not conform to the Unicode
Bidirectional Algorithm.

3. If a candidate implementation of the Unicode Standard does not conform
to the Unicode Bidirectional Algorithm (of the same version), it does not
conform to the Unicode Standard.

***Lanin*** I think so, but I am a programmer, not a lawyer :-)

--- EXCERPT END ---

The Emacs manual and all official Emacs publications should make it clear
that Emacs does not conform to the Unicode Standard. Anything else is
simply not true, and is a deliberate misleading.

On Wed, Jul 19, 2017 at 11:50 AM, Itai Berli <itai.berli@HIDDEN> wrote:

> Eli, in different bug report, namely 27526, I recently wrote the followin=
g
> remark:
>
> > the line-wrapping bug is still a major annoyance, at best, and until it
> is fixed, Emacs cannot claim to be Unicode compliant.
>
> to which you replied:
>
> > I disagree, as I already said many times.
>
> You do agree, though, that Emacs does not conform to the Unicode
> Bidirectional Algorithm as specified in the Unicode Standard Annex #9.
> After all, the following paragraph appears in the bidi code itself (
> http://git.savannah.gnu.org/cgit/emacs.git/tree/src/bidi.c):
>
>    Note that, because reordering is implemented below the level in
>    xdisp.c that breaks glyphs into screen lines, we are violating
>    paragraph 3.4 of UAX#9. which mandates that line breaking shall be
>    done before reordering each screen line separately.
>
> So the only thing you disagree with me is that non-conformance to the
> Unicode Bidirectional Algorithm is tantamount to non-conformance to the
> Unicode Standard. Well, this disagreement is easily settled by reading
> article C12 'Bidirectional Text' of section 3.2 'Conformance Requirements=
'
> of the Unicode Standard:
>
> A process that displays text containing supported right-to-left character=
s
> or embedding codes shall display all visible representations of character=
s
> (excluding format characters) in the same order as if the Bidirectional
> Algorithm had been applied to the text, unless tailored by a higher-level
> protocol as permitted by the specification.
>
> * The Bidirectional Algorithm is specified in Unicode Standard Annex #9,
> =E2=80=9CUni- code Bidirectional Algorithm.=E2=80=9D
>
>
> On Sun, Jul 9, 2017 at 9:30 PM, Eli Zaretskii <eliz@HIDDEN> wrote:
>
>> > From: Benjamin Riefenstahl <b.riefenstahl@HIDDEN>
>> > Cc: 27525 <at> debbugs.gnu.org,  itai.berli@HIDDEN
>> > Date: Sun, 09 Jul 2017 20:17:41 +0200
>> >
>> > >> From: Richard Stallman <rms@HIDDEN>
>> > >> It might be good if Emacs could refill lines automatically the way
>> > >> some other ediors do.
>> >
>> > Eli Zaretskii writes:
>> > > We already have that: "M-x visual-line-mode RET".
>> >
>> > JFTR, even that does not help in this case.  With visual-line-mode the
>> > order of the lines is still wrong with the text that the OP gave.
>>
>> Of course.  It isn't supposed to help.  From the POV of the display
>> engine, visual-line-mode is just a fancy kind of producing
>> continuation lines, so all the problems you see with continued lines
>> will still be there in visual-line-mode.
>>
>
>

--94eb2c1b47ce5fc6bd0554ab35a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And in case you counter that Emacs takes advantage of the =
&quot;higher-level protocol&quot; clause, this clause doesn&#39;t apply to =
paragraph 3.4, which Emacs violates.<div><br></div><div>But don&#39;t take =
my word for it. I contacted Mr. Aharon Lanin in the matter. Mr. Lanin is a =
senior software engineer at Google Tel Aviv as well as one of the three edi=
tors of the Unicode Bidirectional Algorithm from version 6.3.0 till the lat=
est one, v. 10.0.0. I presented him with the following screenshot of a bidi=
 paragraph in Emacs (it&#39;s the same screenshot as I posted originally in=
 the present ticket):=C2=A0<a href=3D"http://imgur.com/Bckn7zP" target=3D"_=
blank">http://imgur.com/Bckn<wbr>7zP</a><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">I list below an excerp from our conversation, =
which Mr. Lanin has given me permission to quote.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">--- EXCERPT BEGIN ---</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">***Me***:=C2=A0=
<span style=3D"font-size:12.8px">Just to be clear,</span><span style=3D"fon=
t-size:12.8px">=C2=A0</span><span style=3D"font-size:12.8px">are the follow=
ing statements correct for the Unicode Standard v. 8.0.0 and above? (I&#39;=
m mentioning v. 8.0.0 because this is the version that Emacs claims conform=
ance to.)</span></div><div style=3D"font-size:12.8px"><br></div><div style=
=3D"font-size:12.8px">1. The way Emacs handles line wrapping of bidi paragr=
aphs does not satisfy section 3.4 of the Unicode Bidirectional Algorithm<sp=
an style=3D"font-size:12.8px">. There are no provisions for higher-level pr=
otocol interpretation of this section.</span></div><div style=3D"font-size:=
12.8px"><span style=3D"font-size:12.8px"><br></span></div><div style=3D"fon=
t-size:12.8px"><span style=3D"font-size:12.8px">2. If a candidate implement=
ation of the Unicode Bidirectional Algorithm doesn&#39;t satisfy section 3.=
4, it does not conform to the Unicode Bidirectional Algorithm.</span></div>=
<div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></span=
></div><div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">3. =
If a candidate implementation of the Unicode Standard does not conform to t=
he Unicode Bidirectional Algorithm (of the same version), it does not confo=
rm to the Unicode Standard.</span></div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">***Lanin***=C2=A0<span style=3D"font-size:12.8=
px">I think so, but I am a programmer, not a lawyer :-)</span></div><div cl=
ass=3D"gmail_extra"><span style=3D"font-size:12.8px"><br></span></div><div =
class=3D"gmail_extra"><span style=3D"font-size:12.8px">--- EXCERPT END ---<=
/span></div></div><div class=3D"gmail_extra"><span style=3D"font-size:12.8p=
x"><br></span></div><div class=3D"gmail_extra"><span style=3D"font-size:12.=
8px">The Emacs manual and all official Emacs publications should make it cl=
ear that Emacs does not conform to the Unicode Standard. Anything else is s=
imply not true, and is a deliberate misleading.</span></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 19, 2017 at 11=
:50 AM, Itai Berli <span dir=3D"ltr">&lt;<a href=3D"mailto:itai.berli@gmail=
.com" target=3D"_blank">itai.berli@HIDDEN</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Eli, in different bug report, na=
mely 27526, I recently wrote the following remark:<div><br></div><div><span=
 style=3D"font-size:12.8px">&gt; the=C2=A0</span><span class=3D"m_183185420=
619152252gmail-m_4586446226191867975gmail-m_1648264449077757751gmail-m_7580=
623812396828587gmail-m_7648370520775038743gmail-m_-8476453000225662030gmail=
-m_50193904117246291gmail-il" style=3D"font-size:12.8px;background-color:rg=
b(255,255,255)">line</span><span style=3D"font-size:12.8px">-</span><span c=
lass=3D"m_183185420619152252gmail-m_4586446226191867975gmail-m_164826444907=
7757751gmail-m_7580623812396828587gmail-m_7648370520775038743gmail-m_-84764=
53000225662030gmail-m_50193904117246291gmail-il" style=3D"font-size:12.8px;=
background-color:rgb(255,255,255)">wrapping</span><span style=3D"font-size:=
12.8px">=C2=A0bug is still a major=C2=A0</span><span style=3D"font-size:12.=
8px">annoyance, at best, and until it is fixed, Emacs cannot claim to be Un=
icode compliant.</span><br style=3D"font-size:12.8px"><br>to which you repl=
ied:</div><div><br></div><div>&gt;=C2=A0<span style=3D"font-size:12.8px">I =
disagree, as I already said many times.</span></div><div><br></div><div>You=
 do agree, though, that Emacs does not conform to the Unicode Bidirectional=
 Algorithm as specified in the Unicode Standard Annex #9. After all, the fo=
llowing paragraph appears in the bidi code itself (<a href=3D"http://git.sa=
vannah.gnu.org/cgit/emacs.git/tree/src/bidi.c" target=3D"_blank">http://git=
.savannah.gnu.org/<wbr>cgit/emacs.git/tree/src/bidi.c</a><wbr>):</div><div>=
<pre><code>   Note that, because reordering is implemented below the level =
in
   xdisp.c that breaks glyphs into screen lines, we are violating
   paragraph 3.4 of UAX#9. which mandates that line breaking shall be
   done before reordering each screen line separately.</code></pre></div><d=
iv>So the only thing you disagree with me is that non-conformance to the Un=
icode Bidirectional Algorithm is tantamount to non-conformance to the Unico=
de Standard. Well, this disagreement is easily settled by reading article C=
12 &#39;Bidirectional Text&#39; of section 3.2 &#39;Conformance Requirement=
s&#39; of the Unicode Standard:</div><div><br></div><div><font face=3D"mono=
space, monospace">A process that displays text containing supported right-t=
o-left characters or embedding codes shall display all visible representati=
ons of characters (excluding format characters) in the same order as if the=
 Bidirectional Algorithm had been applied to the text, unless tailored by a=
 higher-level protocol as permitted by the specification.</font></div><div>=
<font face=3D"monospace, monospace"><br></font></div><div><font face=3D"mon=
ospace, monospace">* The Bidirectional Algorithm is specified in Unicode St=
andard Annex #9, =E2=80=9CUni- code Bidirectional Algorithm.=E2=80=9D</font=
><div><div class=3D"h5"><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jul 9, 2017 at 9:30 PM,=
 Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=
=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt; From: Benjamin Riefenstahl &lt;<a href=3D"mai=
lto:b.riefenstahl@HIDDEN" target=3D"_blank">b.riefenstahl@turtl=
e-trading.<wbr>net</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:27525 <at> debbugs.gnu.org" target=3D"_blank">27525@d=
ebbugs.gnu.org</a>,=C2=A0 <a href=3D"mailto:itai.berli@HIDDEN" target=3D=
"_blank">itai.berli@HIDDEN</a><br>
&gt; Date: Sun, 09 Jul 2017 20:17:41 +0200<br>
<span>&gt;<br>
&gt; &gt;&gt; From: Richard Stallman &lt;<a href=3D"mailto:rms@HIDDEN" tar=
get=3D"_blank">rms@HIDDEN</a>&gt;<br>
&gt; &gt;&gt; It might be good if Emacs could refill lines automatically th=
e way<br>
&gt; &gt;&gt; some other ediors do.<br>
&gt;<br>
&gt; Eli Zaretskii writes:<br>
&gt; &gt; We already have that: &quot;M-x visual-line-mode RET&quot;.<br>
&gt;<br>
&gt; JFTR, even that does not help in this case.=C2=A0 With visual-line-mod=
e the<br>
&gt; order of the lines is still wrong with the text that the OP gave.<br>
<br>
</span>Of course.=C2=A0 It isn&#39;t supposed to help.=C2=A0 From the POV o=
f the display<br>
engine, visual-line-mode is just a fancy kind of producing<br>
continuation lines, so all the problems you see with continued lines<br>
will still be there in visual-line-mode.<br>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>

--94eb2c1b47ce5fc6bd0554ab35a5--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jul 2017 17:25:01 +0000
Resent-Message-ID: <handler.27525.B27525.150048509530861 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150048509530861
          (code B ref 27525); Wed, 19 Jul 2017 17:25:01 +0000
Received: (at 27525) by debbugs.gnu.org; 19 Jul 2017 17:24:55 +0000
Received: from localhost ([127.0.0.1]:48056 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dXsiU-00081h-Ol
	for submit <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:24:54 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49047)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dXsiT-00081V-8u
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:24:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dXsiK-0003as-UK
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:24:48 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45476)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dXsiK-0003ao-R2; Wed, 19 Jul 2017 13:24:44 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2218
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dXsiJ-00013U-Bs; Wed, 19 Jul 2017 13:24:44 -0400
Date: Wed, 19 Jul 2017 20:24:26 +0300
Message-Id: <83tw28bar9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 (message from Itai Berli on Wed, 19 Jul 2017 11:50:54 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Wed, 19 Jul 2017 11:50:54 +0300
> 
> Eli, in different bug report, namely 27526, I recently wrote the following remark:
> 
> > the line-wrapping bug is still a major annoyance, at best, and until it is fixed, Emacs cannot claim to be
> Unicode compliant.
> 
> to which you replied:
> 
> > I disagree, as I already said many times.
> 
> You do agree, though, that Emacs does not conform to the Unicode Bidirectional Algorithm as specified in the
> Unicode Standard Annex #9.

I maintain that Emacs deviates from the UBA in a relatively minor way,
in an aspect that is only tangentially related to reordering
bidirectional text for display, and that raises its head in situations
that are relatively rare in practice, and in many of those rare cases
can be easily worked around by breaking long lines.

> So the only thing you disagree with me is that non-conformance to the Unicode Bidirectional Algorithm is
> tantamount to non-conformance to the Unicode Standard.

Not only, see above.

> Well, this disagreement is easily settled by reading
> article C12 'Bidirectional Text' of section 3.2 'Conformance Requirements' of the Unicode Standard:

No, it is not settled; see above.

And I don't really understand what is the purpose of your insistence
on the formal definition of this deviation.  It certainly won't help
fixing this issue any time soon, not unless someone steps forward to
do the job, which IMO is quite large.  All it does is cause me to
think, for the first time in many years, whether I indeed had to
invest all that huge amount of time and energy in single-handedly
coding, testing, and debugging the bidirectional text support for
Emacs, which even today, 10 years later, still shines among all the
bidi-aware editors out there, certainly among those of the Free
Software variety.  Even the fribidi library didn't yet catch up with
Unicode 6.3 and later.

If after all that all I get is this badgering about a minor issue
whose solution needs a thorough rewrite of the related code, then I
wish I never wasted those efforts working on a feature which I naïvely
assumed will be tremendously useful to many, and that in fact causes
only negative reactions from the few who use it.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jul 2017 17:29:02 +0000
Resent-Message-ID: <handler.27525.B27525.150048532931221 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150048532931221
          (code B ref 27525); Wed, 19 Jul 2017 17:29:02 +0000
Received: (at 27525) by debbugs.gnu.org; 19 Jul 2017 17:28:49 +0000
Received: from localhost ([127.0.0.1]:48074 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dXsmH-00087V-9u
	for submit <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:28:49 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49765)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dXsmF-00087H-JR
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:28:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dXsm7-0005L8-87
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 13:28:42 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45507)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dXsm7-0005L1-4q; Wed, 19 Jul 2017 13:28:39 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2219
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dXsm6-00042p-Ho; Wed, 19 Jul 2017 13:28:38 -0400
Date: Wed, 19 Jul 2017 20:28:27 +0300
Message-Id: <83shhsbakk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 (message from Itai Berli on Wed, 19 Jul 2017 15:59:14 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Wed, 19 Jul 2017 15:59:14 +0300
> 
> The Emacs manual and all official Emacs publications should make it clear that Emacs does not conform to
> the Unicode Standard. Anything else is simply not true, and is a deliberate misleading.

The Emacs manual already describes this deviation.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jul 2017 21:42:02 +0000
Resent-Message-ID: <handler.27525.B27525.150050046522274 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150050046522274
          (code B ref 27525); Wed, 19 Jul 2017 21:42:02 +0000
Received: (at 27525) by debbugs.gnu.org; 19 Jul 2017 21:41:05 +0000
Received: from localhost ([127.0.0.1]:48200 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dXwiO-0005nB-Oz
	for submit <at> debbugs.gnu.org; Wed, 19 Jul 2017 17:41:05 -0400
Received: from mail-wm0-f50.google.com ([74.125.82.50]:38449)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dXwiM-0005ma-KP
 for 27525 <at> debbugs.gnu.org; Wed, 19 Jul 2017 17:41:03 -0400
Received: by mail-wm0-f50.google.com with SMTP id w191so10520647wmw.1
 for <27525 <at> debbugs.gnu.org>; Wed, 19 Jul 2017 14:41:02 -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=ATCZ6vINtdXcrHpzxrrrMb2Z5N9EAmm3G+P6GyOK9QU=;
 b=DEC0AtzWm6dsjVHU/6Jo//DGHB8DVfAl+X0Bk335RbbnObQ+f84ZMb8UBK7EnxCLFn
 MdhEyschGT+l30oVCPlsCp4wG2OnTr+QiSV1HN9QnGjKdvYvopMkNjlXUljP7TVfgyyy
 +zboMF2NUU7+EJEDeDSLtV1pvm40cbKR5DISJA+9cq4d3fjVkH6k4vy9Jskd1Rzd6ldU
 BkCQxW4nXzNOh8QThfXUcPk7dD3hRP8MQ6CSyY45V5d9TdrxJZbFxzxZmVFJZoicIjI8
 fNiPvYMzRO3g716QI0f7Gvw5NOoSBGZjH/cuquSHkRF7+s2FrfE8f3GSIi3R/tOf9oxp
 WI2Q==
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=ATCZ6vINtdXcrHpzxrrrMb2Z5N9EAmm3G+P6GyOK9QU=;
 b=Z23bEz5KL7eXPeP1JZk5zgz7EGrGL0qNscioGEwNgFV2I3/yhh3qX2CQWpxuNRjFSj
 9xLkpdL7CsWKsR1nX4vqhNA6SVJh7eFZd0dXH/fJN66law2cxpUl8xGG3z9kHy2q5k15
 uXb7F35Vim5wl4o/ZMLUFikWDtPwNEU5X9yRGf8mdez5obIV5BrgINL+zNz0GB+YJ8XX
 Aff91wMGH/JJAoJkwWiacevEM3hQrrOqZ42tXZM5viyUEZbwFTJFqUZdRPOtWIwi4QRK
 NPVdN7yVJQ7n8JL5oo1YJ6p8MhFDslTvIujD2meogwdxnInQO3myqI9rEGcDzc6DwKCO
 /UEQ==
X-Gm-Message-State: AIVw1105OMek+Fxutz00mul/HkcpnrejXOgY49xeCAhsmyN4td7MN5TK
 WRwS9zp0iu4YvGUc9RuvbCuja6jaZJng
X-Received: by 10.28.7.211 with SMTP id 202mr881730wmh.113.1500500456372; Wed,
 19 Jul 2017 14:40:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.9 with HTTP; Wed, 19 Jul 2017 14:40:15 -0700 (PDT)
In-Reply-To: <83shhsbakk.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Thu, 20 Jul 2017 00:40:15 +0300
Message-ID: <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11443512b0024f0554b27c5d"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--001a11443512b0024f0554b27c5d
Content-Type: text/plain; charset="UTF-8"

I appreciate your hard work. I can imagine that it took you a lot of time,
effort and agony to pull off this feature, and your efforts were
worthwhile: you created a good and helpful feature. For some purposes the
feature is perfect as it is, especially now that you've allowed
customization of the paragraph separator. I believe Emacs can be the #1
plain-text bidi editor out there, but this hinges on fixing this bug.

> I maintain that Emacs deviates from the UBA in a relatively minor way,
in an aspect that is only tangentially related to reordering
bidirectional text for display, and that raises its head in situations
that are relatively rare in practice, and in many of those rare cases
can be easily worked around by breaking long lines.

One of the valuable aspects of an ISO standard is that it is not left to
the personal judgment of a programmer to decide what is worth implementing,
and how to do so. It is not for you to decide what is a minor detail and
what is a major one, what is tangential and what is core. You need to
implement it to the letter, or else you can't claim conformance, no matter
how slight you imagine your deviation to be.

On what do you base your claim that this problem occurs relatively rarely
in practice? This is the kind of statement that only a specialist
linguist/statistician can make. And have you taken into account the type of
demographics who use Emacs' bidi feature and the kinds of texts they're
likely to type?

Contrary to what you said, my personal experience show that this is a major
inconvenience, and that it is a situation that occurs very often, almost
every paragraph, in fact, since I write primarily LaTeX documents where
English markup is intermixed with predominantly Hebrew text containing
frequent quotes from English textbooks and articles.

Yes, breaking lines is a possible workaround for LaTex, but it makes for
ugly and erratic looking paragraphs that are difficult to read and edit.
And what about documents that are not LaTeX? What workaround do they have?

You mention breaking "long lines", but this is not just a problem of long
lines. It takes just two English words inside a Hebrew paragraph that
happen to fall on a line break, to manifest this bug.

>  even today, 10 years later, still shines among all the
bidi-aware editors out there, certainly among those of the Free
Software variety.

Yes, Emacs shines as one of the very rare bidi-aware text editors that
enable entering explicit directional formatting characters. This is indeed
to Emacs' credit and is a very helpful feature.

However, Emacs also shines as possibly the only bidi-aware text editor that
botches the line wrapping of bidi paragraphs. Every single editor that I've
checked gets it right: from Word to Kate to GEdit to Google Docs to
BlueFish to TextEdit.

> And I don't really understand what is the purpose of your insistence
on the formal definition of this deviation.  It certainly won't help
fixing this issue any time soon, not unless someone steps forward to
do the job, which IMO is quite large.

I don't know what you mean by 'the formal definition of this deviation'. I
think that Emacs should not mislead the users and potential users. That it
should not claim to conform to a standard when it does not. I think that
when prospective users google "Emacs bidi" or "Emacs unicode" they will be
able to easily see that there's a problem with bidi line wrapping and that
if they require a text editor that is Unicode compliant they should look
elsewhere. The keywords are: transparency, truth in advertising,
user-friendly, and standards-oriented.

> The Emacs manual already describes this deviation.

In the online manual sections 22.19 (Bidirectional Editing) and 37.26
(Bidirectional Display) claim that Emacs implements the Unicode
Bidirectional Algorithm.


On Wed, Jul 19, 2017 at 8:28 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Itai Berli <itai.berli@HIDDEN>
> > Date: Wed, 19 Jul 2017 15:59:14 +0300
> >
> > The Emacs manual and all official Emacs publications should make it
> clear that Emacs does not conform to
> > the Unicode Standard. Anything else is simply not true, and is a
> deliberate misleading.
>
> The Emacs manual already describes this deviation.
>

--001a11443512b0024f0554b27c5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><span style=3D"font-size:12.8px">I appreciate your ha=
rd work. I can imagine that it took you a lot of time, effort and agony to =
pull off this feature, and your efforts were worthwhile: you created a good=
 and helpful feature. For some purposes=C2=A0</span><span style=3D"font-siz=
e:12.8px">the feature is perfect as it is, especially now that you&#39;ve a=
llowed customization of the paragraph separator. I believe Emacs can be the=
 #1 plain-text bidi editor out there, but this hinges on fixing this bug.</=
span></div><div><br></div><div><span style=3D"font-size:12.8px">&gt; I main=
tain that Emacs deviates from the UBA in a relatively minor way,</span><br>=
</div><span style=3D"font-size:12.8px">in an aspect that is only tangential=
ly related to reordering</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">bidirectional text for display, and that raises its h=
ead in situations</span><br style=3D"font-size:12.8px"><span style=3D"font-=
size:12.8px">that are relatively rare in practice, and in many of those rar=
e cases</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8p=
x">can be easily worked around by breaking long lines.</span><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">One of the valuable aspects of an ISO standard is that it is not left t=
o the personal judgment of a programmer to decide what is worth implementin=
g, and how to do so. It is not for you to decide what is a minor detail and=
 what is a major one, what is tangential and what is core. You need to impl=
ement it to the letter, or else you can&#39;t claim conformance, no matter =
how slight you imagine your deviation to be.</span></div><div><br></div><di=
v><span style=3D"font-size:12.8px">On what do you base your claim that this=
 problem occurs relatively rarely in practice? This is the kind of statemen=
t that only a specialist linguist/statistician can make. And have you taken=
 into account the type of demographics who use Emacs&#39; bidi feature and =
the kinds of texts they&#39;re likely to type?</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">Contrary to what you said, my personal experience show that this is a maj=
or inconvenience, and that it is a situation that occurs very often, almost=
 every paragraph, in fact, since I write primarily LaTeX documents where En=
glish markup is intermixed with predominantly Hebrew text containing freque=
nt quotes from English textbooks and articles.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div>Yes, breaking lines is a possib=
le workaround for LaTex, but it makes for ugly and erratic looking paragrap=
hs that are difficult to read and edit. And what about documents that are n=
ot LaTeX? What workaround do they have?</div><div><br></div><div>You mentio=
n breaking &quot;long lines&quot;, but this is not just a problem of long l=
ines. It takes just two English words inside a Hebrew paragraph that happen=
 to fall on a line break, to manifest this bug.</div><div><br></div><div>&g=
t;=C2=A0<span style=3D"font-size:12.8px">=C2=A0</span><span style=3D"font-s=
ize:12.8px">even today, 10 years later, still shines among all the</span></=
div><span style=3D"font-size:12.8px">bidi-aware editors out there, certainl=
y among those of the Free</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">Software variety.</span><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Yes, Emacs =
shines as one of the very rare bidi-aware text editors that enable entering=
 explicit directional formatting characters. This is indeed to Emacs&#39; c=
redit and is a very helpful feature.</span></div><div><span style=3D"font-s=
ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">However,=
 Emacs also shines as possibly the only bidi-aware text editor that botches=
 the line wrapping of bidi paragraphs. Every single editor that I&#39;ve ch=
ecked gets it right: from Word to Kate to GEdit to Google Docs to BlueFish =
to TextEdit.</span></div><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">&gt;=C2=A0</span><span style=3D"=
font-size:12.8px">And I don&#39;t really understand what is the purpose of =
your insistence</span></div><span style=3D"font-size:12.8px">on the formal =
definition of this deviation.=C2=A0 It certainly won&#39;t help</span><br s=
tyle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">fixing this issu=
e any time soon, not unless someone steps forward to</span><br style=3D"fon=
t-size:12.8px"><span style=3D"font-size:12.8px">do the job, which IMO is qu=
ite large.=C2=A0</span><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">I don&#39;t know what you mean by =
&#39;the formal definition of this deviation&#39;. I think that Emacs shoul=
d not mislead the users and potential users. That it should not claim to co=
nform to a standard when it does not. I think that when prospective users g=
oogle &quot;Emacs bidi&quot; or &quot;Emacs unicode&quot; they will be able=
 to easily see that there&#39;s a problem with bidi line wrapping and that =
if they require a text editor that is Unicode compliant they should look el=
sewhere. The keywords are: transparency, truth in advertising, user-friendl=
y, and standards-oriented.</span></div><div><br></div><div><div><div>&gt;=
=C2=A0<span style=3D"font-size:12.8px">The Emacs manual already describes t=
his deviation.</span></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">In the online manual sections=
=C2=A022.19 (Bidirectional Editing) and=C2=A037.26 (Bidirectional Display) =
claim that Emacs implements the=C2=A0</span>Unicode Bidirectional Algorithm=
.</div></div><div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 19, 201=
7 at 8:28 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@gn=
u.org" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">&gt; From: Itai Berli &lt;<a href=3D"=
mailto:itai.berli@HIDDEN" target=3D"_blank">itai.berli@HIDDEN</a>&gt;=
<br>
&gt; Date: Wed, 19 Jul 2017 15:59:14 +0300<br>
<span>&gt;<br>
&gt; The Emacs manual and all official Emacs publications should make it cl=
ear that Emacs does not conform to<br>
&gt; the Unicode Standard. Anything else is simply not true, and is a delib=
erate misleading.<br>
<br>
</span>The Emacs manual already describes this deviation.<br>
</blockquote></div><br></div></div></div></div>

--001a11443512b0024f0554b27c5d--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jul 2017 05:09:02 +0000
Resent-Message-ID: <handler.27525.B27525.150052730810969 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150052730810969
          (code B ref 27525); Thu, 20 Jul 2017 05:09:02 +0000
Received: (at 27525) by debbugs.gnu.org; 20 Jul 2017 05:08:28 +0000
Received: from localhost ([127.0.0.1]:48412 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dY3hM-0002qq-8o
	for submit <at> debbugs.gnu.org; Thu, 20 Jul 2017 01:08:28 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33022)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dY3hK-0002qd-JN
 for 27525 <at> debbugs.gnu.org; Thu, 20 Jul 2017 01:08:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dY3hC-000358-5Y
 for 27525 <at> debbugs.gnu.org; Thu, 20 Jul 2017 01:08:21 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51780)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dY3hC-000352-1c; Thu, 20 Jul 2017 01:08:18 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3253
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dY3hB-00038f-I3; Thu, 20 Jul 2017 01:08:17 -0400
Date: Thu, 20 Jul 2017 08:08:07 +0300
Message-Id: <83lgnjbsqw.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 (message from Itai Berli on Thu, 20 Jul 2017 00:40:15 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Thu, 20 Jul 2017 00:40:15 +0300
> 
> I believe Emacs
> can be the #1 plain-text bidi editor out there, but this hinges on fixing this bug.

And I believe you exaggerate the importance of this issue, and how
much it diminishes the usefulness of the Emacs bidi support.  Can we
agree to disagree about that, now that we've reiterated that
disagreement many times, and all of that is forever recorded in the
bug tracker?

> 
> > I maintain that Emacs deviates from the UBA in a relatively minor way,
> in an aspect that is only tangentially related to reordering
> bidirectional text for display, and that raises its head in situations
> that are relatively rare in practice, and in many of those rare cases
> can be easily worked around by breaking long lines.
> 
> One of the valuable aspects of an ISO standard is that it is not left to the personal judgment of a programmer
> to decide what is worth implementing, and how to do so. It is not for you to decide what is a minor detail and
> what is a major one, what is tangential and what is core. You need to implement it to the letter, or else you
> can't claim conformance, no matter how slight you imagine your deviation to be.

Of course, it's for me to decide.  Emacs is not an implementation of
the Unicode Standard: Emacs _follows_ the Unicode recommendations
where we decide it to be useful/practical, and doesn't where we don't.

> On what do you base your claim that this problem occurs relatively rarely in practice? This is the kind of
> statement that only a specialist linguist/statistician can make. And have you taken into account the type of
> demographics who use Emacs' bidi feature and the kinds of texts they're likely to type?

It doesn't take a statistician/linguist to realize that

  . long lines that wrap on Emacs display are rare to begin with
  . lines with predominantly RTL text in LTR paragraphs are rare, and
    likewise lines with predominantly LTR text in RTL paragraphs
  . multiplying 2 rare cases makes the result very rare

> Contrary to what you said, my personal experience show that this is a major inconvenience, and that it is a
> situation that occurs very often, almost every paragraph, in fact, since I write primarily LaTeX documents
> where English markup is intermixed with predominantly Hebrew text containing frequent quotes from English
> textbooks and articles.

LaTeX documents can easily work around the problem by breaking long
lines into shorter ones.

> Yes, breaking lines is a possible workaround for LaTex, but it makes for ugly and erratic looking paragraphs
> that are difficult to read and edit.

I fail to see why it would be ugly or hard to read.  Especially since
you can now have a different paragraph direction after every newline.
Perhaps you need to break lines more judiciously, not at random
points.

> And what about documents that are not LaTeX? What workaround do they
> have?

Plain text documents, and documents that are "nearly plain text", like
TeX, Texinfo, and other similar systems, rarely if ever consider
newlines as significant.  So this workaround is available there as
well.  About the only exception I know of is poetry, where over-long
lines are even rarer.

Btw, on GUI terminals there's one other workaround: make your Emacs
window wider.  That works with any file/buffer, not just text-like
ones.

> You mention breaking "long lines", but this is not just a problem of long lines. It takes just two English words
> inside a Hebrew paragraph that happen to fall on a line break, to manifest this bug.

Yeah, and how frequently does that happen?

> However, Emacs also shines as possibly the only bidi-aware text editor that botches the line wrapping of bidi
> paragraphs. Every single editor that I've checked gets it right: from Word to Kate to GEdit to Google Docs to
> BlueFish to TextEdit.

You are free to use those other bidi-aware editors, if they suit your
needs better.  They don't have half the bidi features you get in
Emacs, but if line-wrapping is so much more important for you than all
the rest of the UBA, you don't have to use Emacs.

> > The Emacs manual already describes this deviation.
> 
> In the online manual sections 22.19 (Bidirectional Editing) and 37.26 (Bidirectional Display) claim that Emacs
> implements the Unicode Bidirectional Algorithm.

You have the latest sources in the Git repository you cloned, look
there for the latest text.

Once again: this is an annoyance, and I'd love to see it fixed.  But
it's a minor annoyance, which happens rarely, and on most cases there
are workarounds.  Fixing it is a large job, and will take a motivated
volunteer with a lot of talent or a lot of free time (or both).  Until
we are lucky to have that, we will have to live with this annoyance.

Cane we PLEASE finally agree to disagree about this?  I see no reason
for discussing this further, as we are just repeating the same
arguments again and again.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jul 2017 07:03:02 +0000
Resent-Message-ID: <handler.27525.B27525.150053414421458 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150053414421458
          (code B ref 27525); Thu, 20 Jul 2017 07:03:02 +0000
Received: (at 27525) by debbugs.gnu.org; 20 Jul 2017 07:02:24 +0000
Received: from localhost ([127.0.0.1]:48466 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dY5Tb-0005a2-Dx
	for submit <at> debbugs.gnu.org; Thu, 20 Jul 2017 03:02:23 -0400
Received: from mail-wr0-f177.google.com ([209.85.128.177]:36681)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dY5TZ-0005Zo-Nf
 for 27525 <at> debbugs.gnu.org; Thu, 20 Jul 2017 03:02:22 -0400
Received: by mail-wr0-f177.google.com with SMTP id y43so66709982wrd.3
 for <27525 <at> debbugs.gnu.org>; Thu, 20 Jul 2017 00:02:21 -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=+uWgSyXY3slEJYFWpgJ50zqDG//EYZLwZhwqduYiuLg=;
 b=MmQ34nmfwJGL87IW1nP2ISMCXDlaL9/00NHE7RLA59w6dncYuPc73lDHsFEV8ELynX
 Swuqu9V2PRUGulPa7MwhIGBGh72h/N3Qqr8TX0DIN8BYBZplf2eivfnktZQxnFpFKdIE
 CAc/INcLPBaxRbHLt+HCS4RXbH5RcfDUgOHk1jgssmvNbI0TdbupghWCedfW2CreJtWx
 7CMPx9SRAPA3IHQbjUbEt8D8O2RffwKAOj7xj40+C3cz/wuXbC7j3b2oF1CVjwzyMXcB
 rch/GNJLIWzbtChzGhYcO4ofYzDkQp/8Wo3QjIkCpPS9e3ufQSpS/xiuU3Gk8ms5sZH9
 0UPg==
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=+uWgSyXY3slEJYFWpgJ50zqDG//EYZLwZhwqduYiuLg=;
 b=R9EXHPfjt0fYts8Yfo+sHHkhTR7E1M+4bJbbZqK6NdZi81BMwH9lU+wU4VpplpF5MF
 asGn3pSLZ5f5aheIP+ZfayYmxP44PXq8w38ugnmQOHSrjrUN65n12gQCy6YUCLCRjnba
 O+kZbBnWOs8sxv5Didue4ach5QwlrFY/TFnI8mRs49K9C6Uja5XeZU3laxgGROL6J2FL
 qjtD86xaKGhkLnF5d2YmZ4ctXT7gV5ShEGzZM12E4Ezbq/sPv7GWMwVmVBePHUKAeYrD
 8KpBhQuR+2xQHSBkBweYPr2Udnyu131eKZAb89lFZnoL40y9d7l7EenxpzRLuJkM0Gh8
 21qA==
X-Gm-Message-State: AIVw110kSWGtqnNTjFn9NUKHrxrK5Z2Nl7YLbfuJY85caRZq9iUPRmyg
 W+CJbq4Kv0zoSdH2sjpkGcg43dlMbp4C
X-Received: by 10.223.170.150 with SMTP id h22mr6205587wrc.140.1500534134332; 
 Thu, 20 Jul 2017 00:02:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.196 with HTTP; Thu, 20 Jul 2017 00:01:33 -0700 (PDT)
In-Reply-To: <83lgnjbsqw.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Thu, 20 Jul 2017 10:01:33 +0300
Message-ID: <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
Content-Type: multipart/alternative; boundary="94eb2c1b47ce0ceb710554ba547c"
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--94eb2c1b47ce0ceb710554ba547c
Content-Type: text/plain; charset="UTF-8"

I see no reason to continue this discussion any further.

One thing I'm curious about, though. What bidi features exist in Emacs,
half of which the other editors don't have? Which features were you
referring to when you wrote that, thanks to them, "10 years later, Emacs
still shines among all the bidi-aware editors out there"?

On Thu, Jul 20, 2017 at 8:08 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Itai Berli <itai.berli@HIDDEN>
> > Date: Thu, 20 Jul 2017 00:40:15 +0300
> >
> > I believe Emacs
> > can be the #1 plain-text bidi editor out there, but this hinges on
> fixing this bug.
>
> And I believe you exaggerate the importance of this issue, and how
> much it diminishes the usefulness of the Emacs bidi support.  Can we
> agree to disagree about that, now that we've reiterated that
> disagreement many times, and all of that is forever recorded in the
> bug tracker?
>
> >
> > > I maintain that Emacs deviates from the UBA in a relatively minor way,
> > in an aspect that is only tangentially related to reordering
> > bidirectional text for display, and that raises its head in situations
> > that are relatively rare in practice, and in many of those rare cases
> > can be easily worked around by breaking long lines.
> >
> > One of the valuable aspects of an ISO standard is that it is not left to
> the personal judgment of a programmer
> > to decide what is worth implementing, and how to do so. It is not for
> you to decide what is a minor detail and
> > what is a major one, what is tangential and what is core. You need to
> implement it to the letter, or else you
> > can't claim conformance, no matter how slight you imagine your deviation
> to be.
>
> Of course, it's for me to decide.  Emacs is not an implementation of
> the Unicode Standard: Emacs _follows_ the Unicode recommendations
> where we decide it to be useful/practical, and doesn't where we don't.
>
> > On what do you base your claim that this problem occurs relatively
> rarely in practice? This is the kind of
> > statement that only a specialist linguist/statistician can make. And
> have you taken into account the type of
> > demographics who use Emacs' bidi feature and the kinds of texts they're
> likely to type?
>
> It doesn't take a statistician/linguist to realize that
>
>   . long lines that wrap on Emacs display are rare to begin with
>   . lines with predominantly RTL text in LTR paragraphs are rare, and
>     likewise lines with predominantly LTR text in RTL paragraphs
>   . multiplying 2 rare cases makes the result very rare
>
> > Contrary to what you said, my personal experience show that this is a
> major inconvenience, and that it is a
> > situation that occurs very often, almost every paragraph, in fact, since
> I write primarily LaTeX documents
> > where English markup is intermixed with predominantly Hebrew text
> containing frequent quotes from English
> > textbooks and articles.
>
> LaTeX documents can easily work around the problem by breaking long
> lines into shorter ones.
>
> > Yes, breaking lines is a possible workaround for LaTex, but it makes for
> ugly and erratic looking paragraphs
> > that are difficult to read and edit.
>
> I fail to see why it would be ugly or hard to read.  Especially since
> you can now have a different paragraph direction after every newline.
> Perhaps you need to break lines more judiciously, not at random
> points.
>
> > And what about documents that are not LaTeX? What workaround do they
> > have?
>
> Plain text documents, and documents that are "nearly plain text", like
> TeX, Texinfo, and other similar systems, rarely if ever consider
> newlines as significant.  So this workaround is available there as
> well.  About the only exception I know of is poetry, where over-long
> lines are even rarer.
>
> Btw, on GUI terminals there's one other workaround: make your Emacs
> window wider.  That works with any file/buffer, not just text-like
> ones.
>
> > You mention breaking "long lines", but this is not just a problem of
> long lines. It takes just two English words
> > inside a Hebrew paragraph that happen to fall on a line break, to
> manifest this bug.
>
> Yeah, and how frequently does that happen?
>
> > However, Emacs also shines as possibly the only bidi-aware text editor
> that botches the line wrapping of bidi
> > paragraphs. Every single editor that I've checked gets it right: from
> Word to Kate to GEdit to Google Docs to
> > BlueFish to TextEdit.
>
> You are free to use those other bidi-aware editors, if they suit your
> needs better.  They don't have half the bidi features you get in
> Emacs, but if line-wrapping is so much more important for you than all
> the rest of the UBA, you don't have to use Emacs.
>
> > > The Emacs manual already describes this deviation.
> >
> > In the online manual sections 22.19 (Bidirectional Editing) and 37.26
> (Bidirectional Display) claim that Emacs
> > implements the Unicode Bidirectional Algorithm.
>
> You have the latest sources in the Git repository you cloned, look
> there for the latest text.
>
> Once again: this is an annoyance, and I'd love to see it fixed.  But
> it's a minor annoyance, which happens rarely, and on most cases there
> are workarounds.  Fixing it is a large job, and will take a motivated
> volunteer with a lot of talent or a lot of free time (or both).  Until
> we are lucky to have that, we will have to live with this annoyance.
>
> Cane we PLEASE finally agree to disagree about this?  I see no reason
> for discussing this further, as we are just repeating the same
> arguments again and again.
>

--94eb2c1b47ce0ceb710554ba547c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see no reason to continue this discussion any further.<d=
iv><br></div><div>One thing I&#39;m curious about, though. What bidi featur=
es <span style=3D"font-size:12.8px">exist in Emacs, half of which the other=
 editors don&#39;t have? Which features were you referring to when you wrot=
e that, thanks to them, &quot;</span><span style=3D"font-size:12.8px">10 ye=
ars later, Emacs still shines among all the=C2=A0</span><span style=3D"font=
-size:12.8px">bidi-aware editors out there&quot;?</span><br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 20, 2017 at 8:=
08 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" =
target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">&gt; From: Itai Berli &lt;<a href=3D"mailto:itai.berli@gmail.=
com" target=3D"_blank">itai.berli@HIDDEN</a>&gt;<br>
&gt; Date: Thu, 20 Jul 2017 00:40:15 +0300<br>
<span>&gt;<br>
&gt; I believe Emacs<br>
&gt; can be the #1 plain-text bidi editor out there, but this hinges on fix=
ing this bug.<br>
<br>
</span>And I believe you exaggerate the importance of this issue, and how<b=
r>
much it diminishes the usefulness of the Emacs bidi support.=C2=A0 Can we<b=
r>
agree to disagree about that, now that we&#39;ve reiterated that<br>
disagreement many times, and all of that is forever recorded in the<br>
bug tracker?<br>
<span><br>
&gt;<br>
&gt; &gt; I maintain that Emacs deviates from the UBA in a relatively minor=
 way,<br>
&gt; in an aspect that is only tangentially related to reordering<br>
&gt; bidirectional text for display, and that raises its head in situations=
<br>
&gt; that are relatively rare in practice, and in many of those rare cases<=
br>
&gt; can be easily worked around by breaking long lines.<br>
&gt;<br>
&gt; One of the valuable aspects of an ISO standard is that it is not left =
to the personal judgment of a programmer<br>
&gt; to decide what is worth implementing, and how to do so. It is not for =
you to decide what is a minor detail and<br>
&gt; what is a major one, what is tangential and what is core. You need to =
implement it to the letter, or else you<br>
&gt; can&#39;t claim conformance, no matter how slight you imagine your dev=
iation to be.<br>
<br>
</span>Of course, it&#39;s for me to decide.=C2=A0 Emacs is not an implemen=
tation of<br>
the Unicode Standard: Emacs _follows_ the Unicode recommendations<br>
where we decide it to be useful/practical, and doesn&#39;t where we don&#39=
;t.<br>
<span><br>
&gt; On what do you base your claim that this problem occurs relatively rar=
ely in practice? This is the kind of<br>
&gt; statement that only a specialist linguist/statistician can make. And h=
ave you taken into account the type of<br>
&gt; demographics who use Emacs&#39; bidi feature and the kinds of texts th=
ey&#39;re likely to type?<br>
<br>
</span>It doesn&#39;t take a statistician/linguist to realize that<br>
<br>
=C2=A0 . long lines that wrap on Emacs display are rare to begin with<br>
=C2=A0 . lines with predominantly RTL text in LTR paragraphs are rare, and<=
br>
=C2=A0 =C2=A0 likewise lines with predominantly LTR text in RTL paragraphs<=
br>
=C2=A0 . multiplying 2 rare cases makes the result very rare<br>
<span><br>
&gt; Contrary to what you said, my personal experience show that this is a =
major inconvenience, and that it is a<br>
&gt; situation that occurs very often, almost every paragraph, in fact, sin=
ce I write primarily LaTeX documents<br>
&gt; where English markup is intermixed with predominantly Hebrew text cont=
aining frequent quotes from English<br>
&gt; textbooks and articles.<br>
<br>
</span>LaTeX documents can easily work around the problem by breaking long<=
br>
lines into shorter ones.<br>
<span><br>
&gt; Yes, breaking lines is a possible workaround for LaTex, but it makes f=
or ugly and erratic looking paragraphs<br>
&gt; that are difficult to read and edit.<br>
<br>
</span>I fail to see why it would be ugly or hard to read.=C2=A0 Especially=
 since<br>
you can now have a different paragraph direction after every newline.<br>
Perhaps you need to break lines more judiciously, not at random<br>
points.<br>
<span><br>
&gt; And what about documents that are not LaTeX? What workaround do they<b=
r>
&gt; have?<br>
<br>
</span>Plain text documents, and documents that are &quot;nearly plain text=
&quot;, like<br>
TeX, Texinfo, and other similar systems, rarely if ever consider<br>
newlines as significant.=C2=A0 So this workaround is available there as<br>
well.=C2=A0 About the only exception I know of is poetry, where over-long<b=
r>
lines are even rarer.<br>
<br>
Btw, on GUI terminals there&#39;s one other workaround: make your Emacs<br>
window wider.=C2=A0 That works with any file/buffer, not just text-like<br>
ones.<br>
<span><br>
&gt; You mention breaking &quot;long lines&quot;, but this is not just a pr=
oblem of long lines. It takes just two English words<br>
&gt; inside a Hebrew paragraph that happen to fall on a line break, to mani=
fest this bug.<br>
<br>
</span>Yeah, and how frequently does that happen?<br>
<span><br>
&gt; However, Emacs also shines as possibly the only bidi-aware text editor=
 that botches the line wrapping of bidi<br>
&gt; paragraphs. Every single editor that I&#39;ve checked gets it right: f=
rom Word to Kate to GEdit to Google Docs to<br>
&gt; BlueFish to TextEdit.<br>
<br>
</span>You are free to use those other bidi-aware editors, if they suit you=
r<br>
needs better.=C2=A0 They don&#39;t have half the bidi features you get in<b=
r>
Emacs, but if line-wrapping is so much more important for you than all<br>
the rest of the UBA, you don&#39;t have to use Emacs.<br>
<span><br>
&gt; &gt; The Emacs manual already describes this deviation.<br>
&gt;<br>
&gt; In the online manual sections 22.19 (Bidirectional Editing) and 37.26 =
(Bidirectional Display) claim that Emacs<br>
&gt; implements the Unicode Bidirectional Algorithm.<br>
<br>
</span>You have the latest sources in the Git repository you cloned, look<b=
r>
there for the latest text.<br>
<br>
Once again: this is an annoyance, and I&#39;d love to see it fixed.=C2=A0 B=
ut<br>
it&#39;s a minor annoyance, which happens rarely, and on most cases there<b=
r>
are workarounds.=C2=A0 Fixing it is a large job, and will take a motivated<=
br>
volunteer with a lot of talent or a lot of free time (or both).=C2=A0 Until=
<br>
we are lucky to have that, we will have to live with this annoyance.<br>
<br>
Cane we PLEASE finally agree to disagree about this?=C2=A0 I see no reason<=
br>
for discussing this further, as we are just repeating the same<br>
arguments again and again.<br>
</blockquote></div><br></div></div>

--94eb2c1b47ce0ceb710554ba547c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 20 Jul 2017 11:10:02 +0000
Resent-Message-ID: <handler.27525.B27525.150054899919561 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150054899919561
          (code B ref 27525); Thu, 20 Jul 2017 11:10:02 +0000
Received: (at 27525) by debbugs.gnu.org; 20 Jul 2017 11:09:59 +0000
Received: from localhost ([127.0.0.1]:48661 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dY9LC-00055Q-Fa
	for submit <at> debbugs.gnu.org; Thu, 20 Jul 2017 07:09:58 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58477)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dY9LB-00055E-Ad
 for 27525 <at> debbugs.gnu.org; Thu, 20 Jul 2017 07:09:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dY9L0-0001dm-VU
 for 27525 <at> debbugs.gnu.org; Thu, 20 Jul 2017 07:09:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55956)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dY9L0-0001dg-Rt; Thu, 20 Jul 2017 07:09:46 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4069
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dY9L0-00010c-BF; Thu, 20 Jul 2017 07:09:46 -0400
Date: Thu, 20 Jul 2017 14:09:36 +0300
Message-Id: <83bmofbc0f.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 (message from Itai Berli on Thu, 20 Jul 2017 10:01:33 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Resent-Sender: help-debbugs@HIDDEN
> From: Itai Berli <itai.berli@HIDDEN>
> Date: Thu, 20 Jul 2017 10:01:33 +0300
> 
> I see no reason to continue this discussion any further.

Thank you.

> One thing I'm curious about, though. What bidi features exist in Emacs, half of which the other editors don't
> have? Which features were you referring to when you wrote that, thanks to them, "10 years later, Emacs still
> shines among all the bidi-aware editors out there"?

 . For starters, all the UBA features are fully supported, including
   the directional isolates and bracket-matching (a.k.a. "BPA").
 . Support for bidirectional display on both GUI and text-mode terminals.
 . Both logical-order and visual-order cursor motion.
 . Full support for Arabic shaping and other complex-script shaping
   features in bidirectional text (e.g., Hebrew "nikkud").
 . Bidi formatting controls are visible on screen, so users don't need
   to guess why display looks like it does.
 . Variables to control where paragraphs begin and end, for the
   purposes of determining base paragraph direction.
 . Variables to disable mirroring of parentheses due to bidi context,
   and even disable bidi reordering entirely, if needed.
 . Lisp functions that are necessary when writing bidi-aware
   customizations and features:
   . a function that returns base paragraph direction at point
   . a function that returns resolved bidi levels for a line
   . a function that takes a string and wraps it so that it could be
     concatenated with other strings without fear of producing jumbled
     display due to reordering (important for tabular display)
   . a function to find characters whose directionality was overridden
     by bidi controls (which could be used to maliciously dupe the
     user to think a string is not what it really is)
   . a function to return a substring of buffer text surrounded by
     bidi controls that make sure its visual appearance will not
     change when copied to a different portion of text

And that is even before we consider Emacs-only features, which those
other editors can only dream about, like mouse-highlight, display and
overlay strings, invisible text, text alignment on display, etc. --
all of which are bidi-aware in Emacs.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 06:21:01 +0000
Resent-Message-ID: <handler.27525.B27525.15006180155127 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.15006180155127
          (code B ref 27525); Fri, 21 Jul 2017 06:21:01 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 06:20:15 +0000
Received: from localhost ([127.0.0.1]:50312 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYRIM-0001Kd-GJ
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 02:20:14 -0400
Received: from mail-wr0-f182.google.com ([209.85.128.182]:38568)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dYRIK-0001KP-Jp
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 02:20:13 -0400
Received: by mail-wr0-f182.google.com with SMTP id f21so21888259wrf.5
 for <27525 <at> debbugs.gnu.org>; Thu, 20 Jul 2017 23:20:12 -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=pvd1zQsa3+RBYYB02azJJyooZhenpvNpritL7lRnIhk=;
 b=Qn8txy3eWehJPZWo2D7imErI+NDdevcCJKSyeLbteOyEWvTUKb0yIvbAd+SEEdGZgS
 +xYUjOhlkuwjF2UzzstHKbIi+CGAE/6xY2b4evgVCc5aIna+U+Y/w9mpwKoUAAwkXDzM
 O2SquycfZNxPN4mPLKLzPG7WoLUe/yJbPmMQZDIu+bPK7L6n/COArGlLWN8I+JI9T5W2
 WjGcbcTQT519zYb6KNnGgUZHgojXJWR/TukG4pHDMoS/zC0mT5VG0Ga9QK4KotAKMGC7
 0WKq2/AWZVhXwWzVlry5JgPTn6CJ1aUMiFwYUih+5mYMHj4Aziooa2nqiWEbDiEo2Fdv
 TE2Q==
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=pvd1zQsa3+RBYYB02azJJyooZhenpvNpritL7lRnIhk=;
 b=raJb48Ju5xgNcfA1fSxfBhzhAayOeGiFZonCC7JNH8heDqa1gWEfIX1u1u4rg3OBxx
 zySWvR/0iyPraK17zn7q7eUQRT4h/0rLSWfbELHzQBGm/v8xz9nNqR+teW3uFFtmet6c
 Zuar+nJZdZg7Jm+0/BfRX4CfYqT4DJ5zupZQ1NTCx6cRjdnZoUY/O9dAygmBIWtc7ZJZ
 HXldVNop9uGK9b5+i3u0yTaZ1TABAhR0dx2PZ029wg08rG91+zd+DDzIBP/5WyBZz87N
 Z6rJsDl4JGpy18JvAnAaaVSwIEJsVcHkMpcX9g+GA7+l1u80aR7tQzn72z6mUOZDQ8yd
 eeMQ==
X-Gm-Message-State: AIVw111m9Om0LmDL/qhTCblYz11VcdTSd41OcjVSW2WTczLTz9ASilRm
 SJmK+H7ix0HNn8OLAyBCtV5/ZqCJ1up2
X-Received: by 10.223.170.7 with SMTP id p7mr8251631wrd.79.1500618006598; Thu,
 20 Jul 2017 23:20:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.196 with HTTP; Thu, 20 Jul 2017 23:19:25 -0700 (PDT)
In-Reply-To: <83bmofbc0f.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Fri, 21 Jul 2017 09:19:25 +0300
Message-ID: <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
Content-Type: multipart/alternative; boundary="94eb2c1cd6d43a19eb0554cddb5a"
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--94eb2c1cd6d43a19eb0554cddb5a
Content-Type: text/plain; charset="UTF-8"

You sure put a lot of thought and effort into it. Thank you for that.

Now that I have downloaded the source code, I'd like to take a look at this
problem first hand. I'm not a programmer, not even an amateur one, but I
can sometimes make sense of the general gist of code when I read it, and
I'd like to take a look at the part of code that's responsible for the
present bug, maybe put a breakpoint here and there and give it a test run
to get a feel of how it works, and why it misses the mark when it comes to
line wrapping bidi paragraphs.

Could you please give me some pointers: what files should I look into, what
functions should I read, possibly even suggestions for where to put
breakpoints and which variables to watch. I'm not asking for a
comprehensive and detailed run down of this feature; just a starting
point(s). Every tip and suggestion will be welcome.

On Thu, Jul 20, 2017 at 2:09 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Resent-Sender: help-debbugs@HIDDEN
> > From: Itai Berli <itai.berli@HIDDEN>
> > Date: Thu, 20 Jul 2017 10:01:33 +0300
> >
> > I see no reason to continue this discussion any further.
>
> Thank you.
>
> > One thing I'm curious about, though. What bidi features exist in Emacs,
> half of which the other editors don't
> > have? Which features were you referring to when you wrote that, thanks
> to them, "10 years later, Emacs still
> > shines among all the bidi-aware editors out there"?
>
>  . For starters, all the UBA features are fully supported, including
>    the directional isolates and bracket-matching (a.k.a. "BPA").
>  . Support for bidirectional display on both GUI and text-mode terminals.
>  . Both logical-order and visual-order cursor motion.
>  . Full support for Arabic shaping and other complex-script shaping
>    features in bidirectional text (e.g., Hebrew "nikkud").
>  . Bidi formatting controls are visible on screen, so users don't need
>    to guess why display looks like it does.
>  . Variables to control where paragraphs begin and end, for the
>    purposes of determining base paragraph direction.
>  . Variables to disable mirroring of parentheses due to bidi context,
>    and even disable bidi reordering entirely, if needed.
>  . Lisp functions that are necessary when writing bidi-aware
>    customizations and features:
>    . a function that returns base paragraph direction at point
>    . a function that returns resolved bidi levels for a line
>    . a function that takes a string and wraps it so that it could be
>      concatenated with other strings without fear of producing jumbled
>      display due to reordering (important for tabular display)
>    . a function to find characters whose directionality was overridden
>      by bidi controls (which could be used to maliciously dupe the
>      user to think a string is not what it really is)
>    . a function to return a substring of buffer text surrounded by
>      bidi controls that make sure its visual appearance will not
>      change when copied to a different portion of text
>
> And that is even before we consider Emacs-only features, which those
> other editors can only dream about, like mouse-highlight, display and
> overlay strings, invisible text, text alignment on display, etc. --
> all of which are bidi-aware in Emacs.
>

--94eb2c1cd6d43a19eb0554cddb5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>You sure put a lot of thought and effort into it. Tha=
nk you for that.</div><div><br></div>Now that I have downloaded the source =
code, I&#39;d like to take a look at this problem first hand. I&#39;m not a=
 programmer, not even an amateur one, but I can sometimes make sense of the=
 general gist of code when I read it, and I&#39;d like to take a look at th=
e part of code that&#39;s responsible for the present bug, maybe put a brea=
kpoint here and there and give it a test run to get a feel of how it works,=
 and why it misses the mark when it comes to line wrapping bidi paragraphs.=
<div><br></div><div>Could you please give me some pointers: what files shou=
ld I look into, what functions should I read, possibly even suggestions for=
 where to put breakpoints and which variables to watch. I&#39;m not asking =
for a comprehensive and detailed run down of this feature; just a starting =
point(s). Every tip and suggestion will be welcome.</div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Thu, Jul 20, 2017 at 2:09 PM, El=
i Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D=
"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">&gt; Resent-Sender: <a href=3D"mailto:help-debbugs@HIDDEN" target=3D"_b=
lank">help-debbugs@HIDDEN</a><br>
&gt; From: Itai Berli &lt;<a href=3D"mailto:itai.berli@HIDDEN" target=3D=
"_blank">itai.berli@HIDDEN</a>&gt;<br>
&gt; Date: Thu, 20 Jul 2017 10:01:33 +0300<br>
<span>&gt;<br>
&gt; I see no reason to continue this discussion any further.<br>
<br>
</span>Thank you.<br>
<span><br>
&gt; One thing I&#39;m curious about, though. What bidi features exist in E=
macs, half of which the other editors don&#39;t<br>
&gt; have? Which features were you referring to when you wrote that, thanks=
 to them, &quot;10 years later, Emacs still<br>
&gt; shines among all the bidi-aware editors out there&quot;?<br>
<br>
</span>=C2=A0. For starters, all the UBA features are fully supported, incl=
uding<br>
=C2=A0 =C2=A0the directional isolates and bracket-matching (a.k.a. &quot;BP=
A&quot;).<br>
=C2=A0. Support for bidirectional display on both GUI and text-mode termina=
ls.<br>
=C2=A0. Both logical-order and visual-order cursor motion.<br>
=C2=A0. Full support for Arabic shaping and other complex-script shaping<br=
>
=C2=A0 =C2=A0features in bidirectional text (e.g., Hebrew &quot;nikkud&quot=
;).<br>
=C2=A0. Bidi formatting controls are visible on screen, so users don&#39;t =
need<br>
=C2=A0 =C2=A0to guess why display looks like it does.<br>
=C2=A0. Variables to control where paragraphs begin and end, for the<br>
=C2=A0 =C2=A0purposes of determining base paragraph direction.<br>
=C2=A0. Variables to disable mirroring of parentheses due to bidi context,<=
br>
=C2=A0 =C2=A0and even disable bidi reordering entirely, if needed.<br>
=C2=A0. Lisp functions that are necessary when writing bidi-aware<br>
=C2=A0 =C2=A0customizations and features:<br>
=C2=A0 =C2=A0. a function that returns base paragraph direction at point<br=
>
=C2=A0 =C2=A0. a function that returns resolved bidi levels for a line<br>
=C2=A0 =C2=A0. a function that takes a string and wraps it so that it could=
 be<br>
=C2=A0 =C2=A0 =C2=A0concatenated with other strings without fear of produci=
ng jumbled<br>
=C2=A0 =C2=A0 =C2=A0display due to reordering (important for tabular displa=
y)<br>
=C2=A0 =C2=A0. a function to find characters whose directionality was overr=
idden<br>
=C2=A0 =C2=A0 =C2=A0by bidi controls (which could be used to maliciously du=
pe the<br>
=C2=A0 =C2=A0 =C2=A0user to think a string is not what it really is)<br>
=C2=A0 =C2=A0. a function to return a substring of buffer text surrounded b=
y<br>
=C2=A0 =C2=A0 =C2=A0bidi controls that make sure its visual appearance will=
 not<br>
=C2=A0 =C2=A0 =C2=A0change when copied to a different portion of text<br>
<br>
And that is even before we consider Emacs-only features, which those<br>
other editors can only dream about, like mouse-highlight, display and<br>
overlay strings, invisible text, text alignment on display, etc. --<br>
all of which are bidi-aware in Emacs.<br>
</blockquote></div><br></div></div>

--94eb2c1cd6d43a19eb0554cddb5a--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 08:39:01 +0000
Resent-Message-ID: <handler.27525.B27525.150062628817581 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150062628817581
          (code B ref 27525); Fri, 21 Jul 2017 08:39:01 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 08:38:08 +0000
Received: from localhost ([127.0.0.1]:50344 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYTRn-0004ZV-KD
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 04:38:07 -0400
Received: from eggs.gnu.org ([208.118.235.92]:43617)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dYTRl-0004Z2-Oq
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 04:38:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dYTRb-0006JC-HW
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 04:38:00 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42612)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dYTRK-00067W-RK; Fri, 21 Jul 2017 04:37:55 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1848
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dYTRK-0002gU-7t; Fri, 21 Jul 2017 04:37:38 -0400
Date: Fri, 21 Jul 2017 11:37:30 +0300
Message-Id: <83tw269odx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
 (message from Itai Berli on Fri, 21 Jul 2017 09:19:25 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
 <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Fri, 21 Jul 2017 09:19:25 +0300
> 
> Now that I have downloaded the source code, I'd like to take a look at this problem first hand. I'm not a
> programmer, not even an amateur one, but I can sometimes make sense of the general gist of code when I
> read it, and I'd like to take a look at the part of code that's responsible for the present bug, maybe put a
> breakpoint here and there and give it a test run to get a feel of how it works, and why it misses the mark when
> it comes to line wrapping bidi paragraphs.
> 
> Could you please give me some pointers: what files should I look into, what functions should I read, possibly
> even suggestions for where to put breakpoints and which variables to watch. I'm not asking for a
> comprehensive and detailed run down of this feature; just a starting point(s). Every tip and suggestion will be
> welcome.

The relevant files are bidi.c and xdisp.c.  There's a long comment at
the beginning of xdisp.c, whose last parts deal with how the bidi
reordering is incorporated into the display engine, and a long comment
at the beginning of bidi.c that has more details about the reordering
itself.

Note that this is not an implementation bug, it's a consequence of how
the bidi reordering engine's integration with the rest of the display
code was designed: we reorder text for display _before_ making the
layout decisions.  IOW, the layout layer of the display engine is fed
characters in _visual_ order, already reordered by bidi.c functions
which the layout layer calls when it needs another character.  The
advantage of this design is that the display engine knows almost
nothing about the reordering stuff, it doesn't care about resolved
levels etc., because all that was already taken care of.

To make line-wrapping do what the UBA describes, we would need to feed
the display engine with characters in logical order, but record with
each character its resolved bidi level, resulting from partial
processing by bidi.c.  Then, when a line is completely laid out, we'd
need to reorder the glyphs prepared for that line according to UBA
rules L1, L2, and L4, using the resolved levels recorded by bidi.c
code.  (L3 is tricky, because combining marks are applied when
producing glyphs, so it has to be solved by "some other method".)

The above means we need to redesign the interface between xdisp.c and
bidi.c, and then rewrite the current reordering function into
something that will work on the glyphs of a laid-out line.

That in itself is more or less straightforward refactoring of the
existing code, but unfortunately it isn't the scary part of the job.
The scary part is all the subtleties of the Emacs display engine and
the features it provides, when bidirectional text is involved.  For
example, many places need to calculate layout metrics without
displaying anything.  A typical example is vertical-motion when
line-move-visual is in effect -- it needs to determine what buffer
position is displayed one screen line up or down from a given
character.  Another example is how we process a mouse click, which
starts by determining which buffer position (more accurately, which
offset of what object) is displayed at given pixel coordinates.

These places use functions that "simulate" display -- they perform all
the layout calculations, but don't create glyphs (because nothing
needs to be displayed).  Since glyphs are not created, the "line" to
be displayed doesn't exist, and thus the reordering step will have
nothing to work on.  Whoever will work on fixing line-wrapping will
have to figure out how to solve this problem in a way that is
compatible with the 2nd sentence of the UBA's section 3.4.  There are
many complications in this part of the display code, because
oftentimes Emacs ends the display "simulation" before reaching the end
of the line, and sometimes even starts it in the middle of a line.
All this needs to be figured out and implemented when reordering needs
to see a full screen line, and implemented in a way that doesn't hurt
performance in any significant way.

Then there are complications with invisible text: the 'invisible' text
property can start and/or end in the middle if non-base embedding
level, and the question is how to produce the result that the user
expects, when some of the characters that affect reordering are
effectively hidden from the reordering code, because the invisible
text is simply skipped and never fed to the layout layer.  (With the
current design, reordering is done before the text invisibility is
considered, so the result is quite naturally the expected one.)
Similar problems arise with display properties and overlays which hide
portions of buffer text, optionally replacing them with some other
text or image -- the reordering step will somehow need to avoid
reordering the text of a display string as if it were part of the
surrounding buffer text, because that's not what the user expects.

Another complication is where glyph production and layout decisions
are mixed with bidi level resolution.  One such situation is how we
implement the display property of the form '(space :align-to HPOS)'
which is treated as a paragraph separator for the purposes of bidi
reordering (thus supporting display of tables with bidirectional
text).  If we separate reordering from level resolution, this will
have to be rethought if not reimplemented.

And I'm quite sure there are other complications that I forget.  This
is what took the lion's share of the work on making the display engine
bidi-aware (because the basic reordering engine which is now bidi.c
was written and debugged, as a stand-alone program, 15 years ago).
Whoever will work on fixing the line-wrapping issue will have to do at
least part of that anew.  I surely hope a motivated individual will
step forward for the job at some point, but they need to know what
they will face.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 09:46:02 +0000
Resent-Message-ID: <handler.27525.B27525.150063033023543 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150063033023543
          (code B ref 27525); Fri, 21 Jul 2017 09:46:02 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 09:45:30 +0000
Received: from localhost ([127.0.0.1]:50376 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYUUz-00067e-Pr
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 05:45:30 -0400
Received: from mail-wm0-f46.google.com ([74.125.82.46]:33450)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dYUUx-00067O-Ff
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 05:45:28 -0400
Received: by mail-wm0-f46.google.com with SMTP id v139so2428154wmv.0
 for <27525 <at> debbugs.gnu.org>; Fri, 21 Jul 2017 02:45:27 -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=dRg13gGVJJVf4sUPwu5hp23tjRxxw2yUWbO35bBp5+w=;
 b=q2yB+HI3S0ohz85tvYAAoTbtx/Rg9pWWXRyDF31rw44bFRSeepXk898SVVJD3KZFTy
 +CQOVIZg744+/hzZvv9gdz72Zdg9u5GvUl9KPcO9NmmtmNaIscsKSZmLHrlqiPOvxlA7
 vRDt6s1DFTKKLRjd8hPh3INsq4ePN4ubPQS3MP2MvBNYyyHtUZK1+FpvXpH36DH1mp3H
 PqpKI6PaYcOD89AexDxtfjHFtaEHOvq1mwsvvnajwRIk4D1iEyUQ2MgGSvQLfTitS0Q7
 mNBcl4Sxwlz37UF+tqYCfa/yMNcNt9PKFzw8O9RgHaGbNCq5Kl2tfLw5VuywYces1nbM
 6Yxw==
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=dRg13gGVJJVf4sUPwu5hp23tjRxxw2yUWbO35bBp5+w=;
 b=o/7TNg3xn5TmC1dPe6UZ6/tS3OdmvviY97QvZ+1XazjDqIGVMy3MBMHUiHyqlZSeE/
 4LussDJZ8lDJquLqMzDnQh58kZsQNoS5r3cEe2Hrz4dtc5kB5V/Bpch1Yq7jECCVBJvb
 C8RFKW69BIbR9xvkpgAf/ZPmYTj3cKYv0BN3BrIe+OjK3XHGAeXgTTcuopoPK5Lv1QtN
 4IoEfqv0P0k7RcCz58522Q9cbaKmJMZKmn5BgiWr8jWJWEX/t6v2W2W8iyFNMgbVv10z
 +C9lIpR24siQm8PKn4qRVvMqpdNaQ/3QWJpyMxVwuHM5fDt3l4MkVhEaZroeB95X6cDg
 z/vQ==
X-Gm-Message-State: AIVw112ltzFOqrzAbBcVKSefGerF/85ExPge7LAkOlKVziZpuhWeCT+L
 V1UAeKgi7fT58PdL3ZNxnpcqPyej3MZ5
X-Received: by 10.28.7.211 with SMTP id 202mr4542029wmh.113.1500630321360;
 Fri, 21 Jul 2017 02:45:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.196 with HTTP; Fri, 21 Jul 2017 02:44:40 -0700 (PDT)
In-Reply-To: <83tw269odx.fsf@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
 <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
 <83tw269odx.fsf@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Fri, 21 Jul 2017 12:44:40 +0300
Message-ID: <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
Content-Type: multipart/alternative; boundary="001a114435123e7c080554d0b976"
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

--001a114435123e7c080554d0b976
Content-Type: text/plain; charset="UTF-8"

Thank you.

I just want to make sure I understand. Please correct me if I'm wrong.

1. The bidi logic is entirely contained in the file bidi.c.

2. The display logic is entirely contained in the file xdisp.c.

3. The interface between the two modules is minimal. If I wish to cancel
Emacs' bidi features, all I need to do is comment out a couple lines in
xdisp.c and a user who doesn't use bidi documents will never know the
difference.

4. All the complications you mentioned are limited to code in xdisp.c


On Fri, Jul 21, 2017 at 11:37 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Itai Berli <itai.berli@HIDDEN>
> > Date: Fri, 21 Jul 2017 09:19:25 +0300
> >
> > Now that I have downloaded the source code, I'd like to take a look at
> this problem first hand. I'm not a
> > programmer, not even an amateur one, but I can sometimes make sense of
> the general gist of code when I
> > read it, and I'd like to take a look at the part of code that's
> responsible for the present bug, maybe put a
> > breakpoint here and there and give it a test run to get a feel of how it
> works, and why it misses the mark when
> > it comes to line wrapping bidi paragraphs.
> >
> > Could you please give me some pointers: what files should I look into,
> what functions should I read, possibly
> > even suggestions for where to put breakpoints and which variables to
> watch. I'm not asking for a
> > comprehensive and detailed run down of this feature; just a starting
> point(s). Every tip and suggestion will be
> > welcome.
>
> The relevant files are bidi.c and xdisp.c.  There's a long comment at
> the beginning of xdisp.c, whose last parts deal with how the bidi
> reordering is incorporated into the display engine, and a long comment
> at the beginning of bidi.c that has more details about the reordering
> itself.
>
> Note that this is not an implementation bug, it's a consequence of how
> the bidi reordering engine's integration with the rest of the display
> code was designed: we reorder text for display _before_ making the
> layout decisions.  IOW, the layout layer of the display engine is fed
> characters in _visual_ order, already reordered by bidi.c functions
> which the layout layer calls when it needs another character.  The
> advantage of this design is that the display engine knows almost
> nothing about the reordering stuff, it doesn't care about resolved
> levels etc., because all that was already taken care of.
>
> To make line-wrapping do what the UBA describes, we would need to feed
> the display engine with characters in logical order, but record with
> each character its resolved bidi level, resulting from partial
> processing by bidi.c.  Then, when a line is completely laid out, we'd
> need to reorder the glyphs prepared for that line according to UBA
> rules L1, L2, and L4, using the resolved levels recorded by bidi.c
> code.  (L3 is tricky, because combining marks are applied when
> producing glyphs, so it has to be solved by "some other method".)
>
> The above means we need to redesign the interface between xdisp.c and
> bidi.c, and then rewrite the current reordering function into
> something that will work on the glyphs of a laid-out line.
>
> That in itself is more or less straightforward refactoring of the
> existing code, but unfortunately it isn't the scary part of the job.
> The scary part is all the subtleties of the Emacs display engine and
> the features it provides, when bidirectional text is involved.  For
> example, many places need to calculate layout metrics without
> displaying anything.  A typical example is vertical-motion when
> line-move-visual is in effect -- it needs to determine what buffer
> position is displayed one screen line up or down from a given
> character.  Another example is how we process a mouse click, which
> starts by determining which buffer position (more accurately, which
> offset of what object) is displayed at given pixel coordinates.
>
> These places use functions that "simulate" display -- they perform all
> the layout calculations, but don't create glyphs (because nothing
> needs to be displayed).  Since glyphs are not created, the "line" to
> be displayed doesn't exist, and thus the reordering step will have
> nothing to work on.  Whoever will work on fixing line-wrapping will
> have to figure out how to solve this problem in a way that is
> compatible with the 2nd sentence of the UBA's section 3.4.  There are
> many complications in this part of the display code, because
> oftentimes Emacs ends the display "simulation" before reaching the end
> of the line, and sometimes even starts it in the middle of a line.
> All this needs to be figured out and implemented when reordering needs
> to see a full screen line, and implemented in a way that doesn't hurt
> performance in any significant way.
>
> Then there are complications with invisible text: the 'invisible' text
> property can start and/or end in the middle if non-base embedding
> level, and the question is how to produce the result that the user
> expects, when some of the characters that affect reordering are
> effectively hidden from the reordering code, because the invisible
> text is simply skipped and never fed to the layout layer.  (With the
> current design, reordering is done before the text invisibility is
> considered, so the result is quite naturally the expected one.)
> Similar problems arise with display properties and overlays which hide
> portions of buffer text, optionally replacing them with some other
> text or image -- the reordering step will somehow need to avoid
> reordering the text of a display string as if it were part of the
> surrounding buffer text, because that's not what the user expects.
>
> Another complication is where glyph production and layout decisions
> are mixed with bidi level resolution.  One such situation is how we
> implement the display property of the form '(space :align-to HPOS)'
> which is treated as a paragraph separator for the purposes of bidi
> reordering (thus supporting display of tables with bidirectional
> text).  If we separate reordering from level resolution, this will
> have to be rethought if not reimplemented.
>
> And I'm quite sure there are other complications that I forget.  This
> is what took the lion's share of the work on making the display engine
> bidi-aware (because the basic reordering engine which is now bidi.c
> was written and debugged, as a stand-alone program, 15 years ago).
> Whoever will work on fixing the line-wrapping issue will have to do at
> least part of that anew.  I surely hope a motivated individual will
> step forward for the job at some point, but they need to know what
> they will face.
>

--001a114435123e7c080554d0b976
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you.<div><br></div><div>I just want to make sure I u=
nderstand. Please correct me if I&#39;m wrong.</div><div><br></div><div>1. =
The bidi logic is entirely contained in the file bidi.c.</div><div><br></di=
v><div>2. The display logic is entirely contained in the file xdisp.c.</div=
><div><br></div><div>3. The interface between the two modules is minimal. I=
f I wish to cancel Emacs&#39; bidi features, all I need to do is comment ou=
t a couple lines in xdisp.c and a user who doesn&#39;t use bidi documents w=
ill never know the difference.<br><div><br></div><div>4. All the complicati=
ons you mentioned are limited to code in xdisp.c</div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 21, 2=
017 at 11:37 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz=
@gnu.org" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">&gt; From: Itai Berli &lt;<a href=3D"mailto:itai.berl=
i@HIDDEN" target=3D"_blank">itai.berli@HIDDEN</a>&gt;<br>
&gt; Date: Fri, 21 Jul 2017 09:19:25 +0300<br>
<span>&gt;<br>
&gt; Now that I have downloaded the source code, I&#39;d like to take a loo=
k at this problem first hand. I&#39;m not a<br>
&gt; programmer, not even an amateur one, but I can sometimes make sense of=
 the general gist of code when I<br>
&gt; read it, and I&#39;d like to take a look at the part of code that&#39;=
s responsible for the present bug, maybe put a<br>
&gt; breakpoint here and there and give it a test run to get a feel of how =
it works, and why it misses the mark when<br>
&gt; it comes to line wrapping bidi paragraphs.<br>
&gt;<br>
&gt; Could you please give me some pointers: what files should I look into,=
 what functions should I read, possibly<br>
&gt; even suggestions for where to put breakpoints and which variables to w=
atch. I&#39;m not asking for a<br>
&gt; comprehensive and detailed run down of this feature; just a starting p=
oint(s). Every tip and suggestion will be<br>
&gt; welcome.<br>
<br>
</span>The relevant files are bidi.c and xdisp.c.=C2=A0 There&#39;s a long =
comment at<br>
the beginning of xdisp.c, whose last parts deal with how the bidi<br>
reordering is incorporated into the display engine, and a long comment<br>
at the beginning of bidi.c that has more details about the reordering<br>
itself.<br>
<br>
Note that this is not an implementation bug, it&#39;s a consequence of how<=
br>
the bidi reordering engine&#39;s integration with the rest of the display<b=
r>
code was designed: we reorder text for display _before_ making the<br>
layout decisions.=C2=A0 IOW, the layout layer of the display engine is fed<=
br>
characters in _visual_ order, already reordered by bidi.c functions<br>
which the layout layer calls when it needs another character.=C2=A0 The<br>
advantage of this design is that the display engine knows almost<br>
nothing about the reordering stuff, it doesn&#39;t care about resolved<br>
levels etc., because all that was already taken care of.<br>
<br>
To make line-wrapping do what the UBA describes, we would need to feed<br>
the display engine with characters in logical order, but record with<br>
each character its resolved bidi level, resulting from partial<br>
processing by bidi.c.=C2=A0 Then, when a line is completely laid out, we&#3=
9;d<br>
need to reorder the glyphs prepared for that line according to UBA<br>
rules L1, L2, and L4, using the resolved levels recorded by bidi.c<br>
code.=C2=A0 (L3 is tricky, because combining marks are applied when<br>
producing glyphs, so it has to be solved by &quot;some other method&quot;.)=
<br>
<br>
The above means we need to redesign the interface between xdisp.c and<br>
bidi.c, and then rewrite the current reordering function into<br>
something that will work on the glyphs of a laid-out line.<br>
<br>
That in itself is more or less straightforward refactoring of the<br>
existing code, but unfortunately it isn&#39;t the scary part of the job.<br=
>
The scary part is all the subtleties of the Emacs display engine and<br>
the features it provides, when bidirectional text is involved.=C2=A0 For<br=
>
example, many places need to calculate layout metrics without<br>
displaying anything.=C2=A0 A typical example is vertical-motion when<br>
line-move-visual is in effect -- it needs to determine what buffer<br>
position is displayed one screen line up or down from a given<br>
character.=C2=A0 Another example is how we process a mouse click, which<br>
starts by determining which buffer position (more accurately, which<br>
offset of what object) is displayed at given pixel coordinates.<br>
<br>
These places use functions that &quot;simulate&quot; display -- they perfor=
m all<br>
the layout calculations, but don&#39;t create glyphs (because nothing<br>
needs to be displayed).=C2=A0 Since glyphs are not created, the &quot;line&=
quot; to<br>
be displayed doesn&#39;t exist, and thus the reordering step will have<br>
nothing to work on.=C2=A0 Whoever will work on fixing line-wrapping will<br=
>
have to figure out how to solve this problem in a way that is<br>
compatible with the 2nd sentence of the UBA&#39;s section 3.4.=C2=A0 There =
are<br>
many complications in this part of the display code, because<br>
oftentimes Emacs ends the display &quot;simulation&quot; before reaching th=
e end<br>
of the line, and sometimes even starts it in the middle of a line.<br>
All this needs to be figured out and implemented when reordering needs<br>
to see a full screen line, and implemented in a way that doesn&#39;t hurt<b=
r>
performance in any significant way.<br>
<br>
Then there are complications with invisible text: the &#39;invisible&#39; t=
ext<br>
property can start and/or end in the middle if non-base embedding<br>
level, and the question is how to produce the result that the user<br>
expects, when some of the characters that affect reordering are<br>
effectively hidden from the reordering code, because the invisible<br>
text is simply skipped and never fed to the layout layer.=C2=A0 (With the<b=
r>
current design, reordering is done before the text invisibility is<br>
considered, so the result is quite naturally the expected one.)<br>
Similar problems arise with display properties and overlays which hide<br>
portions of buffer text, optionally replacing them with some other<br>
text or image -- the reordering step will somehow need to avoid<br>
reordering the text of a display string as if it were part of the<br>
surrounding buffer text, because that&#39;s not what the user expects.<br>
<br>
Another complication is where glyph production and layout decisions<br>
are mixed with bidi level resolution.=C2=A0 One such situation is how we<br=
>
implement the display property of the form &#39;(space :align-to HPOS)&#39;=
<br>
which is treated as a paragraph separator for the purposes of bidi<br>
reordering (thus supporting display of tables with bidirectional<br>
text).=C2=A0 If we separate reordering from level resolution, this will<br>
have to be rethought if not reimplemented.<br>
<br>
And I&#39;m quite sure there are other complications that I forget.=C2=A0 T=
his<br>
is what took the lion&#39;s share of the work on making the display engine<=
br>
bidi-aware (because the basic reordering engine which is now bidi.c<br>
was written and debugged, as a stand-alone program, 15 years ago).<br>
Whoever will work on fixing the line-wrapping issue will have to do at<br>
least part of that anew.=C2=A0 I surely hope a motivated individual will<br=
>
step forward for the job at some point, but they need to know what<br>
they will face.<br>
</blockquote></div><br></div></div>

--001a114435123e7c080554d0b976--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Itai Berli <itai.berli@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 11:00:03 +0000
Resent-Message-ID: <handler.27525.B27525.150063478630272 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 27525 <at> debbugs.gnu.org
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150063478630272
          (code B ref 27525); Fri, 21 Jul 2017 11:00:03 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 10:59:46 +0000
Received: from localhost ([127.0.0.1]:50395 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYVes-0007sC-6m
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 06:59:46 -0400
Received: from mail-wr0-f177.google.com ([209.85.128.177]:33589)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <itai.berli@HIDDEN>) id 1dYVeq-0007rz-H1
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 06:59:45 -0400
Received: by mail-wr0-f177.google.com with SMTP id v105so50821052wrb.0
 for <27525 <at> debbugs.gnu.org>; Fri, 21 Jul 2017 03:59:44 -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=QHMCFnBwFIR49hDMsM4x0/jPBIEhIcecMDrBExF8X44=;
 b=eQ91MTitlI3c7Rja/euy9pFi62iKQxE9tmZa/AvHqCK9GQ22y5yppZKAn+Rs6IJx1o
 ip1OVhUx2Nr9fBj6rmU0oHLvxjzJ+3nDiQrO9mBAMYVvcIT8JDM1ghMh3FqI4oDf5PLn
 brss0MM6/RS/QzWbJrX22rYhA1G+BOwX3Tn6P46mJVpK/leGKLB92SSw0yvXZJBIHoBh
 1gTDNivpp7XWusjtrFx4gCJXrYQtuatcP1MdHiRxv2uN/ZDAyLlUSJM/SLHxwFIAKrqH
 s3QcLY/16agqbuJ+8Ko9ixl/rZLFjOVh8qv06w3JYHvhcW0QAI9a3TIpBsHG0to/A3sf
 lLnA==
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=QHMCFnBwFIR49hDMsM4x0/jPBIEhIcecMDrBExF8X44=;
 b=mVl1CbxAHQoacEICZaqRe4psWkqRRkoEQezoTsfsA9EoPmGaEzYdm9sxEum5ZRtH6d
 hhPFUd38OCH5oMLSbKrnHl3mqPlaXbQRCuMWfMcqaihW3TCjep6ypmacRtQJW76oT7UW
 SoAyEYn+Ao7VZq8QN9FunaCUQilOng0yufiGMvc74C7lTpZF/BPH+PHBk+eY0vPG2WUA
 cRoVq4PYK50uYunCUAhaM8hjFBwEO7mL/C9KE0z3jyE/9nTz0lCfyWHSeD+4JJVFrHYc
 RCapozU1R9nquU7VHYpFGnK0UW5H3s6MQnwHs0b13i9EXLyJDjrzamqPSFACwKTrJ9NB
 bIcw==
X-Gm-Message-State: AIVw110dzYJ4QzJqBrwxwrqxIOVzXTwIiBoe3aST7cvLxowOsRz2y9lp
 DlEWb1aEuRNZ8zx8NlvkMQ2CMFtm+vc3
X-Received: by 10.223.167.69 with SMTP id e5mr619339wrd.79.1500634778148; Fri,
 21 Jul 2017 03:59:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.196 with HTTP; Fri, 21 Jul 2017 03:58:57 -0700 (PDT)
In-Reply-To: <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
 <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
 <83tw269odx.fsf@HIDDEN>
 <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
From: Itai Berli <itai.berli@HIDDEN>
Date: Fri, 21 Jul 2017 13:58:57 +0300
Message-ID: <CABsNJ=MH3kkcL5_GFA2vpo-sjLodhON6VLSeARbTOSphRMX3Fw@HIDDEN>
Content-Type: multipart/alternative; boundary="94eb2c1cc68ae3a6590554d1c2e3"
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--94eb2c1cc68ae3a6590554d1c2e3
Content-Type: text/plain; charset="UTF-8"

I have a suggestion for another approach to tackling this bug. It doesn't
fix the problem, but it offers a better workaround, in my opinion, than the
present one of requiring the user to break lines manually. Is this approach
easier to implement?

Instead of requiring Emacs to wrap lines correctly as they are being typed,
only require it to display correctly wrapped lines once a file is opened,
as well as once the user explicitly invokes a certain function while
editing the file.

On Fri, Jul 21, 2017 at 12:44 PM, Itai Berli <itai.berli@HIDDEN> wrote:

> Thank you.
>
> I just want to make sure I understand. Please correct me if I'm wrong.
>
> 1. The bidi logic is entirely contained in the file bidi.c.
>
> 2. The display logic is entirely contained in the file xdisp.c.
>
> 3. The interface between the two modules is minimal. If I wish to cancel
> Emacs' bidi features, all I need to do is comment out a couple lines in
> xdisp.c and a user who doesn't use bidi documents will never know the
> difference.
>
> 4. All the complications you mentioned are limited to code in xdisp.c
>
>
> On Fri, Jul 21, 2017 at 11:37 AM, Eli Zaretskii <eliz@HIDDEN> wrote:
>
>> > From: Itai Berli <itai.berli@HIDDEN>
>> > Date: Fri, 21 Jul 2017 09:19:25 +0300
>> >
>> > Now that I have downloaded the source code, I'd like to take a look at
>> this problem first hand. I'm not a
>> > programmer, not even an amateur one, but I can sometimes make sense of
>> the general gist of code when I
>> > read it, and I'd like to take a look at the part of code that's
>> responsible for the present bug, maybe put a
>> > breakpoint here and there and give it a test run to get a feel of how
>> it works, and why it misses the mark when
>> > it comes to line wrapping bidi paragraphs.
>> >
>> > Could you please give me some pointers: what files should I look into,
>> what functions should I read, possibly
>> > even suggestions for where to put breakpoints and which variables to
>> watch. I'm not asking for a
>> > comprehensive and detailed run down of this feature; just a starting
>> point(s). Every tip and suggestion will be
>> > welcome.
>>
>> The relevant files are bidi.c and xdisp.c.  There's a long comment at
>> the beginning of xdisp.c, whose last parts deal with how the bidi
>> reordering is incorporated into the display engine, and a long comment
>> at the beginning of bidi.c that has more details about the reordering
>> itself.
>>
>> Note that this is not an implementation bug, it's a consequence of how
>> the bidi reordering engine's integration with the rest of the display
>> code was designed: we reorder text for display _before_ making the
>> layout decisions.  IOW, the layout layer of the display engine is fed
>> characters in _visual_ order, already reordered by bidi.c functions
>> which the layout layer calls when it needs another character.  The
>> advantage of this design is that the display engine knows almost
>> nothing about the reordering stuff, it doesn't care about resolved
>> levels etc., because all that was already taken care of.
>>
>> To make line-wrapping do what the UBA describes, we would need to feed
>> the display engine with characters in logical order, but record with
>> each character its resolved bidi level, resulting from partial
>> processing by bidi.c.  Then, when a line is completely laid out, we'd
>> need to reorder the glyphs prepared for that line according to UBA
>> rules L1, L2, and L4, using the resolved levels recorded by bidi.c
>> code.  (L3 is tricky, because combining marks are applied when
>> producing glyphs, so it has to be solved by "some other method".)
>>
>> The above means we need to redesign the interface between xdisp.c and
>> bidi.c, and then rewrite the current reordering function into
>> something that will work on the glyphs of a laid-out line.
>>
>> That in itself is more or less straightforward refactoring of the
>> existing code, but unfortunately it isn't the scary part of the job.
>> The scary part is all the subtleties of the Emacs display engine and
>> the features it provides, when bidirectional text is involved.  For
>> example, many places need to calculate layout metrics without
>> displaying anything.  A typical example is vertical-motion when
>> line-move-visual is in effect -- it needs to determine what buffer
>> position is displayed one screen line up or down from a given
>> character.  Another example is how we process a mouse click, which
>> starts by determining which buffer position (more accurately, which
>> offset of what object) is displayed at given pixel coordinates.
>>
>> These places use functions that "simulate" display -- they perform all
>> the layout calculations, but don't create glyphs (because nothing
>> needs to be displayed).  Since glyphs are not created, the "line" to
>> be displayed doesn't exist, and thus the reordering step will have
>> nothing to work on.  Whoever will work on fixing line-wrapping will
>> have to figure out how to solve this problem in a way that is
>> compatible with the 2nd sentence of the UBA's section 3.4.  There are
>> many complications in this part of the display code, because
>> oftentimes Emacs ends the display "simulation" before reaching the end
>> of the line, and sometimes even starts it in the middle of a line.
>> All this needs to be figured out and implemented when reordering needs
>> to see a full screen line, and implemented in a way that doesn't hurt
>> performance in any significant way.
>>
>> Then there are complications with invisible text: the 'invisible' text
>> property can start and/or end in the middle if non-base embedding
>> level, and the question is how to produce the result that the user
>> expects, when some of the characters that affect reordering are
>> effectively hidden from the reordering code, because the invisible
>> text is simply skipped and never fed to the layout layer.  (With the
>> current design, reordering is done before the text invisibility is
>> considered, so the result is quite naturally the expected one.)
>> Similar problems arise with display properties and overlays which hide
>> portions of buffer text, optionally replacing them with some other
>> text or image -- the reordering step will somehow need to avoid
>> reordering the text of a display string as if it were part of the
>> surrounding buffer text, because that's not what the user expects.
>>
>> Another complication is where glyph production and layout decisions
>> are mixed with bidi level resolution.  One such situation is how we
>> implement the display property of the form '(space :align-to HPOS)'
>> which is treated as a paragraph separator for the purposes of bidi
>> reordering (thus supporting display of tables with bidirectional
>> text).  If we separate reordering from level resolution, this will
>> have to be rethought if not reimplemented.
>>
>> And I'm quite sure there are other complications that I forget.  This
>> is what took the lion's share of the work on making the display engine
>> bidi-aware (because the basic reordering engine which is now bidi.c
>> was written and debugged, as a stand-alone program, 15 years ago).
>> Whoever will work on fixing the line-wrapping issue will have to do at
>> least part of that anew.  I surely hope a motivated individual will
>> step forward for the job at some point, but they need to know what
>> they will face.
>>
>
>

--94eb2c1cc68ae3a6590554d1c2e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have a suggestion for another approach to tackling this =
bug. It doesn&#39;t fix the problem, but it offers a better workaround, in =
my opinion, than the present one of requiring the user to break lines manua=
lly. Is this approach easier to implement?<div><br></div><div>Instead of re=
quiring Emacs to wrap lines correctly as they are being typed, only require=
 it to display correctly wrapped lines once a file is opened, as well as on=
ce the user explicitly invokes a certain function while editing the file.</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri,=
 Jul 21, 2017 at 12:44 PM, Itai Berli <span dir=3D"ltr">&lt;<a href=3D"mail=
to:itai.berli@HIDDEN" target=3D"_blank">itai.berli@HIDDEN</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thank you.<di=
v><br></div><div>I just want to make sure I understand. Please correct me i=
f I&#39;m wrong.</div><div><br></div><div>1. The bidi logic is entirely con=
tained in the file bidi.c.</div><div><br></div><div>2. The display logic is=
 entirely contained in the file xdisp.c.</div><div><br></div><div>3. The in=
terface between the two modules is minimal. If I wish to cancel Emacs&#39; =
bidi features, all I need to do is comment out a couple lines in xdisp.c an=
d a user who doesn&#39;t use bidi documents will never know the difference.=
<br><div><br></div><div>4. All the complications you mentioned are limited =
to code in xdisp.c</div><div><br></div></div><div><div class=3D"h5"><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 21, 2017 at =
11:37 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN=
g" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">&gt; From: Itai Berli &lt;<a href=3D"mailto:itai.berli@gmail=
.com" target=3D"_blank">itai.berli@HIDDEN</a>&gt;<br>
&gt; Date: Fri, 21 Jul 2017 09:19:25 +0300<br>
<span>&gt;<br>
&gt; Now that I have downloaded the source code, I&#39;d like to take a loo=
k at this problem first hand. I&#39;m not a<br>
&gt; programmer, not even an amateur one, but I can sometimes make sense of=
 the general gist of code when I<br>
&gt; read it, and I&#39;d like to take a look at the part of code that&#39;=
s responsible for the present bug, maybe put a<br>
&gt; breakpoint here and there and give it a test run to get a feel of how =
it works, and why it misses the mark when<br>
&gt; it comes to line wrapping bidi paragraphs.<br>
&gt;<br>
&gt; Could you please give me some pointers: what files should I look into,=
 what functions should I read, possibly<br>
&gt; even suggestions for where to put breakpoints and which variables to w=
atch. I&#39;m not asking for a<br>
&gt; comprehensive and detailed run down of this feature; just a starting p=
oint(s). Every tip and suggestion will be<br>
&gt; welcome.<br>
<br>
</span>The relevant files are bidi.c and xdisp.c.=C2=A0 There&#39;s a long =
comment at<br>
the beginning of xdisp.c, whose last parts deal with how the bidi<br>
reordering is incorporated into the display engine, and a long comment<br>
at the beginning of bidi.c that has more details about the reordering<br>
itself.<br>
<br>
Note that this is not an implementation bug, it&#39;s a consequence of how<=
br>
the bidi reordering engine&#39;s integration with the rest of the display<b=
r>
code was designed: we reorder text for display _before_ making the<br>
layout decisions.=C2=A0 IOW, the layout layer of the display engine is fed<=
br>
characters in _visual_ order, already reordered by bidi.c functions<br>
which the layout layer calls when it needs another character.=C2=A0 The<br>
advantage of this design is that the display engine knows almost<br>
nothing about the reordering stuff, it doesn&#39;t care about resolved<br>
levels etc., because all that was already taken care of.<br>
<br>
To make line-wrapping do what the UBA describes, we would need to feed<br>
the display engine with characters in logical order, but record with<br>
each character its resolved bidi level, resulting from partial<br>
processing by bidi.c.=C2=A0 Then, when a line is completely laid out, we&#3=
9;d<br>
need to reorder the glyphs prepared for that line according to UBA<br>
rules L1, L2, and L4, using the resolved levels recorded by bidi.c<br>
code.=C2=A0 (L3 is tricky, because combining marks are applied when<br>
producing glyphs, so it has to be solved by &quot;some other method&quot;.)=
<br>
<br>
The above means we need to redesign the interface between xdisp.c and<br>
bidi.c, and then rewrite the current reordering function into<br>
something that will work on the glyphs of a laid-out line.<br>
<br>
That in itself is more or less straightforward refactoring of the<br>
existing code, but unfortunately it isn&#39;t the scary part of the job.<br=
>
The scary part is all the subtleties of the Emacs display engine and<br>
the features it provides, when bidirectional text is involved.=C2=A0 For<br=
>
example, many places need to calculate layout metrics without<br>
displaying anything.=C2=A0 A typical example is vertical-motion when<br>
line-move-visual is in effect -- it needs to determine what buffer<br>
position is displayed one screen line up or down from a given<br>
character.=C2=A0 Another example is how we process a mouse click, which<br>
starts by determining which buffer position (more accurately, which<br>
offset of what object) is displayed at given pixel coordinates.<br>
<br>
These places use functions that &quot;simulate&quot; display -- they perfor=
m all<br>
the layout calculations, but don&#39;t create glyphs (because nothing<br>
needs to be displayed).=C2=A0 Since glyphs are not created, the &quot;line&=
quot; to<br>
be displayed doesn&#39;t exist, and thus the reordering step will have<br>
nothing to work on.=C2=A0 Whoever will work on fixing line-wrapping will<br=
>
have to figure out how to solve this problem in a way that is<br>
compatible with the 2nd sentence of the UBA&#39;s section 3.4.=C2=A0 There =
are<br>
many complications in this part of the display code, because<br>
oftentimes Emacs ends the display &quot;simulation&quot; before reaching th=
e end<br>
of the line, and sometimes even starts it in the middle of a line.<br>
All this needs to be figured out and implemented when reordering needs<br>
to see a full screen line, and implemented in a way that doesn&#39;t hurt<b=
r>
performance in any significant way.<br>
<br>
Then there are complications with invisible text: the &#39;invisible&#39; t=
ext<br>
property can start and/or end in the middle if non-base embedding<br>
level, and the question is how to produce the result that the user<br>
expects, when some of the characters that affect reordering are<br>
effectively hidden from the reordering code, because the invisible<br>
text is simply skipped and never fed to the layout layer.=C2=A0 (With the<b=
r>
current design, reordering is done before the text invisibility is<br>
considered, so the result is quite naturally the expected one.)<br>
Similar problems arise with display properties and overlays which hide<br>
portions of buffer text, optionally replacing them with some other<br>
text or image -- the reordering step will somehow need to avoid<br>
reordering the text of a display string as if it were part of the<br>
surrounding buffer text, because that&#39;s not what the user expects.<br>
<br>
Another complication is where glyph production and layout decisions<br>
are mixed with bidi level resolution.=C2=A0 One such situation is how we<br=
>
implement the display property of the form &#39;(space :align-to HPOS)&#39;=
<br>
which is treated as a paragraph separator for the purposes of bidi<br>
reordering (thus supporting display of tables with bidirectional<br>
text).=C2=A0 If we separate reordering from level resolution, this will<br>
have to be rethought if not reimplemented.<br>
<br>
And I&#39;m quite sure there are other complications that I forget.=C2=A0 T=
his<br>
is what took the lion&#39;s share of the work on making the display engine<=
br>
bidi-aware (because the basic reordering engine which is now bidi.c<br>
was written and debugged, as a stand-alone program, 15 years ago).<br>
Whoever will work on fixing the line-wrapping issue will have to do at<br>
least part of that anew.=C2=A0 I surely hope a motivated individual will<br=
>
step forward for the job at some point, but they need to know what<br>
they will face.<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>

--94eb2c1cc68ae3a6590554d1c2e3--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 13:02:01 +0000
Resent-Message-ID: <handler.27525.B27525.150064211622466 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150064211622466
          (code B ref 27525); Fri, 21 Jul 2017 13:02:01 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 13:01:56 +0000
Received: from localhost ([127.0.0.1]:50467 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYXZ6-0005qI-3R
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:01:56 -0400
Received: from eggs.gnu.org ([208.118.235.92]:40452)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dYXZ4-0005q5-Vq
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:01:55 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dYXYu-0004Hx-VZ
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:01:49 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56745)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dYXYu-0004Ht-Rv; Fri, 21 Jul 2017 09:01:44 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2035
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dYXYu-0001MJ-82; Fri, 21 Jul 2017 09:01:44 -0400
Date: Fri, 21 Jul 2017 16:01:35 +0300
Message-Id: <83r2xa9c5s.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
 (message from Itai Berli on Fri, 21 Jul 2017 12:44:40 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
 <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
 <83tw269odx.fsf@HIDDEN>
 <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Fri, 21 Jul 2017 12:44:40 +0300
> 
> 1. The bidi logic is entirely contained in the file bidi.c.

"Bidi logic" is not well defined.  If you mean the implementation of
the UBA, then yes, it's in bidi.c, with the sole exception of
mirroring of characters due to bidi context, which is in xdisp.c.

> 2. The display logic is entirely contained in the file xdisp.c.

If by "display logic" you mean the layout parts, i.e. the code which
constructs screen lines out of characters and breaks physical lines
into logical lines, then yes.

> 3. The interface between the two modules is minimal. If I wish to cancel Emacs' bidi features, all I need to do
> is comment out a couple lines in xdisp.c and a user who doesn't use bidi documents will never know the
> difference.

Not exactly.  There are numerous code snippets that handle
bidi-related complications, like the fact that buffer position is no
longer monotonously increasing with screen coordinates, all over in
xdisp.c.  But if bidi.c functions are never called, these snippets
will most probably be no-ops.

> 4. All the complications you mentioned are limited to code in xdisp.c

No.  The current implementation includes a couple of functions in
bidi.c that perform on-the-flight reordering of characters into visual
order.  These functions will have to be bypassed, and instead there
should be a new implementation of reordering which works on a laid-out
screen line.  In addition, the data structures shared by bidi.c and
xdisp.c will have to be changed to include the resolved level of each
character and some other information (part of that is already there,
but it will have to be revisited to make sure it doesn't hide some of
the info needed for reordering, because currently the information is
stored post-reordering).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 21 Jul 2017 13:20:02 +0000
Resent-Message-ID: <handler.27525.B27525.150064319723953 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 27525
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Itai Berli <itai.berli@HIDDEN>
Cc: 27525 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 27525-submit <at> debbugs.gnu.org id=B27525.150064319723953
          (code B ref 27525); Fri, 21 Jul 2017 13:20:02 +0000
Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 13:19:57 +0000
Received: from localhost ([127.0.0.1]:50473 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dYXqW-0006EH-N4
	for submit <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:19:56 -0400
Received: from eggs.gnu.org ([208.118.235.92]:46774)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dYXqU-0006E4-PS
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:19:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dYXqM-00025o-Bw
 for 27525 <at> debbugs.gnu.org; Fri, 21 Jul 2017 09:19:49 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56964)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dYXqM-00025g-8C; Fri, 21 Jul 2017 09:19:46 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2040
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dYXqL-0002vs-Dm; Fri, 21 Jul 2017 09:19:46 -0400
Date: Fri, 21 Jul 2017 16:19:35 +0300
Message-Id: <83pocu9bbs.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CABsNJ=MH3kkcL5_GFA2vpo-sjLodhON6VLSeARbTOSphRMX3Fw@HIDDEN>
 (message from Itai Berli on Fri, 21 Jul 2017 13:58:57 +0300)
References: <CABsNJ=M_vAG49AuX8x9xZ4=QB7gZxDWjvfLQrrphJWaY+_pKaA@HIDDEN>
 <CABsNJ=PyrdUBU4bsa+Y7oD=97OwQpgCgcGVS-Qq5BmrC7uJtbg@HIDDEN>
 <CABsNJ=N+EJ9GCrLyY_fi9zm54ji_-zi_A8R4QZuxeDhp-foOjw@HIDDEN>
 <E1dSWss-0000ey-Uw@HIDDEN> <8337abobuz.fsf@HIDDEN>
 <87eftpa30a.fsf@HIDDEN> <83a84djweb.fsf@HIDDEN>
 <CABsNJ=PzzCvP_103dRgWAaYbq3Eh9VqKyrnr6A=2JagV-7D-Ww@HIDDEN>
 <CABsNJ=Oxv8PuQ=a9VViWt67q4Wt=nZHWEji2V_j55GTRcmJMfw@HIDDEN>
 <83shhsbakk.fsf@HIDDEN>
 <CABsNJ=NR=jeERo6RQan6E+3o2wEngL=xAeaoxyw5KPB+oae47g@HIDDEN>
 <83lgnjbsqw.fsf@HIDDEN>
 <CABsNJ=PtNhA0aptf0jo1Jk1h52zUz=7gWySoV+aEV0vmux3agQ@HIDDEN>
 <83bmofbc0f.fsf@HIDDEN>
 <CABsNJ=MrnXe7OopOnw=XUr536wTdq+f+uRjoMQQRiz1Pvrukww@HIDDEN>
 <83tw269odx.fsf@HIDDEN>
 <CABsNJ=OqYN1ZkHEHK8WUus5ph8_P1KtdVLFKqEpR_8h=mDsC5g@HIDDEN>
 <CABsNJ=MH3kkcL5_GFA2vpo-sjLodhON6VLSeARbTOSphRMX3Fw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Itai Berli <itai.berli@HIDDEN>
> Date: Fri, 21 Jul 2017 13:58:57 +0300
> 
> Instead of requiring Emacs to wrap lines correctly as they are being typed, only require it to display correctly
> wrapped lines once a file is opened, as well as once the user explicitly invokes a certain function while editing
> the file.

Thanks, but this proposal is unworkable, for several reasons.

First, reordering of bidirectional text is a display-time feature.
That means text in the buffer is left intact, in its original logical
order, and is reordered only when some portion of that text is being
considered for possible redisplay.  (I wrote "considered for possible
redisplay" on purpose, because many times the display engine will
decide that certain parts of the display have not changed, and
therefore this potential will not be realized for some of the text.)
The reordered characters appear in their visual order only in the data
structures used as part of redisplay, the buffer text retains its
original order.  These data structures are ephemeral and not
accessible from Lisp.

This means that wrapping lines when a file is first visited by Emacs
is meaningless, because most of the file will not be shown on-screen.
Likewise with the user invoking a command: it can only be done when an
incorrect display is already on the screen, and only for the part that
is actually displayed.

But there is a more fundamental reason why this will not be useful.
Almost everything the user does in Emacs causes a redisplay cycle.
Even when the user just moves the cursor, there is a redisplay
immediately after that.  If your cursor blinks (as it does by
default), each blink causes a redisplay cycle.  Each such redisplay
cycle compares the actual screen display with the desired one, and
redraws any parts that are different.  So unless the correct line
wrapping is part of the "normal" display, it will be very short-lived,
since the very next redisplay cycle might replace it with the
"incorrectly" wrapped lines.

All of this is due to the basics of the Emacs design: changes to
buffer text and other related objects made by the Lisp interpreter do
not directly drive the display.  Instead, when the Lisp interpreter
becomes idle (meaning that it is done with changing buffers and other
objects, as instructed by the last command), redisplay is
automatically called, and is responsible for figuring out what, if
anything, needs to be changed on display due to the changes made by
the Lisp interpreter.  It follows that you cannot "fix" redisplay
problems by something you do in Lisp.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.