# Beyond Vim and Emacs: A Scalable UI Paradigm
Sid Kasivajhula
A practiced dexterity with the arcane incantations known as keybindings is
the true mark of the veteran Emacs user. Yet, it takes years to get there,
and if you tried to explain what you were doing there, nobody would
understand, least of all those Vim users who would say that the whole
enterprise was foolhardy to begin with. They don't get it, those fools. Let
them flounder about in their "normal mode." Normal isn't good enough for
me! I want exceptional, IDEAL, I want… glorious mode, that's what I want.
And the only thing that'll cut it is if I do it … my way. Why, with my
precious emacs.d, I'm invincible! Well… just between you and me, there
are times when learning new keybindings every time someone makes a new toy
gets to be a bit of a drag, and some days I can't keep my C-c's and my C-c
C-c's straight if I'm being honest with you, but you'll never catch me
admitting it! I do wonder if there's a better way to get to glorious mode,
even though my .emacs.d is already perfect (of course).
If this secretly sounds like you, then rejoice, there just might be a new
way, a better way! And you could potentially get there in days instead of
years, so that even your script kiddie coworker with their "VSCode" (groan)
may at last come around to your way of looking at things, and, maybe, just
maybe, even those Vim users (hiss!)!
"Epistemic" Emacs is a user interface paradigm based on treating aspects of
the user interface as conceptual entities that can be reasoned about in
terms of a standard language. Essentially, instead of learning keybindings
for each specific action, you learn keybindings for general, conceptual
habits, kind of like Vim, except that instead of reasoning only about text,
you reason about any aspect of your interaction with the machine, whether
it's windows or buffers or even those interactions themselves. The promise
of this approach is that you just learn a simple language once, and you can
then apply it to vastly different aspects of your user interface, with the
same keybindings doing different things in different contexts, in sensible
and predictable ways. And in principle, whenever that new toy technology
comes around, anyone could extend the UI language to apply to it in a
matter of minutes, and you'd already know how to use it.
<!-- from the pad --->
Actual start and end time (EST): Start: 2020-11-28T11.00.47; Q&A 2020-11-28T11.18.12; End: 2020-11-28T11.24.51
# Questions
## Can minor-modes in Emacs be integrated via chimera as a "mode"?
### Good question. More likely, minor modes could be coupled to rigpa "modes", towers (sets of modes), or complexes (sets of towers), so that entering those modes/towers would enable those minor modes, and likewise disable the minor modes upon exiting. E.g. for Lisp editing, we might want to enable the symex / paredit minor mode in Lisp tower, and disable it upon swapping to Vim/Emacs tower.
## Do you think it would be hard for people to remember all the modes and bindings?
### Bindings, no - it would be easier than currently because the bindings generally stay the same across modes (e.g. hjkl always means left down up right, and there are other conventions)
### Modes, if the tower is 2-3 tall, then it's not a problem at all. Totally intuitive. For > 3 it might be hard, so I think in practice you would alternate across more small towers rather than have fewer big towers
### Also, most modes are always available via "direct access" keybinding (eg. s-w = window mode), so you can jump to one at any time, and it'll return you to your original position in the tower when you exit. Modes don't need to be in the current tower in order for you to use them. But if you're using them frequently you might want to add them or temporarily switch to a tower that has them – whatever feels the most natural for the specific case.
## Are you familiar with <http://emacs-versor.sourceforge.net> ?
### And other earlier implementations.
### A short comparison would be nice.
### Not familiar with this, but it looks very interesting
## What package is used?
### Probably Symex mode! → <https://github.com/countvajhula/symex.el>
### The package isn't yet published to MELPA → <https://github.com/countvajhula/rigpa> (was called indra.el)
### The mode is called \`epistemic-mode' (final name is not decided on yet)
## Why is the package called rigpa?
### A reference: <https://en.wikipedia.org/wiki/Rigpa> (knowledge of the ground)
## How to deal with Dvorak (et al.) layouts? This has always bugged me. Is there a "XModmap Mode"…?
### Vim users don't remap their keys. The homerow is not a big deal, actually.
- Hm… I've always found it a bit of an obstacle but haven't tried hard! hjkl → jk makes sense but hl, not so much.
- The day you want to do this, you'll absolutely be able to do it and have it become natural. Just gotta want it :)
## I mostly use default model provided by vanilla emacs and work in org-mode for text editing. Can you give some examples, e.g. how can the user can use the concept of "mode of mode" to do some interesting editing?
### The more modes you have, the shorter the individual keystrokes become.
- ^ Not to be a pain but my comment about Dvorak is related :-)
### There are many bindings in Org mode (e.g. agenda manipulation, manipulating headings and subheadings, promoting/demoting) that would be a natural fit for a dedicated modal interface. At the moment you probably use only a subset of all of the available options because of the constraints of conveniently (1) knowing about, (2) remembering and (3) using the bindings. With a dedicated mode, you could edit Org buffers using a Vim-like modal interface where all of the options are easy to remember and use
### Mode mode / tower mode could be useful if you are doing literate programming or "multi-modal" org buffers where you have many different languages embedded within the Org file. In this case, you could modify your tower using mode mode, or swap between different towers, to quickly have the right modes for different parts of the file
## How do new modes come into existence?
### Modes from any modal interace provider are supported via a modal interface abstraction layer ("chimera")
### You can define new modes as a hydra or as an evil state, and then they just need to be "registered" with the framework via a function call for them to be incorporated
## Is this built on top of Hydra?
### Any modal interface provider is in principle supported. There is an abstraction layer called "chimera" that allows any provider to be used as long as it implements an interface (e.g. including indicating entry and exit hooks for each mode)
### Some of the modes are evil modes (e.g. normal, insert)
### While others are hydras (window, buffer, etc) (including Symex? yes, Symex too)
## Which retro theme are you using?
### green phosphor
## Will this involve defining more epistemic-modes for non-editable buffers like Dired? How do you deal with the explosion of the number of modes?
### This is a great question, so here is a long answer:
- I am keen to keep this extension lightweight so that it plays well with existing Emacs tools without needing a custom ecosystem. The modal interface abstraction layer "chimera" would be a big part of this, enabling existing modal-like interfaces to be recognized in the framework out of the box, meaning that they would be automatically "wired into" the broader framework via the standard exits (e.g. Escape and Enter)
- I'm not sure what the best way to handle dired would be, but if it could be handled in this way, then that would be the way to do it.
- The "complex" of towers initially available is tied to major mode, that takes away some of the complexity right off the bat. E.g. when you open a Lisp file it gives you a Lisp-related + general-purpose complex of towers
- The idea is to support the "explosion" of modes, but make it scale well by (1) having them be structured, and (2) the structure being the same at every level
## How do you deal with the mental overhead of keeping a stack of modes and your position in it? While this simplifies the actual editing process by defining them as a single set of keybindings, the complexity is transferred to navigating modes.
### While the complexity is transferred, the nature of that complexity is different. In the case of keybindings, the complexity is unstructured and ad hoc, whereas in the case of mode navigation, it's a matter of "going to the right place" for your keys to have the right meaning
### In practice you would only have towers of size 2-3 I would guess, with every other mode jump always being available via an ad hoc jump (e.g. even in Vim tower, you can always jump to Window mode and it would return you to the original mode you were in upon exit)
### And the main paradigm would be swapping between small towers
# Notes
- Indra's Net: <https://en.wikipedia.org/wiki/Indra%27s_net>
- "we are at a higher level looking down at the text, we can describe this text…"
- "there is a way to go down to ground level, and a way to escape from that to the referential level"
- "all of the nouns of the world of text are available"
- …. Or you could have a dedicated mode for every noun — Nouns as modes
- Character, Word, Line mode; Window mode! All with the same basic keystrokes.
- "Rumpelstiltskin Principle" from CS — if you can name something you have power over it
- modes of modes → "Mode mode" (the modes that are present in the buffer)
- Such a refreshing point of view.
- Tower mode → ?? "There are many towers available for use in different buffers"
- Cf. <https://www.press.umich.edu/19900/tower_of_myriad_mirrors>
- Not a real mode, but a "referential plane"
- Demos "Strange Loop".
- Two directions: sideways changes perspective (normal, word, line) all different perspectives; up or down (takes you through meta levels)
- Unknown meta level → same basic interactions
- <https://github.com/countvajhula/indra.el> formerly called epistemic-mode, now called rigpa (concept in Tibetan Buddhism, in Dzogchen teaching, or the great completion)
- Similar idea from <http://emacs-versor.sourceforge.net>
