Hi,
I would like to remove the hard-coded `deepest-level' from
`org-columns--compute-spec'.
(let* ((deepest-level 29)
...)
The main reason I am looking at this is maintainability. Removing
`deepest-level' would get rid of a magic number and make
`org-columns--compute-spec' easier to follow, while also making the
accumulator track the actual headline levels seen in the buffer instead
of a fixed limit.
The practical behavioral effect may be small -- I do not know if anyone
really uses column summaries with headings deeper than level 29. But if
such headings are present, they would be handled naturally rather than
falling outside the fixed accumulator.
Here is what I found in the history.
- In the old `org-colview' code, as early as the commit that split out
the file, 1b58b6ba9f (2008-04-09), the summary code used `lmax 30'
and vectors of length 30. This meant that only indexes 0..29 were
valid.
- The comment next to this value was already:
Does anyone use deeper levels???
so the value looks like an arbitrary accumulator size, not a semantic
Org limit.
- There is a related precedent in `org-clock-sum'. It also used a
hard-coded `lmax = 30' accumulator, but commit 9059c8fae
(2014-02-24) removed that arbitrary limit by growing the per-level
vector dynamically.
So my current understanding is that the `29' limit in `org-colview'
comes from the old implementation detail of using a 30-element vector,
not from an intentional Org restriction.
Would it make sense to remove this hard-coded limit from
`org-columns--compute-spec' as well, by growing the per-level
accumulator dynamically?
Does this sound like a reasonable direction?
Best,
--
Slawomir Grochowski
