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 <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 51766@debbugs.gnu.org
> Date: Sat, 13 Nov 2021 19:29:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (let ((inhibit-modification-hooks t))
> >>   (insert "Insertion that will never trigger before/after-change-functions"))
> >
> > So the problem is that Org uses the modification hooks as the primary
> > mechanism (with which quail presents no problem), and
> > buffer-chars-modified-tick as the fallback, and that when some code
> > inhibits the modification hooks, then the primary mechanism cannot
> > work and quail breaks the fallback?
> 
> 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?

> >> The quail's insertion+deletion itself is not a problem for Org cache -
> >> it does not really alter the buffer text and cannot break the cache. The
> >> problem is that it cannot be distinguished from the first example - both
> >> cases will trigger buffer-chars-modified-tick increase.
> >
> > You didn't answer my question regarding buffer-modified-tick: it can
> > explain to Org why buffer-chars-modified-tick jumped unexpectedly, and
> > thus (hopefully) resolve this situation.  If that helps, you could
> > perhaps turn the table and use buffer-chars-modified-tick is the
> > primary method of discovering changes, not as fallback.
> > ...
> >> The only assumption I had it that Emacs does not frequently change
> >> buffer text without triggering modification hooks. Clearly, the
> >> assumption was wrong.
> >
> > I meant the assumptions about what buffer-chars-modified-tick does and
> > what its value means.
> 
> 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?

> Even if Org used the value of buffer-chars-modified-tick, it would not
> be useful. There is no information about buffer region where the edits
> happened if we just look at buffer-chars-modified-tick. AFAIK, only
> after-change-functions have access to the changed region bounds.

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

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

> > The Emacs code related to tree-sitter already uses change indications,
> > and AFAIR didn't require any changes to the existing infrastructure.
> > I wonder why Org cannot settle with what we have, if your needs are
> > similar enough to those of tree-sitter.
> 
> I just checked https://github.com/casouri/emacs/blob/ts/src/insdel.c
> That ts Emacs branch directly modifies C-level Emacs buffer editing
> primitives (see the calls to ts_record_change). So, it is not affected
> by inhibit-modification-hooks.

That's what I meant by "existing infrastructure".