I spotted the following things:

• Rope folder: If empty, no such a folder is used at all. This is a bit odd because if you leave it empty, the default (.ropeconfig) is used. So it may need to contain whitespace?!
• Pydocstyle convention. This can be left blank? What does happen in the case that neither pep257 nor numpy is chosen?
• Yapf: If both Yapf and autopep8 are enabled the latter is preferred. Does this mean that if both are enabled, there is no way to invoke Yapf despite it is enabled? In this case it would be more intuitive to have a select field that either enables Yapf or autopep8. But this list needs to be populated dynamically because installation of these plugins got optional and not all may be available.

@exploide Thanks for the review 👍

Rope folder: If empty, no such a folder is used at all. This is a bit odd because if you leave it empty, the default (.ropeconfig) is used. So it may need to contain whitespace?!

Good point fixed in #99

Pydocstyle convention. This can be left blank? What does happen in the case that neither pep257 nor numpy is chosen?

I personally don't use pydocstyle. The options mirror the CLI of pydocstyle. Unfortunately I haven't found a good way of handling null values in Atom config schema.

Yapf:
Does this mean that if both are enabled, there is no way to invoke Yapf despite it is enabled?

I haven't tried it myself but that's how I interpret the language server docs. We should test it and clear up the docs.

In this case it would be more intuitive to have a select field that either enables Yapf or autopep8.

Apart from the the downside you mentioned we had a similar discussion for completions on the pyls repo some time ago: palantir/python-language-server#222 (comment)

It would become impossible for a plugin to add extra formatters. Which was the point of plugins in the first place.
This is certainly a good argument for the language server itself. Though I'm unsure if this is a thing we want or should support in ide-python.

For now I tried to keep the config options as close to the language server as possible to avoid additional conversions. But I'm very open to ideas for restructuring our settings.

Good, thanks. Seems like a few points need further investigation.

I don't fully understand the thing with the formatters. If there were another plugin that eventually decides to offer formatting functionality (let's say pydocstyle supports formatting in the future), then the language server would need additional code to expose this functionality via the interface implemented by languageclient / ide-ui anyway. Or am I wrong? So changes to the language server (and then in this package) become necessary in every case?!

Seems like a few points need further investigation.

👍

So changes to the language server (and then in this package) become necessary in every case?!

People can also install 3rd-party-plugins like the isort-formatter to extend the functionality of the language server. I don't know if we'd be able to support this use case if we implement a custom config.