diff mbox series

Add project-wide .vimrc configuration

Message ID 20201209002619.25468-1-felipe.contreras@gmail.com (mailing list archive)
State New, archived
Headers show
Series Add project-wide .vimrc configuration | expand

Commit Message

Felipe Contreras Dec. 9, 2020, 12:26 a.m. UTC
It's not efficient that everyone must set specific configurations in all
their ~/.vimrc files; we can have a project-wide .vimrc that everyone
can use.

By default it's ignored, you need the following in your ~/.vimrc

  set exrc
  set secure

Then the project-wide configuration is loaded, which sets the correct
filetype for the documentation and tests, and also the default
indentation of c, sh, and asciidoc files.

If you have the shareness syntax file it will be used for the tests, but
if not the sh syntax will still be used.

These default configurations can be overriden in the typical way (by
adding the corresponding file in ~/.vim/after/ftplugin).

We could add the vim modelines at the bottom of every file, like other
projects do, but this seems more sensible.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 .vimrc | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 .vimrc

Comments

Junio C Hamano Dec. 9, 2020, 1:08 a.m. UTC | #1
Felipe Contreras <felipe.contreras@gmail.com> writes:

> It's not efficient that everyone must set specific configurations in all
> their ~/.vimrc files; we can have a project-wide .vimrc that everyone
> can use.

Does .vimrc gets used from the current directory?  If so, just like
clang-format, it makes sense to place it with dot-prefix at the root
of the project, like this patch does.  But ...

>
> By default it's ignored, you need the following in your ~/.vimrc
>
>   set exrc
>   set secure

... it does not sound like it is the case.

And I am sensing that this ".vimrc that happens in the current
directory is not used by default" is not such a well known fact
among vim users (otherwise you wouldn't be writing it here), and if
that is the case, I am afraid that this invites an unneeded end-user
confusion when they see dot-commandname-rc file and see its contents
not honored at all.

Whether it is well known by intended audience that it is by default
unused, we should give the instruction we see above (and below, up
to the description of how to override) in a comment at the beginning
of the file, I think.  Then, once the user follows the insn, the new
file added by this patch would start working without any further user
action, which is very nice.

> Then the project-wide configuration is loaded, which sets the correct
> filetype for the documentation and tests, and also the default
> indentation of c, sh, and asciidoc files.
>
> If you have the shareness syntax file it will be used for the tests, but
> if not the sh syntax will still be used.
>
> These default configurations can be overriden in the typical way (by
> adding the corresponding file in ~/.vim/after/ftplugin).
>
> We could add the vim modelines at the bottom of every file, like other
> projects do, but this seems more sensible.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  .vimrc | 9 +++++++++
>  1 file changed, 9 insertions(+)
>  create mode 100644 .vimrc
>
> diff --git a/.vimrc b/.vimrc
> new file mode 100644
> index 0000000000..d250ab26e0
> --- /dev/null
> +++ b/.vimrc
> @@ -0,0 +1,9 @@
> +augroup git
> +  au!
> +  au BufRead,BufNewFile */t/*.sh set ft=sharness.sh
> +  au BufRead,BufNewFile */Documentation/*.txt set ft=asciidoc
> +
> +  au FileType c setl noet ts=8 sw=0 cino=(s,:0,l1,t0
> +  au FileType sh setl noet ts=8 sw=0
> +  au FileType asciidoc setl noet ts=8 sw=0 autoindent
> +augroup END
Aaron Schrab Dec. 9, 2020, 1:18 a.m. UTC | #2
At 18:26 -0600 08 Dec 2020, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>By default it's ignored, you need the following in your ~/.vimrc
>
>  set exrc

Running `:help 'exrc'` in vim includes the text:

         Setting this option is a potential security leak.  E.g., consider
         unpacking a package or fetching files from github, a .vimrc in there
         might be a trojan horse.  BETTER NOT SET THIS OPTION!
         Instead, define an autocommand in your .vimrc to set options for a
         matching directory.

So I don't think it's a good idea to encourage people to do that by 
using a name that invites it. Also I think that the file would be more 
discoverable for people to incorporate into their own configuration if 
not named as a hidden file.
Denton Liu Dec. 9, 2020, 1:32 a.m. UTC | #3
Hi Felipe,

On Tue, Dec 08, 2020 at 06:26:19PM -0600, Felipe Contreras wrote:
> It's not efficient that everyone must set specific configurations in all
> their ~/.vimrc files; we can have a project-wide .vimrc that everyone
> can use.
> 
> By default it's ignored, you need the following in your ~/.vimrc
> 
>   set exrc
>   set secure
> 
> Then the project-wide configuration is loaded, which sets the correct
> filetype for the documentation and tests, and also the default
> indentation of c, sh, and asciidoc files.
> 
> If you have the shareness syntax file it will be used for the tests, but

s/shareness/sharness/

> if not the sh syntax will still be used.
> 
> These default configurations can be overriden in the typical way (by
> adding the corresponding file in ~/.vim/after/ftplugin).
> 
> We could add the vim modelines at the bottom of every file, like other
> projects do, but this seems more sensible.
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  .vimrc | 9 +++++++++
>  1 file changed, 9 insertions(+)
>  create mode 100644 .vimrc
> 
> diff --git a/.vimrc b/.vimrc
> new file mode 100644
> index 0000000000..d250ab26e0
> --- /dev/null
> +++ b/.vimrc
> @@ -0,0 +1,9 @@
> +augroup git
> +  au!
> +  au BufRead,BufNewFile */t/*.sh set ft=sharness.sh
> +  au BufRead,BufNewFile */Documentation/*.txt set ft=asciidoc
> +
> +  au FileType c setl noet ts=8 sw=0 cino=(s,:0,l1,t0
> +  au FileType sh setl noet ts=8 sw=0
> +  au FileType asciidoc setl noet ts=8 sw=0 autoindent
> +augroup END

A couple of nits. We should tab-indent this file since the rest of the
project uses tabs everywhere. Also, perhaps use the full name for the
option names so that it's immediately obvious what each setting does?

Aside from that, the settings themselves are sensible and I'm for this
patch.

-Denton

> -- 
> 2.29.2
>
brian m. carlson Dec. 9, 2020, 2:23 a.m. UTC | #4
On 2020-12-09 at 00:26:19, Felipe Contreras wrote:
> It's not efficient that everyone must set specific configurations in all
> their ~/.vimrc files; we can have a project-wide .vimrc that everyone
> can use.
> 
> By default it's ignored, you need the following in your ~/.vimrc
> 
>   set exrc
>   set secure

I would strongly recommend against advising users to use this
configuration.  Vim has been known to have repeated security problems
with what options are allowed in restricted environments, and even with
the secure option, it's still easy to do something like this:

  func Foo()
    !echo >/tmp/foo
  endfunction

  nmap i :call Foo()<CR>

When the user hits "i" to enter insert mode, they'll execute the
attacker's arbitrary code.

> We could add the vim modelines at the bottom of every file, like other
> projects do, but this seems more sensible.

We have an .editorconfig file[0], which is a cross-editor file that can be
used to specify these settings.  It is supported by many editors out of
the box, although Vim requires a plugin.  Since we don't want to support
configuration for every editor under the sun, it makes sense to use a
single file for multiple editors and let people configure their editor
accordingly.

Since Vim would require configuration either way and .editorconfig files
don't have any known security issues, the .editorconfig file seems like
a better option.

[0] https://editorconfig.org/
Felipe Contreras Dec. 9, 2020, 2:32 a.m. UTC | #5
On Tue, Dec 8, 2020 at 7:08 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > It's not efficient that everyone must set specific configurations in all
> > their ~/.vimrc files; we can have a project-wide .vimrc that everyone
> > can use.
>
> Does .vimrc gets used from the current directory?  If so, just like
> clang-format, it makes sense to place it with dot-prefix at the root
> of the project, like this patch does.  But ...

Actually no. I tested this with "vim Documentation/git-pull.txt", and
that works fine, but apparently only from that directory.

I'm investigating other solutions.

> > By default it's ignored, you need the following in your ~/.vimrc
> >
> >   set exrc
> >   set secure
>
> ... it does not sound like it is the case.
>
> And I am sensing that this ".vimrc that happens in the current
> directory is not used by default" is not such a well known fact
> among vim users (otherwise you wouldn't be writing it here), and if
> that is the case, I am afraid that this invites an unneeded end-user
> confusion when they see dot-commandname-rc file and see its contents
> not honored at all.

I'd say at least 90% of what vim does is not well known for most vim uses.

> Whether it is well known by intended audience that it is by default
> unused, we should give the instruction we see above (and below, up
> to the description of how to override) in a comment at the beginning
> of the file, I think.  Then, once the user follows the insn, the new
> file added by this patch would start working without any further user
> action, which is very nice.

Right. That makes sense. I'll add the instructions to the next version
once I find a good alternative for exrc.

Cheers.
Junio C Hamano Dec. 9, 2020, 3:15 a.m. UTC | #6
Aaron Schrab <aaron@schrab.com> writes:

> At 18:26 -0600 08 Dec 2020, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>>By default it's ignored, you need the following in your ~/.vimrc
>>
>>  set exrc
>
> Running `:help 'exrc'` in vim includes the text:
>
>         Setting this option is a potential security leak.  E.g., consider
>         unpacking a package or fetching files from github, a .vimrc in there
>         might be a trojan horse.  BETTER NOT SET THIS OPTION!
>         Instead, define an autocommand in your .vimrc to set options for a
>         matching directory.
>
> So I don't think it's a good idea to encourage people to do that by
> using a name that invites it. Also I think that the file would be more 
> discoverable for people to incorporate into their own configuration if
> not named as a hidden file.

Thanks.  I do not use vim and did not know how commonly recommended
the "set exrc" would be, but what you said makes total sense.  In
that case, I'd suggest shipping this file without the dot-prefix
with a clear instruction how to make use of its contents in a secure
manner in a comment at the top of the file.

If having vimrc (no dot) at the top-level of the tree is untidy, we
can add a place in contrib/ that houses configurations to help
various editors and IDEs (e.g. contrib/editors/), too.
Felipe Contreras Dec. 9, 2020, 6:20 a.m. UTC | #7
On Tue, Dec 8, 2020 at 7:32 PM Denton Liu <liu.denton@gmail.com> wrote:
> On Tue, Dec 08, 2020 at 06:26:19PM -0600, Felipe Contreras wrote:

> > diff --git a/.vimrc b/.vimrc
> > new file mode 100644
> > index 0000000000..d250ab26e0
> > --- /dev/null
> > +++ b/.vimrc
> > @@ -0,0 +1,9 @@
> > +augroup git
> > +  au!
> > +  au BufRead,BufNewFile */t/*.sh set ft=sharness.sh
> > +  au BufRead,BufNewFile */Documentation/*.txt set ft=asciidoc
> > +
> > +  au FileType c setl noet ts=8 sw=0 cino=(s,:0,l1,t0
> > +  au FileType sh setl noet ts=8 sw=0
> > +  au FileType asciidoc setl noet ts=8 sw=0 autoindent
> > +augroup END
>
> A couple of nits. We should tab-indent this file since the rest of the
> project uses tabs everywhere. Also, perhaps use the full name for the
> option names so that it's immediately obvious what each setting does?

All right, makes sense to me.
Felipe Contreras Dec. 9, 2020, 6:28 a.m. UTC | #8
On Tue, Dec 8, 2020 at 7:18 PM Aaron Schrab <aaron@schrab.com> wrote:
>
> At 18:26 -0600 08 Dec 2020, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >By default it's ignored, you need the following in your ~/.vimrc
> >
> >  set exrc
>
> Running `:help 'exrc'` in vim includes the text:
>
>          Setting this option is a potential security leak.  E.g., consider
>          unpacking a package or fetching files from github, a .vimrc in there
>          might be a trojan horse.  BETTER NOT SET THIS OPTION!
>          Instead, define an autocommand in your .vimrc to set options for a
>          matching directory.

Yeah, but if they *really* didn't want people to set this option they
would remove it.

Yes, it's dangerous, but that's why it's an option.

Anyway, I wrote a simple loader that should take care of this security
risk, in the same way other local vimrc loaders do.

> So I don't think it's a good idea to encourage people to do that by
> using a name that invites it. Also I think that the file would be more
> discoverable for people to incorporate into their own configuration if
> not named as a hidden file.

Perhaps. There's already an .editorconfig so we would be following
similar steps, and also this is what other vimrc loaders already use.

Since I'm adding a contrib/vim directory maye a README file would make sense.

Check v2 and let me know what you think.
Felipe Contreras Dec. 9, 2020, 6:36 a.m. UTC | #9
On Tue, Dec 8, 2020 at 8:24 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2020-12-09 at 00:26:19, Felipe Contreras wrote:
> > It's not efficient that everyone must set specific configurations in all
> > their ~/.vimrc files; we can have a project-wide .vimrc that everyone
> > can use.
> >
> > By default it's ignored, you need the following in your ~/.vimrc
> >
> >   set exrc
> >   set secure
>
> I would strongly recommend against advising users to use this
> configuration.  Vim has been known to have repeated security problems
> with what options are allowed in restricted environments, and even with
> the secure option, it's still easy to do something like this:
>
>   func Foo()
>     !echo >/tmp/foo
>   endfunction
>
>   nmap i :call Foo()<CR>
>
> When the user hits "i" to enter insert mode, they'll execute the
> attacker's arbitrary code.

v2 should probably deal with that.

> > We could add the vim modelines at the bottom of every file, like other
> > projects do, but this seems more sensible.
>
> We have an .editorconfig file[0], which is a cross-editor file that can be
> used to specify these settings.  It is supported by many editors out of
> the box, although Vim requires a plugin.  Since we don't want to support
> configuration for every editor under the sun, it makes sense to use a
> single file for multiple editors and let people configure their editor
> accordingly.

Sure. But it doesn't set cinoptions, nor does it set filetypes for
documentation and tests.

Plus, it's a single file, it's not like we are adding modesets at the
bottom of every single file like other projects do.

Also, we don't have to support configurations for every editor under
the sun, that's a slippery slope fallacy.

We can stop at 1 editor: the most widely used editor by developers by far [1].

Cheers.

[1] https://pkgstats.archlinux.de/packages#query=vim
Junio C Hamano Dec. 9, 2020, 6:54 a.m. UTC | #10
Felipe Contreras <felipe.contreras@gmail.com> writes:

>> We have an .editorconfig file[0], which is a cross-editor file that can be
>> used to specify these settings.  It is supported by many editors out of
> ...
> Also, we don't have to support configurations for every editor under
> the sun, that's a slippery slope fallacy.
>
> We can stop at 1 editor: the most widely used editor by developers by far [1].
>
> Cheers.
>
> [1] https://pkgstats.archlinux.de/packages#query=vim

It shows 71% (for vim-runtime), that is a lot higher than ~20% for
emacs.

Amusingly, https://pkgstats.archlinux.de/packages#query=nano tells
us that nano clicks at 80%, which makes it the editor with the
largest number with your yardstick ;-) [*2*].

In any case, I think it is a worthy goal to ship a sample set of
"vimrc" entries that people can readily accept for their use.  It
also is a reasonable "feature request" to consider doing something
similar to "editorconfig" to give other editors similar convenience.


[Footnote]

*2* In other words, I doubt these graphs are depicting "how widely
is an editor used by developers".  It is just showing how often it
is installed, and I know the primary workstation I use daily has vim
and nano installed without me choosing to have them, as opposed to
emacs I had to manually install, and I only use vim once every month
and nano once every quarter.

Note that I do not doubt vim is popular.  It is popular and it makes
sense to include it in the set of "first class" editors that deserve
priority treatment when we allocate engineering effort to support.

I just do not think these graphs are the best supporting material
for the claim you made "the most widely used editor by developers".
Felipe Contreras Dec. 9, 2020, 7:16 a.m. UTC | #11
On Wed, Dec 9, 2020 at 12:55 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> >> We have an .editorconfig file[0], which is a cross-editor file that can be
> >> used to specify these settings.  It is supported by many editors out of
> > ...
> > Also, we don't have to support configurations for every editor under
> > the sun, that's a slippery slope fallacy.
> >
> > We can stop at 1 editor: the most widely used editor by developers by far [1].
> >
> > Cheers.
> >
> > [1] https://pkgstats.archlinux.de/packages#query=vim
>
> It shows 71% (for vim-runtime), that is a lot higher than ~20% for
> emacs.
>
> Amusingly, https://pkgstats.archlinux.de/packages#query=nano tells
> us that nano clicks at 80%, which makes it the editor with the
> largest number with your yardstick ;-) [*2*].

Right. But I doubt there's many git developers using nano.

Anyway, that's not my yardstick, I just recall I've seen multiple
surveys of the editors that developers use, and vim always comes at
the top, by far. I just quickly searched for some evidence to sustain
my notion.

> In any case, I think it is a worthy goal to ship a sample set of
> "vimrc" entries that people can readily accept for their use.  It
> also is a reasonable "feature request" to consider doing something
> similar to "editorconfig" to give other editors similar convenience.

Indeed. Editors are kind of a touchy subject, but I don't think
anybody can deny that vim and emacs are the two most popular. My only
point is that we don't have to support "every editor under the sun".

Cheers.

> [Footnote]
>
> *2* In other words, I doubt these graphs are depicting "how widely
> is an editor used by developers".  It is just showing how often it
> is installed, and I know the primary workstation I use daily has vim
> and nano installed without me choosing to have them, as opposed to
> emacs I had to manually install, and I only use vim once every month
> and nano once every quarter.

Yes, but in Arch Linux at least no editor is installed by default.
Junio C Hamano Dec. 9, 2020, 8:13 a.m. UTC | #12
Felipe Contreras <felipe.contreras@gmail.com> writes:

>> *2* In other words, I doubt these graphs are depicting "how widely
>> is an editor used by developers".  It is just showing how often it
>> is installed, and I know the primary workstation I use daily has vim
>> and nano installed without me choosing to have them, as opposed to
>> emacs I had to manually install, and I only use vim once every month
>> and nano once every quarter.
>
> Yes, but in Arch Linux at least no editor is installed by default.

I thought everybody has nano not because it is adequate and usable
for them, but because it comes by default with distros, and distro
in turn choose nano not because it is particularly popular but is
small enough not to matter if left behind unused when the user
chooses a real editor.

But you are essentially usaying that 80% of Arch users install nano
by choice.  I find it doubly surprising.
Felipe Contreras Dec. 9, 2020, 8:52 a.m. UTC | #13
On Wed, Dec 9, 2020 at 2:13 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> >> *2* In other words, I doubt these graphs are depicting "how widely
> >> is an editor used by developers".  It is just showing how often it
> >> is installed, and I know the primary workstation I use daily has vim
> >> and nano installed without me choosing to have them, as opposed to
> >> emacs I had to manually install, and I only use vim once every month
> >> and nano once every quarter.
> >
> > Yes, but in Arch Linux at least no editor is installed by default.
>
> I thought everybody has nano not because it is adequate and usable
> for them, but because it comes by default with distros, and distro
> in turn choose nano not because it is particularly popular but is
> small enough not to matter if left behind unused when the user
> chooses a real editor.
>
> But you are essentially usaying that 80% of Arch users install nano
> by choice.  I find it doubly surprising.

I double checked. The installation instructions [1] do tell you to
pick an editor, and they don't suggest any.

I am half-surprised. The StackOverflow question "How do I exit the Vim
editor?" has 2.2 million views [2], there's countless memes about that
ordeal [3], and the SO team even found it wise to write a blog post
about it [4]. I don't know how to exit emacs (Ctrl-X Ctrl-e?), and I
suspect many emacs users don't know how to exit vim.

Nano doesn't have this problem. Which means for somebody entering the
world of Linux, that's a plus.

Cheers.

[1] https://wiki.archlinux.org/index.php/Installation_guide#Install_essential_packages
[2] https://stackoverflow.com/questions/11828270/how-do-i-exit-the-vim-editor
[3] https://twitter.com/iamdevloper/status/993821761648103425
[4] https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/


--
Felipe Contreras
Randall S. Becker Dec. 9, 2020, 4:18 p.m. UTC | #14
On December 9, 2020 3:13 AM, Junio C Hamano wrote:
> To: Felipe Contreras <felipe.contreras@gmail.com>
> Cc: brian m. carlson <sandals@crustytoothpaste.net>; Git
> <git@vger.kernel.org>; Jeff King <peff@peff.net>; Emily Shaffer
> <emilyshaffer@google.com>
> Subject: Re: [PATCH] Add project-wide .vimrc configuration
> 
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> *2* In other words, I doubt these graphs are depicting "how widely is
> >> an editor used by developers".  It is just showing how often it is
> >> installed, and I know the primary workstation I use daily has vim and
> >> nano installed without me choosing to have them, as opposed to emacs
> >> I had to manually install, and I only use vim once every month and
> >> nano once every quarter.
> >
> > Yes, but in Arch Linux at least no editor is installed by default.
> 
> I thought everybody has nano not because it is adequate and usable for
> them, but because it comes by default with distros, and distro in turn
choose
> nano not because it is particularly popular but is small enough not to
matter
> if left behind unused when the user chooses a real editor.
> 
> But you are essentially usaying that 80% of Arch users install nano by
choice.
> I find it doubly surprising.

I know of perhaps 3 or 4 nano users in the NonStop community. There are
probably three orders of magnitude more vi/vim users. vim and vi both come
installed on the platform by default. Nano is an add-on that my team builds
as a courtesy but there's small interest but it is loyal.

Regards,
Randall
diff mbox series

Patch

diff --git a/.vimrc b/.vimrc
new file mode 100644
index 0000000000..d250ab26e0
--- /dev/null
+++ b/.vimrc
@@ -0,0 +1,9 @@ 
+augroup git
+  au!
+  au BufRead,BufNewFile */t/*.sh set ft=sharness.sh
+  au BufRead,BufNewFile */Documentation/*.txt set ft=asciidoc
+
+  au FileType c setl noet ts=8 sw=0 cino=(s,:0,l1,t0
+  au FileType sh setl noet ts=8 sw=0
+  au FileType asciidoc setl noet ts=8 sw=0 autoindent
+augroup END