Use the default erlang format for erlang_ls.config

[sirikid]

Subj.

[robertoaloi]

@maxno-kivra Any concerns with this?

[robertoaloi]

Hi @sirikid and thanks for your contribution!

I am happy to support Erlang terms as a possible format (that would also make it easier to produce diagnostics for the configuration itself), but I believe we should keep this change backward compatible, at least for now. What do you think about trying to parse the config in both ways (Erlang, YAML) before giving up? Something like

• erlang_ls.config -> Try both Erlang and YAML for now, only Erlang in the future
• erlang_ls.yaml -> Read it as YAML (we may want to deprecate this later)

An option is to call it something like erlang_ls.eterm. What do you think?

[sirikid]

I am happy to support Erlang terms as a possible format (that would also make it easier to produce diagnostics for the configuration itself), but I believe we should keep this change backward compatible, at least for now. What do you think about trying to parse the config in both ways (Erlang, YAML) before giving up? Something like

* erlang_ls.config -> Try both Erlang and YAML for now, only Erlang in the future

* erlang_ls.yaml -> Read it as YAML (we may want to deprecate this later)

Sure, we can also emit a warning if erlang_ls.config is written in YAML. I will update the PR.

An option is to call it something like erlang_ls.eterm. What do you think?

I would like to keep it .config because Erlang itself and widely adopted tools like Rebar3 use .config.

[maxno-kivra]

I was thinking about breaking existing configs. As long as the users doesn't notice this change, why not. But if it means I'm forced to update all my config files I wouldn't be very happy.

I also would like to keep support for YAML. Partly the same reason as above, don't force the user to make an arbitrary change. But also because many other tools use YAML and I like the consistency with those. (Although YAML as a format is not great, I give you that.)

[sirikid]

@robertoaloi ping