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

[Alan Mackenzie]

Hello, Eli.

On Tue, Oct 27, 2015 at 08:23:07PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 27 Oct 2015 13:40:25 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > I haven't managed to get anywhere with this.  The code in
> > Fvertical_motion is already quite complicated, due to the variable
> > it_overshoot_count, and the various things that make it necessary, like
> > `before-string' or `after-string' overlays with LFs in them.  If we add
> > in code to correct for "actual" WS into the melee, the code could not
> > help becoming even more difficult to understand.

> > What makes me less enthusiastic about the approach is that it only
> > covers one case, that with (nlines > 0) where point is already within
> > the first text line in the window (not before it).

> In that case, it probably means I will have to do this.  Please send
> the smallest patch that allows window-start to be where you want it,
> and doesn't involve vertical-motion, together with some simple test
> case to show what doesn't work in the unmodified vertical-motion.  I
> will then come up with a fix for that function.

Thanks, this is appreciated.  I've just created an up to date master
repository to make sure my stuff still works, and it doesn't.  So I'm
working on it.  Maybe I'll get the stuff to you later on today, or
tomorrow.

> > I still feel that my approach, of analysing the buffer after
> > Fvertical_motion has moved the nlines and correcting it's position, is
> > the right one.  It separates this complexity from the rest of Fv_m.

> I don't want to separate it, because vertical-motion already does
> almost everything you need, AFAICT.  What you suggest would mean
> significant duplication of code that is already quite tricky.  (Please
> note that you for now tried to handle only the relatively simple case
> of screen lines produced entirely from buffer text, no display or
> overlay strings, no images, no display tables, no composed characters.
> Most of the hair in vertical-motion's code is because of these use
> cases.)

I was aware of this.  But getting the simplest case working first seemed
like a good idea..

> > I've spent some time looking at bidi.c and SAVE_IT, RESTORE_IT.  In
> > essence, IIUC, the bidi cache that SAVE_IT saves belongs conceptually to
> > a struct it, but is too big to be included in it.

> Not only is it big (and theoretically can be as big as the largest
> buffer Emacs can support), its size is not fixed: while the display
> engine iterates through buffer text, it constantly enlarges and
> shrinks the cache as needed (assuming there's bidirectional text; if
> not, the cache is always exactly 1 or 2 slots long).  So it cannot be
> part of the it structure.

Understood.

[ .... ]

> > In fact, why not put Fvertical_motion into xdisp.c, too?  It would
> > appear to have quite a lot to do with display, and not a lot to do
> > with indentation.

> I don't like moving such important functions between files, it
> complicates forensics ("git annotate" etc.).  We have functions
> elsewhere that use xdisp.c functionality, so it's not like indent.c is
> the only one.

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).