Sorry, it's my omission, I had set 'fileencoding' in '.vimrc'...
ps:
Excuse me to get this message so late. I cannot visit google group
last few days.
On 2010-8-28, 03:37 Ben Fritz fritzophre...@gmail.com wrote:
On Aug 25, 11:11 pm, JiaYanwei jia...@126.com wrote:
e.g. If the system/vim
Oh, sorry, I forgeted that 'fileencoding' may be empty. This should be
handled.
I encountered the opposite that 'fileencoding' is often different from
'encoding' while editing existing files.
Ben Fritz wrote:
On Aug 26, 9:40 am, Ben Fritz fritzophre...@gmail.com wrote:
From my
I think this will be more reasonable than before.
If the encoding of edited text file differ form the system/vim encoding, it's
inconvenient to set default HTML charset to be 'encoding'. Thus, after
':TOhtml', we should modify the generated HTML file to make the file encoding
the same as HTML
At 2010-08-07 21:57:23，Tony Mechelynck antoine.mechely...@gmail.com wrote:
On 04/08/10 19:16, JiaYanwei wrote:
At 2010-08-04 23:46:23, Bram Moolenaarb...@moolenaar.net wrote:
JiaYanwei wrote:
For example, I work with Windows Xp Simplified Chinese Edition. There's a
character 'CIRCLED
For example, I work with Windows Xp Simplified Chinese Edition. There's a
character 'CIRCLED NUMBER TWENTY' - U+2473, beyond the character set of ACP
(system active codepage) CP936. While it can be copyed and pasted into the
textbox of Find and Replace dialog, but it can't be inputed directly
At 2010-08-04 23:46:23, Bram Moolenaar b...@moolenaar.net wrote:
JiaYanwei wrote:
For example, I work with Windows Xp Simplified Chinese Edition. There's a
character 'CIRCLED NUMBER TWENTY' - U+2473, beyond the character set of ACP
(system active codepage) CP936. While it can be copyed
The dialogs are poped up by the function inputdialog() and the commands
promptfind, promptrepl. The procedures inside gVim cannot get the correct
input from these dialogs if the input contains any unicode character beyond
the character set of ACP (system active codepage), even if the gVim runs
When interchanging data with Windows such as clipboard operation, gvim will
convert the text into UCS-2 encoding, but different from UTF-16, UCS-2 can't
encode non-BMP characters.
For example, when paste a non-BMP character U+248BB from Windows clipboard,
it will insert two separated
Hello Tony,
It's really to be the similar problem, but this one only arise under Windows
operating system, the UTF-16le BOM problem is platform independence. I was
uncertain wherher a combined patch was convenient.
On 2008-10-22 23:21:11, Tony Mechelynck wrote:
I expect this is related with
Oh, I had made a mistake, I want to say They're really similar problems
the first sentence.
On 2008-10-23 00:16:20, JiaYanwei
Hello Tony,
It's really to be the similar problem, but this one only arise under Windows
operating system, the UTF-16le BOM problem is platform independence. I
For a 2 byte BOM FF FE, ucs-2le is used, which doesn't work for
little-endian UTF-16 text.
Like the patch 7.1.261, the only difference is the byte order.
And I have also writen a patch for Vim-7.2.025:
*** ../vim-7.2.025/src/fileio.c Wed Oct 15 15:09:56 2008
--- src/fileio.cSat Oct 18
Hello Tony,
Thanks for your helpful suggestion.
By the way, wish Bram a wonderful holiday.
on 2008-10-18 18:18:45, Tony Mechelynck wrote:
I confirm that Vim 7.2.25 with 'fencs' starting in ucs-bom identifies
UTF-16le files with BOM as if they were UCS-2le, even if codepoints
above U+ are
12 matches
Mail list logo
