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.

Reply via email to