I mentioned this at the end of #36, but I'll reiterate a bit and provide some more justification.

I explicitly want to keep the configuration of this plugin quite simple. It's very easy to fall into the trap of trying to support every possible workflow via the config, and that way leads to option hell. It can become super flexible, but it also gets very difficult to reason about, becomes harder for new users to grok, and creates almost a mini-DSL that I have to maintain, debug, and add features to. For this reason, the stock configuration is intentionally designed to cover only the most common use cases. For anything more complex, it's expected that you can call conform.format() directly yourself, passing in whatever list of formatters you want.

To more directly answer your immediate question: I agree that having a "lsp" formatter would be a nice interface and make the config easier. Well...in the common case it's probably much the same, but I agree that it feels a bit more aesthetic. However, the issue is that LSP formatting is decidedly not like other formatting. Non-LSP formatters can operate as a pure function, taking lines in and spitting lines out. They're beautifully stateless. LSP formatters can only operate on the current state of a buffer, and they return a set of TextEdits. Building a system that can treat these two the same would require additional layers of abstraction and some kludgy hacks. If all we're getting for that is a slightly nicer config interface, I don't think it's worth it. It feels better to leave things simpler and easier to reason about.

For these reasons, I'm filing this under "not planned"

Explicit LSP formatter #61

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions