-
Notifications
You must be signed in to change notification settings - Fork 235
Reduce prompt noise when stopping at breakpoints in the debugger #130
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
Comments
In this case I was mimicing the behavior of the ISE when breakpoints are hit. However, I can see the value of not writing the debug prompt initially when the breakpoint is hit but only after the user executes a command in the REPL. That way it'd remove the noise if you're just stepping through a bunch of breakpoints. I think the prompt is helpful in the case where you're typing commands, especially when navigating around directories. At some point I'm going to file a feedback request to get rid of the input box in the REPL window so that you can type after the actual prompt text in the buffer. I'm not sure whether they'll actually do it, though :) |
Yup, I saw that, and I kept typing there to see if I could get any information. |
Do you think that it's confusing enough that it should be removed entirely? I feel like the console experience is going to be pretty weird without a prompt. |
I like that better. I guess we could do like ISE and emit a line like this at breakpoints:
But I'm not sure that adds much value either. The editor is pretty good about switching to the correct file and line when a breakpoint is hit. And when you do write the prompt, I'd remove the |
Yeah, I'll remove the |
Don't know if this makes sense. Adding [Read Only] would make it explicit |
I think [Read Only] may be even more confusing, they might think they can't type commands at all. At any rate, the confusion factor of anything shouldn't be a blocker since I except people will try to enter commands anyway and realize how it works. Hopefully in the future we'll get the ability to let the user type in the REPL window after the prompt so that this won't be a problem anymore. |
With the change to only display the "prompt" when a command is executed at the debug console, I view this as less of a prompt and more of a "marker" between script output and commands I execute during debugging. To that end, perhaps we should emit the DBG line before and after execution of a command at the debug console prompt e.g.:
|
It might be hard to do the before/after because if the user enters multiple commands without continuing from the breakpoint then they'll get duplicated prompt strings on the subsequent commands, something like this:
Showing the prompt only after a command executes is probably enough for now. I'll go with that and see what kind of feedback we get. If people think it's confusing we'll be able to tweak the output for the next release. |
Sounds good. |
This change keeps the debug adapter from printing the prompt until the user enters a command. This will allow breakpoints to be hit without the prompt being shown every time. The change also trims the ending '>' character off of the end of the prompt to reduce user confusion about where commands should be typed.
…port Add support for loading host profile scripts
Every time I hit a breakpoint, I see the DBG prompt in the debug console:
This sort of gives the impression I can type after the
>
which I can't. It also clutters up the output. My question is - do we need this prompt text spit out to the console at every breakpoint and debug console command execution?I guess seeing what path I'm currently at is useful but I'm not sure I need to see that over and over. :-) Also the
PS
in the prompt doesn't really add much value and the>
is downright misleading.Now if you could modify the prompt text in the input textbox area of the DEBUG console - that could be cool.
The text was updated successfully, but these errors were encountered: