Skip to content

"unknown-token" is overloaded #695

@danielshahaf

Description

@danielshahaf
Member

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 9931990).

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?

Activity

phy1729

phy1729 commented on Mar 15, 2020

@phy1729
Member

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

danielshahaf commented on Mar 15, 2020

@danielshahaf
MemberAuthor

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

added this to the 0.8.0 milestone on Mar 16, 2020

13 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @phy1729@danielshahaf

        Issue actions

          "unknown-token" is overloaded · Issue #695 · zsh-users/zsh-syntax-highlighting