This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # aws (30)
- # beginners (141)
- # boot-dev (3)
- # cider (48)
- # clara (35)
- # clojure (95)
- # clojure-europe (6)
- # clojure-italy (20)
- # clojure-nl (19)
- # clojure-norway (1)
- # clojure-portugal (6)
- # clojure-spec (7)
- # clojure-survey (3)
- # clojure-uk (93)
- # clojuredesign-podcast (22)
- # clojurescript (20)
- # core-async (54)
- # cursive (29)
- # datascript (1)
- # datomic (4)
- # emacs (2)
- # fulcro (10)
- # jobs (17)
- # juxt (3)
- # kaocha (20)
- # leiningen (20)
- # malli (22)
- # other-languages (7)
- # pedestal (4)
- # perun (2)
- # quil (2)
- # re-frame (7)
- # reagent (3)
- # reitit (31)
- # shadow-cljs (18)
- # spacemacs (11)
- # vim (32)
Hmm, that’s odd, the doc is HTML but it’s all wrapped in a
pre. I’ll look at that one too.
I remember why I did this now. It’s because the first line of a docstring normally has no indentation, but the others have whatever indentation the string itself has in the source code. So like this:
(defn foo "Docstring here. And here." [x] ...)
Here, the second line has 3 spaces at the start of the line. I think what I’ll do is check all the lines excluding the first, find the minimum indent of all those lines and then apply that to all of them.
Would this also fix the misalignment seen in the below screenshots? Left is the function's source and right is the quick doc view.
Just updated and the docstrings look much nicer! Looks like the latest eap did not fix the multiline args alignment.
I'm asking my students to install Cursive with Clojure CLI/deps, and several of them on Windows are having the same problem, which I don't know how to resolve.
The "Working with Deps" documentation  says to hit "refresh" in a settings panel to download the list of available options for the
tools.deps.alpha library version. But that network request seems to be consistently failing, on various Windows computers.
Anybody know what the issue might be?
Possibly relatedly, I noticed a one-time popup, maybe after installing the Cursive plugin (though I'm not sure), that said it was unable to download a JAR file, I think from Maven Central. It gave the URL. We gave that URL to a web browser and it told us that
http:// was disabled and to try
https:// instead. When we manually made that substitution in the browser, we were able to download the JAR file. Not that that helped us with whatever problem IntelliJ and/or Cursive had, though.
@U056QFNM5 That’s definitely odd. The
http:// thing sounds related, but I can’t think what that would be. I thought that everything was downloaded over HTTPS anyway.
Do you see anything in the log on the failed machines? Help->Show log in Finder/Explorer.
It shows the spinner for a split second is all.
<none> is still selected in the list, and no other options are available. No error message or anything.
Ok, so the Maven Central repo is indeed being fetched over HTTP, which seems wrong. I’ll fix that. In the meantime, you could use the “Use private repo” option, give it the id
central2 and the address
and see if that helps.
Great, thanks very much! I'll pass that along. I wonder if Maven Central recently changed their config to block http instead of redirect or something.
I suspect it’s something in your network environment, since all Cursive users are using HTTP and this is the first time I’ve ever heard of a problem with it.
(that said, that it uses HTTP by default is definitely a bug - I’ve just fixed that for the next build).
One user reports that your 'Use private repo' workaround worked. Thanks for the quick responses! I haven't noticed issues with the network before, but I wouldn't rule it out. We're on a large campus (UNC), so maybe there's some weird security policy or something.
Effective January 15, 2020, The Central Repository no longer supports insecure communication over plain HTTP and requires that all requests to the repository are encrypted over HTTPS.