← all builds

From-Scratch Build · Dev Environment

Synced Editor Config

My text editor's settings, key bindings and installed packages — pulled out of one laptop, put under version control, and shared so every machine I touch opens the editor with the exact same muscle memory.

Editor settingsKey bindingsPackages SymlinkVersion control

What it is

One editor, every machine

A modern text editor keeps its personality in a folder of small files: a preferences file with your tab width and theme, a keymap that remaps shortcuts to your fingers, a list of installed packages, and per-language tweaks. Set up by hand, that folder is unique to one computer — and re-creating it on a second machine means hours of remembering exactly which boxes you ticked.

I built this to make the editor's "personality folder" portable. The whole user-configuration directory becomes a version-controlled repository; on any new machine you clone it once and point the editor at it. From then on a setting changed on one computer is a setting changed everywhere.

The core idea I wanted to learn: an editor is only as good as its configuration, and configuration is just files. If those files live in a repo and the editor reads them through a symlink, "sync my editor" stops being a feature you pay for and becomes something you own.

The stack

What's in the config folder

Each file in the editor's user folder controls one slice of behaviour. Here's what I tracked and why it matters.

preferences

Global settings

The base preferences — font, theme, indentation, rulers, behaviour on save. The single file that shapes how the editor looks and feels everywhere.

shortcuts

Key bindings

A custom keymap that remaps commands to the shortcuts my hands already know, so the editor never fights my reflexes on a new machine.

packages

Package list

The list of installed plugins. Tracking it means a fresh install can restore the same extensions automatically, not one by one.

per-language

Syntax settings

Language-specific overrides — different rules for Python than for markup — so each file type behaves the way that language wants.

theme

Colour theme

A bundled colour scheme kept in the repo, so the editor looks identical everywhere instead of falling back to defaults.

manager

Package manager

The editor's plugin manager reads the tracked package list and reinstalls everything — the bridge between a config file and a working install.

How it works

Clone once, sync forever

The trick is not to copy the config onto each machine but to replace the editor's user folder with a link to the repository. After that, the editor and the repo are the same thing.

  1. Install the manager core

    Add the editor's package manager first, so it's ready to restore plugins once the tracked list is in place.

  2. Clone the config core

    Pull the version-controlled user folder down to the new machine into a known location.

  3. Move the old folder aside core

    Rename the editor's existing user folder rather than deleting it — a safe escape hatch if anything goes wrong.

  4. Symlink it in core

    Point the editor's user folder at the cloned repo. Now editing settings in the app is editing the repo.

  5. Let packages restore core

    On launch the manager reads the tracked package list and reinstalls every missing plugin automatically.

  6. Cross-platform paths future

    Fuller handling of editor paths beyond one operating system is left as future work — ambitious builds are never quite finished.

How it runs

The setup, end to end

Syncing is the whole point. The promise of the build is that a second machine reaches an identical editor without a single setting touched by hand:

In my rebuild I focused on the clone-and-link path: replace the user folder with a link, reopen the editor, and watch settings, key bindings and packages all snap into place.

Reflection

What rebuilding it taught me