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

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

>> Well... I added yet another exception on main. Note that this special
>> case is also just in older Emacs versions.
>
> Ihor, have you pushed the change? I still can reproduce the issue with 
> Emacs-26.3

Oops. I fixed Emacs 27, but apparently not Emacs 26. Should be fixed
now.

>> (and I secretly hope that this kind of
>> patch will be implemented by someone else as a part of tree-sitter
>> integration).
>
> A piece of friendly trolling: it would be tree-sitter module for Org syntax.

tree-sitter is comparable with org-element. org-element
parser is fairly fast and also uses incremental parsing ;)

tree-sitter vs. org-element on 15M Org file
org-element-parse-buffer
(16.090262757 1 0.7365683609999962)

org-element-parse-buffer 'element granularity
(7.688000744 0 0.0)
8sec

tree-sitter via https://github.com/milisims/tree-sitter-org
parsed down to 58% of the buffer in 5.3sec and exited with error
extrapolates to ~9sec

Racket's brack via https://github.com/tgbugs/laundry
failed to finish parsing in reasonable time. Cancelled at 10m11.436s

Clojure parser via https://github.com/200ok-ch/org-parser
failed to finish parsing with java.lang.OutOfMemoryError: GC overhead limit exceeded
Running time 8m28.078s

So, tree-sitter may be faster, but not that much faster and we will have
communication overheads when using tree-sitter module.

>> The most problematic
>> is the case triggered by self-insert-command, but it will not trigger
>> cache reset.
>
> I mean namely this case of just typing text somewhere in a large file.

My data is for 15M file. Indeed, things will be worse for even larger
files, but let's hope that people's Org files are not yet that large and
we can wait until Emacs 28 is released.

Best,
Ihor