>>> David PONCE <david.ponce@...> seems to think that:
>[ ... ]
>> I spoke too soon. I believe you had changes to the internal
>> structure of the tokens that we want to do first. AFAIK, all token
>> generators now use the new constructors, so it should be safe to do.
>The only question that remains is: what internal format to use to
>represent tags? It seems that you agreed with my latest proposal to
>use two plists, one for public "attributes" and another for "private"
>So the internal format could look like this:
>(NAME TAG-CLASS ATTRIBUTES PROPERTIES)
>where NAME is a string, TAG-CLASS a symbol (type, function, variable,
>code, etc.), and ATTRIBUTES and PROPERTIES are Emacs property lists.
>You suggested too, to add the overlay to the above data structure,
>that would become:
>(NAME TAG-CLASS ATTRIBUTES PROPERTIES OVERLAY)
>Am I right?
>In my idea, I considered the overlay as a particular "private"
>property of the tag, and thus, associated it with an internal
>":raw-data" private property. At tag creation that property would be
>a vector [START END] (maybe using a cons (START . END) would be more
>efficient, and consume less storage?), and would become an overlay
>after cooking the tag.
I don't remember why I chose a vector before.
>However, I probably miss something here. You certainly thought about
>something to take into account, when you suggested to distinguish the
>overlay in the data structure ;-)
>Can we state on a final data structure, we could work with?
[ ... ]
When we are done, I hope that the new data structure is relevant only
insofar as it provides 2 features:
1) Proof to ourselves that we can safely change it
2) A starting point for finding the optimal data structure for tokens.
Of course, that doesn't mean we shouldn't try to make is as useful as
possible now. ;)
To that end I captured some usage statistics:
As you can see, those functions that do something with the overlay
are used more than any other part of the token. I was guessing
before, but now I am sure that we want to put the overlay in an easy
to get to location.
It has turned out that the top 3 fields are the ones in the currently
proposed data structure, which is nice.
I had suggested using a vector before also. Functions like
semantic-token-overlay-cdr would then be quite difficult to implement.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org