|
From: | Stefan Monnier |
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: | Thu, 16 Jun 2022 22:54:22 -0400 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> (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
[Prev in Thread] | Current Thread | [Next in Thread] |