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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> Well.  This was also my assumption.  I initially implemented the checking
> code to detect internal errors in Org.
>
> Then we received 12 bug reports on this. The offenders were identified
> in some cases. They were:
> - polymode, valign, and ox-hugo
> - Doom (unrelated to this particular issue, but Doom is let-binding major-mode...)
> - Emacs quail and also replace-match in some cases (because of
>   false-positives caused by changing buffer-chars-modified-tick)

IIUC Quail and replace-match shouldn't be in the above list: they're
caught by your debugging check but they're false positives.

> 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

AFAIK this is *also* a false positive: the buffer is only temporarily
modified within the `with-silent-modifications` and reverted to its
previous state before the end of that macro, so there's no need to flush
your parser's state.

>> I don't think this *can* exist: if we add a mechanism which ignores
>> `inhibit-modification-hooks` it will still need some way to ignore some
>> changes so we'll need another `inhibit-<foo>` variable to "silence"
>> those changes and we'll be back at square one.
>>
>> I think the better way to proceed is to figure out why/when
>> significant changes are made while `inhibit-modification-hooks` is
>> non-nil, since that's the origin of your problems, AFAICT.
>
> See the above. There is real-world code doing things that make
> Emacs ignore after-change-functions.

I don't see how this relates to what I'm saying: what I'm saying is that
for the same reason there's code that has very valid reasons to inhibit
`after-change-functions`, there will be code that has very valid reasons
to inhibit some new `after-really-every-change-functions`, and then
there will inevitably also be code that abuses this.

The only real solution is to "push back" and get those abuses fixed.

One thing you could do, for example is replace your char-modified-tick
check with one based on buffer-size: it won't catch all cases, but it
won't suffer from false positives, so you can really scream bloody
murder when it happens.


        Stefan