On 22/10/06, Daniel Trstenjak <Daniel.Trstenjak@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.