From: Ihor Radchenko <yantar92@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 51766@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#51766: string-pixel-width limitations (was: bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods)
Date: Tue, 21 Jun 2022 20:39:10 +0800 [thread overview]
Message-ID: <87a6a6qjgx.fsf@localhost> (raw)
In-Reply-To: <834k0eky7h.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> >> Because string width in different buffers may be different depending on
>> >> the fontification, frame font size, face remapping,
>> >> wrap-prefix/line-prefix string properties (AFAIK, the built-in
>> >> string-pixel-width will return incorrect value on string with such
>> >> properties), invisibility specs in the buffer, line numbers mode, etc
>> >> We have implemented a number of workarounds in org-string-width on main,
>> >> but I am not 100% sure that I covered all the edge cases.
>> >
>> > If you need such high accuracy, may I suggest window-text-pixel-size?
>>
>> window-text-pixel-size suffers from the same issues with
>> wrap-prefix/line-prefix and line numbers mode.
>
> What issue are those?
The length of line-prefix is added to the return value of
window-text-pixel-size, which makes it wrong when the intention is
measuring the actual string width.
Not that window-text-pixel-size is misbehaving here - line-prefix does
need to be included if the intention is to query the actual full width
of text in buffer. The same goes for line numbers mode - line numbers
are a part of window size.
However, using window-text-pixel-size becomes awkward as the means to
measure expected string width when it is going to be inserted into
current buffer.
>> Also, in order to use it in current buffer on not-yet-inserted string,
>> you need to insert it. That where the issue in valign originated from.
>
> The usual method is to use a temporary buffer.
Yes, and it is not accurate because temporary buffer may not have the
same local environment for face remapping, invisibility specs,
char-property-alias, etc
To show all the trickery, let me share org-string-width I had to
implement for the purposes of Org mode. I did not want this function to
be complex and every single extra LOC there is fixing some edge case,
test failure, or bug report:
(defun org-string-width (string &optional pixels)
"Return width of STRING when displayed in the current buffer.
Return width in pixels when PIXELS is non-nil."
(if (and (version< emacs-version "28") (not pixels))
;; FIXME: Fallback to old limited version, because
;; `window-pixel-width' is buggy in older Emacs.
(org--string-width-1 string)
;; Wrap/line prefix will make `window-text-pizel-size' return too
;; large value including the prefix.
(remove-text-properties 0 (length string)
'(wrap-prefix t line-prefix t)
string)
;; Face should be removed to make sure that all the string symbols
;; are using default face with constant width. Constant char width
;; is critical to get right string width from pixel width (not needed
;; when PIXELS are requested though).
(unless pixels
(remove-text-properties 0 (length string) '(face t) string))
(let (;; We need to remove the folds to make sure that folded table
;; alignment is not messed up.
(current-invisibility-spec
(or (and (not (listp buffer-invisibility-spec))
buffer-invisibility-spec)
(let (result)
(dolist (el buffer-invisibility-spec)
(unless (or (memq el
'(org-fold-drawer
org-fold-block
org-fold-outline))
(and (listp el)
(memq (car el)
'(org-fold-drawer
org-fold-block
org-fold-outline))))
(push el result)))
result)))
(current-char-property-alias-alist char-property-alias-alist))
(with-temp-buffer
(setq-local display-line-numbers nil)
(setq-local buffer-invisibility-spec
(if (listp current-invisibility-spec)
(mapcar (lambda (el)
;; Consider elipsis to have 0 width.
;; It is what Emacs 28+ does, but we have
;; to force it in earlier Emacs versions.
(if (and (consp el) (cdr el))
(list (car el))
el))
current-invisibility-spec)
current-invisibility-spec))
(setq-local char-property-alias-alist
current-char-property-alias-alist)
(let (pixel-width symbol-width)
(with-silent-modifications
(setf (buffer-string) string)
(setq pixel-width
(if (get-buffer-window (current-buffer))
(car (window-text-pixel-size
nil (line-beginning-position) (point-max)))
(set-window-buffer nil (current-buffer))
(car (window-text-pixel-size
nil (line-beginning-position) (point-max)))))
(unless pixels
(setf (buffer-string) "a")
(setq symbol-width
(if (get-buffer-window (current-buffer))
(car (window-text-pixel-size
nil (line-beginning-position) (point-max)))
(set-window-buffer nil (current-buffer))
(car (window-text-pixel-size
nil (line-beginning-position) (point-max)))))))
(if pixels
pixel-width
(/ pixel-width symbol-width)))))))
Best,
Ihor
next prev parent reply other threads:[~2022-06-21 12:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 13:56 bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods Ihor Radchenko
2021-11-11 15:19 ` Eli Zaretskii
2021-11-11 15:50 ` Ihor Radchenko
2021-11-11 17:35 ` Eli Zaretskii
2021-11-12 12:06 ` Ihor Radchenko
2021-11-12 12:15 ` Eli Zaretskii
2021-11-12 12:53 ` Ihor Radchenko
2021-11-12 13:09 ` Eli Zaretskii
2021-11-12 13:39 ` Ihor Radchenko
2021-11-12 15:17 ` Eli Zaretskii
2021-11-13 9:10 ` Ihor Radchenko
2021-11-13 10:11 ` Eli Zaretskii
2021-11-13 11:29 ` Ihor Radchenko
2021-11-13 13:38 ` Eli Zaretskii
2021-11-13 14:43 ` Ihor Radchenko
2021-11-13 15:24 ` Eli Zaretskii
2022-06-17 2:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17 5:36 ` Eli Zaretskii
2022-06-17 13:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17 10:05 ` Ihor Radchenko
2022-06-17 10:50 ` Eli Zaretskii
2022-06-21 4:13 ` bug#51766: string-pixel-width limitations (was: bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods) Ihor Radchenko
2022-06-21 10:16 ` Eli Zaretskii
2022-06-21 11:00 ` Ihor Radchenko
2022-06-21 12:17 ` Eli Zaretskii
2022-06-21 12:39 ` Ihor Radchenko [this message]
2022-06-21 12:47 ` Eli Zaretskii
2022-06-21 13:03 ` Ihor Radchenko
2022-06-22 23:49 ` bug#51766: string-pixel-width limitations Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-17 13:28 ` bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-21 4:14 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6a6qjgx.fsf@localhost \
--to=yantar92@gmail.com \
--cc=51766@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).