GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
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);

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.