Automattic/harper

Describe the bug If you run harper-cli lint over multiple directories (possibly only multiple files?), different dirs or files can be processed in parallel on different threads, but they print to stdout at the same time, resulting in mangled output. To Reproduce Steps to reproduce the behavior: cargo run --release --manifest-path harper/Cargo.toml -p harper-cli -- lint --quiet --format default --only PassiveVoice ~/harper/harper-core/tests/text |& less -R Note that in this case I was testing a new linter from a new PR. Expected behaviour A clear and concise description of what you expected to happen. Screenshots I'm guessing there's probably a quick fix and a proper fix. The quick fix is to put the parallel processing behind a switch. The proper fix would be to figure out how to do the linting in parallel but without each thread's output stomping on the output of other threads. Maybe an intermediate fix would be having an output mode that does the linting in parallel but without the l

Some websites are goldmines of real-world English mistakes: Hacker News, Reddit, Medium. It would be great if harper-cli lint could accept a URL (or multiple since it works with multiple inputs already) I don't think Harper yet works with HTML - maybe I'm wrong? Whether we do or not, it might still work better to first convert to plain text or to Markdown. It would probably also be best either way to trim all the boilerplate from pages first and leave only the main content. Ages ago there was a tool called "Boilerpipe" in Java for this. I'm sure there are much better newer tools these days. LLMs probably use them so there's probably more to choose from than ever. (This is probably a good issue to work on with the aid of an AI coding agent. If you pursue this, please use our official PR template and pay attention to our AI coding disclosure rules etc.)

My PR #4211 passes all cargo test for rust but keeps failing in the Obsidian integration. I'm not doing to well trying to understand the error messages so I'm not positive but I'm tending toward thinking that when the OneOfMany config type was introduced that support for it might not have been added as needed to the Obsidian plugin. Both CoPilot here on GitHub and the free AI agent in my editor (Devin) seem not to have been able to figure out why there are failures in the Obsidian integration. Because the Obsidian plugin uses harper.js the problem could be there or in the WASM?

I was planning to add more linters that handle verbs with multiple past participles like "hanged" vs "hung", "dived" vs "dove", "pleaded" vs "pled", and started looking at how I did the "sneaked" vs "snuck" one. This led me to discover that both "sneaked" and "snuck" are now flagged: Digging further in #4209 I discovered that this is due to the change in linter configuration from lint_group/mod.rs to default_configuration.json and the fact that there is a OneOfMany type of linter preference that was introduced. I've looked manually, Googled in both site:github.com/Automattic/harper and site:writewithharper.com, and asked the built-in coding agent in the Devin fork of VS Code if it can find documentation for OneOfMany and we can't find any. We could still be missing something but it seems to be undocumented and so far not used for any linter. I have not dug into whether anything needs to be documented downstream for harper.js or any of the integrations.

This is even more important than it already was due to the rise of AI-generated rules, which are still terrible at including real-world examples rather than contrived examples made on assumptions that are too short-sighted to avoid false positives. (Humans also do this, but humans that become Harper contributors can learn how to overcome this. So far AIs can't.) An ideal tool would use existing corpora and XML/database dumps, feeds, and APIs of coding and tech-related sites. I believe Stack Overflow still publishes database dumps, or at least that older ones are still available. Neither Slashdot nor Hacker News publish dumps but that do seem to have real-time feeds. For GitHub we might be able to leverage their search API. Such a tool would probably not belong in the Harper repo, but as one or more separate projects. But ideally may be installed on a server that authorized Harper devs/contributors would be able to access for reasons of storage space, API limits, etc.