Bug#474609: Netrw's handling of multi-byte filepaths

[Teemu Likonen]

drchip at campbellfamily.biz wrote (2008-05-05 09:28 -0700):

> v125h tries to address this; it involved changing various places which
> used to use s:Strlen() (but not all).  There's a new option variable,
> too: g:netrw_xstrlen.  Haven't documented it (yet), but it allows one
> to choose several methods to figure out multi-character string
> lengths.  However, the problem you forwarded involved a need to use
> the actual string length, not the visible string length.  Hopefully
> I got all the changes right for this.

Hello, and thanks for the update. It seems to work pretty well. I found
one defect though. It's hard to explain but I'll show you an example; it
triggers with netrw's wide listing mode (i.e. g:netrw_liststyle=2).

First make a clear testing directory for reproducing this bug:
$ mkdir testdir; cd testdir

Now create a directory which has a multibyte character in its name:
$ mkdir test-ä

Create also a file:
$ touch testfile

When browsing to that directory in wide listing mode we see

  test-ä/  testfile

which is correct.

Now, if we browse to test-ä/ directory, Vim won't enter to the directory
but starts editing filename "test-ä/  t" instead (see the spaces).
I think the "t" comes from the first letter of the filename "testfile".
Other funny thing is that when we open the "testfile" from netrw browser
Vim will start editing file "estfile".

There are also some spacing issues in wide listing mode: file or
directory names with multibyte or double-width characters cause other
directory items in the same line to display too close.

I'm using netrw version 125k. In other listing modes it seems to work
nicely, even with double-width characters like "な" (U+306A).