-
Notifications
You must be signed in to change notification settings - Fork 213
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
Make it obvious in-editor when Cody has provided an autocomplete #667
Comments
See Figma for notes on logic, animation, and prototypes (select a frame and hit command-space to start). For the sidebar notification, it uses the same design as #653 — but this time I've fleshed out the motion details too (which would apply to both) Screen.Recording.2023-08-14.at.7.01.50.pm.movScreen.Recording.2023-08-14.at.6.57.56.pm.mov |
Nice! Love the ghost text in the editor and celebration text afterwards. @philipp-spiess could we launch this as a test? I'd love to see if this leads to a meaningful bump in autocomplete metrics |
@chenkc805 Sure, I don't see a reason why we can't :) |
Lets do it then! CC: @kelsey-brown for visibility |
Here's the experiment requirements:
|
I imagine the autocomplete acceptance rate is highly dependent on the quality of the answers themselves (you get very different results based on the type of file you open and what line you're editing etc) — we might need to control for that (if possible). |
I forgot to mention earlier, we can also provide a small bit of markdown content in the decoration's This would be a good opportunity to provide any longer words, and link to docs or the getting started guide’s "Autocomplete" section. This seems like an easy add if it's just a an extra decoration property to specify. @philipp-spiess should I quickly mockup up what that content would be? |
It should be fine - at scale with lots of different users who are randomly enrolled, the quality should average out to be the same across both groups
Can we scope this into a separate PR? Feels a bit like scope creep here and this PR already has a decent amount of changes in it. |
Thanks for all the input! Just to set expectations here but we have not scheduled eng time for this in the current sprint, so let's find out who is going to work on this and how to prioritize it against the other things in our next planning on Monday. We also need to validate if we can do some of the work here, it's not clear to me yet if we can trigger a code lense "view" during autocomplete events yet. Plus is it currently impossible to tell if our completion is visible or e.g. a copilot one is visible. We guard for this in our logs by only counting acceptance rate for users that do not have copilot or other extensions enabled. Should we do this here too and only show "👈 Cody autocomplete` if none of the other extensions are enabled? And, I suspect, we want to make sure to only ever show these once? But what if we show a completion only for a few MS?
I would suggest we pick a different name here and also prefix with cody. What about
We don't have logging for this on the client but I think we can probably do this with SQL foo? :D |
Yeah works for me!
We can do this in SQL :) |
We've talked about this a bit during our morning sync today with @beyang and he had an interesting point: If the goal is to show our users the value they're getting, it might be better to have a less intrusive way of doing this. He suggested a "stats" widget that we can use to show some nice statistics instead. I’m curious what you think about this @toolmantim? If we had that, would we still want to use the code lenses to show when a completions is inserted? |
@philipp-spiess sorry I didn't follow up on that comment! This is about onboarding, and it's only shown once. Once I mentioned that to @beyang he was on board. The stats widget is an interesting idea… but probably for another use case. For onboarding, there's also a chat pane view version of this, which I've extracted out of a previous PR in #1071. That's probably a much easier first step, and is close to done? But the in-editor experience as designed above is what a lot of people internally were asking for (and what a few of the other AI assistants implement). |
Fixed via #1071 |
@DanTup we’d love you to get the in-editor version of this working next! It’s designed above, but I’m expecting we may need to iterate/adjust as we start to get things working. |
@toolmantim has this already been started? (the video above looks like a working implementation but I'm unfamiliar with Figma so don't know if this is just mocked up.. it looks very real) |
@DanTup nothing started, the above is just a mockup! 😊 |
An implementation for #667. I initially implemented decorations both when the completion was visible and when accepted, as described in the issue above: https://github.com/sourcegraph/cody/assets/1078012/b027245a-9af3-4a33-b01b-aac9d5a0b0d8 However, there was some concerns about being able to reliably shown this _only when a Cody completion is visible_. Specifically, when VS Code asks us for completions, there is no guarantee they will be shown (because it may be asking multiple providers at once). We also can't tell if the user hits `escape` to hide the inline completion so the decoration could be hidden. So this change implements only the accepted decoration: https://github.com/sourcegraph/cody/assets/1078012/e456a00f-d6d9-4a9d-b7d6-abd62f2625a0 @toolmantim WDYT? ~~Still needs tests but I want to ensure the implementation is right before adding them.~~ Fixes #667 ## Test plan Tested with a new e2e test (`pnpm test:e2e`). --------- Co-authored-by: Tim Lucas <t@toolmantim.com>
Autocomplete is our # 1 onboarding task for now. But Cody’s autocomplete works behind the scenes, with no chance for a new user to understand what's really going on. Currently it's somewhat confusing, and a little anticlimatic.
We need to:
Related PRDs:
Related Slack messages:
References:
The text was updated successfully, but these errors were encountered: