Re: [CEDET-devel] Is Semantic able to work with indirect buffers? - some more findings and a solution idea

[Eric M. L. <er...@si...>]

>>> Lennart Borgman <len...@gm...> seems to think that:
>On Thu, Apr 16, 2009 at 10:29 AM,  <kla...@ca...> 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:                       er...@si...
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net