Decorations with gutter icons hide breakpoint icons
ArtemGovorov opened this issue · 43 comments
- VSCode Version: 1.0.0
- OS Version: any
Steps to Reproduce:
- Create a decoration type
window.createTextEditorDecorationType({ gutterIconPath: ... });with an icon, decorate a line. - Set a breakpoint for the line. While the breakpoint works, the decoration type gutter icon is completely hiding it.
Ideally, there should be a way to see both (all) icons. I'm assuming the same issue happens if two different extensions set different icons for the same line. Atom and IntelliJ platform based IDEs solve this by allowing to create a plugin specific gutter/or just extending the gutter horizontally to fit all icons.
If the above mentioned solution is not desirable for some reason, then it should probably be allowed to set a gutter icon zIndex for a decoration type. Or maybe the breakpoint icon should just take precedence and always be displayed above any extensions icons.
Hi guys,
Any news on this issue?
it's making it much harder to debug like that (i'm used to use the mouse to set a breakpoint)
Today there is space in there for one glyph.
I guess we need to implement an overflow experience in there.
This is a feature-bug, as the code was never designed to handle more than one glyph margin for a line.
+1 on this - I'm experiencing the issue with Wallaby, but I can see that other plugins may be competing for the same real-estate in the future. Visual Studio supports this feature today.
+1 Also am a Wallaby user who would like to see both breakpoints and wallaby line coverage. My thought is that seeing the breakpoint glyph is of higher importance than the coverage glyph, maybe some kind of multiple glyph (with precedence) system would work?
Ignoring the obvious degenerate cases, why not just make the gutter big enough to hold the maximum number of glyphs currently displayed on any line??
New to vscode (really enjoying it so far). Also a fan of wallabyjs and would love to see a feature added to allow more elegant behavior here.
It sounds like there are two main ways this could be resolved:
- Easier, less flexible path: Allowing z-index style ordering so Wallaby icons go below VS Code's
- Complex, better path: Increasing the width of that gutter area
@alexandrudima is the "easier" path something a first/second-time contributor could tackle? (any hidden gotchas?)
I think that could work. IModelDecorationOptions could get a new zIndex property that could be used for sorting in the various places we render decorations.
Cool, looks like 843facb fixed this. @ArtemGovorov is that enough to go off of?
@JoshuaKGoldberg Unfortunately, gutter icons decorations in VS Code are apparently rendered by applying class names to the same div, so zIndex is irrelevant:
I just ran into this with my extension, I want to show brackets in the gutter but as long as they block breakpoints it's highly annoying and probably won't be used.
+1 please fix this issue
I would very much like a solution to this as I have just forgotten how much I miss using Bookmarks from VS (which has been my history with VSCode.. what am I missing, go find an extension that does it).
Would there be some way an extension could detect other 'states' for a line like 'there is a breakpoint here' and if so incorporate a combo glyph for display? Just some basic onAddBookmark() { if line(number)->hasBreakPoint { useBreakpointBookmark } else { useBookmark } } .. Or something? I know this would not fix multiple extensions working in conjunction with out some auto-combine capabilities to generate the compiled glyphs.. But it might be a step in a direction.
+1 Running into this issue with Wallaby code coverage indicators vs breakpoints.
+1 Had to stop Wallaby while debugging tests.
+1 it's really annoying to stop wallaby when I want to debug the application.
+1
+1
Wait, if gutter icon rendering is handled by applying classes to a div, then couldn't an !important modifier be added to the breakpoint class style? Not the best long term solution, but wouldn't that solve the immediate issue?
In some cases it's much more convenient to just click to set the breakpoint, especially on a laptop that requires you to click the line then press fn+f9 -- I really hope that whatever solution is decided that this would be continue to be possible... Could a possible solution be that gutters are added by extensions instead of reusing the existing one? That would be relatively similar to the "gutters as wide as they need to be" solution, though I imagine it could get rather cluttered.
Honestly for me losing the click to set breakpoint functionality is more annoying than not being able to see it, since I can see it in the breakpoints list in the debug panel... would that part be a wallaby issue, like they should set pointer-events: none to allow for the click to pass through?
This is now an issue for Flutter/Dart projects as well.
+1 - open since 2016 and still no solution to the rather common problem of "being able to debug using modern methods"? :) I cant believe we're stuck with 'use keyboard shortcuts' as a solution - any news?
Personally I would be in favor of 'stacking' icons, click would toggle breakpoints, and the "top" icon should indicate breakpoint status. Would solve most of my issues, may not look greatest, but would work for now. Not setting/indicating breakpoints on gutter click is just wrong.
Per personal experience and #95992, the breakpoint icon is no longer hidden when other decorators exist, it merely is displayed in front of them. It seems that as long as #5455 is unresolved (or remains an unplanned feature), an easy (and albeit temporary) solution to this particular issue (and moreso to #95992) would be to make any click event in the breakpoint portion of the gutter toggle the breakpoint for that line (as is the expected behavior when there is no decorator). It seems that click events are ignored when a decorator is being rendered, and that could (potentially) prove to be relatively trivial to resolve.
It has been 4 years and over 90,000 issues since this problem was originally raised. I hope my suggestion may aid in finally making some progress.
+1 for fixing this
+1 for fixing this
I'm not sure how the code could be fixed, but could we have this mix?
Can we consider if can have appendDecoratorItem or prependDecoratorItem?
hi,
Just curious what is the main blocker for resolving this issue? Does the vscode team think this should NOT be addressed? Or there is no consensus on how to fix it? Or maybe it is a resource/priority issue? It seems there are a lot of interesting suggestions but did not see comments from the core team... can someone from the vscode team shed some light on how to best move forward on this issue? thanks.
4 years. The issue has been here for 4 years. Am I the only one who thinks it's crazy that this hasn't been worked on so far? I find it quite critical.
It also works very poorly with Error Gutters: https://marketplace.visualstudio.com/items?itemName=IgorSbitnev.error-gutters
Will there be a fix for this?
+1...5 years now without a fix, c'mon guys
any update on this its 5 years now .
Yep, +1 on this one. Seems simple enough so lets get it done! Clicking the line number could also set a breakpoint or something? :)
Is there any update on this issue?
+1 for fixing this , it havn't been fixed yet
looks like this has been resolved in TestExplorer since v1.59, see the gutter menu below. Is there a way to expose the same feature to extensions? cc @connor4312
It looks like the root cause is this function:
Where the breakpoint hover/click overlay is explicitly being skipped. While I can kind of see the reasoning -- e.g. not wanting it to look like there is interaction based on the decoration shown, as it will always be about the breakpoint -- at least until #5455 is supported.
Maybe there could be a new gutterInteraction: false or gutterAllowBreakpoint: true setting that could be added to the decoration options, to allow the breakpoint interaction to be allowed on top of a gutter decoration. Or maybe this should just always be allowed for all current gutter decorations, and when🤞 interactivity on the gutter lands it could turn off the breakpoint interaction.
/cc @hediet as you've been making some recent changes with the 3-way merge support
I know some UX changes needs a fair amount of exploration and tests, but I wonder why not borrow how other products works.
- JetBrains IDEs (IntelliJ and Rider) simply expand the gutter to support more decorators.
- Embarcadero Delphi reserves a gutter space to breakpoints, and additional decorators (like bookmarks) are added to its side.
I mean, it's been 6 years...
looks like this has been resolved in TestExplorer since v1.59, see the gutter menu below. Is there a way to expose the same feature to extensions? cc @connor4312
This is something we manually handle in the testing code in VS Code core.
We've also discussed this in #114776
Sorry please delete - commented on wrong issue
This feature is desperately needed.
Want to just ping the devs on this again, since it's now 2023.
I personally came across this bug due to the test coverage highlights blocking my ability to add debug breakpoints.
Would love to see this fixed!