Add highlight group for ! and ? operators #79

rsaihe commented 2022年07月28日 01:39:12 +02:00 (Migrated from github.com)

There should be a special highlight group for the error set operator (!) and the optional operator (?). I propose the names zigErrorSet and zigOptional for these highlight groups.

Ideally it would be possible to have zigErrorSet not match the logical NOT operator (!), but I am not sure how such a thing might be implemented.

zigErrorSet and zigOptional should be linked to the (currently unused) zigSpecial highlight group.

Additionally, I feel it would also make sense to create a new highlight group zigDeref for the pointer dereference operator, which could perhaps also be linked to zigSpecial.

? and ! in particular are quite important to pay attention to, so I feel it makes sense to allow them to be specially highlighted to make them more obvious when reading code.

There should be a special highlight group for the error set operator (!) and the optional operator (?). I propose the names `zigErrorSet` and `zigOptional` for these highlight groups. Ideally it would be possible to have `zigErrorSet` not match the logical NOT operator (!), but I am not sure how such a thing might be implemented. `zigErrorSet` and `zigOptional` should be linked to the (currently unused) `zigSpecial` highlight group. Additionally, I feel it would also make sense to create a new highlight group `zigDeref` for the pointer dereference operator, which could perhaps also be linked to `zigSpecial`. ? and ! in particular are quite important to pay attention to, so I feel it makes sense to allow them to be specially highlighted to make them more obvious when reading code.

rsaihe commented 2022年08月16日 23:30:11 +02:00 (Migrated from github.com)

This is (partially) addressed in #80.

This is (partially) addressed in #80.

talcynon commented 2023年01月02日 22:14:15 +01:00 (Migrated from github.com)

For zigErrorSet:
I think there are two hurdles to getting this syntax rule to work...

1. You can't tell by looking at just !x whether it refers to an error set type or a logical-not.
2. Vim syntax rules shouldn't "feel around" for context. Processing should move from one rule to the next.

I've worked with rules like this before, and it's quite straight-forward to get things working correctly. For a syntax as sparse as Zig's, it may be even easier.

Here's a screenshot of my first update to the rules (based on the changes in #80):

image

The syntax rules require knowing the sequence of tokens to test. In this case, fn may be followed by a contained function name, followed by a contained parameter list, followed by a type.

Like so:

" XXX Other zigType rules listed elsewhere.
" TODO Handle explicit error set type before the !.
syn match zigType "[!]\?[A-Za-z_][A-Za-z0-9_]*" contained
" FUNCTIONS {{{2
syn keyword zigKeyword fn skipwhite nextgroup=zigFunctionName
syn match zigFunctionName "[A-Za-z_][A-Za-z0-9_]*" contained skipwhite nextgroup=zigFunctionParams
syn region zigFunctionParams start="(" end=")" contained contains=TOP skipwhite nextgroup=zigType

The secondary, contextual rules are contained, meaning they are only considered/tested when explicitly referenced by another rule. (In this case, that means zigFunctionParams is only tested after zigFunctionName is matched, etc.) No need for feeling around, and much less risk of ambiguous rules relying on syntax declaration order rather than actual meaning of the text.

nextgroup provides a hint about the next rule to match. If it doesn't match the following name, life goes on. Here, I remove the !u8 from main. Vim couldn't match the zigType rule there, so it just carries on testing the other rules.

image

Bonus for this approach: free highlighting of smaller syntax elements, like function names in function declarations. :hi link zigFunctionName String produces the following:

image

If you're interested in doing something like this and want some help writing/testing/debugging, let me know. 😊

For `zigErrorSet`: I think there are two hurdles to getting this syntax rule to work... 1) You can't tell by looking at *just* `!x` whether it refers to an error set type or a logical-not. 2) Vim syntax rules shouldn't "feel around" for context. Processing should move from one rule to the next. I've worked with rules like this before, and it's quite straight-forward to get things working correctly. For a syntax as sparse as Zig's, it may be even easier. Here's a screenshot of my first update to the rules (based on the changes in #80):  The syntax rules require knowing the sequence of tokens to test. In this case, `fn` may be followed by a `contained` function name, followed by a `contained` parameter list, followed by a type. Like so: ```vim " XXX Other zigType rules listed elsewhere. " TODO Handle explicit error set type before the !. syn match zigType "[!]\?[A-Za-z_][A-Za-z0-9_]*" contained " FUNCTIONS {{{2 syn keyword zigKeyword fn skipwhite nextgroup=zigFunctionName syn match zigFunctionName "[A-Za-z_][A-Za-z0-9_]*" contained skipwhite nextgroup=zigFunctionParams syn region zigFunctionParams start="(" end=")" contained contains=TOP skipwhite nextgroup=zigType ``` The secondary, contextual rules are `contained`, meaning they are only considered/tested when explicitly referenced by another rule. (In this case, that means `zigFunctionParams` is only tested after `zigFunctionName` is matched, etc.) No need for feeling around, and much less risk of ambiguous rules relying on syntax declaration order rather than actual meaning of the text. `nextgroup` provides a hint about the next rule to match. If it doesn't match the following name, life goes on. Here, I remove the `!u8` from `main`. Vim couldn't match the `zigType` rule there, so it just carries on testing the other rules.  Bonus for this approach: free highlighting of smaller syntax elements, like function names in function declarations. `:hi link zigFunctionName String` produces the following:  If you're interested in doing something like this and want some help writing/testing/debugging, let me know. 😊