Well, two points:
1) Now i'm convinced that we should use an advice if there is no hook which runs with BOTH(!) of clone-indirect-buffer and make-indirect-buffer (alos with XEmacs which have only the later one):
I have written a small test-avice for make-indirect-buffer which only contains the following code:
(message "return-value: %s, Cur-buffer: %s, base-buffer: %s"
ad-return-value (buffer-name) (buffer-base-buffer)))
This works well and we see how it works...just replace the message-call with the cache clearing and we are fine... this after advice is save and can not fail so we can do it ... if we are paranoid we could encapsulate in a call to condition-case nil...... ;-)
2) I think i have found a way how to detect very fast the indirect-buffer-set of a buffer without looping each time over the whole buffer list: we do this via the advice above and within kill-buffer-hook! :-)
We write a small framework which makes a smart storage of the current indirect-buffer-list of each opened base-buffer, e.g. an alist with key is a base-buffer and value is the list of all related indirect-buffers to the base-buffer... This storage we administrate with the advice of make-indirect-buffer and with kill-buffer-hook so this storage is always up-to-date...
Then you can use in your after-change-function this indirect-buffer-storage to propagate... shouldbe fast because we can use `eq' and buffer-objects... if still to slow we could add a further alist which contains an entry for each(!) current opened file-buffer (regardless if a base- or an indirect one), and car is a buffer-object and cdr is the base-buffer for this buffer - so we have a two step storage...
see the answer to my emacs-bug-report....
Von: Eric M. Ludlam [mailto:email@example.com]
Gesendet: Fr 17.04.2009 14:11
An: Berndl, Klaus
Cc: firstname.lastname@example.org; email@example.com
Betreff: Re: AW: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
CEDET/Semantic will track tiny changes in a buffer based on the
after-change-functions. Those changes are just noted with overlays.
Once Semantic goes to update the tags in the buffer, it takes these
overlays, and merges them together to find out which tags changed. It
will then reparse those text units, and splices the results into the
original list, attempting to keep as much of the old structure as
As the indirect buffer might be in a different mode, and have a
completely different parser, all changes in it must be tracked as
completely separate and reparsed completely separately.
So long as Emacs doesn't propagate the calls to the change function,
we'd need to do that propagation of change ourselves. If, as you
suggest, you can quickly get the list of linked buffers, this should
be ok to do in the change hook. I don't know if propagating the
changes later will help in this case. Just the notification is not
enough since I need all the data of location as well.
>>> <firstname.lastname@example.org> seems to think that:
>first a definition: let us name all buffers having an =
>indirect-buffer-relationship among each other as a 'indirect buffer set' =
>- this includes exactly one file-based base-buffer and an arbitrary =
>number of indirect-buffers to this base-buffer...
>after fixing a very small bug in ECB i found that it could be sufficient =
>a) has the current active buffer switched by the user (e.g. by switching =
>window, buffer etc...), i.e. is now another buffer current compared to =
>the last run of this check
>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not =
>thinked in depth about this...maybe this check is not necessary or even =
>c) has been one of the buffers of the indirect-buffer-set changed / =
>If a, b and c are all true then clear the toplevel cache of semantic and =
>fetch the tags =3D=3D> this will return the right tag-set containing all =
>changes previously made in another buffer of the indirect-buffer-set.
>Encapsulate this in an idle-function which runs e.e. each second and =
>checks a - c (s.a.) - at least a is very fast checkable (ECB does this =
>already for its own sake) - so when editing in a buffer a) always fails =
>and therefore no checks for b and c are necessary =3D=3D> no performance =
>E.g. see `ecb-basic-buffer-sync' - search for =
>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in =
>ecb-file-browser.el (CVS-version) which already checks condition a.
>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i =
>sent to you).
>Condition c: Hmm, do not know exactly what is here necessary - maybe it =
>is already enough to check if that buffer has changed which was previous =
>before switching to the current one [a) compares already these two]?! =
>Eric. Lennart, you are the semantic guys, i'm sure you know a solution =
>for c) ;-)
>Summary: With such a mechanism no realtime-propagation is needed during =
>editing a buffer etc.. the only thing a user wants is, that when he =
>edits a buffer of a indirect-buffer-set (see definition at beginning) =
>and he later switch to another buffer of this set then this other buffer =
>should be automatically be reparsed to reflect (e.g. this means in ECB: =
>display) the correct tag-set (including the changes made in the other =
>buffer of the indirect-buffer-set)... For a user it's equal if the =
>tag-info-changes in one buffer of an indirect-buffer-set are immediately =
>propagated to all other buffers of such a buffer-set, he only wants to =
>get the right tag-set when he *activate* another buffer of the =
>Well, now a short question: Was my description understandable for you? =
>Sometimes it's not easy for me being as precise and clear as necessary =
>when writing in english ;-)
>In general I'm now quite optimistic that there can be found a solution =
>for the problem without performance-issues.... and without two much =
>effort to implement ;-)
>Von: Eric M. Ludlam [mailto:email@example.com]
>Gesendet: Fr 17.04.2009 05:41
>An: Lennart Borgman
>Cc: Berndl, Klaus; firstname.lastname@example.org
>Betreff: Re: [CEDET-devel] Is Semantic able to work with =
>indirectbuffers?-some more findings and a solution idea
>>>> Lennart Borgman <email@example.com> seems to think that:
>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =
>>> Propagating change-hook calling as a part of Emacs could be a bit
>>> hazardous. =A0Many change hooks might be redisplaying interactive
>>> things, and assume that they are called in the current buffer the
>>> focus is in. =A0That could get a bit wacky.
>>Aren't the change hooks run in the indirect buffers too?
>Yes, but only when the indirect buffer is the current buffer. Or so
>it seems the way I'm using it. An edit in one buffer does not trigger
>my hooks in the other buffers to run.
>I've only been able to run some simple experiments, so I don't know
>in any great detail hat is going on.
> Eric Ludlam: firstname.lastname@example.org
> Siege: www.siege-engine.com Emacs: =