Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google style docstring issues #2

Closed
7 tasks
leonhard-s opened this issue Oct 29, 2020 · 1 comment
Closed
7 tasks

Google style docstring issues #2

leonhard-s opened this issue Oct 29, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@leonhard-s
Copy link
Owner

leonhard-s commented Oct 29, 2020

The following is a collection of issues with Google style docstrings compiled after inspection of the Napoleon plugin's example code.


  • Literal raw blocks defined with two trailing colons are busted again. They used to work, so this is likely just a typo or omission.

  • The bold formatting used for section headings breaks when the previous code block indented by more than two levels just before.

    This is likely due to the previous indented block not finishing properly, which results in the next section's header being consumed by the previous block. Inserting any character to make the indentation a gapless "staircase" again fixes it.

  • Module-level variable and attribute annotations currently do not have any type highlighting.

  • Emphasis control characters are currently applied within code blocks, as well as if the corresponding asterisk is escaped.

  • Parameter highlighting breaks if type information is provided: param1 (int): The first parameter.

    Note that it is also permitted to use cross-references for these type hints: param2 (:obj:`str`, optional): The second parameter

  • Magic method names are treated as links and underlined - this is fine as long as this can be escaped, which is not a thing yet (see above).

  • Currently, single words ending in a colon that happen to fold into a new line are treated as headings. This can likely be addressed by requiring a blank line lookbehind in the corresponding RegEx.

@leonhard-s leonhard-s added the enhancement New feature or request label Oct 29, 2020
@leonhard-s
Copy link
Owner Author

Discarding this issue for the same reason as #2: Highlighting already readable code does not improve the experience in any meaningful way, so the scope has been reduced to focus on the harder-to-read statements like roles, directives and cross-references.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant