Indentation of threading macro broken

[j0ni]

I'm seeing the threading macros indented like this:

(-> first
  second
  third)

(->
    first
  second
  third)

(->> first
  second
  third)

(->>
    first
  second
  third)

which seems wrong.

Edited to add: I see this in the changelog:

Added special indentation settings for ->, ->>, cond->, cond->>, some-> and some->>

Possibly related? Are these configuration changes? If so, is there some config I'm now supposed to do to get the behaviour I used to have, and which is described here?

[j0ni]

Also, the behaviour of assoc indentation went from this:

(assoc the-map
  :a-key a-val)

to

(assoc the-map
       :a-key a-val)

[bbatsov]

Possibly related? Are these configuration changes? If so, is there some config I'm now supposed to do to get the behaviour I used to have, and which is described here?

I have not updated the guide, but the changes are intentional. Those macros were never supposed to be indented as they were.

Also, the behaviour of assoc indentation went from this:

This is also intentional.

(->
first
second
third)

The first arg of the threading macro is a bit special (the macro takes expr and forms as args), therefore it should be on the first line together with the operator (as in forms like doto, etc). People have been practicing the second style of indentation only because of the incorrect indentation settings before version 4.0.

(assoc the-map
:a-key a-val)

This was incorrect - an ordinary function like assoc should have been indented as it was.

I realize some of those changes might seem odd to people used to old (and incorrect behaviour), but they're all for the best. Some poor indentation decisions were made in the past in clojure-mode and what's worse - they were copied in other tools (e.g. LightTable) just because they were in clojure-mode. It was about time we corrected those.

[bbatsov]

//cc @cursiveclojure

[cursive-ghost]

I think Cursive already indents according to the new settings, except for the threading macros. Cursive by default will indent these as:

(-> first
    second
    third)

But this can be configured to achieve:

(-> first
  second
  third)

easily if required. Cursive also provides an "indent-only" mode which always indents subsequent lines in a form by 2 spaces - this will give the second indentation style by default.

[zane]

It feels important to have alignment on the defaults. Could @cursiveclojure change the default behavior for the threading macros?

[bbatsov]

@cursiveclojure Those macros should not use the standard alignment for a very simple reason - all their args are not the same. People normally don't think about this in the context of the basic ->> and ->, but is easy to comprehend if we observer cond-> and as->:

(cond-> []
  (< 2 3) (conj :a)
  42 (conj :b)
  (> 2 3) (conj :nope)
  :go (conj :more))

;; [:a :b :more]
(as-> shape s
  (rotate s 30)
  (scale s 1.2)
  (translate s 10 -2))

The signature of threading macros like -> and ->> has the same structure of macros like case and we should treat them accordingly. It'd be great if those get indented in the same manner in all Clojure dev environments, but that's obviously out of my hands. I can only express my regret that I didn't alter this the moment I took over the maintenance of the Emacs Clojure stack.

[cursive-ghost]

Hmm. It's relatively simple to fix, but it'll lead to complaints :). I'll consult the Cursive mailing list and see whether people would prefer to maintain the current default or not. I'll also have to reformat the whole Cursive code base. I'm not sure I agree about the structure of these macros being the same as case, since these macros have an implied sequence which I feel like the alignment indicates.

[bbatsov]

Hmm. It's relatively simple to fix, but it'll lead to complaints :).

All such changes lead to complaints. When somebody gets used to something it's hard to point the flaws in it.

I'm not sure I agree about the structure of these macros being the same as case, since these macros have an implied sequence which I feel like the alignment indicates.

Signatures don't lie - [x & forms]. :-)

I can see the allure of treating all params in the same manner, but this is kind of misleading. Changing the default will also kill practices like:

; no form on the first line
(->>
  first
  second
  third)

; wasted horizontal space
(->> first
     second
     third)

[amalloy]

I don't update my clojure-mode installation regularly (or at all), but I was linked to this issue and have some things to say. I agree wholeheartedly with the change to assoc: that special case never made any sense.

But I totally disagree with the -> indentation change. Two-space indentation doesn't mean "the first arg is different from the rest of the args" - if it did, you'd want to revert the assoc change, and adjust functions like update-in, map, and zillions of others to fit. Two-space indentation signifies a "body" argument, as in defn or let. Using it for -> is quite confusing, unless you use it for every indentation, as apparently Cursive offers to let you do.

Additionally, I don't like the idea of special indentation rules based just on function name when there's any possibility that the tool will misunderstand context. It's fine for defn, for example, because everyone always writes (defn foo [] ...) as its own top-level form. But -> can get used in interesting places where this indentation would be clearly wrong. Consider, for example,

(doto my-obj
  (.setText "test")
  (-> (.getPosition)
      (.getX)
      (.setValue 10)))

Here, the first argument to -> is not different from the others, because it's used in a context where the "actual" first argument is implicit. It would be atrocious to indent that as follows:

(doto my-obj
  (.setText "test")
  (-> (.getPosition)
    (.getX)
    (.setValue 10)))

Is clojure-mode really smart enough to not apply its new special case here?

[llasram]

Is more in-depth discussion of this change taking place elsewhere? I don't want to dog-pile out-of-band if so, but I agree with all the points @amalloy has made. Moreover, I'm concerned becaused it seems that like-it-or-not "however Emacs formats it" is the de facto actual standard for Clojure code formatting, and changes should probably be subjected to broader discussion and community consensus.

[bbatsov]

@amalloy You should see my comments in #266.

But I totally disagree with the -> indentation change. Two-space indentation doesn't mean "the first arg is different from the rest of the args" - if it did, you'd want to revert the assoc change, and adjust functions like update-in, map, and zillions of others to fit. Two-space indentation signifies a "body" argument, as in defn or let. Using it for -> is quite confusing, unless you use it for every indentation, as apparently Cursive offers to let you do.

I'm well aware what the 2-space indentation means and I do think that -> fits the bill. An expression gets threaded through a series of expressions (which can be considered a body IMO). And the first expression is clearly different (it won't wrapped in parens if they are missing for instance).

Please, note that doto and ->/->> have exactly the same signatures. Trying to justify they deserve different treatment sounds kind of strange to me. Yeah, I realise most people think of several equivalent expressions threaded together, but I think that the proper way to reason about threading is threading the first expression through a series of expressions (the form's body). I think it says something along those lines in the macro's docstring.

Additionally, I don't like the idea of special indentation rules based just on function name when there's any possibility that the tool will misunderstand context. It's fine for defn, for example, because everyone always writes (defn foo [] ...) as its own top-level form. But -> can get used in interesting places where this indentation would be clearly wrong. Consider, for example,

(doto my-obj
(.setText "test")
(-> (.getPosition)
(.getX)
(.setValue 10)))

You clearly believe that this is some sort of special case, but at seems totally ordinary to me. The wrapping doto doesn't change the way -> works.
I should stop writing replies at night... Yeah, scenarios like that are regrettable and show the limitations of simple indentation engines...

Is clojure-mode really smart enough to not apply its new special case here?

I really think there's no special case here.

Is more in-depth discussion of this change taking place elsewhere? I don't want to dog-pile out-of-band if so, but I agree with all the points @amalloy has made. Moreover, I'm concerned becaused it seems that like-it-or-not "however Emacs formats it" is the de facto actual standard for Clojure code formatting, and changes should probably be subjected to broader discussion and community consensus.

It'd say that the community Clojure style guide is much more authoritative standard. Nobody had discussed this there so far, however. On the other hand I'm pretty certain that most folks consider the old indentation correct simply because they're used to it and haven't given it that much thought in the past.
I also know that a lot of tools are simply copying the indentation of clojure-mode (with all its bugs), so I'd rather them copy something semantically correct and consistent.

Clearly people disagree on ->/->>'s indentation - the new settings got both praise and flak (as always). Dealing with language standards is a nerve-wrecking experience. :-)

[cursive-ghost]

I'm inclined to leave the Cursive default settings as they are for the moment. I agree with a lot of the arguments that have been presented, and I don't think that requiring people to reformat their code bases is worth whatever (clearly debatable) benefit there might be.

I'd like to address a few other points:

Cursive does actually understand threading forms and doto, so @amalloy's examples of nesting them will indent correctly. If you don't take that into account you'll get really ugly formatting in a lot of cases.

@llasram made the point that Emacs shouldn't be the de-facto standard, and I agree. It's a non-goal for me to imitate Emacs' formatting, especially when many people consider particular formatting more or less a bug (see for example #235). It is a goal to allow users sufficient configuration options to allow them to match whatever Emacs is currently using, since this is important for multi-editor teams, or people who switch from one to the other. However Cursive now allows much more sophisticated per-form formatting (aligning let-block values and Midje facts, for example, and more complex things) which a lot of people have asked for.

In #266 @bbatsov says:

Special indentation is reserved for macros and special forms with body forms

Initially Cursive only allowed customising macro forms but people asked for the ability to customise functions too (see cursive-ide/cursive#536). There are clearly a lot of examples where this is desirable so Cursive now allows it - artem is another example of this.

I don't think that the community will ever agree on one standard to rule them all. Other languages with much more complex syntaxes manage to have different projects using different styles - I think tools should adapt to those styles rather than trying to enforce them.