Offer an setting to turn off inline break points

[octref]

I don't like my text to be shifted, also when I'm editing text in debug mode, the breakpoints can get into weird state. Try to delete or move text around the breakpoints and you can easily find this happening:

[isidorn]

It is a fair feature request to have a setting to turn off inline breakpoints. However I would not add it until we get more feedback like this.

As for the weird breakpoint locations when you edit text that is a duplicate of https://github.com/Microsoft/vscode/issues?q=is%3Aissue+assignee%3Aisidorn+author%3Amjbvz+is%3Aclosed
And @roblourens can comment more (I think the fix is pushed, but not sure if new node extension was released)

[eamodio]

While I don't think I'd want to turn them off -- I do find them too intrusive in their current form especially since they show up in unexpected places (imo - see below) and bounce/shift when toggled.

I also find it odd (even though I understand why) that there are 2 dots at the start of the line -- the toggle for all of them, and the toggle for that start of the line. But maybe the start of the line one should only show up if a column breakpoint is selected? Because otherwise it is really just a duplicate and visual noise (imo).

[isidorn]

@eamodio thanks for the feedback. I am open to changing this, however I would wait for more feedback still. Thanks

[roblourens]

The bouncing is definitely annoying, also the fact that the first breakpoint tends to shift the text by a whole tab, rather than just by the width of the breakpoint.

I would say that maybe we should hide the first bp decoration when the user just set a line breakpoint, but it can also be useful to see where that breakpoint actually is, if it is not in the location where you expect.

[octref]

Yeah, this makes it much harder to read. If there's no option to turn it off, I definitely hope it doesn't shift at least the beginning of the text so I can't easily read blocks' start and end.

[eamodio]

Yeah I would vote to hit the first BP decoration too if its for the whole line. But when it should show up, we could check to see if there is just whitespace and have it be placed without taking up space in the DOM, and only take up space if it needs too (e.g. the line has no leading whitespace)

[lopugit]

any updates on this? I'd like just breakpoints on the left of the line number and that's all

[netpoetica]

I will second the notion that I would love to have them, but the jumping around is so distracting that I would be happy to at least turn them off.

I have encountered quite a few strange things that were not just simple visual complaints:

• when you are editing code and a breakpoint is set, it visually appears that your indenting is wrong. Then your linter complains when you "fix" it, because it appears at correct indentation but is actually "wrong" - it only appears correct because the breakpoint is essentially a tab.
• I have seen some strange quirks where the breakpoint will not appear directly at the place you would expect. For example, return this.sayHello(), if you put a breakpoint on the line, the code would appear like r[]eturn t[]his.s[]Hello(), where [] is the position of the breakpoint

I would personally prefer to right click on the row and then say "add inline breakpoints", and then it would show all those helpful hints it already does of where it could go. But generally stopping on a line is what I am looking for.

Cheers!

[dougdenn]

I would also add my vote to be able to turn this off because the line breakpoints don't always work correctly. Example:

I want to break before newState is returned, but instead the only breakpoint option I have is after the return so I can't see anything. Note that the return null lower down does have the option to break before returning.

[roblourens]

In your case @dougleville, inline breakpoints are actually helpful because they are showing you that (for some reason) there is no valid BP location on that line before return newState. "disable inline breakpoints" just refers to whether we show the inline decorations, it wouldn't affect actual pausing behavior. This could be because of the way the code is minified or just runtime weirdness. But if you see something different when debugging with chrome devtools, that could be a bug, please file a bug for that.

[isidorn]

We will first try to improve the experience to decrease the jumping and than if people still would like a setting I would be open to add it in the future. Thanks for the feedback

[dougdenn]

In your case @dougleville, inline breakpoints are actually helpful because they are showing you that (for some reason) there is no valid BP location on that line before return newState. "disable inline breakpoints" just refers to whether we show the inline decorations, it wouldn't affect actual pausing behavior. This could be because of the way the code is minified or just runtime weirdness. But if you see something different when debugging with chrome devtools, that could be a bug, please file a bug for that.

Replying for the sake of completeness - fair enough, I checked the Chrome debugger and the behavior was the same so this is confirmed not a vscode problem. Thanks @roblourens

[octref]

Another option is to have a half-transparent red background on the first letter after the breakpoint, instead of removing it completely. This way the text doesn't shift and we can still see the inline breakpoints.

[isidorn]

Here are some ideas for the name of the setting. The setting would be a boolean
debug.inlineBreakpointLocations
debug.inlineBreakpointCandidates

I would like to have inline breakpoint in the setting name since users asociate the breakpoint locations withe the inline breakpoints as seen in the name of this issue

fyi @weinand

[isidorn]

I went with debug.inlineBreakpointCandidates try it out and let me know how it goes.
I am open for changing the name. And I still plant to fix the UX issues with the candidate breakpoints, though having a setting does not hurt since the backend can be wrong and there is nothing we can do about it.

Fixed via 47b8f20

[weinand]

Since this setting affects the UI I would have expected to see a "show" in the settings name, e.g. debug.showInlineBreakpointCandidates.

[isidorn]

Makes sense. Thanks! I have changed the setting name as you suggested to debug.showInlineBreakpointCandidates

[lopugit]

Makes sense. Thanks! I have changed the setting name as you suggested to debug.showInlineBreakpointCandidates

you are a fuckin legend, next time you're in Melbourne, Australia I'll buy you a beer <3

[hagemann]

Idea: How about toggling BPs with a double-click? I never use BPs and find the feature excruciatingly annoying when selecting lines or when accidentally clicking the area to switch windows. I think a double-click wouldn't be so much pain for someone who uses BPs while it's an incredible relief for someone who doesn't. Completely disabling them is another solution.

[weinand]

@hagemann The issue has been closed more than a month ago. If you want to get heard, I suggest that you create a new issue with your suggestion.