Fork me on GitHub
Alys Brooks15:04:26

How do other Conjure users handle throwaway or testing forms? For example, when I test functions, I end up re-evaluating the function with a certain set of arguments repeatedly as I evolve or test it. I realize I can do :ConjureEval . but that's not super convenient for editing. You can also add commented-out forms but those can easily get committed by mistake and clutter diffs. One solution I like is having a repl_sessions directory with useful snippets for experimenting (example: Another good option is writing tests, especially if you have tests set up to run whenever you save a file. I'd be curious to know what other ideas people have.


Most of the time, I just do the comment form thing. I've developed a rigor around being careful what I commit. I always review git status and git diff before staging, and I have git configured to show me what I'm about to commit when I use git commit to type in the commit message. I also use, which makes it visually obvious right there in Vim what changes I've made since the last commit.


For projects where I'm writing a lot more scratch code, I make a "scratch" or "user" file, and sometimes it even makes sense to exclude that file in the gitignore so that I don't have to worry about making sure I don't commit it.

Alys Brooks16:04:58

Thanks! I should probably be more aware of what I'm actually committing in general. (I review diffs before merging a PR at least, but sometimes skip that step before committing.) The other issue I have with comment forms is that if I want to keep them around for multiple commits, I have to manually select chunks to commit. I guess a Git plugin might help with that.


Or on the command line, you can use git add -p


I use comment blocks too along with vim-gitgutter, just like Dave 😉


Brain twins 🧠


Comment form and marks, using <leader>em or whatever it is to evaluate at mark. And I often commit the comment form into the business application as documentation.


ah yes, marks are super handy too!


wasn't it you @U0AHJUHJN that asked for them?


can't recall


It's been so long ago, I don't remember exactly how it went down, but I do remember taking part in conversations about that feature. I may or may not have come up with it, I honestly forget 😄


I still use it a lot!


I also have a comment form. I tend to mark a few test forms in it with ma , mb ... and keep my cursor in the defn I'm working on. My localleader is , so I use ,er to re-eval the root defn, then ,ema, ,emb ... to run the test form. Ideally then the test forms turn into a deftest, then it becomes a combo of ,er and ,tn to eval tests in my current namespace.


re: scratch files, I've been playing with using vim-projectionist to jump to a scratch file. So if the main ns is /src/my/ns.clj then the scratch is as /dev/ns_scratch.clj (alongside eg. /dev/user.clj. If it's a public project I gitignore the scratch files, but in private ones I sometimes commit this stuff since it can help teammates.


haven't quite got the .projections.json set up right for this yet.

Alys Brooks17:04:57

Ahh interesting. I've thought about something like projectionist.


I use vim-gitgutter to keep track of changes in the various buffers, and then git-fugitive when writing commits, in the mode that shows the whole diff when committing

Alys Brooks17:04:16

Projectionist is a good reminder because otherwise I'd be tempted to write something from scratch and fall down a rabbit hole.

Alys Brooks17:04:15

I like Signify for showing changed and modified lines myself because it supports Mercurial as well.


projectionist helps me avoid the weirdly strong ugh factor I have around setting up a new, properly-properly named scratch (or test) file ... wish I knew how to use it better.


I use projectionist a lot, but to jump from namespace to namespace_test


❯ cat .projections.json 
  "src/*.clj": {
    "alternate": "test/{}_test.clj",
    "type": "source",
    "template": [
      "(ns {dot|hyphenate}",
      "  {open}:author \"David Harrigan\"{close}",
      "  (:require",
      "   [ :as log]))",
      "(set! *warn-on-reflection* true)",
  "test/*_test.clj": {
    "alternate": "src/{}.clj",
    "type": "test",
    "template": [
      "(ns {dot|hyphenate}-test",
      "  {open}:author \"David Harrigan\"{close}",
      "  (:require",
      "   [expectations.clojure.test :as t :refer [defexpect expect expecting in more-> more-of]]",
      "   [{dot|hyphenate} :as sut]))",
      "(set! *warn-on-reflection* true)",


oh nice ... didn't know about template


one of these days I mean to look into how vim-rails implements :Etest, :Emodel, etc. Just one alternate with :A is nice but not quite enough. Eg per this discussion :Escratch or :Etest would be good, with :A jumping btw test and main ns.


I use comments quite a lot, but am trying to write them pretty early as proper tests and then use ,tn instead of running where the cursor is, or with marks