Where I can find good documentation for every available settings.json configuration option so I can configure VS code however I like to?
There isn't an official maintained list of everything, but you can find some guides in the VS Code Documentation.
For theme color reference, you can see the list at Theme Color documentation.
The closest to what you want may be pressing Ctrl+, (or by using the gear menu in the bottom left), you can open a GUI that will show all configurable settings and allow you to search them. For some things, it will tell you to edit it in the settings.json instead, though. In which case, you may need to to look at the documentation for usage instructions.
Related
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.
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.
When I right click in the editor, vs code executes whatever menu item the cursor happens to be over. It happens far too fast for me to make my actual choice known.
I have already spent 30 minutes trying to find a solution. If you search for "right click" in the Command Palette, you are told there are no matches. You don't get any hits in the docs, either. Please advise. Thank you.
It has been reported that the situation you mentioned is a bug in the repository on GitHub. It is reported that Visual Studio Code works fine when zoom is disabled.
You can update the following setting to override this behavior:
"editor.mouseWheelZoom": false
Or you can update the mouseWheelZoom setting from the pop-up window by using the shortcut CTRL + , to go to Settings.
It's crazy, but this is still an issue for Linux users after so many years. Especially, when using a Laptop with touch-pad it makes VSCode frustrating to use. The problem occurs when you use "native" window style (you can tell, because the theme will not be applied to context menus) and have a non-default zoom.
The GitHub issue that #sercan linked to has a few solutions. In order to save you some time, there is basically two things that I found work and make sense:
Set your zoom level to default / 0. In settings.json add: "window.zoomLevel": 0 This works with all window styles, but obviously is not always viable
Change the title bar style from native to custom. In settings.json add: "window.titleBarStyle": "custom" This will change how the title bar but also the context menus look. Setting this, you can zoom in again
When I'm opening settings using Preferences: Open Settings (JSON) I'm getting screen like this:
But in VSCode videos/tutorials I see people somehow have splitted window, with default settings on the left and user/workspace setting on the right:
How I can enable it?
===========================
EDIT:
I found "workbench.settings.openDefaultSettings" option and set it to true, but still my UI is different from desired on screenshot above ( I don't see search box for searching settings, also I don't see the message Place your settings in the right ... to override):
As mentioned #Juraj Kocan in comments, it happens after last VS Code updates.
This is Github issue related to this new "feature"
This one helped me:
"workbench.settings.useSplitJSON": true,
"workbench.settings.editor": "json",
How to Get to the JSON settings in Newer Versions of VS Code
In the latest versions of VS Code, you can convert back to the split JSON settings editor by changing the following settings in the (now standard) UI settings editor:
Workbench > Settings: Editor
Change from UI to json
Workbench > Settings: Use Split JSON
Checkmark to enable the option
after making this change, VS Code will open its settings as a JSON file, like in older versions of the application, rather than in the new UI. This allows you to make the changes that other answers provide, directly in the JSON (if you can find the right place and file to make them in..)
NOTE: Whether or not you actually want to use the JSON settings is a different question. Most of the time, the settings search function allows finding the same settings in the new UI. Sometimes it is difficult to get search to work though, especially if the settings are worded differently in the new UI style. There may also be cases where extensions haven't been updated to accommodate the new UI setting style, and so there is no option but to enter the JSON directly.
Not sure what do you mean by "Default".
steps to open setting by keyboard are:
press Ctrl+p (an input command line would appear at the top.)
press >
A List will appear like that in image. (search preference for all vs code settings)
In the terminal when I try to use emacs the colors are not good, most of the times I can't properly see the text.
In vim I know I can change the colorscheme with :colo <colorscheme_name>
Is there something similar in emacs?
A tutorial on the proper steps to change the colors would be appreciated.
I'm not sure of tutorial, but off top of my head, what you probably will want to do is: M-x customize then navigate to the section called "Faces" - you'll get a bunch of settings related to the color scheme and other font-related settings.
But Emacs has tons of customizations related to how text is displayed. I'm using this http://www.nongnu.org/color-theme/ but you can find a lot of info here: http://emacswiki.org/emacs/ColorTheme (emacswiki is basically the resource to be consulted first when you have any Emacs-related problem).
Obviously, you can do that in your .emacs file by adding different settings, but I'd suggest to use what's generated by the changed settings first, see how it works and then add on top of that yourself (once you modify settings from the customization buffer, it will save the changes into .emacs file - you can then open it and see what exactly did it do).
M-x load-theme
then use arrows to select a theme.
Adding here for easy reference ( #deong shared this answer via comment under the accepted answer).