path: root/2020/info/07.md

# 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 &#x2013;
  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"&#x2026;?
- Vim users don't remap their keys. The homerow is not a big deal,
  actually.
- Hm&#x2026; 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&#x2026;".
- "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".
- &#x2026;. 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>