From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Mixed L2R and R2L paragraphs and horizontal scroll Date: Fri, 12 Feb 2010 14:36:39 +0200 Message-ID: <83iqa2d414.fsf@gnu.org> References: <83tyu3iu6b.fsf@gnu.org> <83vdeghfqg.fsf@gnu.org> <201002012205.o11M5Sci011809@beta.mvs.co.il> <83k4uvh09o.fsf@gnu.org> <201002031310.o13DAqXd019253@beta.mvs.co.il> <40314.130.55.118.19.1265230948.squirrel@webmail.lanl.gov> <201002041621.o14GL6w5006928@beta.mvs.co.il> <833a1ghjrj.fsf@gnu.org> <83tytwf1tp.fsf@gnu.org> <30fb12601002111340m26c80bcfi69906ac90d887684@mail.gmail.com> <83ljeyd8br.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1265978501 12800 80.91.229.12 (12 Feb 2010 12:41:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Feb 2010 12:41:41 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: cben@users.sf.net Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri Feb 12 13:41:38 2010 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nfuq0-0007eO-71 for gnu-emacs-bidi@m.gmane.org; Fri, 12 Feb 2010 13:41:36 +0100 Original-Received: from localhost ([127.0.0.1]:58591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfupz-0001rA-Hr for gnu-emacs-bidi@m.gmane.org; Fri, 12 Feb 2010 07:41:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NfuoQ-0001OM-Qm for emacs-bidi@gnu.org; Fri, 12 Feb 2010 07:39:58 -0500 Original-Received: from [140.186.70.92] (port=45413 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NfuoP-0001Nf-Uj for emacs-bidi@gnu.org; Fri, 12 Feb 2010 07:39:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NfuoO-0002km-Rr for emacs-bidi@gnu.org; Fri, 12 Feb 2010 07:39:57 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:46492) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NfuoO-0002kV-KW; Fri, 12 Feb 2010 07:39:56 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KXQ00800AYYDB00@a-mtaout22.012.net.il>; Fri, 12 Feb 2010 14:38:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KXQ0034NB4HNTD0@a-mtaout22.012.net.il>; Fri, 12 Feb 2010 14:38:42 +0200 (IST) In-reply-to: <83ljeyd8br.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:555 gmane.emacs.devel:121071 Archived-At: > Date: Fri, 12 Feb 2010 13:03:52 +0200 > From: Eli Zaretskii > Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org > > > So if only the line breaking points were static, you'd have no > > performance problem! > > If the line breaking points were at known buffer positions, yes. Actually, that's not true, in general. Embeddings break that. Here's an example. Imagine the following text in logical order: he said "I HEARD HIM SAYING ['car is CAR in arabic'] AND FAINTED" The [...] part is an embedding: it is there to have this text display as he said "DETNIAF DNA 'car is RAC in arabic' GNIYAS MIH DRAEH I" rather than as he said "GNIYAS MIH DRAEH I 'car is RAC in arabic' DETNIAF DNA" The latter display does not express what the writer of the text wanted to say. (Please don't nit-pick wrt the known issues with reordering quotes and apostrophes: they are here just to make the text more readable, and can be easily removed without affecting the fundamental problem I'm talking about.) UAX#9 allows up to 60 levels of such embeddings, btw. The characters [ and ] represent special Unicode code points known as LRE and PDF, respectively. There are also LRO, RLE, and RLO, for similar jobs but with the other direction. Now, suppose the window is only wide enough to display this: he said "'car is GNIYAS MIH DRAEH I" The continuation line should then display the rest of the text: "DETNIAF DNA RAC in arabic' (again, disregard the placement of quotes). Right? Or does this look incorrect? If so, what is the correct display in this case? Anyway, if we stop the bidi reordering after "car is", and restart it at "CAR", the information about the unfinished embedding is lost, and the continuation line will be displayed differently. Which means breaking the line in the middle of an embedding is tricky at best. It also means that putting a newline on some whitespace character, like fill-paragraph does, will have the same problem of generating incorrect (or at least unexpected) display of the second part of the broken line. Conclusion: to apply such smart line continuation, we need first to establish where are the points at which we are allowed to break the line.