1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Design notes on plan9-for-vimspace
##################################
:date: 1970-01-01T00:00:00
:status: draft
:category: computer
:tags: vim, plan9, ACME
When I have seen for the first time the screencast_ 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 I was
driven away by the mouse-driven nature of the result. I am a strong
believer in Zenclavier_ and mouse is the first thing which breaks any
attempts of learning my fingers patterns of behavior. I remember I was
thinking when I saw the screencast 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:: {filename}/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_ for help, but then I decided that
actually what I was asking for (to summarize the screencast, separate
individual ideas, and try to relocate them to the vim universe) could be
done by myself. Better for annotation than screencast is actual paper,
so I have found (because of the great Bell Labs tradition of documenting
their design in standalone papers) Rob Pike’s paper_ describing design
of ACME. This article is basically commentary on this 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 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
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 Vannevar Bush (Memex_), Ted Nelson (Xanadu_), and Neil
Larson (`Maxthink and Houdini`_). 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.
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 line 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.
.. [#] 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.
.. _project:
https://github.com/plan9-for-vimspace/plan9-for-vimspace/
.. _screencast:
https://www.youtube.com/watch?v=dP1xVpMPn8M
.. _Zenclavier:
http://archive.oreilly.com/pub/a/oreilly//news/zenclavier_1299.html
.. _asked:
https://github.com/plan9-for-vimspace/plan9-for-vimspace/issues/4
.. _paper:
http://doc.cat-v.org/plan_9/4th_edition/papers/acme/
.. _Memex:
https://en.wikipedia.org/wiki/Memex
.. _Xanadu:
https://en.wikipedia.org/wiki/Project_Xanadu
.. _`Maxthink and Houdini`:
http://maxthink.com/
|
