User forums > Help

Is it possible to see a function's comments in autocomplete?

(1/2) > >>

MachinTrucChose:
I love the autocomplete feature and use it frequently, but is there no way to be able to see a function's comments (preferably both the ones in the header and the implementation file)?

It's time-consuming (and annoying) to rightclick the function name, click Go To Declaration/Implementation, read the function's documentation, then navigate back to where I was about to use it.

ollydbg:
Good question:
Currently, this is not implemented in the CodeCompletion plugin. So, we us the way your mentioned.

--- Quote from: MachinTrucChose on November 18, 2009, 04:59:01 am --- rightclick the function name, click Go To Declaration/Implementation, read the function's documentation, then navigate back to where I was about to use it.

--- End quote ---

I think there are two ways to add this function:

1, We can open the source file behind the scene, and read the comments around(before and after) the function declaration, and show them in the tip windows.

2, When building the token trie( parsing the source file), we should add new field of Token class, which restore the related comments, then we can use them later.

I personally prefer the first method. :D

MachinTrucChose:
OK, so it's not implemented yet? Thanks for answering.

Out of curiosity, why would the first implementation suggestion be preferable? If I'm understanding you correctly, the Autocomplete plugin parses all the source files on launch, saving all the function names/parameter list in memory. Wouldn't it be better to use that same occasion to save the comments as well? Sure, this uses more memory (a negligeable amount like 1mb unless you're loading the entire Linux kernel source), but at least you're not opening/closing files in the background constantly.

ollydbg:

--- Quote from: MachinTrucChose on November 20, 2009, 04:21:56 am ---OK, so it's not implemented yet? Thanks for answering.

Out of curiosity, why would the first implementation suggestion be preferable? If I'm understanding you correctly, the Autocomplete plugin parses all the source files on launch, saving all the function names/parameter list in memory. Wouldn't it be better to use that same occasion to save the comments as well? Sure, this uses more memory (a negligeable amount like 1mb unless you're loading the entire Linux kernel source), but at least you're not opening/closing files in the background constantly.

--- End quote ---

Yes, You are right!
This is a good reason to use the second implementation. We can add a field "wxString comment" to every Token. But I'm not sure it can implement easily. Because we have both comments around the statement. How can the parser determine which comment belong to the correct token?

MortenMacFly:

--- Quote from: ollydbg on November 20, 2009, 04:28:58 am ---How can the parser determine which comment belong to the correct token?

--- End quote ---
This is absolutely not easy. Often you find such code snippets:

--- Code: ---/* My comment on the function */
/* const */ RetObj& MyFunc (int i, float b) // b=0
{
  // ...
}

--- End code ---

How would you differ which comment to show?

The only thing I can imagine is to support e.g. doxygen comments only. In that case the code would look like:

--- Code: ---/** My doxygen comment on the function */
/* const */ RetObj& MyFunc (int i, float b) // b=0
{
  // ...
}

--- End code ---
...and you could easily search for comments between "/**" and "*/" before a function. Hence using specialisations like:

--- Code: ---int myInt; //!< My Doxygen comment

--- End code ---
...which are possible in principle for functions, too would be difficult.

So - the only idea I have is to support doxygen style comments before a function. The last question: What to show? The documentation of the declaration, or implementation, both can be applicable and appear twice.

Edit: I'll also tell you what I usually do:
I create code with full doxygen documentation. Then I create the documentation and embed this into C::B as a help file. Thus I have always every documentation available. Because mostly I not only need the docs of the function, but some others, too. which are nicely liinked in the generated help.

Navigation

[0] Message Index

[#] Next page