From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#27525: 25.1; Line wrapping of bidi paragraphs Date: Thu, 20 Jul 2017 08:08:07 +0300 Message-ID: <83lgnjbsqw.fsf@gnu.org> References: <8337abobuz.fsf@gnu.org> <87eftpa30a.fsf@blei.turtle-trading.net> <83a84djweb.fsf@gnu.org> <83shhsbakk.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1500527357 21818 195.159.176.226 (20 Jul 2017 05:09:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Jul 2017 05:09:17 +0000 (UTC) Cc: 27525@debbugs.gnu.org To: Itai Berli Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 20 07:09:13 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 1dY3i0-00057v-Po for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Jul 2017 07:09:09 +0200 Original-Received: from localhost ([::1]:36107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dY3i4-0001dt-DO for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Jul 2017 01:09:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dY3hx-0001dc-V2 for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 01:09:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dY3hu-0003Gz-PQ for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 01:09:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45736) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dY3hu-0003Gt-L0 for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 01:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dY3hu-0002ri-Cr for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2017 01:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2017 05:09: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.150052730810969 (code B ref 27525); Thu, 20 Jul 2017 05:09:02 +0000 Original-Received: (at 27525) by debbugs.gnu.org; 20 Jul 2017 05:08:28 +0000 Original-Received: from localhost ([127.0.0.1]:48412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dY3hM-0002qq-8o for submit@debbugs.gnu.org; Thu, 20 Jul 2017 01:08:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dY3hK-0002qd-JN for 27525@debbugs.gnu.org; Thu, 20 Jul 2017 01:08:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dY3hC-000358-5Y for 27525@debbugs.gnu.org; Thu, 20 Jul 2017 01:08:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dY3hC-000352-1c; Thu, 20 Jul 2017 01:08:18 -0400 Original-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 ) id 1dY3hB-00038f-I3; Thu, 20 Jul 2017 01:08:17 -0400 In-reply-to: (message from Itai Berli on Thu, 20 Jul 2017 00:40:15 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:134778 Archived-At: > 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.