[vial-devel] Re: [slim-vim] Vial has a home on common-lisp.net

[Brad Beveridge]

On 22/10/06, Daniel Trstenjak <Daniel.Trstenjak at online.de> wrote:
>
> Hi Brad,
>
> At the moment you really seem to have a productive phase :).
> I find that it's very admirable to start a new editor,
> because for me personally it would be very painful to redo
> the work all others already have done.

Yah :)  But I justify it to myself with a few reasons
1) I'm learning Lisp and need a project
2) There are no Vi style editors written in Common Lisp
3) Starting an editor from scratch may be stupid, but is certainly not
unprecedented :)

> In a former mail you said that you started Vial because
> the structure of Vim wasn't sufficient enough for a
> good Slime/Lisp development environment.
>
> Is it really fully illusive to make a fork of Vim
> and restructure it, so that it will become a sufficient
> Slime/Lisp development environment.
>
> I don't want to make any proposal to you, I'm only
> interested in the fact.

Firstly, I'd like to start out by saying that Vim is my editor of
choice and from a user perspective it is a fantastic editor.  Now I'm
going to disparage Vim's code :)  I'm a C guy by day, so I think I
know my way around C code.  Vim's code is some of the ugliest C code
I've encountered.  It is also pre-ansi C compatible, which makes it
pretty ugly.
Vim has been designed to allow features to be compiled in and out, but
the way this is implemented is to surround code with #ifdef/#endif
blocks - so the code is littered with feature specific code wrapped in
blocks.  There are functions that are pages and pages long.  Modules
are thousands or tens of thousands of lines long.  The code is deeply
entangled with itself, it is very hard to pick one small bit of code
and confidently change it without knowing the entire system.  There
are over 350K lines of code in Vim.
Vim also has a very odd execution structure, it can block waiting for
input in many places and what you are allowed to do in each place
might be different.

Also, I don't think that Bram is super willing to accept major changes
to Vim.  There was an effort to integrate Vim to KDE, which eventually
faltered after about 2 years.  Those guys started the yzis.org
project, an attempt to write an editor backend that runs like Vim.
That might be a good project to hook in to, but they aren't moving
that quickly.

This all makes for a very painful development experience, and forking
Vim would be very hard.

It might have been worth looking at another Vi like editor (elvis,
nvi), but the first steps there would be to integrate ECL and try from
scratch.

I think that so far my choice to start fresh has been a good one, I'm
learning CL as I go, but so far my feature list is:
 - Unlimited undo/redo - Simple conceptual model
 - Easy to add Vim commands [1]
 - Multiple buffer support
 - Multiple window support
  - Regex searching
 - colour support
 - search highlighting
  - autocomplete for EX commands (ie :e filen<tab> -> :e filename.lisp)
  - basic commands: jkhl, d, dd, 0, $, a, A, i, I, y, yy, p, u, <C-R>

All this in less than 2800 lines of code, and I intend to reduce that
line count when I have a clean up soon.  Less lines means less bugs
and easier to understand.

One of the goals of Slim-vim was to provide CL code that could be
easily used to interface to Slime in other projects - that is still a
goal.  Slim-vim and Vial will stay separate projects, though pretty
soon Vial will be getting Slim-vim support.

For more thoughts about Vial, read the wiki page
http://bradb.nfshost.com/stuff/index.cgi/Vial, or grab the code and
read overview.notes

I hope that I've managed to explain my reasoning well enough :)
Vial is currently usable, but only if you are prepared to have some
issues and basically be a developer.  If you feel like checking it
out, please do - I'd love to get another developer or two working on
it.

Cheers
Brad

[1] The command to delete a region is "d{motion}", ie "d$" "d0" "dj"
"d2j".  The code to implement this is:
(defun command-d-motion (region)
 (active-register-needs-updating)
 (delete-region region :whole-lines t))
(define-pattern 'op-motion "d" #'command-d-motion)

There is of course magic behind DEFINE-PATTERN, but for commands that
operate as operation-motion, the function simply needs to take a
region.  Repeats of the command or of the motion are taken care of
automatically.