Better TextMate scopes for various language elements

[jayfoad]

language-apl seems to use the "wrong" TextMate scope for various APL language elements.

I apologise in advance that this issue is a mixture of things that just seem wrong to me, and things that actually affect github syntax colouring.

Diving right in:

• [X] Ordinary names like foo are storage.type.name.apl. This seems very odd and causes GitHub to colour them like e.g. type names in C, i.e. red, which is pretty distracting. Surely just variable.apl or variable.other.apl would be better?

• [x] System names like ⎕FOO are support.system.variable.apl; should perhaps be support.variable.system.apl because support.variable seems to be a well-known scope. Probably makes no difference in practice because although the GitHub CSS mentions support.variable it seems to treat it the same as just support.

• [x] entity.label.name.apl and entity.function.name.apl should be entity.name.label.apl / entity.name.function.apl because entity.name is a well-known documented scope. Probably doesn't affect GitHub syntax colouring.

• [x] Primitives like + and ⍨ are keyword.operator.\.apl. I can see that this follows the TextMate documentation, but I find it a bit unfortunate that they get coloured the same as "real" APL keywords like :If. What scope do other language grammars tend to use for symbolic operators?

• [x] In lambdas ⍺ ⍵ ⍺⍺ etc are variable.lambda..apl. Should perhaps be under variable.language, since they are like reserved words in the language. I think this would affect GitHub syntax colouring a little.

[Alhadis]

System names like ⎕FOO are support.system.variable.apl; should perhaps be support.variable.system.apl

The order in which scope-names appear is immaterial, meaning the two scope-lists above are effectively equivalent.

should be entity.name.label.apl / entity.name.function.apl because entity.name is a well-known documented scope

As above, the appearance of name in the scope-list chain wouldn't make a difference. ;)

but I find it a bit unfortunate that they get coloured the same as "real" APL keywords like :If. What scope do other language grammars tend to use for symbolic operators?

This, actually. They tend to use keyword.operator.arithmetic for things like + / * - and keyword.operator.logical.boolean for things like != or &&, etc. However, the keyword.operator scopes aren't strictly limited to symbolic forms - it's common to see true scoped as keyword.operator.boolean.logical.true, for example.

I think what complicates this issue most is that APL has a well-refined notion of what an "operator" is, whereas TextMate grammars have a less defined and broader interpretation. I recall this was a source of confusion for me early in the project as I deliberated between TextMate/APL semantics and naming conventions.

What do you think we should do?

[jayfoad]

The order in which scope-names appear is immaterial

Thanks. I didn't know that.

What do you think we should do?

I've looked at a few other languages. Java and Javascript use keyword.operator for their operators. C and Go leave them uncategorised.

My personal preference would be not to categorise APL primitives as any kind of keyword, just because I don't like seeing so much red on github.com, but I certainly won't try to insist. Is there anyone else who might have a reasonable view on this, or on the use of keyword.operator in general?

Maybe I should petition github-syntax-theme-generator to colour keyword.operators differently from all other keywords...?

[Alhadis]

Heh. Well even if you do now, there's no telling if they'll be worsened by sudden future changes when GitHub's designers settle on a modified colour scheme.

In other words, what looks great now mightn't look as great after a redesign impacts syntax highlighting...

[jayfoad]

OK. Well, since plenty of other language grammars are using keyword.operator for their operators, and it's documented as the correct thing to do, I hereby withdraw my complaint.

Thanks for the other fix!