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: Tue, 27 Oct 2015 20:23:07 +0200 Message-ID: <83fv0w41dg.fsf@gnu.org> References: <837fmm65bl.fsf@gnu.org> <20151016201238.GD2779@acm.fritz.box> <83twpp51xz.fsf@gnu.org> <20151017115738.GA2522@acm.fritz.box> <83oafx4qsb.fsf@gnu.org> <83lhb14o6e.fsf@gnu.org> <83k2ql4lsy.fsf@gnu.org> <20151018150052.GD1639@acm.fritz.box> <83lhb0hy0h.fsf@gnu.org> <20151019102755.GB2438@acm.fritz.box> <20151027134025.GA2401@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445970254 6467 80.91.229.3 (27 Oct 2015 18:24:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 18:24:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 19:24:05 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 1Zr8ui-0000iB-UZ for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 19:24:05 +0100 Original-Received: from localhost ([::1]:33624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8ui-0001LV-9X for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 14:24:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8ua-0001FA-OW for emacs-devel@gnu.org; Tue, 27 Oct 2015 14:24:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr8uX-0000Jn-JR for emacs-devel@gnu.org; Tue, 27 Oct 2015 14:23:56 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:34726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8uX-0000JP-Al for emacs-devel@gnu.org; Tue, 27 Oct 2015 14:23:53 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NWW00A005K3ML00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Tue, 27 Oct 2015 20:22:53 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWW00A945Q4L440@a-mtaout23.012.net.il>; Tue, 27 Oct 2015 20:22:53 +0200 (IST) In-reply-to: <20151027134025.GA2401@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.175 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:192743 Archived-At: > Date: Tue, 27 Oct 2015 13:40:25 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > I haven't managed to get anywhere with this. The code in > Fvertical_motion is already quite complicated, due to the variable > it_overshoot_count, and the various things that make it necessary, like > `before-string' or `after-string' overlays with LFs in them. If we add > in code to correct for "actual" WS into the melee, the code could not > help becoming even more difficult to understand. > > What makes me less enthusiastic about the approach is that it only > covers one case, that with (nlines > 0) where point is already within > the first text line in the window (not before it). In that case, it probably means I will have to do this. Please send the smallest patch that allows window-start to be where you want it, and doesn't involve vertical-motion, together with some simple test case to show what doesn't work in the unmodified vertical-motion. I will then come up with a fix for that function. > I still feel that my approach, of analysing the buffer after > Fvertical_motion has moved the nlines and correcting it's position, is > the right one. It separates this complexity from the rest of Fv_m. I don't want to separate it, because vertical-motion already does almost everything you need, AFAICT. What you suggest would mean significant duplication of code that is already quite tricky. (Please note that you for now tried to handle only the relatively simple case of screen lines produced entirely from buffer text, no display or overlay strings, no images, no display tables, no composed characters. Most of the hair in vertical-motion's code is because of these use cases.) > I've spent some time looking at bidi.c and SAVE_IT, RESTORE_IT. In > essence, IIUC, the bidi cache that SAVE_IT saves belongs conceptually to > a struct it, but is too big to be included in it. Not only is it big (and theoretically can be as big as the largest buffer Emacs can support), its size is not fixed: while the display engine iterates through buffer text, it constantly enlarges and shrinks the cache as needed (assuming there's bidirectional text; if not, the cache is always exactly 1 or 2 slots long). So it cannot be part of the it structure. > Would the following strategy for maybe_move_to_exact_bol work? > o - Execute SAVE_IT on *it just once, right at the start. > o - Calculate the target position using several struct it's, as > currently coded, ignoring bidi aspects. > o - Execute RESTORE_IT on *it. > o - Move *it to our target position. > o - Set it->current_x and it->hpos to zero. No, you cannot ignore bidi aspects. The move_it_* functions work in visual order, not in logical order. So the bidi aspects are inherently part of your use of those functions. > How about putting maybe_move_to_exact_bol into xdisp.c, allowing it to > use SAVE_IT and RESTORE_IT without exporting these two macros? That's OK (assuming we need that function -- it looks too large for such a simple job). But that is a relatively minor problem. > In fact, why not put Fvertical_motion into xdisp.c, too? It would > appear to have quite a lot to do with display, and not a lot to do > with indentation. I don't like moving such important functions between files, it complicates forensics ("git annotate" etc.). We have functions elsewhere that use xdisp.c functionality, so it's not like indent.c is the only one. > Another point I'd appreciate clarification on. Some while back, for > example, your mail of Fri, 16 Oct 2015 20:26:08 +0300, we were talking > about the order of screen positions varying non-linearly with buffer > positions. Is it true that if a continuation line begins at buffer > position A, then for x < A, buffer position x will be displayed on a > previous line? By "continuation line" do you mean the 2nd, 3rd, etc. screen line of a long physical line? If so, the answer is NO, not in general (although in practice it's almost always like you describe, even when bidi text is in the buffer). > (And also for x > A, x will be displayed on this line or a > subsequent one?) Also no. IOW, the visual order is non-linear both in X and in Y directions.