The first published version of the vim-Acme article

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
 ==========