bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

CCing the commit author.

Sorry for using external plugin, but master has two separate unrelated
critical regressions (the other one is going via link in *Help* buffer
and getting Emacs locked up with 100% CPU and quickly increasing memory
usage, which complicates reducing the steps), and since there's a clear
commit that introduced the problem I decided to report it as is.

# Steps to reproduce

1. Make sure you're in the Emacs repository and `./build/src/emacs` is
the built binary
2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil
/tmp/evil`
3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs`
(Emacs with Evil loaded will start)
4. Press `n` to refuse running tests
5. Turn line numbers on by evaluating: (setq-default display-line-
numbers 'visual)
6. Press `df`

## Expected

Line numbers are still shown

## Actual

Line numbers disappear

# Additional information
   
The commit that introduced the problem:
   
   commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD)
   Author: David Ponce <da_vid@orange.fr>
   Date:   Thu Aug 22 16:56:11 2024 +0200
   
       Use 'with-work-macro' in 'string-pixel-width'
       
       Tweak the implementation of 'string-pixel-width' to run
       faster and use less memory.  Also cater for the case where
       this function is called in parallel (bug#72689).
       * lisp/emacs-lisp/subr-x.el (string-pixel-width): Use
       `with-work-macro'.  Prefer `remove-text-properties' to
       `propertize' to avoid creating a new string on each call.
   
    lisp/emacs-lisp/subr-x.el | 22 +++++++++++++---------
    1 file changed, 13 insertions(+), 9 deletions(-)
   [03.09.2024-17:13:32] constantine@dell-g15  ~/Projects/builds/emacs-
   git/src/emacs-git ‹node-›  ‹› (dffdbc1f1fd*) 
   

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Cc: da_vid@orange.fr
> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Tue, 03 Sep 2024 17:46:09 +0300
> 
> CCing the commit author.
> 
> Sorry for using external plugin, but master has two separate unrelated
> critical regressions (the other one is going via link in *Help* buffer
> and getting Emacs locked up with 100% CPU and quickly increasing memory
> usage, which complicates reducing the steps), and since there's a clear
> commit that introduced the problem I decided to report it as is.
> 
> # Steps to reproduce
> 
> 1. Make sure you're in the Emacs repository and `./build/src/emacs` is
> the built binary
> 2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil
> /tmp/evil`
> 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs`
> (Emacs with Evil loaded will start)
> 4. Press `n` to refuse running tests
> 5. Turn line numbers on by evaluating: (setq-default display-line-
> numbers 'visual)
> 6. Press `df`

What does "df" do?  Does it somehow end up calling string-pixel-width?

IOW, please show how string-pixel-width is related to the above.

> ## Expected
> 
> Line numbers are still shown
> 
> ## Actual
> 
> Line numbers disappear
> 
> # Additional information
>    
> The commit that introduced the problem:
>    
>    commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD)
>    Author: David Ponce <da_vid@orange.fr>
>    Date:   Thu Aug 22 16:56:11 2024 +0200
>    
>        Use 'with-work-macro' in 'string-pixel-width'

Does it help to replace

   (setq display-line-numbers nil

with

   (setq-local display-line-numbers nil

in string-pixel-width?

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote:
> > Cc: da_vid@orange.fr
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Tue, 03 Sep 2024 17:46:09 +0300
> > 
> > CCing the commit author.
> > 
> > Sorry for using external plugin, but master has two separate
> > unrelated
> > critical regressions (the other one is going via link in *Help*
> > buffer
> > and getting Emacs locked up with 100% CPU and quickly increasing
> > memory
> > usage, which complicates reducing the steps), and since there's a
> > clear
> > commit that introduced the problem I decided to report it as is.
> > 
> > # Steps to reproduce
> > 
> > 1. Make sure you're in the Emacs repository and `./build/src/emacs`
> > is
> > the built binary
> > 2. Execute `git clone --depth 1 https://github.com/emacs-evil/evil
> > /tmp/evil`
> > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil emacs`
> > (Emacs with Evil loaded will start)
> > 4. Press `n` to refuse running tests
> > 5. Turn line numbers on by evaluating: (setq-default display-line-
> > numbers 'visual)
> > 6. Press `df`
> 
> What does "df" do?

"df" is triggering the action "delete text up to" and it will wait for
the third key, the symbol to "delete text up to". But for the problem
to appear pressing the third key is not required.

As a matter of fact, sometimes it gets reproduced by just pressing "f"
which stands for "go to next symbol" (and it would similarly wait a
keypress to define a symbol to go to), but for some reason it happens
much less compared to pressing "df".

>   Does it somehow end up calling string-pixel-width?

It seems it doesn't. I used a `M-x debug-on-entry string-pixel-width`
and then pressed "df" which made line numbers disappear, but debugger
wasn't triggered.

> IOW, please show how string-pixel-width is related to the above.

Offhand I don't know. I would reduce steps, but I can't use *Help* for
reasons mentioned in my 1st email, and I still didn't find a commit
which does not hang upon following *Help* buffer, because 1000 commits
before dffdbc1f1fd6 Emacs fails to compile with some native-compilation
errors and `make clean` doesn't help. I presume finding the culprit for
this problem will take some time.

I don't know if it's of any help, but upon pressing "df" the caret
turns from a rectangle to a square (half the rectangle size). This is
indicating that Emacs is waiting for the next keypress, perhaps this
indication somehow triggers the problem…

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Tue, 2024-09-03 at 19:18 +0300, Konstantin Kharlamov wrote:
> On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote:
> > > Cc: da_vid@orange.fr
> > > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > > Date: Tue, 03 Sep 2024 17:46:09 +0300
> > > 
> > > CCing the commit author.
> > > 
> > > Sorry for using external plugin, but master has two separate
> > > unrelated
> > > critical regressions (the other one is going via link in *Help*
> > > buffer
> > > and getting Emacs locked up with 100% CPU and quickly increasing
> > > memory
> > > usage, which complicates reducing the steps), and since there's a
> > > clear
> > > commit that introduced the problem I decided to report it as is.
> > > 
> > > # Steps to reproduce
> > > 
> > > 1. Make sure you're in the Emacs repository and
> > > `./build/src/emacs`
> > > is
> > > the built binary
> > > 2. Execute `git clone --depth 1
> > > https://github.com/emacs-evil/evil
> > > /tmp/evil`
> > > 3. Execute `PATH="$(pwd)/build/src/:$PATH" make -C /tmp/evil
> > > emacs`
> > > (Emacs with Evil loaded will start)
> > > 4. Press `n` to refuse running tests
> > > 5. Turn line numbers on by evaluating: (setq-default display-
> > > line-
> > > numbers 'visual)
> > > 6. Press `df`
> > 
> > What does "df" do?
> 
> "df" is triggering the action "delete text up to" and it will wait
> for
> the third key, the symbol to "delete text up to". But for the problem
> to appear pressing the third key is not required.
> 
> As a matter of fact, sometimes it gets reproduced by just pressing
> "f"
> which stands for "go to next symbol" (and it would similarly wait a
> keypress to define a symbol to go to), but for some reason it happens
> much less compared to pressing "df".
> 
> >   Does it somehow end up calling string-pixel-width?
> 
> It seems it doesn't. I used a `M-x debug-on-entry string-pixel-width`
> and then pressed "df" which made line numbers disappear, but debugger
> wasn't triggered.
> 
> > IOW, please show how string-pixel-width is related to the above.
> 
> Offhand I don't know. I would reduce steps, but I can't use *Help*
> for
> reasons mentioned in my 1st email, and I still didn't find a commit
> which does not hang upon following *Help* buffer, because 1000
> commits
> before dffdbc1f1fd6 Emacs fails to compile with some native-
> compilation
> errors and `make clean` doesn't help. I presume finding the culprit
> for
> this problem will take some time.
> 
> I don't know if it's of any help, but upon pressing "df" the caret
> turns from a rectangle to a square (half the rectangle size). This is
> indicating that Emacs is waiting for the next keypress, perhaps this
> indication somehow triggers the problem…

So FWIW, I'm not really clear how to debug it further. The problem
seems to only reproduce interactively. I tried calling manually various
functions like `(evil-find-char 1 ?f)`, `(evil-operator-range)`,
`(evil-delete 1 3)` but it didn't trigger the problem. In particular,
`(evil-operator-range)` is the one that makes caret turn to a square
waiting for input, but problem doesn't reproduce like this.

However, I found an alternative way to reproduce it, unfortunately
still requiring Evil:

1. Press f (it will wait for next character)
2. Press C-g to cancel the action
3. Press M-:

Result: line numbers disappear along with minibuffer popping up.

Another interesting point: after line numbers disappeared, if I
evaluate `display-line-numbers` (i.e. just to see its value), line
numbers immediately appear back.

----------

Regarding the unrelated hang, I more or less figured that out. It
turned out to be in another plugin, but it didn't look like a plugin
bug because usually when ELisp hangs you can stop a loop with C-g or
even just quit emacs with ^C or killall, but for some reason
occasionally only SIGKILL worked, which made me think it's a hang in C
code. But it wasn't.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Cc: 73005@debbugs.gnu.org, da_vid@orange.fr
> Date: Wed, 04 Sep 2024 16:02:27 +0300
> 
> 1. Press f (it will wait for next character)
> 2. Press C-g to cancel the action
> 3. Press M-:
> 
> Result: line numbers disappear along with minibuffer popping up.
> 
> Another interesting point: after line numbers disappeared, if I
> evaluate `display-line-numbers` (i.e. just to see its value), line
> numbers immediately appear back.

Sounds like Evil does the above with current buffer set to the work
buffer where we calculate string-pixel-width, and where we therefore
disabled display-line-numbers?

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Wed, 2024-09-04 at 16:15 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Cc: 73005@debbugs.gnu.org, da_vid@orange.fr
> > Date: Wed, 04 Sep 2024 16:02:27 +0300
> > 
> > 1. Press f (it will wait for next character)
> > 2. Press C-g to cancel the action
> > 3. Press M-:
> > 
> > Result: line numbers disappear along with minibuffer popping up.
> > 
> > Another interesting point: after line numbers disappeared, if I
> > evaluate `display-line-numbers` (i.e. just to see its value), line
> > numbers immediately appear back.
> 
> Sounds like Evil does the above with current buffer set to the work
> buffer where we calculate string-pixel-width, and where we therefore
> disabled display-line-numbers?

I git-grepped over Evil the word `work-buffer` and there is no matches.
So there isn't direct call to `with-work-buffer`. Then I tried to `M-x
debug-on-entry with-work-buffer` and reproduced the issue, but debugger
wasn't triggered either.

So doesn't seem like it.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 04/09/2024 6:00 PM, Konstantin Kharlamov wrote:
> On Wed, 2024-09-04 at 16:15 +0300, Eli Zaretskii wrote:
>>> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
>>> Cc: 73005@debbugs.gnu.org, da_vid@orange.fr
>>> Date: Wed, 04 Sep 2024 16:02:27 +0300
>>>
>>> 1. Press f (it will wait for next character)
>>> 2. Press C-g to cancel the action
>>> 3. Press M-:
>>>
>>> Result: line numbers disappear along with minibuffer popping up.
>>>
>>> Another interesting point: after line numbers disappeared, if I
>>> evaluate `display-line-numbers` (i.e. just to see its value), line
>>> numbers immediately appear back.
>>
>> Sounds like Evil does the above with current buffer set to the work
>> buffer where we calculate string-pixel-width, and where we therefore
>> disabled display-line-numbers?
> 
> I git-grepped over Evil the word `work-buffer` and there is no matches.
> So there isn't direct call to `with-work-buffer`. Then I tried to `M-x
> debug-on-entry with-work-buffer` and reproduced the issue, but debugger
> wasn't triggered either.
> 
> So doesn't seem like it.

Could it be that a temporary buffer named " *work*" is being used somewhere?
In which case there could be nasty side effects with the same buffer being
used by `with-work-buffer'?

Just a wild guess.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Date: Thu, 5 Sep 2024 00:07:35 +0200
> Cc: 73005@debbugs.gnu.org
> From: David Ponce <da_vid@orange.fr>
> 
> Could it be that a temporary buffer named " *work*" is being used somewhere?
> In which case there could be nasty side effects with the same buffer being
> used by `with-work-buffer'?

In that case, modifying the name used by with-work-buffer should solve
the problem, I think.

If that doesn't help, either, I guess we do need a reproducer without
Evil, if such a beast exists, because the problem might be in Evil
itself.  If the problem is not in Evil, coming up with a reproducer
will go a long way towards the solution, and might even point out to
the culprit.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

Ping! Can we please make some progress here?

> Cc: 73005@debbugs.gnu.org, Hi-Angel@yandex.ru
> Date: Thu, 05 Sep 2024 08:49:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 5 Sep 2024 00:07:35 +0200
> > Cc: 73005@debbugs.gnu.org
> > From: David Ponce <da_vid@orange.fr>
> > 
> > Could it be that a temporary buffer named " *work*" is being used somewhere?
> > In which case there could be nasty side effects with the same buffer being
> > used by `with-work-buffer'?
> 
> In that case, modifying the name used by with-work-buffer should solve
> the problem, I think.
> 
> If that doesn't help, either, I guess we do need a reproducer without
> Evil, if such a beast exists, because the problem might be in Evil
> itself.  If the problem is not in Evil, coming up with a reproducer
> will go a long way towards the solution, and might even point out to
> the culprit.
> 
> 
> 
> 

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

In case the ping is for me: sorry, what I understand from the last
mails is that I need to find some Emacs function that is executed every
time any buffer is created, and then add a print there that would show
every buffer name being created during reproducing the problem. This
research would take some time from me, but I am kind of got swamped
here, working on my weekend, etc… 😊 If you have some specific steps
for me to try, I'd be happy to try them out. Otherwise, if I need to do
some digging, I think I'll be able to do only that some time later, not
in the near few weeks unfortunately, I think…

On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> Ping! Can we please make some progress here?
> 
> > Cc: 73005@debbugs.gnu.org, Hi-Angel@yandex.ru
> > Date: Thu, 05 Sep 2024 08:49:34 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Date: Thu, 5 Sep 2024 00:07:35 +0200
> > > Cc: 73005@debbugs.gnu.org
> > > From: David Ponce <da_vid@orange.fr>
> > > 
> > > Could it be that a temporary buffer named " *work*" is being used
> > > somewhere?
> > > In which case there could be nasty side effects with the same
> > > buffer being
> > > used by `with-work-buffer'?
> > 
> > In that case, modifying the name used by with-work-buffer should
> > solve
> > the problem, I think.
> > 
> > If that doesn't help, either, I guess we do need a reproducer
> > without
> > Evil, if such a beast exists, because the problem might be in Evil
> > itself.  If the problem is not in Evil, coming up with a reproducer
> > will go a long way towards the solution, and might even point out
> > to
> > the culprit.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 21/09/2024 11:02 AM, Eli Zaretskii wrote:
> Ping! Can we please make some progress here?
> 
>> Cc: 73005@debbugs.gnu.org, Hi-Angel@yandex.ru
>> Date: Thu, 05 Sep 2024 08:49:34 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>>> Date: Thu, 5 Sep 2024 00:07:35 +0200
>>> Cc: 73005@debbugs.gnu.org
>>> From: David Ponce <da_vid@orange.fr>
>>>
>>> Could it be that a temporary buffer named " *work*" is being used somewhere?
>>> In which case there could be nasty side effects with the same buffer being
>>> used by `with-work-buffer'?
>>
>> In that case, modifying the name used by with-work-buffer should solve
>> the problem, I think.
>>
>> If that doesn't help, either, I guess we do need a reproducer without
>> Evil, if such a beast exists, because the problem might be in Evil
>> itself.  If the problem is not in Evil, coming up with a reproducer
>> will go a long way towards the solution, and might even point out to
>> the culprit.

Hi Eli,

I don't use Evil at all, so I was just speculating on a possible cause.

What I did, however, was search the Evil source code (cloned from
https://github.com/emacs-evil/evil) for a possible occurrence of the
term "*work*" (used as the basis for the buffer names generated by
`with-work-buffer' ), but I didn't find one.  Nor any occurrence of
`string-pixel-width' for that matter.

I'm afraid I don't see how either `with-work-buffer' or
`string-pixel-width' would be involved in this problem.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> Ping! Can we please make some progress here?

Hello! Got some spare time, dug into it. Found a few interesting
things:

1. (not really interesting, but…) problem persists in current master
2. The exact function call that causes the problem is `(kill-all-local-
variables t)` inside `(work-buffer--release)`. If I remove it,
everything works as before.

   I guess this implies that bug is not in David's commit per se, but
rather something that's always been present and just got triggered by
David's commit.
3. There's an unrelated bug that confused this whole research, since it
seemed like the function is never called: dong `M-x debug-on-entry
string-pixel-width` does nothing even though `string-pixel-width` is
called.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Sun, 2024-11-03 at 22:07 +0300, Konstantin Kharlamov wrote:
> On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> > Ping! Can we please make some progress here?
> 
> Hello! Got some spare time, dug into it. Found a few interesting
> things:
> 
> 1. (not really interesting, but…) problem persists in current master
> 2. The exact function call that causes the problem is `(kill-all-
> local-
> variables t)` inside `(work-buffer--release)`. If I remove it,
> everything works as before.
> 
>    I guess this implies that bug is not in David's commit per se, but
> rather something that's always been present and just got triggered by
> David's commit.
> 3. There's an unrelated bug that confused this whole research, since
> it
> seemed like the function is never called: dong `M-x debug-on-entry
> string-pixel-width` does nothing even though `string-pixel-width` is
> called.

Great news! I reduced the testcase to just the vanilla Emacs
functional.

# The new steps to reproduce

1. Run emacs as `./build/src/emacs -Q --eval "(setq-default display-
line-numbers 'visual)"`
   
   A emacs with line numbers turned on should start
2. Evaluate `(define-key (make-sparse-keymap) [tab-bar] (lookup-key
global-map [tab-bar]))`

## Expected

Line numbers are still shown

## Actual

Line numbers disappear

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Sun, 2024-11-03 at 22:34 +0300, Konstantin Kharlamov wrote:
> On Sun, 2024-11-03 at 22:07 +0300, Konstantin Kharlamov wrote:
> > On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> > > Ping! Can we please make some progress here?
> > 
> > Hello! Got some spare time, dug into it. Found a few interesting
> > things:
> > 
> > 1. (not really interesting, but…) problem persists in current
> > master
> > 2. The exact function call that causes the problem is `(kill-all-
> > local-
> > variables t)` inside `(work-buffer--release)`. If I remove it,
> > everything works as before.
> > 
> >    I guess this implies that bug is not in David's commit per se,
> > but
> > rather something that's always been present and just got triggered
> > by
> > David's commit.
> > 3. There's an unrelated bug that confused this whole research,
> > since
> > it
> > seemed like the function is never called: dong `M-x debug-on-entry
> > string-pixel-width` does nothing even though `string-pixel-width`
> > is
> > called.
> 
> Great news! I reduced the testcase to just the vanilla Emacs
> functional.
> 
> # The new steps to reproduce
> 
> 1. Run emacs as `./build/src/emacs -Q --eval "(setq-default display-
> line-numbers 'visual)"`
>    
>    A emacs with line numbers turned on should start
> 2. Evaluate `(define-key (make-sparse-keymap) [tab-bar] (lookup-key
> global-map [tab-bar]))`

Even, just `(lookup-key global-map [tab-bar])` is enough.

> ## Expected
> 
> Line numbers are still shown
> 
> ## Actual
> 
> Line numbers disappear

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

On 03/11/2024 8:07 PM, Konstantin Kharlamov wrote:
> On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
>> Ping! Can we please make some progress here?
> 
> Hello! Got some spare time, dug into it. Found a few interesting
> things:
> 
> 1. (not really interesting, but…) problem persists in current master
> 2. The exact function call that causes the problem is `(kill-all-local-
> variables t)` inside `(work-buffer--release)`. If I remove it,
> everything works as before.
> 
>     I guess this implies that bug is not in David's commit per se, but
> rather something that's always been present and just got triggered by
> David's commit.
> 3. There's an unrelated bug that confused this whole research, since it
> seemed like the function is never called: dong `M-x debug-on-entry
> string-pixel-width` does nothing even though `string-pixel-width` is
> called.

Hi Konstantin,

Thank you for your report!  This helped me (sort of) reproduce your issue
which seems to be caused by a side effect of `string-pixel-width' when
setting `display-line-numbers' to nil.

Could you please try the attached patch and tell me if it fixes the issue
for you?

Thanks!
   

[-- Attachment #2: string-pixel-width-line-numbers.patch --]
[-- Type: text/x-patch, Size: 1541 bytes --]

diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
index e5a056e7732..df825bd68c8 100644
--- a/lisp/emacs-lisp/subr-x.el
+++ b/lisp/emacs-lisp/subr-x.el
@@ -400,12 +400,6 @@ string-pixel-width
     ;; Keeping a work buffer around is more efficient than creating a
     ;; new temporary buffer.
     (with-work-buffer
-      ;; If `display-line-numbers' is enabled in internal
-      ;; buffers (e.g. globally), it breaks width calculation
-      ;; (bug#59311).  Disable `line-prefix' and `wrap-prefix',
-      ;; for the same reason.
-      (setq display-line-numbers nil
-            line-prefix nil wrap-prefix nil)
       (if buffer
           (setq-local face-remapping-alist
                       (with-current-buffer buffer
@@ -414,10 +408,17 @@ string-pixel-width
       ;; Avoid deactivating the region as side effect.
       (let (deactivate-mark)
         (insert string))
+      ;; If `display-line-numbers' is enabled in internal
+      ;; buffers (e.g. globally), it breaks width calculation
+      ;; (bug#59311).  Disable `line-prefix' and `wrap-prefix',
+      ;; for the same reason.
+      (add-text-properties
+       (point-min) (point-max) '(display-line-numbers-disable t))
       ;; Prefer `remove-text-properties' to `propertize' to avoid
       ;; creating a new string on each call.
       (remove-text-properties
        (point-min) (point-max) '(line-prefix nil wrap-prefix nil))
+      (setq line-prefix nil wrap-prefix nil)
       (car (buffer-text-pixel-size nil nil t)))))
 
 ;;;###autoload

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Sun, 2024-11-03 at 22:56 +0100, David Ponce wrote:
> On 03/11/2024 8:07 PM, Konstantin Kharlamov wrote:
> > On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> > > Ping! Can we please make some progress here?
> > 
> > Hello! Got some spare time, dug into it. Found a few interesting
> > things:
> > 
> > 1. (not really interesting, but…) problem persists in current
> > master
> > 2. The exact function call that causes the problem is `(kill-all-
> > local-
> > variables t)` inside `(work-buffer--release)`. If I remove it,
> > everything works as before.
> > 
> >     I guess this implies that bug is not in David's commit per se,
> > but
> > rather something that's always been present and just got triggered
> > by
> > David's commit.
> > 3. There's an unrelated bug that confused this whole research,
> > since it
> > seemed like the function is never called: dong `M-x debug-on-entry
> > string-pixel-width` does nothing even though `string-pixel-width`
> > is
> > called.
> 
> Hi Konstantin,
> 
> Thank you for your report!  This helped me (sort of) reproduce your
> issue

Nice! Let me note for the safe case, since you say "sort of", that in
later emails I posted simpler steps to reproduce by just evaluating

	(lookup-key global-map [tab-bar])

> which seems to be caused by a side effect of `string-pixel-width'
> when
> setting `display-line-numbers' to nil.
> 
> Could you please try the attached patch and tell me if it fixes the
> issue
> for you?
> 
> Thanks!

Thank you, I confirm it does fix the bug!

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 04/11/2024 2:05 AM, Konstantin Kharlamov wrote:
> On Sun, 2024-11-03 at 22:56 +0100, David Ponce wrote:
>> On 03/11/2024 8:07 PM, Konstantin Kharlamov wrote:
>>> On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
>>>> Ping! Can we please make some progress here?
>>>
>>> Hello! Got some spare time, dug into it. Found a few interesting
>>> things:
>>>
>>> 1. (not really interesting, but…) problem persists in current
>>> master
>>> 2. The exact function call that causes the problem is `(kill-all-
>>> local-
>>> variables t)` inside `(work-buffer--release)`. If I remove it,
>>> everything works as before.
>>>
>>>      I guess this implies that bug is not in David's commit per se,
>>> but
>>> rather something that's always been present and just got triggered
>>> by
>>> David's commit.
>>> 3. There's an unrelated bug that confused this whole research,
>>> since it
>>> seemed like the function is never called: dong `M-x debug-on-entry
>>> string-pixel-width` does nothing even though `string-pixel-width`
>>> is
>>> called.
>>
>> Hi Konstantin,
>>
>> Thank you for your report!  This helped me (sort of) reproduce your
>> issue
> 
> Nice! Let me note for the safe case, since you say "sort of", that in
> later emails I posted simpler steps to reproduce by just evaluating
> 
> 	(lookup-key global-map [tab-bar])
> 
>> which seems to be caused by a side effect of `string-pixel-width'
>> when
>> setting `display-line-numbers' to nil.
>>
>> Could you please try the attached patch and tell me if it fixes the
>> issue
>> for you?
>>
>> Thanks!
> 
> Thank you, I confirm it does fix the bug!

Thank you!

Hi Eli,

Would you mind to commit this fix? Here is a possible change log:

2024-11-04  David Ponce  <da_vid@orange.fr>

	* subr-x.el (string-pixel-width): Set text property
	`display-line-numbers-disable' instead of changing the
	buffer-local value of `display-line-numbers'.  Fix bug#73005.

Thank you!

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 10:02:22 +0100
> Cc: 73005@debbugs.gnu.org
> From: David Ponce <da_vid@orange.fr>
> 
 Hi Eli,
> 
> Would you mind to commit this fix? Here is a possible change log:
> 
> 2024-11-04  David Ponce  <da_vid@orange.fr>
> 
> 	* subr-x.el (string-pixel-width): Set text property
> 	`display-line-numbers-disable' instead of changing the
> 	buffer-local value of `display-line-numbers'.  Fix bug#73005.

Thanks, I will look into this when I have time.  It isn't urgent.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 04/11/2024 2:13 PM, Eli Zaretskii wrote:
>> Date: Mon, 4 Nov 2024 10:02:22 +0100
>> Cc: 73005@debbugs.gnu.org
>> From: David Ponce <da_vid@orange.fr>
>>
>   Hi Eli,
>>
>> Would you mind to commit this fix? Here is a possible change log:
>>
>> 2024-11-04  David Ponce  <da_vid@orange.fr>
>>
>> 	* subr-x.el (string-pixel-width): Set text property
>> 	`display-line-numbers-disable' instead of changing the
>> 	buffer-local value of `display-line-numbers'.  Fix bug#73005.
> 
> Thanks, I will look into this when I have time.  It isn't urgent.

No problem for me.  At the same time, maybe you can shed some light
on why initializing the local variable `display-line-numbers' in the
work buffer interferes with the setting in other buffer?  I'm probably
missing something in the current implementation.

Thanks you!

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 14:58:09 +0100
> Cc: Hi-Angel@yandex.ru, 73005@debbugs.gnu.org
> From: David Ponce <da_vid@orange.fr>
> 
> >> 2024-11-04  David Ponce  <da_vid@orange.fr>
> >>
> >> 	* subr-x.el (string-pixel-width): Set text property
> >> 	`display-line-numbers-disable' instead of changing the
> >> 	buffer-local value of `display-line-numbers'.  Fix bug#73005.
> > 
> > Thanks, I will look into this when I have time.  It isn't urgent.
> 
> No problem for me.  At the same time, maybe you can shed some light
> on why initializing the local variable `display-line-numbers' in the
> work buffer interferes with the setting in other buffer?  I'm probably
> missing something in the current implementation.

Without looking at the code, my first guess would be that you change
the global default value, not the buffer-local value.  The fact that
you kill-all-local-variables might have something to do with that.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I forgot to reply to all. Sorry.
  
On 04/11/2024 5:38 PM, Eli Zaretskii wrote:
>> Date: Mon, 4 Nov 2024 14:58:09 +0100
>> Cc: Hi-Angel@yandex.ru, 73005@debbugs.gnu.org
>> From: David Ponce <da_vid@orange.fr>
>>
>>>> 2024-11-04  David Ponce  <da_vid@orange.fr>
>>>>
>>>> 	* subr-x.el (string-pixel-width): Set text property
>>>> 	`display-line-numbers-disable' instead of changing the
>>>> 	buffer-local value of `display-line-numbers'.  Fix bug#73005.
>>>
>>> Thanks, I will look into this when I have time.  It isn't urgent.
>>
>> No problem for me.  At the same time, maybe you can shed some light
>> on why initializing the local variable `display-line-numbers' in the
>> work buffer interferes with the setting in other buffer?  I'm probably
>> missing something in the current implementation.
> 
> Without looking at the code, my first guess would be that you change
> the global default value, not the buffer-local value.  The fact that
> you kill-all-local-variables might have something to do with that.

I cannot see where it could happen in the code.

However, I think I have more or less figured out what could be going on.

`display-line-numbers' is a special variable that when changed causes the
current buffer to be redisplayed in the current window (see frame.el from
line 3194).

It seems that, when `string-pixels-width' sets the value of
`display-line-numbers' to nil locally in the working buffer, this triggers
a redisplay of the buffer in the selected window, and the line numbers to
disappear.  When the working buffer is later recycled and local variables
killed, it seems that this does not trigger buffer redisplay, and the line
numbers therefore remain disabled, as observed in the simple recipe provided
by Konstantin.  If you just evaluate (setq display-line-numbers display-line-numbers)
after Konstantin's recipe, the current buffer is redisplayed and the line
numbers appear again, because `string-pixel-width' didn't change the global value
of `display-line-numbers'.

If I modify `string-pixel-width' to add
`(setq display-line-numbers display-line-numbers)' before to return the result,
line numbers are not deactivated:

(defun string-pixel-width (string &optional buffer)
   "Return the width of STRING in pixels.
If BUFFER is non-nil, use the face remappings from that buffer when
determining the width.
If you call this function to measure pixel width of a string
with embedded newlines, it returns the width of the widest
substring that does not include newlines."
   (declare (important-return-value t))
   (if (zerop (length string))
       0
     ;; Keeping a work buffer around is more efficient than creating a
     ;; new temporary buffer.
     (prog1
         (with-work-buffer
       ;; If `display-line-numbers' is enabled in internal
       ;; buffers (e.g. globally), it breaks width calculation
       ;; (bug#59311).  Disable `line-prefix' and `wrap-prefix',
       ;; for the same reason.
       (setq display-line-numbers nil
             line-prefix nil wrap-prefix nil)
       (if buffer
           (setq-local face-remapping-alist
                       (with-current-buffer buffer
                         face-remapping-alist))
         (kill-local-variable 'face-remapping-alist))
       ;; Avoid deactivating the region as side effect.
       (let (deactivate-mark)
         (insert string))
       ;; Prefer `remove-text-properties' to `propertize' to avoid
       ;; creating a new string on each call.
       (remove-text-properties
        (point-min) (point-max) '(line-prefix nil wrap-prefix nil))
       (car (buffer-text-pixel-size nil nil t)))
       (setq display-line-numbers display-line-numbers))))

However, using the `display-line-numbers-disable' property to temporarily
disable line numbers in `string-pixels-width', without involving redisplay,
seems a better approach to me.

Regarding Konstantin recipe, `string-pixel-width' is called by `tab-bar-auto-width'
when (lookup-key global-map [tab-bar]) is evaluated.

Thanks

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Mon, 2024-11-04 at 20:39 +0100, David Ponce wrote:
> I forgot to reply to all. Sorry.
>   
> On 04/11/2024 5:38 PM, Eli Zaretskii wrote:
> > > Date: Mon, 4 Nov 2024 14:58:09 +0100
> > > Cc: Hi-Angel@yandex.ru, 73005@debbugs.gnu.org
> > > From: David Ponce <da_vid@orange.fr>
> > > 
> > > > > 2024-11-04  David Ponce  <da_vid@orange.fr>
> > > > > 
> > > > > 	* subr-x.el (string-pixel-width): Set text property
> > > > > 	`display-line-numbers-disable' instead of changing
> > > > > the
> > > > > 	buffer-local value of `display-line-numbers'.  Fix
> > > > > bug#73005.
> > > > 
> > > > Thanks, I will look into this when I have time.  It isn't
> > > > urgent.
> > > 
> > > No problem for me.  At the same time, maybe you can shed some
> > > light
> > > on why initializing the local variable `display-line-numbers' in
> > > the
> > > work buffer interferes with the setting in other buffer?  I'm
> > > probably
> > > missing something in the current implementation.
> > 
> > Without looking at the code, my first guess would be that you
> > change
> > the global default value, not the buffer-local value.  The fact
> > that
> > you kill-all-local-variables might have something to do with that.
> 
> I cannot see where it could happen in the code.
> 
> However, I think I have more or less figured out what could be going
> on.
> 
> `display-line-numbers' is a special variable that when changed causes
> the
> current buffer to be redisplayed in the current window (see frame.el
> from
> line 3194).
> 
> It seems that, when `string-pixels-width' sets the value of
> `display-line-numbers' to nil locally in the working buffer, this
> triggers
> a redisplay of the buffer in the selected window, and the line
> numbers to
> disappear.  When the working buffer is later recycled and local
> variables
> killed, it seems that this does not trigger buffer redisplay, and the
> line
> numbers therefore remain disabled, as observed in the simple recipe
> provided
> by Konstantin.

Thank you, great research! But note that problem is not triggered by
setting `display-line-numbers` to nil (even though it's part of the
equation). Instead it is triggered specifically by (kill-all-local-
variables), and removing this call makes problem go away.

>   If you just evaluate (setq display-line-numbers display-line-
> numbers)
> after Konstantin's recipe, the current buffer is redisplayed and the
> line
> numbers appear again, because `string-pixel-width' didn't change the
> global value
> of `display-line-numbers'.

A more curious way to get line numbers is evaluating just `display-
line-numbers`, i.e. without any modification.

> If I modify `string-pixel-width' to add
> `(setq display-line-numbers display-line-numbers)' before to return
> the result,
> line numbers are not deactivated:
> 
> (defun string-pixel-width (string &optional buffer)
>    "Return the width of STRING in pixels.
> If BUFFER is non-nil, use the face remappings from that buffer when
> determining the width.
> If you call this function to measure pixel width of a string
> with embedded newlines, it returns the width of the widest
> substring that does not include newlines."
>    (declare (important-return-value t))
>    (if (zerop (length string))
>        0
>      ;; Keeping a work buffer around is more efficient than creating
> a
>      ;; new temporary buffer.
>      (prog1
>          (with-work-buffer
>        ;; If `display-line-numbers' is enabled in internal
>        ;; buffers (e.g. globally), it breaks width calculation
>        ;; (bug#59311).  Disable `line-prefix' and `wrap-prefix',
>        ;; for the same reason.
>        (setq display-line-numbers nil
>              line-prefix nil wrap-prefix nil)
>        (if buffer
>            (setq-local face-remapping-alist
>                        (with-current-buffer buffer
>                          face-remapping-alist))
>          (kill-local-variable 'face-remapping-alist))
>        ;; Avoid deactivating the region as side effect.
>        (let (deactivate-mark)
>          (insert string))
>        ;; Prefer `remove-text-properties' to `propertize' to avoid
>        ;; creating a new string on each call.
>        (remove-text-properties
>         (point-min) (point-max) '(line-prefix nil wrap-prefix nil))
>        (car (buffer-text-pixel-size nil nil t)))
>        (setq display-line-numbers display-line-numbers))))
> 
> However, using the `display-line-numbers-disable' property to
> temporarily
> disable line numbers in `string-pixels-width', without involving
> redisplay,
> seems a better approach to me.
> 
> Regarding Konstantin recipe, `string-pixel-width' is called by `tab-
> bar-auto-width'
> when (lookup-key global-map [tab-bar]) is evaluated.
> 
> Thanks

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Mon, 2024-11-04 at 22:50 +0300, Konstantin Kharlamov wrote:
> A more curious way to get line numbers is evaluating just `display-
> line-numbers`, i.e. without any modification.

s/to get line numbers/to get line numbers back

Sorry, I was re-editing this sentence and screwed it up 😅

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 04/11/2024 8:53 PM, Konstantin Kharlamov wrote:
> On Mon, 2024-11-04 at 22:50 +0300, Konstantin Kharlamov wrote:
>> A more curious way to get line numbers is evaluating just `display-
>> line-numbers`, i.e. without any modification.
> 
> s/to get line numbers/to get line numbers back
> 
> Sorry, I was re-editing this sentence and screwed it up 😅

It seems the problem is the non-nil argument passed to
`kill-all-local-variables' to also kill permanent local variables:

Here is a minimal recipe:

emacs -Q --eval "(setq-default display-line-numbers 'visual)"

Then evaluate in the *scratch* buffer:

(with-temp-buffer
   (setq-local display-line-numbers nil)
   (kill-all-local-variables t))

==> Line numbers disappear.

emacs -Q --eval "(setq-default display-line-numbers 'visual)"

Then evaluate in the *scratch* buffer:

(with-temp-buffer
   (setq-local display-line-numbers nil)
   (kill-all-local-variables))

==> Line numbers don't change.

No idea why.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 04/11/2024 9:08 PM, David Ponce wrote:
> On 04/11/2024 8:53 PM, Konstantin Kharlamov wrote:
>> On Mon, 2024-11-04 at 22:50 +0300, Konstantin Kharlamov wrote:
>>> A more curious way to get line numbers is evaluating just `display-
>>> line-numbers`, i.e. without any modification.
>>
>> s/to get line numbers/to get line numbers back
>>
>> Sorry, I was re-editing this sentence and screwed it up 😅
> 
> It seems the problem is the non-nil argument passed to
> `kill-all-local-variables' to also kill permanent local variables:
> 
> Here is a minimal recipe:
> 
> emacs -Q --eval "(setq-default display-line-numbers 'visual)"
> 
> Then evaluate in the *scratch* buffer:
> 
> (with-temp-buffer
>    (setq-local display-line-numbers nil)
>    (kill-all-local-variables t))
> 
> ==> Line numbers disappear.
> 
> emacs -Q --eval "(setq-default display-line-numbers 'visual)"
> 
> Then evaluate in the *scratch* buffer:
> 
> (with-temp-buffer
>    (setq-local display-line-numbers nil)
>    (kill-all-local-variables))
> 
> ==> Line numbers don't change.
> 
> No idea why.

I looked at the C code of `kill-all-local-variables' in buffer.c.
This function calls `reset_buffer_local_variables' to do the actual
work of killing local variables.  As far as I can see in the
implementation, when this function is invoked with a true argument to
also kill permanent local variables, it just clears the list of local
variable for the passed buffer.  On the contrary, when called with a
false argument to keep permanent local variables, more things are
done, like triggering variables watchers for example. This might
explain why `(kill-all-local-variables)' and
`(kill-all-local-variables t)' have different side effects on
`display-line-numbers'.

Based on the above analyze, a possible workaround in
`work-buffer--release' could be to call first
(kill-all-local-variables), then (kill-all-local-variables t), like
this:

(defun work-buffer--release (buffer)
   "Release work BUFFER."
   (if (buffer-live-p buffer)
       (with-current-buffer buffer
         ;; Flush BUFFER before making it available again, i.e. clear
         ;; its contents, remove all overlays and buffer-local
         ;; variables.  Is it enough to safely reuse the buffer?
         (let ((inhibit-read-only t)
               ;; Avoid deactivating the region as side effect.
               deactivate-mark)
           (erase-buffer))
         (delete-all-overlays)
         (let (change-major-mode-hook)
           (kill-all-local-variables) ;; Workaround bug#73005
           (kill-all-local-variables t))
         ;; Make the buffer available again.
         (push buffer work-buffer--list)))
   ;; If the maximum number of reusable work buffers is exceeded, kill
   ;; work buffer in excess, taking into account that the limit could
   ;; have been let-bound to temporarily increase its value.
   (when (> (length work-buffer--list) work-buffer-limit)
     (mapc #'kill-buffer (nthcdr work-buffer-limit work-buffer--list))
     (setq work-buffer--list (ntake work-buffer-limit work-buffer--list))))

If my understanding of the C code is correct, the extra cost of the
second call to `kill-all-local-variable' should be negligible.

I did test the above version of `work-buffer--release' which seems to
fix the issue with setting `display-line-numbers' in
`string-pixel-width', using Konstantin recipe.

Depending on what solution is preferred, I could prepare a patch
accordingly.

Thanks!

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 10:02:22 +0100
> Cc: 73005@debbugs.gnu.org
> From: David Ponce <da_vid@orange.fr>
> 
> On 04/11/2024 2:05 AM, Konstantin Kharlamov wrote:
> > On Sun, 2024-11-03 at 22:56 +0100, David Ponce wrote:
> >> On 03/11/2024 8:07 PM, Konstantin Kharlamov wrote:
> >>> On Sat, 2024-09-21 at 12:02 +0300, Eli Zaretskii wrote:
> >>>> Ping! Can we please make some progress here?
> >>>
> >>> Hello! Got some spare time, dug into it. Found a few interesting
> >>> things:
> >>>
> >>> 1. (not really interesting, but…) problem persists in current
> >>> master
> >>> 2. The exact function call that causes the problem is `(kill-all-
> >>> local-
> >>> variables t)` inside `(work-buffer--release)`. If I remove it,
> >>> everything works as before.
> >>>
> >>>      I guess this implies that bug is not in David's commit per se,
> >>> but
> >>> rather something that's always been present and just got triggered
> >>> by
> >>> David's commit.
> >>> 3. There's an unrelated bug that confused this whole research,
> >>> since it
> >>> seemed like the function is never called: dong `M-x debug-on-entry
> >>> string-pixel-width` does nothing even though `string-pixel-width`
> >>> is
> >>> called.
> >>
> >> Hi Konstantin,
> >>
> >> Thank you for your report!  This helped me (sort of) reproduce your
> >> issue
> > 
> > Nice! Let me note for the safe case, since you say "sort of", that in
> > later emails I posted simpler steps to reproduce by just evaluating
> > 
> > 	(lookup-key global-map [tab-bar])
> > 
> >> which seems to be caused by a side effect of `string-pixel-width'
> >> when
> >> setting `display-line-numbers' to nil.
> >>
> >> Could you please try the attached patch and tell me if it fixes the
> >> issue
> >> for you?
> >>
> >> Thanks!
> > 
> > Thank you, I confirm it does fix the bug!
> 
> Thank you!
> 
> Hi Eli,
> 
> Would you mind to commit this fix? Here is a possible change log:
> 
> 2024-11-04  David Ponce  <da_vid@orange.fr>
> 
> 	* subr-x.el (string-pixel-width): Set text property
> 	`display-line-numbers-disable' instead of changing the
> 	buffer-local value of `display-line-numbers'.  Fix bug#73005.
> 
> Thank you!

Thanks, installed on the master branch, and closing the bug.

bug#73005: [REGRESSION, BISECTED]: line numbers disappear when pressing `df` in evil-mode

[Konstantin Kharlamov]

On Tue, 2024-09-03 at 18:30 +0300, Eli Zaretskii wrote:   
> > The commit that introduced the problem:
> >    
> >    commit dffdbc1f1fd6569c518e2e3b5e771a54e9e9483f (HEAD)
> >    Author: David Ponce <da_vid@orange.fr>
> >    Date:   Thu Aug 22 16:56:11 2024 +0200
> >    
> >        Use 'with-work-macro' in 'string-pixel-width'
> 
> Does it help to replace
> 
>    (setq display-line-numbers nil
> 
> with
> 
>    (setq-local display-line-numbers nil
> 
> in string-pixel-width?

Sorry, I forgot to reply here. No, it doesn't change anything.