Feat/lsp symbols#9
Conversation
chore: extract setup_completions to its own function
cachebag
left a comment
There was a problem hiding this comment.
Generally speaking as well, I noticed that on reprompts, @lsp is just treated as literal text because we didn't update build_reprompt_messages.
You should either strip it entirely or support it in this PR.
Thanks so much for your contribution :D
| return require("jumpy").config | ||
| end | ||
|
|
||
| local function get_workspace_symbols(bufnr) |
There was a problem hiding this comment.
Please move @lsp resolution into prompt._submit (or perhaps a new jumpy/context_tools.lua) and pass the resolved string through context.
This file should only know how to format extra sections it's handed.
| local function get_workspace_symbols(bufnr) | ||
| local filename = vim.fn.expand("%:t:r") | ||
|
|
||
| local res = vim.lsp.buf_request_sync(bufnr, "workspace/symbol", { query = filename }, 1000) |
There was a problem hiding this comment.
Sync call blocks the UI for up to 1s inside the otherwise-async LLM pipeline. You should use vim.lsp.buf_request with a callback.
Additionally, bufnr is never actually passed in from prompt._submit, so this is always 0. Plumb source_buf through context explicitly instead of relying on expand("%").
| end | ||
|
|
||
| local function get_workspace_symbols(bufnr) | ||
| local filename = vim.fn.expand("%:t:r") |
There was a problem hiding this comment.
I don't think this is the right decision. For most files, it will return either noting or an unrelated set (which kind of defeats the purpose of this feature).
We can probably file an issue for prompt-derived queries later but for now, please drop the query so the LLM can see the real project structure.
|
|
||
| for _, r in pairs(res or {}) do | ||
| for _, s in ipairs(r.result or {}) do | ||
| out[#out + 1] = string.format("- %s [%s]", s.name, kinds[s.kind] or "?") |
There was a problem hiding this comment.
You should include s.containerName and a workspace-relative path from s.location.uri, and cap the list to like 200.
A flat list of bare names with no location is not useful to the model and can blow up the prompt on bigger workspaces.
| local prompt = context.prompt | ||
| local symbols = "" | ||
|
|
||
| if prompt:find("@lsp") then |
There was a problem hiding this comment.
Use a frontier pattern like prompt:gsub("%f[%w@]@lsp%f[%W]", "") instead.
Also: if no LSP client supports workspace/symbol, this silently produces an empty section. Please vim.notify so the user knows @lsp did nothing.
|
|
||
| if match then | ||
| vim.schedule(function() | ||
| vim.fn.complete(col - #match, completionItems) |
There was a problem hiding this comment.
Nit: could we guard this with if vim.fn.mode() == "i"?
Added support for
@lspcompletions in the prompt buffer. When used, the plugin now callsvim.lsp.buf.workspace_symbol, formats the returned symbols, and prepends the resulting workspace context to the prompt sent to the LLM.Notes
workspace_symbolbehavior appears to vary across LSP servers:basedpyrightandgoplsreturn no results when provided with an empty query ("")lua_lsreturns all project symbols for the same request (intended behaviour)I also tried an alternative implementation that called
textDocument/documentSymbolfor every file in the workspace and merged the results manually. While this produced better results across servers, it often resulted in severe lag (3-4s) even in relatively small projects. So, I decided not to use that approach and just rely on the LSP's workspace_symbol implementation