Thank you very much for this contribution!

But I can't merge the json5 part of the PR - in my opinion, this dependency significantly increases the complexity and the code base size and it is not a sustainable approach in the long term.

I would appreciate it if you could split it into smaller parts. I can also still try to merge this PR piecewise (not sure how to do it yet) when I have a relatively free evening.

Aside from the json5 dependency (and updating all of the pregenerated syntax grammars) this is already a very small patch. Four changed files, excluding the automated parts.

I agree that the dependency is very unfortunate. On the other hand, it might be better than writing a bespoke or in situ parser! I used git subrepo so that maintaining it is trivial. And it exists in its own commit, making it a simple matter to revert.

The other other option is using a SublimeText/PackageControl dependency. Since there are no json5-compatible parsers currently available as a PackageControl dependency (and I don't want to maintain one myself) vendoring was the least disruptive option.

It comes with another downside, though, and that is mentioned in the commit comment that uses it: The dependency is inadequate because it does not preserve comments. I just found https://pypi.org/project/json-five/ which could fix that problem. But a decision still needs to be made between either vendoring it or publishing a dependency on PackageControl.

I think I've enumerated all three options available for fixing #39 and related problems described in the b11ea9e commit comment. Using a PackageControl dependency will certainly look the smallest from the PR perspective. I'm unfamiliar with how it all works, only noting that I came across the linked documentation that describes the process. (Seems like kind of a hack, to me. But if it's the best way to depend on non-trivial code, maybe it's worth the effort?)

What is JSON5 needed for? Is there something that ST's settings.get doesn't work for?

I cherry-picked Fix CSV file extensions and syntax scopes and published a new release: https://github.com/mechatroner/sublime_rainbow_csv/releases/tag/2.10.0. Thanks again for contributing your time to work on this and other issues. We need to find a way to adjust Fix custom color scheme CL to avoid external dependencies. Perhaps settings.get proposed by @michaelblyons would do the trick.

What is JSON5 needed for? Is there something that ST's settings.get doesn't work for?

My understanding is that the settings API doesn’t give you a way to specify which file you are manipulating. (If I’m wrong, it would be a great improvement to remove the dependency!)

My understanding is that the settings API doesn’t give you a way to specify which file you are manipulating.

That is kind of correct. The API only accepts a basename and stores any modifications you do inside a corresponding file in the User package.

That said, that's exactly what the code is doing anyway:

https://github.com/parasyte/sublime_rainbow_csv/blob/b11ea9e8fdb46cc5ce3f026f01e9cbbc5fd01e24/main.py#L427

And, even that aside, I don't see why you couldn't just use the built-in json library to write to the file because, at least as far as I can see, the json5 package doesn't mention anything about preserving existing comments or style via a roundtrip parser (like ruamel.yaml).

I understand that the path is easy to construct, but it's unclear how the settings API is supposed to use it, if it can at all.

The json5 package does not preserve comments (one of the limitations that I documented) but the json-five package does. The json package that ships with Python is not adequate because it cannot parse comments or trailing commas, both of which are common in the Sublime settings files.

If this just concerns parsing, you can use sublime.decode_value.

Still, I'd like to understand why you couldn't use ST's settings API to modify settings. Perhaps there is a misunderstanding here. The general usage would be as follows:

syntax_settings = sublime.load_settings(syntax_file_basename)
syntax_settings.set('color_scheme', COLOR_SCHEME_FILE)
sublime.save_settings(syntax_file_basename)

The answer is that I'm just unfamiliar with the API. If those three lines work, then that's the obvious solution.

And if it is that simple, why was the original code overwriting the settings with a hardcoded string? When I had trouble deciphering the documentation (why is the returned Syntax object completely disconnected and unreferenced by the sublime.save_settings() call?) I assumed that the reason for not using it in the first place was because it wasn't fit for purpose.

I cannot answer this question since I was mainly made aware of this PR via a question on discord, but since the API usage I mentioned hasn't changed since at least ST2 days, I can only assume it was either because there was a weird edge case that we're not thinking of here or because the option was simply not considered (perhaps also due to unfamiliarity with the API).