\endcode Within Doxygen Comment Does Not Stop Color Coding

[PiezonTM]

I have a Doxygen comment with a "\code" section.  Within the "\code" section the color coding works fine--looks good.  However after the "\endcode" the following comments still have color coding, I suspect it shouldn't.

Code: [Select]

/*!
This part of the Doxygen comment is color coded as a comment--which seems good.

\code
/* This section gets color coded correctly */

/* some comment... */
static int    var[2];
...
\endcode

The comments that now follow do not use the "comment" color.
Instead a for or "quoted string" will be color coded to match the color coding.
*/
Is there something I have done wrong or do I need to do something different?  Could it just be the comment within the code section ending the doxygen color coding?  If so, is Doxygen "\code" sections supposed to be supported?

I'm running:
SlickEdit Pro 2014 (v19.0.2.5 64-bit)
Emulation: CUA
OS: Linux
OS Version: Ubuntu 14.04.2 LTS

[Clark]

Maybe I'm confused. Is this supposed to be C++ code? C++ does not support nested comments "/* /* */ */".

[PiezonTM]

The code is actually C.  We are using gcc. I would agree nesting comments may not be typical but is supported depending on the compiler, many throw warnings depending on the options in an attempt to avoid confusion in the code.  Since we are using doxygen for documentation we sometimes need code as a samples which may itself contain comments. 

[Clark]

You can reconfigure the color coding for C++ to allow for nested comments.

[LBCEi]

I suspect that what you will find after you enable nested comments is that the "code" section in your Doxygen comment is no longer colored as code and the entire comment block is now colored as a comment.  This is what I would expect -- although it might be kind of "cute" if these embedded "code" sections were colored as code.  However, I think the confusion this would cause between these "code" comment sections and real sections of code would be a problem.

My 2 cents.

[Clark]

That would be correct. There would have to be some sort of embedded language support for the \code section. It's not supported that way yet.

[PiezonTM]

Thanks for the suggestion.  I went through and attempted to enable nested comments for:
/*!  */   - Doxygen style
/** */   - Doxygen style
/*   */   - Standard C comment
None of this had any effect.  The comments after the \code section were still color coded.  Is this potentially a problem?

[Clark]

Works for me. When I turned on "Nesting allowed" for each of these. It allowed me to nest comments and get the correct comment color for something like the following:

/*
   before
   /* nested */
   after <-- this gets colored as comment color when you turn on "Nesting allowed"
*/

[PiezonTM]

That is a standard C example, not a Doxygen \code example.  Can you try the example I have at the start for this post.  I just tried that example verbatim and it fails.  I suspect the problem may be when Doxygen syntax is parsed.

[Clark]

\code has no effect on color coding of comments. It would require embedded color coding as I described in a previous post.

[PiezonTM]

Have a look at my output (attached file).  The problem seems to be a nested comment in my doxygen \code.  I could really care less if the \code is color coded (would be a neat option).  I'd like the comments after the \code to be comment color coded.  At this rate I'd be happy with the entire comment, \code and all, be comment color coded.  This is not the case for my example with Doxygen \code containing comments.  Unless there is something else I am missing.  I've ensured the "Nesting Allowed" is checked.

[Clark]

I don't have access to a computer right now so I can't try your exact example. It looks to me like the Nesting allowed check box isn't set. You could try restarting SlickEdit but I didn't need to restart to see the effects of the check box.

[Clark]

On second thought, it doesn't realize that /* starts another nesting since the current pair starts with /*!. Sadly there isn't a great work around for this other than removing the doc comment definitions and using nesting allowed for /*.

[Clark]

I think we can put some better smarts in for this in v20.

[Dennis]

You may not like for this idea, but rather than using a non-standard compiler extension, you could search and replace your code samples and not embed /* or */ in comments.

Code: [Select]

/**
 * The description of this function is that it will be described with an example.
 * <pre>
 * /&ast; nobody knows what this function will do &ast;/
 * void main(int argc, char *argv[]) {
 *   mystery_function();
 * }
 * </pre>
 */
void mystery_function();