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>]

Eli Zaretskii [2022-06-17 08:36:37] wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  51766@debbugs.gnu.org
>> Date: Thu, 16 Jun 2022 22:54:22 -0400
>> 
>> 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.
>
> I thought that was clear from the rest of the discussion: it's quail's
> input methods that cause the issue, because quail tries to pretend
> that just one character was inserted, when in fact the user could type
> several characters.

AFAIK in the case of Quail the char-modified-ticks changes (so there's
some insertions/deletions going on) while `inhibit-modification-hooks`
is set, but the state of the buffer at the next
`before-change-functions` is correct, e.g. the buffer-hash is unchanged.

IOW in the cse of Quail the Org mode code doesn't need to flush the
whole parser's state, which means that the code that flushes the parser
state when char-modified-ticks is modified silently was written to
defend against *other* problems.


        Stefan