Can Doxygen easily be configured to recognise TODO and FIXME lines? - doxygen

I've just installed and setup an instance of Doxygen, but out of the box it only finds TODO tags in code when marked in a block like:
/**
* #todo Foo
*/
It doesn't seem to find:
// TODO Foo
// FIXME Bar
// #todo Baz
Most IDE's and bug trackers which handle parsing are fine with them, is there an easy way to configure Doxygen to find them and list them as ToDo items?

There are a number of examples and methods we can use:
For a one line comment with valid doxygen commands (e.g. \todo) you would use
/// \todo Some (optional) text
Note the three forward slashes, not the usual two. See point three on the second list in the special documentation blocks section of the doxygen documentation. This can be used to add new todo items to your source code.
Generally one can define custom tags (like FIXME) by defining an alias in the Doxygen configuration file. For example
ALIASES += FIXME="\todo"
which will allow you to write \FIXME in your source code and the comments prefixed with \FIXME will be included in you todo list in the final documentation. The problem here is that you have to prefix your aliases with the \ (or #) symbol and begin the comment with three leading forward slashes which, if you want to leave the FIXMEs in your code as they are, is not an option.
Finally, an alternative method, and what I think you are looking for, would be to preprocess your source files using the INPUT_FILTER configuration file option. This option defines a command that is applied to each of your source files before doxygen builds the documentation, so we can define a command which replaces instances of TODO and FIXME with valid doxygen markup.
INPUT_FILTER = "sed -e 's/\/\/.*FIXME/\/\/\/ \\todo/'"
This filter replaces all instances of // FIXME (with any amount (or none) of whitespace between // and FIXME) with /// \todo. This substitution is made internally by doxygen only: your source files are not modified on disk.
Note: This last point was inspired by the accepted answer to the question Getting doxygen and MSVC TODO tags to work together. However, that answer used the FILE_VERSION_FILTER configuration option rather than INPUT_FILTER. I think that the latter (INPUT_FILTER) is actually more appropriate here. Also, the sed command used in that answer does not work for me.

Related

Orgmode, How can I remove codeblock descriptions?

I have an orgmode document with a latex codeblock:
So:
#+BEGIN_SRC latex
Hello
#+END_SRC
But when I generate a pdf, I get:
How can I remove this "Latex" description, and have only "So: Hello" shown?
Thank you!
From the comment, I don't think that org-latex-classes is quite correct. In
particular, the \usepackage* bit doesn't look correct.
The C-h v for that variable states
Alist of LaTeX classes and associated header and structure.
If #+LATEX_CLASS is set in the buffer, use its value and the
associated information. Here is the structure of each cell:
(class-name
header-string
(numbered-section . unnumbered-section)
...)
The header string
-----------------
The HEADER-STRING is the header that will be inserted into the
LaTeX file. It should contain the \documentclass macro, and
anything else that is needed for this setup. To this header, the
following commands will be added:
- Calls to \usepackage for all packages mentioned in the
variables ‘org-latex-default-packages-alist’ and
‘org-latex-packages-alist’. Thus, your header definitions
should avoid to also request these packages.
- Lines specified via "#+LATEX_HEADER:" and
"#+LATEX_HEADER_EXTRA:" keywords.
If you need more control about the sequence in which the header
is built up, or if you want to exclude one of these building
blocks for a particular class, you can use the following
macro-like placeholders.
[DEFAULT-PACKAGES] \usepackage statements for default packages
[NO-DEFAULT-PACKAGES] do not include any of the default packages
[PACKAGES] \usepackage statements for packages
[NO-PACKAGES] do not include the packages
[EXTRA] the stuff from #+LATEX_HEADER(_EXTRA)
[NO-EXTRA] do not include #+LATEX_HEADER(_EXTRA) stuff
So a header like
\documentclass{article}
[NO-DEFAULT-PACKAGES]
[EXTRA]
\providecommand{\alert}[1]{\textbf{#1}}
[PACKAGES]
will omit the default packages, and will include the
#+LATEX_HEADER and #+LATEX_HEADER_EXTRA lines, then have a call
to \providecommand, and then place \usepackage commands based
on the content of ‘org-latex-packages-alist’.
So I don't think you should have that \packages* line in there. Also, you are
better off either using the custom interface to set this variable or put it as a
setq in your init file. I don't think there is any reason to have to load it
inside an eval-after-load call.
Use the org variables mentioned in the docs above to add/remove packages. You
need to be careful with this as I've found this to be one area org-mode can be a
little fragile - there are some package dependencies which kick in differently
depending on whether your exporting a whole org file as latex, part of a
file/tree or a block.

Can make expand several macros in the external text file for me?

I've got a rather big and verbose section of line-based configuration file. I'd like to use this section as template (assuming I going to preconfigure this section, test it and then replace actual values with $(make) $(macros)), substituting the key parameters (very few of them, really) effectively "cloning" this "template" with few customized parameters to the working config file. Can make do the work for me in the described case?
Please bear with me, I'm truly a make layman and even not sure if it is right tool in this case.
An example
I'm preconfiguring and testing something like:
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
I'm wondering that if convert tokens marked with trailing zero above to macros:
<$(section)>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with $(trailing)
</$(section)>
... wondering that I can utilize make to produce clones of premade configuration slightly customized with my data in place of macros:
<section42>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing42
</section42>
<foo>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with bar
</foo>
Assuming "section42", "foo" and "trailing42", "bar" are substitutes for $(section), $(trailing) macros respectively.
You can use m4 preprocessor in your makefiles to do exactly that: expand macros in template files:
M4 can be called a “template language”, a “macro language” or a “preprocessor language”. The name “m4” also refers to the program which processes texts in this language: this “preprocessor” or “macro processor” takes as input an m4 template and sends this to the output, after acting on any embedded directives, called macros.
Create a file named section.m4:
$ cat section.m4
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
And have a rule in your makefile to expand macros in that template to produce section.cfg:
section.cfg : section.m4
m4 -Dsection0=foo -Dtrailing0=bar $< >$#

How can I use a simpler link syntax in org-mode?

I'd like to have links with the syntax [[foo bar]] go to files with the name foo bar.org. This would make using org-mode much more like using a personal local wiki.
Is this possible without breaking existing link functionality? I'd also ideally still be able to export to html, etc. with standard org-mode tools.
The best I've been able to do is something like: (setq org-link-abbrev-alist '(("o" . "file:%s.org")))
This lets me use the syntax [[o:foo bar]], but that is more verbose, and looks distractingly ugly inline. For example: The quick brown o:fox jumps over the o:lazy_dog. And [[o:foo bar][foo bar]] is even more verbose to type and edit (though it reads fine in org mode).
I don't have a ready made solution and am not a programmer, but this part is self-documenting in org.el, you can write a dedicated link search function. I cite:
"List of functions to execute a file search triggered by a link.
Functions added to this hook must accept a single argument, the search
string that was part of the file link, the part after the double
colon. The function must first check if it would like to handle this
search, for example by checking the `major-mode' or the file
extension. If it decides not to handle this search, it should just
return nil to give other functions a chance. If it does handle the
search, it must return a non-nil value to keep other functions from
trying.
Each function can access the current prefix argument through the
variable `current-prefix-arg'. Note that a single prefix is used to
force opening a link in Emacs, so it may be good to only use a numeric
or double prefix to guide the search function.
In case this is needed, a function in this hook can also restore the
window configuration before `org-open-at-point' was called using:
(set-window-configuration org-window-config-before-follow-link)")
See also Hyperlinks :: Custom Searches # gnu.org

Doxygen expands environment variable inside mainpage

I have a mainpage.dox file which is invoked in the configuration file as:
USE_MDFILE_AS_MAINPAGE = ../mainpage.dox
Inside the document I provide instructions on compiling. I would like to list the compiler option as -L/$(MKLROOT)/lib/intel64 -lmkl_rt, however the $(MKLROOT) part is expanded. Is there a way to prevent this from happening?
When I put the following in mainpage.md
1 Test with backticks `-L$(MKLROOT)/lib/intel64 -lmkl_rt`
2 Test without backticks -L\$(MKLROOT)/lib/intel64 -lmkl_rt
3 Test with code <code>-L\$(MKLROOT)/lib/intel64 -lmkl_rt</code>
#verbatim
4 Test with verbatim -L$(MKLROOT)/lib/intel64 -lmkl_rt
#endverbatim
The $(MKLROOT) in the first example gets (incorrectly) expanded.
The other three examples work as expected (using doxygen 1.8.5)
Note that USE_MDFILE_AS_MAINPAGE expects a pure markdown file, not something with a /*! .. */ comment block.
FWIW the latest version of Doxygen as of this writing (1.8.15) still behave in the same way and escaping the backslash still doesn't work. I'm using the following workaround for now:
`-L$``$(MKLROOT)`
which, while ugly, works and doesn't require adding the <code> tags everywhere.
I've also created an issue in Doxygen asking for this to be changed.

How can I get Emacs to ignore certain keywords?

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.)