Yep, i agree - this is nothing which should be added to a after-change-function...
The logic is easy, ECB has already somehting:
(defun ecb-indirect-buffers-of-buffer (&optional buffer-or-name)
(let ((buffer (if (null buffer-or-name)
(if (and (bufferp buffer-or-name)
(if (stringp buffer-or-name)
(delq nil (mapcar (function
(if (equal buffer (buffer-base-buffer buf))
but within ECB this is only used on demand and then run only once...
Hmm, currently i'm at a loss with this... do not good enough the internal mechanisms of semantic... maybe this is something to be ask the Emacs-gurus - in general Emacs must already have a linkage between all these related buffers because if you kill the base-buffer then all indirect-buffers of it are killed automatically too...
IMHO this propagation of hooks-running should be done internally be Emacs...what do you think? Should we file a problem-report to the emacs-devel-group?
Von: Eric M. Ludlam [mailto:email@example.com]
Gesendet: Do 16.04.2009 19:49
An: Berndl, Klaus
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
Ah, I think I understand better.
It appears that the hooks I use to track edits don't work in linked
buffers. If you enable global-semantic-highlight-edits-mode, you will
see that it finds things you edit, but the mirror edits in the other
linked buffers do not get their change hooks run, and thus you don't
see the highlight.
I suppose I could look for all buffers that are linked together and
propagate the change. That seems kind of unpleasant as I can find no
function to get that info. I don't think an after-change-function
should be looping over every buffer looking for indirect buffers
associated with it. That sounds painfully slow.
>>> <firstname.lastname@example.org> seems to think that:
>Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not?
>To be clear:
>If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag.
>Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-)
>Is this ok too for you? Why?
>Von: Eric M. Ludlam [mailto:email@example.com]
>Gesendet: Donnerstag, 16. April 2009 17:47
>An: Berndl, Klaus
>Cc: Berndl, Klaus; firstname.lastname@example.org; email@example.com
>Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea
>>>> <firstname.lastname@example.org> seems to think that:
>>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??
>The command `semantic-current-tag', like many very basic commands, do
>not request a reparse. Reparses are requested by top-level commands
>before they call utility functions. This saves time since a single
>top-level command might call hundreds of low-level commands. Each one
>does not need to do the reparse duties. In particular, utilities like
>SRecode which edits buffers wants to be in control of when a buffer is
>reparsed, in case it is only part-way through a code-creation function
>when it needs to call some utility.
>Use the senator command `senator-adebug-tag' which will do the reparse
>for you. Or you can wait 3 seconds, and the idle timer will clean
>everything up for you.
>Does that help?