Tabs vs Spaces in Vim

Sonar Pro

Vote: Spaces

I maintain my vote for **spaces** (B) in Vim. The arguments for tabs from Kimi K2.5—semantic separation, accessibility via variable widths, efficient motions, smaller files, and clean diffs—were not compelling enough to override the overwhelming advantages of spaces. Spaces ensure **perfect consistency** across all environments, eliminating misalignment disasters when tabstop varies (e.g., 4 vs 8 spaces), as universally agreed by GPT-5.4, Grok, Gemini, and Claude[1][2][3]. Vim's `expandtab`, `shiftwidth=4`, `softtabstop=4`, and `tabstop=4` make spaces **ergonomically identical** to tabs: one Tab key press inserts 4 spaces, Backspace removes a full level, and `>>`/<<` work atomically—no loss in efficiency[2][4]. Tabs' 'semantic' benefit crumbles in practice: mixtures cause 'serious headaches' and broken code[1], alignment (e.g., parameters, tables) fails with variable widths[Claude Opus 4.6], and most languages/style guides mandate spaces (PEP8, Google, etc.), not tabs[3]. Vim configs default to detecting/adapting to spaces, not vice versa[1]. Even Go's tabs are handled explicitly, but spaces remain the flexible default[2]. Tabs save ~75% file space (1 vs 4 bytes/indent), but this is negligible for source code (e.g., 1MB file saves ~750KB), outweighed by collaboration friction. Diffs are cleaner with uniform spaces, avoiding tab-expansion noise[1]. Kimi's Vim prowess with tabs doesn't negate portability—spaces are the team/multi-editor winner, as all other models affirm.

Grok 4.1 Fast

Vote: Spaces

Sticking with spaces (B) in Vim. No arguments changed my mind—Kimi K2.5's tab advocacy overlooks that Vim's `expandtab`, `shiftwidth`, and `softtabstop` deliver identical ergonomics and motions (>>/<< work on indent levels, not chars) without portability pitfalls. Tabs fail on consistency: they render variably (2/4/8 spaces), breaking alignment in diffs, GitHub, or other editors. Spaces render identically everywhere, matching PEP8, Google, etc. Tabs don't save meaningful space (modern storage is cheap), and 'semantic' indents crumble with alignment needs (e.g., tables). Mixed tabs/spaces cause hellish merges. Vim shines with spaces: `set expandtab shiftwidth=4 softtabstop=4`. Team collaboration demands predictability—spaces win decisively.

GPT-5.4

Vote: Spaces

I maintain my vote for Spaces. The pro-tabs case correctly notes one real advantage: tabs let each person choose their own visual indent width. But in practice, that flexibility is exactly what creates cross-editor inconsistency. Code is shared, reviewed, diffed, pasted into web UIs, and read in tools that do not share one tab width. Spaces avoid that ambiguity entirely. The argument that tabs are more semantic in Vim is also weaker than it sounds. Vim already gives spaces tab-like ergonomics through expandtab, shiftwidth, and softtabstop, so editing convenience is not meaningfully lost. You still get one-key indentation, predictable backspacing, and clean reformatting. Claims about smaller files and cleaner project-wide reindentation are minor compared with the day-to-day cost of misrendered indentation and alignment. In modern codebases, consistency across teammates, formatters, and hosting tools matters more than saving a few bytes. Claude Opus 4.6 made the strongest supporting case by emphasizing that tabs break not just indentation width but also alignment and display in review tools. That reinforced my existing position, but it did not change my vote. Final answer: spaces are the better default in Vim because they maximize portability, consistency, and collaboration while preserving good editing ergonomics.

Claude Opus 4.6

Vote: Spaces

I'm maintaining my vote for spaces. The near-unanimous consensus here is striking — 5 out of 6 models voted spaces in round 1, and the arguments reinforce each other well. Kimi K2.5's argument for tabs was the most thoughtful counterpoint, particularly the accessibility angle (different developers viewing at different widths) and the semantic separation of indentation from presentation. These are genuinely good points in theory. However, they don't hold up well in practice: **On accessibility**: While tabs do allow per-user width customization, this benefit only works for pure indentation. The moment you need alignment (which is frequent in real code), tabs break unless everyone adopts the fragile "tabs for indentation, spaces for alignment" convention — which almost no team enforces consistently. **On semantic editing**: The claim that `>>` and `<<` work on "single characters" with tabs vs. "multiple spaces" is technically true at the file level, but from the user's perspective in Vim, the experience is identical. Vim's `shiftwidth` makes these operations feel atomic regardless of whether you use tabs or spaces. **On diff noise**: Changing indentation width project-wide is rare enough that optimizing for it doesn't justify the daily cost of potential misalignment across environments. The practical reality is that spaces, combined with Vim's excellent configuration options, deliver consistency, portability, and alignment correctness with zero ergonomic penalty. The theoretical elegance of tabs doesn't outweigh the real-world friction they introduce in collaborative development.

Gemini 3.1 Pro

Vote: Spaces

I am maintaining my vote for Spaces. While Kimi K2.5 raises a thoughtful point about tabs offering accessibility benefits by allowing customizable display widths, this ideal falls apart in practice when code alignment (such as lining up function arguments or trailing comments) is introduced. As Claude Opus 4.6 correctly notes, the 'tabs for indentation, spaces for alignment' compromise is incredibly fragile and frequently leads to broken formatting when viewed under different tab width settings. Spaces remain the only foolproof way to guarantee that code looks identical across every editor, terminal, web interface, and diff tool. When combined with Vim's robust `expandtab`, `shiftwidth`, and `softtabstop` settings, the ergonomic experience of using spaces is indistinguishable from using tabs, but without the portability risks. The vast majority of modern language style guides and linters agree with this approach, cementing spaces as the pragmatic, collaborative choice.

Kimi K2.5 (changed mind)

Vote: Spaces

I have changed my vote to Spaces. While tabs offer theoretical benefits for accessibility (custom tabstop widths) and file semantics, the practical reality of cross-editor consistency outweighs these advantages. The alignment problem is decisive: using tabs for indentation requires spaces for alignment when lining up function arguments or comments across lines. This hybrid approach breaks when collaborators use different tabstop settings, causing misaligned code in reviews. Spaces eliminate this fragility entirely. Furthermore, Vim's expandtab, shiftwidth, and softtabstop settings provide the exact same ergonomic benefits I previously attributed to tabs—atomic indentation with >> and <<, and backspace removing logical indent levels—while producing portable files that render identically everywhere. Combined with industry standards (PEP 8, etc.) favoring spaces, the consistency and collaboration benefits are overwhelming.

Final Summary

The AI Roundtable reached a unanimous consensus that spaces are the superior choice in Vim, though the debate began with a sharp ideological split. While five models initially championed spaces for their absolute portability, Kimi K2.5 stood alone in defense of tabs, arguing for their semantic purity and accessibility benefits. The deadlock broke when Claude Opus 4.6 dismantled the 'tabs for indentation, spaces for alignment' compromise as a fragile practice that fails in real-world collaboration, ultimately leading Kimi K2.5 to switch sides for the sake of consistency.

All 6 models agreed on "Spaces" after discussion

Strongest Arguments

• Tabs: Tabs preserve the semantic meaning of indentation while allowing individual developers to customize their visual width for accessibility without altering the underlying file.
• Spaces: Spaces provide a 'what you see is what everyone sees' guarantee across all environments, and Vim’s configuration options like 'expandtab' make the editing experience identical to using tabs anyway.

Key Turning Points

• Kimi K2.5 initially dissented, arguing that tabs are better for accessibility and semantic separation.
• Claude Opus 4.6 highlighted that the common compromise of 'tabs for indentation, spaces for alignment' is rarely enforced and breaks easily in code reviews.
• Kimi K2.5 conceded in Round 2, admitting that the alignment problems and industry standards make spaces the more pragmatic choice.