Docs / How-to guides

Use vim, VS Code, and Other Editors

Edit shared files in the editor you already use.

Editing works as usual

The shared folder is a normal folder to your editor. Open a file from the mount, edit, save. The save reaches the other computer in well under a second on a normal link (measured). Nothing about your editor's configuration needs to change.

What a save looks like to KeibiDrop

Editors save in different ways, and the common ones are tested with the real programs:

Only the changed part of a file is transferred on an edit, which matters for large files: a 2 MiB change in a 512 MiB file moves 2 MiB instead of 512.

Two people in one file

Turn-taking, where one person saves and the other picks up later, produces clean convergence with no extra files. If both of you save the same file at nearly the same moment, the newer save wins the name and the other version appears as a conflict file next to it, on both machines. See Handle conflict files.

For live pair-editing of the same buffer, use a collaborative editor. KeibiDrop syncs saved files; it does not merge keystrokes.

macOS: seeing live in-place edits

A peer's edit reaches your programs on every platform as soon as they read the file again, also when the edit keeps the file's size the same. On macOS that needs KeibiDrop 0.5.0 or later: 0.4.8 and earlier showed such an edit only after the next size change, unless live_collab was on. From 0.5.0 leave live_collab off; the configuration reference says when it still helps.

IDEs and big projects

An IDE that indexes a project reads many files. On a shared folder, those reads are on-demand fetches: the first index of a big cold project pulls what it reads, then the local cache serves it. If you open a large project over a slow link, let the first index finish before judging the speed. Build outputs written to the mount sync like any files; if the other side does not need them, point build output at a local directory instead.