Ihor Radchenko <yanta...@gmail.com> writes:

>> Oops, you are right. I fixed this. It should be way faster. I can
>> navigate in your example file without much trouble.
>> Please let me know how it goes.
> I tested with master + my personal config + native compilation of org,
> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae.
> Did not see much improvement.
> Vertical motion in the folded buffer is still quite slow.

Oh! This is embarrassing. I improved speed, then broke it again in
a later commit. Sorry for wasting your time. I think I fixed it again.
Thank you for the feedback.

Could you have a look again?

> Apparently I misunderstood the purpose of: 1027e0256
> "Implement `org-cycle-hide-property-drawers'"

The function is meant to re-hide only property drawers after visibility
cycling. Its purpose is not to improve /unfolding/ speed. Unfolding is
very fast already, faster than using text properties.

Folding has roughly the same speed in both cases: most time is spent
looking for the next location to fold. However, folding with text
properties is more resilient, so you fold less often.

As a side note, your file contains 5217 headlines and 5215 property
drawers. I'll ignore the 3989 regular drawers for the time being
(although they do contribute to the slow navigation). In current master,
it means there is at most 5217 overlays in the buffer. With text
properties, the worse situation in the same.

Of course, that case happens less often with text properties. For
example, it happens in "contents" view in both cases. However, in "show
all" view, it is only a problem with overlays.


Nicolas Goaziou

Reply via email to