diff options
Diffstat (limited to 'modes/Concepts.txt')
| -rw-r--r-- | modes/Concepts.txt | 298 |
1 files changed, 298 insertions, 0 deletions
diff --git a/modes/Concepts.txt b/modes/Concepts.txt new file mode 100644 index 0000000..e9cfac4 --- /dev/null +++ b/modes/Concepts.txt @@ -0,0 +1,298 @@ +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. |