On 2020-12-11 at 01:08:00, Felipe Contreras wrote: > On Wed, Dec 9, 2020 at 9:51 PM brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
