alex VS markdownlint

Catch insensitive, inconsiderate writing with tools like alex

This story has been a motivating principle behind my life for a long time, and therefore, whenever I've worked on docs, I've thought about how I could ensure that exclusionary words, even unintentionally, did not make their way into the final copy. During my time at Nexmo, a communications API company, I introduced Alex, an NPM package that helps you identify potentially exclusionary language in your writing, into the CI/CD pipeline for the documentation.

As a philosophy student: Zotero for reference management, the Better BibTeX plugin to auto-generate a .bib file, and two language servers for diagnostics: LTeX for grammar- and spellchecking, and alex for style and sensitivity checking.

When using it as a lib you can pass a markdown string (https://github.com/get-alex/alex#markdownvalue-config) or raw text string (https://github.com/get-alex/alex#textvalue-config). This will return an object that should contain everything you need to perform a naive replacement.

alex is a lovely command-line tool that takes in text or markdown files and, using retext-equality and retext-profanities, highlights suggestions for improvement. alex checks for gendered work titles, gendered proverbs, ableist language, condescending or intolerant language, profanities, and much more.

Heck, he could even go so far and start using GitHub's automation system (Actions) to run some check on his writing. (Maybe something like alexjs)

I've been a part of several code clean-ups where giant code bases needed to be changed to considerate language. I've never once encountered a bad actor when the actual work got underway. Part of being a programmer is to question the reasoning behind large changes but any programmer worth their salt understands the big picture if you can clearly explain it. I wouldn't read too much into the actions of a few people in any programming subreddit who are opposed to pronouns. Those people will always exist. I'm certain that the vast majority of programmers in those subs are either strongly in favour of gendered pronouns or are apathetic toward it. To drive home the point, the fight for considerate language has been driven by developers themselves. All these wonderful tools such as alex.js or even org level changes inside big companies are part of it.

alex

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.