Re: [ECB-list] Using the partial reparse hook within ECB! (was: AW: ECB2.40 released!)

Hi Klaus,

  On tag IDs, there is something like the tag ID, though much more
subtle.  It is the cons cell that is the tag.  When a tag is reparsed,
the cons cell is recycled, so you can ask is this tag T eq to stored tag
sT.

  The tag id would be a challenge to keep straight, since you can't
associated a number a names (names change), and you can't associate them
with tag order, since new tags are inserted frequently, and you can't
associate them with buffer position, since that certainly moves around a
lot.

  What you can do, that might be quite easy for ECB, is you can store
your own ECB data as a property on the tag.  Properties are available
for applications to use to keep track of things, and are kept whenever a
tag is recycled.  Thus, you could put a property into a tag saying "I'm
open" so when a refresh occurs, you can keep it open or closed.  This is
even better than using the cons cell, since you would know if a tag was
seen by you before.

Does that help?  Dave P. and I debated how to track this info many
times, and found no happy solution.  Speedbar just keeps it's old cache
around until you ask it to refresh the tags.

I think this might also help with your other question too.  The partial
reparse hook is good when your application treats each tag as an
individual.  (ie, tag decoration mode).  You would need to use tag
properties to keep track of your tags if you want to use it for the tag
list as a group.

Eric 

On Wed, 2009-05-20 at 11:11 +0200, [email protected] wrote:
> Another idea for the problem: maybe we could add to a semantic-tag a new slot :tag-id which would be a generated unique (within the full taglist of a buffer) ID (e.g. a number) - this ID would and MUST be unchanged even if the tag itself has been reparsed and so e.g. a new tag-name - 
> 
> Example: suppose we have a class CCC with two methods MM1 and MM2.
> 
> Tag for CCC has :tag-id 1, MM1 has :tag-id 2 and MM2 has :tag-id 3
> 
> Now we rename method MM1 to MM2, this means that method MM1 will be reparsed an gets a new tag-name MM2 but the :tag-id is still 2
> Or we add a new parameter to MM1, here the same, MM1 must be reparsed but :tag-id is still 2...
> 
> If we add a new method MM3 then this new method gets a :tag-id 4. But in this case the class CCC itself is reparsed and the tag must be updated because it has a new function-children... But the :tag_id of CCC is still 1...
> 
> Then there is no need to change the semanztic of the partial-reparse hook: still only one argument: the list of updated tags - but now ECB can check the :tag-id of each tag and search in ist tree-buffer for a tree-node which has as data a semantic-tag which has the same :tag-id as a new updated tag - this tree-node must be updated....
> 
> The only things we would need:
> - An ID-generator in semantc (should not be so hard)
> - a new tag-slot :tag-id and a getter and setter-method (should be simple)
> - some changes in the tag-fetching/creating/updating-mechanism within semantic (can not judge the needed effort)
> - some small changes in ECB - but should be not so hard, most things i need are already there...
> 
> Eric, please tell me (in a hard and direct manner ;-) if this is nonsense what i have suggested? I'm not deep enough in your reparse/update-mechanism but currently this sounds good in my ears ;-)
> 
> Thoughts?
> 
> BTW: how speedbar deals with partial hook-updates (e.g. triggered by the idle-scheduler)??
> 
> Ciao,
> klaus
> 
> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:[email protected]] 
> Gesendet: Mittwoch, 20. Mai 2009 09:30
> An: [email protected]; [email protected]; [email protected]
> Cc: [email protected]
> Betreff: [ECB-list] Using the partial reparse hook within ECB! (was: AW: ECB2.40 released!)
> 
> Hi 
> 
> @Eric: i added you to this thread because IMHO we need your expertice and knowledge and advice ...
> 
> >So, the only remaining problem is that the methods buffer still expands 
> >whenever I start to edit.  (Adding (require
> >'python) doesn't help.)
> 
> Well, the (require 'python) was only meant to setup python-mode correctly fopr you...
> 
> Collapsing/expanding tags when you are editing:
> 
> Each time semantic decides that the buffer has to be reparsed to update the current tag-list to the current buffer contents semantic calls a hook which then in turn updates the ECB-methods window and rebuilds it completely which in turn displays all tags with their default-expand-state (which can be influenced by the options `ecb-type-tag-expansion' and `ecb-show-tags' - see the docstrings)...
> 
> BUT: To be honest, concerning this topic the problem is in ECB not in semantic, at least partly (Eric, nice to hear, isn't it? ;-)...the description above is only half of the story: semantic offers two hooks where tools like ECB can hook in to update their stuff when semantic performs a reparse, one of them is the `semantic-after-partial-cache-change-hook'. And now we came to one of the biggest TODOs on my TODO-list, unfortunately i have no really good idea about a solution - and now Eric, you can chip in ;-)
> 
> This partial-hook of semantic offers exactly these tags which must be updated not the whole tag-list of the whole buffer - fine - exactly what we would need not to update the whole ecb-window but only these nodes which represent the updated tags - if this would work the collapse-state of all other nodes would be untouched and the problem of Don would have been gone...unfortunately it's quite impossible for ECB to identify these nodes in ist ECB-window which represent the new update-tag-list offered by the partial hook.
> 
> @Don: probably the rest isn't very intersting for you, therefore here one short fact for you: your collaps/expand-problem is a known annoying behavior in current ECB and there is no solution - but maybe in the njext releases - but for this i have to discuss with Eric.....
> 
> @Eric: maybe it's the best i show you the current function ECB adds to the partial-reparse hook, because there are already some comments about the problem:
> 
> (defun ecb-update-after-partial-reparse (updated-tags)
>   "Updates the method buffer and all internal ECB-caches after a partial semantic-reparse. This function is added to the hook `semantic-after-partial-cache-change-hook'."
>   ;; TODO: Currently we get simply the whole cache from semantic (already up
>   ;; to date at this time!) and then we rebuild the whole tree-buffer with
>   ;; this cache-contents. This is slow for big sources. We should implement
>   ;; a mechanism where only the UPDATED-TAGS are used and only this ones are
>   ;; updated.
> 
>   ;; TODO: Klaus Berndl <[email protected]>: here we could check if
>   ;; UPDATED-TAGS contains only one tag and if this tag contains no childrens
>   ;; then we could use the new function `tree-buffer-update-node' to simply
>   ;; updating the associated node instead of a full reparse and then full
>   ;; tree-buffer-update.
>   (if (and (= 1 (length updated-tags))
>            (null (ecb-children-tags (car updated-tags))))
>       ;; TODO: Klaus Berndl <[email protected]>: 
>       ;; we could update this single node if we can find this node. But this
>       ;; could be difficult (or impossible?) because here we only know the new
>       ;; semantic-tag but our nodes contain only outdated semantic-tags as
>       ;; data so how to find the associated node??!!
>       ;; Maybe we could search the node which contaisn the parent-tag of the
>       ;; updated tag and then we compute the position p of this tag in the list
>       ;; of the children of its parent-tag and then we update that node which
>       ;; comes on the same position p in the list of childrens of the
>       ;; associated parent-node - hmm, but can we be sure that the sequence of
>       ;; children-tags and children-nodes is the same?? probably not because
>       ;; the nodes are ordered alphabetically and the tags are are ordered in
>       ;; that sequence they are code in the source-buffer! Hmmm...........
>       ;; Until this question is solved we must use the full reparse/rebuild
>       ;; :-( One possible solution: tempor. ordering the
>       ;; semantic-tag-childrens by name and getting the position p of the
>       ;; updated tag in that ordered tag-sequence...
>       (ecb-rebuild-methods-buffer-with-tagcache (ecb-fetch-semantic-tags))
>     (ecb-rebuild-methods-buffer-with-tagcache (ecb-fetch-semantic-tags))))
> 
> You see what is my problem?`How to identify these nodes in the methods-tree-buffer which holds as data an *OLD* outdated semantic-tag but should be updated with a new reparsed tag supplied by your partial-hook? 
> Example: let's say the buffer contains a function named "XXX" which has been renamed to "XXXX" - then i suppose semamtic runs only a partial reparse and the partial hook would suply exactly this new tag with a new tag-name "XXX" - how could ECB know that for this tag the tree-buffer-node representing the old tag "XXX" should be updated with new tag-data "XXXX"??? IMHO quite impossible  at least not really reliable...
> 
> The only solution which came in my mind is: Could semantic supply not only the new tags but also the old ones which have been infected by the partial reparse. In our example: semantic would not only supply the new tag "XXXX" but additionaly the old one "XXX" too. Would this be possible (AFAICS semantic should be able to access to old tag, right or false)? If possible then the next question is: what is the best data-structure?
> A) simply a new optional argument old-updated-tags for partial-hook functions which contains the old tags for these tags which have been reparsed - complete new added tags (for which no old one has existed) would have no equivalent in this new optional argument...
> B) a complete new structure for update-tags, e.g. a cons: where the car is a new tag and the cdr is the old equivalent, where the cdr can be nil for complete new tags (e.g. added function)..
> 
> Advantage of B) the exact correlation between new tag and old tag is much easier...
> 
> Eric, two questions?
> 1) Is my description of the problem understandable for you?
> 2) Can we solve this problem?
> 
> Thanks!
> 
> Ciao,
> Klaus
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Ecb-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ecb-list

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
_______________________________________________
Cedet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-devel