This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-20
Channels
- # announcements (5)
- # aws (15)
- # babashka (12)
- # beginners (87)
- # calva (13)
- # cider (16)
- # clj-kondo (4)
- # clojure (22)
- # clojure-argentina (1)
- # clojure-europe (9)
- # clojure-houston (1)
- # clojure-nl (2)
- # clojure-norway (25)
- # clojure-uk (5)
- # clojurescript (12)
- # core-typed (37)
- # cursive (15)
- # datomic (40)
- # editors (8)
- # emacs (4)
- # events (1)
- # hyperfiddle (29)
- # keechma (8)
- # leiningen (6)
- # lsp (7)
- # malli (25)
- # off-topic (26)
- # pathom (10)
- # portal (3)
- # re-frame (22)
- # reitit (1)
- # releases (1)
- # ring (2)
- # shadow-cljs (18)
- # yamlscript (1)
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?
This is relevant for static analysis. CIDER has direct access to your runtime, and does not need help with understanding macros.
Sweet, thanks!
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
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)))
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.
I wasn't able to find an existing issue on github. I can file an issue if that would be helpful.
Here's the discussion thread https://clojurians.slack.com/archives/C053AK3F9/p1710954316447099
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)
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.
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.
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)
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
.