From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.bugs Subject: bug#3018: Re[1]: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook Date: Sat, 18 Apr 2009 08:56:11 -0400 Message-ID: <200904181256.n3ICuBSV014525@projectile.siege-engine.com> References: <84D8FEFE8D23E94E9C2A6F0C58EE07E30239ADFA@mucmail3.sdm.de> <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@mucmail3.sdm.de> Reply-To: "Eric M. Ludlam" , 3018@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1240069780 19219 80.91.229.12 (18 Apr 2009 15:49:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2009 15:49:40 +0000 (UTC) Cc: 3018@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 18 17:50:59 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 1LvCo4-0007v1-5f for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 17:50:56 +0200 Original-Received: from localhost ([127.0.0.1]:48575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvCme-0007du-6f for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2009 11:48:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvADA-0003r3-T5 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 09:04:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvAD5-0003mS-Vc for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 09:04:00 -0400 Original-Received: from [199.232.76.173] (port=38214 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvAD5-0003m7-OM for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 09:03:55 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:36948) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LvAD4-0006QP-Oo for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2009 09:03:55 -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 n3ID3pOY023285; Sat, 18 Apr 2009 06:03:51 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3ID0337021984; Sat, 18 Apr 2009 06:00:03 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Eric M. Ludlam" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Apr 2009 13:00:02 +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.124005938621794 (code B ref 3018); Sat, 18 Apr 2009 13:00:02 +0000 Original-Received: (at 3018) by emacsbugs.donarmstrong.com; 18 Apr 2009 12:56:26 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 05:56:23 -0700 Original-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 Original-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 In-reply-to: <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@mucmail3.sdm.de> (klaus.berndl@capgemini-sdm.com) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 18 Apr 2009 09:04:00 -0400 X-Mailman-Approved-At: Sat, 18 Apr 2009 11:44:09 -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:27321 Archived-At: 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 >>> 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@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 > > >