Mojca Miklavec wrote:
On 6/14/06, A.J.Mechelynck wrote:
In $VIMRUNTIME/vimrc_example.vim for Vim 7.0, last change 2002 Sep 19,
at line 56
filetype plugin indent on
...
Thanks for all the hints. Using the extensive explanation and after
playing with all possible combinations: the most crutial part was
setting
set termencoding=cp1250 encoding=utf-8
before both
syntax on
filetype plugin indent on
in vimrc_example.
I'll play with it and inspect a bit more (looks pretty weired and I
would never have come to the clue that termencoding might be important
for "syntax" and "highlighting" issues) to understand it better.
Again: thanks a lot for taking your time, it works like a charm now!
Mojca
Well, so much the better if it woks like a charm. Once you understand
how best to do it, maybe you should write a tip and publish it at
vim-online http://vim.sourceforge.net/. Don't forget to mention pitfalls
and alternative methods (such as using 'langmenu').
I don't recommend modifying the vimrc_example (except by copying it to
another pathfilename) because:
a) if a bug is found in it, a patchlevel upgrade may modify it silently;
b) when you upgrade to a Vim version higher than 7.0, the whole
$VIMRUNTIME structure will be re-created from scratch under a different
name (such as $VIM/vim71 instead of $VIM/vim70).
In both cases, any modifications you made into the vimrc_example will be
lost (maybe after you've forgotten about them). What I recommend is
sourcing the vimrc_example from your own vimrc, with most customizations
after it, and maybe a few lines before it if they influence what the
vimrc_example does. For instance, I prefer English menus and messages,
and I have noticed that to get them even on multilingual Vim, and that
on both Windows and Linux, I need the following before sourcing the
vimrc_example:
if has("unix")
language messages C
else
language messages en
endif
Anything which doesn't have to go before the vimrc_example should go
after it, and many settings must go after it to override it. For instance:
filetype indent off " overrides the "indent" part of :filetype
plugin indent on
set nobackup writebackup " overrides "set backup" in the vimrc_example
etc.
'termencoding' defines how Vim interprets keyboard input in all cases.
In console vim but not in the GUI it also tells Vim how the console
interface will interpret screen output. In the GUI, screen output is
defined by 'encoding' and by the glyphs in the font(s) defined by
'guifont' and, when used (which is seldom necessary), 'guifontset' and
'guifontwide'. Your further experiments may help us all understand how
Vim writes to the menu bar. I would expect that when 'termencoding' is
empty Vim should fall back to the value of 'encoding' (see ":help
'termencoding" then scroll to /^\s*When empty/). That would be right
until or unless the 'encoding' setting is altered (normally by the vimrc).
I notice that the help says 'termencoding' is forcibly set to UTF-8 at
GUI startup in the GTK+2 gvim. I wonder why. Does the GTK+2 keyboard
interface always use UTF-8?
Best regards,
Tony.