A few suggestions

[sandstrom]

A few suggestions in no particular order:

• Difficult to use on code comments because it will:
  • Nag about no upper-case on short code comments such as # optimized for speed; it should have some mechanism to either easily disable capitalization and punctuation checks for inline code comments, or only do it for longer passages of text, e.g. >15 words.
  • Will complain about a ton of technical terms it doesn't understand.
  • Doesn't understand backticks in comments, for example # This is tied to the ``UserStats`` model. will complain about UserStats not being a word.
• Add a global config file we can add to the repo root, for example /harper-conf.yml with all the ignore rules etc. Also make the CLI accept the config via a CLI flag, but also search for it if none is passed.
• There is no grouping of linting rules. It would make sense to try to group them. For example 'idiomatic/ChangesOfTack' and 'hyphenate/RapidFire'.
• It's likely not a good idea that every single word fix is a rule. Instead of having 'ChockFull' and 'RapidFire', why not just have a single general hyphenate rule?

[hippietrail]

Hey thanks for the feedback!

• For nagging about uppercase in short code comments Harper currently has no was to know what "kind of area" it's in. It's either skipping over code or it's in lintable content such as comments in a source code file. It would be great if it had more awareness of what it's in so that settings can be set only in certain kinds of areas. This is related to how I would like it to be able to lint string literals as well as comments but it would probably want to flag different subsets of lints in each.

• For missing technical words you can send us a PR of file a GitHub issue if they're widely used and likely to remain widely used, or put them in the user dictionary if not.

• The problems with backticks and single quotes are different I believe. I think backticks kind of mark something as code within the comments. For single quotes they are ambiguous because the same ascii ' is used for apostrophes. Would be tricky to come up with a good solution, but one is needed.

• There is a certain amount of logic for grouping rules. I wish to use it for some of my lints for related singular and plurals or present and past tense but I haven't learned that yet. Even so I tend to think that more kinds of grouping might be warranted. ChangesOfTack is one of my linters that I want to support that for. I tried a few weeks ago but I should try again.

• ChockFull is also one of my lints. It primarily looks for bigger errors where it's commonly written with wrong words because people have misheard the idiom, such as "choke full". But it wasn't much extra effort to get it to also fix missing hyphens. But you're right that it should be more general. There are a few rules in there for checking hyphenation on certain words but I think it would be easy to augment the linter that joins pairs of words that should be single words to do the same for ones that should be hyphenated. The main reason it's not already there is because it needs hyphenated terms in the dictionary and the dictionary originally only supported single-word terms.

[sandstrom]

The problems with backticks and single quotes are different I believe.

I agree, my comment is really mostly about backticks. Will update.

[mcecode]

• Add a global config file we can add to the repo root, for example /harper-conf.yml with all the ignore rules etc. Also make the CLI accept the config via a CLI flag, but also search for it if none is passed.

There's actually an issue related to this (#147), but it just hasn't had much traction to be implemented. Maybe you can chime in and add your ideas there also.

[hippietrail]

• There is no grouping of linting rules. It would make sense to try to group them. For example 'idiomatic/ChangesOfTack' and 'hyphenate/RapidFire'.

I've got a PR coming that addresses grouping of inflections etc. like change of tack & changes of tack. I've wanted to do it for ages so this was enough to nudge me: #1529