On Wed, 17 Mar 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> These aren't commands they are environments! They have start
> Allan> and end tags that must match. Therefore we need the
> Allan> InsetEnvironment to support multiple paragraphs and to
> Allan> automatically support the output of matching tags. If a DOM
> Allan> allows end tags to be left off then the environment can simply
> Allan> ignore the output of the end tag. This will require some
> Allan> co-ordination with the Writers.
>
> Before we go to supporting environments with hierarchy (vs. the
> current linear support for environments), we'll have to think about
The current linear support relies upon recursion (at least in writing to
files) and duplication of code to place the end markers and control
output. If we move everything to Insets then the export routines are
dependent upon Insets (either as member functions of the Inset or as
multiple-dispatched separate functions) so it makes more sense to have
environments stored hierarchically since we know exactly when to output
end markers. Then there is no duplication of code and the recursion (now
encapsulation) is explicit in the data structures and not just in some
convoluted code.
> the repercutions that this will have on the GUI. The current system
> (two consecutive 'itemize' are in the same environments) is weak in
Two consecutive paragraphs in an InsetEnvironment would be in the same
environment (obviously). But I think what you mean is: can this scheme
allow two consecutive environments of the same type?
I've a feeling that the answer may be better .layout info. Such as a
flag that states that no automatic merging of these types should take
place. That would eliminate the two theorems in a row bug and still allow
lists to be merged.
> some sense, but very easy to use. How do you want to reflect on screen
> the hierarchical nature of environments, and how will users be able to
> interact with it?
The onscreen display of lists should still be the same (but that's all
controlled by the .layout files anyway). The biggest difference would come
in handling two consecutive environments of the same type that cannot be
merged. Everytime a user sets a paragraph as type "Theorem" for example
it will start a new environment of that type. If they want to add another
paragraph to that environment they type in their Standard text and
"depth-increment" it -- just like they can do now. In fact I described
this sequence last year when we were discussing this very problem.
For lists and other environments that can be merged setting a paragraph as
type "list" or whatever will add another entry to the pre-existing
environment. Depth incrementing a Standard paragraph will extend the last
entry of the list. Where an entry may be multiple paragraphs ie. an
InsetContainer (using this name to avoid confusing paragraphs and
InsetParagraphs).
The merging on creation described above simply involves appending the
current paragraph to the end of the InsetEnvironments vector. This is
quite simple given that we know the cursor position and hence the location
of the current paragraph in the document*. Certainly no more difficult
than anything we currently do.
* assumes a cursor consists of a ParagraphIterator and a BufferIterator
where a ParagraphIterator is effectively an offset into the current
paragraph, an unsigned int, and a BufferIterator points to the start of a
given paragraph. Then --BufferIterator gives us the previous paragraph
ie. the last paragraph of the last entry in the list. Alternatively, we
could have a different iterator that is a FixedDepthIterator such that
paragraphs on the same level can be accessed. Thus
--FixedDepthIterator(BufferIterator) would give us the InsetEnvironment
for the list.
Allan. (ARRae)
