EditorConfig for Vim: The Built-in Option and What the Plugin Still Adds

What Problem This Plugin Solves

EditorConfig is a file format that standardizes indentation, line endings, and other editor settings across a project. The editorconfig-vim plugin reads .editorconfig files when you open a buffer in Vim or Neovim and applies the matching properties. The problem it solves is the drift between what your global vimrc sets and what a project expects. Without it, each contributor's editor may format code differently, producing noisy diffs. The plugin targets Vim users who want project-specific formatting rules to override their personal settings automatically. It also matters for teams that already use .editorconfig in other editors, because this plugin brings the same behavior into Vim. The README positions it as the official plugin for Vim, with a GitHub repository and a Vim online page. The plugin is not a full editor configuration system. It only handles the properties listed in the README, which are the standard EditorConfig properties plus spelling_language and max_line_length. That is a concrete scope, and it matters when you compare it to editor-agnostic tools that do more.

How It Applies Rules: The Mechanism

When you open a file, the plugin looks for .editorconfig files in the directory tree, starting from the file's location and moving upward until it finds a root marker. The README says the plugin includes the EditorConfig core, so no external Python core is needed. That core parses the .editorconfig syntax and resolves which properties apply to the current file. The plugin then maps those properties to Vim settings. For example, indent_style sets expandtab or noexpandtab, indent_size sets shiftwidth, and tab_width sets tabstop. The mapping is not one-to-one for every property. insert_final_newline requires Vim's +fixendofline feature, available on Vim 7.4.785 and later, or a PreserveNoEOL script. That means the plugin cannot guarantee this property works on older Vim builds. The plugin also exposes a disable mechanism. You can set b:EditorConfig_disable in a buffer, or use an autocommand to disable it for a filetype, as shown with gitcommit. This is a per-buffer escape hatch, not a global toggle. The README also documents g:EditorConfig_disable_rules, which lets you turn off specific properties, such as trim_trailing_whitespace, in your vimrc. That is a rare but useful override for conflicts with autosave plugins.

Installation Paths and First Run

The README lists four installation methods. The simplest is to download the archive and extract it into ~/.vim on Unix or $VIM_INSTALLATION_FOLDER\vimfiles on Windows. That should create four directories: autoload, doc, ftdetect, and plugin. Alternatively, you can use a Vim 8 package by running mkdir -p ~/.vim/pack/local/start, then cd there, then git clone https://github.com/editorconfig/editorconfig-vim.git. The README notes that the directory name local can be anything, but a path element must exist. For pathogen, Vundle, or vim-plug, you add the repository to your plugin manager. With vim-plug, you add Plug 'editorconfig/editorconfig-vim' to your .vimrc, source it with :source $MYVIMRC, then run :PlugInstall. After installation, you may need to run :helptags ALL to make the :help editorconfig page available. The plugin does not require any external core library, which simplifies setup compared to earlier versions. There is one version-specific note: after version 1.2.1, the plugin will not automatically set the .editorconfig filetype to dosini. If you want that behavior, you must install version 1.2.1 specifically. That is a concrete trade-off between staying current and keeping a convenience feature.

The Bundled Alternative: When You Might Not Need This Plugin

The README explicitly states that Vim 9.0.1799 and above comes bundled with a recent stable version of this plugin. Neovim 0.9 and above has its own Lua-based implementation. That changes the adoption decision. If you run a recent Vim or Neovim, installing this plugin is redundant for basic functionality. The bundled versions may not be identical to the standalone plugin, but the README frames them as equivalent for typical use. The plugin's value then shifts to older editors. For Vim 9.0.1799 or earlier, or Neovim below 0.9, the plugin is the way to get EditorConfig support. The README does not specify which exact version of the plugin is bundled, only that it is a recent stable version. That means behavior may lag behind the latest release. If you need a fix that shipped after your editor's bundle, you might still install the plugin to override it. The plugin's own version history shows a v1.2.1 release in January 2025, so the standalone version is actively maintained. But the bundled code reduces the audience for that maintenance.

Exclusion Patterns and the fugitive Conflict

The README highlights a specific interoperability issue with Tim Pope's fugitive plugin. Fugitive buffers have a name like fugitive://..., and the plugin would try to apply .editorconfig rules to those buffers, which is usually not desired. The solution is to set g:EditorConfig_exclude_patterns to a list of patterns, such as ['fugitive://.*']. The same option works for remote files over scp: ['scp://.*']. You can combine both patterns. This is a real limitation: the plugin does not automatically skip non-local or special buffers. You must configure it yourself. The README does not mention other special buffers, such as netrw or quickfix, so you may need to add your own patterns. The exclude option is a list of regex patterns, which gives you flexibility but also requires you to know the buffer naming scheme. This is a small but concrete cost. Without it, the plugin can interfere with git workflows, which is ironic for a formatting tool. The README frames this as ensuring the plugin works well with fugitive, not as a bug. That is a fair characterization, but it is a manual step that new users might miss.

Limitations and Failure Modes

The plugin only supports the properties listed in the README. It does not cover every property in the EditorConfig specification, such as file_type_emulation or those added later. If a project relies on an unsupported property, the plugin silently ignores it, and you may not notice. The insert_final_newline property depends on Vim's +fixendofline feature, which is not available on all builds. On a minimal Vim without that feature, the property will not work unless you install PreserveNoEOL. The README does not say what happens when the feature is missing, only that it is required. That is a silent failure mode. Another limitation is the version-specific dosini filetype behavior. After 1.2.1, .editorconfig files will not be recognized as dosini filetype automatically. That may affect syntax highlighting or filetype plugins. The README suggests installing version 1.2.1 if you want to retain that behavior, but then you lose later fixes. The disable_rules option is a workaround for conflicts, but the README warns it is not recommended. It is a blunt instrument: disabling trim_trailing_whitespace globally affects all buffers, not just the conflicting one. The plugin also does not handle encoding conversion beyond what Vim's charset mapping supports, which is a broader Vim limitation.

Maintenance, Licensing, and Upgrade Cost

The repository's last push was January 27, 2025, with release v1.2.1 on the same day. That indicates active maintenance, though the release cadence is not frequent. The v1.2.0 release came in November 2023, so there is roughly a year between feature releases. The license is listed as NOASSERTION in the repository metadata, which is unusual. The README does not mention a license explicitly. That is a concern for organizations that require clear licensing. The plugin is hosted on GitHub, so you can inspect the source, but the license status is ambiguous. The README links to contribution guidelines in the editorconfig core repository, suggesting the project follows the EditorConfig project's practices. The upgrade cost is low if you use a plugin manager. With vim-plug, you run :PlugUpdate. There is no migration guide in the README, but the plugin's options have remained stable across versions. The main upgrade concern is the dosini filetype change after 1.2.1. If you upgrade from an older version, you may lose that behavior. The README does not provide a migration path other than pinning to 1.2.1. For a formatting plugin, the maintenance burden is mostly about keeping up with Vim's own bundled version. If your Vim bundles the plugin, the editor's update cycle handles it. Otherwise, you are responsible for updating this plugin separately.

Who Should Use It and What to Verify First

The plugin is the right choice for users on Vim versions before 9.0.1799 or Neovim before 0.9. It is also useful if you need the dosini filetype behavior and prefer to stay on version 1.2.1. If you are on a recent editor, the built-in implementation is likely sufficient, and installing the plugin adds no value. Before installing, check your Vim version with :version or your Neovim version with :version or :nvim --version. If you use fugitive or scp, plan to set g:EditorConfig_exclude_patterns immediately. Verify that your Vim build has +fixendofline if you rely on insert_final_newline. Also check the license situation if that matters to your project. The plugin's documentation is thin on troubleshooting, so you should test a simple .editorconfig file in a scratch directory to confirm rules apply. The concrete next step is to run :helptags ALL after installation and read :help editorconfig for the full option list. The plugin is a small, focused tool that solves a real problem, but its relevance depends heavily on your editor version.

Editorial conclusion

Adopt editorconfig-vim if you run Vim older than 9.0.1799 or Neovim below 0.9, or if you need the dosini filetype behavior for .editorconfig files, which the plugin sets only through version 1.2.1. Skip it if your editor already bundles the plugin or a Lua equivalent, and verify your Vim version before installing. Check the g:EditorConfig_exclude_patterns option first if you use fugitive or scp, because those remote buffers need explicit exclusion to avoid unexpected rule application.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes