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 #80 received at 51766 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51766 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 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 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.

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.

Best,
Ihor

Previous Next

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