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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 1 Oct 2015 11:02:04 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > The display engine always starts from the physical BOL when it lays
> > out buffer text.  That's because only at a physical BOL it knows that
> > the window-relative X coordinate is zero.  Otherwise, there's no
> > anchor for it to start at.
> 
> OK, so such a change would be, at least somewhat, non-trivial.  Could the
> supplied window start position, as in (set-window-start line-middle-pos
> nil t), not count as such an anchor?

It cannot act as an anchor, because the horizontal X coordinate is not
(and cannot be) known by the caller.

> > Invalidating this basic assumption will cause strange effects,
> > including the horizontal scrolling I mentioned.
> 
> This horizontal scrolling (of a long line at the top of W3, when a
> scroll-down brings the beginning of the line onto the window) would be
> precisely what's wanted here.

Then go ahead and make the change.  The display engine will cope.  I'm
not sure what users will say, but that's not my problem here ;-)

> > > In the worst case, very difficult.  Indeed, with three follow windows,
> > > all of slightly different widths, and a fiendish specially constructed
> > > file, it could be that when you scroll the buffer a single screen line to
> > > deal with a break between W1 and W2, you create the same problem between
> > > W2 and W3.  In such a scenario, you might end up scrolling the buffer
> > > quite a long way in the search for no "broken" continued lines at either
> > > boundary.  With such a file there might be NO position where there isn't
> > > a break.
> 
> > Are you talking about lines so long that they take more than one
> > window-full to display?  If so, let's not bother about those for the
> > moment.  Do you see such problem with reasonably short lines?
> 
> No, I was just thinking of ordinary 100 character lines in ordinary
> windows.

Then I don't see the problem.  yes, you will need to scroll several
lines, but why is that a problem?

> Let me outline the problem I saw: I have a command `scrolldown-n', bound
> to S-<up>.  With point in W3, S-<up> was failing to scroll the screen.
> The cause was the split line making (window-end W2) different from
> (window-start W3), which messed up Follow Mode's window alignment
> routines.

I understood.  If you never break in the middle of a continued line,
this should not happen.

> Another (lesser) problem is moving point from W2 to W3 with C-x o
> sometimes causes W1 and W2 to scroll up one line; this has the same
> cause.  It is suboptimal.

IIUC, you will not be able to fix this.  Changes near the boundary
between 2 windows will always be likely to cause some scrolling like
that.

> > > If we were to go this route (of repositioning to avoid line breaks
> > > between follow windows), there would have to be a limit on how far one
> > > could scroll, with a value such as 3.
> 
> > In what units?  Screen lines?  Why only 3?
> 
> Yes, 3 screen lines.  With a command like `scrolldown-n', or C-u 1
> <PageUp>, the user is requesting a single line scroll.  Scrolling more
> than this, even 2 or 3 lines, would be puzzling and irritating.

Not sure if horizontal scrolling will be more or less irritating, but
I guess we will find out soon.