can I remove dimmed-colored properties in settings.json file in VSCode? - visual-studio-code

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.

Related

How can I easily toggle display of problem underlining in VS Code editor panels?

I'm using VS Code with a number of different programming languages, which all have some form of problem validation provided via an extension. While these problem underlines are generally useful, I find them very annoying while I'm writing a particular piece of code, and only useful once I'm mostly done typing. I often think while writing code and I also tend to hit Ctrl+S very often, so there is no way that my IDE can "debounce" properly, as it wouldn't be able to tell if I'm done writing code or not.
How can I disable all lints from being displayed, regardless of the programming language used, until I re-enable them (or restart Code or whatever)?
I'm not looking for a always-hidden solution that permanently changes my settings. More for something that I can toggle with a keyboard shortcut or similar.
While I am most interested in a solution that works regardless of where the lints come from, the two extensions that'd be responsible for most of my lints are rust-analyzer and Kotlin, but I also have clangd and TexLab installed and also use TypeScript whenever I can't avoid it but currently I don't have any extension for it installed.
I don't think the exact thing you are looking for exists at the time of this writing.
I am not aware of any "global" (programming-language-agnostic) setting that toggles showing underlines for problems in the editor view. There is a setting that toggles showing decorations for problems in the files/folders view (problems.decorations.enabled), but that's not what you're looking for.
As shown by the answers to How to disable error highlighting in VS Code?, there are settings on a per-language basis to disable validation (such as css.validate, php.validate.enable, html.validate.*, json.validate.enable, etc. Note that language extensions may not follow that pattern of naming their settings fields)
In terms of getting a keyboard shortcut to toggle such a setting (whether the currently-non-existent-(I-think) programming-language-agnostic setting, or an individual programming-language-specific setting), see this Q&A: VSCode: Keyboard shortcuts for modifying user settings, where #matt-bierner points to the rebornix.toggle extension, which allows configuring keyboard shortcuts to toggle individual bi-state settings fields.
As for feature-requests and possible future features to VS Code, see this issue on the VS Code GitHub repo: Toggle problem visibility in Editor #166797. You can show your support for the feature reuqest by giving a thumbs up reaction to the issue. But please don't make a "me too" comment. "me too" comments generally come off as annoying to repo maintainers because they clutter up discussion and don't contribute anything of significant value.
Override theme colors in settings.json
{
"workbench.colorCustomizations": {
"[Visual Studio Light]": {
"editorError.foreground": "#00000000"
},
"editorError.foreground": "#00ff00"
}
}
will make errors transparent while using "Visual Studio Light" theme
and lightgreen while using any other theme, for example
Source: https://youtu.be/vR2y4VoCZg4?t=97
with the extension When File you can make the squiggles transparent when the file is dirty.
Add this to your settings.json file (global or workspace/folder)
"whenFile.change": {
"whenDirty": {
"editorError.foreground": "#ff000020",
"editorWarning.foreground": "#ff000020",
"editorInfo.foreground": "#ff000020"
}
}
File add a new line css. Lint dot empty rules and assign the value of ignore.

How to put tap space in my code while using prettier in vscode

Prettier is useful in most times. But, sometimes I want to put tap space in my code for enhanced reading of the code. Is there any way for put tap space in my code intentionally while using Prettier?
I think you mean tab spaces with a b not a p. if that's correct, then no, in general prettier does not allow for discretionary tabs, because it is what is known as an opinionated formatter, meaning that it has its own opinions about the way code should look.
If you want more control over your formatting, you can uninstall prettier and choose a different formatting extension instead, like beautify - or even just use the built-in VS code language features, which provide formatting and are fairly customizable.
In the settings section of VS code, you can search for terms like tab and white space to customize the behavior.

How to make VSCode Intellisense window wider

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".

VS Code terminal colors are screwy

I'm using the default theme. The terminal's colors are impossible to read, make no sense, and are inconsistent. I've tried switching themes but they're terrible in all the themes.
Here's what it looks like in the default. Are you able to read my yellow input against the gray background? And why isn't there a black background everywhere?
I realize there are settings that can manually set the fore/background colors. But I'm thinking something is broken for me because of how screwy the terminal behaves.
For example, here's what I see when I first start the terminal, type a bunch of stuff, backspace to delete half of it, resize the terminal pane, then delete some more. Notice how some of the deleted spaces have yellow and some have gray. Also notice how the area where the CWD would be shown is all black.
Here are the contents of my settings.json file:
{
"window.zoomLevel": 0,
"git.enableSmartCommit": true,
"workbench.startupEditor": "newUntitledFile"
}
What needs fixing, and how?
Edit:
Just to satisfy your curiosity, I added this to my settings.json file:
"workbench.colorCustomizations": {
"terminal.foreground": "#ffffff",
"terminal.background": "#000000"
}
No joy:
There might be something wrong in your console settings, you might want to remove the content of HKCU\Console in your registry. Save it before, obviously, but there shouldn't be any side effect: it'll just be recreated with the default settings.
Okay, so here's a list of all possible settings that you could tweak in your terminal window colorscheme: (source)
"workbench.colorCustomizations": {
"terminal.background":"#1D2021",
"terminal.foreground":"#A89984",
"terminalCursor.background":"#A89984",
"terminalCursor.foreground":"#A89984",
"terminal.ansiBlack":"#1D2021",
"terminal.ansiBlue":"#0D6678",
"terminal.ansiBrightBlack":"#665C54",
"terminal.ansiBrightBlue":"#0D6678",
"terminal.ansiBrightCyan":"#8BA59B",
"terminal.ansiBrightGreen":"#95C085",
"terminal.ansiBrightMagenta":"#8F4673",
"terminal.ansiBrightRed":"#FB543F",
"terminal.ansiBrightWhite":"#FDF4C1",
"terminal.ansiBrightYellow":"#FAC03B",
"terminal.ansiCyan":"#8BA59B",
"terminal.ansiGreen":"#95C085",
"terminal.ansiMagenta":"#8F4673",
"terminal.ansiRed":"#FB543F",
"terminal.ansiWhite":"#A89984",
"terminal.ansiYellow":"#FAC03B"
}
Now for me, the colors of folder names was too bright over an even brighter background color that highlighted them and I couldn't read squat (that's because of my VSCode theme called NightOwl -- :P Sarah) so I thought (wrongly) to change terminal.background and terminal.foreground properties but that refer to the entire rendered window of the terminal.
Because these properties are actually named after Ansi Escape Codes, what I was actually looking for were these properties: terminal.ansiBlue for folder name text color and terminal.ansiGreen for folder name background highlight color.
As soon as I tweaked those, my terminal was good to go.
The way to do it is to just set all these settings and start removing or changing them to see which is which for your preference. K Thx Bye
Also beware that terminal.ansiGreen is used by git diff as a color to show additions.
On March 8th 2022 the default value for the integrated terminal "minimum contrast ratio" was updated from 1 (no effect) to 4.5 (minimal effect). Depending on your color settings and what is being displayed, this can cause your integrated terminal foreground colors to be wrong.
To disable this feature, override the default in your own settings.json file:
"terminal.integrated.minimumContrastRatio": 1
There are two solutions. Xavier's solution works, and mklement0's comment was also correct.
Solution #1
Do what Xavier said (and upvote his answer).
But, if you don't want to mess up registry settings (or if, like me, you have lots of registry settings nestled under the HKCU\Console root), then...
Solution #2
Get Windows 10 build number 18309 (or newer)
Join the Windows Insider Program
Make sure you're on a "ring" that includes a new-enough build. For me at this moment that meant joining the "fast" ring
Wait forever for updates to finish installing
Add "terminal.integrated.windowsEnableConpty": true to your settings.json
Restart terminals
Upvote mklement0's comment
...
Profit!
I am new to VS Code (and I'm trying to better my PowerShell skills) and have/had this same problem. Deleting all the Reg keys cited above related to colors seemed to fix it, but I believe the root problem is that VS Code seems to be trying to honor the color scheme set up outside the VS Code Terminal itself, from the shell. Really annoying and I'm not sure how to separate the two.
I had setup a blue background/yellow font scheme in PS prior to installing VS Code. That was the same color scheme the terminal in VS Code was displaying directly around the text.

Is it possible to seperate tab and indentation configuration in Visual Studio Code?

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.