How do I zprint-str a string with several forms?

[PEZ]

Hello,

I'm adding a ”pretty print current form or selection” command to Calva. For when it is a selection I run into problems with that zprint-str only returns (and, I assume, formatted) the first form in the parsed string:

(zprint-str "a b" {:parse-string? true}) => "a"

How do I get all forms parsed and formatted?

[kkinnear]

You use zprint-file-str, which takes the string of an entire file (or selection). The calling sequence is (zprint-file-str string-to-format identifier options-map). This is the doc-string (which says about what I was going to say):

 (doc zprint-file-str)
-------------------------
zprint.core/zprint-file-str
([file-str zprint-specifier new-options doc-str] [file-str zprint-specifier new-options] [file-str zprint-specifier])
  Take a string, which typically holds the contents of an entire
  file, but doesn't have to, and format the entire string, outputing
  a formatted string.  It respects white space at the top level,
  while ignoring it within all top level forms (unless :indent-only,
  :respect-bl, or :respect-nl are used).  It allows comments at the
  top level, as well as in function definitions, and also supports
  ;!zprint directives at the top level. See File Comment API for
  information on ;!zprint directives. zprint-specifier is the thing
  that will be used in messages if errors are detected in ;!zprint
  directives, so it should identify the file (or other element) to
  allow the user to find the problem. new-options is an options-map
  containing options to be used when doing the formatting (and will
  be overriddden by any options in ;!zprint directives).  doc-str
  is an optional string to be used when setting the new-options
  into the configuration.

Speaking of formatting a selection, I was working on someones VSCode extension to use zprint, and at least the API that he was using took the whole file and the lines for the selection. Since zprint only really operates on "whole" expressions, that is, "top-level" expressions, zprint has a :range feature where you can give zprint line numbers and zprint will expand the lines to ensure that they encompass whole "top-level" forms. But the normal output is an entire file with just the expanded line sequence formatted. Which the VSCode extension then gave back to VSCode. But it seemed kind of dumb to hand back the whole file, so I added a capability to zprint that can be used with the input :range capability which will return just the formatted lines -- and tell you which ones they were (since they were almost certainly expanded). This probably makes the processing faster, though I don't know that for sure. It felt better, anyway.

Regardless of the how you handle the output, one nice feature of using zprint is that if you have your cursor in a function, you can just hit "format selection", and while there isn't really a selection, at least in VSCode the start and end line is the same, but zprint will expand the range to encompass the top-level function and format it. Which is pretty nice. Just point at a function and format.

Anyway, I won't go into more detail on any of this unless you are interested. I can point you at the configuration approach if you want.

[PEZ]

Thanks! 🙏 That did the trick.

BTW: I had some old rich comment code that sent forms as data to zprint-str. Using zprint-file-str instead I noticed that it also accepts this, and does the right thing with it. The doc string doesn't mention this, and maybe it should?

As for that :range feature. Very nice! I have yet to make Calva offer zprint as the formatter, but I will eventually get around to that. Then this might come in handy:

As it happens, in the Calva formatter (which uses cljfmt) I do something quite similar. Though at the point where the actual formatter gets called the :range entry has the actual range that should be formatted. The figuring out what that range should be happens elsewhere in Calva. Not sure if that makes sense. Let me try with an example:

1. The user presses TAB with the cursor in a Clojure file.
2. Calva figures out the current enclosing form (this is different from what you described, but essentially means that Calva's formatting is more local than zprint with :range) and sends that to the formatter (as :range), and the current cursor position, together with all the text of the document.
3. The formatter formats only the range and returns the new document text and a new :range for the formatted part. The formatter also figures out where the new cursor position should be (as you and I have discussed earlier 😄)
4. Calva applies the changes.

(There is actually some more things happening in 3., but I can dwell on those some later time.)

The formatter is also used by Calva Paredit to format the edited code. Here, Paredit might need to format more than just the edited code (e.g. with a barf edit) Both these uses lead to that Calva really needs to be in full control of what is formatted. So I would probably not use the :range feature of zprint. I still think it's cool, just informing about my particular use cases. Of course, if zprint would be configurable to work more like what I describe, it would be able to do so with better precision than I currently have. (I only have the strings, not the AST/zipper.) I'll probably get back to you about this once I am at the place where I go for adding the zprint formatter option to Calva.