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]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 51766@debbugs.gnu.org
> Date: Sat, 13 Nov 2021 22:43:17 +0800
> 
> > But if buffer-modified-tick completely explains the change in
> > buffer-chars-modified-tick, you can conclude that
> > buffer-chars-modified-tick didn't change for your purposes, and then
> > all's well, no?
> 
> I looked into it again and tried to play with non-cyrillic input looking
> at the values of buffer-chars-modified-tick and buffer-modified-tick.
> You are right, there seems to be a special relation between the values
> when I use non-latin input method
> (buffer-chars-modified-tick=buffer-modified-tick). Thanks!

That's what the implementation does: it copies the value from the
latter to the former.

> However, I am not sure if equality of the chars-modified-tick and
> modified-tick is unique to non-changing edits. Can test in the wild
> though.

I'd be surprised if the relation were violated.  But weirder things
have happened, so...

> > Then maybe this is the missing infrastructure you'd like to see
> > implemented.
> 
> Yes, I think. In practical terms, it may something like a new pair of
> hooks: before/after-change-no-inhibit-functions. The hooks work exactly
> like before/after-change-functions, but cannot be suppressed by
> let-binding inhibit-modification-hooks and
> before/after-change-functions. If necessary they can still be explicitly
> let-bound to nil, but it should be discouraged. WDYT?

Something like that, yes.  Just with shorter names ;-)