Fixed bug where line breakpoint would use incorrectly character #490
Conversation
|
Adding break points to the test is definitely something we want to do but I do think it's an pr in itself. May be something to add to the todo when/before object orient the targets are implemented to make sure that we don't don't have any regression? |
|
I don't think it should be too hard. Just a manual test like the one you did for #382, no? Ie run the add breakpoint command, then list editor breakpoints. I'd think the actual content (ignoring test setup boilerplate) would be like 10–15 lines. But maybe I'm missing something? |
|
Ok I was thinking line breaks for the test recorder. A one of can of course be made. |
No that seems like overkill. Just one to test happy path and one to test the thing you just fixed is probably plenty. Can't imagine we'll be recording lots of breakpoint tests |
|
Tests added |
There was a problem hiding this comment.
Nice test! I believe your code is also careful to make sure it doesn't move the end of the target to the start of the line when it is doing a removal, so might be good to add a quick test to ensure that using "break air" for removal works properly, lest someone (me probably 😅) moves that if statement upwards in an effort to "simplify". Make sense?
|
Removal tests added |
Line level breakpoints are always on character 0. This new implementation is consistent with the built in vscode breakpoint functions in regard to line and inline breakpoints.