On Sun, Oct 07, 2007 at 08:46:47PM +0300, Martin Vermeer wrote: > 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)?
That seems like a fair summation. > 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. Yes, there's actually /more/ of an argument for CT insets than style insets I think. However, my usual objections still apply I think. It'd still be jarring to have the cursor behave "strangely" just because a word has been inserted. > 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. I understand what you're all saying about this difference. I think it's a fair thing to point out. However, I'm extremely dubious that it makes sense for the UI to express this semantic difference. How does this advantage the user? I don't remember seeing a clear answer to this question. > 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... I just about managed to get CT working and that was way harder. I'm entirely confident in the LyX team's ability to implement a range based style feature and make it maintainable. Since it seems the claim that inset code can provide a non-inset based UI has been dropped, the argument is pretty much entirely about an inset UI vs. a ranges UI I think. It's ultimately dangerous to consider implementation when arguing this, since you already have the inset code pretty much done, and lethargy tends to be a compelling argument :/ regards john
