@misha I don’t agree that this changes semantics - I do agree that the alignment can cause diffs to be larger than they would be otherwise. However the same is true of the map value alignment and let binding alignment that exists right now.

@misha @denik My main problem with this proposal is that it’s hard to identify when you would want it. One of the nice things about Clojure is that you can use normal data structures for everything, but that also means that they can be hard for me to work with.

In @denik’s original examples, the method body is really just a bunch of vectors - how could I tell that this is hiccup (or whatever) and know to align it in a certain way?

@denik Here’s a simple example of when this might break down:

(let [{:keys [a b c d]} something]
  {:a        a
   :b        b
   :c        c
   :d        d})

(contrived example of course, but you get the idea)

@cfleming that's why I don't use such formatting even now :) (though it does make code examples in the docs, or established, tested, less likely to change code in the libraries tiny bit more readable)

Right, I use it for maps, but not for lets

IntelliJ’s diff is good enough that I can easily see what’s actually changed, and it’s only me looking at the diffs so that’s ok.

But especially in a mixed team that can be a problem.

By "semantics" I mean: visual grouping easily gets changed so that attributes of one entity are "closer" to attributes of another, than to the entity itself. This easily provides wrong impression about code structure/ forms relationships

Ok, so it might make code more confusing. I don’t find that myself, and I’d argue it’s not semantics as such, but that’s just quibbling 🙂

I don't even want to start thinking about "how to make it work well with parinfer"

True

Yeah, parinfer complicates this sort of thing.

There are already a lot of bugs/side effects with things like rename and parinfer.

Maybe not "changes", but "de-emphasizes"

That’s fair enough.

But my main problem with the proposal is that, even if we all agreed the idea was good, it’s unclear how to decide where and when to apply it.

I’d like to provide better support for Hiccup et al, but I’m not sure how to detect that some vector is actually supposed to represent Hiccup (or Garden css, or whatever else).

re: diffs, most diff tools should be able to ignore whitespace changes when asked

Guido would be so angry

I think aligning makes sense when the data is tabular (a vector of maps with the same keys or a vec of vectors) but aligning the vals in a map or let subconsciously suggests that the left side names are related to one another. When I have map/let alignment turned on I find myself choosing poorer names on the left side because I don't want one long, descriptive name to push all the values too far away from the other bindings.

{title              ...
 id                 ...
 comments           ...
 published-datetime ...}

{title    ...
 id       ...
 comments ...
 pub-dt   ...}

contrived, but I'd say the top map has better naming, but is harder to read.

(i find all these arguments compelling - i’m fine with the current alignment/indentation style)

@misha: @cfleming points taken. Colin, in your case I don't particularly see where how this breaks down. In a let the scope is he binding vector of the let, so whatever is within would get alignment. Re: the data structure being hiccup or something else, I'd say that's a nice treat but too specific to implement for. As you've correctly identified this indentation style is about aligning map values in arbitrarily deep nested data structures or a bindings. Can you make another example where this falls apart?

@denik: How do I know the scope of a let is the binding vector and not the list of the let?

Without hard-coding that?

@cfleming you’d hardcode that in cursive’s indentation policy, not in the code itself. That’s okay, isn’t it?