GNOME Bugzilla – Bug 737472
HTML code special commands unconditionally include line numbers
Last modified: 2016-09-05 13:45:33 UTC
This commit: commit 0dd59398b3f62288897c8c3405977a27a94fbfee Author: Dimitri van Heesch <dimitri@stack.nl> Date: Mon Aug 4 14:07:53 2014 +0200 Bug 734099 - Add support for non-parsed language caused the existing hard-coded TRUE showLineNumbers parameter to FileParser::parseCode to take effect in html. Consequently @code blocks that formerly were the raw code now have line numbers. These (syntactically invalid) line numbers get captured by cut-and-paste from the documentation, preventing use of @code to demonstrate best practices in a form suitable for users to copy into their applications. Whether a particular @code or @verbatim block includes line numbers should be controllable by the user. At this time, the only way to restore the old behavior aapears to be to change the hard-coded value for showLineNumbers that is passed to FileParser::parseCode in htmldocvisitor.cpp to TRUE and rebuild Doxygen.
Correction: the change is to pass FALSE instead of TRUE for showLineNumbers in htmldocvisitor.cpp and rebuild.
I think this may describe the cause of an issue we are having. Since updating to version 1.8.8 (from 1.8.5), the code blocks created by \dontinclude in markdown files, now have line numbers. This isn't great, because the line numbering is not useful and distracting. For example, the \dontinclude example from the Doxygen manual (see http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmddontinclude), yields HTML output like this: Our main function starts like this: 1 void main() 2 { First we create an object t of the Test class. 1 Test t; Then we call the example member function 1 t.example(); After that our little test routine ends. 1 }
I recently pushed a proposed patch to githib (pul request 511) for the problem so that "unparsed" code does not get linenumbers anymore.
Code has been integrated on github.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.8.12. Please verify if this is indeed the case. Reopen the bug if you think it is not fixed and please include any additional information that you think can be relevant (preferably in the form of a self-contained example).