Using MacVim over ExpanDrive/MacFusion => very slow

[GoogleCodeExporter]

What steps will reproduce the problem?

Mount an external Server using sshfs (either ExpanDrive or MacFusion)
Make sure .vimrc is configured to handle backups and swaps locally via:

set backupdir=~/.vim/backups
set directory=~/.vim/swaps

What is the expected output? What do you see instead?

When opening a file on the remote directory, handling it is extremely slow, 
even on a 50 MBit/s 
connection. This includes scrolling, visual mode handling, mouse handling.

 Copying the file over to a local directory and editing it there is fast as usual. 

Using the command line 'vim' application shipped with MacOS does NOT show this 
problem, its 
fast as expected, so the symptoms come from a different behavior of the MacVim 
implementation.

What does MacVIM do differently than the normal vim INSIDE the directory of the 
file, even 
though backups and swaps are moved to a local position?

What version of MacVim and OS X are you using (see "MacVim->About MacVim"
and  "Apple Menu->About This Mac" menu items, e.g. "Snapshot 40, 10.5.6
Intel")?

Version 7.2 stable 1.2 (33.3)

Original issue reported on code.google.com by heiko.kopp@gmail.com on 22 Nov 2009 at 12:12

[GoogleCodeExporter]

Try starting MacVim without the GUI and see if the problem persists.  From 
Terminal, type:

/Applications/MacVim.app/Contents/MacOS/Vim

(Assuming you've put MacVim.app in the Applications folder.)

Do you still see the same problem?

Original comment by bjorn.winckler@gmail.com on 22 Nov 2009 at 5:38

[GoogleCodeExporter]

Hello,

thank you for your fast reply. I've tested it. I opened a file using the MacVim 
'Vim' in an xterm (to have 
scrolling support) and once again with the 'vim' application delivered by Mac 
OS. 

The problem occurs in Non-GUI Mode for the MacVim 'Vim'. The 'vim' delivered 
with Mac OS is fast and reacts 
as it should.

So it seems it is not directly related to the GUI component but something else. 
Hope this helps. Let me know if 
you need any other information.

Best regards.

Original comment by heiko.kopp@gmail.com on 24 Nov 2009 at 8:32

[GoogleCodeExporter]

It would seem that the problem was introduced into Vim after the version that 
comes with OS X (7.2.108 on my 
machine), since the Vim binary that comes with MacVim.app is newer.  There is a 
chance that this was fixed in a 
newer version of Vim, so you should first of all try downloading the latest 
snapshot (51 at the time of this 
writing) and see if that fixes the problem.

If not, you have to post to vim_dev and explain the problem there because I do 
not (in general) fix problems in 
core Vim.

Original comment by bjorn.winckler@gmail.com on 27 Nov 2009 at 6:49

[GoogleCodeExporter]

Uh, oh, I spoke too soon: the version of Vim that is in the stable build of 
MacVim.app is version 7.2, so the 
version that ships with Snow Leopard is actually newer than that (what version 
of Vim comes with your OS X?).  
You should still try the latest snapshot as it may contain a fix.

Original comment by bjorn.winckler@gmail.com on 27 Nov 2009 at 6:52

[GoogleCodeExporter]

Hello, thank you for pointing this out. The snapshot Version 51 solves this 
problem. The Version reacts as fast as 
the Snow Leopard internal 'vim' version does. Whatever led to this problem has 
been fixed :-)

Thanx!

Original comment by heiko.kopp@gmail.com on 28 Nov 2009 at 12:41

[GoogleCodeExporter]

Great!

Original comment by bjorn.winckler@gmail.com on 28 Nov 2009 at 1:56

• Changed state: Fixed

[GoogleCodeExporter]

Hello,

This problem still persists for me under Mac OS X 1.6.2 using MacVim snapshot 
51 and 
ExpanDrive 2.0.6. I have set my backupdir and swap directory in both .vimrc and 
.gvimrc to my local machine. I do not experience this problem with vim version 
7.2.108 
that ships with OS X 10.6.2, nor with 
/Applications/MacVim.app/Contents/MacOS/Vim.

Can you replicate this issue?

Original comment by blake.co...@gmail.com on 30 Jan 2010 at 10:33

[GoogleCodeExporter]

I don't have access to ExpanDrive so it will be a bit tricky to debug.  Have 
you gone through the first step of the 
ReportingBugs wiki page?

Original comment by bjorn.winckler@gmail.com on 31 Jan 2010 at 1:35

[GoogleCodeExporter]

I found out, that this is still a problem. It is not fixed (even not with 
version 52). But I found out that it only 
happens, in case the current directory (the one you set with :cd <dir>) is ON 
the fuse-sshfs share. If you for 
example do a :cd /Volumes, it works fast ... if the share is named foo and you 
do :cd /Volumes/foo, scrolling is 
SLOW as hell.

Maybe this helps a bit.

Original comment by heiko.kopp@gmail.com on 7 Mar 2010 at 2:16

[GoogleCodeExporter]

Please bring this problem up on vim_use, there may be some people on that group 
that can help figure out what 
is causing this slowness.

Original comment by bjorn.winckler@gmail.com on 7 Mar 2010 at 2:31

• Changed state: New

[GoogleCodeExporter]

Hmm I'm unsure as this only affects MacVim, NOT even the command line version 
of it. But if you think it helps, I 
will do so! 

Original comment by heiko.kopp@gmail.com on 7 Mar 2010 at 2:38

[GoogleCodeExporter]

I just tried installing MacFUSE + Macfusion.app and I cannot reproduce the 
problem you are describing.

I tried mounting a remote server via sshfs, then opened Terminal and browsed to 
/Volume/server and opened a 
2000 line .tex file on the remote server using "mvim".  Scrolling is as fast a 
always, visual selection is fast, etc.

Did you try eliminating possible rc-file problems as described in the 
ReportingBugs wiki?

Original comment by bjorn.winckler@gmail.com on 7 Mar 2010 at 3:10

[GoogleCodeExporter]

Hello,

I finally used the newest version of MacFUSE + macfusion.app as you did. This 
combination works. It seems the 
problem is related to ExpanDrive in a way it handles directory lookups. I 
opened a ticket at their website. Thank 
you! 

Original comment by heiko.kopp@gmail.com on 14 Mar 2010 at 1:42

[GoogleCodeExporter]

I'm glad it works...I'll close this issue again.

Original comment by bjorn.winckler@gmail.com on 14 Mar 2010 at 2:01

• Changed state: Invalid