Kaushal Modi <kaushal.m...@gmail.com> writes: > I actually run a wrapper script to update Org and that has all that: > ... > I verified that at least the git hash was latest as of then: > release_9.5-364-g*de022e*
Odd. Though the commit number is indeed correct. > There's a setup included in there; I forgot about that. If you don't mind > trying it again, this would download everything needed: Thanks! I was able to follow your steps this time. > Sorry, but I am getting similar backtrace in another function now: Sigh... Should be fixed now. I did not expect that arguments to cache functions could ever be markers. After the fix, I was able to see the warning you were talking about in the earlier email. Your test case revealed an important omission in the cache logic when a huge number of edits are stacked together into asynchronous cache queue. Thanks you for providing the excellent reproducer! On latest main, your example file is exported without any warnings. Also, I noticed that the large number of edits makes the cache use a lot of memory adding load onto the Emacs garbage collector. May I know what exactly ox-hugo does that triggers that many edits? Exporting your example files took approximately 30sec on my system (both with and without cache). I believe that the speed can be improved if cache is used more optimally. > *Another observation: * > > I see this warning when building from the latest main: > > In org-element--cache-sync: > org-element.el:5935:19: Warning: assignment to free variable > ‘org-element--cache-change-warning’ Thanks! Fixed. Best, Ihor
