here is my config

I see nothing wrong with your config. I do note that you have “run with intellij project classpath” selected - have you also selected the needed profiles in the Leiningen tool window (and refreshed the project afterwards)?

thanks a lot @U08BJGV6E, I figured out by chance what the problem was. I am on ubuntu and clojure code does not compile on an encrypted file system. Normally the compilation ends up with a 'File name too long' error. I had this problem before but in this case I failed to connect the dots since I have not seen this exact error message. I tried to run lein test on the cli and this time I got the 'File name too long' error plus the error from above. So I moved the project to an unencrypted partition and the errors disappeared both for lein test and for starting a local REPL.

okay, that’s a weird one 😅

I think https://cursive-ide.com/userguide/repl.html#repl-commands is what you’re looking for

Cool! I think this is part of the answer. Now, I’m wondering if I can get the evaluation result and somehow present a menu to the user, using IntelliJ’s GUIs stuff. Something like the print below, which is from Emacs.

The result of the repl command is going to go to the repl

Got it. So I guess it’s not possible to manipulate the output and do other stuff in the editor itself. Thanks :thumbsup:

And I’m not sure there’s an easy way to access it. I’m thinking for what you want to do you’d need to write your own intellij plugin. #clj-extras-plugin does something similar, it extends Cursive’s functionality with stuff like clj-kondo integration and inline eval

Oh, that’s a good pointer. Yeah, it might require writing a plugin. If the plugin you mentioned eval stuff and presents it inline, I suppose it’s possible to do what I want. Thanks again

@U976F1AR2 if u depend on such a custom workflow, then what is your motivation for using intellij/cursive?

I don’t use cursive, I’m evaluating if integrating some functionality with editors is worth it (for making other ppl have a similar experience).

@U976F1AR2 in other words, you are looking into the Cursive features/workflow, to see how to achieve something similar in Emacs? Because I'd be interested in something like that too! What I found to be great about Cursive, compared to CIDER, are the following: 1. prints the evaluated forms into the REPL window, not just the evaluation results 2. evaluation results are pretty-printed, but with extra intelligence for long strings, which are automatically chopped up into a sequence of narrower strings 3. stack traces are also printed into the REPL window, they are unmangled and often have links back to the code (although, it's also a hindrance too, because it often obscures error messages, which might be printed several pages above) 4. stdout, stderr & REPL client errors are all printed to the same REPL window, as the evaluated expressions and their evaluation results, so i don't have to hunt them down in separate windows. (this is kinda like what u would get with any inferior process integration in Emacs, including inf-clojure) 5. it has a great compromise regarding the set of evaluation and structural navigation/editing commands, so it's not as overwhelming as CIDER, which is great for onboarding new Clojure programmers. we can save them from choice-paralysis.... (this is one of those cases, where the "less is more" principle worked well. i started to miss other evaluation options though, but only after 7 years!) 6. it's not Emacs-level customizable, BUT still have a "REPL commands" feature for extension, which can also be delivered to every developer of a project via version control. i could do similar thing with run configurations, using .dir-locals.el, but im not sure how can i distribute CIDER "extensions" in a way that they are automatically picked up by other Emacs devs. 7. the whole REPL client / REPL middleware injection is nicely kept seamless. i wish i would know more about how it works, but for beginners it's a blessing not to deal with such gory details 8. "Sync modified files" is a great feature and saves you from integrating clojure.tools.namespace/refresh into your project and making it aware of it. of course it's not as good, because it doesn't unload namespaces, but highly simplifies the workflow.

9. built-in auto-formatting is great, IF your whole team is on Cursive, because it's just there, without installing anything extra, comes with great default settings, integrated to the version control interface, so it can auto-format before committing and it only has a single keyboard shortcut, which works on the whole file or the selection. no electric-indent, indent-aggressively, reindent current form with tab (though, there is some Emacs-like TAB feature), clj-format, joker, etc etc. simply gets out of the way. it's not so great for multi-editor teams though, because no other formatting tool formats exactly the same way as Cursive 😄

Hi @U086D6TBN. > in other words, you are looking into the Cursive features/workflow, to see how to achieve something similar in Emacs? It’s actually the other way around, for a specific feature. Let me explain my use case. I use Emacs with inf-clojure. I like its simplicity and I have my own customizations that replicate some cider features, add some keybindings, etc. Now, I’m experimenting a new workflow. The basic idea is getting context-sensitive actions based on symbol at point, that is, the symbol the cursor is over (I suppose you know Emacs terminology). The actions are selected by a Clojure lib (let’s call it lib) So, for example, if the cursor is over schema.core, I can do this: • Press a keybinding • Emacs calls a lib macro passing the symbol or form at point as argument, using inf-clojure--process-response. • The lib calculates what are the apropriate actions given its put (more on that later). It returns a json. • Emacs reads the json and presents the results using completing-read, as shown in the image. Some actions examples: clojure test: run test, run last test (it holds state); ns: switch, dir, remove file: slurp function: doc, source map, vector & others: inspect, inspect tree Now, those actions are mostly already provided by editors, in a way or another. And you can obviously just call them manually anyway. So having them is, well, not impressive. However, it has a few advantages: 1) only actions that make sense for the thing at point are displayed. 2) the emacs command can be called from any buffer. It works in source code, but also in the repl. So, if there’s an ns printed in the repl, you could switch to it, to give a trivial example. 3) lib is supposed to be extensible. To extend on 3: I’m adding actions that know what the a test is an integration test (ie, uses https://github.com/nubank/state-flow, for the purposes of nubank) and provides actions for generating sequence diagram related to them. The code that generate the sequence diagrams do not reside in lib, but this workflow makes it possible to remember that it exists and call it easily. In fact, one of the motivations for lib is that even if we create great tools that are useful in a dev context, simply remembering their namespaces and libs might be hard.

In any case, I’ve used IntelliJ for a few months and I see other people using it at work, and I agree with your remarks. On 5), I was surprised that it doesn’t have a convenient way of evaluating the last sexp (or maybe I’m missed it). But then, in any case, people don’t miss it 🤷

So, that’s the motivation of my original question. I’m wondering how difficult it would be to have this workflow in intelliJ. (I could also make lib have a GUI that implemented this menu, sure, but having to switch windows and loose context would be slightly less convenient)