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

Hi,

If you have code:

------
package foo;

class foo {};
------

and change it to:

------
package foo;
import bar;

class foo {};
------

then the incremental reparse engine treats this is three regions.  There 
is the import foo region, the class region, and the region of whitespace 
between the import and class.  It will "Parse" between the package and 
class statements, and splice those tags in.

All you need to do is call 'semantic-fetch-tags', which will also call 
semantic-parse-changes first.  If that fails, it will try a full reparse 
of the whole buffer, and if that fails (or if it predicts the full 
reparse would fail) then it does nothing.

I cannot divine from your examples so far what makes it special such 
that the fetch tags doesn't splice in the new import, unless you code is:

(insert "...")
(semantic-find-tags-by-whatever ...)

in which case, the find does not automatically reparse.  Many semantic 
APIs do not request a reparse, since if you are in the middle of 
modifying a buffer, you probably don't want a reparse, since the old 
state is more valuable than what might be a messed up state.  Thus, when 
your code knows the buffer state is good for parsing, it needs to call 
semantic-fetch-tags.

Eric

Jeff Peck wrote:
> Ok, now we are getting down to it!
> The code you outline is exactly the way it is currently set up.
> 
> The interesting and troublesome case is when 
> (semantic-find-tags-by-class 'include)
> return null; that is: when there are currently no import statements in 
> the buffer,
> so semantic-parse has not found/recorded any import statements.
> 
> In that case, we look for a 'package' statement and insert after that,
> or lacking a 'package' we find the first 'class' statement and insert 
> before that...
> 
> That is when we (insert (concat "import" new-import "\n")).
> 
> Now: since this is being inserted between the 'packge' clause and the 
> 'class' clause,
> is is not really modifying any of the existing tag regions...
> and so does not automatically get noticed by a simple reparse.
> 
> Which brings the question: when we do this insert, which will create the 
> first 'import-tag,
> What incantation is appropriate to cause a reparse that will find the 
> new tag?
> 
> Empirically, I find that this works:
> (semantic-fetch-tags)(semantic-parse-changes)
> But is that correct, optimal, or just lucky?
> 
> ----- Original Message ----- From: "Eric M. Ludlam" <[email protected]>
> To: "Jeff Peck" <[email protected]>
> Cc: "JDEE Development" <[email protected]>
> Sent: Saturday, January 09, 2010 6:58 PM
> Subject: Re: [jdee-devel] Bugs introduced that affected jde-import-all
> (insert semantic tag)
> 
> 
>> Hi Jeff,
>>
>> Semantic-fetch-tags is an interface to get you the list of tags in the 
>> current buffer as quickly as possible.  That's why the buffer has a 
>> parser state, such as 'up to date' or 'needs reparse'.  It checks to 
>> see what the current state is and does the fastest parse trick 
>> possible and then returns the cache.  If the buffer is up to date, it 
>> returns the cache.  If it needs reparse, it runs the incremental 
>> reparser.  If the buffer is in a bad state, it returns the cache, and 
>> marks the buffer that it needs a full reparse sometime in the near 
>> future.
>>
>> The only proper way to get a tag into the buffer cache is to have the 
>> text in the buffer, and have the buffer get reparsed.  It is possible 
>> to splice your own tags into the cache, but that has the possibility 
>> of corrupting the cache.
>>
>> In Semantic parlance, the "cache" is the list of all tags in a buffer. 
>> A "table" is a tag list associate with a file/buffer.  A "database", 
>> is a set of tables, usually associated with a directory, or a 
>> specialized tag source, like GNU Global, or a Jar file.
>>
>> If I understand your question correctly, you want to scan through the 
>> tags, find a good spot to put a import statement, then add an import.
>>
>> Finding the location, if the file is organized in a classic way, would 
>> be as simple as:
>>
>> (goto-char (semantic-tag-end (last (semantic-find-tags-by-class 
>> 'include))))
>>
>> doing the insert, you probably then want to do an:
>> (end-of-line)
>> (insert "\n")
>> (insert "... whatever")
>>
>> Once that is done, a 'semantic-fetch-tags' will update the buffer 
>> cache. If you need to actually know if the refresh was successful, 
>> then you probably want to use semantic-refresh-tags-safe, which 
>> provides a status.
>>
>> For SRecode, I have indeed contemplated the idea of inserting a tag, 
>> and splicing the known text back into the tag list as a speedy way of 
>> modifying the buffer, but I found that the parsing speed is just fine, 
>> and the 'inhibit-change-hooks' trick I posted about earlier keeps 
>> things running quickly.
>>
>> Does that help?
>> 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