Andre Poenitz wrote:
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.
Oh I agree that the inset index (or even address) as char_type is
interesting. I was just objecting to replacing those 4 bytes with a
bigger structure containing the char_type itself and its attributes.
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.
We are suspiciously in phase lately...
Abdel.
