Defaults and providers

Purpose

Two things every Neovim user touches but that aren't strictly features in their own right: the defaults — keymaps, options, autocmds the editor sets out of the box — and the providers — bridges to the host languages (Python, Ruby, Node, Perl) that are used to run plugins not yet ported to Lua.

Defaults

Where they live

runtime/lua/vim/_core/defaults.lua (~39k bytes)   The current defaults
runtime/plugin/                                     Built-in plugins (always loaded)
runtime/pack/dist/opt/                              Opt-in plugins (`:packadd`)

runtime/lua/vim/_core/defaults.lua is run at startup. It installs:

• The default keymaps that aren't part of Vim's set: <C-l> to redraw + clear search, Y to yank-to-EOL (matching D and C), [d / ]d for diagnostics, [c / ]c for the change list, etc. Most are documented in :help vim.lsp.start and :help defaults.
• A BufRead autocmd that picks up the .editorconfig file via runtime/plugin/editorconfig.vim.
• Filetype detection (runtime/lua/vim/filetype.lua, ~96 KB — the biggest single Lua file in the tree).
• Sensible mouse defaults (mousemodel = "popup_setpos" etc.).
• Default highlight groups for diagnostics, treesitter captures, LSP, etc.

These defaults can be overridden by user init.lua. They're applied early enough that user config sees them and can adjust.

Why defaults exist

Historically Vim shipped with conservative defaults inherited from vi. Neovim has progressively added defaults that are useful to most users (truecolor, persistent undo on, smarter search), in part because the project's value proposition is "good out of the box". The full list is documented at runtime/doc/news.txt (per-version) and runtime/doc/vim_diff.txt (vs Vim).

Filetype detection

runtime/lua/vim/filetype.lua is two large pattern tables: one keyed by exact filename (e.g., Dockerfile), one by extension (.lua, .go). When a buffer is read, runtime/plugin/filetype.lua runs the pattern lookup and sets filetype. Customization is via vim.filetype.add({...}). The whole thing is data-driven; new entries are appended to the tables.

Providers

What they are

A provider is an out-of-process bridge that lets Neovim run a plugin not implemented in Lua. There are four:

• Python 3 — pynvim. Host process: python3.
• Ruby — neovim gem. Host: ruby.
• Node — neovim npm. Host: node.
• Perl — Neovim::Ext. Host: perl.

Each is started lazily (only when a plugin asks for it) by spawning the host process with the plugin manifest and an msgpack-rpc channel.

Where they live

runtime/lua/vim/provider/
├── perl.lua
├── python.lua
├── ruby.lua
└── ...
runtime/lua/vim/provider.lua    Entry point
runtime/autoload/provider/      Vimscript glue

Each provider Lua module:

• Detects the host (python3 --version, ruby --version, etc.).
• Caches the executable path.
• Spawns the host with the channel arguments via vim.system.
• Translates the host's RPC into the editor's plugin API.

Why providers exist

The Vim ecosystem includes long-running plugins that would be expensive to rewrite. Providers let those plugins keep working under Neovim while new ones are written in Lua.

Health checks

:checkhealth reports each provider's status. The check lives at runtime/lua/vim/provider/<lang>/health.lua:

• Is the host installed?
• Is the client library (pynvim, neovim gem, ...) installed?
• Is it the correct version?

If a provider isn't needed, you can disable it with let g:loaded_python3_provider = 0 (etc.) in init.lua. The startup cost of probing for python3 is the main reason to do this.

Default plugins (in runtime/plugin/ and runtime/pack/)

Some plugins ship inside the binary's runtime directory and are loaded at startup or on-demand:

• man.lua — :Man command and man:// URI scheme. Loaded on demand.
• editorconfig.lua — apply .editorconfig settings.
• tutor — :Tutor command. The interactive tutorial.
• spellfile.lua — auto-download spell files.
• tohtml — :TOhtml to render the buffer as HTML.
• comment (vim._comment) — gc operator.
• difftool, undotree — diff and undo visualizers.
• nvim.tutor, nvim.spellfile — namespaced versions of the above (the new convention from runtime/doc/dev_arch.txt).

Per dev_arch.txt, "New plugins should place Lua modules in the shared 'nvim' namespace: require('nvim.foo'), not require('foo')." The legacy ones predate this rule.

Integration points

• vim.api.nvim_set_keymap is what defaults.lua uses to install user-overridable maps.
• vim.filetype.add lets users add detection rules; the defaults file uses the same API.
• vim.g.loaded_<provider>_provider = 0 disables a provider.
• vim.fn['<provider>#Call'](...) invokes a provider function from Vimscript; bridges to the host.

Entry points for modification

• Change a default keymap. Edit runtime/lua/vim/_core/defaults.lua. Each map has a comment explaining what it does and why.
• Add a default highlight group. Edit the set_default_highlights section.
• Add a filetype detection rule. Edit runtime/lua/vim/filetype.lua. The tables are alphabetized.
• Add a new provider. Mirror the structure of runtime/lua/vim/provider/python.lua. Almost no users add providers — most additions go in vim.system plus a Lua plugin.

Key source files

File	Purpose
runtime/lua/vim/_core/defaults.lua	Default keymaps, highlights, autocmds
runtime/lua/vim/filetype.lua	Filetype detection (the biggest pure-Lua file in the tree)
runtime/lua/vim/provider/python.lua	Python provider
runtime/lua/vim/provider/ruby.lua	Ruby provider
runtime/lua/vim/provider/perl.lua	Perl provider
runtime/lua/vim/provider.lua	Provider entry point
runtime/plugin/man.lua	:Man plugin
runtime/plugin/editorconfig.lua	EditorConfig plugin
runtime/doc/news.txt	Per-release news, including default changes
runtime/doc/vim_diff.txt	List of differences from Vim