v0.3.0: deeper claudecode.nvim integration + lint fixes
- agents/companion.md: recognise three surfaces (mcp-neovim-server RPC, claudecode.nvim IDE-link, declarative NixVim config) and rule for picking between MCP-RPC vs IDE-link tools (selection/diff/diagnostics -> IDE link; everything else -> mcp__neovim__*) - skills/claude-code-handoff: document the full :ClaudeCode* command surface (SelectModel, Status, TreeAdd, partial-file Add with line range) and recommend partial-file Add over whole-buffer send - skills/editor-act: fix markdown lint issues (vim language hint on code fences, line-length on feedkeys snippet)
This commit is contained in:
oleks
+23
-30
@@ -1,32 +1,25 @@
|
||||
{
|
||||
"name": "nvim-agentic-companion",
|
||||
"version": "0.2.0",
|
||||
"description": "Neovim companion that pairs the running editor (via mcp-neovim-server) with the official Claude Code IDE plugin (coder/claudecode.nvim). Provides an opinionated agent and skills for introspecting your live nvim state (buffers, keymaps, diagnostics, plugins), driving it on your behalf (open files, run keymaps, execute lua), and handing work cleanly to the in-editor Claude Code session for buffer edits.",
|
||||
"author": {
|
||||
"name": "oleks",
|
||||
"email": "plugins@oleks.space"
|
||||
},
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
"neovim",
|
||||
"nvim",
|
||||
"claude-code",
|
||||
"mcp",
|
||||
"agentic",
|
||||
"ide"
|
||||
],
|
||||
"userConfig": {
|
||||
"nvim_socket": {
|
||||
"type": "string",
|
||||
"title": "Neovim RPC socket path",
|
||||
"description": "Unix socket where the running nvim instance is listening (must match the MCP server's NVIM_SOCKET_PATH).",
|
||||
"default": "/run/user/1000/nvim.sock"
|
||||
},
|
||||
"config_path": {
|
||||
"type": "string",
|
||||
"title": "Path to NixVim source-of-truth config",
|
||||
"description": "File path the companion treats as the canonical declarative nvim config. Used to cite where a keymap or plugin is defined.",
|
||||
"default": "/home/oleks/projects/servers/emmett/nixos/neovim.nix"
|
||||
}
|
||||
}
|
||||
"name": "nvim-agentic-companion",
|
||||
"version": "0.3.0",
|
||||
"description": "Neovim companion that pairs the running editor (via mcp-neovim-server) with the official Claude Code IDE plugin (coder/claudecode.nvim). Provides an opinionated agent and skills for introspecting your live nvim state (buffers, keymaps, diagnostics, plugins), driving it on your behalf (open files, run keymaps, execute lua), and handing work cleanly to the in-editor Claude Code session for buffer edits.",
|
||||
"author": {
|
||||
"name": "oleks",
|
||||
"email": "plugins@oleks.space"
|
||||
},
|
||||
"license": "MIT",
|
||||
"keywords": ["neovim", "nvim", "claude-code", "mcp", "agentic", "ide"],
|
||||
"userConfig": {
|
||||
"nvim_socket": {
|
||||
"type": "string",
|
||||
"title": "Neovim RPC socket path",
|
||||
"description": "Unix socket where the running nvim instance is listening (must match the MCP server's NVIM_SOCKET_PATH).",
|
||||
"default": "/run/user/1000/nvim.sock"
|
||||
},
|
||||
"config_path": {
|
||||
"type": "string",
|
||||
"title": "Path to NixVim source-of-truth config",
|
||||
"description": "File path the companion treats as the canonical declarative nvim config. Used to cite where a keymap or plugin is defined.",
|
||||
"default": "/home/oleks/projects/servers/emmett/nixos/neovim.nix"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"neovim": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "mcp-neovim-server"],
|
||||
"env": {
|
||||
"NVIM_SOCKET_PATH": "/run/user/1000/nvim.sock"
|
||||
}
|
||||
}
|
||||
}
|
||||
"mcpServers": {
|
||||
"neovim": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "mcp-neovim-server"],
|
||||
"env": {
|
||||
"NVIM_SOCKET_PATH": "/run/user/1000/nvim.sock"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
+106
-42
@@ -5,54 +5,100 @@ color: green
|
||||
tools: Bash, Read, Edit, Write, Glob, Grep, Skill, AskUserQuestion, WebFetch, WebSearch, TodoWrite, mcp__neovim__*
|
||||
---
|
||||
|
||||
You are the **nvim companion**. You sit between the user, their *running* Neovim instance, and their declarative NixVim config. Your job is to answer "how do I do X here?" with answers grounded in what is **actually loaded right now**, and to *do* X for them when that is cheaper than teaching.
|
||||
# nvim companion
|
||||
|
||||
# Two surfaces you read from
|
||||
You are the **nvim companion**. You sit between the user, their *running* Neovim
|
||||
instance, and their declarative NixVim config. Your job is to answer "how do I
|
||||
do X here?" with answers grounded in what is **actually loaded right now**, and
|
||||
to *do* X for them when that is cheaper than teaching.
|
||||
|
||||
You have access to two complementary sources of truth. Use both, and prefer the one that matches the question.
|
||||
## Surfaces you can read and act on
|
||||
|
||||
1. **Live nvim instance** — `mcp__neovim__*` tools talk to the running nvim over a Unix socket. Use this for:
|
||||
- "what's bound to `<leader>ff` *right now*?"
|
||||
- "which buffers are open?"
|
||||
- "what's the cursor at?"
|
||||
- "what's in my messages buffer?"
|
||||
- "are there LSP diagnostics in this file?"
|
||||
- any answer that depends on *runtime* state.
|
||||
You have *three* complementary surfaces. Use the one that matches the question.
|
||||
|
||||
2. **NixVim config** at `{{config_path}}` (default `/home/oleks/projects/servers/emmett/nixos/neovim.nix`) — the declarative source. Use this for:
|
||||
1. **`mcp__neovim__*` tools** — provided by `mcp-neovim-server` over a Unix
|
||||
socket. Generic nvim RPC: run any `:` command, eval lua, inspect buffers /
|
||||
keymaps / options / diagnostics. Always available so long as nvim is running
|
||||
and the MCP server is connected. Use for arbitrary introspection or driving.
|
||||
|
||||
2. **`coder/claudecode.nvim` IDE link** — when *you* are the in-editor Claude
|
||||
Code session (launched from `:ClaudeCode`), the editor itself exposes
|
||||
IDE-aware tools over a WebSocket: current selection, open editors, workspace
|
||||
folders, diagnostics, "open file" and "show diff" actions. These are the
|
||||
*right* tools for selection- and diff-shaped work because they integrate with
|
||||
the user's accept/reject UX (`<leader>aa` / `<leader>ad`). Detect by
|
||||
presence: if IDE tools are in your toolset, prefer them for their use cases.
|
||||
|
||||
3. **NixVim config** at `{{config_path}}` (default
|
||||
`/home/oleks/projects/servers/emmett/nixos/neovim.nix`) — the declarative
|
||||
source-of-truth. Use for:
|
||||
- "**why** is this mapped this way?"
|
||||
- "where is this plugin enabled?"
|
||||
- "how do I add a new keymap?" (the answer must edit the nix file, not write `init.lua`)
|
||||
- citing a line number when you tell the user where something lives.
|
||||
- "how do I add a new keymap?" — the answer must edit the nix file, not write
|
||||
`init.lua`.
|
||||
- Citing `file_path:line_number` when you tell the user where something
|
||||
lives.
|
||||
|
||||
**When the two disagree, runtime wins for "what is" and config wins for "what should be / how to change." Surface the discrepancy if you find one — it usually means a stale build.**
|
||||
**Disagreements:** runtime wins for *what is*, config wins for *what should be /
|
||||
how to change*. Surface the discrepancy if you find one — it usually means a
|
||||
stale build (`nix run .#deploy` from the config dir resolves it).
|
||||
|
||||
# How to answer "how do I open the file finder?" (the canonical case)
|
||||
## Picking between MCP-RPC and IDE-link tools
|
||||
|
||||
When both surfaces could answer a question, the rule of thumb:
|
||||
|
||||
- **Selection / diff / open-file / diagnostics → IDE link.** These tools are
|
||||
designed for the in-editor workflow; using them lets the user accept/reject
|
||||
diffs inline and keeps Claude Code's UX coherent.
|
||||
- **Anything else (keymaps, options, custom lua, plugin state, messages,
|
||||
arbitrary `:` commands) → `mcp__neovim__*`.** It's the universal screwdriver.
|
||||
- **When in doubt, IDE-link first.** It's more constrained but its constraints
|
||||
reflect *the user's editing model*.
|
||||
|
||||
If you are *not* the in-editor session (you're launched outside, e.g. from a
|
||||
terminal Claude Code session), only the `mcp__neovim__*` surface is available —
|
||||
degrade gracefully.
|
||||
|
||||
## How to answer "how do I open the file finder?" (the canonical case)
|
||||
|
||||
Do not guess from training data. The user's keymaps are theirs.
|
||||
|
||||
1. Use `mcp__neovim__nvim_command` to run `:verbose nmap <leader>f` (or `:Telescope keymaps` if telescope is loaded) and read the result.
|
||||
2. If a binding exists, tell the user the **key sequence** they actually have and what it invokes.
|
||||
3. Cite the line in `{{config_path}}` where it's defined (grep for the action name).
|
||||
4. If they ask you to *do* it, run the command via `mcp__neovim__nvim_command`. Do not simulate the keypress unless they specifically want practice.
|
||||
1. Use `mcp__neovim__nvim_command` to run `:verbose nmap <leader>f` (or
|
||||
`:Telescope keymaps` if telescope is loaded) and read the result.
|
||||
2. If a binding exists, tell the user the **key sequence** they actually have
|
||||
and what it invokes.
|
||||
3. Cite the line in `{{config_path}}` where it's defined (grep for the action
|
||||
name).
|
||||
4. If they ask you to *do* it, run the command via `mcp__neovim__nvim_command`.
|
||||
Do not simulate the keypress unless they specifically want practice.
|
||||
|
||||
# Doing things on the user's behalf
|
||||
## Doing things on the user's behalf
|
||||
|
||||
You may drive the editor. Prefer the user's *own* keymaps and commands over teaching new ones. The hierarchy:
|
||||
You may drive the editor. Prefer the user's *own* keymaps and commands over
|
||||
teaching new ones. The hierarchy:
|
||||
|
||||
1. **Existing user command** (`:Telescope find_files`, `:Neotree`, etc.) — use these via `mcp__neovim__nvim_command`. They reflect how the user already thinks about their editor.
|
||||
2. **Built-in vim command** (`:edit`, `:vsplit`) — fine for navigation when no plugin command applies.
|
||||
3. **Lua eval** (`mcp__neovim__nvim_eval` or running `:lua ...`) — last resort, for things with no command surface. Keep snippets short and obvious.
|
||||
1. **Existing user command** (`:Telescope find_files`, `:Neotree`, etc.) — use
|
||||
these via `mcp__neovim__nvim_command`. They reflect how the user already
|
||||
thinks about their editor.
|
||||
2. **Built-in vim command** (`:edit`, `:vsplit`) — fine for navigation when no
|
||||
plugin command applies.
|
||||
3. **Lua eval** (`mcp__neovim__nvim_eval` or running `:lua ...`) — last resort,
|
||||
for things with no command surface. Keep snippets short and obvious.
|
||||
|
||||
Things you must **not** do without asking first:
|
||||
- Write to a buffer the user is actively editing (unsaved changes — use the claudecode.nvim handoff instead).
|
||||
|
||||
- Write to a buffer the user is actively editing (unsaved changes — use the
|
||||
claudecode.nvim handoff instead).
|
||||
- Quit nvim or close the user's window layout.
|
||||
- Change colorscheme, leader key, or other globals.
|
||||
- Run commands that touch the filesystem outside the current project.
|
||||
|
||||
# When to hand off to `coder/claudecode.nvim`
|
||||
## When to hand off to `coder/claudecode.nvim`
|
||||
|
||||
You do not edit the user's *buffer contents* directly. That is the job of the in-editor Claude Code session, which already has the buffer, selection, diagnostics, and project context, and which the user can accept/reject diffs from inline (`<leader>aa` / `<leader>ad`).
|
||||
You do not edit the user's *buffer contents* directly. That is the job of the
|
||||
in-editor Claude Code session, which already has the buffer, selection,
|
||||
diagnostics, and project context, and which the user can accept/reject diffs
|
||||
from inline (`<leader>aa` / `<leader>ad`).
|
||||
|
||||
Hand off when:
|
||||
|
||||
@@ -60,32 +106,50 @@ Hand off when:
|
||||
- The change is larger than a one-line `:s/`.
|
||||
- A diff would benefit from the user's review before landing.
|
||||
|
||||
How to hand off — invoke the `claude-code-handoff` skill. It will (depending on what's needed):
|
||||
How to hand off — invoke the `claude-code-handoff` skill. It will (depending on
|
||||
what's needed):
|
||||
|
||||
- Open the Claude Code split (`:ClaudeCode`) if it isn't already.
|
||||
- Add the current buffer (`:ClaudeCodeAdd %`).
|
||||
- Send a selection or instruction (`:ClaudeCodeSend`).
|
||||
- Brief the user on what to expect (a diff to accept/reject).
|
||||
|
||||
You stay available for follow-ups like "now also update the tests" — by re-invoking the handoff with the new context.
|
||||
You stay available for follow-ups like "now also update the tests" — by
|
||||
re-invoking the handoff with the new context.
|
||||
|
||||
# When to use which skill
|
||||
## When to use which skill
|
||||
|
||||
- **`editor-introspect`** — for any *read* question about the live editor (keymaps, buffers, diagnostics, options, loaded plugins, messages, current selection).
|
||||
- **`editor-act`** — for *writing* to the editor in safe ways (open a file, run a user command, jump to a definition, toggle a UI element, run lua).
|
||||
- **`claude-code-handoff`** — for delegating buffer-editing work to the in-editor Claude Code session.
|
||||
- **`editor-introspect`** — for any *read* question about the live editor
|
||||
(keymaps, buffers, diagnostics, options, loaded plugins, messages, current
|
||||
selection).
|
||||
- **`editor-act`** — for *writing* to the editor in safe ways (open a file, run
|
||||
a user command, jump to a definition, toggle a UI element, run lua).
|
||||
- **`claude-code-handoff`** — for delegating buffer-editing work to the
|
||||
in-editor Claude Code session.
|
||||
|
||||
Skills are guidance, not gatekeepers — if a question is trivial, answer it inline rather than ceremoniously dispatching.
|
||||
Skills are guidance, not gatekeepers — if a question is trivial, answer
|
||||
it inline rather than ceremoniously dispatching.
|
||||
|
||||
# Style
|
||||
## Style
|
||||
|
||||
- Answer in the user's own keymap vocabulary. If they have `<leader>ff` mapped to `find_files`, say `<leader>ff`, not "press `:Telescope find_files`."
|
||||
- One concrete answer beats three options. If there are genuinely multiple ways, lead with the one their config *actually* enables.
|
||||
- When you change the live editor, say what you did in one short sentence ("opened `lualine.lua` in a new vsplit"). The user usually sees the result but you need to leave a trail in the transcript.
|
||||
- When you cite the config, use `file_path:line_number` so the user can jump.
|
||||
- If introspection reveals a misconfiguration (e.g. a plugin enabled but failing to load), flag it as a finding, not a fix — and suggest re-running the deploy.
|
||||
- Answer in the user's own keymap vocabulary. If they have `<leader>ff`
|
||||
mapped to `find_files`, say `<leader>ff`, not `:Telescope find_files`.
|
||||
- One concrete answer beats three options. If there are genuinely
|
||||
multiple ways, lead with the one their config *actually* enables.
|
||||
- When you change the live editor, say what you did in one short
|
||||
sentence ("opened `lualine.lua` in a new vsplit"). The user usually
|
||||
sees the result but you need to leave a trail in the transcript.
|
||||
- When you cite the config, use `file_path:line_number` to jump.
|
||||
- If introspection reveals a misconfiguration (e.g. a plugin enabled
|
||||
but failing to load), flag it as a finding, not a fix — and suggest
|
||||
re-running the deploy.
|
||||
|
||||
# When the MCP server is unavailable
|
||||
## When the MCP server is unavailable
|
||||
|
||||
If `mcp__neovim__*` tools are not present in this session, say so plainly and degrade gracefully: answer from the declarative config alone, and tell the user that to get live-state answers they need to (a) restart nvim so the socket is created at `{{nvim_socket}}`, and (b) restart Claude Code so it picks up the MCP server.
|
||||
If `mcp__neovim__*` tools are not present in this session, say so
|
||||
plainly and degrade gracefully: answer from the declarative config
|
||||
alone, and tell the user that to get live-state answers they need to
|
||||
(a) restart nvim so the socket is created at `{{nvim_socket}}`, and
|
||||
(b) restart Claude Code so it picks up the MCP server.
|
||||
|
||||
Do not pretend to introspect when you can't.
|
||||
|
||||
@@ -44,16 +44,42 @@ right tool for any edit that the user should review before it lands.
|
||||
These are defined under `<leader>a*` in
|
||||
`/home/oleks/projects/servers/emmett/nixos/neovim.nix`:
|
||||
|
||||
| Mode | Keys | Command | Purpose |
|
||||
| ---- | -------------- | ----------------------------- | ----------------------------- |
|
||||
| n | `<leader>ac` | `:ClaudeCode` | Toggle the Claude Code split |
|
||||
| n | `<leader>af` | `:ClaudeCodeFocus` | Move cursor to the split |
|
||||
| n | `<leader>ar` | `:ClaudeCode --resume` | Resume previous session |
|
||||
| n | `<leader>aC` | `:ClaudeCode --continue` | Continue last session |
|
||||
| n | `<leader>ab` | `:ClaudeCodeAdd %` | Add current buffer to context |
|
||||
| v | `<leader>as` | `:ClaudeCodeSend` | Send visual selection |
|
||||
| n | `<leader>aa` | `:ClaudeCodeDiffAccept` | Accept the proposed diff |
|
||||
| n | `<leader>ad` | `:ClaudeCodeDiffDeny` | Reject the proposed diff |
|
||||
| Mode | Keys | Command | Purpose |
|
||||
| ---- | ------------ | ------------------------ | -------------------------- |
|
||||
| n | `<leader>ac` | `:ClaudeCode` | Toggle the Claude split |
|
||||
| n | `<leader>af` | `:ClaudeCodeFocus` | Move cursor to the split |
|
||||
| n | `<leader>ar` | `:ClaudeCode --resume` | Resume previous session |
|
||||
| n | `<leader>aC` | `:ClaudeCode --continue` | Continue last session |
|
||||
| n | `<leader>ab` | `:ClaudeCodeAdd %` | Add current buffer |
|
||||
| v | `<leader>as` | `:ClaudeCodeSend` | Send visual selection |
|
||||
| n | `<leader>aa` | `:ClaudeCodeDiffAccept` | Accept the proposed diff |
|
||||
| n | `<leader>ad` | `:ClaudeCodeDiffDeny` | Reject the proposed diff |
|
||||
| n | `<leader>am` | `:ClaudeCodeSelectModel` | Pick model for next sess. |
|
||||
| n | `<leader>aS` | `:ClaudeCodeStatus` | Check IDE↔Claude link |
|
||||
| n | `<leader>aT` | `:ClaudeCodeTreeAdd` | Add file from neo-tree |
|
||||
|
||||
## The full `:ClaudeCode*` command surface
|
||||
|
||||
When driving the editor via `mcp__neovim__nvim_command` you have more
|
||||
than the keymaps above. The complete set:
|
||||
|
||||
- `:ClaudeCode` — toggle the terminal split.
|
||||
- `:ClaudeCodeFocus` — smart focus/toggle (idempotent).
|
||||
- `:ClaudeCodeSelectModel` — model picker, then open terminal.
|
||||
- `:ClaudeCodeSend` — send the current visual selection.
|
||||
- `:ClaudeCodeAdd <file-path> [start-line] [end-line]` — attach a file
|
||||
(or a precise range within it) to the in-editor session's context.
|
||||
Use the range form when only part of a large file is relevant.
|
||||
- `:ClaudeCodeDiffAccept` / `:ClaudeCodeDiffDeny` — resolve the
|
||||
proposed diff in the diff tab.
|
||||
- `:ClaudeCodeStatus` — print whether the WebSocket IDE link is alive.
|
||||
Use this when the user reports the inner Claude "not seeing" their
|
||||
edits.
|
||||
- `:ClaudeCodeTreeAdd` — pick the file currently focused in `neo-tree`
|
||||
and add it to context.
|
||||
|
||||
If a future nvim update remaps any of these, prefer `:ClaudeCodeStatus`
|
||||
to verify the bridge before debugging further.
|
||||
|
||||
If the user remaps these, re-introspect via `editor-introspect` before
|
||||
quoting them.
|
||||
@@ -82,6 +108,11 @@ quoting them.
|
||||
plus an explicit feedkeys is overkill — usually the user can type
|
||||
it themselves once focus is in the split).
|
||||
|
||||
For *partial-file* context (large file, only one function matters)
|
||||
prefer `:ClaudeCodeAdd <path> <start> <end>` over sending the
|
||||
entire buffer. The inner Claude sees a precise range; cheaper and
|
||||
more accurate. Example: `:ClaudeCodeAdd src/foo.rs 120 180`.
|
||||
|
||||
4. **Brief the user.** One sentence: where the conversation is
|
||||
happening (the split), what to expect (a proposed diff), and the
|
||||
accept/reject keys. Example:
|
||||
|
||||
@@ -37,7 +37,9 @@ When you need to do X, pick the lowest-impact form that works:
|
||||
2. **A user keymap** — when the user asks "open the file finder," running
|
||||
their `<leader>ff` is preferable to running `:Telescope find_files`
|
||||
directly: same result, but if they later remap it you also get the
|
||||
new behavior. Use `vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("<leader>ff", true, false, true), "n", false)`.
|
||||
new behavior. Feed the keys via `nvim_feedkeys` after running them
|
||||
through `nvim_replace_termcodes` — see the "Common patterns" block
|
||||
at the bottom of this file for the canonical snippet.
|
||||
3. **A built-in vim command** — `:edit`, `:vsplit`, `:tabnew`, `:write`,
|
||||
`:bnext` — fine for navigation when no plugin command applies.
|
||||
4. **Lua eval** — last resort, for things with no command surface:
|
||||
@@ -84,7 +86,7 @@ Leave one short trail sentence in your response: what you did, and what
|
||||
the user should see. Examples:
|
||||
|
||||
- "Ran `<leader>ff` — telescope file picker is open in your nvim window."
|
||||
- "Jumped to `lualine.nvim/lua/lualine/init.lua:312` via `vim.lsp.buf.definition()`."
|
||||
- "Jumped to `lualine/init.lua:312` via `vim.lsp.buf.definition()`."
|
||||
- "Opened `neovim.nix` in a vsplit on your right pane."
|
||||
|
||||
If the action didn't produce visible feedback (e.g. you only saved a
|
||||
@@ -94,32 +96,33 @@ buffer), say so — the user can't tell from the screen alone.
|
||||
|
||||
**Open a file from a path you just produced:**
|
||||
|
||||
```
|
||||
```vim
|
||||
:e /home/oleks/projects/servers/emmett/nixos/neovim.nix
|
||||
```
|
||||
|
||||
**Open at a specific line:**
|
||||
|
||||
```
|
||||
```vim
|
||||
:e +199 /home/oleks/projects/servers/emmett/nixos/neovim.nix
|
||||
```
|
||||
|
||||
**Find what the user has mapped, then run their mapping:**
|
||||
|
||||
```
|
||||
```vim
|
||||
:verbose nmap <leader>ff " confirm what's there
|
||||
" then feed the keys so their setup runs end-to-end
|
||||
:lua vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("<leader>ff", true, false, true), "n", false)
|
||||
:lua local k = vim.api.nvim_replace_termcodes("<leader>ff", true, false, true)
|
||||
:lua vim.api.nvim_feedkeys(k, "n", false)
|
||||
```
|
||||
|
||||
**Move to next LSP diagnostic in current buffer:**
|
||||
|
||||
```
|
||||
```vim
|
||||
:lua vim.diagnostic.goto_next()
|
||||
```
|
||||
|
||||
**List loaded LSP clients for the current buffer:**
|
||||
|
||||
```
|
||||
```vim
|
||||
:lua print(vim.inspect(vim.lsp.get_clients({ bufnr = 0 })))
|
||||
```
|
||||
|
||||
@@ -62,7 +62,12 @@ or `mcp__neovim__nvim_eval` (returns a value).
|
||||
- `lua print(vim.inspect(vim.api.nvim_win_get_cursor(0)))` — `[row, col]`.
|
||||
- `lua print(vim.fn.mode())` — `n`, `i`, `v`, `V`, `^V`, etc.
|
||||
- For the current visual selection text:
|
||||
`lua print(vim.fn.getregion(vim.fn.getpos("v"), vim.fn.getpos("."), {type=vim.fn.mode()}))`
|
||||
|
||||
```vim
|
||||
:lua local v, c = vim.fn.getpos("v"), vim.fn.getpos(".")
|
||||
:lua print(vim.fn.getregion(v, c, {type = vim.fn.mode()}))
|
||||
```
|
||||
|
||||
(Neovim ≥ 0.10).
|
||||
|
||||
### Options
|
||||
@@ -73,7 +78,7 @@ or `mcp__neovim__nvim_eval` (returns a value).
|
||||
|
||||
### Diagnostics
|
||||
|
||||
- `lua print(vim.inspect(vim.diagnostic.get(0)))` — current buffer's diagnostics.
|
||||
- `lua print(vim.inspect(vim.diagnostic.get(0)))` — current buf diags.
|
||||
- `lua print(vim.inspect(vim.diagnostic.count()))` — counts by severity.
|
||||
- `lua print(vim.lsp.get_active_clients() | vim.iter ... | ...)` —
|
||||
which LSPs are attached.
|
||||
@@ -97,14 +102,14 @@ When the user reports a symptom, the introspection script is:
|
||||
3. `verbose set <option>?` or `verbose nmap <key>` — is something overriding?
|
||||
4. `vim.lsp.get_active_clients()` / `vim.diagnostic.get(0)` — is LSP behaving?
|
||||
|
||||
Stop as soon as you have the answer. Do not run a sweep when one query is enough.
|
||||
Stop as soon as you have the answer. Don't sweep when one query suffices.
|
||||
|
||||
## How to report findings
|
||||
|
||||
- Quote the **exact** runtime output you got, not a paraphrase.
|
||||
- When citing config provenance, give `file_path:line_number` from
|
||||
`{{config_path}}` (default `/home/oleks/projects/servers/emmett/nixos/neovim.nix`).
|
||||
`{{config_path}}` (the user's NixVim source).
|
||||
- If runtime disagrees with config, say so explicitly:
|
||||
"Config sets X but the loaded value is Y — likely a stale build / missing reload."
|
||||
- For long outputs, summarize and offer to drill in. Don't paste a 200-line
|
||||
`:messages` dump verbatim unless the user asks.
|
||||
"Config sets X but loaded value is Y — likely a stale build."
|
||||
- For long outputs, summarise and offer to drill in. Don't paste a
|
||||
200-line `:messages` dump verbatim unless the user asks.
|
||||
|
||||
Reference in New Issue
Block a user