Fork me on GitHub

This means that I don't autocomplete macros, for example, unless Compliment or clj-suitable is on classpath (in this case, I'll use their inspection libraries that will use the ClojureScript compiler environment to find macros)


Some news about "evaluate block": I've just found out that most editors highlight parenthesis in a way that's not compatible with the way Chlorine detects blocks. It became more and more confusing as soon as I tried to add more features over block detection, so I'm reverting some decisions. This means, in practice, that |(+ 1 2) will evaluate (+ 1 2) (currently is not evaluating anything) and (+ (- 1 2)| 3) will evaluate (- 1 2) (currently is evaluating the whole block)


I though the new behavior would be better integrated with Clojure semantics, but in the end it became more confusing as most editors highlight parens and that's what most users expect it'll be evaluated when you choose to "evaluate block"....


Currently |(+ 1 2) seems to execute the surrounding block and (+ 1 2)| executes 1 + 2 -- the latter was originally the case in Chlorine but then changed to surrounding block (or nothing? I can't remember) and has recently changed back, right?


It's a recent change that has caused |(+ 1 2) to no longer evaluate the form following:

  |(+ 1 2))
that evaluates the whole comment block right now and so it returns nil.


Anyways, glad to hear the proposed change so that the cursor immediately before or after a paren will execute the form inside those parens rather than the surrounding expression! Thank you!


Yes, I'll probably push a new version that'll use this new behavior (and also fix a bug) today or tomorrow 🙂


So I realize what you just wrote and will be quiet, except to note that “evaluate whatever form the cursor is currently in” is simpler than adding “except for the special cases x, y and... who knows?”. Anyway, do what you have to 🙂


The typical navigation by form in Clojure puts the cursor either immediately before or immediately after a pair of parens so that is the "natural" place to eval form. Having to navigate forward and then back up one character or navigate backward and then move forward one character for each form you want to eval is a pain, esp. when you then have to go forward (or backward) that same character in order to navigate to the next form. Suddenly you've turned eval, next form, eval, next form eval into eval, move, next form, move, eval, move, next form, move eval...


I see 🙂 Is there a way to have Chlorine highlight (subtly) what it considers the current form to be?


No, there isn't. On the old proto-repl package, there was a code that highlighted Atom's current form just before evaluation, so maybe it can be implemented 🙂


Hmm. Not that I ever felt the need to complicate my life by hacking Atom/Chlorine/whatever is involved, but it does sound like fun. And limited in scope 😄


@Matt FWIW Mauricio has made it really easy to work with Chlorine in source form so hacking on it is a very pleasant experience.

👍 4
thanks3 4

(also, BTW, your nickname here makes it almost impossible to @ you in response because it's short and generic and there are so many Matt's here that Slack can't pick you out of a list)