GNU bug report logs - #3018
clone-indirect-buffer-hook should be make-indirect-buffer-hook

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: <klaus.berndl@HIDDEN>; merged with #3038; dated Thu, 16 Apr 2009 15:50:04 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Removed tag(s) notabug and wontfix. Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Added tag(s) notabug and wontfix. Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Merged 3018 3038. Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 3018@HIDDEN:

Received: (at 3018) by emacsbugs.donarmstrong.com; 19 Apr 2009 04:55:50 +0000
From klaus.berndl@HIDDEN Sat Apr 18 21:55:50 2009
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,MDO_CABLE_TV3,
	MULTALT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from world2.sdm.de (world2.sdm.de [192.76.162.230])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3J4tjtK002282
	for <3018@HIDDEN>; Sat, 18 Apr 2009 21:55:47 -0700
Received: from mucns1 ([10.40.232.18] helo=mucns1.sdm.de)
	by world2.sdm.de with esmtp (MTA)
	id 1LvP47-00029l-EO; Sun, 19 Apr 2009 06:55:39 +0200
Received: from sdmmail1.sdm.de ([10.40.232.6])
	by mucns1.sdm.de with esmtp (MTA)
	id 1LvP47-0002Qf-DF; Sun, 19 Apr 2009 06:55:39 +0200
Received: from mucmail3.sdm.de ([10.40.232.45]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 19 Apr 2009 06:55:39 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9C0AB.157086D1"
Subject: AW: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Date: Sun, 19 Apr 2009 06:55:38 +0200
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E314C83B@HIDDEN>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Thread-Index: AcnATs19Y3uMWX+oTV62B+EDQgp9gAAW07qF
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN><jwviql3vxou.fsf-monnier+emacsbugreports@HIDDEN><84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@HIDDEN><200904181256.n3ICuBSV014525@HIDDEN> <jwv1vrqkouh.fsf-monnier+emacsbugreports@HIDDEN>
From: <klaus.berndl@HIDDEN>
To: <monnier@HIDDEN>, <eric@HIDDEN>
Cc: <3018 <at> debbugs.gnu.org>
X-OriginalArrivalTime: 19 Apr 2009 04:55:39.0110 (UTC) FILETIME=[1599A060:01C9C0AB]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9C0AB.157086D1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 =3D=3D> 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=20
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=FCngliche Nachricht-----
Von: Stefan Monnier [mailto:monnier@HIDDEN]
Gesendet: Sa 18.04.2009 19:54
An: Eric M. Ludlam
Cc: Berndl, Klaus; 3018 <at> debbugs.gnu.org
Betreff: Re: AW: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook
=20
>   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


------_=_NextPart_001_01C9C0AB.157086D1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>AW: AW: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Ah, now i understand - when calling =
make-indirect-buffer interactively<BR>
the clone-arg is always nil... major-mode is fundamental-mode =
(e.g.),<BR>
no overlays are copied =3D=3D&gt; the buffer is not setup for =
semantic...<BR>
Just tested - with respect to semantic indirect-buffers made by<BR>
make-indirect-buffer are quite useless, because not even the =
major-mode<BR>
is copied, so semantic is in consequence not active for such a =
non-clone.<BR>
<BR>
Well, so if a user wants a real clone then he must use =
clone-indirect-buffer.<BR>
I have misunderstood this...thanks for explanation.<BR>
<BR>
Well, then it might be ok, only having the clone-indirect-buffer hook =
because<BR>
semantic has only to deal with indirect-buffers which are real clones =
not with<BR>
that ones created by make-indirect-buffer...<BR>
<BR>
Eric: Now for me the clone-indirect-buffer-hook solution is ok and =
save.<BR>
<BR>
Topic after-change-function: Stefan, what do you think? Are there =
chances that this<BR>
bug will be fixed in the near future or do have any idea for a =
practicable work-<BR>
around?<BR>
<BR>
Ciao,<BR>
Klaus<BR>
<BR>
-----Urspr=FCngliche Nachricht-----<BR>
Von: Stefan Monnier [<A =
HREF=3D"mailto:monnier@HIDDEN">mailto:monnier@HIDDEN<=
/A>]<BR>
Gesendet: Sa 18.04.2009 19:54<BR>
An: Eric M. Ludlam<BR>
Cc: Berndl, Klaus; 3018 <at> debbugs.gnu.org<BR>
Betreff: Re: AW: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook<BR>
<BR>
&gt;&nbsp;&nbsp; Klaus' explanation is accurate.&nbsp; Semantic's =
parsing engine needs to<BR>
&gt; have separate tag streams (tracked by overlays) for each =
buffer.&nbsp; When<BR>
&gt; the clone replicates the overlays and local variables, they share =
the<BR>
&gt; same cons cells in Semantic's tag data structure.&nbsp; When =
Semantic then<BR>
&gt; incrementally parses the buffer, and splices new tags in, things =
get a<BR>
&gt; bit unreliable.&nbsp; If the two buffers were in two different =
modes (ie,<BR>
&gt; one of the multi-modes?) with different parsers, I can imagine =
things<BR>
&gt; being even stranger.<BR>
<BR>
Yes, this is a &quot;common&quot; problem, and is the reason why<BR>
clone-indirect-buffer-hook was introduced.&nbsp; If =
`make-indirect-buffer' is<BR>
called with a nil `clone' argument this problem shouldn't show up<BR>
(because such a call shouldn't copy the overlays).&nbsp; So the problem =
might<BR>
only show up when calling `make-indirect-buffer' with a non-nil =
`clone'<BR>
argument without going through clone-indirect-buffer.&nbsp; When did you =
come<BR>
across such a situation?<BR>
<BR>
&gt;&nbsp;&nbsp; The after-change function does not seem to be called =
for all linked<BR>
&gt; buffers.&nbsp; Changing a base buffer doesn't call the same hooks =
in the<BR>
&gt; indirect buffer, and vice-versa.&nbsp; This means that changes get =
lost, as<BR>
&gt; each buffer appears to need Semantic to track the changes =
separately.<BR>
<BR>
Indeed, it might be that *-change-functions only get called in the<BR>
buffer from which they are performed, which is probably a bug.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9C0AB.157086D1--

Acknowledgement sent to <klaus.berndl@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.