Use JuliaFormatter instead of DocumentFormat#972
Conversation
Closes julia-vscode/DocumentFormat.jl#70 JuliaFormatter was originally forked from DocumentFormat when domluna wanted to add canonicalising functionality. Since then, extensive work has gone into JuliaFormatter. I believe it is significantly more feature-rich than DocumentFormat at this time. I believe there are significant advantages both to the Julia community at large and to LanguageServer.jl to combine efforts on a single code formatter.
…Server.jl into non-Jedi-juliaformatter
|
Requires domluna/JuliaFormatter.jl#448 for compat with older Julia versions. |
|
This now also adds some rudimentary support for selection formatting. |
davidanthoff
left a comment
davidanthoff
left a comment
There was a problem hiding this comment.
So I think the main blocker at the moment is that we're waiting for MinimalStyle, i.e. domluna/JuliaFormatter.jl#256, right?
|
Oh, and also, it would be great if @ZacLN could generally take a look at JuliaFormatter.jl etc and chime in. |
| longest_prefix = CSTParser.longest_common_prefix(something(longest_prefix, line), line) | ||
| end | ||
|
|
||
| config = get_juliaformatter_config(doc, server) |
There was a problem hiding this comment.
Does this request get hit every key stroke? If so it's not ideal to search the disk each time. I can't remember whether we're able to have a file watch from within the languageserver which may be why this has been done
There was a problem hiding this comment.
We could just add those files to https://github.com/julia-vscode/julia-vscode/blob/master/src/extension.ts#L232, and then we would get normal LSP messages about their content etc. That seems in general better?
There was a problem hiding this comment.
Does this request get hit every key stroke?
No, only when explicitly requested.
We could just add those files to https://github.com/julia-vscode/julia-vscode/blob/master/src/extension.ts#L232, and then we would get normal LSP messages about their content etc. That seems in general better?
IIUC we'd only be notified by FS events or when the user opens/changes the .JuliaFormatter.toml. The client won't just dump all matching files into the server.
There was a problem hiding this comment.
The client won't just dump all matching files into the server.
Not sure what you mean by that. We could just handle .JuliaFormatter.toml files the same way we handle all .jl files in the workspace, right? Then they would be in-memory always?
There was a problem hiding this comment.
Is that so? I thought we'd load most files directly from disk?
There was a problem hiding this comment.
Yes, we load initially, but then we don't need to reload because we get notifications whenever they are updated. If this is not hit with every keystroke that probably doesn't matter that much, though.
Having said that, the LSP will have to move to a model at some point where language servers just don't touch the file system at all and instead can get all content from the client, just to make things work properly with virtual file systems that are supported in the client. At the moment there is not support for that in the protocol itself, but we would probably be better prepared for that if we made these files "normal" files. On the other hand, lets not make that a roadblock for this PR :) The MinimalStyle is, though...
4 participants
Fixes julia-vscode/DocumentFormat.jl#70.