Implement theme and transparency functions

[bar0meter]

Added functions to enable transparency and apply themes based on terminal.

[local-cr-testing]

📝 Walkthrough

Walkthrough

Introduces terminal-aware theme selection in after/plugin/theme.lua. Adds functions to enable transparency and to choose colorscheme based on TERM_PROGRAM (iTerm.app → deus; otherwise → duskfox). Removes direct colorscheme deus call and invokes the new apply function at script end.

Changes

Cohort / File(s)	Summary
Theme configuration after/plugin/theme.lua	Replaces static colorscheme with terminal-aware flow using TERM_PROGRAM. Adds enableTransparency for highlight groups. Applies deus for iTerm, duskfox otherwise; transparency application is present but partially commented in non-iTerm path. Review env-var branching, commented logic, and highlight group coverage.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

A moonlit tweak in my Vimmy burrow,
I hop through themes from dusk to morrow.
iTerm whispers “deus” in the night,
Else “duskfox” paints the screen just right.
Transparent trails where carrots gleam—
A bunny curates the perfect theme. 🥕✨

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change by highlighting the newly added theme and transparency functions.
Description check	✅ Passed	The description accurately relates to the changes by mentioning added functions for transparency and terminal-based theme application.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

_{Comment @local-cr-testing help to get the list of available commands and usage tips.}

[local-cr-testing]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @after/plugin/theme.lua:
- Around line 49-57: Wrap each vim.cmd.colorscheme call in a protected call
(pcall) inside apply_theme_for_terminal and provide a safe fallback theme if the
requested scheme isn't installed; specifically, when applying "deus" or
"duskfox" via vim.cmd.colorscheme, call it with pcall and on failure call
vim.cmd.colorscheme again with a known-safe fallback (e.g., "default" or another
bundled theme) so missing themes won't error and break startup.

🧹 Nitpick comments (1)

after/plugin/theme.lua (1)

1-47: Apply transparency after :colorscheme (and re-apply on ColorScheme) to avoid being overwritten.

Right now enableTransparency() (even if uncommented) is called in the same branch after vim.cmd.colorscheme("duskfox") (good), but it won’t persist if the user changes colorscheme later, and the function mixes "none"/"NONE" plus hard-coded fg that may clash across themes.

Proposed refactor: make transparency consistent + auto re-apply

 local function enableTransparency()
-        vim.api.nvim_set_hl(0, "Normal", { bg = "none" })
+        vim.api.nvim_set_hl(0, "Normal", { bg = "NONE" })
         vim.api.nvim_set_hl(0, "NormalFloat", { bg = "none" })
         vim.api.nvim_set_hl(0, "FloatBorder", { bg = "none" })
@@
-        vim.api.nvim_set_hl(0, "LineNr", { bg = "none", fg = "#5c6370" })
+        -- Consider avoiding hard-coded fg so it adapts to theme palettes
+        vim.api.nvim_set_hl(0, "LineNr", { bg = "NONE" })
@@
 end
+
+local function setup_transparency_autocmd()
+        local group = vim.api.nvim_create_augroup("ThemeTransparency", { clear = true })
+        vim.api.nvim_create_autocmd("ColorScheme", {
+                group = group,
+                callback = enableTransparency,
+        })
+end

📜 Review details

Configuration used: Environment YAML

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7ac7683 and caede56.

📒 Files selected for processing (1)

• after/plugin/theme.lua

🔇 Additional comments (1)

after/plugin/theme.lua (1)

59-59: Nice simple entrypoint; consider keeping it idempotent if sourced multiple times.

Direct invocation is fine in after/plugin/*; just ensure any future additions (e.g., autocmd creation) use augroups/clear to avoid duplicates.

[local-cr-testing]

⚠️ Potential issue | 🟠 Major

Guard vim.cmd.colorscheme(...) with pcall + fallback to prevent startup/config breakage when a theme isn’t installed.

If deus or duskfox isn’t available, this will throw and stop sourcing this plugin file.

Proposed fix: safe theme selection with fallback

 local function apply_theme_for_terminal()
         local term_program = vim.env.TERM_PROGRAM or ""
-        if term_program == "iTerm.app" then
-                vim.cmd.colorscheme("deus")
-        else
-                vim.cmd.colorscheme("duskfox")
-                -- enableTransparency()
-        end
+        local ok = false
+        if term_program == "iTerm.app" then
+                ok = pcall(vim.cmd.colorscheme, "deus")
+        else
+                ok = pcall(vim.cmd.colorscheme, "duskfox")
+        end
+
+        if not ok then
+                pcall(vim.cmd.colorscheme, "default")
+        end
+
+        -- If you want transparency, call it here so it always runs after colorscheme:
+        -- enableTransparency()
 end

🤖 Prompt for AI Agents

In @after/plugin/theme.lua around lines 49 - 57, Wrap each vim.cmd.colorscheme
call in a protected call (pcall) inside apply_theme_for_terminal and provide a
safe fallback theme if the requested scheme isn't installed; specifically, when
applying "deus" or "duskfox" via vim.cmd.colorscheme, call it with pcall and on
failure call vim.cmd.colorscheme again with a known-safe fallback (e.g.,
"default" or another bundled theme) so missing themes won't error and break
startup.