> I'm inclined to think that having a specific Heading inset may be a flaw.
> That kind of info should be pushed into a layout file so we have more
> generic handling of documents.
Yes, you are right. We don't need a specific Heading object.
At the top level, we could only have "paragraph" objects. These have modifiers
to fine-tune the behaviour. Specifically, any it can behave like a heading.
We do need to have a "Heading" state bool, because headings are special in many
ways: They have a heading depth (in principle distinct from the nesting depth
- we can have a heading inside a footnote!), they have to go into the TOC, and
other stuff.
So another question is: How do we organize all the different kinds of
information that the different "modes" of paragraphs require?
At the moment, we have a giant struct with fields for all of these things, and
these are carried around even when the information is not relevant. I'd like
us to come up with something better, and in this regard my Value system could
do the job... However, let's ignore this for now.
> The balance I'm referring to is how much and what work does a Writer do
> instead of the Inset and what details can we put in the layouts to limit
> the amount of hard coding in the kernel? For example does the kernel
> really need to know about sections? If so, how much does it need to know?
The kernel needs to know how to format each layout on screen, and as exported
stuff. Also, it needs to know if things should go into some of the dynamic
lists/trees we have in the interface: TOC, List of Figures, List of
References, whatever.
> AFA the Writer vs. Inset question is concerned I'd prefer to have Insets
> automatically handling the output of their own end tags if they need them.
> With your flat document structure and the stack idea it requires the
> Writer to handle the stack. This shouldn't be a difficult problem.
Another potential solution is to pretend that the document structure is a tree.
We can easily define a virtual tree-traversal. It's just a question of taste.
> Hmmm... I suppose if the Writer asks the Inset for its end tag if it has
> one then it may be feasible to eliminate the distinction between commands
> and environments that we currently enforce in the kernel.
Yes, I agree that this is a good reduction. In my mind, I have always
considered the commands as special case.
> With the introduction of a stack to hold end tags for environments as you
> suggested elsewhere I'm inclined to agree with your proposal for a flat
> document structure mainly because it addresses the problems I have have
> with the existing code.
Ok, Lgb, Jean-Marc, Allan, and I all agree that a flat document structure would
work. The rest have not objected, so let's consider this a fixed design
decision then.
> However, I still have some reservations about
> other aspects as rambled about above.
Well, I have no reservations about the other aspects, so we are converging fast
;-)
Greets,
Asger
