Consistency in naming makes reading and memory retrieval much, much easier. Conversely, changing rules and mixing conventions are very confusing and significantly increase cognitive load. Follow language, company, and project conventions for names, even if you don't like them.
Paul Backus pbackus
Don't do the crime, if you can't do the time.
-- Anthony Vincenzo "Tony" Baretta
Vim is an amazing text editor. I love it. Really, I wouldn't [organize][organize] a Vim advent calendar if I didn't. But, as amazing as it is, Vim is not for everyone. It can't solve all your problems, or be a TUI version of your favorite IDE, or make you a better programmer, or land you that dream job in the Bay Area. But Vim can help you be more mindful, focused, and efficient, as long as you approach it with the right mindset.
Don't get me wrong, I certainly welcome you to try Vim, but I'm not a proselyte. I don't thrive on newbies. I just want you to use the right tool for the job and not waste your—and anyone's—time on a fruitless quest.
This guide makes no assumptions on prior knowledge of Github Pages or Travis CI. You'll know which steps to skip (if the project uses Pages already, this will overwrite them). Assumed is you have a public D project on GitHub and you have documented its API with embedded ddoc comments. You should probably be aware of the known issues of ddox, which we use here.
For a project URL like https://github.com/<user>/<project>, the documentation will appear at https://<user>.github.io/<project>/.
The long story: https://docs.travis-ci.com/user/getting-started/, https://docs.travis-ci.com/user/languages/d/
The short story: