[D] Make in a word operator

[ichordev]

Changes:

• Marked in as a word operator so that it can be highlighted as-such.

[jwortmann]

I wonder, would this stacking of keyword.operator.word keyword.operator.comparison (or other keyword.operator.* subscopes) serve as an accepted solution to #3694 in general?

I remember previous discussions leading to no solutions, and iirc keyword.operator.word was deemed to be an outdated scope which shouldn't be used anymore, because word doesn't carry any semantic meaning. So previous similar PRs were refused, e.g. #2089, #2090.

Also see #3694 (comment)

• stacking same kind of scopes (e.g. keyword) turned out to have unwanted implications in the past

[jfcherng]

I wonder, would this stacking of keyword.operator.word keyword.operator.comparison (or other keyword.operator.* subscopes) serve as an accepted solution to #3694 in general?

Agree shouldn't be stacked after I searched the current code base.
https://github.com/search?q=repo%3Asublimehq%2FPackages%20keyword.operator.word%20&type=code
None of them is stacked.

[ichordev]

I wonder, would this stacking of keyword.operator.word keyword.operator.comparison (or other keyword.operator.* subscopes) serve as an accepted solution to #3694 in general?

Agree shouldn't be stacked after I searched the current code base. https://github.com/search?q=repo%3Asublimehq%2FPackages%20keyword.operator.word%20&type=code None of them is stacked.

I'll change it to just use keyword.operator.word then?

[jfcherng]

I'll change it to just use keyword.operator.word then?

That will make this PR to more likely be merged.

[deathaxe]

Primarily expected issues with regards to possible over-use of stacked scopes is the limit of at most 64 stacked scopes per token. Each additional scope may increase risk to break syntax highlighting in deeply nested statements. Now that syntax based folding really requires each block to provide its own meta scope to make sure each bracket is scoped uniquely, chances may even grow further - theoretically. (D doesn't follow this guideline at all, though)

Using only keyword.operaotr.word in a syntax with mixed operator styles but scoping all operators keyword.operator.[logical|...] in a syntax which only uses word-like operators (e.g. Python), introduces the requirement for syntax-specific color scheme rules to ensure same highlighting. On the other hand we probably don't want to scope all keywords in e.g. python keyword.operator.word as we'd loose semantic meaning.

If at all - the initial (stacked) solution would probably be the only accepteble one without breaking backward compatibility and by ignoring chapter one's outlined issue. But someone should then apply that pattern to ALL syntaxes in this repo!

I however have a feeling this would require to also scope symbolic operators accordingly for consistency reasons, because it is odd to use 2 scopes for word-like operators but only 1 for symbolic ones.

Tbh, I wouldn't merge it until a conclusion for #3694 is found.