Double clicking variable selects variable AND $ prefix - this is not desirable

[rkeithhill]

System Details

System Details Output

### VSCode version: 1.56.2 054a9295330880ed74ceaedda236253b4f39a335 x64

### VSCode extensions:
abusaidm.html-snippets@0.2.1
atlassian.atlascode@2.8.6
DavidAnson.vscode-markdownlint@0.41.0
donjayamanne.githistory@0.6.16
DotJoshJohnson.xml@2.5.1
eamodio.gitlens@11.4.1
EditorConfig.EditorConfig@0.16.4
eg2.tslint@1.0.47
everettjf.filter-line@2.0.1
formulahendry.dotnet-test-explorer@0.7.5
gep13.chocolatey-vscode@0.7.2
Mikael.Angular-BeastCode@10.0.3
ms-azuretools.vscode-docker@1.13.0
ms-dotnettools.csharp@1.23.12
ms-edgedevtools.vscode-edge-devtools@1.1.9
ms-python.python@2021.5.842923320
ms-python.vscode-pylance@2021.5.4
ms-toolsai.jupyter@2021.6.832593372
ms-vscode-remote.remote-containers@0.177.2
ms-vscode-remote.remote-ssh@0.65.4
ms-vscode-remote.remote-ssh-edit@0.65.6
ms-vscode-remote.remote-ssh-explorer@0.56.0
ms-vscode-remote.remote-wsl@0.56.3
ms-vscode-remote.vscode-remote-extensionpack@0.21.0
ms-vscode.cpptools@1.4.0
ms-vscode.powershell-preview@2021.5.0
ms-vscode.vscode-typescript-tslint-plugin@1.3.3
msjsdiag.debugger-for-chrome@4.12.12
msjsdiag.debugger-for-edge@1.0.15
NicolasVuillamy.vscode-groovy-lint@1.4.0
redhat.vscode-commons@0.0.6
redhat.vscode-yaml@0.19.2
robinbentley.sass-indented@1.5.1
sibiraj-s.vscode-scss-formatter@2.2.0
SimonSiefke.svg-preview@2.8.3
slevesque.vscode-zipexplorer@0.3.1
spmeesseman.vscode-taskexplorer@2.0.7
streetsidesoftware.code-spell-checker@1.10.2
twxs.cmake@0.0.17
wayou.vscode-todo-highlight@1.0.4
yzhang.markdown-all-in-one@3.4.0


### PSES version:

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19043
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

I had to run this from pwsh. PSIC just hangs when I try to run this command. But PSES is:

=====> PowerShell Preview Integrated Console v2021.5.0 <=====

Issue Description

Double-clicking a variable has changed to now selecting the $ prefix. This is a problem when pasting over the variable when used in splatting e.g. @iwrArgs becomes @$iwrArgs. Ditto with string interpolation "${smtpServer}" becomes "${$smtpServer}" after pasting. This is highly undesirable IMO.

Expected Behaviour

Double-click select of a variable should not include the $ in the selection.

Actual Behaviour

Double-click select of a variable does include the $ in the selection.

[andyleejordan]

Is this sufficient for you? Since it's only a supplied default, the behavior is easily overridden.

"[powershell]": {
    "editor.wordSeparators": "`~!@#$%^&*()-=+[{]}\\|;:'\",.<>/?"
}

This was a small change I made based on feedback gathered during a VS Code PowerShell extension meetup. See #3359 It seemed like most users would prefer the ISE-like behavior were - and $ are not word separators.

What if we put $ back but kept - removed? Then we'd still get PowerShell symbols like Foo-Bar treated as a word, but with $Foo-Bar being two words.

[rkeithhill]

I've got no problem leaving - out as that is not supported in a variable name unless you're willing to use {} e.g. ${foo-bar} = 42. IF I weren't going to use camel/Pascal-casing, I'd use _ instead e.g. $foo_bar = 42. But not having $ in there is messing me up on a daily basis. I wonder if the wordSeparators could be different depending on whether you have a modifier key pressed?

[andyleejordan]

Just playing around with this, the included change makes the VS Code experience consistent with PowerShell itself. That is, if you put the cursor on $Foo-Bar the PowerShell extension (correctly) highlights the whole thing, and double-clicking it with this change then selects the whole thing. Without the included change, double clicking Bar is really confusing, as it gets selected, and slightly more highlighted, will the reset of $Foo-Bar remains highlighted. It's very confusing how it was. I'm going to keep the new default in the extension for the stable release today so we can collect more feedback, but I think in general most people will be happy with this, and the embedded changelog includes exactly how to revert the change.

[poshcodebear]

I'm definitely not one of those happy with this change.

It messes with Ctrl+Backspace, so erasing and retyping a variable name means also having to retype the $, and erasing a parameter also erases the trailing -.

It messes with quick refactoring, so Ctrl+F2 to change the name of a variable means, again, retyping the $, even though it makes no sense that I'd want to change that part since all variables must be decorated with a $ (not to mention, it means splats won't be updated in a quick Ctrl+F2 refactor, which can actually introduce bugs/break scripts)

Not to mention, it makes refactoring multiple functions in the same module to change the noun or prefix a bigger pain, because now I either have to do it for every verb variant or write a regex find/replace for it.

In any event, these are behaviors that I've come to expect from the editor in the several years I've been using Code to write my PowerShell, and this change has already caused a significant amount of aggravation in just the very short time since it's been implemented, to the point I had to dig in to the settings to figure out why it wasn't working as expected, and even went to the hassle of searching the commit history for this repo just to verify I wasn't going mad and this had actually changed.

This is a breaking change to existing user workflows. I don't see the old behavior as confusing in the slightest, and personally feel that existing users who have already come to expect certain behavior should take precedence over new users who can learn the existing behavior more easily than we can re-learn it. Four plus years of muscle memory don't fade overnight.

Anyway, I know there's a workaround and will be using it, but I really think this was a poorly thought out decision.

[andyleejordan]

Per the changelog (which should show up automatically when the extension updates) you can revert with:

"[powershell]": {
    "editor.wordSeparators": "`~!@#$%^&*()-=+[{]}\\|;:'\",.<>/?"
}

[rkeithhill]

and personally feel that existing users who have already come to expect certain behavior should take precedence over new users who can learn the existing behavior more easily than we can re-learn it. Four plus years of muscle memory don't fade overnight.

💯 Amen brother!

[dragonwolf83]

I don't think its that simple. I've hated it for years that you can't double click to select the whole variable with the $ when trying to just copy and paste it. That triggers more work to add it back in or go select it again without double-clicking so that it captures it. Either way, the user gets a bad experience.

If triple-clicking would have selected the whole word instead of the line, it would be a good compromise. I don't know if that is possible in VS Code.

So what scenario should be optimized here? Refactoring, Copying, transforming to splatting or string interpolation? Is there a way to paste with special options like Office does to auto-refactor it? That would be a cool feature.

[poshcodebear]

The way I see it, with copying, you have three options:

• Double-click and move your mouse over until it selects everything you want (it will automatically select whole words if you start with a double-click, so it's pretty easy to just do that, and since doing that makes selecting multiple words faster and easier in general, it's quick to get used to doing this)
• Use the autocomplete/Intellisense system and type the first few characters if you're just entering it in one or two places
• Modify the word separation characters for your own system if the default really bugs you that much; it's been user configurable in VSCode since, I believe, at least 2016

Since PowerShell, as far as I can see (at least of the languages installed on my system), is the only language provider that now modifies the default list of word separation characters, that means even other languages that use the $ variable decorator don't mess with word separator list.

And I will say, for me personally, the minor issues caused by the default word separator list from VSCode are easily overcome with small adjustments to expectations to match, while the issues caused by the modified list means the built in refactoring tools become noticeably less useful, forcing manually using find/replace in a lot of scenarios that a simple Ctrl+F2 should have been able to handle.

And, again, this is a breaking change to existing user workflows to, as far as I can tell, reduce the learning curve, though it seems to me that it doesn't do much on that end, especially compared to the price of making experienced users' tools less functional.

As for the changelog showing up automatically...I haven't seen one in a long while myself, didn't even realize it had updated until I tracked this issue down to it, and just to verify, I launched it on a system I've not coded on for the last few weeks and all I got was a pop-up notification that went away after ten seconds, something that I'm likely not to notice or even bother looking at when I'm in the middle of getting something done. You can say that's my own fault, but I don't think it's an unreasonable expectation that existing workflows won't break because of a change in default behavior as opposed to adding support for changing our own workflows.

Since this update also marks the third time I've had to chase down why variable properties are no longer colored differently than the variables themselves because the name they've been given for TextMate rules has changed, again, I'm genuinely confused by the direction the team running this project have chosen. I don't know about you, but having my tools break in updates costing me an hour or two hunting down what changed and how to fix it isn't exactly a stable, production ready experience. This attitude of "move fast and break things" doesn't belong in professional tooling.

Anyway, I've said my piece, I've fixed my tools and can go about getting my work done and can put this behind me (at least until the team running this project decides to break things again), so I'll be off. Please consider changes like this more carefully in the future. And please consider reversing this one as I'm obviously not the only existing user frustrated by this change, especially since anyone who likes this new behavior could have easily set up their own install to do it had they wanted to at any point in the last five years.

[rkeithhill]

The gift that keeps on giving:

🤦‍♂️

[ThubLives]

I'm kind of puzzled about the trend to keep changing defaults to more closely mimic the ISE when there is a palette command "PowerShell: Enable ISE Mode" that was added specifically to make it easy to change a number of settings to values that more closely mimic the ISE. "PowerShell: Disable ISE Mode" returns those values to the extension defaults, but if those defaults are already ISE-like and foreign to non-PowerShell VSCode users, what is the point?

The main reason I started using VSCode was because I was sick of having different editors for different languages that behaved in unique and cognitively conflicting ways. With VSCode I didn't have to mentally switch back and forth between the text selection behaviours of two DE's and it still did sensible language-specific things like code highlighting and IntelliSense. Common debug shortcut keys and predictable keyboard-based navigation was a huge reason for that.

Obviously, having the option to change this particular setting back is welcome in this case, as other changes ISE-ward have not provided configuration options to restore the old behaviour(#2523). In general I question the wisdom of this overall approach. I completely understand that people either like the way ISE works but want the more advanced features of VSCode, or simply want an easier transition to a more modern tool. I think a separate extension for a PowerShell ISE Mode sounds very sensible and something similar has been done for plenty of other languages. But again, the "Enable ISE Mode" command already exists, supposedly for this very purpose.

More relevant to the discussion at hand -- take this code, a scenario I run into quite often:

$BaseName = 'CSL'
$Seperator = '-'
$Date = Get-Date -Format 'yyyyMMdd'
$Extension = '.dx1'

$NewReportFileName = "$BaseName$Seperator$Date$Extension"

The new default value makes selecting a portion of that string unwieldy. As a bonus, if I want to correct the spelling of that $Seperator variable name this won't work either, as mentioned in an earlier comment. Previously I could just click somewhere in the middle of the name on the second line (notice that it visually highlights the variable as expected), then press + to highlight all instances of that variable name. With the current default value, the string on the last line is not updated with the rest.

Furthermore, the exact same problems occur if the last line uses a literal '-' character:

$NewReportFileName = "$BaseName-$Date$Extension"

tl;dr:
I think the extension defaults should reflect sensible, familiar values for general VSCode users. If you want it to act like the ISE, that's literally what ISE Mode is for.