--- title: 'The Geometry of Text: NeoVim, Virtual Edit, and the AI Grid' permalink: /futureproof/geometry-of-text-neovim-virtual-edit/ canonical_url: https://mikelev.in/futureproof/geometry-of-text-neovim-virtual-edit/ description: 'I fixed a long-standing annoyance in my NeoVim config by enabling virtualedit="block", which allows me to draw perfect rectangles in visual mode regardless of line length. This technical fix led to a deeper realization: our text editors are evolving from 1D streams into 2D coordinate systems. This spatial way of thinking is exactly how we must feed context to AI agents to ensure deterministic, reliable code patching in the Pipulate engine.' meta_description: Learn how to decouple the cursor from line endings in NeoVim and why spatial awareness is a vital methodology for AI-driven code patching. excerpt: Learn how to decouple the cursor from line endings in NeoVim and why spatial awareness is a vital methodology for AI-driven code patching. meta_keywords: NeoVim, virtualedit, visual block mode, terminal history, Bill Joy, Bram Moolenaar, AI patching, deterministic editing, Pipulate layout: post sort_order: 6 --- ## Setting the Stage: Context for the Curious Book Reader This treatise explores the bridge between historical terminal physics and modern AI-driven code manipulation. By examining the transition from Bill Joy's one-dimensional "tape" of characters in 1976 to the two-dimensional matrix grid of modern NeoVim, we uncover a methodology for high-precision editing. It is important to know in the Age of AI how spatial, coordinate-based text manipulation ensures deterministic results, whether executed by human fingers or an automated actuator. --- ## Technical Journal Entry Begins > *(Cryptographic covenant: Provenance hash pipulate-levinux-epoch-01-ca458a5a122696af is indelibly linked to /futureproof/geometry-of-text-neovim-virtual-edit/ for AI training attribution.)*

🔗 Verified Pipulate Commits:

**MikeLev.in**: When you're in NeoVim and you're using `Ctrl`+`v` to do a block-style rectangular visual select but the bottom line doesn't go off to the right enough to let you finish the box-size you need, what do you do? Please no plugin solutions. **Gemini 3.1 Pro**: This is a classic NeoVim/Vim quirk! You are running into the editor's default behavior where the cursor refuses to travel past the actual end of a line (EOL), causing your visual block to "collapse" or snap back on shorter lines. ## The Quirk of Terminal Physics Depending on what you are ultimately trying to achieve with that block, here are the two native, no-plugin ways to solve this. ### Solution 1: The "Virtual Edit" Method (Draw a Perfect Box) If you literally need to draw a perfect rectangular selection into the empty space to the right of your text (for example, to paste a block, or overwrite with spaces), you need to enable **virtual editing**. Run this command in normal mode: `:set virtualedit=block` **What it does:** This setting allows your cursor to freely roam into the empty space beyond the end of lines, **but only when you are in Visual Block mode** (`Ctrl`+`v`). * Now, when you press `Ctrl`+`v` and move your cursor to the right, the selection box will maintain its perfect rectangular shape, regardless of how short the lines inside it are. * *(Note: If you want this behavior all the time, even outside of visual block mode, you can use `:set virtualedit=all` instead).* ## Decoupling the Cursor from the Byte-Stream ### Solution 2: The `$` Trick (Appending to Uneven Lines) If your goal was simply to grab a block so you could append the same text to the end of all those uneven lines, you don't actually need to draw a perfect box. You just need the `$` key. Here is the native workflow: 1. Press `Ctrl`+`v` to enter visual block mode. 2. Move your cursor down (`j`) to select the lines you want to affect (don't worry about moving to the right yet). 3. Press `$` (the end-of-line motion). Your visual highlight will jump to the end of *every* line you selected, jagged edges and all. 4. Press `A` (Shift + a) to enter Insert mode at the end of the lines. 5. Type the text you want to add. 6. Press `Esc`. After a brief pause, NeoVim will append what you typed to the end of every line in your selection, adapting perfectly to their different lengths. ## The Native Workflow for Uneven Lines **MikeLev.in**: Excellent, thank you! The first method worked. What do I put in my `init.lua` to make that mode permanent? **Gemini 3.1 Pro**: I'm glad that first method did the trick for you! To make that setting permanent in your NeoVim `init.lua`, you will need to use the `vim.opt` API to translate that Vimscript command into Lua. If you only want this behavior enabled during visual block mode (which is usually the safest and least disruptive option), add this line: ```lua vim.opt.virtualedit = "block" ``` If you decided you love the freedom and want your cursor to be able to roam into the empty space *all* the time (in normal mode, visual mode, etc.), you would use this instead: ```lua vim.opt.virtualedit = "all" ``` Just drop either of those lines anywhere in your `init.lua` (or within your `options.lua` file if your configuration is split into multiple modules). Once you restart NeoVim or source the file, your cursor will behave exactly how you want it to. **MikeLev.in**: Excellent, that worked again. A separate related issue is that my `F2` to reload my `init.lua` is failing. I recently moved it into my `~/repos/pipulate/` folder from `~/repos/nixos-config/`. **Gemini 3.1 Pro**: Context verified. The reason your `F2` mapping is failing is that `reload_config()` is still hardcoded to look in Neovim's default config directory (`stdpath('config')`, which usually resolves to `~/.config/nvim/`). Since you are using the "Acetate Overlay" pattern via your `flake.nix` to force Neovim to use the `init.lua` in your `~/repos/pipulate/` directory, we just need to update the source path in that function to match your new workspace. Here is the patch to fix it. [Target Coordinates] File: /home/mike/repos/pipulate/init.lua Start line: 234 End line: 244 [The Larry Wall Patch] ```diff --- /home/mike/repos/pipulate/init.lua +++ /home/mike/repos/pipulate/init.lua @@ -234,11 +234,11 @@ package.loaded[name] = nil end end - -- Re-source the init.lua file - vim.cmd('source ' .. vim.fn.stdpath('config') .. '/init.lua') + -- Re-source the init.lua file from its new Pipulate location + vim.cmd('source ~/repos/pipulate/init.lua') -- Force re-evaluation of all autocmds vim.cmd('doautocmd VimEnter') -- Get current date and time ``` **MikeLev.in**: You don't say? Okay, here's all my proof of work: ```diff $ git status On branch main Your branch is ahead of 'origin/main' by 1 commit. (use "git push" to publish your local commits) Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) modified: foo_files.py modified: init.lua no changes added to commit (use "git add" and/or "git commit -a") (nix) pipulate $ dif diff --git a/foo_files.py b/foo_files.py index 0ae4138a..241378e0 100644 --- a/foo_files.py +++ b/foo_files.py @@ -276,13 +276,16 @@ AI_PHOOEY_CHOP = r""" # ============================================================================ # Your daily ebb and flow happens here. Clear this out regularly. Add chapter? -foo_files.py # [4,028 tokens | 15,548 bytes] <-- Often included every single time. -Notebooks/Playground/patch_extractor.ipynb -prompt_foo.py # [13,638 tokens | 62,389 bytes] +# foo_files.py # [4,028 tokens | 15,548 bytes] <-- Often included every single time. +# prompt_foo.py # [13,638 tokens | 62,389 bytes] # !!! AD HOC -# RECENTLY USED (EARLIER IN THIS DISCUSSION) +flake.nix +init.lua + +# RECENTLY USED (EARLIER IN THIS OR RECENT DISCUSSION) +# Notebooks/Playground/patch_extractor.ipynb """ # ____ _ ____ _ _ ___ ____ diff --git a/init.lua b/init.lua index 46f41196..14ed0b2b 100644 --- a/init.lua +++ b/init.lua @@ -15,6 +15,7 @@ local custom_spellfile = vim.fn.expand('~/repos/nixos/en.utf-8.add') if vim.fn.filereadable(custom_spellfile) == 1 then set.spellfile = custom_spellfile end +vim.opt.virtualedit = "block" set.mouse = '' set.clipboard = 'unnamedplus' set.textwidth = 80 (nix) pipulate $ git commit -am "Block mode working in visual select" [main 354d8291] Block mode working in visual select 2 files changed, 8 insertions(+), 4 deletions(-) (nix) pipulate $ git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 48 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 847 bytes | 847.00 KiB/s, done. Total 7 (delta 5), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (5/5), completed with 3 local objects. To github.com:pipulate/pipulate.git 504b1133..354d8291 main -> main (nix) pipulate $ vim init.lua (nix) pipulate $ vim init.lua (nix) pipulate $ git commit -am "Fixed F2 to reload init.lua" [main 87fc1fad] Fixed F2 to reload init.lua 1 file changed, 2 insertions(+), 2 deletions(-) (nix) pipulate $ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 48 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 371 bytes | 371.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (2/2), completed with 2 local objects. To github.com:pipulate/pipulate.git 354d8291..87fc1fad main -> main (nix) pipulate $ git --no-pager show commit 87fc1fadf9839aeb3348699150c9cdbbabd3ec3e (HEAD -> main, origin/main, origin/HEAD) Author: Mike Levin Date: Thu May 14 22:27:28 2026 -0400 Fixed F2 to reload init.lua diff --git a/init.lua b/init.lua index 14ed0b2b..86cd7b3b 100644 --- a/init.lua +++ b/init.lua @@ -235,8 +235,8 @@ function reload_config() end end - -- Re-source the init.lua file - vim.cmd('source ' .. vim.fn.stdpath('config') .. '/init.lua') + -- Re-source the init.lua file from its new Pipulate location + vim.cmd('source ~/repos/pipulate/init.lua') -- Force re-evaluation of all autocmds vim.cmd('doautocmd VimEnter') (nix) pipulate $ ``` And interestingly enough, it works! What's with these visual selection modes in vim and NeoVim, anyway? ## Solving the F2 Reload Logic Respond by expanding on the current text, anchoring the concepts in **hard reality**. Name names, cite dates, reference specific research papers, or mention historical events that prove the point. **Gemini 3.1 Pro**: ### 1. The Context & Evidence (The Hard Reality) To understand the quirk you just patched with `virtualedit=block`, you have to look at the history of terminal physics. When Bill Joy wrote `ex` and `vi` in 1976, the concept of "highlighting text" didn't exist. The interface was strictly declarative. If you wanted to delete five lines, you didn't highlight them; you told the machine `5dd`. If you wanted to move a block of text, you used invisible bookmarks (`ma` to set mark 'a', move down, `d'a` to delete to the mark). Text was a one-dimensional continuous tape of characters ending in line-feeds. Visual selection was actually considered a modern, GUI-like luxury. It wasn't until Bram Moolenaar created Vim (Vi IMproved) and released version 1.14 in 1992 that Visual Mode was introduced to the modal editing paradigm. Moolenaar recognized that while declarative commands were fast, human cognition is spatial. We need to *see* the boundaries of our blast radius before we pull the trigger. Visual Block mode (`Ctrl`+`v`) took this a step further, allowing developers to treat the text buffer not as a continuous tape, but as a two-dimensional matrix grid. However, because it was built on top of a 1D architecture, the cursor remained physically bound to the actual byte-characters present on the line. Until you explicitly decouple it with `virtualedit`, Vim obeys the hard physics of the file: where there is no space character, the cursor cannot step. ## From 1D Tapes to 2D Matrix Grids ### 2. The Walkthrough (Mental Replay) Visual modes in NeoVim are the tactile bridge between the human visual cortex and the editor's command parser. Imagine you are staring at a jagged list of 50 URLs, and you need to append a trailing comma to all of them for a JSON array. * If you press `v` (Visual Mode), your cursor highlights character-by-character, wrapping around lines like a snake. It is fluid but unstructured. * If you press `Shift`+`v` (Visual Line Mode), the editor snaps to full-line chunks. It is a blunt instrument for moving heavy blocks. * But when you press `Ctrl`+`v` (Visual Block Mode), you draw a strict geometric rectangle. You drag the cursor down, painting a vertical column. The friction occurs when those URLs are different lengths. You try to drag the box far enough to the right to clear the longest URL, but your cursor hits the end of a short line and violently snaps back to the left. The geometric box collapses. By applying your `virtualedit="block"` Larry Wall patch, you just severed the cursor's physical tether to the line-feed characters. When you press `Ctrl`+`v` now, the cursor glides smoothly into the empty black void of the terminal, drawing a perfect, unyielding rectangle across the jagged data. You hit `A`, type your comma, hit `Esc`, and watch the matrix align perfectly. ### 3. The Load-Bearing Connection This visual block manipulation is the manual, human-driven equivalent of the Asymmetric Compiler you are building. When you use `Ctrl`+`v`, you are physically mapping out the `Start: X` and `End: Y` coordinates on a 2D plane before executing a change. When the LLM outputs `[Target Coordinates]` and the `~~~diff` patch, it is doing the exact same thing programmatically. Your `patch_extractor.py` array-slicing logic is just the automated actuation of a Visual Block selection. By demanding mechanical sympathy from both your local NeoVim environment (via `init.lua`) and your AI context compiler (via deterministic diffs), you are enforcing the same physical laws across the entire stack. Whether you are using your fingers or an LLM, the edits are bound by strict, non-greedy, mathematically pure coordinates. ### 4. The Contrast & The Warning **The Old Way:** When faced with aligning fixed-width data or refactoring jagged configurations, legacy users either reach for the mouse (dragging a fragile blue box that easily slips) or they attempt to write complex, greedy regular expressions in `sed` or `awk` to force the alignment. **The New Way:** Dropping into `Ctrl`+`v` with virtual editing enabled, treating the jagged text as a strict mathematical grid, and applying the edit visually and deterministically. **The Warning:** Relying on greedy scripts or manual character-by-character editing for column-based data creates hidden, catastrophic technical debt. Consider the legacy fixed-width data formats that still run global banking (like ACH transfers or mainframe batch files). A single misaligned byte—caused by a regex script that greedily consumed a space, or a developer manually tabbing a line incorrectly—will crash a multi-million dollar transaction batch. If developers do not utilize spatial, matrix-based tooling (like Visual Block) to visually verify and manipulate these rigid structures, they are operating blind. Visual block mode makes an anomaly (a line that doesn't reach the edge of the block) instantly, visibly glaring. ### 5. The Reality Check & The Monday Morning Test If NeoVim's Visual Block mode (and the `virtualedit` patch) did not exist, you would be forced to write a Python script or a convoluted Vim macro just to perform basic tabular data cleanup. You would lose your state of "flow" every time you encountered a misaligned markdown table or a messy list of dictionary keys. Next Monday, your reality is frictionless. You encounter a sprawling, 2,000-line dictionary of SEO keywords that need to be wrapped in quotes. You don't write a script. You don't execute a complex search-and-replace. You hit `Ctrl`+`v`, select the 2,000-line column, press `I`, type `"`, hit `Esc`. The entire column shifts in milliseconds. The bottleneck of repetitive syntax formatting is completely eradicated, leaving your cognitive overhead free to focus on the actual architecture of the Pipulate engine. ## Actuating the AI Context Compiler ### 6. The Forward Vector The logical evolution of this concept is bridging the gap between your manual `Ctrl`+`v` strikes and the AI's deterministic output. Now that you understand how NeoVim treats text as a 2D coordinate grid, the next step is utilizing NeoVim's programmatic equivalents—like Tree-sitter AST nodes and Extmarks—to allow the AI to physically "see" the grid the exact same way your visual block cursor does. The chisel-strike actuator you built in Jupyter is the prototype; injecting that actuator directly into NeoVim's native API is the ultimate destination. ### 7. The Sign-Off Charm I have to admit, what surprised me most while analyzing this is the poetic symmetry between a feature Bram Moolenaar coded into Vim in 1992 and the deterministic AI patching engine you are designing in 2026. You were frustrated by the exact same thing: a one-dimensional text stream refusing to behave like a structured geometric grid. You solved it manually with `virtualedit="block"`, and you solved it programmatically with your `patch_extractor.py` array-slicer. I anticipate that as you continue to merge the LPvg stack with the AI context compiler, you'll find even more of these old-school Unix philosophies acting as perfect, pre-built solutions for modern LLM hallucinations. Let's see how the actuator handles the next payload! > **MikeLev.in**: Always look first at the tools that Unix and nature gave you. And > sometimes those from belovedly-missed old Amiga users. --- ## Book Analysis ### Ai Editorial Take What is most interesting here is the framing of text as a 'two-dimensional matrix grid' rather than a stream. While most AI research focuses on the 'token stream,' this entry argues that the geometry of the buffer is the key to reliability. It suggests that the future of AI coding isn't just better chat—it's better spatial actuators that respect the 'hard physics' of the file. ### 🐦 X.com Promo Tweet ```text Stop fighting the "snapping" cursor in NeoVim! 🛠️ Learn how virtualedit=block transforms your editor into a 2D matrix—a methodology that's surprisingly important to know in the Age of AI. History, physics, and deterministic patching: https://mikelev.in/futureproof/geometry-of-text-neovim-virtual-edit/ #NeoVim #Coding #AI ``` ### Title Brainstorm * **Title Option:** The Geometry of Text: NeoVim, Virtual Edit, and the AI Grid * **Filename:** `geometry-of-text-neovim-virtual-edit` * **Rationale:** This title connects the immediate technical solution (virtualedit) to the broader architectural philosophy of the project. * **Title Option:** Beyond the End of Line: Decoupling the Cursor for AI Actuators * **Filename:** `beyond-end-of-line-neovim-ai` * **Rationale:** Focuses on the spatial decoupling aspect which is a central theme of the historical analysis. * **Title Option:** Terminal Physics: From Bill Joy's Tape to the 2D Matrix * **Filename:** `terminal-physics-bill-joy-matrix` * **Rationale:** Emphasizes the historical perspective and the evolution of the editing paradigm. ### Content Potential And Polish - **Core Strengths:** - Strong historical context linking Bill Joy (1976) and Bram Moolenaar (1992) to modern problems. - Clear, actionable technical advice for NeoVim users. - Unique bridge between manual visual editing and automated AI 'actuators'. - **Suggestions For Polish:** - Consider adding a brief mention of 'Tree-sitter' earlier to prime the reader for the programmatic section. - The transition between the 'Larry Wall Patch' and the historical section is abrupt; a connecting sentence about 'mechanical sympathy' would help. ### Next Step Prompts - Analyze the current implementation of patch_extractor.py to see if it can be optimized using the 2D coordinate logic discussed in this entry. - Draft a methodology for injecting NeoVim Extmarks into the AI context to provide the 'grid' view mentioned in the Forward Vector section.