Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solutio
Brought to you by:
zappo
From: <kla...@ca...> - 2009-04-16 15:33:40
|
Hi all, Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results: 1. Start Emacs with semantic activated and load a elisp file X 2. Go to a tag T (e.g. a defun) 3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X 4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> 5. Go to the same tag T as in step 2 6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine! 7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun) 8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine! 9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2> 10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save! 11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer X<2> 12. Switch back to buffer X (the base buffer) and move point to tag T 13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X Summary: With this patch the indirect-buffer has the right buffer-information, which is good. Then the tag-lists seems to be completely independent, so editing one buffer does not influence not the other one - which is also good! What i'm wondering why running semantic-current-tag does not automatically return the newly reparsed tag but the old one (i assume from the semantic tag-cache) - see steps 9. and 13. above... Is this a correct behavior? The charme of indirect buffers is that editing takes effect in the base-buffer an all related indirect buffers: so if i edit (en edition which triggers a reparse!) a tag e.g. the base-buffer then the changes are also in the indirect-buffer so i would expect that when switching to the indirect-buffer (as in step 9) then semantic should recognize that also this buffer has been changed and therefore automatically reparse when i call semantic-curre3nt-tag (as is done in step 8 above)... Why does this not work? Is this because the tag-cache of semantic is file-centric? Or have i misunderstood something?? Conclusion: Eric's patch seems to be a great step forward but not perfect... ;-) Thansk for your help! Klaus -----Ursprüngliche Nachricht----- Von: kla...@ca... [mailto:kla...@ca...] Gesendet: Donnerstag, 16. April 2009 14:10 An: len...@gm... Cc: ced...@li...; er...@si... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea After playing a little bit i found other very mysterious behaviors: 1. Start Emacs with semantic activated and load a elisp file X 2. Go to a tag T (e.g. a defun) 3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X 4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2> 5. Go to the same tag T as in step 2 6. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X well, we know already this failure, but now lets go further 7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument to the defun, if T is a defun) 8. Do M-: (semantic-current-tag) --> semantic returns the repares tag T with the new informations, fine! 9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the reparsed tag T with new informations but still the wrong buffer X Well, same failure as after 6, but now it gets crazy 10. Now edit tag T in the indirect-buffer X<2>!! (e.g. remove the newly added argument from step 7) - do not save! 11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations but still the wrong buffer X 12. Switch back to buffer X (the base buffer) and move point to tag T 13: do M-: (semantic-current-tag) --> you get.................................... nil!! No tag T anymore in the base buffer after editing tag T in the indirect buffer..... Again: With current semantic working with indirect buffers yields to unpredictable side-effects. So either the users should get a warning not to work with indirect buffers and semantic or semantic should be fixed with that respect... Ciao, Klaus -----Ursprüngliche Nachricht----- Von: Lennart Borgman [mailto:len...@gm...] Gesendet: Donnerstag, 16. April 2009 12:33 An: Berndl, Klaus Cc: er...@si...; ced...@li... Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea On Thu, Apr 16, 2009 at 10:29 AM, <kla...@ca...> wrote: > A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging... I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow? ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Cedet-devel mailing list Ced...@li... https://lists.sourceforge.net/lists/listinfo/cedet-devel |