VIM
Autor: Fileas Borja | Publicado: 2011-12-10T00:16:00-02:00

<?xml version="1.0"
      encoding="utf-8"
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">









Vim


Iniciei minha carreira como desenvolvedor de softwares h&aacute; 13 anos. Naquela
&eacute;poca a maioria dos aplicativos empresariais (sistemas administrativos,
cont&aacute;beis, etc) ainda era feito em Clipper, destinados &agrave; rodar em modo
DOS. Os poucos aplicativos que existiam em interface gr&aacute;fica foram criados com
Delphi ou Visual Basic. Este foi o meu in&iacute;cio.


No final de 1998 eu estava trabalhando em uma empresa que desenvolvia sistemas
tanto administrativos como cont&aacute;beis. Todas as aplica&ccedil;&otilde;es da empresa eram
feitas em Clipper e eram muito boas. A empresa tinha uma carteira muito grande
de clientes (mais de 500) e estava tentando entrar na era da interface
gr&aacute;fica. A ferramenta escolhida por eles foi o Visual Basic 4. A primeira
vers&atilde;o que rodava tanto em 16 bits como em 32 bits.


N&atilde;o sei quais foram os crit&eacute;rios que a empresa utilizou para esta escolha. Ela
ocorreu antes da minha entrada. Acredito que eu tenha sido contratado
justamente por causa desta escolha. O VB era famoso por gerar aplica&ccedil;&otilde;es que
comiam a mem&oacute;ria pelo do uso extensivo de objetos COM. Tamb&eacute;m era
muito mau visto porque n&atilde;o gerava execut&aacute;veis em c&oacute;digo nativo, mas sim em
pseudo c&oacute;digo, que necessitava de um run-time para ser executado. Por
essas e outras muitas das empresas que estavam mudando do ambiente DOS para
Windows acabaram escolhendo o Delphi (Borland, na &eacute;poca), em detrimento do VB
da Microsoft.


Bem, eu n&atilde;o conhecia bem o Delphi e confesso que nunca gostei da sintaxe do
Pascal. Eu j&aacute; havia feito alguns trabalhos em VBA (no Access) e por isso a
empresa me chamou para uma entrevista. Em pouco tempo j&aacute; tinha dominado a
ferramenta e logo ela se tornou ineficiente. Do Visual Basic 4 n&oacute;s passamos
para o Visual Basic 5 e houve certa melhora. Agora a linguagem j&aacute; era capaz de
gerar execut&aacute;veis em linguagem nativa, por&eacute;m o run-time ainda era
necess&aacute;rio.


Mas a inefici&ecirc;ncia da ferramente n&atilde;o vem deste ponto, mas sim de seu editor de
textos. Apesar de permitir certa configura&ccedil;&atilde;o, n&atilde;o era suficiente para me
satisfazer. Eu via meus colegas de trabalho, ainda usando DOS e seu editor
preferido, o DBFast, e eu ficava encantado com o modo como ele funcionava.
Tentei us&aacute;-lo para escrever c&oacute;digo em VB, mas houve um problema que me
impediu: a p&aacute;gina de c&oacute;digo. No DOS e no Windows os caracteres acentuados
possuem c&oacute;digos diferentes. Isso praticamente me proibiu de usar o editor.


Eu n&atilde;o me preocupava com a falta do syntax highlight. Isso n&atilde;o me
incomodava. Tamb&eacute;m n&atilde;o me importava com a falta do code insight. Eu
conhecia quase todos os eventos e m&eacute;todos dos objetos do VB de cor. Os que eu
n&atilde;o sabia encontrava no help. Alias, os sistemas de ajuda do Visual Basic
5 e anteriores eram excelentes. Infelizmente a Microsoft mudou para o formato
MSDN na vers&atilde;o 6, o que acabou estragando toda a organiza&ccedil;&atilde;o.  Ficou muito
mais dif&iacute;cil encontrar as coisas depois desta altera&ccedil;&atilde;o.


Bem, como eu estava dizendo, syntax highlight e code insight n&atilde;o me
faziam falta. O que eu realmente invejava no DBFast era sua capacidade de
configurar todas as teclas de atalho poss&iacute;veis, incluindo a cria&ccedil;&atilde;o de macros
para automatizar tarefas repetitivas. Claro que n&atilde;o me dei por vencido. Em
pouco tempo encontrei um editor pequeno, constru&iacute;do por um professor de l&oacute;gica
de uma faculdade Americana (Berkeley, eu acho), chamado Pfe (Programmers File
Editor). Era simples, sem syntax highlight e sem code insight e
totalmente gratuito. Abria arquivos em abas e era totalmente configur&aacute;vel,
eu poderia usar as teclas de atalho que quisesse. Tamb&eacute;m poderia criar macros
que ficavam gravadas entre sess&otilde;es que eu poderia reutilizar posteriormente.
Ele tamb&eacute;m me permitia criar comandos para executar programas externos. Eu
abria o Visual Basic, executava ou compilava a aplica&ccedil;&atilde;o tudo de dentro
do editor. Era fant&aacute;stico.


Usei o Pfe durante muito tempo. Num certo momento comecei sentir falta do 
syntax highlight, por causa dos erros de digita&ccedil;&atilde;o. Colocar as palavras
reservadas em cores diferentes facilita sua identifica&ccedil;&atilde;o. Tamb&eacute;m nos auxilia
na elimina&ccedil;&atilde;o de pequenos erros de digita&ccedil;&atilde;o.


Passei a procurar na Internet por poss&iacute;veis substitutos, e n&atilde;o foi uma tarefa
f&aacute;cil. Ele teria que ser gratuito (claro), ter teclas de atalho para todas as
opera&ccedil;&otilde;es poss&iacute;veis, possibilitar alterar estas teclas de atalho, permitir a
cria&ccedil;&atilde;o de macros para automatizar as tarefas repetitivas e ainda possibilitar
a execu&ccedil;&atilde;o de comandos DOS ou execu&ccedil;&atilde;o de programas externos.


N&atilde;o posso dizer que n&atilde;o encontrei op&ccedil;&otilde;es. Achei v&aacute;rias. Mas sempre faltava
alguma coisa. Em alguns eu n&atilde;o podia alterar certas teclas de atalho as quais
j&aacute; estava muito acostumado. Noutros faltava a op&ccedil;&atilde;o de criar macros ou outra
coisa qualquer. Naquela &eacute;poca o Scintilla ainda estava em est&aacute;gio alpha e
Notepad++ n&atilde;o era nem sonho. Bem, me dei por vencido quando encontrei o
Ultraedit. Acredito que a maioria dos desenvolvedores j&aacute; o conheceu. Por&eacute;m,
ele n&atilde;o &eacute; gratuito, como eu queria. N&atilde;o tive escolha sen&atilde;o pagar por uma
licen&ccedil;a.


O Ultraedit era, realmente, completo. Tinha todos os requisitos que eu
precisava em um editor de textos e ainda mais, vinha com um gerenciador de
projetos que permitia organizar os arquivos de forma hier&aacute;rquica independente
da estrutura de diret&oacute;rios onde eles se encontravam.


Os anos foram passando e eu sai daquela empresa e entrei em outra. Era o
"boom" da Internet no Brasil e eu queria aprender as tecnologias que estavam
na onda: HTML, JavaScript e ASP. Meu editor de textos me acompanhou nesta
jornada. Meu fiel escudeiro Ultraedit n&atilde;o me desapontou nestes novos desafios.
Confesso que esta fase da minha vida profissional foi bem tranquila. A WEB &eacute;
um lugar interessante. N&atilde;o h&aacute; ferramentas indispens&aacute;veis para se construir
conte&uacute;do para ela. Na &eacute;poca quase tudo o que tinha a ver com WEB era gratuito.
Mesmo os aplicativos das maiores empresas do mundo.


Por exemplo, a Microsoft dava de gra&ccedil;a seu encoder de v&iacute;deo, o
Windows Media Encoder. Claro que voc&ecirc; era obrigado &agrave; comprar uma c&oacute;pia do
Windows para utiliz&aacute;-lo. E l&oacute;gico que precisaria de um servidor WEB como o
IIS, contendo o Windows Media Server instalado para poder disponibilizar
estes arquivos. Mas estes s&atilde;o apenas detalhes.


Apesar da Macromedia ter entrado no mercado com seus aplicativos,
principalmente Flash e Dreamweaver, eu fui muito influenciado pelo que o meu
editor de textos j&aacute; fazia e o Dreamweaver nem sonhava: personaliza&ccedil;&atilde;o total.
Tamb&eacute;m havia outro problema com o aplicativo, se voc&ecirc; abrisse sua p&aacute;gina em
design mode todo seu trabalho de limpeza e hard code iriam para o
espa&ccedil;o. Eu e os colegas da minha equipe acabamos por apelidar o Dreamweaver de
DreamHorriver. Portanto, Ultraedit foi, novamente, o salvador da (minha)
p&aacute;tria.


Depois de algum tempo acabei recebendo um convite para trabalhar em outra
empresa. Um novo empreendimento que estava iniciando com desenvolvimento de
aplica&ccedil;&otilde;es para Pocket PC. Eu n&atilde;o conhecia nada deste tipo de equipamento.
J&aacute; tinha ouvido falar de Palm mas, Pocket PC era relativamente novo. Isso foi
em meados de 2001 ou in&iacute;cio de 2002.


Entrei para a empresa e fui apresentado &agrave; plataforma. Ningu&eacute;m, na empresa,
conhecia os equipamentos. Ent&atilde;o fui procurar por recursos e linguagens de
programa&ccedil;&atilde;o para o dispositivo. Acabei descobrindo que eu poderia desenvolver
softwares em C/C++ ou Visual Basic. Era bom demais para ser verdade.


No meu primeiro emprego como desenvolvedor eu acabei aprendendo muito sobre
Visual Basic e como eliminar as defici&ecirc;ncias da linguagem importando e
utilizando fun&ccedil;&otilde;es da API do Windows. Acabei criando uma biblioteca enorme com
fun&ccedil;&otilde;es e opera&ccedil;&otilde;es que faziam de tudo que se possa imaginar. N&oacute;s n&atilde;o
utiliz&aacute;vamos quase nenhum componente ActiveX porque eu
implementei controles (menus, barras de ferramentas, TreeViews, ListViews)
usando a API do Windows diretamente. Por causa desta minha experi&ecirc;ncia com VB
eu achei, em primeira inst&acirc;ncia, que poderia utilizar o mesmo VB para criar
aplicativos para Windows CE. Ledo engano.


O Windows CE utilizava uma linguagem que n&atilde;o era nem o Visual Basic que eu
conhecia como tamb&eacute;m n&atilde;o era o VBA do Access. Mas sim uma vers&atilde;o parecida com
o VBScript para p&aacute;ginas WEB que podia acessar alguns componentes do Windows CE
para criar uma interface com o usu&aacute;rio. Muito dif&iacute;cil de usar e limitado, mas
conseguimos criar nossa primeira aplica&ccedil;&atilde;o deste modo. E l&aacute; estava ele
novamente, o Ultraedit, para salvar a minha pele.


Eu j&aacute; estava t&atilde;o acostumado &agrave;s configura&ccedil;&otilde;es que fazia no meu editor preferido
que n&atilde;o conseguia mais utilizar outro aplicativo. As teclas de atalho j&aacute; eram
autom&aacute;ticas e eu n&atilde;o precisava mais pensar nelas. Quando precisava realizar
uma opera&ccedil;&atilde;o, Zaz! Os dedos faziam o trabalho sozinhos.


Logo de in&iacute;cio percebi que VB n&atilde;o seria a sa&iacute;da definitiva para criar
aplicativos para Windows CE. Eu j&aacute; conhecia a linguagem C. Mas n&atilde;o tinha
pr&aacute;tica. E algumas coisas me amedrontavam, como a utiliza&ccedil;&atilde;o de ponteiros. Eu
n&atilde;o conhecia C++, muito menos MFC ou ATL. Mas n&atilde;o tinha escolha e at&eacute; gostei
do desafio. Eu j&aacute; havia aprendido (e superado) o VB sozinho, tamb&eacute;m j&aacute; havia
aprendido HTML, VBScript e Javascript por mim mesmo. Al&eacute;m de SQL que &eacute;
indispens&aacute;vel a qualquer desenvolvedor de aplicativos cliente/servidor.
Aprender C++, MFC e ATL seria mais informa&ccedil;&atilde;o e bagagem para minha jornada
profissional.


Foram 2 aplicativos, v&aacute;rias vers&otilde;es e tudo estava indo bem. At&eacute; que chegou ao
Brasil o Windows Smartphone. Uma vers&atilde;o diferente do Windows CE e uma vers&atilde;o
diferente da API: sem MFC. Eu fiquei realmente chateado. A Microsoft &eacute;
estranha neste sentido. Embora procure manter a compatibilidade entre as
vers&otilde;es do Windows para suportar aplica&ccedil;&otilde;es antigas, num produto novo como o
Windows Smartphone os desenvolvedores teriam que esquecer tudo o que
aprenderam sobre MFC e sua estrutura Document/View e criar aplica&ccedil;&otilde;es
usando diretamente o Windows SDK.


Na &eacute;poca eu pensei: "S&oacute; eu crio as aplica&ccedil;&otilde;es para Windows CE nesta empresa.
Ent&atilde;o, vou criar uma biblioteca de classes parecida com o MFC mas que eu possa
compartilhar sua utiliza&ccedil;&atilde;o tanto no Windows CE quanto no Windows Smartphone".
E foi o que eu fiz. E ainda uso esta biblioteca de classes at&eacute; hoje.


Embora os ambientes de desenvolvimento da Microsoft evolu&iacute;rem com o tempo,
para o Windows CE e Smartphone eu ainda estava atrelado a uma vers&atilde;o
modificada do Visual Studio 6 chamada eMbedded Visual Tools. Com isso meu
editor de textos estava l&aacute; para me salvar. E o Ultraedit era, novamente, minha
prefer&ecirc;ncia total.


As coisas estavam indo bem e um evento interessante mudou o rumo e a minha
hist&oacute;ria com o Ultraedit: comprei meu primeiro notebook. Pode parecer estranho
a primeira vista, mas o notebook tem tudo a ver com meu div&oacute;rcio com o
Ultraedit. Eu explico. Estava muito acostumado com combina&ccedil;&otilde;es de tecla
como CTRL+PageUp, CTRL+PageDown, CTRL+Home, CTRL+End, teclas
direcionais e etc. Estas s&atilde;o teclas b&aacute;sicas de movimenta&ccedil;&atilde;o do cursor em
qualquer editor de textos. Por&eacute;m, onde est&atilde;o estas teclas num notebook? Talvez
acima ou ao lado do teclado. Talvez em baixo. Pois &eacute;, um detalhe como este me
deixou totalmente travado diante do computador. Meu trabalho n&atilde;o rendia.
Quando eu usava o desktop tudo bem, meu teclado era normal. Mas no notebook eu
sentia muita falta das teclas que eu j&aacute; estava acostumado a usar h&aacute; anos.


Contei este meu problema &agrave; um amigo e ele me mostrou o editor que usava, o
TextPad. Ele me disse que passou pelo mesmo problema quando comprou seu
primeiro notebook e acabou trocando de editor porque o TextPad dava a
possibilidade de personalizar at&eacute; a fun&ccedil;&atilde;o das teclas direcionais, PageUp,
PageDown e etc. O Ultraedit n&atilde;o permitia este tipo de configura&ccedil;&atilde;o, mas
isso nunca me incomodou porque o modo como eu usava estas teclas de navega&ccedil;&atilde;o
era exatamente o modo como estava implementado no Ultraedit. Tentei usar uma
vers&atilde;o shareware do TextPad mas, como tantos outros editores que eu j&aacute;
havia testado, nele tamb&eacute;m faltavam algumas coisas.


Passei a procurar um outro editor de textos que resolvesse meu problema de
forma satisfat&oacute;ria. Testei v&aacute;rios aplicativos que j&aacute; havia testado
anteriormente, em outras vers&otilde;es, mas estava dif&iacute;cil encontrar uma solu&ccedil;&atilde;o.
Foi quando eu tropecei no Cream. Fiz o download, instalei e olhei sua
interface. Comecei a ler o tutorial e sua documenta&ccedil;&atilde;o e fui me dando conta de
que o Cream era uma vers&atilde;o modificada do Vim. Continuei lendo e
descobri que Vim significa Vi IMproved. J&aacute; conhecia o Vi do meu
primeiro emprego como desenvolvedor, onde o servidor de rede era Linux.


Ainda lendo a documenta&ccedil;&atilde;o fui aprendendo sobre os modos do Vi e
como eles funcionavam e se completavam. Fui ficando curioso e acabei por
removendo o Cream para instalar uma vers&atilde;o do Vim.


Fiz todo o seu tutorial e, realmente, ele me empolgou. Achei muito
interessante sua forma modal de funcionar. Mas o que mais me chamou a
aten&ccedil;&atilde;o foi sua configura&ccedil;&atilde;o. Eu era um desenvolvedor essencialmente Windows.
Tinha o Cygwin instalado no meu computador mas apenas por curiosidade. J&aacute;
tinha visto v&aacute;rias vers&otilde;es de Linux mas nunca para utilizar de verdade. Quanto
mais eu lia da documenta&ccedil;&atilde;o do Vim, mais eu ficava curioso e empolgado. Todas
as possibilidades de configura&ccedil;&atilde;o, tudo pode ser personalizado. Tudo! E melhor
ainda. N&atilde;o &eacute; apenas gratuito. &Eacute; open source. Me apaixonei.


A curva de aprendizagem do Vim &eacute; grande. N&atilde;o consegui us&aacute;-lo confortavelmente
em pouco tempo. Tamb&eacute;m n&atilde;o pude substituir o Ultraedit prontamente. Eu tinha
demandas para entregar, e o Vim &eacute; um editor dif&iacute;cil para um usu&aacute;rio Windows
de t&atilde;o longa data. Mas eu insisti e fui aprendendo. Aprendendo e me
acostumando. Fui conhecendo alguns de seus plugins e as formas como eu poderia
alterar as configura&ccedil;&otilde;es do ambiente. Aprendi o VimL, a linguagem de script do
Vim, e comecei a fazer minhas primeiras modifica&ccedil;&otilde;es. Bem, n&atilde;o posso dizer que
conhe&ccedil;o o VimL. Mas consigo fazer algumas coisas.


Este editor de textos me cativou tanto que hoje n&atilde;o fa&ccedil;o nada sem ele. Tenho 3
computadores. Um desktop, um notebook e um MacBook. Todos tem a mesma vers&atilde;o
do Vim. N&atilde;o fa&ccedil;o mais nada com outro editor. Cheguei ao ponto de aprender
LaTeX apenas para poder usar o Vim para criar documentos como contratos,
propostas e cartas. Escrevo e-mails com ele e este post tamb&eacute;m foi escrito
nele.


J&aacute; tenho toda esta minha paix&atilde;o por este aplicativo, e hoje eu sei que seu
cr&eacute;dito &eacute; bem maior do que apenas me possibilitar digitar texto com efici&ecirc;ncia
em um notebook. Ao aprender como ele funciona, e todas as suas
particularidades, eu acabei encontrando um mundo computacional do qual eu n&atilde;o
fazia ideia: A vis&atilde;o Unix de sistema. Foi aprendendo sobre pequenas
ferramentas como grep, ctags e cscope que eu fui me aprofundando
nesta vis&atilde;o e entendendo seu ideal.


Para quem &eacute; usu&aacute;rio Windows e n&atilde;o sabe do que estou falando, a base de
sistemas Unix s&atilde;o suas pequenas ferramentas. Aplicativos de linha de comando
como grep, sed, man, less, ctags e tantos outros pequenos
programas de funcionalidade definida. Pequenas ferramentas com tarefas
espec&iacute;ficas que podem ser usadas em conjunto para atingir diversos objetivos
diferentes. Este foi o principal ponto que me cativou: compartilhamento e
reutiliza&ccedil;&atilde;o.


No sistema Unix se um aplicativo precisa incorporar um corretor
ortogr&aacute;fico, os desenvolvedores n&atilde;o precisam reinventar a roda.
Eles ir&atilde;o utilizar o aspell. Se voc&ecirc; precisa efetuar uma mesma altera&ccedil;&atilde;o
em v&aacute;rios arquivos diferentes, combine o grep com o sed e ter&aacute; sucesso
absoluto.


Esta vis&atilde;o de sistema foi algo totalmente novo para mim. N&atilde;o existe nada igual
no Windows. Por&eacute;m, n&atilde;o tenho como largar o Windows. Ainda fa&ccedil;o uma boa parte
dos meus trabalhos nele. Mas houve uma mudan&ccedil;a. Uma grande mudan&ccedil;a no meu modo
de trabalhar. Assim como o Vim, Cygwin &eacute; presen&ccedil;a obrigat&oacute;ria em todos os meus
computadores. Utilizo v&aacute;rias de suas ferramentas, portadas do Linux para
Windows, para realizar tarefas di&aacute;rias. Desde scripts para automatizar tarefas
repetitivas como ferramentas de backup, compiladores, conversores, grep, man,
ctags, etc, etc, etc. J&aacute; &eacute; assim faz alguns anos e devo isso a um simples (e
antigo) editor de textos.


As vezes acho que estou ficando velho e ultrapassado. Vejo amigos usando
aplicativos como o Visual Studio 10, criando aplica&ccedil;&otilde;es em C# ou VB.NET e se
vangloriando das capacidades do ambiente. Acho que eu n&atilde;o conseguiria usar o
VS10 para nada al&eacute;m de compilar a aplica&ccedil;&atilde;o (e talvez nem isso, se encontrar
um modo de passar os argumentos corretamente, por linha de comando, ao
compilador).  Eclipse? Nem pensar. Eu precisaria de 2GB a mais de mem&oacute;ria s&oacute;
para carregar o programa. Prefiro continuar com minha combina&ccedil;&atilde;o de
Vim+Cygwin, leve e eficiente, que me permite fazer tudo (ou at&eacute; mais) que
outros ambientes de desenvolvimento fazem, sem precisar de um super computador
para isso.

<!-- 
[category development-technology]
[tags Vim,Cygwin,Ultraedit]
[delay +1 hour]
[comments on]
[status draft]
[publicize yahoo|twitter|facebook]
[title VIM]
-->

<!-- xhtml code generated by txt2tags 2.6.669 (http://txt2tags.org) -->
<!-- cmdline: txt2tags devel.t2t -->