Get started

In order to install Hop, you need to decide which plugin manager you want to use. In this wiki, we will be using packer.

  use {
    'phaazon/hop.nvim',
    branch = 'v2',
    config = function()
      require'hop'.setup {}
    end
  }

Pinning

It is highly recommended that you pin a version of Hop. What pinning means is to ensure that Hop will stay at a given version or a range of versions. That will prevent accidental updates of Hop to unstable versions. By default, most Neovim package managers will default to the master or main branches of the plugins, which is okay if you want to test something, but for a production and solid environment, this is not ideal, because plugin authors usually push unstable changes (“nightly”) to those branches.

As a rule of thumb, you should always assume that master / main are unstable and might break your configuration.

For that reason, Hop follows SemVer. It is a very simple standard used worldwide by millions of developers with many different package managers. Applied to Neovim and package managers, Hop implements semantic versioning as follows:

Major releases are represented by branches with the following format: vM, where M is a major version number. For instance, v1 and v2 are both valid major releases. v0 is considered unstable.
Minor releases are represented by branches with the following format: vM.N where M is a major version number and N is the minor version number. For instance, v1.3 and v2.0 are both valid minor releases.
Patch releases are represented by tags with the following format: vM.N.P, where M is a major version number, N is the minor version number and P is the patch version number. For instance, v1.3.1 and v2.0.0 are both valid patch releases.

When you pin a given version, Hop will accept updates for any increment of the version numbers underneath the one you pinned. For instance, if you pin a minor release, like v1.1, all patch releases of v1.1 can be installed, so if a new one is released, you will get it when updating. If you pin v2, you will got all new minor and patch releases. If you pin a patch release, since there is nothing else under a patch version, you will “freeze” Hop to that release. That is slightly different from how some package managers work, where they allow you to provide a minimum version number and allow updates up to the parent version number, i.e. ^v1.2.3 will allow v1.2.4 to be installed in those systems, such as ^v1.2 which will allow v1.3. That is not the case with systems like packer, so be careful about that.

How to use pinning with `packer`

With packer, you can pin Hop to a major, minor or patch release by using branch for major and minor releases, and tag for patch releases.

Some examples:

  -- pin Hop to follow the v2 major release; this will allow all releases of the form v2.*.*
  use {
    'phaazon/hop.nvim',
    branch = 'v2',
    config = function()
      require'hop'.setup {}
    end
  }

  -- pin Hop to follow the v1.3 minor release; this will allow all releases of the form v1.3.*
  use {
    'phaazon/hop.nvim',
    branch = 'v1.3',
    config = function()
      require'hop'.setup {}
    end
  }

  -- pin Hop to the v1.2.0 patch release; this will only allow v1.2.0
  use {
    'phaazon/hop.nvim',
    tag = 'v1.2.0',
    config = function()
      require'hop'.setup {}
    end
  }

Why pinning?

The Neovim plugin ecosystem is flawed by plugins that push to master and break the plugins, because Lua APIs are too weak to catch all the problems at once (and unit / integration testing of plugins is hard). If you care about the stability of your system, you should follow semantic versioning (as you probably do with other languages you use anyway). The recommended way to use Hop is to pin a major release, or minor release if you do not want to get new features. Pinning a patch release is probably never wanted, unless you have found a massive bug in a minor release (and then major as well), which forces you to pin a patch release.