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 https://github.com/airblade/vim-gitgutter, 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.

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.

I use https://github.com/jreybert/vimagit for that - works nicely!

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 wrote about that awesome feature here: https://blog.djy.io/conjuring-clojure-in-vim-2020-edition/#casting-spells

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.

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

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

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",
      "   [clojure.tools.logging :as log]))",
      "",
      "(set! *warn-on-reflection* true)",
      "",
      ";; PRIVATE FUNCTIONS AND DEFINITIONS ↓",
      "",
      ";; PUBLIC FUNCTIONS AND DEFINITIONS ↓",
      ""
    ]
  },
  "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)",
      "",
      ";; PRIVATE FUNCTIONS AND DEFINITIONS ↓",
      "",
      ";; PUBLIC FUNCTIONS AND DEFINITIONS ↓",
      ""
    ]
  }
}

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