-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support current mentions in @ mention menu for prompt templates #6793
feat: support current mentions in @ mention menu for prompt templates #6793
Conversation
@bahrmichael @vovakulikov a small observation regarding "Currently opened tabs" As I was working on providing a fix for expanding current-tab when settings is opened As such this "Currently opened tabs" title could be a bit misleading if someone opens a file from outside It is probably highly unlikely for someone todo this, notice, and complain but there are still users that I don't propose anything, just want to bring this up in case this revelation changes anything or we are ok |
Thank you for pointing that out! If I understand correctly, workspaces is a VSCode concept. Since that's not present in JetBrains products, I'm having trouble coming up with a good term that would reflect workspaces. And I would advise against adding custom code for this. |
export interface ContextItemCurrentSelection extends ContextItemCommon { | ||
type: 'current-selection' | ||
} | ||
|
||
export interface ContextItemCurrentFile extends ContextItemCommon { | ||
type: 'current-file' | ||
} | ||
|
||
export interface ContextItemCurrentRepository extends ContextItemCommon { | ||
type: 'current-repository' | ||
} | ||
|
||
export interface ContextItemCurrentDirectory extends ContextItemCommon { | ||
type: 'current-directory' | ||
} | ||
|
||
export interface ContextItemCurrentOpenTabs extends ContextItemCommon { | ||
type: 'current-open-tabs' | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally curious in which situations it's OK to do this vs creating an internal openctx provider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe @vovakulikov knows more, I'm not confident in this area of code :)
t += `${AT_MENTION_SERIALIZED_PREFIX}?data=${unicodeSafeBtoa( | ||
JSON.stringify(n, undefined, 0) | ||
)}${AT_MENTION_SERIALIZATION_END}` | ||
throw Error('Unhandled node type in atMentionsSerializer.serialize: ' + n.type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there ever a chance that this will be hit in production?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should only appear during development. If someone adds a new type, I want this to light up so they can update the according code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve as we want to hit the path release with it but I think @fkling touched a very good point here, what if we don't resolve these generic mentions as we click prompt and render prompt message (with hydrated generic mention values) but instead we always render this blank generic mentions chips and resolve them only on message submit?
Then we could handle all generic mentions via special internal OpenCtx for generic mentions. (I guess we would have to extend openctx API a littlie bit to support some corner cases when we don't have context for Cody Web, but it should be fine)
I think this would be better since we won't be hitting weird cody://<mention-type>
text in the editor where we don't have the environment context to hydrate these generic mentions (instead we will render something like a chip with a warning colour or throughline chip)
Anyway, @bahrmichael, can I ask you to write a prompt-mentions-doc.md
here where you explain how the full flow of generic and direct mentions work in the prompt library, cody web and cody vs code. I still remember what we did here but this memory will go away pretty fast and with this state of the art in cody it won't be easy to unwrap it
Also, let's pair tomorrow to check some core cases manually in Cody Web with the pulled main in this branch. Thanks for your contributions in prompts library!
@ichim-david, thanks for the catching workspace tabs thing; I agree with @bahrmichael, we, in theory, could have workspace capability settings and change the labels for this chip based on this setting. But I think it's not the blocker problem here and we can add it later when someone will reach out us about this (or when we finish prompts mentions and go to post-ga phase), appreciate your high agency 😉 |
If I understand this correctly, I wouldn't be able to use "current file" or "current selection" multiple times anymore. This is a use case that I heavily enjoy, when I can go through a couple files and tell cody "look at X, Y, and Z". |
Todos for me:
|
The backport to
To backport this PR manually, you can either: Via the sg toolUse the sg backport -r vscode-v1.64.x -p 6793 Via your terminalTo backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-vscode-v1.64.x vscode-v1.64.x
# Navigate to the new working tree
cd .worktrees/backport-vscode-v1.64.x
# Create a new branch
git switch --create backport-6793-to-vscode-v1.64.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 a59e31dddef0cb9017dbf70ad8a1512c97331995
# Push it to GitHub
git push --set-upstream origin backport-6793-to-vscode-v1.64.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-vscode-v1.64.x If you encouter conflict, first resolve the conflict and stage all files, then run the commands below: git cherry-pick --continue
# Push it to GitHub
git push --set-upstream origin backport-6793-to-vscode-v1.64.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-vscode-v1.64.x
Once the pull request has been created, please ensure the following:
|
…ates (#6793) This PR introduces support for current @ mentions in the prompt template editor. This PR has to be followed up by a PR in the sg repository to make this feature visible to users. See demo from my local instance below: https://github.com/user-attachments/assets/268b3d9c-58a7-4ddc-9f1e-0feb398487af The design changes have been reviewed here: https://sourcegraph.slack.com/archives/C07HRH4RJP8/p1737653234416939 New unit tests + manual testing (see video)
…ates (#6793) This PR introduces support for current @ mentions in the prompt template editor. This PR has to be followed up by a PR in the sg repository to make this feature visible to users. See demo from my local instance below: https://github.com/user-attachments/assets/268b3d9c-58a7-4ddc-9f1e-0feb398487af The design changes have been reviewed here: https://sourcegraph.slack.com/archives/C07HRH4RJP8/p1737653234416939 New unit tests + manual testing (see video)
@bahrmichael I think your changes have triggered a failure in my pull request https://github.com/sourcegraph/cody/actions/runs/13249643202/job/36984307007?pr=7037#step:8:1 as I have not worked with context items. |
This PR introduces support for current @ mentions in the prompt template editor. This PR has to be followed up by a PR in the sg repository to make this feature visible to users. See demo from my local instance below:
Screen.Recording.2025-01-24.at.10.33.58.mov
The design changes have been reviewed here: https://sourcegraph.slack.com/archives/C07HRH4RJP8/p1737653234416939
Test plan
New unit tests + manual testing (see video)