Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

> Ihor, thank you for your work related to such issues. I had a hope to 
> thank you for the fix, but I faced a warning again in a bit modified 
> scenario. This time it is soft indent mode.
> ...
> First letter of new heading must be a capital one, though it can be 
> Latin. Converting top-level "H" heading by C-c C-* does not cause such 
> warning.

Well... I added yet another exception on main. Note that this special
case is also just in older Emacs versions.

> I am not an active user of main branch (I was merely hunting for another 
> bug), so I can not estimate performance penalty for large files due to 
> continuous cache resetting. I do not follow emacs-devel mail list last 
> weeks. Have you managed to negotiate with Eli concerning changes 
> required in Emacs code? I mean some followups of ...

The conclusion from that discussion is that someone needs to prepare
upstream patch for Emacs. I may do it in future, but it does not feel
like high priority because fixes for Emacs master will not solve the
problem in older Emacs versions. (and I secretly hope that this kind of
patch will be implemented by someone else as a part of tree-sitter
integration).

As for the performance, the last series of special cases you reported
(thanks again for doing this!) should not happen too frequently. I
cannot imagine users spamming C-c C-* all the time. The most problematic
is the case triggered by self-insert-command, but it will not trigger
cache reset. The worst impact we can see with C-c C-* issue is ~1.5-2x
slower agenda (or other full-text search queries) if cache is reset
between agenda updates. It is still much better than not using cache.

Actually, growing cache too much makes Emacs garbage collector perform
pretty poorly (at least when you have a file so large that cache has
300-400k elements). Reducing cache size from time to time may be even
beneficial for performance. I do not know the realistic cutoff values
though. We may want to implement access frequency-based cache element
removal.

Best,
Ihor