CEDET

>>> "Dave Milter" <davemilter@...> seems to think that:
>The code is:
>-------------------------------------------------------------
  [ ... ]
>int main()
>{
>	Ops ops;
>	ops.copy = my_copy<Foo>;
>	Foo *a, b;
>	b.i = 10;
>	a = static_cast<Foo *>(ops.copy(&b));
>	printf("a->i %d\n", a->
>
>	return EXIT_SUCCESS;
>}
>-------------------------------------------------------------

Sometimes incomplete parenthesis matching can prevent Semantic from
knowing you are inside a function, and restrict the things it can
complete on.  In this case, adding a ) would help.

Because this is the last function in the file, Semantic tries to
assume you mean this to be all one thing, and will try to provide
the function main with the unterminated code body.

Anyway, for me completion worked, and I got an "i" as a completion
option.

If you do:

C-u M-x bovinate RET

it will force a full reparse.  If completion then works, then what you
have found is some sort of incremental parsing error which will be
challenging to find new repro steps for.

>For some reason cedet tell me that it Cannot find types for 'a'.
>CEDET Version:	1.0pre4


The command:

M-x semantic-analyze-current-context RET

will provide a nice output that sometimes indicates where it fell
over.

Eric

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

On 4/30/08, Eric M. Ludlam <eric@...> wrote:
> >>> "Dave Milter" <davemilter@...> seems to think that:
>  >The code is:
>  >-------------------------------------------------------------
>   [ ... ]
>
> >int main()
>  >{
>  >       Ops ops;
>  >       ops.copy = my_copy<Foo>;
>  >       Foo *a, b;
>  >       b.i = 10;
>  >       a = static_cast<Foo *>(ops.copy(&b));
>  >       printf("a->i %d\n", a->
>  >
>  >       return EXIT_SUCCESS;
>  >}
>  >-------------------------------------------------------------
>
>
> Sometimes incomplete parenthesis matching can prevent Semantic from
>  knowing you are inside a function, and restrict the things it can
>  complete on.  In this case, adding a ) would help.
>
>  Because this is the last function in the file, Semantic tries to
>  assume you mean this to be all one thing, and will try to provide
>  the function main with the unterminated code body.
>
>  Anyway, for me completion worked, and I got an "i" as a completion
>  option.
>
>  If you do:
>
>  C-u M-x bovinate RET
>
>  it will force a full reparse.  If completion then works, then what you
>  have found is some sort of incremental parsing error which will be
>  challenging to find new repro steps for.
>
>
>  >For some reason cedet tell me that it Cannot find types for 'a'.
>  >CEDET Version: 1.0pre4
>
>
>
> The command:
>
>  M-x semantic-analyze-current-context RET
>
>  will provide a nice output that sometimes indicates where it fell
>  over.
>


Yeah,  "bovinate" or ");" at the end of line helps,
but creating new file, open in new buffer, and things do not work again,
so it is reprodusible, by the way I use
semantic-ia-complete-symbol-menu to show possible completetions,

analyze-current-context show:
Context Type: #<semantic-analyze-context context>
Bounds: (488 . 488)
Prefix: "a"
        ""
Prefix Classes: 'type
--------

>>> "Dave Milter" <davemilter@...> seems to think that:
>On 4/30/08, Eric M. Ludlam <eric@...> wrote:
  [ ... ]
>> The command:
>>
>>  M-x semantic-analyze-current-context RET
>>
>>  will provide a nice output that sometimes indicates where it fell
>>  over.
>>
>
>
>Yeah,  "bovinate" or ");" at the end of line helps,
>but creating new file, open in new buffer, and things do not work again,
>so it is reprodusible, by the way I use
>semantic-ia-complete-symbol-menu to show possible completetions,
>
>analyze-current-context show:
>Context Type: #<semantic-analyze-context context>
>Bounds: (488 . 488)
>Prefix: "a"
>        ""
>Prefix Classes: 'type
>--------
>

I'm beginning to see the problem now.  When "typing" new code, the
incremental parser is used.  It will not parse anything with lexical
errors.  This is for the case where in the middle of some huge file,
in some function, you might type in:

   if(a.-!-

and if it allowed the broken lexical state, all data after that point
would be lost.

Your case is that you are typing fast enough, that the idle parser
doesn't have a chance to run when the lexical state is ok, and thus
allow the incremental parser to get the right answer.

Unfortunately, I think the first use-case trumps the second.  There
might be something clever to do, like binding ) and } to also do an
incremental parse to clean this up, but that feels kind of
heavy-weight.  Basically, a lexically clean parse is needed before
completion works.  Perhaps there is some sort of highlighting  that
would make this more observable so new users know what to do?

Any thoughts out there?

Eric

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

On 4/30/08, Eric M. Ludlam <eric@...> wrote:
> >>> "Dave Milter" <davemilter@...> seems to think that:
>  >On 4/30/08, Eric M. Ludlam <eric@...> wrote:
>
>   [ ... ]
>
> >> The command:
>  >>
>  >>  M-x semantic-analyze-current-context RET
>  >>
>  >>  will provide a nice output that sometimes indicates where it fell
>  >>  over.
>  >>
>  >
>  >
>  >Yeah,  "bovinate" or ");" at the end of line helps,
>  >but creating new file, open in new buffer, and things do not work again,
>  >so it is reprodusible, by the way I use
>  >semantic-ia-complete-symbol-menu to show possible completetions,
>  >
>  >analyze-current-context show:
>  >Context Type: #<semantic-analyze-context context>
>  >Bounds: (488 . 488)
>  >Prefix: "a"
>  >        ""
>  >Prefix Classes: 'type
>  >--------
>  >
>
>
> I'm beginning to see the problem now.  When "typing" new code, the
>  incremental parser is used.  It will not parse anything with lexical
>  errors.  This is for the case where in the middle of some huge file,
>  in some function, you might type in:
>
>    if(a.-!-
>
>  and if it allowed the broken lexical state, all data after that point
>  would be lost.
>
>  Your case is that you are typing fast enough, that the idle parser
>  doesn't have a chance to run when the lexical state is ok, and thus
>  allow the incremental parser to get the right answer.
>
>  Unfortunately, I think the first use-case trumps the second.  There
>  might be something clever to do, like binding ) and } to also do an
>  incremental parse to clean this up, but that feels kind of
>  heavy-weight.  Basically, a lexically clean parse is needed before
>  completion works.  Perhaps there is some sort of highlighting  that
>  would make this more observable so new users know what to do?
>
>  Any thoughts out there?
>
>

Hm, may be this is stupid idea,
but if run "bovinate" I get right list of possible completetions,
why not, if there are no completion,
run once "bovinate" and only then, if all bad, report about it?

>>> "Dave Milter" <davemilter@...> seems to think that:
>On 4/30/08, Eric M. Ludlam <eric@...> wrote:
>> >>> "Dave Milter" <davemilter@...> seems to think that:
>>  >On 4/30/08, Eric M. Ludlam <eric@...> wrote:
>>
>>   [ ... ]
>>
>> >> The command:
>>  >>
>>  >>  M-x semantic-analyze-current-context RET
>>  >>
>>  >>  will provide a nice output that sometimes indicates where it fell
>>  >>  over.
>>  >>
>>  >
>>  >
>>  >Yeah,  "bovinate" or ");" at the end of line helps,
>>  >but creating new file, open in new buffer, and things do not work again,
>>  >so it is reprodusible, by the way I use
>>  >semantic-ia-complete-symbol-menu to show possible completetions,
>>  >
>>  >analyze-current-context show:
>>  >Context Type: #<semantic-analyze-context context>
>>  >Bounds: (488 . 488)
>>  >Prefix: "a"
>>  >        ""
>>  >Prefix Classes: 'type
>>  >--------
>>  >
>>
>>
>> I'm beginning to see the problem now.  When "typing" new code, the
>>  incremental parser is used.  It will not parse anything with lexical
>>  errors.  This is for the case where in the middle of some huge file,
>>  in some function, you might type in:
>>
>>    if(a.-!-
>>
>>  and if it allowed the broken lexical state, all data after that point
>>  would be lost.
>>
>>  Your case is that you are typing fast enough, that the idle parser
>>  doesn't have a chance to run when the lexical state is ok, and thus
>>  allow the incremental parser to get the right answer.
>>
>>  Unfortunately, I think the first use-case trumps the second.  There
>>  might be something clever to do, like binding ) and } to also do an
>>  incremental parse to clean this up, but that feels kind of
>>  heavy-weight.  Basically, a lexically clean parse is needed before
>>  completion works.  Perhaps there is some sort of highlighting  that
>>  would make this more observable so new users know what to do?
>>
>>  Any thoughts out there?
>>
>>
>
>Hm, may be this is stupid idea,
>but if run "bovinate" I get right list of possible completetions,
>why not, if there are no completion,
>run once "bovinate" and only then, if all bad, report about it?
>

If you had the above syntax, and a full reparse occurred, it would
wipe out all parsed data after point.  In your case, there are no more
functions after point, so the solution would work, but be limited to
that case.

There might be a clever way to allow some restricted incremental
parsing to get the expected (though not correct) answer, but I'd be
hesitant since it'd be filling the tag structures with corrupted
data.  Though I guess that already happens w/ the full parse.

You could turn on `global-semantic-highlight-edits-mode' and get some
visual feedback about the parser state.  Then it'd be more obvious
when there was an issue.

I'll add this to my todo list to try and figure out.

Eric

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

On 5/3/08, Eric M. Ludlam <eric@...> wrote:
> >>> "Dave Milter" <davemilter@...> seems to think that:
>  >On 4/30/08, Eric M. Ludlam <eric@...> wrote:
>  >> >>> "Dave Milter" <davemilter@...> seems to think that:
>  >>  >On 4/30/08, Eric M. Ludlam <eric@...> wrote:
>  >>
>  >>   [ ... ]
>  >>
>  >> >> The command:
>  >>  >>
>  >>  >>  M-x semantic-analyze-current-context RET
>  >>  >>
>  >>  >>  will provide a nice output that sometimes indicates where it fell
>  >>  >>  over.
>  >>  >>
>  >>  >
>  >>  >
>  >>  >Yeah,  "bovinate" or ");" at the end of line helps,
>  >>  >but creating new file, open in new buffer, and things do not work again,
>  >>  >so it is reprodusible, by the way I use
>  >>  >semantic-ia-complete-symbol-menu to show possible completetions,
>  >>  >
>  >>  >analyze-current-context show:
>  >>  >Context Type: #<semantic-analyze-context context>
>  >>  >Bounds: (488 . 488)
>  >>  >Prefix: "a"
>  >>  >        ""
>  >>  >Prefix Classes: 'type
>  >>  >--------
>  >>  >
>  >>
>  >>
>  >> I'm beginning to see the problem now.  When "typing" new code, the
>  >>  incremental parser is used.  It will not parse anything with lexical
>  >>  errors.  This is for the case where in the middle of some huge file,
>  >>  in some function, you might type in:
>  >>
>  >>    if(a.-!-
>  >>
>  >>  and if it allowed the broken lexical state, all data after that point
>  >>  would be lost.
>  >>
>  >>  Your case is that you are typing fast enough, that the idle parser
>  >>  doesn't have a chance to run when the lexical state is ok, and thus
>  >>  allow the incremental parser to get the right answer.
>  >>
>  >>  Unfortunately, I think the first use-case trumps the second.  There
>  >>  might be something clever to do, like binding ) and } to also do an
>  >>  incremental parse to clean this up, but that feels kind of
>  >>  heavy-weight.  Basically, a lexically clean parse is needed before
>  >>  completion works.  Perhaps there is some sort of highlighting  that
>  >>  would make this more observable so new users know what to do?
>  >>
>  >>  Any thoughts out there?
>  >>
>  >>
>  >
>  >Hm, may be this is stupid idea,
>  >but if run "bovinate" I get right list of possible completetions,
>  >why not, if there are no completion,
>  >run once "bovinate" and only then, if all bad, report about it?
>  >
>
>
> If you had the above syntax, and a full reparse occurred, it would
>  wipe out all parsed data after point.  In your case, there are no more
>  functions after point, so the solution would work, but be limited to
>  that case.
>

Yes, but if I have something bellow point,
and I too fast go to this point, before semantic can do its work again,
it again call bovinate, if not found suitable completetion,
and again all will work again.