Re: [SUMMARY] #8 [[bbb:OrgMeetup]] on Wed, June 12, 19:00 UTC+3

[Ihor Radchenko]

Pedro <pinmacs@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>