emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: Vladimir Lomov <lomov.vl@yandex.ru>, emacs-orgmode@gnu.org
Subject: Re: table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
Date: Thu, 11 Nov 2021 20:58:16 +0800	[thread overview]
Message-ID: <87sfw2luhj.fsf@localhost> (raw)
In-Reply-To: <5e0a2e13-41ed-b0fc-6cb6-625d4bb164de@gmail.com>

Max Nikulin <manikulin@gmail.com> writes:

> On 11/11/2021 13:50, Vladimir Lomov wrote:
>> ** Ihor Radchenko:
>>> Vladimir Lomov writes:
>>>> Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting.
>>> Are you able to reproduce with emacs -Q?
> I can confirm it starting with a simple file
> ---- >8 ----
> | 1 |
> ---- 8< ----
> LANG=en_US.UTF-8 emacs -Q -L ~/src/org-mode/lisp/ cyrtable.org
> C-\ russian-computer RET to switch input method
> TAB to create a new cell
> Any letter


I can also reproduce with russian-computer and at least arabic. Seems to
be an issue with non-latin input methods.

The warning is triggered because return value of
buffer-chars-modified-tick with non-latin input method changes _before_
text is inserted. If I add debug-on-entry for self-insert-command or
org-self-insert-command, buffer-chars-modified-tick changes twice: (1)
some time after pressing the keyboard key but before entering
self-insert function (symbol is not inserted into buffer); (2) after
actual insertion. The problem happens in non-Org buffers as well and
with emacs -Q.

org-element-cache relies on the return value of
buffer-chars-modified-tick to control if all the changes in buffer are
reflected in the cache. The docstring says:

>> By comparing the values returned by two individual calls of
>> buffer-chars-modified-tick, you can tell whether a character change
>> occurred in that buffer in between these calls

So, what we observe looks like a Emacs bug.

On Org side, this bug is very bad news. We cannot wait for the Emacs
fixing the bug - older Emacs versions will still be affected.
Alternative ways to control buffer modifications are buffer-hash and
secure-hash. In the past, I had some random failures when buffer-hash
did not reliably reflect buffer updates. The only alternative is
secure-hash, but I am not sure about it's performance. buffer-hash
docstring says that "It should be somewhat more efficient on larger
buffers than secure-hash is, and should not allocate more memory.". So,
I need to test the actual performance on large buffers before switching
from buffer-chars-modified-tick to secure-hash.

Also, I am somehow unable to reproduce the problem in my private Org
branch. Maybe there is some alternative fix without getting rid of

Vladimir, if the issue is affecting your workflows, you can disable
org-element-cache until we fix the bug. Just set org-element-use-cache
to nil in your config before loading Org.


  reply	other threads:[~2021-11-11 12:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11  4:54 [BUG] Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. [9.5 (release_9.5-223-g876e81 @ /usr/share/emacs/site-lisp/org/)] Vladimir Lomov
2021-11-11  5:54 ` Ihor Radchenko
2021-11-11  6:50   ` Vladimir Lomov
2021-11-11 11:53     ` table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting Max Nikulin
2021-11-11 12:58       ` Ihor Radchenko [this message]
2021-11-14  7:56         ` Ihor Radchenko
2021-11-14 16:42           ` Max Nikulin
2021-11-17 12:15             ` Ihor Radchenko
2021-11-18 16:17               ` Max Nikulin
2021-11-21  8:36                 ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sfw2luhj.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=lomov.vl@yandex.ru \
    --cc=manikulin@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).