markdownlint VS docs

Some of Djot's features can be achieved by using markdownlint though: https://github.com/DavidAnson/markdownlint

markdownlint - A Node.js style checker and lint tool for Markdown/CommonMark files.

Improvements - The prefer-some-in-iteration rule will by default no longer flag iteration where a sub-attribute is used, like input[_].item - The use-in-operator rule has been extended to include more types of items, leading to better discovery of locations where in should be used - Remove replace directive in go.mod that made hard to integrate Regal as a library - The project now uses markdownlint to ensure consistent formatting of its documentation - The Go API now allows reading custom rules from an fs.FS filesystem

People are always looking for simple projects to learn Rust with, so here's one for anyone who's currently looking. Port markdownlint to Rust. Markdownlint is ~3.3k lines of JavaScript (including the lint implementation themselves!), so I reckon it's pretty doable.

The markdownlint VS Code extension is powered by the Node library of the same name. Its usage is quite similar to ESLint. It has a set of rules that can be configured, errors are highlighted, and you can automatically fix simple errors.

Markdown Lint

There are no compilers in the Flutter project that guarantee to find issues in README.md or CHANGELOG.md files. To remedy this, the Markdownlint plugin provides a set of guidelines to encourage Markdown file standards and uniformity. You can use this extension to check for problems locally and verify the content before publishing it live. Browse the user manual to learn more about rules.

I can recommend https://linode.com, their documentation is excellent https://www.linode.com/docs/ and ready made images also https://www.linode.com/docs/marketplace/

>In other words, let the machine do your thinking for you No, this was idiotic. A generator tool like Hugo doesn't "think" for you. it's a tool, used by a thinking person. Even if someone new to HTML publishing happens to adopt Hugo, they are going to learn things. By the sounds of it, it's likely they will learn things you have not. They will still learn about HTML and CSS. They may optionally learn about optimizing their HTML and CSS, if it matters for performance of their finished product. Not all sites are the same, after all. The output of Hugo is static HTML (and CSS, js if used, images and other supporting files). The input of Hugo is also static - a collection of HTML templates, CSS and, usually, Markdown text files as the primary content store. Creatively used, Hugo sites can appear as feature-rich as many database-driven sites and in a manner that you simply could not do armed with only an editor, unless your site is only a handful of pages. Any Hugo site can be configured to generate other representations of the site, too, automatically. You probably think that's nonsense, but then again you probably also do not publish a hand--crafted [Atom](https://spf13.com/index.xml) or RSS feed to go along with your hand-crafted HTML. Hand-crafted does not automatically mean better. Even the simplest Hugo site implementation typically makes use of categories or tags (or both) to help readers find other relevant content. Inserting a new page into an existing hierarchy of categories and/or tags is trivial. Edit a file; tag it. The navigation structure is rebuilt, in milliseconds, whether there are five pages or five hundred. [Steve Francia's site](https://spf13.com/) provides examples of these facets in use. With Hugo you can also produce large documentation sites/subsites, and even more importantly, maintain them. The [Let's Encrypt documentation site](https://letsencrypt.org/docs/) is a textbook case study. It's too bad the `vim` project DOES NOT use a tool like Hugo, because then its documentation would stand a chance of being current instead of: > The [VimDoc project](https://www.vim.org/docs.php) has links to various types of Vim documentation. The online, hyperlinked copy of the documentation is currently outdated. Send in the drones to edit. "Currently" has lasted a long time! Another example: [Linode's documentation site](https://www.linode.com/docs/) is generated by Hugo (according to the meta attribute inside, v0.83). You can see the source code for all their documentation, including the site theme and Hugo specifics, here https://github.com/linode/docs. Shocking, isn't it? A tool being used for productivity! You portray using a productivity tool like Hugo as being somehow lazy. That's ridiculous. It's a powerful tool that happens to scale from the simplest of use cases to the complex, and for every use case, makes it possible to produce far richer sites than is possible completely by hand. And all of that without a database or need for a runtime language on a server, or client. A generated Hugo site has no need for PHP includes or other helpers. It can run on the simplest HTTP server; it's just static content. It's a tool, like an editor is a tool, to make an author more productive.

Hugo has seen success with corporate customers, including 1Password, Linode Digital.gov, KeyCDN, and Let’s Encrypt, to name just a few. Bjørn Erik Pedersen took over as the lead maintainer in 2015 and continues to lead Hugo’s thriving community.

Besides the official Vale style guides Buildkite, Linode, and Write The Docs have rules online that you can copy into your repo or use as inspiration for your own rules.

- https://github.com/linode/docs