[How should we handle nested headings? André suggested that the level
of headings should be represented by the position in the tree. I think
it was a mistake that he only sent it this proposal to me personally, so
here is my reply.]
[Nesting is slower in performance.]
> This, of course, depents on the actual implementations. Nobody forces
> you *not* to have paragraph_previous and ..._next references in an
> paragraph class.
This is problematic if Paragraphs are to become Insets.
Insets should be self-contained.
Also, maintaining these paragraph_previous and _next pointers is
troublesome when we change the topology of the tree.
> Anyway, I think this is not even necessary:
> The overhead for traversing the tree should be *very* small since the
> tree is rather shallow. So just implementing some class
> "paragraph_iterator" traversing the tree should be enough for the moment.
> It could be changed to handle previous/next references later if this is
> really a performance issue (which I doubt).
I agree that the performance penalty is very small.
But if we can avoid the extra classes, we should.
Instead, we should choose the simpler representation, and using advanced
iterators, expose this simple representation in other forms, if the need
be.
> I think, we missed some crucial point:
>
> If all is nicely structured as a tree internally, we do not even need
> different types (insets? ;-P) of headings: The type of a heading is
> indicated by its position in the tree, yielding a couple of advantages:
We can achieve the exact same benefits in a simpler way: Have one kind
of HeadingInset that keeps a counter to indicate the nesting level.
> - There won't be a hard-coded limit on the number of levels.
We will allow more nesting with a HeadingInset with a counter, than with
position in a tree: We can only nest to the number of different
pointers to Insets we have, and this is typically smaller than the range
of an integer.
> - Currently, moving from "article" to "book" *is* annoying, you
> basically have to change every heading. With a tree structure it is
> mainly a matter of specifying a book layout (of course, some implementation
> of "book" has to define 'when exporting to latex, level 1 is called
> chapter').
This is also solved with a HeadingInset with a number.
> - It would be easy to collect articles in some bigger document, say
> conference proceedings. Just include seperate articles into the master
> document at the right place. No need to mess around with "section" and
> the like.
This is also solved with a HeadingInset with a number.
> - I *think* that it is easier to implement and to maintain. Instead of
> coding "secton", "subsection" ... one has to care for "go down a level"
> and "go up a level" only.
This is also solved with a HeadingInset with a number.
A HeadingInset with a counter is much easier to promote/demote than a
tree positioning based HeadingInset: We do not have to change anything
in the typology of the data structure. Just a counter inside the inset.
Also, having using the topology to denote the level of a Heading is
dangerous: What if we cut the heading to the clipboard? How will we
handle the level then? Do we need to insert a bunch of blank nested
headings for this? I say this complicated.
We should not use the topology of the tree to hold this kind of
information, IMO.
> - It is more natural for the user: When writing something at some point
> I decide to introduce a new level of nesting
This is also solved with a HeadingInset with a number.
Greets,
Asger
