-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Support preview a WorkspaceEdit #77728
Comments
I have merged #88428 which implements a first version of this: 👇 What's implemented
What's still missing and/or unclear
|
/cc @bobbrow Wrt to knowing if a preview for rename is needed or not: Does C/CPP know this during the |
Very cool. @Colengms should be able to help you answer your question. I don't see an implementation of |
Hi @jrieken . Do you mean Currently, we are using only In our current implementation, if all of the matches found are known to be associated with the selected symbol, we return results from Are you suggesting we leverage preview instead of our own UI, and make preview required in the scenarios in which we would otherwise have presented our own UI? If so, yes, we would need a way to return that preview is required, but wouldn't that be when returning from |
Yes - the plan is to have one UX that works across different language extensions and across different code actions like rename but also for things like "extract function" etc. For this and to provide a honest rename input box we need to know upfront if a rename needs a preview or not. That's why I am bringing up |
@jdneo will try this on Java projects and provide some feedback. |
Yeah, that the design. The list will show each change as computed by the language service. Tbh, I wouldn't make the language service make the change be optimised for the list view as we expect most users to open the diff editor in such cases
Good find. I will push a fix for that. Thanks |
api ideas interface WorkspaceEditMetadata {
label: string
icon: ThemeIcon | {light: Uri, dark: Uri};
check: boolean;
}
export class WorkspaceEdit {
appendTextEdit(uri: Uri, edit: TextEdit, metadata?: WorkspaceEditMetadata):void;
}
|
For the next stable release:
|
Hi @jrieken, Could you explain more about this? How will these APIs affect the preview? |
I'm specifically interested in the role of the |
Sure, these were merely meeting notes and not really fleshed out yet... We are working on supporting scenarios in which an extension can "classify" changes which won't be applied by default. Cpp already does that (with some custom UX) - the screen capture below shows how there are two candidate changes: one inside a string, one inside an inactive ifdef. The language service can suggest them but has low confidence and therefore human approval is needed. The api sketch above is to support this scenario, e.g Also, when a change is unchecked then that would be a signal for us to force show the preview. Otherwise we are likely making this depended on a user setting, e.g I have added |
@bobbrow fyi - the setting to enable/disable preview is now called |
Thanks @jrieken! For the setting, I read this description in your commit: If it's disabled, does that mean you won't show the preview even if the language server requests it? I'm thinking about what happens after we migrate to use this new feature and remove our language setting and our custom implementation. If the developer disables the preview on their own, will you ever show it? My guess is that vscode could still override the setting if the language server sends a metadata object with |
Yeah, that's that plan. The setting is your preferred behaviour but if via API uncertainty is expressed (internally I have now called the property |
@Colengms @jdneo We are planning to finalise the vscode/src/vs/vscode.proposed.d.ts Lines 1414 to 1452 in 760cb13
For some tyre-kicking you can use my sample extension that has served us during testing: #89335 (comment) |
Hi @jrieken . I tried it out again with our rename provider. I still have the following feedback:
|
Understood - I went with the usage of
👍 That was an oversight -> #90664
We discussed that in UX call and was some push-back on having too many check boxes but I do agree with the use-case. That's also something we can easily tweak after the fact. Overall, for the API proposal I see a thumbs up, right? |
Suggestion to rename |
@jrieken . Uri's don't seem to be working for me either. The file referred to in the following image is present on disk: When this happens, I see the following in the console log output (not sure if related) : I see this error recur as I scroll through the refactor preview list. Otherwise, the API is looking good to me. |
Understood - I missed the single-icon case, had only the |
To verify:
|
For many refactoring actions (e.g. Move Java file, Rename Java class/package name), it possibly involves updating multiple files, which is especially true for refactoring some big projects. If the VS Code supports preview the changes of a refactoring WorkspaceEdit before applying, this will help the user discover the potential refactor effects in advance and decide whether to continue the operation.
Generally a WorkspaceEdit contains text edits (Insert, Delete) and resource edits (CreateFile, DeleteFile, RenameFile), they are naturally diffs, and very suitable for preview.
The text was updated successfully, but these errors were encountered: