Hi,
I'm not familiar with the first problem you mention of a tag with no
name. I'll need to investigate that one.
You should try `semantic-show-parser-state-mode'. When you edit, it
puts the buffer in a "needs partial reparse" state. If a partial
re-parse fails, it will wait leaving the buffer in an "needs partial
reparse" state. Otherwise, it puts the buffer back into an all-parsed
state.
If a partial-reparse is requested by an application (ie, because you
want to do a completion, and that parse fails, it puts the buffer into a
"needs full reparse" state instead, and will just use whatever tags it
has left over until that happens. (Usually, in idle time) Sometimes
the entire bottom half of a buffer gets marked as unparsable (see
`semantic-show-unmatched-syntax-mode'.) This should only happen if a
parse is forced in the middle of a set of edits.
ECB can query the current buffer parser state with a series of
functions, such as `semantic-parse=tree-unparsable-p', or
`semantic-parse-tree-needs-update-p'. If you find the tree is getting
reset to a full-reparse too often, you could choose to do nothing if
`semantic-parse-tree-needs-rebuild-p' is true. That might help.
I last worked on this stuff a very long time ago. If you find a
particular case where the behavior should change, lets work out what
that case is and see if we can get it fixed.
Eric
On Sun, 2009-05-24 at 19:12 +0200, klaus.berndl@... wrote:
> Hi Eric,
>
> Another behavior:
>
> When deleting a function in elisp code then the partial hook is called with that deleted tag but without an overlay but instead a beg/end-arry where beg = end...
>
> All these somehow strange partial reparsings lead me to the question:
> Can you please explain when a partial reparse is done and when a full fetch? Iirc you said i have only to deal with tags with overlays - but now i know at least one case where a tag without an overlay is partially reparsed (s.a.)...
>
> BTW: aside from that i now have up and running partially updating tree-nodes when tags are partially reparsed - works like a charme...:-) your hint about overlay-properties was the breaktrough - thanks!
>
> Thanks for explanation!
> Klaus
>
> -----Ursprüngliche Nachricht-----
> Von: Berndl, Klaus
> Gesendet: Samstag, 23. Mai 2009 06:23
> An: 'eric@...'
> Cc: cedet-devel@...
> Betreff: AW: AW: AW: AW: AW: [ECB-list] Using the partial reparse hookwithin ECB!(was: AW: ECB2.40 released!)
>
> Hi Eric,
>
> One remark to the partial parse: When deleting an argument of a function then this is partially reparsed by semantic but the provided updated tag is a tag with an empty name! IMHO somehow clumsy and not what a user would expect... A nameless tag is useless and in fact it isn't a tag... Semantic should not provide such an empty tag but it should either reparse the "parent-function" and provide that tag with the new argument list (now one arg less) or do a full reparse...
>
> What do you think?
>
> Ciao,
> Klaus
>
> -----Ursprüngliche Nachricht-----
> Von: eric@... [mailto:eric@...]
> Gesendet: Donnerstag, 21. Mai 2009 21:27
> An: Berndl, Klaus
> Betreff: Re: AW: AW: AW: AW: [ECB-list] Using the partial reparse hookwithin ECB!(was: AW: ECB2.40 released!)
>
> Hi,
>
> The overlay object is shared between the clone and the original tag. What is not shared is the cons cells that make up the tag, or the tag property list. In addition, the overlay is re-used when a tag is reparsed, unless it is a full reparse of the whole buffer. In that case, you would just get the old behavior. If an old tag gets split in two (ie, you create a new fcn out of the bottom half of an old
> function) then in that case the overlays gets replaced. (ie, no
> re-use) Deletes will also, naturally, delete the overlay.
>
> A question from your previous email was about the overlays in which tags. The only tags (or clones of tags) that have overlays are for tags in buffers. Tags in files that are not in a buffer have a vector, such as [ 123 456 ] that represents the start and end location of the tag. As such, you can't put properties on them. This also means that you may not need to store any information in them, since they will never be reparsed. They won't be reparsed, because they are not in a buffer, which means you aren't editing the file.
>
> Does that help?
> Eric
>
> klaus.berndl@... seems to think that:
>
> > Hi Eric,
> >
> > i have played a little bit with overlay-put and overlay-get with
> > semantic-tags... seems to be cool because props stored in the
> > overlay are as in the original buffer-tag and the clone - seems the
> > overlay is shared (or whatever this means)....
> >
> > Now a question: when semantic partially reparses a tag, is then the
> > old overlay reused, even if the tag-space enhances or shrinks (e.g.
> > if deleting a line in a function-body)??
> >
> > If yes, then this would ber very good for my needs...
> >
> > Ciao,
> > Klaus
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Berndl, Klaus
> > Gesendet: Do 21.05.2009 15:30
> > An: eric@...
> > Betreff: AW: AW: AW: AW: [ECB-list] Using the partial reparse hook
> > within ECB!(was: AW: ECB2.40 released!)
> >
> > Hi Eric,
> >
> > the idea with storing a property in the overlay sounds promising,
> > because the clone tags contain indeed the overlays....
> >
> > But what did you mean with "...You only have to worry about reparse
> > information on tags
> > with overlays, therefore you could just put stuff there.."?
> > of course i know overlay-put and overlay-get put i somehow assume
> > that you have a certain
> > overlay in mind i should deal with, right?
> >
> > If yes, could please provide a short 2-line example how to store a
> > property in that
> > overlay of a tag you mean?
> >
> > BTW: are properties preserved when cloning a tag?
> >
> > another idea could be to link clones together, ie. storing that tag
> > in a clone which has
> > been clones so for ECB it would be easy to store an own property in
> > the buffer-tag,
> > not in the clone...
> >
> > Thanks for your patience ;-)
> > Klaus
> >
> > _________________________________________________________Klaus
> > Berndl / Capgemini sd&m / München Business Development Manager /
> > Bereich BankenTel: +49 89 63812 392 / Fax: +49 89 63812 220 /
> > http://www.de.capgemini-sdm.comMobil: +49 162 2842 051 /
> > klaus.berndl@... sd&m AG, Carl-Wery-Str. 42,
> > 81739 München Zusammen. Für nachhaltigen
> > Erfolg._________________________________________________________Vorstand:
> > Edmund Küpper (Vorsitzender), Burkhard Kehrbusch, Rüdiger Azone,Dr.
> > Uwe Dumslaff, Kai Grambow, Dr. Michael Rading, Josef
> > RannerAufsichtsrat: Pierre Hessler (Vorsitzender)Sitz und
> > Amtsgericht: München HRB 126057
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Eric M. Ludlam [mailto:eric@...]
> > Gesendet: Do 21.05.2009 13:08
> > An: Berndl, Klaus
> > Betreff: Re: AW: AW: AW: [ECB-list] Using the partial reparse hook
> > within ECB!(was: AW: ECB2.40 released!)
> >
> > Hi Klaus,
> >
> > I don't have a complete and short answer for you today. I'll
> > propose some random possibilities instead.
> >
> > First, if you look in cogre/cogre-semantic.el, you will find two
> > functions. Once is cogre-refresh-tag, and the other is
> > cogre-peer-update-from-source. COGRE also makes copies of tags, but
> > needs to go back, and make sure those tags are up to date once in a
> > while. (Such as when a cogre diagram is re-loaded from disk.) You
> > could use this to find the original tag, and apply your properties.
> >
> > There could be performance issues. My other thought was that I
> > could add information in the tag clone during the adoption. I'm not
> > sure what that might be.
> >
> > Lastly, instead of using tag properties, you could use overlay
> > properties. You only have to worry about reparse information on tags
> > with overlays, therefore you could just put stuff there. Your adopted
> > tag clones I think still have the overlays associated with them. Tags
> > w/out overlays would not need special properties since they won't get
> > reparsed.
> >
> > Thoughts?
> > Eric
> >
> > On Thu, 2009-05-21 at 08:40 +0200, klaus.berndl@... wrote:
> >> Hi Eric,
> >>
> >> in general i'm very happy with the put and get stuff... with one
> >> exception:
> >>
> >>
> >> ECB post processes first the fetched tag-list with
> >> semantic-adopt-external-members in codes like c++ and also elisp...
> >> the tree-nodes will e build up with the new post-processed tag-list .
> >> And adopting makes clones of tags, clones of the members and also of
> >> that type-tag which adopts the external members...
> >>
> >> How to link??? the tag in the buffer is not the tag which is stored
> >> in the tree-node because the latter one is a clone, ie. a different
> >> lisp-cell...so if i store a property in the clone it will get lost
> >> after fetching again tags from the buffer....
> >>
> >> Currently i have no clue how to solve this... Do you have an idea?
> >>
> >> Thanks a lot
> >> Klaus
> >>
> >> _________________________________________________________Klaus
> >> Berndl / Capgemini sd&m / München Business Development Manager /
> >> Bereich BankenTel: +49 89 63812 392 / Fax: +49 89 63812 220 /
> >> http://www.de.capgemini-sdm.comMobil: +49 162 2842 051 /
> >> klaus.berndl@... sd&m AG, Carl-Wery-Str. 42,
> >> 81739 München Zusammen. Für nachhaltigen
> >> Erfolg._________________________________________________________Vorstand:
> >> Edmund Küpper (Vorsitzender), Burkhard Kehrbusch, Rüdiger Azone,Dr.
> >> Uwe Dumslaff, Kai Grambow, Dr. Michael Rading, Josef
> >> RannerAufsichtsrat: Pierre Hessler (Vorsitzender)Sitz und
> >> Amtsgericht: München HRB 126057
> >>
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: eric@... [mailto:eric@...]
> >> Gesendet: Mi 20.05.2009 15:04
> >> An: Berndl, Klaus
> >> Cc: ddwiggins@...; ecb-list@...;
> >> cedet-devel@...
> >> Betreff: Re: AW: AW: [ECB-list] Using the partial reparse hook within
> >> ECB!(was: AW: ECB2.40 released!)
> >>
> >> klaus.berndl@... seems to think that:
> >>
> >> > Hi Eric,
> >> >
> >> > Wow, sounds pretty good... But first some questions:
> >> [...]
> >> > Q1: There is a comment that these functions are for internal use
> >> > only - what does this mean for ECB? Is it reliable when ECB uses
> >> > these functions for that needs you suggested??
> >>
> >> Ah. They are marked as internal. I haven't given that too much
> >> thought since this was first written. I've been using tag properties
> >> for miscellaneous things that might not be considered private.
> >>
> >> Let's figure out what you want to do in specifics, and then I'll make
> >> an API for that that is not considered private. For example, there
> >> is semantic-tag-add-hook and semantic-tag-remove-hook. Ther are some
> >> special hooks you can apply to a tag so you can find out when "stuff"
> >> happens to it. There is also semantic-add-label and
> >> semantic-show-label which seem like some high-level hacks that never
> >> got used.
> >>
> >> If these existing functions work fine, then that is ok too. ECB and
> >> CEDET have always been closely related, and that API is unlikely to
> >> change.
> >>
> >> > Q2: Are these the right functions - which ones i would need - i
> >> > assume semantic--tag-put-property and semantic--tag-get-property -
> >> > what about semantic--tag-put-property-no-side-effect? If i have
> >> > undrestood you in the right way, this is not the right one for my
> >> > needs, right?
> >>
> >> You want to take the raw tag directly from the buffer and use the
> >> put/get functions, and not use the 'no-side-effect' function. That
> >> way you will get your properties back out of the buffer again later.
> >>
> >> > Q3: are properties stored permanantly in the semanticdb and
> >> > semantic.caches? I assume not. So when a buffer is opened then all
> >> > tags are without any private properties right? Just to get sure,
> >> is
> >> > fine for me and ECB
> >>
> >> No properties are saved in the persistent database file except for
> >> those used by the parsing engine. Properties also get flushed if a
> >> full reparse of a buffer occurs.
> >>
> >> > Q4: is there any example out for the right usage of these
> >> functions,
> >> > ie. A "real live" example? ;-) In the info-manual of semantic i
> >> > fund only the function-description, i.e. there docstrings....
> >>
> >> There are the simple add/remove hook functions and add/show label I
> >> mentioned above.
> >>
> >> There is also semantic-foreign-tag-p and semantic-tag-file-name that
> >> use these properties.
> >>
> >> There is semantic-decorate.el which stores overlay information.
> >>
> >> cogre-mode.el uses properties to tie cogre nodes to tags.
> >>
> >> semantic-symref.el uses properties to store some statistical
> >> information.
> >>
> >> They are meant to be like 'get' and 'put' in usage.
> >>
> >> > Q5: my approach would be:
> >> > 1. i add to semantic-after-partial-cache-change-hook and
> >> > semantic-after-cache-change-hook the same function which always
> >> gets
> >> > the full tag-list after a reparse (maybe from the semantic-cache
> >> or
> >> > fully reparsed, anyway)
> >> > 2. This function creates for each tag an appropriate tree-node and
> >> > adds the identifier for this tree-node as property-value for a new
> >> > ECB-property like 'ECB-tree-node which indicates, that this tag is
> >> > displayed in the tree-buffer and in which tree-node. After that
> >> this
> >> > property is stored in the tag itself, right? The modified tag is
> >> > stored in the :data-slot the tree-node itself.
> >> > 3. Then i build up the tree-buffer of ECB based on the tree-nodes
> >> of
> >> > step 2 und display the tree-buffer <4. the user does some editing>
> >> > 5. some tags are updated by semantic 6. The hooks of step 1 above
> >> > are called and ECB gets again the
> >> full
> >> > tag-list for current source-buffer
> >> > 7. i check if a tag contains the ECB-property 'ECB-tree-node and
> >> get
> >> > so the information if the tag is currently already represented by
> >> a
> >> > tree-node and by which tree-node - if yes, then i can easily
> >> update
> >> > the tree-node with the modified tag-data ....
> >> >
> >> > Is this somehow right, is it that what you want to suggest? If
> >> yes,
> >> > then this is pretty cool idea and should be not so hard to
> >> > implement...
> >>
> >> Yes, this is what cogre does in one of its code generation steps.
> >> One
> >> difference is that if a full reparse occurs, all the property
> >> information is flushed. I've often wondered how to recover the
> >> property information after a reparse. It might be possible, but it
> >> has not been attempted.
> >>
> >> Good Luck
> >> Eric
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
|