Somehow, after a vscode update my debug line-highlighting line is gone. Debugging works normal, but I never see the correct debugging line. The grey highliting in the screen below is just the cursor-line highlighting.
In the picture below, current debug position is line 147 - but no yellow debug line.
When i press F5, the next line gets highlighted grey, because the cursor switches there. But still no yellow highlight for my currently debuged line. When i click on on another line in the code the grey line switches to that position, leaving the current debug line without any highlighting.
I have a skin installed, "Solarized Express Soda", but deactivation does not fix this.
Is it possible to switch vscode versions back to test this further? Or to deactivate all extentions at once to have a vanilla vscode to approach the problem via elimination process?
VScode Version 1.46.1,
Node Version 10.21.0
Actually, i solved the problem now.
I installed a previous version of vscode, january 1.42.1 - Now it works again properly. I think i will report this issue on the vscode forums. Pherhaps an issue in correlation with my many extentions & old node version 10.21.0(which is still in need - thats another topic)
But perhaps, someone can tell me what I've done wrong, actually, i cant see anything wrong on my side here...
Related
When I click on a line to set a break point, the break point line gets highlighted, then the break point highlight disappears.
Other than that, Firefox developer debug has been working fine.
This might help people in the future without having to modify any js file:
Have you clicked the Deactivate breakpoints button? Pressing this will toggle breakpoints on/off.
If the icon is in blue, it means the breakpoints will be de-activated.
Note: I have noticed that in some sessions the toggle is activated although not blue, a refresh of the page solved this.
This just happened to me in Firefox 60.3.0. The tip about removing the Mozilla folder led me to a better solution, which is to edit the prefs.js file in the Mozilla profile folder. (In my system this was in C:\Users\xxx\AppData\Roaming\Mozilla\Firefox\Profiles\xxx.default)
I deleted all of the lines in prefs.js that began with
user_pref("devtools.
e.g.
user_pref("devtools.toolsidebar-height.inspector", 350);
user_pref("devtools.toolsidebar-width.inspector", 350);
This fixed the problem while preserving all my bookmarks, saved passwords, etc. The lines in prefs.js were recreated when I next ran the debugger.
I my case I have mistakenly enabled 'Blackbox source' on a file (in right click menu). When I disabled it then the breakponts works again.
I just encountered the same problem - Firefox Quantum 60 on Ubuntu.
Solution for me was to delete the ~/.mozilla folder for my account. Lost all my bookmarks, history, settings, etc., but can now set breakpoints again.
In my case it was 2 check-boxes to check:
I ran into this problem, or a variant of it as well. For me, it was because webpack was defaulting to setting devtool to "eval". This broke stopping at breakpoints in Firefox for me. Changing that setting to "source-map" resolved the issue, though I suspect most other non-eval options would work fine as well.
I noticed this because I looked in the generated JS file and noticed everything was put into eval() calls.
Also, check the console for errors. I've experienced this issue (can't set a breakpoint) when there is an error elsewhere in the page..
I just stumbled across a similar problem. In my case, it was the eye on the lower left of the debugger window.
The breakpoint vanishes after clicking the eye:
Update:
And another way to blackbox a source:
UPDATE 16-02-29:
I managed to fix this error by trying to build from the sources hosted on github. Building this way worked but I suspect the fix had something to do with either me downloading powershell 4.0 or Microsoft Build Tools 2015, because I was prompted to update after starting cmder and the bug was still gone even after update. The fix might have also been from editing the init.bat file to point to my manual install of the latest conemu before building. I'm not sure.
ORIGINAL POST:
I'm following a tutorial to setup vim on my Windows machine. I have a weird bug though where when I scroll down on a file in Vim, every other line gets highlighting and will go away if I move the cursor up to those lines.
Like this:
This seems like a screen refresh issue of some kind. There's a similar problem, not sure if related, where sometimes when I got back to cmder after quitting vim the prompt will be placed in the middle of the previous outputs and will start to overwrite these previous lines as commands are executed. This is fixed either by a cls or restarting cmder.
Tutorial: https://www.youtube.com/watch?v=NPtJ4TquQZY
When debugging program in Idea (I'm using 14.1.5 Community Edition), it attempts to put the line I'm currently on close to the center of the screen. And it does so every single step. However, I find this default behavior very annoying, it looks like the code is jumping around.
I wonder if there a way to customize the debugger view in a way that the code would be fixed (as long as I'm not leaving one screen of code) and the current line highlighting would be moving around? (I didn't find it in the Debugger section of the settings.)
Many thanks.
You want to disable "Focus application on breakpoint" which is in the settings under Build,Execution, Deployment > Debugger - it's the first checkbox. It's help documentation reads:
If this check box is selected, on hitting a breakpoint, IntelliJ IDEA will show the location of this breakpoint in the editor and will attempt to bring its frame to the front.
This should do the trick.
I'm using Son of Obsidian color scheme and I've noticed every so often ReSharper Current Line Highlight goes back to the default color. To fix it all I have to do is go into Fonts and Colors and press ok and it goes back to normal. However it's really annoying when it happens and was wondering if anyone else is having this issue? Not sure if it's a VS or ReSharper bug.
I've had the same issue, I think I have narrowed it down to when I upgrade Resharper. Best way is to export your settings and then reimport them after upgrading.
Another thing that I have noticed is if you have two instances of VS open when you close the last instance it will override any changes you made in the previous instance.
I have been searching for an hour or so here and on Google and cant find the answer as to how correct breakpoints being shifted during run. I have reinstalled Xcode(3.2.2), insured load lazily is off, no optimization in target settings, and every other target setting that might cause the problem. I have also destroyed all of the user project files (except for the main .pro file) and nothing seems to correct this. Yes, I am running with breakpoints on. Yes, I have done clean builds.
When I set a breakpoint, in the debugger the break stops two or 3 (or more lines) down in the source code, single stepping continues to show the wrong line. Also, in the debugger window the dark blue breakpoint symbol is gone, it does appear in an editor window.
This is driving me batty.
I had a similar problem (weirdly shifted breakpoints) but my issue turned out to be that I had the wrong target set, so the code I was modifying and setting breakpoints on wasn't even being rebuilt! But the executable would still run, using the old code, leading to what appeared to be oddly shifted breakpoints.
Sometimes Xcode gets confused about line numbering when your source files have inconsistent line endings, e.g. because you've been using different editors and may have a mixture of different line endings in your source file. You can use a tool like BBEdit or its free sibling TextWrangler to fix this problem.
With-in "Build Settings" under the project target change the "Optimization Level" for "Debug" to "None".
I found that this fixed the issue for me.