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]

> (let ((inhibit-modification-hooks t))
>   (insert "Insertion that will never trigger before/after-change-functions"))

This is a severely broken piece of code.  I don't think anyone should
try and handle this in any other way than by screaming bloody murder
when it detects the consequences.

> (defun org-element--after-change-function (...)
>  (setq org-element-chars-modified-tick (buffer-chars-modified-tick))
>  (org-element-cache-submit-request ...))
>
> (defun org-element--before-change-function (...)
>  (unless (eq org-element-chars-modified-tick (buffer-chars-modified-tick))
>      ;; Buffer has been changed without calling after-change-function
>      ;; and we have no way to determine which part of buffer has been changed.
>  ))

So this `unless` is intended to detect the case where we should scream
bloody murder, right?

Why do you need it?  AFAICT it should only be needed for debugging
purposes until the offender is found and shamed publicly.
[ I have a weird feeling that I might be one of the offenders.  ]

> Ideally, a way to track _all_ buffer modifications regardless of
> inhibit-modification-hooks would be useful.

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.


        Stefan