[vim/vim] Add syntax highlight to ENV files (PR #19260)
DuckAfire
Add a simple syntax highlight to files named as:
*.env{rc,}; and.env{rc,}.*.
Note
File type name is env.
Tip
Examples:
.env.examplebackup.env000.envrc
It covers the follow items:
- Fields (all texts they follow the match:
/^\h\(\w\|\.\)*/); - Comments (lines started with
#):- To do tags (
CAUNTION,NOTE,TODO,WARN,WARNING), - Titles; and
- To do tags (
- Values (strings delimited by
=, and end of the line).
Note
I did not use the "classic To do tags" because I think it does not fit into this context.
The main objective of this PR is to improve the syntax beauty*, code legibility,
and syntax extensibility**.
Note
- * Now I used the correct word (see commit:
7ebf6a7a7189d2be7562c9da70f2c24ecdc9535b). - ** Even though there is not many what to extend now, but it can change a day).
Below there is an example code, copy it, and run the syntax script to see how it works.
# Generic comment # TODO: do something to improve this syntax. # FOO: based in VimScript "titles". foo = bar foo.example = # Indentation is not recommended by # this syntax highlight # No-recommended comment position bar = 0 bar.example =
When I was making this, I’m a bit confused whether I need to add .env extension to
ft_from_ext or not, because there is no about .env there, even it is a valid
extension (without self syntax). So, for now, I do not added it.
Note
My English is a little bad, so they can have some gramatical errors here and in my
commits messages - I'm trying to improve it daily.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19260
Commit Summary
- 7ebf6a7 Add syntax highlight to environment (`.env`) files:
- 79f7683 Add `autocmd` rule to enable ENV syntax:
File Changes
(2 files)
- M runtime/filetype.vim (5)
- A runtime/syntax/env.vim (30)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
DuckAfire
duckafire left a comment (vim/vim#19260)I think I undestand what it is wrong, but I do not have certain of how to fix it. Because of this I just will wait for the professionals.
Tip
The main is below:
./src/testdir/runtest.vim:636
└── ./src/testdir/runtest.vim:312
└── ./src/testdir/test_filetype.vim:1046
└── ./src/testdir/test_filetype.vim:1021
From test_filetype.vim:
Found errors in Test_filetype_detection():
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[636]..function RunTheTest[63]..Test_filetype_detection[8]..<SNR>8_CheckItems line 12: cannot edit ".env": Vim:E492: Not an editor command: .env{rc,}{.*,} setf env
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[636]..function RunTheTest[63]..Test_filetype_detection[8]..<SNR>8_CheckItems line 18: with file name: .env: Expected 'sh' but got ''
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[636]..function RunTheTest[63]..Test_filetype_detection[8]..<SNR>8_CheckItems line 12: cannot edit ".envrc": Vim:E492: Not an editor command: .env{rc,}{.*,} setf env
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[636]..function RunTheTest[63]..Test_filetype_detection[8]..<SNR>8_CheckItems line 18: with file name: .envrc: Expected 'sh' but got ''
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
@zeertzjq commented on this pull request.
> @@ -1411,6 +1411,9 @@ au BufNewFile,BufRead drac.* call s:StarSetf('dracula')
" Execline (s6) scripts
au BufNewFile,BufRead s6-* call s:StarSetf('execline')
+" Env
+au BufNewFile,BufRead *.env{rc,} .env{rc,}{.*,} setf env
⬇️ Suggested change
-au BufNewFile,BufRead *.env{rc,} .env{rc,}{.*,} setf env
+au BufNewFile,BufRead *.env{rc,},.env{rc,}{.*,} setf env
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
DuckAfire
@duckafire pushed 1 commit.
- 532281a Fix missing comma:
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
DuckAfire
@duckafire pushed 1 commit.
- 22d3a76 Remove unused variable (`g:main_syntax`):
You are receiving this because you are subscribed to this thread.
DuckAfire
@duckafire pushed 1 commit.
- 6081652 Add ENV files to "filetypes validator":
You are receiving this because you are subscribed to this thread.
DuckAfire
duckafire left a comment (vim/vim#19260)I understand what is wrong, but I do not know what causes these problems.
I think I did not edit nothing related with "server state".
# Summary
...WaitForAssert[2]..<SNR>4_WaitForCommon[11]..<lambda>10 line 1: Expected 'n' but got 'i'
...WaitForAssert[2]..<SNR>4_WaitForCommon[11]..<lambda>11 line 1: Expected '13' but got '14'
...WaitForAssert[2]..<SNR>4_WaitForCommon[11]..<lambda>12 line 1: Expected 'dead' but got 'run'
...Test_client_server_stopinsert line 36: Server did not exit
Tip
See ./src/testdir/test_clientserver.vim, lines: 233; 234; and 238.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns requested changes on this pull request.
Thanks for the PR. However, I'm not sure it's safe to restrict these files to simple parameter definitions, let's see what others think.
> @@ -0,0 +1,27 @@ +" Vim syntax file +" Language: env +" Maintainer: DuckAfire <duck...@gmail.com> +" Last Change: 2026 Jan 27 +" Version: 1 +" Changelog: +" 0. Create syntax file. +" 1. Remove unused variable (g:main_syntax). + +if exists("b:current_syntax") + finish
The de facto standard indent for Vim script is 2 spaces.
> @@ -0,0 +1,27 @@ +" Vim syntax file +" Language: env +" Maintainer: DuckAfire <duck...@gmail.com> +" Last Change: 2026 Jan 27 +" Version: 1 +" Changelog: +" 0. Create syntax file. +" 1. Remove unused variable (g:main_syntax). + +if exists("b:current_syntax") + finish +endif + +sy match envField nextgroup=envValue /^\h\(\w\|\.\)*/⬇️ Suggested change
-sy match envField nextgroup=envValue /^\h\(\w\|\.\)*/ +syn match envField nextgroup=envValue /^\h\%(\w\|\.\)*/
The difference will be negligible in this case but \%(...\) is generally preferred when the sub-expression (capturing group) is not referenced later in the pattern with backreferences as it's a little bit faster.
While :sy is the shortest abbreviation it's almost never used, :syn is the normal spelling.
> +" Maintainer: DuckAfire <duck...@gmail.com> +" Last Change: 2026 Jan 27 +" Version: 1 +" Changelog: +" 0. Create syntax file. +" 1. Remove unused variable (g:main_syntax). + +if exists("b:current_syntax") + finish +endif + +sy match envField nextgroup=envValue /^\h\(\w\|\.\)*/ +sy region envValue matchgroup=Operator start=/=/ end=/$/ +sy match envComment contains=envTodo,envTitles /^#.*$/ +sy keyword envTodo contained CAUTION NOTE TODO WARN WARNING +sy match envTitles contained /#\s*\zs[A-Z0-9][A-Z0-9 ]*:/⬇️ Suggested change
-sy match envTitles contained /#\s*\zs[A-Z0-9][A-Z0-9 ]*:/ +sy match envTitle contained /^\s*#\s*\zs[A-Z0-9][A-Z0-9 ]*:/
This will avoid BAR: being matched in # FOO: ... # BAR: ..., assuming that's the intent.
Usually, syntax group names use the singular form envTitle rather than envTitle.
> @@ -1028,7 +1028,7 @@ au BufNewFile,BufRead *.decl,*.dcl,*.dec
" NOTE: Patterns ending in a star are further down, these have lower priority.
au BufNewFile,BufRead .bashrc,bashrc,bash.bashrc,.bash[_-]profile,.bash[_-]logout,.bash[_-]aliases,.bash[_-]history,bash-fc[-.],*.ebuild,*.bash,*.eclass,PKGBUILD,*.bats,*.cygport call dist#ft#SetFileTypeSH("bash")
au BufNewFile,BufRead .kshrc,*.ksh call dist#ft#SetFileTypeSH("ksh")
-au BufNewFile,BufRead */etc/profile,.profile,*.sh,*.env{rc,} call dist#ft#SetFileTypeSH(getline(1))
+au BufNewFile,BufRead */etc/profile,.profile,*.sh call dist#ft#SetFileTypeSH(getline(1))
.envrc files support full shell syntax, at least when used by direnv so I don't think it should be removed.
.env could be anything, are we sure it's safe to restrict it to parameter definitions?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
DuckAfire
@duckafire pushed 1 commit.
- 5a87021 Apply changes required by github@dkearns:
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19260)I am confused, why is this line there:
au BufNewFile,BufRead */etc/profile,.profile,*.sh,*.envrc,.envrc.* call dist#ft#SetFileTypeSH(getline(1))
Doesn't this set the filetype to sh? Is that actually being used for any shell file? It should go to env filetype as well, no? I also think that the extension .env should go to autoload/dist/ft.vim to ft_from_ext instead.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
DuckAfire
duckafire left a comment (vim/vim#19260)I am confused, why is this line there:
au BufNewFile,BufRead */etc/profile,.profile,*.sh,*.envrc,.envrc.* call dist#ft#SetFileTypeSH(getline(1))Doesn't this set the filetype to
sh? Is that actually being used for any shell file? It should go to env filetype as well, no? I also think that the extension.envshould go toautoload/dist/ft.vimtoft_from_extinstead.
Based on what I read and understood (from source code):
- This line is used to call functions used to search possible shebangs (in SH Flavors) and "exec" commands hidden in comments (in shell-like files). The file type is set based in what is found (default is SH).
Based in what I know, ENV is not a SH file, it is a file to declarate environment variables. This means support of other resources of SH (keywords; operators; ...) does not always supported.
Note
Before this PR, ENV files use SH syntax highlight.
Why do you think ENV to be "moved"?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
DuckAfire
duckafire left a comment (vim/vim#19260)Thanks for the PR. However, I'm not sure it's safe to restrict these files to simple parameter definitions, let's see what others think.
Linguists supports it as a dedicated filetype: https://github.com/github-linguist/linguist/blob/e51c227048a02a8a1b0fae6e72214e7c5f327c73/lib/linguist/languages.yml#L1762-L1784
Dotenv: type: data color: "#e5d559" extensions: - ".env" filenames: - ".env" - ".env.ci" - ".env.dev" - ".env.development" - ".env.development.local" - ".env.example" - ".env.local" - ".env.prod" - ".env.production" - ".env.sample" - ".env.staging" - ".env.template" - ".env.test" - ".env.testing" tm_scope: source.dotenv ace_mode: text language_id: 111148035
Sorry for the errors related with code conventions, I am new here.
About the ENVRC, I did not know this file, nor its purpose. I throght it was legacy name to environment files, or a name low used.
I gave back ENVRC to the place where they were. I also improved the its match.
Do you think files names (.env.example; env.dev; ...) have to be defined to hidden files instead wildcard (.env.*)?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#19260)I am confused, why is this line there:
au BufNewFile,BufRead */etc/profile,.profile,*.sh,*.envrc,.envrc.* call dist#ft#SetFileTypeSH(getline(1))Doesn't this set the filetype to
sh? Is that actually being used for any shell file
That is the correct filetype for direnv rc files and .envrc, foo.envrc, .envrc.foo and foo.envrc.bar variants are all used.
It should go to env filetype as well, no? I also think that the extension
.envshould go toautoload/dist/ft.vimtoft_from_extinstead.
The change adding ft_from_ext wasn't really fully cooked so whether to split up the various patterns is a bit confusing. .envrc could be moved to ft_from_name and the *.envrc variant to ft_from_ext. However, there is also the less common *.envrc.* variant that's not currently matched.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19260)Thanks. The thing that threw me off was that this PR is about highlighting ENV files and did not talk about envrc files. We should separate those two things. into at least separate commits. One commits adds the .env filetype detection and uses the simple environment variable highlighting and the other commit just adds detection for .envrc.* as shell filetype.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
DuckAfire
duckafire left a comment (vim/vim#19260)Thanks. The thing that threw me off was that this PR is about highlighting ENV files and did not talk about envrc files. We should separate those two things. into at least separate commits. One commits adds the
.envfiletype detection and uses the simple environment variable highlighting and the other commit just adds detection for.envrc.*as shell filetype.
As said before, I just change ENVRC match because I thought I was a variation of ENV files.
After to be warnied about this, I putted it again in its original place - together with small improvements in its match pattern.
You are right, it would have been better to divide the fixing of the script syntax, and the eddition of the ENVRC match, I will take this into consideration in possible future PRs.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19260)Alright, the one thing that keeps me from including this right now is that it’s slightly backwards-incompatible: .env files would get their own filetype and no longer be handled as sh. After the release, I can handle any potential backlash a bit better 🙂
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19260)Thanks. I am including this now
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.