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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
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 13:16:28 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  51766 <at> debbugs.gnu.org
> Date: Tue, 21 Jun 2022 12:13:09 +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?

Previous Next

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