Re: [jdee-devel] Bugs introduced that affected jde-import-all (insert semantic tag)
Brought to you by:
paullandes
From: Eric M. L. <er...@si...> - 2010-01-09 22:05:30
|
Hi Jeff Peck wrote: > Eric, this is encouraging. > Without going all the way to srecode templates *today*, > Can you say what is the appropriate incantation to insert a tag into the > 'database'? > I can do: (semantic-tag-new-include new-import nil) to create the tag, > but how to i make that tag visible to the rest of semantic? > [so it will be found by: (semantic-brute-find-tag-by-class 'include > (semantic-fetch-tags)) ] When a buffer is parsed with the java grammar it has to fabricate the tag data structures. For example, in wisent-java-tags.wy you will see: import_declaration : IMPORT qualified_name SEMICOLON (INCLUDE-TAG $2 nil) | IMPORT qualified_name DOT MULT SEMICOLON (INCLUDE-TAG (concat $2 $3 $4) nil) ; The INCLUDE-TAG is a wisent macro that expands to (semantic-tag-new-include ...) Thus, if you use the code as you quoted above, it just creates a data structure, but doesn't insert it into a buffer, a data structure, or anything else. To make it discoverable, you need to explain why it should be discoverable. Ie, should it be a part of a buffer tag list? In that case, you would just modify semantic--buffer-cache, though I recommend against that. If you have some constant list of tags that should always be referenced, such as a library or something derived from a .jar file, then you would make a new kind of Semantic database object, much like that found in semanticdb.el, which will be accessed by search routines for your files. In CEDET/CVS, there is a prototype for accessing jar files that Joakim wrote. >> srecode specifically knows how to insert tags, so you could do this: >> >> (srecode-insert-tag (semantic-tag-new-include "myInclude" nil)) > I'm using cedet-1.0pre6 and do not find a "srecode-insert-tag" Sorry, it is srecode-semantic-insert-tag. >> ... I have a rough template already that would probably need a real >> java programmer to improve it. > > If you have something, send it along! It is easy to try. If you have CEDET/CVS, enable global-srecode-minor-mode. Then try this: Visit /tmp/new.java C-c / / ;; srecode-insert The default it offers should be file:empty. Press RET You now have some misc java code inserted. Go where you want to add an import statement. Type: C-c / / ;; srecode insert It should offer declaration: Add "import", and it should insert an import statement, or bits of one anyway. Things change a bit here depending on which version of the template file you have and if you have field-editing turned on or not. > Also, if you have any theory why doing a (semantic-parse-changes) works > when evaluated as a separate command, but not as around/after advice, > that might also be helpful information. The incremental parser will short-circuit and do nothing whenever the quotes ", or parens {, (, [, etc don't match up. You can set semantic-edits-verbose-flag to non-nil to get additional messages about when the partial reparse needs to bail. > CEDET is really great stuff, but I haven't found the magic decoder ring > to explain the design/threory behind it; and there is so much there, with > many levels of tools and abstraction that it is difficult to 'discover' > a way in. Please ask questions if you have something specific you need to understand. I like answer specific questions, as often that helps me update update the doc. Otherwise the doc is a good place to start. As for how buffers are updated, there are several states a buffer can be in. If you use semantic-load-enable-semantic-debugging-helpers, it will turn on several things I've mentioned so far. One new one is 'show-parser-state-mode'. This will show a small character combo in the mode line on the left. Check the help for the meaning. You will see that there are several states: `-' -> The cache is up to date. `!' -> The cache requires a full update. `~' -> The cache needs to be incrementally parsed. `%' -> The cache is not currently parseable. `@' -> Auto-parse in progress (not set here.) Thus, if you are in a debugger stepping through code, you can now see what the current buffer parse state is, which could also help explain what you see. A typical buffer life cycle goes like this: file loaded - requires full update idle timer goes off - cache up to date user edits - cache needs incremental parse idle timer goes off - not currenty parseable (user added on ( for example) user edits - no change in state idle timer goes off - cache is up to date (parens now line up) Every once in a while, user edits might force a full reparse, but that is (hopefully) rare. Usually happens when you wrap or unwrap large parts of a buffer in new { }. The incremental parser is a bit finicky in what it can do. The chars all need to line up, otherwise it leaves the buffer un-reparsed. Enjoy Eric |