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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Oct 01, 2015 at 11:48:40AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 30 Sep 2015 20:45:13 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > 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 particular problem I'm looking at is with Follow Mode, where a pair
> > of adjacent windows are of unequal width.  This is a very common
> > scenario - I frequently use Follow Mode with three side by side windows
> > of widths 79, 79, and 80 (as measured by window-body-width).

> > The problem occurs when there's a long line at the bottom of window 2
> > and its continuation line at the top of window 3.  The display manager
> > chops off the line in W2 after 78 characters, and inserts a \ sign.  It
> > then starts the continuation line in W3 at character 80 (counting from
> > 1), assuming as it does, that the previous line in this window would be
> > 79 characters long.  So character 79 appears neither on the first
> > portion of the line in W2, nor in its continuation in W3.  This is
> > suboptimal.

> > This problem would not occur if there were a flag to set-window-start
> > meaning "this value really is where I want the window to start, not some
> > beginning of line nearby".

> > How difficult would it be to relax the constraint on window start
> > positions and implement this flag?

> It's not difficult, at least in principle: the recalculation of the
> window-start point is done in a single function.  Not sure if it will
> have adverse effects, though.  You will surely have that horizontal
> scrolling, but I don't know what other effects will be caused.

I think scrolling such a window one screen line down would cause the
break in the line to have to be repositioned.  So it wouldn't be trivial.

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

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.

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.  This might have to be a
customisation variable.

-- 
Alan Mackenzie (Nuremberg, Germany).