bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 01 Apr 2023 14:26:50 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> > . I'm not sure I'm happy about calling find_newline in a loop where 
> > previous code just made a trivial calculation.  Imagine a buffer with a 
> > lot of short lines.  What problem exactly is being solved here, and how 
> > does this change solve it?
> >
> 
> The point is to find the buffer position of BOL.  But you're right, there 
> is a missed optimization here, which I just added (also in dce08cf05c). 
> Now the code searches for that position in [pos-500..pos], 
> [pos-5500..pos-500], [pos-55500..pos-5500], [pos-555500..pos-55500], in 
> that order, and buffers with lots of short lines (or more precisely: 
> buffers with lots of short lines _and_ one or more long lines) are not 
> negatively affected by that code anymore.

OK, but still: why do you need to find the buffer position at BOL, and
how is that related to cursor movement?

> > . Why such a strange method of finding out whether we are on a TTY 
> > frame?  The usual method is FRAME_WINDOW_P (XFRAME (w->frame)).
> >
> 
> That's what I've been using since that function was introduced six months 
> ago or so.  I admit I don't remember why that's what I chose.  If you tell 
> me that using FRAME_WINDOW_P (XFRAME (w->frame)) has the same effect as 
> terminal-live-p == t (and indeed after looking at the code ISTM that 
> that's the case), I'll replace that.

FRAME_WINDOW_P is what we use all over the place, so it must be
correct.

> > . The continuation glyph can be present not only on TTY frames, but also 
> > on GUI frames when one or both of the fringes are disabled, so the test 
> > needs to be augmented.  I think you need to use WINDOW_LEFT_FRINGE_WIDTH 
> > and WINDOW_RIGHT_FRINGE_WIDTH.
> >
> 
> Thanks, I did not realize that.  I just did that (again in dce08cf05c), 
> but I'm not sure how WINDOW_LEFT_FRINGE_WIDTH should be used.  Using 
> WINDOW_RIGHT_FRINGE_WIDTH seems enough, but I'm probably missing 
> something.

You are missing the case of R2L paragraphs, where the continuation
glyph is displayed on the left.