From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: "... the window start at a meaningless point within a line." Date: Fri, 16 Oct 2015 15:19:36 +0000 Message-ID: <20151016151936.GB2779@acm.fritz.box> References: <20150930204513.GA3174@acm.fritz.box> <83mvw39dp3.fsf@gnu.org> <20151001094138.GA2515@acm.fritz.box> <83h9maao7w.fsf@gnu.org> <20151001110204.GB2515@acm.fritz.box> <83egheaj9e.fsf@gnu.org> <20151015181642.GA6467@acm.fritz.box> <834mhr99e8.fsf@gnu.org> <20151016095535.GA2779@acm.fritz.box> <83wpun5d5u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1445009102 1739 80.91.229.3 (16 Oct 2015 15:25:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 15:25:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 17:24:53 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zn6rt-0002xL-HM for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 17:24:29 +0200 Original-Received: from localhost ([::1]:54385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6rs-000116-LI for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 11:24:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6lh-0007yN-4g for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:18:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn6ld-0005vn-Sz for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:18:05 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:36922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6ld-0005tb-HU for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:18:01 -0400 Original-Received: (qmail 8317 invoked by uid 3782); 16 Oct 2015 15:18:00 -0000 Original-Received: from acm.muc.de (p5B14790D.dip0.t-ipconnect.de [91.20.121.13]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 16 Oct 2015 17:17:58 +0200 Original-Received: (qmail 7205 invoked by uid 1000); 16 Oct 2015 15:19:36 -0000 Content-Disposition: inline In-Reply-To: <83wpun5d5u.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191763 Archived-At: Hello, Eli. On Fri, Oct 16, 2015 at 01:19:09PM +0300, Eli Zaretskii wrote: > > Date: Fri, 16 Oct 2015 09:55:35 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > I think most of the time, I just need to assign one struct it to another. > Let's postpone discussing this until we have a working code that > doesn't break bidi. Good idea! [ .... ] > > > Comparisons with == are OK. > > There must be some bidi compatible order operators which express > > "earlier than" etc. I will be needing these. > Define "earlier than". Is that on screen, i.e. in the visual order, > or in the buffer, i.e. in the logical order, a.k.a. "the order of > buffer positions"? These two orders are different for bidirectional > text. I've no experience with bidi text, or even RTL text. Could you cite me an appropriate bidi or RTL file I could play around with, even though I couldn't read it. Would I need any special set up with (for example) fonts, or input methods? In fact, before asking you to answer these I should read the fine manual first. Coming back to the first application of "earlier than" in the function, it determines whether or not there is overlap between the first text line on the screen, and the text between PT and `it'. At the moment, this check for overlap is done with if (beginning < L0_phys_EOL && end >= ws) I can't grasp why this comparison might fail under bidi - all four variables hold text positions. What could go wrong with comparisons involving BOL positions? Am I right in thinking that in an RTL line, the "beginning of the line", i.e. the character immediately following a linefeed, would be displayed at the right hand side of the window, and that subsequent characters would be displayed to the left of this? I see that `it' movements from "left to right" are going to move to successively lower buffer positions, and this will give me trouble. [ .... ] > As long as you use functions that move the iterator, you cannot safely > assign one 'struct it' to another. That's because the iterator object > has a (mostly invisible) companion -- the bidi cache, which must be in > sync with the contents of 'struct it'. But surely each struct it has its own bidi cache, doesn't it? That would be the component bidi_it inside struct it? Or am I missing something here? [ .... ] -- Alan Mackenzie (Nuremberg, Germany).