Pepper is an experiment of mine to simplify code editing from the terminal. It’s mission is to be a minimal and fast code editor with an orthogonal set of both editing and navigation features.
- Small set of editing primitives
- Mnemonic and easy to reach default keybindings (assuming a qwerty keyboard)
- Require minimal effort to navigate and explore a workspace
- Cross-plaftorm (Windows, Linux, BSD, Mac)
- Extensible through external cli tools
- Be as fast and reponsive as possible
# non goals
- Support every possible workflow (it will never get close to feature parity with vim or emacs)
- Have complex ui (like breadcumbs, floating windows, extra status bars, etc)
- Multiple viewports (you can open multiple clients and they’ll be connected)
- Undo tree
- Support for text encodings other than UTF-8
- Fuzzy file picker (you can integrate with fzf, skim, fd, etc)
- Workspace wide search (you can integrate with Grep, Ripgrep, etc)
- Having any other feature that could be better implemented by integrating an external tool
- everything is reachable through the keyboard
- modal editing
- multiple cursors
- caret style cursors (cursors can move past last line character and text is always inserted to its left)
- text-object selection
- keyboard macros
- client/server architecture
- simple syntax highlighting
- language server protocol
In the spirit of https://handmade.network/
all features are coded from scratch using simple stable Rust code.
These are the only external crates being used in the project:
- `winapi` (windows-only): needed to implement windows platform layer
- `libc` (unix-only): needed to implement unix platform layer
# modal editing
Pepper is modal which means keypresses do different things depending on which mode you’re in. However, it’s also designed to have few modes so the overhead is minimal. Most of the time, users will be in either normal or insert mode.
## comparing to vim
Like Vim, you have to actively start text selection. However, unlike it, you can also manipulate selections in normal mode. Also, there’s no ‘action’ then ‘movement’. There’s only selections and actions. That is, d will always only delete selected text. If the selection was empty, it does nothing.
Pepper expands on Vim’s editing capabilities by supporting multiple cursors. This enables you to make several text transformations at once. Also, cursors behave like carets instead of blocks and can always go one-past-last-character-in-line.
## comparing to kakoune
Like Kakoune, you can manipulate selections while in normal mode and actions always operate on selections. However, unlike it, normal mode remembers if you’re selecting text or nor (think a pseudo-mode). This way, there’s no need for extra alt- based keybindings.
Pepper is heavily inspired by Kakoune’s selection based workflow and multiple cursors. However its cursors behave like caret ranges instead of block selections. That is, the cursor is not a one-char selection but only a visual cue to indicate the caret location.