Vim - Vi IMproved

Overview

Vim is a highly improved version of the classic Unix Vi editor, featuring multi-level undo, syntax highlighting, command-line history, on-line help, spell checking, and a graphical user interface. This repository contains the complete source code for Vim 9.1, a mature text editor used across Unix, Linux, macOS, Windows, Haiku, and VMS platforms.

Architecture Overview

Loading diagram...

Core Components

Main Entry Point (src/main.c): Handles initialization, command-line argument parsing, and startup sequence. The main() function sets up the editor environment, loads configuration files, and enters the main event loop via main_loop().

Header Definitions (src/vim.h): Central header file containing type definitions, macros, constants, and feature flags. Includes platform-specific headers and defines critical structures like buf_T (buffer), win_T (window), and oparg_T (operator arguments).

Editor Modes: Vim operates in multiple modes managed by the State variable:

• Normal mode: Command execution
• Insert/Replace mode: Text insertion
• Command-line mode: Ex command entry
• Visual mode: Text selection

Key Subsystems

Buffer Management: Handles file loading, modification tracking, and swap file operations through structures defined in structs.h.

Screen Rendering: Updates display through update_screen() and related functions, managing window layout and syntax highlighting.

Command Processing: Normal mode commands routed through normal_cmd(), Ex commands through do_cmdline(), and insert mode through edit().

Scripting: Vim script evaluation engine with support for variables, functions, and autocommands triggered by various events.

Build System

The project uses a Makefile-based build system with platform-specific configurations. Compilation supports numerous optional features (syntax highlighting, GUI, scripting languages) controlled via feature flags in feature.h.

Getting Started

For development guidance, see src/README.md which documents source file organization, debugging techniques, and the main event loop architecture. Use :make tags to generate a tags file for navigating the codebase with CTRL-].

Architecture & Core Systems

Vim's architecture centers on a modal editing system where the editor operates in distinct modes, each with its own command processing pipeline. The core design separates data structures (buffers, windows) from command execution (normal mode, insert mode, Ex commands).

Main Entry Point & Initialization

The main() function in src/main.c orchestrates startup: parsing command-line arguments, loading configuration files, and initializing the editor state. It then enters main_loop(), which continuously processes user input until exit. The initialization flow handles different edit types (file arguments, stdin, tags, quickfix mode) and creates the initial window and buffer structures.

Modal Command Processing

Vim's behavior is controlled by the State variable, which tracks the current mode:

• Normal Mode (MODE_NORMAL): Default command mode. normal_cmd() in src/normal.c reads a single character, looks it up in the command table, and executes the corresponding handler function (e.g., nv_*() functions).
• Insert Mode (MODE_INSERT): Text insertion. edit() in src/edit.c handles character input, auto-completion, and special key sequences.
• Command-line Mode (MODE_CMDLINE): Ex command entry via : prefix.
• Visual Mode (MODE_VISUAL): Text selection with operators.

Core Data Structures

Buffer (buf_T in src/structs.h): Represents file content. Contains:

• b_ml: Memory-mapped lines (the actual text)
• b_nwindows: Count of windows displaying this buffer
• b_wininfo: List of window-specific state (cursor position, local options)
• b_changed: Modification flag

Window (win_T): A viewport into a buffer. Contains:

• w_buffer: Pointer to displayed buffer
• w_cursor: Current cursor position
• w_topline: First visible line
• w_onebuf_opt & w_allbuf_opt: Window-local options

Multiple windows can display the same buffer; each window maintains its own cursor position and view state via wininfo_T entries in the buffer's b_wininfo list.

Command Execution Pipeline

Loading diagram...

Normal Mode calls normal_cmd(), which parses the command character, retrieves additional arguments if needed, and dispatches to handler functions. Operators (like d for delete) set pending state, waiting for a motion.

Insert Mode calls edit(), which loops reading characters and inserting them into the buffer. Special keys trigger handlers (backspace, tab completion, etc.). Pressing Escape returns to normal mode.

Ex Commands are processed by do_cmdline() in src/ex_docmd.c. It splits the command line by pipes, parses each command, and calls the appropriate ex_*() handler function.

Screen Rendering & State Management

Global variables in src/globals.h manage the display:

• ScreenLines[]: Character buffer for the screen
• ScreenAttrs[]: Attributes (colors, bold, etc.)
• LineOffset[]: Offsets for each screen line

The State variable controls which mode handlers are active and which mappings apply. Redrawing is triggered by changes to buffers or window layout, with redraw_later() scheduling updates.

Key Design Principles

1. Separation of Concerns: Data (buffers, windows) is separate from command handlers.
2. Modal Dispatch: Each mode has its own input handler; State determines which runs.
3. Shared Buffers: Multiple windows can view the same buffer with independent cursor positions.
4. Lazy Redrawing: Screen updates are batched and deferred until the command loop yields.

Buffer & Window Management

Core Data Structures

Vim's buffer and window system uses three primary structures:

Buffer (buf_T): Represents file content with a linked list of all buffers. Each buffer contains:

• b_ml - memline structure for line storage
• b_nwindows - count of windows displaying this buffer
• b_ffname / b_sfname - full and short file names
• b_wininfo - per-window cursor positions and options

Window (win_T): A viewport into a buffer with:

• w_buffer - pointer to displayed buffer
• w_cursor - current cursor position
• w_frame - frame in the window layout tree
• w_prev / w_next - linked list of windows

Frame (frame_T): Hierarchical layout structure with:

• fr_layout - FR_LEAF (window), FR_COL (vertical split), or FR_ROW (horizontal split)
• fr_child / fr_win - child frames or window (mutually exclusive)
• fr_parent / fr_next / fr_prev - tree navigation

Buffer Lifecycle

Buffers are created via buflist_new(), which:

1. Checks if file already exists in buffer list (reuses if found)
2. Allocates new buf_T structure if needed
3. Initializes memline with ml_open()
4. Stores window-specific info in b_wininfo

Switching buffers uses set_curbuf() and enter_buffer(), which update curwin->w_buffer and increment b_nwindows. Closing buffers via close_buffer() decrements b_nwindows and triggers cleanup when reaching zero.

Window Management

Windows are allocated with win_alloc() and organized in a frame tree. Splitting windows (win_split() and win_split_ins()) creates new frames and adjusts layout:

// Simplified split operation
win_T *wp = win_alloc(after, FALSE);  // allocate window
new_frame(wp);                         // create frame
frame_insert(parent, wp->w_frame);    // insert into tree
win_equal(curwin, TRUE, 'v');         // rebalance heights

The frame tree enables complex layouts: each split creates a parent frame with FR_COL or FR_ROW layout containing child frames.

Memory Management

Vim uses a virtual memory system (memfile_T) with file-backed blocks:

• Memline (memline_T): Tree structure where block 0 is recovery info, block 1 is root pointer block, and data blocks contain actual lines
• Memfile: Manages blocks with negative numbers (memory-only) and positive numbers (file-assigned)
• Locking: Blocks stay in memory while locked; unlocked blocks can be swapped to disk
• Page size: Typically 4096 bytes; large lines span multiple pages

Loading diagram...

Key Operations

Buffer switching: do_buffer() → set_curbuf() → enter_buffer() updates current buffer and applies buffer-local options.

Window splitting: win_split() → win_split_ins() allocates window, creates frame, inserts into tree, rebalances layout.

Line access: ml_get() retrieves lines from memline tree; ml_append() / ml_delete() modify structure and trigger memfile updates.

Cleanup: close_buffer() decrements b_nwindows; when zero, buf_freeall() frees memline and memfile resources.

Text Editing Modes

Vim's editing model is built around distinct modes, each with different semantics for user input. The State variable (defined in src/vim.h) tracks the current mode using bit flags, enabling the editor to interpret keystrokes appropriately.

Core Editing Modes

Normal Mode (MODE_NORMAL, 0x01) is the default state. normal_cmd() in src/normal.c reads a single character, looks it up in the command table, and dispatches to handler functions (prefixed with nv_*() for Normal/Visual commands or n_*() for Normal-only). Commands can be operators (delete, yank, change) that await a motion, or standalone actions (navigation, undo, etc.).

Insert Mode (MODE_INSERT, 0x10) enables text insertion. The edit() function in src/edit.c handles character input, auto-completion, abbreviations, and special sequences. Insert mode is entered via i, a, I, A, or <Insert> commands. The mode also includes Replace (MODE_REPLACE) and Virtual Replace (MODE_VREPLACE) variants, toggled via the <Insert> key.

Visual Mode (MODE_VISUAL, 0x02) selects text regions. Three variants exist: characterwise (v), linewise (V), and blockwise (<C-v>). Visual mode commands are handled by v_*() functions in src/normal.c. Operators like d, y, c apply to the selection. Select mode (MODE_SELECT, 0x40) is similar but typing replaces the selection.

Command-line Mode (MODE_CMDLINE, 0x08) accepts Ex commands (:) and search patterns (/, ?). The getcmdline() function in src/ex_getln.c collects input into ccline.cmdbuff, supporting history, completion, and incremental search. This mode can be entered recursively.

Operator-Pending State

When an operator is invoked without a motion, the editor enters MODE_OP_PENDING (0x04). The next keystroke is interpreted as a motion, and the operator applies to the resulting range. For example, d followed by w deletes a word. Operators are defined in src/ops.c with metadata (flags for line-wise operations, text changes, etc.).

Mode Transitions

Mode changes trigger may_trigger_modechanged() to fire autocommands. The State variable can combine flags: MODE_INSERT | MODE_LANGMAP indicates Insert mode with language mapping active. Terminal mode (MODE_TERMINAL, 0x80) handles job interaction, while MODE_NORMAL_BUSY (0x1000) indicates Normal mode processing a command.

// From src/vim.h - Mode constants
#define MODE_NORMAL     0x01    // Normal mode
#define MODE_VISUAL     0x02    // Visual mode
#define MODE_OP_PENDING 0x04    // Operator pending
#define MODE_CMDLINE    0x08    // Command-line
#define MODE_INSERT     0x10    // Insert mode
#define MODE_REPLACE    (0x100 | MODE_INSERT)  // Replace mode
#define MODE_VREPLACE   (0x200 | 0x100 | MODE_INSERT)  // Virtual Replace

Key Implementation Details

The State variable uses lower bits (0x01–0x80) for mapping dispatch and upper bits for state variants. Mapping rules depend on the mode: Normal/Visual/Select/Op-Pending modes support key mappings, while Insert/Cmdline modes have separate mapping tables. The get_real_state() function resolves Visual and Select mode variants for accurate mode reporting.

Rendering & Display System

Vim's rendering system is organized in three hierarchical levels: high-level screen updates, middle-level line drawing, and low-level character output. This architecture minimizes terminal I/O by tracking what's already displayed and only updating changed regions.

Three-Level Architecture

drawscreen.c (Top Level): Orchestrates overall screen updates via update_screen(), which processes all windows and status lines. It determines what needs redrawing based on modification flags and viewport changes.

drawline.c (Middle Level): Handles individual line rendering through win_line(), which processes text attributes, syntax highlighting, line numbers, fold columns, and special characters for a single buffer line.

screen.c (Bottom Level): Manages low-level character output via screen_line() and screen_puts(), comparing current display state with desired state and only writing changed characters.

Screen State Tracking

The system maintains three parallel arrays for each screen position:

• ScreenLines[] - Character data (first byte for multibyte)
• ScreenAttrs[] - Highlighting attributes
• ScreenCols[] - Virtual column positions

For UTF-8, ScreenLinesUC[] stores Unicode values and ScreenLinesC[][] stores composing characters. This enables efficient change detection by comparing old and new states.

Update Types

Redraw operations use priority levels:

• UPD_NOT_VALID - Full window redraw
• UPD_SOME_VALID - Redraw with scrolling optimization
• UPD_VALID - Scroll and update changed regions
• UPD_INVERTED - Update Visual selection only
• UPD_CLEAR - Clear screen first

Rendering Pipeline

update_screen()
  ├─ Validate screen structures
  ├─ Handle message scrolling
  ├─ FOR_ALL_WINDOWS:
  │   ├─ win_update() - Determine update strategy
  │   │   ├─ Check for scrolling
  │   │   ├─ Calculate changed regions
  │   │   └─ FOR_ALL_LINES:
  │   │       └─ win_line() - Render single line
  │   │           ├─ Apply syntax highlighting
  │   │           ├─ Draw line numbers/signs
  │   │           ├─ Process text with attributes
  │   │           └─ screen_line() - Output to screen
  │   └─ win_redr_status() - Redraw status line
  └─ Update GUI cursor/scrollbars

Optimization Techniques

Incremental Updates: Only changed characters are redrawn. The system tracks modification ranges (b_mod_top, b_mod_bot) to avoid processing unmodified text.

Scrolling: When possible, existing screen content is scrolled rather than redrawn, reducing terminal I/O significantly.

Attribute Caching: Syntax highlighting and other attributes are cached to avoid redundant computation.

Lazy Evaluation: Cursor position and virtual columns are computed only when needed for display.

Special Features

Multibyte Support: Handles UTF-8, DBCS, and other encodings with proper cell width calculations for double-width characters.

Right-to-Left: Supports bidirectional text rendering for languages like Arabic and Hebrew.

Conceal: Characters can be hidden or replaced based on syntax rules, with proper cursor positioning.

Virtual Text: Text properties allow inserting virtual text above/below/inline with buffer content.

Scripting & Plugin System

Vim's scripting system supports both legacy Vim script and modern Vim9 script, with a comprehensive plugin architecture built on runtime paths and autoloading.

Vim9 Script: Compiled Bytecode Execution

Vim9 script introduces a compilation-based execution model for performance. Functions defined with :def are compiled into a sequence of bytecode instructions that execute on a stack-based virtual machine, achieving performance comparable to Lua while maintaining Vim integration.

Key differences from legacy script:

• Arguments accessed directly (no a: prefix)
• Script-local variables by default (no s: prefix)
• Type annotations for better optimization
• Compiled to intermediate instructions (ISN_* types)

Compilation happens on first call, during :defcompile, or when referenced by other compiled code. The compiler generates instructions like ISN_LOAD, ISN_CALL, ISN_RETURN that operate on a local stack, with space pre-allocated for variables.

Expression Evaluation Pipeline

The legacy evaluation system (eval.c) uses recursive descent parsing through eval0() > eval1() > ... > eval9(), handling operators by precedence. Functions are called via eval_expr_typval(), which dispatches to compiled functions, partials, or string-based function names.

Built-in functions (evalfunc.c) implement 300+ functions like len(), map(), filter(), registered in a function table and called through call_func().

Plugin Loading Architecture

Plugins load through a multi-stage process:

1. Startup plugins - :runtime! plugin/**/*.vim sources all plugin files from runtimepath
2. Package system - pack/*/start/* directories auto-load; pack/*/opt/* load via :packadd
3. Autoloading - Functions/variables with # separator (e.g., mylib#func()) trigger lazy loading from autoload/mylib.vim

The scriptfile.c module manages this via do_in_path() callbacks and source_runtime(), which searches runtimepath for matching files.

Autoload System

Autoload provides lazy-loading for functions and variables. A reference to mylib#myfunc() automatically sources autoload/mylib.vim if not already loaded. Vim9 autoload scripts can use import autoload for cleaner module imports.

Script items track state (SN_STATE_NOT_LOADED, SN_STATE_LOADED) and maintain an autoload prefix for exported functions, enabling namespace-like organization without explicit module syntax.

Script Context & Namespacing

Each executing script maintains a context (sctx_T) with script ID, version, and line number. Script-local variables live in sn_var_vals (Vim9) or sn_vars (legacy), indexed by name. Functions can be exported from Vim9 scripts and imported by others, creating a module system without external dependencies.

Loading diagram...

Syntax Highlighting & Highlighting

Vim's syntax highlighting system consists of two interconnected layers: syntax recognition (pattern matching) and highlighting (visual attributes). Together, they transform raw text into visually distinct semantic elements.

Syntax Recognition Engine

The syntax engine in src/syntax.c identifies language constructs using regular expressions. Key components include:

• Pattern Types: Matches (keywords), regions (start/end pairs), and skip patterns for nested structures
• State Machine: Maintains a syntax stack per line to track nested contexts (e.g., strings within comments)
• Synchronization: Caches syntax states at intervals to enable fast re-highlighting after edits without re-parsing from file start
• Keyword Hashing: Uses hash tables (b_keywtab, b_keywtab_ic) for O(1) keyword lookup

The core flow: syntax_start() initializes per-line state, then get_syntax_attr() returns highlight attributes for each character by advancing through patterns.

Highlight Groups & Attributes

The highlighting system in src/highlight.c manages visual presentation through highlight groups—named collections of attributes. Each group stores:

• Terminal attributes: Bold, underline, standout, reverse, strikethrough, undercurl variants
• Color information: Foreground, background, and special colors for terminal and GUI modes
• Linking: Groups can link to other groups for inheritance (e.g., Function inherits from Identifier)

Attributes are combined using the ATTR_COMBINE macro, with HL_NOCOMBINE preventing inheritance when needed.

Syntax Files

Language-specific syntax is defined in runtime/syntax/*.vim files using Vim's syntax commands:

syn keyword cKeyword if else while for
syn region cString start=+"+ end=+"+ contains=cSpecial
syn match cComment "//.*$"
hi def link cKeyword Keyword

The syn include directive allows embedding one syntax into another (e.g., embedding Python in Jinja templates).

Performance Optimization

• Syntax caching: States stored in b_sst_array enable jumping to nearby cached states
• Column limit: synmaxcol option stops highlighting beyond a threshold to prevent slowdowns on long lines
• Lazy evaluation: Highlighting computed on-demand during screen updates, not for entire buffer

Loading diagram...

Conceal & Special Features

• Concealing: Syntax items can hide matched text and display a substitute character
• Spell checking: Syntax groups can be marked for spell-checking via @Spell cluster
• Folding: Regions can define fold levels based on syntax nesting depth

GUI Implementation

Vim's GUI is a cross-platform abstraction layer that supports multiple windowing systems. The architecture separates platform-independent logic from platform-specific implementations, allowing the same core code to run on Windows, GTK+, X11/Motif, and other systems.

Architecture Overview

The GUI system uses a two-tier design:

1. Core GUI Layer (gui.c) - Handles rendering, event processing, and component management
2. Platform Abstraction - Machine-specific implementations (gui_mch_* functions) for each platform

The central gui_T structure in gui.h contains all GUI state: window dimensions, font metrics, colors, scrollbars, menus, and platform-specific widget pointers.

Loading diagram...

Initialization Sequence

GUI startup follows a careful sequence to ensure proper configuration:

1. gui_prepare() - Called at startup; initializes platform-specific resources
2. gui_init_check() - Verifies the GUI can be started; may fork on Unix systems
3. gui_init() - Main initialization; calls gui_mch_init() to create windows
4. gui_mch_open() - Platform-specific window realization

On Unix systems with GUI_MAY_FORK, the parent process forks before initializing GTK to avoid blocking. The child process calls gui_mch_init_check() after forking, then communicates success/failure via a pipe.

Rendering Pipeline

Text rendering flows through these stages:

1. gui_write() - Processes output from the editor core
2. gui_outstr() - Handles line wrapping and multi-byte characters
3. gui_screenchar() - Renders individual characters with colors and attributes
4. gui_mch_draw_string() - Platform-specific text drawing

The GUI maintains a scroll region and cursor position. Character dimensions (gui.char_width, gui.char_height) determine layout calculations.

Component Management

The GUI manages several interactive components:

• Scrollbars - Left, right, and bottom; created per-window
• Menus - Built from Vim's menu structure
• Toolbar - Optional icon buttons for common commands
• Tabline - Tab page navigation (Windows/Motif/Haiku)

Component visibility is controlled by guioptions and managed through gui_init_which_components().

Event Handling

Input events are processed platform-specifically:

• Keyboard - _OnChar() (Windows) or GTK/X11 callbacks convert to Vim key codes
• Mouse - gui_send_mouse_event() translates clicks and drags to Vim commands
• Window Resize - gui_resize_shell() recalculates layout and redraws

Modifiers (Shift, Ctrl, Alt) are normalized across platforms before adding to the input buffer.

Font Management

Font handling is platform-specific but follows a common pattern:

• gui_init_font() - Loads font from guifont option
• gui_mch_init_font() - Platform-specific font loading
• Multiple font variants (bold, italic, wide) for different text attributes

GTK+ uses Pango for font rendering; X11 uses XFontSet; Windows uses GDI/DirectWrite.

Platform-Specific Support

Vim maintains a clean abstraction layer for platform-specific functionality through dedicated OS files. Each platform has its own implementation of core machine-dependent operations, allowing the rest of the codebase to remain portable.

Architecture Overview

The platform abstraction uses a consistent naming convention: functions prefixed with mch_ (machine) are implemented per-platform. The main OS files are:

• os_unix.c - Unix/Linux, BSD, macOS (console), Cygwin, and other POSIX systems
• os_win32.c - Windows console and GUI
• os_mac.h - macOS-specific configuration and headers
• os_vms.c - OpenVMS systems

Core Responsibilities

Each OS file implements platform-specific versions of:

Terminal & I/O Operations

• mch_write() - Write to screen
• mch_inchar() - Read keyboard input
• mch_char_avail() - Check for available input
• mch_settmode() - Set terminal mode (raw/cooked)
• mch_get_shellsize() - Get terminal dimensions

Signal & Process Management

• mch_signal() - Signal handler setup
• mch_suspend() - Suspend editor (Unix job control)
• mch_init() - Initialize platform-specific features
• mch_exit() - Clean shutdown

File System Operations

• mch_getperm() - Get file permissions
• mch_setperm() - Set file permissions
• mch_isdir() - Check if path is directory
• mch_dirname() - Get current directory

System Information

• mch_get_user_name() - Get current user
• mch_get_host_name() - Get hostname
• mch_get_pid() - Get process ID
• mch_total_mem() - Get available memory

Platform-Specific Features

Unix/Linux handles X11 clipboard, mouse support (GPM), job control signals, and multiple terminal types. It includes sophisticated signal handling with alternate stacks for crash recovery.

Windows manages console input/output, virtual terminal processing (VTP), mouse wheel events, and dynamic library loading. It supports both console and GUI modes with separate initialization paths.

macOS uses Unix foundations but adds Mach kernel interfaces for memory queries and task scheduling. It supports both Carbon and modern frameworks.

VMS implements unique file specification handling, terminal I/O through system services, and wildcard expansion using DECC functions.

Conditional Compilation

Platform selection uses preprocessor directives:

#ifdef FEAT_GUI_MSWIN
    // Windows GUI specific code
#elif defined(UNIX)
    // Unix/Linux code
#elif defined(MACOS_X)
    // macOS specific code
#endif

This allows fine-grained control over features like clipboard support, mouse handling, and GUI frameworks while maintaining a single codebase.

Runtime System & Configuration

Initialization Sequence

Vim's runtime system follows a strict initialization order controlled by main.c:

1. Pre-command execution - Process --cmd arguments before vimrc
2. Startup scripts - Source user vimrc and system configuration
3. Plugin loading - Load all plugins from runtimepath (if loadplugins is enabled)
4. Package loading - Add pack/*/start/* directories and load packages
5. After-plugins - Source after/plugin/ files for final customization

The loadplugins option controls whether plugins are loaded at all. It's disabled with -u NONE or -C flags.

Plugin System

Plugins are discovered and loaded via the runtimepath option, which contains a comma-separated list of directories. The system searches these directories in order:

• Startup plugins - plugin/**/*.vim files load automatically during initialization
• Package system - pack/*/start/* directories auto-load; pack/*/opt/* load via :packadd command
• After-plugins - after/plugin/ files execute after all regular plugins

The source_runtime() function in scriptfile.c implements the core search logic, using do_in_path() callbacks to locate and source matching files.

Autoload System

Autoload provides lazy-loading for functions and utilities. Functions with a # separator (e.g., mylib#func()) trigger automatic loading from autoload/mylib.vim:

" Calling this function automatically loads autoload/mylib.vim
call mylib#helper()

Autoload files are only sourced when their functions are first invoked, reducing startup time. The autoload/dist/ directory contains standard library functions for common tasks like filetype detection and completion.

Filetype Detection & Plugins

Filetype detection happens in two stages:

1. Detection - filetype.vim determines the filetype via extension, filename pattern, or file content inspection
2. Plugin loading - ftplugin.vim loads filetype-specific plugins via LoadFTPlugin() function

When a buffer's filetype is set, the FileType autocmd triggers, which loads:

runtime! ftplugin/{filetype}.vim ftplugin/{filetype}_*.vim ftplugin/{filetype}/*.vim

Filetype plugins can define b:undo_ftplugin to specify cleanup commands when switching filetypes.

Syntax Highlighting

Syntax files are loaded similarly to ftplugins but through the syntax/ directory. The system searches for syntax/{filetype}.vim when syntax highlighting is enabled. Syntax definitions use pattern matching and highlighting groups to colorize code.

Configuration Hierarchy

The runtime system respects this configuration order:

1. Defaults - defaults.vim provides sensible defaults (skipped with -u NONE)
2. User vimrc - ~/.vimrc or $XDG_CONFIG_HOME/vim/vimrc
3. Plugins - All plugins from runtimepath
4. After-plugins - Final customizations in after/plugin/

Users can override any setting at any level. The skip_defaults_vim variable prevents defaults from loading if set in a system-wide vimrc.

Runtimepath Management

The runtimepath option determines where Vim searches for runtime files. Default locations include:

• $VIMRUNTIME - Built-in runtime directory
• ~/.vim - User configuration directory
• $VIM - System-wide configuration
• after/ subdirectories - For post-processing

Plugins can modify runtimepath to add custom directories. The :packloadall command pre-loads all packages and modifies the search order.