Thread overview
Could Visual D remember expansion of debug watch variables?
October 24
Sometimes I have a deep nesting of a variable that I have to expand many times to find some member to check the variable.

Each time I debug I have to spend about 30 seconds digging in to the variable in the watch window.

Could Visual D remember the previous run's expansion of variables and attempt to auto expand them when the next debug occurs? It would need to scroll to whatever variable was being viewed last too, and not just percent window in case new variables were added.

The idea is to sort of make it so that the watch window sorta of changes as little as possible between runs so no time has to be wasted each time. It's not so bad most of the time but in some cases it really adds to the time to debug.



October 26

On 24/10/2018 20:47, Michelle Long wrote:
> Sometimes I have a deep nesting of a variable that I have to expand many times to find some member to check the variable.
> 
> Each time I debug I have to spend about 30 seconds digging in to the variable in the watch window.
> 
> Could Visual D remember the previous run's expansion of variables and attempt to auto expand them when the next debug occurs? It would need to scroll to whatever variable was being viewed last too, and not just percent window in case new variables were added.
> 
> The idea is to sort of make it so that the watch window sorta of changes as little as possible between runs so no time has to be wasted each time. It's not so bad most of the time but in some cases it really adds to the time to debug.
> 

This is not under control of Visual D, but it is the Visual Studio Debugger Environment that keeps track of the expansion state of locals and watch expressions. AFAICT it doesn't change it if it can reconstruct it while stepping or running to the next breakpoint, but collapses them if an expression cannot be evaluated in between.

October 30
On Friday, 26 October 2018 at 06:28:51 UTC, Rainer Schuetze wrote:
>
>
> On 24/10/2018 20:47, Michelle Long wrote:
>> Sometimes I have a deep nesting of a variable that I have to expand many times to find some member to check the variable.
>> 
>> Each time I debug I have to spend about 30 seconds digging in to the variable in the watch window.
>> 
>> Could Visual D remember the previous run's expansion of variables and attempt to auto expand them when the next debug occurs? It would need to scroll to whatever variable was being viewed last too, and not just percent window in case new variables were added.
>> 
>> The idea is to sort of make it so that the watch window sorta of changes as little as possible between runs so no time has to be wasted each time. It's not so bad most of the time but in some cases it really adds to the time to debug.
>> 
>
> This is not under control of Visual D, but it is the Visual Studio Debugger Environment that keeps track of the expansion state of locals and watch expressions. AFAICT it doesn't change it if it can reconstruct it while stepping or running to the next breakpoint, but collapses them if an expression cannot be evaluated in between.


Imagine that VS did not keep thee view when stepping, it would be a royal pain in the ass! right? Now simply apply that logic to re-running the program! it is still a royal pain in the ass, but it's just less of a pain since one generally does not re-run as much as they step... but it is still the same problem. In some cases, specially with D, re-running is required a lot more than other programmers and so it is more of a problem.

If VS does not expose any way to deal with this, maybe some hacks can be used.

In fact, maybe Visual D can create it's own debugging experience(although, then why not just create a new IDE? ;))

Basically create a new window(maybe a VS dockable window) that allows for displaying debug stuff better? I really have a need to display matrices in a matrix format rather than having to show each row one line at a time one column at a time(element wise)... makes it very hard to visualize information and therefore makes the process of debugging certain things really slow ;/

D really needs a modern IDE with futuristic advanced debugging abilities... far too primitive for my tastes.