I’m working on https://github.com/polyfy/polylith/issues/66 in the Polylith project. In that branch we have switched to use :deps when specifying which bricks to include in a project, e.g. in the https://github.com/polyfy/polylith/blob/issue-66/projects/poly/deps.edn project. It would be nice to switch to :extra-deps even in the root https://github.com/polyfy/polylith/blob/issue-66/projects/poly/deps.edn but right now I don’t want to do that, because I use Cursive and I problem I have is that Cursive doesn’t recognise the source code that is included using :extra-deps it only works when using extra-paths . It works in other IDE:s that I have tried, e.g. Calva, because they treat everything that is accessible from the REPL as code (this is my theory at least). It would be really nice if Cursive could support this too, so that src directories will be “green” even when they are defined as`extra-deps.` If this worked then all projects, development included, could be configured in the same way which would produce less code and be more consistent. What do you think @cfleming?

Hey, has there been a regression around sending top form to REPL? It used to not send the comment block, so you could do this, where | is my caret:

(comment
  (identity coll)|)

(comment
  (identity rows))
=> nil

(identity rows)
=> [1 2 3 4 5]

In your case I'd use the send form before caret command

top form works as you'd expect inside a comment when your caret is within (identity coll)

but not when it's directly in the comment form

That's been like that ever since I use cursive correction: ever since I started sending forms to the repl in cursive 🙂.

That's interesting, in my experience cursive was aware if it was in a comment block and would not send the comment as part of the form...

Which I would have expected as that's basically the standard workflow of using rich comments...

I mean if this is the new behaviour fine, but it's pretty useful to be in a let block within a comment and not have to jump to the top most form to send it via send form before caret... I might be in the minority however 😃...

I think you misunderstand me. Probably I wasn't clear enough.

Standing here and issuing send top form:

(comment
  (identity |coll))

But if you're outside of the 'top' form you are trying to send, then from that position the correct 'top' from is indeed the comment

I use this all the time

If I'm within a let block within a comment, I'll use send top and it'll send the let

If I'm just outside (after) the let block, I need to use another command, 'send form before caret to repl'

And I haven't seen the behavior change in the past 4+ years in this regard

When would you ever want the comment form to be sent?

I don't think I'd want that but the behavior is more consistent this way imo

For a command named 'send topmost form', I'd be rather surprised if that worked like 'send form before caret' under certain conditions

this is why the principle of least surprise is a fallacy. people are surprised by different things

@imre , however, you would never get the surprise, since you wouldn't try to send the comment form. 😎

Also, with the cursor at the top level, near some form. What should be sent if top level is requested? If we think of (comment …) as creating a new top level (since no-one wants to send comment forms anyway) it can send the same thing as would be sent in the top level case. Which, I think should be something, rather than nothing.

My intention was definitely that this should work as @folcon expected, since I also can’t imagine when you’d ever want to sent the comment.

(comment
  (fire-missiles!)
  |
  (+ 1 1))

i implemented this feature in clojure-mode, and luckily emacs's idiom is last sexp almost all the time. so i would fire missles in emacs

Isn't it possible to just ignore the comment form completely? As if you were in the "root"

Treat it the same as:

(fire-missiles!)
|
(+ 1 1)

I’m not sure what would be intended, but yes, it should be treated as if the user were at top level, so probably nothing should be sent.

I did an update and the behaviour seems to be what I expected 😃...

Thanks for chiming in @cfleming 😃...