Should OCamlFormat Default Profile be Improved?

Hey everyone!

On OCamlFormat, there’s a few open issues and pull requests relating to OCamlFormat’s default profile that aren’t progressing and where it is unclear whether they should be pursued or retired.

For example, making the formatting of fun arguments more consistent could affect a lot of code in favour of overall nicer formatting: Indentation of `fun` arguments is inconsistent · Issue #2397 · ocaml-ppx/ocamlformat · GitHub

Here’s an anonymous poll:

  • I’m in favor of the change proposed in the issue
  • I prefer a different output (discuss in this thread)
  • I disagree with changing the output for cosmetic reasons
0 voters

The reason we’re asking this here is that we don’t have any internal resources to have these debates and we want to get an idea how much the OCaml community cares about this. Currently, OCamlFormat is in a maintenance state, but, if the OCaml community is in favor of improving the default profile, contributions would be possible. :orange_heart:


Ocamlformat could be very useful for students (and their teachers reviewing their usually-ugly layout). BUT Ocamlformat (i.e. dune fmt or VS Code) does not work out of the box, one must add an .ocamlformat (even empty) in their directory. Can this be changed?


ocamlformat has an --enable-outside-detected-project flag for this

1 Like

There is a PR in the dune repo to generate an empty .ocamlformat file (along with a couple of other basic files) in a project created with dune init. It needs a little bit of work but imho should be doable.

1 Like

My point is that, if I run ocamlformat, directly or through dune fmt or through VS Code Ctrl+Shift+I, it’s because I want… to run it. Why prevent it when there’s no .ocamformat?


FWIW I concur with @grayswandyr, I already wondered a long time ago about that bizzare way of operating.

1 Like

My guess is that they don’t want to encourage running ocamlformat with a completely empty or missing config file because they want users to at least pick a version profile so that the formatting will not keep changing whenever the ocamlformat version is upgraded.

1 Like

If it works with an empty .ocamlformat file that theory doesn’t hold :–)

In any case that way of operating certainly put me off the software. Well at the time, the formatting aswell: it behaved as if LaTeX would define your paragraphs :sweat_smile:

Don’t know if it improved but if five years laters it remains so dubious to use it seems like a waste of time. If I had to switch from the venerable ocp-indent I think I’d rather go with something more generic like topiary which hooks into the interesting (for language designers) tree-sitter eco-system. From far seems like a good tool for polyglot code bases. Anyone has experiences to share (I’ll fork the discussion if anyone has) ?


It’s just a guess, so there may be another reason. Also, it may be that they are not applying the principle (‘discourage empty config file’) consistently due to oversight.

1 Like

A post was split to a new topic: Experience with formatting a code base with topiary

We had a plan to do it, but only after we a default profile we really liked which isn’t the case currently.
I might push for this even without the nice default if there sufficient demand. An upside of the current situation is that it is a safeguard against formatting a project that did not use ocamlformat by mistake.


Makes sense. Hopefully the team can converge to a default profile in a not-too-distant future. I don’t like all current choices (I regret the loss of the sparse format) but I like having a no-nonsense shared standard formatting even more.


There are other ways, you can always add prompts (and ways to disable them, i.e. the converse of mv :–) if your tool has modes of operations that are potentially destructive.