Vscode-powershell: "Smart" variable rename

[adbertram]

When I rename a variable in one place, I want to ensure all references to that variable are renamed that are in the same scope. Basically, I want to ensure when a rename a variable that anything that might be depending on that name is renamed as well in the same script. Here's an example:

http://www.screencast.com/t/ggUIoKqSC

[Bill-Stewart]

I think you can do this already by 1) selecting the variable, 2) use the command editor.action.selectHighlights (default key mapping is Ctrl+Shift+L), then 3) type the replacement name.

[sgtoj]

@Bill-Stewart You're somewhat correct. @adbertram is referring to the Rename Symbol (F2) command. It will smartly update the symbol (e.g. variable, class, functions, etc.) versus a blind change of all occurrence of a word.

Example:

# get some objects to work with
$something    = (Get-Something);
$anotherthing = (Get-AnotherThing);

# set some value from the first object
$someValue1  = $something.SomeValue;
$someValue2  = $something.SomeValue;

# set another one from the other object
$somevalue3  = $anotherthing.SomeValue;

Basic Explanations:
With Symbol Rename, the editor will understand that both occurrence SomeValue from $something.SomeValue are the same but the one from $anotherthing.SomeValue is not. So the Symbol Rename command of SomeValue property on the $something object will only make two changes even though there are at least 3 occurrence of "somevalue" (actually there are 6).

[Bill-Stewart]

Well, I interpreted the OP's request as variables rather than object members. I wouldn't mind this if performance is good. (As noted, we can already change variables pretty easily.)

[mattmcnabb]

Plus one on the request from @adbertram. The key here is that the token rename should be scope-aware in PowerShell. We've been doing this in ISESteroids for a while:

[rkeithhill]

Because of PowerShell's dynamic scoping that is hard to get right i.e. infer scripter intent. In the example above, I'd argue that renaming $Var1 on line 2 shouldn't rename the variable on line 5. Line 2 should be considered a "new" $Var1 variable because of PowerShell's "copy on write" behavior.

Now if line 2 was $script:Var1 = ... then it would be obvious that line 5 should be renamed.

However, with dynamic scopes you don't know until runtime which scope a variable is defined in if it isn't defined in the local scope. That makes it hard to ensure correctness with this feature request IMO.

[mattmcnabb]

@rkeithhill you're right about the intention of the example above. Sounds like it's difficult to implement - still would be really nice to have. Wonder how it's achieved in ISE Steroids?

[adbertram]

PowerShell Studio does it as well and I used it religiously.

On Tue, Dec 6, 2016 at 6:22 AM, Matt McNabb [e-mail]
wrote:

@rkeithhill https://github.com/rkeithhill you're right about the
intention of the example above. Sounds like it's difficult to implement -
still would be really nice to have. Wonder how it's achieved in ISE
Steroids?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/261#issuecomment-265137172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEG3-kvlvLvsAcgdC_PWAXft0mynxmnmks5rFVOXgaJpZM4JtI2E
.

[daviwil]

The question isn't whether it's possible (it is), it's whether the change we make is correct in terms of how PowerShell's variable scoping works. Right now our symbol renaming is primitive but once we start doing it the "right" way, it will adhere as well as it can to PowerShell's scoping rules.

[adbertram]

Great! Can we get that next week? ;)

On Tue, Dec 6, 2016 at 8:54 AM, David Wilson [e-mail]
wrote:

The question isn't whether it's possible (it is), it's whether the change
we make is correct in terms of how PowerShell's variable scoping works.
Right now our symbol renaming is primitive but once we start doing it the
"right" way, it will adhere as well as it can to PowerShell's scoping rules.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/261#issuecomment-265169692,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEG3-nH5Z8DLHCGTTs5RFqVOrV2DkBxZks5rFXcWgaJpZM4JtI2E
.

[daviwil]

Nope ;) You will get a new release with some other shiny features, though.

[Clijsters]

Would be a great feature!

[ajansveld]

Already a fan of vscode but this would really take it to the next level.

[johntiger1]

Also would like this feature

[smk89]

I'm a bit surprised that it's not in already. The hard bit should be correctly finding all of the references to a variable, which we can already do by hitting Shift+F12. What's left is a way to replace the highlighted strings with a new string.

[Stephanevg]

I am also verry interested in this feature. is there any idea when this will be added?( I don't want to be a negative Nancy, but this issue has been open for two years now.)

[EnderSyth]

I'd like to chime in on this as well. VSCode is great for many languages but for powershell it's lacking some feature you get used to in other languages or even other editors (the ISE integrated terminal with intelisense). I hope this get's added as it would improve the workflow for myself and many others.

[TylerLeonhardt]

(the ISE integrated terminal with intelisense)

@gyro2death have you tried the PowerShell Preview extension with PSReadLine support in the integrated console?

[rjmholt]

I wrote up a quick note in a reddit post a while ago.

PowerShell's dynamic (i.e. determined at runtime) scope makes this impossible to do in general. Take this example:

$x = 1

function Write-X
{
    $x
}

function Write-XInScope
{
    $x = 7
    Write-X
}

Write-X
Write-XInScope

If you rename the $x in Write-X, which $xs do you rename?

Even if you only rename the single $x occurrence in Write-X, you've still broken Write-XInScope.

I think this issue has been blocked by the hope that it might be possible to do something clever here, but it's not; this is runtime-only information, so the only way to always know the scope of a variable is to execute the script.

My thinking is that we should instead take a conservative approach:

• Renaming a normal variable only changes the name of it in its immediate scope
• Renaming a script: variable is lexical, so we can safely rename all occurrences there
• Renaming a global: or env: is slightly more work, but just requires renaming the variable everywhere in a workspace.

This policy may still cause unexpected effects, but it's simpler than almost all other ways of doing things (the other simple one being to rename all occurrences in a script file -- but that file could still be called within another scope).

I have the feeling that many people write PowerShell scripts as though PowerShell has lexical scope, but unfortunately that's not the case. We'll do our best to balance expectations with not breaking PowerShell, but this is one of those edge areas.

[AndersRask]

I wrote up a quick note in a reddit post a while ago.

PowerShell's dynamic (i.e. determined at runtime) scope makes this impossible to do in general. Take this example:

$x = 1

function Write-X
{
    $x
}

function Write-XInScope
{
    $x = 7
    Write-X
}

Write-X
Write-XInScope

But then again, calling a variable inside a function that was defined outside is pretty nasty!
Having read a ton of other peoples PowerShell, I agree though, that we cannot expect lexical scope to be used always, however I think people who would do this, are not even aware of the implications or problems with the code ;-)

I would be fine with that the refactoring only worked inside the advanced function you were currently working, as this would probably be the case in most instances anway