Fork me on GitHub

I enabled looking up the doc on ClojureDocs, but i think that i want to disable it. is there a way?


Hmm, I don’t think there is at the moment, no.


Also, why would you want to do that, @U0AD3JSHL?


It would be nice to be able to have doc lookup from a ordered set of places. One being local docs that you may have of your own notes etc for function docs.


That’s an interesting idea, actually. A few people have collections like this, e.g.


I'm pretty sure I've seen this mentioned before, but I couldn't find a GH issue for it. Is there a way to get Cursive to stop printing large data structures in the REPL? I've been working with gigantic maps and lists of maps a lot lately, and I find myself tip toeing around out of fear of accidentally printing one. If I do print one, I either have to wait a whole minute (sometimes longer) for it to finish printing or restart the REPL. If I decide to wait, the IDE becomes more and more unresponsive as more data prints. It would be fantastic if Cursive had a button similar to the Interrupt button that would stop it from finishing the print of something.


You sound very much like me. I had these exact same thoughts and questions a few months ago :) I'm still in the same situation sadly... i keep sprinkling (take 5) around my code. I even have a helper function which is roughly like (def ? (juxt count (partial take 5)))


so I can use it in both thread first and last situations


Im seriously considering adopting other editors for this kind of interactive exploratory work and do the test driven development and learning kind of work within cursive, though the testing integration is subpar in many aspects compared to the alternatives like kaocha


Yes, this is I’ll see if I can implement that for this EAP series.

❤️ 12

I was already subscribed and :thumbsup::skin-tone-2: to that haha. Somehow it didn't show up in my searches.


Would it also be useful to have a popup when this happens asking if you want to delete the partially-printed output from the output pane? It can get messy and also probably slows things down if you have a ton of unwanted output there.


Probably. Most certainly the first thing I'd do is click the trash button after it happened.


Actually, I had thought about an action to copy the last REPL output. Perhaps just a “Delete last REPL output” might be more general.


Sometimes, if I think the text print will not take that long, I'll sit there clicking the trash can while the REPL prints for 30 seconds 😩


Hehe. I have this implemented now so hopefully those days are gone. It’s not perfect, it’s tricky because there are multiple layers of asynchrony involved for performance reasons, but it should mostly work. The action is sometimes not that responsive when printing massive amounts either, but it should respond in less than 30 seconds 🙂


Woooo!!! Could you possibly know that a huge chunk of text was about to be printed?


Or that some amount has already printed and halt/prompt if the user wants it to continue?


Yes, the REPL will print everything to a string, and then the string gets passed over the REPL connection back to me. I then scan that string and pretty-print it. So I can tell if the result is going to be enormous. Would it be useful to have a max limit set and then prompt if the output is over that size?


So intervening in the printing process is hard because of the asynchrony, in particular prompting the user and waiting to see if they want to continue is difficult. I could prompt if the string I’m about to print is over, say, 5k chars or something (I’m not sure what a reasonable default for this would be, but as long as it’s configurable).


Interrupting the printing was already surprisingly tricky, pausing and resuming is well into far-too-difficult territory.


The problem with the limit would be that at that point I can’t distinguish if the result is one enormous string or a map with a million small items.


What’s the difference from an end user perspective?


Probably nothing, admittedly.


Configurable limit makes sense.


There is already a `print-length` dyn-var (or what was its name) which should be taken in to account. Since it's not on the REPL client side of the process, you can't just easily make use of it, but I would at least expect the same semantics from this setting, so we don't have to deal with another concept and setting name. On that note, would it be possible to just mirror the REPL-server-side's value of this setting on the client? At least on nREPL u could carry it in the response map, along the :ns in something like :env


Then u could pass that along to the async printing process


I also suffer often from the printing being going on in the background, so instead of slapping features on top of the problem, i would rather see ways avoiding it


I quite like the idea of a pop up if I’m trying to print something huge. I don’t want to have to remember to set a dynamic variable in all of my projects.


In other environments it's common to show a ... at the end of the partial data, which is then clickable to see more of it. If we could do that for the pretty printed string at least, that would be great. I can also imagine having a little x in the bottom-right corner of the evaluation, which would only appear on-mouse-hover and allows to clear the last REPL input. I don't really mind to just clear my complete history; that would be good enough for me. No need to clutter the Cursive actions with yet-another non-shortcut-bound command.

👍 4

What I would find intuitive is that the killing of the pretty printing process being the same action as the interrupt evaluation


Because often I cant tell what am I waiting for. I try to interrupt the evaluation, but then it turns out that have been finished and Im just waiting for the result being prettified before anything starts printing


From what I know, the Cursive REPL output is text only. Not sure if he can add buttons like that in. I’m not opposed to using the interrupt button for this action as well. Not sure if it’d be technically feasible to differentiate which action to execute though. I also wouldn’t mind a second button if it’s necessary. This is such a big problem for me lately, any solution besides REPL restarts would be a huge win.


@U083D6HK9 what's your typical situation when this happens? What kind of data are you looking at ? I typically fall into this trap with data pulled from datomic


I agree very much with you; good UX can come later. Let's just have any solution first.


I wouldn’t say it’s common to have elidable datastructures (the clickable ...), AFAIK only unrepl supports that and that’s far from widespread. I think the very latest nREPL also has some support for it but I don’t think any clients do yet.


Replicating the various *print-...* vars locally is something I’ve also been meaning to implement. As @U086D6TBN points out I can’t use these easily, and passing them back from the server to the client is tricky. I think these would probably just end up being config flags in the IDE for client-side use.


Having the single interrupt button do both is also a good idea, I can probably do that.


I’ll fix the stupid icon problem with that button while I’m at it.


I've seen the ... recently in Atom (was it proto-repl or chlorine, I can't remember) Before that I've seen it in CIDER too; tho they have a complete result inspector too


Thanks Colin for prioritizing this exceptionally. I can't think of anything else which annoys me. Maybe the ansi escapes being escaping sometimes, when i print something with pug, but that I can totally live with


@U086D6TBN Is there an issue for the ansi escape thing? I remember discussing it at some point, but I can’t find an issue for it. When you print with pug, does it come out on the process stdout rather than over the REPL? That might explain it. Do you have a simple repro case for that I could try?


I don't remember creating a ticket for it because I couldn't easily create a minimal repro case. It happens on mostly on bigger outputs (stdout, not the result print)


Actually I have time now to look into this. I can present a repro case in a few minutes


Thanks, I’ll take a look that that.


> what's your typical situation when this happens? What kind of data are you looking at ? Sometimes it's from Datomic. Typically the info we pull from Datomic is smaller and would "only" take 30s of printing to get done with. The killer for me is pulling lazy time series data (e.g., metrics) for thousands of items and accidentally printing all of it.


Ok, it was a bit of a battle, but this is now working. Both kinds of interrupt use the same action, since it’s fundamentally a sequential action anyway (command evals in the REPL, REPL prints the value to a string and passes it back, Cursive prints it by which time the eval has usually terminated). So now interrupt will interrupt the eval if it’s still running, and interrupt the printing if it’s got to the printing stage. The action now also has an actually visible icon.


In the process, incredibly, I actually found a bug lurking in the Cursive nREPL client code which has been there for ~5 years.


Wooooo 🎉 Thank you for fixing this. It will save me so much time! That’s always fun. What was the bug?


When handling responses, I had:

(let [status (set (map keyword (:status item)))]
            (status :session-idle)
            (print/print-error state "Session idle - no current executions.\n")

            (status :interrupted)
            (print/print-error state "Evaluation interrupted.\n")
            ...etc etc...
What I hadn’t noticed was that there can be multiple statuses, but cond would only handle the first. Now it looks like:
(doseq [status (set (map keyword (:status item)))]
          (case status
            (print/print-error state "Session idle - no current executions.\n")

            (let [{:keys [id]} item]
              (print/print-error state "Evaluation interrupted.\n")
              (swap! state message-done id))


I'm moving over to a new, fresh laptop, and rebuilding my environment there. I've hit a snag; I'm trying to import my existing Cursive project, which is an umbrella project (lots of sub-modules). In the past, there was a screen where I could click "recursively search" ... that seems to be gone. I'm not sure how to proceed.


i noticed the same problem: i can no longer open and work in an umbrella project that has multiple modules in it.


Is this with leiningen or deps? Although that option should be present for both.


in my case, it’s two deps projects.


If I do New | Project from existing sources…, select either lein or deps, and then press next I get the Recursively search option:


ah, i guess there's a behavioral difference between creating new projects from existing sources and importing existing projects.


so first of all, there's no "create new project from existing sources" on the welcome window. the only two options (that are relevant here) are "create new project" and "open or import" and the latter doesn't give you the pop-up window above. second, during the import, cursive shows an information bubble saying it found deps build scripts but no deps resolution.


I see what you mean, yes. “New project from existing sources” should be the same as “open or import”, but for some reason is not. I’ll investigate that and see what I can see.


Based on this, one workaround if you want to import a huge project would be to create a small dummy project to open, then when that’s open you can use New | Project from existing sources…


IntelliJ 2020.1 w/ Cursive 1.9.1-2020.1


I was super-spare in what I installed as plugins; are there perhaps hidden dependencies on other plugins?


I found the “Recursively search” option by doing File -> New -> Project from Existing Sources. It was on the 2nd screen of the wizard.


I’m still on IntelliJ 2019.3, so that’s just for comparison