Pedro <pinm...@cas.cat> writes: > On 6/22/24 10:32, Ihor Radchenko wrote: >> - Tim continued his struggle with an elusive bug he experiences when >> setting tags (C-c C-q) in large Org buffers - setting tags takes >> forever for him. (There is infinite loop likely lurking somewhere) > > I have the same bug, but I said nothing because I don't have right now > time to report. When I read it, I just wanted to share that this also > happens to me.
To be clear, I have no idea what kind of bug Tim experiences. I just had a _guess_. It may or may not be the same bug. Same for your case. I cannot tell without seeing the details. > I work with huge diary files and I discovered that since the cache is > activated by default, when I remove or move certain subtrees/parts looks > like makes the cache corrupted... Did it start happening recently? If you think that the cache is corrupted, please add (setq org-element--cache-self-verify t) to you config and watch the warnings. > ... not > only affects tag completion, that yeah, it takes forever, it also works > weird on org-captures applied to huge buffer files Again, please report these things separately. I can see that you have problems, but I cannot help you without seeing more details. > From user-view perspective, it was uncomfortable to see it enabled by > default, specially when you have problems, specially, when you try to > deal with a solution, and is not really documented on the workarounds, > etc [0]. The cache was enabled by default after I (0) rewrote the old buggy implementation (1) enabled the new version in dev builds (Org 9.6-pre) and fixed all the reported bugs; (2) released Org 9.6 with org-element--cache-self-verify set to t and fixed the inflow of all the reports about corrupted cache; (3) disabled cache verification to nil when the reports stopped coming. So, at this point, cache issues are extremely rare. (and note how your [0] link is from a 6-years-old post; I rewrote that old cache version) > ... It took me nearly 2 hours to stabilize again my workflow so I > agree that some information should be explained as stated in a recent > conversation [1] That conversation is tangent. It is not about cache being enabled. It is about various caches (not just org-element) being saved to disk. > My vicious workflow regretably involves opening a lot of duplicated > buffers through emacsclient, and at some point, it becomes slow, so I do > this [2] > ;; after doing stuff, cache goes slow, but with this, it improves > ;; so this is arbitrary program, that my brain has associated with Please report this as a bug separately. Ideally, with a reproducer. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
