[Bug]: Misleading text about shared references

[last-partizan]

Your minimal.lua config

irrelevant

Error messages

No response

Log output

irrelevant

Health check output

No response

Describe the bug

It's not really a breaking bug, but more like how the plugin displays shared variables.

> Sharing: ... is added to the next message, but in it does not actually adds any variables to the second message.

Expected behavior is probably - display variables only on the original message.

## Me ─

> Sharing:
> - /tmp/test.txt

#buffer

I'm testing how sharing context works. Display me received file. Short answer, no suggestions on next steps.


## copilot ─

```text
Version 1
```

## Me ─

> Sharing:
> - /tmp/test.txt

How about now?

## copilot ─

```text
Version 1
```

Json log from gd:

--Settings
adapter = "copilot"
n = 1
model = "claude-3.5-sonnet"
max_tokens = 4096
temperature = 0
top_p = 1

--Messages
{ {
    content = "You are an AI programming assistant named \"CodeCompanion\".\nYou are currently plugged in to the Neovim text editor on a user's machine.\n\nYour core tasks include:\n- Answering general programming questions.\n- Explaining how the code in a Neovim buffer works.\n- Reviewing the selected code in a Neovim buffer.\n- Generating unit tests for the selected code.\n- Proposing fixes for problems in the selected code.\n- Scaffolding code for a new workspace.\n- Finding relevant code to the user's query.\n- Proposing fixes for test failures.\n- Answering questions about Neovim.\n- Running tools.\n\nYou must:\n- Follow the user's requirements carefully and to the letter.\n- Keep your answers short and impersonal, especially if the user responds with context outside of your tasks.\n- Minimize other prose.\n- Use Markdown formatting in your answers.\n- Include the programming language name at the start of the Markdown code blocks.\n- Avoid line numbers in code blocks.\n- Avoid wrapping the whole response in triple backticks.\n- Only return code that's relevant to the task at hand. You may not need to return all of the code that the user has shared.\n- Use actual line breaks instead of '\\n' in your response to begin new lines.\n- Use '\\n' only when you want a literal backslash followed by a character 'n'.\n- All non-code responses must use English.\n\nWhen given a task:\n1. Think step-by-step and describe your plan for what to build in pseudocode, written out in great detail, unless asked not to do so.\n2. Output the code in a single code block, being careful to only return relevant code.\n3. You should always generate short suggestions for the next user turns that are relevant to the conversation.\n4. You can only give one reply for each conversation turn.",
    id = 1947269257,
    opts = {
      visible = false
    },
    role = "system"
  }, {
    content = "I'm testing how sharing context works. Display me received file. Short answer, no suggestions on next steps.",
    id = -546777357,
    opts = {
      visible = true
    },
    role = "user"
  }, {
    content = "Buffer ID: 1\nName: test.txt\nPath: /tmp/test.txt\nFiletype: text\nContent:\n```text\n1:  Version 1\n```\n",
    id = -454189760,
    opts = {
      reference = "/tmp/test.txt",
      tag = "variable",
      visible = false
    },
    role = "user"
  }, {
    content = "```text\nVersion 1\n```",
    id = 1226543241,
    opts = {
      visible = true
    },
    role = "llm"
  }, {
    content = "How about now?",
    id = 419434627,
    opts = {
      visible = true
    },
    role = "user"
  }, {
    content = "```text\nVersion 1\n```",
    id = 1226543241,
    opts = {
      visible = true
    },
    role = "llm"
  } }

Reproduce the bug

1. Share a #buffer with agent
2. Look as "> Sharing" in second message (unexpected)

Final checks

• I have made sure this issue exists in the latest version of the plugin
• I have tested with the minimal.lua file from above and have shared this
• I have shared the contents of the log file

[GitMurf]

I love the fact that it does not re-share all the buffer content over and over each message (to keep the context size "leaner"). But I agree there needs to be a way to "update" the content when you want to after changing the buffer. What if a timestamp gets added to the reference for the buffer so you can see when it was shared (and thus the time of content being used from that buffer) and if you include again in a message later the #buffer tag then that means you would like to update the content so it would add an updated copy of the buffer and then would update the timestamp of the buffer in the references list.

thoughts?

[GitMurf]

So maybe the references say something like:

Sharing:

• /tmp/test.txt (as of 10:15 AM)

[GitMurf]

In a perfect world what would be VERY cool is if using the same timestamp concept, the references could highlight / flag any shared reference items that have recent changes... meaning if you update a buffer file and save, the references simply check the last modified timestamp of the reference files and compare to its timestamp when shared and can let you know if a reference has changed to prompt you to re-include an update if you want to.

[olimorris]

> Sharing: ... is added to the next message, but in it does not actually adds any variables to the second message.

My logic for this is that once you add a reference (i.e. a buffer or a file) to the chat buffer, it becomes part of the payload which is sent with every request to your LLM. I chose the verb "sharing" because that's exactly what's happening with every message you send. If I'd have used > Added ... then I think that could be interpreted to mean the reference was added with that message.

There's a fine line to tread in the chat buffer between useful information and visual bloat. This was a feature I hadn't intended to add but acknowledged that for some users it was really useful.

I'm also planning a lot of features related to this e.g. sticky/updateable references on every request and the ability to modify references on the fly.

Closing this as it's not a bug but will transfer to a discussion.

[last-partizan]

No, this is the intended design as you can see in the code.

But, why does it needs to be displayed on every subsequent message?

In UI each -- Me -- block is supposed to represent a single user message to the LLM.
It makes sense that the message with #buffer will include this text about Sharing .... But I don't understand what's point of displaying it for next message?

To be crystal clear, it makes sense to display > Sharing .. when rendering this message:

{
    content = "Buffer ID: 1\nName: test.txt\nPath: /tmp/test.txt\nFiletype: text\nContent:\n```text\n1:  Version 1\n```\n",
    id = -454189760,
    opts = {
      reference = "/tmp/test.txt",
      tag = "variable",
      visible = false
    },
    role = "user"
  }

But for this, it's unexpected.

{
    content = "How about now?",
    id = 419434627,
    opts = {
      visible = true
    },
    role = "user"
  }

[last-partizan]

Oh, wait. I totally missed this.

You're still "sharing" that buffer in subsequent messages.

How does it work?

[olimorris]

Press gd in the chat buffer. You'll see the payload that gets sent to the LLM with every request. Your buffer is in that. Therefore it's shared with every response.

I toggle chat buffers quite regularly. Coming back to a chat buffer after sometime and seeing what context I've shared with the LLM is useful to me. The same with vim help docs. The same with URLs. It's useful to know the LLM is citing those resources in its responses.

To be blunt, I won't be changing this functionality or how references are displayed in the chat buffer.

[GitMurf]

But, why does it needs to be displayed on every subsequent message?

Because how else do you know what is in the conversation history? Without it you won't know / remember what is part of the context as the entire conversation is always the context. If I can't remember whether I already shared file1.txt and file2.txt I will not know the context AI has overall which is important.

[last-partizan]

Yeah, it's probably matter of preference.

I just like how Zed does it. It renders a file shared only for original message.

To be blunt, I won't be changing this functionality or how references are displayed in the chat buffer.

Would you accept PR adding an option to display references only for the original message?