Secret could be lazy-loaded to play nicer with password manager CLIs

[fredrikaverpil]

Hi and thanks for making this excellent plugin! 👋

I store my API keys in 1Password, and I've configured the secrets to be loaded from a CLI. For example:

return {
  {
    "robitx/gp.nvim",
    opts = {
      providers = {
        openai = {
          endpoint = "https://api.openai.com/v1/chat/completions",
          secret = { "op", "read", "op://Personal/xxx/yyy/zzz", "--no-newline" },
        },
      },
    },
  },
}

This has the unfortunate side-effect of popping up a window every time I start nvim, for each provider/secret where I use the op CLI.:

It would be great if you could consider lazy-loading the secret when it is required, so that the window would only pop up, well, when the given agent is requesting to use a certain provider (and its secret). This way, I wouldn't get these popups everytime I start up Neovim.

Or perhaps there's some other way to configure the plugin so that this doesn't get triggered unless I e.g. type :GpChatNew or similar?

[Robitx]

@fredrikaverpil latest version resolves secrets only when they are used

[fredrikaverpil]

Great work @Robitx it works! 🚀 With this change, I'm only prompted when I invoke a :Gp... command. 👍 🎉

A side-note, I'm noticing an error when using the default gpt4o agent (but claude 3.5 sonnet was fine as comparison):

   Info  12:42:22 notify.info Gp.nvim Gp.nvim: Command agent: CodeGPT4o
   Error  12:42:33 msg_show.lua_error Error executing vim.schedule lua callback: ...redrik/.local/share/fredrik/lazy/gp.nvim/lua/gp/init.lua:1805: 'start' is higher than 'end'
stack traceback:
    [C]: in function 'nvim_buf_set_lines'
    ...redrik/.local/share/fredrik/lazy/gp.nvim/lua/gp/init.lua:1805: in function 'on_exit'
    ...redrik/.local/share/fredrik/lazy/gp.nvim/lua/gp/init.lua:1953: in function ''
    vim/_editor.lua: in function <vim/_editor.lua:0>

[Robitx]

@fredrikaverpil that's a new one, are you able to get this error deterministically?

[fredrikaverpil]

@Robitx never mind, I can't reproduce this anymore... not sure how come I got this all the time earlier but not now. 🤷

Thanks for you work on all this! Feel free to close this issue.

[Robitx]

@fredrikaverpil the only way I managed to get this was by prompting the model to respond with a single opened triple backticks at the start of the file, so that first and last response line would be both zero causing ll-1 to underflow to the end of the buffer and tripping VALIDATE((start <= end), "%s", "'start' is higher than 'end'".

vim.api.nvim_buf_set_lines(buf, ll - 1, ll, false, {})

/// Sets (replaces) a line-range in the buffer.
///
/// Indexing is zero-based, end-exclusive. Negative indices are interpreted
/// as length+1+index: -1 refers to the index past the end. So to change
/// or delete the last element use start=-2 and end=-1.

Added fl < ll check to prevent this. Thanks for the report & closing.