You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is intended to be continuation of discussion under #191.
Usability of locals window is limited as variables can store far more complex data than short strings and integers.
In my opinion the most important cases are:
Deeply nested/large data structures (dictionaries in dictionaries in lists and so on)
Objects
Problem common for all these cases is that these data types will consume lot of space on UI therefore more advanced value folding is needed.
It should be possible for example to request showing all keys in dictionary and then expand specific values.
Obviously, it must not be limited only to top level dictionary; Nested dictionary should have equal ability.
When it comes to objects, it should be possible obviously to list names/values of fields and maybe additionally other data like list of methods.
In my opinion it would be nice if users themselves would extend realgud in this area and for example add custom data visualizations (like printing charts with data from python's pandas and so on)
This topic is massive. Probably i will add some sub-issues for it. It will take far more time than current locals implementation and require lot of research.
Additionally, in next months i will not be able to spend that much time on realgud as not, so progress will be slower and i can be less responsive;
Nevertheless i will work on it.
The text was updated successfully, but these errors were encountered:
I'm having a similar issue with the visual representation of some variables with the realgud-xdebug, mostly because of the PHP object representation, and of course that the minibuffer is not enough.
This is an example of a "eval" command to the $kernel variable (in this case due to the xdebug cli implementation be in alpha/beta the real eval command doesn't work).
Also the idea of having a separate buffer with local/global/constants may be interesting, I was thinking in implementing this feature for the realgud-xdebug implementation but, probably a more general solution is a better aproach.
Here are some of the ideas I can help to implement:
Having a separate buffer with variables or maybe functions (similar to imenu?)
Give the debugger implementation developer the ability to parse the eval/get property buffer in order to get some semantic functionalities (navigate to the source code of the variable/class for example).
I'm still learning the realgud code base, but I'm willing to help to improve it, so Emacs can have the best debugger experience, compare (even better?) to more common use IDEs/Editors, and I think this kind of functionalities are a must to.
This issue is intended to be continuation of discussion under #191.
Usability of locals window is limited as variables can store far more complex data than short strings and integers.
In my opinion the most important cases are:
Problem common for all these cases is that these data types will consume lot of space on UI therefore more advanced value folding is needed.
It should be possible for example to request showing all keys in dictionary and then expand specific values.
Obviously, it must not be limited only to top level dictionary; Nested dictionary should have equal ability.
When it comes to objects, it should be possible obviously to list names/values of fields and maybe additionally other data like list of methods.
In my opinion it would be nice if users themselves would extend realgud in this area and for example add custom data visualizations (like printing charts with data from python's pandas and so on)
This topic is massive. Probably i will add some sub-issues for it. It will take far more time than current locals implementation and require lot of research.
Additionally, in next months i will not be able to spend that much time on realgud as not, so progress will be slower and i can be less responsive;
Nevertheless i will work on it.
The text was updated successfully, but these errors were encountered: