Skip to content

"unknown-token" is overloaded #695

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
danielshahaf opened this issue Mar 15, 2020 · 3 comments
Open

"unknown-token" is overloaded #695

danielshahaf opened this issue Mar 15, 2020 · 3 comments

Comments

@danielshahaf
Copy link
Member

danielshahaf commented Mar 15, 2020

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?

danielshahaf added a commit that referenced this issue Mar 15, 2020
Before this commit, the command word was highlighted as "unknown-token"
not because alias loops are invalid, as a comment incorrectly claimed,
but because the command word «a» resolved to a «b» that was ineligible
for being expanded as an alias, and there was no function/builtin/etc.
called "b".

Add a function "b" to demonstrate that alias loops are valid.  I've also
filed issue #695 about the overloading of "unknown-token".
@phy1729
Copy link
Member

phy1729 commented Mar 15, 2020

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
Copy link
Member Author

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

@danielshahaf
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants