JDHankle / riviera

Remote Debugging in EMACS
GNU Lesser General Public License v2.1
6 stars 1 forks source link

Retain Variable Expansion throughout Stepping #12

Closed danlamanna closed 11 years ago

danlamanna commented 11 years ago

Requires researching tree-widget

danlamanna commented 11 years ago
This is by far a weak version of the feature, here are the current issues:
We store the expanded list in terms of variable name

Meaning $foo in one area will stay expanded if we step into a different scope with $foo defined, this isn't ideal behavior. Fortunately, xdebugs XML returns the physical memory address of the variable so we may be able to just switch these out and solve this issue entirely.

We retrieve the variable name through an awful regex

This issue is probably to be taken lightly, I'm sure it can be retrieved in an easier way and this might not even be necessary if we start using the memory address.

We use a tree-widget specific hook rather than the notify setting of widget.el

After battling with the notify setting in the core widget library with no success in getting it to trigger, I resorted to the hook, in the event that tree-widget ever gets removed for something more favorable this will break.

danlamanna commented 11 years ago

Aside from the tree-widget specific hook, the rest of the issues are resolved.

The one thing I noticed is if a variable $foo is expanded, and then you enter another scope where $foo is defined locally - it won't be expanded (as intended), however if you leave that scope and enter into the original one where $foo was to begin with, it will remain expanded. I consider this a feature, if you wanted to view $foo in that scope originally, you'll want it to remain expanded to view after as well. Though if it weren't a feature, it would require watching for when variables fall out of scope to remove them from the expanded variables list which is a large amount of work.

Additionally, I added the feature that refreshes our context list after an evaluated expression, so changes from the eval'd expression are "realtime". The only concern I have with this is large context lists that need to be reloaded.