Yukihiro Nakadaira wrote:
> This problem occurs when encoding=euc-jp. See sepchr variable in
> autoload/netrw.vim. <char-0xff> is used for separate character. But it
> is not safe in euc-jp (and perhaps other multi-byte) encoding.
>
> To reproduce:
> set enc=euc-jp
> " separator, used in netrw
> let sepchr = "\<char-0xff>"
> " put file entry
> put='foo'
> " insert sort priority
> exe 's/^/001'.sepchr.'/'
> " remove it
> exe 's/^\d\{3}'.sepchr.'//e'
>
>
Good catch -- I wasn't having much luck finding the problem (but then I
don't use enc=euc-jp).
I've put netrw v135f on my website
(http://mysite.verizon.net/astronaut/vim/index.html#NETRW).
* g:netrw_sepchr is now user-changeable (in his/her .vimrc). I've set
it by default to 0x01 for euc-jp,
but am awaiting comment from euc-jp users. Any other encodings need
to have the default changed?
* as a related issue, multibyte encodings cause strlen() problems -- as
in, strlen() reports the wrong
string length. With netrw v135f, netrw always calls s:Strlen() where
it may have called strlen()
before; by default g:netrw_xstrlen is zero, which means strlen() will
be used. However, one has
three other choices -- hopefully, one of them will work for you.
Regards,
Chip Campbell
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
