• Stars
    star
    321
  • Rank 127,760 (Top 3 %)
  • Language
    Emacs Lisp
  • License
    GNU General Publi...
  • Created over 9 years ago
  • Updated 3 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Ergonomic Command Mode for Emacs

Join the chat at https://gitter.im/boon-mode/Lobby MELPA MELPA-Stable

Boon: An Ergonomic Command Mode for Emacs

Boon is a complete package for modal editing, which is not Evil.

Strong points:

  • Ergonomic: common commands are easy to type.
  • Emacs-friendly: Emacs conventions are respected as much as compatible with design goals. This means that Boon integrates well with existing Emacs infrastructure, and leverages it. Existing user configuration can often be re-used.
  • Modular: No need to buy into the whole system: mix-and-match the parts you want.

Ergonomic Design

It is largely accepted that modal editing is more ergonomic than using key-chords. Boon attempts to take this advantage to its conclusion, making modal editing as comfortable as possible, by adhering to the following design principles:

  • Spacial allocation first, mnemonics second: the allocation of keys to commands is primarily based on the locations of keys on the keyboard. Whatever is printed on the key cap is a secondary concern.

  • Easy finger rolls: common key combinations should either be left/right hand alternation or easy one-hand rolls.

  • Use of home row and strong fingers for the most used commands.

  • Easy navigation: many keys are allocated to navigation. This strategy facilitates moving around, which is in fact the most common task when editing text. Because movements double up as region-definitions, this design also makes manipulation commands more powerful.

  • Prefer an easy two-keystroke combination to a single hard-to-reach key. Hard-to-reach keys are free for the user to bind to rarely used commands (often user and mode-dependenent).

In command mode, movement keys are bound to the right hand, while text manipulation is bound to the left hand. This division of tasks is reminiscent of game-console controllers.

Right-hand.

The leftwards (and upwards) movements are bound to the leftmost fingers (index and middle finger), while rightwards (and downwards) movements are bound to the rightmost fingers (ring finger and pinky.) Additional unpaired movements are bound to the middle column, which is reached with an extension of the index finger.

Left-hand.

The most common editing commands (cut, paste, parenthesis manipulation) are bound to the home row. The top row is (mainly) for searching. The bottom row gives access to user-defined (C-x) and mode-specific shortcuts (C-c), insert mode, and registers.

Emacs integration

  1. C-x and C-c shortcuts. Any 'C-x ' command is available via 'x '. (drop the 1st "Control"). Thus 'x s' will save all buffers, etc. C-c C- shortcuts are now typed simply as "c ". This means that no special configuration is required when you start using a new major or minor mode.

  2. 'Special' modes. Emacs already has several modes which have a modal interface. (Dired, Magit, etc.) Instead of re-inventing the wheel, Boon leaves these modes alone (mostly). Only the 'x' key is stolen by Boon (so splitting windows, switching buffers, etc. keep their usual shortcut.)

  3. Command repeats. Boon does not use its own mechanism to repeat commands: it simply uses the Emacs standard way. Commands which contain an insertion (eg. replace current word by something else) are properly recorded in Emacs command history. Emacs command history remains fully usable with Boon.

  4. Parsing commands. Boon does not have a special way to parse commands. Everything is done using Emacs keymaps and interactive arguments.

  5. Customize-friendly. Quick customization is easily done using M-x customize-group boon. (re)-Defining keys in the boon-...-keymaps is also supported.

  6. Multiple-cursors support. System of selectors supports multiple-cursors: (multiple regions will be returned when multiple cursors are active).

Modular design

Boon is designed as set of modules, largely independent of each other. Each module is customizable and provides reusable components, in following the Emacs spirit of hackability. This means that even if you disagree with the design choices explained above, you may still want to use some parts of Boon. The structure of Boon is as follows:

  1. boon-moves.el and boon-search.el provide a set of move and search commands. These work the same way as standard Emacs commands --- they are merely more powerful (or just have different emphasis). Layout-frontends typically bind these commands (in addition to standard ones) in the boon keymaps.
  2. boon-arguments.el provides a set of selectors to define regions. (These selectors are the equivalent of vim 'text objects'). Selectors include plain regions (words, lines, paragraphs, ...), but also region transformers (think: exclude borders, just borders, including spaces, "foreach", etc.). Additionally every move command (in the boon-moves-map keymap) can be used as a selector which means that they are easily customized.
  3. boon-core.el provides an infrastructure for modal editing. The implementation draws much inspiration from evil-core, but is heavily simplified.
  4. boon-main.el provides a set of commands. These are similar to standard Emacs commands, but they use the system of selectors described above. (For good measure, some random extra commands are thrown in.) These commands may be used in combination with a modal system or not. A few commands also switch to insert mode.
  5. boon-keys.el, boon-colemak.el, boon-qwerty.el, etc. are (layout-specific) frontends. Those require all the above and provide a mapping of moves, selectors and commands onto keys.

Installation

REQUIREMENTS

  • Emacs version >= 25.1
  • Qwerty, Qwertz or Colemak layout (Workman version partially implemented -- contributions welcome).

Install Boon (perhaps using MELPA), and add the following to your configuration:

(require 'boon-colemak)
;; (require 'boon-qwerty) ;; for qwerty variant

Then

(boon-mode) ;; to enable boon everywhere

If you just eval'ed the above (or just did not want to enable boon everywhere), Boon may not be active in the current buffer. If it is not activated and you want to try it locally, activate it by

M-x turn-on-boon-mode

Usage

You can jump-start by reading any of the cheat sheets (colemak, qwerty) directly, but reading through the tutorial is highly recommended:

(require 'boon-tutorial)
M-x boon-tutorial

(You'll get the version of the tutorial adapted to the layout-frontend you have activated, qwerty, colemak, etc.)

Configuration

The main variables to configure are:

  • boon-select-map, boon-moves-map, boon-command-map, boon-insert-map, boon-special-map. (Those are keymaps.)

  • boon-enclosures (can be customized.)

If you use powerline (or mutatis mutandis spaceline), you may want to:

(require 'boon-powerline)
(boon-powerline-theme) ;; if you want use powerline with Boon
  • Per-mode keybinding can be implemented by setting the boon-map property of the mode symbol. Example:

    (let ((map (make-sparse-keymap))) (set-keymap-parent map boon-command-map) (define-key map "j" 'org-open-at-point-global) (put 'org-mode 'boon-map map))

Comparison with other modal layers for Emacs

If possible I would have liked not to develop Boon (or parts of it) and use an existing package. Hence I have looked into other options and have documented my research below. In summary, even though I would like to share code and/or replace parts of Boon with similar package, at the moment no package offers enough that I feel the urge to try and use them. This is partly due to the fact that Boon maintenance burden is fairly low. (And at the time of inception, the only conceivable alternative was Evil.)

  • Evil

    Evil is a (quite) complete vi emulation layer for Emacs.

    In contrast, in Boon, much of Emacs structure is leveraged and user experience is retained. Examples: the x key gives the C-x prefix map. The usual Emacs (interactive) arguments are used for text objects. Thus most of Boon remains usable even if one does not wish to use modal editing.

    Besides, the vi keybindings do not provide the best ergonomics (IMO).

    Making a boon-like layer on top of Evil appears theoretically possible, but I judge that the amount of work to gain an understanding of the code such that this would be practical would require more work than using Boon separately. Additionally, Emacs integration would still be poorer.

  • Xah Fly Keys http://ergoemacs.org/misc/ergoemacs_vi_mode.html

    Like boon, Xah Fly Keys (hereafter abbreviated to XFK) aims at providing a layout whose design is ergonomic. (According to the author it constitutes "the most efficient editing system in the universe".) Regardless, there follows a comparison based on my understanding.

    1. As far as I can tell XFK has no notion of selectors (vim's ``text objects''). Instead some keys are specially purposed to delete specific chunks of texts. Boon has a smaller set of useful commands and modifiers which can be combined in useful ways. It leaves keys for more "clever" navigation commands (eg. browsing errors) and editing shortcuts (eg. replace and insert in one keystroke).

    2. XFK binds digits to actions, boon leaves them for prefixes. (I may be misunderstanding here --- perhaps they are bound to special characters.)

    3. XFK seem to have less of a systematic assignment of keys to actions, even though the movements are roughly bound to the right hand. I believe that a more systematic binding startegy is easier to learn.

    4. Boon provides 1-key access to C-x and C-c prefixes. Instead, XFK puts everything under a single "leader key" (space), presumably without preserving emacs convention.

    5. The set of supported layouts is different. (Even though I'd expect ports to be easy.) As far as I can see, XFK has an automatic way to construct maps for a new keyboard layout. This is a worthy idea, but unfortunately boon already uses ad-hoc mapping depending on the layout, so adopting this strategy is not backwards compatible.

  • Fingers https://github.com/fgeller/fingers.el

    Fingers borrows a few ideas from Boon, including the division of work between left and right hand. The author (fgeller) gives a detailed account of the particular differences with Boon. My opinion is that Fingers is compatible with Boon concepts and could (and probably should) be implemented as a Boon layout-frontend.

  • Modalka https://github.com/mrkkrp/modalka

    Modalka is an engine to "introduce native modal editing of your own design". Thus its purpose is similar to boon-core.el. It could be possible and beneficial in the future to replace parts of boon-core with a dependency on Modalka. However at the moment it does not seem suitable. The main issue is that modalka does not support several states; it can only be either activated or not. Also, this part of Boon is sufficently simple that adding a dependency may be more troublesome than helpful.

  • RYO modal mode https://github.com/Kungsgeten/ryo-modal

    RYO modal has the same purpose as Modalka and boon-core; it is also a candidate to replace boon-core.el, but still falls short. Compared to Modalka, it provides support for repeating a command. However boon can repeat insertion commands, while RYO modal cannot. Additionally it also suffers from having a single non-insertion state.

  • God-mode https://github.com/chrisdone/god-mode

    God-mode is similar to "sticky modifier keys" in principle. Its simplicity allows to quickly get up to speed with it. However, it lacks the main benefit of a true modal layer: text operators. (what vi people call a "language for text editing"). Boon integrates god-mode functionality for the C-c prefix map specifically (bound to the c key).

  • Modal Mode http://retroj.net/modal-mode (Last updated in 2014)

    Another modal layer for Emacs, which is also lightweight and aims to integrate with Emacs. However, as far as I can see, there is no special attention paid to ergonomics.

More Repositories

1

dante

Emacs Lisp
389
star
2

styx

A nix-based Haskell project manager
Haskell
160
star
3

nano-Agda

Tiny type-checker with dependent types
Haskell
75
star
4

attrap

ATtempt To Repair At Point (emacs flycheck extension)
Emacs Lisp
40
star
5

prettiest

The Prettiest Printer
Haskell
34
star
6

sctt

Type-Theory in Sequent Calculus
Haskell
13
star
7

glpk-hs

Haskell bindings to glpk
Haskell
12
star
8

topics

Various interesting topics I'm looking at
Haskell
12
star
9

MarXup

Markup language on top of Haskell
Haskell
11
star
10

emacs-semantics-theming

Foundation for building semantically meaningful themes over emacs
Emacs Lisp
11
star
11

lp-diagrams

An EDSL for diagrams based based on linear constraints
Haskell
7
star
12

lcr

Lightweight coroutines in elisp
Emacs Lisp
6
star
13

ProbInfer

Material for the course
Haskell
5
star
14

linear-smc

Linear Types, Symmetric Monoidal Categories, and Tensors
Haskell
5
star
15

organ

Haskell
4
star
16

hcad

Haskell library for CAD
Haskell
4
star
17

ControlledFusion

Haskell
3
star
18

inox

A language with linear types
Haskell
3
star
19

lp-diagrams-svg

SVG backend for lp-diagrams
Haskell
3
star
20

typography-geometry

Drawings for printed text documents
Haskell
3
star
21

TTNameBinders

Adventures with names and binders in type-theory
Haskell
3
star
22

whynote

Minimal Note Taking program
Haskell
3
star
23

gasp

Another Haskell Prelude for Algebraic Classes and Structures
Haskell
2
star
24

imbib

bibtex management functions and gui
Haskell
2
star
25

Cake

Build system as a Haskell library
Haskell
2
star
26

FOL

Minimal FOL prover
Haskell
2
star
27

hgal

Haskell Graph Automorphism Library
Haskell
2
star
28

polynomials-bernstein

Haskell
2
star
29

Parsek

The Parsek library developed by Koen Claessen in his functional pearl article Parallel Parsing Processes
Haskell
1
star
30

Generic-Programming-WIth-Dependent-Types

A translation to Agda of the paper with the same title of Altenkirch et al.
1
star
31

labeled-tree

Haskell labeled trees
Haskell
1
star
32

sparse-matrix

sparse matrix represented as quad-tree
Haskell
1
star
33

nnn

Not a Neural Network library
Haskell
1
star
34

labeled-graph

Haskell Labeled Graph
Haskell
1
star
35

nofib

Haskell
1
star
36

cmap

emacs: do at point
Emacs Lisp
1
star
37

dvi-processing

Processing of dvi files
Haskell
1
star