> On 03/12/09 09:35, Mojca Miklavec wrote:
>>
>> On Thu, Dec 3, 2009 at 09:22, Tony Mechelynck wrote:
>>>
>>> Well, is it possible to set the locale to UTF-8 on Windows the way it is
>>> on
>>> Linux? My current locale ($LANG on Linux) is 'en_US.UTF-8'. Maybe you
>>> could
>>> try setting the locale to 'Polish_Poland.UTF-8' or
>>> 'Slovenian_Slovenia.UTF-8' (or some such) on your Windows system? Or does
>>> that create other problems?
>>
>> Yes and no.
>>
>> No because it's not possible to set it to "Slovenian_Slovenia.UTF-8".
>> Windows only seems to accept numerical values for encodings.
>>
>> Yes because it's possible to set the locale to
>> "Slovenian_Slovenia.65001" where 65001 stands for UTF-8, but I guess
>> that vim has no idea what number 65001 means. I have tried it, I have
>> created menu translation menu_slovenian_slovenia.65001.vim which has
>> been used (confirmed by modifying some strings in that translation),
>> but vim didn't behave any differently.
>>
>> Mojca
>>
>> PS: the encoding in locale seems to be there just for "old application
>> that don't understand unicode", so windows doesn't bother to set the
>> locale to Unicode even if it's a a unicode system.
>>
>> PPS: Even if I would manage to force the encoding in Locate to be
>> UTF-8, I guess that it still needs to be fixed in such a way that it
>> will behave properly by default. (Some years ago I was getting Slovak
>> translations by default on every computer which was a lot worse than
>> not getting any tranlation at all.)
>>
>
> Getting all menus and messages in English regardless of the locale is quite
> easy; all it takes is the following code snipped AT THE VERY TOP of your
> vimrc (before setting up the menus, and before sourcing the
> vimrc_example.vim if you source it):
>
> if has('unix')
> language messages C
> else
> language messages en
> endif
>
> If Vim doesn't understand what 65001 means, you could maybe (untested) do
> something like
>
> if v:ctype ~= '\<65001$' " if the locale ends in '65001' as a word
> set enc=utf-8 tenc= " tell Vim that Windows wants UTF-8
> endif
>
> just before the point where you turn 'encoding' to UTF-8 if running in a
> different locale.
Oh, no ... I cannot believe that.
I had
set encoding=utf-8
at the very bottom of my _vimrc file. And *that* line caused the weird
behaviour (I guess it's still the same _vimrc file that I had back on
XP and was working fine there, though I would need to test now). I
needed that line since that was the only way to get UTF-8 encoding
working for editing documents. As far as the termencoding is concerned
it doesn't matter at all what I set it to (any setting or no setting
works fine).
If I shift just that line just a few lines higher then everything
starts working perfectly (no language or locale change happens in
between). If I delete that line or remove my _vimrc file then I get
all the encodings in all the files back to cp1250, but at least the
menus seem to work. (Shouldn't it be time to move on to UTF-8 by
default?)
I feel a bit ashamed since it was mainly the fault of my old _vimrc
file, but I still find it a bit weird that it is still falling back to
the old encodings. Windows documentation explicitely says: "This
locale encoding is there just in case that application doesn't support
Unicode." Vim should be still able to open 8-bit files in that
encoding (maybe the encoding from Locale should automatically be the
default one for 8-bit files unless specified differently), but for new
ones ... why not switching to Unicode completely?
Summary:
- set encoding=utf-8 on top works perfectly
- set encoding=utf-8 on bottom => weird behaviour
- no explicit encoding setting => works, but uses cp1250
- termencoding can be anything (it was crucial to have it set to cp1250 in XP)
Mojca
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment