[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indire
bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Sat, 18 Apr 2009 13:54:58 -0400
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)
> 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.
bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook, Lennart Borgman, 2009/04/17