bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[klaus.berndl]

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

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


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

bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Lennart Borgman]

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@capgemini-sdm.com> wrote:
> 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

bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Stefan Monnier]

> 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: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[klaus.berndl]

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

bug#3018: Re[1]: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Eric M. Ludlam]

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@capgemini-sdm.com> 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
>
>
>

bug#3018: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[Stefan Monnier]

>   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

bug#3018: AW: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook

[klaus.berndl]

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

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 ==> 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 
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üngliche Nachricht-----
Von: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
Gesendet: Sa 18.04.2009 19:54
An: Eric M. Ludlam
Cc: Berndl, Klaus; 3018@emacsbugs.donarmstrong.com
Betreff: Re: AW: bug#3018: clone-indirect-buffer-hook should be make-indirect-buffer-hook
 
>   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


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

bug#3018: bug#3038: 23.0.91; after-change-functions and indirect buffers

[Lars Ingebrigtsen]

<klaus.berndl@capgemini-sdm.com> writes:

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

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, it seems like it was agreed that this works as
designed.  There was then some discussion about after-change-functions,
but this bug report doesn't seem actionable, so I'm closing it.  If
there is something that should be done in this area, opening a new bug
report and restating the issue would be the way forward.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no