-
Notifications
You must be signed in to change notification settings - Fork 915
Inlining values inside debugger #8019
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
Conversation
|
really useful feature! We have to watch out for side effects of calling The debugger does have "Variable Formatters" which can be configured in the settings. Collections (which can be large) will only print their size by default for example. (but I imagine you are probably planning to do that anyway) |
|
I did a lot of improvements lately. Lets see if this is heading in the right direction. |
Done. |
|
FWIW, in VSCode, this needs to be enabled explicitly using the: setting. I didn't find a way, yet, to make it work with |
|
gave it another try and it worked great. I got one exception once but wasn't able to reproduce it a second time: the inline hint should also listen to the main on/off toggle and be potentially also configurable like its other friends (see options window): (I think listening to the main toggle would be sufficient, finer grained options could be added when needed in followup PRs - we don't have to solve everything at once) |
|
Thanks for testing. I'll look at the exception. For the toggle - I think I would prefer to have a different toggle (people may want the debugger values, but not parameter hints, and maybe even vice versa). I'll look into that. |
|
I like where this is going, and agree that this shouldn't be aligned with the inline hints toggle but something separately configured. |
|
What I had in mind is that I think it would be nice to retain the master switch for all inline hints, but add more shortcuts for the sub-switches. It could be somewhere in the debugger toolbar too potentially. Completely decoupled from the editor setting could also work - not sure what is more intuitive. (I suppose i could double-bind my mouse button to achieve something like a master switch still no matter how its implemented) |
|
Aside from commit cleanup (cause of failing test) is this close to ready for merging, or are we retargetting for NB27? |
|
Moving to NB 27, although assuming I can stabilize tests, I would like to integrate as early as possible (so that there's time to fix any breakages). |
af6ff55 to
470ee74
Compare
b6b14eb to
380837c
Compare
mbien
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there seems to be a problem where the inline hints state and the displayed values in the UI are out of sync.
When I press alt+I the checkbox in the view menu (and options) don't update to the new value, even though the inline hints do toggle within the editor. The UI does still work, but it can become inverted with the editor state.
This is a bit of a dejavu since I think this happened before while working on a prior inline hint PR - but I can't remember what the problem was.
java/debugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/values/ComputeInlineValues.java
Outdated
Show resolved
Hide resolved
...bugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/models/InlineValueComputerImpl.java
Outdated
Show resolved
Hide resolved
I tried to reproduce, but does not happen for me. Is there something specific you do? (I did a merge, so there's a possibility that fixed it, although I'd be surprised if it did.) |
|
got the same NPE again while testing (#8019 (comment)):
Oops, I just noticed that this problem is already in NB 26 - so we can probably ignore it here since it is not a regression: I don't have a reliable reproducer yet unfortunately. At some point the |
|
I've fixed the NPE (hopefully), and squashed (to hopefully get a clean GH Actions). I wonder what are the current impressions on this? |
mbien
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good overall. Left a few comments.
...bugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/models/InlineValueComputerImpl.java
Show resolved
Hide resolved
...bugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/models/InlineValueComputerImpl.java
Outdated
Show resolved
Hide resolved
...bugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/models/InlineValueComputerImpl.java
Outdated
Show resolved
Hide resolved
...bugger.jpda.ui/src/org/netbeans/modules/debugger/jpda/ui/models/InlineValueComputerImpl.java
Outdated
Show resolved
Hide resolved
It was there to initialize the computer. But turned out I can simply instantiate it, and it (hopefully) works as well, using |
I guessed that something like that might have been the reason for it. I was just thinking since lookup returns a List and no lazily initialized structure, it could have been already sufficient without the loop itself. But the new impl is more direct and less mysterious - thanks. |
|
Unless there are objections, I would like to merge sometime soon - probably today or tomorrow. |
|
great feature! I agree that it would be good to get it in. Don't forget to squash ;) |


This is a prototype of a feature to show variable values directly in the editor, as permitted by the LSP protocol.
It looks like this inside VS Code:

and inside NetBeans:
