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.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at 3018@HIDDEN:


Received: (at 3018) by emacsbugs.donarmstrong.com; 18 Apr 2009 17:55:09 +0000
From monnier@HIDDEN Sat Apr 18 10:55:08 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=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT
	autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IHt4pB010175
	for <3018@HIDDEN>; Sat, 18 Apr 2009 10:55:05 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAFuw6UlLd+7D/2dsb2JhbACBTstUg30GhSg
X-IronPort-AV: E=Sophos;i="4.40,210,1238990400"; 
   d="scan'208";a="37263165"
Received: from 75-119-238-195.dsl.teksavvy.com (HELO pastel.home) ([75.119.238.195])
  by ironport2-out.teksavvy.com with ESMTP; 18 Apr 2009 13:54:58 -0400
Received: by pastel.home (Postfix, from userid 20848)
	id 6CCB87EFC; Sat, 18 Apr 2009 13:54:58 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Eric M. Ludlam" <eric@HIDDEN>
Cc: <klaus.berndl@HIDDEN>, 3018 <at> debbugs.gnu.org
Subject: Re: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Message-ID: <jwv1vrqkouh.fsf-monnier+emacsbugreports@HIDDEN>
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN>
	<jwviql3vxou.fsf-monnier+emacsbugreports@HIDDEN>
	<84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@HIDDEN>
	<200904181256.n3ICuBSV014525@HIDDEN>
Date: Sat, 18 Apr 2009 13:54:58 -0400
In-Reply-To: <200904181256.n3ICuBSV014525@HIDDEN> (Eric
	M. Ludlam's message of "Sat, 18 Apr 2009 08:56:11 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>   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




Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at 3018@HIDDEN:


Received: (at 3018) by emacsbugs.donarmstrong.com; 18 Apr 2009 12:56:26 +0000
From eric@HIDDEN Sat Apr 18 05:56:26 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=-0.1 required=4.0 tests=FOURLA,HAS_BUG_NUMBER,
	SUBJ_RE_NUM autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from projectile.siege-engine.com (static-71-184-83-10.bstnma.fios.verizon.net [71.184.83.10])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3ICuMSw021777
	for <3018@HIDDEN>; Sat, 18 Apr 2009 05:56:23 -0700
Received: from projectile.siege-engine.com (localhost.localdomain [127.0.0.1])
	by  projectile.siege-engine.com (8.12.8/8.12.8) with ESMTP id n3ICuCEB014527;
	Sat, 18 Apr 2009 08:56:12 -0400
Received: (from zappo@localhost)
	by projectile.siege-engine.com (8.12.8/8.12.8/Submit) id n3ICuBSV014525;
	Sat, 18 Apr 2009 08:56:11 -0400
Date: Sat, 18 Apr 2009 08:56:11 -0400
Message-Id: <200904181256.n3ICuBSV014525@HIDDEN>
From: "Eric M. Ludlam" <eric@HIDDEN>
To: <klaus.berndl@HIDDEN>
CC: monnier@HIDDEN, 3018 <at> debbugs.gnu.org
In-reply-to: <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@HIDDEN>
	(klaus.berndl@HIDDEN)
Subject: Re[1]: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN> <jwviql3vxou.fsf-monnier+emacsbugreports@HIDDEN> <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@HIDDEN>

Hi,

  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.

  The second issue Klaus alludes two is with the after-change
function.  Semantic tracks all the little changes, then the next time
the tag stream needs to be updated for Semantic, it combines those
changes to determine what subset of the buffer to reparse.  This makes
the reparsing step very fast.

  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.
I can imagine calling the after-change-function for every linked
buffer might be a bad idea, but there is also no way to get a list of
all such linked buffers.  If there were, I could propagate the change
tracking myself quite easily.  I don't think having something looping
over all buffers to generate said list myself would be a good idea in
the after-change-function though, especially in the general case where
there aren't any, that would be a waste.

  If you need any additional information, let me know.

Eric


>>> <klaus.berndl@HIDDEN> seems to think that:
>Hi Stefan,
>
>probably Eric could explain this better, but i will make a try:
>
>Currently we try to make ECB and CEDET (semantic) ready for usage with =
>indirect-buffers too... For ECB the part is done but for semantic we =
>detected that there are really ugly and unpredictable side-effects when =
>cloning a buffer which is supported by semantic - simplified reason: all =
>the semantic-overlays are cloned too and it seems that the buffer-object =
>of such a semantic-overlay in the new clone points still to the =
>base-buffer which confuses semantic and all tools using semantic (e.g. =
>ECB) a lot... Therefore  we came to the solution that semantic clears =
>its cache for the new clone when the new clone is created, so the new =
>clone is completely reparsed next time and therefore the new clone gets =
>new semantic overleys completely different from these of the =
>base-buffer... A first and working solution was to do this with =
>clone-indirect-buffer-hook.. but this is an unsave solution because tere =
>is the command make-indirect-buffer which can also be used to create a =
>clone and when done this way, the hook doesn't run, therefore the =
>semantic-cache is not cleared and therefore ugly sideeffets came up =
>which makes semantic quite unusable with indirect buffers... so in this =
>case the usage of the hook is not related to a certain major-mode but we =
>need an entry-point in indirect-buffer-creation to prepare some things =
>needed by semantic and ECB...
>
>Without such a common hook as suggested by me i see only one chance: =
>writing a small after advice for make-indirect-buffer - i have tested =
>this already and it would work but IMHO a hook-solution would be =
>preferable.
>
>Therefore the suggestion to make a hook, which runs also with =
>make-indirect-buffer...
>
>Eric, is this understandable or would you like to add some remarks?
>
>BTW: there is another problem related to indirect-buffer but this one =
>has to be explained by Eric...
>
>best regards
>Klaus
>
>-----Urspr=FCngliche Nachricht-----
>Von: Stefan Monnier [mailto:monnier@HIDDEN]
>Gesendet: Fr 17.04.2009 22:26
>An: Berndl, Klaus
>Cc: 3018@HIDDEN
>Betreff: Re: bug#3018: clone-indirect-buffer-hook should be =
>make-indirect-buffer-hook
>=20
>> IMHO a bug in Emacs 23 because if there is such a hook, then it should
>> be used by both of them - at ist best only by make-indirect-buffer
>> (because this command is called by clone-indirect-buffer) and then the
>> new hook should be named make-indirect-buffer-hook...
>
>If `make-indirect-buffer' is called with a nil argument for `clone',
>then it shouldn't run any buffer-local part of
>clone-indirect-buffer-hook (which is typically used by major modes).
>
>So maybe you're right, but as long as nobody uses the global part of
>clone-indirect-buffer-hook, or calls `make-indirect-buffer' with
>a non-nil `clone' argument (rather than calling clone-indirect-buffer),
>it shouldn't matter.
>
>Care to explain the context in which you bumped into this?  It might
>help us understand what needs to be done.
>
>
>        Stefan
>
>
>





Acknowledgement sent to "Eric M. Ludlam" <eric@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at 3018@HIDDEN:


Received: (at 3018) by emacsbugs.donarmstrong.com; 18 Apr 2009 08:50:12 +0000
From klaus.berndl@HIDDEN Sat Apr 18 01:50:11 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.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER,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 n3I8o4xT014780
	for <3018@HIDDEN>; Sat, 18 Apr 2009 01:50:06 -0700
Received: from mucns1 ([10.40.232.18] helo=mucns1.sdm.de)
	by world2.sdm.de with esmtp (MTA)
	id 1Lv6FL-0008Fe-1v; Sat, 18 Apr 2009 10:49:59 +0200
Received: from sdmmail1.sdm.de ([10.40.232.6])
	by mucns1.sdm.de with esmtp (MTA)
	id 1Lv6FK-0005Ht-WA; Sat, 18 Apr 2009 10:49:59 +0200
Received: from mucmail3.sdm.de ([10.40.232.45]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.3959);
	 Sat, 18 Apr 2009 10:49:58 +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_01C9C002.A731EF2D"
Subject: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Date: Sat, 18 Apr 2009 10:49:58 +0200
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@HIDDEN>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Thread-Index: Acm/mtHkEzf+hbWESU6bqhlPTr4H2wAZlWbx
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN> <jwviql3vxou.fsf-monnier+emacsbugreports@HIDDEN>
From: <klaus.berndl@HIDDEN>
To: <monnier@HIDDEN>, <eric@HIDDEN>
Cc: <3018 <at> debbugs.gnu.org>
X-OriginalArrivalTime: 18 Apr 2009 08:49:58.0785 (UTC) FILETIME=[A7680710:01C9C002]

This is a multi-part message in MIME format.

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

Hi Stefan,

probably Eric could explain this better, but i will make a try:

Currently we try to make ECB and CEDET (semantic) ready for usage with =
indirect-buffers too... For ECB the part is done but for semantic we =
detected that there are really ugly and unpredictable side-effects when =
cloning a buffer which is supported by semantic - simplified reason: all =
the semantic-overlays are cloned too and it seems that the buffer-object =
of such a semantic-overlay in the new clone points still to the =
base-buffer which confuses semantic and all tools using semantic (e.g. =
ECB) a lot... Therefore  we came to the solution that semantic clears =
its cache for the new clone when the new clone is created, so the new =
clone is completely reparsed next time and therefore the new clone gets =
new semantic overleys completely different from these of the =
base-buffer... A first and working solution was to do this with =
clone-indirect-buffer-hook.. but this is an unsave solution because tere =
is the command make-indirect-buffer which can also be used to create a =
clone and when done this way, the hook doesn't run, therefore the =
semantic-cache is not cleared and therefore ugly sideeffets came up =
which makes semantic quite unusable with indirect buffers... so in this =
case the usage of the hook is not related to a certain major-mode but we =
need an entry-point in indirect-buffer-creation to prepare some things =
needed by semantic and ECB...

Without such a common hook as suggested by me i see only one chance: =
writing a small after advice for make-indirect-buffer - i have tested =
this already and it would work but IMHO a hook-solution would be =
preferable.

Therefore the suggestion to make a hook, which runs also with =
make-indirect-buffer...

Eric, is this understandable or would you like to add some remarks?

BTW: there is another problem related to indirect-buffer but this one =
has to be explained by Eric...

best regards
Klaus

-----Urspr=FCngliche Nachricht-----
Von: Stefan Monnier [mailto:monnier@HIDDEN]
Gesendet: Fr 17.04.2009 22:26
An: Berndl, Klaus
Cc: 3018 <at> debbugs.gnu.org
Betreff: Re: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook
=20
> IMHO a bug in Emacs 23 because if there is such a hook, then it should
> be used by both of them - at ist best only by make-indirect-buffer
> (because this command is called by clone-indirect-buffer) and then the
> new hook should be named make-indirect-buffer-hook...

If `make-indirect-buffer' is called with a nil argument for `clone',
then it shouldn't run any buffer-local part of
clone-indirect-buffer-hook (which is typically used by major modes).

So maybe you're right, but as long as nobody uses the global part of
clone-indirect-buffer-hook, or calls `make-indirect-buffer' with
a non-nil `clone' argument (rather than calling clone-indirect-buffer),
it shouldn't matter.

Care to explain the context in which you bumped into this?  It might
help us understand what needs to be done.


        Stefan



------_=_NextPart_001_01C9C002.A731EF2D
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: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Stefan,<BR>
<BR>
probably Eric could explain this better, but i will make a try:<BR>
<BR>
Currently we try to make ECB and CEDET (semantic) ready for usage with =
indirect-buffers too... For ECB the part is done but for semantic we =
detected that there are really ugly and unpredictable side-effects when =
cloning a buffer which is supported by semantic - simplified reason: all =
the semantic-overlays are cloned too and it seems that the buffer-object =
of such a semantic-overlay in the new clone points still to the =
base-buffer which confuses semantic and all tools using semantic (e.g. =
ECB) a lot... Therefore&nbsp; we came to the solution that semantic =
clears its cache for the new clone when the new clone is created, so the =
new clone is completely reparsed next time and therefore the new clone =
gets new semantic overleys completely different from these of the =
base-buffer... A first and working solution was to do this with =
clone-indirect-buffer-hook.. but this is an unsave solution because tere =
is the command make-indirect-buffer which can also be used to create a =
clone and when done this way, the hook doesn't run, therefore the =
semantic-cache is not cleared and therefore ugly sideeffets came up =
which makes semantic quite unusable with indirect buffers... so in this =
case the usage of the hook is not related to a certain major-mode but we =
need an entry-point in indirect-buffer-creation to prepare some things =
needed by semantic and ECB...<BR>
<BR>
Without such a common hook as suggested by me i see only one chance: =
writing a small after advice for make-indirect-buffer - i have tested =
this already and it would work but IMHO a hook-solution would be =
preferable.<BR>
<BR>
Therefore the suggestion to make a hook, which runs also with =
make-indirect-buffer...<BR>
<BR>
Eric, is this understandable or would you like to add some remarks?<BR>
<BR>
BTW: there is another problem related to indirect-buffer but this one =
has to be explained by Eric...<BR>
<BR>
best regards<BR>
Klaus<BR>
<BR>
-----Urspr=FCngliche Nachricht-----<BR>
Von: Stefan Monnier [<A =
HREF=3D"mailto:monnier@HIDDEN">mailto:monnier@HIDDEN<=
/A>]<BR>
Gesendet: Fr 17.04.2009 22:26<BR>
An: Berndl, Klaus<BR>
Cc: 3018 <at> debbugs.gnu.org<BR>
Betreff: Re: bug#3018: clone-indirect-buffer-hook should be =
make-indirect-buffer-hook<BR>
<BR>
&gt; IMHO a bug in Emacs 23 because if there is such a hook, then it =
should<BR>
&gt; be used by both of them - at ist best only by =
make-indirect-buffer<BR>
&gt; (because this command is called by clone-indirect-buffer) and then =
the<BR>
&gt; new hook should be named make-indirect-buffer-hook...<BR>
<BR>
If `make-indirect-buffer' is called with a nil argument for `clone',<BR>
then it shouldn't run any buffer-local part of<BR>
clone-indirect-buffer-hook (which is typically used by major modes).<BR>
<BR>
So maybe you're right, but as long as nobody uses the global part of<BR>
clone-indirect-buffer-hook, or calls `make-indirect-buffer' with<BR>
a non-nil `clone' argument (rather than calling =
clone-indirect-buffer),<BR>
it shouldn't matter.<BR>
<BR>
Care to explain the context in which you bumped into this?&nbsp; It =
might<BR>
help us understand what needs to be done.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9C002.A731EF2D--




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.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at 3018@HIDDEN:


Received: (at 3018) by emacsbugs.donarmstrong.com; 17 Apr 2009 20:27:32 +0000
From lennart.borgman@HIDDEN Fri Apr 17 13:27:32 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=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER
	autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3HKRTY1032678
	for <3018@HIDDEN>; Fri, 17 Apr 2009 13:27:30 -0700
Received: by fxm4 with SMTP id 4so1414566fxm.1
        for <3018@HIDDEN>; Fri, 17 Apr 2009 13:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=V6koTrlELVcUscZ4acPhPdgQWyC4cDvmFEGSpDQHR4g=;
        b=t1xkQ2IZ+evF0ITkhDf1jdFSe2qeYiGagZ6JBjuwBpbi7gk7P2unTmsEEqsiAGx50w
         ZgWcQSSx0fmjmVqkxSkVNJgMWaekcSDvAWritLapJKjl3rk6JXkf67xkaCrkqyJJG3+h
         AySOK5CWJjfCJrfgT+KPhvr11xPQEboe5BO+M=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=jN8gOqOtizkKNJYksgTkbPUcm5VarNXqhJe7TBHw3NMNKivQfLIlzaNFUbHos0jeX+
         1b4QBy97GrG/iUUR0RcuUTSH1A0g5cZxjldpuOuBALWmv8Ua8qSLkZp91qEDcv7XoW1M
         1mcCM5z1jRGhmLNAwuIhcLPw8pIrI7HAoAmL0=
MIME-Version: 1.0
Received: by 10.223.109.148 with SMTP id j20mr671187fap.43.1239962038095; Fri, 
	17 Apr 2009 02:53:58 -0700 (PDT)
In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN>
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN>
Date: Fri, 17 Apr 2009 11:53:58 +0200
Message-ID: <e01d8a50904170253j35be19dbgae08fd0b692c1b2f@HIDDEN>
Subject: Re: bug#3018: clone-indirect-buffer-hook should be 
	make-indirect-buffer-hook
From: Lennart Borgman <lennart.borgman@HIDDEN>
To: klaus.berndl@HIDDEN, 3018 <at> debbugs.gnu.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Klaus, you never sent a bug report, or? Hope someone still answers,
but this might be forgotten if it does not get into the bug system.
Please wait a couple of days and see if someone answers.

On Thu, Apr 16, 2009 at 5:46 PM,  <klaus.berndl@HIDDEN> wrote:
> Hi all,
>
> AFAICS the new hook `clone-indirect-buffer-hook'=C2=A0of Emacs 23 is not =
used by
> the command `make-indirect-buffer-hook' or is it? If not: why not?
>
> IMHO a bug in Emacs=C2=A023 because if there is such a hook, then it shou=
ld be
> used by both of them - at ist best only by make-indirect-buffer (because
> this command is called by clone-indirect-buffer) and then the new hook
> should be named make-indirect-buffer-hook...
>
> Thoughts?
>
> Regards
>
> Klaus




Acknowledgement sent to Lennart Borgman <lennart.borgman@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at 3018@HIDDEN:


Received: (at 3018) by emacsbugs.donarmstrong.com; 17 Apr 2009 20:26:46 +0000
From monnier@HIDDEN Fri Apr 17 13:26:46 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=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER
	autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3HKQgmq032627
	for <3018@HIDDEN>; Fri, 17 Apr 2009 13:26:43 -0700
Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177])
	by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n3HKQaRF008544;
	Fri, 17 Apr 2009 16:26:36 -0400
Received: by faina.iro.umontreal.ca (Postfix, from userid 20848)
	id 0C926813A4; Fri, 17 Apr 2009 16:26:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: klaus.berndl@HIDDEN
Cc: 3018 <at> debbugs.gnu.org
Subject: Re: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Message-ID: <jwviql3vxou.fsf-monnier+emacsbugreports@HIDDEN>
References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN>
Date: Fri, 17 Apr 2009 16:26:36 -0400
In-Reply-To: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN> (klaus
	berndl's message of "Thu, 16 Apr 2009 17:46:30 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV3256=0

> IMHO a bug in Emacs 23 because if there is such a hook, then it should
> be used by both of them - at ist best only by make-indirect-buffer
> (because this command is called by clone-indirect-buffer) and then the
> new hook should be named make-indirect-buffer-hook...

If `make-indirect-buffer' is called with a nil argument for `clone',
then it shouldn't run any buffer-local part of
clone-indirect-buffer-hook (which is typically used by major modes).

So maybe you're right, but as long as nobody uses the global part of
clone-indirect-buffer-hook, or calls `make-indirect-buffer' with
a non-nil `clone' argument (rather than calling clone-indirect-buffer),
it shouldn't matter.

Care to explain the context in which you bumped into this?  It might
help us understand what needs to be done.


        Stefan





Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.

Message received at submit@HIDDEN:


Received: (at submit) by emacsbugs.donarmstrong.com; 16 Apr 2009 15:46:46 +0000
From klaus.berndl@HIDDEN Thu Apr 16 08:46:46 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.1 required=4.0 tests=FOURLA,MULTALT autolearn=no
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3GFkemN020462
	for <submit@HIDDEN>; Thu, 16 Apr 2009 08:46:41 -0700
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LuTnU-0007Vj-11
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 11:46:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LuTnN-0007Q7-W6
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 11:46:38 -0400
Received: from [199.232.76.173] (port=49983 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1LuTnN-0007Ps-Nf
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 11:46:33 -0400
Received: from world2.sdm.de ([192.76.162.230]:58880)
	by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60)
	(envelope-from <klaus.berndl@HIDDEN>)
	id 1LuTnN-0000OI-00
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 11:46:33 -0400
Received: from mucns1 ([10.40.232.18] helo=mucns1.sdm.de)
	by world2.sdm.de with esmtp (MTA)
	id 1LuTnL-0005cQ-Ke
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 17:46:31 +0200
Received: from sdmmail1.sdm.de ([10.40.232.6])
	by mucns1.sdm.de with esmtp (MTA)
	id 1LuTnL-0001oo-Df
	for bug-gnu-emacs@HIDDEN; Thu, 16 Apr 2009 17:46:31 +0200
Received: from mucmail3.sdm.de ([10.40.232.45]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 16 Apr 2009 17:46:31 +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_01C9BEAA.83501ED1"
Subject: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Date: Thu, 16 Apr 2009 17:46:30 +0200
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@HIDDEN>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: clone-indirect-buffer-hook should be make-indirect-buffer-hook
Thread-Index: Acm+qoLtpmDa33IVSeeD/I0zhGqy+Q==
From: <klaus.berndl@HIDDEN>
To: <bug-gnu-emacs@HIDDEN>
X-OriginalArrivalTime: 16 Apr 2009 15:46:31.0018 (UTC) FILETIME=[831CA4A0:01C9BEAA]
X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3)

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9BEAA.83501ED1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

AFAICS the new hook `clone-indirect-buffer-hook' of Emacs 23 is not used =
by the command `make-indirect-buffer-hook' or is it? If not: why not?

IMHO a bug in Emacs 23 because if there is such a hook, then it should =
be used by both of them - at ist best only by make-indirect-buffer =
(because this command is called by clone-indirect-buffer) and then the =
new hook should be named make-indirect-buffer-hook...

Thoughts?

Regards

Klaus


------_=_NextPart_001_01C9BEAA.83501ED1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.5726" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN lang=3DDE>
<P><SPAN class=3D476475514-16042009><FONT face=3D"Courier New" =
size=3D2>Hi=20
all,</FONT></SPAN></P>
<P><SPAN class=3D476475514-16042009><FONT face=3D"Courier New" =
size=3D2>AFAICS the new=20
hook `clone-indirect-buffer-hook'&nbsp;of Emacs 23 is not used by the =
command=20
`make-indirect-buffer-hook' or is it? If not: why not?</FONT></SPAN></P>
<P><FONT face=3D"Courier New">IMHO a bug in Emacs&nbsp;<SPAN=20
class=3D476475514-16042009>23 </SPAN>because if there is such a hook, =
then it=20
sh<SPAN class=3D476475514-16042009>o</SPAN>uld be used by both of them - =
at ist=20
best only by make-indirect-buffer (because this command is called by=20
clone-indirect-buffer) and then the new hook should be named=20
make-indirect-buffer-hook...</FONT></P>
<P><SPAN class=3D476475514-16042009><FONT face=3D"Courier New"=20
size=3D2>Thoughts?</FONT></SPAN></P>
<P><SPAN class=3D476475514-16042009><FONT face=3D"Courier New"=20
size=3D2>Regards</FONT></SPAN></P>
<P><SPAN class=3D476475514-16042009><FONT face=3D"Courier New"=20
size=3D2>Klaus</FONT></SPAN></P></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C9BEAA.83501ED1--





Acknowledgement sent to <klaus.berndl@HIDDEN>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Report forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#3018; Package emacs. Full text available.
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.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.