Ive been looking on the the internet for answer but none comes close to what i was looking for. What is the folder for?
and inside is this json file:
What happen if i delete the folder and do i really need that to be in the folder? Thank you
Short answer:
If you delete it, probably nothing much bad will happen. It'll probably get created again. Your live server may or may not end up on the same port. Probably don't commit it to source control (but maybe you want to).
Longer answer:
.vscode as a folder name has a few clues:
the leading . kind of means "hide this folder". It comes from *nix operating systems where by default if you name a file or folder .anything it'll get hidden.
being called .vscode, which is the name of the editor you're using, suggests it relates specifically to using vscode.
The fact that it gets created when you "do something" suggests that it'll cope if it's not there, but probably the way it'll cope is to re-create it. That's a pretty common thing too.
One use for a settings.json file in a folder is for settings that are specific to that folder. Often you'd have settings that you want to apply to vscode wherever you're using it. But sometimes you have settings that apply to a specific bit of code.
The people that wrote the LiveServer extension seem to think that what port the live server runs on is one of those "per project" settings. I'd agree. You may want to run 2 or 3 live servers (e.g. a PHP web-site and another one that just does API, maybe), or the port that they chose might be in use by something completely else. So to deal with that, they create this settings file. I'd take a stab that if you edit that, then the LiveServer is going to show up on a different port.
But you can probably find the code and check it. Probably this document will tell you what to know.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
(A possibility here that I've chosen the wrong extension, but most vscode extensions are open source, so you should be able to follow the trail to a github repo, and then to either some docs or some code).
Editor settings are that border-line with source control - whether to check in or not. Lots of projects have defined editor settings, such as tabs vs spaces or linting engines. Lots don't. Possibly in this case, if you're part of a large project, the specific ports to use are defined, so it'd go into source control. If it's just you, do what feels good.
I'm using VS code (v1.74.3),Live Server (v5.7.9). There is no settings.json in .vscode folder of my JS project. Instead the settings.json is created in the folder "C:\Users\USER NAME\AppData\Roaming\Code\User" and it is a global settings file to specify extension properties. Most of the Live Server configuration settings mentioned in the documentation can be applied at global level.
Look at the below-given image of Intellij IDEA -
When we use a function it automatically provides the argument name and when we copy a code-snippet then that argument name is not copied(it is just for our reference).
I want to do the same in my vs-code editor but, I can't find any way to do it.
Looks like Inline Parameters for VSCode extension you looking for.
There is a new version of VS Code, there they had given support for Parameter hint highlight See the release notes
This feature, called "parameter hints", requires support from the language server, so whether or not this is currently supported varies from language to language.
For C++, clangd has experimental support for this (enabled by adding --inlay-hints=true to "clangd.arguments") starting from clangd 13.
I'm not familiar with the status for other languages, so will let others answer on that front.
I am using
METEOR#1.4.4.2
WebStorm#2017.1.1
Chrome#58.0.3029.110 (64-bit)
macOS Sierra 10.12.5
ecmascript#0.7.3
ecmascript-runtime#0.3.15
Recently, the debugger started to stop at wrong lines but only visually, mostly it is like 8-14 lines behind the actual breakpoint.
e.g.
*the orange bar indicates the breakpoint in google chrome
console output:
Also, as you can see, some lines are darkened, which means that I can not set a breakpoint there from the browser.
The behavior is the same within the WebStorm internal debugger. So I think it is not Chrome's fault. It looks like the source mapping is broken. I do not know if it is WebStorm, or Meteor that is the cause. Under this conditions it is very hard to debug...
It is difficult to say for sure, but it seems that the issue that you are experiencing is related to a bug that causes Meteor to generate incorrect source maps.
source maps
This is not your browser's "fault". It simply displays the code and the position that is delivered to it by the source maps in your project.
The app.js file and the source map (app.js.map) are generated by the Meteor build process and are served from the .meteor/local/build/programs/web.browser/app directory.
The .map file is responsible of telling the browser how to display the original source, and which segments in the generated app.js file are mapped to which segments in the original source code.
A great explanation about the technical aspects of source maps can be found here.
You can visualize your source maps online and see what maps where using this tool (choose custom... and drag/drop both .js and .map files.
the suspected bug
As a part of the build process, Meteor uses the babel-compiler Meteor package. At some point, a bug caused invalid maps to be produced after babel transformations.
The bug is currently tracked on GitHub and the Meteor folks seem to be closing in on the cause.
what can you do?
At the moment, there is no quick and easy fix.
You can either:
Watch the bug thread and wait for it to be resolved and debug without source maps for now (probably best, if the bug will be fixed soon).
Hack away with local clones of the relevant Meteor packages (could work, I haven't dug into the dependency issues and don't really recommend it, but here's a way of doing it).
Run Meteor from a git checkout in a known good state until a fix is released.
The last option is what #hwilson did in order to begin pinpointing the bug via a git bisect.
You can refer to the Meteor developer document for detailed information regarding the method of running the meteor tool from checkout, but the gist of the things is as follows:
First, make sure that your code, including the .meteor/versions and .meteor/packages are checked out into source control, as you will likely need to mess them up temporarily and will want to restore them once the bug is fixed.
git clone --recursive https://github.com/meteor/meteor.git to a directory of your choosing (e.g, /home/yourname/src/remote.
cd meteor.
git checkout 25a89b5 to get the last known good commit.
git submodule update --init --recursive to make sure everything is still golden after the checkout.
./meteor --help to have the checked out version start
In your project, remove the version info from the .meteor/packages file, as they will likely be incompatible with the ones offered by your checkout.
In your project dir, run /home/yourname/src/remote/meteor/meteor run.
This will run the checked out Meteor version. You may need to do a meteor reset (warning: this clears the local mongo database) or at least clean some of .meteor/local, (e.g, the source maps) for this to work, but this may be unnecessary.
This is quite a lot of effort for a bug which I assume will be resolved in the near future, but I decided to include this info partly in order to be used as documentation for future sourcemap-related issues.
It's hard to say for certain. On a cursory google search it would appear you're not the only one seeing this. As #MasterAM mentioned, it's probably because of source maps from transpilation. I don't think you can do a whole lot about it, but you can try clearing the browser and IDE caches which appears to have worked for some.
Javascript Stops at a line without a breakpoint in remote debug mode
Clearing Webstorm's cache
It is three years too late, but if somebody steel has this problem.
The problem is in the different interpretation of line separators by IDE and compiler, which generates .map files.
For example on the windows in the WebStorm and Angular-Project - the TypeScript compiler ignores line separators, if they are Unix-Style (only LF).
In this case if code formatter transforms too long line to couple of shorter lines and splits these lines by only LF, then in .map file this originally single line will be interpreted as single line, but WebStorm displays by LF separated lines as different lines.
Solution - change line separator to CR+LF and problem will be solved!
P.S. I thin this is a bug in TypeScript compiler
Not sure about this scenario but have faced a similar situation while debugging java with eclipse. It happens when the source code and the compiled/interpreted code that is being debugged - differ.
Try debugging a simple js code to validate if there is something wrong with chrome's js debugger itself. If it works, then an explanation for the lines of code not 'debug-enabled' would be that they are all on the same line (till statement that logs '7'). This could have also offset the line number in the browser.
This is one possible explanation.
I will add that sometimes the Pretty-print of the minified js file add offset in debugging mode between the real line in your code and the shifted line(do to Pretty-print).
So Avoid Pretty-print in mode debug and you will hang to the right line.
I want to run Nuint in Visual, so I set
<StartAction>Program</StartAction>
<StartProgram>$(NUNIT_PATH)\nunit.exe</StartProgram>
<StartArguments>Test.dll</StartArguments>
<StartWorkingDirectory>Test\bin\Debug</StartWorkingDirectory>
in my csproj file. But it stll does not work.
Those entries look correct for the project file. The most likely cause of the problem is that $(NUNIT_PATH) isn't properly set and hence gets evaluated to nothing. This would cause Visual Studio to look for nunit.exe in the Test\bin\Debug directory.
To test this try hard coding the full path to the nunit.exe binary into the file.
<StartProgram>C:\the\path\nunit.exe</StartProgram>
If this works then the NUNIT_PATH value isn't properly set.
Unfortunately the Express editions don't support the StartAction mechanism. See MSDN How to: Change the Start Action for Application Debugging.
I'm looking for alternatives though ;-)
Update see also SO-a/10572249/717355: Try http://www2.wealth-lab.com/Wiki/kbDebugExpress.ashx step 13 for a suggestion on making MSVC think its debugging your code directly. - Untried.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What tweaks / addins / themes do you have rigged up to make your IDE awesome? For example, in Visual Studio I color themes, CodeRush draws lines between braces, I always install and use the Consolas font and I have it setup to sync my settings across computers for when I change hotkeys and whatnot with the help of FolderShare.
Also, this isn't Visual Studio specific, please feel free to mention what you do with Emacs or Eclipse or whatnot as many of us use a few.
ReSharper 4.1 for Visual Studio 2008. It's a beautiful thing. It looks for all kinds of code errors, optimizations, etc. My code is cleaner thanks to this handy Visual Studio plugin.
Optimizing the IDE will be the first step. Resharper helps a lot but sometimes some simple macros are more than enough.
First things first. Change the font from the default crappy one. Then start fiddling with the 'Options' dialog box.
At the recommendation of a friend, I installed Visual Assist for Visual Studio 2008 -- it is awesome. I swear it can read my mind.
[Note: I have no affiliation with them -- just a very happy customer]
I've done a lot, but I really shouldn't have. So in the last few years, I've toned down the number of macros, custom key mappings, custom toolbars, etc. For the most part, I'm of the opinion that developers should get used to the default behavior and appearance of their IDE. Then when you need to work on your colleague's machine, you still know how to get around and manage to help them out. Not to mention that a whole slew of customizations will get broken or rearranged or otherwise reset when an update comes out.
That said, there are a few things that I still do every time I set up an IDE to work on... for example, setting the number of concurrent builds in Visual Studio to be 1, because that feature is so broken that nothing will compile correctly with any greater setting. Apart from that, being an ace with the default behavior will ultimately make you more efficient than spending hours tweaking the software to make it just a little more fluid.
I like CodeSmart VB6 and CodeSmart VS.NET from Axtools http://www.axtools.com/
for advanced syntax highlighting, drawing lines between parts of If..then..else..endif, Do While ... loop and all other constructs. It also has great code auditors and many add-in functions.
Vi plugin!!
I use Emacs. My .emacs file is only a few hundred lines long, but does customize settings based on my machine's hostname and operating system, so that I can use the same config file pretty much anywhere.
Colorization - Custom - White Text on GreyishBlack, Consolas Font
HotKeys - CTRL+SHIFT+ALT+Z (Attach to Process) probably some others too...
Addins - DPack, Coderush, GhostDoc.
Toolbars Off
All Windows set to collapsed
I am not doing presentations with this machine - If I was it would be barebones.
eclipse plugins make my ide exactly the way I want it of course.
eclipse plugin central
I kinda like the default setup of VS, I only make sure about Consolas as the editor font, and tabsize 2 (tabs to spaces), and change the color of numbers (red).
For Java development using Eclipse I have a few plugins that are indispensable. The MyEclipse Workbench adds a lot of functionality to most of the built-in modules. It makes it very easy to deploy an application to multiple application servers, and enhances a lot of the built-in editors. The PMD plugin is great for searching for potential code issues. As mentioned in a previous post today, the Ganymede plugin really helps to highlight log entries.
I dont care much for fancy visual addons, so I left my IDE (Visiual Studio) in the standard look (other than MS Reference Sans Serif font).
I usually change the color scheme to have a black background instead of white.
I use the Zenburn color scheme with Proggy Clean for a font. It's like a comfy chair for my eyes.
Nothing. I hate dealing with all the breakages that inevitably result from updates, etc. So, I adapt myself to my IDE instead.
I've using a combination of ViEmu and ReSharper with a dark theme.
Oh, and I also hide most of the toolbars and turn off the animations to try to speed things up.
Silver background, 8pt Consolas, disable all toolbars and set tab spacing to 3 spaces. :)
For Visual Studio
Most important - Resharper - I bought my own copy so I don't have to badger my employer about it.
Change the colourisation/font - choose whatever suits you
Optimisation (vote up Gulzar's post with the link in it)
Don't try and make the IDE do everything, just because you can. (Kind of ironic seeing I use emacs as well). I personally really dislike integrated source code management.
Change some defaut file associations so double clicking certain file types doesn't kick off Visual Studio
Aside from Resharper I've actually found most other beneficial thing is not customising the IDE, but customising yourself to learn the keyboard shortcuts. Start with the big gains like Ctrl -, Ctrl Shift -, Ctrl Shift V, Ctrl Alt L etc. etc. and then gradually learn the rest of the shortcuts in order of how often you'd use them
Rather than customizing the IDE, I customized my error messages. I have a macro that expands to a #pragma warning statement that generates a compile-time message in the same format as MSVC++. Visual Studio can parse the resulting warning, so a double-click on the message opens the offending file in the IDE and takes me right to the line in question.
I've used the macro:
To "bookmark" a section of code, so developers will be nagged to fix it each time they build.
Within #if blocks to test for various compile-time conditions.
In headers, to see who #includes them, and where.
From vim you can set the makeprg (make program) variable to a command that will build your project, and the errorformat variable to a scanf-style string that describes the format of the build errors. From there:
:make will build your project
:cl lists all of the errors that match errorformat
:cc takes to you the current error
:cn takes you to the next error
:cp takes you to the previous error.
Out of the box, vim sets makeprg and errorformat to work with make and gcc, and all of the commands are documented within vim's built-in help.
I do Java development in Eclipse. Here are some of the plug ins I find useful:
Mylyn - hides project elements not relevant to the current context.
eUML2 - UML editor.
FindBugs - Static analysis tool to find common bugs in Java.
Crap4J - Another static analysis tool.
EclEmma - Code coverage plug-in for unit tests.
Edit: I forgot one:
Disable the spellchecker. :)
In visual studio 2005 I do these:
Bind F11 to fullscreen mode
Enable a vertical line at 80 characters: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Text Editor\Guides = "RGB(196,196,196) 80" (Guides won't be present in the registry.)
Add the "Start Debugging", "Break All" and "Stop Debugging" buttons after the "Help" menu.
I am using Vim Cscope plugin.
Cscope is like 'ctags' on steroids and makes traversing code much easier.
I usually use it along with tags to find where a function is declared and then go directly to whatever code is calling this function.
I also use Vim's Rgrep plugin (recursive search) to search for files in the code hierarchy.
Create some basic macro such as printing bug fix code comments:
Public Sub WriteBugFix()
Dim TS As TextSelection = DTE.ActiveDocument.Selection
TS.Text = "'Edited for Bug Fixed By JK - " & Date.Now.ToShortDateString
End Sub
(This answer assumes the workstation is a GNU/Linux computer.)
Emacs makes an excellent IDE specifically because it can be greatly customized.
You customize Emacs by editing the .emacs file in your home directory. My .emacs is a symbolic link:
$ ln -s /home/bzimmerly/bin/emacs/emacs24/wbz.emacs.el .emacs
Since Emacs offers a variety of specialized major modes for program development and debugging, you can easily "roll your own" IDE design that works best for you. For example, when I'm programming in C or assembler, I like to have the left side running GDB mode, with the right side displaying the source being traced.
A little bit of LISP skill goes a long way to turning Emacs into a very powerful IDE. It is well worth the investment of time to learn how to use this powerful tool!
Finally, tools like Youtube are valuable places for learning how to do this. Just entering "Emacs as an IDE" on the Youtube search form will show videos of how people have modified Emacs for just such a purpose. There are videos on editing Python code, Javascript, Java, C, etc.