>>> "David PONCE" <David.Ponce@...> seems to think that:
>> A while back, we had a discussion about semantic token formats, and
>> concocting a single function for constructing them. Then both parsers
>> could use them to create tokens, and once that was safe, we could
>> change the underlying storage. (If desired).
>> I'm going to take a first stab at this. Eventually, I'll check in
>> semantic-token.el with elements from semantic-fw and semantic-util in
>> it. After that, I'll build the constructors. Then we can look at
>> porting old parsers to the new constructors.
>Will you use EIEIO objects to represent tokens or a simpler (more
>efficient?) property list approach, or a different mechanism?
>Anyway, that would be a great enhancement, that would probably require
>important changes to the existing code ;-)
[ ... ]
I intend to use the same internal format as before, and it may stay
that way for a while, until we are sure we have found and fixed all
code that may be using it. It is unclear to me how much ECB or JDE
or other unknown tool may be using that structure. Afterward, who
As far as new APIs are concerned, I was thinking a generic plist based
approach would be for generic access. It would work for any of the
mechanisms you suggest. Standard tokens (as described in the manual)
may get their own optimized constructors.
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