strange directory listing using netrw v134
Yasufumi Haga
I'm using vim 7.2.60 on linux.
When I run ":e <directory name>" to show a directory list, some of
the filenames and directorynames in the list have "e" at the
beginning of their names, and hitting "Enter" key on a directory name
with "e" at the top in the list won't go down under the directory.
Similarly hitting "Enter" on a filename with "e" at the top in the
list opens a new file. It looks like "e" is added to the names
between "../" or "./" and just before a name beginning with an
uppercase letter in the list. For example, ":e ." shows the following:
...
xsession-errors
.xwm.msgs
.zphotorc
e../
e.Eterm/
e.Tgif/
e.Trash/
e.Wnn7/
e.adobe/
...
ework/
e.bash_profile~
e.bashrc~
e.mew.el~
e.mytips~
e.signature.alist~
Xrootenv.0
Pressing "s" for sort once and twice "e"s at the beginning of their
names disappear, but doing it three times "e"s appear at the top of
their names again.
Would someone please help me solve this strange listing problem?
Thanks in advance.
--Yasufumi
Charles Campbell
> I'm using vim 7.2.60 on linux.
> When I run ":e <directory name>" to show a directory list, some of
> the filenames and directorynames in the list have "e" at the
> beginning of their names, and hitting "Enter" key on a directory name
> with "e" at the top in the list won't go down under the directory.
>
Hello!
I made a directory and put the files you gave (less the leading "e"s) in
it; netrw displayed the directory listing correctly. I'm using v135e;
please try that
(http://mysite.verizon.net/astronaut/vim/index.html#NETRW). However,
not having seen this problem before, I'm not expecting that v135e will
solve the problem.
The next thing to do: please get and install the Decho plugin:
http://vim.sourceforge.net/scripts/script.php?script_id=120
-or-
http://mysite.verizon.net/astronaut/vim/index.html#DECHO
(this latter one is always the most up-to-date)
and then enable it:
vim netrw.vim
:DechoOn
:wq
then
vim your_problematic_directory
If you do a :tabn you'll see the output of the debugging run; please send me a copy and I'll take a look at it.
And, to restore netrw to its usual condition:
vim netrw.vim
:DechoOff
:wq
Regards,
Chip Campbell
Yasufumi Haga
Thanks for your advices.
On Tue, 02 Dec 2008 09:21:10 -0500,
Charles Campbell <Charles.E...@nasa.gov> wrote:
> please try that
> (http://mysite.verizon.net/astronaut/vim/index.html#NETRW).
> However,
> not having seen this problem before, I'm not expecting that v135e
> will
> solve the problem.
Yes, you're right. This doesn't change anything.
>
> The next thing to do: please get and install the Decho plugin:
>
>
> http://vim.sourceforge.net/scripts/script.php?script_id=120
> -or-
> http://mysite.verizon.net/astronaut/vim/index.html#DECHO
> (this latter one is always the most up-to-date)
>
> and then enable it:
>
> vim netrw.vim
> :DechoOn
> :wq
>
> then
> vim your_problematic_directory
>
> If you do a :tabn you'll see the output of the debugging run;
> please send me a copy and I'll take a look at it.
Although I haven't used decho before, I think I got the debug info.
I'll attach this info to this mail and send it to you. Those debug
info have Japanese kanji characters meaning "line" in their contents.
So I took a screenshot of the first case (my home directory) in case
those characters are messed up in it when you open the attached file.
I uploaded the screenshot at
http://homepage3.nifty.com/peterpan/x00/ss.jpg.
Thanks a lot for your help, Charles.
Regards.
--Yasufumi
Yasufumi Haga
I forgot to tell you one thing. I sent a debug info for root
directory in addition to the one for my home directory because this
problem occurs for other directories such as /tmp or /usr as well.
Regards.
--Yasufumi
Yukihiro Nakadaira
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'
--
Yukihiro Nakadaira - yukihiro....@gmail.com
Charles Campbell
> 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'
>
>
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
Yasufumi Haga
Thanks a lot for your big help!!
On Wed, 03 Dec 2008 12:13:20 -0500,
Charles Campbell <Charles.E...@nasa.gov> wrote:
>
> 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.
I should have told you the locale that I use in my first post.
[snip]
> 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).
I fetched the new netrw (v135f) and am using it. It looks like it's
working just fine in my euc-jp environment for now :)
Regards.
--Yasufumi
Matt Wozniski
>
> 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?
Looking at the code, the way this is done seems fundamentally
broken... If I'm understanding things correctly, you're trying to
separate the priority from the filename with a "separator character",
and then using s/\d\{3}SEPCHR// to remove it later. If I'm not
misunderstanding that, it seems that it would be completely impossible
to choose a separator character which is an invalid character in
filenames on all systems. An ext2 filesystem could have a file named
"123\xFF" or "123\x01"; in fact the only two invalid characters on the
filesystem are NUL and forward slash, and neither of those are
suitable for what use here - vim strings can't contain a NUL byte, and
123/ is a valid name for a directory that you may need to sort. I
suppose one work-around might be to substitute all \ for \\ and all /
for \/ and then use / as a separator character, replacing \\ with \
and \/ with / afterwards, but even that idea seems fragile. Am I
completely off base? Is the way it's currently being done safer than
it appears to me?
~Matt
Yasufumi Haga
On Thu, 04 Dec 2008 08:15:34 +0900 (JST),
Yasufumi Haga <yasufu...@nifty.com> wrote:
> Hi Nakadaira-san, Chanles
I'm terribly sorry, Charles. I've just noticed I misspelled your name.
Regards.
--Yasufumi
Teemu Likonen
> On Wed, Dec 3, 2008 at 12:13 PM, Charles Campbell wrote:
>> * 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?
>
> Looking at the code, the way this is done seems fundamentally
> broken...
At least in GNU systems it is possible to use the --dired option of
"ls". It tells explicitly where the filename is in the output. Like
this:
$ ls -l --dired
total 4
-rw-r--r-- 1 dtw dtw 17 2008-12-04 09:36 a し ら $ \ " ' ~
//DIRED// 53 72
//DIRED-OPTIONS// --quoting-style=literal
The filename is located in the output bytes from 53 to 72.
Charles Campbell
Regards,
Chip Campbell
Charles Campbell
> Looking at the code, the way this is done seems fundamentally
> broken... If I'm understanding things correctly, you're trying to
> separate the priority from the filename with a "separator character",
> and then using s/\d\{3}SEPCHR// to remove it later. If I'm not
> misunderstanding that, it seems that it would be completely impossible
> to choose a separator character which is an invalid character in
> filenames on all systems. An ext2 filesystem could have a file named
> "123\xFF" or "123\x01"; in fact the only two invalid characters on the
> filesystem are NUL and forward slash, and neither of those are
> suitable for what use here - vim strings can't contain a NUL byte, and
> 123/ is a valid name for a directory that you may need to sort. I
> suppose one work-around might be to substitute all \ for \\ and all /
> for \/ and then use / as a separator character, replacing \\ with \
> and \/ with / afterwards, but even that idea seems fragile. Am I
> completely off base? Is the way it's currently being done safer than
> it appears to me?
>
At the time this part of netrw was written (and its got parts stretching
back to 1999 or so), dictionaries, lists, etc were not supported. A
different technique to achieve the same goal would be to use sort() with
a comparison function -- and use a list to hold [priority,filename]
entries. This has a time trade-off; interpreted functions run slower
so directories would take longer to display.
My intention for now is to do bug-fixing with netrw. After its settled
down a bit more, there are a number of things I intend to do to improve
netrw's internal workings; priority sorting is one of them. Another is
to improve, streamline, simplify, etc ftp handling. Another involves
netrw-buffer handling. More use of lists (and dictionaries if so
indicated).
Yukihiro Nakadaira
> * 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.
It seems that s:Strlen() is used to get string width in screen column.
If strlen() is used to get byte length of string (e.g. for argument of
strpart()), replacing it with s:Strlen() will cause problem.
Matt Wozniski
>
> Matt Wozniski wrote:
>> Looking at the code, the way this is done seems fundamentally
>> broken... If I'm understanding things correctly, you're trying to
>> separate the priority from the filename with a "separator character",
>> and then using s/\d\{3}SEPCHR// to remove it later. If I'm not
>> misunderstanding that, it seems that it would be completely impossible
>> to choose a separator character which is an invalid character in
>> filenames on all systems. An ext2 filesystem could have a file named
>> "123\xFF" or "123\x01"; in fact the only two invalid characters on the
>> filesystem are NUL and forward slash, and neither of those are
>> suitable for what use here - vim strings can't contain a NUL byte, and
>> 123/ is a valid name for a directory that you may need to sort. I
>> suppose one work-around might be to substitute all \ for \\ and all /
>> for \/ and then use / as a separator character, replacing \\ with \
>> and \/ with / afterwards, but even that idea seems fragile. Am I
>> completely off base? Is the way it's currently being done safer than
>> it appears to me?
>>
> "Fundamentally broken", huh?
Fundamentally broken, as in there's no separator character that can be
used on all systems, and requiring users to try to come up with their
own character that probably won't be used is completely
unreasonable...
~Matt
Tony Mechelynck
[...]
> Fundamentally broken, as in there's no separator character that can be
> used on all systems, and requiring users to try to come up with their
> own character that probably won't be used is completely
> unreasonable...
>
> ~Matt
Well, if you think it's broken you don't have to use it (you can always
use external ftp, external ls or dir, whatever suits you. You're even
welcome to write a better version if you think you can). It's perfectly
good enough for the uses I put it to.
Regards,
Tony.
--
This is National Smokers-Are-Shits Week.
Matt Wozniski
>
> On 04/12/08 20:02, Matt Wozniski wrote:
> [...]
>> Fundamentally broken, as in there's no separator character that can be
>> used on all systems, and requiring users to try to come up with their
>> own character that probably won't be used is completely
>> unreasonable...
>>
>> ~Matt
>
> Well, if you think it's broken you don't have to use it (you can always
> use external ftp, external ls or dir, whatever suits you. You're even
> welcome to write a better version if you think you can). It's perfectly
> good enough for the uses I put it to.
Well, I don't use it, I find NERDTree much nicer, but that's certainly
not the point. Isn't it a good thing for a feature to be written in a
way that allows it to work all the time, in all cases? I'm just
suggesting that rather than patching over this problem by asking the
user to choose a separator byte that isn't likely to cause problems,
that this be fixed to not rely on any magical byte sequences. This is
especially important for a plugin that's packaged with vim, which
ought to represent the best use that can be made of the scripting
language.
~Matt
Charles E. Campbell, Jr.
Regards,
Chip Campbell
Yukihiro Nakadaira
> You're right -- I've put 135g up on my website with this addressed.
I think that more s:Strlen() should be replaced with strlen(). Please
check attached patch. Maybe s:Strlen() is not required in the current
version. This patch is also including fix for wide listing in where the
following line.
@@ -5972 +5972 @@
- exe 'silent keepjumps
'.w:netrw_bannercnt.',$s/^.*$/\=escape(printf("%-'.b:netrw_cpf.'s",submatch(0)),"\\")/'
+ exe 'silent keepjumps '.w:netrw_bannercnt.',$s/$/\=repeat(" ",b:netrw_cpf-virtcol("$"))/'
Yasufumi Haga
This also works fine in my environment.
Thanks.
Regards.
--Yasufumi