Cloonar/chatgpt.vim
2
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity

Compare commits

base: Cloonar:main
Branches Tags
Cloonar:main
Cloonar:change-to-tools
..
compare: Cloonar:change-to-tools
Branches Tags
Cloonar:main
Cloonar:change-to-tools

No commits in common. "main" and "change-to-tools" have entirely different histories.
main ... change-to-

12 changed files with 194 additions and 613 deletions
Download patch file Download diff file Expand all files Collapse all files

27
.chatgpt_config.yaml Normal file
View file

@ -0,0 +1,27 @@
project_name: "chatgpt_nvim"
default_prompt_blocks:
- "basic-prompt"
- "secure-coding"
initial_files:
- "README.md"
debug: false
improved_debug: false
preview_changes: false
interactive_file_selection: false
partial_acceptance: false
enable_debug_commands: true
prompt_char_limit: 300000
enable_chunking: false
enable_step_by_step: true
auto_lint: true
# New tool auto-accept config
tool_auto_accept:
readFile: false
editFile: false
executeCommand: false
# If you set any of these to true, it will auto accept them without prompting.
# 'executeCommand' should remain false by default unless you're certain it's safe.

97
README.md
View file

@ -4,36 +4,28 @@
This plugin integrates a ChatGPT O1 model workflow into Neovim. It allows you to:
1. Generate prompts containing:
- An **initial prompt** (loaded from `.chatgpt_config.yaml` or `chatgpt_config.yaml`)
- A list of directories (as specified in your configuration) from which it gathers the project structure
- **Interactive file selection** (if enabled) so you can choose which directories to include
- Any **initial files** you define (e.g. `README.md`, etc.)
- Optionally, **file contents** can be appended to the prompt when the new `include_file_contents` flag is enabled
- An **initial prompt** (from `.chatgpt_config.yaml`)
- A list of directories (also specified in `.chatgpt_config.yaml`) from which it gathers the project structure and file contents
- **Interactive file selection** if enabled, so you can pick exactly which directories to include
- Any **initial files** you define (e.g., `README.md`, etc.)
2. Copy these prompts to your clipboard to paste into ChatGPT O1.
3. Receive YAML changes from ChatGPT and run `:ChatGPTPaste` to apply them or to supply additional files.
3. Receive YAML changes from ChatGPT, then run `:ChatGPTPaste` to apply them or supply additional files.
## New Key Features
- **Step-by-Step Prompting** (`enable_step_by_step: true`):
If the generated prompt grows too large (exceeding the configured `prompt_char_limit`), the plugin automatically produces a special prompt asking the model to split the task into smaller steps. This ensures you remain within the model’s maximum token capacity without manually breaking your task apart.
If the request grows too large (exceeds `token_limit`), the plugin automatically generates a special prompt asking the model to split the task into smaller steps, working through them one by one. This approach helps you stay within the model’s maximum token limit without having to manually break things apart.
- **Partial Acceptance**:
If `partial_acceptance: true`, you can open a buffer displaying the proposed changes. Remove or comment out lines you do not wish to apply, and only the remaining changes will be executed.
- **Partial Acceptance**: If `partial_acceptance: true`, you can open a buffer that lists the final changes. Remove or comment out lines you don’t want, then only those changes are applied.
- **Preview Changes**:
If `preview_changes: true`, a buffer will show the proposed changes before they are applied.
- **Preview Changes**: If `preview_changes: true`, you get a buffer showing proposed changes before you apply them.
- **Interactive File Selection**:
When `interactive_file_selection: true`, you can choose which directories (from your config file) to include in the prompt, thus managing token usage more effectively.
- **Interactive File Selection**: If `interactive_file_selection: true`, you choose which directories from `.chatgpt_config.yaml` get included in the prompt, reducing token usage.
- **Include File Contents**:
A new configuration flag `include_file_contents` (default: `false`) lets you include the entire contents of the project files in the prompt. When enabled, the plugin gathers and appends the file contents from the selected directories. It counts the total characters and, if the combined file contents exceed the `prompt_char_limit`, it notifies you to disable this feature to avoid exceeding the model’s capacity.
- **Improved Debug**: If `improved_debug: true`, debug logs go into a dedicated `ChatGPT_Debug_Log` buffer for easier reading.
- **Improved Debug**:
If `improved_debug: true`, detailed debug logs are sent to a dedicated `ChatGPT_Debug_Log` buffer for easier review.
## Example `.chatgpt_config.yaml` or `chatgpt_config.yaml`
## Example `.chatgpt_config.yaml`
```yaml
project_name: "chatgpt_nvim"
@ -45,43 +37,40 @@ directories:
initial_files:
- "README.md"
debug: false
include_file_contents: false # Set to true to include file contents in the prompt
enable_step_by_step: true
preview_changes: true
interactive_file_selection: true
partial_acceptance: true
improved_debug: true
prompt_char_limit: 300000 # Maximum characters allowed in the prompt
token_limit: 3000
```
## Usage
1. **`:ChatGPT`**
- If `interactive_file_selection` is enabled, you will select directories via a buffer (named `ChatGPT_File_Selection`).
- Save and close the buffer with `:wq`, `:x`, or `:bd` (no need to use `:q`).
- If `enable_step_by_step` is active and the prompt might exceed `prompt_char_limit`, the plugin will generate a step-by-step instruction prompt.
- If `interactive_file_selection` is on, you’ll pick directories to include in a buffer named `ChatGPT_File_Selection`.
- Save & close with `:wq`, `:x`, or `:bd` (you don’t have to use `:q`).
- If `enable_step_by_step` is on and the prompt might exceed `token_limit`, the plugin will generate instructions prompting the model to address each step separately.
2. **Paste Prompt to ChatGPT**
- If the task is split into steps, copy and paste them one by one into ChatGPT.
- If the task is split into steps, simply copy/paste them one by one into ChatGPT.
3. **`:ChatGPTPaste`**
- The plugin reads the YAML response from your clipboard. If additional files are requested, a step-by-step approach might be suggested.
- When final changes are provided:
- You can optionally preview them (`preview_changes`).
- You can optionally partially accept them (`partial_acceptance`).
- Finally, the plugin applies file writes or deletions as specified in the YAML.
- The plugin reads the YAML from your clipboard. If it requests more files, it might again suggest a step-by-step approach.
- If final changes are provided:
- Optionally preview them (`preview_changes`).
- Optionally partially accept them (`partial_acceptance`).
- Then the plugin writes/deletes files as specified.
## Troubleshooting & Tips
- Adjust `prompt_char_limit` in your configuration file as needed.
- If partial acceptance is confusing, simply remove or comment out lines you do not want before finalizing the buffer.
- When step-by-step prompting occurs, ensure you follow each instruction in the correct order.
- For detailed debug information, check the `ChatGPT_Debug_Log` buffer (if `improved_debug` is enabled) or the standard Neovim messages (if `debug` is enabled).
- You can close the selection or prompt buffers at any time using commands like `:bd`, `:x`, or `:wq`.
- Adjust `token_limit` in `.chatgpt_config.yaml` as needed.
- If partial acceptance is confusing, remember to remove or prepend `#` to lines you don’t want before saving and closing the buffer.
- If step-by-step prompting occurs, ensure you follow each prompt the model provides in the correct order.
- Check `ChatGPT_Debug_Log` if `improved_debug` is on, or the Neovim messages if `debug` is on, for detailed info.
- You can close the selection or prompt buffers at any time with commands like `:bd`, `:x`, or `:wq`. No need to rely on `:q`.
## Debug Commands
If `enable_debug_commands` is true, you can include commands such as:
If `enable_debug_commands` is true, you can include commands like these in your YAML:
```yaml
commands:
- command: "list"
@ -91,23 +80,21 @@ commands:
pattern: "searchString"
target: "path/to/file/or/directory"
```
The **list** command uses the Linux `ls` command to list directory contents, while the **grep** command searches for a given pattern within files or directories.
The **list** command now uses the Linux `ls` command to list directory contents. The **grep** command searches for a given pattern in a file or all files in a directory.
Enjoy your improved, flexible ChatGPT NeoVim plugin with step-by-step support and enhanced file inclusion capabilities!
Enjoy your improved, more flexible ChatGPT Neovim plugin with step-by-step support!
## Test when Developing
## Test when developing
add new plugin to runtimepath
```vim
:set rtp^=~/temp_plugins/chatgpt.vim
```
Clear Lua module cache
```vim
:lua for k in pairs(package.loaded) do if k:match("^chatgpt_nvim") then package.loaded[k]=nil end end
```
Load new plugin code
```vim
:runtime plugin/chatgpt.vim
```
- **Add plugin to runtimepath:**
```vim
:set rtp^=~/temp_plugins/chatgpt.vim
```
- **Clear Lua module cache:**
```vim
:lua for k in pairs(package.loaded) do if k:match("^chatgpt_nvim") then package.loaded[k]=nil end end
```
- **Load new plugin code:**
```vim
:runtime plugin/chatgpt.vim
```

29
chatgpt_config.yaml
View file

@ -1,29 +0,0 @@
project_name: "chatgpt.vim"
default_prompt_blocks:
- "basic"
- "secure-coding"
ignore_files:
- "node_modules/"
- "*.log"
- "vendor/"
include_file_contents: true
debug: false
improved_debug: false
preview_changes: false
interactive_file_selection: false
partial_acceptance: false
enable_debug_commands: true
enable_chunking: false
enable_step_by_step: true
auto_lint: true
tool_auto_accept:
read_file: true
edit_file: true
replace_in_file: true
execute_command: false

66
lua/chatgpt_nvim/config.lua
View file

@ -4,7 +4,6 @@ local uv = vim.loop
local ok_yaml, lyaml = pcall(require, "lyaml")
local prompts = require("chatgpt_nvim.prompts")
-- Determines the Git root or fallback directory.
local function get_project_root()
local current_file = vim.fn.expand("%:p")
local root_dir
@ -29,39 +28,22 @@ local function get_project_root()
return root_dir
end
-- Attempt to locate either .chatgpt_config.yaml or chatgpt_config.yaml, returning whichever exists first.
local function get_config_path()
local root = get_project_root()
local dot_config = root .. "/.chatgpt_config.yaml"
local non_dot_config = root .. "/chatgpt_config.yaml"
local dot_fd = uv.fs_open(dot_config, "r", 438)
if dot_fd then
uv.fs_close(dot_fd)
return dot_config
end
local non_dot_fd = uv.fs_open(non_dot_config, "r", 438)
if non_dot_fd then
uv.fs_close(non_dot_fd)
return non_dot_config
end
return nil
return root .. "/.chatgpt_config.yaml"
end
function M.load()
-- Attempt to find either config file, else fallback
local path = get_config_path()
local fd = uv.fs_open(path, "r", 438)
local config = {
initial_prompt = "",
directories = { "." },
default_prompt_blocks = {},
-- Removed prompt_char_limit
prompt_char_limit = 300000,
project_name = "",
debug = false,
initial_files = {},
include_file_contents = false, -- NEW FLAG: include file contents in prompt if true
preview_changes = false,
interactive_file_selection = false,
partial_acceptance = false,
@ -73,30 +55,17 @@ function M.load()
auto_lint = false,
tool_auto_accept = {
read_file = false,
edit_file = false,
readFile = false,
editFile = false,
replace_in_file = false,
execute_command = false,
executeCommand = false,
}
}
-- If no config file found, alert user and return default config
if not path then
config.initial_prompt = "You are a coding assistant who receives a project's context and user instructions..."
vim.notify(
"No config file found (tried .chatgpt_config.yaml, chatgpt_config.yaml). Using defaults.",
vim.log.levels.WARN
)
config.max_token = 2048
return config
end
local fd = uv.fs_open(path, "r", 438)
if fd then
local stat = uv.fs_fstat(fd)
local data = uv.fs_read(fd, stat.size, 0)
uv.fs_close(fd)
if data and ok_yaml then
local ok, result = pcall(lyaml.load, data)
if ok and type(result) == "table" then
@ -109,6 +78,9 @@ function M.load()
if type(result.default_prompt_blocks) == "table" then
config.default_prompt_blocks = result.default_prompt_blocks
end
if type(result.prompt_char_limit) == "number" then
config.prompt_char_limit = result.prompt_char_limit
end
if type(result.project_name) == "string" then
config.project_name = result.project_name
end
@ -118,12 +90,6 @@ function M.load()
if type(result.initial_files) == "table" then
config.initial_files = result.initial_files
end
if type(result.include_file_contents) == "boolean" then
config.include_file_contents = result.include_file_contents
end
if type(result.ignore_files) == "table" then
config.ignore_files = result.ignore_files
end
if type(result.preview_changes) == "boolean" then
config.preview_changes = result.preview_changes
end
@ -143,6 +109,7 @@ function M.load()
config.enable_step_by_step = result.enable_step_by_step
end
-- auto_lint controls whether we do LSP-based checks
if type(result.auto_lint) == "boolean" then
config.auto_lint = result.auto_lint
end
@ -154,17 +121,10 @@ function M.load()
end
end
end
if type(result.max_token) == "number" then
config.max_token = result.max_token
else
config.max_token = 2048
end
end
end
else
config.initial_prompt = "You are a coding assistant who receives a project's context and user instructions..."
config.max_token = 2048
end
-- Merge default prompt blocks
@ -185,12 +145,6 @@ function M.load()
end
end
-- Include project name in the final initial prompt, if set
if config.project_name ~= "" then
config.initial_prompt =
"[Project Name: " .. config.project_name .. "]\n\n" .. config.initial_prompt
end
if config.debug then
vim.api.nvim_out_write("[chatgpt_nvim:config] Loaded config from: " .. path .. "\n")
vim.api.nvim_out_write("[chatgpt_nvim:config] Debug logging is enabled.\n")

23
lua/chatgpt_nvim/context.lua
View file

@ -131,11 +131,6 @@ end
function M.get_project_files(directories, conf)
local root = vim.fn.getcwd()
local ignore_patterns = load_gitignore_patterns(root, conf)
if conf.ignore_files then
for _, pattern in ipairs(conf.ignore_files) do
table.insert(ignore_patterns, gitignore_to_lua_pattern(pattern))
end
end
local all_files = {}
for _, dir in ipairs(directories) do
local abs_dir = dir
@ -148,9 +143,7 @@ function M.get_project_files(directories, conf)
local rel_files = {}
for _, f in ipairs(all_files) do
local rel = vim.fn.fnamemodify(f, ":.")
if not rel:match("^%.?chatgpt_config%.yaml$") then
table.insert(rel_files, rel)
end
table.insert(rel_files, rel)
end
if conf.debug then
@ -192,16 +185,4 @@ function M.get_file_contents(files, conf)
return table.concat(sections, "\n")
end
-- NEW FUNCTION: Build the project prompt by optionally including file contents.
function M.get_project_prompt(directories, conf)
local structure = M.get_project_structure(directories, conf)
if conf.include_file_contents then
local files = M.get_project_files(directories, conf)
local contents = M.get_file_contents(files, conf)
return structure .. "\n" .. contents
else
return structure
end
end
return M
return M

126
lua/chatgpt_nvim/init.lua
View file

@ -54,12 +54,11 @@ local function read_file(path)
return data
end
-- Added function to close existing buffers matching a name pattern.
local function close_existing_buffer_by_name(name_pattern)
for _, buf in ipairs(vim.api.nvim_list_bufs()) do
local buf_name = vim.api.nvim_buf_get_name(buf)
if buf_name:match(name_pattern) then
vim.api.nvim_buf_delete(buf, {force = true})
local function close_existing_buffer_by_name(pattern)
for _, b in ipairs(vim.api.nvim_list_bufs()) do
local name = vim.api.nvim_buf_get_name(b)
if name:match(pattern) then
vim.api.nvim_buf_delete(b, { force = true })
end
end
end
@ -102,7 +101,7 @@ local function build_prompt(user_input, dirs, conf)
task_lines[#task_lines+1] = "</task>\n"
table.insert(final_sections, table.concat(task_lines, "\n"))
-- 4) <file_content path="..."> from initial_files
-- 4) <file_content path="...">
local file_content_blocks = {}
for _, file_path in ipairs(initial_files) do
local full_path = root .. "/" .. file_path
@ -119,39 +118,6 @@ local function build_prompt(user_input, dirs, conf)
table.insert(final_sections, table.concat(file_content_blocks, "\n\n"))
end
-- 4.1) Dynamic file inclusion via @ operator in user_input
local dynamic_files = {}
for file in user_input:gmatch("@([^%s]+)") do
if file ~= "chatgpt_config.yaml" and file ~= ".chatgpt_config.yaml" then
local already_included = false
for _, existing in ipairs(initial_files) do
if existing == file then
already_included = true
break
end
end
if not already_included then
table.insert(dynamic_files, file)
end
end
end
local dynamic_file_blocks = {}
for _, file in ipairs(dynamic_files) do
local full_path = root .. "/" .. file
if is_subpath(root, full_path) then
local fdata = read_file(full_path)
if fdata then
dynamic_file_blocks[#dynamic_file_blocks+1] = string.format(
"<file_content path=\"%s\">\n%s\n</file_content>", file, fdata
)
end
end
end
if #dynamic_file_blocks > 0 then
table.insert(final_sections, table.concat(dynamic_file_blocks, "\n\n"))
end
-- 5) <environment_details>
local env_lines = {}
env_lines[#env_lines+1] = "<environment_details>"
@ -167,40 +133,29 @@ local function build_prompt(user_input, dirs, conf)
env_lines[#env_lines+1] = os.date("%x, %X (%Z)")
env_lines[#env_lines+1] = ""
env_lines[#env_lines+1] = "# Current Working Directory (" .. root .. ") Files"
env_lines[#env_lines+1] = context.get_project_prompt(dirs, conf) or ""
env_lines[#env_lines+1] = context.get_project_structure(dirs, conf) or ""
env_lines[#env_lines+1] = ""
env_lines[#env_lines+1] = "# Current Mode"
env_lines[#env_lines+1] = "ACT MODE"
env_lines[#env_lines+1] = "</environment_details>"
table.insert(final_sections, table.concat(env_lines, "\n"))
local final_prompt = table.concat(final_sections, "\n\n")
final_prompt = final_prompt:gsub("%chatgpt.vim%", conf.project_name)
return final_prompt
end
local function estimate_token_count(text)
local token_count = 0
for chunk in text:gmatch("%S+") do
for token in chunk:gmatch("(%w+|%p+)") do
token_count = token_count + 1
end
end
return token_count
return table.concat(final_sections, "\n\n")
end
local function handle_step_by_step_if_needed(prompt, conf)
local token_count = estimate_token_count(prompt)
local limit = conf.max_token or 2048
if (not conf.enable_step_by_step) or (token_count <= limit) then
local length = #prompt
local limit = conf.prompt_char_limit or 8000
if (not conf.enable_step_by_step) or (length <= limit) then
return { prompt }
end
return { prompts["step-prompt"] }
end
------------------------------------------------------------------------------
-- :ChatGPT
------------------------------------------------------------------------------
local function run_chatgpt_command()
package.loaded["chatgpt_nvim.config"] = nil
local config = require("chatgpt_nvim.config")
local conf = config.load()
ui.setup_ui(conf)
ui.debug_log("Running :ChatGPT command.")
@ -216,7 +171,6 @@ local function run_chatgpt_command()
local bufnr = vim.api.nvim_create_buf(false, false)
vim.api.nvim_buf_set_name(bufnr, "ChatGPT_Prompt.md")
vim.api.nvim_buf_set_option(bufnr, "filetype", "markdown")
vim.api.nvim_buf_set_option(bufnr, "omnifunc", "v:lua.chatgpt_file_complete")
vim.api.nvim_buf_set_option(bufnr, "bufhidden", "wipe")
vim.api.nvim_buf_set_option(bufnr, "buftype", "")
vim.api.nvim_buf_set_option(bufnr, "modifiable", true)
@ -224,7 +178,6 @@ local function run_chatgpt_command()
vim.api.nvim_buf_set_lines(bufnr, 0, -1, false, {
"# Enter your main user prompt (task) below.",
"",
"You can include files by typing @filename in your prompt.",
"Save & close with :wq, :x, or :bd to finalize your prompt."
})
@ -266,9 +219,10 @@ local function run_chatgpt_command()
vim.cmd("buffer " .. bufnr)
end
------------------------------------------------------------------------------
-- :ChatGPTPaste
------------------------------------------------------------------------------
local function run_chatgpt_paste_command()
package.loaded["chatgpt_nvim.config"] = nil
local config = require("chatgpt_nvim.config")
local conf = config.load()
ui.setup_ui(conf)
ui.debug_log("Running :ChatGPTPaste command.")
@ -284,7 +238,9 @@ local function run_chatgpt_paste_command()
return
end
-- Check if we have tools
if data.tools then
-- Must also verify project name
if not data.project_name or data.project_name ~= conf.project_name then
vim.api.nvim_err_writeln("Project name mismatch or missing. Aborting tool usage.")
return
@ -296,6 +252,7 @@ local function run_chatgpt_paste_command()
return
end
-- If we see project_name & files => older YAML style. We handle it but it's discouraged now.
if data.project_name and data.files then
if data.project_name ~= conf.project_name then
vim.api.nvim_err_writeln("Project name mismatch. Aborting.")
@ -362,6 +319,7 @@ local function run_chatgpt_paste_command()
end
end
else
-- Not final => user is requesting more files
local requested_paths = {}
local root = vim.fn.getcwd()
for _, fileinfo in ipairs(data.files) do
@ -393,6 +351,16 @@ local function run_chatgpt_paste_command()
local length = #prompt
ui.debug_log("Returning requested files. Character count: " .. length)
if length > (conf.prompt_char_limit or 8000) and conf.enable_step_by_step then
local large_step = prompts["step-prompt"]
copy_to_clipboard(large_step)
print("Step-by-step guidance copied to clipboard!")
return
elseif length > (conf.prompt_char_limit or 8000) then
vim.api.nvim_err_writeln("Requested files exceed prompt character limit. No step-by-step support enabled.")
return
end
copy_to_clipboard(prompt)
print("Prompt (with requested files) copied to clipboard! Paste it into ChatGPT.")
end
@ -401,9 +369,10 @@ local function run_chatgpt_paste_command()
end
end
------------------------------------------------------------------------------
-- :ChatGPTCurrentBuffer
------------------------------------------------------------------------------
local function run_chatgpt_current_buffer_command()
package.loaded["chatgpt_nvim.config"] = nil
local config = require("chatgpt_nvim.config")
local conf = config.load()
ui.setup_ui(conf)
ui.debug_log("Running :ChatGPTCurrentBuffer command.")
@ -439,32 +408,11 @@ local function run_chatgpt_current_buffer_command()
end
end
------------------------------------------------------------------------------
-- PUBLIC API
------------------------------------------------------------------------------
M.run_chatgpt_command = run_chatgpt_command
M.run_chatgpt_paste_command = run_chatgpt_paste_command
M.run_chatgpt_current_buffer_command = run_chatgpt_current_buffer_command
function _G.chatgpt_file_complete(findstart, base)
if findstart == 1 then
local line = vim.fn.getline('.')
local col = vim.fn.col('.')
local start = line:sub(1, col):find("@[^%s]*$")
if start then
return start - 1
else
return -1
end
else
local conf = config.load()
local files = context.get_project_files({'.'}, conf)
local completions = {}
local esc_base = base:gsub("([^%w])", "%%%1")
for _, f in ipairs(files) do
if f:match("^" .. esc_base) then
table.insert(completions, f)
end
end
return completions
end
end
return M

327
lua/chatgpt_nvim/prompts.lua
View file

@ -1,82 +1,5 @@
local M = {
["memory-bank"] = [[
# Memory Bank
You are Cline, an expert software engineer with a unique constraint: your memory periodically resets completely. This isn't a bug - it's what makes you maintain perfect documentation. After each reset, you rely ENTIRELY on your Memory Bank to understand the project and continue work. Without proper documentation, you cannot function effectively.
## Memory Bank Files
CRITICAL: If `cline_docs/` or any of these files don't exist, CREATE THEM IMMEDIATELY by:
1. Reading all provided documentation
2. Asking user for ANY missing information
3. Creating files with verified information only
4. Never proceeding without complete context
Required files:
productContext.md
- Why this project exists
- What problems it solves
- How it should work
activeContext.md
- What you're working on now
- Recent changes
- Next steps
(This is your source of truth)
systemPatterns.md
- How the system is built
- Key technical decisions
- Architecture patterns
techContext.md
- Technologies used
- Development setup
- Technical constraints
progress.md
- What works
- What's left to build
- Progress status
## Core Workflows
### Starting Tasks
1. Check for Memory Bank files
2. If ANY files missing, stop and create them
3. Read ALL files before proceeding
4. Verify you have complete context
5. Begin development. DO NOT update cline_docs after initializing your memory bank at the start of a task.
### During Development
1. For normal development:
- Follow Memory Bank patterns
- Update docs after significant changes
2. Say `[MEMORY BANK: ACTIVE]` at the beginning of every tool use.
### Memory Bank Updates
When user says "update memory bank":
1. This means imminent memory reset
2. Document EVERYTHING about current state
3. Make next steps crystal clear
4. Complete current task
Remember: After every memory reset, you begin completely fresh. Your only link to previous work is the Memory Bank. Maintain it as if your functionality depends on it - because it does.
]],
["solidjs"] = [[
["solidjs-development"] = [[
### SolidJS Development Guidelines
You are helping me develop a large SolidJS application. Please keep the following points in mind when generating or explaining code:
@ -121,7 +44,7 @@ local M = {
5. **Styling & CSS Management**
- Use your preferred styling approach (CSS Modules, [Tailwind CSS](https://tailwindcss.com/), or standard CSS/SCSS files).
- Keep global styles minimal, focusing on utility classes or base styling; keep component-level styles scoped whenever possible.
- If using CSS-in-JS solutions or third-party libraries, ensure they integrate cleanly with Solid’s reactivity.
- If using CSS-in-JS solutions or third-party libraries, ensure they integrate cleanly with Solid’s reactivity.
6. **TypeScript & Linting**
- Use **TypeScript** to ensure type safety and improve maintainability.
@ -150,111 +73,21 @@ local M = {
Please follow these guidelines to ensure the generated or explained code aligns well with SolidJS best practices for large, maintainable projects.
]],
["nodejs"] = [[
You are helping me develop a large Node.js application. Please keep the following points in mind when generating or explaining code:
1. **Project & Folder Structure**
- Maintain a clear, top-level directory layout. For example:
```
my-node-app/
├── src/
│ ├── controllers/
│ ├── models/
│ ├── routes/
│ ├── services/
│ ├── utils/
│ └── index.js (or app.js)
├── tests/
│ └── ...
├── package.json
├── .env (if needed)
├── .eslintrc.js
└── ...
```
- Keep your application logic separated in folders:
- **controllers/** (or handlers) for request handling logic,
- **services/** for core business logic or data processing,
- **models/** for database schemas/entities,
- **routes/** for defining routes/endpoints,
- **utils/** for reusable helper functions.
2. **Dependencies & Package Management**
- Use **npm** or **yarn** (pick one and stay consistent) to manage dependencies.
- Keep your `package.json` clean by removing unused dependencies.
- Pin exact versions for critical or sensitive dependencies to ensure reproducible builds.
3. **Configuration & Environment Variables**
- Use environment variables to store sensitive or environment-specific information (e.g., database credentials, API keys).
- Consider a config management library (like [dotenv](https://github.com/motdotla/dotenv) or [dotenv-flow](https://github.com/kerimdzhanov/dotenv-flow)) to load environment variables from `.env` files.
- Keep secrets out of version control (e.g., `.env` should be in `.gitignore`).
4. **Code Organization & Module Patterns**
- Use **ES Modules** (`import`/`export`) or **CommonJS** (`require`/`module.exports`) consistently across the project.
- Keep each module focused on a single responsibility.
- Use a **service layer** for business logic to avoid bloated controllers.
- Use **async/await** for asynchronous operations, ensuring proper error handling (try/catch blocks or .catch callbacks).
5. **Database & Data Persistence**
- Use an ORM/ODM (e.g., [Sequelize](https://sequelize.org/) for SQL, [Mongoose](https://mongoosejs.com/) for MongoDB) or a query builder ([Knex.js](https://knexjs.org/)) to maintain cleaner database interactions.
- Keep database-related logic in separate **models/** or **repositories/**.
- Handle database migrations carefully (e.g., with [db-migrate](https://db-migrate.readthedocs.io/), [Liquibase](https://www.liquibase.org/), or built-in ORM migration tools).
6. **Logging & Monitoring**
- Use a structured logging library (e.g., [Winston](https://github.com/winstonjs/winston), [Pino](https://github.com/pinojs/pino)) to capture logs in JSON or another parseable format.
- Ensure logs include enough context (request IDs, timestamps, etc.) to troubleshoot issues.
- Consider external logging and monitoring solutions (e.g., [Datadog](https://www.datadoghq.com/), [New Relic](https://newrelic.com/)) for production environments.
7. **Security & Best Practices**
- Sanitize and validate all user inputs (e.g., using libraries like [validator](https://github.com/validatorjs/validator.js)).
- Avoid SQL injection by using parameterized queries or ORM features.
- Implement rate limiting or request throttling to prevent abuse (e.g., [express-rate-limit](https://github.com/nfriedly/express-rate-limit)).
- Ensure **HTTPS** is used in production and secure headers are set (e.g., [helmet](https://github.com/helmetjs/helmet) for Express).
- Keep dependencies updated to patch known vulnerabilities (use `npm audit` or equivalent).
8. **Error Handling**
- Use centralized error handling middleware (if using a framework like Express) to catch and process errors consistently.
- Provide clear error messages but avoid leaking sensitive info in production.
- Separate operational errors (e.g., user-related) from programmer errors (e.g., logic bugs) to handle them appropriately.
9. **Testing & Quality Assurance**
- Write **unit tests** for individual modules or functions (e.g., using [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/)).
- Use **integration tests** or **end-to-end tests** (e.g., [Supertest](https://github.com/visionmedia/supertest) for API endpoints).
- Aim for high coverage but focus on critical business logic and error cases.
- Automate tests in your CI pipeline.
10. **Linting & Formatting**
- Use **ESLint** (with recommended or popular config like [Airbnb](https://www.npmjs.com/package/eslint-config-airbnb)) for consistent code quality.
- Use **Prettier** for code formatting to maintain a standardized style.
- Configure linting and formatting checks in a pre-commit hook or CI (e.g., [Husky](https://typicode.github.io/husky/), [lint-staged](https://github.com/okonet/lint-staged)).
11. **Deployment & Environment Management**
- Containerize your app with Docker if possible, specifying a secure and minimal base image.
- Use process managers like [PM2](https://pm2.keymetrics.io/) or systemd for production Node.js processes.
- Maintain separate configuration (or environment variables) for staging, production, etc.
12. **Output Format**
- Present any generated source code with clear folder and file placement (e.g., `controllers/`, `services/`).
- When explaining your reasoning, highlight the architectural decisions or patterns used (e.g., “I introduced a service layer to separate business logic from route handling.”).
- If you modify existing files, specify precisely which lines or sections have changed, and why.
Please follow these guidelines to ensure the generated or explained code aligns well with Node.js best practices for large, maintainable projects.
]],
["go"] = [[
["go-development"] = [[
### Go Development Guidelines
You are helping me develop a large Go (Golang) project. Please keep the following points in mind when generating or explaining code:
1. **Go Modules & Dependency Management**
1. **Go Modules**
- Use a single `go.mod` file at the project root for module management.
- Ensure you use proper import paths based on the module name.
- If you refer to internal packages, use relative paths consistent with the module’s structure (e.g., `moduleName/internal/packageA`).
- **Use the execute_command Tool for Dependencies:** Instead of manually editing version numbers in `go.mod`, please utilize the `execute_command` tool to run dependency commands (such as `go get`) to automatically fetch and update dependencies. This ensures that the correct versions are used without relying on manually provided values.
- If you refer to internal packages, use relative paths consistent with the module’s structure (e.g., `moduleName/internal/packageA`).
2. **Package Structure**
- Each folder should contain exactly one package.
- Avoid creating multiple packages in the same folder.
- Use descriptive folder names and keep package names concise, following Go naming conventions.
- Do not duplicate function or type names across different files in the same folder/package.
- Do not duplicate function or type names across different files in the same folder/package.
3. **File & Folder Organization**
- Organize source code in a folder hierarchy that reflects functionality. For example:
@ -272,26 +105,28 @@ local M = {
└── shared/
```
- Keep external-facing, reusable packages in `pkg/` and internal logic in `internal/`.
- Place the `main()` function in the `cmd/<appname>` folder.
- Place the `main()` function in the `cmd/<appname>` folder.
4. **Coding Best Practices**
- Maintain idiomatic Go code (e.g., short function and variable names where obvious, PascalCase for exported symbols).
- Keep functions short, focused, and tested.
- Use Go’s standard library where possible before adding third-party dependencies.
- When introducing new functions or types, ensure they are uniquely named to avoid collisions.
- Use Go’s standard library where possible before adding third-party dependencies.
- When introducing new functions or types, ensure they are uniquely named to avoid collisions.
5. **Import Management**
- Ensure that every import is actually used in your code.
- Remove unused imports to keep your code clean and maintainable.
- Include all necessary imports for anything referenced in your code to avoid missing imports.
- Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.
- Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.
6. **Output Format**
- Present any generated source code as well-organized Go files, respecting the single-package-per-folder rule.
- When explaining your reasoning, include any relevant architectural trade-offs and rationale (e.g., “I placed function X in package `my_lib` to keep the business logic separate from the command-line interface.”).
- If you modify existing files, specify precisely which changes or additions you are making.
- When explaining your reasoning, include any relevant architectural trade-offs and rationale (e.g., “I placed function X in package Y to keep the domain-specific logic separate from the main execution flow.”).
- If you modify an existing file, specify precisely which changes or additions you are making.
Please follow these guidelines to ensure the generated or explained code aligns well with Golang’s best practices for large, modular projects.
]],
["typo3"] = [[
["typo3-development"] = [[
### TYPO3 Development Guidelines
You are helping me develop a large TYPO3 project. Please keep the following points in mind when generating or explaining code:
@ -315,10 +150,10 @@ local M = {
- Keep site configuration in `config/sites/` (for TYPO3 v9+).
2. **Extension Development**
- Create custom functionality as separate extensions (site packages, domain-specific extensions, etc.) following TYPO3’s recommended structure:
- Create custom functionality as separate extensions (site packages, domain-specific extensions, etc.) following TYPO3’s recommended structure:
- **Key files**: `ext_emconf.php`, `ext_localconf.php`, `ext_tables.php`, `ext_tables.sql`, `Configuration/`, `Classes/`, `Resources/`.
- Use **PSR-4** autoloading and name extensions logically (e.g., `my_sitepackage`, `my_blogextension`).
- Keep your extension’s code under `Classes/` (e.g., Controllers, Models, Services).
- Keep your extension’s code under `Classes/` (e.g., Controllers, Models, Services).
- Place Fluid templates, partials, and layouts under `Resources/Private/` (e.g., `Resources/Private/Templates`, `Resources/Private/Partials`, `Resources/Private/Layouts`).
3. **Configuration (TypoScript & TCA)**
@ -351,10 +186,12 @@ local M = {
7. **Output Format**
- Present any generated source code or configuration files in a well-organized structure.
- Clearly indicate where each file should be placed in the TYPO3 directory layout.
- When explaining your reasoning, include any relevant architectural decisions (e.g., “I created a separate extension for blog functionality to keep it isolated from the site’s main configuration.”).
- When explaining your reasoning, include any relevant architectural decisions (e.g., “I created a separate extension for blog functionality to keep it isolated from the site’s main configuration.”).
- If you modify or extend an existing file, specify precisely which changes or additions you are making.
Please follow these guidelines to ensure the generated or explained code aligns well with TYPO3’s best practices for large, maintainable projects.
]],
["rust"] = [[
["rust-development"] = [[
### Rust Development Guidelines
You are helping me develop a large Rust project. Please keep the following points in mind when generating or explaining code:
@ -367,11 +204,11 @@ local M = {
2. **Crates & Packages**
- Split the application into logical crates (libraries and/or binaries).
- Each crate should have a single main **library** (`lib.rs`) or **binary** (`main.rs`) in its `src/` folder.
- Name crates, modules, and files clearly, following Rust’s naming conventions (e.g., `snake_case` for files/modules, `PascalCase` for types).
- Name crates, modules, and files clearly, following Rust’s naming conventions (e.g., `snake_case` for files/modules, `PascalCase` for types).
- Avoid duplicating the same function or type in multiple crates; share common functionality via a dedicated library crate if needed.
3. **Folder & Module Structure**
- Organize code within each crate using Rust’s module system, keeping related functions and types in logical modules/submodules.
- Organize code within each crate using Rust’s module system, keeping related functions and types in logical modules/submodules.
- A typical directory layout for a workspace with multiple crates might look like:
```
myproject/
@ -389,19 +226,19 @@ local M = {
├── target/
└── ...
```
- If you have integration tests, store them in a `tests/` folder at the crate root, or use the workspace root’s `tests/` directory if they span multiple crates.
- If you have integration tests, store them in a `tests/` folder at the crate root, or use the workspace root’s `tests/` directory if they span multiple crates.
4. **Coding & Documentation Best Practices**
- Write **idiomatic Rust** code:
- Use `cargo fmt` (formatting) and `cargo clippy` (linter) to maintain consistency and quality.
- Use the `?` operator for error handling, preferring `Result<T, E>` over panicking unless absolutely necessary.
- Use `?` operator for error handling, prefer `Result<T, E>` over panicking unless absolutely necessary.
- Document your code using [Rustdoc](https://doc.rust-lang.org/rustdoc/) comments (`///` for public API) and provide examples when relevant.
- Write **unit tests** alongside the code (in `src/` files) and **integration tests** in a dedicated `tests/` folder.
- Keep functions short, focused, and ensure they have well-defined responsibilities.
5. **Reusability & Shared Code**
- Place common or reusable functionality into a dedicated **library** crate.
- Ensure that crates depending on shared code add the appropriate `[dependencies]` or `[dev-dependencies]` in their Cargo.toml.
- Ensure that crates depending on shared code add the appropriate `[dependencies]` or `[dev-dependencies]` in their `Cargo.toml`.
- Use the Rust standard library whenever possible before introducing external dependencies.
6. **Error Handling & Logging**
@ -413,95 +250,22 @@ local M = {
- Present generated source code as well-organized Rust files, respecting the single main library or binary per crate (`lib.rs` or `main.rs`).
- When explaining your reasoning, include any architectural or design decisions (e.g., “I placed function X in crate `my_lib` to keep the business logic separate from the command-line interface.”).
- If you modify existing files, specify precisely which lines or sections have changed.
Please follow these guidelines to ensure the generated or explained code aligns well with Rust best practices for large, modular projects.
]],
["basic"] = [[
["basic-prompt"] = [[
### Basic Prompt
You are assisting me in a coding workflow for a project (e.g., "%PROJECT_NAME%"). **Every time you inspect, modify, or execute operations on files, you must strictly follow the YAML format described below.** Under no circumstances should you output file operations in plain text or deviate from this structure.
You are assisting me in a coding workflow for a project (e.g., "my_project"). Whenever you need to inspect or modify files, or execute commands, you must provide both:
#### Mandatory Guidelines
1. **YAML-Only File Operations**
- **All operations must be provided within one single YAML block** that includes both the `project_name` and the `tools` array.
- If you need to ask questions or request clarifications, do so only in plain text separate from YAML. **Never include non-YAML tool commands.**
2. **Include the Project Name**
- Always include:
```yaml
project_name: "%PROJECT_NAME%"
```
This must be part of every YAML block you generate.
3. **Operations Must Appear in the Tools Array**
- List all actions (e.g., reading, editing, replacing, executing commands) as items in the `tools:` array. If multiple actions are needed, include them sequentially within the same YAML block.
4. **Read Before Write Rule**
- **Do not perform any write operations (using `edit_file` or `replace_in_file`) on an existing file unless you have already read its content in the current session using a `read_file` operation.**
- For new files (files that do not yet exist in the project), this rule does not apply.
- If yo already got the file contents in the first prompt, this rule does not apply.
- **Never** mix read_file with edit_file or replace_in_file in the same YAML block.
5. **File Inspection Before Modification**
- When you need to inspect a file’s contents, always use the following YAML format:
```yaml
project_name: "%PROJECT_NAME%"
tools:
- tool: "read_file"
path: "relative/path/to/file"
```
- Use the information from this operation to decide if and how to modify the file.
6. **Modifying Files**
- To modify a file that you have already read, use:
```yaml
project_name: "%PROJECT_NAME%"
tools:
- tool: "edit_file"
path: "relative/path/to/file"
content: |
# Full updated file content here
```
- Alternatively, for incremental changes, use:
```yaml
project_name: "%PROJECT_NAME%"
tools:
- tool: "replace_in_file"
path: "relative/path/to/file"
replacements:
- search: "old text"
replace: "new text"
```
7. **Executing Commands**
- To run any shell command (e.g., testing, listing files), use:
```yaml
project_name: "%PROJECT_NAME%"
tools:
- tool: "execute_command"
command: "shell command here"
```
8. **General Process**
- **Step 1: Gather Context / Ask Questions**
If any detail is unclear (such as file content or operation intent), ask your clarifying questions in plain text (not in YAML).
- **Step 2: Inspect Files**
Always use `read_file` to check file content before modifying.
- **Step 3: Repeat Steps 1 & 2 as Needed**
If further context is required, ask questions and read files again.
- **Step 4: Make Changes**
Only after reading the file, proceed to use `edit_file` or `replace_in_file`.
- **Step 5: Execute Commands if Needed**
Use `execute_command` as necessary, always within the YAML block.
- **Step 6: Tell that request is complete**
Once all operations are done, confirm that the request is complete with a little summary.
- **Step 7: Repeat other steps as necessary**
#### Example YAML Block
1. `project_name: "<actual_project_name>"` (matching the real project name)
2. A `tools:` array describing the operations you want to perform.
**Example** (substitute `<actual_project_name>` with the real name):
```yaml
project_name: "%PROJECT_NAME%"
project_name: "my_project"
tools:
- tool: "read_file"
- tool: "readFile"
path: "relative/path/to/file"
- tool: "replace_in_file"
@ -510,24 +274,23 @@ local M = {
- search: "old text"
replace: "new text"
- tool: "edit_file"
- tool: "editFile"
path: "relative/path/to/file"
content: |
# Full updated file content here
- tool: "execute_command"
- tool: "executeCommand"
command: "ls -la"
```
#### Important Reminders
- **Always** include the `project_name` and the full YAML block with the `tools` array when calling operations.
- **Never** write or modify a file without first having read its content during the current session (unless the file is new).
- **Do not** produce any tool command output that is not strictly formatted as YAML.
---
This revised prompt ensures that during execution the placeholder "%PROJECT_NAME%" is replaced with the actual project name from the current configuration.
**Key Points**:
- Always include `project_name: "<actual_project_name>"` in the same YAML as `tools`.
- If you only need one tool, include just one object in the `tools` array.
- If multiple tools are needed, list them sequentially in the `tools` array.
- Always run at least one tool (e.g., `readFile`, `editFile`, `executeCommand`), exept you have finished.
- Always just include one yaml in the response with all the tools you want to run in that yaml.
- The plugin will verify the `project_name` is correct before running any tools.
- If the response grows too large, I'll guide you to break it into smaller steps.
]],
["secure-coding"] = [[
### Secure Coding Guidelines

29
lua/chatgpt_nvim/tools/execute_command.lua
View file

@ -1,36 +1,17 @@
local M = {}
M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file)
-- Validate the command exists
local cmd = tool_call.command
if not cmd then
return "[execute_command] Missing 'command'."
return "[executeCommand] Missing 'command'."
end
-- Capture stderr and stdout together by redirecting stderr to stdout
-- This will help diagnose if there's an error causing no output
cmd = cmd .. " 2>&1"
-- Attempt to popen the command
local handle = io.popen(cmd, "r")
local handle = io.popen(cmd)
if not handle then
return string.format("Tool [execute_command '%s'] FAILED to popen.", cmd)
return string.format("Tool [executeCommand '%s'] FAILED to popen.", cmd)
end
-- Read the full output (stdout + stderr)
local result = handle:read("*a") or ""
-- Attempt to close, capturing exit info
local _, exit_reason, exit_code = handle:close()
-- Provide a richer summary including exit code and reason
return string.format(
"Tool [execute_command '%s'] exited with code %s (%s)\n%s",
cmd,
tostring(exit_code),
tostring(exit_reason),
result
)
handle:close()
return string.format("Tool [executeCommand '%s'] Result:\n%s", cmd, result)
end
return M

20
lua/chatgpt_nvim/tools/init.lua
View file

@ -8,13 +8,13 @@ local M = {}
-- We can store a table of available tools here
M.available_tools = {
{
name = "read_file",
usage = "Retrieve the contents of a file. Provide { tool='read_file', path='...' }",
name = "readFile",
usage = "Retrieve the contents of a file. Provide { tool='readFile', path='...' }",
explanation = "Use this to read file content directly from the disk."
},
{
name = "edit_file",
usage = "Overwrite an entire file's content. Provide { tool='edit_file', path='...', content='...' }, Allways include the whole file content",
name = "editFile",
usage = "Overwrite an entire file's content. Provide { tool='editFile', path='...', content='...' }",
explanation = "Use this when you want to replace a file with new content."
},
{
@ -23,17 +23,17 @@ M.available_tools = {
explanation = "Use this to apply incremental changes without fully overwriting the file."
},
{
name = "execute_command",
usage = "Run a shell command. Provide { tool='execute_command', command='...' }",
explanation = "Just run one single command per tool invocation, without comment. It must be a single line. Use with caution, especially for destructive operations (rm, sudo, etc.)."
name = "executeCommand",
usage = "Run a shell command. Provide { tool='executeCommand', command='...' }",
explanation = "Use with caution, especially for destructive operations (rm, sudo, etc.)."
},
}
M.tools_by_name = {
read_file = read_file_tool,
edit_file = edit_file_tool,
readFile = read_file_tool,
editFile = edit_file_tool,
replace_in_file = replace_in_file_tool,
execute_command = execute_command_tool
executeCommand = execute_command_tool
}
return M

18
lua/chatgpt_nvim/tools/lsp_robust_diagnostics.lua
View file

@ -86,12 +86,12 @@ local function send_did_open(bufnr, client_id, path, filetype)
return nil
end
local function send_did_change(bufnr, client_id, path)
local function send_did_change(bufnr, client_id)
local client = lsp.get_client_by_id(client_id)
if not client then return end
local text = table.concat(api.nvim_buf_get_lines(bufnr, 0, -1, false), "\n")
local uri = vim.uri_from_fname(path)
local uri = vim.uri_from_bufnr(bufnr)
local version = 1
client.rpc.notify("textDocument/didChange", {
@ -105,7 +105,6 @@ local function send_did_change(bufnr, client_id, path)
})
end
-- Use vim.wait to allow the event loop to process LSP diagnostics
local function wait_for_diagnostics(bufnr, timeout_ms)
local done = false
local result_diags = {}
@ -122,9 +121,12 @@ local function wait_for_diagnostics(bufnr, timeout_ms)
end
})
vim.wait(timeout_ms, function()
return done
end, 50)
local waited = 0
local interval = 50
while not done and waited < timeout_ms do
vim.cmd(("sleep %d m"):format(interval))
waited = waited + interval
end
pcall(api.nvim_del_augroup_by_id, augrp)
return result_diags
@ -162,8 +164,8 @@ function M.lsp_check_file_content(path, new_content, timeout_ms)
return "(LSP) " .. err2
end
-- Optionally do a didChange with consistent URI
send_did_change(bufnr, client_id, path)
-- Optionally do a didChange
send_did_change(bufnr, client_id)
local diags = wait_for_diagnostics(bufnr, timeout_ms or 2000)
local diag_str = diagnostics_to_string(diags)

4
lua/chatgpt_nvim/tools/manager.lua
View file

@ -16,8 +16,8 @@ end
local function prompt_user_tool_accept(tool_call, conf)
local auto_accept = conf.tool_auto_accept[tool_call.tool]
-- If this is an execute_command and we see it's destructive, force a user prompt
if tool_call.tool == "execute_command" and auto_accept then
-- If this is an executeCommand and we see it's destructive, force a user prompt
if tool_call.tool == "executeCommand" and auto_accept then
if is_destructive_command(tool_call.command) then
auto_accept = false
end

41
lua/chatgpt_nvim/tools/replace_in_file.lua
View file

@ -3,41 +3,14 @@ local robust_lsp = require("chatgpt_nvim.tools.lsp_robust_diagnostics")
local M = {}
-- Function to escape all Lua pattern magic characters:
local function escape_lua_pattern(s)
return s:gsub("([%^%$%(%)%%%.%[%]%*%+%-%?])", "%%%1")
end
local function search_and_replace(original, replacements)
local updated = original
local info_msgs = {}
for _, r in ipairs(replacements) do
local search_str = r.search or ""
local replace_str = r.replace or ""
-- Escape special pattern chars to ensure literal matching:
local escaped_search = escape_lua_pattern(search_str)
local replacement_count = 0
updated, replacement_count = updated:gsub(escaped_search, replace_str)
-- If the string was not found, append an info message
if replacement_count == 0 then
table.insert(info_msgs, string.format(
"[replace_in_file Info] The string '%s' was NOT found in the file and was not replaced.",
search_str
))
else
table.insert(info_msgs, string.format(
"[replace_in_file Info] The string '%s' was replaced %d time(s).",
search_str,
replacement_count
))
end
updated = updated:gsub(search_str, replace_str)
end
return updated, table.concat(info_msgs, "\n")
return updated
end
M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file)
@ -47,8 +20,8 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
if not path or #replacements == 0 then
return "[replace_in_file] Missing 'path' or 'replacements'."
end
local root = vim.fn.getcwd()
if not is_subpath(root, path) then
return string.format("Tool [replace_in_file for '%s'] REJECTED. Path outside project root.", path)
end
@ -58,8 +31,7 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
return string.format("[replace_in_file for '%s'] FAILED. Could not read file.", path)
end
-- Now we get not only the updated data but also info messages about replacements
local updated_data, info_messages = search_and_replace(orig_data, replacements)
local updated_data = search_and_replace(orig_data, replacements)
handler.write_file(path, updated_data, conf)
local msg = {}
@ -68,11 +40,6 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
msg[#msg+1] = string.format("<final_file_content path=\"%s\">\n%s\n</final_file_content>", path, updated_data)
msg[#msg+1] = "\nIMPORTANT: For any future changes to this file, use the final_file_content shown above as your reference.\n"
-- If there are any info messages (strings not found, etc.), include them
if info_messages and info_messages ~= "" then
msg[#msg+1] = "\nAdditional info about the replacement operation:\n" .. info_messages .. "\n"
end
if conf.auto_lint then
local diag_str = robust_lsp.lsp_check_file_content(path, updated_data, 3000)
msg[#msg+1] = "\n" .. diag_str