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.
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 (I could not reproduce exactly how), not only affects tag completion, that yeah, it takes forever, it also works weird on org-captures applied to huge buffer files. So I have a current diary, that tries to get a record of last weeks. When I could not archive it (like right now), it has 5 weeks from now, that means 24k lines in a file, when I can clean it up, goes to an archive file (so then, alleviates org-agenda-files processing), the 2023, which is pretty archived, is 263k lines.
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]. 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]
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]
Being said all, I am very happy with how emacs and orgmode are getting progress done on managing large files, etc. I just wanted to let you know about a problem that I am experimenting, and maybe other people too.
I will note in my agenda on the #9 meeting [3] and I will try to join Cheers, pinmacs [0] In my notes it says: #+name: sourceblock_created_2024-06-27_14-32-44 #+begin_src texthow to disable Element cache? I am having warnings but I don't have time to do bug reporting ( https://orgmode.org/Changes.html )
found the solution (setq org-element-use-cache nil) src https://emacs.stackexchange.com/questions/42006/trouble-with-org-mode-cache-find-error
[ I don't remember where I got this, but I think it should appear in the manual saying that this is a workaround until it is fixed https://orgmode.org/org.html ]
org-element-cache-reset #+end_src[1] email Subject: Please document the caching and its user options, From: Eli Zaretskii, Date: 2024-06-12 11:38:05 AM CEST
[2] #+name: sourceblock_created_2024-06-27_14-33-28 #+begin_src emacs-lisp ;; I use this program when it works slow (defun kill-duplicate-frames () "Kills duplicate frames of buffers." (interactive) (let ((buffers '())) (dolist (frame (frame-list)) (with-selected-frame frame (let ((buffer (current-buffer))) (when (member buffer buffers) (delete-frame)) (add-to-list 'buffers buffer))))) ;; after doing stuff, cache goes slow, but with this, it improves;; so this is arbitrary program, that my brain has associated with "make emacs faster again"
(org-element-cache-reset) (message "Killed duplicate frames of buffers.")) #+end_src[3] email Subject: #9 ((bbb:OrgMeetup)) on Wed, July 10, 19:00 UTC+3, From: Ihor Radchenko <yanta...@posteo.net>, Date: 2024-06-26 5:48:46 PM CEST
OpenPGP_0x9D64597C3A982DCA.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature