Fork me on GitHub

anyone know if there is a way to syntax highlight the type anotations with calva? for example:

(defn hello
  [^string person]
  (+ "hello " person))
can calva syntax highlight the ^string metadata with a different color in this case or is this feature not available?


It’s not currently available, @jetrepilto. We can consider it, of course. Maybe it should be treated similarly to how we treat reader tags today? When a list-ish thing is tagged, it gets the same rainbow color as the brackets. They also get structural treatment, that metadata lacks so far…

Samuel McHugh15:07:46

Is there currently a way to specify how a form should be formatted similar to clj-kondo's lint-as key. Maybe it's a question which should be directed to cljfmt instead. I essentially just want to define formats of forms relative to existing ones, instead of in absolute terms. For example I would like manifold.deferred/let-flow to use the same formatting as clojure.core/let.

Samuel McHugh16:07:59

When I'm aliasing it doesn't seem like the formatter picks up on my config. I have to explicitly add d/let-flow [[:block 1]] to my map of indents to get it to work.


Is that indent-as-you-type or a format (`tab` key)?

Samuel McHugh09:07:04

the default formatting setup also leads to some weird formatting with key-based destructuring in a let block. It looks like the binding alignment occurs first, then the new-lining on the destructuring map. tabbing the sub-forms in order doesn’t change anything though, you’ll always end up with this weird alignment.


That doesn’t look like default formatting. Do you run with :align-associative? on?


As for the first error, try with latest cljfmt from the command line. If that behaves correctly we would learn that upgrading the rather aged version Calva is using probably fixes it.

Samuel McHugh14:07:17

:align-associative? appears to be true by default. If I override it with false tabbing doesn't do anything to the let form I described on line 1. Maybe I misunderstood the docs. To me, the defaults mean what you get if your .cljfmt.edn file is just an empty map. Maybe you're saying the defaults are the map you say to copy-paste into the file.

{:remove-surrounding-whitespace? true
 :remove-trailing-whitespace? true
 :remove-consecutive-blank-lines? false
 :insert-missing-whitespace? true
 :align-associative? false}
So the first being cljfmt defaults and the map you provide being Calva defaults. Have I understood that correctly?


I currently don’t recall what happens if you use an empty map, I must admit… But at least if you don’t have any file at all, associative alignment should be disabled by default. It is a quite experimental and buggy feature. I only use it as a command.

Samuel McHugh14:07:56

I checked with the cljfmt lein plugin v"0.8.0" and it properly flags problems with my file formatting when I use the :alias-map. I also checked v"0.6.3" which is what your fork of cljfmt is and it also works though. I'm not sure upgrading is going to solve this. I'd offer to submit a PR for upgrading but since it's off your fork and I'm not sure where all the dependencies live, I don't think I can.


There is already a PR there about this. And I have spent quite a lot of time trying to merge with newer as well. If you go that path, just know that it is a deeper rabbit hole than first impressions give away.


I think that what we might have to do for now is to drop the support for alignment (which is the only thing my fork adds). Then we could stop using a fork all together. Alignment will eventually be brought into the main cljfmt anyway, and then we can reintroduce that support. I just don’t know how disruptive this might be for some users….

Samuel McHugh15:07:10

Sorry to jump back and forth between these two issue but I think I know the reason my empty map doesn't take your default config for cljfmt. The ternary logic means that "{}" is truthy and will get chosen. So the defaultCljfmtContent doesn't get picked. Then when the "cljfmt-options" function reads the string "{}" it will say that all keys you're looking for have nil value, and therefor falsey


Sounds good. Please share!

Samuel McHugh15:07:58

Mmm maybe I’m not so sure now.

Samuel McHugh15:07:04

Regardless, I think it makes sense to either • merge the cljfmtContent into the defaultCljfmtContent . or • update the docs to make it clear that the inclusion of any cljfmt.edn will have you deviate from some of the defaults you get without it. (The docs already essentially recommends this but I think a small warning could alleviate any confusion) I’m happy to write up either PR if you let me know which you prefer.


Oh, we are not merging? I’d welcome a PR for that! Please submit an issue about it as well.

Samuel McHugh16:07:03

Will do. Another source of confusion is that cljfmtOptions is not actually cljfmt-options. It's a different fn


Yes, it’s a bit confusing. If you come up with a good name for the exported function, you are welcome to include it as part of the PR.

Samuel McHugh20:07:04

Hi @U0ETXRFEW. My git-fu is a bit weak but hopefully it's mostly there. feel free to reach out with any questions.