summaryrefslogblamecommitdiffstats
path: root/vim-acme-design.rst
blob: a9954de0e651086043018a65d43305d241b42c7f (plain) (tree)














































































                                                                            
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.

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.

Hyperlinks in the body of text
------------------------------

x


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