2

enter image description here

#!/bin/bash
echo ${2:-"-l -p"}

Having some bash parameter-substitution fun and (Neo) Vim complains about it, while the code is perfectly fine.

I know I can suppress errors totally by doing sort of like hi Error ctermbg=None, but that's quick and dirty. (I can live with the red background, but it's ugly).

I did :h error [[ press Tab 20 times ]], but didn't find anything interesting about the topic.

Can I fix (or should I report) such misbehaviour?

Pure Vim highlights the same way, running:

vim -u NONE -c "set nocp | set filetype=sh | syn on"
vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 15 2016 18:06:04)
Included patches: 1-86
Compiled by Arch Linux
Huge version without GUI.

Update

Doesn't work in urxvt. Neither in neo nor pure Vim.
Doesn't work in NeoVim. Neither in urxvt nor xterm.
Works only in xterm, pure Vim.

works == no red background, I mean
All of the above happens with -u NONE.

  • Can't reproduce here, even with the "pure vim" configuration (OS X, MacVim 8). Could it be something related to your terminal? – nobe4 Jan 2 '17 at 18:58
  • It's strange that this would work correctly in xterm/Vim, but doesn't in urxvt/Vim. Are you sure you're using the same Vim version in both tests? – Martin Tournoij Jan 3 '17 at 18:52
3

Vim also used to display this as an error, but the latest version no longer does. It looks like the syntax file for Vim has been updated in a fairly recent version Vim, which isn't in Neovim yet.

I downloaded the Vim source and did:

git checkout v7.4.1900

To get an older Vim version. We're only interested in the syntax file (runtime/syntax/sh.vim) so we don't need to re-compile Vim.

After opening a simple a.sh file which contains echo ${2:-"-l -p"} I did:

:unlet b:current_syntax
:source /home/martin/src/vim/runtime/syntax/sh.vim

to load the Vim 7.4.1900 syntax file from the source tree, and now I have the same red text as you do.

So now we need to isolate the patch that fixes this. Unfortunately the git commits for runtime directories don't contain a helpful description (just "update runtime directory") but we know that:

  • v8.0.0142 does not have this problem;
  • v7.4.1900 does have this problem;
  • that the fix is in runtime/syntax/sh.vim

Checking the history for that file we see there aren't that many recent changes, so I simply did git checkout <commit-id> until I managed to reproduce the problem. The commit after that one will have fixed the problem, which is e4a3bcf.

if you look at the diff, we see a number of changes to the shDeref* syntax groups, which seem fix the error.

There are two things you can do:

  • Copy the latest syntax/sh.vim from the Vim source to to ~/.config/nvim/syntax/sh.vim (Neovim) or ~/.vim/syntax/sh.vim (Vim) so it will override the default. Neovim doesn't seem to have made any changes to this file, so you won't lose anything.

    The downside of this is that you won't get any future updates made to the system-wide syntax/sh.vim.

  • You can also try to locally amend the syntax/sh.vim file with just the fixes using the after directory. This will take more time, but you will get future updates made to the system-wide syntax/sh.vim.

  • Whooa you did investigate this :) Thank you very much, I'll try your suggestion now. I think I had some problem with xbindkeys (which I use to start urxvt). I ran urxvt manually and then the pure vim colors were ok. Unfortunately I can't reproduce the urxvt/pure vim misbehaviour any more. I have not updated any of them since, so that's really weird. – Al.G. Jan 3 '17 at 19:51
  • OK, swapping the default sh.vim in neovim with the latest one from vim works. But I don't think it's worth the effort just for some dummy red background on line 53 in /home/user/path/to/file.... :) It was interesting solution anyway, so thanks again +1.5 :). I think, though, I should reconsider using neovim vs pure vim. – Al.G. Jan 3 '17 at 20:18
  • Carpetsmoker, this would have been an excellent time to use git bisect. – studog Jun 6 '17 at 15:20

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.