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