vlang/ved: a small graphical editor with workspace and build integration

The developer problem Ved targets

Ved addresses developers who want a compact graphical editor without adopting a large editor suite. Its stated binary size is approximately 1 MB, and the README says it can compile in under a second. Those figures are project claims rather than independently measured results, but the repository structure supports the broader point: Ved is a relatively small V codebase centered on files such as `ved.v`, `draw.v`, `events.v`, `view.v`, `syntax.v`, and `config.v`.

The editor is designed around code directories rather than isolated files. Workspaces can contain multiple project directories, and the README says users can move between them with keyboard shortcuts. Within a workspace, Ved provides a fuzzy file finder, fast current-file search, Git integration, go-to-definition, split views, and commands tied to a project's build files. This makes it closer to a lightweight development environment than a plain editor window.

That focus does not make Ved suitable for everyone. The README explicitly labels it pre-alpha software, says it may not work for everyone, and acknowledges limitations that must be worked around. The latest listed release is version 0.1, published on 2020-08-06, so the feature list should not be read as evidence of release maturity.

Ved's graphical editor architecture and data flow

The visible repository layout separates GUI drawing, input events, views, configuration, syntax highlighting, navigation, saving, and development commands. `draw.v` handles rendering concerns, while `events.v` is the natural location for keyboard and application events. `view.v` represents the editor's view layer, and `syntax.v` plus the `syntax/` directory contain syntax-related code. Separate modules for `goto.v`, `file_tree.v`, `autocomplete.v`, `timer.v`, and `debugger.v` show that editor navigation and tooling are implemented inside the application rather than delegated to a large external plugin framework.

Ved describes its text rendering as hardware accelerated. The default path uses V's built-in font rendering, while a compile-time `use_freetype` flag selects Freetype. The README suggests Freetype may provide better rendering for some users, which is a conditional preference rather than a universal improvement. Syntax highlighting uses a base16-style color table, though the README warns that Ved's minimal highlighting will not reproduce the appearance promised by many existing base16 themes.

File handling is centered on local editor commands such as open, save, reload, and go to definition. Project integration is also command-driven. A Git command commits with `git commit -am`, another displays `git diff`, and a third uses `git grep` across the workspace. Build integration is narrower: Ved looks for build instructions named `build` and `build2`. That model is direct, but it offers little documented control over custom menus or arbitrary task pipelines.

Building Ved and launching a first project

On GNU/Linux, the README says Ved needs the X11-related packages linked from the V installation instructions. The free type option also requires Freetype and several display libraries. After installing V and those dependencies, clone the repository, compile it with the V command, and launch the resulting executable. The README says compilation should take a couple of seconds in general, while its feature list gives an under-one-second target.

git clone https://github.com/vlang/ved
cd ved
v .
./ved

The `v .` command builds the project from the current directory. The `./ved` command then starts the editor. No configuration file is required because Ved supplies defaults and does not create `conf.toml` by itself.

Ved works best with one or more code directories. Pass those directories as positional arguments when launching it. The following documented invocation opens two project paths:

ved path/to/project1 path/to/project2

The editor creates state under `$HOME/.ved`, where it stores workspaces, sessions, tasks, and configuration. Opening projects at launch is therefore a practical first use rather than merely a convenience. New users should verify that the configured directories open as workspaces and that the local build and Git commands behave as expected before relying on editor automation.

Editing commands, partial Vim mode, and build integration

Ved uses `C` as shorthand for `Ctrl` outside macOS and `⌘` on macOS. The documented basics include `C q q` to exit, `C o` to open a file, `C s` to save, `C r` to reload, `C p` for fuzzy search, and `/` to search within the current file. `C g` copies the current file path to the clipboard, while `t` returns to the previous file. Go-to-definition is available through `gd`.

The Vim support is explicitly incomplete. The README calls it a WIP Vim mode and says a true Vim mode is planned. The supported subset covers cursor movement, paging, word operations, selection, insertion commands, line joining, searching, indentation, deletion, replacement, and `C-n` for autocomplete. The `.` command repeats the last action. This is useful for familiar motions, but it should not be compared with the breadth of a full Vim configuration based on these bindings alone.

Project actions include `C c` for `git commit -am`, `C -` for `git diff`, and `?` for `git grep`. Building is tied to files rather than a documented general-purpose runner. `C u` builds from instructions in `build`, while `C y` uses `build2`. The repository does not document a rollback mechanism, a package manager for Ved plugins, or a migration procedure for configuration between releases. That absence matters because adoption starts from source rather than a mature release channel.

Configuration choices in $HOME/.ved

Ved stores its configuration in `$HOME/.ved/conf.toml`. The file does not appear automatically, which keeps first startup simple but also means documentation-driven customization is optional. The `[editor]` table controls appearance and several editing behaviors, including dark mode, cursor shape, text size, line height, character width, tab display size, and whether backspace at the beginning of a line does nothing.

A short valid configuration can use the keys exactly as documented:

[editor]
dark_mode = false
cursor = 'variable'
text_size = 18
line_height = 20
char_width = 8
tab_size = 4
backspace_go_up = true

The cursor value shown is `'variable'`. The README also identifies block and beam variants. `text_size`, `line_height`, and `char_width` are deliberately presented as advanced values, with a warning that users are unlikely to need to change them. Incorrect values may therefore create an unusable text layout, and the documentation does not define validation or recovery behavior.

Colors are defined through sixteen `base00` through `base0F` entries under `[colors]`. This follows a base16-style organization, but Ved's syntax highlighting is described as very minimal. Themes designed for full editors may consequently produce different visual results. Neither an error format for invalid TOML nor a documented recovery path from a corrupt configuration is provided, so the first configuration edit should retain the existing defaults when testing new values.

Pre-alpha constraints and the alternative approach

The clearest limitation is Ved's declared maturity. The README says stability and user experience are still being improved and that current limitations must be worked around. Planned features include a true Vim mode, Emacs keybindings, Nano keybindings, word wrap, and better syntax highlighting. Their planned status confirms that users should not expect feature parity with established editors.

Freetype support adds another dependency decision. GNU/Linux installation instructions include X11, Xrandr, Mesa, Xi, and Xcursor development packages in the Ubuntu command. macOS and Windows skip the initial X11 requirement, but Freetype remains optional. A source-built application therefore has platform-specific setup costs despite its small compiled size.

Vim is the clearest alternative because it is also referenced by Ved's own documentation, but the approaches differ. Vim centers its editing model on extensive modal command handling and text-centric workflows. Ved centers its interface on a compiled graphical application, hardware-accelerated rendering, workspaces, splits, project paths, build shortcuts, Git actions, fuzzy search, and a Pomodoro-based timer. Ved offers selected Vim motions for convenience, while Vim provides the broader command model that Ved lists only as planned. Developers who prioritize a small project-specific graphical workflow may accept Ved's incomplete feature set. Developers who need complete modal editing or established keybinding coverage have a different adoption decision to make.

Maintenance, licensing, and adoption cost

The repository is not archived, and its last push was on 2026-10-10. That date is recent, but the repository history does not by itself establish the stability of every documented feature. The only listed release remains version 0.1 from 2020-08-06, so users should expect to build and evaluate the current `master` branch rather than rely on a sequence of documented stable releases. The README and repository do not provide a release upgrade guide, compatibility matrix, rollback procedure, or migration notes.

The source-available license is GPL-3.0. For organizations, that affects how distributed modified versions and corresponding source obligations are handled. This is a licensing consideration rather than legal advice. Teams should review the actual `LICENSE` file and their distribution model before embedding or modifying Ved.

Practical upgrade cost is also tied to V and native graphics dependencies. Users may need to track changes in the V compiler, install X11 development packages, or rebuild with the optional Freetype path. The settings directory contains workspaces, sessions, tasks, and `conf.toml`, but the documentation does not say whether older state files remain compatible across source revisions. A low-cost trial is therefore possible through a separate build and local configuration, but a production adoption decision needs direct inspection of those files.

Editorial conclusion

Developers should consider Ved when they want a compact, compilable graphical editor with workspace-oriented commands and are prepared to handle pre-alpha limitations. Users requiring stable releases, complete Vim support, broad keybinding compatibility, word wrap, or mature syntax highlighting should choose a more established editor. Before adoption, compile Ved from the current master branch, test the required X11 packages on GNU/Linux, and verify that its partial Vim mode and built-in Git and build commands match their development workflow.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. vlang/ved on GitHub