mosra / m.css

A no-nonsense, no-JavaScript CSS framework, site and documentation theme for content-oriented websites
https://mcss.mosra.cz
Other
409 stars 92 forks source link

Use full pybind11 docstrings #166

Closed sizmailov closed 2 years ago

sizmailov commented 4 years ago

Pybind11 docstrings were limited to first paragraph and rest was stripped, this PR fixes that.

Test page render ![image](https://user-images.githubusercontent.com/2975991/86127546-bc25e300-bae8-11ea-8e59-be9d17e8d167.png)
codecov[bot] commented 4 years ago

Codecov Report

Merging #166 into master will increase coverage by 1.74%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##           master      #166      +/-   ##
===========================================
+ Coverage   98.25%   100.00%   +1.74%     
===========================================
  Files          27         1      -26     
  Lines        6647       353    -6294     
  Branches       44        44              
===========================================
- Hits         6531       353    -6178     
+ Misses        116         0     -116     
Impacted Files Coverage Δ
plugins/m/qr.py
plugins/m/components.py
documentation/test/_search_test_metadata.py
documentation/doxygen.py
plugins/m/gh.py
plugins/m/plots.py
plugins/m/link.py
plugins/dot2svg.py
plugins/m/dox.py
plugins/ansilexer.py
... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e6eff54...4c149e0. Read the comment docs.

mosra commented 2 years ago

(Sorry for embarrassingly late replies, finally got a chance to get back to this project.)

Originally the reason for parsing enforcing just one-line summaries in C++ code and expecting detailed docs separately was to keep binary sizes down, but one and half year later I don't really care that much anymore. In my case I'll still keep large docstrings outside of the binary, others can do whatever they please. The secondary reason was that it was less likely to accidentally parse something inside a large docstring as a label of the next overload.

I reused an existing test instead of creating a new one in 63baae238730bb81b6ab4b9cd8580ade4fe01e95, merged your code as 1c9d4bb1e60fa99fdbec0dc1ab2832bf901f2b04... and then tried to break the existing parser in d3003a7cb7b546a3b2d610538a70a21046995855, which didn't really go well, basically dropping half of one docstring and adding bogus overloads. With ea0404cefaa071f068bdfa1a99abd62a3fb45a47 the robustness should be a bit better, hopefully good enough to not caught fire with common code :D