Before you reference in-doxygen-documentation-how-to-create-a-link-to-a-specific-line-of-a-file, I already reviewed that and it doesn't answer the question I have.
In doxygen, there are several links created to specific lines of code (assuming code is built when building doxygen output). The best example is function details as shown below:
I would like to create similar links for other items that are parsed when doxygen is created. Specifically, the SDD tags that you see in the picture above. By creating a link from the SDD tags, or referencing it in the same way doxygen does with "Definition at line 6969 of file AlarmManager.cc", will allow my team to jump straight to the line of code where the SDD is referenced/implemented. See code example below:
case NEBULIZER_INOPERATIVE_EN: /// #sdd [ALARM_ANALYSIS_SDD_1]
ConditionEvaluations::SetCondition(C1500);
AlarmManager::ROperandNameList_.append(tempName = C1500);
break;
case NOT_NEBULIZER_INOPERATIVE_EN: /// #sdd [ALARM_ANALYSIS_SDD_2]
ConditionEvaluations::ClearCondition(C1500);
AlarmManager::ROperandNameList_.append(tempName = C1500);
break;
case NEBULIZER_DISCONNECTED_EN: /// #sdd [ALARM_ANALYSIS_SDD_3]
ConditionEvaluations::SetCondition(C1501);
AlarmManager::ROperandNameList_.append(tempName = C1501);
break;
I tried anchors in the code, but that didn't work. I don't know how to just reference and create a link to File->code line.
Related
I have a series of .png images that I would like to add notes to in an Rmarkdown document that I am knitting to a .pdf. The basic code for each image looks like this:
```{r certs_coefplot, out.width="100%", fig.cap=fig.4_cap}
knitr::include_graphics("certs_coefplot.png")
```
With beamer slides, I have just inserted some basic latex like this:
\tiny \emph{Notes}: Put Notes here \normalsize
below each code chunk.
But if I try this in the context of a larger document, the notes do not appear below the figure.
A solution involving a custom hook was proposed to a similar question asked here about adding notes to figures in an .Rnw file. In particular, the version where you put the code for the hook at the beginning and then write:
notes = "Notes to explain the plot"
sources = "Explain the sources"
in each chunk seems really convenient.
Is it possible to apply a similar solution an RMarkdown file?
Thanks for making papaja. It's really terrific!
I just submitted my first journal article using it and ran into problems. The layout staff don't know what to do with the code chunks and listings that are fine in single-column, full page format, but not in their 2-column format. I'm trying use the class 'jou' option to make 2 columns, but I can't figure out how to control the size of code and listing fonts (possibly by modifying the css, as recommended here), or how to using the latex package 'listings' to set listings to wrap (as recommended here).
I'd be grateful for any advice, and my apologies if I've missed how one might do this in the documentation.
If it's only about getting the listings package to work, you can modify the YAML header that it looks similar to the following:
documentclass : "apa6"
classoption : "jou"
output :
papaja::apa6_pdf:
pandoc_args: --listings
header-includes:
- \lstset{breaklines=true}
However, note that using automatic line breaks will most likely break the code at some points. Therefore, it is worthwhile to consider alternatives: For instance, you could try to use a code style that uses more line breaks. The styler package and add-in might be helpful accomplishing this: https://styler.r-lib.org/
Suppose I have a logger function, and I called it all over my code. My logs usually show the probability of the existence of a problem or a bug. More actions and investigations needed to confirm the problem or bug. For example, maintainer or tester should grab the input, open it in an editor, and if a specific string is inside the input, The problem or bug is confirmed.
I want to document the procedure of confirming the bug in a comment above of the log function in code. I also want to extract all of these kinds of comments and create, say an HTML table from them. So I can give that table to the tester or maintainer to find correct bugs for me.
I show it in a simple code. I know it's silly, but does the job:
std::ifstream t("file.txt");
std::string input;
// Read the whole file into input string
// DIAGNOSTICS COMMENT
// NOHELLO_BUG
// Diagnostics steps: 1.Open input file file.txt 2. Search hello inside the file, if hello exists inside the file, there should be a bug, send file.txt to the developer!
if (input.find("hello") == std::string::npos)
{
logger::log("hello not found inside input file!");
return false;
}
Is there any command in Doxygen for this purpose, although Any other solution is welcome too. The most obvious way is to write that table by myself, But maintaining that table will be a disaster too.
Doxygen contains a.o. the commands \todo, \bug
From the documentation:
https://www.doxygen.nl/manual/commands.html#cmdtodo
\todo { paragraph describing what is to be done }
Starts a paragraph where a TODO item is described. The description will also add an item to a separate TODO list. The two instances of the description will be cross-referenced. Each item in the TODO list will be preceded by a header that indicates the origin of the item.
\bug https://www.doxygen.nl/manual/commands.html#cmdbug:
\bug { bug description }
Starts a paragraph where one or more bugs may be reported. The paragraph will be indented. The text of the paragraph has no special internal structure. All visual enhancement commands may be used inside the paragraph. Multiple adjacent \bug commands will be joined into a single paragraph. Each bug description will start on a new line. Alternatively, one \bug command may mention several bugs.
Furthermore doxygen contains the command \xreflist with which you can define your own lists.
Small excerpt from the documentation (https://www.doxygen.nl/manual/commands.html#cmdxrefitem):
\xrefitem "(heading)" "(list title)" { text }
This command is a generalization of commands such as \todo and \bug. It can be used to create user-defined text sections which are automatically cross-referenced between the place of occurrence and a related page, which will be generated. On the related page all sections of the same type will be collected.
The first argument is an identifier uniquely representing the type of the section. The second argument is a quoted string representing the heading of the section under which text passed as the fourth argument is put. The third argument (list title) is used as the title for the related page containing all items with the same key. The keys "todo", "test", "bug" and "deprecated" are predefined.
All class name instanced«s in a class' documentation are linking to itself. Is there an option to prevent this?
This is particularly relevant when I have several classes with similar names and need to navigate through their documentation.
I'm using Doxygen 1.8.13 to document c++ project.
I have not tested it yet, but according to the documentation of Doxygen:
All words in the documentation that correspond to a documented class
and contain at least one non-lower case character will automatically
be replaced by a link to the page containing the documentation of the
class. If you want to prevent that a word that corresponds to a
documented class is replaced by a link you should put a % in front of
the word. To link to an all lower case symbol, use \ref.
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' ;)