path: root/modes/Concepts.txt

Title: Concepts and designs of modes 
Author: JSDurand
Created: 2021-01-01
-------------------------------------

======================================================================
                             Introduction
======================================================================

In this document, and in this document only, sometimes we refer to
Emacs as "the editor", though the situations referred to are
definitely different from those of other editors, and the editor Emacs
does not represent other editors in any way. This reference is solely
out of personal preferences.

When we edit texts through a text editor, since there are a lot of
functionalities we would like to perform in the editor, we oft end up
with binding many keys with various functions in the editor. This
causes a problem: the keys are either too long to conveniently press
or too compactly packaged that it requires experience to remember and
use them at ease (what if we can execute the form “(require
'experience)” in Emacs ;P).

The proposed way in this document to solve this dilemma is to make
keys behave according to the "contexts" of the editor. That is to say,
we are using the same key to perform such different tasks as to switch
buffers, to select different windows, and even to pop up a different
mail to read.

To be honest, there is nothing new in this idea: it is the core idea
of the so-called "modal editing". And there are numerous packages that
implement similar ideas in Emacs already, such as evil, god-mode, or
even viper, just to name a few.

The difference of my implementation with other packages is that I
would like to first push this idea to a more general level, before
specialising to some specific states. In other words, the modes should
reflect more dedicated states of the editor and the current task I am
performing. More precisely, when I am trying to switch buffers, I
shall be in a "buffer mode", that permits me to switch buffers just by
arrow keys, or whatever keys I have chosen for the concepts of "up"
and "down". Moreover, the concepts include not only four directions
but also "previous" and "next", whose functions are to switch to the
previously used and the next-to-be-used buffer respectively.

Simply put, a mode is nothing but a correspondence from concepts to
functions. And the user should decide how to map these concepts to
keys.

Then this document tries to record the modes that I accumulated
through the use of the editor.



======================================================================
                      Analogy with the languages
======================================================================

If we view pressing keys as the user speaking to the computer, then
these keypresses of a user form a "language", in a formal sense. The
letters are the keys on the keyboard (so each user has a potentially
different set of letters), and the words are valid key sequences, as
per the Emacs parlance. For example, in the built-in language of
Emacs, the word "C-x 4 d" means to open a directory in another window.

There are some characteristics of this kind of languages. The most
obvious characteristics is that the verbs are all in one of two
"moods" (this term comes from Latin grammar if my memory serves me):
imperative and interrogative, since this language serves the only
purpose for the user to give the computer commands, or to query some
states.

Another characteristics is that, there are a myriad of "tenses",
"conjugations" and "declensions". These refer to the fact that a key's
meaning depends upon the contexts. So we can view "C-x 4 d" as a
conjugation of the verb "C-x d", which is to open a directory in the
current window.

However, as one of the reasons that the Sanskrit language is deemed
not easy to learn is that it has numerous declensions, conjugations,
liaisons, and irregularities, the same thing happens with the
key-binding language. If a key-binding language has too many tenses
and irregularities, then it is difficult to remember, to use, and to
"speak". And, from my point of view, the built-in key-binding language
of the editor is too difficult to use, however logical the design of
that language may be.

The aim of this document is thus to solve this problem, for me and for
me only, at the same time laying some foundation upon which others may
build their own languages to solve their own problems, in the future.



======================================================================
        The solution in terms of the analogy with the languages
======================================================================

So what does our solution mean in terms of the above analogy with the
languages? I think this is the difference between the agglutinative
languages and analytical languages.

According to Wikipedia, "an agglutinative language is a type of
synthetic languages with morphology that primarily uses
agglutination." And agglutination is "a linguistic process pertaining
to derivational morphology in which complex words are formed by
stringing together morphemes without changing them in spelling or
phonetics."

Basically, this is one of the characteristics of the default Emacs
language: concatenating affixes after affixes, or prefixes.

Again according to Wikipedia, "an analytic language is a language that
primarily conveys relationships between words in sentences by way of
helper words (particles, prepositions, etc.) and word order, as
opposed to using inflections (changing the form of a word to convey
its role in the sentence)."

In our contexts, this means we use helper words (key sequences) to
alter the meanings of keys. In addition, it is also a common oral
practice to use "persistent" contexts. For example, (I don't know
about English, so here I refer to the situation with my mother tongue
Chinese), when telling a story, after one declares this happened in
the past, we can safely use verbs without tenses and expect that the
listener understands this is a past action. Hence the effect I want to
achieve is that we can expect the editor to understand that after we
changed our contexts, the keys have a different meaning now.



======================================================================
                      Major modes and minor modes
======================================================================

One might wonder why I don't just use Emacs' built-in major modes and
minor modes, as those sound like a generalization of the ideas of
modes already. In this regard, I really think my idea of modes is just
like a minor mode, in that it is not directly relateed to the file or
the buffer being operated on. Rather it concerns the intention of the
user. And in effect we can implement the modes as depicted above using
nothing but major and minor modes.

There is a problem though: the minor modes control the keymaps through
the variable "minor-mode-map-alist". It is a plain association list
that associates minor-mode symbols to keymaps. Wheneven the minor-mode
symbol has a non-nil value, the associated keymaps is in effect.
However, the order of priority for these maps is the same as the order
of appearance in this association list. This means we might sometimes
get unpredictable results when we try to activate certain functions in
our modes. Therefore, to avoid this problem, I decided to avail of a
higher-priority map, namely "emulation-mode-map-alists". And it
functions in the same way as the former.



======================================================================
                           General concepts
======================================================================

Some concepts are in a sense "universal" to all modes. These are the
concepts that don't concern with the specific functionalities of
modes, but rather with the abstract notion of modes.

quit        - Quit a mode, and nothing else.
quit & bury - Quit a mode and bury the current buffer.
quit & quit - Quit a mode and quit the selected window.
quit & kill - Quit a mode and kill the current buffer.



======================================================================
                              Buffer mode
======================================================================

The first mode that I desire is a mode that operates on the buffers.
As Protesilaos Stavrou rightly observed, the true power of Emacs lies
in its handling of the buffers, since this frees the limited screen
estate and leverages the power of the computer to manage the editing
resources. So naturally there are a lot of operations related to
buffers that are quite useful to us. Below is a list of the
correspondence between concepts and functions that I can think of.

up        - The previous buffer in the list of buffers.
down      - The next buffer in the list of buffers.
previous  - The previously used buffer.
next      - The next-to-be-used buffer.
            In practice this means the buffers that the user left by
            going to the previous buffer.
jump/show - Either use the completion framework to select a buffer
            or display an interactive list of buffers, i.e. ibuffer.
            This can first call ibuffer, and the second call uses
            the completion framework.    
last      - Whether this deserves an independent concept is still
            debatable. This just switches to the last used buffer. If
            called repeatedly, it switches between two buffers.
save      - Save a buffer.
            I am used to frequently save buffers, so it is important
            to access this conveniently.
kill      - Kill and save a buffer.
delete    - Simply kill a buffer.
rename    - Rename a buffer.
search    - Search through a buffer.



======================================================================
                              Window mode
======================================================================


To be honest I don't believe I really need to manage windows. Rather I
would like Emacs to automatically handle the windows the way I want.
But since it is too difficult to guess my mind, this mode is still
relevant.

up        - Go up a window.
down      - Go down a window.
left      - Go left a window.
right     - Go right a window.
jump/show - Use the completion framework to choose a window to go to.
            It might make sense to have a buffer list all windows that
            I can jump to, just like an "iwindow".
save      - Save a window configuration.
load      - Load a window configuration.
delete    - Kill a window.



======================================================================
                               Help mode
======================================================================

The idea is to make the help system behave more conveniently. For
example, currently if the user opens a file thruogh the help system,
then the user is put in the major mode corresponding to that file. I
think it might be more convenient if the user is still in the help
mode. When and only when the user chooses to exit the help mode,
should the user be put in the major mode corresponding to that file.

up       - Scroll "down".
down     - Scroll "up".
previous - Go to the previous help buffer.
next     - Go to the next help buffer.
search   - Searching through the help buffer is also important.



======================================================================
                            Selection mode
======================================================================

I haven't decided yet whether this should be a separate mode or just a
concept for other different modes that turn the current "object" into
a selection.



======================================================================
                     View mode, or the screen mode
======================================================================

This mode of Emacs really surprised me when I first learned about its
existence. It hinted at endless possibilities, in some sense. But it
does not fully meet my expectations.

I view document frequently. I believe that writing is a reflection of
thinking, and while I am thinking, I like to scroll through the
document to answer such questions as what have I written, does the
current writing follow the outline or the sketch in my mind, do the
writings hint at some directions that I didn't notice before I wrote
them down, and the rest. Consequently, it is am important part of my
editing activity to view the documents.

Since my screen is limited, the occassion occurs frequently that I
need to scroll the document to view some parts of it. In addition, I
like to highlight things, so it is equally important to easily select
or highlight arbitrary things on the screen. Thus my primary focus in
viewing documents are scrolling, positioning the cursor, highlighting,
and (re)centering the buffer.

To be more precise, I would like the directional concepts to be
directly (no pun intended) related to the scrolling of the documents;
this covers eight directional concepts (up, down, left, right, and
their "maximal" versions).

In addition to the above, I would also like to have special "concepts"
to go to the top, the middle, and the bottom of the screen.

Lastly, about the jump/show concept I shall talk a little. I used to
love the package "avy", which permits the user to jump to anywhere on
the screen by matching either a line, a character, or any character
sequence the user inputs. Upon further reflection, however, I do not
find anything this package offers that a plain old "interactive
search" does not offer.

By the way, instead of the name "view mode" it would probably be
better to call it "screen mode", since it concerns the screens. And to
view is a verb, not a state of the editor; after all, we are always
viewing something on the editor, unless it crashes.