Overrides

Last updated: Sep 23rd, 2019

Introduction

One of the great things about Sublime Text is how customizable it is. Along with things like customizing your settings and key bindings, you can add almost any functionality you might want. Using PackageControl you can find and install a vast array of third party packages to add features that make Sublime Text uniquely your own.

Sometimes though, a package does not quite meet your needs and a little tweaking is in order to get things just right. Thankfully, Sublime is open enough to allow you to easily tinker with installed packages to get things running the way you like through the use of package overrides.

Although powerful, there are some common pitfalls that you might fall into while using them. On it's own, Sublime doesn't provide any direct support for working with your package overrides at all, leaving you to manage them yourself. Enter OverrideAudit.

OverrideAudit strives to fill in a missing Sublime Text functionality gap by helping you to manage your overrides. With it you can track the overrides you have made and see how they're different from the file that they are replacing. It can help you to edit them when you need to make changes or get rid of them when you no longer need them.

Most importantly, it can help to keep you informed when there are potential problems that you should take a look at, to help you from falling into those nasty pitfalls.

What are Overrides

In the simplest terms, an override is a file or (more rarely) a complete package that you create to be used as a modification to an existing package. Instead of manually unpacking, editing and repackaging a package file, Sublime Text will treat your override file as if it was contained inside of the target package. This saves you the hassle of editing the contents of the package directly.

Overrides are an important aspect to package customization because both Sublime Text and Package Control will replace a package as a whole when performing updates, thus discarding your changes. You could get around this by disabling updates, but this leaves you potentially using older, more outdated packages. Making changes directly to a package file is a recipe for confusion and is thus not a good idea.

Creating an Override

In order to override files in a package, that package must be installed as a sublime-package file. This is how all packages that ship with Sublime itself are installed, as well as most packages installed by Package Control.

As noted below, there are two different styles of overrides that you can create in Sublime Text, a simple override and a complete override. By far the most common type for most users is a simple override.

The easiest way to create a simple override is by using OverrideAudit's Create Override command to select the resource you want to override. If you've used View Package File from the Command Palette, you can use the Override Current Resource command instead.

Common Pitfalls

Sublime loads override files transparently and silently; there is no warning or message generated that lets you know that part of a package has been overridden.

Now imagine that behind the scenes, the author of such a package fixes some bugs and releases a new version. After your copy of the package is updated, you're left with an override file that is still based on the older version of the package; your override has expired, but you don't know it.

The best case here is that the file you are overriding was not modified at all, while the worst case is that because your file is too old, the package does not work any longer, or may not even fully load. These can be very tricky problems to diagnose if you're not aware of what's going on.

Overrides are very powerful and necessary; many useful customizations that users want to make to get packages to work to their liking can only be performed by creating an override. Overrides are safe as long as you know that they exist and track what's going on.

OverrideAudit is designed to help keep you informed of potential problems, taking the worry out of customizing Sublime to your heart's content so that you're free to get on with your work.

Packages

In Sublime Text, a Package is simply a named collection of resource files that are grouped together to make some kind of modification or extension to Sublime. There are a number of different types of resource files that a package can include, ranging from as simple as an additional key bindings all the way to custom python code for implementing entirely new features.

Most of the functionality that is provided by default in Sublime is provided by a set of Default Packages that ship with Sublime itself, and that list of packages is augmented by third party packages that you choose to install.

Regardless of their content, packages in Sublime text can be installed in two different ways, Packed and Unpacked.

Packed Packages

A Packed package is a collection of files grouped together into a single archive file, which makes them easier to share and install. This is important for mechanisms such as Package Control, which help to install new packages and keep them up to date, and is also the format in which the packages that ship with Sublime (Shipped Packages) are distributed.

A Packed package is actually a zip file with the extension changed to sublime-package. This type of package is used by Sublime for the default packages that it ships with, and is the preferred method for package installation via Package Control as well.

Since a package upgrade will replace the entire package as a whole, it is unwise to make modifications to a package by modifying it directly, since your changes will be lost on package update.

Packages you have installed in this manner are placed inside of the Installed Packages folder, which is stored in a location that is specific to you. You can find this location by selecting the Preferences: Browse Packages command from the command palette and then going up a level to the parent folder.

Shipped Packages are not stored in this location, since a single copy of them is used as the base for all users on the current computer.

Unpacked Packages

Occasionally it is not possible for a package to be installed in a packed format. For example, it may contain platform specific libraries or binaries that cannot be accessed while they are inside of the packed package file.

For packages such as this, Sublime also supports a package installation method known as an Unpacked package. This style of package is stored as a collection of files in a folder inside of the Packages folder.

As with the Installed Packages folder, the location of this folder is specific to you. You can find this location by selecting the Preferences: Browse Packages command from the command palette.

Most notably, all of your customized settings and key bindings are stored in an unpacked package named User inside of this folder.

Override Types

There are two main types of overrides in Sublime Text, Simple and Complete, with the Simple override being the most common type of override for most users.

Regardless of the type of an override, it still shares the same set of pitfalls, in that Sublime uses them unconditionally without telling you that it is doing so or that you might need to update them.

Simple Override

A Simple override is the most common type of override, and allows you to override the complete contents of a single file within a Packed package without modifying the package itself. This ensures that your changes will remain in place even if the package you are overriding is updated by its author.

To create such an override, create an Unpacked folder for the package inside the Packages folder, extract the file you wish to modify from the sublime-package file into that folder, and change it as desired.

While loading the sublime-package file, Sublime will ignore the file from the package file and use the unpacked file instead. This is transparent to you; sublime doesn't provide any indication that an override file is being used.

This works not only for default packages, but also user installed packages and packages which have been completely overrridden (see below).

Complete Override

A Complete override is less common and allows you to override the entire contents of one of the packages that ship with Sublime all at once. The most common use case for this is to update one of the shipped packages with a newer version, allowing you to pick up bug fixes in the default packages in between Sublime releases.

To create such an override, you place a sublime-package file with the same name as one of the default packed in the Installed Packages folder. When loading packages, when Sublime encounters such a package file, it will completely ignore the shipped version and use the overridden version instead.

Like a Simple override, a complete override is transparent to you.

Expired Override

As outlined in the different types of overrides above, when an override is in place Sublime uses it automatically, with no warnings or indications that it is happening. If the source package is updated, your override will remain in effect even though it is possible that the underlying file has been modified.

In this specific case, we say that this override has Expired; the source file is newer than the override file itself, and so some changes may have been made that you should include into your override. Detecting this situation and helping you deal with it is one of the main reasons that OverrideAudit was created.

In the case of a Simple override, the override is considered to be expired if the time stamp of the file inside of the sublime-package file is newer than the last modification time of the override file. For a Complete override, the time stamps of the two package files themselves are compared.

Warning:

The format of a zip file includes a modification time for each file in the archive, but due to technical limitations, this time does not include any time zone information.

For this reason, the detection of an expired Simple override is not completely foolproof, although it is unlikely to be a problem in most cases.

Unknown Override

A file in an Unpacked package is only considered to be an override if an identically named file also exists in the Packed version of that package; that is, such a file is overriding the content of the package.

It's possible for files to appear in the Unpacked version of a package without also existing in the Packed version as well. In this case Sublime still treats that file as if it was a part of the package, but technically speaking it's not an override because it's not overriding anything.

OverrideAudit refers to files of this type as Unknown Overrides to create a distinction between them and actual override files. This distinction is important because OverrideAudit has no way to know why such a file might exist.

Potential reasons for these sort of files range from you manually adding extra package files on purpose (say to extend the functionality of a package) to the sublime-package version of the file being updated to a new version that no longer has such a file within it.

Although the first case is intentional, the second may not be and could be an indication that a file that used to be overridden is no longer present, which could mean that such a file is no longer needed or that its presence will have unforeseen consequences on the operation of the package.

Note:

The ignore_unknown_overrides setting controls whether unknown overrides will be displayed by the Override Report and Bulk Diff Report will display this type of file or not.

The default is to display these files as an extra warning to you, but you can disable this if desired.