Hi Colin, it's great to get your thoughts on this. 2015-09-15 22:52 GMT+01:00 Colin Fleming <colin.mailingl...@gmail.com>:
> I think it's important that the declaration of the formatting be separated > from the declaration of the macro itself. This allows forms which the > editor developer doesn't control to be annotated, e.g. core. Perhaps > library owners could produce an EDN doc containing these specs? Or perhaps > we could obey annotations in the functions themselves, but I think that > some way to additionally annotate external things is essential. > I think it's important that this information be in the metadata. When we're indenting a form, we only need to resolve the var and we'll have its metadata. That seems simpler than having to resolve the var and then look it up in the library's doc or something. Of course, metadata can be added to a var as a separate declaration, so it does allow us to annotate external macros as in: (alter-meta! #'clojure.core/cond assoc :editor/indent 1) Does that cover your point or did I misunderstand something? > I also think that Mr Dynamics is correct, we should not go down the path > of special casing anything, even defn - this is a hard rule that I have in > Cursive that I only break very occasionally :-). The spec should support > everything we need to do. It will be difficult, though [...] > Yes, I agree now as well. > There are also many more aspects to formatting that this does not address > that I think we should think about - line indentation is only one part of > it. What about breaking lines when they're too long? Aligning subforms like > let-binding values? Do we want to do anything about those? Cursive can > handle all of that but doesn't expose the knobs right now. clj-fmt does, I > believe - I think it can take a single line of pr-str output and produce > nicely formatted code. > There are also lots of edge cases that need to be thought through. > Multi-arity function declarations for letfn, proxy etc come to mind. > extend-type also supports multiple arity declarations. condp is another > example of a form with variable numbers of elements per "block" (the :>> > keyword). for-blocks have internal let blocks, etc etc. > Indeed the spec should cover some of this stuff. I'd like the spec to cover as much as possible, but I also don't want to define something so verbose and complicated that people just don't bother. So hopefully we can figure out a way to add some essential features while keeping the complexity in check. In particular: - Handling macros that may take different syntaxes I feel is pretty important. This is basically the multi-arity case you mention. The `fn` could be invoked as `(fn my-func [] 10)` or as `(fn ([] 10) ([x] (inc x)))`, and the indentation is different in these cases. - Another thing I'd like is a way to indicate that there should be a line-break between one symbol/value pair and another in let-bindings. So the subforms you mention. - I would like the spec to say things like "this argument should (or should not) be on its own line". But I *don't* think the spec should say "break the line if it's longer than N chars". It's hard to tell how far to go with this. One thing that I'm planning in > Cursive that I'm not doing currently is also to identify forms which are > part of a do-body-like-thing. This is very useful for refactoring. This > might not have a place in a spec that is purely for indentation, but > definitely would in a more general form structure spec. > The safest option here is to not go too far right now, but define the spec in a way that's extensible, so we can still go as far as we want later. The spec I proposed initially isn't highly extensible. Can we figure out a reasonable way to add a few of these features? -- 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.
