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)

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: monnier@iro.umontreal.ca,  51766@debbugs.gnu.org
> Date: Tue, 21 Jun 2022 20:39:10 +0800
> 
> >> > 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?
> [...]
> 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:

Ah, so you do use window-text-pixel-size...  Then we are in violent
agreement.

Anyway, the beginning of this sub-thread, specifically about valign,
was in the context of Lisp programs that do buffer modifications under
with-silent-modifications or equivalent, and valign seems to do that
because it just needs to measure the pixel width of a string, and it
does that by inserting the string and then removing it.  So in that
case, the "buffer modifications" are indeed null and void, and Org
shouldn't be bothered by such "modifications", because the buffer
really remains unmodified.  Right?