bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Stefan Monnier]

>   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.

Yes, this is a "common" problem, and is the reason why
clone-indirect-buffer-hook was introduced.  If `make-indirect-buffer' is
called with a nil `clone' argument this problem shouldn't show up
(because such a call shouldn't copy the overlays).  So the problem might
only show up when calling `make-indirect-buffer' with a non-nil `clone'
argument without going through clone-indirect-buffer.  When did you come
across such a situation?

>   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.

Indeed, it might be that *-change-functions only get called in the
buffer from which they are performed, which is probably a bug.


        Stefan