Plugin integration for 'mini.nvim'

[pkazmier]

I'd like to work on a PR to submit tuned highlight groups for 'mini.nvim' and its 40+ modules. However, before even starting, I'm having a problem as I'm not sure I understand how the integration system is supposed to work.

Based on my cursory review, it looks like I should be able to add each to PLUGIN_MODULES. Then oasis checks to see if the plugin has been loaded by checking package.loaded, and if it has, then it requires the integration. The challenge I'm facing is that I think most people load their colorscheme very early on—well before other plugins—so the check to see if a plugin has been loaded always fails.

I'm not sure if this is a reliable means to load integrations. Catppuccin requires one to enable specific integrations in their configuration (above and beyond the ones they include by default). They do have a special auto-detection that only works if one uses 'lazy.vim' as their package manager, but I don't use 'lazy.vim' though as I've switched to the new builtin package manager in neovim 0.12+.

Any thoughts?

[uhs-robert]

You are right, you would need to add each to PLUGIN_MODULES and then it would load the highlight group for that module from the .../integrations/plugins/ directory.

On review, I think you are right that the package.loaded is not doing its job properly due to race conditions with lazy loading plugins. I have commented this out for now and will revisit it later. You can now update the plugin and proceed with any mini.nvim integrations without obstruction 😄

---

I don't like the idea of loading all integrations up front in theory, but in practice, the performance difference is less than 0.01 ms on my system, so this is a very low-priority item if it even is one at all.

As the plugin grows and incorporates more integrations, it might be worth it to revisit. Maybe the best solution is simply to defer the problem to the user by adding an opt-in table within their config for them to enable/disable integrations to load? But for now, it's probably unnecessary. What do you think?

[pkazmier]

Thank you!

Maybe the best solution is simply to defer the problem to the user by adding an opt-in table within their config for them to enable/disable integrations to load?

Yeah, that's what I was thinking as well.

[pkazmier]

Great. This works as well as I just tested. I look forward to creating a PR with 'mini.nvim' support. The nice thing about 'mini' is that all of the hl groups it defines link to out of the box hl groups for at least a default experience. Unfortunately, sometimes those just don't look good. As an example, 'mini.pick' defaults its cursor line to CursorLine, which happens to be the same color as the background of a floating window. So, in the picker, there is no visible cursor line. I'll fix those types of things.

[uhs-robert]

That sounds like a good call! I had to do that in a few places with the other integrations that I use as well. I opted just to handle the edge cases that look strange as opposed to defining all the highlight groups outright.

[pkazmier]

Exactly. I will try to minimize how many need to be defined and leverage the linked ones where possible. When I wake up tomorrow, I will start taking a look in between things.

I am really excited about this theme, it’s quite nice. I think you asked if I have a favorite yet, I haven’t really used the others as I think lagoon is simply amazing. It looks great with the languages that I use most often (lua, python, go).

Unfortunately, I spent my Xmas vacation switching everything over to Rose Pine, but then discovered your theme yesterday!! Now I need to start all over and switch everything to Oasis! It’s just too good!! Rose who?? 😀

[uhs-robert]

😂 the theme journey is a never ending one. I wasn't really satisfied till I made my own. It's a color coding system so, once you figure it out, I think it does make reading and learning other languages easier. I originally just wanted to port the desert theme from vim to nvim with a black background. After finishing, I didn't like it and decided to do blue instead. Then I thought why not the rest of the rainbow too?

Lagoon ended up being my favorite as well hence the default. Dune, Mirage, Desert, and Starlight are close followers. Then there is Sol which I use exclusively for sudo edits.

Glad you enjoy it! It's relatively new so it may still change over time. I appreciate your help.

[pkazmier]

'mini.pick' has a prompt that is part of the floating window's border, so I was looking for the correct bg color and came across an inconsistency that I did not understand. In short, c.ui.float.bg, which seemed like the obvious choice until I realized it points to ui.bg.surface, yet NormalFloat points to c.bg.mantle. Thanks.

[uhs-robert]

Good find! That is definitely a bug. Sometimes I fiddle with the theme_generator to override themes at a global level to test out a change before implementing it in the palettes. This is an instance where I tested it, liked it, but forgot to go back and update the individual palettes.

The correct float colors globally should be:

• bg: mantle
• fg: strong

I will be pushing a commit later today that resolves this; I'm making some changes in the same area for Diff and GitSigns.

[pkazmier]

Great. Looking forward to seeing all the changes (not at my computer now).

[uhs-robert]

It has been pushed! 🎉

[pkazmier]

Everything looking good! With the new c.ui.float.*, does it make sense to update the several other places in theme_generator.lua that still refer to the old hardcoded mantle and strong? For example, Pmenu could now be defined as
{ fg=c.ui.float.fg, bg=c.ui.float.bg } instead of { fg=c.fg.strong, bg=c.bg.mantle }? Or maybe it should be a link to NormalFloat instead since they are the same. Thoughts?

[uhs-robert]

Good point, I just updated Pmenu to link to "Normal Float" as they're now the same.

I looked for other instances of mantle and strong together; I didn't see any others. There are two more standalone usages of mantle but I think that's fine, as they help to explain the layering semantically.

[pkazmier]

BTW, I've completed 6 of the 'mini.nvim' plugins so far. I spent a lot of time futzing with the pmenu stuff, so I was distracted. I was thinking of creating a thread for each integration showing the before and after screenshots as well as the hl changes for your approval. Would the work for you? Then when I've finished everything, I'll submit one PR.

[uhs-robert]

That sounds good to me! Whatever is easiest for you will work for me.

You're more familiar with mini than I am, so screenshots are helpful, but I am also open to installing the plugin library and testing it out locally.

[pkazmier]

Okay, so I started posting the ones I've completed so far. I haven't touched the tabline or statusline yet, so disregard those in the screenshots. I'm just working alphabetically down the list.

[pkazmier]

Another question re: diag.ok.fg and diag.warn.fg, the current colors (in lagoon) just don't feel like they match the rest of the colorscheme. Any thoughts about using git.add and 'git.changefor those respectively? You already have alignment withdiag.error.fgandgit.add`. I noticed this as I'm trying to tune 'mini.diff' this morning, so I noticed the inconsistency. Off to work for the day and thus going radio quiet.

[uhs-robert]

Haha that's a great idea, I added the git colors just yesterday. I have been meaning to deprecate those diag colors for some time now.

I just updated the diag colors to use the terminal colors in the same way that git does:

-- Diagnostics
local diag = {
  error = { fg = terminal.bright_red, bg = visual.red },
  warn = { fg = terminal.yellow, bg = visual.yellow },
  info = { fg = terminal.bright_blue, bg = visual.blue },
  hint = { fg = terminal.bright_cyan, bg = visual.teal },
  ok = { fg = terminal.bright_green, bg = visual.green },
}

[pkazmier]

mini.clue

Shows next key clues similar to 'which-key'. I tried to use the same styling you chose for 'which-key':

Configuration

return function(_)
  return {
    MiniClueNextKey = "Statement",
    MiniClueDescGroup = "OasisSecondary",
    MiniClueDescSingle = "OasisLightPrimary",
  }
end

Screenshots

[pkazmier]

mini.cmdline

Provides auto-completion for the command line, but even cooler, is the peek ability it has when one uses ranges. This is where highlight tweaks were required.

Configuration

This only required one to ensure the background of the left-hand vertical separator had the same background as the float.

return function(c)
  return {
    MiniCmdlinePeekSep = { fg = c.fg.muted, bg = c.ui.float.bg },
  }
end

Screenshots

[pkazmier]

mini.diff

Provides git signs in the margins and an overlay that can be toggled in the buffer to see changes in buffer. One neat thing about 'mini.diff' is that it can use the line numbers for git status signs instead of consuming a sign column. These use your new git signs colors and your existing inline diff colors.

Configuration

return function(c)
  return {
    MiniDiffSignAdd = { fg = c.git.add },
    MiniDiffSignChange = { fg = c.git.change },
    MiniDiffSignDelete = { fg = c.git.delete },
  }
end

Screenshots

[pkazmier]

mini.completion

A minimal completion system that provides completion and signature help.

Configuration

return function(c)
  return {
    MiniCompletionActiveParameter = { bg = c.bg.surface },
  }
end

Screenshots

The info window looks crowded, but I normally work with a wider terminal width. Just saving bytes for these screenshots.

[pkazmier]

mini.files

A file explorer that allows you to edit buffer to perform file system operations (similar to 'oil').

Configuration

return function(c)
  return {
    MiniFilesCursorLine = "PmenuSel",
    MiniFilesBorderModified = { fg = c.ui.diag.warn.fg, bg = c.ui.float.bg },
    MiniFilesTitleFocused = { fg = c.theme.secondary, bg = c.ui.float.bg, bold = true },
  }
end

Screenshots

After deleting or adding a file, the outline changes to show you need to synchronize (commit the operation to disk). The neat thing here is that this is just a regular buffer where you can dd to delete a line / file, o to open a line and add a new file, etc ...

[pkazmier]

mini.pick

The mini picker. I like this one a lot because I don't need the preview all the time, but if I want it, I simply press <Tab>.

Configuration

return function(c)
  return {
    MiniPickBorderBusy = { fg = c.ui.diag.warn.fg, bg = c.ui.float.bg },
    MiniPickMatchCurrent = "PmenuSel",
    MiniPickMatchMarked = "Search",
    MiniPickMatchRanges = "PmenuMatch",
    MiniPickPreviewLine = { bg = c.ui.visual.bg },
    MiniPickPrompt = { fg = c.ui.float.fg, bg = c.ui.float.bg, bold = true },
    MiniPickPromptPrefix = { fg = c.ui.float.title, bg = c.ui.float.bg, bold = true },
  }
end

The original version that the discussion in this thread centered around.

return function(c)
  return {
    MiniPickBorderBusy = { fg = c.ui.diag.warn.fg, bg = c.ui.float.bg },
    MiniPickMatchCurrent = "PmenuSel",
    MiniPickMatchMarked = { fg = c.ui.float.fg, bg = c.theme.palette.primary[800] },
    MiniPickMatchRanges = "PmenuMatch",
    MiniPickPrompt = { fg = c.ui.float.fg, bg = c.ui.float.bg, bold = true },
    MiniPickPromptPrefix = { fg = c.ui.float.title, bg = c.ui.float.bg, bold = true },
  }
end

Screenshots

[uhs-robert]

These all look great so far!

What does MiniPickMatchMarked relate to? I'm curious if c.theme.palette.primary[800] is compatible across all themes. Is it the border/title?

[pkazmier]

That’s used when one marks items in the picker to process. Not at home so I can’t make a screenshot for you right now but look at this video from the other thread around 25s mark and you’ll see it. If you have other suggestions I should use for marked items, please let me know.

Screen.Recording.2026-01-04.at.3.31.29.PM.mov

[uhs-robert]

Ah! I see.

For marking an item, I might suggest something like the highlight group Search instead. It is used when searching via /, so it should be familiar to users for multiple selections. Also offers a good contrast and emphasizes importance by using the complementary color of the current palette.

• Search: Uses { fg=c.fg.strong, bg=c.ui.search.bg }

[pkazmier]

That could work, but if someone has an active search term, it's going to be highlighted in the picker as well. So then it could be hard to tell if an item has been marked vs just a preexisting search someone did. But, I guess the search term would never match the whole line, so maybe it would work. I'll make that change.

[pkazmier]

As I work on 'mini.statusline', I'm trying to settle on the look for the filename portion of the statusline. There are two options for me to consider looking at your existing codebase (all use same bg, so no question on that part):

1. Model it after StatusLine with fg as ui.border) and StatusLineNC with fg as fg.muted.
2. Model it after segment C from lualine integration where active has fg of fg.core and inactive has fg.dim assuming I understand lualine correctly as I don't use it and cannot test it.

IMO, I like option 1. Maybe the inactive fg bumped up just a tad to fg.comment. So I'm just curious what your thoughts are about standardizing between the two in existing codebase. If you do that, then I'll be consistent in 'mini.statusline' with whatever you choose.

[uhs-robert]

This will likely be the most challenging piece of the bunch. It is also kind of difficult to answer without playing with mini.statusline as I don't know how many layers the mini.statusline has. But I will try to be as thorough as I can.

My preference would be to emulate the tmux and lualine integrations as much as possible. The current StatusLine and StatusLineNC highlight groups are something I haven't looked at in months (due to my over-reliance on plugins) and are quite out of date. But tmux and lualine are up to date and share the same design philosophy.

Status Line Config

Here is a screenshot example with tmux on the very top row and lualine on the very bottom row:

Normal Mode

Handling Vim Mode

The mini.statusline may allow you to set different colors based on vim mode. If so, that`s fantastic. You can follow this guide below for each vim mode background color (these are what both lualine and tmux use):

• normal = syntax.statement
• insert = syntax.string
• command = syntax.parameter
• visual = syntax.special
• replace = syntax.operator
• terminal = syntax.type

Vim mode example:

Insert Mode

Three Layers

There are three layers to work with. You could even add a fourth by using fg.muted as a background if needed. Two of the layers are tied to the vim modes:

Lualine A	Lualine B	Lualine C
Far left/right edges	Adjacent to edges, acts as a bridge	Center and main status line bar
bg = vim mode, fg = bg.core	bg = bg.mantle, fg = vim mode	bg = bg.surface, fg = fg.core

Note

You may not need all of these. This depends on how many layers the status line has.

But the dynamic vim mode color is a really nice addition if possible.

Inactive Bar

And for inactive, it should be something like:

• Replace vim mode backgrounds with bg.mantle or bg.surface or fg.muted.
• Replace foregrounds with fg.dim or fg.muted or fg.comment, whichever looks best for the current layer.

[pkazmier]

Thank you. 'mini.statusline' does support per-mode colors, but only for the "A" segment (I'm using 'lualine' terms for you as that does not exist in 'mini.statusline'). The "B" segment is fixed as is the "C" segment. So, I used the Normal color for the "B" segment. When I did that, I can make 'mini.statusline' look very similar to 'lualine' (again, ignore the tabline as it has not been tuned yet):

With that said, I'm not a huge fan of using c.fg.core for segment "C" foreground. It feels a bit too bright for me. But while I was playing around and testing with your original StatusLine settings, I have really grown fond of this look as it really leans into the primary of the current flavor. I'll show in several flavors below:

I'll defer to you as it's your theme. If you'd like me to stick with the 'lualine' equivalent, I'll do so as I can simply adjust in my personal config.

[pkazmier]

Actually, here is my favorite version. I switched the background of segment "B" and "C" as I like the progression from BRIGHT ("A")on the left, then less bright ("B"), and then dark ("C"), and then back to less bright ("B"), and lastly BRIGHT again ("A"). It also provides more contrast between fg and bg in segment "C", so one does not have to resort to the bright white.

[uhs-robert]

👍🏻 I vote for this design.

This solves the issue I had and why I used fg.core to begin with for contrast! I agree, this does look the best. Having a second opinion on design choices is really nice 😄 thank you for your help.

I will go ahead and shift lualine, tmux, and the StatusLine highlight groups to be consistent with this design as well.

---

My only concern is that ui.border hasn't been tested as an fg for contrast accessibility (it was just meant to be a decorative element). So, it is very likely to fail AA accessibility against the light background for some themes. The highest risk themes with the primary color palette are the ones that use the color red: Desert, Sol, Rose, Midnight, and Abyss.

A safe bet, that is within the theme.primary family, would be light_primary. It offers higher contrast against the lighter backgrounds while still being distinguishable from the base primary.

• Do you think a darker color would be better here?
  • If so, then we may need to tweak the colors a bit and run some contrast checks against mantle to find a safe color that is a tad darker than the base primary.

However, I am leaning towards light_primary. I think the small lift makes it pop a bit, but not too much. Here are some screenshots of it in action:

[pkazmier]

Perfect. It looks great! I’ll make those changes to my ‘mini.statusline’ config later tonight or early morning.

[pkazmier]

mini.statusline

The 'mini.statusline' is complete. Now both 'lualine' and 'mini.statusline' look more or less similar where possible.

I just realized I started my original thread on 'mini.statusline' under the 'mini.pick' thread. Doh!

Configuration

return function(c)
  return {
    MiniStatuslineModeNormal = { bg = c.syntax.statement, fg = c.bg.core },
    MiniStatuslineModeInsert = { bg = c.syntax.string, fg = c.bg.core },
    MiniStatuslineModeCommand = { bg = c.syntax.parameter, fg = c.bg.core },
    MiniStatuslineModeVisual = { bg = c.syntax.special, fg = c.bg.core },
    MiniStatuslineModeReplace = { bg = c.syntax.operator, fg = c.bg.core },
    MiniStatuslineModeOther = { bg = c.syntax.type, fg = c.bg.core },
    MiniStatuslineDevInfo = { fg = c.syntax.statement, bg = c.bg.surface },
    MiniStatuslineFileInfo = { fg = c.syntax.statement, bg = c.bg.surface },
    MiniStatuslineFilename = { fg = c.theme.light_primary, bg = c.bg.mantle },
    MiniStatuslineInactive = { fg = c.fg.comment, bg = c.bg.surface },
  }
end

Screenshots

'mini.statusline' has the ability where certain sections are truncated based on screen width. For example, here is what the out-of-box statusline looks with a wider window:

And, if you are curious, here is my customized version of 'mini.statusline'. I like to distinguish the directory and filename visually to make it easier to see the filename. So I bolded the filename as it worked well. The other differences in my status line are how I present some of the data and I move diagnostics to the right-side.

[pkazmier]

mini.icons

An icon provider that has a fixed set of hl-groups for better alignment with a colorscheme. So I used the terminal colors, which provided a consistent color across the various flavors of oasis.

Configuration

return function(c)
  return {
    MiniIconsAzure = { fg = c.terminal.blue },
    MiniIconsBlue = { fg = c.terminal.bright_blue },
    MiniIconsCyan = { fg = c.terminal.cyan },
    MiniIconsGreen = { fg = c.terminal.green },
    MiniIconsGrey = { fg = c.terminal.white },
    MiniIconsOrange = { fg = c.terminal.bright_yellow },
    MiniIconsPurple = { fg = c.terminal.magenta },
    MiniIconsRed = { fg = c.terminal.red },
    MiniIconsYellow = { fg = c.terminal.yellow },
  }
end

Screenshots

[pkazmier]

mini.jump

'mini.jump' is a replacement for f/t motions. When you initiate a motion, it highlights all of the occurrences, which lets you continue to press f/t to move to next one. As soon as you press any other key, the highlights disappear. I.e. this is a very transient highlight. For this, it's important that the next available hops are readily visible, so I used the theme.cursor as it seemed like a good fit. I debated between theme.cursor and theme.secondary, but I felt the secondary gets lost with the rest of the syntax highlighting. I provide screenshots of both.

Configuration

return function(c)
  return {
    MiniJump = { undercurl = true, sp = c.theme.cursor },
  }
end

Screenshots

When using 'theme.cursor` instead:

When using theme.secondary instead:

[pkazmier]

mini.map

'mini.map' provides a high-level overview of the buffer and can highlight git add, change, deletes as well as diagnostics.

Configuration

return function(c)
  return {
    MiniMapNormal = { fg = c.fg.comment, bg = c.ui.float.bg },
    MiniMapSymbolCount = { fg = c.fg.comment },
  }
end

Screenshots

[pkazmier]

mini.starter

'mini.starter' is a startup screen.

Configuration

return function(c)
  return {
    MiniStarterFooter = "Comment",
    MiniStarterInactive = { fg = c.fg.muted },
    MiniStarterItemPrefix = { fg = c.theme.strong_primary, bold = true },
    MiniStarterQuery = { fg = c.theme.accent, bold = true },
    MiniStarterSection = "OasisSecondary",
  }
end

Screenshots

Start up screen:

I had typed o at this point:

[uhs-robert]

Is it possible to color the giant mini text with strong_primary? This looks great!

[pkazmier]

mini.trailspace

'mini.trailspace' highlights and allows one to remove trailing whitespace.

Configuration

return function(c)
  return {
    MiniTrailspace = { bg = c.syntax.exception },
  }
end

Screenshots

[pkazmier]

mini.tabline

'mini.tabline' provides a tabline that shows buffers and tab pages. I'm not sure if it's unique to 'mini.tabline', but it uses reverse video "look" to indicate a buffer has been modified. It also distinguishes between buffers visible and those that are hidden. And, of course, the currently selected buffer is highlighted uniquely. I've adapted this to the Oasis.

Configuration

return function(c)
  return {
    MiniTablineCurrent = { fg = c.theme.secondary, bg = c.bg.surface, bold = true },
    MiniTablineFill = "TabLineFill",
    MiniTablineHidden = "TabLine",
    MiniTablineModifiedCurrent = { fg = c.bg.core, bg = c.theme.secondary, bold = true },
    MiniTablineModifiedHidden = { fg = c.bg.core, bg = c.ui.border },
    MiniTablineModifiedVisible = { fg = c.bg.core, bg = c.ui.border, bold = true },
    MiniTablineTabpagesection = { fg = c.bg.core, bg = c.theme.accent },
    MiniTablineVisible = { fg = c.ui.border, bg = c.bg.surface, bold = true },
  }
end

Screenshots

In screenshot below, the current buffer selected is highlighted in the secondary color. You'll also notice that "dx_status.py", opened in a window, is bold whereas the other buffer names are not because they are hidden.

Here is a scenario where three of the buffers have been modified. The currently selected buffer is the secondary color. The other two represent the non-current selection. And the bold one of those means it is opened in a window, while the other is a modified hidden buffer.

And here is what it looks like when more than one tab exists. I use the accent color to call attention to it:

[pkazmier]

Okay, that concludes all of the 'mini.nvim' modules that need tuning for Oasis. Once you're comfortable with the above, let me know and I'll open a single PR with all of the integrations to provide Oasis first-class 'mini.nvim' support. Thanks for all of your help as I worked through these.

[echasnovski]

That's a nice speedup you've got there!

• For the opt out and opt in piece, I made it so users can choose which method they prefer in their config:

I see plugin integrations for all 'mini.nvim' modules separately. May I ask for them to be squashed into a single mini = true integration? The difference is subtle, but TL;DR is that I'd prefer to have 'mini.nvim' as the "main" source and not standalone plugins. Having separate integrations for modules kind of implies that they are standalone plugins. This was initially added by @pkazmier to comply with "autoload on require" approach. As it is now gone, it is not needed anymore and would also simplify this part and default config a lot.

---

I've glanced through commits and there were couple of places that caught my eye:

• Using vim.schedule will bring troubles. If plugin is needed at first redraw (like 'lualine.nvim', tabline, dashboard, etc.), this introduces flicker during startup; at least on slow-ish machines. It is kind of safe to do for plugins that are guaranteed to not be needed on first redraw, but color scheme should not be the place to decide it. I'd just do it without vim.schedule, but optimize the code as much as reasonably possible.
• Having default_enabled = true and all plugins.xxx = true is somewhat confusing. If I set default_enabled = false then it virtually conflict with plugins.xxx = true. It is a matter of taste, but I would set one of them to nil: either default_enabled (the nil is treated as "follow explicit plugins.xxx", while explicit true/false can be used to override) or plugins.xxx to (the nil means "follow default_enabled").
• I think this is equivalent to vim.tbl_deep_extend(). With some caveats about list tables.

[uhs-robert]

Thank you! Your feedback helped a lot; we were able to get the startup reduced by 50%.

May I ask for them to be squashed into a single mini = true integration?

Absolutely! I'm happy to squash those all into one mini family. I need to step away from the computer right now to do some housework, but I'll get that taken care of this week.

---

I appreciate the feedback and deep dive! I went ahead and removed the vim.schedule calls as a quick-fix (just about the same performance either way it turns out).

You're right, setting each plugin to true kind of defeats the purpose of having the quick toggle to begin with 😆. I hadn't considered that. I'm thinking of making each plugin set to nil and the user can override that with explicit true/false. This way, the global on/off switch works as expected.

As for the deep_merge function, I think that this is some leftover code that I forgot to clean up from a while back. I had written some shims to allow lua extras/ to run outside of nvim, so this should be removed.

I'll get these things taken care of in the next week. Once again, I really appreciate your help and feedback. I know giving feedback takes time, so I want you to know that your time is appreciated and that I am grateful 🙏🏻

[uhs-robert]

Busy week over here, finally found some time to tackle these outstanding issues! 🤙🏻

Updates

• Refactor: The mini plugin section of the config has been squashed into one mini = true setting.
• Fix: In config, individual plugins have all been set to nil by default.
  • nil: uses default_enabled setting.
  • true|false: enable or disable plugins individually.
• Fix: Removed the obsolete deep_merge function in exchange for vim.tbl_deep_extend().
  • All extras which require vim. functions do so via the ensure_vim_compat() shims from utils.lua

[echasnovski]

Thanks for squashing into a single mini!

It is nice to see negative diffs and more coherent setup, right? :)

[uhs-robert]

Anytime, and thanks for all the feedback!

It is nice to see negative diffs and more coherent setup, right? :)

Haha! Always, less is more. I used to do a lot of creative writing, and coding feels similar: it’s easy to add words, harder to edit and cut. But the cuts are what make it great by leaving only what's essential. We may start with 5-10 pages of material and end up only needing just one very good paragraph.