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: Sun, 1 Nov 2015 18:46:38 +0000 Message-ID: <20151101184637.GF2768@acm.fritz.box> References: <83k2ql4lsy.fsf@gnu.org> <20151018150052.GD1639@acm.fritz.box> <83lhb0hy0h.fsf@gnu.org> <20151019102755.GB2438@acm.fritz.box> <20151027134025.GA2401@acm.fritz.box> <83fv0w41dg.fsf@gnu.org> <20151028131505.GB2538@acm.fritz.box> <8337wryy0x.fsf@gnu.org> <20151101152354.GD2768@acm.fritz.box> <83h9l5y5on.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 1446403509 11419 80.91.229.3 (1 Nov 2015 18:45:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Nov 2015 18:45:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 01 19:45:02 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 1Zsxci-0001MF-DV for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 19:45:00 +0100 Original-Received: from localhost ([::1]:38476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsxch-0001h9-QJ for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 13:44:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsxcd-0001h4-IY for emacs-devel@gnu.org; Sun, 01 Nov 2015 13:44:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zsxca-0004JK-BY for emacs-devel@gnu.org; Sun, 01 Nov 2015 13:44:55 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:52013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsxcZ-0004If-Uc for emacs-devel@gnu.org; Sun, 01 Nov 2015 13:44:52 -0500 Original-Received: (qmail 82291 invoked by uid 3782); 1 Nov 2015 18:44:49 -0000 Original-Received: from acm.muc.de (p548A4E61.dip0.t-ipconnect.de [84.138.78.97]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 19:44:49 +0100 Original-Received: (qmail 4311 invoked by uid 1000); 1 Nov 2015 18:46:38 -0000 Content-Disposition: inline In-Reply-To: <83h9l5y5on.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:193075 Archived-At: Hello, Eli. On Sun, Nov 01, 2015 at 07:45:28PM +0200, Eli Zaretskii wrote: > > Date: Sun, 1 Nov 2015 15:23:54 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > The patch below should go a long way towards solving these problems. > > > The only issue I left unsolved is exposed when typing C-p on the > > > second screen line of the right-side window: you will see that it > > > doesn't succeed in keeping the visual column. Solving this is left as > > > an exercise ;-) > > > > ;-). Sometimes it doesn't even go to the right line (i.e. when there > > are more or fewer "actual" lines than "xdisp" lines). > The code is explicitly unfinished, I said that much. I wrote it in > the hope that it will show enough to get you off the ground with using > the move_it_* functions for the purposes such as this. But it > definitely needs more work. > > To detect this situation necessarily involves reseat_at_window_start > > followed by moving forward, counting (display) line starts, in some > > fashion. Do you agree? > I don't know if I agree. I don't think I understand the situation > well enough to reason about it. > The problem with the first screen line of a window is the call to > move_it_by_lines with its second argument zero. The simplest solution > is to eliminate that call, and instead achieve the same effect "by > hand" (if at all necessary). > > To move to the right column of the line necessarily involves knowing > > where the "actual" BOL is. > No, not necessarily. Moreover, the "actual BOL" will not help you if > it is known as a buffer position (as opposed to its screen horizontal > coordinate). > > At the moment, I can't see how post analysis (i.e. analysis after > > Fvertical_motion has done move_it_by_lines (&it, nlines)) can be > > avoided. > I don't understand the significance of what you want to say here, > sorry. One of the large changes I made does precisely that, right? > > In this line of thinking, considering how bidi complicates the order of > > PT, end position, and various BOLs, it might be very convenient to > > enhance move_it_in_display_line_to to take TWO (or even several) > > to_charpos parameters, such that the function would stop after reaching > > either one of them. > IME, this kind of reasoning about these problems is not useful, it > leads into a conceptual trap. The key problem is with the definition > of "reaching". In the unidirectional display, whenever you see a > buffer position >= goal, you have "reached" the goal. But this breaks > with bidirectional text, so only strict equality can be meaningfully > tested. But the exact equality might legitimately be out of our reach > (pun intended), for any number of valid reasons: display properties, > truncated lines, position outside the visible portion of the buffer, > and many others. So you can never "reach" the goal, but it doesn't > mean you didn't find your spot. And there are no good solutions to > this conundrum. > Instead of reasoning in terms of buffer positions, you should reason > in terms of screen coordinates. The move_it_* functions all work in > the visual order, i.e. they traverse the text in the order it would be > displayed, from left to right, screen line after screen line. If you > think in terms of screen coordinates and horizontal/vertical moves > across screen lines, you can blissfully forget about bidi. I'm beginning to come around to what you suggested some while ago, namely making Follow Mode windows as wide as eachother. While I'm confident I could make the maybe_move_to_exact_bol approach, modified to use screen positions instead of buffer positions, work properly, it would take a lot of work. Probably more work than it's worth. So I'm going to be breaking off this line of work, at least for now, and look at equal width windows. > > > I hope the changes I made and the comments to those changes will speak > > > for themselves, and show how to solve such problems. > > > > I like your idea for solving the "going back over the top of the window" > > problem. Is there any guarantee that w->prev will actually be the > > window "to the left of" w (whatever that might mean)? > Yes. See the documentation and the implementation of > window-prev-sibling and window-next-sibling. OK, thanks. > > > But in general, I must say that fixing what you are trying to fix > > > is an ambitious undertaking; perhaps it would be better to make > > > sure the two windows are always the same width, using pixel-wise > > > resizing where necessary. > > > > As already said, this would be sub-optimal for ttys, where the total > > width is fixed, and tends not to be a number of the form 2n+1 or 3n+2. > We could say that on a TTY vertical cursor motion across windows can > create strange artifacts, if a continued line spans the window. It's > a relatively rare situation, I think. I think it's more rare that anybody notices, but it happens quite a lot. > Or maybe we could arrange for the windows to be scrolled when cursor > approaches the edge, so that a continued line never straddles more > than one window. > Any of these 2 possibilities looks better to me than to fight an > uphill battle against hidden assumptions within the display engine. > The more I think about this, the more it feels like a tip of a giant > iceberg. Beware! OK. I give up on this for now. I'll look at width equality. -- Alan Mackenzie (Nuremberg, Germany).