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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Oct 31, 2015 at 03:21:02PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 28 Oct 2015 13:15:05 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > After applying the patch, to test things, in X (?or windows)
> > o - Start emacs -Q.
> > o - Load utilities.el.
> > o - Visit fragment.el.
> > o - Using the mouse, make the frame wide enough for two side by side
> >   windows of width 79 and 80.
> > o - C-x 3.
> > o - Fiddle about with the mouse, M-{, M-}, until the windows are 79, and
> >   80 wide (`window-body-width' is your friend, here).
> > o - Scroll the buffer until L162 straddles window 1 and window 2, with
> >   two display lines in each window.  (S-<up>/<down>, C-S-<up>/<down>
> >   from utilies.el are handy, here).

> > First of all, note that in L162, all characters are displayed exactly
> > once.  This is the purpose of this change.

> > With point in W2, note that C-<left> doesn't go to the beginning of
> > the window, and C-<right> doesn't go to the end.  The actual end
> > positions are a line out in both cases.  With point in the split line,
> > note that vertical-motion (C-u <n> C-c m) doesn't go to the right
> > places, even when the target line is below the split line.  Typing <up>
> > and <down> also produce interesting effects.

> > Using M-{ or M-}, make W1 80 wide, and W2 79 wide.  Scroll the windows
> > up and down, back to the same place, to ensure that Follow Mode has
> > resynchronised its windows[*].  Now repeat the experiments of the
> > previous paragraph.  If anything, the results now are even worse.

> 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).  To detect this
situation necessarily involves reseat_at_window_start followed by moving
forward, counting (display) line starts, in some fashion.  Do you agree?
To move to the right column of the line necessarily involves knowing
where the "actual" BOL is.  This also involves a reseat_at_window_start
and moving forward lines.  Do you agree this one, too?

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.

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.  (Naturally, there would be some convention for the
usual case of calling it with just one to_charpos.)  Although this
enhancement would be tedious, it would surely not be difficult.  With
such a function, we could scan through the buffer with both PT and
end_position as to_charpos's.  What do you think?

> 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)?

> Please note that there's a very serious underlying problem here: the
> move_it_* functions and all their callers assume that moving beyond
> above or below the window keeps the same window dimensions, in
> particularly its width.  Follow mode violates this assumption, because
> moving from the left-side to the right-side window or vice versa can
> change the width.  Accounting for this would need very deep changes in
> the above mentioned functions.  For now, I avoided that, and the patch
> below is just a band-aid.  If it works well enough in practice, maybe
> we can avoid the surgery.  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.

-- 
Alan Mackenzie (Nuremberg, Germany).