This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-01
Channels
- # aleph (7)
- # bangalore-clj (1)
- # beginners (89)
- # boot (5)
- # clara (21)
- # cljs-dev (2)
- # cljsrn (57)
- # clojure (58)
- # clojure-austin (1)
- # clojure-conj (1)
- # clojure-italy (5)
- # clojure-losangeles (3)
- # clojure-russia (4)
- # clojure-sanfrancisco (4)
- # clojure-spec (31)
- # clojure-uk (67)
- # clojurebridge (4)
- # clojurescript (56)
- # cursive (92)
- # data-science (4)
- # datomic (15)
- # emacs (23)
- # events (1)
- # fulcro (121)
- # gorilla (2)
- # jobs-discuss (1)
- # juxt (1)
- # lambdaisland (6)
- # lumo (13)
- # off-topic (11)
- # om (1)
- # onyx (17)
- # overtone (5)
- # parinfer (9)
- # planck (3)
- # re-frame (21)
- # reagent (95)
- # ring-swagger (7)
- # spacemacs (58)
- # vim (13)
- # yada (2)
@rgdelato No, IntelliJ plugins have to use the formatting engine it provides, so it’s a custom algorithm.
Dang, that's unfortunate. I'm finding it's very tricky to work with the way other people format their code.
I’m planning a mode to make Cursive conform to external standards such as cljfmt
, but it’ll be hard to make other systems match what Cursive can do.
I can use something like zprint to enforce a format but then Cursive always changes it back.
@kenny If you have specific examples feel free to send them over, or other things you’d like to be able to configure.
Hmm, if it’s very configurable, it might be easier to just expose more knobs in Cursive.
In the meantime, if you have particular problems, send them over and I’ll see if I can help.
I really need an “anonymize this code snippet” function that replaces all the sensitive names with lorem ipsum or something.
Sure. I'll compile a list. This is the first time I'll be working with several other devs using various formats and tools, so getting the format flow correct seems important. Not sure what others are doing to avoid the "formatting tag" that can occur.
Great, let me know. I’m definitely interested in supporting formatting better since it’s really important for mixed-editor tools.
git blame
can ignore whitespace, which is helpful. But it's annoying to see basically every file change when changing a file.
By change I mean turn blue indicating that there are changes that need to be committed.
Yes but you may make several small changes in a number of files and having multiple formats in files seems wrong.
So then you either deal with the wrong feeling or you auto-format the file using Cursive thus creating "format tag."
Yeah, that’s tricky. You don’t have to reformat the whole file though, you can just reformat something like the top-level form you’ve worked on, or even a smaller unit than that if required.
It's just not really something I want to think about. I want to solve problems, not worry about my code formatting 😆
Totally agree. Anyway, I think the solution has to be some variant of zprint. While cljfmt is a very cool, succinct library, it does not come close to the amount of configuration zprint provides.
Yeah, but again I’d rather something opinionated and sensible, so that we can just get on with our lives 🙂
Yep. And I don't think strict formatting matters as much in a lisp as it would in a traditional language (e.g. Java).
That being said, the problem still isn't solved. I think part of the issue is Cursive's autoformatter is not opinionated.
For example, running autoformat on this
(assoc {} :a
"a"
:b "b")
simply aligns all the chars but does not format the code.Which is great for a number of cases. Really it seems like there should be two modes: align & format. Where format does deal with newlines.
This could be an interesting solution: - Create your zprint config - Write a lumo script to run the formatting in your current project - Assign that script to an external tool - Map external tool to a keybinding
The issue is that the formatting engine in IntelliJ is also invoked in many other circumstances, such as pressing enter (to work out where to indent the new line) etc
I’m not sure Cursive will ever allow that much control, just because I don’t think it’s sensible.
Right but IntelliJ's formatting never does anything destructive (as far as I can tell). So as long as you never invoke the autoformatter I think you'd be good.
It's useful because it has a built in "style" for https://github.com/bbatsov/clojure-style-guide.
No way I'm spending my time reading through the zprint doc and configuring everything I can.
The problem is also competing standards - CIDER now has its own specification format in metadata
Well, I think it was designed to be interoperable with cljfmt (I can’t remember if they were designed concurrently or not)
Again, Emacs has its own formatting engine which they probably need to integrate with.
Man, I’m kind of in awe of the zprint doc. I can’t imagine how long it took to write that, let alone implement it.
Haha yeah, very complex. Some documentation formatting would certainly stop scaring people away. Though what really makes me nervous is I recently ran into https://github.com/kkinnear/zprint/issues/23, which is nasty and makes me worried about how their parser is written such that the failing case is to just output nothing.
Latest version fixes it but still. I don't see how failing to parse something correctly should ever spit out nothing.
Anyway, I'll try the lumo solution and see how that goes. I'm very curious how others are solving this problem.
@ikitommi There are a couple of solutions for that. One would be to enable stubs generation for compojure.api.api
, however that might have some unexpected side effects with navigation.
The other solution would be for the doc lookup to use the open REPL if available, and fall back on the statically-determined one if not.
@wilkerlucio I’ll look into that. I’m planning a full namespace tidy, but that might be a good middle ground.
you could keep it simple, just do it when it's all plain flat and simple, otherwise ignore it
@cfleming I can inline the docs for c-api. But wanted to know if there is something coming for this as the function specs contribute to docs too.
btw, feature idea: many clojure libs (including clojure.spec, re-frame) define things with qualified keywords. It would be great if there was a shortcut “goto definition” for those. You can now say “find occurances” and there is most likely one that matter s/def
, reg-event-db
, reg-event-fx
etc. Would massively help on navigation.
@ikitommi Yeah, I’m planning to do that very soon - there’s an issue for it: https://github.com/cursive-ide/cursive/issues/1470