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

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: Fri, 17 Jun 2022 09:28:21 -0400

> Well.  This was also my assumption.  I initially implemented the checking
> code to detect internal errors in Org.
>
> Then we received 12 bug reports on this. The offenders were identified
> in some cases. They were:
> - polymode, valign, and ox-hugo
> - Doom (unrelated to this particular issue, but Doom is let-binding major-mode...)
> - Emacs quail and also replace-match in some cases (because of
>   false-positives caused by changing buffer-chars-modified-tick)

IIUC Quail and replace-match shouldn't be in the above list: they're
caught by your debugging check but they're false positives.

> valign relies on disabling modification hooks because it is otherwise
> difficult to figure out pixel width of a string in current buffer:
> https://github.com/casouri/valign/issues/30

AFAIK this is *also* a false positive: the buffer is only temporarily
modified within the `with-silent-modifications` and reverted to its
previous state before the end of that macro, so there's no need to flush
your parser's state.

>> 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.
>
> See the above. There is real-world code doing things that make
> Emacs ignore after-change-functions.

I don't see how this relates to what I'm saying: what I'm saying is that
for the same reason there's code that has very valid reasons to inhibit
`after-change-functions`, there will be code that has very valid reasons
to inhibit some new `after-really-every-change-functions`, and then
there will inevitably also be code that abuses this.

The only real solution is to "push back" and get those abuses fixed.

One thing you could do, for example is replace your char-modified-tick
check with one based on buffer-size: it won't catch all cases, but it
won't suffer from false positives, so you can really scream bloody
murder when it happens.


        Stefan

Previous Next

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