Update

1 files changed, 44 insertions, 32 deletions

diff --git a/2020/info/07.md b/2020/info/07.md
index 4859eca0..946e6975 100644
--- a/2020/info/07.md
+++ b/2020/info/07.md
@@ -48,49 +48,61 @@ Actual start and end time (EST): Start: 2020-11-28T11.00.47; Q&A 2020-11-28T11.1
 
 
 ## 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.
+
+- 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.
+- 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
+- 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)
+- 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)
+- 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 :)
+- 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
+- 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
+- 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)
+- 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
+- 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
+- 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
+- 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