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

Write a "style checker" extension for sphinx #5

Open
benoitbryon opened this issue May 2, 2012 · 1 comment
Open

Write a "style checker" extension for sphinx #5

benoitbryon opened this issue May 2, 2012 · 1 comment

Comments

@benoitbryon
Copy link
Owner

Feature: validate documentation style
  In order to validate documentation against style guide conventions
  As a documentation writer
  I want to run scripts that give me feedback about style conventions

  Scenario: Get feedback on documentation build
    Given a Sphinx documentation
    And style_guide extension is installed and enabled
    When I run sphinx-build
    Then I get errors, warnings and notices related to style conventions.
@benoitbryon benoitbryon mentioned this issue May 2, 2012
@benoitbryon
Copy link
Owner Author

A question is: where should we plug RST syntax verification?

  • At http://sphinx.pocoo.org/ext/appapi.html#events, we see that candidate would be doctree-resolved event, because at this stage, we know that documents are valid RST files. If necessary to be plugged before, maybe doctree-read or source-read...
  • But, it seems that a doctree object doesn't contain the original sourcecode... It contains a reference to the RST document and line, but what about multiline RST constructs? It seems not so easy to get and analyse the original RST sourcecode. Additional parsing may be required.
  • docutils' RST parser is a state machine. It reads a document line per line and updates states and break conditions (a change in indentation is an example of break condition). Can we plug in to add information about RST markup during parsing? I don't know by now...

Example of useful information could be : for titles (sections), a "is_overlined" boolean and a "overline_char". So that we can easily compare it to best practices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant