I'm trying to configure Visual Studio Code to treat tab characters in files as being 8 spaces but have indentation (when I hit tab on the keyboard) as being 4 spaces. Is this at all possible?
I can achieve this in eclipse with the code style formatter but can't achieve the same thing in VS Code.
(I've submitted an issue to the VS Code repository on git hub now https://github.com/Microsoft/vscode/issues/42643)
You need to modify your user settings (or workspace settings) in VS Code. By default, it is set a tab as 4 spaces.
You can modify the setting "editor.tabSize": 4, and set that to 8.
However, also be aware that "editor.detectIndentation": true, is set to try by default and this causes VS Code to detect the indication size of the file you open. So if the file itself has spacing set to say 4 or even 2, then VS Code will auto set spaces to that value while that file is open...or until you convert indentation.
You can convert indentation via the command palette and that should update the spacing to your desired setting.
As far as I've seen, No.
It appears that VS code still can't separate the two concepts of tab size and indentation distance. Some suggestions, ideas and hopeful soulmates of ours can be found in this issue on github: https://github.com/Microsoft/vscode/issues/5394#issuecomment-215414643
I agree with the comments in that issue in that separating the tab size from the indentation distance is a nice feature that solves several problems. The only thing needed is for someone to actually do the work to implement that in vs code.
Or, a less intrusive route, I have actually been thinking about creating an extension to override the indentation action in some way and use a custom settings variable for the indentation distance there... but I have yet to learn enough about the internals of VS code to determine if that's even possible for an extension to do.
Related
There are dimmed properties in my settings.json file. Are they dimmed because they are not being used? Can I safely remove them?
Answer:
Yes, it is safe to delete settings that have a dimmed-out color. Just to be sure you can check if you have the Git and Prettier extensions installed/uninstalled as it seems those extensions have dimmed-out settings.json file.
Reasoning:
Well in your case, and as #j D3V mentioned, you've disabled or uninstalled the git extension. This means that any settings related to or needed by the extension will be dimmed-out and are no longer required.
I was surfing the web and testing out stuff in my VSCode, and I found a setting in my settings.json file that too, was dimmed out:
The dimmed out setting is "color-highlight.markerType": "dot-before",. This is because I no longer have the extension that used this setting, the extension was named 'Color Highlight':
In the image above, you can see I no longer have the installed extension, however, I once did. Basically, the settings are dimmed-out because they were related to an extension you no longer have installed. Thus it is safe to delete them. If you keep the settings, that's perfectly fine too!
I seen this question when you first posted it, but something was odd.
So the Properties that are Dimmed, Should Be interpreted as "Unreachable by the Control-flow"
In other words, the are unnecessary, and VS Code cannot make use of them.
The editor can be configured to change how dim — or "how opaque" — the code that is "unnecessary" renders. Its a theme property that changes the dimness. I included the configuration to use in your settings.json file below.
NOTE: _The setting uses a base-16 color format, much like you often will see in CSS, or SVG, however, it must have an 8 or 4 digit hex-color as to properly set the transparency. If an eight digit number is used, the first 6 digits are ignored, if a 4 digit is used then the first 3 are ignored. Below is an example of a properly configured configuration for changing how dim "Unreachable Code" renders (aka "unnecessary code").
{
"workbench.colorCustomizations": {
"editorUnnecessaryCode.opacity": "#00000080"
}
}
Its Important to Know Why Code isn't Being Reached
These types of details should always be obvious, if not, something might be wrong, and it is worth investigating. When I first took a look at the image you included (of your settings.json file) I immediately noticed something was off. There were settings that were part of the core, fundamental features that are built-in to VS Code. The settings are contributed through "built-in extensions". The only way they could be dim, is if you disabled one or more built-in extension.
First Let me state, you should never disable VS Codes core extensions that are built-into the editor. If you do, you can't expect the official VS Code Docs to pertain to your editor, you can't expect that other questions on stack overflow will work as the authors intend for them to work, you will also loose many of the features and abilities that make VS Code such a powerful tool.
You should enable the built-in extensions that you disabled.
I have a VSCode extension that helps me autocomplete file paths, however many file paths grow long and are truncated in the VSCode intellisense popover window.
How can I set VSCode to either:
have a fixed width that I can set to be large
automatically expand to fit the intellisense options (preferable)
I happen to have written the extension so if needed I can update it if that is required.
One way around this is to press Ctrl + Space (or what ever your "Trigger suggestion" shortcut is) while the suggestion popover is open to show more detail about current selection.
So this (where I can't differentiate between the Trans imported from #lingui/macro and the one from #lingui/react):
Becomes this:
I don't think this is possible, VSCode generally gives extensions very little control over the built-in UI. See also the Restrictions section of the Extensions Capabilities Overview. Technically there is a way to hack around that, but I wouldn't necessarily recommend it.
There are also a number of settings for the suggest widget, but none of them seems to correspond directly to width. The closest you can get would be reducing the font size with "editor.suggestFontSize".
Recently when I'm launching autocomplete (a.k.a. in VS Code Intellisense) via Ctrl + Space my suggestion list is presented from the very bottom of list (note the slider position):
Usually at this place absolutely non-matching properties are placed so I have not much help from suggestions in such case. VS Code has good knowledge on shape and form of types I'm working with (it's written in TypeScript) so it's expected to present known properties as first (at top of suggestion list)
Does anyone know hot to fix such issue?
This seems to occur at random places, in approximately 70% of hits it's presenting correct list (starting from top)
Configuring the settings should solve the issue:
{
"editor.suggestSelection": "first",
"editor.snippetSuggestions": "top"
}
More about how to customize IntelliSense in Visual Studio Code: here
For my code I'm using Brackets. In editor, code looks proper but after pushing it to github repository, indentations are messed up.
I'm using tab key to make indentation but in preferences there is set "use 2 spaces" after pressing tab key.
I've find out that Github is using 8 spaces for recognised tab keys. But still, it does not give me anything.
The biggest problem is when I use "one var statement".
I've also used jsbeautifier and it doesn't help me at all.
Here you can find an example: My Github code example
Does anybody had such a problem with brackets and github indentations?
Yes I had such problems.
These problems did not reappear when we moved to eslint inside of our IDE. The setup varies for each IDE. You can refer https://eslint.org/docs/rules/indent
If setting eslint is hard for you. Try bracket extensions like https://github.com/brackets-beautify/brackets-beautify . When used correctly it will beautify on save. Caution: Dont beautify code written by others or a team.
I use Dreamweaver at work and NetBeans IDE at home, but in both cases project is stored at github. My problem is that NetBeans seems to be constructing code indenting out of spaces and when opened in dreamweaver or exported to github, indenting here and there breaks (moves unexpectedly further then it was intended or vice versa), although when opened again in NetBeans, goes back to normal. It has been pain for some time already. Is there any resolution to this?
I should say that we at work (and me including) prefer tab indenting.
It depends on the IDE's definition of a TAB. There are usually options within the IDE to indent using a TAB but turn the TAB into a given number of SPACES. I usually indent using TAB but have the IDE turn that into 3 SPACES. This means that it doesn't matter what I (or anyone else) use to read my code later the indets are always the same.
In NetBeans you need to look in the Code Editor options but I have no idea where to find the settings in Dreamweaver.
Its been known that one should use double space rather than tab, because that fact that different IDEs define how the tab button works DIFFERENTLY.
For example, emberjs team require contributor to use double-space rather than tab for formatting the code.
It make sense that to use something recognized in common without an IDE, so that the code structure will not be a problem in a highly collaborated coding team environment.
HOWEVER, if customization of how a tab works in an IDE is enabled, tab will be a great time saver in this case-- Press twice the button cost 200% of the time to press one obviously :)
Hope that helps!