O GVIM trava ao salvar através do FTP do GVFS

5

Adorei a integração do Gnome com o Nautilus e o FTP e consegui montar um diretório de FTP remoto como um marcador / diretório comum e clicar duas vezes em qualquer arquivo remoto para abrir em qualquer programa não modificado. Eu também adorava editar arquivos de texto com o GVim.

No entanto, se eu clicar duas vezes no arquivo no Nautilus para abrir um arquivo de texto no Gvim, o salvamento de um arquivo levará cerca de 10 segundos e o GVim ficará interrompido por esse tempo. O maior irritante é que não posso continuar editando enquanto o editor de texto está aguardando a gravação terminar, esse atraso interrompeu meu fluxo de trabalho e o processo de raciocínio e a economia se torna um processo doloroso. O outro problema é que eu não acho que o upload de um arquivo deva demorar tanto tempo.

Estou ciente do suporte FTP interno do GVim, mas eles não estão tão bem integrados ao FTP do Nautilus e sofrem do mesmo problema.

Então, algumas perguntas:

  1. Existe uma maneira de salvar o GVim ou o GVFS em segundo plano enquanto eu continuo editando?
  2. Por que o GVFS é tão lento? Existe alguma maneira de configurar o GVFS para usar uma única conexão FTP persistente em vez de criar uma nova conexão FTP a cada vez?

Estou no Gentoo Linux x86-64.

    
por Lie Ryan 08.05.2011 / 17:09

2 respostas

0

Infelizmente eu não acho que você vai encontrar uma solução para isso, pelo menos não facilmente. Meu entendimento é que é uma função do sistema de arquivos virtual - bloqueia as gravações até que sejam concluídas com sucesso ou com falha, de modo que possam ser relatadas com precisão ao aplicativo.

Eu tenho (como user55325) experimentado isso com o Kate e SFTP, também com um número de outros aplicativos, parece ser o jeito que funciona.

Como minha VPN para o trabalho é bastante lenta, tive que desistir de editar arquivos dessa maneira quando estava trabalhando em casa e tive que recorrer ao rsync para grandes projetos.

    
por 29.06.2011 / 02:21
0

Supõe-se que você já tenha descontado o plug-in netrw que (pelo menos no Debian e Ubuntu) é distribuído com o tempo de execução do Vim. Este parece ser o caminho certo para fazer as coisas, a menos que você precise que o arquivo pareça ser local por algum motivo.

Se você quiser tratar um arquivo remoto como local, você pode estar melhor com um sistema VFS mais configurável que o gvfs. Por exemplo, você pode considerar os módulos FUSE curlftpfs ou avfs . O primeiro definitivamente permite a reconexão quando uma conexão atinge o tempo limite e é bastante bem documentada.

Realmente parece que o seu problema é porque o gVim acha que seu arquivo é local quando não está, e faz a coisa correta quando a E / S está bloqueada esperando a abertura de uma conexão FTP. Usar uma montagem FUSE que mantenha uma conexão persistente ou usar o plug-in netrw adequadamente deve resolver esses problemas para você.

Você deseja que um aplicativo bloqueie gravações com falha. A montagem por software só deve ser usada para dados somente leitura, portanto, mesmo se o Vim oferecer tal comportamento, não seria uma boa ideia confiar nele.

    
por 20.04.2012 / 18:47