unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: <klaus.berndl@capgemini-sdm.com>
To: <monnier@IRO.UMontreal.CA>, <eric@siege-engine.com>
Cc: 3018@emacsbugs.donarmstrong.com
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	[thread overview]
Message-ID: <84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@mucmail3.sdm.de> (raw)
In-Reply-To: jwviql3vxou.fsf-monnier+emacsbugreports@gnu.org

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 3749 bytes --]

  reply	other threads:[~2009-04-18  8:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16 15:46 bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook klaus.berndl
2009-04-17  9:53 ` Lennart Borgman
2009-04-17 20:26 ` Stefan Monnier
2009-04-18  8:49   ` klaus.berndl [this message]
2009-04-18 12:56     ` bug#3018: Re[1]: AW: " Eric M. Ludlam
2009-04-18 17:54       ` bug#3018: " Stefan Monnier
2009-04-19  4:55         ` bug#3018: AW: " klaus.berndl
2022-05-01 10:00 ` bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84D8FEFE8D23E94E9C2A6F0C58EE07E314C839@mucmail3.sdm.de \
    --to=klaus.berndl@capgemini-sdm.com \
    --cc=3018@emacsbugs.donarmstrong.com \
    --cc=eric@siege-engine.com \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).