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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Not exactly. Org uses modification hooks as the only mechanism to
>> process buffer changes because Org needs to know the region where the
>> buffer text changes. buffer-chars-modified-tick is used for error
>> detection - when buffer text is changed, but Org modification hooks are
>> not called for some reason. quail triggers false positives during the error
>> detection.
>
> Is that any different from what I said, which is that you need error
> detection only when the modification hooks are not called?  And that
> the quail behavior is only the issue when using this error detection,
> i.e. when the modification hooks are not called?

Your understanding is correct.

>> It seems that we have some misunderstanding here. Org does not care
>> about the value of buffer-chars-modified-tick - just whether
>> buffer-chars-modified-tick is changed or not (see the above).
>
> 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!

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.

> So what does Org do if the modification hooks were not called, and
> buffer-chars-modified-tick says the text was changed?

The cache is potentially invalid, so it is dropped altogether by
org-element-cache-reset.

>> > But Org is not interested in just any moidification, AFAIU.  It is
>> > only interested in modifications that change the buffer text.  Isn't
>> > that true?  Or what else is Org interested in for this purpose.
>> 
>> You are right. Org is interested in modifications that change buffer
>> text. Also, Org is interested to be not affected by
>> inhibit-modification-hooks.
>
> 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?

Best,
Ihor