On Wed, Oct 03, 2007 at 08:17:52AM +0200, Abdelrazak Younes wrote: > >2) have each position in the text be represented in the buffer not by a > >char_type, but rather by a struct which would contain, in addition to > >the char_type, also the attribute information belonging to that position > >(and maybe also a pointer to the inset, if it's an inset; this would be > >an extension of what I once suggested in this thread: > >http://permalink.gmane.org/gmane.editors.lyx.devel/88025; but this is > >really a separate issue); and perhaps other position-specific information. > > That's a hammer... I mean, I think the inset address idea is interesting > but replacing each and every char with a bigger structure... ouch! ;-)
It's not that bad when you think about it. We already use 4 byte per char, and 4 bytes would be completely sufficient to serve as index in a array of insets. Simple insets like those representing a single character can be shared/refcounted, and they would not even have to be dynamically allocated as we could e.g. pre-create all Latin1 character insets statically somewhere with an initial refcount of one. I am not saying this is the way to go. There will be issues with the coord cache for instance, but the idea is not completely ridiculous. > >I'm not saying this is easy, I'm sure there are a million little details > >that I haven't even considered. But (a) I *do* think that it may be > >easier than some of the things we want to be able to do if we stick with > >insets (toggling of character styles; 3-box-model); > > Not that difficult IMO but a whole lot cleaner. Right. > >and (b) much more > >importantly, I just think that the *concept* of inset is wrong; and > >using the wrong concept is bound to cost a lot later on, because the > >better the concepts used for coding match the "real concepts", the > >easier it will be to handle new, currently unforeseen situations --- > >just because the code will "behave" more closely to how the "real world" > >it is trying to represent behaves. > > Again you are mixing up look&feel and implementation ;-) And right. Andre'
