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 Stewart ([2010] 2017), 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 [1] 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 Bush (1945), Nelson (1974), Nelson (1960), and Larson (1984) and Larson (1986). 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 [2], 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 Christiansen (1999) 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 [3]. 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 [4]). 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 Zawinski (2003) (“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 Free Software Foundation (b.r.) (which, according to Moolenaar (2017) is what :termdebug uses), but @miranda:2017gdb claims that apparently it is really not good enough either. Miranda (2017) 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?).