-
Notifications
You must be signed in to change notification settings - Fork 238
Description
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.