mirror of
https://github.com/mawww/kakoune.git
synced 2024-11-22 05:03:56 +03:00
153 lines
6.1 KiB
Plaintext
153 lines
6.1 KiB
Plaintext
Kakoune design
|
|
==============
|
|
|
|
This document describes the design goals for Kakoune, including rationale.
|
|
|
|
Interactivity
|
|
-------------
|
|
|
|
Unlike Vim, Kakoune does not have an underlying line-oriented editor. It is
|
|
always expected to be used in an interactive fashion, displaying edited text in
|
|
real time. That should not prevent Kakoune from being used non-interactively
|
|
(executing a macro for example), but priority should be given to ease of
|
|
interactive use.
|
|
|
|
Limited scope
|
|
-------------
|
|
|
|
Kakoune is a code editor. It is not an IDE, not a file browser, not a word
|
|
processor and not a window manager. It should be very efficient at editing code.
|
|
As a side effect, it should be very efficient at editing text in general.
|
|
|
|
Composability
|
|
-------------
|
|
|
|
Being limited in scope to code editing should not isolate Kakoune from its
|
|
environment. On the contrary, Kakoune is expected to run on a Unix-like
|
|
system alongside a lot of text-based tools, and should make it easy to
|
|
interact with these tools.
|
|
|
|
For example, sorting lines should be done using the Unix sort command, not
|
|
with an internal implementation. Kakoune should make it easy to do that,
|
|
hence the +|+ command for piping selected text through a filter.
|
|
|
|
The modern Unix environment is not limited to text filters. Most people use
|
|
a graphical interface nowadays, and Kakoune should be able to take advantage
|
|
of that without hindering text mode support. For example, Kakoune enables
|
|
multiple windows by supporting many clients on the same editing session,
|
|
not by reimplementing tiling and tabbing. Those responsibilities are left
|
|
to the system window manager.
|
|
|
|
Orthogonality
|
|
-------------
|
|
|
|
Kakoune features should be as orthogonal as possible. For example, in Vim,
|
|
there are many ways to modify the buffer: Through normal/insert
|
|
mode, command mode, and Vim scripts. In Kakoune, modifying the buffer is
|
|
only the job of normal/insert mode.
|
|
|
|
That means there should be clear separation of concerns between modes:
|
|
|
|
* normal mode is for manipulating the selection and the selection contents.
|
|
|
|
* insert mode is for interactive insertion into the buffer.
|
|
|
|
* command mode is for non-editing features (opening a file, setting
|
|
options...).
|
|
|
|
Orthogonality is an ideal; it should not forbid common sense pragmatism.
|
|
The +gf+ and +ga+ commands are not strictly selection manipulation commands,
|
|
but they do fit nicely with other +goto+ commands, so they are acceptable in
|
|
normal mode even though they could arguably be moved to command mode.
|
|
|
|
Modes should be orthogonal, as should commands within modes. For
|
|
example, Vim uses both +d+ and +x+ to delete text, with minor differences. In
|
|
Kakoune only +d+ exists, and the design ensures that +x+ is not needed.
|
|
|
|
Speed
|
|
-----
|
|
|
|
Kakoune should be fast -- fast to use, as in a lot of editing in a few
|
|
keystrokes, and fast to execute.
|
|
|
|
* Vim is the benchmark here. Most editing tasks should be doable in fewer
|
|
or the same number of keystrokes as Vim.
|
|
|
|
* Kakoune is designed with asynchronicity in mind. Launching a background
|
|
process and using its result when available should not block the editor.
|
|
|
|
* Kakoune should be implemented with speed in mind. A slow editor is a
|
|
useless one.
|
|
|
|
Simplicity
|
|
----------
|
|
|
|
Simplicity is nice. Simplicity correlates with orthogonality and speed. It makes
|
|
things easier to understand, bugs easier to fix, and code easier to change.
|
|
|
|
* *No threading*: multithreading is a hard problem and is not well suited
|
|
to a text editor:
|
|
|
|
- When we want a direct result, we need to be synchronous with
|
|
the user. A 4x speed improvement is meaningless; we need to have an
|
|
algorithm which appears instantaneous to the user.
|
|
|
|
- When we want an asynchronous result, the processing is best left
|
|
to a helper command which can be reused with other Unix tools.
|
|
|
|
* *No binary plugins*: shared objects by themselves add a lot of
|
|
complexity. Plugins add another interface to Kakoune and go against
|
|
orthogonality. The +%sh{ ... }+ and socket interfaces should be made good
|
|
enough for most plugin use cases.
|
|
|
|
- Rather than writing a plugin for intelligent code completion or source
|
|
code navigation, it is better to write an independent helper tool that can
|
|
interact with Kakoune through the shell.
|
|
|
|
* *No integrated scripting language*: for the same reason as binary plugins.
|
|
|
|
* *Limited smartness*: Kakoune should not try to be too smart. Being smart
|
|
is often unpredictable for the user and makes things context-dependent.
|
|
When Kakoune tries to be smart, it should provide the alternative,
|
|
'non-smart' version. For instance, +\*+ tries to detect word boundaries on
|
|
the selection, but +alt-*+ opts out of this behavior.
|
|
|
|
Unified interactive use and scripting
|
|
-------------------------------------
|
|
|
|
As an effect of both Orthogonality and Simplicity, normal mode is not
|
|
a layer of keys bound to a text editing language layer. Normal mode *is*
|
|
the text editing language.
|
|
|
|
That means there is no +delete-selected-text+ command that +d+ is bound
|
|
to. +d+ *is* the +delete selected text+ command.
|
|
|
|
This permits both scripting and interactive use cases to share the same text
|
|
editing language. Both use normal mode to express complex editing.
|
|
|
|
Besides promoting simplicity by avoiding the introduction of another
|
|
layer, this helps ensure the interactive editing language is expressive
|
|
enough to handle complex use cases, such as indentation hooks.
|
|
|
|
Language-agnostic
|
|
-----------------
|
|
|
|
Kakoune should not be tailored for writing in a specific programming
|
|
language. Support for different languages should be provided by a kak script
|
|
file. Built-in language support should be avoided.
|
|
|
|
Self-documenting
|
|
----------------
|
|
|
|
Kakoune should be able to document its features. Live documentation, along
|
|
with an extensive suggestion/completion system, provides the discoverability
|
|
which is often lacking in non-GUI tools. As much as possible, documentation
|
|
should be integrated with the code so that it stays up to date.
|
|
|
|
Vim compatibility
|
|
-----------------
|
|
|
|
Kakoune is inspired by Vim and should try to keep its commands similar to
|
|
Vim's if there are no compelling reasons to deviate. However, self-consistency
|
|
is more important than Vim compatibility.
|