diff options
Diffstat (limited to 'computer/vim-acme-design.rst')
| -rw-r--r-- | computer/vim-acme-design.rst | 157 |
1 files changed, 95 insertions, 62 deletions
diff --git a/computer/vim-acme-design.rst b/computer/vim-acme-design.rst index 6d1b973..7773422 100644 --- a/computer/vim-acme-design.rst +++ b/computer/vim-acme-design.rst @@ -1,30 +1,32 @@ Design notes on plan9-for-vimspace ################################## -:date: 1970-01-01T00:00:00 -:status: draft +:date: 2017-12-04 :category: computer :tags: vim, plan9, ACME, GUI - -.. komentovaný článek je lokálně dostupný na - file:///home/matej/Dokumenty/clanky/ACME/index.html +:abstract: The purpose of this paper is to document any possible + ideas, which could be salvaged from the Acme text + editor of Plan9 fame, and reuse in vim. .. zotero-setup:: :style: chicago-author-date .. default-role:: xcite -.. FIXME Add quotations from original paper where needed!!! +(This is still a bit a work in progress, any comments and +suggestions are more than welcome). When I have seen for the first time `@cox:2012tour` presenting -ACME, modular text editor from Plan9, I was intriguied by its +Acme, modular text editor from Plan9, I was intriguied by its design which seemed to put Unix philosophy on steroids. However, in the same time I was driven away by the mouse-driven nature of the result. I strongly agree with `@christiansen:1999zenclavier`, -and mouse is the first thing which breaks any attempts of +that the automatism is the key for the increased productivity +(“to be in the Zone”, “to achive the Zen state of mind”), +and that a mouse is the first thing which breaks any attempts of learning my fingers patterns of behavior. I remember, when I saw the screencast, I was thinking whether it would be possible to -transfer somehow the modular nature of ACME to the vim world. +transfer somehow the modular nature of Acme to the vim world. I haven’t came with anything, so I gave up then and forgot whole thing. @@ -34,18 +36,18 @@ thing. :alt: screenshot of Plan 9 desktop So, I was very excited when looking for something else I found on -GitHub project_ trying to bring some Advantages of ACME text +GitHub project_ trying to bring some Advantages of Acme text editor to the vim. However, it is obviously in the early stages of development and it didn’t give much of description on what’s going on (or what’s at least planned to go on). So, I have asked in `@cepl:2016some` for help, but then I decided that actually what I was asking for (to summarize the screencast, separate -individual ideas, and try to relocate them to the vim universe) +individual ideas, and try to remap them to the vim universe) could be done by myself. The actual paper is better than screencast for annotation, so I have found (because of the great Bell Labs tradition of documenting their design in standalone -papers) `@pike:acme` describing design of ACME. This article is -basically commentary on this paper, trying to identify individual +papers) `@pike:acme` describing design of Acme. This article is +basically commentary on that paper, trying to identify individual features, and translate them to the vim universe. User Interface @@ -63,10 +65,10 @@ can be found in all GUI text editors and wordprocessors (including gvim). As such, opinions on it are rather mixed and some people (including me) immediately switch them off. It is possible though that if the tag was done right, it could be -actually useful. ACME’s design offer one possibly large advantage +actually useful. Acme’s design offer one possibly large advantage against normal toolbar in being very easily modifiable. Just by -pointing to it and editing its text one change the content of the -toolbar quite easily. +pointing to it and editing its text, one could change the content +of the toolbar quite easily. Another problem with the normal toolbars (including the gvim ones) is that they require using mouse which makes it unappealing @@ -83,7 +85,8 @@ when the internal command is not found with the given name. It is important to know, that all external commands are run with the ``$PWD`` being set to the directory of the currently opened -document. +document (I am slowly but surely distancing myself from the idea +of `@stewart:2017vim`, but I am still fighting). Hyperlinks in the body of text ------------------------------ @@ -101,7 +104,7 @@ Primary mouse button [#]_ is used more or like normal way the mouse is used in other text/word-processors, i.e., for selection, cutting, and pasting of text. -Most of what ACME does in the body of text is nothing more than +Most of what Acme does in the body of text is nothing more than just a normal hypertext, but not the limited version we have now in the World Wide Web, but it is closer to the original ideas of hypertext as envisioned by `@bush:1945as`, @@ -126,7 +129,8 @@ normal URL style of ``method://target``. Also, given that the system of links should be expandable, so that the user may add new types of links for her particular class of documents, it could be necessary to use something like regular expression or -some other mechanism. +some other mechanism and these scripts should be probably +specific to each filetype. Of course, there will be set of already defined links. The ``vi``-style of ``filename:line#`` is probably a good one, and it @@ -153,10 +157,10 @@ it is extendable. Somehow. Most likely some kind of RE for identifying anchors of links in the body of text (possible with passing some kind of parameters of a link) and something looking like a very simple scripting language to define the action -generated by the activating the link. +generated by activating the link. -Acme-specific programs ----------------------- +A bit on the Acme user interface philosophy +------------------------------------------- Although Acme is in part an attempt to move beyond typescripts [#]_, they will probably always have utility. The @@ -178,20 +182,20 @@ menus with the other more appropriate means of control (three-button mouse, chords), and unfortunately it came also before invention of context menus, which could be more appropriate than the application ones. When looking on -`@cox:2012tour` demo of ACME functionality, I can see user -inteface filled with quite interesting ideas, but fighting my -deepest persuasion that for the activity which consists mostly -from creating text, the keyboard oriented user interface is the -best, in short phrase “we don’t write with mouse”. It seems -significant to me that `@christiansen:1999zenclavier` came a lot -later primary as a reaction to this enamorment to mouse. So, let -us ignore this desire to “move beyond typescripts” and let us +`@cox:2012tour` demo of Acme functionality, I can see user +inteface fighting against my deepest persuasion that for the +activity which consists mostly from creating text, the keyboard +oriented user interface is the best, in short phrase “we don’t +write with mouse”. It seems significant to me that +`@christiansen:1999zenclavier` came a lot later primary as +a reaction to this enamorment to mouse. So, let us abstain from +this primary urge to “move beyond typescripts” and let us consider what we have left here otherwise. -While straying from the ACME itself, we probably need to mention -`@wirth:1992project`, which was original inspiration for ACME, +While straying from the Acme itself, we probably need to mention +`@wirth:1992project`, which was original inspiration for Acme, but to some extent it was more distant from Unix and vi tradition -than the later Plan9 and ACME was [#]_. Whereas Plan9 was firmly +than the later Plan9 and Acme was [#]_. Whereas Plan9 was firmly in the tradition of “everything is file” and “collection of small tools linked together by pipes” (and thus closer to vim running on Linux), Oberon was precursor of the object-oriented software @@ -203,14 +207,25 @@ object-centered computing. Another interesting related project, and even related to vi is `@macfarlane:2017programmer`. Even though, when briefly tested on -Linux, it seems more like combining all disadvantages of ACME (no +Linux, it seems more like combining all disadvantages of Acme (no syntax highlighting, simple text font, overuse of mouse) with disadvantages of vi (are there any?), and also it looks quite buggy (cursor shows in a very different place from where the text entry actually happens), it is as far as I know the only project in the similar venue to this paper. -Back to ACME. Obviously plenty of commands mentioned in the +Acme-specific programs +---------------------- + + This program, win, has a simple structure: it acts as + a two-way intermediary between Acme and the shell, + cross-connecting the standard input and output of the shell + to the text of the window. […] Acme’s advances over [older + similar program] include the actions of the right button […], + the ability to connect long-running programs to the user + interface. + +Back to Acme. Obviously plenty of commands mentioned in the original document are pointless, because vim already contains functionality provided by them (``g`` command) or there are other means of achieving the functionality. Originally, when I started @@ -228,19 +243,19 @@ mode (although probably just in its “normal” not in the inserting one?), but it would be interesting if we could run an action on selection/current word in the terminal. -ACME apparently follows the Zawinski Law (“Every program attempts -to expand until it can read mail. Those programs which cannot so -expand are replaced by ones which can.”) written with these tools -and small help tools. However, I think that is a wrong idea. -I think the main point of vim (and vi) is to be extensible -editor, not Emacs. However, the point is that apparently idea of -plumbing in ACME meant, that there should be no internal -scripting language for it, just external tools with plumbing to -stich all these together. Advantage being obviously independence -on particular language (I do agree, that support for six -independent programming languages in one editor is too much). +Acme apparently follows the `@zawinski:2003zawinski` (“Every +program attempts to expand until it can read mail. Those programs +which cannot so expand are replaced by ones which can.”) written +with these tools and small help tools. However, I think that is +a wrong idea. I think the main point of vim (and vi) is to be +extensible editor, not Emacs. However, the point is that +apparently idea of plumbing in Acme meant, that there should be +no internal scripting language for it, just external tools with +plumbing to stich all these together. Advantage being obviously +independence on particular language (I do agree, that support for +six independent programming languages in one editor is too much). Those external tools are however often very focused on being used -only inside of ACME, so they should be kept separate from normal +only inside of Acme, so they should be kept separate from normal system utilities (all of them are located outside of ``$PATH``). Another idea, which seemed to me surprising and interesting @@ -254,9 +269,26 @@ now how to connect it with any Python debugger, which is what I would need most now, but that’s exactly the type of application which could be best served by the two-way communication between vim and independent daemon program. I thought about moving pdb -towards `@free_software_foundation:debugging`, but -`@miranda:2017gdb` claims that apparently, it is really not good -enough either. +towards `@free_software_foundation:debugging` (which, according +to `@moolenaar:2017patch` is what ``:termdebug`` uses), but +`@miranda:2017gdb` claims that apparently it is really not good +enough either. `@miranda:2017debugsoon` and +`@eclipse_foundation:what` says that the future of debugging is +`@anonymous:integratingdbgvscode`, but it seems that the +development is in really early stages and nothing much solid +works well outside of VS Code (and according to a bit older issue +`@majumdar:2016debug` the protocol is hopelessly +under-documented). However, particular protocol is not that +important for this paper, it is the idea that vim should really +on external headless servers. + + There need to be more programs that use Acme. Browsers for + Usenet and AP News articles, the Oxford English Dictionary, + and other such text sources exist, but more imaginative + applications will be necessary to prove that Acme’s approach + is viable. One that has recently been started is an interface + to the debugger […], although it is still unclear what form + it will ultimately take. Another venue for the development is extending number of external sources which can be seamlessly used inside of the text editor @@ -268,20 +300,18 @@ reference as either target of the external browser (e.g., something like `xman(1)`_) or a small script defining means of conversion of the external source into something which vim can interpret natively. There are also heroic efforts to use -``dict://`` and other data sources in vim and everything seems -quite hackish and unstable. Some better approach is needed, in my -opinion. In the case of manpages I could imagine a modified -command ``man -Thtml`` (not converting references to other -manpages to targets parseable by vim, for example) and ability of -vim read such HTML file (something like ``lynx -stdin``?). - -.. I don't understand what the mentioned ``g`` is supposed to - mean. There is no isolated just ``g`` command, AFAIK. There - is ``gf`` and similar. +``dict://``, translation dictionaries, I use ver weird connector +for Zotero_ while writing this article, and other data sources in +vim and everything seems quite hackish and unstable. Some better +approach is needed, in my opinion. In the case of manpages +I could imagine a modified command ``man -Thtml`` (not converting +references to other manpages to targets parseable by vim, for +example) and ability of vim read such HTML file (something like +the embedded ``lynx -stdin``?). .. [#] Befing a leftie, I don’t like to assume that the left - button is a primary button, so instead of left, middle, and - right labels I use primary, middle, and secondary buttons. + button is a primary button, so instead of left, middle, and + right labels I use primary, middle, and secondary buttons. .. [#] By “typescript” the author means content of the terminal emulator or console, or bascial normal UNIX command line @@ -308,6 +338,9 @@ vim read such HTML file (something like ``lynx -stdin``?). .. _`xman(1)`: https://www.x.org/releases/X11R7.5/doc/man/man1/xman.1.html +.. _Zotero: + https://www.zotero.org/ + References ========== |