Dov Feldstern wrote:
Why do I think that this question is related to "inset-ness"? Because of
the collapsible nature of most insets: collapsing an inset is basically
replacing the text in question with a black box of a known type. (Again,
math stands out, since it is not collapsible. And we're going to see
math standing out a lot. I think math is a special case, where a major
reason for having it as an inset is the fact that the input method is
so very different from "normal" text.) The fact that we can set a
certain type of inset to be non-collapsible is quite beside the point:
it's just another indication of the fact that perhaps that type of inset
need not be an inset at all...
I think you are mixing up the implementation point of View and the
Look&Feel point of View. We can make whatever we like with inset. If we
decide that pressing [Delete] in from of a charstyle inset should not
delete the inset but "enter the inset and delete the first char" then
it's easy enough to implement. But this is look&feel.
On the implementation point of view, charstyle as inset has *many* benefit:
- shorter code
- cleaner code
- generic code
2) Does the text in question "belong to" the proposed inset / markup? If
the attribute which the markup is supposed to endow were to be deleted,
should the contents be deleted as well? If the answer is that "the
contents belong to the markup, and should be deleted along with it",
then this is an inset. If the contents exists independently of the
markup, and should remain intact even if the markup is removed, then
this is *not* an inset.
It's the same as math really or graphics if you prefer. Those _are_
insets and belong to the text too. So that's not a valid point IMHO.
I can think of two possible implementations for storing these attributes
in the memory buffer:
1) spans --- which is how font attributes work today;
And which is horribly complicated...
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! ;-)
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.
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 ;-)
Abdel.
