I didn't see this mapping anywhere else in the community yet, so hear me out.

A modern Neovim key mapping I see often these days is the use of <space> as a <leader> key. I believe this is coming from the need to use a lot of indirect mappings behind the leader namespace, and provide efficient access. I don't use this mapping, I feel the default leader key \ is close enough to the home row to stay where it is. However, in normal mode, the <space> key remains the largest key on the keyboard with little use in Vim.

I realized that when implementing, debugging or understanding new code, one of the most common patterns I would follow is: (1) build/run code, (2) find a bug/behavior, (3) tweak the code, (4) repeat.

While (1) and (2) mostly depend on external tooling, optimizing (3) depends on one's text editor proficiency. One way to tweak the code efficiently is by commenting out parts of the code. This allows for quickly changing the behavior, trying an old or new expression, toggling a specific unit test case, enabling/disabling a new feature, enable/disable flags.

While I don't advocate keeping commented code in final commits, commenting code in and out is a super efficient way to draft code changes. Additionally, commenting in and out code keeps all the short-term history of the code right there in the buffer. So here is my simple remap I've been using for a while now:

vim.keymap.set({"n", "v" }, "<space>", "gcc", { silent = true })

Space bar as comment-in comment-out is such a good muscle memory, I do believe I'm directly more efficient in editing code day to day. Given how rarely I see this mapping, I would advocate for more people trying this mapping in the community.

Combine it with gv (redo previous visual selection) and Treesitter text objects ac, ic to comment lines at the speed of light:

vim.keymap.set({ "x", "o" }, "ac", function()
  require "nvim-treesitter-textobjects.select".select_textobject("@comment.outer", "textobjects")
end)
vim.keymap.set({ "x", "o" }, "ic", function()
  require "nvim-treesitter-textobjects.select".select_textobject("@comment.outer", "textobjects")
end)

Few examples of work in progress code changes, or things you would not see committed. That I see myself very often do thanks how easy <space> is accessible.

Trying the setup() function instead of the init() function:

function configure()
  -- require("guttermarks").init()
  require("guttermarks").setup()
end

Temporarily disable unit test case to restrict debugging to one function:

-- T["alphabet_lower"]["is_lower"] = function(x)
--   eq(utils.is_lower(x), true)
-- end

T["alphabet_lower"]["is_upper"] = function(x)
  eq(utils.is_upper(x), false)
end

Give it a try for a week, tell me what you think!