Andre Poenitz wrote:
> On Wed, Aug 27, 2003 at 01:54:55PM +0200, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > Hm, I think ParIterator + InsetList::iterator should suffice.
>> >
>> > The problem with the InsetText hidden in InsetCollapsable is that this
>> > is not an inset, but some implementation detail which should be
>> > completely invisible.....
>>
>> I do not agree. What is it that forces conceptually an inset to be owned
>> by some paragraph?
>
> Simplicity.
More simplicity would be 'all insets' that it seems we are heading to. And
this would be conceptually nearer to my approach...
>> Why insets cannot own insets?
>
> There is no need to.
>
>> Think about tables for instances.
>
> Math has tables without having insets in insets directly. So,
> technically this is not needed.
Of course, you can reimplement insettext n^2 times if you want. Why do you
want to hide that tables cells are insettext it beats me.
> [And I'd even argue that math tables are much easier to handle than
> 'real' table from a user's perspective. And that's due to the lack of
> this direct containment which leeds to such clumsy solutions like the
> 'cell mode' of real tables.]
I don't know the table code to understand this. But I don't see any
technical reason why the table code cannot directly contain real insets.
> The mathed model is
>
> Inset has cells. ("MathArray")
> A cell has insets.
>
> Nothing else. To expand that to the outside world this would be:
>
> Inset has cells. (ParagraphList)
> A cell has data (characters and insets)
>
> A cell would be the equivalent to an "thin ParagraphList wrapper".
>
> [And in case we ever want to go to a unified cursor/cutbuffer/whatever,
> this needs to be solved...]
IMO in the real word both pars and insets play the role of math cells (can
contain cells and data). Hiding it doesn't help in any way.
The only escape I see is to have 'all insets' (paragraphs are insets) and in
this case we are nearer to my approach.
Regards, Alfredo
