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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


Message #2016 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, dgutov <at> yandex.ru
Subject: Re: bug#56682: locked narrowing
Date: Fri, 02 Dec 2022 00:24:00 +0000
>
> Maybe another option is to do the scan more lazily, keeping track more 
> precisely of what was scanned and/or needs rescanning.
>

Thanks.  It's an option indeed, the problem here is how to keep track of 
what was scanned or needs rescanning.  I think doing that would probably 
need two markers for each buffer, say beg_scan_marker and end_scan_marker. 
An initial scan would set beg_scan_marker to Z and end_scan_marker to BEG. 
Then each operation in insdel.c would move beg_scan_marker downwards (if 
the buffer position at which the operation takes place is before the 
current value of beg_scan_marker) and end_scan_marker upwards (if the 
buffer position at which the operation takes place is after the current 
value of beg_scan_marker).  Then we would only need to scan 
beg_scan_marker - some_constant .. end_scan_marker + some_constant again.

That being said, I'm not sure the added complexity, to avoid small delays 
when performing large editing operations in huge buffers, is worth the 
price.




This bug report was last modified 2 years and 10 days ago.

Previous Next


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