[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes w

From: Eli Zaretskii
Subject: 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
Date: Fri, 12 Nov 2021 15:09:15 +0200

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 51766@debbugs.gnu.org
> Date: Fri, 12 Nov 2021 20:53:33 +0800
> The control code makes sure that all the changes made in buffer are
> processed by org-element-cache. It means that
> org-element--after-change-function saves the buffer-chars-modified-tick
> and the next org-element--before-change-function checks if the saved
> value is unchanged. If the saved value is changed, the buffer has been
> changed after org-element--after-change-function, but before next
> org-element--before-change-function. Such change may be arbitrary and
> the whole cache is potentially obsolete.
> In code, the described roughly looks like:
> (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.
>  ))
> quail changes the buffer after org-element--after-change-function call,
> but before org-element--before-change-function. So, all Org can see is
> that something has been changed in buffer, but there is no way to tell
> what it was. Org cannot distinguish between harmless buffer edits by
> quail (they do not change buffer text) and other kinds of "silent"
> changes.

OK, but why does this invalidate what Org does?  All it means, AFAIU,
is that in some cases Org will do unnecessary processing.  Those cases
are probably not too frequent.

IOW, why invalidating the cache unnecessarily is such a big deal?

> > I don't understand this, either.  Are you saying that inserting a
> > character via an input method doesn't call buffer-modification hooks
> > even once?  If the hooks are called, then what exactly is the problem
> > with the hooks in this scenario?
> The hooks are called, but after quail already triggered
> buffer-chars-modified-tick increase. If quail called
> before-change-functions before buffer-chars-modified-tick increases, it
> would be useful for my scenario. Though I am not sure how feasible it
> is. Just an idea.

Would it help if Org looked at both buffer-modified-tick and

reply via email to

[Prev in Thread] Current Thread [Next in Thread]