Thread: 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 |
From: Eric M. L. <er...@si...> - 2002-11-22 12:59:12
|
>>> "David PONCE" <Dav...@wa...> seems to think that: >Hi Eric, > >[...] >> Do you have a reliable reproducible case? > >Here it is ;-) > [ ... ] I checked in a fix for this problem. The insert issue now works. I tested remove, but it kept doing a full reparse. I need to look into that still. The problem was with semantic-nonterminal-children, and asking for tokens with a position only. This caused it to return a fabricated list. Have fun Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |