new diagnostics context generating errors

[gennaro-tedesco]

I am using the new #diagnostics context as per the latest PR

BREAKING CHANGE: diagnostics moved to separate tool call, selection and buffer calls no longer include them by default

As you can see they are stickied correctly to the buffer

However, upon invoking #diagnostics (say to list or correct the actual errors) I get

error
attempt to index field 'severity' (a nil value)

independent of the model I choose - different models then go ahead and explain why such error occurs, however it seems to be an underlying implementation bug, or does it work correctly in your case? This by the way shows also if one includes the new "diagnostics" in any custom prompt, namely it excepts with the aforementioned error.

P. S. If I lock the repository back to commit d0537a7 then all works as intended if I specify diagnostics myself like in here

[deathbeam]

Hmm yea looks like im not resolving defaults properly, nice find, created a fix.

[gennaro-tedesco]

I have just pulled the latest commit and installed the patch: while the error no longer occurs, it seems that the context ("sticky") really is ignored, not only for the diagnostics, but also for the buffer - namely nothing is read into context and passed to the model, see screenshots below

or

I have also tried with a minimal configuration (namely only defaults) and it seems it is unable to really retrieve the buffer diagnostics altogether. Does it work in your case, perhaps I have misunderstood how the new diagnostic context must be used (though it seems that even just the buffer code isn't passed to the model, the context isn't seen at all)?

[deathbeam]

I have just pulled the latest commit and installed the patch: while the error no longer occurs, it seems that the context ("sticky") really is ignored, not only for the diagnostics, but also for the buffer - namely nothing is read into context and passed to the model, see screenshots below

or I have also tried with a minimal configuration (namely only defaults) and it seems it is unable to really retrieve the buffer diagnostics altogether. Does it work in your case, perhaps I have misunderstood how the new diagnostic context must be used (though it seems that even just the buffer code isn't passed to the model, the context isn't seen at all)?

Yea I tried it, with #diagnostics I can see them in the context (with gc):

neovim://diagnostics//home/deathbeam/git/CopilotChat.nvim/lua/CopilotChat/init.lua (18 lines) (truncated)

ERROR line=881-881: Unexpected <exp> .
  >     endD
ERROR line=884-884: Missed symbol `if`.
  >   else
ERROR line=1250-1250: Missed symbol `end`.
  > return M
ERROR line=861-861: Miss corresponding `end` .
  >   if not config.headless then
ERROR line=1250-1250: Missed symbol `end`.
  > return M

[deathbeam]

also here for the prompt

You need to use # before

[gennaro-tedesco]

I might have identified the issue a little better: as you say, if one explicitly passes the context with #, then it is considered. However, stickied context and system prompts (as per here) seem not to work - might it have to do with renaming of the options table perhaps that might not be reflected in the current prompts?

For instance see the below: I have stickied tools to be buffers and diagnostics

however when running the default system prompt to Optimize I get the following

and the model doesn't actually see the code that we ask to optimise. If instead I

1. explicitly attach new context (via @ or #)
2. explicitly write a prompt/question (not using the default prompts)

then all works fine (which is why I presume the stickied context, though showing in the info, isn't actually sent to the system prompts).

[deathbeam]

Hmm yea I accidentally broke sticky loading so shouldbe fixed here:

#1210

But just tested it with that aswell and it worked fine,

In your screenshot above you did not shared resource via # but you enabled tool via @ and tools need to be used by LLM

[gennaro-tedesco]

In your screenshot above you did not shared resource via # but you enabled tool via @ and tools need to be used by LLM

hmm, this could be because of

BREAKING CHANGE: config.contexts renamed to config.tools

after the latest changes, with the current version, what is the option to pass contexts by default when opening a chat session (or when utilising default prompts)? According to the above it should be by specifying them as

{
  tools = { "buffers", "diagnostics" },
..
}

but then this would make them tools? Should it then be

{
  sticky = { "buffers", "diagnostics" },
..
}

[deathbeam]

Well tools are just for the automatic LLM calls so LLM knowns about them, for extra context you now just use sticky:

{
  sticky = { "#buffers", "#diagnostics" }
}

note the # at the beginning

[gennaro-tedesco]

note the # at the beginning

Aaaaaah, that was the problem, now all works as intended! :D

Thank you for looking into this so thoroughly!