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: Fri, 21 Jul 2017 16:19:35 +0300 Message-ID: <83pocu9bbs.fsf@gnu.org> References: <8337abobuz.fsf@gnu.org> <87eftpa30a.fsf@blei.turtle-trading.net> <83a84djweb.fsf@gnu.org> <83shhsbakk.fsf@gnu.org> <83lgnjbsqw.fsf@gnu.org> <83bmofbc0f.fsf@gnu.org> <83tw269odx.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1500643209 26913 195.159.176.226 (21 Jul 2017 13:20:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Jul 2017 13:20:09 +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 Fri Jul 21 15:20:05 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 1dYXqf-0006ip-Ch for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Jul 2017 15:20:05 +0200 Original-Received: from localhost ([::1]:43182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYXqk-0007qH-Lh for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Jul 2017 09:20:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYXqd-0007pf-NU for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2017 09:20:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dYXqc-0002Gs-OX for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2017 09:20:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47796) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dYXqc-0002Gc-KS for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2017 09:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dYXqc-0006Eg-BJ for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2017 09:20: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: Fri, 21 Jul 2017 13:20: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.150064319723953 (code B ref 27525); Fri, 21 Jul 2017 13:20:02 +0000 Original-Received: (at 27525) by debbugs.gnu.org; 21 Jul 2017 13:19:57 +0000 Original-Received: from localhost ([127.0.0.1]:50473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYXqW-0006EH-N4 for submit@debbugs.gnu.org; Fri, 21 Jul 2017 09:19:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYXqU-0006E4-PS for 27525@debbugs.gnu.org; Fri, 21 Jul 2017 09:19:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dYXqM-00025o-Bw for 27525@debbugs.gnu.org; Fri, 21 Jul 2017 09:19:49 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYXqM-00025g-8C; Fri, 21 Jul 2017 09:19:46 -0400 Original-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 ) id 1dYXqL-0002vs-Dm; Fri, 21 Jul 2017 09:19:46 -0400 In-reply-to: (message from Itai Berli on Fri, 21 Jul 2017 13:58:57 +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:134826 Archived-At: > From: Itai Berli > 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.