can you clarify what you mean by > pulling in a lot of things I might need what does this mean? > turn that into a jump to test.

> First is when I create the file, it seems to be created from a template. A template that I don't like very much and would like to change It's not from a template, check find-file-hook and see if you have cljr--add-ns-if-blank-clj-file in the list. If you want to make it a template, and I'm assuming you're using Doom Emacs (since you mentioned +lsp), you can add a file template. See if you have enabled :editor file-templates module.

Oh hey, didn't expect to see any answer already today :)

To clarify: > pulling in a lot of things I might need I mean optimally I'd like to refer in a large number of potentially useful things, which would vary per-project. > turn that into a jump to test. I mean that if Cider (or something) already knows where to look for a test, I'd like to be able to auto-create a file at that location if it's not there. In either case (file exists or not), I'd like to be able to jump back and forth between the related test namespace and implementation namespaces.

Hmm... I see the file templates are powered by yasnippet, which I find generally annoying to have enabled. I'll probably just stick to re-editing the test ns every time... 😅

Oh I found it!!

(defcustom cljr-clojure-test-declaration "[clojure.test :as t]"
  "The require form to use when clojure.test is in use in a clj file."
  :type 'string
  :safe #'stringp)

Sure enough! This works fine for a start:

(setq! cljr-clojure-test-declaration "[clojure.test :refer [deftest testing is]]")

Ok, I created a .dir-locals.el in my project and put this in and it works perfectly.

((clojure-mode
    (eval .
          (setq! cljr-clojure-test-declaration
                 "[clojure.test :refer [deftest testing is]]
                  [magic.script :refer [compile-python]]
                  [magic.script.passes :refer [compile-sample compile-sample* conform]]
                  [magic.script.util :refer [niceid]]
                  [pattern :refer [ok]]"))))

Good job

Thanks 🙂

So, the first time I attempted to add something like that was 2 years ago. I sent a draft patch to mailing list, asking for help and guidance. Then only a few months later someone said: "Oh, I'd be interested in having something like that"... By that time I lost interest in trying to get this done. If they had Org source hosted on GitHub/GitLab, this wouldn't be an issue at all. Their reluctance to switch from email threads & patches to Pull requests model if not slowly killing Emacs & Org-mode (and a ton of other built-in packages), definitely slowing down the progress.

Agree that it's not ideal (I made that patch last year) but not sure if hosting on GitHub would change too much. There's simply too few people and nobody is getting paid for it. So instead of an email with patch my PR would be open for 9 month.

I see that wasn't your first contribution to the Org-mode source. But still, would you share your thoughts about the process? For me (I think) that was the first attempt to suggest a change, and it wasn't very straightforward and encouraging, so my first attempt became last.

> So instead of an email with patch my PR would be open for 9 month. I disagree. It would be there in the open and someone would've picked it up and attempted to finish it. When your patch is somewhere in the mailing list, who would pick it up?

Who would even see it and know it exists?

I think it's just different and personally I would prefer GitHub as well. But that's obviously not possible because of GNU politics.

There's https://updates.orgmode.org/ that tracks patches to the mailinglist

So it's not that different in terms of discoverability. But github has everything streamlined and you know where the issues and PRs are for every project while with the mailing list you have to know where to look for each project

Right, this issue already has become generational. There's an entire generation of programmers who simply don't know how to, don't want to learn how to, and don't even care about the mailing list & patches model. And this divide would only increase and it seems to me they are not doing enough to change any of that. In a sense, Emacs has become proprietary software. It's not that you can't modify its source, it's just a hassle to get that done. Compare it with cambrian explosion of nice things for Vim in recent years. And it's all because they've simplified and streamlined the process for contributors. Not for the maintainers.

I agree. On the emacs-dev mailinglist they actually discuss about having a self hosted sourcehut as an alternative which I think would already be better but still not as nice and comfy as GitHub. At least you would have one nice view of issues and patches. I'm not a fan of debbugs.

They've been talking about "the alternative" for years. But the truth is - maintainers don't care about changing the status quo to the point of actually making that change. Contributors who don't have time to be involved in maintaining the Org codebase simply won't contribute or would find workarounds like keeping changes in their configs or creating additional packages. That all creates a somewhat unhealthy, half-ass working/broken loop. For me (as I think for most programmers) contributing to Emacs/Org-mode is not much different from contributing to some kind of proprietary project. There's too much needless politics and bureaucracy involved. Sure, I would love to make contributions, but for god sake, simplify the damn process.

@U0G75ARHC In a fit of ultra-deep-google-diving, I found that patch of yours like a year ago, and I’ve been using a (slightly modified) version of it ever since! Thanks for creating it. I even thought about bugging the mailing list about it, but…

See? That once again, proves my point. And that's how proverbial "curse of Lisp" stays in circulation. There's no friggin "curse of Lisp", it's more like Lispers not wanting to prioritize for contributors instead of maintainers.

you can see ours here: https://github.com/metabase/metabase/blob/master/.dir-locals.el

I copied it from there 😬 it's the largest clj one I know of could be a vanilla instance of my being cursed

hope not. nothing special in there. I’m not sure what the 0 means versus us using 1. That stuff is pretty arcane

that's described here https://docs.cider.mx/cider/indent_spec.html :) it works when evaled on ielm 😞 w/e, I'll use .emacs.d instead of dir-locals

did you run (hack-local-variables) to refresh your .dir-locals.el?

or restart?

@U45T93RA6 I think you should remove either the nil or clojure-mode scope, depending on if you want it evaluated in every buffer (`nil`) or only in clojure-mode. So for the eval in clojure-mode only it would be (untested):

((clojure-mode
    (eval . (put-clojure-indent 'facts 0))
    (eval . (put-clojure-indent 'fact 0))))

both tips were actually useful! first I removed the nil, and then I had to (hack-local-variables) in order for the changes to take effect

so ty 🙌

...I created a "save file" hook such that when I save .dir-locals.el, (with-current-buffer b (hack-local-variables)) will be performed for all other buffers.