I have a user snippet configured in Visual Studio Code. Let's take one of the items in this snippet: one with the prefix imp.
Now, prior to the recent VSCode update, as soon as I did something like the following.
it automatically showed the autocompletion box to me (I didn't have to press Ctrl + Space to activate it), as shown below:
But now after the update, something strange has happened. When I type in just im, obviously, it shows me the <img> autocompletion suggestions as shown below:
But when I continue to type the full thing imp, the autocompletion box gets hidden. It's only when I press Ctrl + Space that I get the autocompletion box again.
What is the reason for this problem and how to fix it?
I can reproduce your issue exactly, which led me to look to see if it has been reported on github. It has, see Snippets gone from IntelliSense.
From same issue as above:
I have pushed a fix for next insiders and I have pitched this for the
1.75.1 recovery release
It is in today's Insiders (I just tested it) 02/03/2023.
So you can either try the Insiders Build now or wait for the Recovery Release. And continue to use the manual trigger of Ctrl+Space in the meantime.
As #WayneBloss mentions in a comment below, disabling the snippetsPreventQuickSuggestions setting might fix the issue.
I've been using vscode + eslint + prettier for react / react native editing. All of a sudden, it starts to show the detailed error / warning message, which is not necessary at all, after each wavy underline. The error / warning messages used to only show up when hovering over them.
All I need the classic wavy underlines and less verbosity. Please see the screenshot below. Thanks a lot!
My Visual Studio code editor keeps underlining my code incorrectly and I don't know how to stop it.
Here is an example of my JavaScript being squiggled:
I have tried installing prettier, eslint but it does nothing to solve this.
How can I stop these squiggly lines from appearing incorrectly? I want them IF they are correct.
If I click on the problems tab, it shows this:
Solved! Thanks to zscoop98's answer, I was able to find this page which showed there exists an option standard.enable in settings.json that, after setting that from true to false, it solved the issue and there are no longer these annoying red squiggly lines.
And you can uninstall ESLint extension in vs code to get rid of red lines.You can search ESLint extension in extions folder of vscode
In the image above, I tried setting breakpoints on every line from line 437 to line 443. However, I cannot set breakpoints on lines 439 and 440. When the function runs, the breakpoints on lines 437, 438, 441, and 442 are ignored. Chrome breaks on line 443. This means that I cannot do some debugging before the first conditional runs.
When I click on lines 439 or 440, the breakpoint appears for half a second and jumps to line 443.
Is this a bug or am I missing something? How do I set a breakpoint at or before line 439?
If you are using js minification and sourcemaps, ensure that they are up to date with your source code.
I have same problem in chrome dev tool source panel snippets when I write some codes to test my idea.
Only way for me worked is close dev tool panel and refresh page then reopen
This problem happened after I modified codes in debug mode
This was frustrating for me today but I found the problem. I was trying to place a breakpoint inside an orphan function (nothing was calling it). As soon as I fixed it, all was well. Smart - but wish there was even a tiny hint that this was the case.
I think that my classmate and I had this issue as well today. We made our changes and then hit Ctrl + S (or Cmd + S) to save the changes in the debugger and then we were able to add the breakpoints.
This recently became an issue for me, running System.js and Babel, and with plain ES6 transpiling, I haven't gotten to minifying/mapping yet. A workaround seems to be to add your breakpoint to the !transpiled file, a matching breakpoint will automagically appear in the corresponding line in the raw file.
In my case, I could not put a break point on the calling function line, but it worked into the function... weird but at least it works.
I just had that problem and realized that what I saw in the dev tools source was not the code that actually ran in the browser.
Make sure you empty your cache and reload and have the up to date code.
My problems where in sourcemaps definitions.
I solved my chrome debugging problems with this article: https://www.mistergoodcat.com/post/the-joy-that-is-source-maps-with-vuejs-and-typescript
I was allmost there, all i had to change was at vue.config.js: devtool: "inline-source-map" -> devtool: "eval-source-map"
In my case it was, most likely, a bug in the devtools. When I clicked to set a breakpoint inside an async function nothing seemed to happen, no visual indication of the breakpoint. Although outside the function it showed the blue mark correctly.
But when I ran the code it turned out that all the breakpoints had been set actually.
In my case, it turned out the function I was trying to add a breakpoint in, was never called but I'm not sure why it didn't allow me to add a breakpoint that would never hit anyway.
Can anyone make sense of this apparent contradiction?
Please look at the following screen shot.
The debugger shows the correct error object but the roll over shows the parameter to be null. The latter appears to be the actual state because no error text gets logged to the log file but the debugger shows what should be there!
It's a bug. Please follow WEB-13863 for updates