Complete first draft (alpha-version) of the vim-ACME article.

1 files changed, 149 insertions, 91 deletions

diff --git a/computer/vim-acme-design.rst b/computer/vim-acme-design.rst
index 16f1688..6d1b973 100644
--- a/computer/vim-acme-design.rst
+++ b/computer/vim-acme-design.rst
@@ -14,6 +14,7 @@ Design notes on plan9-for-vimspace
 
 .. default-role:: xcite
 
+.. FIXME Add quotations from original paper where needed!!!
 
 When I have seen for the first time `@cox:2012tour` presenting 
 ACME, modular text editor from Plan9, I was intriguied by its 
@@ -53,49 +54,52 @@ User Interface
 Tag
 ---
 
-    The tag contains the name of the window (usually the name of the
-    associated file or directory), some built-in commands, and a scratch
-    area to hold arbitrary text.
-
-The tag looks very much like our good bad friend, toolbar, which 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 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.
-
-Another problem with the normal toolbars (including the gvim ones) is
-that they require using mouse which makes it unappealing for hard-core
-rodent haters (like me ;)). However, this problem shouldn’t impossible
-to overcome. Shortcut could be created for activating the toolbar and
-then one could move in it (for example) with ``TAB`` and activate with
-``ENTER``. Or there could be set of shortcuts for activating first,
-second, etc. “button” in the toolbar (e.g., ``<Leader>t1`` or something
-of that type).
-
-And yes I like very much possibility of calling not only “internal”
-(however defined) commands, but also external scripts 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.
+    The tag contains the name of the window (usually the name of 
+    the associated file or directory), some built-in commands, 
+    and a scratch area to hold arbitrary text.
+
+The tag looks very much like our good bad friend, toolbar, which 
+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 
+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.
+
+Another problem with the normal toolbars (including the gvim 
+ones) is that they require using mouse which makes it unappealing 
+for hard-core rodent haters (like me ;)). However, this problem 
+shouldn’t impossible to overcome. Shortcut could be created for 
+activating the toolbar and then one could move in it (for 
+example) with ``TAB`` and activate with ``ENTER``. Or there could 
+be set of shortcuts for activating first, second, etc. “button” 
+in the toolbar (e.g., ``<Leader>t1`` or something of that type).
+
+And yes I like very much possibility of calling not only 
+“internal” (however defined) commands, but also external scripts 
+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.
 
 Hyperlinks in the body of text
 ------------------------------
 
-    Typing with the keyboard and selecting with the left button are as
-    in many other systems, including the Macintosh, 8½, and Sam. The
-    middle and right buttons are used, somewhat like the left button, to
-    ‘sweep’ text, but the indicated text is treated in a way that
-    depends on the text’s location—context—as well as its content.  This
-    context, based on the directory of the file containing the text, is
+    Typing with the keyboard and selecting with the left button 
+    are as in many other systems, including the Macintosh, 8½, 
+    and Sam. The middle and right buttons are used, somewhat like 
+    the left button, to ‘sweep’ text, but the indicated text is 
+    treated in a way that depends on the text’s 
+    location—context—as well as its content.  This context, based 
+    on the directory of the file containing the text, is 
     a central component of Acme’s style of interaction.
 
-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.
+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 
 just a normal hypertext, but not the limited version we have now 
@@ -109,45 +113,47 @@ either local (somehow connected to the local path name; of
 course, local in Plan 9 is quite relative term) or activation of 
 some command.
 
-Of course, hypertext is not completely new idea in vim (``Ctrl-]``, to
-some extent ``K``), so it would be probably wise just to extend already
-existing system with new features.
-
-Given that the system is intended to work with plain text (there is no
-separation of presentation from content, aka
-what-you-see-is-what-you-have), it is probably a good idea, actually it
-is necessary, to use for recognition of the hyperlinks more
-sophisticated and more stealthy form than just 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.
-
-Of course, there will be set of already defined links. The ``vi``-style
-of ``filename:line#`` is probably a good one, and it could be quite
-naturally extended to utilize some kind of regular expression-like style
-of pinpointing the location in a document in more flexible way than just
-by line numbers. It should use either absolute style pathnames, or just
-relative pathnames when the directory the local of the current document
-should be kept as a root of the hierarchy. Which means, that I am not at
-all persuaded it should support ``../../filename.txt`` up-the-hierarchy
-stepping filenames.
-
-Also, given the current date and age, it is probably necessary to
-support somehow the plain URLs (possibly by calling external viewer
-program, e.g. by utilizing ``xdg-open`` style of programs), at least
-``http[s]://``.
-
-Among programmers and Unix users it is quite common to use ``man(1)``
-style of links between two manpages, so it is possible it could be used
-as well.
-
-However, the biggest power of the system should lie in fact that it
-should be 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.
+Of course, hypertext is not completely new idea in vim 
+(``Ctrl-]``, to some extent ``K``), so it would be probably wise 
+just to extend already existing system with new features.
+
+Given that the system is intended to work with plain text (there 
+is no separation of presentation from content, aka 
+what-you-see-is-what-you-have), it is probably a good idea, 
+actually it is necessary, to use for recognition of the 
+hyperlinks more sophisticated and more stealthy form than just 
+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.
+
+Of course, there will be set of already defined links. The 
+``vi``-style of ``filename:line#`` is probably a good one, and it 
+could be quite naturally extended to utilize some kind of regular 
+expression-like style of pinpointing the location in a document 
+in more flexible way than just by line numbers. It should use 
+either absolute style pathnames, or just relative pathnames when 
+the directory the local of the current document should be kept as 
+a root of the hierarchy. Which means, that I am not at all 
+persuaded it should support ``../../filename.txt`` 
+up-the-hierarchy stepping filenames.
+
+Also, given the current date and age, it is probably necessary to 
+support somehow the plain URLs (possibly by calling external 
+viewer program, e.g. by utilizing ``xdg-open`` style of 
+programs), at least ``http[s]://``.
+
+Among programmers and Unix users it is quite common to use 
+``man(1)`` style of links between two manpages, so it is possible 
+it could be used as well.
+
+However, the biggest power of the system should lie in fact that 
+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.
 
 Acme-specific programs
 ----------------------
@@ -167,16 +173,20 @@ of the same primary enthusiasm after the invention of computer
 mouse which drove user interface of the first Apple MacIntosh 
 (albeit Plan9 didn’t have to conform to the commercial reality, 
 so they could use the best display technology, best monitors, and 
-three-button mice). 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 consider what we 
-have left here otherwise.
+three-button mice). The design was apparently meant to replace 
+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 
+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, 
@@ -191,6 +201,15 @@ types [#]_). Therefore, in this paper we ignore Oberon, although
 it is certainly perhaps closer to the current ideas about 
 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 
+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 
 original document are pointless, because vim already contains 
 functionality provided by them (``g`` command) or there are other 
@@ -224,6 +243,38 @@ Those external tools are however often very focused on being used
 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 
+originally when I was writing the first version of this paper, 
+only to be at least partially fulfilled by vim8, was the idea of 
+independent programs running as daemons in background 
+communicating with the editor. I think it still waits its 
+possibilities to be fully discovered, but we are on the way 
+certainly. I like ``:termdebug``, but apparently there is no way 
+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.
+
+Another venue for the development is extending number of external 
+sources which can be seamlessly used inside of the text editor 
+and some generalized way how to integrate them. As 
+`@nagel:2017make` shows introducing external information sources 
+into vim are quite hackish. In light of the above discussion on 
+user defined hypertext, we should be able to define manpage 
+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.
@@ -242,15 +293,22 @@ system utilities (all of them are located outside of ``$PATH``).
    his projected recently and created similar system on the 
    current hardware in 2013 (`@wirth:2013programming`)
 
-.. [#] Obscure example of this tool was `@anonymous:geos`, which
-   however managed to have swiftly working environment for work 
-   with text, pictures, and (I think) spreadsheets on ancient 
-   PC/XT computer in time where Microsoft Windows required 
-   high-end systems.
+.. [#] Obscure example of this tool was GEOS_, which ultimately 
+   failed, but it managed to have swiftly working environment for 
+   text, pictures, and (I think) spreadsheets on ancient PC/XT 
+   computer in time where Microsoft Windows required high-end 
+   systems.
 
 .. _project:
     https://github.com/plan9-for-vimspace/plan9-for-vimspace/
 
+.. _GEOS:
+    https://en.wikipedia.org/wiki/GEOS_(16-bit_operating_system)
+
+.. _`xman(1)`:
+   https://www.x.org/releases/X11R7.5/doc/man/man1/xman.1.html
+
 References
 ==========
+
 .. bibliography::