I use winget to install and update a lot of applications, also Vim. winget does then download a Vim-specific installer and starts it.
For a while now the Windows installer of Vim removes the entry from the PATH variable. This is the case since the location changed from c:\Programs\Vim to c:\Users\<user>\AppData\Local\Programs\Vim.
The directory where the binaries are installed must get an entry in the PATH variable otherwise vim.exe is not usable in a cmd, wt or any other terminal emulator window.
There are two PATH variables: a user specific one and a global one which are later merged. The user specific one is indeed modified by the installer. But the result is that an existing entry is removed and a new one is not added. Note: in case of an update you have already an existing entry and it points exactly to that directory. After the installer has finished and I reopened the terminal window to get a fresh environment vim.exe is not in PATH and I must handle the PATH variable manually, again and again.
I would expect the following:
PATH variable the installer should add onePATH variable and it points to
vim.exe is located then it should be unmodified9.2.1119
OS: Windows 11 Pro 25H2
terminal: hyper.exe, wt.exe, conemu.exe, cmd.exe (doesn't matter)
shell: cmd.exe
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Off the top of my head, I wonder if this isn’t due to your path’s being more than 1024 characters. I’ve seen other installers (HerokuCLI) explicitly call this out and decline to add to the path.
But I’ve noticed it as well. I’m just accustomed to re-adding I suppose, because I don’t recall that winget’s ever adding a Vim path. Removing the old path is new.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
No, my entire merged PATH variable is just 1015 bytes, including the Vim entry. Still a lot, probably I will shorten it, but it's still under the limit.
BTW: Because of that long PATH I like to start many cli apps using a symbolic link. I have a directory in PATH where I have just a number of such links. And these links point to binaries somewhere else which are not in PATH, so PATH isn't growing again and again. But with Vim it's complicated: when you make a symbolic link onto vim.exe and start the link Vim will come up rather slowly and it shows then a black screen with "press ENTER or type command to continue". After I press ENTER it works but this start is annoying.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I had this happened to me and my PATH is way way over whatever reasonable limit anyone could think of. I switched winget for chocolatey to keep vim available in wezterm or whatever terminal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I had this happened to me and my PATH is way way over whatever reasonable limit anyone could think of. I switched winget for chocolatey to keep vim available in wezterm or whatever terminal.
Yeah, but it can't be a winget problem since winget doesn't manipulate the PATH variable. winget doesn't even know where a specific application is installed and what environment settings are needed, it's (like chocolatey) just a wrapper for application specific installers like gvim-9.x.xxxx-x64.exe. OK, winget calls the installer as a sub process and provides him an environment which is normally a copy of it's own environment. Maybe chocolatey does it in a different way (can't imagine that).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Chocolatey has the binaries in C:\tools\vim\vim92 and what the terminal is actually running is a script at C:\Windows\vim.bat that eventually runs the vim.exe inside the former directory mentioned.
Besides, choco info vim explains that it uses the ZIP build, so its not using the Windows installer.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Besides,
choco info vimexplains that it uses the ZIP build, so its not using the Windows installer.
Oh, interesting, didn't know that. That changes of course a lot.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()