CEDET

Hi Eric,

Tonight i substantiated my suspicion, that currently semantic is not ready for usage in indirect-buffers - independ of ECB:

Test:
1. Open in emacs any elisp-file X, e.g. one of semantic:
2. Call clone-indirect-buffer for the buffer X, you will get a new indirect buffer named X<2> (or similiar)
3. Ensure that indirect buffer X<2> is the current buffer displayed
4. Now call [C-c , J] (semantic-complete-jump) when point stays on a symbol which is defined in X<2> itself(!!), e.g. any function-symbol
5. semantic-complete-jump will find this symbol but it will go to it in the base buffer X, not in the current indirect-buffer X<2>

This is defintely not what the users expect! IMHO a bug but unfortunatelly one of them which could cause huge effort to fix it - can not estimate what are the costs for reworking semantic so it also works for indirect-buffers....? But maybe it is not all that bad, see below my ideas:

In our example the problem is in this function:

(defun semantic-complete-jump ()
  "Jump to a semantic symbol."
  (interactive)
  (let* ((tag (semantic-complete-read-tag-project "Symbol: ")))
    (when (semantic-tag-p tag)
      (push-mark)
      (semantic-go-to-tag tag)
      (switch-to-buffer (current-buffer))
      (semantic-momentary-highlight-tag tag)
      (working-message "%S: %s "
                       (semantic-tag-class tag)
                       (semantic-tag-name  tag))))) 

The usage of semantic-go-to-tag which takes the buffer stored in the tag and makes this buffer current - but i have tested that all the tags of an indirect-buffer store the buffer-objects of the related base-buffer!

But now lets become more constructive ;-)

But first an excurs - from the emacs -manual:
----------
An "indirect buffer" shares the text of some other buffer, which is
called the "base buffer" of the indirect buffer.  In some ways it is
the analogue, for buffers, of a symbolic link among files.  The base
buffer may not itself be an indirect buffer.

   The text of the indirect buffer is always identical to the text of
its base buffer; changes made by editing either one are visible
immediately in the other.  This includes the text properties as well as
the characters themselves.

   In all other respects, the indirect buffer and its base buffer are
completely separate.  They have different names, independent values of
point, independent narrowing, independent markers and overlays (though
inserting or deleting text in either buffer relocates the markers and
overlays for both), independent major modes, and independent
buffer-local variable bindings.

   An indirect buffer cannot visit a file, but its base buffer can.  If
you try to save the indirect buffer, that actually saves the base
buffer.

   Killing an indirect buffer has no effect on its base buffer.  Killing
the base buffer effectively kills the indirect buffer in that it cannot
ever again be the current buffer.
---------

There is one good thing: indirect-buffers have separate overlays which is definitely good for semantic ;-)
But my suspicion is, that all overlays of the base-buffer are copied to the indirect-buffers...maybe therefore the wrong-buffer-object is stored in the semantic-tags??!! AFAIK semantic uses overlay-buffer to get the buffer of an overlay, right? So, could this be an Emacs bug? IMHO the new overlays of the indirect-buffers should automatically return the correct buffer when calling overlay-buffer for an indirect-buffer...

SO IMHO the key to an indirect-buffer-able semantic could be: 

A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...

B) use something like (ecb-buffer-file-name) (see ecb-utils.el) instead of plain (buffer-file-name) when you (semantic)need the underlying file of a buffer...because this also works for indirect buffers...

Could be that implementing A and B is quite easy but running all necessary tests, that all is working fine afterwars, could be a pain.... ;-)

Summary: IMHO semantic should be able to deal with indirect buffers because otherwise there could be really unwished, unexpected and also unknown sideeffects, which should be avoided with every software...


In the meanwhile i think i can add a small workaround to ECB so it is able to uses current semantic also for indirect buffers, at least to the needs of ECB.

Your thoughts?

Ciao,
Klaus

P.S.
Some weeks before i was in the same situation as you as i detected that ECB was too file-focussed in its internals... Now i have rewritten the source-handling backbone and now the source can either be a real filebuffer or an indirect-buffer if ist base-buffer is a file-buffer.... Dealing with completely file-unrelated buffers makes no sense for a code-browser, but indirect buffer can be senseful, see one of the news of next ECB-release:

** Complete reworked history-buffer

*** The history is able to deal with indirect-buffer entries.
    See new option `ecb-history-stick-indirect-buffers-to-basebuffer'.

*** The history can now be bucketized, see new `ecb-history-make-buckets'.
    This option allows to define several criterias for building buckets in the
    history-buffer all the history entries are sorted in (e.g. by major-mode,
    directory, file-extension or regular expressions).

    The latter one allows in combination with the indirect-buffer ability to
    work with something like "virtual folders" (well, "virtual folders"
    light).

    For example, there is a large project with a huge number of files, and
    there are various tasks in this project. So it could be convenient to
    group buffers according to various tasks. It could be fulfiled through
    using indirect buffers, for example like this

       task_1-aaa.pl
       task_1-bbb.c
       task_1-ccc.sh
       ...
       task_N-xxx.java
       task_N-ccc.sh

    This means create indirect buffers with a name-part which can be used for
    grouping together buffers with same name-part (here e.g. task_1- ...
    task_N-). In the example above you would create two indirect buffers for
    the filebuffer ccc.sh, one named task_1-ccc.sh, the other named
    task_N-ccc.sh).

    Then use the new option `ecb-history-make-buckets' to define regexps for
    bucketizing all (indirect) buffers according their task-part in the
    buffer-name.

This "virual folders" were a suggestion of a user and it sounded senseful in my ears ;-)

On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...

I have no idea how this work, but it sounds that there are some
properties on the overlays that points to position in a buffer. I
guess these are markers. Then maybe a check if the marker points to
the base buffer could be made just before use? Or perhaps that will be
too slow?

>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>
>I have no idea how this work, but it sounds that there are some
>properties on the overlays that points to position in a buffer. I
>guess these are markers. Then maybe a check if the marker points to
>the base buffer could be made just before use? Or perhaps that will be
>too slow?
  [ ... ]


I did an experiment.  I pulled up a simple C++ file, and cloned it.  I
examined the tag, and the tag in the cloned buffer was `eq' the
tag in base buffer.

I then ran:

C-u M-x bovinate RET

to reparse.  Now this throws away all the tag information, and
reparses.  The new tag was not `eq', and also did not have buffer file
names associated with it.

I suspect the "fix" is going to be easy.  First, we need to detect
when the clone is made, then mark the entire new buffer as needing a
full reparse.  Semantic will take care of the rest later, and have all
the tags marked correctly.  I don't think an unlink/link pass would
work since the raw tag data is shared at first.

There is a spiffy keybinding in senator:

C-c , /

which will show you details of the tag under point in the
data-debugger so you can navigate the structure.  It is very helpful
for stuff like this.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi Eric,

Hmm, sound senseful - al least at first glance...

On a second glance i want to point to the most recent posting i sent to you - this one, where i describe what happens after editing tags in the *indirect-buffer*... How does this behavior match your findings you describe below?!

But maybe you are right and fixing one small underlying problem-source in semantic fixes all other misbehaviors too.. But currently i'm slightly pessimistic ;-)

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...] 
Gesendet: Donnerstag, 16. April 2009 13:21
An: Lennart Borgman
Cc: Berndl, Klaus; cedet-devel@...
Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>
>I have no idea how this work, but it sounds that there are some 
>properties on the overlays that points to position in a buffer. I guess 
>these are markers. Then maybe a check if the marker points to the base 
>buffer could be made just before use? Or perhaps that will be too slow?
  [ ... ]


I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.

I then ran:

C-u M-x bovinate RET

to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.

I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.

There is a spiffy keybinding in senator:

C-c , /

which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

After playing a little bit i found other very mysterious behaviors:

1. Start Emacs with semantic activated and load a elisp file X
2. Go to a tag T (e.g. a defun)
3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
5. Go to the same tag T as in step 2
6. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X

well, we know already this failure, but now lets go further

7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument to the defun, if T is a defun)
8. Do M-: (semantic-current-tag) --> semantic returns the repares tag T with the new informations, fine!
9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the reparsed tag T with new informations but still the wrong buffer X

Well, same failure as after 6, but now it gets crazy

10. Now edit tag T in the indirect-buffer X<2>!! (e.g. remove the newly added argument from step 7) - do not save!
11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations but still the wrong buffer X
12. Switch back to buffer X (the base buffer) and move point to tag T
13: do M-: (semantic-current-tag) --> you get.................................... nil!! No tag T anymore in the base buffer after editing tag T in the indirect buffer..... 

Again: With current semantic working with indirect buffers yields to unpredictable side-effects. So either the users should get a warning not to work with indirect buffers and semantic or semantic should be fixed with that respect...

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...] 
Gesendet: Donnerstag, 16. April 2009 12:33
An: Berndl, Klaus
Cc: eric@...; cedet-devel@...
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea

On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...

I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow?

When you edit a buffer, Semantic will reparse only the local area.  It
will recycle the overlay, and splice the new tags into the existing
tags list.  Since the existing tags-list and overlays are all still
from the old buffer, you will get some mysterious behavior as
everything is now mixed.

I think you will find that forcing a reparse of the entire indirect
buffer will also fix the editing case, as the two tag streams will now
be independent.

Here is a patch you can try:

*** semantic.el.~1.212.~	2009-03-18 20:46:39.000000000 -0400
--- semantic.el	2009-04-16 08:29:37.000000000 -0400
***************
*** 299,304 ****
--- 299,309 ----
               (not (semantic-active-p))
               (not (run-hook-with-args-until-success
                     'semantic-inhibit-functions)))
+     ;; Make sure that if this buffer is cloned, our tags and overlays
+     ;; don't go along for the ride.
+     (add-hook 'clone-indirect-buffer-hook
+ 	      'semantic-clear-toplevel-cache
+ 	      nil t)
      ;; Specify that this function has done it's work.  At this point
      ;; we can consider that semantic is active in this buffer.
      (setq semantic-new-buffer-fcn-was-run t)
 

----------
This adds a hook to clear the cache when something is cloned.  Please
give it a try and let me know how it works.  I don't know if this is
really the right thing or not.

Thanks!
Eric

>>> <klaus.berndl@...> seems to think that:
>Hi Eric,
>
>Hmm, sound senseful - al least at first glance...
>
>On a second glance i want to point to the most recent posting i sent
>to you - this one, where i describe what happens after editing tags
>in the *indirect-buffer*... How does this behavior match your
>findings you describe below?!
>
>But maybe you are right and fixing one small underlying
>problem-source in semantic fixes all other misbehaviors too.. But
>currently i'm slightly pessimistic ;-)
>
>Ciao,
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...] 
>Gesendet: Donnerstag, 16. April 2009 13:21
>An: Lennart Borgman
>Cc: Berndl, Klaus; cedet-devel@...
>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea
>
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>
>>I have no idea how this work, but it sounds that there are some 
>>properties on the overlays that points to position in a buffer. I guess 
>>these are markers. Then maybe a check if the marker points to the base 
>>buffer could be made just before use? Or perhaps that will be too slow?
>  [ ... ]
>
>
>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>
>I then ran:
>
>C-u M-x bovinate RET
>
>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>
>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>
>There is a spiffy keybinding in senator:
>
>C-c , /
>
>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>
>Eric
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)!

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...] 
Gesendet: Donnerstag, 16. April 2009 14:32
An: Berndl, Klaus
Cc: lennart.borgman@...; cedet-devel@...
Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

When you edit a buffer, Semantic will reparse only the local area.  It will recycle the overlay, and splice the new tags into the existing tags list.  Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed.

I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent.

Here is a patch you can try:

*** semantic.el.~1.212.~	2009-03-18 20:46:39.000000000 -0400
--- semantic.el	2009-04-16 08:29:37.000000000 -0400
***************
*** 299,304 ****
--- 299,309 ----
               (not (semantic-active-p))
               (not (run-hook-with-args-until-success
                     'semantic-inhibit-functions)))
+     ;; Make sure that if this buffer is cloned, our tags and overlays
+     ;; don't go along for the ride.
+     (add-hook 'clone-indirect-buffer-hook
+ 	      'semantic-clear-toplevel-cache
+ 	      nil t)
      ;; Specify that this function has done it's work.  At this point
      ;; we can consider that semantic is active in this buffer.
      (setq semantic-new-buffer-fcn-was-run t)
 

----------
This adds a hook to clear the cache when something is cloned.  Please give it a try and let me know how it works.  I don't know if this is really the right thing or not.

Thanks!
Eric

>>> <klaus.berndl@...> seems to think that:
>Hi Eric,
>
>Hmm, sound senseful - al least at first glance...
>
>On a second glance i want to point to the most recent posting i sent to 
>you - this one, where i describe what happens after editing tags in the 
>*indirect-buffer*... How does this behavior match your findings you 
>describe below?!
>
>But maybe you are right and fixing one small underlying problem-source 
>in semantic fixes all other misbehaviors too.. But currently i'm 
>slightly pessimistic ;-)
>
>Ciao,
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Donnerstag, 16. April 2009 13:21
>An: Lennart Borgman
>Cc: Berndl, Klaus; cedet-devel@...
>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect 
>buffers? -some more findings and a solution idea
>
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>
>>I have no idea how this work, but it sounds that there are some 
>>properties on the overlays that points to position in a buffer. I 
>>guess these are markers. Then maybe a check if the marker points to 
>>the base buffer could be made just before use? Or perhaps that will be too slow?
>  [ ... ]
>
>
>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>
>I then ran:
>
>C-u M-x bovinate RET
>
>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>
>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>
>There is a spiffy keybinding in senator:
>
>C-c , /
>
>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>
>Eric
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

On Thu, Apr 16, 2009 at 3:04 PM,  <klaus.berndl@...> wrote:
> Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)!

2008-02-12  Stefan Monnier  <monnier@...>

	* simple.el (clone-indirect-buffer-hook): New hook.

Hmm,

IMHO cedet should be based on features of Emacs not contained in the official release! AFAIK Emacs 22.3.1 is still the official release and this one doesn't have this new hook! BTW: XEmacs doesn't have any clone-indirect-stuff - just make-indirect-buffer ... So what about the compatibility of cedet?! IMHO the importance of XEmacs goes south...... ;-) but cedet should be compatible at least with official releases of Gnu Emacs...

Klaus



-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...] 
Gesendet: Donnerstag, 16. April 2009 15:28
An: Berndl, Klaus
Cc: eric@...; cedet-devel@...
Betreff: Re: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

On Thu, Apr 16, 2009 at 3:04 PM,  <klaus.berndl@...> wrote:
> Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)!

2008-02-12  Stefan Monnier  <monnier@...>

	* simple.el (clone-indirect-buffer-hook): New hook.

Should be: "... IMHO cedet should NOT be based on..." 

-----Ursprüngliche Nachricht-----
Von: klaus.berndl@... [mailto:klaus.berndl@...] 
Gesendet: Donnerstag, 16. April 2009 15:42
An: lennart.borgman@...
Cc: cedet-devel@...; eric@...
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea

Hmm,

IMHO cedet should be based on features of Emacs not contained in the official release! AFAIK Emacs 22.3.1 is still the official release and this one doesn't have this new hook! BTW: XEmacs doesn't have any clone-indirect-stuff - just make-indirect-buffer ... So what about the compatibility of cedet?! IMHO the importance of XEmacs goes south...... ;-) but cedet should be compatible at least with official releases of Gnu Emacs...

Klaus



-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...]
Gesendet: Donnerstag, 16. April 2009 15:28
An: Berndl, Klaus
Cc: eric@...; cedet-devel@...
Betreff: Re: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

On Thu, Apr 16, 2009 at 3:04 PM,  <klaus.berndl@...> wrote:
> Hmmmm, thanks for a patch but what is `clone-indirect-buffer-hook'???? My Emacs doesn't have anything like this (Gnu Emacs 22.3.1)!

2008-02-12  Stefan Monnier  <monnier@...>

	* simple.el (clone-indirect-buffer-hook): New hook.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________
Cedet-devel mailing list
Cedet-devel@...
https://lists.sourceforge.net/lists/listinfo/cedet-devel

Ah.  I'm using Emacs 23 from CVS.  I guess that hook doesn't exist
everywhere.

Is there a way to do something similar in Emacs 22?  (I don't have a
copy.)

Eric

>>> <klaus.berndl@...> seems to think that:
>Hmmmm, thanks for a patch but what is
>`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like
>this (Gnu Emacs 22.3.1)!
>
>Ciao,
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...] 
>Gesendet: Donnerstag, 16. April 2009 14:32
>An: Berndl, Klaus
>Cc: lennart.borgman@...; cedet-devel@...
>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea
>
>When you edit a buffer, Semantic will reparse only the local area.  It will recycle the overlay, and splice the new tags into the existing tags list.  Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed.
>
>I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent.
>
>Here is a patch you can try:
>
>*** semantic.el.~1.212.~	2009-03-18 20:46:39.000000000 -0400
>--- semantic.el	2009-04-16 08:29:37.000000000 -0400
>***************
>*** 299,304 ****
>--- 299,309 ----
>               (not (semantic-active-p))
>               (not (run-hook-with-args-until-success
>                     'semantic-inhibit-functions)))
>+     ;; Make sure that if this buffer is cloned, our tags and overlays
>+     ;; don't go along for the ride.
>+     (add-hook 'clone-indirect-buffer-hook
>+ 	      'semantic-clear-toplevel-cache
>+ 	      nil t)
>      ;; Specify that this function has done it's work.  At this point
>      ;; we can consider that semantic is active in this buffer.
>      (setq semantic-new-buffer-fcn-was-run t)
> 
>
>----------
>This adds a hook to clear the cache when something is cloned.  Please give it a try and let me know how it works.  I don't know if this is really the right thing or not.
>
>Thanks!
>Eric
>
>>>> <klaus.berndl@...> seems to think that:
>>Hi Eric,
>>
>>Hmm, sound senseful - al least at first glance...
>>
>>On a second glance i want to point to the most recent posting i sent to 
>>you - this one, where i describe what happens after editing tags in the 
>>*indirect-buffer*... How does this behavior match your findings you 
>>describe below?!
>>
>>But maybe you are right and fixing one small underlying problem-source 
>>in semantic fixes all other misbehaviors too.. But currently i'm 
>>slightly pessimistic ;-)
>>
>>Ciao,
>>Klaus
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Eric M. Ludlam [mailto:eric@...]
>>Gesendet: Donnerstag, 16. April 2009 13:21
>>An: Lennart Borgman
>>Cc: Berndl, Klaus; cedet-devel@...
>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect 
>>buffers? -some more findings and a solution idea
>>
>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>>
>>>I have no idea how this work, but it sounds that there are some 
>>>properties on the overlays that points to position in a buffer. I 
>>>guess these are markers. Then maybe a check if the marker points to 
>>>the base buffer could be made just before use? Or perhaps that will be too slow?
>>  [ ... ]
>>
>>
>>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>>
>>I then ran:
>>
>>C-u M-x bovinate RET
>>
>>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>>
>>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>>
>>There is a spiffy keybinding in senator:
>>
>>C-c , /
>>
>>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>>
>>Eric
>>
>

There is no easy way (except to advice clone-indirect-buffer), but
isn't it good enough that it will work in Emacs 23 (which is in
pretest currently)?


On Thu, Apr 16, 2009 at 3:55 PM, Eric M. Ludlam <eric@...> wrote:
> Ah.  I'm using Emacs 23 from CVS.  I guess that hook doesn't exist
> everywhere.
>
> Is there a way to do something similar in Emacs 22?  (I don't have a
> copy.)
>
> Eric
>
>>>> <klaus.berndl@...> seems to think that:
>>Hmmmm, thanks for a patch but what is
>>`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like
>>this (Gnu Emacs 22.3.1)!
>>
>>Ciao,
>>Klaus
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Eric M. Ludlam [mailto:eric@...]
>>Gesendet: Donnerstag, 16. April 2009 14:32
>>An: Berndl, Klaus
>>Cc: lennart.borgman@...; cedet-devel@...
>>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea
>>
>>When you edit a buffer, Semantic will reparse only the local area.  It will recycle the overlay, and splice the new tags into the existing tags list.  Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed.
>>
>>I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent.
>>
>>Here is a patch you can try:
>>
>>*** semantic.el.~1.212.~       2009-03-18 20:46:39.000000000 -0400
>>--- semantic.el        2009-04-16 08:29:37.000000000 -0400
>>***************
>>*** 299,304 ****
>>--- 299,309 ----
>>               (not (semantic-active-p))
>>               (not (run-hook-with-args-until-success
>>                     'semantic-inhibit-functions)))
>>+     ;; Make sure that if this buffer is cloned, our tags and overlays
>>+     ;; don't go along for the ride.
>>+     (add-hook 'clone-indirect-buffer-hook
>>+            'semantic-clear-toplevel-cache
>>+            nil t)
>>      ;; Specify that this function has done it's work.  At this point
>>      ;; we can consider that semantic is active in this buffer.
>>      (setq semantic-new-buffer-fcn-was-run t)
>>
>>
>>----------
>>This adds a hook to clear the cache when something is cloned.  Please give it a try and let me know how it works.  I don't know if this is really the right thing or not.
>>
>>Thanks!
>>Eric
>>
>>>>> <klaus.berndl@...> seems to think that:
>>>Hi Eric,
>>>
>>>Hmm, sound senseful - al least at first glance...
>>>
>>>On a second glance i want to point to the most recent posting i sent to
>>>you - this one, where i describe what happens after editing tags in the
>>>*indirect-buffer*... How does this behavior match your findings you
>>>describe below?!
>>>
>>>But maybe you are right and fixing one small underlying problem-source
>>>in semantic fixes all other misbehaviors too.. But currently i'm
>>>slightly pessimistic ;-)
>>>
>>>Ciao,
>>>Klaus
>>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Eric M. Ludlam [mailto:eric@...]
>>>Gesendet: Donnerstag, 16. April 2009 13:21
>>>An: Lennart Borgman
>>>Cc: Berndl, Klaus; cedet-devel@...
>>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect
>>>buffers? -some more findings and a solution idea
>>>
>>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>>>
>>>>I have no idea how this work, but it sounds that there are some
>>>>properties on the overlays that points to position in a buffer. I
>>>>guess these are markers. Then maybe a check if the marker points to
>>>>the base buffer could be made just before use? Or perhaps that will be too slow?
>>>  [ ... ]
>>>
>>>
>>>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>>>
>>>I then ran:
>>>
>>>C-u M-x bovinate RET
>>>
>>>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>>>
>>>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>>>
>>>There is a spiffy keybinding in senator:
>>>
>>>C-c , /
>>>
>>>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>>>
>>>Eric
>>>
>>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

No, IMHO this isn't good enough - not every one upgrades his Emacs to the newest one immediately after the new release - this is not what i understand under the term "compatibility", when cedet only works with newest(!) GNU(!) Emacs(!)....

Apart from that you are right, there is no other way to reach the goal unless to advice clone-indirect-buffer which would not so bad - advices are a powerful and save tool - a small after-advice would be easily to implement...

But there is another drawback - independ if using the new hook or an advice: there is also the command make-indirect-buffer (internaly used by clone-indirect-buffer) which doesn't call the new hook clone-indirect-buffer-hook (IMHO a bug in Emacs because if there is such a hook, then it shpuld 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....

Anyway: cause of this there is only one chance: advicing make-indirect-buffer with an after-advice - unfortunatelly this function is defined in C-code anhd i'm not a big fan of advicing c-code routines..... But in general it is possible - maybe woth giving it a trey....

Or are there other solutions?

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...] 
Gesendet: Donnerstag, 16. April 2009 16:02
An: Eric M. Ludlam
Cc: Berndl, Klaus; cedet-devel@...
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

There is no easy way (except to advice clone-indirect-buffer), but isn't it good enough that it will work in Emacs 23 (which is in pretest currently)?


On Thu, Apr 16, 2009 at 3:55 PM, Eric M. Ludlam <eric@...> wrote:
> Ah.  I'm using Emacs 23 from CVS.  I guess that hook doesn't exist 
> everywhere.
>
> Is there a way to do something similar in Emacs 22?  (I don't have a
> copy.)
>
> Eric
>
>>>> <klaus.berndl@...> seems to think that:
>>Hmmmm, thanks for a patch but what is
>>`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like 
>>this (Gnu Emacs 22.3.1)!
>>
>>Ciao,
>>Klaus
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Eric M. Ludlam [mailto:eric@...]
>>Gesendet: Donnerstag, 16. April 2009 14:32
>>An: Berndl, Klaus
>>Cc: lennart.borgman@...; cedet-devel@...
>>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with 
>>indirect buffers? -some more findings and a solution idea
>>
>>When you edit a buffer, Semantic will reparse only the local area.  It will recycle the overlay, and splice the new tags into the existing tags list.  Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed.
>>
>>I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent.
>>
>>Here is a patch you can try:
>>
>>*** semantic.el.~1.212.~       2009-03-18 20:46:39.000000000 -0400
>>--- semantic.el        2009-04-16 08:29:37.000000000 -0400
>>***************
>>*** 299,304 ****
>>--- 299,309 ----
>>               (not (semantic-active-p))
>>               (not (run-hook-with-args-until-success
>>                     'semantic-inhibit-functions)))
>>+     ;; Make sure that if this buffer is cloned, our tags and 
>>+ overlays
>>+     ;; don't go along for the ride.
>>+     (add-hook 'clone-indirect-buffer-hook
>>+            'semantic-clear-toplevel-cache
>>+            nil t)
>>      ;; Specify that this function has done it's work.  At this point
>>      ;; we can consider that semantic is active in this buffer.
>>      (setq semantic-new-buffer-fcn-was-run t)
>>
>>
>>----------
>>This adds a hook to clear the cache when something is cloned.  Please give it a try and let me know how it works.  I don't know if this is really the right thing or not.
>>
>>Thanks!
>>Eric
>>
>>>>> <klaus.berndl@...> seems to think that:
>>>Hi Eric,
>>>
>>>Hmm, sound senseful - al least at first glance...
>>>
>>>On a second glance i want to point to the most recent posting i sent 
>>>to you - this one, where i describe what happens after editing tags 
>>>in the *indirect-buffer*... How does this behavior match your 
>>>findings you describe below?!
>>>
>>>But maybe you are right and fixing one small underlying 
>>>problem-source in semantic fixes all other misbehaviors too.. But 
>>>currently i'm slightly pessimistic ;-)
>>>
>>>Ciao,
>>>Klaus
>>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Eric M. Ludlam [mailto:eric@...]
>>>Gesendet: Donnerstag, 16. April 2009 13:21
>>>An: Lennart Borgman
>>>Cc: Berndl, Klaus; cedet-devel@...
>>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect 
>>>buffers? -some more findings and a solution idea
>>>
>>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>>>
>>>>I have no idea how this work, but it sounds that there are some 
>>>>properties on the overlays that points to position in a buffer. I 
>>>>guess these are markers. Then maybe a check if the marker points to 
>>>>the base buffer could be made just before use? Or perhaps that will be too slow?
>>>  [ ... ]
>>>
>>>
>>>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>>>
>>>I then ran:
>>>
>>>C-u M-x bovinate RET
>>>
>>>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>>>
>>>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>>>
>>>There is a spiffy keybinding in senator:
>>>
>>>C-c , /
>>>
>>>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>>>
>>>Eric
>>>
>>
>
> ----------------------------------------------------------------------
> -------- Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save $200 on 
> the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p 
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

I would agree if this problem with indirect buffers was a major
problem, but is it really that?

Please report the problem with the make-indirect-buffer and the hook
as a bug in Emacs. I am afraid I do not understand exactly why it is
implemented as it is, but I am sure there are others that do.


On Thu, Apr 16, 2009 at 4:14 PM,  <klaus.berndl@...> wrote:
> No, IMHO this isn't good enough - not every one upgrades his Emacs to the newest one immediately after the new release - this is not what i understand under the term "compatibility", when cedet only works with newest(!) GNU(!) Emacs(!)....
>
> Apart from that you are right, there is no other way to reach the goal unless to advice clone-indirect-buffer which would not so bad - advices are a powerful and save tool - a small after-advice would be easily to implement...
>
> But there is another drawback - independ if using the new hook or an advice: there is also the command make-indirect-buffer (internaly used by clone-indirect-buffer) which doesn't call the new hook clone-indirect-buffer-hook (IMHO a bug in Emacs because if there is such a hook, then it shpuld 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....
>
> Anyway: cause of this there is only one chance: advicing make-indirect-buffer with an after-advice - unfortunatelly this function is defined in C-code anhd i'm not a big fan of advicing c-code routines..... But in general it is possible - maybe woth giving it a trey....
>
> Or are there other solutions?
>
> Ciao,
> Klaus
>
> -----Ursprüngliche Nachricht-----
> Von: Lennart Borgman [mailto:lennart.borgman@...]
> Gesendet: Donnerstag, 16. April 2009 16:02
> An: Eric M. Ludlam
> Cc: Berndl, Klaus; cedet-devel@...
> Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea
>
> There is no easy way (except to advice clone-indirect-buffer), but isn't it good enough that it will work in Emacs 23 (which is in pretest currently)?
>
>
> On Thu, Apr 16, 2009 at 3:55 PM, Eric M. Ludlam <eric@...> wrote:
>> Ah.  I'm using Emacs 23 from CVS.  I guess that hook doesn't exist
>> everywhere.
>>
>> Is there a way to do something similar in Emacs 22?  (I don't have a
>> copy.)
>>
>> Eric
>>
>>>>> <klaus.berndl@...> seems to think that:
>>>Hmmmm, thanks for a patch but what is
>>>`clone-indirect-buffer-hook'???? My Emacs doesn't have anything like
>>>this (Gnu Emacs 22.3.1)!
>>>
>>>Ciao,
>>>Klaus
>>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Eric M. Ludlam [mailto:eric@...]
>>>Gesendet: Donnerstag, 16. April 2009 14:32
>>>An: Berndl, Klaus
>>>Cc: lennart.borgman@...; cedet-devel@...
>>>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with
>>>indirect buffers? -some more findings and a solution idea
>>>
>>>When you edit a buffer, Semantic will reparse only the local area.  It will recycle the overlay, and splice the new tags into the existing tags list.  Since the existing tags-list and overlays are all still from the old buffer, you will get some mysterious behavior as everything is now mixed.
>>>
>>>I think you will find that forcing a reparse of the entire indirect buffer will also fix the editing case, as the two tag streams will now be independent.
>>>
>>>Here is a patch you can try:
>>>
>>>*** semantic.el.~1.212.~       2009-03-18 20:46:39.000000000 -0400
>>>--- semantic.el        2009-04-16 08:29:37.000000000 -0400
>>>***************
>>>*** 299,304 ****
>>>--- 299,309 ----
>>>               (not (semantic-active-p))
>>>               (not (run-hook-with-args-until-success
>>>                     'semantic-inhibit-functions)))
>>>+     ;; Make sure that if this buffer is cloned, our tags and
>>>+ overlays
>>>+     ;; don't go along for the ride.
>>>+     (add-hook 'clone-indirect-buffer-hook
>>>+            'semantic-clear-toplevel-cache
>>>+            nil t)
>>>      ;; Specify that this function has done it's work.  At this point
>>>      ;; we can consider that semantic is active in this buffer.
>>>      (setq semantic-new-buffer-fcn-was-run t)
>>>
>>>
>>>----------
>>>This adds a hook to clear the cache when something is cloned.  Please give it a try and let me know how it works.  I don't know if this is really the right thing or not.
>>>
>>>Thanks!
>>>Eric
>>>
>>>>>> <klaus.berndl@...> seems to think that:
>>>>Hi Eric,
>>>>
>>>>Hmm, sound senseful - al least at first glance...
>>>>
>>>>On a second glance i want to point to the most recent posting i sent
>>>>to you - this one, where i describe what happens after editing tags
>>>>in the *indirect-buffer*... How does this behavior match your
>>>>findings you describe below?!
>>>>
>>>>But maybe you are right and fixing one small underlying
>>>>problem-source in semantic fixes all other misbehaviors too.. But
>>>>currently i'm slightly pessimistic ;-)
>>>>
>>>>Ciao,
>>>>Klaus
>>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Eric M. Ludlam [mailto:eric@...]
>>>>Gesendet: Donnerstag, 16. April 2009 13:21
>>>>An: Lennart Borgman
>>>>Cc: Berndl, Klaus; cedet-devel@...
>>>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect
>>>>buffers? -some more findings and a solution idea
>>>>
>>>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>>>On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
>>>>>> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...
>>>>>
>>>>>I have no idea how this work, but it sounds that there are some
>>>>>properties on the overlays that points to position in a buffer. I
>>>>>guess these are markers. Then maybe a check if the marker points to
>>>>>the base buffer could be made just before use? Or perhaps that will be too slow?
>>>>  [ ... ]
>>>>
>>>>
>>>>I did an experiment.  I pulled up a simple C++ file, and cloned it.  I examined the tag, and the tag in the cloned buffer was `eq' the tag in base buffer.
>>>>
>>>>I then ran:
>>>>
>>>>C-u M-x bovinate RET
>>>>
>>>>to reparse.  Now this throws away all the tag information, and reparses.  The new tag was not `eq', and also did not have buffer file names associated with it.
>>>>
>>>>I suspect the "fix" is going to be easy.  First, we need to detect when the clone is made, then mark the entire new buffer as needing a full reparse.  Semantic will take care of the rest later, and have all the tags marked correctly.  I don't think an unlink/link pass would work since the raw tag data is shared at first.
>>>>
>>>>There is a spiffy keybinding in senator:
>>>>
>>>>C-c , /
>>>>
>>>>which will show you details of the tag under point in the data-debugger so you can navigate the structure.  It is very helpful for stuff like this.
>>>>
>>>>Eric
>>>>
>>>
>>
>> ----------------------------------------------------------------------
>> -------- Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save $200 on
>> the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Cedet-devel mailing list
>> Cedet-devel@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>
>

>I would agree if this problem with indirect buffers was a major problem, but is it really that?

Yep, this is a good question - i'm in two minds about this: probably not really many people are working with indirect buffer, this would allow to vote for minor-problem - on the other side there are really ugly side-effects if you use indirect-buffers...

I tend to this: the solution with clone-indirect-buffer-hook is quite useless cause of the make-indirect-buffer problem - at least as long this is not fixed by the Emacs people...
But the clone-indirect-buffer-hook would be already now a good chance to test if Eric's patch solves the whole indirect-buffer-problems of semantic...but i do not have an Emacs 23 copy (where to get a Windows-prebuild - i'm not willwing to compile an Emacs for myself) - could one of you test this with my reported scenarios?

>Please report the problem with the make-indirect-buffer and the hook as a bug in Emacs. I am afraid I do not understand 
>exactly why it is implemented as it is, but I am sure there are others that do.

Where is an guidance how to report an emacs bug?

Thanks
Klaus

Just do

   M-x report-emacs-bug

You can also find this in the menus, under "Help".


On Thu, Apr 16, 2009 at 4:34 PM,  <klaus.berndl@...> wrote:
>>I would agree if this problem with indirect buffers was a major problem, but is it really that?
>
> Yep, this is a good question - i'm in two minds about this: probably not really many people are working with indirect buffer, this would allow to vote for minor-problem - on the other side there are really ugly side-effects if you use indirect-buffers...
>
> I tend to this: the solution with clone-indirect-buffer-hook is quite useless cause of the make-indirect-buffer problem - at least as long this is not fixed by the Emacs people...
> But the clone-indirect-buffer-hook would be already now a good chance to test if Eric's patch solves the whole indirect-buffer-problems of semantic...but i do not have an Emacs 23 copy (where to get a Windows-prebuild - i'm not willwing to compile an Emacs for myself) - could one of you test this with my reported scenarios?
>
>>Please report the problem with the make-indirect-buffer and the hook as a bug in Emacs. I am afraid I do not understand
>>exactly why it is implemented as it is, but I am sure there are others that do.
>
> Where is an guidance how to report an emacs bug?
>
> Thanks
> Klaus
>
>

Hi all,

Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results:

1. Start Emacs with semantic activated and load a elisp file X
2. Go to a tag T (e.g. a defun)
3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
5. Go to the same tag T as in step 2
6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine!

7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun)
8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine!
9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2>

10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save!
11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer  X<2>
12. Switch back to buffer X (the base buffer) and move point to tag T
13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X

Summary: With this patch the indirect-buffer has the right buffer-information, which is good. Then the tag-lists seems to be completely independent, so editing one buffer does not influence not the other one - which is also good!

What i'm wondering why running semantic-current-tag does not automatically return the newly reparsed tag but the old one (i assume from the semantic tag-cache) - see steps 9. and 13. above... Is this a correct behavior? The charme of indirect buffers is that editing takes effect in the base-buffer an all related indirect buffers: so if i edit (en edition which triggers a reparse!) a tag e.g. the base-buffer then the changes are also in the indirect-buffer so i would expect that when switching to the indirect-buffer (as in step 9) then semantic should recognize that also this buffer has been changed and therefore automatically reparse when i call semantic-curre3nt-tag (as is done in step 8 above)...

Why does this not work? Is this because the tag-cache of semantic is file-centric? Or have i misunderstood something??

Conclusion: Eric's patch seems to be a great step forward but not perfect... ;-)

Thansk for your help!
Klaus
 

-----Ursprüngliche Nachricht-----
Von: klaus.berndl@... [mailto:klaus.berndl@...] 
Gesendet: Donnerstag, 16. April 2009 14:10
An: lennart.borgman@...
Cc: cedet-devel@...; eric@...
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

After playing a little bit i found other very mysterious behaviors:

1. Start Emacs with semantic activated and load a elisp file X
2. Go to a tag T (e.g. a defun)
3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
5. Go to the same tag T as in step 2
6. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X

well, we know already this failure, but now lets go further

7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument to the defun, if T is a defun)
8. Do M-: (semantic-current-tag) --> semantic returns the repares tag T with the new informations, fine!
9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the reparsed tag T with new informations but still the wrong buffer X

Well, same failure as after 6, but now it gets crazy

10. Now edit tag T in the indirect-buffer X<2>!! (e.g. remove the newly added argument from step 7) - do not save!
11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations but still the wrong buffer X
12. Switch back to buffer X (the base buffer) and move point to tag T
13: do M-: (semantic-current-tag) --> you get.................................... nil!! No tag T anymore in the base buffer after editing tag T in the indirect buffer..... 

Again: With current semantic working with indirect buffers yields to unpredictable side-effects. So either the users should get a warning not to work with indirect buffers and semantic or semantic should be fixed with that respect...

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...] 
Gesendet: Donnerstag, 16. April 2009 12:33
An: Berndl, Klaus
Cc: eric@...; cedet-devel@...
Betreff: Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea

On Thu, Apr 16, 2009 at 10:29 AM,  <klaus.berndl@...> wrote:
> A) Ensure that the overlays (at least the semantic related) of an indirect-buffer contain the buffer-object of the indirect-buffer and not the base-buffer... If Emacs does this not automatically (which could be a bug) then maybe semantic could do this itself, e.g. by advicing make-indirect-buffer and rebuilding all semantic-overlays so afterwards the correct buffer is returned by overlay-buffer... Maybe this needs more digging...

I have no idea how this work, but it sounds that there are some properties on the overlays that points to position in a buffer. I guess these are markers. Then maybe a check if the marker points to the base buffer could be made just before use? Or perhaps that will be too slow?

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Cedet-devel mailing list
Cedet-devel@...
https://lists.sourceforge.net/lists/listinfo/cedet-devel

>>> <klaus.berndl@...> seems to think that:
>>I would agree if this problem with indirect buffers was a major problem, but is it really that?
>
>Yep, this is a good question - i'm in two minds about this: probably not really many people are working with indirect buffer, this would allow to vote for minor-problem - on the other side there are really ugly side-effects if you use indirect-buffers...
>
>I tend to this: the solution with clone-indirect-buffer-hook is quite useless cause of the make-indirect-buffer problem - at least as long this is not fixed by the Emacs people...
>But the clone-indirect-buffer-hook would be already now a good chance to test if Eric's patch solves the whole indirect-buffer-problems of semantic...but i do not have an Emacs 23 copy (where to get a Windows-prebuild - i'm not willwing to compile an Emacs for myself) - could one of you test this with my reported scenarios?
>
  [ ... ]

Hi,

  Here is a different patch that doesn't depend on the hook.  It uses
a side-effect of the cloning process to detect a change.  Not as
robust as the other solution with the hook, but it will work when the
hook fails.

Enjoy
Eric

--------
*** semantic.el.~1.212.~	2009-03-18 20:46:39.000000000 -0400
--- semantic.el	2009-04-16 11:40:40.000000000 -0400
***************
*** 244,256 ****
    "Return non-nil if the current parse tree needs to be rebuilt."
    `(eq semantic-parse-tree-state 'needs-rebuild))
  
  (defmacro semantic-parse-tree-set-up-to-date ()
    "Indicate that the current parse tree is up to date."
    `(setq semantic-parse-tree-state nil))
  
  (defmacro semantic-parse-tree-up-to-date-p ()
    "Return non-nil if the current parse tree is up to date."
!   `(null semantic-parse-tree-state))
  
  ;;; Interfacing with the system
  ;;
--- 244,268 ----
    "Return non-nil if the current parse tree needs to be rebuilt."
    `(eq semantic-parse-tree-state 'needs-rebuild))
  
+ (defvar semantic-not-indirect-buffer-p nil
+   "Non-nil for a buffer initialized by Semantic that is not an indirect buffer.")
+ (make-variable-buffer-local 'semantic-not-indirect-buffer-p)  
+ 
+ (defun semantic-parse-tree-needs-indirect-reparse-p ()
+   "Return non-nil of the current buffer is indirect, and needs a full reparse.
+ Indirect buffers can copy over tag data, sharing cons-cells which can
+ break the incremental parser."
+   (and semantic-not-indirect-buffer-p (fboundp 'buffer-base-buffer) (buffer-base-buffer)))
+ 
  (defmacro semantic-parse-tree-set-up-to-date ()
    "Indicate that the current parse tree is up to date."
    `(setq semantic-parse-tree-state nil))
  
  (defmacro semantic-parse-tree-up-to-date-p ()
    "Return non-nil if the current parse tree is up to date."
!   `(and (null semantic-parse-tree-state)
! 	(null (semantic-parse-tree-needs-indirect-reparse-p))
! 	))
  
  ;;; Interfacing with the system
  ;;
***************
*** 299,304 ****
--- 311,326 ----
               (not (semantic-active-p))
               (not (run-hook-with-args-until-success
                     'semantic-inhibit-functions)))
+ ;    ;; Make sure that if this buffer is cloned, our tags and overlays
+ ;    ;; don't go along for the ride.
+ ;    (add-hook 'clone-indirect-buffer-hook
+ ;	      'semantic-clear-toplevel-cache
+ ;	      nil t)
+     ;; Setup this buffer to know if it is indirect or not.  This local
+     ;; variable will be cloned for an indirect buffer, and we can detect
+     ;; if we need a full reparse.
+     (setq semantic-not-indirect-buffer-p
+ 	  (and (fboundp 'buffer-base-buffer) (null (buffer-base-buffer))))
      ;; Specify that this function has done it's work.  At this point
      ;; we can consider that semantic is active in this buffer.
      (setq semantic-new-buffer-fcn-was-run t)
***************
*** 323,329 ****
  (defun semantic-fetch-tags-fast ()
    "For use in a hook.  When only a partial reparse is needed, reparse."
    (condition-case nil
!       (if (semantic-parse-tree-needs-update-p)
  	  (semantic-fetch-tags))
      (error nil))
    semantic--buffer-cache)
--- 345,352 ----
  (defun semantic-fetch-tags-fast ()
    "For use in a hook.  When only a partial reparse is needed, reparse."
    (condition-case nil
!       (if (or (semantic-parse-tree-needs-indirect-reparse-p)
! 	      (semantic-parse-tree-needs-update-p))
  	  (semantic-fetch-tags))
      (error nil))
    semantic--buffer-cache)
***************
*** 566,571 ****
--- 589,600 ----
       (garbage-collect)
       (cond
     
+ ;;;; If this is our first call in a new indirect buffer, full update.
+       ((semantic-parse-tree-needs-indirect-reparse-p)
+        (semantic-parse-tree-set-needs-rebuild)
+        (setq semantic-not-indirect-buffer-p nil)
+        (semantic-fetch-tags))
+ 
  ;;;; Try the incremental parser to do a fast update.
       ((semantic-parse-tree-needs-update-p)
        (setq res (semantic-parse-changes))

Hi Eric,

Thank you - but before i test this new patch one question:

How do you judge your new patch concerning the results i wrote to you  in my recent posting (which contain test-results for your frist patch, the hook-based one)?

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...] 
Gesendet: Donnerstag, 16. April 2009 17:41
An: Berndl, Klaus
Cc: lennart.borgman@...; cedet-devel@...
Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea

>>> <klaus.berndl@...> seems to think that:
>>I would agree if this problem with indirect buffers was a major problem, but is it really that?
>
>Yep, this is a good question - i'm in two minds about this: probably not really many people are working with indirect buffer, this would allow to vote for minor-problem - on the other side there are really ugly side-effects if you use indirect-buffers...
>
>I tend to this: the solution with clone-indirect-buffer-hook is quite useless cause of the make-indirect-buffer problem - at least as long this is not fixed by the Emacs people...
>But the clone-indirect-buffer-hook would be already now a good chance to test if Eric's patch solves the whole indirect-buffer-problems of semantic...but i do not have an Emacs 23 copy (where to get a Windows-prebuild - i'm not willwing to compile an Emacs for myself) - could one of you test this with my reported scenarios?
>
  [ ... ]

Hi,

  Here is a different patch that doesn't depend on the hook.  It uses a side-effect of the cloning process to detect a change.  Not as robust as the other solution with the hook, but it will work when the hook fails.

Enjoy
Eric

--------
*** semantic.el.~1.212.~	2009-03-18 20:46:39.000000000 -0400
--- semantic.el	2009-04-16 11:40:40.000000000 -0400
***************
*** 244,256 ****
    "Return non-nil if the current parse tree needs to be rebuilt."
    `(eq semantic-parse-tree-state 'needs-rebuild))
  
  (defmacro semantic-parse-tree-set-up-to-date ()
    "Indicate that the current parse tree is up to date."
    `(setq semantic-parse-tree-state nil))
  
  (defmacro semantic-parse-tree-up-to-date-p ()
    "Return non-nil if the current parse tree is up to date."
!   `(null semantic-parse-tree-state))
  
  ;;; Interfacing with the system
  ;;
--- 244,268 ----
    "Return non-nil if the current parse tree needs to be rebuilt."
    `(eq semantic-parse-tree-state 'needs-rebuild))
  
+ (defvar semantic-not-indirect-buffer-p nil
+   "Non-nil for a buffer initialized by Semantic that is not an 
+ indirect buffer.") (make-variable-buffer-local 
+ 'semantic-not-indirect-buffer-p)
+ 
+ (defun semantic-parse-tree-needs-indirect-reparse-p ()
+   "Return non-nil of the current buffer is indirect, and needs a full reparse.
+ Indirect buffers can copy over tag data, sharing cons-cells which can 
+ break the incremental parser."
+   (and semantic-not-indirect-buffer-p (fboundp 'buffer-base-buffer) 
+ (buffer-base-buffer)))
+ 
  (defmacro semantic-parse-tree-set-up-to-date ()
    "Indicate that the current parse tree is up to date."
    `(setq semantic-parse-tree-state nil))
  
  (defmacro semantic-parse-tree-up-to-date-p ()
    "Return non-nil if the current parse tree is up to date."
!   `(and (null semantic-parse-tree-state)
! 	(null (semantic-parse-tree-needs-indirect-reparse-p))
! 	))
  
  ;;; Interfacing with the system
  ;;
***************
*** 299,304 ****
--- 311,326 ----
               (not (semantic-active-p))
               (not (run-hook-with-args-until-success
                     'semantic-inhibit-functions)))
+ ;    ;; Make sure that if this buffer is cloned, our tags and overlays
+ ;    ;; don't go along for the ride.
+ ;    (add-hook 'clone-indirect-buffer-hook
+ ;	      'semantic-clear-toplevel-cache
+ ;	      nil t)
+     ;; Setup this buffer to know if it is indirect or not.  This local
+     ;; variable will be cloned for an indirect buffer, and we can detect
+     ;; if we need a full reparse.
+     (setq semantic-not-indirect-buffer-p
+ 	  (and (fboundp 'buffer-base-buffer) (null (buffer-base-buffer))))
      ;; Specify that this function has done it's work.  At this point
      ;; we can consider that semantic is active in this buffer.
      (setq semantic-new-buffer-fcn-was-run t)
***************
*** 323,329 ****
  (defun semantic-fetch-tags-fast ()
    "For use in a hook.  When only a partial reparse is needed, reparse."
    (condition-case nil
!       (if (semantic-parse-tree-needs-update-p)
  	  (semantic-fetch-tags))
      (error nil))
    semantic--buffer-cache)
--- 345,352 ----
  (defun semantic-fetch-tags-fast ()
    "For use in a hook.  When only a partial reparse is needed, reparse."
    (condition-case nil
!       (if (or (semantic-parse-tree-needs-indirect-reparse-p)
! 	      (semantic-parse-tree-needs-update-p))
  	  (semantic-fetch-tags))
      (error nil))
    semantic--buffer-cache)
***************
*** 566,571 ****
--- 589,600 ----
       (garbage-collect)
       (cond
     
+ ;;;; If this is our first call in a new indirect buffer, full update.
+       ((semantic-parse-tree-needs-indirect-reparse-p)
+        (semantic-parse-tree-set-needs-rebuild)
+        (setq semantic-not-indirect-buffer-p nil)
+        (semantic-fetch-tags))
+ 
  ;;;; Try the incremental parser to do a fast update.
       ((semantic-parse-tree-needs-update-p)
        (setq res (semantic-parse-changes))

>>> <klaus.berndl@...> seems to think that:
>Hi all,
>
>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results:
>
>1. Start Emacs with semantic activated and load a elisp file X
>2. Go to a tag T (e.g. a defun)
>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
>5. Go to the same tag T as in step 2
>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine!
>
>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun)
>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine!
>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2>
>
>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save!
>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer  X<2>
>12. Switch back to buffer X (the base buffer) and move point to tag T
>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X
>
>Summary: With this patch the indirect-buffer has the right
>buffer-information, which is good. Then the tag-lists seems to be
>completely independent, so editing one buffer does not influence not
>the other one - which is also good!
>
>What i'm wondering why running semantic-current-tag does not
>automatically return the newly reparsed tag but the old one (i assume
>from the semantic tag-cache) - see steps 9. and 13. above... Is this
>a correct behavior? The charme of indirect buffers is that editing
>takes effect in the base-buffer an all related indirect buffers: so
>if i edit (en edition which triggers a reparse!) a tag e.g. the
>base-buffer then the changes are also in the indirect-buffer so i
>would expect that when switching to the indirect-buffer (as in step
>9) then semantic should recognize that also this buffer has been
>changed and therefore automatically reparse when i call
>semantic-curre3nt-tag (as is done in step 8 above)...
>
>Why does this not work? Is this because the tag-cache of semantic is
>file-centric? Or have i misunderstood something??

The command `semantic-current-tag', like many very basic commands, do
not request a reparse.  Reparses are requested by top-level commands
before they call utility functions.  This saves time since a single
top-level command might call hundreds of low-level commands.  Each one
does not need to do the reparse duties.  In particular, utilities like
SRecode which edits buffers wants to be in control of when a buffer is
reparsed, in case it is only part-way through a code-creation function
when it needs to call some utility.

Use the senator command `senator-adebug-tag' which will do the reparse
for you.  Or you can wait 3 seconds, and the idle timer will clean
everything up for you.

Does that help?

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

I think the problem where you can create a cloned buffer w/out running
the hook in Emacs 23 would be a problem the new patch can help with.
The other issue with the tags not being up to date when calling a
utility function I discussed in a different email.  (We seem to be
coding at the same time.)

I'd prefer the hook solution.  I think it will serve everyone best.
Together, the two patches should work together well.

Eric

>>> <klaus.berndl@...> seems to think that:
>Hi Eric,
>
>Thank you - but before i test this new patch one question:
>
>How do you judge your new patch concerning the results i wrote to you  in my recent posting (which contain test-results for your frist patch, the hook-based one)?
>
>Ciao,
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...] 
>Gesendet: Donnerstag, 16. April 2009 17:41
>An: Berndl, Klaus
>Cc: lennart.borgman@...; cedet-devel@...
>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirect buffers? -some more findings and a solution idea
>
>>>> <klaus.berndl@...> seems to think that:
>>>I would agree if this problem with indirect buffers was a major problem, but is it really that?
>>
>>Yep, this is a good question - i'm in two minds about this: probably not really many people are working with indirect buffer, this would allow to vote for minor-problem - on the other side there are really ugly side-effects if you use indirect-buffers...
>>
>>I tend to this: the solution with clone-indirect-buffer-hook is quite useless cause of the make-indirect-buffer problem - at least as long this is not fixed by the Emacs people...
>>But the clone-indirect-buffer-hook would be already now a good chance to test if Eric's patch solves the whole indirect-buffer-problems of semantic...but i do not have an Emacs 23 copy (where to get a Windows-prebuild - i'm not willwing to compile an Emacs for myself) - could one of you test this with my reported scenarios?
>>
>  [ ... ]
>
>Hi,
>
>  Here is a different patch that doesn't depend on the hook.  It uses a side-effect of the cloning process to detect a change.  Not as robust as the other solution with the hook, but it will work when the hook fails.
>
>Enjoy
>Eric
>
  [ ... ]

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not?

To be clear:
If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag.
Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) 

Is this ok too for you? Why?

Thanks
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...] 
Gesendet: Donnerstag, 16. April 2009 17:47
An: Berndl, Klaus
Cc: Berndl, Klaus; lennart.borgman@...; cedet-devel@...
Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea

>>> <klaus.berndl@...> seems to think that:
>Hi all,
>
>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results:
>
>1. Start Emacs with semantic activated and load a elisp file X
>2. Go to a tag T (e.g. a defun)
>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
>5. Go to the same tag T as in step 2
>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine!
>
>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun)
>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine!
>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2>
>
>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save!
>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer  X<2>
>12. Switch back to buffer X (the base buffer) and move point to tag T
>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X
>
>Summary: With this patch the indirect-buffer has the right
>buffer-information, which is good. Then the tag-lists seems to be
>completely independent, so editing one buffer does not influence not
>the other one - which is also good!
>
>What i'm wondering why running semantic-current-tag does not
>automatically return the newly reparsed tag but the old one (i assume
>from the semantic tag-cache) - see steps 9. and 13. above... Is this
>a correct behavior? The charme of indirect buffers is that editing
>takes effect in the base-buffer an all related indirect buffers: so
>if i edit (en edition which triggers a reparse!) a tag e.g. the
>base-buffer then the changes are also in the indirect-buffer so i
>would expect that when switching to the indirect-buffer (as in step
>9) then semantic should recognize that also this buffer has been
>changed and therefore automatically reparse when i call
>semantic-curre3nt-tag (as is done in step 8 above)...
>
>Why does this not work? Is this because the tag-cache of semantic is
>file-centric? Or have i misunderstood something??

The command `semantic-current-tag', like many very basic commands, do
not request a reparse.  Reparses are requested by top-level commands
before they call utility functions.  This saves time since a single
top-level command might call hundreds of low-level commands.  Each one
does not need to do the reparse duties.  In particular, utilities like
SRecode which edits buffers wants to be in control of when a buffer is
reparsed, in case it is only part-way through a code-creation function
when it needs to call some utility.

Use the senator command `senator-adebug-tag' which will do the reparse
for you.  Or you can wait 3 seconds, and the idle timer will clean
everything up for you.

Does that help?

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Ah, I think I understand better.

It appears that the hooks I use to track edits don't work in linked
buffers.  If you enable global-semantic-highlight-edits-mode, you will
see that it finds things you edit, but the mirror edits in the other
linked buffers do not get their change hooks run, and thus you don't
see the highlight.

I suppose I could look for all buffers that are linked together and
propagate the change.  That seems kind of unpleasant as I can find no
function to get that info.  I don't think an after-change-function
should be looping over every buffer looking for indirect buffers
associated with it.  That sounds painfully slow.

Eric

>>> <klaus.berndl@...> seems to think that:
>Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not?
>
>To be clear:
>If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag.
>Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) 
>
>Is this ok too for you? Why?
>
>Thanks
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...] 
>Gesendet: Donnerstag, 16. April 2009 17:47
>An: Berndl, Klaus
>Cc: Berndl, Klaus; lennart.borgman@...; cedet-devel@...
>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea
>
>>>> <klaus.berndl@...> seems to think that:
>>Hi all,
>>
>>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results:
>>
>>1. Start Emacs with semantic activated and load a elisp file X
>>2. Go to a tag T (e.g. a defun)
>>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
>>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
>>5. Go to the same tag T as in step 2
>>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine!
>>
>>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun)
>>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine!
>>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffeer X<2>
>>
>>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save!
>>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer  X<2>
>>12. Switch back to buffer X (the base buffer) and move point to tag T
>>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X
>>
>>Summary: With this patch the indirect-buffer has the right
>>buffer-information, which is good. Then the tag-lists seems to be
>>completely independent, so editing one buffer does not influence not
>>the other one - which is also good!
>>
>>What i'm wondering why running semantic-current-tag does not
>>automatically return the newly reparsed tag but the old one (i assume
>>from the semantic tag-cache) - see steps 9. and 13. above... Is this
>>a correct behavior? The charme of indirect buffers is that editing
>>takes effect in the base-buffer an all related indirect buffers: so
>>if i edit (en edition which triggers a reparse!) a tag e.g. the
>>base-buffer then the changes are also in the indirect-buffer so i
>>would expect that when switching to the indirect-buffer (as in step
>>9) then semantic should recognize that also this buffer has been
>>changed and therefore automatically reparse when i call
>>semantic-curre3nt-tag (as is done in step 8 above)...
>>
>>Why does this not work? Is this because the tag-cache of semantic is
>>file-centric? Or have i misunderstood something??
>
>The command `semantic-current-tag', like many very basic commands, do
>not request a reparse.  Reparses are requested by top-level commands
>before they call utility functions.  This saves time since a single
>top-level command might call hundreds of low-level commands.  Each one
>does not need to do the reparse duties.  In particular, utilities like
>SRecode which edits buffers wants to be in control of when a buffer is
>reparsed, in case it is only part-way through a code-creation function
>when it needs to call some utility.
>
>Use the senator command `senator-adebug-tag' which will do the reparse
>for you.  Or you can wait 3 seconds, and the idle timer will clean
>everything up for you.
>
>Does that help?
>
>Eric
>

Yep, i agree - this is nothing which should be added to a after-change-function...

The logic is easy, ECB has already somehting:

(defun ecb-indirect-buffers-of-buffer (&optional buffer-or-name)
  (let ((buffer (if (null buffer-or-name)
                    (current-buffer)
                  (if (and (bufferp buffer-or-name)
                           (buffer-live-p buffer-or-name))
                      buffer-or-name
                    (if (stringp buffer-or-name)
                        (get-buffer buffer-or-name))))))
    (delq nil (mapcar (function
                       (lambda (buf)
                         (if (equal buffer (buffer-base-buffer buf))
                             buf)))
                      (buffer-list)))))

but within ECB this is only used on demand and then run only once...

Hmm, currently i'm at a loss with this... do not good enough the internal mechanisms of semantic... maybe this is something to be ask the Emacs-gurus - in general Emacs must already have a linkage between all these related buffers because if you kill the base-buffer then all indirect-buffers of it are killed automatically too...

IMHO this propagation of hooks-running should be done internally be Emacs...what do you think? Should we file a problem-report to the emacs-devel-group?

Ciao,
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...]
Gesendet: Do 16.04.2009 19:49
An: Berndl, Klaus
Cc: cedet-devel@...
Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
 
Ah, I think I understand better.

It appears that the hooks I use to track edits don't work in linked
buffers.  If you enable global-semantic-highlight-edits-mode, you will
see that it finds things you edit, but the mirror edits in the other
linked buffers do not get their change hooks run, and thus you don't
see the highlight.

I suppose I could look for all buffers that are linked together and
propagate the change.  That seems kind of unpleasant as I can find no
function to get that info.  I don't think an after-change-function
should be looping over every buffer looking for indirect buffers
associated with it.  That sounds painfully slow.

Eric

>>> <klaus.berndl@...> seems to think that:
>Hmm, i know all this you explained to me - i.e. i know that semantic-current-tag does not trigger a parse-run - but nevertheless the indirect changed indirectbuffer (means changes has been done via the base-buffer) is not parsed - the idle-triggered reparse takes not place - this is what i'm wondering, why not?
>
>To be clear:
>If i change a tag in a base-buffer, than here the buffer is reparsed after 3 seconds and semantic-current-tag returns the modified tag.
>Such a change influences all indirect-buffers of the base buffer - but when i switch to one of these indirect buffers then no reparse takes place, not after 3 sec and not after 3000 sec ;-) 
>
>Is this ok too for you? Why?
>
>Thanks
>Klaus
>
>-----Ursprüngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...] 
>Gesendet: Donnerstag, 16. April 2009 17:47
>An: Berndl, Klaus
>Cc: Berndl, Klaus; lennart.borgman@...; cedet-devel@...
>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect buffers?-some more findings and a solution idea
>
>>>> <klaus.berndl@...> seems to think that:
>>Hi all,
>>
>>Well, i have just modified the clone-indirect-buffer - command in my Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i have applied Eric's patch which uses this new hook and then tested the scenario below - here are the results:
>>
>>1. Start Emacs with semantic activated and load a elisp file X
>>2. Go to a tag T (e.g. a defun)
>>3. Do M-: (semantic-current-tag) --> this will return the tag T with buffer object X
>>4. Call M-x clone-indirect-buffer RET --> this will popup a new indirect buffer X<2>
>>5. Go to the same tag T as in step 2
>>6. Do M-: (semantic-current-tag) --> this will now return the tag T with correct buffer X<2> and not - as before the patch - buffer object X --> fine!
>>
>>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add a new argument iii to the defun, if T is a defun)
>>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag T with the new informations (here iii as new argument, fine!
>>9. Switch to buffer X<2> (the indirect buffer) and do M-: (semantic-current-tag) --> you get the NOT(!) reparsed tag T with old informations (here without the new argument iii) but now with the correct buffer X<2>
>>
>>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another argument jjj) - do not save!
>>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with again new informations and still the correct buffer  X<2>
>>12. Switch back to buffer X (the base buffer) and move point to tag T
>>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T with old informations (ie. Without new argument jjj) but with correct buffer X
>>
>>Summary: With this patch the indirect-buffer has the right
>>buffer-information, which is good. Then the tag-lists seems to be
>>completely independent, so editing one buffer does not influence not
>>the other one - which is also good!
>>
>>What i'm wondering why running semantic-current-tag does not
>>automatically return the newly reparsed tag but the old one (i assume
>>from the semantic tag-cache) - see steps 9. and 13. above... Is this
>>a correct behavior? The charme of indirect buffers is that editing
>>takes effect in the base-buffer an all related indirect buffers: so
>>if i edit (en edition which triggers a reparse!) a tag e.g. the
>>base-buffer then the changes are also in the indirect-buffer so i
>>would expect that when switching to the indirect-buffer (as in step
>>9) then semantic should recognize that also this buffer has been
>>changed and therefore automatically reparse when i call
>>semantic-curre3nt-tag (as is done in step 8 above)...
>>
>>Why does this not work? Is this because the tag-cache of semantic is
>>file-centric? Or have i misunderstood something??
>
>The command `semantic-current-tag', like many very basic commands, do
>not request a reparse.  Reparses are requested by top-level commands
>before they call utility functions.  This saves time since a single
>top-level command might call hundreds of low-level commands.  Each one
>does not need to do the reparse duties.  In particular, utilities like
>SRecode which edits buffers wants to be in control of when a buffer is
>reparsed, in case it is only part-way through a code-creation function
>when it needs to call some utility.
>
>Use the senator command `senator-adebug-tag' which will do the reparse
>for you.  Or you can wait 3 seconds, and the idle timer will clean
>everything up for you.
>
>Does that help?
>
>Eric
>

It is unclear to me exactly what the rules might be for such a thing.
For semantic, the minimum would be as you suggest below for finding
all the indirect buffers in a fast way.  (I think you can use 'eq'
instead of 'equal' BTW.)  At a minimum, a super-fast way of knowing if
a particular buffer has at least one indirect buffer would be ok too.
It's the no-indirects anywhere problem that needs to be resolved.

I could certainly build a framework and do all the tracking myself,
but I'd need that hook fcn since the system I put together for the
patch will have a potential 3 second delay before it takes effect.

Propagating change-hook calling as a part of Emacs could be a bit
hazardous.  Many change hooks might be redisplaying interactive
things, and assume that they are called in the current buffer the
focus is in.  That could get a bit wacky.

Eric

>>> <klaus.berndl@...> seems to think that:
>Yep, i agree - this is nothing which should be added to a =
>after-change-function...
>
>The logic is easy, ECB has already somehting:
>
>(defun ecb-indirect-buffers-of-buffer (&optional buffer-or-name)
>  (let ((buffer (if (null buffer-or-name)
>                    (current-buffer)
>                  (if (and (bufferp buffer-or-name)
>                           (buffer-live-p buffer-or-name))
>                      buffer-or-name
>                    (if (stringp buffer-or-name)
>                        (get-buffer buffer-or-name))))))
>    (delq nil (mapcar (function
>                       (lambda (buf)
>                         (if (equal buffer (buffer-base-buffer buf))
>                             buf)))
>                      (buffer-list)))))
>
>but within ECB this is only used on demand and then run only once...
>
>Hmm, currently i'm at a loss with this... do not good enough the =
>internal mechanisms of semantic... maybe this is something to be ask the =
>Emacs-gurus - in general Emacs must already have a linkage between all =
>these related buffers because if you kill the base-buffer then all =
>indirect-buffers of it are killed automatically too...
>
>IMHO this propagation of hooks-running should be done internally be =
>Emacs...what do you think? Should we file a problem-report to the =
>emacs-devel-group?
>
>Ciao,
>Klaus
>
>-----Urspr=FCngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Do 16.04.2009 19:49
>An: Berndl, Klaus
>Cc: cedet-devel@...
>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with =
>indirectbuffers?-some more findings and a solution idea
>=20
>Ah, I think I understand better.
>
>It appears that the hooks I use to track edits don't work in linked
>buffers.  If you enable global-semantic-highlight-edits-mode, you will
>see that it finds things you edit, but the mirror edits in the other
>linked buffers do not get their change hooks run, and thus you don't
>see the highlight.
>
>I suppose I could look for all buffers that are linked together and
>propagate the change.  That seems kind of unpleasant as I can find no
>function to get that info.  I don't think an after-change-function
>should be looping over every buffer looking for indirect buffers
>associated with it.  That sounds painfully slow.
>
>Eric
>
>>>> <klaus.berndl@...> seems to think that:
>>Hmm, i know all this you explained to me - i.e. i know that =
>semantic-current-tag does not trigger a parse-run - but nevertheless the =
>indirect changed indirectbuffer (means changes has been done via the =
>base-buffer) is not parsed - the idle-triggered reparse takes not place =
>- this is what i'm wondering, why not?
>>
>>To be clear:
>>If i change a tag in a base-buffer, than here the buffer is reparsed =
>after 3 seconds and semantic-current-tag returns the modified tag.
>>Such a change influences all indirect-buffers of the base buffer - but =
>when i switch to one of these indirect buffers then no reparse takes =
>place, not after 3 sec and not after 3000 sec ;-)=20
>>
>>Is this ok too for you? Why?
>>
>>Thanks
>>Klaus
>>
>>-----Urspr=FCngliche Nachricht-----
>>Von: Eric M. Ludlam [mailto:eric@...
>>Gesendet: Donnerstag, 16. April 2009 17:47
>>An: Berndl, Klaus
>>Cc: Berndl, Klaus; lennart.borgman@...; cedet-devel@...
>>Betreff: Re[2]: [CEDET-devel] Is Semantic able to work with indirect =
>buffers?-some more findings and a solution idea
>>
>>>>> <klaus.berndl@...> seems to think that:
>>>Hi all,
>>>
>>>Well, i have just modified the clone-indirect-buffer - command in my =
>Emacs 22.3 copy so it uses now also the new hook of Emacs 23... Then i =
>have applied Eric's patch which uses this new hook and then tested the =
>scenario below - here are the results:
>>>
>>>1. Start Emacs with semantic activated and load a elisp file X
>>>2. Go to a tag T (e.g. a defun)
>>>3. Do M-: (semantic-current-tag) --> this will return the tag T with =
>buffer object X
>>>4. Call M-x clone-indirect-buffer RET --> this will popup a new =
>indirect buffer X<2>
>>>5. Go to the same tag T as in step 2
>>>6. Do M-: (semantic-current-tag) --> this will now return the tag T =
>with correct buffer X<2> and not - as before the patch - buffer object X =
>--> fine!
>>>
>>>7. Switch back to buffer X (the base-buffer) and edit tag T (e.g. add =
>a new argument iii to the defun, if T is a defun)
>>>8. Do M-: (semantic-current-tag) --> semantic returns the reparsed tag =
>T with the new informations (here iii as new argument, fine!
>>>9. Switch to buffer X<2> (the indirect buffer) and do M-: =
>(semantic-current-tag) --> you get the NOT(!) reparsed tag T with old =
>informations (here without the new argument iii) but now with the =
>correct buffer X<2>
>>>
>>>10. Now edit tag T in the indirect-buffer X<2> (e.g. add another =
>argument jjj) - do not save!
>>>11. do M-: (semantic-current-tag) --> you get the reparsed tag T with =
>again new informations and still the correct buffer  X<2>
>>>12. Switch back to buffer X (the base buffer) and move point to tag T
>>>13: do M-: (semantic-current-tag) --> you get the not reparsed tag T =
>with old informations (ie. Without new argument jjj) but with correct =
>buffer X
>>>
>>>Summary: With this patch the indirect-buffer has the right
>>>buffer-information, which is good. Then the tag-lists seems to be
>>>completely independent, so editing one buffer does not influence not
>>>the other one - which is also good!
>>>
>>>What i'm wondering why running semantic-current-tag does not
>>>automatically return the newly reparsed tag but the old one (i assume
>>>from the semantic tag-cache) - see steps 9. and 13. above... Is this
>>>a correct behavior? The charme of indirect buffers is that editing
>>>takes effect in the base-buffer an all related indirect buffers: so
>>>if i edit (en edition which triggers a reparse!) a tag e.g. the
>>>base-buffer then the changes are also in the indirect-buffer so i
>>>would expect that when switching to the indirect-buffer (as in step
>>>9) then semantic should recognize that also this buffer has been
>>>changed and therefore automatically reparse when i call
>>>semantic-curre3nt-tag (as is done in step 8 above)...
>>>
>>>Why does this not work? Is this because the tag-cache of semantic is
>>>file-centric? Or have i misunderstood something??
>>
>>The command `semantic-current-tag', like many very basic commands, do
>>not request a reparse.  Reparses are requested by top-level commands
>>before they call utility functions.  This saves time since a single
>>top-level command might call hundreds of low-level commands.  Each one
>>does not need to do the reparse duties.  In particular, utilities like
>>SRecode which edits buffers wants to be in control of when a buffer is
>>reparsed, in case it is only part-way through a code-creation function
>>when it needs to call some utility.
>>
>>Use the senator command `senator-adebug-tag' which will do the reparse
>>for you.  Or you can wait 3 seconds, and the idle timer will clean
>>everything up for you.
>>
>>Does that help?
>>
>>Eric
>>
>
>

On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
> Propagating change-hook calling as a part of Emacs could be a bit
> hazardous.  Many change hooks might be redisplaying interactive
> things, and assume that they are called in the current buffer the
> focus is in.  That could get a bit wacky.

Aren't the change hooks run in the indirect buffers too?

>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>> Propagating change-hook calling as a part of Emacs could be a bit
>> hazardous.  Many change hooks might be redisplaying interactive
>> things, and assume that they are called in the current buffer the
>> focus is in.  That could get a bit wacky.
>
>Aren't the change hooks run in the indirect buffers too?

Yes, but only when the indirect buffer is the current buffer.  Or so
it seems the way I'm using it.  An edit in one buffer does not trigger
my hooks in the other buffers to run.

I've only been able to run some simple experiments, so I don't know
in any great detail hat is going on.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi guys,

first a definition: let us name all buffers having an indirect-buffer-relationship among each other as a 'indirect buffer set' - this includes exactly one file-based base-buffer and an arbitrary number of indirect-buffers to this base-buffer...

after fixing a very small bug in ECB i found that it could be sufficient to detect:
a) has the current active buffer switched by the user (e.g. by switching window, buffer etc...), i.e. is now another buffer current compared to the last run of this check
b) is the buffer switch within a 'indirect-buffer-set (hmm, have not thinked in depth about this...maybe this check is not necessary or even forbidden?!
c) has been one of the buffers of the indirect-buffer-set changed / reparsed etc...

If a, b and c are all true then clear the toplevel cache of semantic and fetch the tags ==> this will return the right tag-set containing all changes previously made in another buffer of the indirect-buffer-set.

Encapsulate this in an idle-function which runs e.e. each second and checks a - c (s.a.) - at least a is very fast checkable (ECB does this already for its own sake) - so when editing in a buffer a) always fails and therefore no checks for b and c are necessary ==> no performance lack...

E.g. see `ecb-basic-buffer-sync' - search for "(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in ecb-file-browser.el (CVS-version) which already checks condition a.
Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i sent to you).
Condition c: Hmm, do not know exactly what is here necessary - maybe it is already enough to check if that buffer has changed which was previous before switching to the current one [a) compares already these two]?! Eric. Lennart, you are the semantic guys, i'm sure you know a solution for c) ;-)

Summary: With such a mechanism no realtime-propagation is needed during editing a buffer etc.. the only thing a user wants is, that when he edits a buffer of a indirect-buffer-set (see definition at beginning) and he later switch to another buffer of this set then this other buffer should be automatically be reparsed to reflect (e.g. this means in ECB: display) the correct tag-set (including the changes made in the other buffer of the indirect-buffer-set)... For a user it's equal if the tag-info-changes in one buffer of an indirect-buffer-set are immediately propagated to all other buffers of such a buffer-set, he only wants to get the right tag-set when he *activate* another buffer of the buffer-set!

Well, now a short question: Was my description understandable for you? Sometimes it's not easy for me being as precise and clear as necessary when writing in english ;-)

In general I'm now quite optimistic that there can be found a solution for the problem without performance-issues.... and without two much effort to implement ;-)

Thoughts?
Klaus


-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...]
Gesendet: Fr 17.04.2009 05:41
An: Lennart Borgman
Cc: Berndl, Klaus; cedet-devel@...
Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
 
>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>> Propagating change-hook calling as a part of Emacs could be a bit
>> hazardous.  Many change hooks might be redisplaying interactive
>> things, and assume that they are called in the current buffer the
>> focus is in.  That could get a bit wacky.
>
>Aren't the change hooks run in the indirect buffers too?

Yes, but only when the indirect buffer is the current buffer.  Or so
it seems the way I'm using it.  An edit in one buffer does not trigger
my hooks in the other buffers to run.

I've only been able to run some simple experiments, so I don't know
in any great detail hat is going on.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

On Fri, Apr 17, 2009 at 5:41 AM, Eric M. Ludlam <eric@...> wrote:
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>>> Propagating change-hook calling as a part of Emacs could be a bit
>>> hazardous.  Many change hooks might be redisplaying interactive
>>> things, and assume that they are called in the current buffer the
>>> focus is in.  That could get a bit wacky.
>>
>>Aren't the change hooks run in the indirect buffers too?
>
> Yes, but only when the indirect buffer is the current buffer.  Or so
> it seems the way I'm using it.  An edit in one buffer does not trigger
> my hooks in the other buffers to run.

Hm, that is a bit problematic and perhaps a bug. Are we taking about
after-change-hook etc?

On Fri, Apr 17, 2009 at 10:35 AM, Lennart Borgman
<lennart.borgman@...> wrote:
> On Fri, Apr 17, 2009 at 5:41 AM, Eric M. Ludlam <eric@...> wrote:
>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>>>> Propagating change-hook calling as a part of Emacs could be a bit
>>>> hazardous.  Many change hooks might be redisplaying interactive
>>>> things, and assume that they are called in the current buffer the
>>>> focus is in.  That could get a bit wacky.
>>>
>>>Aren't the change hooks run in the indirect buffers too?
>>
>> Yes, but only when the indirect buffer is the current buffer.  Or so
>> it seems the way I'm using it.  An edit in one buffer does not trigger
>> my hooks in the other buffers to run.
>
> Hm, that is a bit problematic and perhaps a bug. Are we taking about
> after-change-hook etc?

Eh, after-change-functions is the hook name.

See my other posting - i'm not sure if we are reliant on this hook-stuff to make semantic useable with indirect buffers...
KLaus 

-----Ursprüngliche Nachricht-----
Von: Lennart Borgman [mailto:lennart.borgman@...] 
Gesendet: Freitag, 17. April 2009 11:31
An: Eric M. Ludlam
Cc: Berndl, Klaus; cedet-devel@...
Betreff: Re: Re[1]: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea

On Fri, Apr 17, 2009 at 10:35 AM, Lennart Borgman <lennart.borgman@...> wrote:
> On Fri, Apr 17, 2009 at 5:41 AM, Eric M. Ludlam <eric@...> wrote:
>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>>>> Propagating change-hook calling as a part of Emacs could be a bit 
>>>> hazardous.  Many change hooks might be redisplaying interactive 
>>>> things, and assume that they are called in the current buffer the 
>>>> focus is in.  That could get a bit wacky.
>>>
>>>Aren't the change hooks run in the indirect buffers too?
>>
>> Yes, but only when the indirect buffer is the current buffer.  Or so 
>> it seems the way I'm using it.  An edit in one buffer does not 
>> trigger my hooks in the other buffers to run.
>
> Hm, that is a bit problematic and perhaps a bug. Are we taking about 
> after-change-hook etc?

Eh, after-change-functions is the hook name.

>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>On Fri, Apr 17, 2009 at 10:35 AM, Lennart Borgman
><lennart.borgman@...> wrote:
>> On Fri, Apr 17, 2009 at 5:41 AM, Eric M. Ludlam <eric@...> wrote:
>>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam <eric@...> wrote:
>>>>> Propagating change-hook calling as a part of Emacs could be a bit
>>>>> hazardous.  Many change hooks might be redisplaying interactive
>>>>> things, and assume that they are called in the current buffer the
>>>>> focus is in.  That could get a bit wacky.
>>>>
>>>>Aren't the change hooks run in the indirect buffers too?
>>>
>>> Yes, but only when the indirect buffer is the current buffer.  Or so
>>> it seems the way I'm using it.  An edit in one buffer does not trigger
>>> my hooks in the other buffers to run.
>>
>> Hm, that is a bit problematic and perhaps a bug. Are we taking about
>> after-change-hook etc?
>
>Eh, after-change-functions is the hook name.

Yes, I use after-change-functions.  It tracks the individual edits.
In idle time, the individual edits are merged together against tags so
I know what tags change.  I can then reparse only the minimal text
that makes up any possible changes in the buffer.

If you edit the base buffer, these functions don't get run in the
indirect buffer, but if you edit the indirect buffer, they do get run,
but not in the base buffer.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

CEDET/Semantic will track tiny changes in a buffer based on the
after-change-functions.  Those changes are just noted with overlays.
Once Semantic goes to update the tags in the buffer, it takes these
overlays, and merges them together to find out which tags changed.  It
will then reparse those text units, and splices the results into the
original list, attempting to keep as much of the old structure as
possible.

As the indirect buffer might be in a different mode, and have a
completely different parser, all changes in it must be tracked as
completely separate and reparsed completely separately.

So long as Emacs doesn't propagate the calls to the change function,
we'd need to do that propagation of change ourselves.  If, as you
suggest, you can quickly get the list of linked buffers, this should
be ok to do in the change hook.  I don't know if propagating the
changes later will help in this case.  Just the notification is not
enough since I need all the data of location as well.

Eric


>>> <klaus.berndl@...> seems to think that:
>Hi guys,
>
>first a definition: let us name all buffers having an =
>indirect-buffer-relationship among each other as a 'indirect buffer set' =
>- this includes exactly one file-based base-buffer and an arbitrary =
>number of indirect-buffers to this base-buffer...
>
>after fixing a very small bug in ECB i found that it could be sufficient =
>to detect:
>a) has the current active buffer switched by the user (e.g. by switching =
>window, buffer etc...), i.e. is now another buffer current compared to =
>the last run of this check
>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not =
>thinked in depth about this...maybe this check is not necessary or even =
>forbidden?!
>c) has been one of the buffers of the indirect-buffer-set changed / =
>reparsed etc...
>
>If a, b and c are all true then clear the toplevel cache of semantic and =
>fetch the tags =3D=3D> this will return the right tag-set containing all =
>changes previously made in another buffer of the indirect-buffer-set.
>
>Encapsulate this in an idle-function which runs e.e. each second and =
>checks a - c (s.a.) - at least a is very fast checkable (ECB does this =
>already for its own sake) - so when editing in a buffer a) always fails =
>and therefore no checks for b and c are necessary =3D=3D> no performance =
>lack...
>
>E.g. see `ecb-basic-buffer-sync' - search for =
>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in =
>ecb-file-browser.el (CVS-version) which already checks condition a.
>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i =
>sent to you).
>Condition c: Hmm, do not know exactly what is here necessary - maybe it =
>is already enough to check if that buffer has changed which was previous =
>before switching to the current one [a) compares already these two]?! =
>Eric. Lennart, you are the semantic guys, i'm sure you know a solution =
>for c) ;-)
>
>Summary: With such a mechanism no realtime-propagation is needed during =
>editing a buffer etc.. the only thing a user wants is, that when he =
>edits a buffer of a indirect-buffer-set (see definition at beginning) =
>and he later switch to another buffer of this set then this other buffer =
>should be automatically be reparsed to reflect (e.g. this means in ECB: =
>display) the correct tag-set (including the changes made in the other =
>buffer of the indirect-buffer-set)... For a user it's equal if the =
>tag-info-changes in one buffer of an indirect-buffer-set are immediately =
>propagated to all other buffers of such a buffer-set, he only wants to =
>get the right tag-set when he *activate* another buffer of the =
>buffer-set!
>
>Well, now a short question: Was my description understandable for you? =
>Sometimes it's not easy for me being as precise and clear as necessary =
>when writing in english ;-)
>
>In general I'm now quite optimistic that there can be found a solution =
>for the problem without performance-issues.... and without two much =
>effort to implement ;-)
>
>Thoughts?
>Klaus
>
>
>-----Urspr=FCngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 17.04.2009 05:41
>An: Lennart Borgman
>Cc: Berndl, Klaus; cedet-devel@...
>Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with =
>indirectbuffers?-some more findings and a solution idea
>=20
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =
><eric@...> wrote:
>>> Propagating change-hook calling as a part of Emacs could be a bit
>>> hazardous. =A0Many change hooks might be redisplaying interactive
>>> things, and assume that they are called in the current buffer the
>>> focus is in. =A0That could get a bit wacky.
>>
>>Aren't the change hooks run in the indirect buffers too?
>
>Yes, but only when the indirect buffer is the current buffer.  Or so
>it seems the way I'm using it.  An edit in one buffer does not trigger
>my hooks in the other buffers to run.
>
>I've only been able to run some simple experiments, so I don't know
>in any great detail hat is going on.
>
>Eric
>
>--=20
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: =
>http://cedet.sourceforge.net
>
>

Yes, of course - the "full"-featured solution should do what you describe...

BUT my suggestion was another one: at least we should ensure that an "indirectly" changed buffer (ie. changed via editing another buffer in the indirect-buffer-set) will be reparsed when this buffer becomes current for the user(!). IMHO for a first solution it would be sufficient to completely clear the tag-cache, so afterwards the buffer will be automatically fully reparsed ad all tags are uptodate... This can of course not use your incremental parsing mechanism you described. But better some full parse-runs as no parsing at all though it would be necessary...

Maybe not the gold-medal, but sometimes bronze medal is also not bad - aftre that we can try to reach the gold-medal...

Thoughts?
Klaus

-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...] 
Gesendet: Freitag, 17. April 2009 14:11
An: Berndl, Klaus
Cc: lennart.borgman@...; cedet-devel@...
Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea

CEDET/Semantic will track tiny changes in a buffer based on the after-change-functions.  Those changes are just noted with overlays.
Once Semantic goes to update the tags in the buffer, it takes these overlays, and merges them together to find out which tags changed.  It will then reparse those text units, and splices the results into the original list, attempting to keep as much of the old structure as possible.

As the indirect buffer might be in a different mode, and have a completely different parser, all changes in it must be tracked as completely separate and reparsed completely separately.

So long as Emacs doesn't propagate the calls to the change function, we'd need to do that propagation of change ourselves.  If, as you suggest, you can quickly get the list of linked buffers, this should be ok to do in the change hook.  I don't know if propagating the changes later will help in this case.  Just the notification is not enough since I need all the data of location as well.

Eric


>>> <klaus.berndl@...> seems to think that:
>Hi guys,
>
>first a definition: let us name all buffers having an = 
>indirect-buffer-relationship among each other as a 'indirect buffer 
>set' =
>- this includes exactly one file-based base-buffer and an arbitrary = 
>number of indirect-buffers to this base-buffer...
>
>after fixing a very small bug in ECB i found that it could be 
>sufficient = to detect:
>a) has the current active buffer switched by the user (e.g. by 
>switching = window, buffer etc...), i.e. is now another buffer current 
>compared to = the last run of this check
>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not = 
>thinked in depth about this...maybe this check is not necessary or even 
>= forbidden?!
>c) has been one of the buffers of the indirect-buffer-set changed / = 
>reparsed etc...
>
>If a, b and c are all true then clear the toplevel cache of semantic 
>and = fetch the tags =3D=3D> this will return the right tag-set 
>containing all = changes previously made in another buffer of the indirect-buffer-set.
>
>Encapsulate this in an idle-function which runs e.e. each second and = 
>checks a - c (s.a.) - at least a is very fast checkable (ECB does this 
>= already for its own sake) - so when editing in a buffer a) always 
>fails = and therefore no checks for b and c are necessary =3D=3D> no 
>performance = lack...
>
>E.g. see `ecb-basic-buffer-sync' - search for = 
>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in = 
>ecb-file-browser.el (CVS-version) which already checks condition a.
>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i 
>= sent to you).
>Condition c: Hmm, do not know exactly what is here necessary - maybe it 
>= is already enough to check if that buffer has changed which was 
>previous = before switching to the current one [a) compares already 
>these two]?! = Eric. Lennart, you are the semantic guys, i'm sure you 
>know a solution = for c) ;-)
>
>Summary: With such a mechanism no realtime-propagation is needed during 
>= editing a buffer etc.. the only thing a user wants is, that when he = 
>edits a buffer of a indirect-buffer-set (see definition at beginning) = 
>and he later switch to another buffer of this set then this other 
>buffer = should be automatically be reparsed to reflect (e.g. this 
>means in ECB: =
>display) the correct tag-set (including the changes made in the other = 
>buffer of the indirect-buffer-set)... For a user it's equal if the = 
>tag-info-changes in one buffer of an indirect-buffer-set are 
>immediately = propagated to all other buffers of such a buffer-set, he 
>only wants to = get the right tag-set when he *activate* another buffer 
>of the = buffer-set!
>
>Well, now a short question: Was my description understandable for you? 
>= Sometimes it's not easy for me being as precise and clear as 
>necessary = when writing in english ;-)
>
>In general I'm now quite optimistic that there can be found a solution 
>= for the problem without performance-issues.... and without two much = 
>effort to implement ;-)
>
>Thoughts?
>Klaus
>
>
>-----Urspr=FCngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 17.04.2009 05:41
>An: Lennart Borgman
>Cc: Berndl, Klaus; cedet-devel@...
>Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with = 
>indirectbuffers?-some more findings and a solution idea =20
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =
><eric@...> wrote:
>>> Propagating change-hook calling as a part of Emacs could be a bit 
>>> hazardous. =A0Many change hooks might be redisplaying interactive 
>>> things, and assume that they are called in the current buffer the 
>>> focus is in. =A0That could get a bit wacky.
>>
>>Aren't the change hooks run in the indirect buffers too?
>
>Yes, but only when the indirect buffer is the current buffer.  Or so it 
>seems the way I'm using it.  An edit in one buffer does not trigger my 
>hooks in the other buffers to run.
>
>I've only been able to run some simple experiments, so I don't know in 
>any great detail hat is going on.
>
>Eric
>
>--=20
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: =
>http://cedet.sourceforge.net
>
>

Well, two points:

1) Now i'm convinced that we should use an advice if there is no hook which runs with BOTH(!) of clone-indirect-buffer and make-indirect-buffer (alos with XEmacs which have only the later one):

I have written a small test-avice for make-indirect-buffer which only contains the following code:

(save-excursion
    (set-buffer ad-return-value)
    (message "return-value: %s, Cur-buffer: %s, base-buffer: %s"
             ad-return-value (buffer-name) (buffer-base-buffer)))

This works well and we see how it works...just replace the message-call with the cache clearing and we are fine... this after advice is save and can not fail so we can do it ... if we are paranoid we could encapsulate in a call to condition-case nil...... ;-)

2) I think i have found a way how to detect very fast the indirect-buffer-set of a buffer without looping each time over the whole buffer list: we do this via the advice above and within kill-buffer-hook! :-)

We write a small framework which makes a smart storage of the current indirect-buffer-list of each opened base-buffer, e.g. an alist with key is a base-buffer and value is the list of all related indirect-buffers to the base-buffer... This storage we administrate with the advice of make-indirect-buffer and with kill-buffer-hook so this storage is always up-to-date...

Then you can use in your after-change-function this indirect-buffer-storage to propagate... shouldbe fast because we can use `eq' and buffer-objects... if still to slow we could add a further alist which contains an entry for each(!) current opened file-buffer (regardless if a base- or an indirect one), and car is a buffer-object and cdr is the base-buffer for this buffer - so we have a two step storage...

Thoughts?

Ciao,
Klaus

P.S.
see the answer to my emacs-bug-report....
-----Ursprüngliche Nachricht-----
Von: Eric M. Ludlam [mailto:eric@...]
Gesendet: Fr 17.04.2009 14:11
An: Berndl, Klaus
Cc: lennart.borgman@...; cedet-devel@...
Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with indirectbuffers?-some more findings and a solution idea
 
CEDET/Semantic will track tiny changes in a buffer based on the
after-change-functions.  Those changes are just noted with overlays.
Once Semantic goes to update the tags in the buffer, it takes these
overlays, and merges them together to find out which tags changed.  It
will then reparse those text units, and splices the results into the
original list, attempting to keep as much of the old structure as
possible.

As the indirect buffer might be in a different mode, and have a
completely different parser, all changes in it must be tracked as
completely separate and reparsed completely separately.

So long as Emacs doesn't propagate the calls to the change function,
we'd need to do that propagation of change ourselves.  If, as you
suggest, you can quickly get the list of linked buffers, this should
be ok to do in the change hook.  I don't know if propagating the
changes later will help in this case.  Just the notification is not
enough since I need all the data of location as well.

Eric


>>> <klaus.berndl@...> seems to think that:
>Hi guys,
>
>first a definition: let us name all buffers having an =
>indirect-buffer-relationship among each other as a 'indirect buffer set' =
>- this includes exactly one file-based base-buffer and an arbitrary =
>number of indirect-buffers to this base-buffer...
>
>after fixing a very small bug in ECB i found that it could be sufficient =
>to detect:
>a) has the current active buffer switched by the user (e.g. by switching =
>window, buffer etc...), i.e. is now another buffer current compared to =
>the last run of this check
>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not =
>thinked in depth about this...maybe this check is not necessary or even =
>forbidden?!
>c) has been one of the buffers of the indirect-buffer-set changed / =
>reparsed etc...
>
>If a, b and c are all true then clear the toplevel cache of semantic and =
>fetch the tags =3D=3D> this will return the right tag-set containing all =
>changes previously made in another buffer of the indirect-buffer-set.
>
>Encapsulate this in an idle-function which runs e.e. each second and =
>checks a - c (s.a.) - at least a is very fast checkable (ECB does this =
>already for its own sake) - so when editing in a buffer a) always fails =
>and therefore no checks for b and c are necessary =3D=3D> no performance =
>lack...
>
>E.g. see `ecb-basic-buffer-sync' - search for =
>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in =
>ecb-file-browser.el (CVS-version) which already checks condition a.
>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i =
>sent to you).
>Condition c: Hmm, do not know exactly what is here necessary - maybe it =
>is already enough to check if that buffer has changed which was previous =
>before switching to the current one [a) compares already these two]?! =
>Eric. Lennart, you are the semantic guys, i'm sure you know a solution =
>for c) ;-)
>
>Summary: With such a mechanism no realtime-propagation is needed during =
>editing a buffer etc.. the only thing a user wants is, that when he =
>edits a buffer of a indirect-buffer-set (see definition at beginning) =
>and he later switch to another buffer of this set then this other buffer =
>should be automatically be reparsed to reflect (e.g. this means in ECB: =
>display) the correct tag-set (including the changes made in the other =
>buffer of the indirect-buffer-set)... For a user it's equal if the =
>tag-info-changes in one buffer of an indirect-buffer-set are immediately =
>propagated to all other buffers of such a buffer-set, he only wants to =
>get the right tag-set when he *activate* another buffer of the =
>buffer-set!
>
>Well, now a short question: Was my description understandable for you? =
>Sometimes it's not easy for me being as precise and clear as necessary =
>when writing in english ;-)
>
>In general I'm now quite optimistic that there can be found a solution =
>for the problem without performance-issues.... and without two much =
>effort to implement ;-)
>
>Thoughts?
>Klaus
>
>
>-----Urspr=FCngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 17.04.2009 05:41
>An: Lennart Borgman
>Cc: Berndl, Klaus; cedet-devel@...
>Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with =
>indirectbuffers?-some more findings and a solution idea
>=20
>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =
><eric@...> wrote:
>>> Propagating change-hook calling as a part of Emacs could be a bit
>>> hazardous. =A0Many change hooks might be redisplaying interactive
>>> things, and assume that they are called in the current buffer the
>>> focus is in. =A0That could get a bit wacky.
>>
>>Aren't the change hooks run in the indirect buffers too?
>
>Yes, but only when the indirect buffer is the current buffer.  Or so
>it seems the way I'm using it.  An edit in one buffer does not trigger
>my hooks in the other buffers to run.
>
>I've only been able to run some simple experiments, so I don't know
>in any great detail hat is going on.
>
>Eric
>
>--=20
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: =
>http://cedet.sourceforge.net
>
>

Hi Klaus,

  If you replace the message with something that calls the hook we'd
like to have, then we won't need to change any code in semantic once
the hook is generally available (if ever.)

  You're other idea is good too with indirect buffer tracking.  I will
attempt to explain the after-change-function issue as a reply to the
other email.

Eric


>>> <klaus.berndl@...> seems to think that:
>Well, two points:
>
>1) Now i'm convinced that we should use an advice if there is no hook =
>which runs with BOTH(!) of clone-indirect-buffer and =
>make-indirect-buffer (alos with XEmacs which have only the later one):
>
>I have written a small test-avice for make-indirect-buffer which only =
>contains the following code:
>
>(save-excursion
>    (set-buffer ad-return-value)
>    (message "return-value: %s, Cur-buffer: %s, base-buffer: %s"
>             ad-return-value (buffer-name) (buffer-base-buffer)))
>
>This works well and we see how it works...just replace the message-call =
>with the cache clearing and we are fine... this after advice is save and =
>can not fail so we can do it ... if we are paranoid we could encapsulate =
>in a call to condition-case nil...... ;-)
>
>2) I think i have found a way how to detect very fast the =
>indirect-buffer-set of a buffer without looping each time over the whole =
>buffer list: we do this via the advice above and within =
>kill-buffer-hook! :-)
>
>We write a small framework which makes a smart storage of the current =
>indirect-buffer-list of each opened base-buffer, e.g. an alist with key =
>is a base-buffer and value is the list of all related indirect-buffers =
>to the base-buffer... This storage we administrate with the advice of =
>make-indirect-buffer and with kill-buffer-hook so this storage is always =
>up-to-date...
>
>Then you can use in your after-change-function this =
>indirect-buffer-storage to propagate... shouldbe fast because we can use =
>`eq' and buffer-objects... if still to slow we could add a further alist =
>which contains an entry for each(!) current opened file-buffer =
>(regardless if a base- or an indirect one), and car is a buffer-object =
>and cdr is the base-buffer for this buffer - so we have a two step =
>storage...
>
>Thoughts?
>
>Ciao,
>Klaus
>
>P.S.
>see the answer to my emacs-bug-report....
>-----Urspr=FCngliche Nachricht-----
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 17.04.2009 14:11
>An: Berndl, Klaus
>Cc: lennart.borgman@...; cedet-devel@...
>Betreff: Re[1]: AW: [CEDET-devel] Is Semantic able to work with =
>indirectbuffers?-some more findings and a solution idea
>=20
>CEDET/Semantic will track tiny changes in a buffer based on the
>after-change-functions.  Those changes are just noted with overlays.
>Once Semantic goes to update the tags in the buffer, it takes these
>overlays, and merges them together to find out which tags changed.  It
>will then reparse those text units, and splices the results into the
>original list, attempting to keep as much of the old structure as
>possible.
>
>As the indirect buffer might be in a different mode, and have a
>completely different parser, all changes in it must be tracked as
>completely separate and reparsed completely separately.
>
>So long as Emacs doesn't propagate the calls to the change function,
>we'd need to do that propagation of change ourselves.  If, as you
>suggest, you can quickly get the list of linked buffers, this should
>be ok to do in the change hook.  I don't know if propagating the
>changes later will help in this case.  Just the notification is not
>enough since I need all the data of location as well.
>
>Eric
>
>
>>>> <klaus.berndl@...> seems to think that:
>>Hi guys,
>>
>>first a definition: let us name all buffers having an =3D
>>indirect-buffer-relationship among each other as a 'indirect buffer =
>set' =3D
>>- this includes exactly one file-based base-buffer and an arbitrary =3D
>>number of indirect-buffers to this base-buffer...
>>
>>after fixing a very small bug in ECB i found that it could be =
>sufficient =3D
>>to detect:
>>a) has the current active buffer switched by the user (e.g. by =
>switching =3D
>>window, buffer etc...), i.e. is now another buffer current compared to =
>=3D
>>the last run of this check
>>b) is the buffer switch within a 'indirect-buffer-set (hmm, have not =
>=3D
>>thinked in depth about this...maybe this check is not necessary or even =
>=3D
>>forbidden?!
>>c) has been one of the buffers of the indirect-buffer-set changed / =3D
>>reparsed etc...
>>
>>If a, b and c are all true then clear the toplevel cache of semantic =
>and =3D
>>fetch the tags =3D3D=3D3D> this will return the right tag-set =
>containing all =3D
>>changes previously made in another buffer of the indirect-buffer-set.
>>
>>Encapsulate this in an idle-function which runs e.e. each second and =
>=3D
>>checks a - c (s.a.) - at least a is very fast checkable (ECB does this =
>=3D
>>already for its own sake) - so when editing in a buffer a) always fails =
>=3D
>>and therefore no checks for b and c are necessary =3D3D=3D3D> no =
>performance =3D
>>lack...
>>
>>E.g. see `ecb-basic-buffer-sync' - search for =3D
>>"(defecb-autocontrol/sync-function ecb-basic-buffer-sync" in =3D
>>ecb-file-browser.el (CVS-version) which already checks condition a.
>>Condition b) is easy to implement (see ecb-indirect-buffers-of-buffer i =
>=3D
>>sent to you).
>>Condition c: Hmm, do not know exactly what is here necessary - maybe it =
>=3D
>>is already enough to check if that buffer has changed which was =
>previous =3D
>>before switching to the current one [a) compares already these two]?! =
>=3D
>>Eric. Lennart, you are the semantic guys, i'm sure you know a solution =
>=3D
>>for c) ;-)
>>
>>Summary: With such a mechanism no realtime-propagation is needed during =
>=3D
>>editing a buffer etc.. the only thing a user wants is, that when he =3D
>>edits a buffer of a indirect-buffer-set (see definition at beginning) =
>=3D
>>and he later switch to another buffer of this set then this other =
>buffer =3D
>>should be automatically be reparsed to reflect (e.g. this means in ECB: =
>=3D
>>display) the correct tag-set (including the changes made in the other =
>=3D
>>buffer of the indirect-buffer-set)... For a user it's equal if the =3D
>>tag-info-changes in one buffer of an indirect-buffer-set are =
>immediately =3D
>>propagated to all other buffers of such a buffer-set, he only wants to =
>=3D
>>get the right tag-set when he *activate* another buffer of the =3D
>>buffer-set!
>>
>>Well, now a short question: Was my description understandable for you? =
>=3D
>>Sometimes it's not easy for me being as precise and clear as necessary =
>=3D
>>when writing in english ;-)
>>
>>In general I'm now quite optimistic that there can be found a solution =
>=3D
>>for the problem without performance-issues.... and without two much =3D
>>effort to implement ;-)
>>
>>Thoughts?
>>Klaus
>>
>>
>>-----Urspr=3DFCngliche Nachricht-----
>>Von: Eric M. Ludlam [mailto:eric@...]
>>Gesendet: Fr 17.04.2009 05:41
>>An: Lennart Borgman
>>Cc: Berndl, Klaus; cedet-devel@...
>>Betreff: Re[1]: [CEDET-devel] Is Semantic able to work with =3D
>>indirectbuffers?-some more findings and a solution idea
>>=3D20
>>>>> Lennart Borgman <lennart.borgman@...> seems to think that:
>>>On Thu, Apr 16, 2009 at 11:36 PM, Eric M. Ludlam =3D
>><eric@...> wrote:
>>>> Propagating change-hook calling as a part of Emacs could be a bit
>>>> hazardous. =3DA0Many change hooks might be redisplaying interactive
>>>> things, and assume that they are called in the current buffer the
>>>> focus is in. =3DA0That could get a bit wacky.
>>>
>>>Aren't the change hooks run in the indirect buffers too?
>>
>>Yes, but only when the indirect buffer is the current buffer.  Or so
>>it seems the way I'm using it.  An edit in one buffer does not trigger
>>my hooks in the other buffers to run.
>>
>>I've only been able to run some simple experiments, so I don't know
>>in any great detail hat is going on.
>>
>>Eric
>>
>>--=3D20
>>          Eric Ludlam:                       eric@...
>>   Siege: http://www.siege-engine.com          Emacs: =3D
>>http://cedet.sourceforge.net
>>
>>
>
>
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net