Change color of Vim error message when .swp file exists

Question

This is a really minor thing but it keeps bugging me. Whenever I try to open foo.txt if a .foo.txt.swp file exists, the error message that shows up displays in a color that painfully clashes with my background color as seen below:

Playing with colors in my Terminal.app preferences didn't change this color. How do I change this color?

Answer 1

This is using the MoreMsg highlighting group, so in your colorscheme, you want to tweak this highlighting option.

Answer 2

You can change the color by changing the colorscheme you are using.

There are probably many entries on the file defining your colorscheme, but you can find which one you should change by executing :highlight, which will list all current highlight groups and how they are displayed. Just look for the one that hurts your eyes and change it.

If you are using a colorscheme that comes bundled with vim you could follow the instructions at :help 6.3:

You could also write your own color scheme.  This is how you do it:

1. Select a color scheme that comes close.  Copy this file to your own Vim
   directory.  For Unix, this should work:

    !mkdir ~/.vim/colors
    !cp $VIMRUNTIME/colors/morning.vim ~/.vim/colors/mine.vim

   This is done from Vim, because it knows the value of $VIMRUNTIME.

---

Edit:

When I run :highlight none of the colors match the one I don't like, including the MoreMsg highlighting group. Nothing changes when I put the line hi MoreMsg term=bold ctermfg=black gui=bold guifg=black in ~/.vim/colors/mine.vim.

This is really unexpected. Try restarting Vim or issuing :colorscheme mine to ensure that your changes are being read.

The colors are usually defined by the colorscheme, but there is a chance that some plugin you are using is overwriting the highlight group.

At first you should check if the colorscheme is indeed the culprit. Try commenting all the lines on the current colorscheme and then restart Vim. If nothing changes you could also try changing the colorscheme and check if the color of the message changes.

If the problem persists, you should follow the procedure described on Vim-FAQ 2.5. Some relevant parts follows:

2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a problem with my setup or with Vim? / Have I found a bug in Vim?

First, you need to find out, whether the error is in the actual runtime files or any plugin that is distributed with Vim or whether it is a simple side effect of any configuration option from your .vimrc or .gvimrc. So first, start vim like this:

vim -u NONE -U NONE -N -i NONE

this starts Vim in nocompatible mode (-N), without reading your viminfo file (-i NONE), without reading any configuration file (-u NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc file) or even plugin.

If the error does not occur when starting Vim this way, then the problem is either related to some plugin of yours or some setting in one of your local setup files. You need to find out, what triggers the error, you try starting Vim this way:

vim -u NONE -U NONE -N

If the error occurs, the problem is your .viminfo file. Simply delete the viminfo file then. If the error does not occur, try:

vim -u ~/.vimrc --noplugin -N -i NONE

This will simply use your .vimrc as configuration file, but not load any plugins. If the error occurs this time, the error is possibly caused by some configuration option inside your .vimrc file. Depending on the length of your vimrc file, it can be quite hard to trace the origin within that file.

The best way is to add :finish command in the middle of your .vimrc. Then restart again using the same command line. If the error still occurs, the bug must be caused because of a setting in the first half of your .vimrc. If it doesn't happen, the problematic setting must be in the second half of your .vimrc. So move the :finish command to the middle of that half, of which you know that triggers the error and move your way along, until you find the problematic option. If your .vimrc is 350 lines long, you need at a maximum 9 tries to find the offending line (in practise, this can often be further reduced, since often lines depend on each other).

If the problem does not occur, when only loading your .vimrc file, the error must be caused by a plugin or another runtime file (indent autoload or syntax script). Check the output of the :scriptnames command to see what files have been loaded and for each one try to disable each one by one and see which one triggers the bug. Often files that are loaded by vim, have a simple configuration variable to disable them, but you need to check inside each file separately.

If your problem still occurs when using vim -u NONE -U NONE -N -i NONE then you could check if it is specific to your terminal by trying to reproduce it on another type of terminal (xterm, urxvt, etc).

Answer 3

I was able to solve this exact same issue by editing my "my_custom_color_file.vim" file and commenting out the "hi clear" line near the top. I don't know at all why this fixed it, but it seems to not impact any of the colors that show up in ":so $VIMRUNTIME/syntax/hitest.vim", at least.

If anyone wants to suggest a better fix, please do. My setup includes bg=dark, and I, like the OP, was not having any of my custom colors respected during the swap file message. In my ~/.vimrc, I have a line reading "colo my_custom_color_file". It was a direct copy of ron.vim originally. I hope this helps someone else who just wants to open their vim in peace and tranquility.

Answer 4

I just comment out the "hi clear" line in the colorscheme (bundle/vim-colorschemes/colors/solarized.vim) file (I use spf13 vim and mac os catalina) and it works. Don't know what causes the issue.