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.
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.
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".
The fold folding icons all appear next to the numbers on the leftmost edge. I would like them to be next to their indented guides. Is there a way to change that? I don't see anything in the settings. Is there an extension or perhaps a way I can extend my theme to do that?
I'm also already using the Guides extension and Colorize brackets, and while those are useful it would be nice to have the folding icons closer to where the actual guidelines are.
No, this is not possible as of VS Code 1.24.
If this is something that you would like to see, please file a feature request
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.