From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "... the window start at a meaningless point within a line." Date: Fri, 16 Oct 2015 13:19:09 +0300 Message-ID: <83wpun5d5u.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1444990802 20341 80.91.229.3 (16 Oct 2015 10:20:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 10:20:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 12:19:45 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 1Zn26p-000777-93 for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 12:19:35 +0200 Original-Received: from localhost ([::1]:52499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn26o-0001Za-KU for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 06:19:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn26k-0001ZL-DZ for emacs-devel@gnu.org; Fri, 16 Oct 2015 06:19:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn26g-0004fu-De for emacs-devel@gnu.org; Fri, 16 Oct 2015 06:19:30 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn26g-0004fk-4z for emacs-devel@gnu.org; Fri, 16 Oct 2015 06:19:26 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWB002005VTZO00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 16 Oct 2015 13:19:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB0027M5ZWWV50@a-mtaout20.012.net.il>; Fri, 16 Oct 2015 13:19:08 +0300 (IDT) In-reply-to: <20151016095535.GA2779@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:191736 Archived-At: > Date: Fri, 16 Oct 2015 09:55:35 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > Why do you need to touch compute-motion? I don't think it's used in > > your scenarios. > > Because it deals with screen lines and columns. But looking more closely > at it, it doesn't use struct it's, or anything like that, so perhaps I > won't need to do anything to it. AFAIR, it's only used in batch mode, so should not be relevant. > > I'd prefer these [SAVE_IT and RESTORE_IT] to stay private to xdisp.c. > > If you really need them elsewhere (I don't think so), there are > > alternative solutions. > > 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. > > > + if (IT_CHARPOS (*it) < ws) > > > + { > > > + below = false; /* exact_it is already past `it'. */ > > > + SAVE_IT (post_exact_it, exact_it, cache); > > > + } > > > Same here. > > > > + while (1) > > > + { > > > + if (IT_CHARPOS (exact_it) < IT_CHARPOS (*it)) > > > + SAVE_IT (pre_exact_it, exact_it, cache); > > > + if (!forward_to_next_display_line_start (&exact_it)) > > > + break; /* protection against infinite looping. */ > > > + if (below > > > + && IT_CHARPOS (exact_it) >= IT_CHARPOS (*it)) > > > + { > > > + below = false; > > > + SAVE_IT (post_exact_it, exact_it, cache); > > > + } > > > + if (IT_CHARPOS (exact_it) > end) > > > + break; > > > And here. And everywhere else. > > > > + if (IT_CHARPOS (exact_it) == IT_CHARPOS (xdisp_it)) > > > 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 also suspect you don't need all those calls to SAVE_IT all over the > > place. In any case, you are leaking memory here, because there's not > > a single RESTORE_IT to free the memory that SAVE_IT allocates. > > As I said, straight assignments should do most of the time. 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'. > > Can you describe the algorithm of this function in English? Then > > perhaps I could help you rewrite it in bidi-aware way. > > OK, here goes! It's a bit long winded, but that's because the function > is little more than an assemblage of special cases. Thanks, I will study it and see what can I propose.