On Sun, Oct 07, 2007 at 05:38:54PM +0100, John Levon wrote: > On Fri, Oct 05, 2007 at 10:53:14PM +0300, Martin Vermeer wrote: ... > > Is this what you mean? Sure you could do it. I would expect > > I'm not really interested in implementation. This thread is all about > the UI, that's what REALLY matters. > > Given your other post it seems that you'd actually be for an inset-based > CT UI. You are at least consistent :)
Only because you forced me to think it through... thanks for that. Let me see: is your UI objection due to the fact that running text is linear, a narrative, and insets break that logic (selection, cursor movement, line breaking)? If so (a sensible argument), than for CT the argument becomes IMO invalid: here we have an indeed linear base narrative, but annotated with tentative additions and deletions, so no longer linear. And in CT mode, operations like select, cut and paste are anyway tightly circumscribed. I don't see how insets containing those annotations can do any more damage to the linearity. It is somewhat similar (not exactly of course) as with branches. How does that carry over to text styles? For mark-up such as emph, if it extends over some length of text, I see your point. But for other cases of well-defined semantic mark-up such as noun, I disagree. These are always short, self-contained, (well you may want to correct a person's name if spelled wrong but that's it), and essentially 'atoms' or single characters from the narrative POV. The same for the many short elements defined in XML. Those are natural insets. And BTW you may exclude implementation from this argument, but in real life it _is_ along. Coding resources are limited, and other things being equal or close, it should be looked at. An implemented, good UI beats a perfect one that requires prohibitive implementation _and_ maintenance resources... - Martin
