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

[klaus.berndl]

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-
around?

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
Gesendet: Sa 18.04.2009 19:54
An: Eric M. Ludlam
Cc: Berndl, Klaus; 3018@emacsbugs.donarmstrong.com
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.


        Stefan