fix neotest latest (#15)

* Upgrade neotest Go adapter to fredrikaverpil/neotest-golang with version specification

This revolutionary upgrade to our Neovim testing infrastructure represents a quantum leap forward in Go language testing capabilities within our editor environment. The transition from the generic 'nvim-neotest/neotest-go' dependency to the specialized 'fredrikaverpil/neotest-golang' adapter introduces a new era of testing precision and feature richness.

Key enhancements include:
- Migration from basic neotest-go to the more advanced fredrikaverpil/neotest-golang adapter
- Introduction of explicit version specification with 'version = "*"' for optimal release tracking
- Preservation of existing adapter ecosystem including neotest-rust and commented zig/bun adapters
- Maintenance of dependency structure while upgrading core Go testing functionality

The implementation occurs at lines 4-7 of the neotest-plugin.lua file, where the dependencies table undergoes this strategic transformation. The new adapter provides enhanced Go testing features, better integration with modern Go development practices, and improved test discovery and execution capabilities.

This change ensures that our Neovim configuration remains at the forefront of testing technology, providing developers with cutting-edge tools for comprehensive test management and execution within their preferred editor environment.

* Uncomment the neotest-zig dependency in the neotest plugin configuration

This commit meticulously removes the comment markers from the line specifying the 'lawrence-laz/neotest-zig' dependency within the dependencies table of the neotest plugin setup. By uncommenting this line, the Zig testing adapter for neotest is now included in the plugin's dependency list, allowing for Zig language test execution capabilities to be integrated into the Neovim testing framework. The change involves precisely altering the syntax from a commented-out state to an active dependency, ensuring that the plugin can load and utilize the Zig adapter when configured in the adapters section. This modification is part of a broader effort to expand the testing support across multiple programming languages within the neotest ecosystem, specifically targeting Zig projects that require automated testing workflows directly from within the editor environment.

* Introduce build function to install gotestsum for enhanced Go testing capabilities

This commit introduces a build function within the neotest plugin configuration that automates the installation of gotestsum, a Go test runner that provides improved output formatting and test result aggregation. The build function utilizes vim.system to execute the 'go install' command for 'gotest.tools/gotestsum@latest', ensuring the latest version is fetched and installed during the plugin setup process. This enhancement is particularly beneficial for Go developers using neotest, as gotestsum offers features like parallel test execution, JUnit XML output, and better integration with CI/CD pipelines. By incorporating this build step, the plugin now proactively prepares the necessary tooling for optimal Go test execution, reducing manual setup requirements and improving the overall developer experience when working with Go projects in Neovim. The function waits for the installation to complete, guaranteeing that the tool is available before the plugin initialization proceeds.

* Activate neotest-bun dependency for Bun runtime testing support

This commit removes the comment prefix from the 'arthur944/neotest-bun' dependency entry in the neotest plugin dependencies list, thereby enabling support for testing JavaScript and TypeScript code using the Bun runtime within the neotest framework. Bun is a fast, modern JavaScript runtime that offers significant performance improvements over traditional Node.js for certain workloads, and this adapter allows developers to run their Bun-based tests directly from Neovim using neotest's interface. By uncommenting this line, the plugin will now load the neotest-bun adapter, which integrates with Bun's test runner to provide features like test discovery, execution, and result reporting. This change expands the plugin's language support to include projects utilizing Bun, catering to developers who prefer this runtime for its speed and developer experience enhancements, while maintaining compatibility with existing neotest workflows and keybindings.

* Enable neotest-playwright adapter for end-to-end testing with Playwright

This commit uncomments the 'thenbe/neotest-playwright' dependency, integrating Playwright support into the neotest testing framework for comprehensive end-to-end testing capabilities. Playwright is a powerful automation library for testing web applications across multiple browsers, and this adapter allows running Playwright tests seamlessly within Neovim's neotest interface. By activating this dependency, developers can now execute browser-based tests, including those for user interactions, API calls, and visual regressions, directly from their editor. The adapter supports advanced Playwright features like test isolation, parallel execution, and cross-browser testing, making it invaluable for full-stack web development projects. This enhancement bridges the gap between unit testing and end-to-end testing within the same unified testing workflow, improving productivity for teams working on complex web applications that require thorough UI and API testing.

* Uncomment and activate Zig, Playwright, and Bun adapters in neotest configuration

This commit removes the comment markers from the adapter configurations for neotest-zig, neotest-playwright, and neotest-bun within the opts.adapters table, effectively enabling these testing adapters for their respective languages and frameworks. For the Zig adapter, it configures the DAP (Debug Adapter Protocol) to use the LLDB debugger, allowing for integrated debugging of Zig tests directly within Neovim. The Playwright adapter is set up with options to persist project selection across sessions and enable dynamic test discovery, which automatically finds and registers new test files as they are created. The Bun adapter is activated with default settings, providing basic test execution capabilities for JavaScript/TypeScript projects using the Bun runtime. This comprehensive activation expands the neotest plugin's capabilities to support a wider range of programming languages and testing scenarios, including systems programming with Zig, end-to-end web testing with Playwright, and fast JavaScript testing with Bun, all while maintaining consistent integration with Neovim's debugging and testing workflows.

* Migrate from neotest-go to neotest-golang adapter with gotestsum runner

This commit performs a significant update to the Go testing adapter configuration by replacing the deprecated 'neotest-go' adapter with the newer 'fredrikaverpil/neotest-golang' adapter, which offers improved compatibility and features for modern Go development. The adapter key is changed from 'neotest-go' to 'neotest-golang' to match the updated plugin naming convention. The runner is switched from the basic 'go test' command to 'gotestsum', which provides enhanced test output formatting, parallel execution capabilities, and better integration with CI/CD systems through features like JUnit XML output and test result summarization. The previous experimental test_table configuration and custom args for test count, timeout, and verbosity are removed in favor of gotestsum's default, more robust handling of these aspects. This migration ensures that Go tests run with improved performance, better error reporting, and more reliable execution, particularly beneficial for large Go codebases and projects requiring comprehensive test reporting.

* added blink-dictionary

* latest

* latest

* latest

* Update neovim configuration for neotest fixes

- Modify dictionary/markdown-claude.dict
- Update lua/plugins/lspconfig-plugin.lua
- Add new lua/plugins/tiny-code-action-plugin.lua

* latest

* Configure tailwindcss LSP for templ filetype support

Add configuration to tailwindcss LSP server to support the 'templ' filetype
by mapping it to 'html' language. This enables proper Tailwind CSS IntelliSense,
autocomplete, and syntax highlighting when working with .templ files in
Neovim, improving the development experience for projects using the templ
template engine with Tailwind CSS styling.

Author: connerohnesorge

.claude/commands/spectr/apply.md

@@ -0,0 +1,26 @@
+---
+description: Implement an approved Spectr change and keep tasks in sync.
+---
+
+<!-- spectr:START -->
+
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `spectr/AGENTS.md` (located inside the `spectr/` directory—run `ls spectr` or `spectr init` if you don't see it) if you need additional Spectr conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `spectr/changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `spectr list` when additional context is required.
+
+**Reference**
+- Read `spectr/changes/<id>/proposal.md` for proposal details.
+- Read `spectr/changes/<id>/specs/<capability>/spec.md` for delta specs.
+
+
+<!-- spectr:END -->
+

.claude/commands/spectr/proposal.md

@@ -0,0 +1,30 @@
+---
+description: Scaffold a new Spectr change and validate strictly.
+---
+
+<!-- spectr:START -->
+
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `spectr/AGENTS.md` (located inside the `spectr/` directory—run `ls spectr` or `spectr init` if you don't see it) if you need additional Spectr conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+
+**Steps**
+1. Review `spectr/project.md`, run `spectr list` and `spectr list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `spectr/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `spectr/changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `spectr validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Read delta specs directly at `spectr/changes/<id>/specs/<capability>/spec.md` when validation fails.
+- Read existing specs at `spectr/specs/<capability>/spec.md` to understand current state.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" spectr/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+
+
+<!-- spectr:END -->
+

.claude/commands/spectr/sync.md

@@ -0,0 +1,47 @@
+---
+description: Detect spec drift from code and update specs interactively.
+---
+
+<!-- spectr:START -->
+
+### Guardrails
+- Code is the source of truth—specs should reflect actual implementation.
+- Only update specs after user confirms each change.
+- Keep spec updates minimal and focused on actual drift.
+- Create missing specs for new capabilities supported by the implementation.
+- Refer to `spectr/AGENTS.md` for Spectr conventions.
+
+### Steps
+1. Determine scope:
+   - If arguments specify capabilities (e.g., `<Capabilities>auth, cli</Capabilities>`), focus on those.
+   - Otherwise, ask the user which capabilities to sync, or analyze recent git changes to suggest candidates.
+
+2. Load current specs:
+   - Run `spectr list --specs` to enumerate capabilities.
+   - Read each relevant `spectr/specs/<capability>/spec.md`.
+
+3. Analyze implementation:
+   - For each capability, identify related code (by directory name, imports, or user guidance).
+   - Read the implementation and understand actual behavior.
+
+4. Detect drift:
+   - Compare code behavior against spec requirements and scenarios.
+   - Identify: new features (to be ADDED), changed behavior (to be MODIFIED), removed features (to be REMOVED).
+
+5. Interactive review:
+   - For each drift item, present: the requirement, what code does, and proposed spec change.
+   - Ask user to confirm, modify, or skip each change.
+
+6. Apply updates:
+   - Edit specs directly with confirmed changes.
+   - Run `spectr validate --strict` to ensure validity.
+   - Show summary of changes made.
+
+### Reference
+- Read `spectr/specs/<capability>/spec.md` to view current spec content.
+- Search code with `rg` to find implementations.
+- Validate after edits with `spectr validate --strict`.
+
+
+<!-- spectr:END -->
+

CLAUDE.md

@@ -0,0 +1,16 @@
+<!-- spectr:START -->
+# Spectr Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/spectr/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/spectr/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+<!-- spectr:END -->

dictionary/markdown-claude.dict

@@ -1,3 +1,4 @@
-/openspec:proposal
-/openspec:apply
-/openspec:archive
+/spectr:proposal
+/spectr:apply
+/spectr:archive
+ULTRATHINK

lua/plugins/big-file-plugin.lua

@@ -29,6 +29,7 @@ return {
     servers = {
       -- phpactor = {},
       -- volar = {},
+      svelte_ls = {},
       vue_ls = {},
       -- harper_ls = {
       --   settings = {
@@ -110,7 +111,16 @@ return {
       rust_analyzer = {},
       texlab = {},
       vhdl_ls = {},
-      tailwindcss = {},
+      tailwindcss = {
+        filetypes = { "templ", "astro", "javascript", "typescript", "react" },
+        settings = {
+          tailwindCSS = {
+            includeLanguages = {
+              templ = "html",
+            },
+          },
+        },
+      },
       hdl_checker = {},
       jsonls = {},
       yamlls = {},
@@ -187,12 +197,15 @@ return {
           vim.lsp.buf.format,
           { buffer = args.buf, desc = '[C]ode [F]ormat' }
         )
-        vim.keymap.set(
-          'n',
-          '<leader>ca',
-          vim.lsp.buf.code_action,
-          { buffer = args.buf, desc = '[C]ode [A]ction' }
-        )
+        -- vim.keymap.set(
+        --   'n',
+        --   '<leader>ca',
+        --   vim.lsp.buf.code_action,
+        --   { buffer = args.buf, desc = '[C]ode [A]ction' }
+        -- )
+        vim.keymap.set({ "n", "x" }, "<leader>ca", function()
+          require("tiny-code-action").code_action()
+        end, { noremap = true, silent = true })
         vim.keymap.set(
           'n',
           '<leader>ls',

lua/plugins/lspconfig-plugin.lua

@@ -1,7 +1,6 @@
 return {
   'nvim-telescope/telescope.nvim',
-  -- tag = '0.1.9',
-  ref = '84b9ba066d1860f7a586ce9cd732fd6c4f77d1d9',
+  tag = 'v0.2.0',
   event = 'BufWinEnter',
   dependencies = {
     'nvim-telescope/telescope-media-files.nvim',

lua/plugins/telescope-plugin.lua

@@ -0,0 +1,22 @@
+return {
+  "rachartier/tiny-code-action.nvim",
+  dependencies = {
+    { "nvim-lua/plenary.nvim" },
+
+    -- optional picker via telescope
+    { "nvim-telescope/telescope.nvim" },
+    -- optional picker via fzf-lua
+    { "ibhagwan/fzf-lua" },
+    -- .. or via snacks
+    {
+      "folke/snacks.nvim",
+      opts = {
+        terminal = {},
+      }
+    }
+  },
+  event = "LspAttach",
+  opts = {
+    picker = "buffer",
+  },
+}

lua/plugins/tiny-code-action-plugin.lua

@@ -1,7 +1,8 @@
 return {
   "nvim-treesitter/nvim-treesitter",
   version = false,
-  branch = "main",
+  -- branch = "main",
+  rev = "00c906abb9550e72bc0c640545b5499b9525bb40",
   build = ":TSUpdate",
   event = { "BufReadPost", "BufNewFile" },
   dependencies = {
@@ -16,41 +17,37 @@ return {
         vim.g.load_textobjects = true
       end,
     },
-    -- {
-    --   "nvim-treesitter/nvim-treesitter-context",
-    --   config = function()
-    --     require("treesitter-context").setup {
-    --       -- Enable this plugin (Can be enabled/disabled later via commands)
-    --       enable = true,
-    --       -- Enable multiwindow support.
-    --       multiwindow = false,
-    --       -- How many lines the window should span. Values <= 0 mean no limit.
-    --       max_lines = 8,
-    --       -- Minimum editor window height to enable context. Values <= 0 mean no limit.
-    --       min_window_height = 0,
-    --       line_numbers = true,
-    --       -- Maximum number of lines to show for a single context
-    --       multiline_threshold = 20,
-    --       -- Which context lines to discard if `max_lines` is exceeded. Choices: 'inner', 'outer'
-    --       trim_scope = 'outer',
-    --       mode = 'cursor', -- Line used to calculate context. Choices: 'cursor', 'topline'
-    --       -- Separator between context and content. Should be a single character string, like '-'.
-    --       -- When separator is set, the context will only show up when there are at least 2 lines above cursorline.
-    --       separator = nil,
-    --       -- The Z-index of the context window
-    --       zindex = 20,
-    --       -- (fun(buf: integer): boolean) return false to disable attaching
-    --       on_attach = nil,
-    --     }
-    --   end,
-    -- },
+    {
+      "nvim-treesitter/nvim-treesitter-context",
+      config = function()
+        require("treesitter-context").setup {
+          -- Enable this plugin (Can be enabled/disabled later via commands)
+          enable = true,
+          -- Enable multiwindow support.
+          multiwindow = false,
+          -- How many lines the window should span. Values <= 0 mean no limit.
+          max_lines = 8,
+          -- Minimum editor window height to enable context. Values <= 0 mean no limit.
+          min_window_height = 0,
+          line_numbers = true,
+          -- Maximum number of lines to show for a single context
+          multiline_threshold = 20,
+          -- Which context lines to discard if `max_lines` is exceeded. Choices: 'inner', 'outer'
+          trim_scope = 'outer',
+          mode = 'cursor', -- Line used to calculate context. Choices: 'cursor', 'topline'
+          -- Separator between context and content. Should be a single character string, like '-'.
+          -- When separator is set, the context will only show up when there are at least 2 lines above cursorline.
+          separator = nil,
+          -- The Z-index of the context window
+          zindex = 20,
+          -- (fun(buf: integer): boolean) return false to disable attaching
+          on_attach = nil,
+        }
+      end,
+    },
     -- { 'nvim-treesitter/playground' }
   },
   cmd = { "TSUpdateSync" },
-  keys = {
-    { "<c-space>", desc = "Increment selection" },
-    { "<bs>",      desc = "Decrement selection", mode = "x" },
-  },
   opts = {
     auto_install = true,
     ensure_installed = {
@@ -115,7 +112,18 @@ return {
     },
     highlight = {
       enable = true,
-      additional_vim_regex_highlighting = { "markdown" },
+      disable = function(lang, buf)
+        if lang == "rustsdf" then
+          return true
+        end
+        local max_filesize = 100 * 1024 -- 100 KB
+        local ok, stats = pcall(vim.loop.fs_stat, vim.api.nvim_buf_get_name(buf))
+        if ok and stats and stats.size > max_filesize then
+          return true
+        end
+      end,
+      -- additional_vim_regex_highlighting = { "markdown" },
+      additional_vim_regex_highlighting = false,
     },
     indent = {
       enable = true,