Existe uma versão GUI do vim (gvim), incluindo uma para o Windows (assim como uma para o 'Cygwin' que roda no X-GUI (que também roda no Windows).
Eu tentaria o gvim nativo e verificaria se isso te dá a velocidade que você está procurando.
Nota: Eu não acho que os mais novos vims rodem no console (muitos problemas). (Esclarecimento: a versão do cygwin não roda no cmd.exe do Windows - sem suporte de terminal. Ele é executado em um emulador TTY regular, assim como os emuladores cygwin tty e sob o cygwin-X - o melhor seria provavelmente o cygwin. X - Eu executo as sessões do linux-gvim, exclusivamente através do X do cygwin. Minha conexão com o servidor é "interna" (não exposta à internet), então não preciso usar criptografia, por isso é muito rápido.
Para melhor responder a pergunta do pôster original, há algumas incógnitas - como o console do qual ele está falando e quando ele menciona zsh & bash, ele está falando sobre as versões cygwin, ou aquelas rodando sob o subsistema win10-linux, ou o quê?
Originalmente, o problema pode ser o console que você estava usando, por isso recomenda-se experimentar as versões nativas, mas quanto ao motivo pelo qual os consoles são mais lentos - eu falo sobre isso abaixo. Lembre-se: mesmo se você executar um console de texto - ainda é provável correndo na área de trabalho do Windows. Portanto, é uma emulação de GUI de uma janela de console de texto - não um console baseado em hardware real como os antigos consoles do DOS anteriores ao Windows costumavam ser (que usavam hardware gráfico para fazer rolagem, por exemplo). Quanto às versões nativas do vim:
Tente o link
Eu recomendaria esta versão: link
Se você não se importa em como colocar sua colagem mais rapidamente no vim, mas apenas quer saber por que o console é mais lento - o gui, pode aceitar texto colado diretamente sem passar por um único caractere Interface de leitura / gravação de caracteres simples (o console). Percorrendo o console envolve leitura & escrevendo caracteres únicos, 1 de cada vez. Ou seja a pasta entra no windows (o SO), o que a transforma em um fluxo de caracteres únicos enviados para o driver de entrada no console. Aqueles entram em um buffer de sistema (não vim). Então o vim tem que ler esses caracteres do sistema. Embora você possa ler / gravar vários caracteres, eles ainda são processados e exibidos 1 por vez pelo SW subjacente. Muito ineficiente. Quando o vim atualiza o console - ele está gravando os caracteres e emitindo códigos de tty-movement (não muito na entrada) para mover o texto. Tudo é tratado transformando ações gráficas em códigos de caracteres que são enviados para o console, que interpreta os códigos de caracteres para simular um TTY.
Além disso, ele ainda fará o processamento normal que o vim faz - mas para ver qual tem um impacto maior, executar a versão GUI do vim irá cortar todas as coisas do console.
No topo da lentidão normal de um console simulado, o console no Windows está sendo executado no Windows - e o Windows vem adicionando mais camadas de indireção desde o XP. Pelo menos 1 foi adicionado no XP, uma camada razoável pequena / rápida, mas indo para o vista / win7, muito perceptível por atraso-chave foi adicionado. Esses atrasos acontecem para cada chave! Pelo que entendi, mais camadas foram adicionadas ao Win10 para permitir nuvem & dispositivo remoto indireto.
No que diz respeito à pasta na versão GUI do vim - ele tem indirecções adicionadas, mas são para toda a mensagem de colar (não por caractere). Assim, o vim obtém todo o texto colado que pode processar sem atualizar a tela com cada caractere - portanto, apenas uma atualização de tela é necessária após o processamento do texto colado. Mais pode ser feito, dependendo da velocidade de processamento e da velocidade do vídeo - ou seja, o vim às vezes mostra um progresso parcial quando as coisas demoram mais, mas acredito que seja uma opção habilitada no vim.