Re: Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> We want to have the paragraphs available as cells, for linking. The idea 
> is that whenever an applitude has an item X, it tries to assign exactly 
> one cell to it, and doesn't delete or change that cell for the whole 
> lifetime of item X, so that other applitudes can make connections to it 
> and have them stay. With paragraphs, the problem is that two paragraphs 
> may be joined into one, without the second paragraph really 
> disappearing-- its text just became part of the first. If we try to 
> separate the paragraphs again, by hitting "Enter" where we separated 
> them, the second paragraph may come back as it was-- but without the 
> links to it, since to the applitude, it's still a 'new' paragraph.

Yes, this is a very good example.

> My proposal for paragraphs through the containment mechanism doesn't 
> completely solve this problem, but does alleviate it.
> 
> The point is that because of the hierarchical containment, we never need 
> to split or join a cell. When there were two paragraphs, P and Q, with 
> their own cells along d..contain-set, and the user joins the two 
> paragraphs, cell Q never disappears: only its "paragraph start" mark is 
> removed. When the user inserts a paragraph break into P, the cell isn't 
> really split; we just split what's *inside* it into multiple cells 
> *contained* in P, and one of these cells has a paragraph start mark. P 
> therefore now contains two paragraphs-- If we now make the links mean, 
> "the paragraph (the beginning of) P/Q is in," our semantics work mostly 
> fine.

That works better than I expected it would.

The other question is, how much code do we need to ensure text works
correctly and logically, in all user interfaces that use these?

> Still, I *want* to be able to see and connect paragraphs as cells. It's 
> part of the fun. :)

I agree completely. The problem is managing the interactions.

	Tuomas