[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indire
From: |
klaus.berndl |
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 |
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üngliche 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
> 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
bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook, Lennart Borgman, 2009/04/17