markdownlint VS walkdir

There are more linting tools that I won't go into deeply, but you can integrate them with lint-staged. For example, you can lint your CSS content with Stylelint, or even lint your README files with markdownlint, etc.

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.

https://github.com/BurntSushi/walkdir for discovering markdown files

The API looks really nice! What is your vision for the project? How is it going to compare to (walkdir)[https://github.com/BurntSushi/walkdir] performance and feature-wise?

> I believe that GNU find is slow because it is specifically written to allow arbitrary filesystem depth as opposed to "open file descriptor limit-limited depth".

I haven't benchmarked find specifically, but I believe the most common Rust library for the purpose, walkdir[1], also allows arbitrary file system recursion depth, and is extremely fast. It was fairly close to some "naive" limited depth code I wrote in C for the same purpose.

I'd be curious to see benchmarks of whether this actually makes a difference.

[1] https://github.com/BurntSushi/walkdir

It relies pretty heavily on the walkdir library from burntsushi so kudos to them!

Although, I don't think FileType is the only problem. There's also Metadata, which I also had to re-roll: https://github.com/BurntSushi/walkdir/blob/1d7293a5a1ef548ce587a0b08abce5f21571a100/src/os/unix/stat.rs