5

I defined some highlights in the vimrc file and it works well in gvim. However after I mksession and sourced it back, I found that some (maybe all) of the custom highlights were lost and vim used the default settings of the colorscheme.
The sessionoptions is blank,buffers,curdir,folds,help,options,tabpages,winsize.
Snippet from my vimrc file:

let current_color = ""

if has("gui_running")
    colorscheme desert
    let current_color = "desert"
else
    colorscheme torte
    let current_color = "torte"
endif

" Section about changing color
if current_color == "desert"
    hi LineNr guifg=DarkKhaki
    " Or guibg=NavajoWhite1
    hi StatusLine guifg=black guibg=LightGoldenrod3
    hi PmenuSel guifg=black guibg=LightGoldenrod3
    " Or guibg=Plum3
    hi Pmenu guifg=black guibg=RosyBrown
    hi CursorLine guibg=Grey27
elseif current_color == "torte"
    hi CursorLine term=NONE cterm=NONE ctermbg=238
    hi Search term=reverse ctermfg=229 ctermbg=136
    hi StatusLine ctermfg=16 ctermbg=179 cterm=NONE
    hi StatusLineNC ctermfg=244 ctermbg=144 cterm=NONE
    hi Comment term=bold ctermfg=74
    hi Constant term=underline ctermfg=217
    hi LineNr term=underline ctermfg=143
    hi Folded ctermfg=220
    hi FoldColumn ctermfg=220
    hi Special ctermfg=214
    hi NonText ctermfg=152 ctermbg=239
    hi Visual ctermfg=186 ctermbg=64 cterm=NONE
    hi PmenuSel ctermfg=16 ctermbg=179 cterm=NONE
    hi Pmenu ctermfg=16 ctermbg=138
    hi ColorColumn ctermbg=88
    hi WarningMsg ctermfg=202
    hi ErrorMsg ctermfg=15 ctermbg=160
    hi Error ctermfg=15 ctermbg=160
endif
hi Modifier cterm=inverse ctermfg=118 gui=inverse guifg=#87ff00
hi StatuslineWarning cterm=inverse ctermfg=210 gui=inverse guifg=#ff8787

Any help? Thanks very much!

  • I don't know how to fix your problem, but you could type :hi (this command will list all the current highlight groups that have attributes set), then look at an element for which the color is not the one you want. For example, let's say you realise that the background color for the StatusLine is the default, not your custom one. Then you could type :verb hi StatusLine. This command will tell you which file is the last one to have modified the color of the status line. Maybe it will give you a hint of what's going wrong. – saginaw Nov 6 '15 at 15:07
  • 1
    Could you provide some more information, like how do you save exactly your session and restore it later ? Manually, through a function, with an autocmd ? Where does the problem happen (gvim, terminal vim, both) ? Have you noticed something strange inside your Session.vim ? To debug, you could also launch vim with an empty vimrc with the command : vim -u NONE -U NONE and then sourcing manually each file that you want. Besides, vim --startuptime foo bar will open the file bar and write every file that is sourced during launch inside the file foo. – saginaw Nov 6 '15 at 20:33
  • @saginaw Hi, I encountered this issue in gvim on Windows 7. I used mksession! D:\Session.vim to manually save a session and then restart gvim and source D:\Session.vim to source it back. At first, verb hi StatusLine showed that it was last modified in D:\Program Files (x86)\Vim\_vimrc and everything went well. After I saved and restored session, it said that the StatusLine was last modified in D:\Program Files (x86)\Vim\vim74\colors\desert.vim and the StatusLine was not what I wanted.(Note that desert is my colorscheme). – tamlok Nov 7 '15 at 0:13
  • @saginaw In my vimrc, I first set the colorscheme to desert and then do set custom highlights. I pasted the Session.vim in Gist. I just tested it in vim and the issue remained. I use vim -S Session.vim --startuptime foo and found that vim sourced the torte.vim before and after sourcing .vimrc. torte is my color scheme in vim. I aslo pasted it out in Gist. So there is something wrong in vimrc? It is here. – tamlok Nov 7 '15 at 0:34
5

Your last comment says that your default colorscheme is sourced twice : once before your custom highlight groups, and once after.

The second time it's loaded, your custom highlight groups must be overwritten. I think the reason why your default theme is loaded a second time when you source your Session.vim, is because the latter includes this line (83) :

set background=dark

:h 'background' says :

When a color scheme is loaded (the "g:colors_name" variable is set) setting 'background' will cause the color scheme to be reloaded.

So I suppose that when the set background=dark from your Session.vim is executed, your default theme is reloaded but not your custom colors because they are defined in a different place (your vimrc).

I don't know if it will work, but here are a few suggestions you could try :

  • Delete this line from your Session.vim. This should solve the issue now, but you will have to do it again every time you create a new session with the :mksession command.

  • Change the value of the sessionoptions option.

    At the moment you say it's blank,buffers,curdir,folds,help,options,tabpages,winsize.
    The options part is responsible for saving options (including the background one) and mappings.

    You could use the following command before saving the session or include it inside your vimrc : set sessionoptions-=options

    As a result, your sessionsoptions value will be blank,buffers,curdir,folds,help,tabpages,winsize and your options will not be saved anymore.

  • Write your custom highlight groups into a dedicated file (let's say custom_colors.vim) and then, inside your vimrc, add an autocmd that automatically source this file at the end of the startup. For example, something like this :

    autocmd VimEnter * source /path/to/custom_colors.vim

    Since this file should be sourced after Session.vim, its settings should not be overwritten.

    Here I used the VimEnter event but you could also try the SessionLoadPost event :

    autocmd SessionLoadPost * source /path/to/custom_colors.vim

  • 1
    Thanks very much! 1. The first solution works well. But I have to delete this line each time I make a new session. Deleting set bg=dark in vimrc does not help. 2. The second solution works well, too. But I will lose some tab-related settings, such as expand or noxpand tab, which will disturb me since different projects have different rules for this. 3. The third solution also works. I just wrap the highlight settings in a function and autocmd to call it. Note that setting only the VimEnter will not work if you start up Vim and then source Session.vim, but works in vim -S Session.vim. – tamlok Nov 8 '15 at 1:35
  • 1
    So I just add both VimEnter and SessionLoadPost to call my function to set the highlight. Question: it is so strange that if I make some highlight in my vimrc, sessions will not work well with the default settings due to the set background=dark/light line in the session file. It just likes a trap for Vimmers. Do you think this is a bug in Vim? Thanks very much again for your kindness and knowledge about Vim. :) – tamlok Nov 8 '15 at 1:39
  • So many vimrc config on github will not work well with sessions. For example, some set mode-aware cursor directly in vimrc. After recovering from session, the cursor will be invisible in insert mode because of the custom highlights will be lost. – tamlok Nov 8 '15 at 1:57
  • By the way, do you know how to tell what current colorscheme is in vimrc? For now, I just maintain a current_color variable manually. – tamlok Nov 8 '15 at 2:21
  • The name of your current colorscheme is stored inside the global variable g:colors_name. You can test it with this command : echo g:colors_name. – saginaw Nov 8 '15 at 2:58
1

Easiest stable solution

Create a shell function to open a vim session and source your .vimrc after session finish loading, so you'll have all your seetings back:

Open you shell configuration file (.bashrc or .zshrc, etc) and write this function:

vims() {
  vim -S "$1" -c 'source ~/.vimrc'
}

After saving and sourcing the shell config file (or restarting the shell) you'll be always able to open a vim session with the command...

vims mysession.vim

...and it's done! :)

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.