Turbo is a terminal text editor built to test Turbo Vision

The editor is the test harness

Turbo is an experimental text editor for the terminal, based on the Scintilla code editing component by Neil Hodgson and the Turbo Vision application framework, which is a fork hosted by the same author. The readme states the purpose plainly: it was created to demonstrate new features in Turbo Vision, and in particular it has served as testing ground for Turbo Vision's Unicode capabilities. That reordering matters, because it tells you what to expect. This is not a text editor that happens to use a framework, it is a working application that exists to give a framework a hard problem. The consequences show up in the feature list, where several items are marked as depending on Turbo Vision, such as Unicode in dialog text boxes and True Color support, which is exactly the kind of thing a framework has to be pushed on before it is claimed to work.

The look and feel is a deliberate choice

The project's stated goals are that Turbo aims at being intuitive and easy to use, with usability and productivity as its two other major objectives, although it has not got that far yet. And only for being a Turbo Vision application, it offers a vintage look and feel. That last clause is the honest one. A Turbo Vision application has the appearance of a program from the DOS era, with a menu bar, a workspace window and dialog boxes, and the screenshot in the readme shows exactly that. For a user who grew up on that interface it is familiar; for everyone else it is a novelty, and the readme addresses this with a line that is either charming or a warning depending on your mood, saying that Turbo has been designed to be intuitive so you probably already know how to use it. The keybindings are the conventional ones, with Ctrl+C and Ctrl+Ins for copy, Ctrl+V and Shift+Ins for paste, Ctrl+X and Shift+Del for cut, Ctrl+Z and Ctrl+Y for undo and redo, Tab and Shift+Tab to indent and unindent, Ctrl+E to toggle a comment and Ctrl+A to select all.

Building it on Unix

On Unix systems you build Turbo yourself, and the first step is to clone the repository with its submodules using the recursive option of git clone. The dependencies are CMake, a compiler supporting C++17 and libncursesw, with the note about the w, for Unix only. Three optional dependencies add real capability: libmagic for better recognition of file types, libgpm for mouse support on the Linux console, and xsel, xclip and or wl-clipboard for system clipboard integration, the last being Unix only except on macOS. The build itself is two commands.

cmake . -DCMAKE_BUILD_TYPE=Release && # Or 'RelWithDebInfo', or 'MinSizeRel', or 'Debug'.
cmake --build .

The build type comment is worth pausing on, because for an editor you are going to debug you would want RelWithDebInfo or Debug rather than Release, and the choice is the one line of configuration you will want to change.

There are also per-distribution instructions, and the Ubuntu 20.04 one is the shortest.

sudo apt update && sudo apt upgrade
sudo apt install build-essential cmake gettext-base git libgpm-dev libmagic-dev libncursesw5-dev xsel
git clone --recursive https://github.com/magiblot/turbo.git
cd turbo
cmake . -DCMAKE_BUILD_TYPE=Release
cmake --build . -- -j$(nproc) # Build Turbo.
sudo cp turbo /usr/local/bin/ # Install (optional).

The parallel build flag is worth copying, since a single-threaded build of a C++ editor with two large dependencies is not something you want to sit through. The Ubuntu 18.04 variant differs only in pinning g++-8 through the CXX variable before the cmake call.

Windows binaries come from the workflow artifacts

On Windows the readme points you at the Actions page rather than at a release, and the instructions are specific about where to look. You click the first successful workflow, with a green tick, in the list, and at the bottom of the workflow page, as long as you are logged in to GitHub, there is an Artifacts section containing two files. turbo-x86.zip is a 32-bit executable built with MSVC requiring Windows Vista or later, and turbo-x64.zip is the 64-bit executable built with MSVC requiring x64 Windows Vista or later. The reason for this arrangement is that the repository publishes no GitHub releases at all, so the continuous integration output is the distribution channel, and the artefacts are only available to a logged-in user. The repository root confirms the setup, with a .github/ directory, a .gitmodules file for the dependencies and a deps/ directory that holds them.

Opening files and the keybindings that matter

From the command line the editor takes a list of files, and the readme notes that to open several files in a directory tree you should use wildcards or subcommands if they are supported by your shell.

# Open all .c and .h files in the current directory and its subdirectories
turbo `find . -type f -name '*.c' -o -name '*.h'`
# Open all files in the current directory and its subdirectories, excluding executables and hidden files or directories
turbo `find . -type f \! -executable \! -path '*/.*'`

Inside the application, the navigation bindings follow the usual conventions, with Ctrl+F for find, Ctrl+R for replace, Ctrl+G for go to line, Ctrl+Back or Alt+Back and Ctrl+Del to erase one word left or right, Ctrl+Left and Ctrl+Right to move one word at a time, and Ctrl+Shift+Up and Ctrl+Shift+Down to move the selected lines. Document management is on Ctrl+N for a new document, Ctrl+O for the open dialog, Ctrl+S to save, Ctrl+W to close the focused document, F6 and Shift+F6 to move between documents in most recently used order, and Ctrl+Q or Alt+X to exit. In environments with extended keyboard support, such as the Linux console, Windows or Kitty 0.20.0 and later, more shortcuts work, and any problem with them belongs in the Turbo Vision tracker rather than the editor's, since the terminal application is the layer in charge.

The feature list tells you what is missing

The to-do list is unusually complete for a readme, and it is more informative than a feature section would be. Done are several files open at once, line numbers, word wrap, suspend to shell, Unicode in documents and in particular UTF-8, double-width characters, opening binary files without panicking, a list of open documents in most recently used order, tree views of open documents both unsorted and sorted alphabetically, case-insensitive search, find as you type, replace, go to line, removing trailing whitespace on save, ensuring a newline at the end of the file, comment toggling, brace match highlighting and integration with the system clipboard. Syntax highlighting covers a specific set of languages, C, C++, Rust, Python, JavaScript, Make, Bash, Ruby, JSON, YAML, HTML, INI, Go and PHP, with the rest of the Scintilla languages still to do. Not done are a list of recently opened files, detecting files modified on disk, persistent configuration, keybinding customisation, colour scheme customisation, Vim input mode and localisation. Scintilla has many more features and the readme says making more of them available is a matter of time, with contributions welcome.

Where this is the wrong choice

Three limits are worth naming. The first is that the editor is not finished by its author's own account, and the missing items are the ones that make an editor pleasant to live in, namely persistent configuration, keybinding customisation and colour schemes. The second is the platform gap, where Windows gets prebuilt binaries but Unix users build from source and must supply the wide-character ncurses library, and macOS is explicitly excluded from the clipboard helpers. The third is the terminal itself. An editor built on a text-mode framework inherits the terminal's limits, and the project is candid about the dependency on the framework for Unicode in dialogs and for True Color, which is not yet supported. What the project does deliver is a working, unusual editor with a vintage interface, and, more valuably, a real application that keeps pushing on the Unicode corners of a framework that other people are writing applications on.

Editorial conclusion

Turbo suits a developer who wants to see what Turbo Vision can do before writing an application in it, and it suits anyone who wants a terminal editor that handles UTF-8 and double-width characters without falling over. It is the wrong tool for daily editing today, because the readme itself says usability and productivity are objectives it has not reached, and the feature list shows persistent configuration, keybinding customisation and colour scheme customisation still unchecked. It is also the wrong choice if you want Vim input mode, since that is an open item. Before building it, read the dependency list, because the wide-character ncurses library is required on Unix and the optional pieces are what make mouse support, file type detection and clipboard integration work. The last push was on 2026-10-04 and the repository publishes no releases.

Frequently asked questions

Official sources

1. Issues
2. magiblot/turbo on GitHub
3. README