Tuomas Lukka wrote:
Everything is programmed in a modular fashion. Also, all the applitudes have been designed carefully so that unanticipated connections will be possible, as far as is feasible.This is the thing on which the whole long email rests; now, the big question is: is the paragraph representation you suggestin accordance with this?
Yes, I know, but I didn't answer that question, I replied to the more general question whether applitude overlap w/ interpretation is possible at all...
What, exactly, are the rules here?
Ok, these things *are* actually quite difficult when it comes to paragraphs, but fortunately, with hierarchical containment things get a little nicer ;-)
Let me first summarize the problem: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.
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.
Still, this isn't really clean. I don't like that "the paragraph the beginning of P/Q is in" stuff too much. But structurally, I anticipate it to work (i.e., the connections should be mostly handled well). Maybe we can think of something cleaner... But I can't see that, yet.
One issue here is that creating paragraphs and so on will, under this scheme, inevitably mean changes in the containment structure, though they shouldn't be horrible. However, users who want to use the containment structure for certain views might not like it if internal structure like paragraphs is put on the containment dims... hmmm.
Still, I *want* to be able to see and connect paragraphs as cells. It's part of the fun. :)
- Benja