# geany-plugins: the Geany plugin collection and its Autotools build

> geany-plugins is a C collection of plugins for the Geany editor, built with Autotools where each plugin is enabled or disabled through its own configure option and any plugin with a missing build dependency is dropped automatically.

**geany/geany-plugins** — The combined Geany Plugins collection

- Repository: https://github.com/geany/geany-plugins
- Website: http://plugins.geany.org/
- Stars: 644 · Forks: 290
- Language: C
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/geany-geany-plugins

## A plugin collection for a small, C based editor

Geany is a small editor and its official plugin collection is where most of its serious features live. The README lists the available plugins as configure options, and the list covers most of what a programmer would reach for: a debugger, version control through geanyvc, code navigation through codenav, symbol lists through scope and the overview plugin, a LaTeX plugin, an LSP plugin, a tree browser, a project organizer and workbench for multiple projects, a spell checker, a Markdown plugin, a pretty printer, an update checker, a web helper and a Vim mode. There is also the long tail: addons, autoclose, automark, a macro plugin, numbered bookmarks, pair tag highlighting, a shift column tool, a table converter, lipsum text insertion, a pastebin plugin and a send mail plugin. The collection is written in C and follows the editor's own plugin interface, which is why it has to be built against a matching Geany.

## The Autotools build, and why autogen.sh only exists in git

Building the collection uses Autotools, and the usage block in the README is the whole install story:
```bash
  ./configure [arguments] or alternatively ./autogen.sh [arguments]
  make
  sudo make install
```
The `./configure` script is what a release package ships with. The `./autogen.sh` alternative only exists if you took the sources from the git repository, because the script is what generates that configure script in the first place, and the README says plainly that it is not included in release packages. Once the script has run, `make` builds the plugins and `sudo make install` puts them where Geany can find them. The README warns that this path configures, builds and installs most of the plugins rather than all of them, which is the first sign that this collection is not a single binary with a single set of requirements.

## A missing dependency silently removes a plugin from the build

This is the detail that catches people. The README says there is some auto-detection in place which automatically disables plugins if there are insufficient build dependencies. Every plugin therefore has a configure option that takes one of three forms: `--enable-<option>=auto`, which is the default and decides based on whether the dependency exists on your system, `--enable-<option>`, which forces the feature on and makes configure fail with an error message if dependencies are missing, and `--disable-<option>`, which turns it off outright. The result is that a build can finish successfully and simply not contain the plugin you expected, for instance because a development package for a debugger or a version control client is missing. If a plugin does not show up in Geany after the install, the configure output is where to look first.

## all-plugins turns a list of options into one decision

Listing every plugin option on the command line is not practical, so the collection provides a special option named all-plugins that changes the default for every plugin at once. The README gives the mechanics: `--enable-all-plugins` forcefully enables all plugins as if each plugin specific option had been passed, and it can be combined with individual options to select a subset without listing everything. Two examples in the documentation show the two ends of that. Passing `--disable-all-plugins` with one `--enable-<option>` gives you exactly one plugin, while `--enable-all-plugins` with `--enable-<option>=auto` gives you everything except the plugins whose dependencies are missing. The example configure invocation in the README is the narrow case:
```bash
  ./configure --enable-geanylua --enable-spellcheck
```
That form forces both plugins on even when their dependencies are missing, which is how you find out whether the dependency is genuinely required.

## Building one plugin directory instead of the whole tree

The build system is recursive Automake, and the README explains what that buys you: after running `./configure`, you can compile each individual plugin by changing into the plugin's directory and running make inside it. Each plugin lives in its own top-level directory, such as debugger/, geanyvc/, lsp/, markdown/ or treebrowser/, so a targeted build is a matter of being in the right directory rather than rebuilding the collection. This matters for two reasons. A developer working on one plugin does not pay for the whole tree, and a user who only needs one feature can produce a single plugin module and install it without the rest. The trade-off is that this per-directory route is undocumented as a supported user path and assumes the configure step has already run, since the generated makefiles come from it.

## Plugin directories and configure option names do not line up

The repository tree and the option list are not a one to one mapping, and that trips people who try to guess a plugin name. The tree holds directories named git-changebar/, pretty-printer/, po/ and keyrecord/, while the option list uses names such as gitchangebar, pretty_printer, pohelper and geanypg, and it lists no option for keyrecord at all. The option name is the one that matters for `./configure`, and it is not always the directory name with the dashes removed. The tree also contains build/, utils/, configure.ac, Makefile.am and the README sources, which are build machinery rather than plugins. If you are scripting a build for a particular machine, read the option list rather than mapping directories to flags.

## Per plugin licences live in COPYING.md

The collection does not carry a single uniform licence. The README points to the COPYING file for individual licence information about the various included plugins, and the repository itself is listed under a custom licence that GitHub cannot classify. The top-level tree confirms the splitwith COPYING.md at the top of the tree. Practical consequence for teams: if you redistribute a plugin binary inside a product, you have to check the licence of that plugin rather than assume one rule applies to the whole collection, and the metadata a package manager shows you for the collection will not answer that question. This is not legal advice, but it is the kind of thing that belongs in a release checklist rather than in a general policy.

## Commits are recent, tagged releases are not

The two signals here point in different directions, so read both. The last push to the repository was on 2026-10-12, which is recent work on the tree. The tagged releases are older: 2.1.0 was tagged on 2025-07-06, 2.0.0 on 2023-10-19 and 1.38.0 on 2021-10-09. So the collection receives changes without producing a new numbered release on a matching schedule, and a distribution that packages by release will lag behind the tree. The homepage at plugins.geany.org is where the project points for the collection itself. For an updater, the practical question is which source you track: the git tree for current plugins, or a release tarball whose configure script is already generated and whose plugin set is frozen at the tag.

## Conclusion

geany-plugins fits Geany users who want debugger, version control, LaTeX, LSP or tree browser support without patching the editor itself, and who can read the configure options to see exactly which plugin is skipped on their machine. It does not fit someone who wants a single command install, since the collection is built from source with Autotools and needs its dependencies present. Before building, read the plugin list in the README, check that the dependencies of the plugins you want are installed, and remember that the last tagged release, 2.1.0 from 2025-07-06, is older than the last push on 2026-10-12.

## FAQ

### How do I build the Geany plugins from source?

The collection uses Autotools: run ./configure or, from a git checkout, ./autogen.sh, then make and sudo make install. The autogen.sh script only exists in the git repository and is not included in release packages.

### How do I enable only the Geany plugins I want?

Pass one --enable-<option> per plugin to configure, for example ./configure --enable-geanylua --enable-spellcheck. You can also use --disable-all-plugins with a single enable option, or --enable-all-plugins to force everything on.

### What happens when a Geany plugin dependency is missing?

By default the auto-detection disables plugins whose build dependencies are not present, so the build succeeds without them. Forcing a plugin with --enable-<option> makes configure fail with an error message instead.

### Under what license are the Geany plugins released?

Individual plugins carry their own terms, and the README points to the COPYING file for per plugin licence information. The repository itself is listed under a custom licence that GitHub cannot classify, so check the plugin you actually ship.

### How current is the Geany plugin collection?

The last push to the repository was on 2026-10-12, while the most recent tagged release is 2.1.0 from 2025-07-06, preceded by 2.0.0 in 2023 and 1.38.0 in 2021. Work in the tree moves ahead of the numbered releases.

## Sources

- [geany/geany-plugins on GitHub](https://github.com/geany/geany-plugins)
- [Issues](https://github.com/geany/geany-plugins/issues)
- [Project website](http://plugins.geany.org/)
- [README](https://github.com/geany/geany-plugins/blob/master/README.md)
- [Releases](https://github.com/geany/geany-plugins/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/geany-geany-plugins