[Haskell] Add Cabal Syntax

[deathaxe]

This PR proposes to add basic support for Cabal Configuration Files.

It appears Cabal to be the default package manager used by Haskell. It might therefore make sense to have basic support for Cabal
configuration files available next to Haskell syntax itself.

It is known not to be intended to add further rarely used syntax definitions to the repo in general. We might also add it as dedicated package to Package Control then.

[FichteFoll]

I just took a brief look as I had some time to kill. I've never used cabal before, and I can't comment on its usage in the Haskell ecosystem, but generally this looks fine to me.

[jrappen]

Over all this seems fine.

---

Was there a reason, meta.toc-list.* wasn't added to the symbol list? Also symbol tests? It's already all set up in the syntax and the test with the scopes.

[deathaxe]

Sections are displayed in Symbol List via entity.name.section.

Symbol tests have not been prominent and important enough.

[jwortmann]

Not specific to only this PR, but maybe we can unify the scope names used for punctuations within mappings?

What's currently used in various syntaxes (on master):

Syntax	key-value separator, e.g. : or =	entry separator, e.g. , or ;	uses meta.mapping
JSON	punctuation.separator.mapping.key-value	punctuation.separator.mapping.pair	✔️
YAML	punctuation.separator.key-value.mapping	-	❌
CSS	punctuation.separator.key-value	punctuation.terminator.rule	❌
Python (dict)	punctuation.separator.mapping.key-value	punctuation.separator.mapping	✔️
JavaScript (object literal)	punctuation.separator.key-value	punctuation.separator.comma	✔️
Lua (table)*	punctuation.separator.key-value	punctuation.separator.field	✔️
BibTeX	punctuation.separator.key-value	punctuation.separator.mapping.pair	✔️
Git config	keyword.operator.assignment	-	✔️
Cabal (this PR)	punctuation.separator.mapping.key-value	-	✔️

*not sure whether the Lua tables are directly comparable to the other mappings listed here

Any more that I have forgotten?
The mapping part in the scope used by a few synaxes seems to be redundant to me, because it is already given by meta.mapping, and color schemes could hence use meta.mapping punctuation.separator to target separators only within mappings. So how about to establish the conventions punctuation.separator.key-value and maybe punctuation.separator.pair?

[jrappen]

• There are a few other separators, so keeping *.mapping.* makes sense. Compare:
  https://github.com/SublimeText/PackageDev/blob/24d53896ff1532b057df73f41ad9e6ca8578c9f3/plugins/lib/scope_data/data.py#L190-L255
• I guess deathaxe just forgot it in his CSS rewrite. The YAML rewrite was quite a while back.
• I don't understand why we should skip a level for mapping, but keep it for the others (listed two points above here).

[jwortmann]

My intention is mostly to have unified scope names between syntaxes, so as long as it is used consistenty, I could live with the .mapping. part in the scope.

It's just that it is redundant due to the meta.mapping, and from the table above only two syntaxes (JSON & Python) use it, while key-value as the third level is used in 5 syntaxes (YAML, CSS, JavaScript, Lua, BibTeX). Actually I forgot HTML which also uses punctuation.separator.key-value for the = in tag attributes, so it's 6 syntaxes already. The scope ordering from the provided link doesn't seem fully comprehensive about what is used in this repository for punctuation.separator scopes, for example it misses punctuation.separator.comma which is also extensively used. I think for the other separator scopes there is no comparable meta scope, i.e. they don't have this redundancy. What exactly do you mean with "skip a level"?

For CSS, I can understand that it wasn't changed to meta.mapping, because the CSS scopes are somewhat unique and a lot of color schemes depend on them. This can't be carelessly converted without ensuring that backward compatibility is provided.

[deathaxe]

@jwortmann Please open a new issue for that discussion. That's really off topic here!

[deathaxe]

Here hs-source-dirs, build-depends, exposed-modules, other-modules and default-language are marked as definitions.

They are tagged meta.mapping.key entity.name.tag as any other top-level key-value pair. What's wrong about it?

[BenjaminSchaaf]

They are tagged meta.mapping.key entity.name.tag as any other top-level key-value pair. What's wrong about it?

By marked as definitions I mean they show up in goto-symbol, which I'm not sure is desirable considering the amount of duplicates.

[deathaxe]

I found a possibility to quickly navigate to those keys useful. If not, we can remove Cabal Symbol List

[BenjaminSchaaf]

The top-level entities should certainly be there, but non-top level stuff like "build-depends" doesn't seem useful. fwiw I'm not a user of this so maybe it makes sense to include those for a reason I'm not aware of.

[deathaxe]

There's no difference between top- and none-top-level keys, logically. Former ones just describe globals, while latter ones single assets or build targets. The meaning however is the same within their scope.

Syntax currently doesn't distinguish them and I am uncertain I want to add this level of complexity. So it's all or nothing.

[deathaxe]

source-repository-package is highlighted as regular text.

Only known tokens are supported as section headers (see section_tags variable) to avoid false positives. We could add this special keyword. If we are in doupt about others being unknown a more general pattern was to be used.

[deathaxe]

Presumably * has semantic meaning here; probably good to highlight it.

allow-newer seems to be part of https://cabal.readthedocs.io/en/3.8/cabal-project.html#solver-configuration-options

Solver syntax is not implemented, currently. Seems to be related with dependencies however.

[deathaxe]

All review comments are addressed.

[jrappen]

This seems fine, though seeing support for some v3.8 features in a syntax written for v3.4 was unexpected.

[deathaxe]

v3.4 was the up-to-date spec version at the time of writing cabal syntax. It doesn't mean it shouldn't support newer features.

[moodmosaic]

Great work! @deathaxe, was this released with BUILD 4142?

[jrappen]

The pull request is still open.

deathaxe has addressed all comments by SublimeHQ two months ago already.

@FichteFoll hasn't re-reviewed yet, and the PR still needs another review to be merged into the master branch.

[FichteFoll]

Since perfect is the arch-enemy of good, I'll approve of this PR in its current state. If any of these are things you want to work on, @deathaxe, be my guest, but I wouldn't block a merge on them.

1. There are still debates to be had regarding the key scope, but since we don't have a clear direction on this yet, this particular PR is not the place to discuss and decide on it.

2. Similarly, some key-value pairs definititely look like the value should be an unquoted string (much like in YAML) where they currently only have meta.mapping.value. Again, not something I'm hung up upon.

3. The other thing I noticed was stacking of meta.function-call, but also not a requirement for me for such a rarely used syntax.

[deathaxe]

to 1.) I'd be happy with any suitable scope of those keys as we don't even have categorized this kind of files. We could treate them as mappings / structured key-value pairs and use json/yaml scopes. It wouldn't be the worst choise, but there's no real need to distinguish data types of keys like in YAML. Scoping it string therefore feels a little odd as everthing in those files is a string and we'd have the same kind of discussions about "everything is string scoped" as we had/have for JSON/YAML.

As Cabal is basically Haskell's Makefile the question arises, how to scope .PHONY: and friends in Makefile later on. They now are scoped function.

... but well, that's probably a separate topic.

to 2.) Same here. We could scope them string. What I had in mind is HTML and Markdown, which both don't scope plain text special as well.

to 3.) Do you have any examples? Or is it meta.function-call.arguments meta.group which you are concerned about?

[FichteFoll]

Re 3.: No, I don't. Not sure what I was seeing there exactly but I certainly don't see it anymore.

[michaelblyons]

Since perfect is the arch-enemy of good, I'll approve of this PR in its current state.

➕

[deathaxe]

Suggestions for better scopes are always wellcome.