From :rod to :semantic

[vemv]

Hi there,

in #170 we devised a style called :rod which various people liked/adopted. I'm using it at work currently (even if we aren't quite happy with the results yet).

However I never found the time to explain more exhaustively how it looks like (for a variety of forms), and importantly, why, so that users can understand this choice and perhaps make this style easier to share/adopt.

While :rod isn't necessarily a widespread style, it is a very reasonable/non-fanciful one, derived (and compatible) from well-known styles and backed by years of real-world usage in team settings.

Importantly, I think that implementing this style would be a great showcase/benchmark for zprint's capabilities, and surely would leave composable primitives.

Perhaps :rod was bit of an organic name, I think that :semantic would do it more justice.

So, without further ado...

The :semantic style

tldr

:semantic is a subset of:

• clojure-mode
• CIDER style
  • (which is basically clojure-mode)
• the Clojure Style Guide

which is stricter in a few ways, emphasizing meaning over concision, and a sense of homogeneity that makes formatting more predictable (e.g. I can predict how a formatting will look like, vs. seeing a seemingly random result influenced by concision or a column limit).

Explanation

It is 'semantic' in that there's a rigid mapping between forms (e.g. defn, if) and where the newlines should be located. So a maintainer can say things such as:

• because I see that this form is laid out in this way, I can tell instantly that it's a defn (or a defrecord, etc)
• because I see that this call is indented with two spaces, I can tell it's a macro invocation
• because I see that this call is indented with an aligned style, I can tell it's a function call

In other words: by visually scanning the whitespace, before seeing the contained forms, I can already tell what I'm about to find.

This IME greatly decreases cognitive costs, reducing friction as one reads/maintains code.

Importantly, it makes Clojure look more 'like a language', as opposed to simply mashing sexprs together.

Case study: if

As a very self-contained example of my ideas, we can consider if. Here's an example to be avoided:

;; bad
(if (foo) 1 2)

What's wrong here? (foo) represents a condition, while 1 represents a 'then'. By placing them in the same line, they look as if they belonged to the same category.

They don't: they're not simply different items in a list, but things with profoundly different meanings.

So allocating one line for each kind of thing makes this distinction clearer:

;; good
(if (foo) ;; one line for condition
  1 ;; ...one line for then...
  2) ;; ...and one line for else

There are many other examples for making such distinctions. Such as:

;; bad
(fn [] [])

Here we put an argv and a [] return value in the same line. They look visually identical and nearby, so one is suggesting that they are the same kind of thing, when they aren't.

This is what I mean with make Clojure look more 'like a language'. In many programming languages observes a certain relationship between syntax and newline placement, and honors it even if there's a way to shortcut it.

The rules in question

1 - Certain forms have a canonical newline placement

Under :semantic, certain forms have a canonical placement for newlines and blank lines.

The most important being the following:

1.1 - defn, fn

;; Examples from https://github.com/kkinnear/zprint/issues/170
(defn foo []
  1
  2
  3
  4
  5)

(defn foo
  ([]
   1)

  ([a]
   1))

(defn foo
  ([]
   1
   2
   3
   4
   5)
  
  ([a]
   1))

1.2 - defprotocol, defrecord, extend*

;; One line per method
;; One line for docstring if present
;; One blank line between methods
(defprotocol AProtocol
  (doit [this]
    "Docstring")

  (dothat [this that])

  (domore [this that]))

(defprotocol AnotherProtocol
  (xdoit [this]
    "Docstring")

  (xdothat [this that])

  (xdomore [this that]))

;; Fields vector in same line as `ADefrecord`
;; One blank line between methods
;; One blank line between protocols
;; No blank line between a protocol name and its first method
(defrecord ADefrecord [f1 f2 f3]
  AProtocol
  (doit [this]
    (run! println [1 2 3])
    (println this))

  (dothat [this that])

  (domore [this that])

  AnotherProtocol
  (xdoit [this])

  (xdothat [this that])

  (xdomore [this that]))

;; deftype just like defrecord
(deftype ADefrecord [f1 f2 f3]
  AProtocol
  (doit [this])

  (dothat [this that])

  (domore [this that])

  AnotherProtocol
  (xdoit [this])

  (xdothat [this that])

  (xdomore [this that]))

;; extend-type just like defrecord (except, of course, that there isn't a fields vector)
(extend-type ExtendedType
  AProtocol
  (doit [this]
    (run! println [1 2 3])
    (println this))

  (dothat [this that])

  (domore [this that])

  AnotherProtocol
  (xdoit [this])

  (xdothat [this that])

  (xdomore [this that]))

;; extend-protocol just like expend-type
(extend-protocol ExtendedProtocol
  String
  (doit [this]
    (run! println [1 2 3])
    (println this))

  (dothat [this that])

  (domore [this that])

  Thread
  (xdoit [this])

  (xdothat [this that])

  (xdomore [this that]))

1.3 - defmethod

;; Incorrect - the return value `[]` is not placed in its own line
(defmethod wrong-defmethod :default [x] [])

;; Prefered style
(defmethod some-defmethod :some-dispatch-value [a b c]
  (println a)
  (println b)
  (println c))

;; Next-prefered style (when a column limit imposes it): argv after dispatch value
(defmethod some-defmethod-B :some-dispatch-value
  [a b c]
  (println a)
  (println b)
  (println c))

;; Next-prefered style (when a column limit imposes it): one line for dispatch value, one line for argv
(defmethod some-defmethod-C
  :some-dispatch-value
  [a b c]
  (println a)
  (println b)
  (println c))

1.4 - if, if-not

;; Incorrect: `if` has a canonical form
(if 1 2 3)

;; Correct
(if 1
  2
  3)

1.5 - Macros taking a & body

;; Incorrect
(when 1 2)

;; Correct
(when 1
  2)

;; ^ Broader rule derived from `when` rule: for any macro that takes a `body`, said body cannot be in the same line as the macro being invoked
(defmacro Foo
  {:style/indent 1}
  [a & body])

;; Incorrect: non-body and body macro arguments are in the same line
(foo 1 2 3)

;; Correct: there's a newline before the `body`
;; This enables 2-space indentation, allowing humans to see it's a macro call.
(foo 1
  2
  3)

1.6 - =, not=, <, <=, or, and

;; Incorrect
(= [1 3 2] [1 3 2])

;; Correct: one line per item allows visual diffing (by moving the eye vertically)
(= [1 3 2]
   [1 3 2])

1.7 - ->, ->>

-> is a bit different: it has some considerations as a macro (relative to newline placement), but it indents like a defn.

clojure-mode also makes this exception.

;; Correct
(-> 0 inc inc inc)

;; Also correct
(-> 0
    inc
    inc
    inc)

;; Incorrect
(->
 0
 inc
 inc
 inc)

1.8 - try

(try ;; A newline must be placed after `try`
  (call1)
  (call2)
  (catch Exception e ;; A newline must be placed after the exception binding
    (call3))
  (finally ;; A newline must be placed after `finally`
    (call4)))

---

2 - Independent forms within a body get one line each

Given a body, e.g. defn's or do's, no two independent forms should reside under the same line.

;; Incorrect: there are two independent body sexprs within the same line
(fn [x y]
  (+ x y) (+ x y))

;; Incorrect: there are two independent body sexprs within the same line
(defn foo [x y]
  (+ x y) (+ x y))

3 - The first argument of a function call must be placed in the same line as the function name

Given a function call, its first argument must reside in the same line as that of the function being called. This forces aligned style.

;; Incorrect - causes 1-space indentation which is not desirable
(foo
 1 2 3)

;; Correct
(foo 1 2 3)

;; Also correct
(foo 1
     2
     3)

If it was impossible to make such a sexpr fit within a column limit, I'd prefer if users fixed it manually (which is very often possible with simple refactorings e.g. split into let bindings, or helper defns)

4 - Multi-line sexprs cannot be siblings of single-line sexprs

;; Incorrect - the sexpr `1` is in the same line as a multi-line sibling sexpr within a function call
(comp (fn [x]
        (inc x)) 1)

;; Correct - whenever a sepxr within a function call spans more than one line, then each argument in that function call
;; must be located in its own line
(comp (fn [x]
        (inc x))
      1)

5 - Argument vectors are placed in the same line as the function name

This consideration emphasizes that a function is a function of something. e.g. f is a f(x), which is deeply related to math and FP notation.

;; bad
(defn f
  [x]
  )

;; correct
(defn f [x]
  )
;; Acceptable exceptions are the presence of a docstring and whenever a column limit would not be met.

---

I think that :rod already satisfies a few of this expectations, and probably a few others are very much at hand.

For others I don't know if they would entail a lot of work. I'd love to know your impression of what's possible first. If everything seems at hand I can try coding the rules myself which would seem nice.

Probably #223 is a blocker - I can't quite reason about things when they currently happen to be broken.

Also, rule 1.5 requires understanding what "special" and "non-special" (body) arguments are, which is related to #225 .

I hope you appreciate the issue writeup, it might sound ranty in some passages but I'm simply trying to convey its rationale. Probably much of the issue could eventually make it to the official doc? I could eventually further refine these words.

Cheers - V

[kkinnear]

Wow! That's a lot to digest. Thank you for the effort to explain all of this to me.

I have read this over several times, but not yet gone into great detail in trying to make it happen. Overall, zprint is designed for just this sort of thing -- you can have it the way you want it. As you have noted.

This writeup could certainly make it into the documentation for zprint, possibly with minor adjustments to the tone so that it isn't quite so adamant about the "right" way to do things. But we can see about that as we get it working.

At first glance, these are the things that might be hard:

1. You have noted 1.5 requires knowledge of how a macro is defined. Moreover, zprint as usually used, doesn't even know a macro from a function -- unless you tell it in the :fn-map. So for most users, this won't be operational.
2. I haven't looked into 1.2 yet. I have put a lot of work into this area, and it might be that with a little creative configuration, zprint could do what you want now. Alternatively, it may be that it needs a "guide", like I had to do for :rod.
3. Rule 3, about "forcing aligned style", and making people refactor code that doesn't meet a column limit, is going to require some work -- possibly only work getting me to understand what you want. I found the link to "aligned" style far from clear, probably because I'm coming from a very different environment than those words were written for.

I'm not asking for you to explain more at this point, though I will be for sure as we get into this.

I want to fix the existing bugs (in particular the multithreading one you noted, #226), and get a new release out.

After that, I think the way to approach this is to work on one or two sections at a time, get them the way you want, and then move on to the next. Possibly with a number of alpha releases that you can play with to see how it works.

I envision this overall as a :style made up of a number of other styles. That way, people could opt-in to one of the styles but not have to buy into the whole thing. It also makes it much easier to maintain and test.

Thanks again for the effort in writing all of this up. I'm looking forward to getting into this soon!

[vemv]

Cheers. Thanks as always for taking these into consideration.

This writeup could certainly make it into the documentation for zprint, possibly with minor adjustments to the tone so that it isn't quite so adamant about the "right" way to do things. But we can see about that as we get it working.

👍

You have noted 1.5 requires knowledge of how a macro is defined. Moreover, zprint as usually used, doesn't even know a macro from a function -- unless you tell it in the :fn-map. So for most users, this won't be operational.

FWIW, for my use case I plan invoke zprint from the same JVM as the REPL's, so that knowledge would be accessible. For the "binary / CLI" use case, I could regularly emit zprint files from said REPL JVM, keeping those auto-generated files version-controlled, maybe shared in a .jar, etc.

I found the link to "aligned" style far from clear

You can find snippets for always-align and always-indent in said link. Rule 3 intends that:

• function calls use 'aligned' style (or are expressed in a single LOC)
• macro calls use 'indented' style (or are expressed in a single LOC, as long as Rule 1 isn't broken)

After that, I think the way to approach this is to work on one or two sections at a time, get them the way you want, and then move on to the next.

Yes, that would be perfect. Feel free to work on these in a PR format and request a review from me. Quite obviously I'm not in a position to review the impl - instead I can come up with more / trickier test cases for each feature.

I envision this overall as a :style made up of a number of other styles. That way, people could opt-in to one of the styles but not have to buy into the whole thing. It also makes it much easier to maintain and test.

Indeed, this would maximize usefuless and ensure cleanliness.

[kkinnear]

So, I've made some good progress with this work. I have implemented the function name "alias" you suggested in Issue #234. I have also added a particularly finicky enhancement which allows configuration of multiple lines in lists, which several of your requests required and which zprint pretty much didn't do (without using guides). I have also slightly enhanced guides themselves. I rewrote the :rod style not using a guide to see if I could do it, and using the new multi-line capability that worked.

So, I have a moderately enhanced basic zprint (library). I have then written an options map which seems to do (most of?) what you are requesting. At some point, when (if) we like it, I'll bake the options map in as a style directly into zprint, but treating it as a separate "thing" at this point makes sharing changes easier.

I am very interested in you having a chance to try this, in part simply to find test cases where what I've done simply doesn't work right, and also to expose places where my understanding of what you desire is flawed. I expect about equal numbers of each kind of problem to appear.

My thinking on how to share this with you is as follows. I believe you are using zprint as a library, so if I were to push up a [zprint "1.2.4-alpha1"] to GitHub, and share the options map I've created here in the issue, I think that it would be relatively easy for you to clone the repo and have the library right there. It just takes a lein clean lein install to get it into your local maven. Alternatively, I could push an alpha to clojars if that would be easier. Either would work for me.

In addition to an alpha library and an options map to use when testing things, I also need to respond to a number of your requests with a comment or two.

Just FYI (as I'll probably change it a bit as I continue testing), here is the current options map:

(def semantic
  {:style-map
     {:s1.0 {:doc "Remove standard things that don't fit",
             :fn-map {"if" :none, "when" :none}},
      :s1.1 {:doc "defn and fn",
             :fn-map {"defn" [:force-nl-body {:style :rod-base}],
                      "defn-" "defn",
                      "fn" "defn"}},
      :s1.2 {:doc
               "defprotocol, defrecord, deftype, extend-type, extend-protocol",
             :fn-map {"defprotocol" :arg1-extend},
             :extend {:nl-count 2, :nl-separator? true},
             :fn-force-nl #{:fn}},
      :s1.3 {:doc "defmethod",
             :fn-map {"defmethod" [:guided-body
                                   {:guide [:element :element-best
                                            :element-best-first
                                            :element-best-first :newline
                                            :element-newline-best-*]}]}},
      :s1.4 {:doc "if, if-not",
             :fn-map {"if" :arg1-force-nl-body, "if-not" "if"}},
      :s1.5 {:doc "macros like when, many more to do",
             :fn-map {"when" :arg1-force-nl, "when-not" "when"}},
      :s1.6 {:doc "=, not=, or, and, <, >, <=, >=",
             :fn-map {"=" [:hang
                           {:fn-force-nl #{:hang},
                            :next-inner-restore [[[:fn-force-nl] :hang]]}],
                      "not=" "=",
                      "or" "=",
                      "and" "=",
                      "<" "=",
                      ">" "=",
                      "<=" "=",
                      ">=" "="}},
      :s1.7 {:doc "->, ->>", :remove {:fn-force-nl #{:noarg1-body}}},
      :s1.8 {:doc "try, catch, finally",
             :fn-map {"try" :flow-body,
                      "catch" [:arg2
                               {:fn-force-nl #{:arg2},
                                :next-inner-restore [[[:fn-force-nl] :arg2]]}],
                      "finally" :flow-body}},
      :sall {:style [:s1.0 :s1.1 :s1.2 :s1.3 :s1.4 :s1.5 :s1.6 :s1.7 :s1.8]}}})

As you can see, the numbers in the "sub-styles" correspond to the numbers you created in this issue. I expect that when we are finished, I'd name them something more evocative, but for now I wanted to be able to figure out what I was doing relative to what you requested, above.

I'll give explicit instructions as to how to use this after I hear back from you and post an alpha.

It has been an interesting experience trying to bend zprint to fit your approach, and so far I have been kind of surprised at how few modifications I had to make to the basic code to get as close as I have gotten (which may or may not be on target, we'll see). I have certainly had to read my own documentation, since some of the features I'm using were implemented several years ago.

[kkinnear]

General comments on your definition of "semantic", above:

1.5 - Macros taking a & body

;; Incorrect
(when 1 2)

;; Correct
(when 1
2)

;; ^ Broader rule derived from when rule: for any macro that takes a body, said body cannot be in the same line as the macro being invoked
(defmacro Foo
{:style/indent 1}
[a & body])

;; Incorrect: non-body and body macro arguments are in the same line
(foo 1 2 3)

;; Correct: there's a newline before the body
;; This enables 2-space indentation, allowing humans to see it's a macro call.
(foo 1
2
3)

For the clojure.core functions that are macros with arguments and then body, it is simply work to identify which take one argument and which two arguments, and then make them :arg1-force-nl or :arg2 today. I need to create :arg2-force-nl to make this trivial for two argument macros. I already did when and when-not, and so it isn't all that difficult to work through the other clojure.core ones. I wouldn't mind help identifying which ones seem important to you.

If there are any with three arguments and then a body, I'd love to hear about it. Well, not really, but it would be good to know.

At present zprint has no way to know about macros in real time. I know that your use case has access to this information, and so you can tell zprint what should be done, but that's not something that I can solve in the general case. We might want to talk about just how you might want to tell zprint what should be done in case I can make that more efficient or easier for you to do.

One take-away for me is that I need to implement :arg2-force-nl, which will also simplify the options map I showed above.

2 - Independent forms within a body get one line each

Basically, zprint doesn't ever do this. Well, with some work you can configure it to do this, and you can do this easily with guides, but unless you try hard, zprint won't do this.

3 - The first argument of a function call must be placed in the same line as the function name

;; Incorrect - causes 1-space indentation which is not desirable
(foo
 1 2 3)

;; Correct
(foo 1 2 3)

;; Also correct
(foo 1
     2
     3)

If it was impossible to make such a sexpr fit within a column limit, I'd prefer if users fixed it manually (which is very often possible with simple refactorings e.g. split into let bindings, or helper defns)

zprint will never do the "incorrect" version, above.

What you are looking for is for a function that doesn't fit on one line, for zprint to "hang" the arguments, instead of "flowing" the arguments. If the hang causes things to look bad (i.e., it is toward the margin, and pushing things even more toward the marging looks bad), then zprint will do this:

(foo
  1
  2
  3)

It will make the indent appropriate (when using :style :community) either for body or argument functions -- to the extent that someone has told it what kind of function it is.

If you want people to fix things manually, the issue seems to me to be: how to tell them that it needs to be fixed?

One answer would be to think of this kind of output:

(foo
  1
  2
  3)

as a signal that you should fix things so that a hang will fit. Or, if it doesn't bother you, don't change it.

4 - Multi-line sexprs cannot be siblings of single-line sexprs

zprint will never do the incorrect thing. Well, I can configure it to do so, but unless I work hard, it will not do this.

5 - Argument vectors are placed in the same line as the function name

To the best of my knowledge, the current implementation of :style :rod does this as you want. That said, it is entirely new in this release.

[vemv]

If there are any with three arguments and then a body, I'd love to hear about it. Well, not really, but it would be good to know.

Probably the safe upper bound is, say, five arguments. (I assume these rules are "just data" and/or easy to scale)

At present zprint has no way to know about macros in real time.

Got it. It is only fair to try solving this problem even if it doesn't directly affect me.

Perhaps one approach would be to leverage clj-kondo or clojure-lsp analysis files. The might already reflect the style/indent metadata for bespoke macros, otherwise it surely is a minor feature request.

Basically, zprint doesn't ever do this.

Didn't expect that one to be honest! Hmmm, does it mean that it can actively produce such formatting?

Or merely that it can't fix it when it finds it?

Either way it probably would be an important limitation. Although perhaps I could work around by authoring my own small rewrite-clj thingy and composing it with zprint (one pass for zprint :semantic, one pass for inserting newlines, one last pass to add indentation to the inserted newlines - with a different zprint config that won't undo my changes)

If the hang causes things to look bad (i.e., it is toward the margin, and pushing things even more toward the marging looks bad), then zprint will do this: [...]

Mmm, as I'm understanding it, it seems highly undesirable. The style should be always "hang" (in clojure-mode lingo: always-align), because in clojure-mode one can only choose one setting at a time (always-align or always-indent). Emacs settings don't suddenly change because of some or other consideration; they're simply set to what the user specified.

This is not only a technical limitation, but also something that UX-wise makes sense: I expect my settings to be consistent, and the results to be consistent. Otherwise it would seem mentally taxing to see formatting bounce from one style to the other.

(This relates to "predictability" as explained in the main rationale)

[kkinnear]

If there are any with three arguments and then a body, I'd love to hear about it. Well, not really, but it would be good to know.
Probably the safe upper bound is, say, five arguments. (I assume these rules are "just data" and/or easy to scale)

At present zprint has no way to know about macros in real time.
Got it. It is only fair to try solving this problem even if it doesn't directly affect me.

Perhaps one approach would be to leverage clj-kondo or clojure-lsp analysis files. The might already reflect the style/indent metadata for bespoke macros, otherwise it surely is a minor feature request.

Two things here. First, I'm interested in getting clojure.core macros formatted the way you want. Second, I have no present interest in formatting user written macros based on their argument lists by looking at external information. Nobody has ever requested that, and you have another way to solve that problem in your environment. So this is not a current problem I'm interested in solving, in part because I don't personally find the results useful. If, over time, other folks request this, I'll look into it.

Basically, zprint doesn't ever do this.
Didn't expect that one to be honest! Hmmm, does it mean that it can actively produce such formatting?

I think we aren't communicating here. I meant that zprint will, in general, not produce the incorrect thing. Unless I really try, it won't do the wrong thing, so this isn't something we have to "fix".

If the hang causes things to look bad (i.e., it is toward the margin, and pushing things even more toward the marging looks bad), then zprint will do this: [...]
Mmm, as I'm understanding it, it seems highly undesirable. The style should be always "hang" (in clojure-mode lingo: always-align), because in clojure-mode one can only choose one setting at a time (always-align or always-indent). Emacs settings don't suddenly change because of some or other consideration; they're simply set to what the user specified.

This is not only a technical limitation, but also something that UX-wise makes sense: I expect my settings to be consistent, and the results to be consistent. Otherwise it would seem mentally taxing to see formatting bounce from one style to the other.

(This relates to "predictability" as explained in the main rationale)

Hmm. I think you are saying that one configuration of options should produce the same output given the same input. Which zprint will do. I think you are also saying that one configuration of options should produce code formatted in a way which is totally predictable in advance. Which may be what emacs will do. That isn't what zprint does. zprint tries both hang and flow at pretty much every level, and uses some complex heuristics to decide which looks "better". Which is how it comes out with formatted code that looks about as good as hand-formatted code (if, of course, your hand-formatting would use the same general approach as zprint uses). It can be a challenge to answer to question "why did zprint do it that way and not this way".

Some of this is because zprint works with a right margin, and tries (better than any other formatter of which I am aware) to actually make things fit within that margin. And make the code look good when it does it. I'm thinking that you don't really care about the right margin.

There may be a way to turn off trying it both ways and doing the "better" version. I'll have to think on this some more.

[vemv]

I think we aren't communicating here. I meant that zprint will, in general, not produce the incorrect thing.

Oh, alright!

Which may be what emacs will do. That isn't what zprint does.

Yep. And zprint is being both smart and 'too smart'. A dumb algorithm is also more consistent, which is a virtue per se (as a UX and predictability consideration).

I'm thinking that you don't really care about the right margin.

Kind of, I care about limits but formatting things inconsistently is not an acceptable fix for that to me (and arguably, to people using Emacs or anything that isn't zprint... other formatters don't have these double-edged complex heuristics).

My preferred kind of fix would be 'semantic', e.g. extract to let, to defn, to fn, thread-first the expression, etc - things that a formatter isn't generally expected to do.

I quite actively like that some things are delegated to humans. The human fix will produce better code, while, I'd argue, the zprint fix will only make the bad code look good (which is a merit! But not what I'd advocate for).

[kkinnear]

Just a quick thought on 1.6, above -- where you want (= [1 2 3] [1 2 3]) to be:

(= [1 2 3]
   [1 2 3])

zprint has the capability to format things with two arguments on one line, but force them to hang (as you specify above) if there are more than two arguments (or more than three arguments). So, it could be configured easily to do this:

(= [1 2 3] [1 2 3])

(= [3 4 5]
   [3 4 5]
   [3 4 5])

If that is interesting to you.

[vemv]

I'd be good with a strict 1.6 rule, i.e. always have one line per argument for those few functions. (Thanks!)

[kkinnear]

Ok, that's fine.

[kkinnear]

I'm going to convert this issue to a "Discussion", with the category of "Ideas". I think that we will be better able to go back and forth and actually interact on the various details of what you want there. I've never done this before, so my apologies if it all falls apart. Presumably GitHub will place a pointer in this issue redirecting you to the appropriate discussion.

[kkinnear]

One of the things to think about as we move forward here is how much of what zprint does by default do you want to keep around? That is what the first sub-style is all about:

(def semantic
  {:style-map
     {:s1.0 {:doc "Remove standard things that don't fit",
             :fn-map {"if" :none, "when" :none}},
...

This is just a placeholder for removing the formatting instructions for things you don't want. It actually is meaningless as presently written, as both if and when are redefined in other sub-styles. But over time, this is where I think you might want to remove the default behavior of zprint in cases where you don't want to simply replace it.

But the question is real. As an example, take assoc. zprint currently formats assoc as an :arg1-pair. This means several things:

1. If it fits on one line, and has no more than three arguments, it will format on one line.
2. If it formats on multiple lines, the first argument is on the same line as assoc if at all possible.
3. If it formats on multiple lines, each key-value pair will format on their own line.

Thus:

(czprint i229t ps)
(assoc my-map :key1 :val1)

(czprint i229s ps)
(assoc my-map
  :key1 :val1
  :key2 :val2)

This is sort of a small thing, but it may or may not fit into what you want to do. There are a number of :pair things, for instance.

[vemv]

Thanks for bringing up the topic. Probably indeed there will be a number of things that I'd like to remove.

At the same time it's probably not urgent. I'd trust that rules generally can be added, removed, etc and the result would still compose nicely.

Anyway, I'm curious, would it be feasible to leave a nearly empty config map - with just :semantic and a few essentials? That would seem a "stable API" of sorts, i.e. new unrelated rules wouldn't affect :semantic.

[kkinnear]

I'm not sure what you mean by a "nearly empty config map". My expectation is that there will be a :semantic style that really has no particularly detailed configuration, but just "invokes" a bunch of other styles. These other "sub-styles", are full-blown styles that anyone can use independently of being combined into the :semantic style.

The config map is large because it is also documentation for what is possible to configure. There are ways to see just what is different from the default, so you don't have to look at the whole thing. I'm open to additional ideas on how to display the options map, if you have any, because it is certainly large and a lot to digest today.

[vemv]

I'm not sure what you mean by a "nearly empty config map".

I meant, would it be possible to run the :semantic preset and remove all or almost all other config? Would it produce bad formatting?

It might be a good idea to run the unit-tests with such a setup, verifying that :semantic is self-sufficient or at least that it needs a specific, known (closed) set of additional rules to work properly.

[kkinnear]

I'm going to "table" this for a while. I expect that :semantic would work fine without some of the "rules" (though I don't think of them that way). That said, there is a lot in the configuration that isn't even remotely "rules". But this is a problem for another day -- one where we have something that does what you want and I can support.

[kkinnear]

What do you want to do with multi-airity things in a defrecord or deftype or whatever?

For instance, I'm guessing that this is not what you want:

(defrecord ADefrecord [f1 f2 f3]
  AProtocol
    (doit
      ([this that] (run! println [1 2 3]) (println this))
      ([this] (doit [this nil])))

    (dothat [this that])

    (domore [this that])

  AnotherProtocol
    (xdoit [this])

    (xdothat [this that])

    (xdomore [this that]))

I expect that you would like the multi-airity doit to be formatted like :rod, like this:

(defrecord ADefrecord [f1 f2 f3]
  AProtocol
    (doit
      ([this that] 
       (run! println [1 2 3]) (println this))

      ([this] 
       (doit [this nil])))

    (dothat [this that])

    (domore [this that])

  AnotherProtocol
    (xdoit [this])

    (xdothat [this that])

    (xdomore [this that]))

But I don't really know what you have in mind here. This isn't a trivial question, as the first is what comes out today. The second example I have hand-edited. I will have to work to make that happen, but if that is what you want, I'll figure it out. I have some ideas on how to do that.

[vemv]

The correct formatting, as far as indentation goes, would be identical to that emitted by clojure-mode:

(defrecord ADefrecord [f1 f2 f3]
  AProtocol
  (doit
    ([this that]
     (run! println [1 2 3])
     (println this))
    
    ([this]
     (doit [this nil])))
  
  (dothat [this that])

  (domore [this that])
  
  AnotherProtocol
  (xdoit [this])
  
  (xdothat [this that])
  
  (xdomore [this that]))

I agree in (always) placing a newline after (doit i.e. after a function name that will have multiple arities.

[vemv]

Getting back to the discussion ASAP, apologies for the delay and thanks so much for the news!

[vemv]

@kkinnear Finally I got a good chance to reply. I went post by post. Guess the GH Discussions format was handy here as we're having threads!

Sorry again for the delay, I had to sprint at work for a few weeks.

[kkinnear]

No problem. I've been busy too -- I implemented :hiccup and ':html` output that someone requested.

That said, how (if at all) would you like to get access to what I've done prior to my releasing it so you could see if I've understood and actually implemented what you are looking for? I could either push the code to GitHub, and you could build the library, or I could push an alpha library (or likely multiple libraries) to clojars.

This wouldn't be tomorrow, as I have to figure out how to do the defrecord thing above for sure, and there might be one or two other things I have to do before I could give you something to try, so it will be a while (hopefully a short while) before I have something for you to play with.

[vemv]

I'm comfortable building artifacts locally, thanks!

This wouldn't be tomorrow, as I have to figure out how to do the defrecord thing above for sure, and there might be one or two other things I have to do before I could give you something to try, so it will be a while (hopefully a short while) before I have something for you to play with.

Will be pleased to try out the latest refinements, looking forward 🍻

[kkinnear]

I have something for you to try. I'm sure that it isn't exactly what you want, but it does do most of the concrete things that you wrote up in 1.1 through 1.8 originally. Here is how you get/use it:

1. I created a branch called semantic in the zprint repo on GitHub. You need to clone/fork/whatever the repo and get that branch.
2. I use leiningen for most things. lein clean and lein install will get you an artifact zprint "1.2.4-alpha1" in your local maven repository.
3. Open a REPL where [zprint "1.2.4-alpha1"] is available, and paste the def below into the REPL.
4. In the REPL, type (set-options! semantic) -- using whatever incantations you need to make sure set-options! comes from zprint.core.
5. Now, you have loaded all of the styles. You can try them out individually, or all together.

For instance, I've recently been spending a lot of time working on :s1.2, doing things like this:

(czprint stuff {:parse-string? true :style :s1.2})

Of course, I'm working in namespace zprint.core already.
You have a style for each of your 1.x things, and one called :sall which does them all.

There are several significant features I have implemented in the base code of zprint to make all of this work.

This includes the string alias capability you requested, which I have used in the style definitions below.

So, try it out, and let me know how this works for you.

(def semantic
  ; version 0.1.0
  ; Requires zprint 1.2.4-alpha1
  {:style-map
     {:s1.0 {:doc "Remove standard things that don't fit",
             :fn-map {"if" :none, "when" :none}},
      :s1.1 {:doc "defn and fn",
             :fn-map {"defn" [:force-nl-body {:style :rod-base}],
                      "defn-" "defn",
                      "fn" "defn"}},
      :s1.2 {:doc
               "defprotocol, defrecord, deftype, extend-type, extend-protocol",
             :fn-map {"defprotocol" [:arg1-extend {:style :s1.2-base}],
                      "defrecord" [:arg2-extend-body {:style :s1.2-base}],
                      "deftype" "defrecord",
                      "extend-type" "defprotocol",
                      "extend-protocol" "defprotocol"}},
      :s1.2-base {:doc "Common code for extend things",
                  :extend {:nl-count 2, :nl-separator? true, :indent 0},
                  :fn-force-nl #{:fn},
                  :fn-type-map {:fn [:force-nl-body {:style :rod-base}],
                                #_[:none
                                   {:list {:option-fn (partial rodfn
                                                               {:multi-arity-nl?
                                                                  true})}}]},
                  :next-inner {:next-inner {:fn-type-map {:fn nil}}}},
      :s1.3 {:doc "defmethod",
             :fn-map {"defmethod" [:guided-body
                                   {:guide [:element :element-best
                                            :element-best-first
                                            :element-best-first :newline
                                            :element-newline-best-*]}]}},
      :s1.4 {:doc "if, if-not",
             :fn-map {"if" :arg1-force-nl-body, "if-not" "if"}},
      :s1.5 {:doc "macros like when, many more to do",
             :fn-map {"when" :arg1-force-nl-body, "when-not" "when"}},
      :s1.6 {:doc "=, not=, or, and, <, >, <=, >=",
             :fn-map {"=" [:hang
                           {:fn-force-nl #{:hang},
                            :next-inner-restore [[[:fn-force-nl] :hang]]}],
                      "not=" "=",
                      "or" "=",
                      "and" "=",
                      "<" "=",
                      ">" "=",
                      "<=" "=",
                      ">=" "="}},
      :s1.7 {:doc "->, ->>", :remove {:fn-force-nl #{:noarg1-body}}},
      :s1.8 {:doc "try, catch, finally",
             :fn-map {"try" :flow-body,
                      "catch" :arg2-force-nl-body,
                      "finally" :flow-body}},
      :sall {:doc "version 0.1.0",
             :style [:s1.0 :s1.1 :s1.2 :s1.3 :s1.4 :s1.5 :s1.6 :s1.7 :s1.8]}}})

[vemv]

@kkinnear : trying this out.

In the meantime it seems worthwhile to merge master into semantic? I tried to and there were a lot of conflicts.

[kkinnear]

You can ignore the semantic branch. Everything that was in semantic is now in master and in the 1.2.4 release. So the options map I offered you, above, should work identically with the 1.2.4 release as with the previous semantic branch.

I should remove the semantic branch. As we move forward I may need to do another branch with pre-released capabilities for you to try, but that isn't today's issue.

[vemv]

Ok, so I've given it a quick pass.

A first issue that I observed is that if both :community and :sall are applied, defprotocol/extend-protocol will get 1-space indentation. I think there were similar issues in the past, but now they aren't as frequent.

Also, :extend-via-metadata true is formatting strangely:

(defprotocol ISql
  :extend-via-metadata

  true

  (execute! [this q])

  (execute-one! [this q]))

...This would seem a reasonable "rule":

(defprotocol ISql
  :extend-via-metadata true
  :other-option true
  (execute! [this q])

  (execute-one! [this q]))

i.e. options are expressed in one line each, with no surrounding blank lines.

Finally, testing (from clojure.test) is getting "function call" indentation, while one would want macro (2-space) indentation for it.

I could keep trying out :sall after getting these sorted out - sounds good?

Thanks!

[kkinnear]

Making progress.

1. I've got the indentation for the defprotocol\extend-protocol fixed -- defined a new fn-type: :arg1-extend-body. That will need a new branch for you to see it, but for now you can just assume it will be there.
2. I've got the defprotocol worked out to so this is what comes out:

 (czprint i236a {:parse-string? true :style :sall})
(defprotocol ISql
  :extend-via-metadata true
  :other-option true
  (execute! [this q])

  (execute-one! [this q]))

Also works with docstrings:

(czprint i236c {:parse-string? true :style :sall})
(defprotocol ISql
  "This is a docstring!"
  :extend-via-metadata true
  :other-option true
  (execute! "This is another docstring"
    [this q])

  (execute-one! [this q]))

But what do you want to have happen with this one?

(czprint i236d {:parse-string? true :style :sall})
(defprotocol ISql
  "This is a docstring!"
  :extend-via-metadata true
  :other-option true
  (execute! "This is another docstring"
    [this q]
    [this and q])
  (execute-one! 
    [this q]
    [this and q]
    [this and that q]))

This seems reasonable to me, but I'm generally unable to predict what you will find acceptable, so I thought I'd ask. I could see going with this, or maybe putting the docstring on the next line:

(czprint i236d {:parse-string? true :style :sall})
(defprotocol ISql
  "This is a docstring!"
  :extend-via-metadata true
  :other-option true
  (execute! 
   "This is another docstring"
    [this q]
    [this and q])
  (execute-one! 
    [this q]
    [this and q]
    [this and that q]))

Either one requires me to do something to make it work, since these aren't really the standard multiple arities and so the existing code I have doesn't work quite right.

3. For testing, it isn't defined as anything. To get what you want, you need it to be :arg1-body. Here is what you get if you do that:

 (czprint i236e {:parse-string? true :style [:community :sall]})
(testing "Arithmetic"
  (testing "with positive integers"
    (is (= 4
           (+ 2 2)))
    (is (= 7
           (+ 3 4))))
  (testing "with negative integers"
    (is (= -5
           (+ -2 -2)))                ;error here
    (is (= -1
           (+ 3 -4)))))

Once you let me know what you want for the multi-arity defprotocol, I'll fix that.

Then there are two ways to go. You can find some other problems with what you've got, or I could delete the semantic branch and make a new one so you have the changes I've just made available. I did end up changing the source, as well as the options map (and will change it more once I find out what you want for the defprotocol).

Thanks.

[vemv]

or maybe putting the docstring on the next line

This, thanks. For completeness, there should be blank linkes between methods, as usual:

(defprotocol ISql
  "This is a docstring!"
  :extend-via-metadata true
  :other-option true
  (execute!
    "This is another docstring"
    [this q]
    [this and q])

  (execute-one!
    [this q]
    [this and q]
    [this and that q]))

Then there are two ways to go.

(Whichever is most comfortable to you)

Cheers - V

[kkinnear]

Yes, thanks, I managed to lose the blank line in there. So now this is what it does:

(czprint i236d {:parse-string? true :style :sall})
(defprotocol ISql
  "This is a docstring!"
  :extend-via-metadata true
  :other-option true
  (execute!
    "This is another docstring"
    [this q]
    [this and q])

  (execute-one!
    [this q]
    [this and q]
    [this and that q]))

[vemv]

Alright! Is the semantic2 branch ready to try out?

[kkinnear]

Yes, see next thing in the discussion. You need the new option map too.

[kkinnear]

I have pushed a new branch, semantic2 to GitHub. You should be able to build something from that branch. I didn't make it -alpha anything, since I forgot I did that last time and it cost me when I went to release lein-zprint. It was also a pain during development for zprint, as I am developing in this branch (not just working with you in it). So semantic2 builds zprint 1.2.5, though when zprint 1.2.5 really releases, it will be considerably different than what semantic2 builds today. Just FYI.

Here is the associated options map:

(def semantic2
  ; version 0.1.2
  ; Requires zprint 1.2.5
  {:style-map
     {:s1.0 {:doc "Remove standard things that don't fit",
             :fn-map {"if" :none, "when" :none}},
      :s1.1 {:doc "defn and fn",
             :fn-map {"defn" [:force-nl-body {:style :rod-base}],
                      "defn-" "defn",
                      "fn" "defn"}},
      :s1.2
        {:doc "defprotocol, defrecord, deftype, extend-type, extend-protocol",
         :fn-map {"defprotocol" [:arg1-extend-body
                                 {:extend {:nl-count 2, :nl-separator? true},
                                  :list {:option-fn defprotocolguide-s},
                                  :fn-type-map {:fn :flow-body}}],
                  "defrecord" [:arg2-extend-body {:style :s1.2-base}],
                  "deftype" "defrecord",
                  "extend-type" [:arg1-extend-body {:style :s1.2-base}],
                  "extend-protocol" "extend-type"}},
      :s1.2-base {:doc "Common code for extend things",
                  :extend {:nl-count 2, :nl-separator? true, :indent 0},
                  :fn-force-nl #{:fn},
                  :fn-type-map {:fn [:force-nl-body {:style :rod-base}]},
                  :next-inner {:next-inner {:fn-type-map {:fn nil}}}},
      :s1.3 {:doc "defmethod",
             :fn-map {"defmethod" [:guided-body
                                   {:guide [:element :element-best
                                            :element-best-first
                                            :element-best-first :newline
                                            :element-newline-best-*]}]}},
      :s1.4 {:doc "if, if-not",
             :fn-map {"if" :arg1-force-nl-body, "if-not" "if"}},
      :s1.5 {:doc "macros like when, many more to do",
             :fn-map {"when" :arg1-force-nl-body, "when-not" "when"}},
      :s1.6 {:doc "=, not=, or, and, <, >, <=, >=",
             :fn-map {"=" [:hang
                           {:fn-force-nl #{:hang},
                            :next-inner-restore [[[:fn-force-nl] :hang]]}],
                      "not=" "=",
                      "or" "=",
                      "and" "=",
                      "<" "=",
                      ">" "=",
                      "<=" "=",
                      ">=" "="}},
      :s1.7 {:doc "->, ->>", :remove {:fn-force-nl #{:noarg1-body}}},
      :s1.8 {:doc "try, catch, finally",
             :fn-map {"try" :flow-body,
                      "catch" :arg2-force-nl-body,
                      "finally" :flow-body}},
      :s1.9 {:doc "other stuff", :fn-map {"testing" :arg1-body}},
      :sall {:doc "version 0.1.0",
             :style [:s1.0 :s1.1 :s1.2 :s1.3 :s1.4 :s1.5 :s1.6 :s1.7 :s1.8
                     :s1.9]}}})

Note that I created yet another style: :s1.9, in which I put the :fn-map for testing. I think of this as a miscellaneous style, where random things that don't fit anywhere else can go.

I believe that this branch and options map fix all of the problems that you have so far identified.

[vemv]

:s1.9, in which I put the :fn-map for testing

Actually I don't consider testing different from when at all i.e. it's good to put it under 1.5, with the same :arg1-force-nl-body.

Speaking of 1.5, as it docs hints it lacks many entries. Here are the main ones with an indent of 1 per clojure-mode:

(ns if if-not case cond-> cond->> when while when-not when-first doto locking fdef extend let binding loop for doseq dotimes when-let if-let when-some if-some this-as testing go-loop)

Some of them are good to remove since they have more specific rules e.g. ns, if, ,,,. Whatever causes the less trouble.

The following entries should get a similar treatment, but with indent 0 instead of indent 1:

(cond do delay future comment alt! alt!! go thread)

(I think I omitted the case for do/future etc in my original post. This "rule" is just as important as 1.5).

Full example for clarity:

;; Never correct: there should be one newline after the `delay` symbol, no matter what
(delay 1)

;; Correct
(delay
  1)

;; Incorrect
(future 1
  2)

;; Correct
(future
  1
  2)

Finally, by convention, any macro named ^with-.* also gets an indentation value of 1 i.e. when-like (unless, of course, there's an explicit rule for rule for the symbol in question). Not sure if there's regex support already.

Also, if you could include the def semantic2 somewhere in a ns, that would make iteration easier.

Thanks again!

[kkinnear]

Thanks for the update. I may just be having a slow day, so excuse me if this makes no sense. (It is very hot where I am at the moment, and as I am quite literally "off the grid", AC isn't an option.)

You mentioned two groups of functions above, those with "indent of 1" and those with an "indent of 0". Generally, zprint does an :indent of 2, but when doing :style :community, it will do an :indent of 2 for some things, and an :indent of 1 for other things. While zprint can do an :indent of 0, mostly it doesn't. So, I'm wondering if we aren't quite communicating here.

For the group above, the one starting with (ns if if-not ...), is this what you want?

;; Correct
(if 1
  2
  3)

I think of this as "body" indentation (when doing :style :community), and these get what zprint considers :indent 2.

For the second group above, the one starting with (cond do delay future ...), presumably this is what you want? (Since you gave this example for future just now):

;; Correct
(delay
  1)

;; Correct
(future
  1
  2)

I also think of this as :indent 2.

I was thinking this might be :indent 1, and maybe your indents (presumably those from Clojure-mode), and my indents might be off by one, but given both of the ones above seem to me to be my idea of :indent 2 -- I'm totally confused here.

Given the two groups above, (ns if if-not ...) and (cond do delay future ...), could you give me an example from each group with the indentation that you would like for each group? Then I'll be less confused as to what you really want.

Thanks!

[kkinnear]

Great!

While reviewing what I sent yesterday, I realized that when-first and when-let looked good even though they should not have been :arg1-force-nl-body -- they should have remained :binding. They looked good only because they had one pair in the binding vector. I've fixed that now.

One more question about a possible simplification on how to do some of this. In :s1.5 you wanted several things to be :arg1-force-nl-body. It turns out that most of them were already :arg1-body. There are a few more more :arg1-body functions as well. If you want all :arg1-body functions turned into :arg1-force-nl-body functions, there is an easy way to that without explicitly changing the function type for every function. I can just put :arg1-body into the set that says "don't ever do this function type on one line", which I already use for a bunch of function types.

Here are the functions that are already :arg1-body:

   "def" :arg1-body,
   "defmacro" :arg1-body,
   "defexpect" [:arg1-body
   "defmulti" :arg1-body,
*  "defn" :arg1-body,
*  "defn-" :arg1-body,
   "deftest" :arg1-body,
   "if" :arg1-body,
   "if-not" :arg1-body,
   "ns" :arg1-body,
   "s/def" [:arg1-body {:list {:constant-pair-min 2}}],
   "s/fdef" [:arg1-body {:list {:constant-pair-min 2}}],
   "when" :arg1-body,
   "when-not" :arg1-body,
   "with-meta" :arg1-body,
   "with-redefs-fn" :arg1-body,

I've starred defn and defn- because we already handle those differently. If I just put :arg1-body into the set :fn-force-nl, then all of these functions will act as though they are :arg1-force-nl-body without having to explicitly set every function in the :fn-map. This has several positive aspects. If one or two of those functions you want to be different, it makes sense to me to handle them explicitly.

Also this removes the need for :s1.4, since if and if-not will be caught with above change.

So, the explicit question: is it ok for all of the functions listed above that are already :arg1-body to become like they were :arg1-force-nl-body (other than defn and defn- which are handled differently already)?

[vemv]

Uhm, I'm slightly confused but it looks like you both understand what I ultimately want, and also are finding the best internals to accomplish so.

So we can go for what you're proposing, and I can just run it again in a few codebases.

We can also create unit tests for zprint - I'd be pleased to contribute simple input -> output mappings, for all of "semantic".

Other than that, I'm somewhat agnostic as for what zprint internals are used for achieving Semantic - in this case it looks like everything is implemented, so worst-case scenario, we just change some keywords here and there?

[kkinnear]

I've pushed a new branch to GitHub: semantic2. It is the development branch for zprint 1.2.5, and has the necessary features to support the semantic2 options map. That options map resides in guide.cljc, namespace 'zprint.guide. It happens to be there because it needs one of the guides from that file to correctly operate.

NOTE: I've integrated the indentation rules from :style :community into the semantic2 options map, so you should stop using :community. It had some other things that I believe would actually not be helpful to what you are trying to do.

This is what I do (at a REPL):

(use 'zprint.core :reload)
(in-ns 'zprint.core)
(use 'clojure.repl)
(use 'zprint.guide :reload)
(set-options! semantic2)
(czprint "your stuff" {:style :sall})

The only really important part is that you need only :style :sall, and that you absolutely need the new branch, as it has features and changes to the default config.cljc that are required to make semantic2 operate correctly

I would be truly delighted if you contributed a set of input -> output mappings for all of semantic. If you give them to me in a file, I'll convert them into my desired unit test approach.

Thanks.

[vemv]

Cheers. Would you like to continue the conversation as small, focused GH issues?

(I'd hope to create as few as possible, of course!)

[kkinnear]

If that is your preference, I'm ok with moving to GH issues for specific problems you encounter. If we get too many, I'll suggest we move back to this discussion, and make each new problem a top-level "comment" or "reply" or whatever. I have a few things left to discuss as we get closer to hopefully making this a permanent capability in zprint, for which I will continue to use this discussion.

[kkinnear]

Also, there are no regex rules. Somebody asked for some a long time ago, but the trouble with regex rules is that instead of a single relatively fast map lookup on every function name (or sometimes two if there is a "/" in the name), zprint would be doing multiple series of regex matches on every function name. The performance difference would probably be noticeable, though I haven't actually implemented it enough to benchmark to be sure. I do know that I've spent a lot of time working on performance, and so I've been unwilling to move backward when I can reasonably avoid it, and I imagine that regex-based rules would be a step backward. Just FYI.

[kkinnear]

I'm confused what problem you are trying to solve? Most of the clojure.core functions you wanted formatted in a particular way are already covered now -- or at least I thought they were. Are you trying to catch user defined functions that look like existing clojure.core functions and get them for format the same? Or are there a bunch of existing clojure.core or other clojure.* functions that you want to format differently that you haven't told me about, that you think regex rules or your dynamic rules will pick up? Or is this to solve some altogether different problem that I'm not seeing?

[vemv]

I'm confused what problem you are trying to solve?

I'll want to use zprint in as many codebases as possible (which have many tiny ones at work), so any formatting that would appear 'off' would be an obstacle in adoption.

Specifically, I have in mind non- clojure.core macros named with- or def*. Both appear every now and then.

And also, in a way Semantic aims to mirror a subset of clojure-mode formatting (which certainly has these regexes). Part of the point is that you would use clojure-mode intentfully and would need no invocation of zprint for things to look fine (of course zprint is still used by non-Emacs users, as a CI linter, cli tool, etc).

[kkinnear]

I didn't know you had a concrete use for some sort of pattern matching. I'll bump it up the priority list, though I still don't know when (or if) I'll actually be able to implement it. Just so I'm clear, do you need actual regex matching, or would prefix matching be sufficient. That is, if set of rules existed where the matching was clojure.string/starts-with? instead of a full regex, would that be useful?

[vemv]

Thanks!

would that be useful?

Yes, in principle. For the def case specifically, one has to take care that certain words don't match e.g. default, defer.

[kkinnear]

In the middle of the night last night I was trying to get back to sleep and starting thinking about how to do rules like regex rules in zprint. I rarely have good ideas in the middle of the night, but in this case I realized that regex rules are already possible in zprint today.

It turns out that the :fn-map has several things in it besides the names of functions. One of these optional things is a keyword :default-not-none, which is used whenever a function is looked up in the :fn-map and not found, and there is something configured for :default-not-none. If :default-not-none is configured with an :option-fn which contains a cond with a bunch of regexes, then you get regex rules.

For example:

 (czprint regexa
         {:parse-string? true,
          :fn-map {:default-not-none
                     [:none
                      {:list {:option-fn (fn ([] "rulesfn")
                                             ([options len sexpr]
                                              (let [fn-str (str (first sexpr))]
                                                (cond (re-find #"^when" fn-str) {:fn-style "when"}
                                                      :else nil))))}}]}})
(defn regexa
  "The when-tst should format like when"
  [this is a test]
  (list this is a test)
  (let [some stuff
        more stuff
        lots (when-tst stuff
               this
               needs
               to
               be
               longer
               than
               one
               lineeven
               more
               things)]
    (stuff bother)))

; This is what you get without the rules

(czprint regexa {:parse-string? true})
(defn regexa
  "The when-tst should format like when"
  [this is a test]
  (list this is a test)
  (let [some stuff
        more stuff
        lots (when-tst stuff
                       this
                       needs
                       to
                       be
                       longer
                       than
                       one
                       lineeven
                       more
                       things)]
    (stuff bother)))

So, this will mostly work today (and all of it will work when I next push semantic2). I have added the additional capability to return a :fn-style which isn't just a "normal" keyword, like :arg1-body. You can now also return a string in the :fn-style, and zprint will treat it like the alias capability you requested (and that I've implemented), where in the :fn-map you can simply say "do this function like this other function". So you can also use that in the :fn-style return of an :option-fn, as I did above.

Anyway, so regexes are possible now, and will be even more useful with the "alias" capability when I release 1.2.5.