On Mon, 15 Mar 1999, Andre' Poenitz wrote:
> > We certainly do not want that. But it does not make sense to me in any
> > document to include a paragraph into a paragraph without some kind of
> > wrapper which specifies the semantics of the inner paragraph.
>
> If these paragraphs have different properties, why not?
> Why not at all?
>
> I don't know whether you have worked with one of the newer releases of
> Maple or Mathematica. They both have a really nice feature when it comes
> to larger documents: You can structure the worksheet by "grouping"
> cells or other "groups" and "hide" part of the worksheet by
> "collapsing a group" (like LyX does with footnotes/tables).
I'd like to be able to collapse arbitrary paragraphs like a "folding
editor" does (occam does this). Or at least support folding/collapsing of
environments.
[hidden flag]
> While I am thinking about it: Changing something to paragraph style
> "comment" removes its original style, am I right? This is particularly
> annoying if one has changed a nested list into a comment, since this
> means one has to recreate the list structure from scratch. I think
> "paragraphs within paragraphs" could be used to work around it...
This is another good suggestion and I think its been on most peoples todo
lists for a while. Proper comments using the appropriate latex
environment.
InsetEnvironment and even an improved InsetCommand will build most of our
documents hierarchy. Headings and such are ultimately one of these two
types and a simple linear list of paragraphs doesn't allow for the needs
of environments in particular "\end{environment}". Thus a Buffer that is
a list<InsetParagraph> is okay if we also allow InsetEnvironment to
contain a list of paragraphs thus ensuring a much simpler scheme to
output appropriate hierarchy markings like the \end{..}.
Hmmm... Each of these can hold a list of Insets (which may be paragraphs)
InsetParagraph
InsetEnvironment
* hierarchy support
InsetCommand
* maybe not this one but if we could come up with a scheme so we
could figure out which commands can use a hierarchy (something in a
.layout) we'd be in a position to better support collapsing and get
out of hardcoding specific sectioning support into the kernel.
TOC would then be based on info from the .layout rather than on
specific info in the kernel.
Now then can a paragraph (text concept) or an InsetParagraph
(implementation concept) contain/be a heading or a list or is it just a
paragraph of text?
That is should the three be peers/siblings in a Buffer or not?
If we say "no" then the InsetEnvironment which may contain a multipage
enumerated list with several levels may be sqeezed into the container (an
InsetParagraph) along with multiple other InsetEnvironments. Maybe a
better name for InsetParagraph (in this case) is InsetContainer where an
InsetContainer may be:
1. a real paragraph in the written word sense
-- most of the arguements I've read in this thread seem to
be because one person is talking about the text concept
"paragraph" and the other is talking about the
implementation concept of an Inset container.
2. a collection of possibly hierarchically based components.
-- could this cause any problems? What about when it
comes time to export/import?
Hmmm... I was inclined to think maybe they should be peers in the
Buffer with the restriction that an InsetParagraph can't contain an
InsetEnvironment or an InsetCommand but an InsetEnvironment or
InsetCommand can contain an InsetParagraph. But that won't work unless we
can split commands into two types: sections/hierarchy types and
non-section/hierarchy types..
After rereading all this again I've got an idea forming that we do need
some form of hierarchy support for commands either way (peers/not-peers).
InsetEnvironment is already a self contained concept (but not a self
contained implementation yet). Maybe a special form of command inset is
needed that supports a list of deeper paragraphs (like section commands
having associated subsections etc.) This generalisation would then allow
us to generalise the sectioning support and put things like counter update
rules in the .layout files where they belong instead of hardcoding them...
(a scripting language would be helpful here but it could be done without
one).
But then again Asger has argued that we probably shouldn't have a tree.
If we typically only have < 10 levels (usually only 4 or 5 I'd think) then
changing the level of a given section or paragraph isn't going to take
that long or be that difficult either. Even the alfanumber 20-odd levels
shouldn't be that big a task.
> I think handling paragraphs differently than "real" insets only asks
> for trouble in implementation, maintenance *and* useage... it is much
> simpler to tell people "an A is something that contains other A's" than
> to say "an A usually contains B, C and D, and a B might contain A's but C
> and D not except you do ..." ;-)
This is the problem with calling an InsetParagraph a paragraph when it can
really contain multiple hierarchies of paragraphs. That is, confusing the
text concept paragraph with the container idea.
Allan. (ARRae)
