How do I change the highlight color of the Doxygen tokens like #param or #return so it matches the same visual as JSdoc comments?
What I currently have in my .cpp/.hpp files:
What I would like to see (this is inside a .js file):
For example, is there a way to tell VSCode, all #params strings should be blue?
I managed to get JSDoc like comment blocks highlighting using the Better C++ syntax package. For more customization checkout this issue thread.
EDIT: After we determined that your jsdoc comment syntax was not being separately parsed, you found the Better C++ Syntax package which does so. And gives you more control over the contents of a jsdoc comments's internals. Now this textmate scope will give you the blue colored #'s parameters you desired.
Try this in your settings.json
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"scope": "storage.type.class.doxygen.cpp",
"settings": {
"foreground": "#00f"
}
}
]
}
You can get the scope by using the Developer: Inspect TM Scopes command from the command palette. This allows you to click on a word in your editor, like #param and see its textmate scope. Which then goes into the tokenColorCustomizations rule.
There are typically 3 or 4 scopes listed which you can use in a space-separated list if you want more distinction. Such as if you wanted this rule to apply only to js docs:
"scope": " source.cpp storage.type.class.doxygen.cpp
Besides the foreground color you can also set its fontStyle here as well. Options are: italic, bold and underline - which can be used in combination with each other too.
As you noticed, with that Beter C++ Syntax package, you need to use #brief instead of #desc in your cpp jsdoc-like comments.
Related
Based on the answer to this question, I was able to get 2-column papaja with listings wrapping (rather than overflowing column width). But the listings package turns off various features that help code listings and R output stand out relative to the main text.
A simple solution would be if I could globally change the font faces and/or sizes selectively for code and R output. Is there a way to do that in papaja? I haven't been able to figure this out from papaja or Rmarkdown documentation. Thank you!
When you use the listings package in a papaja (or bookdown) document, what is technically happening is that all code is wrapped into an lstlisting LaTeX environment that comes with its own capabilities of customizing code appearance. Hence, you don't see the syntax highlighting that you would otherwise see if you would not use the listings package. The documentation of the listings package with instructions how to style your code can be found here.
To make use of this, you can extend the YAML header of your papaja document like this:
documentclass : "apa6"
classoption : "jou"
output :
papaja::apa6_pdf:
pandoc_args: --listings
header-includes:
- \lstset{breaklines=true,language=R,basicstyle=\tiny\ttfamily,frame=trB,commentstyle=\color{darkgray}\textit}
Here, I first specify the code's language, and use a tiny monospace font. With frame, I add a frame around the code block, and with commentstyle I set comments in italic and gray.
How do I change the syntax highlighting in VSCode so that it adheres to a particular style guide? For example, I want to adhere to the Google C++ style guide where member variables are written as some_member_variable_. When I use this convention, VSCode does not color that name differently from standard text. But I have some code that uses the mSomeMemberVariable convention, and that does get colored differently than other text. Is there a way to configure this better?
TL;DR >There is no easy way to apply Google style syntax highlighting unless you find an existing cpp Textmate grammar file for it (I could not find one). However the following is how you would implement it yourself.
Looking at the CPP syntax file (cpp.tmLanguage.json), we see that there is no scope pattern capturing the Google-style member variables. You can add one:
{ // this is the existing scope that matches mSomeMemberVariable
"match": "\\b(f|m)[A-Z]\\w*\\b",
"name": "variable.other.readwrite.member.cpp"
},
{ // you can add this scope to match some_member_variable_
"match": "\\b([a-z][a-z\\d]*_)+\\b",
"name": "variable.other.readwrite.member.google.cpp"
}
Now you can make sure it is styled by making sure its scope (or any of the outer scopes like variable.other.readwrite.member), has a theme rule in your theme's .json file.
The following is a more detailed explanation. From here we see:
There are two components to syntax highlighting:
Breaking text into a list of tokens and scopes using a grammar
Then using a theme to map these scopes to specific colors and styles
First we need to figure out which "scope" is styling the member variable:
Command palette > ctrl+shift+p > Developer: Inspect TM Scopes
Click on the member variable name (mSomeMemberVariable)
The most specific scope is the top-most entry. As of this posting it is called variable.other.readwrite.member.cpp
The .cpp part of the name tells us that the scope is defined in the C++ grammar (syntax). As of now the file used for the cpp syntax can be found under [applications_folder]/code/resources/app/extensions/cpp/syntaxes/cpp.tmLanguage.json (see the file in the github repo).
Searching for the scope name in the syntax definition file, we find the following pattern:
{
"match": "\\b(f|m)[A-Z]\\w*\\b",
"name": "variable.other.readwrite.member.cpp"
}
And to see what style is applied to the above scope, we look at the active theme's *.json file. For example, if you are using the Dark+ (default dark) theme, you can find the theme json file at extensions/theme-defaults/themes/dark_plus.json. In this file we find the following text mate theme rule:
{
"name": "Variable and parameter name",
"scope": [
"variable",
"meta.definition.variable.name",
"support.variable",
"entity.name.variable"
],
"settings": {
"foreground": "#9CDCFE"
}
}
From this rule we see that the highlighting is applied by the variable scope. (note that all outer scope styles are applied to inner ones unless you specifically specify the inner scope style to override it)
Now one option for you would be to add your own scope to the existing file. Another would be to edit the existing scope to also match the Google style member variable regex pattern. Yet another option would be to define your own grammar based on the CPP extension style file and create your very own Google CPP VSCode Extension. For example, taking the first approach you can edit cpp.tmLanguage.json as follows:
{
"match": "\\b([a-z][a-z\\d]*_)+\\b",
"name": "variable.other.readwrite.member.google.cpp"
}
P.S. After editing the json files restart VSCode for the changes to take effect.
In my Django projet, I have one models.py file that PyCharm is only partially syntax coloring: it's coloring the Python keywords and comments but not other things it normally does like coloring method names, keyword parameters. This is the only file in my project like this -- all other .py files are fully syntax colored.
It's the file name not contents that is the issue. I know this because when I rename the file, PyCharm immediately fully syntax colors it. When I rename it back to models.py, it goes back to partial coloring.
Note it's not just the syntax coloring that's off -- it's also other code analysis-related tools for this file.
What could be causing PyCharm to be treating this one file differently?
In the PyCharm status bar, there is a "Highlighting level" indicator. Clicking on it allows you to choose the highlighting level between "None", "Syntax" and "Inspections", and the selected value is persisted per file. Please try clicking on it and making sure that the level is set to "Inspections".
In emacs when you do doc comments it correctly highlights docs that start with /**. Example:
/**
* #brief: Test
*/
would be correctly fontified with font-lock-string-face and font-lock-doc-face.
Some people do doc comments with /// instead and Emacs does not fontify this using font-lock-doc-face and font-lock-string-face. Is there a way to get emacs to fontify those types of doc comments as well? I am trying to accomplish this for C/C++ but a flexible solution would be nice.
EDIT:
After looking through the emacs source code a bit I see that this is handled in cc-fonts.el in the lisp/progmodes folder. It looks like c-font-lock-doc-comments can be called with different prefix arguments and modifying this might fix it. When I get more time I will try and see what needs to be changed.
(defconst custom-font-lock-keywords
`((,(lambda (limit)
(c-font-lock-doc-comments "///"
limit gtkdoc-font-lock-doc-comments)))))
(setq-default c-doc-comment-style (quote (gtkdoc javadoc autodoc custom)))
Not too bad just drop in a .emacs file. You can customize the keywords but I just use the default gtkdoc keywords since that works for me.
Thanks to wvxvw for the pointer to c-doc-comment-style.
After testing for a bit this does not work for multi line /// comments (each starting with /// on separate lines). Will edit if fixed.
I am working on some 2D geometry code, in particular a line-class. I have made an enum to describe the relation of line (let's not get into detail concerning this). However to document this, I have something like this:
enum enumRELATION {
/*!this line #######
* other line -------
*
* |
* #######
* |
* |
*/
RELATION_INTERSECT,
...
};
If I let doxygen parse that file, to generate an HTML-file, in the HTML-file this looks like crap (of course). In other words the 2D-plane I try to show is all wrong. I know I can use <br>, to at least get the line breaks, but that's only half the story, because the spaces are still not correct. And the <br>'s makes my documentation in the actual source/header-file look awful. Is there a nice way around this? Or am I too demanding?
You can surround your documentation with the <pre> ... </pre> element, which should nicely keep your line breaks and indentation.
pre is one of the HTML tags that can be safely used in Doxygen documentations, according to this page: http://www.doxygen.nl/manual/htmlcmds.html
Alternatively, you can embed images in your documentation, using the \image command: http://www.doxygen.nl/manual/commands.html#cmdimage
I believe the use of proper images might make the documentation clearer to understand than using 'ascii art' ;)