GNU bug report logs -
#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
Previous Next
Full log
Message #83 received at 51766 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca, 51766 <at> debbugs.gnu.org
> Date: Tue, 21 Jun 2022 19:00:34 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> > That discussion is very short and lacking in detail, but up front, why
> >> > doesn't valign use the primitives we provide for determining the pixel
> >> > width of a string?
> >>
> >> 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?
> 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.
This bug report was last modified 3 years and 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.