From: Ihor Radchenko <email@example.com> To: Max Nikulin <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected." Date: Tue, 30 Nov 2021 20:54:05 +0800 [thread overview] Message-ID: <871r2x953m.fsf@localhost> (raw) In-Reply-To: <firstname.lastname@example.org> Max Nikulin <email@example.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
next prev parent reply other threads:[~2021-11-30 12:54 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-11 11:40 Max Nikulin 2021-11-11 13:07 ` Ihor Radchenko 2021-11-14 7:59 ` Ihor Radchenko 2021-11-18 14:55 ` [BUG] " Max Nikulin 2021-11-21 8:35 ` Ihor Radchenko 2021-11-30 11:59 ` Max Nikulin 2021-11-30 12:54 ` Ihor Radchenko [this message] 2021-12-01 12:27 ` Max Nikulin 2021-12-02 1:48 ` Ihor Radchenko 2021-12-02 16:37 ` Max Nikulin 2021-12-03 4:36 ` Ihor Radchenko 2021-12-03 11:35 ` Max Nikulin 2021-12-05 5:56 ` 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style 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=871r2x953m.fsf@localhost \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).