GNU bug report logs - #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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> gmail.com>

Date: Thu, 11 Nov 2021 13:56:01 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 51766 <at> debbugs.gnu.org
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
> (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





This bug report was last modified 3 years and 48 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.