Skip to content

Filter and/or organize variables displayed during debugging #56

@rkeithhill

Description

@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.:
variabletypes
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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions