I need some zprint config examples

Oh, wow. Thanks for taking these things up for honest consideration. After having tried to bend zprint to do what I needed, I sort of concluded that it wasn’t really meant for that. I am still planning to offer it as a ”Format Document” command, supporting feeding it with a config map so that it can be used by people who have such maps and zprint in their work flows. (Format on save is tricky on VS Code because one needs to be super quick to perform it or VS Code will just skip it.) I am super happy for you opening up a discussion for seeing if something could be done in order for me to offer zprint for all the use cases in Calva Formatter.

Some of the stuff I mentioned in the CLJ Commons Formatter thread was in the context: "We are making a new formatter and need to consider its place inside the editors as well”. So not necessarily stuff that must be handled by a formatter/indenter used by Calva today. I hack my way past some limitations (even if I rather would wish to not have to do that, of course).

Let me start, like you did, with the Format Document/On save use case. I think I know how to easily do that without you having to support it in any particular way. There is one thing that would help me throw out one of my hacks is if I could be informed by zprint where the cursor should move to ”stay” in the same place in there structure after formatting. I have a regexp based hack for that today, but on my wish list is to be able to kick that out.

Using your numbering from above:

  1. I hear you about that ”keeping existing newlines” is the most challenging one on my wish list. It is also the most important one, and it goes a bit beyond keeping just newlines, as it is about some of the whitespace in general, as this, fixed, issue on cljfmt shows. Yes, I think it is that while in this "on type” mode, the formatter should be an ”indenter only” thing (and aligner/justifyer). There might be intermediate ground, of course, but we should maybe try find that in a voice call, some day? I do think I can hack my way mitigating this, now that I think about it. But my hacks tend to make things a bit brittle, is my experience, and I think formatting needs to be a really solid and reliable thing.

  2. I will experiment a bit with the info you provided. I do have a hack to mitigate this somewhat today, as mentioned above.

  3. I think with that idea you had about Calva keeping a zipper updated with the help of zprint, might be a way forward for this ”format a range only” case. But it looks a bit like this: In order to keep the formatting as you type snappy enough Calva only formats the current enclosing (by some type of brackets) form. The issue with newlines keeps me from trying out if zprint is fast enough so that the current top level form could be used. In any case I can feed the formatter with any form and deal with padding the needed indent on it, I guess. With cljfmt I can do this, however:

(cljfmt/reformat-string "    (fn []\nbar\nbaz)"
                       {:remove-surrounding-whitespace? false
                        :remove-trailing-whitespace? false
                        :remove-consecutive-blank-lines? false})
=> "    (fn []\n      bar\n      baz)"

It pads the indent from the first line on the following ones, which is sort of necessary with cljfmt, because it indents some things, but not others so I can’t do the padding myself. Doing the same thing with zprint, for reference:

(zprint-str "    (fn []\nbar\nbaz)"
            {:style :community
             :parse-string-all? true})
=> "(fn [] bar baz)"

Apropos only formatting expressions: I do have an issue filed towards Calva Formatter about being able to format non-expressions, but I am not obsessed about that yet myself, so not a blocker.

  1. I solve this like #3 today. But whatI mean with this wish is that I’d like it f I didn’t have to extract the form to be formatted, but could rely on the formatter to do this for me, given the cursor position within a larger chunk of code. (The whole text, preferably, but maybe it would have to be the current top level form, given zprint’s way of doing things?) Doing it line based does not really work, I think.

  2. I’ll have to think about this a bit. I am not a very experienced Clojure programmer and haven’t even ventured into zippers yet. But it sounds like a good idea. If I understand it correctly I would ”back” the editor with a zipper corresponding to the current text and feed this zipper (or even parts of it?) to zprint? Would zprint give me instructions on how to edit my zipper?

I’m running out of time right now. Will have to return to this. Again thanks for lending me your ear this generously!