You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<memberdef kind="function" id="extra_8txt_1afc80a6c723fc08b438df6fb016fc461e" prot="public" static="no" const="no" explicit="no" inline="no" virt="non-virtual">
<type>title There may</type>
<definition>title There may be</definition>
<argsstring>(index.html) that are distributed with Python-Markdown that are not included here in Extra.The features of those extensions are not part of PHP Markdown Extra</argsstring>
<name>be</name>
<param>
<type>index.</type>
<declname>html</declname>
</param>
<briefdescription>
</briefdescription>
<detaileddescription>
</detaileddescription>
<inbodydescription>
</inbodydescription>
<location file="Python-Markdown-2.6.5-final/docs/extensions/extra.txt" line="37" column="1"/>
</memberdef>
<memberdef kind="function" id="extra_8txt_1aee61e6bce6c1e5b8c0802804ce9a805e" prot="public" static="no" const="no" explicit="no" inline="no" virt="non-virtual">
<type>title There may and not part of Python Markdown Extra If you really would like Extra to include additional we suggest creating your own clone of Extra under a different</type>
<definition>title There may and not part of Python Markdown Extra If you really would like Extra to include additional we suggest creating your own clone of Extra under a different name</definition>
<argsstring>(see the[Extension API](api.html)).Markdown Inside HTML Blocks---------------------------Unlike the other Extra features</argsstring>
<name>name</name>
<param>
<type>see </type>
<declname>the</declname>
<array>(api.html)[Extension API]</array>
</param>
<briefdescription>
</briefdescription>
<detaileddescription>
</detaileddescription>
<inbodydescription>
</inbodydescription>
<location file="Python-Markdown-2.6.5-final/docs/extensions/extra.txt" line="42" column="1"/>
</memberdef>
This bug does not occur in a previous version of Doxygen, however I'm unsure exactly which version I'm using (it's written 1.8.11 in the VERSION & in xml, but haven't updated in around 6 months, before the 1.8.11 release date 30-12-2015)
From the looks of it, doxygen crawls and autodocuments .txt, as appears in Python-Markdown-2.6.5-final/docs/extensions/extra.txt
If you need any more data or examples, please let me know. Thx.
Tell me if you need anything else. I can attach the full all.xml if it's needed.
I'm constantly monitoring the xml output on various open-source packages. This bug occurred in multiple packages, not only this specific package. And again, it was added after Aug 23,2015.
Hope this helps, tell me if there's anything more you need.
On 2016-01-27 18:24:14 +0000, albert wrote:
I didn't find the all.xml when directly running doxygen, as far as I know by head this is a result of a "postprocessing" step with xsl etc.
I looked for the text part:
title There may be
(index.html) that are distributed with Python-Markdown that are not included here in Extra.The features of those extensions are not part of PHP Markdown Extra
Which I found in the 1.8.11 version in extra_8txt.xml. This file was not present in the 1.8.10 version.
In version 1.8.10 the txt files were not processed by default, in the 1.8.11 version they are. When enabling the txt files in in the 1.8.10 version the file this extra_8txt.xml will appear too and has the same content (except for the version number) as in the 1.8.11 version.
You might want to disable the *.txt (and *.md) files or even, in this case, the complete docs directory.
Why have txt files been enabled since 1.8.10? What was the feature request?
I think it's a bad solution that by default, non code files will be recognized as proper functions in the xml, with argsstrings, params, code body etc.
As a user, for me, doxygen's strength is to distinguish between actual code and other stuff, and by default it should read only comments of the actual code.
Isn't it better that by default doxygen only parses a specific set of extensions known as code like .h .cpp etc?
Moreover, i think it breaks doxygen, because the list of txt extensions that a user can have is endless there's no way to exclude all of them. As the bug title says, a user that runs doxygen on a given repository will have a high chance of having phantom functions as a result. On the other hand, the list of code files is finite.
If the feature request that asked for parsing txt file is important, an easy fix would maybe be to introduce an additional flag in the cfg additional non-code file extensions that doxygen will parse.
Hope my comment is helpful, if I can provide any more feedback, please let me know.
On 2016-01-28 19:03:54 +0000, albert wrote:
Regarding my statement:
"In version 1.8.10 the txt files were not processed by default, in the 1.8.11 version they are. When enabling the txt files in in the 1.8.10 version the file this extra_8txt.xml will appear too and has the same content (except for the version number) as in the 1.8.11 version." in Comment 4 I now think it is not true as I didn't find any reference yet why it is present now and was not present in the past. Looks like txt file are processed as C files (historical reason, now still present due to compatibility, maybe setting the txt files to md files in the EXTENSION_MAPPING might help.
I think that in principle txt files are still useful as they might contain some background information (like in md, dox files etc).
I don't think it's there for historical reasons - it's new. It did not occur in the Aug 25, 2015 version in Github (https://github.com/doxygen/doxygen/tree/SHA: 663544c), with the attached config file, as described in comment2.
I've looked at the git commit messages since then and couldn't find any message that directly relates to why it was changed. I'm not intimate with Doxygen source code to git blame the specific line that defines which extensions are read by default.
I can do more tests and find the specific commit that changed it.
Think of users using doxygen out of the box on a given GitHub repository, containing source files and other non-source files. If Doxygen will create functions/namespaces/classes that are simply not there, they will not give Doxygen a second chance, and that would be a shame. The problem will get bigger as the number of non-source files increases. I personally don't use the HTML output - will these "phantom" functions/classes/namespaces be created there as well?
If you look at any GitHub repository, I agree with you that there is useful information in these files, but I think the easiest way to view them is to directly look at the files and directories of the repository. A simple link to the repository will give you all that info. I don't think Doxygen should crawl these files.
One question just to be clear - The new default will make it read .txt & .md extensions only, or everything? What about .rst .doc .docx .xls .xml .html etc...
On 2016-01-30 17:41:09 +0000, albert wrote:
Did some further research and found pull request 383 (#383) from August 16 2015 and incorporated on August 31 2015 with comment:
Make list of default extensions consistent with language mapping list
One of the file extensions added by default was 'txt' and this is by default interpreted as C code. In the past it was possible to specify 'txt' files as well and they would be interpreted as C code (main usage will probably have been to give some text and place this between C comment signs so the default interpreter could be used). The 'txt' files mentioned in this bug report are more markdown style and using an EXTENSION_MAPPING would be beneficial.
Looking at the config.xml file this file has not been updated and thus there is now and inconsistency between the documentation and the implementation.
This inconsistency should be removed.
The said pull request was the cause of the mentioned bug
changing the EXTENSION_MAPPING to txt=md solved it.
If I may, I will suggest changing the default away from txt=c, and not only changing the documentation. I think it will fit better most GitHub repositories who tend to have many txt files, especially since doxygen is used these days for other languages than c.
I also think that for the repository used to report this bug, the new default creates a bug, because classes that are not there are created. I also checked the html output - please look at the html created for class "so" in "classes" tab, "class list" tab which simply does not exist in the code. Same If you look on "classes" tab, "class hierarchy", class "so" seems to inherit from classes that do not exist.
I think that currently the best default would be txt=md or don't parse txt files (which was the default behavior before Aug 31 2015) - both options are programming language agnostic.
Created attachment 320097
comment10 html screenshot
On 2016-01-31 13:05:48 +0000, Dimitri van Heesch wrote:
I'll remove parsing .txt files by default like before. Then the user can configure doxygen to do this using the "c" or "markdown" parser if needed, using FILE_PATTERNS and EXTENSION_MAPPING.
On 2016-09-05 13:46:04 +0000, Dimitri van Heesch wrote:
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).
The text was updated successfully, but these errors were encountered:
status RESOLVED severity major in component documentation for ---
Reported in version 1.8.12-GIT on platform Other
Assigned to: Dimitri van Heesch
Original attachment names and IDs:
On 2016-01-19 13:53:29 +0000, erez.oxman@gmail.com wrote:
On 2016-01-19 17:50:38 +0000, erez.oxman@gmail.com wrote:
On 2016-01-24 19:06:00 +0000, albert wrote:
On 2016-01-24 19:33:29 +0000, erez.oxman@gmail.com wrote:
On 2016-01-27 18:24:14 +0000, albert wrote:
On 2016-01-27 19:13:15 +0000, erez.oxman@gmail.com wrote:
On 2016-01-28 19:03:54 +0000, albert wrote:
On 2016-01-28 20:43:11 +0000, erez.oxman@gmail.com wrote:
On 2016-01-30 17:41:09 +0000, albert wrote:
On 2016-01-30 17:49:50 +0000, albert wrote:
On 2016-01-30 22:06:47 +0000, erez.oxman@gmail.com wrote:
On 2016-01-30 22:12:59 +0000, erez.oxman@gmail.com wrote:
On 2016-01-31 13:05:48 +0000, Dimitri van Heesch wrote:
On 2016-02-02 06:52:26 +0000, erez.oxman@gmail.com wrote:
On 2016-09-05 13:46:04 +0000, Dimitri van Heesch wrote:
The text was updated successfully, but these errors were encountered: