On 08/10/08 11:50, bill lam wrote:
> On Wed, 08 Oct 2008, Tony Mechelynck wrote:
>> 1. Make sure 'encoding' is set to a value which allows representing
>> Traditional Chinese. I recommend utf-8 but YMMV. See also
>> http://www.vim.org/scripts/script.php?script_id=789 "Switching to
>> Unicode in an orderly manner".
>
> The file can not be converted to utf8 because it was intended to be used
> by some old dos software after editing.
Anything can be translated to utf8 if your Vim is compiled with
+multi_byte and +iconv. Test it with
:echo has('multi_byte') has('iconv')
If the answer is 1 1 you have what it takes. If it's 0 0 you need a
better gvim version. If it's 1 0 you need to make sure you have the
iconv library installed where it can be found. On Linux this usually
means installing the corresponding package from your distribution, then
recompiling gvim. Here are the relevant lines from my configure output:
checking --enable-multibyte argument... yes
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for iconv_open()... yes
Note that setting 'encoding' to utf8 doesn't mean the file will be
converted to UTF-8 on disk, it just means it will be represented as
UTF-8 in Vim memory with conversion back-and-forth on reading and
writing. This conversion is lossless if the file obeys the rules of the
'fileencoding' you tell Vim to use for it with ++enc=
>> 2. The fact that you're posting with Mutt makes me believe that you're
>> on Unix/Linux now. In that case you should make sure that 'fileformats'
>> includes "dos", otherwise you'll probably see a ^M at the end of each line.
>
> Vim seemed smarter enough to detected "dos", may be I had configured
> already.
>> 3. If Big5 is not in your 'fileencodings' (plural), then open the file with
>>
>> :e ++enc=big5 filename.ext
>>
>> see ":help ++opt"
>
> What I most interested is that ASCII-127 was displayed as a single
> character that resembles the shape of a house or triangle under dos
> environment. However VIM displayed it as "^?", so is a font problem or
> a codepage problem or a problem of vim itself.
>
In ASCII or Latin1, 0x7F is Ctrl-?, the DELETE character, so if you try
to edit that file as if it were Latin1 or UTF-8, that character will
appear as ^? in Vim, and usually in the blue colour used for control
characters.
According to http://en.wikipedia.org/wiki/Big5 , Big5 is, strictly
speaking, a DBCS encoding with only double-byte characters where the
first byte can be 0x81 to 0xFE, the second byte either 0x40 to Ox7E or
0xA1 to 0xFE; it is always used mixed with single bytes from a
system-dependent 7-bit encoding, usually ASCII. This means 0x7F can only
appear as a single byte, and if ASCII, as the DEL character.
You may try
:set isprint+=127
but on my system that character is not displayed as a "house or
triangle" the way it used to be on DOS consoles with cp437, but as a
question mark (in konsole) or as nothing at all (in the linux text
console), even if I explicitly load a 0x7F from disk with ++enc=cp437.
Of course, there is then no visual clue to tell the DEL control
character (0x7F) apart from a true question mark (0x3F) so I think you
would be better off leaving it as-is and displaying it as ^?
To answer your question ("is it a font problem or a codepage problem or
a problem of vim itself?") I would say it's a DOS problem.
Best regards,
Tony.
--
Jesus Saves,
Moses Invests,
But only Buddha pays Dividends.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
