Re: [CEDET-devel] Incremental parser problem
Brought to you by:
zappo
From: David P. <Dav...@wa...> - 2002-11-21 09:47:32
|
Hi Eric, [...] > Do you have a reliable reproducible case=3F Here it is ;-) 1. Create the following simple test.java file: class test { void method1() { } void method3() { } } 2. Save the file, close the buffer, and open it again to get a clean cache like this: (("test" type "class" (("method1" function "void" nil nil nil ((reparse-symbol . class_member_declaration)) #<overlay from 19 to 39 in test.java>) ("method3" function "void" nil nil nil ((reparse-symbol . class_member_declaration)) #<overlay from 48 to 68 in test.java>)) nil nil nil nil #<overlay from 1 to 73 in test.java>)) 3. Just insert a new declaration between `method1' & `method3', like this: class test { void method1() { } int i; void method3() { } } The incremental parser should say: "Inserted tokens: (i)" and you would be able to navigate to the new token using senator (which uses the overlays) :-) But M-x bovinate still shows: (("test" type "class" (("method1" function "void" nil nil nil ((reparse-symbol . class_member_declaration)) #<overlay from 19 to 39 in test.java>) ("method3" function "void" nil nil nil ((reparse-symbol . class_member_declaration)) #<overlay from 57 to 77 in test.java>)) nil nil nil nil #<overlay from 1 to 82 in test.java>)) The new token is not in the cache, it is only in the buffer :-( A side effect is that the semantic imenu (built from the cache) will never show the new `i' variable token. As I wrote all the above I wonder if rebuilding the cache from tokens in the buffer (that is from the hierarchy of 'semantic' tagged overlays) could be possible=3F I can see the following benefits to a such solution: - side effect free - no more need for splice functions - buffer/cache consistency The main drawback could be a slow down of the incremental parser when processing large token trees. Hope it helps. Thanks! David |