Re: Bugs introduced that affected jde-import-all (insert semantic tag)

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev