On Mon, 22 Mar 1999, Alejandro Aguilar Sierra wrote:
[...]
> > > At the moment, the big discussion is turning around whether paragraphs should
> > > be insets or not. We have not really decided yet.
>
> As an authority on both LyX and Mathed insets, my opinion is NO. A
> paragraph should be as fluid as water inside either the workarea, a table
> cell or a math text inset. So an entire buffer would be displayed trough a
> single workarea sized inset wich could have inside, recursively, several
> other insets. This is how mathed works currently and I think it works
> well.
Why does an Inset need to have a defined rectangular box it fits into?
Why can't an Inset be given a box and told to fill this as best it can?
Perhaps a member function that takes a width and returns a height-required
-to-fit-everything-in. Not every Inset needs this freedom and quite a few
do have fixed size requirements but that is a peculiarity of those insets
only and doesn't have to generalize to all Insets.
If something like this existed, and I've gotten the impression from other
discussions that others want to flow text like this, then I see no reason
why an InsetParagraph couldn't exist and couldn't flow to fill whatever
box it's put into.
As we've already read in discussions last week it seems likely that there
are a few aspects of the existing Inset hierarchy that will need to be
ditched soon in order to get a better system. Take the command vs.
environment split, it isn't necessary to make this distinction in the
hierarchy and in fact it creates artificial barriers. So I suggest we try
to think "outside the box."
As to whether or not an InsetParagraph should be included here's a short
list of observations:
* A single layout style may affect multiple paragraphs
* A single paragraph may have multiple Insets
* A single paragraph may have multiple fonts changes within it
* Relying upon '\n's to denote a paragraph is awkward and error
prone as demonstrated by our existing code. The alternative:
* {A LaTeX paragraph.\par}
* <p>A typical [SG|X|HT]ML paragraph.</p>
The last point might also have its difficulties in itemized lists for
example where two paragraphs are used for a single itemized point as in:
* This is a long winded example.
That has a second paragraph.
* This is the next item.
where we'd need to generate (I think):
{\item This is a long winded example.
That has a second paragraph.\par}
My LaTeX knowledge doesn't stretch quite this far so the above example
could easily be wrong so I welcome any correction. I have a feeling it'd
actually need to generate something more like:
\item {This is a long winded example.
That has a second paragraph.\par}
Either way, what's the best way of handling this? An InsetContainer
perhaps that can handle multiple paragraphs?
We seem to be agreed on using paragraphs as building blocks for a document
so one question is: If we don't have a paragraph Inset which Insets are
allowed to contain Paragraphs? or do none of them contain paragraphs and
we figure out where a paragraph begins and ends by some interpretation of
Insets (eg. everything between two InsetLayouts is a single paragraph)?
Last week I suggested the use of an InsetLayout to be used in a similar
manner to InsetFont, effectively marking everything that comes between it
and the next InsetLayout as having a particular layout and other custom
paragraph settings excluding minipage because that isn't really a
paragraph attribute*. This could then apply to multiple paragraphs if we
had an InsetContainer or multiple InsetParagraphs. This idea came from
the observation that the current Paragraph implementation has a huge
amount of info in its structure. Most of which is often shared with its
neighbouring paragraphs. The additional benefit of the InsetLayout
approach is that it would make stuff like Larry's (or was it Richard's?)
need for clusters of paragraphs a bit easier to force from within LyX
(without support from the layout styles).
Hmmm...
Allan. (ARRae)
