Re: "... the window start at a meaningless point within a line."

[Alan Mackenzie]

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: address@hidden
> > From: Alan Mackenzie <address@hidden>
> > 
> > > 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).