From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#3018: 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@mucmail3.sdm.de> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@mucmail3.sdm.de> Reply-To: klaus.berndl@capgemini-sdm.com, 3018@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C002.A731EF2D" X-Trace: ger.gmane.org 1240045501 25463 80.91.229.12 (18 Apr 2009 09:05:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2009 09:05:01 +0000 (UTC) Cc: 3018@emacsbugs.donarmstrong.com To: , Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 18 11:06:21 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lv6UQ-0006jD-3L for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 11:05:50 +0200 Original-Received: from localhost ([127.0.0.1]:57187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lv6T0-0003wM-HE for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 05:04:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lv6Su-0003vP-8H for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 05:04:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lv6Sp-0003ur-58 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 05:03:59 -0400 Original-Received: from [199.232.76.173] (port=39660 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lv6So-0003ud-V5 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 05:03:54 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:45848) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lv6So-00064o-2l for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 05:03:54 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I93pWS018799; Sat, 18 Apr 2009 02:03:52 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3I8t4DA016243; Sat, 18 Apr 2009 01:55:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Apr 2009 08:55:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3018 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3018-submit@emacsbugs.donarmstrong.com id=B3018.124004461215345 (code B ref 3018); Sat, 18 Apr 2009 08:55:04 +0000 Original-Received: (at 3018) by emacsbugs.donarmstrong.com; 18 Apr 2009 08:50:12 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 01:50:06 -0700 Original-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 Original-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 Original-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 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 X-OriginalArrivalTime: 18 Apr 2009 08:49:58.0785 (UTC) FILETIME=[A7680710:01C9C002] X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 18 Apr 2009 05:03:59 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:27309 Archived-At: 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@IRO.UMontreal.CA] Gesendet: Fr 17.04.2009 22:26 An: Berndl, Klaus Cc: 3018@emacsbugs.donarmstrong.com 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 AW: bug#3018: clone-indirect-buffer-hook should be = make-indirect-buffer-hook

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@IRO.UMontreal.CA<= /A>]
Gesendet: Fr 17.04.2009 22:26
An: Berndl, Klaus
Cc: 3018@emacsbugs.donarmstrong.com
Betreff: Re: bug#3018: clone-indirect-buffer-hook should be = make-indirect-buffer-hook

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