Smaller text edits in lsp formatting handler

[jrentlez]

Hi, I saw the TODO in the new LSP implementation and thought I'd try it.

Now, the formatting handler does a byte by byte diff of the unformatted and formatted contents, and only responds with the changes between the two.
An alternative would be a line by line diff, but I found that doing it byte-wise has two advantages:

1. document.position_at() can be used to compute positions
2. The formatted string can just be sliced to get the new text, no need to search for line endings

Additionally, I took the liberty of implementing two other nitpicks that I had with the LSP. Let me know if you'd prefer separate PRs or don't want these at all.

1. The servers initialize response includes a serverInfo field
2. FormattingOptions are respected

Couldn't find a CONTRIBUTING.md, so I hope I didn't miss any PR guidelines 😅.

[JohnnyMorganz]

Very cool, thanks for taking the time to implement this! Looks pretty reasonable to me.

The only thing I'm a bit wary of is the FormattingOptions. Ignoring this originally was intentional, as I'd prefer project configuration is explicitly all part of the stylua.toml. In practice, the issue we are trying to avoid is if your editors formatting options don't match the formatting options that a project has defined (e.g., you prefer indent with spaces, this is configured in your editor, but you're working on a project that indents with tabs, now the formatting is incorrect as stylua.toml is not respected)

I'd prefer to leave this one out, but if you reckon it's useful I'd be open to making this configurable in some way. Maybe an (off-by-default) option passed in initialization options, like respect_editor_formatting_options? If we go that route, let's also mention it in the README.

Also, could you update the changelog with this improvement?

[jrentlez]

In practice, the issue we are trying to avoid is if your editors formatting options don't match the formatting options that a project has defined (e.g., you prefer indent with spaces, this is configured in your editor, but you're working on a project that indents with tabs, now the formatting is incorrect as stylua.toml is not respected)

I agree that explicitly set config options shouldn't be overridden, but if neither stylua.toml nor editorconfig nor the cli arguments contain indent_width for example, I think its better to use the editors setting than a constant default.
For example, lines with tab characters may exceed the default 120 columns limit if stylua uses indent_width = 4 but the editor uses indent_width = 8 .

The fields in the Config struct are now optional, which allows the formatting handler to determine whether an option has been set or not.

I know this change is sorta out-of-scope for this PR, but I couldn't think of another way to use FormattingOptions as a fallback.
The Config changes are all inside the latest commit, so if you still prefer the respect_editor_formatting_options approach they can be reverted.

[JohnnyMorganz]

Sorry, I'm still not sure about that. For example, in all of my projects I rely on the stylua defaults and do not explicitly specify them in stylua.toml. If another contributor comes in and has different editor settings, I would want to make sure it's aligned with my project settings.

For now, I'd prefer to leave it out of this change. Everything else LGTM (and thanks for catching the missing range formatting server capability too)

[jrentlez]

Ok, thank you for considering the idea though. I've replaced the fallback behavior with a new init option respect_editor_formatting_options, and rebased on the latest commit.

[JohnnyMorganz]

Thank you!