{"thread":{"id":"54802","subject":"[PATCH v2 0/2] vim: configuration and sharness syntax","startedAt":"2020-12-09T06:56:36Z","lastAt":"2020-12-15T06:58:27Z","messageCount":22,"participants":["Felipe Contreras","Eric Sunshine","Christian Brabandt","Jeff King","brian m. carlson"],"isPatch":true,"patchVersion":2,"patchTotal":2},"messages":[{"id":"411822","messageId":"20201209065537.48802-1-felipe.contreras@gmail.com","threadId":"54802","inReplyTo":null,"subject":"[PATCH v2 0/2] vim: configuration and sharness syntax","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-09T06:55:35Z","receivedAt":"2020-12-09T06:56:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"After investigating alternatives for exrc I found too many, doing a wide\nrange of irrelevant stuff, many unmaintained, others requiring multiple\ndependencies, and some loaded the configuration too late.\n\nThe only one that seemed to fit the bill is vim-addon-local-vimrc, which\ndoes work straightofrwardly, but hasn't been updated since 2015.\n\nInstead I chose to simply vim-addon-local-vimrc, and take advantage of\ngit ('git rev-parse --show-toplevel' saves us a lot of the complexity of\nthese loaders).\n\nThe result is a very simple loader which is also secure, since it cannot\ndo anything unless you manually whitelist the project(s) you want load\n.vimrc files from.\n\nAnd since I already created some files in 'contrib/vim' I decided to put\nthe sharness syntax file there too.\n\n\nFelipe Contreras (2):\n Add project-wide .vimrc configuration\n contrib: vim: add sharness syntax file\n\n .vimrc | 23 ++++++++++++++++++++++\n contrib/vim/plugin/gitvimrc.vim | 21 ++++++++++++++++++++\n contrib/vim/syntax/sharness.vim | 34 +++++++++++++++++++++++++++++++++\n 3 files changed, 78 insertions(+)\n create mode 100644 .vimrc\n create mode 100644 contrib/vim/plugin/gitvimrc.vim\n create mode 100644 contrib/vim/syntax/sharness.vim\n\n-- \n2.29.2\n\n"},{"id":"411823","messageId":"20201209065537.48802-2-felipe.contreras@gmail.com","threadId":"54802","inReplyTo":"20201209065537.48802-1-felipe.contreras@gmail.com","subject":"[PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-09T06:55:36Z","receivedAt":"2020-12-09T06:56:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It's not efficient that everyone must set specific configurations in all\ntheir ~/.vimrc files; we can have a project-wide .vimrc that everyone\ncan use.\n\nThere's different ways to load this configuration, for example with\nvim-addon-local-vimrc [1], but we don't need much of the complexity of\nthese solutions.\n\nInstead I created a simple loader that is in the contrib area, which can\nbe installed with:\n\n cp -aT contrib/vim ~/.vim/pack/plugins/start/git\n\nThen, add the location of the Git repository to your ~/.vimrc:\n\n let g:gitvimrc_whitelist = [ expand('$HOME') . '/dev/git' ]\n\nThen the project-wide configuration will be loaded, which sets the\ncorrect filetype for the documentation, and also the default indentation\nof c, sh, perl, and asciidoc files.\n\nThese default configurations can be overridden in the typical way (by\nadding the corresponding file in ~/.vim/after/ftplugin).\n\nWe could add the vim modelines at the bottom of every file, like other\nprojects do, but this seems more sensible.\n\n[1] https://github.com/MarcWeber/vim-addon-local-vimrc\n\nSigned-off-by: Felipe Contreras \n---\n .vimrc | 22 ++++++++++++++++++++++\n contrib/vim/plugin/gitvimrc.vim | 21 +++++++++++++++++++++\n 2 files changed, 43 insertions(+)\n create mode 100644 .vimrc\n create mode 100644 contrib/vim/plugin/gitvimrc.vim\n\ndiff --git a/.vimrc b/.vimrc\nnew file mode 100644\nindex 0000000000..602c746477\n--- /dev/null\n+++ b/.vimrc\n@@ -0,0 +1,22 @@\n+\" To make use of these configurations install the git plugin provided in\n+\" the contrib section:\n+\"\n+\" cp -aT contrib/vim ~/.vim/pack/plugins/start/git\n+\"\n+\" Then whitelist the location of this directory to your ~/.vimrc:\n+\"\n+\" let g:gitvimrc_whitelist = [ expand('$HOME') . '/dev/git' ]\n+\"\n+\" You can add multiple locations, or specify a regexp pattern.\n+\"\n+\n+augroup git\n+\tau BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n+\n+\tau FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n+\tau FileType sh setl noexpandtab tabstop=8 shiftwidth=0\n+\tau FileType perl setl noexpandtab tabstop=8 shiftwidth=0\n+\tau FileType asciidoc setl noexpandtab tabstop=8 shiftwidth=0 autoindent\n+augroup END\n+\n+\" vim: noexpandtab tabstop=8 shiftwidth=0\ndiff --git a/contrib/vim/plugin/gitvimrc.vim b/contrib/vim/plugin/gitvimrc.vim\nnew file mode 100644\nindex 0000000000..c3946e5410\n--- /dev/null\n+++ b/contrib/vim/plugin/gitvimrc.vim\n@@ -0,0 +1,21 @@\n+let s:gitvimrc_whitelist = get(g:, 'gitvimrc_whitelist', [])\n+\n+function LoadGitVimrc()\n+ let l:top = trim(system('git rev-parse --show-toplevel'))\n+ if l:top == '' | return | endif\n+ let l:file = l:top . '/.vimrc'\n+ if !filereadable(l:file) | return | endif\n+\n+ let l:found = 0\n+ for l:pattern in s:gitvimrc_whitelist\n+ if (match(l:top, l:pattern) != -1)\n+ let l:found = 1\n+ break\n+ endif\n+ endfor\n+ if !l:found | return | endif\n+\n+ exec 'source ' . fnameescape(l:file)\n+endf\n+\n+call LoadGitVimrc()\n-- \n2.29.2\n\n"},{"id":"411824","messageId":"20201209065537.48802-3-felipe.contreras@gmail.com","threadId":"54802","inReplyTo":"20201209065537.48802-1-felipe.contreras@gmail.com","subject":"[PATCH v2 2/2] contrib: vim: add sharness syntax file","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-09T06:55:37Z","receivedAt":"2020-12-09T06:56:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It gets a bit tedious to see all the tests in the same color, so I\nwrote a vim syntax file to relax my eyes.\n\nI've tried to make it work in as many situations as possible, yet there\nare still some issues with HEREDOC strings.\n\nMuch better than nothing though.\n\nThis can be enabled with the following pattern:\n\n au BufRead,BufNewFile */t/*.sh set filetype=sh.sharness\n\nWhoever, that's already added to the project .vimrc.\n\nSigned-off-by: Felipe Contreras \n---\n .vimrc | 1 +\n contrib/vim/syntax/sharness.vim | 34 +++++++++++++++++++++++++++++++++\n 2 files changed, 35 insertions(+)\n create mode 100644 contrib/vim/syntax/sharness.vim\n\ndiff --git a/.vimrc b/.vimrc\nindex 602c746477..31600aaeca 100644\n--- a/.vimrc\n+++ b/.vimrc\n@@ -11,6 +11,7 @@\n \"\n \n augroup git\n+\tau BufRead,BufNewFile */t/*.sh set filetype=sh.sharness\n \tau BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n \n \tau FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\ndiff --git a/contrib/vim/syntax/sharness.vim b/contrib/vim/syntax/sharness.vim\nnew file mode 100644\nindex 0000000000..6ffc64ff06\n--- /dev/null\n+++ b/contrib/vim/syntax/sharness.vim\n@@ -0,0 +1,34 @@\n+let b:is_bash=1\n+runtime! syntax/sh.vim\n+\n+syn keyword shsStatement test_done\n+syn keyword shsStatement test_set_editor test_set_index_version test_decode_color lf_to_nul nul_to_q q_to_nul q_to_cr q_to_tab qz_to_tab_space append_cr remove_cr generate_zero_bytes sane_unset test_tick test_pause debug test_commit test_merge test_commit_bulk test_chmod test_modebits test_unconfig test_config test_config_global write_script test_unset_prereq test_set_prereq test_have_prereq test_declared_prereq test_verify_prereq test_external test_external_without_stderr test_path_is_file test_path_is_dir test_path_exists test_dir_is_empty test_file_not_empty test_path_is_missing test_line_count test_file_size list_contains test_must_fail_acceptable test_must_fail test_might_fail test_expect_code test_i18ncmp test_i18ngrep verbose test_must_be_empty test_cmp_rev test_cmp_fspath test_seq test_when_finished test_atexit test_create_repo test_ln_s_add test_write_lines perl test_bool_env test_skip_or_die mingw_test_cmp test_env test_match_signal test_copy_bytes nongit depacketize hex2oct test_set_hash test_detect_hash test_oid_init test_oid_cache test_oid test_oid_to_path test_set_port test_bitmap_traversal test_path_is_hidden test_subcommand\n+syn keyword shsStatement test_cmp test_cmp_config test_cmp_bin packetize\n+\n+syn region shsTest fold start=\"\\\" end=\"$\" contains=shsTestTitle\n+syn region shsTest fold start=\"\\\\s\\+\\<[A-Z_,]\\+\\>\" end=\"$\" contains=shsPrereq\n+syn region shsTest fold start=\"\\\\s\\+\\<[A-Z_,]\\+\\>\" end=\"$\" contains=shsPrereqLazy\n+\n+syn keyword shsTestStatement contained containedin=shsTest test_expect_success test_expect_failure test_expect_unstable test_lazy_prereq\n+\n+syn region shsTestTitle contained start=' 'hs=s+1 end=' 'me=e-1 nextgroup=shsTestBody contains=shSingleQuote,shDoubleQuote\n+\n+\" multiple line body\n+syn region shsTestBody contained transparent excludenl matchgroup=shQuote start=+ '$+hs=s+1,rs=e end=+'$+ contains=@shSubShList\n+syn region shsTestBody contained transparent excludenl matchgroup=shQuote start=+ \"$+hs=s+1,rs=e end=+\"$+ contains=@shSubShList\n+\n+\" single line body\n+syn region shsTestBody contained oneline transparent excludenl keepend matchgroup=shQuote start=+ '+hs=s+1 end=+'$+ contains=@shSubShList\n+syn region shsTestBody contained oneline transparent excludenl keepend matchgroup=shQuote start=+ \"+hs=s+1 end=+\"$+ contains=@shSubShList\n+\n+syn match shsPrereq contained \"\\<[A-Z_,]\\+\\>\" nextgroup=shsTestTitle\n+syn match shsPrereqLazy contained \"\\<[A-Z_,]\\+\\>\" nextgroup=shsTestBody\n+\n+syn cluster shCommandSubList add=shsTest,shsStatement\n+\n+hi def link shsStatement Statement\n+hi def link shsTestStatement Function\n+hi def link shsPrereq Identifier\n+hi def link shsPrereqLazy shsPrereq\n+\n+let b:current_syntax='sharness'\n-- \n2.29.2\n\n"},{"id":"411825","messageId":"CAPig+cRmCV23BjN0t3jF+VtxNS2a=E3Tr=x53DPn46qM15uMng@mail.gmail.com","threadId":"54802","inReplyTo":"20201209065537.48802-3-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 2/2] contrib: vim: add sharness syntax file","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-12-09T07:05:01Z","receivedAt":"2020-12-09T07:05:54Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Dec 9, 2020 at 1:56 AM Felipe Contreras\n wrote:\n> It gets a bit tedious to see all the tests in the same color, so I\n> wrote a vim syntax file to relax my eyes.\n>\n> I've tried to make it work in as many situations as possible, yet there\n> are still some issues with HEREDOC strings.\n>\n> Much better than nothing though.\n>\n> This can be enabled with the following pattern:\n>\n> au BufRead,BufNewFile */t/*.sh set filetype=sh.sharness\n>\n> Whoever, that's already added to the project .vimrc.\n\ns/Whoever/However/\n\n> Signed-off-by: Felipe Contreras \n"},{"id":"411830","messageId":"20201209085356.GJ22416@256bit.org","threadId":"54802","inReplyTo":"20201209065537.48802-2-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Christian Brabandt","fromEmail":"cb@256bit.org","sentAt":"2020-12-09T08:53:56Z","receivedAt":"2020-12-09T09:03:15Z","isPatch":true,"sender":{"key":"cb@256bit.org","avatar":"https://gravatar.com/avatar/c72756321dd9fa10cada6d4b1f2c4e577a979373d76960608f816cb49c575b02?d=mp&s=160"},"body":"Hi,\n\nFelipe Contreras schrieb am Mittwoch, den 09. Dezember 2020:\n\n> +augroup git\n> +\tau BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> +\n> +\tau FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n> +\tau FileType sh setl noexpandtab tabstop=8 shiftwidth=0\n> +\tau FileType perl setl noexpandtab tabstop=8 shiftwidth=0\n> +\tau FileType asciidoc setl noexpandtab tabstop=8 shiftwidth=0 autoindent\n> +augroup END\n\nThis will set filetype specific options. So after this file has been \nloaded, it will set e.g. set tabstop and shiftwidth options for \nfiletypes outside of the git project.\n\nShouldn't this only apply to files inside the git code repository?\n\n> +\n> +\" vim: noexpandtab tabstop=8 shiftwidth=0\n> diff --git a/contrib/vim/plugin/gitvimrc.vim b/contrib/vim/plugin/gitvimrc.vim\n> new file mode 100644\n> index 0000000000..c3946e5410\n> --- /dev/null\n> +++ b/contrib/vim/plugin/gitvimrc.vim\n> @@ -0,0 +1,21 @@\n> +let s:gitvimrc_whitelist = get(g:, 'gitvimrc_whitelist', [])\n> +\n> +function LoadGitVimrc()\n> + let l:top = trim(system('git rev-parse --show-toplevel'))\n\ntrim needs at least vim 8.0.1630. Is this recent enough? Could also use \nsystemlist()[0] which is available starting at vim 7.4.248 or just a \nsimple split(system(), \"\\n\")[0] which should be compatible with vim 7.\n\n> + if l:top == '' | return | endif\n> + let l:file = l:top . '/.vimrc'\n> + if !filereadable(l:file) | return | endif\n> +\n> + let l:found = 0\n> + for l:pattern in s:gitvimrc_whitelist\n\nYou could directly use `get(g:, 'gitvimrc_whitelist', [])` directly, so \nthe script local var s:gitvimrc_whitelist is not really needed.\n\n> + if (match(l:top, l:pattern) != -1)\n\nThis uses a regex match. Perhaps do a string comparsion? If this is \nneeded, consider adding \"\\C\" to force matching case and perhaps also \\V \nto force a literal match. Otherwise the options magic, ignorecase, \nsmartcase etc are applied to the matching.\n\n> + let l:found = 1\n> + break\n> + endif\n> + endfor\n> + if !l:found | return | endif\n> +\n> + exec 'source ' . fnameescape(l:file)\n> +endf\n> +\n> +call LoadGitVimrc()\n\nOn the style: I personally dislike the `l:` prefix for function local \nvariables, as this does not add anything. But perhaps this is just my \npersonal preference.\n\nBest,\nChristian\n"},{"id":"411835","messageId":"CAMP44s18FMyJoHogud3QjWGya_9bAB7yAaYUb1aTQ12fYUTNxw@mail.gmail.com","threadId":"54802","inReplyTo":"20201209085356.GJ22416@256bit.org","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-09T10:29:25Z","receivedAt":"2020-12-09T10:30:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hello,\n\nOn Wed, Dec 9, 2020 at 2:54 AM Christian Brabandt wrote:\n\n> Felipe Contreras schrieb am Mittwoch, den 09. Dezember 2020:\n>\n> > +augroup git\n> > + au BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> > +\n> > + au FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n> > + au FileType sh setl noexpandtab tabstop=8 shiftwidth=0\n> > + au FileType perl setl noexpandtab tabstop=8 shiftwidth=0\n> > + au FileType asciidoc setl noexpandtab tabstop=8 shiftwidth=0 autoindent\n> > +augroup END\n>\n> This will set filetype specific options. So after this file has been\n> loaded, it will set e.g. set tabstop and shiftwidth options for\n> filetypes outside of the git project.\n>\n> Shouldn't this only apply to files inside the git code repository?\n\nYes. But this file can only be loaded if your cwd is inside this\nrepository. That is; if \"git rev-parse --show-toplevel\" shows the same\ndirectory as this file.\n\n> > +\n> > +\" vim: noexpandtab tabstop=8 shiftwidth=0\n> > diff --git a/contrib/vim/plugin/gitvimrc.vim b/contrib/vim/plugin/gitvimrc.vim\n> > new file mode 100644\n> > index 0000000000..c3946e5410\n> > --- /dev/null\n> > +++ b/contrib/vim/plugin/gitvimrc.vim\n> > @@ -0,0 +1,21 @@\n> > +let s:gitvimrc_whitelist = get(g:, 'gitvimrc_whitelist', [])\n> > +\n> > +function LoadGitVimrc()\n> > + let l:top = trim(system('git rev-parse --show-toplevel'))\n>\n> trim needs at least vim 8.0.1630. Is this recent enough?\n\n2018? I think that's good enough. If not I'd be happy to include any\nother suggestion.\n\n> Could also use\n> systemlist()[0] which is available starting at vim 7.4.248 or just a\n> simple split(system(), \"\\n\")[0] which should be compatible with vim 7.\n\nYeah, in Linux. Will that work in Windows where carriage returns are \"\\r\\n\"?\n\n> > + if l:top == '' | return | endif\n> > + let l:file = l:top . '/.vimrc'\n> > + if !filereadable(l:file) | return | endif\n> > +\n> > + let l:found = 0\n> > + for l:pattern in s:gitvimrc_whitelist\n>\n> You could directly use `get(g:, 'gitvimrc_whitelist', [])` directly, so\n> the script local var s:gitvimrc_whitelist is not really needed.\n\nTrue. It's just a force of habit to copy the global scope to the\nscript scope. That being said; the \"for\" would call the get() function\nmultiple times (probably). So I'm not entirely sure what is being\ngained.\n\n> > + if (match(l:top, l:pattern) != -1)\n>\n> This uses a regex match. Perhaps do a string comparsion? If this is\n> needed, consider adding \"\\C\" to force matching case and perhaps also \\V\n> to force a literal match. Otherwise the options magic, ignorecase,\n> smartcase etc are applied to the matching.\n\nThis was straight-up copied from another solution. I just checked :h\nmatch() and didn't find any low-hanging fruit.\n\nIf you have a better proposal just type it out. I'm not overly\nfamiliar with vimscript, I just know the above works.\n\n> > + let l:found = 1\n> > + break\n> > + endif\n> > + endfor\n> > + if !l:found | return | endif\n> > +\n> > + exec 'source ' . fnameescape(l:file)\n> > +endf\n> > +\n> > +call LoadGitVimrc()\n>\n> On the style: I personally dislike the `l:` prefix for function local\n> variables, as this does not add anything. But perhaps this is just my\n> personal preference.\n\nI don't mind either way. I just add it for consistency since the\nsyntax sometimes doesn't identify such variables (e.g \"if !found\"),\nbut most of the time the syntax doesn't do it either way (which is\nodd).\n\nSo just s/l:// ?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"411836","messageId":"CAMP44s1FD2aBej3GMOQ4pWSga50uCwR3GBXfHL2KQLu3FSKLNA@mail.gmail.com","threadId":"54802","inReplyTo":"CAPig+cRmCV23BjN0t3jF+VtxNS2a=E3Tr=x53DPn46qM15uMng@mail.gmail.com","subject":"Re: [PATCH v2 2/2] contrib: vim: add sharness syntax file","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-09T10:39:24Z","receivedAt":"2020-12-09T10:40:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Dec 9, 2020 at 1:05 AM Eric Sunshine wrote:\n>\n> On Wed, Dec 9, 2020 at 1:56 AM Felipe Contreras\n> wrote:\n> > It gets a bit tedious to see all the tests in the same color, so I\n> > wrote a vim syntax file to relax my eyes.\n> >\n> > I've tried to make it work in as many situations as possible, yet there\n> > are still some issues with HEREDOC strings.\n> >\n> > Much better than nothing though.\n> >\n> > This can be enabled with the following pattern:\n> >\n> > au BufRead,BufNewFile */t/*.sh set filetype=sh.sharness\n> >\n> > Whoever, that's already added to the project .vimrc.\n>\n> s/Whoever/However/\n\nOops. Thanks.\n\n-- \nFelipe Contreras\n"},{"id":"411927","messageId":"20201209104532.GL22416@256bit.org","threadId":"54802","inReplyTo":"CAMP44s18FMyJoHogud3QjWGya_9bAB7yAaYUb1aTQ12fYUTNxw@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Christian Brabandt","fromEmail":"cb@256bit.org","sentAt":"2020-12-09T10:45:32Z","receivedAt":"2020-12-09T10:47:48Z","isPatch":true,"sender":{"key":"cb@256bit.org","avatar":"https://gravatar.com/avatar/c72756321dd9fa10cada6d4b1f2c4e577a979373d76960608f816cb49c575b02?d=mp&s=160"},"body":"\nOn Mi, 09 Dez 2020, Felipe Contreras wrote:\n\n> On Wed, Dec 9, 2020 at 2:54 AM Christian Brabandt wrote:\n> \n> > Felipe Contreras schrieb am Mittwoch, den 09. Dezember 2020:\n> >\n> > > +augroup git\n> > > + au BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> > > +\n> > > + au FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n> > > + au FileType sh setl noexpandtab tabstop=8 shiftwidth=0\n> > > + au FileType perl setl noexpandtab tabstop=8 shiftwidth=0\n> > > + au FileType asciidoc setl noexpandtab tabstop=8 shiftwidth=0 autoindent\n> > > +augroup END\n> >\n> > This will set filetype specific options. So after this file has been\n> > loaded, it will set e.g. set tabstop and shiftwidth options for\n> > filetypes outside of the git project.\n> >\n> > Shouldn't this only apply to files inside the git code repository?\n> \n> Yes. But this file can only be loaded if your cwd is inside this\n> repository. That is; if \"git rev-parse --show-toplevel\" shows the same\n> directory as this file.\n\nYes, however what I was trying to say was: Once I edited a file from \nwithin the git source repository, this means it will apply to all \nfurther files I will edit in this session. So I do `:e \n~/bin/my_precious_shell_script.sh` it will apply those settings there as \nwell.\n\nSo I would rather call a function in the FileType autocommand, that \nchecks the path of the currently edited file before it applies those \nsettings.\n\n> > > +\n> > > +\" vim: noexpandtab tabstop=8 shiftwidth=0\n> > > diff --git a/contrib/vim/plugin/gitvimrc.vim b/contrib/vim/plugin/gitvimrc.vim\n> > > new file mode 100644\n> > > index 0000000000..c3946e5410\n> > > --- /dev/null\n> > > +++ b/contrib/vim/plugin/gitvimrc.vim\n> > > @@ -0,0 +1,21 @@\n> > > +let s:gitvimrc_whitelist = get(g:, 'gitvimrc_whitelist', [])\n> > > +\n> > > +function LoadGitVimrc()\n> > > + let l:top = trim(system('git rev-parse --show-toplevel'))\n> >\n> > trim needs at least vim 8.0.1630. Is this recent enough?\n> \n> 2018? I think that's good enough. If not I'd be happy to include any\n> other suggestion.\n\nNot sure. CentOS 7 seems to have 7.4.629 and CentOS 8 8.0.1763, Ubuntu \nLTS 16.04 7.4.1689, all according to https://repology.org/project/vim/versions\n\nAnd then there is neovim. I suppose it has trim()\n\n> > Could also use\n> > systemlist()[0] which is available starting at vim 7.4.248 or just a\n> > simple split(system(), \"\\n\")[0] which should be compatible with vim 7.\n> \n> Yeah, in Linux. Will that work in Windows where carriage returns are \"\\r\\n\"?\n\nYes.\n\n> > > + if l:top == '' | return | endif\n> > > + let l:file = l:top . '/.vimrc'\n> > > + if !filereadable(l:file) | return | endif\n> > > +\n> > > + let l:found = 0\n> > > + for l:pattern in s:gitvimrc_whitelist\n> >\n> > You could directly use `get(g:, 'gitvimrc_whitelist', [])` directly, so\n> > the script local var s:gitvimrc_whitelist is not really needed.\n> \n> True. It's just a force of habit to copy the global scope to the\n> script scope. That being said; the \"for\" would call the get() function\n> multiple times (probably). So I'm not entirely sure what is being\n> gained.\n\nThis function is called only once and get() should be quite fast.\n\n> \n> > > + if (match(l:top, l:pattern) != -1)\n> >\n> > This uses a regex match. Perhaps do a string comparsion? If this is\n> > needed, consider adding \"\\C\" to force matching case and perhaps also \\V\n> > to force a literal match. Otherwise the options magic, ignorecase,\n> > smartcase etc are applied to the matching.\n> \n> This was straight-up copied from another solution. I just checked :h\n> match() and didn't find any low-hanging fruit.\n> \n> If you have a better proposal just type it out. I'm not overly\n> familiar with vimscript, I just know the above works.\n\nIs comparing literally good enough? e.g. \n\nif top ==# pattern\n\n(this would match case, or use ==? to ignore case). In any case, make \ncase matching explicit, so that the options `ignorecase` and `smartcase` \nare not used.\n\n> \n> > > + let l:found = 1\n> > > + break\n> > > + endif\n> > > + endfor\n> > > + if !l:found | return | endif\n> > > +\n> > > + exec 'source ' . fnameescape(l:file)\n> > > +endf\n> > > +\n> > > +call LoadGitVimrc()\n> >\n> > On the style: I personally dislike the `l:` prefix for function local\n> > variables, as this does not add anything. But perhaps this is just my\n> > personal preference.\n> \n> I don't mind either way. I just add it for consistency since the\n> syntax sometimes doesn't identify such variables (e.g \"if !found\"),\n> but most of the time the syntax doesn't do it either way (which is\n> odd).\n\nYou mean the vimscript syntax? I don't remember seeing such.\n\n> So just s/l:// ?\n\nYes, unless you use a variable called count, which would be shadowed by \nv:count\n\nBest,\nChristian\n-- \nAchte auf Deine Gedanken! Sie sind der Anfang Deiner Taten.\n\t\t-- Chinesisches Sprichwort\n"},{"id":"411887","messageId":"X9EFVIlm8sYKtLwr@coredump.intra.peff.net","threadId":"54802","inReplyTo":"20201209065537.48802-1-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 0/2] vim: configuration and sharness syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-12-09T17:11:48Z","receivedAt":"2020-12-09T17:12:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 09, 2020 at 12:55:35AM -0600, Felipe Contreras wrote:\n\n> After investigating alternatives for exrc I found too many, doing a wide\n> range of irrelevant stuff, many unmaintained, others requiring multiple\n> dependencies, and some loaded the configuration too late.\n\nI'm not opposed to this solution, but I probably wouldn't use it myself.\nI wonder if it would be sufficient to just say \"here are some sensible\nvim options\", coupled with human-readable instructions for how to\nintegrate them into your .vimrc, along with some path-selection.\n\nIt's perhaps not quite as turnkey. On the other hand, it's easy for\npeople who are even moderate vim users to understand what each line\ndoes. In the plugin solution, there are more lines dedicated to loading\nthe config than there are actual config lines.\n\nI dunno.\n\n> And since I already created some files in 'contrib/vim' I decided to put\n> the sharness syntax file there too.\n\nThis part I like very much. The actual policy logic is sufficiently\ncomplex that I hope people will be able to contribute back small fixes.\n\n-Peff\n"},{"id":"411889","messageId":"X9EI8c9yeX136ewm@coredump.intra.peff.net","threadId":"54802","inReplyTo":"20201209065537.48802-2-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-12-09T17:27:13Z","receivedAt":"2020-12-09T17:28:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 09, 2020 at 12:55:36AM -0600, Felipe Contreras wrote:\n\n> +augroup git\n> +\tau BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> +\n> +\tau FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n\nI had to read up on a few of these settings, and I'm still slightly\npuzzled:\n\n - I generally leave shiftwidth=8, but reading the documentation says\n that 0 is equivalent to \"1 tabstop\". So that should be equivalent.\n\n - I've been using \"(0\" for years for my git work (which indents to\n align new lines with the unclosed parenthesis). I'm not quite sure\n what \"(s\" means. The documentation says \"1s\" would be \"one\n shiftwidth\". Is just \"s\" the same?\n\n - I also have \":0\", which doesn't indent case labels. Matches our\n style.\n\n - I didn't have \"l\" set myself. I never noticed because it only\n matters if you open a case with an extra brace, which is relatively\n rare. For non-vim folks, it is preferring:\n\n\tswitch (foo) {\n\tcase 0: {\n\t\tbreak;\n\t}\n\n to:\n\n\tswitch (foo) {\n\tcase 0: {\n\t\t\tbreak;\n\t\t}\n\n which seems consistent with our style. So I think that is worth\n doing.\n\n - t0 is specifying not to indent function return types when they\n appear on a separate line. But our style is not to put those return\n types on a separate line, anyway. Do we need this?\n\n-Peff\n"},{"id":"411966","messageId":"CAMP44s19FKYT5LNUxbGZP3czFmhe9t5B-FAfH+V2btNvMNW31g@mail.gmail.com","threadId":"54802","inReplyTo":"X9EI8c9yeX136ewm@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-10T01:55:55Z","receivedAt":"2020-12-10T01:56:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Dec 9, 2020 at 11:27 AM Jeff King wrote:\n>\n> On Wed, Dec 09, 2020 at 12:55:36AM -0600, Felipe Contreras wrote:\n>\n> > +augroup git\n> > + au BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> > +\n> > + au FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n>\n> I had to read up on a few of these settings, and I'm still slightly\n> puzzled:\n>\n> - I generally leave shiftwidth=8, but reading the documentation says\n> that 0 is equivalent to \"1 tabstop\". So that should be equivalent.\n\nYes. It is.\n\nIf you read the help of tabstop [1] it says there are four main ways\nof using tab, and we are using the fourth one: \"always set 'tabstop'\nand 'shiftwidth' to the same value, and 'noexpandtab'.\"\n\nOther projects use a different tabstop, and expandtab (mode 2),\nhowever, I have *never* found a use case where it made sense to have a\ndifferent shiftwidth than tabstop. And it gets tedious to *always* do\nts=X sw=X, when you can just do sw=0 in your ~/.vimrc, and ts=X per\nproject.\n\n> - I've been using \"(0\" for years for my git work (which indents to\n> align new lines with the unclosed parenthesis). I'm not quite sure\n> what \"(s\" means. The documentation says \"1s\" would be \"one\n> shiftwidth\". Is just \"s\" the same?\n\nYes. If you read CodingGuidelines it says there are two schools of\nthought when it comes to splitting long logical lines. The first\nexample is \"(s\", the second one is \"(0\".\n\nThe reason why I prefer \"(s\" is that this is more commonly used in the\nLinux kernel. However, it's not quite the same in vim (when there's\nmore than one parenthesis). I've planned to contact vim developers\nabout that, but I haven't yet. Just for that reason it might make\nsense to use \"(0\" for the project.\n\n> - I also have \":0\", which doesn't indent case labels. Matches our\n> style.\n>\n> - I didn't have \"l\" set myself. I never noticed because it only\n> matters if you open a case with an extra brace, which is relatively\n> rare. For non-vim folks, it is preferring:\n>\n> switch (foo) {\n> case 0: {\n> break;\n> }\n>\n> to:\n>\n> switch (foo) {\n> case 0: {\n> break;\n> }\n>\n> which seems consistent with our style. So I think that is worth\n> doing.\n>\n> - t0 is specifying not to indent function return types when they\n> appear on a separate line. But our style is not to put those return\n> types on a separate line, anyway. Do we need this?\n\nRight. I recall at some point it was annoying me that types were auto\nindented magically at wrong times. Testing \"ts\" that doesn't seem to\nhappen anymore, but it also doesn't seem to be working at all.\n\nDo you see some difference from \"t0\" and \"ts\" with:\n\n void\n main(void) { }\n\nCheers.\n\n[1] https://vimhelp.org/options.txt.html#%27tabstop%27\n\n-- \nFelipe Contreras\n"},{"id":"411978","messageId":"CAMP44s24shbskATDCyffE4HC9vP6fnxQcWc-SBHLZQ2DEXaiwg@mail.gmail.com","threadId":"54802","inReplyTo":"X9EFVIlm8sYKtLwr@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/2] vim: configuration and sharness syntax","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-10T03:25:14Z","receivedAt":"2020-12-10T03:26:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Dec 9, 2020 at 11:11 AM Jeff King wrote:\n>\n> On Wed, Dec 09, 2020 at 12:55:35AM -0600, Felipe Contreras wrote:\n>\n> > After investigating alternatives for exrc I found too many, doing a wide\n> > range of irrelevant stuff, many unmaintained, others requiring multiple\n> > dependencies, and some loaded the configuration too late.\n>\n> I'm not opposed to this solution, but I probably wouldn't use it myself.\n> I wonder if it would be sufficient to just say \"here are some sensible\n> vim options\", coupled with human-readable instructions for how to\n> integrate them into your .vimrc, along with some path-selection.\n>\n> It's perhaps not quite as turnkey. On the other hand, it's easy for\n> people who are even moderate vim users to understand what each line\n> does. In the plugin solution, there are more lines dedicated to loading\n> the config than there are actual config lines.\n\nIf they only code for Git, it's straightforward to tell them how to\nconfigure vim.\n\nBut if the user contributes to two projects with two different\ncode-styles it gets to get tricky to tell them what to do. And when\nyou get to three, my bet is that the vast majority of people wouldn't\nknow what's the best solution for the user.\n\nThis is the most non-intrusive solution.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"411979","messageId":"X9GbIG9vZbK1pEoi@camp.crustytoothpaste.net","threadId":"54802","inReplyTo":"20201209065537.48802-2-felipe.contreras@gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-10T03:50:56Z","receivedAt":"2020-12-10T03:52:36Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-09 at 06:55:36, Felipe Contreras wrote:\n> diff --git a/.vimrc b/.vimrc\n> new file mode 100644\n> index 0000000000..602c746477\n> --- /dev/null\n> +++ b/.vimrc\n> @@ -0,0 +1,22 @@\n> +\" To make use of these configurations install the git plugin provided in\n> +\" the contrib section:\n> +\"\n> +\" cp -aT contrib/vim ~/.vim/pack/plugins/start/git\n> +\"\n> +\" Then whitelist the location of this directory to your ~/.vimrc:\n> +\"\n> +\" let g:gitvimrc_whitelist = [ expand('$HOME') . '/dev/git' ]\n> +\"\n> +\" You can add multiple locations, or specify a regexp pattern.\n> +\"\n> +\n> +augroup git\n> +\tau BufRead,BufNewFile */Documentation/*.txt set filetype=asciidoc\n> +\n> +\tau FileType c setl noexpandtab tabstop=8 shiftwidth=0 cino=(s,:0,l1,t0\n> +\tau FileType sh setl noexpandtab tabstop=8 shiftwidth=0\n> +\tau FileType perl setl noexpandtab tabstop=8 shiftwidth=0\n> +\tau FileType asciidoc setl noexpandtab tabstop=8 shiftwidth=0 autoindent\n> +augroup END\n\nI don't think this should go in this location. It should go in contrib.\nHere's why:\n\n* We should not ship editor-specific files in the main directory of the\n repository. Even though Vim is very popular, it is one of many\n editors, and it is not even the most popular editor (which is now VS\n Code). We have editor-independent files, and users can copy this into\n the root of the repository and ignore it if they want it there.\n* Whether a user wants to use automatic indentation is a personal\n preference. I do happen to like it, but there are others who don't\n and prefer to leave it off. Similarly, whether to use cindent,\n smartindent, or autoindent is a preference, as is which cindent\n options to use (I use different ones).\n* These settings affect every file that's loaded in the same editor\n process. While many people open different editor windows for\n different projects, other people prefer to use the client-server\n functionality to load all of their projects in the same editor. These\n are not, for example, the editor settings I normally use for non-Git\n AsciiDoc files.\n\nSo while I agree that these are common settings, they are not\nuniversally applicable, even for Vim and Neovim users, and we shouldn't\ntry to claim that all or even most Vim and Neovim users should use them.\nIn contrast, the .editorconfig file specifies things which are (a)\nguaranteed to affect only this repository and (b) are essential parts of\nour coding style. It notably omits things like line endings which are a\nmatter of user or platform preference.\n\nSo I think contrib makes more sense here.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412001","messageId":"X9I+eisn7sQuWZ1J@coredump.intra.peff.net","threadId":"54802","inReplyTo":"CAMP44s19FKYT5LNUxbGZP3czFmhe9t5B-FAfH+V2btNvMNW31g@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-12-10T15:27:54Z","receivedAt":"2020-12-10T15:29:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 09, 2020 at 07:55:55PM -0600, Felipe Contreras wrote:\n\n> > - t0 is specifying not to indent function return types when they\n> > appear on a separate line. But our style is not to put those return\n> > types on a separate line, anyway. Do we need this?\n> \n> Right. I recall at some point it was annoying me that types were auto\n> indented magically at wrong times. Testing \"ts\" that doesn't seem to\n> happen anymore, but it also doesn't seem to be working at all.\n> \n> Do you see some difference from \"t0\" and \"ts\" with:\n> \n> void\n> main(void) { }\n\nNo, but picking it does seem to impact a larger example. If I open up\nwt-status.c and modify the first function to be:\n\n static const char *\n color(int slot, struct wt_status *s)\n {\n\nthen reindenting it with t0 versus ts makes a difference (and I do\nprefer the t0 behavior). But we would not use that split-line style in\nour project in the first place, I don't think.\n\n-Peff\n"},{"id":"412030","messageId":"CAMP44s2yBLD+4GTny-GxAuoUdg66zChebsKc=-V7AeOw+RTx-A@mail.gmail.com","threadId":"54802","inReplyTo":"X9I+eisn7sQuWZ1J@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-11T00:43:18Z","receivedAt":"2020-12-11T00:46:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 10, 2020 at 9:27 AM Jeff King wrote:\n>\n> On Wed, Dec 09, 2020 at 07:55:55PM -0600, Felipe Contreras wrote:\n>\n> > > - t0 is specifying not to indent function return types when they\n> > > appear on a separate line. But our style is not to put those return\n> > > types on a separate line, anyway. Do we need this?\n> >\n> > Right. I recall at some point it was annoying me that types were auto\n> > indented magically at wrong times. Testing \"ts\" that doesn't seem to\n> > happen anymore, but it also doesn't seem to be working at all.\n> >\n> > Do you see some difference from \"t0\" and \"ts\" with:\n> >\n> > void\n> > main(void) { }\n>\n> No, but picking it does seem to impact a larger example. If I open up\n> wt-status.c and modify the first function to be:\n>\n> static const char *\n> color(int slot, struct wt_status *s)\n> {\n>\n> then reindenting it with t0 versus ts makes a difference (and I do\n> prefer the t0 behavior).\n\nI see.\n\nFor some reason this is indented:\n\n void\n main(void)\n {\n\nBut not this:\n\n void\n main(void) {\n\n> But we would not use that split-line style in\n> our project in the first place, I don't think.\n\nNo, we don't use it, but I recall some problems when not setting it\n(perhaps pasting code with that style).\n\nAnyway, I can't reproduce any of the problems, so I'm fine with dropping it.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412031","messageId":"CAMP44s33J6F60W=2Yd2WSGE78VT0XBkewi8m3unXvathBH2TOQ@mail.gmail.com","threadId":"54802","inReplyTo":"X9GbIG9vZbK1pEoi@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-11T01:08:00Z","receivedAt":"2020-12-11T01:09:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Dec 9, 2020 at 9:51 PM brian m. carlson\n wrote:\n> On 2020-12-09 at 06:55:36, Felipe Contreras wrote:\n\n> I don't think this should go in this location. It should go in contrib.\n> Here's why:\n>\n> * We should not ship editor-specific files in the main directory of the\n> repository.\n\nWhy not?\n\n> Even though Vim is very popular, it is one of many\n> editors, and it is not even the most popular editor (which is now VS\n> Code).\n\nEven if vim is not the most popular, it certainly is among the top 3\n(and I doubt VS Code is the most popular, I would like to see some\nnumbers on that, but even then; VS Code is not an editor).\n\nNobody is arguing to have editor-specific files for \"every editor\nunder the sun\", just perhaps 2 (or maybe even 3).\n\nNo slippery slope fallacy here.\n\n> We have editor-independent files, and users can copy this into\n> the root of the repository and ignore it if they want it there.\n\nWhich are insufficient. They are certainly better than nothing. Plus,\nit's unclear how many people are actually using those.\n\nAnd I'm still waiting for the argument against adding such a top-level file.\n\nWhat is the harm?\n\n> * Whether a user wants to use automatic indentation is a personal\n> preference. I do happen to like it, but there are others who don't\n> and prefer to leave it off. Similarly, whether to use cindent,\n> smartindent, or autoindent is a preference, as is which cindent\n> options to use (I use different ones).\n\nSo?\n\nThese options will not be forced on users, they have to specifically\nenable them by doing at least two steps, *and* they can still\nselectively override them in their ~/.vim files.\n\n> * These settings affect every file that's loaded in the same editor\n> process.\n\nThat is not true.\n\n:setlocal [1] applies the setting to the current buffer only, not\nglobally, and *only* when the buffer is of the filetype specified in\nthe autocommand.\n\n> So while I agree that these are common settings, they are not\n> universally applicable, even for Vim and Neovim users, and we shouldn't\n> try to claim that all or even most Vim and Neovim users should use them.\n\nWe don't. These are defaults, which a) the user must consciously\nchoose to apply them, and b) can be easily overridden (as is explained\nin the commit message).\n\n> So I think contrib makes more sense here.\n\nClearly. But you haven't put forward an argument about how precisely\nwill this negatively affect *any* user (or the project).\n\nCheers.\n\n[1] https://vimhelp.org/options.txt.html#%3Asetlocal\n\n-- \nFelipe Contreras\n"},{"id":"412038","messageId":"X9Lf1p++YktzZMWe@camp.crustytoothpaste.net","threadId":"54802","inReplyTo":"CAMP44s33J6F60W=2Yd2WSGE78VT0XBkewi8m3unXvathBH2TOQ@mail.gmail.com","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-11T02:56:22Z","receivedAt":"2020-12-11T02:58:15Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-11 at 01:08:00, Felipe Contreras wrote:\n> On Wed, Dec 9, 2020 at 9:51 PM brian m. carlson\n> wrote:\n> > On 2020-12-09 at 06:55:36, Felipe Contreras wrote:\n> \n> > I don't think this should go in this location. It should go in contrib.\n> > Here's why:\n> >\n> > * We should not ship editor-specific files in the main directory of the\n> > repository.\n> \n> Why not?\n\nBest practices indicate that we don't check in files which are specific\nto a developer. Anything that controls the specific editor people use\nis by definition specific to the developer. Checking in these files\nleads to conflicts over which settings to apply and whose settings are\nbetter when they could just be avoided.\n\nIf we have style policies, those should be expressed in a general,\nuniversal way so that all users can take advantage of them in the same\nway.\n\nFurthermore, some editors want entire large directories of configuration\nfiles in order to work correctly, which we don't want to include.\n\nIf we treat all editors in the same way, then every developer gets the\nsame experience when they work on our code. If that experience is\ninadequate, our time would be better spent improving it in a universal\nway so that all developers can benefit.\n\n> > Even though Vim is very popular, it is one of many\n> > editors, and it is not even the most popular editor (which is now VS\n> > Code).\n> \n> Even if vim is not the most popular, it certainly is among the top 3\n> (and I doubt VS Code is the most popular, I would like to see some\n> numbers on that, but even then; VS Code is not an editor).\n> \n> Nobody is arguing to have editor-specific files for \"every editor\n> under the sun\", just perhaps 2 (or maybe even 3).\n> \n> No slippery slope fallacy here.\n\nBecause we don't need them. Your solution requires the user to\nconfigure Vim with a plugin _and then_ allow the specific directory in\norder to be secure, which means it doesn't work with worktrees. It also\nrequires that the user never pull an untrusted branch into their\nrepository. It also has other undesirable effects which I mentioned in\nmy original email.\n\nThe .editorconfig file also requires a user to configure a plugin, once,\nand then things automatically work in a secure way across projects. In\nother words, the existing solution requires a user to affirmatively act,\nbut with less effort, less potential for security problems, and better\ncross-project support.\n\nSo the .vimrc solution requires more effort, has more potential security\nproblems, is less flexible, is less like how other projects solve this\nproblem, and is less general.\n\n> > We have editor-independent files, and users can copy this into\n> > the root of the repository and ignore it if they want it there.\n> \n> Which are insufficient. They are certainly better than nothing. Plus,\n> it's unclear how many people are actually using those.\n\nWhy are they insufficient? Multiple developers are using them on Git\nalready. They're used on projects from Microsoft[0], W3C[1], and folks\nworking on JSONPath[2]. They are the de facto standard for this\npurpose.\n\nIn contrast, searching GitHub commits for \".vimrc\" shows overwhelmingly\nthat the repositories in which these commits are named are called\n\"dotfiles\". I was unable to find any projects from major organizations\nusing this configuration style.\n\nMy general rule is that when I'm unsure what decision to make on a\nproject, I should make the decision that everybody else has made,\nbecause users and developers will expect my project to work just like\neveryone else's.\n\n> And I'm still waiting for the argument against adding such a top-level file.\n> \n> What is the harm?\n\nAs mentioned, enabling the use of this file is still risky from a\nsecurity perspective because it precludes even pulling in an untrusted\nbranch and then spawning an editor. We already have a more general\nsolution that is more widely adopted and has fewer downsides, so there's\nno point in adding files which really provide little benefit over what\nwe already have.\n\nIf there's little benefit, we shouldn't carry files which are going to\nbe subject mostly to pointless arguments over personal preference. The\nfact that two heavy Vim users disagree so strongly over relatively\nsimple settings is an argument for not adopting this approach as a set\nof project settings.\n\n> > * Whether a user wants to use automatic indentation is a personal\n> > preference. I do happen to like it, but there are others who don't\n> > and prefer to leave it off. Similarly, whether to use cindent,\n> > smartindent, or autoindent is a preference, as is which cindent\n> > options to use (I use different ones).\n> \n> So?\n> \n> These options will not be forced on users, they have to specifically\n> enable them by doing at least two steps, *and* they can still\n> selectively override them in their ~/.vim files.\n\nRight, but why are your preferred settings checked into Git as a project\nsetting? They are objectively no better than my settings, which differ.\nAbsent a compelling reason that these settings are objectively better,\nwe should not endorse them as preferred project settings.\n\n> > * These settings affect every file that's loaded in the same editor\n> > process.\n> \n> That is not true.\n> \n> :setlocal [1] applies the setting to the current buffer only, not\n> globally, and *only* when the buffer is of the filetype specified in\n> the autocommand.\n\nSo if I spawn an editor process using this .vimrc in my Git directory\nand then I load an AsciiDoc file from a different repository into that\nsame Vim process, are you arguing that the Git settings will not be\napplied to the AsciiDoc file from other directory? I'm pretty sure that\nVim will in fact use the Git settings. It's possible, however, that\nI've misunderstood how Vim works.\n\n.editorconfig doesn't have these downsides.\n\n> > So while I agree that these are common settings, they are not\n> > universally applicable, even for Vim and Neovim users, and we shouldn't\n> > try to claim that all or even most Vim and Neovim users should use them.\n> \n> We don't. These are defaults, which a) the user must consciously\n> choose to apply them, and b) can be easily overridden (as is explained\n> in the commit message).\n\nI'm arguing that they are not universal enough to be defaults.\nMoreover, a set of defaults for how a user _could_ configure their\neditor would belong in contrib, much like defaults for how a user\n_could_ configure their MUA to send properly to the mailing list.\n\nWe already have files for Emacs and VS Code, and those live properly in\ncontrib, along with code for Thunderbird and alternative build systems.\nIf we're treating this proposal like existing code, it belongs in\ncontrib.\n\nThe .editorconfig file, on the other hand, doesn't express defaults. It\nexpresses only project standards and doesn't specify any other settings.\n\n[0] https://github.com/microsoft/fabrikate\n[1] https://github.com/w3c/specberus\n[2] https://github.com/jsonpath-standard/internet-draft\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412044","messageId":"CAMP44s3skSjDM4c=G2izwX7n-9Of_TMsgouozj=O8sD68B18Pw@mail.gmail.com","threadId":"54802","inReplyTo":"X9Lf1p++YktzZMWe@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-11T04:37:26Z","receivedAt":"2020-12-11T04:39:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Dec 10, 2020 at 8:57 PM brian m. carlson\n wrote:\n>\n> On 2020-12-11 at 01:08:00, Felipe Contreras wrote:\n> > On Wed, Dec 9, 2020 at 9:51 PM brian m. carlson\n> > wrote:\n> > > On 2020-12-09 at 06:55:36, Felipe Contreras wrote:\n> >\n> > > I don't think this should go in this location. It should go in contrib.\n> > > Here's why:\n> > >\n> > > * We should not ship editor-specific files in the main directory of the\n> > > repository.\n> >\n> > Why not?\n>\n> Best practices indicate that we don't check in files which are specific\n> to a developer.\n\nBut it's not specific to a developer.\n\n> Anything that controls the specific editor people use\n> is by definition specific to the developer.\n\nNot really. Everyone that replied to the patch agreed on those settings.\n\nDid anyone say they use tabstop=4?\n\n> Checking in these files\n> leads to conflicts over which settings to apply and whose settings are\n> better when they could just be avoided.\n>\n> If we have style policies, those should be expressed in a general,\n> universal way so that all users can take advantage of them in the same\n> way.\n\nDo you have any specifics? Because nobody complained about the\nproposed settings.\n\n> Furthermore, some editors want entire large directories of configuration\n> files in order to work correctly, which we don't want to include.\n\nThat's a problem for \"some editors\". Not vim.\n\n> If we treat all editors in the same way, then every developer gets the\n> same experience when they work on our code.\n\nBut we don't want every developer to get the same experience. We want\ndevelopers to get the best experience they can get from their editor\nof choice.\n\nWe don't want the least common denominator.\n\n> If that experience is\n> inadequate, our time would be better spent improving it in a universal\n> way so that all developers can benefit.\n\nThis is the nirvana fallacy. We don't have to wait for a perfect\nsolution when we have a perfectly good enough solution. *Right now* we\ncan help the vast majority of vim users. There's no reason not to do\nso.\n\nFeel free to contribute patches to editorconfig until the experience\nmatches the proposed .vimrc. In the meantime the proposal is still the\nbest solution.\n\n> > > Even though Vim is very popular, it is one of many\n> > > editors, and it is not even the most popular editor (which is now VS\n> > > Code).\n> >\n> > Even if vim is not the most popular, it certainly is among the top 3\n> > (and I doubt VS Code is the most popular, I would like to see some\n> > numbers on that, but even then; VS Code is not an editor).\n> >\n> > Nobody is arguing to have editor-specific files for \"every editor\n> > under the sun\", just perhaps 2 (or maybe even 3).\n> >\n> > No slippery slope fallacy here.\n>\n> Because we don't need them.\n\nWe don't need to need them. All we need is to want them (because it's\nbetter than the current situation).\n\n> Your solution requires the user to\n> configure Vim with a plugin _and then_ allow the specific directory in\n> order to be secure, which means it doesn't work with worktrees.\n\nThe editorconfig solution also requires a plugin.\n\nAnd the .vimrc solution does work with worktrees. All the user has to\ndo is specify them.\n\nOr just:\n\n let g:gitvimrc_whitelist = [ '.*' ]\n\nPlus, even if it didn't work with worktrees, it's still better than\nthe current situation, where it works nowhere.\n\n> It also\n> requires that the user never pull an untrusted branch into their\n> repository.\n\nThis is always the case. An untrusted branch can modify the git binary\nto do whatever it wants.\n\n> The .editorconfig file also requires a user to configure a plugin, once,\n> and then things automatically work in a secure way across projects.\n\nAnd have a *much poorer* configuration as a result.\n\nIt's not even close.\n\n> So the .vimrc solution requires more effort, has more potential security\n> problems, is less flexible, is less like how other projects solve this\n> problem, and is less general.\n\nAll that is hypothetical.\n\nWhat is *factually* the case is that the resulting configuration is\nmuch superior.\n\n> > > We have editor-independent files, and users can copy this into\n> > > the root of the repository and ignore it if they want it there.\n> >\n> > Which are insufficient. They are certainly better than nothing. Plus,\n> > it's unclear how many people are actually using those.\n>\n> Why are they insufficient? Multiple developers are using them on Git\n> already. They're used on projects from Microsoft[0], W3C[1], and folks\n> working on JSONPath[2]. They are the de facto standard for this\n> purpose.\n\nI already explained:\n\n1. The sharness syntax is not set for tests\n2. The asciidoc syntax is not set for the documentation\n3. The specific cinoptios for C code are not set: \"(s,:0,l1\"\n\nAll of these are improvements the people that replied to the proposal\nseem to want.\n\n> In contrast, searching GitHub commits for \".vimrc\" shows overwhelmingly\n> that the repositories in which these commits are named are called\n> \"dotfiles\". I was unable to find any projects from major organizations\n> using this configuration style.\n\nThis is the naturalistic fallacy. Just because in the current state\nmost projects do not have a .vimrc does not mean we should follow the\nsteps of most projects.\n\nMost projects have vim modelines at the end of each file. Shall we\nfollow what most projects do?\n\nIn addition it's the bandwagon fallacy: if all your friends jumped off\na cliff, would you?\n\nThe reason why most projects don't have a .vimrc file is that nobody\nhas taken the time out of their normal tasks to improve the current\nsituation.\n\nBut I just did.\n\n> > And I'm still waiting for the argument against adding such a top-level file.\n> >\n> > What is the harm?\n>\n> As mentioned, enabling the use of this file is still risky from a\n> security perspective because it precludes even pulling in an untrusted\n> branch and then spawning an editor.\n\nThat is always a risk.\n\nHave you ever pulled a branch from an untrusted source and not looked\nat the commits?\n\n> We already have a more general\n> solution that is more widely adopted and has fewer downsides, so there's\n> no point in adding files which really provide little benefit over what\n> we already have.\n\nIs it widely adopted? I've never heard of editorconfig.\n\n> If there's little benefit, we shouldn't carry files which are going to\n> be subject mostly to pointless arguments over personal preference.\n\nWho says there's little benefit? Nobody that replied objects to this\nchange (except you).\n\nIf you see little benefit, then you don't use this .vimrc solution.\n\nWhy are you against the rest of us making our own decision out of our\nown volition?\n\n> The\n> fact that two heavy Vim users disagree so strongly over relatively\n> simple settings is an argument for not adopting this approach as a set\n> of project settings.\n\nWho are these two heavy vim users that disagree so strongly?\n\n> > > * Whether a user wants to use automatic indentation is a personal\n> > > preference. I do happen to like it, but there are others who don't\n> > > and prefer to leave it off. Similarly, whether to use cindent,\n> > > smartindent, or autoindent is a preference, as is which cindent\n> > > options to use (I use different ones).\n> >\n> > So?\n> >\n> > These options will not be forced on users, they have to specifically\n> > enable them by doing at least two steps, *and* they can still\n> > selectively override them in their ~/.vim files.\n>\n> Right, but why are your preferred settings checked into Git as a project\n> setting?\n\nThey are not my preferred settings. Everyone (so far) has agreed these\nare good project-wide settings.\n\n> They are objectively no better than my settings, which differ.\n\nHow do they differ? What are your settings?\n\n> Absent a compelling reason that these settings are objectively better,\n> we should not endorse them as preferred project settings.\n\nThey don't have to be better than *your* settings. They have to be\nbetter than vim's default settings, which they are.\n\n*Your* settings will not be overridden.\n\n> > > * These settings affect every file that's loaded in the same editor\n> > > process.\n> >\n> > That is not true.\n> >\n> > :setlocal [1] applies the setting to the current buffer only, not\n> > globally, and *only* when the buffer is of the filetype specified in\n> > the autocommand.\n>\n> So if I spawn an editor process using this .vimrc in my Git directory\n> and then I load an AsciiDoc file from a different repository into that\n> same Vim process, are you arguing that the Git settings will not be\n> applied to the AsciiDoc file from other directory? I'm pretty sure that\n> Vim will in fact use the Git settings. It's possible, however, that\n> I've misunderstood how Vim works.\n\nIn that particular case; yes, those settings would be applied.\n\nConfigurations are never perfect. If this particular configuration\nbothers you, and I fix that. Would you then approve of this change?\n\n> > > So while I agree that these are common settings, they are not\n> > > universally applicable, even for Vim and Neovim users, and we shouldn't\n> > > try to claim that all or even most Vim and Neovim users should use them.\n> >\n> > We don't. These are defaults, which a) the user must consciously\n> > choose to apply them, and b) can be easily overridden (as is explained\n> > in the commit message).\n>\n> I'm arguing that they are not universal enough to be defaults.\n\nAnd yet everyone else that replied is fine with them.\n\n> We already have files for Emacs and VS Code, and those live properly in\n> contrib, along with code for Thunderbird and alternative build systems.\n> If we're treating this proposal like existing code, it belongs in\n> contrib.\n\nAnd yet we have .editorconfig, .clang-format, and .tsan-suppressions,\nwhich don't seem to be hurting anybody.\n\n> The .editorconfig file, on the other hand, doesn't express defaults. It\n> expresses only project standards and doesn't specify any other settings.\n\nFine.\n\nThe .vimrc file doesn't express defaults. It expresses project standards.\n\nThere. Now conceptually they are the same.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412225","messageId":"X9gT57SAHzGm3ET2@coredump.intra.peff.net","threadId":"54802","inReplyTo":"X9Lf1p++YktzZMWe@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-12-15T01:39:51Z","receivedAt":"2020-12-15T01:40:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 11, 2020 at 02:56:22AM +0000, brian m. carlson wrote:\n\n> > > * We should not ship editor-specific files in the main directory of the\n> > > repository.\n> > \n> > Why not?\n> \n> Best practices indicate that we don't check in files which are specific\n> to a developer. Anything that controls the specific editor people use\n> is by definition specific to the developer. Checking in these files\n> leads to conflicts over which settings to apply and whose settings are\n> better when they could just be avoided.\n\nI think that's a good general policy, but it's not unreasonable to\nhelp people make configure some widely used tools. The key things to me\nare:\n\n - we should do so at the most general level possible. I agree that\n .editorconfig is the right level for features it supports. But\n there are bits being suggested here that I think it does not (like\n how to indent case labels).\n\n We also have .clang-format, for which there's a vim plugin (but I've\n not used it, nor editorconfig, myself). It seems like it may support\n more options.\n\n - people who use the editor config take responsibility for maintaining\n it, and nobody else needs to care. E.g., I'd expect editorconfig to\n more of a source of truth than any vim config, and if there's a\n conflict for people who care about vim to sort it out (and not\n somebody who touched .editorconfig).\n\n - it doesn't suggest any actions that might be bad practices. I agree\n that the instructions for auto-loading this .vimrc are more\n complicated than necessary and might have security implications.\n Carrying a file in contrib/vim that says \"copy this to ~/.vim/foo\"\n or even \"copy these lines to your ~/.vimrc\" seems a lot safer. And\n it makes it easier for people who prefer to adapt the config to\n their own setup.\n\nSo I'm not opposed to carrying some vim config, but I think it's best to\nfocus on simplicity and providing human-readable instructions, rather\nthan ad-hoc plugin infrastructure.\n\n-Peff\n"},{"id":"412239","messageId":"5fd8279ce0696_d7c482087@natae.notmuch","threadId":"54802","inReplyTo":"X9gT57SAHzGm3ET2@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-15T03:03:56Z","receivedAt":"2020-12-15T03:35:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, Dec 11, 2020 at 02:56:22AM +0000, brian m. carlson wrote:\n\n> - it doesn't suggest any actions that might be bad practices. I agree\n> that the instructions for auto-loading this .vimrc are more\n> complicated than necessary and might have security implications.\n> Carrying a file in contrib/vim that says \"copy this to ~/.vim/foo\"\n> or even \"copy these lines to your ~/.vimrc\" seems a lot safer. And\n> it makes it easier for people who prefer to adapt the config to\n> their own setup.\n> \n> So I'm not opposed to carrying some vim config, but I think it's best to\n> focus on simplicity and providing human-readable instructions, rather\n> than ad-hoc plugin infrastructure.\n\nGenerally I would agree, but do you know what such instructions would look like?\n\nIn particular what instructions would look like for a person that\ncontributes to more than 3 projects with different C code-style.\n\nI can assure they are anything but human-readable.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412242","messageId":"X9hJenCYkwTmxNjA@coredump.intra.peff.net","threadId":"54802","inReplyTo":"5fd8279ce0696_d7c482087@natae.notmuch","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-12-15T05:28:26Z","receivedAt":"2020-12-15T05:30:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 14, 2020 at 09:03:56PM -0600, Felipe Contreras wrote:\n\n> Jeff King wrote:\n> > On Fri, Dec 11, 2020 at 02:56:22AM +0000, brian m. carlson wrote:\n> \n> > - it doesn't suggest any actions that might be bad practices. I agree\n> > that the instructions for auto-loading this .vimrc are more\n> > complicated than necessary and might have security implications.\n> > Carrying a file in contrib/vim that says \"copy this to ~/.vim/foo\"\n> > or even \"copy these lines to your ~/.vimrc\" seems a lot safer. And\n> > it makes it easier for people who prefer to adapt the config to\n> > their own setup.\n> > \n> > So I'm not opposed to carrying some vim config, but I think it's best to\n> > focus on simplicity and providing human-readable instructions, rather\n> > than ad-hoc plugin infrastructure.\n> \n> Generally I would agree, but do you know what such instructions would look like?\n> \n> In particular what instructions would look like for a person that\n> contributes to more than 3 projects with different C code-style.\n> \n> I can assure they are anything but human-readable.\n\nMostly what I'm suggesting is asking the user to copy the settings they\nwant, rather than sourcing a file in the repository that may contain\narbitrary options. So something like:\n\n \" Settings to match Git's style/indentation preferences.\n \"\n \" You can put these straight in your .vimrc if you want to use\n \" them all the time. Or if you want to use them only inside\n \" certain directories, wrap them like this:\n \" if match(getcwd(), \"/path/to/your/git/repo\")\n \" au Filetype c setl ...etc...\n \" endif\n \"\n au FileType c setl ...etc...\n\nThat means they won't automatically pick up new options if they change,\nbut that's the point. They should be inspecting and deciding which\noptions they want to take.\n\nThe conditional above definitely has some flaws. It relies on the\nworking directory rather than the location of the file (which is the\nsame as your plugin; yours is just picking it up implicitly from calling\ngit). And once the autoloaders are set up, I think they'd trigger for\nany C file, even outside the repository directory.\n\nIdeally we'd combine the autoloader for BufRead and FileType, but it\nseems non-trivial to do so. I think:\n\n au BufNewFile,BufRead /path/to/git/* if &filetype == \"c\" | setl ... | endif\n\nworks, though it's a little clunky, as each line would need to repeat\nit. There might be a better way. I'm not that familiar with doing\ntricky things with vim's autoloading. But my point is mostly that the\nvalue in the information is saying \"here are some useful vim settings\nyou might want to use\". I don't think we need to solve \"here's how to\ntrigger some settings for some directories\" for everyone. We should let\nthem integrate the settings as they see fit.\n\n-Peff\n"},{"id":"412245","messageId":"5fd85e2eeab1a_d7c48208f6@natae.notmuch","threadId":"54802","inReplyTo":"X9hJenCYkwTmxNjA@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] Add project-wide .vimrc configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-15T06:56:46Z","receivedAt":"2020-12-15T06:58:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n\n> Ideally we'd combine the autoloader for BufRead and FileType, but it\n> seems non-trivial to do so. I think:\n> \n> au BufNewFile,BufRead /path/to/git/* if &filetype == \"c\" | setl ... | endif\n> \n> works, though it's a little clunky, as each line would need to repeat\n> it.\n\nYeah, that works, *temporarily*. If the user has configured\n~/.vim/after/ftplugin/c.vim, that would override those autocommand\nsettings when the file is reloaded. Which is precisely why the above is\nnot recommended.\n\n> I don't think we need to solve \"here's how to trigger some settings\n> for some directories\" for everyone. We should let them integrate the\n> settings as they see fit.\n\nYeah. But how?\n\nI already explored this at dept, and I arrived at only one sensible\noption.\n\n-- \nFelipe Contreras\n"}]}