Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control the output verbosity or how expressions are printed in DAP REPL #737

Open
wookayin opened this issue Oct 26, 2022 · 3 comments
Open

Comments

@wookayin
Copy link
Contributor

wookayin commented Oct 26, 2022

Problem Statement

Can we control how an evaluated expression is printed in the DAP REPL? If the default one is too verbose, showing all the attributes (as a tree) expanded, can we make it compact so that it behaves closer to conventional debuggers --- specifically, when it comes to python, like pudb or ipdb.

(This might be a bit python-specific, but could be related to other languages as well.)

image

For instance, when printing out some python object in the REPL, it shows not only the __repr__ representation but also all the attributes as in the variables/watches widget. As an example, a pandas.DataFrame object will print ~100 attributes and lines that would be too much verbose and not that quite informative.

Possible Solutions

(1) Always print the attribute tree in the REPL window, but make it collapsible so that when collapsed it takes at most one line. In this particular example, it may show a few, concise lines like (which could be collapsible and expandable):

▸ df DataFrame = Empty DataFrame
                 Columns: []  
                 Index: []    

(2) Add an option (in any ways) to completely disable displaying the attributes; and print the __repr__(object) only as ipdb, pudb, etc. does.

image

Considered Alternatives

microsoft/debugpy#1078

wookayin added a commit to wookayin/nvim-dap that referenced this issue Jul 29, 2023
A new option `show_tree` can be set by users to configure whether to
show the expandable tree in the DAP REPL window. Concise and simple
representation in the REPL would be useful for many languages,
see mfussenegger#737 for an example (python).

The option can be configured using, for instance:

```
require('dap.repl').show_tree = false
```
@mfussenegger
Copy link
Owner

Relates to #1062

This seems a bit specific to python. Only printing the root would make it significantly worse for other languages.

Always printing repr(object) would require language specific knowledge in nvim-dap. That's out of scope but
a fairly simple solution would be the .e0 repl command mentioned in the other issue. It would give users control over how many levels to print

Other than that I think it would require some custom formatting hooks. I'm open to suggestions how those could look like

@wookayin
Copy link
Contributor Author

Is it difficult to make the tree collapsible by default or upon configuration? Or any kind of configuration point will be great.

@carschandler
Copy link

I agree with this completely!

Here are a few examples of how other debugger environments handle this:

  • VS Code's debug console handles this gracefully by printing only the __repr__() which can be expanded if desired to show all attributes. This is by far the best solution IMO. You get the __repr__() which is incredibly useful when working with packages like numpy, pandas, xarray, etc. which were tailored for use in REPLs/notebooks, and you also get the ability to expand it and poke into attributes if needed. Specifically, you get the __repr__() printed so that it is formatted correctly, not just the string representation of it with a bunch of \ns included. I was poking around the VS Code source yesterday trying to see where it enforces this behavior for Python, but I haven't found it yet, and it may be somewhere in the Python extension.
  • I also have lots of experience debugging in ipython using ipdb which relies on the ipython REPL itself for inspection (similar story for pdb and the default Python REPL), so only the __repr__ is displayed (formatted properly), with no ability to drop down. I much prefer having no attributes shown to all attributes shown. If I need to see what is available inside the object, I'll just tab to auto-complete or if I really needed to see all attributes available, I could just dir(my_object).
  • In PyCharm, the Evaluate Expression input box returns a collapsed tree representation, much like what we would get if we only showed the root in nvim-dap. Undesirable, but it makes up for it by including an ipython console in a different tab of the debug window where I can get all the same features mentioned in the previous bullet! Very cool, and if it's possible for nvim-dap to hook into ipython then I would be elated, because the ipython console is simply incredible. Not sure how JetBrains is doing it, may have something to do with the embed feature in ipython. I think Spyder does something similar.

While I generally think that language-specific hooks are yucky, I think the alternative of printing the entire tree is worse in terms of user-experience and it's not what has come to be expected from a Python debugging experience.

In summary, I think the best options would be, in order:

  1. Make it so that the REPL prints only the __repr__() of the object by default with the ability to then expand to see all attributes. Bonus points if the __repr__() string is actually python-printed so that format is correct.
  2. Only print the properly formatted __repr__() string, but then you throw away the beautiful capability and UI of the nvim-dap REPL.
  3. Add the ability to make the root collapsed by default.

One could also make the argument that you could just print objects each time you want to see the __repr__(), but I have noticed that the nvim-dap REPL prints twice when you do this, which is annoying when printing something that takes a bunch of lines and can be disorienting to find where it actually started. This whole issue probably wouldn't bother me as much if printing just printed once lol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants