[{"content":"Gosto da ideia do Emacs de que tudo é um buffer: arquivos, diretórios, shells, resultados de busca. O que não gosto é que cada modo do Emacs vem com as próprias teclas.\nNo Neovim eu tento ficar com a primeira parte sem a segunda, e manter as teclas do Vim funcionando do mesmo jeito em todo lugar.\nPor que buffers Um buffer é só texto. Tudo que é buffer já funciona com o que eu sei: me mover, buscar, copiar, editar, desfazer.\nO que não é buffer normalmente é uma janela nova com as próprias teclas. Instale dez plugins assim e você tem dez ferramentinhas na mesma tela, cada uma com as suas regras. Parece poderoso, mas fica mais difícil de usar, porque o que você aprende numa não ajuda na outra.\nUma pergunta antes de adicionar um plugin Isso me dá um buffer, ou uma janela nova com as próprias teclas?\nOs plugins de que mais gosto diminuem o que eu preciso decorar, e o oil.nvim é o melhor exemplo. Ele mostra um diretório como um buffer. Pra mover um arquivo, dou dd, p em outro lugar e salvo com :w. Pra renomear, edito o nome. Não precisei aprender nada novo.\nRecursos nativos muitas vezes ganham pelo mesmo motivo. O nvim.difftool nativo coloca os arquivos alterados de um git difftool -d na quickfix list, que eu já sei usar. O diffview.nvim faz o mesmo trabalho numa janela própria, com as próprias teclas, então fiquei com o nativo.\nSinais de que algo não se encaixa Teclas que só funcionam numa janela. Você precisa saber onde está antes de saber o que uma tecla faz. Coisas que você não acha de novo. Não aparecem no :ls e não dá pra reabrir depois. Resultados que não viram texto. Não dá pra buscar neles, filtrar ou rodar de novo. O último passa despercebido fácil. Um fuzzy picker normalmente esquece a sua busca quando fecha. O :grep não esquece, porque fica no histórico de comandos, e o q: abre esse histórico como um buffer. Subo até a última busca, troco uma palavra e rodo de novo.\nIsso só me importa pra buscas. Pra voltar a um arquivo, o :ls basta.\nA quickfix list junta tudo Quase toda busca minha acaba na quickfix list, e a partir dela tudo funciona junto:\nFerramenta O que faz :grep com ripgrep preenche a lista :Cfilter filtra a lista :cdo / :cfdo roda um comando em cada resultado, ou em cada arquivo :colder / :cnewer navega entre listas mais antigas e mais novas nvim.difftool usa uma quickfix list pras mudanças do git Como é sempre o mesmo tipo de lista, os mesmos comandos funcionam em tudo.\nO mesmo vale pros mapeamentos Mapeamentos também se acumulam, e é fácil não perceber porque eles não aparecem em lugar nenhum. Faço uma pergunta parecida: esse mapeamento me poupa de algo, ou é mais uma coisa pra lembrar?\nDois tipos normalmente não valem a pena:\nUm atalho pra um comando que já funciona em todo lugar. \u0026lt;Space\u0026gt;g pra :grep economiza quatro teclas, mas o :grep funciona em qualquer Vim ou Neovim, sem configuração. Refazer algo que outra ferramenta já faz. Eu tinha dez linhas de Lua pra abrir um arquivo do lado do atual. Com o oil, o - já faz isso. Pra abrir arquivos fiquei com três jeitos, dependendo do que eu sei:\nQuando Como Não sei o nome, ou está do lado do arquivo atual - (oil) Sei o nome, em qualquer lugar do projeto :E, um comando meu (fuzzy match no rg --files) Sei o caminho completo :e Eu tinha quatro mapeamentos pra isso e agora tenho dois: - pro oil, e \u0026lt;Space\u0026gt;r, que começa o :E. Os outros dois não me poupavam de nada.\nOnde a regra não vale O menu de autocompletar é um popup em qualquer editor, e tudo bem. Um picker rápido, que abre e fecha em dois segundos, também está ok, desde que eu não precise daquela busca de novo. O meu próprio plugin, pathpick.nvim, copia o caminho do arquivo atual em vários formatos. Ele abre sim um popup pequeno, mas cada linha é exatamente o texto que vai ser copiado, então yy, / e o modo visual funcionam como em qualquer outro buffer.\nEntão a minha regra é mais estreita que \u0026ldquo;nada de popups\u0026rdquo;: tudo que eu quero reencontrar deve ficar num buffer.\nMinha config hoje Neovim 0.12 com o gerenciador de plugins nativo, o vim.pack, e três plugins: oil.nvim, pathpick.nvim e treesitter (que só melhora o destaque de sintaxe e não adiciona janela nem teclas). O resto é nativo ou poucas linhas da minha config: a quickfix list, o :Cfilter, o nvim.difftool e o fuzzy matching. Os plugins que tirei não tinham nada de errado; eles só faziam, numa janela própria, coisas que um buffer já fazia.\nPor que não usar o Emacs, então? Eu testei. O Emacs coloca tudo num buffer, e muitas teclas funcionam em todo lugar, mas cada modo acrescenta as próprias teclas por cima, e elas não valem no modo seguinte.\nO Vim tem três modos principais (Normal, Insert e Visual), e eles funcionam igual em todo lugar. Você combina uma ação com um alvo: ci\u0026quot; muda o que está dentro das aspas, daw apaga uma palavra, \u0026gt;ip indenta um parágrafo. Isso funciona num arquivo de código, no q: e no oil. Quando aprendo uma ação nova, ela funciona em tudo que eu já conheço. No Emacs, aprender um comando novo normalmente me dava só um comando novo.\nTem também um motivo prático. Trabalho no terminal o dia todo, no foot com tmux (escrevi sobre o meu setup), e o Vim nasceu pro terminal.\nLivro recomendado Practical Vim, do Drew Neil, é um livro incrível. Ele ensina a pensar em como usar o Vim, que é o que você precisa pra entender o Vim de verdade.\n","permalink":"https://lucasgrvarela.com/pt/posts/neovim-everything-is-a-buffer/","summary":"\u003cp\u003eGosto da ideia do Emacs de que tudo é um buffer: arquivos, diretórios, shells, resultados de busca. O que não gosto é que cada modo do Emacs vem com as próprias teclas.\u003c/p\u003e\n\u003cp\u003eNo Neovim eu tento ficar com a primeira parte sem a segunda, e manter as teclas do Vim funcionando do mesmo jeito em todo lugar.\u003c/p\u003e","title":"Trate tudo como buffer, igual ao Emacs, mas mantenha o Vim simples"},{"content":"Uso open source todo dia há anos, a começar pelo Linux, mas só comecei a contribuir de verdade há alguns meses. O primeiro projeto foi o OpenTofu.\nComeçou com um problema meu. Uso o OpenTofu com Terragrunt Stacks, e a saída do plan das units sem mudanças era poluída demais, então abri uma issue.\nUm tempo depois, perguntei se eu mesmo podia resolver. Os mantenedores atribuíram a issue pra mim, revisaram meu PR e fizeram o merge. Era uma correção pequena, mas resolveu o meu problema.\nDepois tentei algo mais difícil: um panic no comunicador SSH quando um proxy HTTP falha no handshake CONNECT. Esse também foi mergeado.\nAlgumas coisas facilitaram continuar. O repositório é bem organizado, e as labels das issues mostram o que já dá pra pegar. Pedir pra pegar uma issue é simples. E o Slack da comunidade é aberto; o pessoal lá me ajudou a achar no que trabalhar depois.\nJá são quatro PRs mergeados, e comecei a contribuir também com o tofu-ls, o language server do OpenTofu. Meu primeiro PR lá está em revisão.\nEstou aprendendo bastante com isso. Estou escrevendo mais Go e conhecendo uma codebase grande por dentro: como uma mudança num lugar afeta outros, e quais padrões os mantenedores preferem.\nO OpenTofu pede pra não usar assistentes de código com IA, por questões de copyright, então escrevo todo o código eu mesmo. Acho que isso me fez aprender muito melhor a codebase.\nSe você quer começar a contribuir, escolha um projeto de que gosta e comece por um problema que você realmente tem. Leia as diretrizes de contribuição e desenvolvimento e siga elas. Abra uma issue (ou encontre uma), peça pra trabalhar nela e espere um mantenedor concordar antes de começar.\nObrigado aos mantenedores do OpenTofu por me receberem tão bem.\n","permalink":"https://lucasgrvarela.com/pt/posts/contributing-to-opentofu/","summary":"\u003cp\u003eUso open source todo dia há anos, a começar pelo Linux, mas só comecei a contribuir de verdade há alguns meses. O primeiro projeto foi o \u003ca href=\"https://github.com/opentofu/opentofu\"\u003eOpenTofu\u003c/a\u003e.\u003c/p\u003e","title":"Como comecei a contribuir com o OpenTofu"},{"content":"Quase todo o meu dia acontece numa janela de terminal. É assim que ela está configurada.\nO foot abre direto no tmux O foot é um terminal pequeno e rápido pra Wayland. O meu abre em tela cheia e entra numa sessão do tmux chamada main, ou cria ela se não existir:\n[main] initial-window-mode=fullscreen shell=tmux new-session -A -s main Se eu fecho o terminal, é só abrir de novo e volto pra mesma sessão, com cada janela onde eu deixei.\nDuas linhas no tmux me dão cores completas e as teclas extras que o foot suporta:\nset -as terminal-features \u0026#34;,foot*:RGB:extkeys\u0026#34; set -s extended-keys on tmux: as principais mudanças As mudanças que mais uso:\nTecla ou ajuste O que faz prefix = Ctrl+a mais fácil de alcançar que Ctrl+b Alt+1..9 pula pra uma janela sem o prefix prefix \u0026quot; e prefix % divide o painel, mantendo o mesmo diretório prefix c janela nova, sempre no meu diretório home nome da janela o nome do diretório do painel ativo modo de cópia teclas do Vim, e y copia pro clipboard Divisões e janelas novas se comportam diferente de propósito. Uma divisão normalmente é pra tarefa em que já estou, então abre no mesmo diretório. Uma janela nova normalmente é pra outra coisa, então começa no meu diretório home.\nO layout: uma janela, até quatro sessões Quase todo o trabalho acontece numa janela, dividida em quatro áreas. Cada área tem o Claude Code num repo em cima, e um shell da mesma tarefa embaixo:\n+---------------------------+---------------------------+ | claude (repo A) | claude (repo B) | | | | +---------------------------+---------------------------+ | $ kubectl get pod | $ nvim | +---------------------------+---------------------------+ | claude (repo C) | claude (repo D) | | | | +---------------------------+---------------------------+ | $ git diff | $ tofu plan | +---------------------------+---------------------------+ Quando o Claude termina, o shell onde confiro o trabalho está logo abaixo. O prefix z deixa um painel em tela cheia quando um plan ou um diff não cabe.\nSó rodo quatro em dias cheios, com até três em tarefas e uma só pra perguntas. Num dia normal, são duas.\nO Neovim roda nesses painéis de shell. Nos projetos em que ferramentas de IA são permitidas, o Claude faz um rascunho da mudança, e eu reviso, corrijo e testo no editor ao lado.\nUm limite de memória como fusível Cada sessão do Claude Code roda com um limite de memória definido pelo systemd:\nalias claude=\u0026#39;systemd-run --user --scope -q -p MemoryHigh=3500M -p MemoryMax=4G -p MemorySwapMax=1G claude\u0026#39; Na minha máquina, uma sessão nova usa uns 320 MiB, e uma com vinte minutos de trabalho uns 480 MiB. O limite de 4 GiB é umas oito vezes isso, e quatro sessões no limite precisariam de mais memória do que a minha máquina tem. O limite não está ali pra dividir memória entre sessões. Está ali pro caso de uma sessão dar problema: só ela é afetada, e o tmux, o navegador e todo o resto continuam rodando.\nNa prática, o que limita quantas sessões eu rodo é o quanto eu consigo revisar.\n","permalink":"https://lucasgrvarela.com/pt/posts/terminal-workflow-foot-tmux-neovim-claude-code/","summary":"\u003cp\u003eQuase todo o meu dia acontece numa janela de terminal. É assim que ela está configurada.\u003c/p\u003e","title":"Meu fluxo no terminal: foot, tmux, Neovim e sessões do Claude Code em paralelo"},{"content":"Oi, eu sou o Lucas. Sou brasileiro e moro na Costa del Sol, na Espanha, perto do mar.\nGanhei meu primeiro computador aos 8 anos, presente dos meus pais e da minha avó. Eu usava mais pra jogar: Tibia, Counter-Strike 1.6, Warcraft e Dota.\nDepois estudei mecatrônica e fiz um curso técnico em telecomunicações. Gostava bem mais da eletrônica e da programação do que da parte mecânica, então fui fazer Ciência da Computação no Instituto Federal Catarinense. Foi lá que comecei a usar Linux de verdade, e onde conheci a Fernanda, minha companheira. Meu primeiro emprego foi na Senior Sistemas, uma grande empresa brasileira de ERP, programando em Java e C.\nFui pra infraestrutura na T-Systems, trabalhando na Telekom Cloud e em clusters de HPC (computação de alto desempenho) que rodavam simulações de dinâmica de fluidos e aerodinâmica para empresas como a Volkswagen. Aprendi lá, no dia a dia, boa parte do que sei de Linux, Python, Ansible, Terraform e Kubernetes, e desde então trabalho com DevOps, SRE e platform engineering.\nEm algum momento também tentei fazer jogos e descobri que não gostava, principalmente porque não curtia criar os assets. O que eu gosto, desde criança, é descobrir como as coisas funcionam e ir fundo até entender o sistema inteiro. Infraestrutura e hardware me dão muito disso.\nHoje sou Senior Platform Engineer, DevOps \u0026amp; SRE, com mais de 8 anos de experiência, trabalhando remoto com times do mundo todo. Algumas coisas de que me orgulho:\nTech Lead de um grupo de SRE com 12 engenheiros, numa plataforma com mais de 5.000 pods Liderei a migração de 80 repositórios do Terraform Cloud para o Atlantis, cortando cerca de US$ 70 mil por ano em custos Liderei a plataforma em Black Fridays sem nenhum incidente Como Tech Lead, o que eu mais valorizava eram as pessoas: a mentoria e a cultura do time.\nTambém contribuo com open source, principalmente com o OpenTofu e o tofu-ls, e escrevo sobre o que aprendo neste blog.\nLonge do computador, geralmente estou com a Fernanda, andando na praia, fazendo trilha ou tomando um vinho. Algumas das minhas trilhas estão no Wikiloc.\nSe quiser conversar sobre infraestrutura, open source ou trabalho, me mande um email em lucasgrvarela@gmail.com ou me encontre no LinkedIn.\n","permalink":"https://lucasgrvarela.com/pt/about/","summary":"Lucas Grigolon Varela, Senior Platform Engineer, DevOps \u0026amp; SRE brasileiro, morando na Espanha (CET). Minha história, meu trabalho e o que eu valorizo.","title":"Sobre"}]