Not quite stylish formatting of named arguments.

[MIvanchev]

Fipp, as well as pprint, doesn't seem to render named arguments correctly:

(foo :param1 "What a sunny day this is!"
     :param2 "Wait, which day is it again?"
     :param3 364)

Would be rendered as:

(foo
  :param1
  "What a sunny day this is!"
  :param2
  "Wait, which day is it again?"
  :param3
  364

I consider this an issue because there are well-known rules for formatting them.

[brandonbloom]

There isn't really a foolproof way to tell keyword arguments from positional arguments. If you've got a sensible heuristic, I'd consider a very simple patch via PR. Absent a PR, I'm going to close this ticket for reasons discussed below.

Since this (and similar comments) have come up before, I'm going to take this opportunity to put some of my design thoughts about Fipp in to writing: First and foremost, Fipp is a pretty printer construction kit. It comes with two pre-constructed printers: One for Edn and one for Clojure Code.

My Edn printer is intended to be fast. Fast enough to use for pretty-printing large data files. If you want truly pretty data, you can use the Fipp-based https://github.com/greglook/puget/ printer, which trades some speed for features (like sorting keys in maps and colorization).

@mkremins' contributed Clojure code printer is intended to be simple. It's never going to support deep analysis, rich customization, or stuff like that. It's not a code reformatter. The primary use-case is for debugging macro-expansions. In that context, failure to meet community accepted style guidelines is perfectly acceptable and entirely expected. If somebody wanted to follow in Puget's footsteps and use Fipp to create a richly featured code-printer (maybe utilizing tools.analyzer), I'd be happy to support and promote their efforts.

That said, Fipp will always strive to provide primitives that can preserve the linear time and bounded space guarantees. That said, the code which produces the "pretty document" fed to the printing engine can trivially utilize non-linear time or unbounded space (Pudget does when sorting). I'd expect that a fully featured source beautifier may also need richer primitives to execute inside the printing engine. Such primitives would need to be considered on a case-by-case basis and any potentially-slow primitives would need a very strong justification.

[MIvanchev]

Fair enough, I had the impression Fipp was supposed to replace the source code (as in 'program') capabilities of Clojure's own pprint. My bad!

[brandonbloom]

Fipp does in fact have most of the functionality of Clojure's own pprint, which largely targets the same use case (debugging; not reformatting).

[bhurlow]

@brandonbloom thanks for linking to your discussing here from the fipp docs. I understand fipp is targeting debugging use cases and not code formatting/refactoring. Can you point to any projects that do build off fipp (like puget) to target code formatting? Perhaps there are none, either way Fipp seems like it would be a good building block towards that goal

[brandonbloom]

I'm sure some exist, but I do not make use of any of them, so I can't point you in the right direction. Sorry.

[bhurlow]

@brandonbloom fair enough thnx!