A.J.Mechelynck wrote:
David Woodfall wrote:
SOLVED!
Well I think I fixed by rtfm:
:set termenc=cp1252
Seems to work, but I don't know yet whether it breaks anything else.
'termencoding' tells Vim (in both the Console and GUI versions) how your
keyboard translates data and (in the Console version only) how the
terminal displays it. By default it is set to empty, which means "use
the value of 'encoding'". This is OK as long as you don't change
'encoding' in your vimrc. If you do, then it is "prudent" to save in
'termencoding' your "locale" encoding, i.e., whatever 'encoding' was set
to at startup, like this:
ERRATUM
if has("multi_byte") " if not, we don't have Unicode support
if &enc !~? '^u' " if 'encoding' starts with u or U,
" then Unicode is already set
if &tenc == ""
let &tenc = &enc " avoid clobbering the keyboard encoding
endif
set enc=utf-8
endif
set fencs=ucs-bom,utf-8,latin1 " heuristics for existing files
setglobal bomb fenc=latin1 " defaults for newly-created files
else
echomsg "Warning: No multibyte support"
endif
" the following adds (among other things) the current 'fileencoding'
" to the statusline text
if has("statusline")
exe 'set statusline=%<%f\ %h%m%r%=%k[%{(&fenc\ '
\ . '==\ \"\"?&enc:&fenc).(&bomb?\",BOM\":\"\")}]\ %l,%c%V[%b=0x%02B]\
%P'
endif
Best regards,
Tony.
Best regards,
Tony.
--
"Wagner's music is better than it sounds."
-- Mark Twain
