Romain Lafourcade

Plugins are usually configured with *passive* globally-scoped variables, which allows users to perform all their setup in their `vimrc`. Requiring the plugin to be loaded for configuring it seems like...

I'm not sure why exactly you would want to put that code in `ftplugin/markdown.vim` instead of `after/ftplugin/markdown.vim`. `$VIMRUNTIME/ftplugin/markdown.vim` has this line: runtime! ftplugin/html.vim ftplugin/html_*.vim ftplugin/html/*.vim which sources all the available...

There is already a mechanism in place for all of that: - plugin A exposes `g:plugin_a_enable_omnifunc`, - plugin B exposes `g:plugin_b_use_omnifunc`, - they are falsy by default, - user decides...

Even better: keep the whole discussion in one place.

The core issue with your idea is that both text objects and custom operator-pending mode mappings are currently implemented via visual mode. There is no built-in way around that. The...

We debated doing just that for `javascript` but there are too many options available and too many ways to use or not use them. Coming up with a working piece...

I can't speak for *all* "Javascript programmers" but it is generally considered best practice to use the tools and settings agreed upon at the project level rather than one's preferred...

It looks like most of the "formatters" in vim-codefmt either work on a range or a or buffer due the inherent limitations of the corresponding external tools. Also, the "syntax"...

> Okay, these are web dev files? Just asking how common that is outside Javascript constructs. But even if it's only Javascript, that accounts in practice for 80% or so...

Yeah I'm not sure where that idea of switching formatters within a same buffer comes from. The usual scenario is: 1. Project is started. 2. Choices are made regarding compiler,...