On Fri, Oct 05, 2007 at 08:28:30PM +0100, John Levon wrote: > On Fri, Oct 05, 2007 at 10:23:58PM +0300, Martin Vermeer wrote: > > > > > > > (Unfortunately insets are no good for CT) > > > > > > > > > > Interesting, why? From what I can see it seems that all the inset > > > > > people's preferences apply just the same to CT. > > > > > > > > Funny :-( > > > > > > I'm serious, I don't understand why it's different for you? > > > > I don't think you are. Do you seriously think I am that > > dogmatic? Come on. I can recognise a use case where insets > > are a plain bad idea. > > I don't think you're dogmatic. I'm genuinely interested in what makes CT > insets fail for you but style insets work. I have my own reasons for CT > insets being an awful idea, but they mostly apply to style insets too.
You're serious about this aren't you? How would you do it? Two inset types "deleted text" and "inserted text", right? And then you have to handle Delete, Backspace and typing characters: typing Del the first time creates a Deleted inset; second and later times will move characters from the right into the inset. Etc. Backspace works naturally, deleting inserted chars leftward. Is this what you mean? Sure you could do it. I would expect the complexity to be similar as using ranges -- handling paragraph ends, e.g. --, as I don't quite see where you could leverage the encapsulation provided by insets. Those are just clusters of inserted / deleted stuff, without anything more in common than precisely that: being inserted or deleted. It would require an awful lot of special code to be added. There's just one nice thing you could do: use the collapsing property to preview what the doc would look like if you accept or reject these clusters. Somewhat similar to what branches do. Hmmm... interesting. Who knows if there hadn't been a pre-existing incomplete CT implementation... perhaps I was too rash rejecting the idea out of hand. - Martin
