GNU bug report logs -
#67248
30.0.50; string-pixel-width is affected by the global value of display-line-numbers
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Fri, 17 Nov 2023 21:25:02 UTC
Severity: normal
Found in version 30.0.50
Fixed in version 29.2
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 67248 in the body.
You can then email your comments to 67248 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#67248
; Package
emacs
.
(Fri, 17 Nov 2023 21:25:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 17 Nov 2023 21:25:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
1. (string-pixel-width "abc") ; => 51
2. (customize-set-variable 'display-line-numbers t)
3. (string-pixel-width "abc") ; => 119
This function's implementation makes provision for
display-line-numbers-mode, but not for the original variable
display-line-numbers, which will be t independent of the value of
display-line-numbers-mode.
I think it's a bad idea to have these two different ways to do the same
thing, and it can lead to bugs like this one. I would suggest obsoleting
the public use of display-line-numbers -- making it private, probably.
At least removing it from the customization group display-line-numbers.
Barring that, the patch below seems to work. Although it proliferates
the differences between Emacs versions which one would have to be on the
lookout for.
Originally reported at
https://github.com/company-mode/company-mode/issues/1427.
diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
index 572822351b1..4fda98ae3d0 100644
--- a/lisp/emacs-lisp/subr-x.el
+++ b/lisp/emacs-lisp/subr-x.el
@@ -343,8 +343,7 @@ string-pixel-width
(with-current-buffer (get-buffer-create " *string-pixel-width*")
;; If `display-line-numbers-mode' is enabled in internal
;; buffers, it breaks width calculation, so disable it (bug#59311)
- (when (bound-and-true-p display-line-numbers-mode)
- (display-line-numbers-mode -1))
+ (setq-local display-line-numbers nil)
(delete-region (point-min) (point-max))
;; Disable line-prefix and wrap-prefix, for the same reason.
(setq line-prefix nil
In GNU Emacs 30.0.50 (build 271, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0) of 2023-11-17 built on potemkin
Repository revision: 94849ba35f40393362050b5937578dcf3076b4bf
Repository branch: feature/cl-lib-improvements
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.10
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#67248
; Package
emacs
.
(Sat, 18 Nov 2023 07:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 67248 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 17 Nov 2023 23:23:58 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
>
> 1. (string-pixel-width "abc") ; => 51
> 2. (customize-set-variable 'display-line-numbers t)
> 3. (string-pixel-width "abc") ; => 119
>
> This function's implementation makes provision for
> display-line-numbers-mode, but not for the original variable
> display-line-numbers, which will be t independent of the value of
> display-line-numbers-mode.
>
> I think it's a bad idea to have these two different ways to do the same
> thing, and it can lead to bugs like this one. I would suggest obsoleting
> the public use of display-line-numbers -- making it private, probably.
> At least removing it from the customization group display-line-numbers.
I don't see a need for such drastic measures, certainly not due to
this bug. Having the variable and the mode in this case is not
different from other similar cases, for example, word-wrap vs
visual-line-mode. You have just discovered that the test in
string-pixel-width was not the correct one, that's all.
> Barring that, the patch below seems to work. Although it proliferates
> the differences between Emacs versions which one would have to be on the
> lookout for.
Thanks, I think this is indeed the right solution. Please install the
patch on the emacs-29 branch.
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
You have taken responsibility.
(Sat, 18 Nov 2023 16:37:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
bug acknowledged by developer.
(Sat, 18 Nov 2023 16:37:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 67248-done <at> debbugs.gnu.org (full text, mbox):
Version: 29.2
On 18/11/2023 09:14, Eli Zaretskii wrote:
> I don't see a need for such drastic measures, certainly not due to
> this bug. Having the variable and the mode in this case is not
> different from other similar cases, for example, word-wrap vs
> visual-line-mode.
At least word-wrap and visual-line-mode have different names. And the
latter provides a bunch of other features than the former.
display-line-numbers and display-line-numbers-mode sound totally
identical, so I'm not at all surprised that the author of the referenced
bug report customized both of them. That's a usability problem.
> Thanks, I think this is indeed the right solution. Please install the
patch on the emacs-29 branch.
Okay, pushed as 0128495afde. Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 17 Dec 2023 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 146 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.