docs: Auto generate command list

[sudormrfbin]

Adds a crate binary helix-docs which generates automatic documentation for typable commands (and other things in the future). The current method simply imports helix-term and iterates through every command and generates a markdown string which is written to a file in book/src/generated/ and then included in the book output. I didn't pull in any crates for programatically generating markdown and went with simple string interpolation since it satisfies our needs for now.

Generate docs with:

cargo xtask docgen

I'm not sure how to integrate this with the CI, which would be able to automate the generation itsef.

[archseer]

How about using cargo xtask maybe? https://github.com/matklad/cargo-xtask

[pickfire]

I do think this should be auto-generated, especially when contributors and even the maintainers sometime miss it. We could set a check to see if it's the latest in CI.

[sudormrfbin]

How about using cargo xtask maybe? matklad/cargo-xtask

That seems like a good idea, I'll adopt it for the PR. We could also add some tasks for compiling and cleaning tree-sitter grammars, though that seems more appropriate for a Makefile since it's mostly shell commands. I think xtask for Rust based automation and a Makefile for other tasks is a good balance.

[sudormrfbin]

Typable commands and language support can be auto generated now, all that's left is to find a way to integrate with the CI:

[sudormrfbin]

I have added an action to auto commit documentation changes using https://github.com/stefanzweifel/git-auto-commit-action, but due to limitations imposed by GitHub it cannot run on a PR and commit changes to the fork (it's doable but requires the contributor to jump through some hoops as explained here), and as such I have configured it to run on push to master which should be good enough.

[archseer]

I have configured it to run on push to master which should be good enough.

What about simply adding a CI lint that checks the docs are up to date or else suggesting to the contributor to re-run the command? I'm a bit wary of depending on 3rd party GitHub Actions, and auto-committing to master after each change could get really noisy.

[archseer]

Alternatively, rather than running the xtask on master, it could be ran during the book/ build.

[sudormrfbin]

I've changed it to a lint that runs alongside other checks. Also isn't the book build done only if there are changes to the doc files ? In this case we wouldn't know if there are changes until xtask is run.

[archseer]

Oh I mean, rather than generating the doc files ahead of time and commiting them to git, generate them at book/ build time.

[archseer]

Either option works for me

[sudormrfbin]

Rebased and reworded history 🎉 (I settled on lint since it seemed the easiest to get started with).