> You certainly have a dilemma. It is exactly this problem that made
> me attempt to make the new incremental parser more robust. I would
> also someday like to make the full-reparse go back and synchronize
> against old overlays and cons cells also.
Yes, this would be a real milestone in reparsing...
> Anyway, what you need to do here is, whenever you "cache" a token,
> make a marker object, and position it at token start.
>(let ((m (make-marker)))
> (move-marker m (semantic-token-start T))
> When you need to get back to the old token, you can do this:
> (goto-char m)
> and this will work perhaps 90% of the time. It will not work if T
> was deleted, or cut from one location to another. To protect
> against that, you need to do name compares or something similar.
Thanks for this hint - i had already tried this yesterday with copy-marker
instead of move-marker but it seems not to be fully satisfying me...
Now i have implemented it like you suggested with move-marker...and it seems
to be the best possible solution for now.
>>> "Berndl, Klaus" <klaus.berndl@...> seems to think that:
>suppose semantic 1.4.2.
>Further suppose that i have a semantic-token T (e.g. a function-token of an
>elisp-file F). T contains all informations of a function-token and therefore
>among others also a valid overlay.
>Ok, now suppose that i store this token in a certain own cache. Then a full reparse
>is done (either autom. or manually triggered) because i have changes something other
>in file F - the elisp-code to which token T belongs (i.e. the function) is unchanged.
>But after the full reparse the overlay of the token T stored in my own cache (i need it
>for certain purposes - at least the overlay-informations of the tokens) is invalid.
>(Eric, you remember we have discussed a related topic a long time ago?)
>Ok, it sounds understandable that after a reparse the old overlays are invalid because
>replaced by the new one (generated by the bovination/parsing run).
>But now i have a problem: I want to use the overlay-informations of my cached token T
>(need overlay-buffer overlay-start/end) but the overlay of T is now invalid cause of the
>reparse and there is a new token T' with a new valid overlay.
>Now i'm wondering how to resync my cache with the new tokens (ok, i could throw away
>the whole cache after a reparse but this would be bad because this cache stores a
>"navigation"-history similary back- and next-button of a webbrowser :-( or at least with
>the new overlays of the tokens.
>But for this i must recognize the the new generated token T' is equlivalent to the old token
>T (equivalent in the sense it is the token of the same unchanged function, has same argument-
>list etc. etc.) but i can not compare T and T' foe example with semantic-equivalent-tokens-p
>because this function needs for comparison the overlays and - remember - token T doesn't
>contain a valid overlay!
>To make a long story short: Any senseful or prakticable ways to check for token-equivalence if
>one of the token contains an INVALID overlay. AFAICS name, and type are not enough because for
>example in C++ files there can be method-declaration in the class and also the method-
>implementation outside of the class in the same file...hmm, this could be checked with adopted-
>Ok, anyway, thoughs? Or was my problem not described understandable??
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>Cedet-devel mailing list
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