Is there a way to set ENABLE_PREPROCESSING = NO while making sure that documentation for macros will still be included?
For example, it's easy to set PREDEFINED = __cplusplus, but I would rather not have to do that for every single #define that Doxygen might not predefine (i.e. __GNUC__, etc).
Related
I want to create my own Visual Studio Code theme. The JSON file for VSC themes consists of an object called colors, which contains UI colors, and an array called tokenColors, which contains syntax colors (from my understanding).
The VSC documentation for the different colors selectors can be found here. What I haven't found is a list of the different tokenColors and what they mean.
So far, I have found out that you can use the Developer: Inspect Editor Tokens and Scopes command to find out what token/scope every word/symbol in your code belongs to. But I can't write code in every language containing every possible code construct and keyword just to then inspect them and find out the scope they belong to.
I also learnt that these scopes are the same or similar to the ones used in Sublime Text. However, this documentation only contains a small portion of the scopes used in VSC's built in themes. How am I supposed to find out what the remaining scopes stand for?
For syntax highlighting a different set of colors is used, with an own set of token identifiers (aka. scopes). The Syntax Highlighting Guide describes details of the tokenization + theming process and refers to the TextMate rules, which are used also in VS Code.
This page contains section about naming conventions and that's essentially the base set of token IDs that have become the de-facto standard. Extensions often create their own scopes, but you cannot handle all of them. So, focus on the base set instead.
Fortunately, scope selectors are hierarchically organized. When the highlighter cannot find a color for, say, keyword.sql.mysql it tries again with keyword.sql or finally with keyword. That means, as long as all scopes follow these rules, then there will be at least a color available from the base set.
I would like to ask if you know a way how to make Doxygen ignore some keywords in code.
I use C in automation project (created in B+R Automation Studio) so there are Local and Global variables definitions.
Example:
_Local int variable1
_Global int variable2
This causes problems to Doxygen generated documentation.
What I need is to ignore bold part of variable definition but I only found a way how to ignore bigger part of code (unfortunately syntax have to stay exactly as in example).
Thank you for your advice and/or answers.
Cheers,
Pavel
The possibilities doxygen has for this are:
create an INPUT_FILTER filtering away the unwanted parts
have a look at the preprocessing possibilities and define all names
define all the names in an include file and include this file conditionally and run with preprocessing
For all possibilities see the documentation in the configuration file section
I'm learning about gcc's cleanup attribute, and learning how it calls a function to be run when a variable goes out of scope, and I don't understand why you can use the word "cleanup" with or without underscores. Where is the documentation for, or documentation of, the version with underscores?
The gcc documentation above shows it like this:
__attribute__ ((cleanup(cleanup_function)))
However, most code samples I read, show it like this:
__attribute__ ((__cleanup__(cleanup_function)))
Ex:
http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html
http://www.nongnu.org/avr-libc/user-manual/atomic_8h_source.html
Note that the first example link states they are identical, and of course coding it proves this, but how did he know this originally? Where did this come from?
Why the difference? Where is __cleanup__ defined or documented, as opposed to cleanup?
My fundamental problem lies in the fact that I don't know what I don't know, therefore I am trying to expose some of my unknown unknowns so they become known unknowns, until I can study them and make them known knowns.
My thinking is that perhaps there is some globally-applied principle to gcc preprocessor directives, where you can arbitrarily add underscores before or after any of them? -- Or perhaps only some of them? -- Or perhaps it modifies the preprocessor directive or attribute somehow and there are cases where one method, with or without the extra underscores, is preferred over the other?
You are allowed to define a macro cleanup, as it is not a name that is reserved to the compiler. You are not allowed to define one named __cleanup__. This guarantees that your code using __cleanup__ is unaffected by other code (provided that other code behaves, of course).
As https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax explains:
You may optionally specify attribute names with __ preceding and following the name. This allows you to use them in header files without being concerned about a possible macro of the same name. For example, you may use the attribute name __noreturn__ instead of noreturn.
(But note that attributes are not preprocessor directives.)
I have a third party piece of code that works differently when I add a macro via Makefile e.g. -DMacro instead of doing #define MACRO in a top level header file
(which as their documentation implies is included in ALL files).
I Googled if there are any differences in defining it in different ways but could not come up with much except Precedence of -D MACRO and #define MACRO.
I am wondering if I am missing anything about make documentation / C standards before I start debugging and determining the issue.
Thanks for any answers.
Usually, it's exactly the same but neither make nor the ISO standard have anything to say about it. It's up to the compiler itself, some may not even have a -D option.
To make, it's just running the command (such as gcc) with whatever options it takes. ISO doesn't specify anything about how to run a compiler, just how the compiler (and the things it creates) behaves.
For gcc, the preprocessor options can be found here so it looks like it is identical to #define.
I would like to tell emacs to treat some keywords (or regular expressions even better) as syntactic whitespace, or, in other words, to ignore them.
For example: emacs highlighting and cedet misinterpret the code
void function() some_compiler_specific_modifier(){
...
}
as some_compiler_specific_modifier being the function name.
I have a list of the modifiers so I would love it if emacs could just ignore them whenever it finds them.
EDIT: the most important part is to make the cedet parser ignore these keywords...
To do this, you can modify semantic-lex-c-preprocessor-symbol-map to include the symbols you want to have disappear. Since you have lots of macros, and some of those macros apparently take an argument, you are probably better off create some new header, such as:
goofy.h:
#define some_compiler_specific_modifier(A)
#define some_other_compiler_modifier(B)
// ...
and then add that to semantic-lex-c-preprocessor-symbol-file.
After modifying those variables, you may need to then call semantic-c-reset-preprocessor-symbol-map to get the changes to take effect.
Alternately, use the ede-cpp-root-project type and specify the above info via the configuration in that project style. (See the doc for more on that.)