Sourcing (a very tiny) vimrc changes iskeyword

Question

I'm having a hard time understanding how set nocompatible (a line which, from this answer on StackOverflow, I understand I could also remove from my ~/.vimrc, correct me if I'm wrong), syntax enable and VimPlug are interacting as regards iskeyword which changes upon sourcing my ~/.vimrc, causing a change in the behavior of *.

I'm sure I had a similar issue some week ago with a TeX file, but I can't bother reproducing it now, as the present reproduction seems enough for asking a question.

My troubleshooting resulted in the following screencast, which I describe it below, if you find it more convenient

1. At the time 00:35 I have reduced my ~/.vimrc to a bare minimum:

   if empty(glob('~/.vim/autoload/plug.vim'))
     silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
     \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
     au VimEnter * PlugInstall --sync | source $MYVIMRC
   endif
   call plug#begin('~/.vim/plugged')
   call plug#end()
   set nocompatible " to use Vim, not just vi
   syntax enable
   

2. Then I go back to the terminal via Ctrl-Z, open a CSS file and, at time 00:44, I hit * while the cursor is at the beginning of the word box-sizing, and what gets searched is \<box-sizing\>, which I think is correct for a CSS file; not shown in the screencast, I've verified that :echo &iskeyword gives @,48-57,_,192-255,-;
3. At the time ~00:53 I :so ~/.vimrc (which I've modified at step 1) then hit * again, showing that something \<box\> is searched this time! I've verified (not shown) that :echo &iskeyword give @,48-57,_,192-255.
4. I quit the CSS file, then I go back to my ~/.vimrc, and delete the set nocompatible line at the time 01:05.
5. One more time, I reopen the CSS file and repeat the procedure, showing that this time, also after :so ~/.vimrc, * still searches \<box-sizing\>.
6. I close the CSS file, go back to ~/.vimrc, restore the set nocompatible line, delete all VimPlug specific stuff, and :write this content (time 01:29) set nocompatible syntax enable
7. Finally I open the CSS file a third time, and show that * only searches \<box\> now. What is happening? Given the very scarce ~/.vimrc I show during the screencast, what in world could be messing around with iskeyword? Should I ask for help to Junegunn Choi?

Answer 1

The effect you're seeing is due to the set nocompatible command resetting many other options, 'iskeyword' included.

From :help 'nocompatible':

This is a special kind of option, because when it's set or reset, other options are also changed as a side effect. NOTE: Setting or resetting this option can have a lot of unexpected effects: Mappings are interpreted in another way, undo behaves differently, etc. If you set this option in your vimrc file, you should probably put it at the very start.

I'd in fact go further, and say that you should not set this option in your vimrc file at all. Because 'nocompatible' is effectively the default right now:

When a vimrc or gvimrc file is found while Vim is starting up, this option [compatible] is switched off, and all options that have not been modified will be set to the Vim defaults. Effectively, this means that when a vimrc or gvimrc file exists, Vim will use the Vim defaults [nocompatible], otherwise it will use the Vi defaults [compatible].

And that's not even the full story, because starting on Vim 8 when no vimrc file exists, Vim will source the defaults.vim file, which will set 'nocompatible' as well. So, in practice, you'll always get it, without setting it explicitly.

(In fact, I previously posted a question exploring why one will still often find advice to add set nocompatible to one's vimrc, considering it's basically been the default for quite some time.)

In the specific case of 'iskeyword', you'll see that it has different defaults for Vim (nocompatible) and Vi (compatible):

(Vim default for Win32: @,48-57,_,128-167,224-235
                    otherwise: @,48-57,_,192-255
    Vi default: @,48-57,_)

Therefore, setting nocompatible will end up resetting this option.

Furthermore, you're editing a CSS file, and the filetype plug-in for CSS has recently updated to modify 'iskeyword' and include a dash as a valid keyword character (as it's indeed a common character in CSS keywords.) See $VIMRUNTIME/ftplugin/css.vim for more details.

As such, it's expected that this option will be reset while setting nocompatible, and since it's typically a buffer-local setting which is expected to be tweaked for different filetypes, that's just one more strong argument to avoid explicitly setting nocompatible in your vimrc, particularly if you expect to reload it using :so $MYVIMRC or similar while Vim is already running and you might be editing a file which has settings that might be affected by nocompatible. (A workaround here is to use :e after :so $MYVIMRC, to reload the current file, which will trigger filetype detection again and reset any filetype-specific options such as 'iskeyword' in this specific case.)