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

From: Gregory Heytings <[email-masked]>
Date: Sat, 01 Apr 2023 15:41:13 +0000

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

Well, with the improved calculation:

max (bol_pos + ((pos - bol_pos) / len - 1) * len, BEGV)

instead of:

max ((pos / len - 1) * len, BEGV)

cursor movement becomes accurate.  You can see that for example in the 
'long-line.xml' file, in which the cursor does not move to a "wrong" 
column anymore (or sometimes even to another column on the same visual 
line).  The idea is that, instead of simply taking a position in the 
buffer that only depends on the value of 'pos' as a value for BEGV (with 
'get_small_narrowing_begv'), we take one that is, inside a long line, 
relative to BOL, IOW, it is always BOL + n * len, for some n.

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

Okay, thanks.

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

Okay, so what would be the correct calculation here?  This?

int width = window_body_width (w, WINDOW_BODY_IN_CANONICAL_CHARS)
   - (WINDOW_RIGHT_FRINGE_WIDTH (w) == 0
      || WINDOW_RIGHT_FRINGE_WIDTH (w) == 0 ? 1 : 0);