Vim

Neste breve post gostaria de por algumas referências onde vocês podem consultar algumas dicas de vim, o editor. Assim, quem está começando a brincar com esta excelente ferramenta, já saberá por onde começar!

• vimgrep, uma forma de busca bem eficiente
• Vim e screen para pair programming
• Usando vim para criar apresentações Power Point
• produtivo no vim com 15 dicas
• mais 17 dicas no screencast do Lucas Catón
• e mais 3 dicas do Core Code
• mais 17 dicas, agora do Garotosopa

Se você tiver mais dicas

, não deixe dizê-la nos comentários!

Hoje em dia está cada vez mais comuns a hospedagem de plugins para vim em repositórios remotos, como o github.com e o bitbucket.com. O problema da instalação destes plugins é que é necessário clonar o repositório e manualmente mover os arquivos para os respectivos diretórios, dentro do ~/.vim/.

A atualização destes plugins acaba sendo uma tarefa negligenciada, pois demanda um esforço muito grande. Isto, sem considerar a necessidade da atualização, pois seria necessário visitar todos os sites dos plugins vendo se há a necessidade de atualização.

Com o pathogen.vim, a coisa muda um pouco de perspectiva. O plugin cria um diretório chamado bundle dentro do ~/.vim/. Dentro deste diretório é permitido criar subdiretórios que contenham a mesma hierarquia contida em ~/.vim/.

Olá! Descobri recentemente que é possível baixar a documentação do PHP no formato do man do UNIX. Isso é muito bom, já que assim, podemos consultar funções com parâmetros, variáveis e exemplos. Melhor, podemos fazer isso direto do Vim.

Eu já tinha lido sobre uma opção do Vim chamada keywordprg, mas nunca havia encontrado uma serventia. Quando eu li no blog do bjori, realmente me veio à mente como eu poderia utilizá-la.

A busca efetiva pode ajudar muito, caso bem usada, tanto no ganho de tempo como na efeciência de substituições ou refactories. Seguem alguns outros exemplos de finalidades para a busca utilizando o Vim:

• Certeza de encontrar todas as incidências
• Ficam visualmente destacadas (com :set hlsearch)
• Testar substituições
• Verificar a ortografia atrás de erros de digitação
• Encontrar variáveis ou funções não utilizadas, só declaradas
• Encontrar rapidamente algum termo
• Verificar a existência de algum termo

Além da conhecida / (barra) para buscar, existe o :vimgrep. É dele que quero falar.

Bem, é notável o crescimento das metodologias ágeis de desenvolvimento de software. Uma das práticas que me agrada muito, é a programação em pares (pair programming). É bem perceptível, a um longo prazo, a diferença que faz essa prática. Navegando pela internet, como um marujo sem rumo, encontrei um post falando sobre Remote Pair Programming. Parece meio estranho, porque o XP (eXtreme Programming) faz alusão a uma dupla programar em um único computador, com um único teclado e um único mouse.

Pois é, quem nunca mexeu com java que atire a primeira pedra. Trabalhar com java fora de um IDE é realmente muito ruim. Mas deveria eu criar uma IDE em modo texto para o Vim ou ver alguma solução para o meu problema no google?

Eu já sabia da existência, mas nunca tinha visto um motivo para fazê-lo. Trata-se do vim ou gvim dentro do Eclipse. Alguns motivos que me tentaram a usá-lo:

• Compilar é muito mais simples no eclipse.
• Achar arquivos em pacotes é mais fácil com o Project Browser
• Pode-se utilizar outros plugins do Eclipse, como o de modelagem pra Swing, AWT, etc
• Integração com o SVN

Essa semana eu precisei de uma apresentação Power Point. Abri o Impress, o editor de apresentações do OpenOffice. Comecei meu raciocínio sobre a apresentação. Quando me dei conta, estava colocando negrito e identando um parágrafo. Ao reler o parágrafo, havia 3 erros de gramática. Foi a gota d'água: Não consigo criar apresentações, pensei.

Quando eu vou escrever em algum programa de qualquer suíte de escritório - openoffice, koffice, etc -, eu geralmente me preocupo mais com o negrito da palavra, com identação do parágrafo do que com o conteúdo em si. Isso é um pecado.

Meu primeiro instinto foi: vou escrever tudo no Vim, depois colo no Impress. Boa! Ok, mas e quanto às páginas?
Vou ter que por página por página? Ainda sim eu teria mais trabalho. Eu teria que refazer as listas para que ficassem com as "bolinhas" à esquerda. E teria que modificar todos os títulos para negrito?

Olá! Eu estava pensando em usar o feriado pra aprender pyGTK, com um projeto que estou na cabeça. Mas, sexta-feira me surgiu outra idéia, que tocou mais forte.

Muita gente me perguntava o que eu punha no meu .vimrc, quais configurações e o que elas faziam. Então, pra ajudar o pessoal e também manter uma documentação (porque eu esqueço rápido essas coisas), eu criei o .vimrc generator.

Quantas vezes você faz um arquivo que é exatamente igual à um outro arquivo por dia? Quantas vezes você abre um arquivo só para copiar um trecho de código que é utilizado em vários arquivos? Quantas vezes você se vê fazendo a mesma coisa que fez em outro lugar?

E aquela palavra que você sempre escreve errada? Aquela função que você sempre esquece o nome?

Conheça algumas dicas para aumentar a produtividade e diminuir o trabalho dessas coisas rotineiras.

Em alguns projetos, ao se dar um commit, é necessário especificar quais arquivos foram adicionados ou modificados e ainda mencionar o porque. Algo do tipo:

functions.pl - Adicionada a função que faz aquilo e corrigida a função tal que tinha um erro de português.

É realmente um porre ver todos os arquivos que foram modificados e dizer as mudanças, mas é necessário. Aqui vai uma dica pra quem quer melhorar isso e, por que não, automatizar. Vou utilizar o exemplo com o svn, mas adaptem para o que vocês usam.

cd /raiz/do/repositorio
svn status | vim -