Re: [PATCH v2 1/2] Add project-wide .vimrc configuration

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 7237 bytes --]

On 2020-12-11 at 01:08:00, Felipe Contreras wrote:
> On Wed, Dec 9, 2020 at 9:51 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > On 2020-12-09 at 06:55:36, Felipe Contreras wrote:
> 
> > I don't think this should go in this location.  It should go in contrib.
> > Here's why:
> >
> > * We should not ship editor-specific files in the main directory of the
> >   repository.
> 
> Why not?

Best practices indicate that we don't check in files which are specific
to a developer.  Anything that controls the specific editor people use
is by definition specific to the developer.  Checking in these files
leads to conflicts over which settings to apply and whose settings are
better when they could just be avoided.

If we have style policies, those should be expressed in a general,
universal way so that all users can take advantage of them in the same
way.

Furthermore, some editors want entire large directories of configuration
files in order to work correctly, which we don't want to include.

If we treat all editors in the same way, then every developer gets the
same experience when they work on our code.  If that experience is
inadequate, our time would be better spent improving it in a universal
way so that all developers can benefit.

> >   Even though Vim is very popular, it is one of many
> >   editors, and it is not even the most popular editor (which is now VS
> >   Code).
> 
> Even if vim is not the most popular, it certainly is among the top 3
> (and I doubt VS Code is the most popular, I would like to see some
> numbers on that, but even then; VS Code is not an editor).
> 
> Nobody is arguing to have editor-specific files for "every editor
> under the sun", just perhaps 2 (or maybe even 3).
> 
> No slippery slope fallacy here.

Because we don't need them.  Your solution requires the user to
configure Vim with a plugin _and then_ allow the specific directory in
order to be secure, which means it doesn't work with worktrees.  It also
requires that the user never pull an untrusted branch into their
repository.  It also has other undesirable effects which I mentioned in
my original email.

The .editorconfig file also requires a user to configure a plugin, once,
and then things automatically work in a secure way across projects.  In
other words, the existing solution requires a user to affirmatively act,
but with less effort, less potential for security problems, and better
cross-project support.

So the .vimrc solution requires more effort, has more potential security
problems, is less flexible, is less like how other projects solve this
problem, and is less general.

> >   We have editor-independent files, and users can copy this into
> >   the root of the repository and ignore it if they want it there.
> 
> Which are insufficient. They are certainly better than nothing. Plus,
> it's unclear how many people are actually using those.

Why are they insufficient?  Multiple developers are using them on Git
already.  They're used on projects from Microsoft[0], W3C[1], and folks
working on JSONPath[2].  They are the de facto standard for this
purpose.

In contrast, searching GitHub commits for ".vimrc" shows overwhelmingly
that the repositories in which these commits are named are called
"dotfiles".  I was unable to find any projects from major organizations
using this configuration style.

My general rule is that when I'm unsure what decision to make on a
project, I should make the decision that everybody else has made,
because users and developers will expect my project to work just like
everyone else's.

> And I'm still waiting for the argument against adding such a top-level file.
> 
> What is the harm?

As mentioned, enabling the use of this file is still risky from a
security perspective because it precludes even pulling in an untrusted
branch and then spawning an editor.  We already have a more general
solution that is more widely adopted and has fewer downsides, so there's
no point in adding files which really provide little benefit over what
we already have.

If there's little benefit, we shouldn't carry files which are going to
be subject mostly to pointless arguments over personal preference.  The
fact that two heavy Vim users disagree so strongly over relatively
simple settings is an argument for not adopting this approach as a set
of project settings.

> > * Whether a user wants to use automatic indentation is a personal
> >   preference.  I do happen to like it, but there are others who don't
> >   and prefer to leave it off.  Similarly, whether to use cindent,
> >   smartindent, or autoindent is a preference, as is which cindent
> >   options to use (I use different ones).
> 
> So?
> 
> These options will not be forced on users, they have to specifically
> enable them by doing at least two steps, *and* they can still
> selectively override them in their ~/.vim files.

Right, but why are your preferred settings checked into Git as a project
setting?  They are objectively no better than my settings, which differ.
Absent a compelling reason that these settings are objectively better,
we should not endorse them as preferred project settings.

> > * These settings affect every file that's loaded in the same editor
> >   process.
> 
> That is not true.
> 
> :setlocal [1] applies the setting to the current buffer only, not
> globally, and *only* when the buffer is of the filetype specified in
> the autocommand.

So if I spawn an editor process using this .vimrc in my Git directory
and then I load an AsciiDoc file from a different repository into that
same Vim process, are you arguing that the Git settings will not be
applied to the AsciiDoc file from other directory?  I'm pretty sure that
Vim will in fact use the Git settings.  It's possible, however, that
I've misunderstood how Vim works.

.editorconfig doesn't have these downsides.

> > So while I agree that these are common settings, they are not
> > universally applicable, even for Vim and Neovim users, and we shouldn't
> > try to claim that all or even most Vim and Neovim users should use them.
> 
> We don't. These are defaults, which a) the user must consciously
> choose to apply them, and b) can be easily overridden (as is explained
> in the commit message).

I'm arguing that they are not universal enough to be defaults.
Moreover, a set of defaults for how a user _could_ configure their
editor would belong in contrib, much like defaults for how a user
_could_ configure their MUA to send properly to the mailing list.

We already have files for Emacs and VS Code, and those live properly in
contrib, along with code for Thunderbird and alternative build systems.
If we're treating this proposal like existing code, it belongs in
contrib.

The .editorconfig file, on the other hand, doesn't express defaults.  It
expresses only project standards and doesn't specify any other settings.

[0] https://github.com/microsoft/fabrikate
[1] https://github.com/w3c/specberus
[2] https://github.com/jsonpath-standard/internet-draft
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]