I asked the same question in a different thread but was asked to move it into a separate thread in this category. So there it is again:
I have a few questions I want to ask. However I'm not sure if it's the right place for that. I have to admit that I have very little to none knowledge related to the LSP technology, so please bare with me.
Judging from the table in the OP there are or will be features that are source code related that editors and IDE's can start sharing. By 'sharing' I mean in the context of shared API on how to handle similar things in different editors. In particular I'm speaking about Folding and Formatting features. By this day I've seen tons of of Swift libraries and various code styles. However there are and always will be inconsistencies between different libraries due to different coding styles.
For instance I would like to contribute two multiple projects, but I nearly always end up screwing up the formatting, just because the projects follow a different source style that I do or my IDE is set up to follow. By that I only refer to one single thing: tabs vs spaces (2, 4, etc.).
Wouldn't be nice if we can generalize at least a few major cases with this project, starting with that problem?!
In the long term it would be great to have a shared mechanism that each editor / IDE can automatically make > use of for such fundamental things.
I Imagine something along the following line:
Project A uses tabs, IDE automatically adjust itself, stdlib uses 2 spaces, the IDE will adjust itself again (locally not globally).
Formatting is something we want to provide, but what to do exactly, like
Define formatting rules and allow to specify them per-project
Use inference for formatting rules of the existing source file
Push more for common rules enforced by convenient tools, like the Go approach
is up for debate, but it's a bit early to discuss this.
What we want is to have a tool offering formatting functionality and integrate that into SourceKit-LSP; once such functionality exists we can have concrete discussions on how to utilize it exactly.
I have to disagree that it's too early to discuss what such a feature should look like, even if we don't yet know how it would work, since the what may inform the how. Frankly, such tooling is decades overdue in the Apple ecosystem. Designing such a feature doesn't even have to be much work, since nearly every other IDE has some sort of auto formatting system built in, so Swift's tooling can just copy those capabilities. Personally, I like presets plus the ability to use a visual editor to update a style that can then be shared per project and across projects. It should also work similarly across all of Apple's tooling, not just the Swift language server. I think such a discussion would be helpful to inform the capabilities that should be built into the LS, but also as a public vetting of ideas that could inform the priority of features for IDEs adopting the LSP (hint, hint).
If you ever used Objective-Clean and its wonderful online editor, you will have another proof it can be done nicely :). I quite liked the choice of styles with examples and the ability, when needed, to be lax and allow all three/multiple variations of that rule (essentially an option to ignore the rule).