Re: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution
Brought to you by:
zappo
From: <kla...@ca...> - 2009-04-17 13:41:34
|
Yes, of course - the "full"-featured solution should do what you describe... BUT my suggestion was another one: at least we should ensure that an "indirectly" changed buffer (ie. changed via editing another buffer in the indirect-buffer-set) will be reparsed when this buffer becomes current for the user(!). IMHO for a first solution it would be sufficient to completely clear the tag-cache, so afterwards the buffer will be automatically fully reparsed ad all tags are uptodate... This can of course not use your incremental parsing mechanism you described. But better some full parse-runs as no parsing at all though it would be necessary... Maybe not the gold-medal, but sometimes bronze medal is also not bad - aftre that we can try to reach the gold-medal... Thoughts? Klaus -----Ursprüngliche Nachricht----- Von: Eric M. Ludlam [mailto:er...@si...] Gesendet: Freitag, 17. April 2009 14:11 An: Berndl, Klaus Cc: len...@gm...; ced...@li... Betreff: Re[1]: 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 possible. 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. Eric >>> <kla...@ca...> seems to think that: >Hi guys, > >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 =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 = 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 ;-) > >Thoughts? >Klaus > > >-----Urspr=FCngliche Nachricht----- >Von: Eric M. Ludlam [mailto:er...@si...] >Gesendet: Fr 17.04.2009 05:41 >An: Lennart Borgman >Cc: Berndl, Klaus; ced...@li... >Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with = >indirectbuffers?-some more findings and a solution idea =20 >>>> Lennart Borgman <len...@gm...> seems to think that: >>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam = ><er...@si...> wrote: >>> 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 > >--=20 > Eric Ludlam: er...@si... > Siege: www.siege-engine.com Emacs: = >http://cedet.sourceforge.net > > |