I noticed that the preferences are written in json which is nice and easy to edit. However I think yaml would be a better choice because it relies on indentation which makes it easy to read like python syntax. I see json more of a transport protocol and yaml for human readable markup.
Thanks
To change it now would be a big change.
There is also nothing wrong with JSON and itās regarded as the most popular format for such things 
json is good but yaml is better (in this case). Isnāt your goal to be sublime?
I would like you to take a look at it because many times a big change ends up being not that bad after itās done.
[quote=ādeluciaā]json is good but yaml is better (in this case). Isnāt your goal to be sublime?
I would like you to take a look at it because many times a big change ends up being not that bad after itās done.[/quote]
I know how YAML works, itās not bad, but to me, and Iām sure others JSON makes it far easier to understand what is going on.
Aye, I agree YAML would have been a much better choice. Off the top of my end I think there would be a lot less escaping needs and itād be much more readable and easier to maintain, which is good for config files. Right now with JSON itās rather curly brace hell and itās very easy to get lost in all the nested brackets and braces.
Perhaps there was a technical limitation of some sort?
Ok here is segment of the keymap file and the equivalent in yaml. I think the yaml is leaner and easier to read.
JSON:
{ "keys": "backspace"], "command": "left_delete" },
{ "keys": "shift+backspace"], "command": "left_delete" },
{ "keys": "ctrl+shift+backspace"], "command": "left_delete" },
{ "keys": "delete"], "command": "right_delete" },
{ "keys": "enter"], "command": "insert", "args": {"characters": "\n"} },
{ "keys": "shift+enter"], "command": "insert", "args": {"characters": "\n"} }
]
YAML:
As a programmer, I can appreciate the convenience of JSON as a portable and well-supported format.
As an end-user, I struggle to imagine a more unreadable mess for dealing with a large configuration system such as Sublimeās. I never thought Iād find myself missing XML (for the keymaps).
To me this is brace/bracket/quoted literal/string escaping-hell. Definitely a step backwards from the previous ācustom directiveā syntax (or whatever it was in ST1) in terms of usability, IMO.
YAML is slightly better.
Anything that uses symbols rather than quoted string literals for keys would be a slight improvement. Like Ruby hashes, or even Javascript associative arrays, all of which are painlessly converted to JSON or other associative array structures.
Maybe Iām missing something, but I think this is a case where thereās a benefit to eating the pain of conversion on the backend (from a proprietary syntax) for the sake of the user.
Is the debate over already ?
Iād also like to throw in some support for YaML. After all, the resulting data type are the same, and not only do we avoid the { } hell, we also avoid the " " hell for property names.
Maybe would it be possible to at least give us the choice ? Like an option that says āRead .yml config files, then .jsonā or the inverse or so ?
Holy necro, Batman!
Iād like to throw in support for JSON. As ironcladlou mentioned, itās extremely portable and widely supported. I canāt think of any user experience needs trumping these two programming requirements. Admittedly, YAML does share some formatting structure with Python but itās not difficult to format JSON for readability.
My 2cents:
YAML IS AWESOME. As a configuration language, It is fast, flexible, metaprogrammable.
It would NOT be a big change, In-Fact it would be a dropin replacement because JSON is a valid subset of YAML.
All current JSON config files would work perfectly when being parsed by the YAML, making this the perfect time to switch over.
People wonāt even have to know that PyYaml is actually parsing their Json file.
In additon to this, YAML has some really cool features such as anchors which allow us to reduce repetition in config files (define once, use many times.)
From the wiki definition:
[quote]YAML syntax was designed to be easily mapped to data types common to most high-level languages: list, associative array, and scalar.[4] Its familiar indented outline and lean appearance make it especially suited for tasks where humans are likely to view or edit data structures, such as configuration files, dumping during debugging, and document headers (e.g. the headers found on most e-mails are very close to YAML). Although well-suited for hierarchical data representation, it also has a compact syntax for relational data as well.[5] Its line and whitespace delimiters make it friendly to ad hoc grep/Python/Perl/Ruby operations. A major part of its accessibility comes from eschewing the use of enclosures like quotation marks, brackets, braces, and open/close-tags which can be hard for the human eye to balance in nested hierarchies.
[/quote]
So please, reconsider YAML. Itās awesome, Itās powerful, Itās a drop-in replacement.
JSON is verbose, bloated and ugly ā YAML or CSON would be a great improvement.
Cson disqualifies as a configuration format because it is badly specified and requires coffeescript to be parsed (since it is essentially coffeescript). My 2ct.
I think my love for yaml is quite clear nowadays, so I doubt I have to say anything else regarding this thread.
Hi!
Yaml would be great for the following reasons:
{, alomost no quotes, no comma)And, it would stop those problems with Json:
So, please @jps or @wbond, consider swapping on YAML.
Matt
PS: if youāre for this swap too, please leave a comment, so we can see how many people would enjoy it, and so maybe it will accelerate the process.
@math2001 Jon and I have discussed the idea of using YAML. There are some definitely pluses to it, but some downsides also. One of the bigger issues is that significant whitespace isnāt intuitive to many users unless theyāve worked with a language like Python before. Using it for .sublime-syntax was a big win over XML or JSON. The additional complexity of understanding YAML was justified there since writing a syntax definition isnāt the sort of thing most users do.
We havenāt made a definitive call on it yet, but as with most other things, Iāll try to chime in and answer questions as people ask them. IMO, all of the XML files that are supported due to compatibility with TextMate would ideally be superseded by a format that is easier to modify. Solving this issue isnāt next on my list of things to do, but is definitely not low priority.
As with most parts of the implementation of Sublime Text, the implementation details required to maintain performance arenāt always obvious. Changing file formats requires that the parser we are using is extremely efficient, especially since there are thousands of .sublime-syntax, .tmPreferences, .sublime-settings and .sublime-snippet files that are loaded whenever Sublime Text is started.
You should take a look at Hjson. It does not suffer from JSONs trailing commas, allows comments and is easier to use than YAML.
Hi evrbd,
in some projects, e.g. nodeJS, a āpackage.jsonā-cfg-file gets changed by the NPM-/Yarn-tool and the User, too. Thus it cannot contain comment-lines, which would be helpful. The ordering of keys cannot be maintained āby-handā, too.
In my workflow, i convert -by hand/script- from JSON to YAML and back. I have comments and key-order preserved and the benefit of a cleaner view for editing the YAML.
Iām working on a script that merges/diffs newly added keys from the JSON- into the YAML-file while preserving comment-lines in YAML. I used pythons ruamel.yaml-lib.
Later iād like to make a ST-plugin, that automatically converts a JSON-config-file into a YAML-representation, opening the YAML in a editible-view, whereas the JSON-file opens in read-only view, if it opens at all.
Iām new to Sublime, so if there already exists a plugin that already does smth. similar, please tell me. Iād like to lern the sublime-API by example.
While i consider this scenario to be a special-case and i donāt expect this to become integrated into ST, i wonder if maybe such a situation is somehow ātypicalā for others, too ?
In general-terms, having two files with identical contents but in different formats, that need to be kept in-sync and the file-formats can be (automatically)-transformed in both directions ?
Maybe this is already too much of IDE ? iām not sure - i find such scenarios more often in my workflows and i need a supportive-editor to handle such stuff.
regards, andreas
@math2001 and @laktak STās config files allow trailing commas and comments. The userās Preferences.sublime-settings file is the only one that doesnāt keep them when changing something e.g. via command palette. I use trailing commas and comments in keymaps, projects and plugin configs.
@delucia your keymap doesnāt have to look so bad if you format it better, e.g.:
[
{
"keys": ["backspace"],
"command": "left_delete",
},
{
"keys": ["shift+backspace"],
"command": "left_delete",
},
{
"keys": ["ctrl+shift+backspace"],
"command": "left_delete",
},
{
"keys": ["delete"],
"command": "right_delete",
},
{
"keys": ["enter"],
"command": "insert",
"args": { "characters": "\n" },
},
{
"keys": ["shift+enter"],
"command": "insert",
"args": { "characters": "\n" },
},
]
@twoolie people will know that PyYaml is actually parsing their config because ST will probably get slower on startup. Here is a Ruby benchmark and Python benchmark. Maybe somebody could do a benchmark of ST startup time with YAML vs JSON parser. I love ST for its speedy startup and actually I also love JSON for its unambiguity (though no comments and no trailing commas sucks, which ST āfixedā).
@bosinski your plugin could keep YAML configs in a folder, which get converted to JSON on save (e.g. Preferences.yaml becomes Preferences.sublime-settings). That way you keep the original YAML with comments and also have the performance benefit of JSON. Youād need to hook into the Preferences menu somehow.
Choosing a niche format over an established standard, like JSON and YAML, is hardly ever a good option (mostly due to the lack of an eco-system supporting it). It also doesnāt solve any of JSONās shortcomings, as mentioned by the thread starter.
Apart from that ā Iāve seen other JSON-like formats which set the same goal, and of all of them JSON5 appears to the closest of ever becoming standard. Until itās not, I wouldnāt even consider it.