netrw problems
Caleb Eggensperger
../../../../src/appl/gssftp/ftp/cmds.c: at line 175
../../../../src/appl/gssftp/ftp/cmds.c: at line 177
../../../../src/appl/gssftp/ftp/cmds.c: at line 192
../../../../src/appl/gssftp/ftp/cmds.c: at line 194
This security scheme is not implemented
This security scheme is not implemented
KERBEROS_V4 rejected as an authentication type
../../../../src/appl/gssftp/ftp/cmds.c: at line 205
../../../../src/appl/gssftp/ftp/cmds.c: at line 208
../../../../src/appl/gssftp/ftp/cmds.c: at line 211
../../../../src/appl/gssftp/ftp/cmds.c: at line 213
../../../../src/appl/gssftp/ftp/cmds.c: at line 228
I have no idea what I'm supposed to glean from these errors, but everything works normally, expect for the issues below; I can successfully edit and save files.
I can turn this opening of windows off with :let g:netrw_use_errorwindow=0 (I also have to :set cmdheight=2 or else I have to press enter every time I save). This apparently just closes the window automatically almost immediately after it coming up; I can see the flash of the window coming up and then vanishing.
This wouldn't be a problem on it's own, but when I do this, every time I save, a buffer is apparently created (driving up my buffer numbers on any files I later open), and as I continue to edit and save, things slowly start breaking.
Syntax highlighting stops working (I have to press ^L a lot for a while, then it just starts breaking completely), and each successive write becomes slower and slower until it's unusable.
Worst of all, when I try to quit, I press "ZZ" as usual and it writes the buffer, but does not exit. :q doesn't work, :q! doesn't work. Even ^Z and then killing doesn't work (I have to kill -9 in order to get rid of it) If I :q!, I get these two error messages (simultaneously):
E37: No write since last change (add ! to override)
E162: No write since last change for buffer "ftp://calebegg.com/<other file I'm editing>"
(no, that's not a typo, I'm using :q! and it's telling me to add a !)
Switching to that file and trying from there is no good either; I get the same error message, except with the first file.
I would really appreciate any advice anyone has. Thanks.
--
Caleb Eggensperger
http://calebegg.com/
Ben Schmidt
> I only recently found out about netrw, and it seems like an amazing
> feature. However, I've been having some issues with it. Specifically,
> whenever I try to open or save a file, a window opens up with this content:
>
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 175
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 177
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 192
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 194
> This security scheme is not implemented
> This security scheme is not implemented
> KERBEROS_V4 rejected as an authentication type
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 205
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 208
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 211
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 213
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 228
This looks like a GSSAPI problem to me in your ftp client.
Does it happen if you use the ftp command line utility manually?
If so, that confirms it. See if there are any clues in the utility as to
whether it's a local or remote error. I expect local, but it may be
worth checking. If local, I'd recommend reinstalling ftp and/or gssapi
using your package management system, and make sure you supply all the
necessary flags to enable all the authentication types you need. Or
maybe you need to omit the ones you don't need. Which OS and version are
you on?
Though if everything is working, maybe it doesn't matter. Perhaps an
unneeded but possible authentication method is unsupported/
unimplemented. Still, it's odd that these warnings are spat out. If
something like that isn't compiled in, the user isn't usually told about
it unless the authentication actually fails, unless there's a software
bug or debugging is enabled or something.
> I have no idea what I'm supposed to glean from these errors, but
> everything works normally, expect for the issues below; I can
> successfully edit and save files.
>
> I can turn this opening of windows off with :let
> g:netrw_use_errorwindow=0 (I also have to :set cmdheight=2 or else I
> have to press enter every time I save). This apparently just closes the
> window automatically almost immediately after it coming up; I can see
> the flash of the window coming up and then vanishing.
>
> This wouldn't be a problem on it's own, but when I do this, every time I
> save, a buffer is apparently created (driving up my buffer numbers on
> any files I later open), and as I continue to edit and save, things
> slowly start breaking.
>
> Syntax highlighting stops working (I have to press ^L a lot for a while,
> then it just starts breaking completely), and each successive write
> becomes slower and slower until it's unusable.
Hmmm. That sounds nasty. Could you post the output of :ls! for us to
examine? I find this odd, because ordinarily buffer numbers just going
up isn't a problem, as long as the earlier buffers are fully deleted,
and even then, often it's no problem.
To capture the output of :ls! you can do something like
:redir > somefile
:ls!
:redir END
and then send us somefile.
> Worst of all, when I try to quit, I press "ZZ" as usual and it writes
> the buffer, but does not exit. :q doesn't work, :q! doesn't work. Even
> ^Z and then killing doesn't work (I have to kill -9 in order to get rid
> of it)
This is perhaps normal. The default TERM signal of kill can be caught,
and Vim does so, and just tidies up and dies when it receives it--but
not if it's suspended. I expect if you do ^Z then kill vim, then do fg
to bring Vim back to the foreground, it will pick up the signal and die
at that point. The KILL of kill -9 can't be caught, so Vim dies
immediately when you issue the kill.
> If I :q!, I get these two error messages (simultaneously):
>
> E37: No write since last change (add ! to override)
> E162: No write since last change for buffer
> "ftp://calebegg.com/<other file I'm editing>"
>
>
> (no, that's not a typo, I'm using :q! and it's telling me to add a !)
>
> Switching to that file and trying from there is no good either; I get
> the same error message, except with the first file.
This is what happens when a hidden buffer is modified, which I suspect
is what is happening here.
What is the value of your 'hidden' option and how do you switch between
your files?
You can do :qa! to exit Vim by ignoring changes made in *all* buffers,
hidden or not. Let us know whether that works, as it will at least
confirm my theory about a modified hidden buffer causing this behaviour.
Cheers,
Ben.
Charles E Campbell Jr
> I only recently found out about netrw, and it seems like an amazing
> feature. However, I've been having some issues with it. Specifically,
> whenever I try to open or save a file, a window opens up with this
> content:
>
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 175
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 177
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 192
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 194
> This security scheme is not implemented
> This security scheme is not implemented
> KERBEROS_V4 rejected as an authentication type
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 205
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 208
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 211
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 213
> ../../../../src/appl/gssftp/ftp/cmds.c: at line 228
>
These errors are not generated by netrw. Try using ftp manually and see
if you get them; I suspect you have some local configuration issues.
>
>
> I can turn this opening of windows off with :let
> g:netrw_use_errorwindow=0 (I also have to :set cmdheight=2 or else I
> have to press enter every time I save). This apparently just closes
> the window automatically almost immediately after it coming up; I can
> see the flash of the window coming up and then vanishing.
Errors/Warnings/Notes are either issued to a separate error window
(default behavior, g:netrw_use_errorwindow == 1) or they use echoerr
messages. You can see such messages later with :messages . I've done
it this way because I just can't seem to get messages to show up
reliably otherwise. Netrw is not "just closing the window automatically
almost immediately"; it is using echomsg (with g:netrw_use_errorwindow
== 0).
Hmm -- there is a separate window/buffer made to temporarily hold the
commands being sent to ftp, and vim's filter mechanism is used to send
the commands along. However, if there's an error with the ftp
operation, as you're clearly having, Netrw calls netrw#ErrorMsg() with
the first line of the message(s). Given your setting, that message is
echomsg'd instead of being sent to a separate window. However, the
window/buffer holding the ftp commands is then "bd"d -- buffer deleted.
This latter operation always occurs during an ftp operation.
>
> This wouldn't be a problem on it's own, but when I do this, every time
> I save, a buffer is apparently created (driving up my buffer numbers
> on any files I later open), and as I continue to edit and save, things
> slowly start breaking.
Please use redir with ls! so I can see what buffers are being left
behind. I won't be around for the next two weeks, so this will take
awhile. If you can get your ftp to work correctly then these problems
will disappear, too.
Regards,
Chip Campbell
Caleb Eggensperger
look into that to see if there's anything I can do about it. I'm
running ubuntu dapper.
The output of ls! after opening two files and then repeatedly writing them is:
:ls!
1 %a + "ftp://calebegg.com/countdown2.xml" line 1
2 h "[No Name]" line 0
5u "/tmp/v821660/8.xml" line 1
6 h + "ftp://calebegg.com/countdown_content/cd_msg_en.xml" line 1
7u "[No Name]" line 1
9u "/tmp/v821660/12.xml" line 1
10u#h "[No Name]" line 1
11u "[No Name]" line 1
12u "[No Name]" line 1
13u "[No Name]" line 1
14u "[No Name]" line 1
[...]
31u "[No Name]" line 1
As far as the twitchy window opening every time I write, it seems to
contain the same output as the original window; that's why I assumed
it was just opening and then immediately closing it.
Thanks for your help
--
Caleb Eggensperger
http://calebegg.com/