You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched all issues to ensure it has not already been reported.
Summary
I would like to see basic refactoring features like renaming local variables and if possible renaming global variables and function names using Language Server Protocol and integrated with refactor features provided by vscode.
In short, this is very difficult because PowerShell is not a statically typed or scoped language. We hope to explore a limited scope of rename but it would need to be known it will be opt-in with shortcomings with a warning. See more detail on that issue.
I saw #261, at least renaming a local variable inside functions or inside the closest scope shouldn't be a problem, vscode API provides registerRenameProvider a little described here (this page also contains other info about renaming, search: "rename") and in deep described here and here.
Have you tried these APIs? They are supposed exactly for this purpose. You can use these APIs since this extension uses LSP.
Practically, you don't have to do anything, everything is done inside LSP, it looks like all you need to do is consume and implement these APIs and interfaces to provide rename functionality for this extension. What means you don't have to code the renaming feature from the ground up.
There is no rename functionality implemented in the LSP (PSES) as of yet. That's the primary first task that must occur before it can be wired up in the frontend extension. Issues for PSES are usually first tracked here as it's where most people first look, but the two are developed mostly in tandem (VSCode being the "primary" consumer of PSES, but there's other editors too (neovim, atom, etc.)
What means you don't have to code the renaming feature from the ground up.
It looks like that is the exact opposite of what I wrote. 😎🙃 You will have to code everything yourself. I have found PowerShell/PowerShellEditorServices#2152 and also #4950, it looks like one year of hard work, what is the state of this PR, will be merged soon or it's still in the early stages?
As I recall there are several edge cases this doesn't handle, so we were going to need to surface an opt-in to warn users about the potential perils of using this feature. Andy Jordan (@andyleejordan) can elaborate, but I recommend continued discussion happen on the PR or issue and not on this dupe.
Ok, I'm going to sleep because I'm in half suspend mode already, writing with one eye already closed, thx for replies, I will dream about renaming in pwsh 😅
Activity
JustinGrote commentedon May 30, 2024
Dupe of #261
In short, this is very difficult because PowerShell is not a statically typed or scoped language. We hope to explore a limited scope of rename but it would need to be known it will be opt-in with shortcomings with a warning. See more detail on that issue.
silverqx commentedon May 30, 2024
I saw #261, at least renaming a local variable inside functions or inside the closest scope shouldn't be a problem, vscode API provides
registerRenameProvidera little described here (this page also contains other info about renaming, search: "rename") and in deep described here and here.Have you tried these APIs? They are supposed exactly for this purpose. You can use these APIs since this extension uses LSP.
silverqx commentedon May 30, 2024
Practically, you don't have to do anything, everything is done inside LSP, it looks like all you need to do is consume and implement these APIs and interfaces to provide rename functionality for this extension. What means you don't have to code the renaming feature from the ground up.
JustinGrote commentedon May 30, 2024
"Practically, you don't have to do anything, everything is done inside LSP"
And who do you think writes the LSP? 😁
https://github.com/PowerShell/PowerShellEditorServices
There is no rename functionality implemented in the LSP (PSES) as of yet. That's the primary first task that must occur before it can be wired up in the frontend extension. Issues for PSES are usually first tracked here as it's where most people first look, but the two are developed mostly in tandem (VSCode being the "primary" consumer of PSES, but there's other editors too (neovim, atom, etc.)
silverqx commentedon May 31, 2024
It looks like that is the exact opposite of what I wrote. 😎🙃 You will have to code everything yourself. I have found PowerShell/PowerShellEditorServices#2152 and also #4950, it looks like one year of hard work, what is the state of this PR, will be merged soon or it's still in the early stages?
silverqx commentedon May 31, 2024
Code quality looks good with a lot of tests.
JustinGrote commentedon May 31, 2024
As I recall there are several edge cases this doesn't handle, so we were going to need to surface an opt-in to warn users about the potential perils of using this feature. Andy Jordan (@andyleejordan) can elaborate, but I recommend continued discussion happen on the PR or issue and not on this dupe.
silverqx commentedon May 31, 2024
Ok, I'm going to sleep because I'm in half suspend mode already, writing with one eye already closed, thx for replies, I will dream about renaming in pwsh 😅