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

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 01, 2015 at 01:16:03PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 1 Oct 2015 09:41:38 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > > In the Elisp manual, page "Window Start and End", it's described how, if
> > > > in (set-window-start x) x is a position not at the start of a line, the
> > > > display engine will, instead of x, choose some value near x as the
> > > > window start.  Is this really necessary?

> > > The reason for this is that we want the physical beginning of the line
> > > (i.e. the character after a newline or at bob) always be aligned at
> > > the left edge of the window's text area, even if it is currently out
> > > of view.  This prevents annoying horizontal scrolling of long lines
> > > when the beginning of the line comes into view.

> > OK.  But we're really talking here about where continuation lines start,
> > not physical BOLs.

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

> 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.  This would ensure that every character on
the line would be displayed exactly once, both when the line straddles W2 and
W3, and after it is scrolled entirely onto W3.

> > > But let me turn the table and ask you: how difficult would it be to
> > > make sure follow-mode never lets a window end in the middle of a
> > > continued line?

> > 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.

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.

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.

> > In real life?  I imagine it's quite common to use Follow Mode with very
> > narrow windows (say, four at ~60 wide) when the annoyance of continued
> > lines is less important than seeing all of a long function on the screen
> > at once.  There will then be lots of continued lines, and 3 window
> > boundaries, W1-W2, W2-W3, W3-W4.

> I don't expect "lots", except in text buffers.  Program sources
> usually have shorter lines.  In any case, it would be rare to see
> lines that take more than 2 screen lines.

> > 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.

-- 
Alan Mackenzie (Nuremberg, Germany).