Hello!
I have massive org-mode file with thousands of SRC blocks.
As the file grew, I started to get very poor performance, but setting
`org-fold-core--ignore-modifications` to `t` solved it.
However, I still get very poor performance when a lot of folded headings are in
view. It gets slower a
d by Emacs.
Removing it solves my issue:
(org-link-set-parameters "id" :follow #'org-roam-id-open)
Thanks!
Sebastian Wålinder writes:
> I have been reading through the code, and it appears that org-id doesn't
> store the actual positions of ids within all files.
>
>
I have been reading through the code, and it appears that org-id doesn't store
the actual positions of ids within all files.
It's instead fetched every time the link is accessed. There must be something
strange going on with the org cache causing this issue.
Sebastian Wålind
Hello!
I often use org-id to create persistent links to headings like this:
* Foo
:PROPERTIES:
:ID: BAR
:END:
[[BAR][Link]]
However, after inserting a line above foo, following the link BAR will take me
to the wrong line, because the org-id database hasn't been updated with the
headline
Hello!
I write regularly in a massive org file ~160 000 lines, and experience
progressive slowdowns as the buffer remains open when I have the setting `(setq
org-fold-core-style 'text-properties)`.
When the file is first opened, all operations are very fast. But as I keep
using, it keeps slowi
Hello!
It appears that indirect buffers duplicate the entire org element cache from
the base buffer whenever created.
Running `memory-report` indicates that each indirect buffer has the same memory
blueprint.
This becomes a massive issue with large org files.
My in my 160 000 line org file, t
Hello!
When org-babel inserts results after evaluating a org-babel block, the current
narrowing isn't respected.
Org searches outside of the current narrowing to find a result block, then
updates that.
Here's a example to illustrate it:
```
#+CAPTION: 1. Evaluate this to narrow to the elisp bl
