Skip to content

Fix static doc viewing in IDEs - #14195

Draft
larsoner wants to merge 5 commits into
mne-tools:mainfrom
larsoner:static-docs
Draft

Fix static doc viewing in IDEs#14195
larsoner wants to merge 5 commits into
mne-tools:mainfrom
larsoner:static-docs

Conversation

@larsoner

Copy link
Copy Markdown
Member

The goals of this PR are to eventually:

  1. Make it so that docstrings are rendered properly in IDEs by filling out all of them
  2. Keep docdict as the source of truth for multiple docstrings (good for blame, and existing workflows)
  3. Use a pre-commit hook to ensure docstrings don't drift -- if docdict is modified, update all matches (preserve old dev behavior); but also add a new one: if a single matching docstring is modified, modify docdict and all others (no longer have to open docs.py to edit a shared docstring, can edit inplace and have it propagate). # noqa: E501s are added/removed as needed (e.g., if the docdict entry is unindented and runs to 87 char, the indented version will need the noqa line).
  4. Preserve exising fill_doc/verbose/copy_*_to_* as these are used in MNE-BIDS and MNE-Connectivity (and low cost to keep here)

The diff looks scary, but of the ~1800 lines added only ~700 are the hook machinery, the rest is tests plus filled-in-docstring etc. This PR only implements these changes for a representative subset of docstrings that hopefully captures all of our fill_doc/verbose use cases. Assuming we're happy with the results, we can merge this, then I'll open a second PR that changes all docdict'ed docstrings to use this method (so that we can .git-blame-revs-ignore it after it merges).

These changes require some doc parsing logic, but it's not too bad. If we require that all these entries start on a given line at a given indentation level and don't decrease that level, it's doable. (There are some cases that are tough to disambiguate in the propagate-back-to-docdict case, and if it can't, then it will just raise an error and not try, similar to other pre-commit hooks when they cannot automatically fix things.)

Iterated multiple times through with Claude Fable 5. Changes understood by me. I plan to review more carefully in the coming days but wanted to get a WIP PR going in the meantime.

First part of two-part approach to #8218

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant