| Message ID | 20201209002619.25468-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add project-wide .vimrc configuration | expand |
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
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.
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 >
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/
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.
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.
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.
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.
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
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".
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.
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.
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
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 --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
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