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 <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> valign relies on disabling modification hooks because it is otherwise
>> difficult to figure out pixel width of a string in current buffer:
>> https://github.com/casouri/valign/issues/30
>
> 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.

The most accurate way to measure the real string width inside current
buffer is actually inserting it and requesting the measurement.

Best,
Ihor