microsoft
Chat context: same file can appear twice
When I explicitly add a file as context, I would not expect it to appear twice based on the active editor:
//cc @isidorn
cc @hawkticehurst - as we discussed the eye-of-Sauron Current file UX.
Lol yeah, my recommendation is that we explore removing eye-of-Sauron UX/UI and instead just render the current file like any other attached file context.
Potential UX flow:
- When a new chat/edit is started, automatically attach the current file as context
- Folks can remove it if desired, this decision will persist for the duration of the chat
- This will also persist if a new file is opened during a given chat. If they want that file added they must do so manually
- The rationale is that I expect it will be far more annoying if after deciding to remove current file context it gets re-added every time a new file is opened
- If they want to add the current file back at any point they can do so manually
- I expect this won't be a huge issue since people are already used to adding other files as context manually
- Rinse and repeat for new chats
Open questions:
- When a new chat is opened and the current file is automatically attached, should we render the "Current file" label text or none at all (just the file name)?
- Why keep? Adds helpful context as to why this file was added
- Why remove? Declutters what can become a very visual and information dense area of UI
Also as a reference:
Cursor automatically attaches the current file and renders it as a regular file attachment with no label text.
Windsurf doesn't seem to attach the current file as context at all. When prompted "What does this file do?" it was able to automatically detect the current open file and answer the question.
I like the simplicity of Option 2. I also like the interaction model you propose. Would have to try it out to know for sure how well it works.
Rob and Ben might differ from my perspective. Let's wait to hear their thoughts.
One thing that drove the current implicit context design was seeing that users like to keep long-running chats, rather than clearing them each time they start a new topic. I constantly hit ctrl+L to clear the chat and many things would be easier if everyone did that! 😅
I hope that the real way out of this is an "agentic flow" in more scenarios- ie the LLM has more power to pull in the context tha tis important.
I hope that the real way out of this is an "agentic flow" in more scenarios- ie the LLM has more power to pull in the context that is important.
👆👆 Agree
One thing that drove the current implicit context design was seeing that users like to keep long-running chats, rather than clearing them each time they start a new topic. I constantly hit ctrl+L to clear the chat and many things would be easier if everyone did that! 😅
This is a great call out. A few initial thoughts / potential solutions:
Add a # command for "current file"
It's not a complete solution, but could represent a happy medium of making it just a tiny bit easier to add the current file back as context vs needing to identify what the current file is and then add it.
The command could also automatically detect when the current file changes (versus needing to manually update the current file each time you change files, once you've removed the initially attached current file at the beginning of a chat).
Detect when someone has started a new "coding session"
Q: Are there ways methods, APIs, heuristics we have for detecting when someone has walked away from VS Code and then come back (a la the computer went to sleep and is now back on)?
We could implement logic that will auto-add current file context to the same chat if we detect a distinct new "coding session" has begun.
That or we could just implement a sort of naive timer (i.e. every 12 hours auto-add the current file as context). I personally don't like this one cause it's non-intuitive and would almost certainly be viewed as a bug for folks who don't know about this type of logic.
Another variant of these ideas is to render a prompt after an interval of time or after a new "session" is detected that explicitly asks if the user wants the current file to be added back as context.
This feels a tiny bit better, but again has downsides in terms of getting very annoying if we get the timing wrong (i.e. 12 hours could represent someone starting a new working session OR it could be the 12th hour of a deeply gnarly debug session and we probably don't want to be rendering "wanna add the current file back as context" prompts 😅).
For me personally I would love the option (I think 2) where the current active editor just shows up like any other context, without extra decorations. It would still change and replace based on changing the editor, but it doesn't really matter for me as a user to know how it got there, as long as its implicitly added and updated.
If we end up with a UI that is just simple, I think thats best. Maybe on hover we could explain how the file was added there and it still needs an action to "pin" it I guess.
I don't think a timer would really capture it, but there was some data science work some time ago to try to understand whether the LLM can segment conversations and detect when a new topic has started. From what I remember, it was kind of inconclusive and seemed like it couldn't do a great job.
And I'm not trying to reject all the ideas, just adding historical context 😄
I don't think a timer would really capture it
Yeah that's my gut sense too. Really would prefer to avoid that kind of mechanism.
it was kind of inconclusive and seemed like it couldn't do a great job.
That's good to know. If anything maybe the proper/root solution is to go back and really look at the UI/UX for starting to new chats cause it's definitely a kind of hidden-away feature atm.
But at the minimum, I can still keep pondering on the long-running chat issue and see if some more robust ideas come to mind.
And I'm not trying to reject all the ideas, just adding historical context 😄
Oh you're totally fine! In fact, keep it coming! This brainstorming / spit balling phase is absolutely the time to gather historical context, toss out a bunch of ideas, scrutinize them, and think about all the edge cases. Rather talk through all the potential thorns now versus half way through implementation 😅
Following up: Do we think this (specifically eye-of-Sauron UX) is worth bringing to UX Sync?
Checking back in on this issue, how are we feeling 1.5 months later? I'm leaning towards following what Cursor does:
- Attach current file with no label text by default
- When you change files the current file context will be updated
- If current file context is manually removed it will remain removed for the rest of the chat session (i.e. when switching between files)
- When a new chat is started rinse and repeat
It takes up the least amount of space and I'd argue this specific behavior is not important enough (relative to other behaviors in chat) to warrant we do something novel/different.
It's slight different in Cursor, they only attach the current file on the first message of a session. If I send one message, then open a new file, it's not added to the chat. This is fine with me. One way or another, implicit context needs to go.
Other options- Windsurf and Cline don't show the current file by default at all, but it knows about your UI state, the names of your open files, and it will use a tool to read the current file if it seems relevant.
Zed shows the current file with a dotted widget that you can click to include (chat.ts here)
We have similar UI already for "suggested files" (off by default)
I'd like to explore something where we include some UI state context by default, I think it's really helpful in an agent mode.
Something that I feel is missing for us is that if I open "Add Context", I see a nice overview of context types, and it's obvious that I can add files, and my open files are easily visible. But if I type #, I see this
which feels like a lot with all the tools, and it's not immediately obvious that I can add files like this. I'd like to see my open files when going that route.
I really do like the idea of showing the current file dotted! Makes it an overall much calmer UI and still preserves our behaviour ✅
Yes. I am impressed by Zed, as posted here https://vscodeteam.slack.com/archives/C1C2M1KEZ/p1746794234264019
+1 for dotted line. So it is opt-in to include it.
It's slightly different in Cursor, they only attach the current file on the first message of a session. If I send one message, then open a new file, it's not added to the chat. This is fine with me. One way or another, implicit context needs to go.
Ooh I missed that thank you for calling it out. Also to clarify you're fine with automatically attached current file context not being auto attached after the first message is sent?
Other options - Windsurf and Cline don't show the current file by default at all, but it knows about your UI state, the names of your open files, and it will use a tool to read the current file if it seems relevant.
Oooh honestly I would be a big fan of this. Letting the AI choose if the current file is appropriate to use feels like the a great default. The current file would just become regular context like anything else –– it's a simplification of the UX / mental model that I really like.
Zed shows the current file with a dotted widget that you can click to include (chat.ts here). We have similar UI already for "suggested files" (off by default)
I really do like the idea of showing the current file dotted!
+1 for dotted line. So it is opt-in to include it.
I also potentially like the dotted line treatment too, however, is the idea that the the current file would just become suggested context that you would need to manually accept as context or would it be auto attached and just have a dotted line treatment?
If it's the latter (auto-attached with dotted line), I would be against this because then the same visual treatment would have two different behaviors depending on the file/context.
Something that I feel is missing for us is that if I open "Add Context", I see a nice overview of context types, and it's obvious that I can add files, and my open files are easily visible. But if I type #, I see this...
Big +1, @kkbrooks and I were talking about this like 2-3 weeks ago. At this point, my $0.02 would be to copy exactly what the add context quick pick does today (i.e. a high level menu organized by categories/types of context with sub menus). Is something like that possible with the current inline menu that shows up when you press #?
Actually created a new issue for the updated inline context menu that @roblourens said he wants to explore, so we can keep this issue focused on the current file context question.
Also to clarify you're fine with automatically attached current file context not being auto attached after the first message is sent?
Yeah, I'd be fine with that.
I also potentially like the dotted line treatment too, however, is the idea that the the current file would just become suggested context that you would need to manually accept as context or would it be auto attached and just have a dotted line treatment?
The first one, it's shown as a suggestion
Is something like that possible with the current inline menu that shows up when you press #
We probably don't have the ability to make a drill-down experience in the suggest widget really nice. I think I'd like to just sort a couple recent files to the top and we could probably do that.
@justschen thanks! Should we assign to current milestone so Ben and me verify? Or we plan to have a test plan item for all the changes here?
@isidorn @bpasero i made a TPI for this that covers the general new implicit flow, feel free to assign yourself or Ben to take it on if needed!