fix bytecodealliance#35

This commit separates the syntax highlighting rules for `result` types with angle brackets (`result<...>`) and `result` types without type parameters.

Previously, both types were handled in a single rule, `meta.result.ty.wit`, which ended at a newline (technically "after"), comma, or closing bracket.
However, if a `result` type appeared as a parameter, the scope wouldn't end until one of these conditions was met.
(As observed, the scope didn’t end even when a newline was encountered, likely because it was captured by other rules, though...).

This change simplifies the `meta.result.ty.wit` scope by splitting the handling of `result<...>` and `result`.
Now, `result<...>` is handled similarly to `list<...>` and `tuple<...>`, while `result` without `<...>` is handled by `result-base`, which marks the `result` keyword as `entity.name.type.result.wit`.

As a consequence of this change, line comments on `result<xxx> // comment` will no longer be ignored. However, this is a known issue for other types as well.

fix bytecodealliance#35

This commit separates the syntax highlighting rules for `result` types with angle brackets (`result<...>`) and `result` types without type parameters.

Previously, both types were handled in a single rule, `meta.result.ty.wit`, which ended at a newline (technically "after"), comma, or closing bracket.
However, if a `result` type appeared as a parameter, the scope wouldn't end until one of these conditions was met.
(As observed, the scope didn’t end even when a newline was encountered, likely because it was captured by other rules, though...).

This change simplifies the `meta.result.ty.wit` scope by splitting the handling of `result<...>` and `result`.
Now, `result<...>` is handled similarly to `list<...>` and `tuple<...>`, while `result` without `<...>` is handled by `result-base`, which marks the `result` keyword as `entity.name.type.result.wit`.

As a consequence of this change, line comments on `result<xxx> // comment` will no longer be ignored. However, this is a known issue for other types as well.

fix bytecodealliance#35

This commit separates the syntax highlighting rules for `result` types with angle brackets (`result<...>`) and `result` types without type parameters.

Previously, both types were handled in a single rule, `meta.result.ty.wit`, which ended at a newline (technically "after"), comma, or closing bracket.
However, if a `result` type appeared as a parameter, the scope wouldn't end until one of these conditions was met.
(As observed, the scope didn’t end even when a newline was encountered, likely because it was captured by other rules, though...).

This change simplifies the `meta.result.ty.wit` scope by splitting the handling of `result<...>` and `result`.
Now, `result<...>` is handled similarly to `list<...>` and `tuple<...>`, while `result` without `<...>` is handled by `result-base`, which marks the `result` keyword as `entity.name.type.result.wit`.

As a consequence of this change, line comments on `result<xxx> // comment` will no longer be ignored. However, this is a known issue for other types as well.