História do Vim e um guia para seu uso efetivo

Nota do tradutor: esta é a primeira parte do artigo monumental (na verdade monumental) sobre o Vim e suas capacidades do desenvolvedor de Minneapolis e do autor do projeto PostgREST, Joe begriffs Nelson.

A primeira parte do artigo é dedicada ao conhecimento da história do Vim como editor, e o autor fala sobre vários fatos interessantes sobre os recursos do Vim. Na segunda parte da tradução, todos os chips e hackers que Joe decidiu compartilhar com o público estarão concentrados. A narrativa, como tal, desaparece e resta apenas um conjunto de diretrizes para a ação. Como o texto original tem dimensões completamente inaceitáveis, dividimos essa história em dois artigos de aproximadamente o mesmo tamanho. Hoje é a primeira de duas publicações. Boa leitura.

---

Este artigo é baseado na pesquisa da história do Vim e na leitura do manual do usuário, capa a capa. Espero que essas notas o ajudem a descobrir (ou redescobrir?) As funcionalidades básicas deste editor para você, além de permitir que você abandone o uso de arquivos vimrc avisados ​​e use plugins com mais atenção.

Referências

Para ir além dos tópicos usuais, eu recomendaria obter uma cópia em papel deste manual e uma ampla referência de bolso. Como não consegui encontrar uma cópia impressa do guia do usuário do Vim, acabei imprimindo o arquivo PDF que acompanha o editor usando o printme1.com. $VIMRUNTIME/doc/usr_?? vem com software em $VIMRUNTIME/doc/usr_?? . Como uma lista conveniente de comandos, posso aconselhar o livro de referência “Vi and Vim Editors Pocket” .

Conteúdo

• A história
• Hierarquia de configuração
• Plugins de terceiros
• Backups e propinas
• Incluir e caminho
• Editando e compilando um loop
• Diffs and Patches
• Buffer de entrada / saída
• Tipos de arquivo
• Não esqueça o mouse
• Diversos

A história

Nascimento vi

Os comandos e funções do Vi existem há mais de cinquenta anos, começando com o editor QED. Aqui está sua linha do tempo:

• 1966: QED (Quick Editor) no Berkeley Timesharing System
• Julho de 1969: com sua ajuda, eles pousaram na lua (bem, para referência)
• Agosto de 1969: QED → ed na AT&T
• 1976 fev: ed → em ("Editor de mortais") no Queen Mary's College
• 1976: em → ex ("estendido") na Universidade da Califórnia, Berkeley
• 1977 Out: ex recebe o modo visual, vi - terminal de texto

Se você ler o manual QED e ex , poderá encontrar algumas semelhanças entre eles. Ambos os editores usam gramática semelhante para indicar e trabalhar com intervalos de linhas.

Editores como QED ed e em foram projetados para terminais de impressão, que em sua maioria eram máquinas de escrever elétricas comuns com um modem conectado a eles. Esses terminais de "copiadora completa" exibiam comandos no papel e, obviamente, após a entrada, era impossível fazer correções. Portanto, o processo de edição consistiu em editar manualmente os comandos do usuário no papel e depois inseri-los novamente.

Em 1976, os terminais de vídeo, por exemplo, ADM-3A, apareceram. Um "modo aberto" foi adicionado ao editor Ex, o que permitiu a edição através de um terminal de vídeo em uma única página. Um modo visual foi adicionado para orientar nas linhas do terminal usando o cursor. O modo visual foi ativado pelo comando “vi” e atualizou constantemente o arquivo exibido na tela, mantendo o posicionamento da linha de comando na parte inferior da tela. Fato interessante: as setas foram colocadas nas teclas h, j, k, l no ADM-3A, o que nos permitiu mover o cursor para vi.

Você pode aprender mais sobre essa transição de ed para ex / vi em uma entrevista com Bill Joy . Nele, ele fala sobre como ele criou o ex / vi e sobre algumas coisas que acabaram por desapontá-lo.

O vi clássico é apenas uma alteração é ex. Ambos são representados pelo mesmo arquivo binário, que pode ser executado nos modos ex e vi, dependendo do nome do arquivo executável. O legado de toda essa história é que o ex / vi “se desdobra” quando usado, quase não requer recursos do sistema e pode funcionar em condições de largura de banda limitada. Também está disponível na maioria dos sistemas existentes e é totalmente descrito no POSIX.

Vi para vim

Derivado de ed, o ex-editor era a propriedade intelectual da AT&T. Para usar o vi em plataformas diferentes do Unix, as pessoas precisavam escrever clones com uma base de código fonte diferente.

Aqui estão alguns deles:

• nvi - 1980 para 4BSD
• calvin - 1987 para DOS
• vil - 1990 para DOS
• stevie - 1987 para Atari ST
• elvis - 1990 para Minix e 386BSD
• vim - 1991 para Amiga
• viper - 1995 para o Emacs
• elwin - 1995 para Windows
• lemmy - 2002 para Windows

Vamos nos concentrar no clone do centro da lista - Vim. Bram Mulenaar queria usar o vi no Amiga e começou a trabalhar com a Atari e a desenvolver o stevie do clone do vi. E ele nomeou sua versão do porto "Vi Imitation". Se você quiser aprender sobre esse processo em primeira mão, assista à entrevista dele na Free Software Magazine.

Na versão 1.22, o Vim foi renomeado como "Vi IMproved", que indica a superioridade da cópia sobre o original. Aqui está um gráfico das seguintes versões principais, com descrições de alguns recursos:



Para obter mais informações sobre cada versão, deve-se usar ajuda, por exemplo, para o vim8. Para ver as atualizações planejadas, bem como uma lista de erros conhecidos, você deve acessar todo.txt.

Por exemplo, a oitava versão incluía algum suporte para trabalhos assíncronos devido à pressão no projeto do NeoVim. Os desenvolvedores deste último queriam executar a depuração e o REPL para scripts da web dentro do editor.

Geralmente o Vim é superportável. Adaptando toda a história de sua existência para trabalhar em plataformas completamente diferentes, este editor foi forçado a permanecer dentro da estrutura da cultura "fácil" de codificação. O Vim é executado no OS / 390, Amiga, BeOS e BeBox, Macintosh Classic, Atari MiNT, MS-DOS, OS / 2, QNX, RISC-OS, BSD, Linux, OS X, VMS e MS-Windows. Você pode confiar no Vim em qualquer lugar e não se importa com o equipamento que usa.

No final do caminho original do vi, em 2002, o código fonte ex / vi ainda era publicado sob a licença do software livre BSD. Feiticeiros estão disponíveis em ex-vi.sourceforge.net .

Mas vamos ao que interessa. Antes de começar a analisar o Vim, é útil saber como ele organiza e lê seus arquivos de configuração.

Hierarquia de configuração

Anteriormente, eu acreditava erroneamente que o Vim obtém todas as suas configurações e scripts apenas do arquivo .vimrc. Visualizar repositórios de “arquivos de ponto” aleatórios só pode reforçar essa opinião. Muitas vezes, as pessoas enviam monstruosamente arquivos .vimrc únicos cuja tarefa é controlar todos os aspectos do editor. Essas configurações enormes também são chamadas de “vim distros”.

De fato, o Vim possui uma estrutura elegante na qual .vimrc é apenas um dos muitos "pontos de entrada". De fato, você mesmo pode perguntar ao Vim quais scripts ele carrega. Para fazer isso, edite algum código-fonte para um projeto aleatório em sua máquina, faça o download e execute o comando

 :scriptnames 

Vale a pena ler esta lista. Tente adivinhar o que esses scripts fazem e anote os diretórios em que estão localizados.

A lista foi mais longa do que você esperava? Se você instalou muitos plugins, o editor tem muito o que fazer. Verifique se ele fica mais lento na inicialização executando o seguinte comando de criação start.log:

 vim --startuptime start.log name-of-your-file 

Basta comparar a rapidez com que o Vim começa a partir da caixa:

 vim --clean --startuptime clean.log name-of-your-file 

Para determinar quais scripts devem ser carregados na inicialização ou durante o carregamento do buffer, é necessário verificar o caminho do tempo de execução do Vim. Esse caminho é representado por uma lista de diretórios separados por vírgula, cada um dos quais contém uma estrutura comum. O Vim verifica essas estruturas em cada diretório para encontrar seus scripts de inicialização. Os diretórios são processados ​​estritamente na ordem em que estão localizados na lista.

Verifique o caminho de execução no seu sistema através deste comando:

 :set runtimepath 

Meu sistema contém os seguintes diretórios especificados por padrão para verificação do caminho de execução. Nem todos eles existem, mas o Vim ainda tentará acessá-los e verificará o conteúdo se eles ainda estiverem no local:

~/.vim
Diretório inicial, projetado para perfis criados.

/usr/local/share/vim/vimfiles
Diretório Vim em todo o sistema, para perfis com privilégios de administrador do sistema.

/usr/local/share/vim/vim81
Aka $ VIMRUNTIME, para arquivos distribuídos com o Vim.

/usr/local/share/vim/vimfiles/after
No diretório Vim em todo o sistema, também existe o diretório after. Pretende-se adicionar as configurações pessoais do administrador do sistema "padrão".

~/.vim/after
O diretório "depois" no diretório inicial. Isso é necessário para que as configurações pessoais não cancelem ou se sobreponham às configurações de todo o sistema ou "padrão".

Em geral, os diretórios são processados ​​na mesma ordem em que são gravados no start.log, uma exceção é feita apenas para "after". Este está sempre no final da lista e é processado por último.

Ao processar cada diretório, o Vim procura subpastas neles com nomes específicos. Para saber mais sobre isso, consulte a ajuda runtimepath. Aqui está uma breve descrição daqueles que consideraremos mais adiante no texto:

plugin /
Aqui estão os arquivos de script do Vim que são carregados automaticamente ao editar qualquer tipo de arquivo. Eles também são chamados de "global".

autoload /
(Não deve ser confundido com "plugin"). Esses scripts de inicialização contêm funções que são reforçadas apenas a pedido de outros scripts.

ftdetect /
Scripts para determinar os tipos de arquivo. Em seu trabalho, eles contam com a extensão, local ou conteúdo interno do arquivo.

ftplugin /
Scripts que são executados ao editar arquivos de um tipo conhecido.

compiler /
Determina como executar vários compiladores ou verificações de fiapos e como analisar sua saída. Pode ser dividido entre vários plug-ins de uma vez. O compilador não é executado automaticamente e deve ser chamado por um comando.

pack /
Um contêiner para pacotes nativos do Vim 8, o sucessor do gerenciamento de pacotes no estilo Pathogen. Possui sistema de empacotamento próprio, não requer código de terceiros para funcionar.

E finalmente, ~ / .vimrc é uma armadilha para as configurações gerais do editor. Usado para definir as configurações padrão, que podem ser atribuídas a um tipo específico de arquivo. Para visualizar a lista inteira, você pode selecionar .vimrc e executar o comando options.

Plugins de terceiros

Os plug-ins são apenas scripts do Vim, para os quais basta colocá-los nos lugares corretos no caminho de execução. Em geral, o processo de instalação é extremamente simples: basta fazer o upload do (s) arquivo (s). O problema é que alguns plugins são bastante difíceis de atualizar ou remover, porque estão espalhados em subdiretórios diferentes e obstruem os caminhos de execução com seus scripts. Ou seja, no final, é difícil determinar qual arquivo pertence a qual plugin.

Para resolver esse problema, os "gerenciadores de plugins" começaram a se desenvolver. No vim.org, havia um registro de plugins pelo menos até 2003, inclusive (se o arquivo não estiver mentindo). No entanto, os "gerenciadores de plug-ins" como entidade entraram em moda somente em 2008.

Essas ferramentas adicionam diretórios especiais para plug-ins para rastrear caminhos de execução e organizar tags pelas quais os plug-ins podem ser rastreados. A maioria dos gerentes também obtém atualizações de plugins da rede.

Abaixo, construí gerenciadores de plugins de acordo com a cronologia de sua ocorrência. Com base nos intervalos de datas de lançamento da primeira e da última versão. Se não havia lançamentos oficiais, tomei como base as primeiras datas de lançamento e a última atualização.

• Mar. 2006 - Jul. 2014: Vimball
• Out 2008 - dez 2015: Pathogen
• Ago 2009 - Dez 2009: Vimana
• Dez 2009 - Dez 2014: VAM
• Ago 2010 - Nov 2010: Jolt
• Oct. 2010 - Nov. 2012: tplugin
• Outubro de 2010 - fevereiro de 2014: Vundle
• Mar 2012 - Mar 2018: vim-flavor
• Abril de 2012 - março de 2016: NeoBundle
• Janeiro de 2013 - agosto de 2017: infectar
• Feb. 2013 - Aug. 2016: vimogen
• Out 2013 - Jan 2015: vim-unbundle
• Dec 2013 - Jul 2015: Vizardry
• Feb. 2014 - Oct. 2018: vim-plug
• Janeiro de 2015 - outubro de 2015: facilitador
• Aug. 2015 - Apr. 2016: Vizardry 2
• Janeiro de 2016 - junho de 2018: dein.vim
• Setembro de 2016 - o momento: nativo no Vim 8
• Feb. 2017 - Sep. 2018: minpac
• Mar 2018 - Mar 2018: autopac
• Fev 2017 - Jun 2018: pack
• Mar 2017 - Sep 2017: vim-pck
• Sep. 2017 - Sep. 2017: vim8-pack
• Sep. 2017 - maio de 2019: volt
• Sep. 2018 - Feb. 2019: vim-packager
• Fevereiro de 2019 - fevereiro de 2019: plugpac.vim

A primeira coisa que você precisa prestar atenção na lista acima é a enorme variedade. A segunda - cada uma das ferramentas apresentadas está “viva” há cerca de quatro anos e, muito provavelmente, sai de moda.

O caminho de menor resistência no gerenciamento de plug-ins é simplesmente usar a funcionalidade interna do Vim 8, que não exige a obtenção de nenhum código de terceiros. Vamos ver como fazer isso.

Para começar, crie dois diretórios dentro do seu runtimepath: opt e start.

 mkdir -p ~/.vim/pack/foobar/{opt,start} 

Preste atenção ao espaço reservado "foobar" (o nome pode ser alterado). Classifica completamente todos os pacotes que entram. A maioria dos usuários simplesmente despeja todos os seus plugins em qualquer categoria e, em geral, isso é normal. Escolha qualquer nome que você quiser; Vou continuar usando foobar. Em teoria, você também pode criar várias categorias, por exemplo ~/.vim/pack/navigation e ~/.vim/pack/linting . Observe que o Vim não reconhece duplicação entre categorias e baixa duplicatas duas vezes, se existirem.

Pacotes em "start" são carregados automaticamente, enquanto pacotes em "opt" não são carregados até que sejam do Vim usando o comando :packadd . Essa opção é boa para pacotes raramente usados ​​e é suportada pelo Vim imediatamente, sem a necessidade de executar scripts. Observe que :packadd não :packadd contrapartida para descarregar pacotes.

Para revisar este exemplo, adicionaremos o plug-in de pesquisa difusa ctrlp para optar. Baixe e descompacte sua versão mais recente em:

 curl -L https://github.com/kien/ctrlp.vim/archive/1.79.tar.gz \ | tar zx -C ~/.vim/pack/foobar/opt 

Este comando criará a ~ / .vim / pack / foobar / opt / ctrlp.vim-1.79 pacote pronto para uso. Volte ao vim e crie os ponteiros da tag de ajuda (índice de helptags) para o novo pacote:

 :helptags ~/.vim/pack/foobar/opt/ctrlp.vim-1.79/doc 

Este comando criará um arquivo chamado "tags" na pasta com os tipos de pacote, que disponibilizam temas para visualização no sistema interno do Vim. Forma alternativa: execute helptags ALL depois de baixar o pacote, e o comando cuidará de todos os arquivos e seus caminhos de execução.
Quando quiser usar um pacote, faça o download e lembre-se de que, nesse caso, a terminação funciona usando guias, para que você não precise digitar o nome completo:

 :packadd ctrlp.vim-1.79 

O diretório base do Packadd está no runtimepath, que permite usar scripts de seu plug-in e ftdetect. Após carregar o ctrlp, você pode usar o comando CTRL-P para abrir a pesquisa de arquivos por correspondência parcial.

Algumas pessoas controlam seu diretório ~ / .vim e usam o git para controlar a versão de cada pacote. Da minha parte, apenas descompacte os pacotes dos arquivos tar e os rastreio manualmente através do repositório. Se você usar pacotes suficientemente maduros que não exijam atualizações frequentes, bem como scripts, eles serão bem pequenos e não farão bagunça no histórico do git.

Backups e reversões de versões

Dependendo das preferências do usuário, o Vim pode protegê-lo de quatro causas possíveis de perda de dados:

1. Falha ao editar (entre salvamentos). O Vim pode se proteger contra isso salvando periodicamente as alterações no arquivo de paginação.
2. Proteção contra a edição do mesmo arquivo com duas instâncias do Vim, proteção contra a substituição de alterações feitas por uma ou mais instâncias. Isso também é feito através do arquivo de troca.
3. Falha durante o próprio processo de salvamento após alterar o arquivo final, mas até que o novo conteúdo seja completamente gravado. O Vim pode protegê-lo disso com a função writebackup. Para fazer isso, ele cria no processo de salvar um novo arquivo, que posteriormente substitui o original, se tudo correu bem. O método de substituição é determinado pela configuração de cópia de segurança.
4. Salvando o novo conteúdo do arquivo, desde que o original seja restaurado. O Vim permite salvar uma cópia de backup de um arquivo após fazer alterações.

Mas antes de começar a explorar essas configurações inteligentes, que tal algumas piadas? Aqui estão alguns comentários de amostra dos arquivos vimrc no GitHub:

“Não crie um arquivo de paginação. Gerencie tudo através do controle de versão. ”
“Backups para exilados. Use o controle de versão. ”
"Somente controle de versão!" Apenas hardcore!
"Vivemos em um mundo de controle de versão, portanto, as trocas e os backups estão no lixo".
"Por que você precisa de arquivos de backup se o controle de versão é suficiente."
"Eu nunca usei arquivos de backup do Vim ... Use o controle de versão."
"A maioria das coisas pode ser encontrada através do controle de versão".
"Desative backups de arquivos, porque você ainda usa o sistema de controle de versão;)".
"E o controle de versão veio, e o Git nos salvou."
“Desative arquivos de troca e sistema de backup. Sempre use o controle de versão! SEMPRE! ”
"Não preciso de backup, porque trabalho com controle de versão".

A ironia é que os comentários acima refletem apenas uma compreensão do quarto e, em parte, do terceiro tipo de falha. Se você recusar o arquivo de troca e o backup, perderá a proteção no caso descrito nos parágrafos 1 e 2.

Aqui está um exemplo de configuração que eu recomendo para uma operação segura:

 " Protect changes between writes. Default values of " updatecount (200 keystrokes) and updatetime " (4 seconds) are fine set swapfile set directory^=~/.vim/swap// " protect against crash-during-write set writebackup " but do not persist backup after successful write set nobackup " use rename-and-write-new method whenever safe set backupcopy=auto " patch required to honor double slash at end if has("patch-8.1.0251") " consolidate the writebackups -- not a big " deal either way, since they usually get deleted set backupdir^=~/.vim/backup// end " persist the undo tree for each file set undofile set undodir^=~/.vim/undo// 

Essas configurações incluem backups para gravações incompletas, mas não salvam arquivos após a conclusão da operação, porque temos controle de versão, o melhor controle de versão, blá blá blá, etc. etc. Observe que você pode precisar de mkdir ~ / .vim / {swap, undodir, backup}; caso contrário, o Vim acessará a próxima pasta legível. Você provavelmente também precisará executar o comando chmod nas pastas de destino para que seu conteúdo seja privado, pois os arquivos de troca e o histórico de backup podem conter informações confidenciais.

Vale ressaltar que o recurso de nossos caminhos de configuração é que eles sempre fecham com uma barra. Essa ortografia permite que a função elimine a possível ambiguidade nos caminhos dos arquivos de paginação e backup para arquivos com os mesmos nomes, que estão em diretórios diferentes. Por exemplo, o arquivo de troca para / foo / bar será salvo em ~ / .vim / swap /% foo% bar.swp (escapei de barras com sinais de porcentagem). Houve um bug no patch recente do Vim que impediu que a barra fosse levada em consideração para o backupdir, portanto, a proteção contra ela é mostrada acima.

Nosso Vim também salva o histórico de reversão para cada arquivo, para que você possa restaurar a versão correta mesmo após sair do modo de edição. Embora essa função possa parecer redundante no fundo do arquivo de troca que já temos, o histórico de reversão é uma linha de defesa adicional durante a gravação do arquivo.

Quando falamos de reversões, vale lembrar que o Vim suporta uma árvore completa do histórico de edição de arquivos. Isso significa que você pode fazer uma alteração, reverter e repetir as mesmas alterações novamente, e tudo isso serão três pontos de recuperação diferentes. O tempo e a extensão das alterações feitas podem ser verificados usando o comando undolist, mas é problemático remover a árvore. : 5 , . , — , undotree — .

. . : . , .

: , ,vim . nowritebackup, , . , Vim , . backupskip .

«patchmode» Vim . , . , tar-, , git. set patchmod = .orig foo- foo.orig.

Include path

(include) . Vim path, include, suffixesadd, includeexpr. (. help include-search) — ctags .

. , . , help include .

, [i , , [d . gf Vim . :find, **/* , . , .. , .

, . ( ) CTRL-D. .

 " fuzzy-find lite nmap <Leader><space> :e ./**/ 

: path (headers) . , : checkpath, , . C checkpath. , , . , checkpath , .

«., / Usr / include ,,» . , — /usr/include, . , :help file-searching .

ftplugin ( ) , . : ./src/include ./include.

 setlocal path=.,,*/include/**3,./*/include/**3 setlocal path+=/usr/include 

«**3» — . , . , .

, , :checkpath , . , , .

: :he [, :he gf, :he :find .

---

.