3

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:

enter image description here

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

  • 1
    That color is defined by your colorscheme. – romainl Jun 8 '16 at 14:39
5

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

|improve this 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).

|improve this answer|||||
  • 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. Any idea why that might be? – Ben Lindsay Jun 8 '16 at 20:08
  • @BenLindsay I've updated the answer with a few suggestions. – mMontu Jun 9 '16 at 11:45
  • Using your suggestions, I found that plugins and viminfo don't have any effect, but commenting out colorscheme desert in my .vimrc changed the color. I copied $VIMRUNTIME/colors/desert.vim into ~/.vim/colors/mydesert.vim and changed every ctermfg and guifg color to black. Now, if I have foo.txt already open and try to reopen from command line using vim foo.txt, my color problem still persists. However, if I open vim, then type :colorscheme mydesert then :e foo.txt, then all the colors in the error message are black as expected, so something else must be changing the colorscheme too – Ben Lindsay Jun 20 '16 at 16:58
  • @BenLindsay Now, if I have foo.txt already open and try to reopen from command line using vim foo.txt, my color problem still persist -- is there any chance that you left colorscheme desert in your vimrc? – mMontu Jun 20 '16 at 18:02
  • No, I checked. If I comment out colorscheme mydesert in my vimrc, the message color is dark green. If I uncomment it, the message color is sea green. The same thing happens whether or not mydesert.vim has hi MoreMsg ctermfg=black or hi MoreMsg ctermfg=darkgreen. But when I reload the colorscheme from within vim before opening an already opened file, the MoreMsg ctermfg setting exactly controls the color I see. I'm still very confused about where this nasty sea green color is coming from – Ben Lindsay Jul 4 '16 at 13:53
1

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.