Why was `align-cases` removed from ocamlformat?

I much preferred formatting that aligned cases, and found it to be a really non-trivial gain in readability and accessibility. Suddenly, I find the option gone after updating, but I can’t find any explanation of why this was removed. Could anyone supply some information on the motivation for this feature removal?

1 Like

The worst part is it looks like I cannot use ocamlformat now without it unaligning my cases, even if I manually align them, so I guess I may just stop using the tool I guess?

Partial explanation here: Feature request: align-record-decl · Issue #1821 · ocaml-ppx/ocamlformat · GitHub

3 Likes

Thank you for digging up that link! This is really unfortunate imo, but glad to have found the motivation at least!

I’m sad to see human readability and accessibility neglected for the sake of making the work easier on machines :confused:

2 Likes

Machines have whitespace-ignoring flags like diff -w (often available from a checkbox in web apps), and that go fmt does horizontal alignment should keep such features popular, so I feel like implementation simplicity is the real driver here. Maybe after the code’s cleaned up some readability features like this can come back.

2 Likes

Note that alignement often makes it look nice but harder to read and I don’t think you should do it in general. In fact it’s discouraged by the programming guidelines (but I don’t think their justification is convincing).

My justification would rather be that if there’s a wide blank gap between patterns and branches it becomes difficult for your eyes to determine which pattern match with branches without using your finger. A similar problem appears in the layout of indices and table of contents when people insist to align page numbers on the right of the page – often mitigated by dot leaders which are not only ugly but also don’t really solve the problem efficiently for the reader, writing the page just after the entry is perfectly alright.

But in some cases alignement can be useful to make a point across two different cases (e.g. when there’s subtle symmetrical index fiddling) and I don’t think that’s for a machine to decide. I really wish for a better middle ground between ocamlformat and ocp-indent.

2 Likes

It definitely does not make it harder to read for me, and I’m sure I’m not the only one! That said, I grant this will vary from reader to reader and so likely across code bases.

This is true, but iirc, the alignment functionality usually defaults back to unaligned when the graps are beyond a certain threshold (at least, this is what i am used to).

Maybe I can at least find a configuration that will not undo my manual configurations. At worst, I can just use an older version of ocamlformat, tho i worry that ocaml 5 compat will make that infeasible for the long term.

Maybe it calls for a fork or competing project that prioritizes flexibility and the needs of different readers? If I magically get extra free time, I’ll consider such a thing.

Perhaps what’s really called for is more investment in structural-type editing tools that will will allow customized rendering be normalize into a uniform representation on disk.

I find it quite disheartening to see a feature which, imo, helps with accessibility for certain kinds of readers cut out of a core tool for the sake of reducing diff size (which @jrfondren can already easily be managed automatically) and simplifying the implementation. That said, I readily acknowledge that the maintainers don’t own me anything. I just think this it’s a minor accessibility loss for our tooling.

I personally really, really dislike alignment, in any language where this is sometimes practised like Terraform or let-bindings in Clojure. It is fun-ish when you first see it, but then I find it absolutely annoying to use when not using a formatting tool (have fun pointlessly adding padding just because you renamed a thing or have a merge fail because of unrelated padding adjustment which “whitespace ignore”-options don’t catch), annoying to deal with in an editor like vim since you need to move around all the useless padding space and last but not least annoying to read, since the values are somewhat off to the right side of the screen, so you need to have your code-splits wide enough or you might not even see the code in the editor (or it breaks the line, making it look even worse).

So yeah, very much an “eye of the beholder” thing.

3 Likes

I agree it can be annoying not having a formatting tool available to take care of it. Thus… :wink:

i also agree it’s something that gets in the eye of only some beholders :smiley:

As a shameless plug, with regards to code comprehension and quickly understanding code that makes use of large match branches, users of emacs can have a slightly easier time by using Gopcaml-mode’s structural navigation capabilities:
gopcaml-mode-move-around
I bring this up only because I do actually find this capability extremely useful for navigating through large OCaml codebases with ease - it helps especially much when the size of these branches may expand past a single page.

1 Like

More details here: De-deprecate align-* features · Issue #1996 · ocaml-ppx/ocamlformat · GitHub

2 Likes