Windows file associations

Although the Vim installer gives you options to create right-click "edit with Vim" options, it is convenient to be able to simply double-click on a file to have it open in Vim. This "double-click to open" is commonly referred to as a "file association" and is fairly easy to set up in Microsoft Windows. You can use the "Open With..." menu in Windows to set up a basic association, but that will not allow you to specify any command-line arguments to Vim, such as --remote-silent to open with an existing Vim instance. In order to fully specify the action to take when double-clicking a file, Windows provides the ftype and assoc command-line tools.

To use, simply open a Windows command prompt and type something like the following:

Note: If the above commands are entered in a batch file, the percent sign must be escaped (replace "%1" with "%%1").

This particular command sequence will set up Windows to open any files with a .php extension in an existing gvim window (or it will open new gvim window if there is no already opened gvim window).

In general, the assoc command is used to associate a given file extension with a filetype. The ftype command is used to tell Windows what to do to open files of a given file type. You can associate any number of file extensions with a given filetype, which makes it easy to set up a single action for similar types of files. For example, the following will treat any files with extensions .c, .h, .pl, or .py as "sourcecode", which it will launch in Vim as we did with PHPFile above:

Contents

Both the ftype and assoc commands work by creating entries in a specific registry location which Windows will check for various actions taken on a file. The easiest and safest way to create these entries is to use the command-line tools, but it is possible to create them by hand.

assoc .c=sourcecode will create a registry key at HKEY_CLASSES_ROOT\.c that has a (Default) value of sourcecode. When you double-click on a .c file, Windows will see this key and look for another key to figure out what to do with a sourcecode file.

ftype sourcecode="C:\Program Files\Vim\vim72\gvim.exe" "%1" will set up another registry entry, in HKEY_CLASSES_ROOT\sourcecode\Shell\Open\command with (Default) value of "C:\Program Files\Vim\vim72\gvim.exe" "%1". This entry could do with more inspection.

Consider the .html file extension. For most users, it would not make sense to open a .html file in Vim when double-clicking the file. Most users would want the file to open in a web browser when double-clicking, but being able to automatically edit the file in Vim when modifying the file would be a nice thing to be able to do. This is where the registry entry created by ftype comes in.

WARNING: Editing your Windows registry may cause unintended side effects that render your system inoperable. Although this tip has worked in the past for some people, there is no guarantee that it will work for you. Use with caution, and at your own risk.

There are no easy command-line or GUI tools to do this, but you can set up other actions, such as "edit", in the same registry area that ftype uses. Simply replace the "open" portion of the registry key path with the desired action (in this case, "edit"). For example, assume that .html files have been associated with a filetype called htmlfile. Then, to keep the existing double-click action in place, but add Vim as the "edit" action, give the following registry key a (Default) value of "C:\Program Files\Vim\vim72\gvim.exe" "%1": HKEY_CLASSES_ROOT\htmlfile\Shell\Edit\command

Registry entry for the "edit" action

Note: in Windows XP, there is a GUI for doing this, accessible through the "Folder Options" dialog.

Now, you can double-click on a .html file to open it in your web browser as normal. But you can also right-click on the file, and choose "Edit" from the context menu. This will open the file in gvim.

Unfortunately, all of the methods mentioned above apply your file associations in an area of the registry used by every user account in your Windows installation. This means that if you are on a multi-user system, and you are the only user using Vim, other people will get very annoyed if you use these tools to make files launch in Vim.

Luckily, although Windows does not provide a GUI or even easy command-line tools to edit or change it, Windows 2000 and above provide a place in the registry that can be used to store user-specific file associations. This place is HKEY_CURRENT_USER\Software\Classes. Creating a file association here uses two steps, which duplicate what the assoc and ftype commands do in their registry area. For an example, we will associate the ".c" extension to the "sourcecode" filetype, and then tell Windows to launch anything in the "sourcecode" filetype in gvim version 7.2, opening the file in a new tab. It should be easy to adjust this as desired.

WARNING: Editing your Windows registry may cause unintended side effects that render your system inoperable. Although this tip has worked in the past for some people, there is no guarantee that it will work for you. Use with caution, and at your own risk.

To do this, you need only create a registry key with the name of the file extension desired and a default value of the filetype you want to associate with it. For our example, you would create the key, HKEY_CURRENT_USER\Software\Classes\.c (using regedit or the command-line "reg add" command). In regedit, you can see a (Default) value for this key after creating it. Set the value to sourcecode.

The next step is to tell Windows what to do with your new filetype, just like the ftype command.

First, create the key HKEY_CURRENT_USER\Software\Classes\sourcecode\shell\open\command. This key will also have a (Default) value, which you need to set to the program used to open files of this type. For example, you could set it to "C:\Program Files\Vim\vim72\gvim.exe" --remote-tab-silent "%1" to open .c files (and other sourcecode typed files) in a new tab in the default gvim.

Registry entry for filetype action

Just as we explained above, you can specify other actions to take besides opening on a double-click, simply by replacing "open" with the appropriate action in the registry key path.

Windows does provide a command-line utility for editing the registry: reg add. You can use this tool from a CMD prompt, but it is probably more useful to create a batch file containing commands to set all your desired file associations.

You need to escape double-quote characters with a backslash. To set the (Default) value we need, provide an empty string as the value name using /v "". In a batch file, you also need to escape the '%' character with a second '%' character. With this in mind, the following lines in a batch file will set up the file association given in our example above:

For user-specific associations, should also mention creating and merging a reg file, which is probably easier.

The usual Windows escape character is "^". Why do we need to escape quotes with a backslash in the "reg add" command? This seems weird, but it works.

You need to escape a double quote (and a backslash) in a ref file because that is how the syntax was designed. It allows RegEdit to differentiate between these characters entered as data vs as entered as delimiters. Same as the percent sign in batch files.
ArtK Oct 14, 2014

Sure, I understand the concept of escaping. But why is the escape character '\' here? In .bat files you use ^ to escape anything, and backslash normally doesn't do anything special. So what's special about "reg add"? --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

Whoa! Lots of inaccurate and misleading statements here. Some corrections and clarifications:

I don't think anything is actually inaccurate here, see my responses below. Maybe we need to retool which portions get emphasis. Please let us know what you think. --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

File association definitions are are stored under registry keys in two (virtual) hives: HKLM and HKU. Specifically, HKLM\Software\Classes\ and HKCU\Software\Classes\ plus HKCU\...\FileExts\:

HKLM\Software\Classes\ defines associations for the local machine, i.e., all users (unless overridden by HKCU definitions)

HCR is an alias for HKLM\Software\Classes\. It is not a copy. It is not ambiguous. It is not a merging of anything. It is simply a shorthand way of directly referring to a subset of HKLM (HKLM\Software\Classes\).

Experimentation shows that HCR includes entries for both HKLM and HKCU definitions. I agree it is not a copy...but it certainly seems to be a merging of some kind. Do you know where to find documentation on how this alias works? What happens if you create something here, does it get stored in HKLM or HKCU? --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

Similarly, HKCU is an alias for a subset of HKU (HKU\S-1-5-21-...\) - the currently logged on user account. Again, just a shorthand name. (Each user account has a unique S-1-5-21-... key under HKU so HKCU is unique for each user.)

Good to know. I don't think that's very useful information for this tip, however...I don't think that much detail is needed in knowing how to set up file associations in HKCU. Do you disagree? --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

In addition, HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\ contains all the user account created definitions managed via "Explorer\Tools\Folder Options\File Types". These include, for example, application created entries when you install an app for a single user or when you allow your browser to set itself as the default browser.

OK, good to know. Where does this tie-in to double-clicking to open a file? Is it worth mentioning in this tip? Is there an easy editor or configuration tool for this outside the registry? We should include it if it is useful, especially if it provides an easy alternative to registry hacking. --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

When a file reference is double clicked, Windows first looks in HKCU for any file association definitions for that specific file extent. If and only if no definition exists in HKCU for the requested verb (Open, Edit, Print, etc), does Windows look in HCR for its info.

I don't think HCR works the way you think it does. Right now on my system, in HCR, I have a "sourcecode" entry (with various open/edit verbs defined). "sourcecode" does not exist in HKLM\Software\Classes; here the entries skip right from "SoundRec" to "SPCFile". On the other hand, in HKCU\Software\Classes, "sourcecode" is present. So, obviously HCR includes entries from HKCU\Software\Classes.

On the other hand, in HCR, "sourcecode" is surrounded "SoundRec" and "SPCFile" just like in HKLM\Software\Classes. But HKCU\Software\Classes has "Software" and "stylesheet" surrounding the "sourcecode" entry. Thus, HCR also obviously includes entries from HKLM. HCR is definitely merging the two locations in some fashion. I just don't know the details as to how. --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

Consequently, ASSOC and FTYPE are totally useless for managing user specific file associations. These utilities operate only on HCR keys (and require admin rights to change entries). Also, FTYPE only operates on the command key for the "open" verb (...\shell\open\command\); it cannot set or reset any other verb command key.

Yes, I agree. That's why we have a separate section on #User-specific associations, and also #Associating Vim with other actions. But since most computers probably have only a few users, and this doesn't involve manually hacking the registry, and since alternate verbs are less common than "double-click to open": ftype and assoc are probably good to mention first. Do we need to emphasize that more in the section about ftype and assoc? --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

This is just the tip of the iceberg regarding file associations. The next level is all of the "OpenWith" mechanisms for many-to-one and one-to-many associations. For more info, see SuperUser post[1], do a Google search[2] or browse the registry with RegEdit (if you don't change anything, it is safe to look. Create a check point first to be doubly safe.)

ArtK Oct 14, 2014

This tip is the result of hours of fiddling with the registry and Google searching, and it works. So please don't assume proper searching was not done first. If this were easy, well-documented, or if Windows had a built-in UI, we may not have needed a tip in the first place. I'm sure there is more to the story about file associations, this is only an attempt to document the process SOMEWHERE because it isn't easy to find this information. Especially as it relates to something as user-specific as a preferred text editor.

The top few Google hits for 'Windows "file associations"' all talk about using the GUI tools in Windows to set an "open with" program. This is all well and good, but programs like Vim often need to pass various command-line arguments along with the file to be useful. Can this be done with the "open with" GUIs?

Thanks for the SuperUser link, that gives some good detail, especially about the FileExts area. But you should certainly look into the HKEY_CLASSES_ROOT again, I think you're incorrect there. --Fritzophrenic (talk) 18:30, October 14, 2014 (UTC)

The following is a "for reader's information" comment; not a suggestion that the tip be changed. In classic Microsoft style, using HKEY_CLASSES_ROOT is ambiguous. I do not know the details, but on at least some systems (after Windows 9x), I think the following is correct:

HKEY_LOCAL_MACHINE\Software\Classes : for all users

HKEY_CURRENT_USER\Software\Classes : for interactive user

HKEY_CLASSES_ROOT : merged view of above (and is used by Win9x apps)

I don't know what happens if you write to HKEY_CLASSES_ROOT (which does not exist). Perhaps (like installing some apps), if you are in the Administrators group, you will write to HKLM, otherwise you will write to HKCU. JohnBeckett 08:24, 2 July 2009 (UTC)

This is correct as far as I know. I wanted to include some information about how HKCR is a merged view of HKLM/Software/Classes and HKCU/Software/Classes, but doing so would beg information such as "what happens when I edit an entry that actually exists in HKCU?" etc. From experimentation, it seems that creating new keys in this area will always create it in HKLM (system-wide), and ftype and assoc certainly do that, but I don't really have any documentation of that fact, and I don't know what it will do for limited-privilege accounts. I also don't know what happens when you edit an existing key, but I imagine it will "do the right thing" and keep the original where it was. I don't know this for a fact though. For these reasons, I left out that tidbit. But if we can answer some of these questions, it would be a good thing to include.