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


View this message in rfc822 format

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: bug#56682: locked narrowing
Date: Tue, 16 Aug 2022 21:18:21 +0000
>
> Adding such a LOCK argument might be a good idea, actually, since ELisp 
> packages may also want to impose restrictions on widening (see my recent 
> message to `emacs-devel` about ELisp support for locked narrowing).
>

It might be a good idea indeed.  I did not have an immediate need for it, 
and did not see how to do it (because of the unbalanced specbind).

>
> Why leave the `specbind (Qrestrictions_locked, Qt)` out of the function 
> when you've already included the 3 calls to `record_unwind_protect`? The 
> 4 share the same requirements (because `specbind` pushes on the 
> `specpdl`, just like `record_unwind_protect`).  They naturally belong 
> together.
>

They do indeed, and that's actually what the original code did, but I was 
told that it was better to not do that.

>
> Also, a function that sometimes pushes to `specpdl` (and hence requires 
> the caller to do the `SPECPDL_INDEX + unbind_to` dance) and sometimes 
> not, depending on some value of its argument is a bit unnatural (it 
> complicates the reasoning when we try and convince ourselves that the 
> stack discipline of the specpdl is obeyed).  So I'd recommend you split 
> the function into two: a first one that only does the narrowing itself 
> and a second one which calls the first plus unconditionally does the 
> `specbind+record_unwind_protect`.
>

Okay, thanks.  That's probably another way to do it, indeed.

>> Not "a lot", but indeed there's some redundancy there that could have 
>> been avoided.
>
> AFAICT it's more than half of the code of each branch.
>

That's still not "a lot", there are 12 statements in total in the two 
branches.  And they have 3 statements in common...




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

Previous Next


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