Clojurians Log v2

Did evaluate-block change recently? If I place my cursor at the end of a form and call it, I'm getting back nil. For example, (+ 1 2)| returns nil instead of 3. (| represents cursor position)

@jaihindhreddy It did change but not very recently -- that change was quite a while ago.

hmm. It's been quite a while since I've fired up Atom. Was busy with other stuff.

Is there a thing now that can replicate the old behaviour?

i.e, a thing that evals the form just before the cursor

Not that I know of. I know @mauricio.szabo is aware of the change. I don't believe it was intentional, but I get the impression it's hard to fix (without breaking other stuff).

If I'm at the end of a form I want evaluated, I either hit backspace and then ctrl-; b, or ctrl-left then ctrl-; b

I understand. Also, I just noticed that evaluate-top-block doesn't ignore comment. Is this also new or was it always like this?

Always like that.

The change to eval form (at end of form) was annoying for a while but I've mostly gotten used to it. Still occasionally catches me out and invokes an eye roll :face_with_rolling_eyes:

Thank you for your help!

Probably not the answer you wanted 🙂

Yes, it was quite some time ago. The old implementation was using some Atom APIS that were difficult to test and did get confused on things like comments, strings, and so on

It also had problems with repetition of parens. I don't really remember the exact issue, but there were times when you got something like ((some-code)) that it was difficult to evaluate exactly the form you wanted

What I did fix was an issue where you wouldn't get any result if the cursor was in the end of the line and you want to evaluate "top block"

Yup. That is fixed. Can I try and contribute a version of evaluate top block that ignore comments? Just want to know if you have any disagreement with that idea itself.

@jaihindhreddy As someone who uses Rich Comment Forms a lot in my day-to-day work, I don't find that a comment often contains a single form to eval but a sequence of forms to eval step-by-step. If I want a group of expressions to be executed together, I'd wrap them in do and eval that (so I'd still have the option to eval individual forms within the do as well).

Yes, when I want to evaluate a single form inside a comment I use the comment for #_

There is already an exception to ignore this form when evaluating

If you have

(comment
  (def app (...))
  (def sys (...))
  (some complex expression using app and sys))

The thing is that there's already a bunch of rules when evaluating blocks and top blocks, I don't think adding a new one will benefit too much...

@jaihindhreddy What about the example I just gave? Three forms inside comment. Without the comment, each of those would be a separate top-level block...

huh. Yup. The way I was picturing it, the version in my head would evaluate only one of those, because it simply doesn't see the comment form. And the current one evaluates the whole thing but along with comment itself so nothing really happens.