[{"content":"I like the Emacs idea that everything is a buffer: files, directories, shells, search results. What I don\u0026rsquo;t like is that every Emacs mode comes with its own keys.\nIn Neovim I try to get the first part without the second, and keep the Vim keys working the same way everywhere.\nWhy buffers A buffer is just text. Anything that\u0026rsquo;s a buffer already works with everything I know: moving around, searching, yanking, editing, undo.\nAnything that isn\u0026rsquo;t a buffer is usually a new window with its own keys. Install ten plugins like that and you end up with ten small tools on one screen, each with its own rules. It looks powerful, but it\u0026rsquo;s harder to use, because what you learn in one of them doesn\u0026rsquo;t help in the next.\nOne question before adding a plugin Does this give me a buffer, or a new window with its own keys?\nThe plugins I like most remove things I have to remember, and oil.nvim is the best example. It shows a directory as a buffer. To move a file, I dd it, p it somewhere else and save with :w. To rename one, I edit the name. I didn\u0026rsquo;t have to learn anything new.\nBuilt-in features often win for the same reason. The built-in nvim.difftool puts the changed files of git difftool -d in the quickfix list, which I already know how to use. diffview.nvim does the same job in its own window, with its own keys, so I kept the built-in one.\nSigns that something doesn\u0026rsquo;t fit Keys that only work in one window. You have to know where you are before you know what a key does. Things you can\u0026rsquo;t find again. They don\u0026rsquo;t show up in :ls and you can\u0026rsquo;t reopen them later. Results that don\u0026rsquo;t become text. You can\u0026rsquo;t search them, filter them or run them again. The last one is easy to miss. A fuzzy picker usually forgets your search when it closes. :grep doesn\u0026rsquo;t, because it stays in the command history, and q: opens that history as a buffer. I go up to the last search, change a word and run it again.\nI only care about this for searches. To get back to a file, :ls is enough.\nThe quickfix list ties it together Most of my searches end up in the quickfix list, and from there everything works together:\nTool What it does :grep with ripgrep fills the list :Cfilter narrows the list :cdo / :cfdo runs a command on every result, or on every file :colder / :cnewer moves between older and newer lists nvim.difftool uses a quickfix list for git changes Since it\u0026rsquo;s always the same kind of list, the same commands work on all of it.\nThe same goes for mappings Mappings pile up too, and it\u0026rsquo;s easy not to notice because they don\u0026rsquo;t show up anywhere. I ask a similar question: does this mapping save me from something, or is it one more thing to remember?\nTwo kinds are usually not worth it:\nA shortcut for a command that already works everywhere. \u0026lt;Space\u0026gt;g for :grep saves four keys, but :grep works in any Vim or Neovim, with no setup. Rebuilding something another tool already does. I had ten lines of Lua to open a file next to the current one. With oil, - already does that. For opening files I ended up with three ways, depending on what I know:\nWhen How I don\u0026rsquo;t know the name, or it\u0026rsquo;s next to the current file - (oil) I know the name, anywhere in the project :E, a small command of mine (fuzzy match on rg --files) I know the full path :e I used to have four mappings for this and now I have two: - for oil, and \u0026lt;Space\u0026gt;r, which starts :E. The other two weren\u0026rsquo;t saving me anything.\nWhere the rule doesn\u0026rsquo;t apply The completion menu is a popup in every editor, and that\u0026rsquo;s fine. A quick picker that opens and closes in two seconds is fine too, as long as I don\u0026rsquo;t need that search again. My own plugin, pathpick.nvim, copies the current file\u0026rsquo;s path in different forms. It does open a small popup, but each line is the exact text it will copy, so yy, / and visual mode work like in any other buffer.\nSo my rule is narrower than \u0026ldquo;no popups\u0026rdquo;: anything I want to come back to should live in a buffer.\nMy config today Neovim 0.12 with its built-in plugin manager, vim.pack, and three plugins: oil.nvim, pathpick.nvim and treesitter (which only improves highlighting and adds no window or keys). Everything else is built in or a few lines of my own config: the quickfix list, :Cfilter, nvim.difftool and fuzzy matching. Nothing was wrong with the plugins I removed; they just did things in their own window that a buffer could already do.\nWhy not just use Emacs? I tried it. Emacs puts everything in a buffer, and many keys work everywhere, but each mode adds its own keys on top and those don\u0026rsquo;t carry over to the next mode.\nVim has three main modes (Normal, Insert and Visual), and they work the same everywhere. You combine an action with a target: ci\u0026quot; changes inside quotes, daw deletes a word, \u0026gt;ip indents a paragraph. That works in a code file, in q: and in oil. When I learn a new action, it works on everything I already know. In Emacs, learning a new command usually just gave me one new command.\nThere\u0026rsquo;s also a practical reason. I work in the terminal all day, in foot with tmux (I wrote about my setup), and Vim was made for the terminal.\nRecommended book Practical Vim, by Drew Neil, is an amazing book. It teaches you how to think about using Vim, which is what you need to really grok it.\n","permalink":"https://lucasgrvarela.com/posts/neovim-everything-is-a-buffer/","summary":"\u003cp\u003eI like the Emacs idea that everything is a buffer: files, directories, shells, search results. What I don\u0026rsquo;t like is that every Emacs mode comes with its own keys.\u003c/p\u003e\n\u003cp\u003eIn Neovim I try to get the first part without the second, and keep the Vim keys working the same way everywhere.\u003c/p\u003e","title":"Treat everything as a buffer, like Emacs, but keep Vim simple"},{"content":"I\u0026rsquo;ve used open source every day for years, starting with Linux, but I only started contributing seriously a few months ago. The first project was OpenTofu.\nIt started with a problem of my own. I use OpenTofu with Terragrunt Stacks, and the plan output for units with no changes was too noisy, so I opened an issue.\nA while later I asked if I could fix it myself. The maintainers assigned it to me, reviewed my PR and merged it. It was a small fix, but it fixed my problem.\nAfter that I tried something harder: a panic in the SSH communicator when an HTTP proxy fails the CONNECT handshake. That one got merged too.\nA few things made it easy to keep going. The repository is well organized, and the issue labels tell you what\u0026rsquo;s ready to pick up. Asking to work on an issue is simple. The community Slack is open, and people there helped me find what to work on next.\nI\u0026rsquo;m at four merged PRs now, and I\u0026rsquo;ve started on tofu-ls, the OpenTofu language server. My first PR there is in review.\nI\u0026rsquo;m learning a lot from it. I\u0026rsquo;m writing more Go, and I\u0026rsquo;m getting to know a big codebase from the inside: how a change in one place affects others, and which patterns the maintainers prefer.\nOpenTofu asks contributors not to use AI coding assistants, for copyright reasons, so I write all the code myself. I think that has helped me learn the codebase much better.\nIf you want to start contributing, pick a project you like and start with a problem you actually have. Read the contributing and development guidelines and follow them. Open an issue (or find one), ask to work on it, and wait for a maintainer to say yes before you start.\nThanks to the OpenTofu maintainers for being so welcoming.\n","permalink":"https://lucasgrvarela.com/posts/contributing-to-opentofu/","summary":"\u003cp\u003eI\u0026rsquo;ve used open source every day for years, starting with Linux, but I only started contributing seriously a few months ago. The first project was \u003ca href=\"https://github.com/opentofu/opentofu\"\u003eOpenTofu\u003c/a\u003e.\u003c/p\u003e","title":"How I started contributing to OpenTofu"},{"content":"Most of my day happens in one terminal window. This is how it\u0026rsquo;s set up.\nfoot opens straight into tmux foot is a small, fast terminal for Wayland. Mine opens fullscreen and attaches to a tmux session called main, or creates it if it doesn\u0026rsquo;t exist:\n[main] initial-window-mode=fullscreen shell=tmux new-session -A -s main If I close the terminal, I just open it again and I\u0026rsquo;m back in the same session, with every window where I left it.\nTwo lines in tmux give me full colors and the extra keys foot supports:\nset -as terminal-features \u0026#34;,foot*:RGB:extkeys\u0026#34; set -s extended-keys on tmux: the main things I changed The changes I use the most:\nKey or setting What it does prefix = Ctrl+a easier to reach than Ctrl+b Alt+1..9 jump to a window without the prefix prefix \u0026quot; and prefix % split, keeping the same directory prefix c new window, always in my home directory window name the directory name of the active pane copy mode Vim keys, and y copies to the clipboard Splits and new windows behave differently on purpose. A split is usually for the task I\u0026rsquo;m already on, so it opens in the same directory. A new window is usually for something else, so it starts in my home directory.\nThe layout: one window, up to four sessions Most of the work happens in one window, split into four areas. Each area has Claude Code in one repo on top, and a shell for the same task below it:\n+---------------------------+---------------------------+ | claude (repo A) | claude (repo B) | | | | +---------------------------+---------------------------+ | $ kubectl get pod | $ nvim | +---------------------------+---------------------------+ | claude (repo C) | claude (repo D) | | | | +---------------------------+---------------------------+ | $ git diff | $ tofu plan | +---------------------------+---------------------------+ When Claude finishes, the shell where I check its work is right below it. prefix z makes a pane fullscreen when a plan or a diff doesn\u0026rsquo;t fit.\nI run four only on busy days, with up to three on tasks and one just for questions. On a normal day it\u0026rsquo;s two.\nNeovim runs in those shell panes. On projects where AI tools are allowed, Claude drafts the change, and I review, fix and test it in the editor next to it.\nA memory limit as a safety fuse Every Claude Code session runs with a memory limit set through systemd:\nalias claude=\u0026#39;systemd-run --user --scope -q -p MemoryHigh=3500M -p MemoryMax=4G -p MemorySwapMax=1G claude\u0026#39; On my machine, a new session uses about 320 MiB, and one after twenty minutes of work about 480 MiB. The 4 GiB limit is about eight times that, and four sessions at the limit would need more memory than my machine has. The limit isn\u0026rsquo;t there to split memory between sessions. It\u0026rsquo;s there in case one session goes wrong: only that session is affected, and tmux, the browser and everything else keep running.\nIn practice, what limits the number of sessions I run is how much I can review.\n","permalink":"https://lucasgrvarela.com/posts/terminal-workflow-foot-tmux-neovim-claude-code/","summary":"\u003cp\u003eMost of my day happens in one terminal window. This is how it\u0026rsquo;s set up.\u003c/p\u003e","title":"My terminal workflow: foot, tmux, Neovim and parallel Claude Code sessions"},{"content":"Hi, I\u0026rsquo;m Lucas. I\u0026rsquo;m Brazilian, and I live on the Costa del Sol in Spain, close to the sea.\nI got my first computer when I was 8, a gift from my parents and my grandmother. I mostly played games on it: Tibia, Counter-Strike 1.6, Warcraft and Dota.\nLater I studied mechatronics and did a technical course in telecommunications. I liked the electronics and the programming a lot more than the mechanical part, so I went on to study Computer Science at the Instituto Federal Catarinense. That\u0026rsquo;s where I got into Linux, and where I met Fernanda, my partner. My first job was at Senior Sistemas, a large Brazilian ERP company, writing Java and C.\nI moved to infrastructure at T-Systems, working on the Telekom Cloud and on HPC (high-performance computing) clusters that ran fluid dynamics and aerodynamics simulations for companies like Volkswagen. I learned most of my Linux, Python, Ansible, Terraform and Kubernetes there, on the job, and I\u0026rsquo;ve worked in DevOps, SRE and platform engineering ever since.\nAt some point I also tried making games, and found out I didn\u0026rsquo;t enjoy it, mostly because I didn\u0026rsquo;t like making the assets. What I liked, as a kid and now, is figuring out how things work and going deeper until I understand the whole system. Infrastructure and hardware give me a lot of that.\nToday I\u0026rsquo;m a Senior Platform Engineer, DevOps \u0026amp; SRE, with 8+ years of experience, working remotely with teams around the world. Some things I\u0026rsquo;m proud of:\nTech Lead of a 12-engineer SRE group running a platform with 5,000+ pods Led the move of 80 repos from Terraform Cloud to Atlantis, cutting about $70k a year in costs Led the platform through Black Fridays with zero incidents As a Tech Lead, the part I cared about most was the people: mentoring them and the culture of the team.\nI also contribute to open source, mainly OpenTofu and tofu-ls, and I write about what I learn on this blog.\nAway from the computer I\u0026rsquo;m usually with Fernanda, walking on the beach, hiking, or having a glass of wine. Some of my hikes are on Wikiloc.\nIf you want to talk about infrastructure, open source or work, email me at lucasgrvarela@gmail.com or find me on LinkedIn.\n","permalink":"https://lucasgrvarela.com/about/","summary":"Lucas Grigolon Varela, Brazilian Senior Platform Engineer, DevOps \u0026amp; SRE, based in Spain (CET). My story, my work and what I care about.","title":"About"}]