"unknown-token" is overloaded

[danielshahaf]

Highlighting all errors the same way makes sense from a UI perspective (cough #691 cough), but it makes the tests weaker: when a test checks that an alias is highlighted as unknown-token, it can't easily check whether that's due to a syntax error (as in alias x='() ]]') or due to, say, a command word not being an existing alias/function/etc. (as fixed in 9931990b92a276c6ec69cdf6af9f9f3b65603cd1).

How about adding some new styles for more specific errors — e.g., unknown-token-not-a-command-name, unknown-token-parse-error, etc — that will be highlighted the same way by default, but will make the tests more specific?

[phy1729]

I thought there was already an issue for this, but perhaps all the discussion was on IRC. I think we need at least four new styles: parse-error for when zsh will error before attempting to run anything, unknown-arg0 for command not found, command-error for things like [ -n foo; or sudo;, and lint-warning for things like #691 and ; ;. All three (or more) can fallback to unknown-token to maintain backwards compat.

Unopposed to further splitting past those so that each error style is distinct.

[danielshahaf]

Sounds good to me. Labelled "good first issue".

[danielshahaf]

Triage: incomplete, new feature (as opposed to bugfix), but referenced by many other issues so presumed a popular feature request, 0.8.0 has plenty of content already merged, redrawhook is the next priority: remilestone 0.9.0.