bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gregory Heytings
Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.
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);






reply via email to

[Prev in Thread] Current Thread [Next in Thread]