Integration/merge with JuliaFormatter?

[norru]

I'm using

https://github.com/singularitti/vscode-julia-formatter

to format code. It produces a very nice output but unfortunately so slow as to be unusable in an interactive way (works fine as an external tool though). This is, likely, a consequence of it not being integrated in the Language Server.

Can JuliaFormatter be integrated in DocumentFormat as an optional backend?

I have tried DocumentFormat as it is as a replacement but it doesn't indent correctly in multi-line statements (unless I'm missing some magic tick box?)

[norru]

The following related JuliaFormatter issues could be solved more easily by having the formatter run within the JLS.

singularitti/vscode-julia-formatter#4
singularitti/vscode-julia-formatter#5
singularitti/vscode-julia-formatter#6

[davidanthoff]

Could you open an issue with a repo case for the incorrect indentation? We should just fix that here.

I don't see us supporting two different formatting tools here, that just adds too much complexity.

[norru]

I could do it but why duplicate effort?

DocumentFormat appears to simply ignore multi-line statements, never mind breaking them down into lines correctly, taking into account parameter lists, expressions, arrays and tuples.

It does look like a significant effort if implemented from scratch and I really could do with an usable formatter sooner than later :)

Besides, the alternative workflow I've got right now is to run JuliaFormatter from within the REPL (JuliaFormatter has too slow a start to be viable as a separate process which is started each time). The alternative for it to work would it be for the VSC plugin to run a separate "formatting server" and use a request/response protocol to communicate with it. Reminds you of anything? ;)

[davidanthoff]

I could do it but why duplicate effort?

Just to be clear, DocumentFormat.jl has been around forever. I don't understand why there was a need to create a second formatting tool (in the form of JuliaFormatter.jl), but that is where we are now. Given that DocumentFormat.jl powers both VS Code, the LS and the package butler story, we want to fix bugs in it, so bug reports are appreciated.

DocumentFormat appears to simply ignore multi-line statements

Could you post an example? That would be great.

never mind breaking them down into lines correctly

So I'd be thrilled to see a PR that adds an optional story that adds or removes line breaks, but I wouldn't want that to be the default, I think that is too invasive and opinionated for a default formatting tool.

[norru]

So I'd be thrilled to see a PR that adds an optional story that adds or removes line breaks, but I wouldn't want that to be the default, I think that is too invasive and opinionated for a default formatting tool.

I'd love that option too, not too fussed about that not being the default. Most formatters I use (all languages) have separate options to break down formal arguments, actual arguments, expressions, module declarations and so on (and generally having those enabled by default). Works perfectly for me so I don't have to spend days pecking on the space/tab/enter key :)

I'm personally ok for opinionated as long as I can opt out of defaults. I do remember hacking Elm Format with a sed script because there was no option (and no plans to implement it) to remove redundant line breaks.

I don't understand why there was a need to create a second formatting tool (in the form of JuliaFormatter.jl),

I can guess: people wanted opinionated line breaks :D

EDIT: Summoning @domluna

[norru]

Could you post an example? That would be great.

Here's a trivial example of code that DocumentFormat.jl doesn't handle in any way (doesn't even indent correctly):

function example(a, b, c)
    a(b, "first", 
                    c,
            "third",
        "fourth")
end

I would expect either:

function example(a, b, c)
    a(b, "first", c, "third", "fourth")
end

If the formatted line is within margins, or

function example(a, b, c)
    a(b,
       "first",
       c,
       "third",
       "fourth")
end

if it doesn't. More sophisticated algorithms could do something like this as well

function example(a, b, c)
    a(b, "first", c, 
       "third", "fourth")
end

And this should be done for any kind of sequences, including arguments, export clauses etc, possibly with a separate enable/disable option for each.

By the way I am not making this stuff up, I've seen it working many times. Every other language I have ever used had a least one formatter tool which supported this.

[norru]

New issue at: #71

[waldyrious]

DocumentFormat.jl has been around forever. I don't understand why there was a need to create a second formatting tool (in the form of JuliaFormatter.jl), but that is where we are now.

For historical reference, that package was created following the discussion at #27.

[norru]

@waldyrious To me it does look like that there is a definite appetite for different formatter options which (IMO) should be both supported by the VSC extension.

These two options are philosophically incompatible with each other as:

1. DocumentFormat approach: minimal edits, just surgically add tabs/spaces. Never touch line breaks.
2. JuliaFormatter (@domluna's) approach: full pretty printing, opinionated, with opt-outs. Line breaks are added/removed if needed.

I rarely saw any requests for 1) outside of the Julia community., but I do acknowledge that both approaches are perfectly valid depending on user's preferences and workflows.

(To be fair, I have never seen an IDE support only 1) before, except for Emacs in the early days. Rust, Go, C#, Java, Kotlin, Scala, etc... all have support for full pretty printed in most IDEs.)

I believe that users that are used to approach 1) find 2) unacceptable and vice-versa. The current strategy for VSC is to consider only 1).

I also believe this does a disservice to a potentially large userbase which prefers/it is used to/is more efficient with approach 2).

My preferred solution would be to have both available in the Julia Language Server. A JLS configuration option would select the backend. The default would be to keep the current behaviour (DocumentFormat).

It might be relatively straightforward to implement as these formatters have a very similar API.

Once the initial abstraction is implemented, little additional maintenance is required except keeping the package version up to date, as JuliaFormatter has its own maintainer and release cycles.

[domluna]

Btw, with custom styles (on master of JuliaFormatter) it would be possible to have a style that does what DocumentFormat currently does. I have a WIP version of formatting in the YAS style

[jlperla]

For what it is worth, I have been using the latest JuliaFormatter with the YAS style and a .JuliaFormatter.toml file. So far it has been extremely polished. Especially useful for coding with students who aren't yet accustomed to code layout/etc.

As @domluna says, the ability to add https://domluna.github.io/JuliaFormatter.jl/dev/custom_styles/ seems very likely that it could provide a "simple" style, which could be the default for vscode if you prefer. then in their .JuliaFormatter.toml files people could choose style = simple, style = default and style = yas.