# Beyond Vim and Emacs: A Scalable UI Paradigm
Sid Kasivajhula
[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--sid-kasivajhula.webm" subtitles="/2020/subtitles/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--sid-kasivajhula.vtt" size="161MB"]]
[Download compressed .webm video (45.1M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--sid-kasivajhula--vp9-q56-video-original-audio.webm)
[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--questions--sid-kasivajhula.webm" subtitles="/2020/subtitles/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--questions--sid-kasivajhula.vtt" size="40MB"]]
[Download compressed .webm video (5M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--07-beyond-vim-and-emacs-a-scalable-ui-paradigm--questions--sid-kasivajhula--vp9-q56-video-original-audio.webm)
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. If it is already a "modal"-like minor mode, then we
ocould potentially do it this way. But in general, it could make sense
to couple minor modes 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. From a quick look, I can say that versors is partially related to rigpa, in that its "cursors" roughly correspond to noun modes. Rigpa isn't limited to noun modes, though. For instance Vim's normal mode contains many nouns and a special command language. On the other hand, Emacs's usual editing behavior doesn't think in terms of nouns at all and has a myriad of ad hoc keybindings. Yet, both are rigpa modes, along with modes like window-mode and buffer-mode which each correspond to individual nouns (like versor). Rigpa is less about the nature of the modes (about which it is relatively unopinionated, although noun-specific modes may be a common choice) than it is about the relationship between modes, the ability to structure them and interrelate them and configure them on the fly.
## 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 interface 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>
