From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Itai Berli Newsgroups: gmane.emacs.bugs Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs Date: Thu, 20 Jul 2017 10:01:33 +0300 Message-ID: References: <8337abobuz.fsf@gnu.org> <87eftpa30a.fsf@blei.turtle-trading.net> <83a84djweb.fsf@gnu.org> <83shhsbakk.fsf@gnu.org> <83lgnjbsqw.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1b47ce0ceb710554ba547c" X-Trace: blaine.gmane.org 1500534195 4655 195.159.176.226 (20 Jul 2017 07:03:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Jul 2017 07:03:15 +0000 (UTC) To: 27525@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 20 09:03:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dY5UJ-0000l9-K0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Jul 2017 09:03:07 +0200 Original-Received: from localhost ([::1]:36359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dY5UO-0000b6-VW for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Jul 2017 03:03:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dY5UI-0000al-3U for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 03:03:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dY5UE-0001yj-Ti for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 03:03:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45789) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dY5UE-0001yA-NG for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 03:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dY5UE-0005b2-6O for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 03:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Itai Berli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2017 07:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27525-submit@debbugs.gnu.org id=B27525.150053414421458 (code B ref 27525); Thu, 20 Jul 2017 07:03:02 +0000 Original-Received: (at 27525) by debbugs.gnu.org; 20 Jul 2017 07:02:24 +0000 Original-Received: from localhost ([127.0.0.1]:48466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dY5Tb-0005a2-Dx for submit@debbugs.gnu.org; Thu, 20 Jul 2017 03:02:23 -0400 Original-Received: from mail-wr0-f177.google.com ([209.85.128.177]:36681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dY5TZ-0005Zo-Nf for 27525@debbugs.gnu.org; Thu, 20 Jul 2017 03:02:22 -0400 Original-Received: by mail-wr0-f177.google.com with SMTP id y43so66709982wrd.3 for <27525@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) Original-Received: by 10.28.197.196 with HTTP; Thu, 20 Jul 2017 00:01:33 -0700 (PDT) In-Reply-To: <83lgnjbsqw.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:134781 Archived-At: --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 wrote: > > From: Itai Berli > > 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
I see no reason to continue this discussion any further.
One thing I'm curious about, though. What bidi featur= es exist in Emacs, half of which the other= editors don't have? Which features were you referring to when you wrot= e that, thanks to them, "10 ye= ars later, Emacs still shines among all the=C2=A0bidi-aware editors out there"?

On Thu, Jul 20, 2017 at 8:= 08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Itai Berli <itai.berli@gmail.com>
> 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 fix= ing this bug.

And I believe you exaggerate the importance of this issue, and how much it diminishes the usefulness of the Emacs bidi support.=C2=A0 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<= br> > 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 dev= iation to be.

Of course, it's for me to decide.=C2=A0 Emacs is not an implemen= tation 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 rar= ely in practice? This is the kind of
> statement that only a specialist linguist/statistician can make. And h= ave you taken into account the type of
> demographics who use Emacs' bidi feature and the kinds of texts th= ey're likely to type?

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

=C2=A0 . long lines that wrap on Emacs display are rare to begin with
=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

> 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, sin= ce I write primarily LaTeX documents
> where English markup is intermixed with predominantly Hebrew text cont= aining frequent quotes from English
> textbooks and articles.

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

> Yes, breaking lines is a possible workaround for LaTex, but it makes f= or 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.=C2=A0 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.=C2=A0 So this workaround is available there as
well.=C2=A0 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.=C2=A0 That works with any file/buffer, not just text-like
ones.

> You mention breaking "long lines", but this is not just a pr= oblem of long lines. It takes just two English words
> inside a Hebrew paragraph that happen to fall on a line break, to mani= fest 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: f= rom 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 you= r
needs better.=C2=A0 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.=C2=A0 B= ut
it's a minor annoyance, which happens rarely, and on most cases there 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=
we are lucky to have that, we will have to live with this annoyance.

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
arguments again and again.

--94eb2c1b47ce0ceb710554ba547c--