This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # atlanta-clojurians (8)
- # beginners (103)
- # boot (22)
- # boot-dev (1)
- # cider (36)
- # cljs-dev (55)
- # cljsrn (3)
- # clojars (25)
- # clojure (104)
- # clojure-brasil (1)
- # clojure-dusseldorf (2)
- # clojure-italy (8)
- # clojure-norway (9)
- # clojure-russia (15)
- # clojure-spec (6)
- # clojure-uk (26)
- # clojurescript (246)
- # cursive (26)
- # data-science (1)
- # datomic (22)
- # dirac (11)
- # editors (1)
- # emacs (8)
- # fulcro (50)
- # graphql (11)
- # hoplon (1)
- # jobs-discuss (27)
- # leiningen (44)
- # luminus (33)
- # lumo (2)
- # mount (1)
- # off-topic (8)
- # onyx (5)
- # parinfer (4)
- # reagent (94)
- # ring-swagger (14)
- # shadow-cljs (37)
- # spacemacs (10)
- # specter (3)
- # tools-deps (4)
- # unrepl (14)
- # yada (5)
@gonewest818 I recall
macroexpand was enriching
eval somewhere. The debugging middleware was doing something similar.
Ops, I meant to write
Basically the important thing when enriching an existing middleware is to make sure the different middleware gets applied in the right order, which you specify in the middleware descriptor.
Yes, I eventually found
inspect, thanks. I am not 100% sure of the wrap- macro but I’ll work from the example and see how much I can pick up.
@pri most likely the
lein executable is not on Emacs’s exec path. However, if you’re getting something about
lein in a boot project that’s pretty puzzling. Why did you decide to customize the
boot command instead of the generic command or whatever?
> I was under the impression that it reevaluated every function in the buffer, no? @iwannaseethelight It works differently - compiles the entire file, doesn’t care about the functions in it.
Do you mean that it compiles the file but that functions in it won’t be re-instrumented?
Frankly, I don’t remember the implementation details in the debugger. I just know that evaluating forms and entire buffers is implemented differently in nREPL.
@jumblemuddle In theory the connection dispatch should work transparently based on the project you’re in and the type of the file you’re editing, but with static dispatch you can just select explicitly which connection to use.
@bozhidar as mentioned in my question, i'm not using boot or lein (a new mac or ubuntu installation) and testing via a fresh emacs + clojure-mode + inf-clojure + nodejs setup. As of now, I'm able to connect to lumo's socket repl via
lumo -n 5555 by running
M-x inf-clojure-connect, and a repl opens up in a new buffer; however I can't evaluate or load the form in the source file; in cider I'd normally evaluate via
C-x e or
inf-clojure-minor-mode is not setup or something like that. Those keybindings are coming from it.
But to start
lumo directly with
inf-clojure you’d normally modify the generic command (which is not project-specific. Don’t recall the name of the exact variable.
I assume you don’t have this in your config
(add-hook 'clojure-mode-hook #'inf-clojure-minor-mode).
Just keep in mind that this is going to interfere with
cider-mode, so be careful with this.
Maybe we should add to
inf-clojure something like CIDER’s functionality to enable its minor mode automatically when started.
I use the above every day so I can help with that and yes it cannot cohexist with cider-mode
Probably there should be a warning if you enable both of them, otherwise some people might be extremely confused.
i naively added a line in the PR have not even looked what it contains until @bozhidar pointed out that it is completely out of place
or could change the placeholder text to make it more obvious it’s to be filled in?
So the first release could be a single bullet, a “we split out functionality & migrated here” kind of thing, or could try to be more of an inventory exactly what. For now I would suggest just the one liner.
cider-test-run-ns-tests and then in the
*cider-test-report* buffer tried to do the
d diff option?
When I do it it doesn’t give me a useful diff.
basically, I have a test like:
the diff compares
(t/is (= foo (run-thing bar)))
"expected buffer" (t/is (= foo (run-thing bar))) "actual buffer" (= <foo-evaled> <fn-result-evaled>)