Minimum Viable Editor
I am about to publish out a new version of my visual, structure programming editor. It is written in python, over Pygame and PyOpenGL libraries. It paints with signed distance field fonts and filled polygons. The layouter is driven by a heap of python functions. Today's blog post tells about Minimum Viable Products, and how does it appear in editor design.
Minimum Viable Product has been defined as the product with just those features that allow the product to be deployed, nothing else. It is a product development strategy attempting to reach highest return on investment versus risk value. You're supposed to test the product against market to validate it, and minimize the risks it forms.
The concept is useful in editor design context the minimum viable product is analogous to the editing model followed by the editor and affects the composition of richer set of features. For any given editing problem there are several variations of an editing model.
My system works on extended forms of text, so it replaces plain text editors. To become widespread it'd have to be available for everyone. The design of a plain text editor has been reiterated for decades now. Examples:
- Cursorless text editors. Users specify a line, or a string to replace along the editing command.
- "visual" mode to cursorless editing. The "visual" provided the cursor and keeps the cursorless editing model.
- Emacs -style. The cursor is included in the editing model. Operations build around the cursor motion.
Modern VIM includes features from the cursorful editing to satisfy expectations of beginning users, but the editor doesn't rely on those features. The model fits text editing better, but holds steeper learning curve.
Emacs interface is capable of summoning rich variety of hand-related injuries, but there's no denying it is beginner friendly. The cursor's motion is simpler and special features are triggered by special key chords.
Recreation of emacs -style editing is simpler than creation of VIM -style editing. The "minimum viable emacs" is easier to understand than "minimum viable vim". Worst of modern text editors resemble emacs more than vim.
Both emacs and vim have a common minimum viable product. It's this:
line = ""
while ch != "":
line += getch()
It's called minibuffer. Emacs proceeds by extending the minibuffer. Vim proceeds by turning the minibuffer into a line based editor, then constructing cursor and visual mode over that line based editor. Both editors eventually converge to extend their features by composing existing functions.
In structure based editing there are more ways to navigate around the document. Meaning there is bigger chance that you need them occassionally to edit the structure efficiently. Efficient working on the text require VIM -style features and the disconnection between cursor and the data model.