Filter and/or organize variables displayed during debugging

[rkeithhill]

Right now the variables displayed in Global, Script and stack frame local scope are simply every single variable returned by:

Get-Variable -Scope <Global | Script | <stack frame #>>

While this returns variables the user has defined, it also returns many, many built-in variables including predefined constants like $null, $true and $false in addition to SessionStateCapacityVariables like MaximumAliasCount, MaximumDriveCount, etc even in local scope e.g.:

Name                
----                
?                   
args                
ConsoleFileName     
ExecutionContext    
false               
HOME                
Host                
i <== assigned in the function              
input               
itemCount <== assigned in the function       
MaximumAliasCount   
MaximumDriveCount   
MaximumErrorCount   
MaximumFunctionCount
MaximumVariableCount
MyInvocation        
null                
PID                 
PSBoundParameters   
PSCommandPath       
PSCulture           
PSDebugContext      
PSHOME              
PSScriptRoot        
PSUICulture         
PSVersionTable      
ShellId             
true                

So here you have two variables that are very likely to be the most interesting to you in the Local scope but you have to pick through 28 variables. That is not a great user experience.

I want to determine a way to organize this information (set of variables) into a more usable structure. VSCode offers up a tree view to display nodes - whether those are containers like Global, Script, Local or variables where variables can be a primitive variable such as a bool, or a composite variable such as a Process object.

One approach I'm leaning towards is adding a top level folder called Auto that acts like the C#/VS auto debug variables window. This would attempt to show just the two variables that you have assigned locally.

Another approach is to just filter the Local list of variables. This can be done partly by inspecting the type returned by the call to Get-Variable e.g.:

It would be pretty simple to filter out the NullVariable ($null).

Variables also have an Options property with values like ReadOnly, Constant, AllScope.

SessionStateCapacityVariable typed variables are rarely of interest but I wouldn't say never of interest. These are typically set by a profile (if modified at all). One way to handle these is only show them in a scope other than Global when they have a different value than their Global counterpart. Another way is to create a tree node under Local called something like System and "hide" these less interesting variables there.

All of these approaches require that we somehow know how to distinguish between PowerShell-defined and user-defined variables. I can filter somewhat based on type as shown above. Still, there are a lot of PSVariable typed variables that are PowerShell-defined. I hate the idea of maintaining a static list of built-in variable names. Does that list exist somewhere in S.M.A.dll?

I guess we could check if the variable name appears in the Global scope and only display it again if the value is different. However comparing values is tricky because not all objects support equality comparison ($Host comes to mind). Value comparison will also come into play for another proposal - indicating dirty variables (variables whose values have changed since the last debug stop).

Sorry for the stream of consciousness post here but I wanted to get some of these ideas down.

[rkeithhill]

OK, spent some time on this today and this is what I have implemented:

Note: I added the red underline in MSPaint before posting this, it's not really there in VSCode. :-)

I'm open to changing the name of the node Automatic Variables: but I don't have control over the :. VSCode seems to add that. I'm also tempted to go with a "top level" Auto or My node that contains the filtered list of useful variables.

What you will notice is that the Global scope does not have an Automatic Variables node. That is because the primary way I'm determining what is an automatic variable is to check any AllScope | Constant or AllScope | ReadOnly variable to see if it exists in the Global scope and if so, it goes into Automatic Variables. This approach doesn't work when the scope being processed is the Global scope.

There is another possibility for distinguishing between user-created and PowerShell-created variables but it requires reflection against the internal System.Management.Automation.SpecialVariabes static class. What do you think? OK to use reflection? The downside is that we get broken by a change to this type in a future version of PowerShell.

[rkeithhill]

I don't like that the previous attempt's "Automatic Variables" node appears like a variable itself instead of just a container. So here's it what it would look like to have an "Auto" at the top level:

The Auto node's contents change based on which stack frame is selected in the call stack.

Right now, the other scopes do no filtering and display everything returned by Get-Variable -Scope .... So with Local opened it looks like this:

What do you think? Any preference over this version versus the previous "Automatic Variables:" version?

[daviwil]

I like the new approach better too. It's cleaner when the automatic variables show up as their own section rather than appearing like a variable. Changing it based on selected stack frame sounds right to me.

[rkeithhill]

OK, that's the approach I'll go with. Should have a PR for you by tomorrow - I hope.

[daviwil]

Great, looking forward to it!

[daviwil]

Should we go ahead and close this issue?

[rkeithhill]

Yes.