Design notes on plan9-for-vimspace
##################################

:date: 2017-12-04
:category: computer
:tags: plan9, ACME, GUI, neovim
: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

When I have seen for the first time :xcite:`@cox:2012tour`
presenting 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
:xcite:`@christiansen:1999zenclavier`, 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.  I haven’t came with
anything, so I gave up then and forgot whole thing.

.. image:: {static}/images/glenda_sshot.png
    :width: 66%
    :align: center
    :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
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 :xcite:`@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 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) :xcite:`@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
==============

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 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 
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 (I am slowly but surely distancing myself from the idea 
of :xcite:`@stewart:2017vim`, but I am still fighting).

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

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 :xcite:`@bush:1945as`, :xcite:`@nelson:1974computer`,
:xcite:`@nelson:1960project`, and :xcite:`@larson:1984maxthink`
and :xcite:`@larson:1986houdini`. Target of the link can be a way
richer than just a jump to other document (or some particular
place in a document). Links are in their nature 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 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 
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 activating the link.

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 
    first program written for Acme was therefore one to run 
    a shell or other traditional interactive application in 
    a window, the Acme analog of xterm. 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.

First of all, I needed to disentangle what I think about those
“typescripts”. It seems to me that Plan9 user interface was
child 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). 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 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
:xcite:`@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, 
but to some extent it was more distant from Unix and vi tradition 
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 
(not only object oriented programming, but also object-centered 
user interface, where tools are oriented around particular data 
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.

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 
to write this paper, I was consdiering whether the internal term 
is a good idea.  Now it is part of vim8, so the question is moot.  
However, it is simply terminal displaying output of programs run 
from vim (or inside of the terminal itself), but the editor 
should be also able to react back on (and read from) the content 
of the terminal.

It would be really interesting if the script running in ``:term`` 
would be able to open file for ediitng in vim in a new 
window/tab. Apparently we have mapping for keys in the terminal 
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 :xcite:`@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 for vim.  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
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 :xcite:`@free_software_foundation:debugging` (which, according 
to :xcite:`@moolenaar:2017patch` is what ``:termdebug`` uses), but 
`@miranda:2017gdb` claims that apparently it is really not good 
enough either.  :xcite:`@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 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://`` protocol, translation dictionaries, I use very 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.

.. [#] By “typescript” the author means content of the terminal 
   emulator or console, or bascial normal UNIX command line 
   oriented interface: “The typescript—an intermingling of 
   textual commands and their output—originates with the scrolls 
   of paper on teletypes.”

.. [#] Interesting thing is that even professor Wirth resurrected 
   his projected recently and created similar system on the 
   current hardware in 2013 (:xcite:`@wirth:2013programming`)

.. [#] 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

.. _Zotero:
    https://www.zotero.org/

References
==========

.. bibliography::