bug#3018: Re[1]: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Eric M. Ludlam]

Hi,

  Klaus' explanation is accurate.  Semantic's parsing engine needs to
have separate tag streams (tracked by overlays) for each buffer.  When
the clone replicates the overlays and local variables, they share the
same cons cells in Semantic's tag data structure.  When Semantic then
incrementally parses the buffer, and splices new tags in, things get a
bit unreliable.  If the two buffers were in two different modes (ie,
one of the multi-modes?) with different parsers, I can imagine things
being even stranger.

  The second issue Klaus alludes two is with the after-change
function.  Semantic tracks all the little changes, then the next time
the tag stream needs to be updated for Semantic, it combines those
changes to determine what subset of the buffer to reparse.  This makes
the reparsing step very fast.

  The after-change function does not seem to be called for all linked
buffers.  Changing a base buffer doesn't call the same hooks in the
indirect buffer, and vice-versa.  This means that changes get lost, as
each buffer appears to need Semantic to track the changes separately.
I can imagine calling the after-change-function for every linked
buffer might be a bad idea, but there is also no way to get a list of
all such linked buffers.  If there were, I could propagate the change
tracking myself quite easily.  I don't think having something looping
over all buffers to generate said list myself would be a good idea in
the after-change-function though, especially in the general case where
there aren't any, that would be a waste.

  If you need any additional information, let me know.

Eric


>>> <klaus.berndl@capgemini-sdm.com> seems to think that:
>Hi Stefan,
>
>probably Eric could explain this better, but i will make a try:
>
>Currently we try to make ECB and CEDET (semantic) ready for usage with =
>indirect-buffers too... For ECB the part is done but for semantic we =
>detected that there are really ugly and unpredictable side-effects when =
>cloning a buffer which is supported by semantic - simplified reason: all =
>the semantic-overlays are cloned too and it seems that the buffer-object =
>of such a semantic-overlay in the new clone points still to the =
>base-buffer which confuses semantic and all tools using semantic (e.g. =
>ECB) a lot... Therefore  we came to the solution that semantic clears =
>its cache for the new clone when the new clone is created, so the new =
>clone is completely reparsed next time and therefore the new clone gets =
>new semantic overleys completely different from these of the =
>base-buffer... A first and working solution was to do this with =
>clone-indirect-buffer-hook.. but this is an unsave solution because tere =
>is the command make-indirect-buffer which can also be used to create a =
>clone and when done this way, the hook doesn't run, therefore the =
>semantic-cache is not cleared and therefore ugly sideeffets came up =
>which makes semantic quite unusable with indirect buffers... so in this =
>case the usage of the hook is not related to a certain major-mode but we =
>need an entry-point in indirect-buffer-creation to prepare some things =
>needed by semantic and ECB...
>
>Without such a common hook as suggested by me i see only one chance: =
>writing a small after advice for make-indirect-buffer - i have tested =
>this already and it would work but IMHO a hook-solution would be =
>preferable.
>
>Therefore the suggestion to make a hook, which runs also with =
>make-indirect-buffer...
>
>Eric, is this understandable or would you like to add some remarks?
>
>BTW: there is another problem related to indirect-buffer but this one =
>has to be explained by Eric...
>
>best regards
>Klaus
>
>-----Urspr=FCngliche Nachricht-----
>Von: Stefan Monnier [mailto:monnier@IRO.UMontreal.CA]
>Gesendet: Fr 17.04.2009 22:26
>An: Berndl, Klaus
>Cc: 3018@emacsbugs.donarmstrong.com
>Betreff: Re: bug#3018: clone-indirect-buffer-hook should be =
>make-indirect-buffer-hook
>=20
>> IMHO a bug in Emacs 23 because if there is such a hook, then it should
>> be used by both of them - at ist best only by make-indirect-buffer
>> (because this command is called by clone-indirect-buffer) and then the
>> new hook should be named make-indirect-buffer-hook...
>
>If `make-indirect-buffer' is called with a nil argument for `clone',
>then it shouldn't run any buffer-local part of
>clone-indirect-buffer-hook (which is typically used by major modes).
>
>So maybe you're right, but as long as nobody uses the global part of
>clone-indirect-buffer-hook, or calls `make-indirect-buffer' with
>a non-nil `clone' argument (rather than calling clone-indirect-buffer),
>it shouldn't matter.
>
>Care to explain the context in which you bumped into this?  It might
>help us understand what needs to be done.
>
>
>        Stefan
>
>
>