Installed Prettier. Want to set preferences to format on paste and save but getting error message - unable to write into user settings. Please open the user settings to correct errors/warnings in it and try again.
To format prettier I went into the extension, typed in format and tried to select Format on paste and format on save. That's when the error message appeared. When I check settings, I see this:
"editor.formatOnPaste": true,
"editor.formatOnSave": true,
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[html]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
What can I do?
Follow the steps it might help you:
Open the user settings file by going to Preferences > Settings in the VS Code editor, or by pressing the keyboard shortcut Ctrl+ (on Windows) or Cmd+ (on Mac).
In the Settings editor, find the section for "editor.formatOnPaste" and "editor.formatOnSave". Make sure that these settings are set to true, like this:
"editor.formatOnPaste": true,
"editor.formatOnSave": true,
Check the rest of the file for any syntax errors or warnings. In your case, it looks like there is an extra comma at the end of the "[jsonc]" and "[html]" sections, which is causing the error. Remove the extra comma, and make sure that the file is properly formatted and indented.
Save the changes to the file, and try setting the formatting options again.
This should work now that the syntax errors have been fixed.
Sublime Text - spell check does not work for .txt files (while working for other files).
Why? How to fix? Any ideas?
Also: in a new file (not yet saved) the spell check works. However, after the file is saved as .txt, the spell check does not work. Unexpected. Why? How to fix?
The Preferences.sublime-settings has:
"spell_check": true,
and nothing special for .txt files.
Sublime Text, Build 4126.
UPD. In safe mode:
Here we see that in helloe.bash the helloe is not spell-checked. Why?
The Bash.sublime-settings has:
// These settings override both User and Default settings for the Bash syntax
{
}
UPD2. After adding "spell_check": true in Bash.sublime-settings the helloe is still not spell-checked. Any ideas why?
Multiple things to check:
Check how .txt files are syntax-highlighted. In my case .txt files are syntax-highlighted as .bash files (it is needed by some reason).
If .txt files are syntax-highlighted as .bash files, then helloe is a variable name, which is not spell checked by default. As user #OdatNurd said:
spell_check controls weather or not spell checking is turned on or not, but spelling_selector determines what text is actually spell checked. Specifically, in source code files it's basically strings and comments. In your example the text is a variable name. If you want to alter that, you need to alter the spelling_selector too.
While trying to setup a dropbox folder with git, I saw a "Icon\r" file which is not created by me. I try to ignore it in the ~/.gitignore file. But adding Icon\r Icon\r\r Icon? won't work at all.
You can use vim as well.
vim .gitignore
in a new line write Icon, then
press ctrl+v and then press Enter
repeat step 3
save and exit (shortcut: ZZ)
Now you should have Icon^M^M and it's done :)
For a smarter use you could add it to your gitignore global config file in ~/.gitignore_global.
(This improves on the original answer, following a suggestion by robotspacer, according to hidn's explanation.)
The Icon? is the file of OS X folder icon. The "?" is a special character for double carriage return (\r\r).
To tell git to ignore it, open a terminal and navigate to your repository folder. Then type:
printf "Icon\r\r" >> .gitignore
If the file does not exist, it will be created and Icon\r\r will be its one line. If the file does exist, the line Icon\r\r will be appended to it.
"Icon[\r]" is probably a better alternative.
In vim, you just put Icon[^M], which is Icon[ followed by CtrlV, Enter then ].
The problem with "Icon\r\r" is EOL conversion.
The whole line is actually "Icon\r\r\n", counting line ending. Based on your setup, CRLF may be converted to LF on commit, so your repo will actually have "Icon\r\n". Say you sync the changes to another repo. You will get "Icon\r\n" in that working directory, which ignores Icon but not Icon^M. If you further edit .gitignore and commit it there, you will end up with "Icon\n" - completely losing \r.
I encountered this in a project where some develop on OS X while some on Windows. By using brackets to separate \r and the line ending, I don't have to repeat \r twice and I don't worry about EOL conversion.
The best place for this is in your global gitignore configuration file. You can create this file, access it, and then edit per the following steps:
>> git config --global core.excludesfile ~/.gitignore_global
>> vim ~/.gitignore_global
press i to enter insert mode
type Icon on a new line
while on the same line, ctrl + v, enter, ctrl + v, enter
press esc, then shift + ; then type wq then hit enter
Regarding Naming (and Quoting) Things: First, more people would benefit by knowing that ANSI-C Quoting can be used to unambiguously match the macOS icon file. Both Icon$'\r' or $'Icon\r' and work in Bash and Zsh and most other modern shells, I hope, such as Fish.
Keep Your .gitignore Editable: While I'm impressed by the byte-level manipulation offered by other answers here, these methods are brittle in practice. Simply put, programmers tend to use text editors, and many of these editors are configured to alter line endings when saving a file. (For example, see this VS Code discussion about line ending normalization.)
Do you want your careful byte editing undone by your editor? Of course not. So perhaps you find it practical and convenient to configure your editor so that it doesn't affect line endings. You might look into (a) editor-specific configuration settings; or (b) cross-editor configuration (i.e. EditorConfig).
But this gets complex and messy. If want a simpler, more flexible way, use this in your .gitignore file:
# .gitignore
Icon?
![iI]con[_a-zA-Z0-9]
Explanation for the patterns:
Use Icon? because the gitignore format does not support \r as an escape code.
Use [iI] because Git can be case sensitive.
Use [_a-zA-Z0-9] to catch many common ASCII characters; you may want to broaden this.
You can test that your gitignore patterns are working as expected with:
git check-ignore -v *
For example, for testing, with these files in a directory:
-rw-r--r--# Icon?
-rw-r--r-- icon8
drwxr-xr-x icons
-rw-r--r-- iconography
... the result of git check-ignore -v * is:
/Users/abc/.gitignore:3:Icon? "Icon\r"
/Users/abc/.gitignore:4:![iI]con[_a-zA-Z0-9] icon_
/Users/abc/.gitignore:4:![iI]con[_a-zA-Z0-9] icons
This is what you want.
Long Term Recommendation This problem would be trivial to fix if Git supported the \r escape in .gitconfig files. One could simply write:
# .gitignore
Icon[\r]
So I suggest we engage with the Git community and try to make this happen.
(If you do want to wade in and suggest a patch to Git, be sure to read first.)
References
From the gitignore documentation:
Otherwise, Git treats the pattern as a shell glob: "*" matches anything except "/", "?" matches any one character except "/" and "[]" matches one character in a selected range. See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.
Please see This linuxize.com article for good examples of the square bracket syntax and negation syntax in .gitignore files.
For those that want to dig deep and see how pattern matching has changed over time in the Git source code, you can run this search for uses of fnmatch in the git repository on GitHub.
The Icon? is the file of OSX folder icon. It turn out that \r is actually CRLF. So I use ruby to add the line to .gitignore file. Open terminal and navigate to home folder, then:
> irb
>> f = File.open(".gitignore", "a+") #<File:.gitignore>
>> f.write("Icon\r\r") # output a integer
>> f.close
>> exit
For me this worked in TextMate: Icon<CR><CR>. The <CR> is a carriage return character, which is at ctrl-alt-return on the keyboard. You can also find it in the standard Character Viewer app searching for cr. Please note that the <CR> is an invisible character, so it's only visible if the editor is set up to show them.
I'm posting just an update answer because the one above didn't work for me but actually simply adding Icon? in my .gitignore worked. If you look at your name file on your Finder, it is actually how it is displayed.
Icon[\r] did not work for me. I had to use the following in .gitignore...
Icon*
I also added Icon* to my Settings > Core > Ignored Names in Atom...
.git, .hg, .svn, .DS_Store, ._*, Thumbs.db, desktop.inis, Icon*
Add Icon? to your .gitignore file and save it. It should do the job.
Icon?
To avoid wasting time on such trivial issues, I recommend using gibo.
gibo dump macOS >> .gitignore
The result:
### Generated by gibo (https://github.com/simonwhitaker/gibo)
### https://raw.github.com/github/gitignore/e5323759e387ba347a9d50f8b0ddd16502eb71d4/Global/macOS.gitignore
# General
.DS_Store
.AppleDouble
.LSOverride
# Icon must end with two \r
Icon
# Thumbnails
._*
# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk
Is there a way to set a default document type when saving a NEW FILE?
I created several new files and I want to have a default value of .txt when saving a NEW FILE.
Create a new plugin Tools > Developer > New Plugin...
Paste this in:
import sublime, sublime_plugin
class EverythingIsPowerShell(sublime_plugin.EventListener):
def on_new(self, view):
view.set_syntax_file('Packages/PowerShell/Support/PowershellSyntax.tmLanguage')
Save and call it NewTabSyntax.py. New tabs will now default to Powershell.
You can change the syntax to whatever you prefer. To find out the "path" of a particular syntax, simply open a file of that syntax, open the console (View > Show Console) and type:
view.settings().get('syntax')
This plugin does it:
https://github.com/spadgos/sublime-DefaultFileType
seems pretty great.
Edit:
Ok, two things, there currently seems to be a small bug so the text file syntax is not being correctly picked up due to the whitespace in the filename. In addition you need to set the "use_current_file_syntax" to false, (otherwise the new file will default to whatever filetype you have open already when you hit Ctrl-N)... So the fix/workaround is this:
Put the following code in: Packages/User/default_file_type.sublime-settings
{ "default_new_file_syntax": "Packages/Text/Plain_text.tmLanguage",
"use_current_file_syntax": false }
NOTE THE UNDERSCORE.
Next, find the "Plain text.tmLanguage" file and copy and rename it (in the same folder) as "Plain_text.tmLanguage". [be sure to copy/duplicate it, do not just rename it, as it may have dependancies]
Restart, just to be sure, and this should do the trick.
Also note this plugin only works for new files created with Ctrl-N.
Working after these steps:
1.Uninstalled
2.Installed using Package Control
3.Test using default install (type Jave) <-- worked
4.Copy and Renamed file Sublime Text 2\Packages\Text\Plain text.tmLanguage > Sublime Text 2\Packages\Text\Plain_text.tmLanguage
5.Changed file Sublime Text 2\Packages\Default File Type\default_file_type.sublime-settings >
`{ "default_new_file_syntax": "Packages/Text/Plain_text.tmLanguage", "use_current_file_syntax": true }`
-- All working.
I did not need to copy any files into the 'Packages/User' folder
#fraxel _ Thanks for all the help and quick response.
If I try to autocomplete smth in a Ruby file, that has require 'xxx' statement, it starts to scan all files required (and files required by required files as well). and it does that every freakin time!
Is it possible to make vim autocomplete to NOT scan required files or just files in particular path (e.g. app/ only)?
One of the following should work
:set path=.,/myinclude1,/myinclude2 to set your own include path
:set complete-=i to disable use of included files in default completion
:set include= to unset the include file matching pattern
I would suggest you use the second one, so CTRL-X CTRL-I will still work correctly