Consider Rusty Object Notation (RON) for settings?

[xpe]

Check for existing issues

• Completed

Describe the feature

I recommend supporting Rusty Object Notation (RON) for Zed settings. If I had to pick one reason it would be this: to reduce the impedance mismatch between settings and code.

Motivation

In terms of community feedback, given that Zed is written in Rust, I think adoption of a settings.ron format would be welcomed.

I understand Zed is growing and changing quickly, with many ideas competing for adoption and developer time. This particular idea would be a small step towards embracing the best tooling available in the Rust ecosystem. From what I can tell, the Zed code and team embodies these ideas. Being willing to break free of purely inertial conventions is an important value to embody in a young project like Zed. 🚀

Comparison with JSON

Here are some advantages over JSON, taken from the "Why RON" section of the RON README:

• trailing commas allowed
• single- and multi-line comments
• field names aren't quoted, so it's less verbose
• optional struct names improve readability
• enums are supported (and less verbose than their JSON representation)

There are two key limitations of RON versus JSON -- which could be rectified:

1. At present, I don't know of something analogous to JSON Schema for RON. (If there is interest in using RON, I would be happy to start designing ideas for a RON Schema, and I'm confident others would help.)

2. In my experience, RON parsing errors could stand some improvement. Again, more eyes can solve this problem.

[jansol]

Related to 1: what is the tooling state for RON in general? For example currently we have LSP suggestions based on the schema while editing the config file, which is a huge usability feature. Additionally it's easy to faff about with the JSON using external tools such as nushell, jq, etc, which I am not familiar with RON equivalents of?

As for schemas, looks like there is not much going on upstream yet: ron-rs/ron#470