Fork me on GitHub
#cider
<
2024-03-20
>
jmckitrick11:03:48

I’d like to experiment with guardrails (https://github.com/fulcrologic/guardrails) and it suggests you ‘Make sure to set your editor or IDE to resolve Guardrails’ >defn and >fdef as Clojure’s defn, and >defn- as defn- respectively – this way you get proper highlighting, formatting, error handling, structural navigation, symbol resolution, and refactoring support.' I’ve never tried this before, nor seen CIDER docs on how to do it. Has anyone else?

magnars11:03:00

This is relevant for static analysis. CIDER has direct access to your runtime, and does not need help with understanding macros.

jmckitrick11:03:00

Sweet, thanks!

Samuel Ludwig14:03:47

if you use something like clj-kondo however (which is SA), you need to add some config to the projects .clj-kondo (or do it inline) as described here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#unrecognized-macros

jmckitrick14:03:56

Perfect, I’ll need that as well.

😊 1
41ph4_Ph4un16:03:38

Has anyone had the same issue that I'm having now with Emacs + org-mode while attempting to tangle Clojure code? Tangling any clojure source block results in the expression to be wrapped with something like this (in this case the source block having (+ 1 2 3) in it:

(prn (binding [*out* (java.io.StringWriter.)](+ 1 2 3)))

phronmophobic17:03:24

Stumbled on some very curious behavior. If I evaluate an expression (eg. C-M-x cider-eval-defun-at-point) on an expression that is the last line in a buffer followed by a comment, it prints the evaluated value of the comment instead of the current form. I've attached a demonstration. The buffer is in whitespace-mode so that it's easier to tell if the form is the last line in the buffer or not. It's not really a problem for me. I just thought the behavior was interesting.

phronmophobic17:03:03

I wasn't able to find an existing issue on github. I can file an issue if that would be helpful.

vemv17:03:54

Curious behavior indeed! I reckon that it doesn't happen if there's a newline at EOF, which most people use nowadays. So probably it's not something we'd want to fix (but PRs welcome)

phronmophobic17:03:55

I reckon that it doesn't happen if there's a newline at EOF, which most people use nowadays.Yes. Adding a newline makes it work as expected as far as I can tell.

1
p4v4n16:03:33

Commenting before I forget. I looked into this last friday as it sounded familiar to a different bug and it turned out to be the case. This particular bug can probably be patched with some changes in clojure-backward-logical-sexp but the real root cause of the bug is a abstraction flaw of end-of-defun fn in emacs.

p4v4n16:03:26

There is a similar abstraction flaw in beginning-of-defun fn as well.We fixed it last year by bypassing it with clojure-beginning-of-defun and beginning-of-defun-raw.(https://github.com/clojure-emacs/clojure-mode/pull/663)

p4v4n16:03:12

The fix for replacing end-of-defun is probably more involved as we don’t have clojure-end-of-defun fn in clojure-mode and emacs doesn’t provide end-of-defun-raw.

p4v4n16:03:52

A fix would likely look something like 1. Writing clojure-end-of-defun fn + Defining end-of-defun-raw 2. Replacing end-of-defun fn with end-of-defun-raw in all clojure-emacs packages. 3. Improve test coverage as everyone assumed the end-of-defun fn behaviour as standard till now.

p4v4n16:03:33

I will look into this issue again next weekend and hopefully come up with a simpler fix/plan.