Thomas Schumm wrote:
I had been getting this error (or something very similar) for a while now when
editing PHP files, but now I'm also getting it when editing Cheetah
templates.
---------------------------------------------------------------------
Error detected while processing /usr/share/vim/vim70/syntax/html.vim:
line 200:
E108: No such variable: "b:current_syntax"
---------------------------------------------------------------------
Is it a bug in the syntax file? Is there something strange about my
configuration that could be triggering this? I've been hacking up
the /usr/share/.../html.vim file to make it check for the existence of that
variable before it unlets it, but obviously, that gets changed back every
time I upgrade vim. I'd like to find a more permanent fix.
1. As you painfully discovered, users should change nothing in
$VIMRUNTIME and its subdirectories, because any upgrade can silently
add, remove or change anything there.
2. The standard version of $VIMRUNTIME/syntax/html.vim (for Vim 7.0,
last change 2006 Apr 13) mentions b:current_syntax at several places:
- at line 14, it exits immediately if b:current_syntax already exists
when it is sourced;
- at lines 165, 190 and 200, it undefines b:current_syntax immediately
after "syn include" statements
- at lines 285 it sets b:current_syntax to the value "html" just before
exiting.
Line 200 is just after a "syn include" statement for syntax/css.vim
$VIMRUNTIME/syntax/css.vim (for Vim 7.0, last change: 2005 Nov 23)
treats b:current_syntax similarly, and in particular sets it to "css" at
line 272.
So the question is: what have you been doing with
$VIMRUNTIME/syntax/css.vim ?
If you have been altering the Vim runtime files out of recognition, I
recommend that you download a new set from
ftp://ftp.vim.org/pub/vim/runtime/ (except its dos/ subdirectory, see
note at bottom of this post) and, in the future, limit your changes to
adding files in 'runtimepath' directory trees /other/ than $VIMRUNTIME.
Normally there are directory trees mentioned in 'runtimepath', as follows:
$HOME/.vim (on Unix), or
$HOME/vimfiles (on Windows):
full-fledged scripts peculiar to a single user
$VIM/vimfiles (on all platforms)
full-fledged scripts added system-wide (by an admin) in addition
to those distributed with Vim
$VIMRUNTIME
scripts distributed together with Vim ONLY
$VIM/vimfiles/after
system-wide "small changes" to scripts of the same name in any of
the above
$HOME/.vim/after (on Unix), or
$HOME/vimfiles/after (on Windows):
user-specific "small changes" to scripts of the same name in any
of the above.
Also, if $VIMRUNTIME is not found, Vim 7.0 will set it to the equivalent
of $VIM/vim70 ; and, if $VIM is also not found, Vim for Unix will
(unless changed at compile-time) set it to /usr/local/share/vim . If
neither $VIMRUNTIME nor $VIM exist on Windows, Vim will set them in
function of where its executable is located: for example, if gvim is in
C:\Program Files\vim\vim70 it will set $VIMRUNTIME to that directory and
$VIM to its parent. The details are a little more complex but can be
found under ":help $VIM" and ":help $VIMRUNTIME". I recommend not to
define $VIMRUNTIME in the environment outside of Vim, and to either not
define $VIM either, or to define it as the same as the default (with, on
Windows, an "8.3" name without spaces such as C:\PROGRA~1\vim to mean
"C:\Program Files\vim"). The advantage of defining $VIM outside of Vim
as the same as the default, is that then you can use $VIM and $VIM/vim70
(or, on Windows, %VIM% and %VIM%\vim70) in the shell to mean $VIM and
$VIMRUNTIME respêctively. (The exact syntax to define an environment
variable varies from shell to shell, and the way to set environment
variables permanently varies from OS to OS, so I'm not going to delve
into that here.)
see
:help 'runtimepath'
:help $VIM
:help $VIMRUNTIME
and what they link to.
Note: The files in ftp://ftp.vim.org/pub/vim/runtime/dos/ are duplicates
of the other files in pub/vim/runtime/ but with Dos ends-of-lines (CR+NL
instead of NL only, which also means that the "Unix" files take up a
little less disk space than the "Dos" ones). However, Vim for Windows is
quite capable of handling the "Unix" files, both when running
("sourcing") them as when editing (or viewing) them, on the only
condition that the 'fileformats' option should include "unix". This is
the default. (You may want to add ":set fileformats+=mac" or ":set
fileformats=dos,unix,mac" to your vimrc in order to recognise all
possible types of ends-of-lines when editing.)
Best regards,
Tony.
