Po 04 prosince 2017
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.
When I have seen for the first time Cox (2012) 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 Christiansen (1999), 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.
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 Cepl (2016) 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) Pike (1994) describing design of Acme. This article is basically commentary on that paper, trying to identify individual features, and translate them to the vim universe.
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 ( 2017), but I am still fighting).
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 (2012) 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 (1992), 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 ( 2017). 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.
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 (n.d.) (which, according to Moolenaar (2017) is what :termdebug uses), but Miranda (2017a) claims that apparently it is really not good enough either. Miranda (2017b) and Eclipse Foundation (n.d.) says that the future of debugging is Integrating Debuggers into Visual Studio Code (n.d.), 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 (2016) 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 (2017) 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 (Wirth (2013))|
|||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.|