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 #89 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 15:47:24 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  51766 <at> 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?

Previous Next

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