When I run a build e.g. of an Angular app in the vscode terminal and I get a bunch of errors, I would like to quickly go through each, fix it and move to the next. Currently I have to scroll through the list without being sure of what has already been fixed or not. I am thinking either a collapsible view (i.e. collapse build errors which have already been fixed) or a way to split/group the errors in sections and move from one to the next would be ideal.
Is there a way or an extension to do this?
Related
Recently VSCode is showing an animated line, that moves constantly from the left to the right. The movement is distracting when I am trying to code.
What is the line, and how can I disable it?
This is because it's "loading" something in the background.
Display the Ouptut console shiftcmd/ctrlu (or: View > Output) and on the right, in a selectable list, check the different tasks or logs to see what process is still pending.
Sometimes it's a plugin which is stuck, or a wrong configuration of your project.
It could also simply be a bug in VSCode.
Does anyone know what the blue moving line (from left to right) in Visual Studio Code means?
It appears relatively often, especially when reactivating from hibernation mode. Looks like some background processes are currently active.
Once the bar shows, it doesn't go away until I restart the program.
It should be possible to make it transparent:
Put this into settings.json:
"workbench.colorCustomizations": {
"progressBar.background": "#fff0",
}
This occurs because when you try to find some file or functions which are not available, VsCode continues to keep trying to get that function and redirect cursor over there. So the loader stays there forever. The solution is to make VsCode look for something which it can find.
Just ctrl+click on any function which is available. Also you can ctrl+click on function where it is defined itself so it will directly point on it and loader will be removed.
For example you have below function
public function GetUSer(){
}
So just ctrl+click on GetUser and the loader will vanish.
No need to restart VsCode
Edit for js users :
Let say you have defined a variable :
var userName = 'Test';
And you have used it somewhere in the code
var userNameLength = userName.length
So just ctrl+click on userName where we get the length. It will go to defination (where the variable is defined) and the progress bar will be gone.
Like previous answer said it is a loading indicator which occurs when vscode is attempting to look something up like a function definition or trying to lint.
You cannot hide it that I am aware of but you can get it to go away obviously by relaunching vscode. It is also limited to the current editor window so you can split your editor and then close the one with the indicator.
That is a loading indicator. It happens when something is loading or is in process. It might be constantly refreshing the file tree because of changes in the directory
With VSCode 1.52 (Nov. 2020), that moving bar should be more explicit (and cancellable!)
Progress for long running operations in Explorer
We now show progress in the Explorer and Status bar for long running File operations (longer than 500ms).
There is also an inital support for cancelling these long running operations.
This should be particularly helpful when copying large folders or downloading resources from remote.
(Click on the picture to enlarge)
Perform the below changes in Visual Studio Code preferences settings
Disable Auto update
Disable Auto update of extensions
Disable error reporting service
My project contains a LOT of folders, many of which I routinely have open, making for a lengthy explorer view. I find scrolling this view quite frustrating for two reasons:
There is no equivalent of the editor.mouseWheelScrollSensitivity setting for the explorer view. I'm also generally happy with the scroll speed for my mouse in other applications, so don't want to go messing with a system wide setting to compensate for VSC.
The scrollbar is frustratingly difficult to grab at and requires precise mouse placement. The number of times I accidentally grab at the slider and resize the view rather than scroll it is ridiculous.
I've found no useful extension to help in this matter. Has anybody any suggestions? I'll raise an enhancement request in Github if necessary.
Here are 2 shortcuts that can speed up navigation between files:
With Ctrl then Tab you can browse a history of your last viewed files. Great for switching around when working on multiple files.
With Ctrl+P (Go to File... command) you can quickly go to a file by name. You can also search for files inside folders like this: folder/subfolder/file.ext. This is great if you know what you are looking for.
Source and more navigation tips: https://code.visualstudio.com/docs/editor/editingevolved#_quick-file-navigation
This PR in vscode 1.59 may have fixed this issue: https://github.com/microsoft/vscode/pull/110059/commits/61efc577e038ac772f12511fb823de27296dbc69
New settings:
workbench.list.mouseWheelScrollSensitivity
workbench.list.fastScrollSensitivity
I have been working on my project when suddenly I have not compiled anymore, it stays waiting in Compile swift source files ... I cleaned the project, the folder, deleted the app and nothing. Is there any way to know what is happening?
Is there any way to know what is happening?
Yes. Go into the Report Navigator which is the one selected by the little speech bubble at the top right of the navigator pane. It will give you a list of all the actions you have performed like builds and tests and runs. The current build will be at the top of the pane. Click on it.
In the main editor you will see some buttons at the top and maybe some messages. Click the All Messages button and it will show you a tree view of the current build. The bottom line will be what the build system is doing now. If it is not changing (i.e. new lines appearing) the build is stuck.
Almost certainly the bottom line will be something like Compile SomeFile.swift. Assuming it is, you can now triage the problem. The Swift compiler usually gets stuck on inferring types for complicated expressions. The way to triage this is to comment out the entire file and then add lines back until the problem reappears. Make sure that you always add enough back so that the file compiles without error.
Obviously, the last line you added back will be the one causing the problem. Usually it's an expression that concatenates strings together with non strings that causes the problem.
The problem is in dictionary [String:Any] when I change the dictionary to [String:String] the problem is resolved . Is very strange..
I'm facing a wierd problem. My eclipse, has a google signin button which is occupying some of the space which I do not want to happen. Initially it had "Sign-in to Google" text along with it. I've followed some blog post and set accordingly to show just the icon (I don't remember that blog post link).
But now, the icon is getting replicating .. it is being shown 12 times. It is actually creating childs :P
I've gone through all the options present in Customize Perspective menu, none of them had this button listed. Can someone help me in removing that google sign button from my perspective? One possible suspect is- my eclipse crashes when I suspend and wakeup my machine.
You can use the Window > Reset Perspective... menu command to reset the perspective to its default state, which might eliminate that toolbar and buttons. If that fails, I would create a new workspace and import the projects into it using File > Import > Existing Projects into Workspace.
If you want to try to salvage your existing workspace, it's possible to do so my manually editing Eclipse's internal file that stores your Workbench layout, but it's a bit tricky. Here are the steps I've followed to eliminate a similar repeated toolbar item:
Exit Eclipse.
Find the Workbench layout file, it's path is <workbench>\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi. Make a backup of this file before you touch it - this is essential because it's easy to corrupt the file if you change the wrong things.
Open the file in your favorite XML-aware editor - most packages of Eclipse include the XML editor that works just fine1, but be aware that if you use Eclipse to edit the file you can't have Eclipse open on the workspace that contains the workbench.xmi you want to edit.
Find the section of <trimBars> nodes in the XML; from there you have to determine which <trimBars> node you need to edit. In your case it looks like a vertical one, probably with a side="Right" attribute.
Under the correct <trimBars> node you'll find multiple <chlidren> nodes, each with an elementId attribute that should help you identify it; you're looking for <children> nodes that are identified as something related to the Google plugin.
Delete the <children> nodes that seem related to the unwanted toolbar buttons. In your case, it appears that there is an entire toolbar that you might want to eliminate, so you might want to delete the entire containing <trimBars> node.
Save the file and start Eclipse on that workspace.
1Some packages of Eclipse include EMF tools that will open it in a special XMI editor that does not provide a view of the source, only a structural tree view. Depending on how you like to work with XML, this might be easier than editing raw XML.
This is not a perspective but a view. You can hover over that bar with the buttons and click Alt+Shift+F1 to check where this View comes from. Then you can either disable/uninstall the contributing feature (Help -> Installation Details) or check where the feature came from.
If it comes from the IDE, you can open a bug for it. If it is contributed from a third party plugin, contact the developers of that plugin.
There is an eclipse bug concerning duplicate view toolbar buttons in Luna that has recently closed as well. Maybe this solves your problem as well.
Edit: Taken from this bug:
root cause is that in Luna 4.4M5 WorkbenchWindowControlContribution.createControl is called twice, the
first time with a null value for
WorkbenchWindowControlContribution.getWorkbenchWindow() while it is
still being created. This is related to what has been reported here
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427452
second cause is that my createControl(Composite parent) method was calling PlatformUI.getWorkbench().getActiveWorkbenchWindow() instead
of WorkbenchWindowControlContribution.getWorkbenchWindow(). This
resulted in an attempt to create a new Workbench Window, which
recursively calls createControl() again. This has already been
reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=366708