Home » Language IDEs » C / C++ IDE (CDT) » Code completion
| Code completion [message #19030] |
Tue, 19 February 2002 08:38  |
Eclipse User |
|
|
|
Originally posted by: johan.nosp.m.appeal.se
Is code completion available when editing C code in lpex? I have tried
typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
"Shift+Enter", but no luck.
I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
patched LPEX (which now seems to work OK after very superficial testing).
Cheers //Johan
|
|
|
| Re: Code completion [message #19232 is a reply to message #19030] |
Tue, 19 February 2002 10:22  |
| Eclipse User |
|
|
|
CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
main, switch, try, while. These are defined in
com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
/ editing them yet...
Note that Ctrl+R may not work for you if you installed the examples plugins
(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
accelerator).
Johan Walles wrote:
> Is code completion available when editing C code in lpex? I have tried
> typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
> "Shift+Enter", but no luck.
>
> I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
> patched LPEX (which now seems to work OK after very superficial testing).
>
> Cheers //Johan
|
|
|
| Re: Code completion [message #19271 is a reply to message #19232] |
Tue, 19 February 2002 10:43 |
| Eclipse User |
|
|
|
Originally posted by: johan.nosp.m.appeal.se
printf is not a keyword; it's a function implemented by libc (I think).
Its declaration is in stdio.h.
Does this mean that:
1. My example should have worked and I've found a bug?
2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
don't know how?
//Johan
adrian wrote:
> CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
>
> At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
> - don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
> main, switch, try, while. These are defined in
> com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
> / editing them yet...
>
> Note that Ctrl+R may not work for you if you installed the examples plugins
> (/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
> accelerator).
>
> Johan Walles wrote:
>
>
>>Is code completion available when editing C code in lpex? I have tried
>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
>>"Shift+Enter", but no luck.
>>
>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
>>patched LPEX (which now seems to work OK after very superficial testing).
>>
>> Cheers //Johan
>>
>
|
|
|
| Re: Code completion [message #19357 is a reply to message #19271] |
Tue, 19 February 2002 11:42 |
| Eclipse User |
|
|
|
Hi Johan,
You are correct that you need to tell the CDT how to parse stdio.h. The
way to do this is to set the "Parse Include Path", by "right-clicking"
on your project, and choosing Properties...
Note: I believe that in the current driver, just changing the include
path and re-parsing won't actually kick off another parse (since no
time-stamps of your project files have changed). You will probably have
to "Remove Parse Information" first, then re-parse (this is a bug).
There could be an argument made that /usr/include should always be in
the Parse Include Path, but the decision was made to let the choice fall
to the user since it is time and memory consuming to parse every
included file (and every file that they include). Another idea I've
been toying with is to "pre-package" some parse information based on the
most common include files so that it is always available to the parser,
but I haven't thought that through yet.
Hope that helps...
Jeff Turnham
Johan Walles wrote:
>
> printf is not a keyword; it's a function implemented by libc (I think).
> Its declaration is in stdio.h.
>
> Does this mean that:
> 1. My example should have worked and I've found a bug?
> 2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
> don't know how?
>
> //Johan
>
> adrian wrote:
>
> > CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
> >
> > At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
> > - don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
> > main, switch, try, while. These are defined in
> > com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
> > / editing them yet...
> >
> > Note that Ctrl+R may not work for you if you installed the examples plugins
> > (/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
> > accelerator).
> >
> > Johan Walles wrote:
> >
> >
> >>Is code completion available when editing C code in lpex? I have tried
> >>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
> >>"Shift+Enter", but no luck.
> >>
> >>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
> >>patched LPEX (which now seems to work OK after very superficial testing).
> >>
> >> Cheers //Johan
> >>
> >
|
|
|
| Re: Code completion [message #19403 is a reply to message #19357] |
Wed, 20 February 2002 02:58 |
| Eclipse User |
|
|
|
Originally posted by: johan.nosp.m.appeal.se
I have added /usr/include to the parse include path, removed parse
information and run a re-parse. That the parse was successful (for some
definition of "successful") is indicated by my main() function showing
up in the "Project Objects" pane.
Still, when I type "prin" followed by either ctrl-space or ctrl-r,
nothing happens. Any other suggestions?
//Johan
Jeff Turnham wrote:
> Hi Johan,
>
> You are correct that you need to tell the CDT how to parse stdio.h. The
> way to do this is to set the "Parse Include Path", by "right-clicking"
> on your project, and choosing Properties...
> Note: I believe that in the current driver, just changing the include
> path and re-parsing won't actually kick off another parse (since no
> time-stamps of your project files have changed). You will probably have
> to "Remove Parse Information" first, then re-parse (this is a bug).
>
> There could be an argument made that /usr/include should always be in
> the Parse Include Path, but the decision was made to let the choice fall
> to the user since it is time and memory consuming to parse every
> included file (and every file that they include). Another idea I've
> been toying with is to "pre-package" some parse information based on the
> most common include files so that it is always available to the parser,
> but I haven't thought that through yet.
>
> Hope that helps...
>
> Jeff Turnham
>
>
> Johan Walles wrote:
>
>>printf is not a keyword; it's a function implemented by libc (I think).
>> Its declaration is in stdio.h.
>>
>>Does this mean that:
>>1. My example should have worked and I've found a bug?
>>2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
>>don't know how?
>>
>> //Johan
>>
>>adrian wrote:
>>
>>
>
>
>
>>>CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
>>>
>>>At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
>>>- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
>>>main, switch, try, while. These are defined in
>>>com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
>>>/ editing them yet...
>>>
>>>Note that Ctrl+R may not work for you if you installed the examples plugins
>>>(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
>>>accelerator).
>>>
>>>Johan Walles wrote:
>>>
>>>
>>>
>>>>Is code completion available when editing C code in lpex? I have tried
>>>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
>>>>"Shift+Enter", but no luck.
>>>>
>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
>>>>patched LPEX (which now seems to work OK after very superficial testing).
>>>>
>>>> Cheers //Johan
>>>>
>>>>
|
|
|
| Re: Code completion [message #19495 is a reply to message #19403] |
Wed, 20 February 2002 09:38 |
| Eclipse User |
|
|
|
Hi Johan,
You have found a parser bug. I just opened a bug for it (10015).
What is happening has to do with certain macros following function
prototypes.
Let me show you how you can actually view what has been parsed.
After doing your parse with the include path set, goto the "Parsed
Files" view, and to the "Filter" drop-down at the top of the view. By
default the Filter is set to "Parsed Source" which is defined as the
files which have been parsed that exist within your Eclipse C\C++
Project. Change the Filter to "Included Source" and you should see the
files that have been parsed that were found on your Include Path. One
of these should be "stdio.h".
Select "stdio.h", and then goto the "Project Details" view. What you
probably see is 1 function, namely "remove(__const char *__filename)".
If you expand this function you will probably see another function, and
if you expand that another one, and so on. This is the parser not
properly handling the way these functions are declared. For example
the remove function prototype looks like this (at least in my version
anyway):
extern int remove (__const char *__filename) __THROW;
From my brief investigation, it appears that the definition of __THROW
(which is in malloc.h -> "#define __THROW throw()") is not being found,
so __THROW is being treated as a regular identifier and infact as part
of of the body of the remove function! Then the parser is looking for a
closing } and not finding one, so it thinks that everything else that
follows is part of the function body also.
This will definitely be fixed in the next driver.
So in the meantime, if you wanted just to verify that code-assist is
working you could try it with the remove() function instead of
printf(). So typing "re" and hitting <Ctrl>-<Space> should give you the
remove function prototype.
Thanks..
Jeff Turnham
Johan Walles wrote:
>
> I have added /usr/include to the parse include path, removed parse
> information and run a re-parse. That the parse was successful (for some
> definition of "successful") is indicated by my main() function showing
> up in the "Project Objects" pane.
>
> Still, when I type "prin" followed by either ctrl-space or ctrl-r,
> nothing happens. Any other suggestions?
>
> //Johan
>
> Jeff Turnham wrote:
>
> > Hi Johan,
> >
> > You are correct that you need to tell the CDT how to parse stdio.h. The
> > way to do this is to set the "Parse Include Path", by "right-clicking"
> > on your project, and choosing Properties...
> > Note: I believe that in the current driver, just changing the include
> > path and re-parsing won't actually kick off another parse (since no
> > time-stamps of your project files have changed). You will probably have
> > to "Remove Parse Information" first, then re-parse (this is a bug).
> >
> > There could be an argument made that /usr/include should always be in
> > the Parse Include Path, but the decision was made to let the choice fall
> > to the user since it is time and memory consuming to parse every
> > included file (and every file that they include). Another idea I've
> > been toying with is to "pre-package" some parse information based on the
> > most common include files so that it is always available to the parser,
> > but I haven't thought that through yet.
> >
> > Hope that helps...
> >
> > Jeff Turnham
> >
> >
> > Johan Walles wrote:
> >
> >>printf is not a keyword; it's a function implemented by libc (I think).
> >> Its declaration is in stdio.h.
> >>
> >>Does this mean that:
> >>1. My example should have worked and I've found a bug?
> >>2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
> >>don't know how?
> >>
> >> //Johan
> >>
> >>adrian wrote:
> >>
> >>
> >
> >
> >
> >>>CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
> >>>
> >>>At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
> >>>- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
> >>>main, switch, try, while. These are defined in
> >>>com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
> >>>/ editing them yet...
> >>>
> >>>Note that Ctrl+R may not work for you if you installed the examples plugins
> >>>(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
> >>>accelerator).
> >>>
> >>>Johan Walles wrote:
> >>>
> >>>
> >>>
> >>>>Is code completion available when editing C code in lpex? I have tried
> >>>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
> >>>>"Shift+Enter", but no luck.
> >>>>
> >>>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
> >>>>patched LPEX (which now seems to work OK after very superficial testing).
> >>>>
> >>>> Cheers //Johan
> >>>>
> >>>>
|
|
|
| Re: Code completion [message #19540 is a reply to message #19495] |
Wed, 20 February 2002 10:02 |
| Eclipse User |
|
|
|
Originally posted by: johan.nosp.m.appeal.se
I am able to reproduce the exact steps you describe, and can verify
that I am in fact hit by that very bug. Just like in your case, my
first function is remove().
However, I can't use code completion with remove() either. Typing
"re" then ctrl-space has no effect at all.
Any other ideas? Or should I bugzilla it?
Cheers //Johan
JT wrote:
> Hi Johan,
>
> You have found a parser bug. I just opened a bug for it (10015).
> What is happening has to do with certain macros following function
> prototypes.
> Let me show you how you can actually view what has been parsed.
>
> After doing your parse with the include path set, goto the "Parsed
> Files" view, and to the "Filter" drop-down at the top of the view. By
> default the Filter is set to "Parsed Source" which is defined as the
> files which have been parsed that exist within your Eclipse C\C++
> Project. Change the Filter to "Included Source" and you should see the
> files that have been parsed that were found on your Include Path. One
> of these should be "stdio.h".
>
> Select "stdio.h", and then goto the "Project Details" view. What you
> probably see is 1 function, namely "remove(__const char *__filename)".
> If you expand this function you will probably see another function, and
> if you expand that another one, and so on. This is the parser not
> properly handling the way these functions are declared. For example
> the remove function prototype looks like this (at least in my version
> anyway):
>
> extern int remove (__const char *__filename) __THROW;
>
> From my brief investigation, it appears that the definition of __THROW
> (which is in malloc.h -> "#define __THROW throw()") is not being found,
> so __THROW is being treated as a regular identifier and infact as part
> of of the body of the remove function! Then the parser is looking for a
> closing } and not finding one, so it thinks that everything else that
> follows is part of the function body also.
>
> This will definitely be fixed in the next driver.
>
> So in the meantime, if you wanted just to verify that code-assist is
> working you could try it with the remove() function instead of
> printf(). So typing "re" and hitting <Ctrl>-<Space> should give you the
> remove function prototype.
>
> Thanks..
>
> Jeff Turnham
>
>
>
>
> Johan Walles wrote:
>
>>I have added /usr/include to the parse include path, removed parse
>>information and run a re-parse. That the parse was successful (for some
>>definition of "successful") is indicated by my main() function showing
>>up in the "Project Objects" pane.
>>
>>Still, when I type "prin" followed by either ctrl-space or ctrl-r,
>>nothing happens. Any other suggestions?
>>
>> //Johan
>>
>>Jeff Turnham wrote:
>>
>>
>>>Hi Johan,
>>>
>>>You are correct that you need to tell the CDT how to parse stdio.h. The
>>>way to do this is to set the "Parse Include Path", by "right-clicking"
>>>on your project, and choosing Properties...
>>>Note: I believe that in the current driver, just changing the include
>>>path and re-parsing won't actually kick off another parse (since no
>>>time-stamps of your project files have changed). You will probably have
>>>to "Remove Parse Information" first, then re-parse (this is a bug).
>>>
>>>There could be an argument made that /usr/include should always be in
>>>the Parse Include Path, but the decision was made to let the choice fall
>>>to the user since it is time and memory consuming to parse every
>>>included file (and every file that they include). Another idea I've
>>>been toying with is to "pre-package" some parse information based on the
>>>most common include files so that it is always available to the parser,
>>>but I haven't thought that through yet.
>>>
>>>Hope that helps...
>>>
>>>Jeff Turnham
>>>
>>>
>>>Johan Walles wrote:
>>>
>>>
>>>>printf is not a keyword; it's a function implemented by libc (I think).
>>>> Its declaration is in stdio.h.
>>>>
>>>>Does this mean that:
>>>>1. My example should have worked and I've found a bug?
>>>>2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
>>>>don't know how?
>>>>
>>>> //Johan
>>>>
>>>>adrian wrote:
>>>>
>>>>
>>>>
>>>
>>>
>>>>>CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
>>>>>
>>>>>At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
>>>>>- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
>>>>>main, switch, try, while. These are defined in
>>>>>com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
>>>>>/ editing them yet...
>>>>>
>>>>>Note that Ctrl+R may not work for you if you installed the examples plugins
>>>>>(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
>>>>>accelerator).
>>>>>
>>>>>Johan Walles wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Is code completion available when editing C code in lpex? I have tried
>>>>>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
>>>>>>"Shift+Enter", but no luck.
>>>>>>
>>>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
>>>>>>patched LPEX (which now seems to work OK after very superficial testing).
>>>>>>
>>>>>> Cheers //Johan
>>>>>>
>>>>>>
>>>>>>
|
|
|
| Re: Code completion [message #19585 is a reply to message #19540] |
Wed, 20 February 2002 13:04 |
| Eclipse User |
|
|
|
Well the simplest testcase to determine if code-assist is working is do
the following:
(I have verified this works with R1 and R2 on my system):
1. Create a project with a single file (main.cpp) that looks like this:
//main.cpp
#include "stdio.h"
int main()
{
};
2. Set up the Parse Include Path to point to /usr/include.
3. Parse the Project, and verify that the main() function shows in the
Project Objects view
4. Double-Click on the function object to open it in the Lpex Editor.
5. Put the cursor inside the body of main() and type "re"
6. Type <Ctrl>-<Space>. You should get at least the "remove(..)"
function showing up
but it sounds like you aren't...if after these simple steps it still
doesn't work,
you can open a bug (and even paste these steps in it to save you
typing ;-)
7. Also you could try invoking Code Assist from the Edit Menu. If it
works from there,
then we know the problem is related to keyboard handling.
If you do open a bug, please be sure to include details about your
system, since I
can't seem to reproduce it.
Thanks....
Jeff Turnham
Johan Walles wrote:
>
> I am able to reproduce the exact steps you describe, and can verify
> that I am in fact hit by that very bug. Just like in your case, my
> first function is remove().
>
> However, I can't use code completion with remove() either. Typing
> "re" then ctrl-space has no effect at all.
>
> Any other ideas? Or should I bugzilla it?
>
> Cheers //Johan
>
> JT wrote:
>
> > Hi Johan,
> >
> > You have found a parser bug. I just opened a bug for it (10015).
> > What is happening has to do with certain macros following function
> > prototypes.
> > Let me show you how you can actually view what has been parsed.
> >
> > After doing your parse with the include path set, goto the "Parsed
> > Files" view, and to the "Filter" drop-down at the top of the view. By
> > default the Filter is set to "Parsed Source" which is defined as the
> > files which have been parsed that exist within your Eclipse C\C++
> > Project. Change the Filter to "Included Source" and you should see the
> > files that have been parsed that were found on your Include Path. One
> > of these should be "stdio.h".
> >
> > Select "stdio.h", and then goto the "Project Details" view. What you
> > probably see is 1 function, namely "remove(__const char *__filename)".
> > If you expand this function you will probably see another function, and
> > if you expand that another one, and so on. This is the parser not
> > properly handling the way these functions are declared. For example
> > the remove function prototype looks like this (at least in my version
> > anyway):
> >
> > extern int remove (__const char *__filename) __THROW;
> >
> > From my brief investigation, it appears that the definition of __THROW
> > (which is in malloc.h -> "#define __THROW throw()") is not being found,
> > so __THROW is being treated as a regular identifier and infact as part
> > of of the body of the remove function! Then the parser is looking for a
> > closing } and not finding one, so it thinks that everything else that
> > follows is part of the function body also.
> >
> > This will definitely be fixed in the next driver.
> >
> > So in the meantime, if you wanted just to verify that code-assist is
> > working you could try it with the remove() function instead of
> > printf(). So typing "re" and hitting <Ctrl>-<Space> should give you the
> > remove function prototype.
> >
> > Thanks..
> >
> > Jeff Turnham
> >
> >
> >
> >
> > Johan Walles wrote:
> >
> >>I have added /usr/include to the parse include path, removed parse
> >>information and run a re-parse. That the parse was successful (for some
> >>definition of "successful") is indicated by my main() function showing
> >>up in the "Project Objects" pane.
> >>
> >>Still, when I type "prin" followed by either ctrl-space or ctrl-r,
> >>nothing happens. Any other suggestions?
> >>
> >> //Johan
> >>
> >>Jeff Turnham wrote:
> >>
> >>
> >>>Hi Johan,
> >>>
> >>>You are correct that you need to tell the CDT how to parse stdio.h. The
> >>>way to do this is to set the "Parse Include Path", by "right-clicking"
> >>>on your project, and choosing Properties...
> >>>Note: I believe that in the current driver, just changing the include
> >>>path and re-parsing won't actually kick off another parse (since no
> >>>time-stamps of your project files have changed). You will probably have
> >>>to "Remove Parse Information" first, then re-parse (this is a bug).
> >>>
> >>>There could be an argument made that /usr/include should always be in
> >>>the Parse Include Path, but the decision was made to let the choice fall
> >>>to the user since it is time and memory consuming to parse every
> >>>included file (and every file that they include). Another idea I've
> >>>been toying with is to "pre-package" some parse information based on the
> >>>most common include files so that it is always available to the parser,
> >>>but I haven't thought that through yet.
> >>>
> >>>Hope that helps...
> >>>
> >>>Jeff Turnham
> >>>
> >>>
> >>>Johan Walles wrote:
> >>>
> >>>
> >>>>printf is not a keyword; it's a function implemented by libc (I think).
> >>>> Its declaration is in stdio.h.
> >>>>
> >>>>Does this mean that:
> >>>>1. My example should have worked and I've found a bug?
> >>>>2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
> >>>>don't know how?
> >>>>
> >>>> //Johan
> >>>>
> >>>>adrian wrote:
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>>>CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
> >>>>>
> >>>>>At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
> >>>>>- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
> >>>>>main, switch, try, while. These are defined in
> >>>>>com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
> >>>>>/ editing them yet...
> >>>>>
> >>>>>Note that Ctrl+R may not work for you if you installed the examples plugins
> >>>>>(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
> >>>>>accelerator).
> >>>>>
> >>>>>Johan Walles wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Is code completion available when editing C code in lpex? I have tried
> >>>>>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
> >>>>>>"Shift+Enter", but no luck.
> >>>>>>
> >>>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
> >>>>>>patched LPEX (which now seems to work OK after very superficial testing).
> >>>>>>
> >>>>>> Cheers //Johan
> >>>>>>
> >>>>>>
> >>>>>>
|
|
|
| Re: Code completion [message #19721 is a reply to message #19585] |
Thu, 21 February 2002 03:00 |
| Eclipse User |
|
|
|
Originally posted by: johan.nosp.m.appeal.se
>>>>>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208
As you suspect, ctrl-space doesn't work. Also, I cannot find Code
Assist on neither the Edit menu nor the context menu :-(. Where exactly
is it supposed to reside?
//Johan
Jeff Turnham wrote:
> Well the simplest testcase to determine if code-assist is working is do
> the following:
> (I have verified this works with R1 and R2 on my system):
>
> 1. Create a project with a single file (main.cpp) that looks like this:
> //main.cpp
> #include "stdio.h"
> int main()
> {
>
> };
> 2. Set up the Parse Include Path to point to /usr/include.
> 3. Parse the Project, and verify that the main() function shows in the
> Project Objects view
> 4. Double-Click on the function object to open it in the Lpex Editor.
> 5. Put the cursor inside the body of main() and type "re"
> 6. Type <Ctrl>-<Space>. You should get at least the "remove(..)"
> function showing up
> but it sounds like you aren't...if after these simple steps it still
> doesn't work,
> you can open a bug (and even paste these steps in it to save you
> typing ;-)
> 7. Also you could try invoking Code Assist from the Edit Menu. If it
> works from there,
> then we know the problem is related to keyboard handling.
>
> If you do open a bug, please be sure to include details about your
> system, since I
> can't seem to reproduce it.
>
> Thanks....
>
>
> Jeff Turnham
>
>
> Johan Walles wrote:
>
>>I am able to reproduce the exact steps you describe, and can verify
>>that I am in fact hit by that very bug. Just like in your case, my
>>first function is remove().
>>
>>However, I can't use code completion with remove() either. Typing
>>"re" then ctrl-space has no effect at all.
>>
>>Any other ideas? Or should I bugzilla it?
>>
>> Cheers //Johan
>>
>>JT wrote:
>>
>>
>>>Hi Johan,
>>>
>>>You have found a parser bug. I just opened a bug for it (10015).
>>>What is happening has to do with certain macros following function
>>>prototypes.
>>>Let me show you how you can actually view what has been parsed.
>>>
>>>After doing your parse with the include path set, goto the "Parsed
>>>Files" view, and to the "Filter" drop-down at the top of the view. By
>>>default the Filter is set to "Parsed Source" which is defined as the
>>>files which have been parsed that exist within your Eclipse C\C++
>>>Project. Change the Filter to "Included Source" and you should see the
>>>files that have been parsed that were found on your Include Path. One
>>>of these should be "stdio.h".
>>>
>>>Select "stdio.h", and then goto the "Project Details" view. What you
>>>probably see is 1 function, namely "remove(__const char *__filename)".
>>>If you expand this function you will probably see another function, and
>>>if you expand that another one, and so on. This is the parser not
>>>properly handling the way these functions are declared. For example
>>>the remove function prototype looks like this (at least in my version
>>>anyway):
>>>
>>>extern int remove (__const char *__filename) __THROW;
>>>
>>>From my brief investigation, it appears that the definition of __THROW
>>>(which is in malloc.h -> "#define __THROW throw()") is not being found,
>>>so __THROW is being treated as a regular identifier and infact as part
>>>of of the body of the remove function! Then the parser is looking for a
>>>closing } and not finding one, so it thinks that everything else that
>>>follows is part of the function body also.
>>>
>>>This will definitely be fixed in the next driver.
>>>
>>>So in the meantime, if you wanted just to verify that code-assist is
>>>working you could try it with the remove() function instead of
>>>printf(). So typing "re" and hitting <Ctrl>-<Space> should give you the
>>>remove function prototype.
>>>
>>>Thanks..
>>>
>>>Jeff Turnham
>>>
>>>
>>>
>>>
>>>Johan Walles wrote:
>>>
>>>
>>>>I have added /usr/include to the parse include path, removed parse
>>>>information and run a re-parse. That the parse was successful (for some
>>>>definition of "successful") is indicated by my main() function showing
>>>>up in the "Project Objects" pane.
>>>>
>>>>Still, when I type "prin" followed by either ctrl-space or ctrl-r,
>>>>nothing happens. Any other suggestions?
>>>>
>>>> //Johan
>>>>
>>>>Jeff Turnham wrote:
>>>>
>>>>
>>>>
>>>>>Hi Johan,
>>>>>
>>>>>You are correct that you need to tell the CDT how to parse stdio.h. The
>>>>>way to do this is to set the "Parse Include Path", by "right-clicking"
>>>>>on your project, and choosing Properties...
>>>>>Note: I believe that in the current driver, just changing the include
>>>>>path and re-parsing won't actually kick off another parse (since no
>>>>>time-stamps of your project files have changed). You will probably have
>>>>>to "Remove Parse Information" first, then re-parse (this is a bug).
>>>>>
>>>>>There could be an argument made that /usr/include should always be in
>>>>>the Parse Include Path, but the decision was made to let the choice fall
>>>>>to the user since it is time and memory consuming to parse every
>>>>>included file (and every file that they include). Another idea I've
>>>>>been toying with is to "pre-package" some parse information based on the
>>>>>most common include files so that it is always available to the parser,
>>>>>but I haven't thought that through yet.
>>>>>
>>>>>Hope that helps...
>>>>>
>>>>>Jeff Turnham
>>>>>
>>>>>
>>>>>Johan Walles wrote:
>>>>>
>>>>>
>>>>>
>>>>>>printf is not a keyword; it's a function implemented by libc (I think).
>>>>>>Its declaration is in stdio.h.
>>>>>>
>>>>>>Does this mean that:
>>>>>>1. My example should have worked and I've found a bug?
>>>>>>2. I need to somehow tell the CDT to parse /usr/include/stdio.h, but I
>>>>>>don't know how?
>>>>>>
>>>>>> //Johan
>>>>>>
>>>>>>adrian wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>>>CDT has code assist (Ctrl+Space), not sure if it works for base keywords.
>>>>>>>
>>>>>>>At the LPEX level, there currently is some keyword/template expansion (Ctrl+R
>>>>>>>- don't ask...) for the following keywords in C/C++: case, do, doc, for, if,
>>>>>>>main, switch, try, while. These are defined in
>>>>>>>com/ibm/lpex/cpp/Profile.properties. There is no preference page for adding
>>>>>>>/ editing them yet...
>>>>>>>
>>>>>>>Note that Ctrl+R may not work for you if you installed the examples plugins
>>>>>>>(/eclipse/plugins/org.eclipse.ui.examples.readmetool adds a Ctrl+R
>>>>>>>accelerator).
>>>>>>>
>>>>>>>Johan Walles wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Is code completion available when editing C code in lpex? I have tried
>>>>>>>>typing "prin" (as in "printf"), followed by "CTRL+Space", "CTRL+Enter",
>>>>>>>>"Shift+Enter", but no luck.
>>>>>>>>
>>>>>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208 and a
>>>>>>>>patched LPEX (which now seems to work OK after very superficial testing).
>>>>>>>>
>>>>>>>>Cheers //Johan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
|
|
|
| Re: Code completion [message #19765 is a reply to message #19721] |
Thu, 21 February 2002 08:38 |
| Eclipse User |
|
|
|
Hi Johan,
Well that's pretty strange if you aren't seeing what I'm seeing on the
Edit menu. I put a screen-cap of what I see here:
http://64.38.235.23/tools/cdt/downloads/temp/codeassist.gif
Can you tell me how yours is different?
Thanks...
Jeff Turnham
Johan Walles wrote:
>
> >>>>>>>>I am using the Linux-GTK build from 20020125 with CDT 20020208
>
> As you suspect, ctrl-space doesn't work. Also, I cannot find Code
> Assist on neither the Edit menu nor the context menu :-(. Where exactly
> is it supposed to reside?
>
> //Johan
>
|
|
|
Goto Forum:
Current Time: Fri Apr 25 19:41:03 EDT 2025
Powered by FUDForum. Page generated in 0.08825 seconds |
Home