On December 21, 2014 at 1:12:10 AM, Leon Grapenthin (grapenthinl...@gmail.com) wrote: Thanks for bringing this up here and linking to the issue I raised on GH. I wanted to start a discussion here as well but have not yet found time.
My concerns and worries are less about the style-guide in general and more about the indentation change regarding assoc introduced as default in clojure-mode 4.0.0. At this point in the discussion (bbatsovs reply here) I don't think there is another way to change his mind than more people in the community trying to convince him otherwise. TLDR is that bbatsov has decided with release 4.0.0 that indenting assoc in the way introduced more than 6 years ago is not so much of a good idea anymore because it "defies an extremely strong Lisp tradition ". I believe I presented a bit more arguments than that. :-) I find it personally preferable for the three reasons listed here. Since bbatsov was so kind to fix threading macros yesterday, I guess he can be convinced about assoc, too. This is unlikely to happen. Few people were upset about the assoc indentation and more greeted it. Not to mention most tools don’t use special indentation for assoc by default. I’ll extend the clojure-mode docs with more info about indentation customizations, which sounds like a reasonable compromise to me for people who disagree with the defaults. People should certainly be able to indent their code however they see fit. Regarding the discussion in general: How about agreeing to an EDN structure with indentation hints which can be loaded into any Clojure IDE? This would offer library authors to provide indentation hints for their macros themselves. They could also be added as meta-data to the vars so that during an active nrepl connection the correct indentation for e. g. om/dom forms would be pulled automatically... Best regards, Leon. On Saturday, December 20, 2014 10:14:18 AM UTC+1, Colin Fleming wrote: Hi everyone, There's been a bit of discussion recently on a couple of clojure-mode tickets that I thought were worth discussing here. The tickets are #265 and #266, and they later led to PR #96 on Bozhidar Batsov's Clojure Style Guide. The part of the discussion I wanted to raise starts here, where there's some discussion around the nature of the style guide itself. Bozhidar clearly sees himself as the steward of a community style guide, something he's done to great success with the Ruby style guide. However it seems that there is a significant part of the community that didn't see it that way, and had seen it more as his personal style guide that he happened to put out there. I'm interested in starting a discussion around this because I do think it's valuable to have some degree of community consensus around these issues, specifically so that tools can have consistent defaults. That said, one of the defining features of lisps in general is that they permit essentially unlimited flexibility, and in my experience programmers in general really don't like being told what to do, especially around indentation. So, I'd like to ask the obvious initial question - do we as a community think that there is value in having a style guide like this? If so, to Marshall's point on the list, do we think it should try to mandate what people should be doing, or should it describe what they actually currently do in real code, even if that's the result of historical accidents? For what it's worth, from my point of view I definitely think that a guide like this is useful, and I've referred to Bozhidar's guide myself from time to time when trying to decide what to do for a particular feature in Cursive. However I do think that it needs more flexibility than it currently has - there are some things marked in there as "bad" that I'd like to see downgraded to "prefer the other way unless you have a good reason", which of course I always feel like I have. In particular, some of the reasoning behind the linked changes above I think needs to be more flexible - there are good use cases for customising indentation for some functions, for example. Of course, if we decide that we do want a guide like this then we can spend many happy years arguing about what should go in it, but first things first :-) Cheers, Colin -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
