Rename?

[KristofferC]

Other code formatters are named as clang-format gofmt, rustfmt etc. Perhaps this package could be called something like jlfmt, JuliaFormat, julia-format etc? DocumentFormat seems a bit generic to me.

[davidanthoff]

CodeFormatters.jl or something like that? I think if we end up creating a command line tool it should actually not live in this package here, but be another separate package that could then be called jlfmt or something like that. Given that many tools will use the functionality in here, I think all the tools (LanguageServer.jl, command line tool, github bot) should take a dependency on this package.

[ZacLN]

Yep for sure, this was only supposed to be temporary, so CodeFormatter.jl? @KristofferC if I change the repo name with an attobot PR pending will it mess things up?

[KristofferC]

I mean, it is a Julia code formatter and it I don't see the point of having plural since we are not instantiating a bunch of formatters. In my opinion JuliaFormat seems in spirit to the package guidelines while still being similar in spirit to the clang-format and co.

[iblislin]

How about this?

    Julia
+)  format
--------------
    Julmat

And I just discoverd this: https://sv.wikipedia.org/wiki/Julmat

[ZacLN]

JuliaFormat it is

[davidanthoff]

I think having the word Code in there is not bad, JuliaFormat could be a lot of other things. So maybe JuliaCodeFormat.jl? I'm not a huge fan of the plural thing either, but isn't that the normal package naming guideline? But I'm certainly on board ignoring that and using the singular here, seems better.

[KristofferC]

Being similar to other code formatters is in my opinion quite nice. Being super explicit has advantages but it can also be kinda ugly :P

[davidanthoff]

Well, I don't think any "normal" user will ever use this package, right? I think this is a package that will be used by other packages/tools. I'm all for using similar names for those tools, so that users aren't confused. But I would use a super explicit name for this back-end package here.

[KristofferC]

Why wouldn't the CLI live here in e.g. a bin folder? Splitting things too much apart makes automatic testing awkward since things have to move in lockstep and it also reduces discoverability. To me Pkg.add("JuliaFormat") and then symlink the CLI to your bin folder seems pretty optimal to me.

[davidanthoff]

I would prefer to not ship any CLI as part of the VS Code extension, which we would have to do if it was part of this repo. There is going to be a complicated dependency situation no matter what because the LanguageServer.jl and the github bot will also depend on this repo here.

[KristofferC]

It would just be a script file in a folder? I don't see how it could matter for LanguageServer whether it is here or not.

[ZacLN]

I'm easy on the \bin stuff. Re the name: guidlines suggest not using Julia in the title soCodeFormatter`?

[KristofferC]

Yeah but the guidelines for not using "Julia" is just to not use it to show that the package itself is written in Julia. But here we are talking about formatting Julia code. It's the same situation as JuliaParser.

[davidanthoff]

It would just be a script file in a folder? I don't see how it could matter for LanguageServer whether it is here or not.

We might want to eventually have build script that puts the binary into the path or something like that. The command line tool might want to be on a different release schedule than the VS Code extension etc. Just think it would be easier to keep these separate.