Rasmus <ras...@gmx.us> writes: > But are the slowdowns associated with outline.el functions anything that > will realistically be felt in normal usage?
They are noticeable under certain circumstances. I implemented `org-show-children' because `show-children' was /reported/ as slow. Generally speaking, outline doesn't cope well with dense sub-trees. As an example, consider `org-forward-heading-same-level'. Using outline, we need to move to next headline, check its level, compare with original, rinse and repeat, possibly many times, until we find a match. However, we could simply do (re-search-forward some-appropriate-regexp nil t) and be done with it since we can turn level into a regexp. > IMO the biggest advantage of orgstruct is that it has more sensible > keybindings than outline. Of course it's also nice with lists and tables > (assuming they are not in orgstruct++; don't remember)... Table is orgtbl-mode, not orgstruct-mode. List handling is a real concern however, because we cannot use the parser (there is no context to know about) but still have to analyze lists. > Adding advice to orgstruct, which is a mess anyway, won't make it any > worse than it is... Agreed. > I'm all for advising if that's easier or if we want to add workarounds in > more places. For my problem, the proposed one line patch fixes it, > though. Indeed. But it only solves `org-show-children'. I have the feeling that we will encounter a similar issue with another base function like this one later, tho. Regards,
