Format using JuliaFormatter.jl

[dahtah]

Some functionality for using JuliaFormatter.jl, which offers more sophisticated formatting than julia-mode at the moment, and is useful for following style guides. Inspired by julia-formatter.el.
This PR provides julia-snail-format-region and julia-snail-format-buffer. Default style can be changed by providing a config file
as per JuliaFormatter docs.

[gcv]

First, I'd like to see examples of code that JuliaFormatter does better than julia-mode, and a bit more of an argument to support the assertion in julia-formatter.el that "[fixing current indentation engine] seem[s] impractical". Impractical how? Because julia-mode maintainers don't accept patches? Or because the Emacs indentation engine is too inflexible to support the desired changes (I agree it kinda sucks but it's been widely used for many languages and does not require server round-trips just to indent code).

Second, if we were to include this patch, I think we need to make its dependencies opt-in. Remember how you guys had to drag me kicking and screaming to include CSTParser? And that was just two dependencies. JuliaFormatter pulls in dozens. I'd like to put together a Snail-configuration optional way to enable features which require Julia dependencies. (Basically an Emacs-side list of Julia packages, which, if set, will tell Snail to use Pkg on the Julia side to install extra stuff that may be missing. The advantage is not taking the hit of installing all these dependencies if you don't want them.)

[dahtah]

Thanks for your feedback! As to your first point: JuliaFormatter.jl is much more extensive in the changes it makes, but I don't think there's anything there that couldn't in principle be replicated in emacs. It has the advantage of being easy to customise on a per-project basis and also already there. I personally don't care about the particular position of semicolons but I know some organisations enforce style guides. I just knocked this feature together because a collaborator prefers consistent style in a package. If nothing else this PR can serve as a model for how easy it is to extend julia-snail, thanks to the transparent client-server model.
The broader question is whether Julia support on emacs should (a) lean on traditional emacs tools or (b) leverage stuff that's being developed on the Julia side. I think julia-snail makes (b) easy, which is good news because the set of people who are proficient in both emacs-lisp and Julia is pretty small. In addition Julia happens to be pretty good at string processing, and fast, so that the overhead in client-server communication is partly made up for.
Fully agree with your point on dependencies, JuliaFormatter pulls an insane amount of dependencies for no good reason that I can see. It'd be nice to have a optional dependency system but right now there's no clean Julia mechanism for it.

[gcv]

Okay. I'm convinced.

I have in mind a pure Snail-side solution for the dependency problem. Basically, as I described above: some features in Snail will be gated by an opt-in custom setting, and when that setting is turned on, the feature gets to add dependencies to an Emacs-side data structure. When Snail starts, if it notices the Julia side is missing packages listed in that data structure, it'll install them.

I think this'll help a lot with adding features with your point (b) above.

I don't have time to work on that right now, but maybe in a few weeks.

[dahtah]

All right, sounds good!

[gcv]

I thought a lot about what you said, and implemented the idea of Snail extensions to make things like this easier to write and maintain:

• https://github.com/gcv/julia-snail/blob/master/README.md#extensions
• https://github.com/gcv/julia-snail/blob/master/EXTENSIONS.md

I grabbed your code (cherry-pick commit here: 69cd68a) but moved things around to fit the extensions API I put together. It's here: https://github.com/gcv/julia-snail/tree/master/extensions/formatter

Let me know what you think!

[dahtah]

Wonderful, thanks! I'll give it a try and let you know.