[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3018: AW: AW: bug#3018: clone-indirect-buffer-hook should be make-in
bug#3018: AW: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Sun, 19 Apr 2009 06:55:38 +0200
Ah, now i understand - when calling make-indirect-buffer interactively
the clone-arg is always nil... major-mode is fundamental-mode (e.g.),
no overlays are copied ==> the buffer is not setup for semantic...
Just tested - with respect to semantic indirect-buffers made by
make-indirect-buffer are quite useless, because not even the major-mode
is copied, so semantic is in consequence not active for such a non-clone.
Well, so if a user wants a real clone then he must use clone-indirect-buffer.
I have misunderstood this...thanks for explanation.
Well, then it might be ok, only having the clone-indirect-buffer hook because
semantic has only to deal with indirect-buffers which are real clones not with
that ones created by make-indirect-buffer...
Eric: Now for me the clone-indirect-buffer-hook solution is ok and save.
Topic after-change-function: Stefan, what do you think? Are there chances that this
bug will be fixed in the near future or do have any idea for a practicable work-
Von: Stefan Monnier [mailto:address@hidden]
Gesendet: Sa 18.04.2009 19:54
An: Eric M. Ludlam
Cc: Berndl, Klaus; address@hidden
Betreff: Re: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
> 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