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 to detect:
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 forbidden?!
c) has been one of the buffers of the indirect-buffer-set changed / reparsed etc...
If a, b and c are all true then clear the toplevel cache of semantic and fetch the tags ==> 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 ==> no performance lack...
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 buffer-set!
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:firstname.lastname@example.org]
Gesendet: Fr 17.04.2009 05:41
An: Lennart Borgman
Cc: Berndl, Klaus; email@example.com
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
>>> Lennart Borgman <firstname.lastname@example.org> seems to think that:
>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <email@example.com> wrote:
>> Propagating change-hook calling as a part of Emacs could be a bit
>> hazardous. Many change hooks might be redisplaying interactive
>> things, and assume that they are called in the current buffer the
>> focus is in. That 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: http://cedet.sourceforge.net